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

[Philipp Zabel]

Hi Russell,

Am Mittwoch, den 11.06.2014, 09:17 +0100 schrieb 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:
> 
[...]
>
> 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.)

That would have been nice. Also there's the Audio PLL which is similar
to the Video PLL, only with a different post divider.

> 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.

Part of this could be achieved if clock notifiers would have a way to
give feedback to the core code when they NAK a clock change.

[...]
> 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.

For this reason struct display_timing includes minimum, maximum and
typical values for all timing parameters. This is also supported by
the display timing device tree bindings:
Documentation/devicetree/bindings/video/display-timing.txt
Unfortunately there is no code yet that can make use of this
information.

regards
Philipp