On Monday 09 March 2009 12:16:04 Thomas Renninger wrote: > Hi, > > On Friday 06 March 2009 21:22:45 Jarod Wilson wrote: > > Some atom procs don't do freq scaling (such as the atom 330 on my own > > littlefalls2 board). By adding the atom family here, we at least get > > the benefit of passive cooling in a thermal emergency. > > Not sure how to see that its actually helping any, > > but the driver does bind and > > claim its functioning on my atom 330. > I do not think this is a good idea. > > There was a patch posted for a eeepc specific cpufreq enhancement > making use of some "not official" ACPI methods. > > Re: [PATCH 1/1] cpufreq: eeepc 900 frequency scaling driver > > There existed two version, one of Tom Hughes integrating the cpufreq > parts into the already existing eeepc driver and one of Cristiano > Prisciandaro providing a separate eeepc cpufreq driver. > > Now we have three unsynchronized instances doing clock modulation: > - as specified by ACPI spec > - through unspecified ACPI functions (e.g. on eeepc, fortunately > only on a specific set of machines) > - natively via p4_clockmod > > The eeepc driver has not been pushed yet, as far as I can tell, but > Matthew and Pavel already went through the code and did not object. > > I wonder what happens if you load the p4_clockmod and eeepc driver > both doing more or less the same. So far as I know, all the netbook atom procs are to date, of the n2?0 variant, which are handled by acpi-cpufreq just fine. At least here in Fedora land, if acpi-cpufreq is bound, we don't try p4-clockmod, so this is only relevant for the desktop-targeted atoms at the moment, and they're definitely found in !eeepc machines, so if anything, this sounds like a better approach that relying on the eeepc-specific drivers for throttling on non-acpi-cpufreq atom procs. Aren't these eeepc-specific drivers for the non-atom eeepc's anyway? -- Jarod Wilson jarod@xxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe cpufreq" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
