On 04/23/2013 04:45 PM, Mark Brown wrote:
On Tue, Apr 23, 2013 at 02:44:58PM +0300, Taras Kondratiuk wrote:
GPU voltage is regulated by some devfreq driver.
CPU voltage is regulated by generic cpufreq-cpu0 driver.
Both drivers know only about their operational points.
They don't know anything about chip limits.
Clearly at least the lower bound is known to the drivers...
Do you mean a voltage of the lowest operation point?
I see two options here:
1. Pass somehow chip limits to drivers so they can limit their request.
Pros: No need for regulator_set_voltage_min()
Cons: a) Need to pass info about chip limits to driver. New API?
Why on earth would this need a new API?
I think I'm missing something.
How can I pass chip limits to a driver in some generic way?
b) CPU and GPU may have different limits,
so after very first request voltage may violate
CPU or GPU range.
If the CPU and GPU drivers are trying to select incompatible
configurations then we really ought to be detecting that, ignoring it
seems like an obvious failure. There's a bootstrapping problem but
that's also an issue with specifying only the minimum voltage...
2. Define chip limits in Reg X constraints.
Pros: Limits will be applied to driver's request transparently.
No need to pass info about limits to driver.
Limits are set before the first request, so no violation.
Cons: regulator_set_voltage_min() is needed.
IMHO option #2 is better.
Do you see other ways?
Above you clearly say that this is all modelling operating points. If
you're doing that then I would expect the drivers to be talking
operating points to an operating point abstraction.
I went through several SoC datasheets and found that min approach
won't work for some of them (like AM335x).
The only safe way is to send max OPP voltage as a max_uV.
So please skip this series.
--
BR
Taras Kondratiuk | GlobalLogic
--
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
