On Mon, Jun 16, 2014 at 11:13:02AM -0300, Fabio Estevam wrote:
> On Wed, Jun 11, 2014 at 5:17 AM, Russell King - ARM Linux
> <linux@xxxxxxxxxxxxxxxx> wrote:
>
> > 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
>
> Ok, I have tried this approach:
>
> --- a/arch/arm/mach-imx/clk-imx6q.c
> +++ b/arch/arm/mach-imx/clk-imx6q.c
> @@ -441,8 +441,8 @@ static void __init imx6q_clocks_init(struct device_node *ccm
>
> if ((imx_get_soc_revision() != IMX_CHIP_REVISION_1_0) ||
> cpu_is_imx6dl()) {
> - clk_set_parent(clk[ldb_di0_sel], clk[pll5_video_div]);
> - clk_set_parent(clk[ldb_di1_sel], clk[pll5_video_div]);
> + clk_set_parent(clk[ldb_di0_sel], clk[pll3_usb_otg]);
> + clk_set_parent(clk[ldb_di1_sel], clk[pll3_usb_otg]);
> }
>
> and it allows HDMI and LVDS to be displayed if I boot with the HDMI
> kernel connected. Would this be an acceptable solution in the
> meantime?
I have no objection to that as an interim solution, but it does leave
me wondering whether this causes LDB to change the USB OTG clocks.
Might it be worth printing something, just in case someone finds
USB OTG breaks and wonders why?
--
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
