On Tue, Jun 10, 2014 at 04:13:06PM +0100, Russell King - ARM Linux wrote:
> where 'M' is the IPU DI clock muxer. However, we're currently setting
> this up as:
>
> LM --+---------------- LDB serial
> `- /7 -+-------- LDB DI clock
> IPM --- /N ---- IM --- IPU DI clock
>
> and hoping that the LDB and IPU DI clocks are appropriately synchronised.
I've just found that we do indeed do this - but there's nothing to
switch the configuration back when the LDB is no longer using a
particular DI.
Also, I'm having a hard time working out why we have the LDB being
given all sorts of clocks...
LM --+----------------- LDB serial (clks 33, aka di0_pll)
`- /7 -+--------- LDB DI clock (clks 135, aka di0)
`- IM --- IPU DI clock (clks 39, aka di0_sel)
The LDB is given all of these to play with, including reprogramming
the IM, and there's nothing which ever programs IM to anything but
the LDB DI clock once it's set there.
Not only does this feel horribly unclean from the DT perspective, but
it's also a horrid violation of reasonable layering. What if we wanted
to fix this by adding control of di0_sel to the HDMI interface too?
We then need to list yet again the IPU DI clock and the desired input
clock there, and make the imx-hdmi code aware of that.
Wouldn't it be better to have the ipuv3-crtc, or even the IPU DI code
be in control of its external clock mux, and request the IPU DI code
to select a particular input clock? In other words, have one central
place where the IPU DI clock is controlled, rather than ending up with
it spread through lots of different sub-drivers?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
