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
| ||
|
Date: Fri, 30 Sep 2022 17:07:03 +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 5:04 PM AngeloGioacchino Del Regno <angelogioacchino.delregno@...labora.com> wrote: > > 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@...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. > > > > 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? Sounds good to me. FWIW, I think it's OK for drivers to reinitialize hardware to a known state that it can work with. As long as it doesn't break the system while doing so. ChenYu > > > 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