On 21.03.2016 16:53, Sebastian Reichel wrote:
Hi Mark,
On Mon, Mar 21, 2016 at 01:45:15PM +0000, Mark Brown wrote:
On Mon, Mar 21, 2016 at 03:39:15PM +0200, Ivaylo Dimitrov wrote:
On 21.03.2016 13:45, Mark Brown wrote:
No, if the voltage is variable we can't tell what the current
constraints are without something telling us so we just don't vary the
voltage until we're told to do this. If we immediately lower the
voltage to the minimum supported voltage that's going to break things.
There are constraints set by the board DTS. Isn't it reasonable the
framework to set the voltage to minimum voltage from the dts if the current
set one is bellow it?
Yes, if it's out of bounds for the constraints we should bring it
up/down to the minimum/maximum (when copying people into a thread it's a
good idea to explain what the problem you are trying to solve is,
especially if you're throwing around bodges).
We have this regulator definition in omap3-n900.dts:
&vmmc2 {
regulator-name = "V28_A";
regulator-min-microvolt = <2800000>;
regulator-max-microvolt = <3000000>;
regulator-always-on; /* due VIO leak to AIC34 VDDs */
};
The regulator is enabled during probe, but the voltage is not
configured. The default reset voltage of the regulator is 2.6V.
So basically when the regulator is enabled, it uses a voltage,
which is out of the DT specified range.
We also have a second problem: If the system has been rebooted from
Nokia's stock kernel the regulator is left in STANDBY mode. Since
the mode is not configured during probe, it results in different
problems. According to my understanding it can be fixed trivially
by adding
&vmmc2 {
regulator-initial-mode = <2>;
};
doesn't work:
"regulator-vmmc2: mapping for mode 2 not defined"
twl-regulator is missing .of_map_mode function.
Also, if we go that route, we should set the initial modes for all the
regulators, not only vmmc2 (and not only for N900), as we don't really
know what is the status of regulators at startup. I think a better
approach is if regulator framework sets all always-on regulators to
enabled, unless stated otherwise (which it already does iiuc).
I think there is a bug in twl-regulator twl4030reg_enable() and/or
twl4030reg_is_enabled() - the latter only checks if DEV_GRP is P1, but
not for the actual state of the regulator (bits 3:0). Also, what looks
suspicious to me is that all the regulators are put in P1 device group.
Legacy board code spreads the regulators all over the groups, so maybe
this is simply a regression compared to legacy boot.
Regards,
Ivo
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
