Thermal state switching

Nate Lawson nate at root.org
Mon Feb 21 16:41:22 PST 2005


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


More information about the freebsd-acpi mailing list