Messages in this thread | | | From | Chen-Yu Tsai <> | Date | Wed, 15 Jun 2022 16:25:25 +0800 | 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/
| |