Messages in this thread | | | From | Thomas Renninger <> | Subject | Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver | Date | Mon, 24 Nov 2008 17:36:52 +0100 |
| |
On Monday 24 November 2008 04:13:24 pm Thomas Renninger wrote: > On Monday 24 November 2008 10:38:58 am Tom Hughes wrote: > > Cristiano Prisciandaro wrote: > > > From: Cristiano Prisciandaro <cristiano.p@solnet.ch> > > > > > > The bios of the eeepc 900 exposes an acpi method that allows clocking > > > the cpu to 630/900 MHz. This driver allows controlling the frequency > > > switch through the cpufreq subsystem. > > > > I should perhaps add at this point that I have an alternative patch > > based on Cristiano's code, which adds this cpufreq driver to the > > existing eeepc-laptop module rather than creating a separate module for > > it. > > > > Personally I'm quite happy with either solution so I'll leave it to you > > to decide what is the best way to go, but my patch is available if you > > want it. > > Either way, shouldn't you be able to provide a dmi matching module alias: > MODULE_ALIAS("dmi:...") > for autoloading? > > Or are these two cpufreq functions part of an ACPI device you could match > for, then it should get an ACPI driver? Oh, they are part of this general Asus \\_SB.ATKD device, which is only used by asus_laptop.c until now? I don't know \\_SB.ATKD in detail, but it has not a HID to match against and contains ASUS specific ACPI helper functions?
Looks like a growing mess in the ASUS ACPI area...
Some more questions: Why are they providing their own cpufreq interface and not following the spec (providing _PSS, ..)? Could it be that you are only throttling the CPU?
Are these functions already used by the ACPI tables internally? - could be dangerous - could be helpful -> Is there some upper level device/interface in ASL?
Could it happen that upcoming machines provide this interface (the two ACPI functions) and also can do real CPU frequency/volt switching, e.g. via acpi-cpufreq?
Thomas
> If this ACPI device provides more functions, then these should probably > also be added to this driver. > Splitting the OS drivers the same way as BIOS splits up functionality into > ACPI devices is a good idea. > > Could you paste at least the whole ACPI device in which: > #define ASUS_CPUFV_READ_METHOD "CFVG" > #define ASUS_CPUFV_WRITE_METHOD "CFVS" > sit or better point to an acpidump/dsdt output. > > Thomas
| |