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.
./drivers/clk/sunxi/clk-sun4i-display.c
./drivers/clk/sunxi/clk-sun4i-tcon-ch1.c
)
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