lkml.org 
[lkml]   [2019]   [Dec]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v3 03/15] soc: tegra: Add Tegra PMC clock registrations into PMC driver
On Mon, Dec 16, 2019 at 05:23:23PM +0300, Dmitry Osipenko wrote:
> >> Could you please clarify what do you mean by the "existing users"?
> >> AFAIK, nothing in kernel uses mux clocks.
> >
> > The DT clk bindings allow for parent initialization, so it's certainly
> > possible there are some DTs which rely on this. We promised to never
> > break the bindings, which changing to 1 clock would do.
>
> What about this variant:
>
> 1. Keep the old CaR code in place.
>
> 2. Make CaR driver to scan whole device-tree for the legacy PMC clocks.
>
> 3. If legacy clock is found, then register PMC clocks from CaR.
>
> 4. If legacy clocks are not found, then don't register PMC clocks from
> CaR.
>
> 5. Add clocks support to the PMC driver and only register them if
> legacy clocks are not registered by CaR.
>
> Now both old and new DTBs can co-exist and work, everyone happy.

That seems even more work.. Today the only upstream user is audio.
Currently these clocks are setup by the CAR clock driver. However
as they will move to the PMC driver, this mechanism cannot be used.
Hence the plan is to modify the audio driver to check for the PMC clocks
in DT and if they are not available use the CAR clocks as fallback.
The whole reason the clocks move to the PMC driver, is that when PMC
becomes secure, all accesses have to go via an SMC. Given that we don't
want SMCs all over the Tegra drivers, it's a good opportunity to move
the PMC clock handling into the PMC driver. PMC can be secure with both
'new' and old DTs, so just registering the PMC clocks in the CAR driver
if legacy clocks are found in the DT, won't always work.

Peter.

\
 
 \ /
  Last update: 2019-12-16 16:12    [W:0.333 / U:1.504 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site