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 <bou...@antioche.eu.org>
NetBSD: 26 ans d'experience feront toujours la difference
--
