On Thursday 03 September 2009 23:42:31 Dominik Brodowski wrote:
> Hey,
>
> On Thu, Sep 03, 2009 at 01:23:28PM +0200, Thomas Renninger wrote:
> > I now realized that this patch somewhat clashes with
> > cpufrequtils cpufreq-info --hwlimits command.
> > IMO "cpufreq-info --hwlimits" is wrong here as it evaluates
> > max_freq sysfs value which could also get limited by the user.
>
> huh?
>
> brodo@comet:~$ cpufreq-info --hwlimits
> 800000 2001000
> brodo@comet:~$ sudo cpufreq-set --max 1.2G
> brodo@comet:~$ cpufreq-info --hwlimits
> 800000 2001000
Ah, I didn't look into cpufreqinfo details where hwlimits
is coming from.
But how would one then differ between:
- The max freq the CPU is really capable of
- Whether it's a BIOS limitation
I like to have the _PPC limitation exposed to userspace
in a way one can be sure it is a _PPC limitation.
cpuinfo.bios_limit?
Another, more intrusive idea (I mainly care about _PPC
distinction):
Best also thermal or whatever other limits there could happen.
Most generic approach which comes to my mind is something like:
- Introduce
cpufreq_verify_within_limits(policy, min, max)
wrapper:
cpufreq_set_limit(char *limit_name, policy, min, max)
Thermal or PPC(processor) driver could then use:
cpufreq_set_limit("bios", policy, min, max)
cpufreq_set_limit("thermal", policy, min, max)
cpufreq core's cpufreq_set_limit function will remember the limit
and where it comes from and calls cpufreq_verify_within_limits internally.
thermal, processor and possible other drivers would need to
register a cpufreq limit, a sysfs file could then dynamically be created
and the limit exposed, e.g. like:
cpu0/cpufreq/limits/thermal
cpu0/cpufreq/limits/bios (or ppc now?)
cpu0/cpufreq/limits/...
Any idea of an easier way to achieve this (provide a unique and easy
way to show freq limitations and what's the root cause
of it)?
Thomas
> --hwlimits evaluates cpuinfo_{cur,min,max}_freq which are the hardware
> limits. Those may be limited further by the BIOS on runtime (firmware
> limits, so to speak). It seems to me that this is what you want to add with
> this patch?
>
> Best,
> Dominik
>
--
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
