Message-ID: <CAGXv+5F-P0D5G2ydxUbwDPaW-GgDSYOUGv5+3yx8JbHL_px=EA@mail.gmail.com>
Date:   Fri, 30 Sep 2022 17:02:10 +0800
From:   Chen-Yu Tsai <wenst@...omium.org>
To:     AngeloGioacchino Del Regno 
        <angelogioacchino.delregno@...labora.com>
Cc:     MandyJH Liu (劉人僖) 
        <MandyJH.Liu@...iatek.com>,
        "matthias.bgg@...il.com" <matthias.bgg@...il.com>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "robh+dt@...nel.org" <robh+dt@...nel.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "jose.exposito89@...il.com" <jose.exposito89@...il.com>,
        "drinkcat@...omium.org" <drinkcat@...omium.org>,
        "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        Chun-Jie Chen (陳浚桀) 
        <Chun-Jie.Chen@...iatek.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>,
        Miles Chen (陳民樺) 
        <Miles.Chen@...iatek.com>,
        Weiyi Lu (呂威儀) <Weiyi.Lu@...iatek.com>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        Rex-BC Chen (陳柏辰) 
        <Rex-BC.Chen@...iatek.com>,
        "krzysztof.kozlowski+dt@...aro.org" 
        <krzysztof.kozlowski+dt@...aro.org>,
        "nfraprado@...labora.com" <nfraprado@...labora.com>
Subject: Re: [PATCH v3 08/10] clk: mediatek: clk-mt8195-topckgen: Drop
 univplls from mfg mux parents

On Fri, Sep 30, 2022 at 4:58 PM AngeloGioacchino Del Regno
<angelogioacchino.delregno@...labora.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@...labora.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@...labora.com>
> >>>> Reviewed-by: Chen-Yu Tsai <wenst@...omium.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.

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
>

Powered by blists - more mailing lists