Re: [PATCH 3/7] clk: sunxi: unify sun6i AHB1 clock with proper PLL6 pre-divider

[Maxime Ripard <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org>]

[-- Attachment #1: Type: text/plain, Size: 2168 bytes --]

On Thu, Sep 25, 2014 at 04:03:40PM -0700, Mike Turquette wrote:
> Quoting Maxime Ripard (2014-09-13 03:26:03)
> > On Fri, Sep 12, 2014 at 11:16:26AM +0800, Chen-Yu Tsai wrote:
> > > Hi,
> > > 
> > > On Fri, Sep 12, 2014 at 5:02 AM, Maxime Ripard
> > > <maxime.ripard-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> wrote:
> > > > Hi,
> > > >
> > > > On Sat, Sep 06, 2014 at 06:47:24PM +0800, Chen-Yu Tsai wrote:
> > > >> This patch unifies the sun6i AHB1 clock, originally supported
> > > >> with separate mux and divider clks. It also adds support for
> > > >> the pre-divider on the PLL6 input, thus allowing the clock to
> > > >> be muxed to PLL6 with proper clock rate calculation.
> > > >>
> > > >> Signed-off-by: Chen-Yu Tsai <wens-jdAy2FN1RRM@public.gmane.org>
> > > >
> > > > It looks fine, but I'd rather see this in a separate file, especially
> > > > since we don't seem to have any order dependency.
> > > 
> > > Sorry, just to be clear, separate file under clk/sunxi?
> > 
> > Yes
> > 
> > > This cannot be in a separate file, as it shares a spinlock with apb1
> > > divider. They share the same register.
> > > 
> > > We could move apb1 out though. But i would prefer to do that when
> > > we split out all the clocks into individual OF_CLK_DECLAREs.
> > 
> > Ah right, my bad :)
> > 
> > My plan on the long term is to kill clk-sunxi as a place where all the
> > clocks are defined, and only leave the "policy" there, for example the
> > clock protection code (even if that should probably be removed too,
> > together with clkdev), the various rates / parenting enforcements,
> > etc.
> 
> Interesting! Where are you planning to store the clock data?

Which data? 

I guess, for the rate boundaries, the DT would be the right place,
wether a clock should be protected can be derived from its
compatible. And for the rate to enforce, maybe a clock-frequency
property in the DT too, or directly in the driver, I haven't really
thought about that part at the moment to be honest :)

Maxime

-- 
Maxime Ripard, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]