Re: [Letux-kernel] [RFC PATCH 0/3] Enable 1GHz support on omap36xx

[Adam Ford <aford173@gmail.com>]

On Mon, Sep 9, 2019 at 1:11 PM H. Nikolaus Schaller <hns@goldelico.com> wrote:
>
>
> > Am 09.09.2019 um 18:54 schrieb H. Nikolaus Schaller <hns@goldelico.com>:
> >
> > Hi Tony,
> >
> >> Am 09.09.2019 um 18:32 schrieb Tony Lindgren <tony@atomide.com>:
> >>
> >> Hi,
> >>
> >> * H. Nikolaus Schaller <hns@goldelico.com> [190909 14:57]:
> >>> Another question that came up by private mail from André was if we
> >>> should better disable the turbo OPPs of omap34xx and 36xx by default
> >>> (status = "disabled";) because there are concerns about overheating
> >>> the chips and we have no thermal regulation like for omap4 & 5.
> >>>
> >>> But this would mean that every board DTS would have to set it explicitly
> >>> to "enabled".
> >>
> >> Yes I started thinking about that too. I think there is a requirement
> >> to do the scaling via the voltage processor for the higher modes.
> >
> > It depends on how you read the little footnotes...
> >
> > Table 4-18. Processor Voltages Without SmartReflex:
> >
> >       • This table defines the safe VDD1 (vdd_mpu_iva) voltage ranges to be used before using the SmartReflex AVS feature for OPPs calibration.
> >       • Values are defined when SmartReflexTM feature is deactivated. They can be lower when SmartReflexTM is activated.
> >       • OPP130 and OPP1G are not available above TJ of 90C.
> >       • (6)  OPP1G is a high performance operating point which has following requirements:
> >               • –  ABB LDO must be set to FBB (Forward Body Bias) mode when switching to this OPP. It requires having a 1 F capacitor connected to cap_vdd_bb_mpu_iva.
> >               • –  AVS (Adaptive Voltage Scaling) power technique must be used to achieve optimum operating voltage.
> >
> > So I read this as:
> >
> > * OPP130 and OPP1G should be guarded by 90°C thermal framework
> > * OPP1G should also set the ABB LDO to FBB mode
> > * AVS does only reduce voltage levels (to save energy = heat = problem)
> > * only if we want "optimum operating voltage" (read as: "lowest possible voltage" = "highest energy saving") we must use AVS
> >
> > I.e. we do not necessarily need AVS or SmartReflex or help from the
> > twl4030 (except for changing the voltage).
> >
> >> And there needs to be some way to automatically change to a lower
> >> OPP in some cases.
> >
> > That should probably be done through the thermal framework like
> > on omap4 & omap5?
> >
> >>
> >> For normal OPPs, using the twl regulator directly should be OK.
> >
> > Maybe for the turbo OPPs as well.
> >
> >> For the higher modes, maybe we could pass the callback functions
> >> from arch/arm/mach-omap2/voltage.c for the twl regulator so the
> >> voltage processor hardware can handle them directly. Or add a
> >> separate regulator driver operating the voltages like Nishanth
> >> posted patches for earlier.
> >
> > So in my (limited) understanding it would suffice to set the ABB LDO
> > to FBB mode for OPP1G.
>
> Ok, we have to check if the ti,abb-v2 "LDO" driver
> drivers/regulator/ti-abb-regulator.c
> can handle that with a DT entry similar to:
>
> https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts/omap5.dtsi#L365

At least for the 3630, the ti-abb-regulator driver is the same driver,
but different structures based on v1, v2, or v3 are used based on
which compatible flag is used.

I tried enabling the vbb-supply in the device tree, but the driver
doesn't load it without .multi_regulator being true.

cpus {
/* OMAP3630/OMAP37xx variants OPP50 to OPP130 and OPP1G */
     cpu: cpu@0 {
          operating-points-v2 = <&cpu0_opp_table>;
          vbb-supply = <&abb_mpu_iva>;
          clock-latency = <300000>; /* From omap-cpufreq driver */
     };
};

I enabled that in the 3630 structure, but then the opp must list
voltage points for both regulators.
Looking at the entry for abb_mpu_iva, it appears to have voltages that
directly match the OPP table, so I made a duplicate entry:

 opp-microvolt = <1012500 1012500 1012500>,
                           <1012500 1012500 1012500>;

and similar for 600, 800 and 1000 similar to the way dra7.dtsi does
it, but then I got some nasty errors and crashes.

I started undoing the stuff, and I wanted to see if the abb_mpu_iva
regulator was even running, but I would get -22 errors when I went to
read the voltage.

# cat /sys/devices/platform/68000000.ocp/483072f0.regulator-abb-mpu/regulator/regulator.5/microvolts
-22

If someone has any suggestions on how to test the abb_mpu_iva driver,
let me know.

>
> Needs a little time to add to a new version of the patch set.
>
> > And make sure that the TJ does not exceed 90°C by reducing the cpufreq
> > through the thermal framework. But: the thermal sensors of the omap3
> > are quite odd (they seem to jump up by 10° after first use).

Can we just do a dummy read to get it out of the way?  ;-)

>
> I'll leave this out for the moment for future study.
Works for me, Baby steps.

Thanks for all your work.

adam
>
> BR and thanks,
> Nikolaus
>