Yes. All the things needed are in cpufreq already and I don't think we need to export things like P-state power etc in /sys. I think we should be able to remove all P-state stuff in /proc/acpi without adding anything in cpufreq. Thanks, Venki >-----Original Message----- >From: Thomas Renninger [mailto:trenn@xxxxxxx] >Sent: Tuesday, February 27, 2007 6:46 AM >To: Zhang, Rui >Cc: linux-acpi@xxxxxxxxxxxxxxx; Brown, Len; Pallipadi, Venkatesh >Subject: Re: problem about ACPI processor procfs > >On Tue, 2007-02-27 at 17:33 +0800, Zhang, Rui wrote: >> Hello, list >> >> I met some problems when duplicating ACPI processor procfs >interface in sysfs. >> #cat /proc/acpi/processor/CPU0/limit >> Active limit: P0:T0 >> User limit: P0:T0 >> Thermal limit: P0,T0 >> >> IMO, "Tx" is easy to understand. It indicates the active >T-state, T-state set by user and T-state set by thermal (in >passive mode). >> >> But what does the "Px" stand for? After reading the code in >processor_thermal.c, I don't think user or thermal will change >its value. >> And I don't know if it's still needed when porting to sysfs. > >Px are P-states, this is cpufreq. >Writing to it will probably interfere with /sys/devices/../cpufreq/*. >x should correspond to the amount of entries in >/sys/devices/../cpufreq/scaling_available_frequencies. > >Can't we just get rid of this? Is there any userspace prog >that made use >of this in /proc and if was it really useful in any way? > > Thomas > - To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
