Date: Mon, 21 Feb 2005 16:40:10 -0800 From: Nate Lawson <nate@root.org> To: "Alexandre \"Sunny\" Kovalenko" <Alex.Kovalenko@verizon.net> Cc: freebsd-acpi@freebsd.org Subject: Re: Thermal state switching Message-ID: <421A7F6A.6040004@root.org> In-Reply-To: <1108597181.1001.8.camel@RabbitsDen> References: <1107914318.1015.15.camel@RabbitsDen> <420FB25B.8010106@root.org> <1108597181.1001.8.camel@RabbitsDen>
next in thread | previous in thread | raw e-mail | index | archive | help
Alexandre "Sunny" Kovalenko wrote: > On Sun, 2005-02-13 at 12:02 -0800, Nate Lawson wrote: > >>Alexandre "Sunny" Kovalenko wrote: >> >>>Good people, >>> >>>I was looking at thermal states switching by acpi_thermal.c and it looks >>>like follows (provided that temperature raises and falls slowly and >>>gradually): >>> >>>NONE =up> AC2 =up> AC1 =up> AC0 =down> NONE (1) >>> >>>I do not know whether this was intentional or not and, for me, something >>>along the lines of >>> >>>NONE =up> AC2 =up> AC1 =up> AC0 =down> AC1 =down> AC2 =down> NONE (2) >>> >>>seemed more natural. >> >>The behavior should be as in #2. If it isn't, we should fix that. >>However, I'm not sure how your patch would fix this. It seems more >>correct in that we only set the starting time after switching coolers >>but I don't see how this affects the ACx levels. Could you explain more? > > I do apologize for delay in answer -- day job decided to catch up with > me. > > I guess, I have not explained it properly to start with -- behavior (2) > could not be achieved because start time will be reset as long as you > have _ACx state with the threshold lower then your current temperature. > Or, rather, it could not be achieved if you have non-zero min_runtime. > Moving reset of the start time out of that loop gets everything working > along the lines of (2). Resetting it there did look suspicious to start > with, but since I am just learning my way through ACPI stuff, I have > decided to ask the question instead of filing PR. > > Hope this was better explanation then previous one. > Thanks, I studied things carefully and figured out the behavior. The non-zero min runtime check was subtracting the start time just after it had been set, always giving a very small result. I committed the patch. -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?421A7F6A.6040004>