[PATCH v3 08/10] clk: mediatek: clk-mt8195-topckgen: Drop univplls from mfg mux parents

[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 at 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 at 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 at collabora.com>
>>>>>> Reviewed-by: Chen-Yu Tsai <wenst at 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
>>