linux-kernel - Dealing with temporary clock parents for PLL consumers?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAGXv+5G9j_XVhuH2XO8g0YQn=NT3Typ0OYkKtr7qHkZM9XKpwQ@mail.gmail.com>
Date:   Wed, 15 Jun 2022 16:25:25 +0800
From:   Chen-Yu Tsai <wenst@...omium.org>
To:     Stephen Boyd <sboyd@...nel.org>,
        Michael Turquette <mturquette@...libre.com>,
        matthias.bgg@...nel.org
Cc:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>,
        linux-clk <linux-clk@...r.kernel.org>,
        LAKML <linux-arm-kernel@...ts.infradead.org>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Dealing with temporary clock parents for PLL consumers?

Hi everyone,

As part of getting Panfrost to support devfreq on MediaTek SoCs, we've
been trying to internalize PLL consumer reparenting during PLL
reconfiguration into the clock drivers. This was previously done by
the individual clock consumer hardware drivers, Panfrost in this case.

I posted some patches for temporarily reparenting PLL consumers while the
PLL is reconfigured on MediaTek platforms [1]. This is based on a similar
mechanism in the Allwinner sunxi-ng clock driver. This works OK for the
MT8183, but as Angelo recently discovered, there are complications for
MT8192 and MT8195 due to how the clock tree is.

On MT8183, the clock tree for the GPU looks like this:

  <XTAL>     ----------------\
  <GPU PLL>  ------- <gate>--\\ <mux> --> GPU
  <stable PLL 1>  -- <gate>--//
  <stable PLL 2>  -- <gate>--/

Since we temporarily reparent the GPU to the XTAL, everything is OK.

On MT8192 / MT8195, the clock tree is more complicated with a fast mux:
(same parent with different dividers omitted)

  <GPU PLL>  <gate> ----------------------------\
                                                 \
  <XTAL>     ---------------\                     <fast mux> --> GPU
  <stable PLL 1> -- <gate> --- <mux> -- <gate> --/
  <stable PLL 2> -- <gate> -/

As shown, we now have a gate in the temporary clock parent (the other side
of the fast mux) that needs to be ungated. The question is how do we deal
with this, since the temporary muxing away from the GPU PLL is done without
updating the clk core's view of the clock tree.

Angelo and I discussed various solutions:

a) We could mark it as a critical clock so that it's always ungated,
   but that seems a bit heavy handed.

b) (by me) Add clk_prepare_enable() / clk_disable_unprepare() calls in
   the clk notifier that handles the temporary muxing. This might trip
   up the clk core in unexpected ways.

c) (by Angelo) Tie the temporary clock parent to the GPU's power domain.
   This means the clock is only enabled when the GPU is in use. I think
   this is a bit hackish though.

d) Add support for such a mechanism to the clock core. I assume this is
   a common requirement across platforms, as PLLs tend to overshoot when
   being reconfigured on the fly, and can cause glitches in their consumers.

We'd like to get opinions from folks about:

1. Whether (b) is acceptable from the clk subsystem's perspective.
2. Whether (c) is acceptable in the platform maintainer's view.
3. Whether there is interest in (d), assuming it is doable.

Thanks
ChenYu

[1] https://lore.kernel.org/linux-mediatek/20220523085923.1430470-1-wenst@chromium.org/