Date: Mon, 25 Feb 2008 23:03:56 +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: <47C32D3C.2020205@icyb.net.ua> In-Reply-To: <47C30201.3060501@root.org> References: <47B96989.6070008@icyb.net.ua> <98F7E48C-1CBF-494D-8411-D80E25247214@FreeBSD.org> <47BAF97A.80405@icyb.net.ua> <47BAFB27.1050509@root.org> <47BB2D1F.8000008@icyb.net.ua> <47BEF0C1.5090800@icyb.net.ua> <47BEF211.4030608@icyb.net.ua> <47C30201.3060501@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
on 25/02/2008 19:59 Nate Lawson said the following: > Andriy Gapon wrote: >> on 22/02/2008 17:56 Andriy Gapon said the following: >>> Please find attached a patch that makes sure that acpi_thermal is >>> initialized after PCI bus is available, so that it is possible to decide >>> about hardware quirks based on PCI information. >>> The code uses the same approach as ichss does. >>> The patch is tested to work. >> Oops! I attached on older version of the patch, sorry. >> Correct patch is here. >> (parent of acpi_throttle is cpu, not acpi) >> >>> NOTE: This patch in contaminated! It contains code that forces throttle >>> duty width to be 3 bits for PIIX4E and PIIX4M. This is in accordance >>> with the chipsets specifications. Some motherboard/bios vendors lie >>> about this value in FADT. >>> If not accepted, this quirk can be easily stripped from the patch as its >>> code is contained in distinct hunks. > > Ok, couple comments I think should be addressed before committing: > > * This only adds a child to cpu0. On an SMP machine, we should have a > device instance attached to each cpu. On machines where each CPU has > its own throttling register, this is necessary to program the new rate. > > * Is it necessary to add "device_probe_and_attach(child)"? I guess if > the child is added after the cpu parent's probe/attach run has > completed, that could be a problem. > > * I'm uncomfortable with moving the whole driver probe under pci. I'd > rather the pci probe happen separately and provide information to the > cpufreq probe. But I'm not sure this is feasible. I wonder if John > might have any advice on how to coordinate between PCI and cpufreq? > Nate, these are very good points. It seems that I wrote something very specific to my case and didn't consider other scenarios. I completely forgot about SMP case. I need to think more about this. A possible blanket solution would be to probe/attach all and any cpu child devices after pci bus is attached. But I don't know if this is a viable solution in general and if it's possible to implement at all. -- Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?47C32D3C.2020205>