linux-kernel - Re: [PATCH] clk: imx: add CLK_GET_RATE_NOCACHE flag for i.MX8M composite clock

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1545141748.5874.27.camel@pengutronix.de>
Date:   Tue, 18 Dec 2018 15:02:28 +0100
From:   Lucas Stach <l.stach@...gutronix.de>
To:     Anson Huang <anson.huang@....com>
Cc:     Fabio Estevam <festevam@...il.com>,
        "sboyd@...nel.org" <sboyd@...nel.org>,
        "s.hauer@...gutronix.de" <s.hauer@...gutronix.de>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        "linux-clk@...r.kernel.org" <linux-clk@...r.kernel.org>,
        dl-linux-imx <linux-imx@....com>,
        "kernel@...gutronix.de" <kernel@...gutronix.de>,
        Fabio Estevam <fabio.estevam@....com>,
        "shawnguo@...nel.org" <shawnguo@...nel.org>,
        "mturquette@...libre.com" <mturquette@...libre.com>,
        "linux-arm-kernel@...ts.infradead.org" 
        <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH] clk: imx: add CLK_GET_RATE_NOCACHE flag for i.MX8M
 composite clock

Am Dienstag, den 18.12.2018, 13:53 +0000 schrieb Anson Huang:
[...]
> > 
> > > Regarding about the over head, yes, the change in common composite
> > > clock register has too many over head for other clocks, what if I
> > > ONLY have dram core clock to pass the CLK_GET_RATE_NOCACHE flag to
> > > register the composite clock?
> > 
> > IMHO marking clocks under TF-A control explicitly as nocache would be
> > much more acceptable than doing it for every composite clock. This
> > seems okay for a short term solution.
> > 
> > Still I think that whatever is causing the bus frequency scale to
> > change should have a way to explicitly invalidate the clock cache for
> > the affected clocks eventually.
> 
> It is because the DDR PLL/clocks can only be changed with strict DDR
> freq change flow, and it is done in TF-A, Linux kernel can NOT touch
> it in runtime, so we have to mark the child clock of DDR PLL to be
> uncached, in V2 patch, I will just add the flag for the DDR PLL child
> clocks to be a shorten solution, should be only very few ones, hope
> it is acceptable, thanks.

I fully understand why you are doing the frequency change in TF-A and I
agree with the reasoning to do so. I also think that using uncached for
the few clocks under TF-A control is fine for now.

But if/when the bus frequency scaling is actually implemented for
upstream I think the flow should look something like that:

1. Bus freq scaling driver determines that a change is necessary
2. Scaling driver calls into TF-A to do the change
3. TF-A reconfigures clock rates
4. Scaling driver calls into clock driver to signal that a clock change
might have happened
5. Clock driver invalidates and recalculates cached values for the
affected clocks

Regards,
Lucas