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@xxxxxxxxx> wrote: > > > On Mon, Jun 9, 2014 at 5:09 PM, Russell King - ARM Linux > > > <linux@xxxxxxxxxxxxxxxx> 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 _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
