[PATCH] imx-drm: imx-hdmi: fix hdmi hotplug detection initial state

[Russell King - ARM Linux]

On Tue, Jun 10, 2014 at 10:32:25AM -0300, Fabio Estevam wrote:
> On Tue, Jun 10, 2014 at 9:58 AM, Fabio Estevam <festevam at gmail.com> wrote:
> > On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux
> > <linux at arm.linux.org.uk> wrote:
> >
> >> Right, so the problem isn't at the HDMI level, but at the DI level... so
> >> that's where we need to debug what's being setup.  I left some debugging
> >> in ipu-di.c - could you try enabling that please?
> >
> > Booting the kernel with the HDMI cable connected (no image is seen on
> > HDMI, only on LVDS):
> 
> In case it helps, I am also able to reproduce the problem on a
> imx6dl-hummingboard using the attached debug patch.

Thanks, that's most useful for my testing.  I have a version of the HB
here which has an LVDS connector on... but I have no LVDS panel to
connect to it.

Anyway, this is the pertinent information which confirms what's going
on... from /sys/kernel/debug/clk/clk_summary - reformatting a little:

    pll5_video                        1    1      909999984  0
       pll5_post_div                  1    1      454999992  0
          pll5_video_div              2    2      454999992  0
...
             ipu1_di0_pre_sel         1    1      454999992  0
                ipu1_di0_pre          1    1      454999992  0
                   ipu1_di0_sel       1    1      454999992  0
                      ipu1_di0        1    1      454999992  0
             ldb_di1_sel              1    1      454999992  0
                ldb_di1_div_3_5       1    1      129999997  0
                   ldb_di1_podf       1    1      64999999   0
                      ldb_di1         1    1      64999999   0
                         ipu1_di1_sel 1    1      64999999   0
                            ipu1_di1  1    1      64999999   0

This shows that ipu1_di1 is correctly connected to the ldb_di1 clock,
and we can see what happened to the HDMI clock - and it's /not/ good
because we end up feeding a clock in excess of the stated maximum to
the IPU... 455MHz vs 270MHz max.

When Xorg is running, and Xorg has disabled the LVDS:

    pll5_video                        1    1      1188000000 0
       pll5_post_div                  1    1      297000000  0
          pll5_video_div              1    1      148500000  0
...
             ipu1_di0_pre_sel         1    1      148500000  0
                ipu1_di0_pre          1    1      148500000  0
                   ipu1_di0_sel       1    1      148500000  0
                      ipu1_di0        1    1      148500000  0
             ldb_di1_sel              0    0      148500000  0
                ldb_di1_div_3_5       0    0      42428571   0
                   ldb_di1_podf       0    0      21214286   0
                      ldb_di1         0    0      21214286   0
                         ipu1_di1_sel 0    0      21214286   0
                            ipu1_di1  0    0      21214286   0

Now, can we satisfy the combination of required clocks...

	LDB - 65MHz pixel clock,
		* 7 => 455MHz shift clock
				(note that had PLL3 PFD3 been routed to
				 the LDB clocks, then we'd almost have
				 this - 454.7MHz.)

	HDMI - 148.5MHz pixel clock
		* 2 => 297MHz
		* 3 => 445.5MHz
		* 4 => 594MHz (note that had PLL2 PFD1 been routed to
				the IPU DI clocks, this would get
				1080, 720, 576 and 480 p/i modes.)

Well, that question becomes whether 446MHz (3sf) and 455MHz are close
enough.  Given that the HDMI clock is related to the audio clock, we
should try to maintain its accuracy.  So, subsituting 446MHz as the
LDB shift clock would give us a clock of 63.6MHz, which is a little
over a 2% error.

The problem here is that we need more inteligence from CCF in order to
do that - we need it to be able to reprogram the dividers so that the
IPU DI0 clock remains at 148.5MHz while increasing the output of
pll5_video_div three-fold.

Another solution would be to source the LDB clock from PLL3 at 480MHz,
this gives a pixel clock of 68.6MHz (3sf).  The other options are
396MHz, 352MHz which would produce a considerably slower clock.

I've just been digging in a few LVDS panel data sheets, and it seems many
have quite a tolerance on the clock.  A 640x480 panel (Optrex) says
anything between 20 and 30MHz is acceptable.  An 800x600 Toshiba works
out at anything between 29MHz and 40MHz.  AUO 1024x768 gives a range of
50 to 81MHz.  However, there are some other AUO panels which we have in
drm_panel which specify an exact frequency.  We don't have the ability
in drm_panel to specify a range of frequencies - it may be useful if
we did, since we could use that to work out whether we can drive both
simultaneously off one PLL or one of the fixed clocks.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.