Re: [CRTC:24] vblank wait timed out

[Martyn Welch <martyn.welch@collabora.co.uk>]

On Mon, Mar 27, 2017 at 12:11:12PM +0100, Martyn Welch wrote:
> On Fri, Mar 24, 2017 at 11:42:53AM +0100, Philipp Zabel wrote:
> > On Fri, 2017-03-24 at 10:24 +0000, Martyn Welch wrote:
> > [...]
> > > > Could you move to v4.9 or v4.10 and check if the four patches in
> > > > https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.9-ipu-dp-plane-fix
> > > > or
> > > > https://git.pengutronix.de/cgit/pza/linux/tag/?id=v4.10-ipu-dp-plane-fix-2
> > > > help?
> > > > 
> > > 
> > > I've updated to v4.10, the patches from v4.10-ipu-dp-plane-fix-2 resolve
> > > the error, though we are unfortunately still experiencing the loss of
> > > output on LVDS display. Time to look elsewhere for the cause of that I
> > > guess. :-)
> > 
> > Is the LVDS serial clock derived from the video PLL on that board?
> > (What is the output of /sys/kernel/debug/clk/clk_summary?)
> > 
> 
> I beleive so. I've included a few dumps from clk_summary below.
> 

After looking at the dumps in more detail, I think I know what's
happening:

Problem appears to be a clocking issue. When we have a display connected
to the HDMI port pre-boot, it uses the following chain to drive IPU2
(which is used for this display):

PLL5(756000000) -> PLL5_POST_DIV(756000000/2) ->
    PLL5_VIDEO_DIV(378000000/1) -> LDB_DI1_IPU_DIV(378000000/3.5) ->
    LDB_DI1(108000000) -> IPU2_DI0(108000000)


If the display connected via the LVDS interface is connected either
before or after boot, we end up with IPU1 being drive thus:

PLL2_PFD2(432000000) -> IPU2_DI1_PRE_CLK(432000000) ->
    IPU2DI1_PODF(432000000/4) -> IPU1_DI0(108000000)


On the other hand, if only the LVDS is connected at boot, instead it is
sets up IPU1 as follows:

PLL5(756000000) -> PLL5_POST_DIV(756000000/2) ->
    PLL5_VIDEO_DIV(378000000/1) -> LDB_DI1_IPU_DIV(378000000/3.5) ->
    LDB_DI1(108000000) -> IPU1_DI0(108000000)


Which interestingly matches how IPU2 is configured previously.

When the HDMI interface is then connected it does this to configure IPU2:

PLL5(864000000) -> PLL5_POST_DIV(756000000/4) ->
    PLL5_VIDEO_DIV(216000000/2) -> IPU2DI0_PODF(108000000/1) ->
    IPU2_DI0(108000000)


But as the path "PLL5 -> PLL5_POST_DIV -> PLL5_VIDEO_DIV" is shared with
IPU1 the change in frequency and divider values results in:

PLL5(864000000) -> PLL5_POST_DIV(756000000/4) ->
    PLL5_VIDEO_DIV(216000000/2) -> LDB_DI1_IPU_DIV(108000000/3.5) ->
    LDB_DI1(30857142) -> IPU1_DI0(30857142)


So the LVDS Bridge and IPU1 are now underclocked by 3.5 times.


I suspect that (theoretically) as IPU1_DI0 is already configured at the
required frequency via LDB_DI1, it might have been sufficient for the
IPU2_DI0_SEL MUX to select LDB_DI1 as its source?

Martyn
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel