Re: [RESEND 2] cpufreq: dt: disable unsupported OPPs

["Rafael J. Wysocki" <rjw@rjwysocki.net>]

On Thursday, October 23, 2014 05:13:02 PM Lucas Stach wrote:
> Am Donnerstag, den 23.10.2014, 16:43 +0200 schrieb Geert Uytterhoeven:
> > Hi Lucas,
> > 
> > On Thu, Oct 23, 2014 at 4:10 PM, Lucas Stach <l.stach@pengutronix.de> wrote:
> > > Am Donnerstag, den 23.10.2014, 11:19 +0200 schrieb Geert Uytterhoeven:
> > >> On Tue, Oct 21, 2014 at 4:19 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote:
> > >> > On Thursday, October 16, 2014 12:08:20 PM Lucas Stach wrote:
> > >> >> If the regulator connected to the CPU voltage plane doesn't
> > >> >> support an OPP specified voltage with the acceptable tolerance
> > >> >> it's better to just disable the OPP instead of constantly
> > >> >> failing the voltage scaling later on.
> > >> >>
> > >> >> Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
> > >> >> Acked-by: Viresh Kumar <viresh.kumar@linaro.org>
> > >> >
> > >> > Applied, thanks!
> > >>
> > >> This commit
> > >> (http://git.kernel.org/cgit/linux/kernel/git/rafael/linux-pm.git/commit/?h=linux-next&id×bbd4cd0359d781b67c9e621d4bbfd1bb2f3783)
> > >> causes a boot regression on r8a7791/koelsch. It hangs after:
> > >>
> > >>     TCP: cubic registered
> > >>     Initializing XFRM netlink socket
> > >>     NET: Registered protocol family 17
> > >>     NET: Registered protocol family 15
> > >>     ata1: link resume succeeded after 1 retries
> > >>     ata1: SATA link down (SStatus 0 SControl 300)
> > >>     random: nonblocking pool is initialized
> > 
> > >> Reverting this commit fixes the issue, and makes the boot continue with:
> > >>
> > >>     cpufreq: __cpufreq_add_dev: CPU0: Running at unlisted freq: 1300000 KHz
> > >>     cpufreq: __cpufreq_add_dev: CPU0: Unlisted initial frequency
> > >> changed to: 1312500 KHz
> > >>     cpu cpu1: failed to get cpu-2 clock: 1
> > >>     cpufreq_dt: cpufreq_init: Failed to allocate resources: -2
> > >>
> > >
> > > Urgh, thanks for the report. Am I right that for koelsch you do
> > > reference a regulator supply for the cpu, but don't actually have a
> > > driver for it, so a dummy regulator gets plugged in there?
> > 
> > arch/arm/boot/dts/r8a7791-koelsch.dts has:
> > 
> > &cpu0 {
> >         cpu0-supply = <&vdd_dvfs>;
> > };
> > 
> > &i2c6 {
> >         status = "okay";
> >         clock-frequency = <100000>;
> > 
> >         vdd_dvfs: regulator@68 {
> >                 compatible = "dlg,da9210";
> >                 reg = <0x68>;
> > 
> >                 regulator-min-microvolt = <1000000>;
> >                 regulator-max-microvolt = <1000000>;
> >                 regulator-boot-on;
> >                 regulator-always-on;
> >         };
> > };
> > 
> > CONFIG_REGULATOR_DA9210=y
> > 
> > and the driver does seem to run:
> > 
> >     DA9210: 1000 mV at 4600 mA
> > 
> Ah right, I misread your initial report. So the issue doesn't seem to be
> directly related to the cpufreq-dt driver but seems to be located
> somewhere deeper down the chain. The fact that this change triggers the
> bug may be a hint here. The only thing which is new in the change is
> that it tries to get the supported voltage from the regulator. As the
> regulator can not change its voltage (min_uV = max_uV) this translates
> directly to a get_voltage() which in turn only tries to read a register
> of the i2c chip via regmap.
> 
> So it seems that somehow the i2c transaction fails and things spin
> indefinitely there. Maybe this gives a clue on how to debug this
> further.

Well, I've dropped the patch for now.  The underlying issue needs to be fixed
before we can apply it again.


-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.