acpi_cpu: _PDC vs _OSC

[Andriy Gapon]

on 03/02/2010 17:21 Rui Paulo said the following:
> On 3 Feb 2010, at 14:53, Andriy Gapon wrote:
> 
>> What do you think about changing logic of evaluating _PDC and _OSC for Processor
>> object in acpi_cpu_attach?
>> It seems that later versions of ACPI standard deprecate _PDC in favor of _OSC.
>> Although, in practice they seem to be present or not present together, sometimes
>> _PDC being only a wrappper around _OSC.  There are still, of course, systems with
>> only _PDC present.  I assume that there are systems with only _OSC too.
>>
>> I would like to change the order, so that _OSC evaluation is attempted first and
>> only if it fails then proceed with _PDC.
>>
>> Also, I would like to print status returned by _OSC (in case of successful
>> evaluation) if it is not zero. (Note: this is not the same as status of evaluating
>> _OSC).
>>
>> And I am going to fix the following comment:
>> * On some systems we need to evaluate _OSC so that the ASL
>> * loads the _PSS and/or _PDC methods at runtime.
>>
>> Although on many systems either _PDC or _OSC or both dynamically load SSDTs that
>> contain additional Processor objects like _PSS and _PCT, I haven't seen any system
>> where _OSC would load _PDC.  And, honestly, that wouldn't make any sense.
>> Perhaps, comment's author meant _PCT in place of _PDC, or something like that.
> 
> I added the comment and I have such system. It's a MacBook first generation.
> 
> By evaluating _OSC we were able to make _PDC visible, thus enabling cpufreq(4).

You know what is strange - in current code _PDC is evaluated before _OSC.
1. So even if _OSC makes it visible, how would that affect anything?  There is no
code that would evaluate _PDC that comes into existence after _OSC evaluation.

2. That's beside the theoretical question of why _OSC which deprecates _PDC would
bring in the latter.

3. Also, are you sure that it was _PDC that did that? I.e. not _PSS, not _PCT, not
_ETC :-)

-- 
Andriy Gapon