Port-arm archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: clk_set_parent() by name ?

On Mon, Mar 19, 2018 at 09:17:08PM -0300, Jared McNeill wrote:
> On Mon, 19 Mar 2018, Manuel Bouyer wrote:
> > On Mon, Mar 19, 2018 at 05:20:45PM -0300, Jared McNeill wrote:
> > > I see what you mean now. The issue I have with clk_set_parent_byname is that
> > > it pushes internals of the clk provider into device drivers. The names are
> > > arbitrary and not consistent across ccu drivers, only really meant for
> > > printing/debugging etc.
> > 
> > Yes I understant that.
> > On the other hand, the clock hierarchy knowledge in the display's driver
> > is also quise soc-specific.
> There are 5 different families of SoCs that share this DE implementation
> (sun4i, sun5i, sun6i, sun7i, sun9i). I don't really want to have SoC
> specific clock code in there..

but pushing driver-specific clock setup in the ccu also looks wrong
to me, and could appear as black magic.

> > > If you're using static clock parents, you can just initialize them in your
> > > ccu driver's attach function.
> > > 
> > > If you need to dynamically adjust clock parents, do you have enough context
> > > in the ccu driver on a clk_set_rate call to auto-select the correct parent?
> > 
> > unfortunably no, not in all case.
> > In allwinner/, the debe clocks are hardcoded to use pll5 as parent,
> > we could probably do the same in sunxi.
> Yeah I think that's reasonable.
> > the video0/video1 clocks depends on the video mode, they will have to be setup
> > either in the hdmi when we're using hdmi (this is where we know the video
> > mode), or directly in the tcon when using the LCD outputs.
> > But when using tcon without hdmi we have to reference to the video0/video1
> > clocks in the device tree.
> In Linux the TCON uses the two declared clocks (tcon-ch0 and tcon-ch1), and
> the clk framework automatically reparents. I think we can do the same
> without breaking abstractions here.

It seems they have display-specific clock drivers (e.g.
So we'll probably have to do the same, instead of using the
PLL generic drivers.
This will also probably need an update of the clock interface (like
reference counts for enable/disable, "exclusive" clocks, maybe others).

I'll try to find more in details what's needed.

Manuel Bouyer <bouyer%antioche.eu.org@localhost>
     NetBSD: 26 ans d'experience feront toujours la difference

Home | Main Index | Thread Index | Old Index