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@gmail.com wrote:
On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux linux@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