Re: [PATCH v2 4/4] pwm: meson: make full use of common clock framework

[Martin Blumenstingl <martin.blumenstingl@googlemail.com>]

Hello Thierry and Heiner,

On Thu, Apr 13, 2023 at 11:13 AM Thierry Reding
<thierry.reding@gmail.com> wrote:
>
> On Tue, Apr 11, 2023 at 09:48:46PM +0200, Martin Blumenstingl wrote:
> > On Tue, Apr 11, 2023 at 9:26 PM Heiner Kallweit <hkallweit1@gmail.com> wrote:
> > [...]
> > > +               init.name = name;
> > > +               init.ops = &clk_gate_ops;
> > > +               init.flags = CLK_SET_RATE_PARENT;
> > As much as I don't want it: I think we need CLK_IGNORE_UNUSED here as well :-(
> > On GXBB, GXL and GXM SoCs the board design typically uses PWM
> > regulators (like the boards using 32-bit SoCs as well as newer boards
> > using G12A or later SoCs).
> > This means: if we enable that PWM controller and one of the channels
> > is firmware managed and the other isn't then we can end up disabling
> > the clock - taking away VCCK (which supplies the CPU) or VDDEE (which
> > supplies GPU and various other components).
> > I'd be happy if there are other suggestions around this though.
>
> What exactly does "firmware managed" mean? Typically we describe all
> supplies in DT to avoid these kinds of workarounds. If VCCK and/or VDDEE
> are PWM-controlled regulators that should never be turned off, can they
> not simply be added to device tree and marked as "always-on"? That would
> propagate to the PWM and make sure the corresponding clock remains
> enabled.
Most Amlogic boards use PWM-controlled regulators. There's three SoC
generations I know of that are "special" when it comes to managing
these regulators (and CPU clocks) though.
Let's start with the simple ones: Meson8/8b/8m2, G12A, G12B, SM1 (and
I assume newer generations as well): here the PWM regulators are
managed by Linux.
Then there's the special cases: GXBB, GXL and GXM which run a SCPI
firmware for managing the CPU clocks, regulators and suspend.

SCPI firmware is running in the "secure world", while Linux is running
in the "normal world".
I don't know if there's boards with secure boot that lock Linux out
from the PWM and CPU clock registers.
This means: so far we've left any PWM controller settings that relate
to the regulators up to the SCPI firmware, not messing with any of the
registers from Linux.

My concern is for example with the Khadas VIM2, see it's schematics [0] page 4:
- PWM_C is used to manage the VDDEE regulator (I suspect that there's
a typo though and it should be called VDDEE_PWM_C, but the schematics
state that the signal is called "VDDEE_PWM_D")
- PWM_D can routed to the GPIO headers
Now if a user enables &pwm_cd (the PWM controller responsible for
channel PWM_C and PWM_D) to use PWM_D on the pin header we don't want
to turn off PWM_C by accident.
Turning PWM_C off by accident can happen if we register the clock gate
and don't have a consumer for it. CCF (common clock framework) can
then just turn off that clock because it's unused. This would lock up
the board because VDDEE is used for critical functionality on the SoC.

Two extra questions from Heiner:
> I check regarding Thierry's comment and found the vddcpu
> pwm-regulators described in the DT's. Is your concern that
> not for all boards the vddcpu pwm-regulator is described in
> the DT?
Correct, boards that have the pwm-regulators described in their .dts
(typically the boards using a Meson8/8b/8m2, G12A, G12B or SM1 SoC)
are not a problem.
Only the ones that don't describe the pwm-regulators in their .dts are
an issue as these are managed by the SCPI firmware.

> AFAICS pwm channels are independent. How can switching
> off the clock for one channel affect the other channel?
It's not about one channel affecting the other. My thought is that
CCF's "disabled unused clocks" feature will turn off the clock if it's
not used. Since SCPI firmware uses it, Linux doesn't know that CCF may
disable the clock unless CLK_IGNORE_UNUSED is set.

I hope this makes sense. If you have any additional questions then
feel free to ask.


Best regards,
Martin


[0] https://dl.khadas.com/products/vim2/schematic/vim2_sch_v12.pdf