Messages in this thread | | | Date | Fri, 30 Sep 2022 11:04:04 +0200 | Subject | Re: [PATCH v3 08/10] clk: mediatek: clk-mt8195-topckgen: Drop univplls from mfg mux parents | From | AngeloGioacchino Del Regno <> |
| |
Il 30/09/22 11:02, Chen-Yu Tsai ha scritto: > On Fri, Sep 30, 2022 at 4:58 PM AngeloGioacchino Del Regno > <angelogioacchino.delregno@collabora.com> wrote: >> >> Il 30/09/22 10:44, Chen-Yu Tsai ha scritto: >>> On Fri, Sep 30, 2022 at 4:29 PM AngeloGioacchino Del Regno >>> <angelogioacchino.delregno@collabora.com> wrote: >>>> >>>> Il 30/09/22 07:59, MandyJH Liu (劉人僖) ha scritto: >>>>> On Tue, 2022-09-27 at 12:11 +0200, AngeloGioacchino Del Regno wrote: >>>>>> These PLLs are conflicting with GPU rates that can be generated by >>>>>> the GPU-dedicated MFGPLL and would require a special clock handler >>>>>> to be used, for very little and ignorable power consumption benefits. >>>>>> Also, we're in any case unable to set the rate of these PLLs to >>>>>> something else that is sensible for this task, so simply drop them: >>>>>> this will make the GPU to be clocked exclusively from MFGPLL for >>>>>> "fast" rates, while still achieving the right "safe" rate during >>>>>> PLL frequency locking. >>>>>> >>>>>> Signed-off-by: AngeloGioacchino Del Regno < >>>>>> angelogioacchino.delregno@collabora.com> >>>>>> Reviewed-by: Chen-Yu Tsai <wenst@chromium.org> >>>>>> --- >>>>>> drivers/clk/mediatek/clk-mt8195-topckgen.c | 9 ++++++--- >>>>>> 1 file changed, 6 insertions(+), 3 deletions(-) >>>>>> >>>>>> diff --git a/drivers/clk/mediatek/clk-mt8195-topckgen.c >>>>>> b/drivers/clk/mediatek/clk-mt8195-topckgen.c >>>>>> index 4dde23bece66..8cbab5ca2e58 100644 >>>>>> --- a/drivers/clk/mediatek/clk-mt8195-topckgen.c >>>>>> +++ b/drivers/clk/mediatek/clk-mt8195-topckgen.c >>>>>> @@ -298,11 +298,14 @@ static const char * const ipu_if_parents[] = { >>>>>> "mmpll_d4" >>>>>> }; >>>>>> >>>>>> +/* >>>>>> + * MFG can be also parented to "univpll_d6" and "univpll_d7": >>>>>> + * these have been removed from the parents list to let us >>>>>> + * achieve GPU DVFS without any special clock handlers. >>>>>> + */ >>>>>> static const char * const mfg_parents[] = { >>>>>> "clk26m", >>>>>> - "mainpll_d5_d2", >>>>>> - "univpll_d6", >>>>>> - "univpll_d7" >>>>>> + "mainpll_d5_d2" >>>>>> }; >>>>>> >>>>>> static const char * const camtg_parents[] = { >>>>> There might be a problem here. Since the univpll_d6 and univpll_d7 are >>>>> available parents in hardware design and they can be selected other >>>>> than kernel stage, like bootloader, the clk tree listed in clk_summary >>>>> cannot show the real parent-child relationship in such case. >>>> >>>> I agree about that, but the clock framework will change the parent to >>>> the "best parent" in that case... this was done to avoid writing complicated >>>> custom clock ops just for that one. >>>> >>>> This issue is present only on MT8195, so it can be safely solved this way, >>>> at least for now. >>>> >>>> Should this become a thing on another couple SoCs, it'll then make sense >>>> to write custom clock ops just for the MFG. >>> >>> Would CLK_SET_RATE_NO_REPARENT on the fast mux coupled with forcing >>> the clk tree to a state that we like (mfgpll->fast_mux->gate) work? >> >> I'm not sure that it would, and then this would mean that we'd have to add >> assigned-clock-parents to the devicetree and the day we will introduce the >> "complicated custom clock ops" for that, we'll most probably have to change >> the devicetree as well... which is something that I'm a bit reluctant to do >> as a kernel upgrade doesn't automatically mean that you upgrade the DT with >> it to get the "new full functionality". > > You can also do it by doing clk_set_parent() in the clock driver after the > clocks are registered, or just write to the register before the clock is > registered. >
I honestly don't like doing that - but I can try if that works and, if it does, I can send a commit with a Fixes tag later, perhaps?
> We do the latter in some of the sunxi-ng drivers, though IIRC it was to > force a certain divider on what we expose as a fixed divider clock. > > ChenYu > >> Introducing the new clock ops for the mfg mux is something that will happen >> for sure, but if we don't get new SoCs with a similar "issue", I don't feel >> confident to write them, as I fear these won't be as flexible as needed and >> will eventually need a rewrite; that's why I want to wait to get the same >> situation on "something new". >> >> In my opinion, it is safe to keep this change as it is, even though I do >> understand the shown concerns about the eventual unability to show the tree >> relationship in case the bootloader chooses to initialize the mfg mux with >> a univpll parent. >> >> Regards, >> Angelo >>
| |