acpi_throttle: quirk based on pci info

[Andriy Gapon]

on 28/02/2008 20:11 Nate Lawson said the following:
> John Baldwin wrote:
>> Actually, we can make ichss rather simple w/o changing it much by having it 
>> just set a global variable in its PCI probe routine and checking that global 
>> when attaching to the CPU.
> 
> I like your approach.

I like it too. And I also think that if pci-cpu ordering is implemented,
then pci_find_bsf approach that John mentioned should work too. So there
would be no need to attach to pci bus at all - all pci-specific stuff
could be done through the chipset device.

>> One other thing that concerns me is that cpufreq drivers want to know about 
>> each other (e.g. smist checks for ichss0, etc.).  I'd rather that if we have 
>> multiple drivers controlling the same back-end hardware (via difference 
>> interfaces) they all use the same driver name (e.g. speedstep0) and use probe 
>> priority to decide which driver wins if both ichss0 and smist0 can handle a 
>> CPU for example.
> 
> It took me a while to figure out what the generic interface was actually 
> hooking up to in terms of hardware.  For example, some laptops export 
> p4tcc via acpi_throttle.  Others export a SMI/BIOS equivalent that 
> programs the chipset instead of the CPU.  Unfortunately, there doesn't 
> seem to be an easy way to figure out if two drivers are talking to the 
> same hardware so it seems the right choice is to only use the generic 
> interface if the hw-specific one fails to attach.
> 
> I think making acpi_throttle attach at a lower priority than ichss, est, 
> and smist is the best approach.  I wouldn't want to change the names as 
> it would be hard to figure out which hw is actually being driven. 
> Still, there needs to be a way for them to indicate that they attach to 
> the same hw as acpi_throttle.  Your global may be the best approach for now.

And there is another thing: as I understand there could be multiple
"cpufreq-ish" devices attached simultaneously - some providing absolute
values, some providing relative ones, and "the" cpufreq device
aggregates them.
John's suggestion has a lot of appeal. Maybe it could be implemented in
some other form, but that definitely would require detailed analysis.

>> Here is a patch to make CPUs come after PCI and an attempt to fix ICH.  Note 
>> that if we made ichss_identify() manually look for the PCI device by bsf 
>> instead of using a probe routine to find it we could remove the pci "driver" 
>> completely and make it work on kldload.  It also fixes a bug that the attempt 
>> to enable SS via a PCI config register write could never work as it passed a 
>> cpu0 device_t to pci_read_config/pci_write_config in ichss_probe() 
>> previously.  I moved this to attach() (where it belongs) and used the right 
>> device_t so this should work now.  I have no hardware to test it on though.
> 
> ICH SpeedStep is pretty old.  You need Pentium 3 era laptops, i.e IBM T23.

Unfortunately I can not test this particular driver too for the same reason.
I will test the acpi ordering patch and its interaction with
acpi_throttle (with my private quirk for PIIX4E).


-- 
Andriy Gapon