On 04/23/2013 11:48 AM, Mark Brown wrote:
On Mon, Apr 22, 2013 at 07:49:37PM +0300, Taras Kondratiuk wrote:
Yeah. Sure 4kV is not a real request, but
max will be limited by system constrains.
According to regulator_set_voltage() documentation
system constraints should be set before calling this function,
so I assume I can rely on them. No?
Another possible implementation is below, but prefer initial one.
I just don't see any reason for this API. The driver setting the
voltage ought to have some idea of what the chip limits are too for
safety.
Let's take an example.
One regulator supplies CPU and GPU inside of SoC.
+-------------+
| SoC |
VDD_CPU | +-----+ |
+------------->| CPU | |
+-------+ | | +-----+ |
| Reg X |---+ | |
+------ + | VDD_GPU | +-----+ |
+------------->| GPU | |
| +-----+ |
+-------------+
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.
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?
b) CPU and GPU may have different limits,
so after very first request voltage may violate
CPU or GPU range.
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?
--
BR
Taras Kondratiuk | GlobalLogic
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
