Date: Thu, 28 Feb 2008 21:17:18 +0200 From: Andriy Gapon <avg@icyb.net.ua> To: Nate Lawson <nate@root.org> Cc: freebsd-acpi@freebsd.org Subject: Re: acpi_throttle: quirk based on pci info Message-ID: <47C708BE.3020108@icyb.net.ua> In-Reply-To: <47C6F939.4060301@root.org> References: <47B96989.6070008@icyb.net.ua> <200802271126.30132.jhb@freebsd.org> <47C5E0A6.5030102@icyb.net.ua> <200802280856.31548.jhb@freebsd.org> <47C6F939.4060301@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C708BE.3020108>