[PATCH] i.MX IPU SoC support

[PATCH] i.MX IPU SoC support

[Sascha Hauer]

This series adds the necessary i.MX SoC stuff to make the IPU support
usable. Basically needed are the IPU devices in the devicetrees. This
series also adds display support for the i.MX51 babbage which then is
the first board for which the IPU driver works without out of tree
stuff.

Shawn, I already sent the MIPI setup patch some time ago. From what
I read I think we can agree on the approach on just setting the correct
register values in the SoC code, right?

Sascha

The following changes since commit 77b67063bb6bce6d475e910d3b886a606d0d91f7:

  Linux 3.7-rc5 (2012-11-11 13:44:33 +0100)

are available in the git repository at:

  git://git.pengutronix.de/git/imx/linux-2.6.git ipu

for you to fetch changes up to f774f0f776e282d6e0eb67dbf00703ed79b8bca2:

  ARM i.MX51 babbage: Add display support (2012-11-12 16:16:19 +0100)

----------------------------------------------------------------
Sascha Hauer (6):
      ARM i.MX51: setup MIPI during startup
      ARM i.MX5: switch IPU clk support to devicetree bindings
      ARM i.MX53: Add IPU support
      ARM i.MX51: Add IPU support
      ARM i.MX6: Add IPU support
      ARM i.MX51 babbage: Add display support

Steffen Trumtrar (1):
      ARM i.MX6: fix ldb_di_sel mux

 arch/arm/boot/dts/imx51-babbage.dts |   16 +++++++++
 arch/arm/boot/dts/imx51.dtsi        |   67 +++++++++++++++++++++++++++++++++++
 arch/arm/boot/dts/imx53.dtsi        |    7 ++++
 arch/arm/boot/dts/imx6q.dtsi        |   18 ++++++++++
 arch/arm/mach-imx/clk-imx51-imx53.c |   19 +++++-----
 arch/arm/mach-imx/clk-imx6q.c       |    2 +-
 arch/arm/mach-imx/mm-imx5.c         |   20 +++++++++++
 7 files changed, 140 insertions(+), 9 deletions(-)

[PATCH 1/7] ARM i.MX51: setup MIPI during startup

[Sascha Hauer]

The MIPI interface has to be initialized for proper IPU support.
The MIPI officially is not supported, but still needs initialization.
This patch adds this to the SoC startup as all it does is poking
some magic values into registers for which we do not have documentation.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/mm-imx5.c |   20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)

diff --git a/arch/arm/mach-imx/mm-imx5.c b/arch/arm/mach-imx/mm-imx5.c
index acb0aad..f01e74f 100644
--- a/arch/arm/mach-imx/mm-imx5.c
+++ b/arch/arm/mach-imx/mm-imx5.c
@@ -81,8 +81,28 @@ void __init imx50_init_early(void)
 	mxc_arch_reset_init(MX50_IO_ADDRESS(MX50_WDOG_BASE_ADDR));
 }
 
+/*
+ * The MIPI HSC unit has been removed from the i.MX51 Reference Manual by
+ * the Freescale marketing division. However this did not remove the
+ * hardware from the chip which still needs to be configured for proper
+ * IPU support.
+ */
+static void __init imx51_ipu_mipi_setup(void)
+{
+	void __iomem *hsc_addr;
+	hsc_addr = MX51_IO_ADDRESS(MX51_MIPI_HSC_BASE_ADDR);
+
+	/* setup MIPI module to legacy mode */
+	__raw_writel(0xf00, hsc_addr);
+
+	/* CSI mode: reserved; DI control mode: legacy (from Freescale BSP) */
+	__raw_writel(__raw_readl(hsc_addr + 0x800) | 0x30ff,
+		hsc_addr + 0x800);
+}
+
 void __init imx51_init_early(void)
 {
+	imx51_ipu_mipi_setup();
 	mxc_set_cpu_type(MXC_CPU_MX51);
 	mxc_iomux_v3_init(MX51_IO_ADDRESS(MX51_IOMUXC_BASE_ADDR));
 	mxc_arch_reset_init(MX51_IO_ADDRESS(MX51_WDOG1_BASE_ADDR));
-- 
1.7.10.4

[PATCH 2/7] ARM i.MX6: fix ldb_di_sel mux

[Sascha Hauer]

From: Steffen Trumtrar <s.trumtrar@pengutronix.de>

This adds the mmdc_ch1 as a possible parent for the ldb_di clk.
According to the datasheet, this clock can be selected at this mux.

Signed-off-by: Steffen Trumtrar <s.trumtrar@pengutronix.de>
---
 arch/arm/mach-imx/clk-imx6q.c |    2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm/mach-imx/clk-imx6q.c b/arch/arm/mach-imx/clk-imx6q.c
index 3ec242f..6b511ba 100644
--- a/arch/arm/mach-imx/clk-imx6q.c
+++ b/arch/arm/mach-imx/clk-imx6q.c
@@ -104,7 +104,7 @@ static const char *gpu2d_core_sels[]	= { "axi", "pll3_usb_otg", "pll2_pfd0_352m"
 static const char *gpu3d_core_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd2_396m", };
 static const char *gpu3d_shader_sels[] = { "mmdc_ch0_axi", "pll3_usb_otg", "pll2_pfd1_594m", "pll2_pfd9_720m", };
 static const char *ipu_sels[]		= { "mmdc_ch0_axi", "pll2_pfd2_396m", "pll3_120m", "pll3_pfd1_540m", };
-static const char *ldb_di_sels[]	= { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
+static const char *ldb_di_sels[]	= { "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "mmdc_ch1_axi", "pll3_pfd1_540m", };
 static const char *ipu_di_pre_sels[]	= { "mmdc_ch0_axi", "pll3_usb_otg", "pll5_video", "pll2_pfd0_352m", "pll2_pfd2_396m", "pll3_pfd1_540m", };
 static const char *ipu1_di0_sels[]	= { "ipu1_di0_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
 static const char *ipu1_di1_sels[]	= { "ipu1_di1_pre", "dummy", "dummy", "ldb_di0", "ldb_di1", };
-- 
1.7.10.4

[PATCH 3/7] ARM i.MX5: switch IPU clk support to devicetree bindings

[Sascha Hauer]

The i.MX5 clk support has platform based clock bindings for the
IPU. IPU support is devicetree only, so move them over to devicetree
based bindings. Also, enable MIPI clocks which do not have a device
associated with, but still need to be enabled to do graphics on
i.MX51.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/clk-imx51-imx53.c |   19 +++++++++++--------
 1 file changed, 11 insertions(+), 8 deletions(-)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index a0bf848..02932da 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -306,6 +306,10 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
 	clk_prepare_enable(clk[spba]);
 	clk_prepare_enable(clk[emi_fast_gate]); /* fec */
 	clk_prepare_enable(clk[emi_slow_gate]); /* eim */
+	clk_prepare_enable(clk[mipi_hsc1_gate]);
+	clk_prepare_enable(clk[mipi_hsc2_gate]);
+	clk_prepare_enable(clk[mipi_esc_gate]);
+	clk_prepare_enable(clk[mipi_hsp_gate]);
 	clk_prepare_enable(clk[tmax1]);
 	clk_prepare_enable(clk[tmax2]); /* esdhc2, fec */
 	clk_prepare_enable(clk[tmax3]); /* esdhc1, esdhc4 */
@@ -349,10 +353,9 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 	clk_register_clkdev(clk[mx51_mipi], "mipi_hsp", NULL);
 	clk_register_clkdev(clk[vpu_gate], NULL, "imx51-vpu.0");
 	clk_register_clkdev(clk[fec_gate], NULL, "imx27-fec.0");
-	clk_register_clkdev(clk[ipu_gate], "bus", "imx51-ipu");
-	clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx51-ipu");
-	clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx51-ipu");
-	clk_register_clkdev(clk[ipu_gate], "hsp", "imx51-ipu");
+	clk_register_clkdev(clk[ipu_gate], "bus", "40000000.ipu");
+	clk_register_clkdev(clk[ipu_di0_gate], "di0", "40000000.ipu");
+	clk_register_clkdev(clk[ipu_di1_gate], "di1", "40000000.ipu");
 	clk_register_clkdev(clk[usb_phy_gate], "phy", "mxc-ehci.0");
 	clk_register_clkdev(clk[esdhc1_ipg_gate], "ipg", "sdhci-esdhc-imx51.0");
 	clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx51.0");
@@ -442,10 +445,10 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 	clk_register_clkdev(clk[vpu_gate], NULL, "imx53-vpu.0");
 	clk_register_clkdev(clk[i2c3_gate], NULL, "imx-i2c.2");
 	clk_register_clkdev(clk[fec_gate], NULL, "imx25-fec.0");
-	clk_register_clkdev(clk[ipu_gate], "bus", "imx53-ipu");
-	clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx53-ipu");
-	clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx53-ipu");
-	clk_register_clkdev(clk[ipu_gate], "hsp", "imx53-ipu");
+	clk_register_clkdev(clk[ipu_gate], "bus", "18000000.ipu");
+	clk_register_clkdev(clk[ipu_di0_gate], "di0", "18000000.ipu");
+	clk_register_clkdev(clk[ipu_di1_gate], "di1", "18000000.ipu");
+	clk_register_clkdev(clk[ipu_gate], "hsp", "18000000.ipu");
 	clk_register_clkdev(clk[usb_phy1_gate], "usb_phy1", "mxc-ehci.0");
 	clk_register_clkdev(clk[esdhc1_ipg_gate], "ipg", "sdhci-esdhc-imx53.0");
 	clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx53.0");
-- 
1.7.10.4

[PATCH 3/7] ARM i.MX5: switch IPU clk support to devicetree bindings

[Shawn Guo]

Hi Sascha,

On Mon, Nov 12, 2012 at 04:23:25PM +0100, Sascha Hauer wrote:
> The i.MX5 clk support has platform based clock bindings for the
> IPU. IPU support is devicetree only, so move them over to devicetree
> based bindings. Also, enable MIPI clocks which do not have a device
> associated with, but still need to be enabled to do graphics on
> i.MX51.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   19 +++++++++++--------
>  1 file changed, 11 insertions(+), 8 deletions(-)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index a0bf848..02932da 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -306,6 +306,10 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
>  	clk_prepare_enable(clk[spba]);
>  	clk_prepare_enable(clk[emi_fast_gate]); /* fec */
>  	clk_prepare_enable(clk[emi_slow_gate]); /* eim */
> +	clk_prepare_enable(clk[mipi_hsc1_gate]);
> +	clk_prepare_enable(clk[mipi_hsc2_gate]);
> +	clk_prepare_enable(clk[mipi_esc_gate]);
> +	clk_prepare_enable(clk[mipi_hsp_gate]);

I just noticed that enabling these clocks will stop my imx51-babbage
board from booting to console.  Can you please investigate it?

Shawn

>  	clk_prepare_enable(clk[tmax1]);
>  	clk_prepare_enable(clk[tmax2]); /* esdhc2, fec */
>  	clk_prepare_enable(clk[tmax3]); /* esdhc1, esdhc4 */
> @@ -349,10 +353,9 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  	clk_register_clkdev(clk[mx51_mipi], "mipi_hsp", NULL);
>  	clk_register_clkdev(clk[vpu_gate], NULL, "imx51-vpu.0");
>  	clk_register_clkdev(clk[fec_gate], NULL, "imx27-fec.0");
> -	clk_register_clkdev(clk[ipu_gate], "bus", "imx51-ipu");
> -	clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx51-ipu");
> -	clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx51-ipu");
> -	clk_register_clkdev(clk[ipu_gate], "hsp", "imx51-ipu");
> +	clk_register_clkdev(clk[ipu_gate], "bus", "40000000.ipu");
> +	clk_register_clkdev(clk[ipu_di0_gate], "di0", "40000000.ipu");
> +	clk_register_clkdev(clk[ipu_di1_gate], "di1", "40000000.ipu");
>  	clk_register_clkdev(clk[usb_phy_gate], "phy", "mxc-ehci.0");
>  	clk_register_clkdev(clk[esdhc1_ipg_gate], "ipg", "sdhci-esdhc-imx51.0");
>  	clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx51.0");
> @@ -442,10 +445,10 @@ int __init mx53_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  	clk_register_clkdev(clk[vpu_gate], NULL, "imx53-vpu.0");
>  	clk_register_clkdev(clk[i2c3_gate], NULL, "imx-i2c.2");
>  	clk_register_clkdev(clk[fec_gate], NULL, "imx25-fec.0");
> -	clk_register_clkdev(clk[ipu_gate], "bus", "imx53-ipu");
> -	clk_register_clkdev(clk[ipu_di0_gate], "di0", "imx53-ipu");
> -	clk_register_clkdev(clk[ipu_di1_gate], "di1", "imx53-ipu");
> -	clk_register_clkdev(clk[ipu_gate], "hsp", "imx53-ipu");
> +	clk_register_clkdev(clk[ipu_gate], "bus", "18000000.ipu");
> +	clk_register_clkdev(clk[ipu_di0_gate], "di0", "18000000.ipu");
> +	clk_register_clkdev(clk[ipu_di1_gate], "di1", "18000000.ipu");
> +	clk_register_clkdev(clk[ipu_gate], "hsp", "18000000.ipu");
>  	clk_register_clkdev(clk[usb_phy1_gate], "usb_phy1", "mxc-ehci.0");
>  	clk_register_clkdev(clk[esdhc1_ipg_gate], "ipg", "sdhci-esdhc-imx53.0");
>  	clk_register_clkdev(clk[dummy], "ahb", "sdhci-esdhc-imx53.0");
> -- 
> 1.7.10.4
> 

[PATCH 3/7] ARM i.MX5: switch IPU clk support to devicetree bindings

[Sascha Hauer]

Hi Shawn,

On Tue, Dec 11, 2012 at 01:57:00PM +0800, Shawn Guo wrote:
> Hi Sascha,
> 
> On Mon, Nov 12, 2012 at 04:23:25PM +0100, Sascha Hauer wrote:
> > The i.MX5 clk support has platform based clock bindings for the
> > IPU. IPU support is devicetree only, so move them over to devicetree
> > based bindings. Also, enable MIPI clocks which do not have a device
> > associated with, but still need to be enabled to do graphics on
> > i.MX51.
> > 
> > Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > ---
> >  arch/arm/mach-imx/clk-imx51-imx53.c |   19 +++++++++++--------
> >  1 file changed, 11 insertions(+), 8 deletions(-)
> > 
> > diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> > index a0bf848..02932da 100644
> > --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> > +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> > @@ -306,6 +306,10 @@ static void __init mx5_clocks_common_init(unsigned long rate_ckil,
> >  	clk_prepare_enable(clk[spba]);
> >  	clk_prepare_enable(clk[emi_fast_gate]); /* fec */
> >  	clk_prepare_enable(clk[emi_slow_gate]); /* eim */
> > +	clk_prepare_enable(clk[mipi_hsc1_gate]);
> > +	clk_prepare_enable(clk[mipi_hsc2_gate]);
> > +	clk_prepare_enable(clk[mipi_esc_gate]);
> > +	clk_prepare_enable(clk[mipi_hsp_gate]);
> 
> I just noticed that enabling these clocks will stop my imx51-babbage
> board from booting to console.  Can you please investigate it?

I just tested it, this seems to be a bit complicated. I can confirm that
with IPU disabled the last message I see from the kernel is:

IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready

When the IPU is enabled everything is fine. In my testing the IPU was
enabled, in the end that was the motivation of the whole series.

It seems to be that the system does not work when the MIPI/HSP clocks
are enabled and the IPU clock is disabled. I found some reserved bits
in the reference manual. Could you try the following and see if it fixes
your problem?


>From 7d6eca0b10c1a1e2f13c229f6c6c8d6541926dd5 Mon Sep 17 00:00:00 2001
From: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue, 11 Dec 2012 10:08:50 +0100
Subject: [PATCH] ARM i.MX51 clock: Fix regression since enabling MIPI/HSP
 clocks

The MIPI/HSP clocks were recently turned on in the i.MX51 clock tree.
It turned out that the system does not work properly when the MIPI/HSP
clocks are enabled, but the IPU clock is disabled. This happens when
IPU support is disabled. In this case the IPU clock gets disabled when
the clock framework turns off unused clock in a late_initcall. This
is broken since:

| commit 9a2d4825a9368e018003a2732a61be063d178f67
| Author: Sascha Hauer <s.hauer@pengutronix.de>
| Date:   Tue Jun 5 13:53:32 2012 +0200
|
|     ARM i.MX5: switch IPU clk support to devicetree bindings
|
|     The i.MX5 clk support has platform based clock bindings for the
|     IPU. IPU support is devicetree only, so move them over to devicetree
|     based bindings. Also, enable MIPI clocks which do not have a device
|     associated with, but still need to be enabled to do graphics on
|     i.MX51.

This patch fixes this by setting some reserved bits in the CCM as recommended
in the reference manual.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/mach-imx/clk-imx51-imx53.c |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
index e8c0473..579023f 100644
--- a/arch/arm/mach-imx/clk-imx51-imx53.c
+++ b/arch/arm/mach-imx/clk-imx51-imx53.c
@@ -319,6 +319,7 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 			unsigned long rate_ckih1, unsigned long rate_ckih2)
 {
 	int i;
+	u32 val;
 	struct device_node *np;
 
 	clk[pll1_sw] = imx_clk_pllv2("pll1_sw", "osc", MX51_DPLL1_BASE);
@@ -390,6 +391,21 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
 	imx_print_silicon_rev("i.MX51", mx51_revision());
 	clk_disable_unprepare(clk[iim_gate]);
 
+	/*
+	 * Reference Manual says: Functionality of CCDR[18] and CLPCR[23] is no
+	 * longer supported. Set to one for better power saving.
+	 *
+	 * The effect of not setting these bits is that MIPI clocks can't be
+	 * enabled without the IPU clock being enabled aswell.
+	 */
+	val = readl(MXC_CCM_CCDR);
+	val |= 1 << 18;
+	writel(val, MXC_CCM_CCDR);
+
+	val = readl(MXC_CCM_CLPCR);
+	val |= 1 << 23;
+	writel(val, MXC_CCM_CLPCR);
+
 	return 0;
 }
 
-- 
1.7.10.4


-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 3/7] ARM i.MX5: switch IPU clk support to devicetree bindings

[Shawn Guo]

On Tue, Dec 11, 2012 at 10:14:53AM +0100, Sascha Hauer wrote:
> I just tested it, this seems to be a bit complicated. I can confirm that
> with IPU disabled the last message I see from the kernel is:
> 
> IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
> 
> When the IPU is enabled everything is fine. In my testing the IPU was
> enabled, in the end that was the motivation of the whole series.
> 
> It seems to be that the system does not work when the MIPI/HSP clocks
> are enabled and the IPU clock is disabled. I found some reserved bits
> in the reference manual. Could you try the following and see if it fixes
> your problem?
> 
Yes, it fixes my problem.  Thanks for the quick fixing.

> 
> From 7d6eca0b10c1a1e2f13c229f6c6c8d6541926dd5 Mon Sep 17 00:00:00 2001
> From: Sascha Hauer <s.hauer@pengutronix.de>
> Date: Tue, 11 Dec 2012 10:08:50 +0100
> Subject: [PATCH] ARM i.MX51 clock: Fix regression since enabling MIPI/HSP
>  clocks
> 
> The MIPI/HSP clocks were recently turned on in the i.MX51 clock tree.
> It turned out that the system does not work properly when the MIPI/HSP
> clocks are enabled, but the IPU clock is disabled. This happens when
> IPU support is disabled. In this case the IPU clock gets disabled when
> the clock framework turns off unused clock in a late_initcall. This
> is broken since:
> 
> | commit 9a2d4825a9368e018003a2732a61be063d178f67
> | Author: Sascha Hauer <s.hauer@pengutronix.de>
> | Date:   Tue Jun 5 13:53:32 2012 +0200
> |
> |     ARM i.MX5: switch IPU clk support to devicetree bindings
> |
> |     The i.MX5 clk support has platform based clock bindings for the
> |     IPU. IPU support is devicetree only, so move them over to devicetree
> |     based bindings. Also, enable MIPI clocks which do not have a device
> |     associated with, but still need to be enabled to do graphics on
> |     i.MX51.
> 
> This patch fixes this by setting some reserved bits in the CCM as recommended
> in the reference manual.
> 
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

Tested-by: Shawn Guo <shawn.guo@linaro.org>

Shawn

> ---
>  arch/arm/mach-imx/clk-imx51-imx53.c |   16 ++++++++++++++++
>  1 file changed, 16 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/clk-imx51-imx53.c b/arch/arm/mach-imx/clk-imx51-imx53.c
> index e8c0473..579023f 100644
> --- a/arch/arm/mach-imx/clk-imx51-imx53.c
> +++ b/arch/arm/mach-imx/clk-imx51-imx53.c
> @@ -319,6 +319,7 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  			unsigned long rate_ckih1, unsigned long rate_ckih2)
>  {
>  	int i;
> +	u32 val;
>  	struct device_node *np;
>  
>  	clk[pll1_sw] = imx_clk_pllv2("pll1_sw", "osc", MX51_DPLL1_BASE);
> @@ -390,6 +391,21 @@ int __init mx51_clocks_init(unsigned long rate_ckil, unsigned long rate_osc,
>  	imx_print_silicon_rev("i.MX51", mx51_revision());
>  	clk_disable_unprepare(clk[iim_gate]);
>  
> +	/*
> +	 * Reference Manual says: Functionality of CCDR[18] and CLPCR[23] is no
> +	 * longer supported. Set to one for better power saving.
> +	 *
> +	 * The effect of not setting these bits is that MIPI clocks can't be
> +	 * enabled without the IPU clock being enabled aswell.
> +	 */
> +	val = readl(MXC_CCM_CCDR);
> +	val |= 1 << 18;
> +	writel(val, MXC_CCM_CCDR);
> +
> +	val = readl(MXC_CCM_CLPCR);
> +	val |= 1 << 23;
> +	writel(val, MXC_CCM_CLPCR);
> +
>  	return 0;
>  }
>  
> -- 
> 1.7.10.4
> 
> 
> -- 
> Pengutronix e.K.                           |                             |
> Industrial Linux Solutions                 | http://www.pengutronix.de/  |
> Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
> Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |

[PATCH 4/7] ARM i.MX53: Add IPU support

[Sascha Hauer]

This adds the IPU device to the devicetree.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/boot/dts/imx53.dtsi |    7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm/boot/dts/imx53.dtsi b/arch/arm/boot/dts/imx53.dtsi
index 76ebb1a..3387c5d 100644
--- a/arch/arm/boot/dts/imx53.dtsi
+++ b/arch/arm/boot/dts/imx53.dtsi
@@ -67,6 +67,13 @@
 		interrupt-parent = <&tzic>;
 		ranges;
 
+		ipu: ipu at 18000000 {
+			#crtc-cells = <1>;
+			compatible = "fsl,imx53-ipu";
+			reg = <0x18000000 0x080000000>;
+			interrupts = <11 10>;
+		};
+
 		aips at 50000000 { /* AIPS1 */
 			compatible = "fsl,aips-bus", "simple-bus";
 			#address-cells = <1>;
-- 
1.7.10.4

[PATCH 5/7] ARM i.MX51: Add IPU support

[Sascha Hauer]

This adds the IPU device to the devicetree along with the necessary pinctrl
settings for the parallel display outputs.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/boot/dts/imx51.dtsi |   67 ++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 67 insertions(+)

diff --git a/arch/arm/boot/dts/imx51.dtsi b/arch/arm/boot/dts/imx51.dtsi
index 75d069f..c20e868 100644
--- a/arch/arm/boot/dts/imx51.dtsi
+++ b/arch/arm/boot/dts/imx51.dtsi
@@ -62,6 +62,13 @@
 		interrupt-parent = <&tzic>;
 		ranges;
 
+		ipu: ipu at 40000000 {
+			#crtc-cells = <1>;
+			compatible = "fsl,imx51-ipu";
+			reg = <0x40000000 0x20000000>;
+			interrupts = <11 10>;
+		};
+
 		aips at 70000000 { /* AIPS1 */
 			compatible = "fsl,aips-bus", "simple-bus";
 			#address-cells = <1>;
@@ -295,6 +302,66 @@
 					};
 				};
 
+				ipu_disp1 {
+					pinctrl_ipu_disp1_1: ipudisp1grp-1 {
+						fsl,pins = <
+							528 0x5 /* MX51_PAD_DISP1_DAT0__DISP1_DAT0 */
+							529 0x5 /* MX51_PAD_DISP1_DAT1__DISP1_DAT1 */
+							530 0x5 /* MX51_PAD_DISP1_DAT2__DISP1_DAT2 */
+							531 0x5 /* MX51_PAD_DISP1_DAT3__DISP1_DAT3 */
+							532 0x5 /* MX51_PAD_DISP1_DAT4__DISP1_DAT4 */
+							533 0x5 /* MX51_PAD_DISP1_DAT5__DISP1_DAT5 */
+							535 0x5 /* MX51_PAD_DISP1_DAT6__DISP1_DAT6 */
+							537 0x5 /* MX51_PAD_DISP1_DAT7__DISP1_DAT7 */
+							539 0x5 /* MX51_PAD_DISP1_DAT8__DISP1_DAT8 */
+							541 0x5 /* MX51_PAD_DISP1_DAT9__DISP1_DAT9 */
+							543 0x5 /* MX51_PAD_DISP1_DAT10__DISP1_DAT10 */
+							545 0x5 /* MX51_PAD_DISP1_DAT11__DISP1_DAT11 */
+							547 0x5 /* MX51_PAD_DISP1_DAT12__DISP1_DAT12 */
+							549 0x5 /* MX51_PAD_DISP1_DAT13__DISP1_DAT13 */
+							551 0x5 /* MX51_PAD_DISP1_DAT14__DISP1_DAT14 */
+							553 0x5 /* MX51_PAD_DISP1_DAT15__DISP1_DAT15 */
+							555 0x5 /* MX51_PAD_DISP1_DAT16__DISP1_DAT16 */
+							557 0x5 /* MX51_PAD_DISP1_DAT17__DISP1_DAT17 */
+							559 0x5 /* MX51_PAD_DISP1_DAT18__DISP1_DAT18 */
+							563 0x5 /* MX51_PAD_DISP1_DAT19__DISP1_DAT19 */
+							567 0x5 /* MX51_PAD_DISP1_DAT20__DISP1_DAT20 */
+							571 0x5 /* MX51_PAD_DISP1_DAT21__DISP1_DAT21 */
+							575 0x5 /* MX51_PAD_DISP1_DAT22__DISP1_DAT22 */
+							579 0x5 /* MX51_PAD_DISP1_DAT23__DISP1_DAT23 */
+							584 0x5 /* MX51_PAD_DI1_PIN2__DI1_PIN2 (hsync) */
+							583 0x5 /* MX51_PAD_DI1_PIN3__DI1_PIN3 (vsync) */
+						>;
+					};
+				};
+
+				ipu_disp2 {
+					pinctrl_ipu_disp2_1: ipudisp2grp-1 {
+						fsl,pins = <
+							603 0x5 /* MX51_PAD_DISP2_DAT0__DISP2_DAT0 */
+							608 0x5 /* MX51_PAD_DISP2_DAT1__DISP2_DAT1 */
+							613 0x5 /* MX51_PAD_DISP2_DAT2__DISP2_DAT2 */
+							614 0x5 /* MX51_PAD_DISP2_DAT3__DISP2_DAT3 */
+							615 0x5 /* MX51_PAD_DISP2_DAT4__DISP2_DAT4 */
+							616 0x5 /* MX51_PAD_DISP2_DAT5__DISP2_DAT5 */
+							617 0x5 /* MX51_PAD_DISP2_DAT6__DISP2_DAT6 */
+							622 0x5 /* MX51_PAD_DISP2_DAT7__DISP2_DAT7 */
+							627 0x5 /* MX51_PAD_DISP2_DAT8__DISP2_DAT8 */
+							633 0x5 /* MX51_PAD_DISP2_DAT9__DISP2_DAT9 */
+							637 0x5 /* MX51_PAD_DISP2_DAT10__DISP2_DAT10 */
+							643 0x5 /* MX51_PAD_DISP2_DAT11__DISP2_DAT11 */
+							648 0x5 /* MX51_PAD_DISP2_DAT12__DISP2_DAT12 */
+							652 0x5 /* MX51_PAD_DISP2_DAT13__DISP2_DAT13 */
+							656 0x5 /* MX51_PAD_DISP2_DAT14__DISP2_DAT14 */
+							661 0x5 /* MX51_PAD_DISP2_DAT15__DISP2_DAT15 */
+							593 0x5 /* MX51_PAD_DI2_PIN2__DI2_PIN2 (hsync) */
+							595 0x5 /* MX51_PAD_DI2_PIN3__DI2_PIN3 (vsync) */
+							597 0x5 /* MX51_PAD_DI2_DISP_CLK__DI2_DISP_CLK */
+							599 0x5 /* MX51_PAD_DI_GP4__DI2_PIN15 */
+						>;
+					};
+				};
+
 				uart1 {
 					pinctrl_uart1_1: uart1grp-1 {
 						fsl,pins = <
-- 
1.7.10.4

[PATCH 6/7] ARM i.MX6: Add IPU support

[Sascha Hauer]

This adds the IPU devices to the devicetree.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/boot/dts/imx6q.dtsi |   18 ++++++++++++++++++
 1 file changed, 18 insertions(+)

diff --git a/arch/arm/boot/dts/imx6q.dtsi b/arch/arm/boot/dts/imx6q.dtsi
index f3990b0..39d3433 100644
--- a/arch/arm/boot/dts/imx6q.dtsi
+++ b/arch/arm/boot/dts/imx6q.dtsi
@@ -1001,5 +1001,23 @@
 				status = "disabled";
 			};
 		};
+
+		ipu1: ipu at 02400000 {
+			#crtc-cells = <1>;
+			compatible = "fsl,imx6q-ipu";
+			reg = <0x02400000 0x400000>;
+			interrupts = <0 6 0x4 0 5 0x4>;
+			clocks = <&clks 130>, <&clks 131>, <&clks 132>;
+			clock-names = "bus", "di0", "di1";
+		};
+
+		ipu2: ipu at 02800000 {
+			#crtc-cells = <1>;
+			compatible = "fsl,imx6q-ipu";
+			reg = <0x02800000 0x400000>;
+			interrupts = <0 8 0x4 0 7 0x4>;
+			clocks = <&clks 133>, <&clks 134>, <&clks 137>;
+			clock-names = "bus", "di0", "di1";
+		};
 	};
 };
-- 
1.7.10.4

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Sascha Hauer]

The babbage board has a DVI-I output which allows to output analog
and digital signals simultaneously. This patch adds support for it
to the devicetree. The DDC signals are not wired up on the board, so
DRM will fall back on default VESA modes.

Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
---
 arch/arm/boot/dts/imx51-babbage.dts |   16 ++++++++++++++++
 1 file changed, 16 insertions(+)

diff --git a/arch/arm/boot/dts/imx51-babbage.dts b/arch/arm/boot/dts/imx51-babbage.dts
index cbd2b1c..567e7ee 100644
--- a/arch/arm/boot/dts/imx51-babbage.dts
+++ b/arch/arm/boot/dts/imx51-babbage.dts
@@ -22,6 +22,22 @@
 	};
 
 	soc {
+		display at di0 {
+			compatible = "fsl,imx-parallel-display";
+			crtcs = <&ipu 0>;
+			interface-pix-fmt = "rgb24";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ipu_disp1_1>;
+		};
+
+		display at di1 {
+			compatible = "fsl,imx-parallel-display";
+			crtcs = <&ipu 1>;
+			interface-pix-fmt = "rgb565";
+			pinctrl-names = "default";
+			pinctrl-0 = <&pinctrl_ipu_disp2_1>;
+		};
+
 		aips at 70000000 { /* aips-1 */
 			spba at 70000000 {
 				esdhc at 70004000 { /* ESDHC1 */
-- 
1.7.10.4

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Martin Fuzzey]

Hi Sascha,

On Mon, Nov 12, 2012 at 4:23 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> +               display at di1 {
> +                       compatible = "fsl,imx-parallel-display";
> +                       crtcs = <&ipu 1>;

This works but Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
says "crtc"  (without the s). Looks like the doc has a typo.

I ran into that problem today on i.MX53

Regards,

Martin

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Fabio Estevam]

On Mon, Nov 12, 2012 at 7:40 PM, Martin Fuzzey <mfuzzey@gmail.com> wrote:
> Hi Sascha,
>
> On Mon, Nov 12, 2012 at 4:23 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> +               display at di1 {
>> +                       compatible = "fsl,imx-parallel-display";
>> +                       crtcs = <&ipu 1>;
>
> This works but Documentation/devicetree/bindings/staging/imx-drm/fsl-imx-drm.txt
> says "crtc"  (without the s). Looks like the doc has a typo.

Care to send a patch?

Thanks,

Fabio Estevam

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Fabio Estevam]

Hi Sascha,

On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
> The babbage board has a DVI-I output which allows to output analog
> and digital signals simultaneously. This patch adds support for it
> to the devicetree. The DDC signals are not wired up on the board, so
> DRM will fall back on default VESA modes.
>
> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>

I am running linux-next 20130108, which has this patch applied and I
get the following on my mx51babbage:

[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] No driver support for vblank timestamp query.
[drm] Initialized imx-drm 1.0.0 20120507 on minor 0
imx-ipuv3 40000000.ipu: DI0 base: 0x5e040000 remapped to a08aa000
imx-ipuv3 40000000.ipu: DI1 base: 0x5e048000 remapped to a08ac000
imx-ipuv3 40000000.ipu: IPUv3EX probed
Unable to handle kernel NULL pointer dereference at virtual address 0000000c
pgd = 80004000
[0000000c] *pgd=00000000
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0    Not tainted  (3.8.0-rc2-next-20130108+ #996)
PC is at imx_drm_handle_vblank+0xc/0x20
LR is at ipu_irq_handler+0x1c/0xe0
pc : [<803f97b8>]    lr : [<803fe5f0>]    psr: 40000193
sp : 9f855b20  ip : 9f855b30  fp : 9f855b2c
r10: 9fa69600  r9 : 8070d39a  r8 : 00000127
r7 : 00000000  r6 : 9fa5f010  r5 : 9fa69650  r4 : 9fa701c0
r3 : 803fe5d4  r2 : 9fa69650  r1 : 9fa5f010  r0 : 00000000
Flags: nZcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 90004019  DAC: 00000017
Process swapper/0 (pid: 1, stack limit = 0x9f854238)
Stack: (0x9f855b20 to 0x9f856000)
5b20: 9f855b5c 9f855b30 803fe5f0 803f97b8 9f854000 002012d0 9f855bd4 9fa701c0
5b40: 9fa69650 00000000 00000000 00000127 9f855b94 9f855b60 8006ed8c 803fe5e0
5b60: 0003a980 00000000 00000000 9fa69600 9fa69650 00000001 9fa78c10 00000000
5b80: 00000017 00000009 9f855bac 9f855b98 8006ef34 8006ed44 9fa69600 9fa69650
5ba0: 9f855bcc 9f855bb0 80071ac4 8006eee0 80071a10 00000127 9f855c28 00000000
5bc0: 9f855be4 9f855bd0 8006e6e4 80071a1c 00000007 00000110 9f855c1c 9f855be8
5be0: 803fabb0 8006e6c8 80258e7c 00800000 9f855c1c 9f805480 9fa78c10 9f80cdb4
5c00: 0000001b 00000000 9fa69630 00000000 9f855c64 9f855c20 803facf4 803fab28
5c20: 00000000 00000000 00000001 00000002 00000003 0000000a 0000000b 0000000c
5c40: 0000000d 0000000e 9f855c64 0000001b 806cfe08 9f854000 9f855c7c 9f855c68
5c60: 8006e6e4 803fac98 000001b0 806db178 9f855ca4 9f855c80 8000ede8 8006e6c8
5c80: 00000010 00000000 8070dca0 00000000 00000001 9f855cd0 9f855ccc 9f855ca8
5ca0: 800085ac 8000eda0 80515b44 60000113 ffffffff 9f855d04 00000127 60000113
5cc0: 9f855d24 9f855cd0 8000e080 80008540 9fa69650 60000113 00050005 00000000
5ce0: 9fa69600 9fa701c0 9fa69650 00000000 00000127 9fa69630 60000113 9f855d24
5d00: 00000000 9f855d18 80070418 80515b44 60000113 ffffffff 9f855d64 9f855d28
5d20: 80070418 80515b18 8011565c 800af4e4 00003278 000080d0 9f855d54 9fa701c0
5d40: 9fa69600 9fa5f010 00000000 803fe5d4 00000000 00000127 9f855d94 9f855d68
5d60: 80070720 80070258 00000000 9fa70190 00000127 803fe5d4 9fa64410 00000000
5d80: 8069220c 9fa5f010 9f855dc4 9f855d98 80072690 8007066c 806556fc 9fa5f010
5da0: 9fa68940 9fa5f010 9fa78c10 9fa64410 807057a4 8070d480 9f855df4 9f855dc8
5dc0: 803fe038 80072640 00000000 806556fc 9fa5f010 80116c14 8075c080 807057a4
5de0: 9fa64410 00000000 9f855e04 9f855df8 802d8e38 803fdf2c 9f855e2c 9f855e08
5e00: 802d79b0 802d8e24 00000000 9fa64410 807057a4 9fa64444 00000000 000000a4
5e20: 9f855e4c 9f855e30 802d7bc8 802d7944 802d7b34 807057a4 802d7b34 00000000
5e40: 9f855e74 9f855e50 802d6128 802d7b40 9f833158 9fa658b4 80257848 807057a4
5e60: 806f3e10 9fa65980 9f855e84 9f855e78 802d7558 802d60dc 9f855eb4 9f855e88
5e80: 802d7174 802d7544 8065563c 8070d480 9f855eb4 807057a4 00000006 00000000
5ea0: 8070d480 000000a4 9f855edc 9f855eb8 802d8110 802d7008 9f854000 00000006
5ec0: 00000000 8070d480 000000a4 8070d480 9f855eec 9f855ee0 802d905c 802d809c
5ee0: 9f855efc 9f855ef0 806b2618 802d901c 9f855f54 9f855f00 800086b8 806b2610
5f00: 9f855f54 9f855f10 806b2604 00000000 00000000 00000006 00000006 8068f8f8
5f20: 00000000 806489fc 9f855f54 806c43e0 00000006 806c43c0 8070d480 000000a4
5f40: 8069220c 806ce9a8 9f855f94 9f855f58 80692978 80008684 00000006 00000006
5f60: 8069220c 00000000 00000000 00000000 8050b0bc 00000000 00000000 00000000
5f80: 00000000 00000000 9f855fac 9f855f98 8050b0cc 80692880 ffffffff 00000000
5fa0: 00000000 9f855fb0 8000e598 8050b0c8 00000000 00000000 00000000 00000000
5fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
5fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
Backtrace:
[<803f97ac>] (imx_drm_handle_vblank+0x0/0x20) from [<803fe5f0>]
(ipu_irq_handler+0x1c/0xe0)
[<803fe5d4>] (ipu_irq_handler+0x0/0xe0) from [<8006ed8c>]
(handle_irq_event_percpu+0x54/0x19c)
 r8:00000127 r7:00000000 r6:00000000 r5:9fa69650 r4:9fa701c0
[<8006ed38>] (handle_irq_event_percpu+0x0/0x19c) from [<8006ef34>]
(handle_irq_event+0x60/0x80)
[<8006eed4>] (handle_irq_event+0x0/0x80) from [<80071ac4>]
(handle_level_irq+0xb4/0x134)
 r5:9fa69650 r4:9fa69600
[<80071a10>] (handle_level_irq+0x0/0x134) from [<8006e6e4>]
(generic_handle_irq+0x28/0x38)
 r6:00000000 r5:9f855c28 r4:00000127 r3:80071a10
[<8006e6bc>] (generic_handle_irq+0x0/0x38) from [<803fabb0>]
(ipu_irq_handle+0x94/0xc4)
 r4:00000110 r3:00000007
[<803fab1c>] (ipu_irq_handle+0x0/0xc4) from [<803facf4>]
(ipu_irq_handler+0x68/0xbc)
[<803fac8c>] (ipu_irq_handler+0x0/0xbc) from [<8006e6e4>]
(generic_handle_irq+0x28/0x38)
 r6:9f854000 r5:806cfe08 r4:0000001b
[<8006e6bc>] (generic_handle_irq+0x0/0x38) from [<8000ede8>]
(handle_IRQ+0x54/0xb4)
 r4:806db178 r3:000001b0
[<8000ed94>] (handle_IRQ+0x0/0xb4) from [<800085ac>] (tzic_handle_irq+0x78/0xa8)
 r8:9f855cd0 r7:00000001 r6:00000000 r5:8070dca0 r4:00000000
r3:00000010
[<80008534>] (tzic_handle_irq+0x0/0xa8) from [<8000e080>] (__irq_svc+0x40/0x54)
Exception stack(0x9f855cd0 to 0x9f855d18)
5cc0:                                     9fa69650 60000113 00050005 00000000
5ce0: 9fa69600 9fa701c0 9fa69650 00000000 00000127 9fa69630 60000113 9f855d24
5d00: 00000000 9f855d18 80070418 80515b44 60000113 ffffffff
[<80515b0c>] (_raw_spin_unlock_irqrestore+0x0/0x3c) from [<80070418>]
(__setup_irq+0x1cc/0x414)
[<8007024c>] (__setup_irq+0x0/0x414) from [<80070720>]
(request_threaded_irq+0xc0/0x158)
[<80070660>] (request_threaded_irq+0x0/0x158) from [<80072690>]
(devm_request_threaded_irq+0x5c/0x90)
[<80072634>] (devm_request_threaded_irq+0x0/0x90) from [<803fe038>]
(ipu_drm_probe+0x118/0x1ec)
[<803fdf20>] (ipu_drm_probe+0x0/0x1ec) from [<802d8e38>]
(platform_drv_probe+0x20/0x24)
 r7:00000000 r6:9fa64410 r5:807057a4 r4:8075c080
[<802d8e18>] (platform_drv_probe+0x0/0x24) from [<802d79b0>]
(driver_probe_device+0x78/0x1fc)
[<802d7938>] (driver_probe_device+0x0/0x1fc) from [<802d7bc8>]
(__driver_attach+0x94/0x98)
 r8:000000a4 r7:00000000 r6:9fa64444 r5:807057a4 r4:9fa64410
r3:00000000
[<802d7b34>] (__driver_attach+0x0/0x98) from [<802d6128>]
(bus_for_each_dev+0x58/0x84)
 r6:00000000 r5:802d7b34 r4:807057a4 r3:802d7b34
[<802d60d0>] (bus_for_each_dev+0x0/0x84) from [<802d7558>]
(driver_attach+0x20/0x28)
 r6:9fa65980 r5:806f3e10 r4:807057a4
[<802d7538>] (driver_attach+0x0/0x28) from [<802d7174>]
(bus_add_driver+0x178/0x248)
[<802d6ffc>] (bus_add_driver+0x0/0x248) from [<802d8110>]
(driver_register+0x80/0x14c)
 r8:000000a4 r7:8070d480 r6:00000000 r5:00000006 r4:807057a4
[<802d8090>] (driver_register+0x0/0x14c) from [<802d905c>]
(platform_driver_register+0x4c/0x60)
[<802d9010>] (platform_driver_register+0x0/0x60) from [<806b2618>]
(ipu_drm_driver_init+0x14/0x1c)
[<806b2604>] (ipu_drm_driver_init+0x0/0x1c) from [<800086b8>]
(do_one_initcall+0x40/0x184)
[<80008678>] (do_one_initcall+0x0/0x184) from [<80692978>]
(kernel_init_freeable+0x104/0x1cc)
[<80692874>] (kernel_init_freeable+0x0/0x1cc) from [<8050b0cc>]
(kernel_init+0x10/0xec)
[<8050b0bc>] (kernel_init+0x0/0xec) from [<8000e598>] (ret_from_fork+0x14/0x3c)
 r4:00000000 r3:ffffffff
Code: e89da800 e1a0c00d e92dd800 e24cb004 (e590300c)
---[ end trace d806e2933ab4f47d ]---
Kernel panic - not syncing: Fatal exception in interrupt

Any suggestions as to how to make mx51babbage display something out of
the DVI port?

Thanks,

Fabio Estevam

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Fabio Estevam]

On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> wrote:
> Hi Sascha,
>
> On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer <s.hauer@pengutronix.de> wrote:
>> The babbage board has a DVI-I output which allows to output analog
>> and digital signals simultaneously. This patch adds support for it
>> to the devicetree. The DDC signals are not wired up on the board, so
>> DRM will fall back on default VESA modes.
>>
>> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
>
> I am running linux-next 20130108, which has this patch applied and I
> get the following on my mx51babbage:

Ok, good news. I see a nice penguin on my monitor now.

Discussed with Marek and he proposed a quick workaround:

--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq, void *dev_id)
 {
        struct ipu_crtc *ipu_crtc = dev_id;

+       if (!ipu_crtc->imx_crtc) {
+               pr_err("Spurious IPU IRQ\n");
+               return IRQ_HANDLED;
+       }
+
        imx_drm_handle_vblank(ipu_crtc->imx_crtc);

        if (ipu_crtc->newfb) {

It seems that this issue happened because bootloader leaves the IPU turned on.

Thanks,

Fabio Estevam

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Marek Vasut]

Dear Fabio Estevam,

> On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > Hi Sascha,
> > 
> > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer <s.hauer@pengutronix.de> 
wrote:
> >> The babbage board has a DVI-I output which allows to output analog
> >> and digital signals simultaneously. This patch adds support for it
> >> to the devicetree. The DDC signals are not wired up on the board, so
> >> DRM will fall back on default VESA modes.
> >> 
> >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > 
> > I am running linux-next 20130108, which has this patch applied and I
> 
> > get the following on my mx51babbage:
> Ok, good news. I see a nice penguin on my monitor now.
> 
> Discussed with Marek and he proposed a quick workaround:
> 
> --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq, void
> *dev_id) {
>         struct ipu_crtc *ipu_crtc = dev_id;
> 
> +       if (!ipu_crtc->imx_crtc) {
> +               pr_err("Spurious IPU IRQ\n");
> +               return IRQ_HANDLED;
> +       }
> +
>         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> 
>         if (ipu_crtc->newfb) {
> 
> It seems that this issue happened because bootloader leaves the IPU turned
> on.

To elaborate more on this stuff:

491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
492                         IPU_IRQ_EOF);
493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, 
ipu_irq_handler, 0,
494                         "imx_drm", ipu_crtc);
495         if (ret < 0) {
496                 dev_err(ipu_crtc->dev, "irq request failed with %d.\n", 
ret);
497                 goto err_out;
498         }
499 
500         disable_irq(ipu_crtc->irq);

This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If the IPU is on, 
it produces an interrupt before the driver is fully set up. I didn't produce a 
patch yet, I think I might offload this to someone else. Volunteers?

Best regards,
Marek Vasut

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Philipp Zabel]

Am Dienstag, den 08.01.2013, 18:09 +0100 schrieb Marek Vasut:
> Dear Fabio Estevam,
> 
> > On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > > Hi Sascha,
> > > 
> > > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer <s.hauer@pengutronix.de> 
> wrote:
> > >> The babbage board has a DVI-I output which allows to output analog
> > >> and digital signals simultaneously. This patch adds support for it
> > >> to the devicetree. The DDC signals are not wired up on the board, so
> > >> DRM will fall back on default VESA modes.
> > >> 
> > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > 
> > > I am running linux-next 20130108, which has this patch applied and I
> > 
> > > get the following on my mx51babbage:
> > Ok, good news. I see a nice penguin on my monitor now.
> > 
> > Discussed with Marek and he proposed a quick workaround:
> > 
> > --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> > @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq, void
> > *dev_id) {
> >         struct ipu_crtc *ipu_crtc = dev_id;
> > 
> > +       if (!ipu_crtc->imx_crtc) {
> > +               pr_err("Spurious IPU IRQ\n");
> > +               return IRQ_HANDLED;
> > +       }
> > +
> >         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> > 
> >         if (ipu_crtc->newfb) {
> > 
> > It seems that this issue happened because bootloader leaves the IPU turned
> > on.
> 
> To elaborate more on this stuff:
> 
> 491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
> 492                         IPU_IRQ_EOF);
> 493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, 
> ipu_irq_handler, 0,
> 494                         "imx_drm", ipu_crtc);
> 495         if (ret < 0) {
> 496                 dev_err(ipu_crtc->dev, "irq request failed with %d.\n", 
> ret);
> 497                 goto err_out;
> 498         }
> 499 
> 500         disable_irq(ipu_crtc->irq);
> 
> This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If the IPU is on, 
> it produces an interrupt before the driver is fully set up. I didn't produce a 
> patch yet, I think I might offload this to someone else. Volunteers?

Reordering the ipu_get_resources and imx_drm_add_crtc calls should resolve this:

From: Philipp Zabel <p.zabel@pengutronix.de>
Subject: [PATCH] staging: imx/drm: add crtc before registering interrupt
 handler

If the bootloader already enabled the display, the interrupt handler
will be called as soon as it is registered. If the CRTC is not already
added at this time, the call to imx_drm_handle_vblank will result in
a NULL pointer dereference.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/staging/imx-drm/ipuv3-crtc.c |   21 ++++++++-------------
 1 file changed, 8 insertions(+), 13 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index 4b3a019..3d04abb 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -506,28 +506,23 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
 {
 	int ret;
 
-	ret = ipu_get_resources(ipu_crtc, pdata);
-	if (ret) {
-		dev_err(ipu_crtc->dev, "getting resources failed with %d.\n",
-				ret);
-		return ret;
-	}
-
 	ret = imx_drm_add_crtc(&ipu_crtc->base,
 			&ipu_crtc->imx_crtc,
 			&ipu_crtc_helper_funcs, THIS_MODULE,
 			ipu_crtc->dev->parent->of_node, pdata->di);
 	if (ret) {
 		dev_err(ipu_crtc->dev, "adding crtc failed with %d.\n", ret);
-		goto err_put_resources;
+		return ret;
 	}
 
-	return 0;
-
-err_put_resources:
-	ipu_put_resources(ipu_crtc);
+	ret = ipu_get_resources(ipu_crtc, pdata);
+	if (ret) {
+		dev_err(ipu_crtc->dev, "getting resources failed with %d.\n",
+				ret);
+		return ret;
+	}
 
-	return ret;
+	return 0;
 }
 
 static int ipu_drm_probe(struct platform_device *pdev)
-- 
1.7.10.4

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Marek Vasut]

Dear Philipp Zabel,

> Am Dienstag, den 08.01.2013, 18:09 +0100 schrieb Marek Vasut:
> > Dear Fabio Estevam,
> > 
> > > On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > > > Hi Sascha,
> > > > 
> > > > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer
> > > > <s.hauer@pengutronix.de>
> > 
> > wrote:
> > > >> The babbage board has a DVI-I output which allows to output analog
> > > >> and digital signals simultaneously. This patch adds support for it
> > > >> to the devicetree. The DDC signals are not wired up on the board, so
> > > >> DRM will fall back on default VESA modes.
> > > >> 
> > > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > 
> > > > I am running linux-next 20130108, which has this patch applied and I
> > > 
> > > > get the following on my mx51babbage:
> > > Ok, good news. I see a nice penguin on my monitor now.
> > > 
> > > Discussed with Marek and he proposed a quick workaround:
> > > 
> > > --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> > > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> > > @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq, void
> > > *dev_id) {
> > > 
> > >         struct ipu_crtc *ipu_crtc = dev_id;
> > > 
> > > +       if (!ipu_crtc->imx_crtc) {
> > > +               pr_err("Spurious IPU IRQ\n");
> > > +               return IRQ_HANDLED;
> > > +       }
> > > +
> > > 
> > >         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> > >         
> > >         if (ipu_crtc->newfb) {
> > > 
> > > It seems that this issue happened because bootloader leaves the IPU
> > > turned on.
> > 
> > To elaborate more on this stuff:
> > 
> > 491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
> > 492                         IPU_IRQ_EOF);
> > 493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq,
> > ipu_irq_handler, 0,
> > 494                         "imx_drm", ipu_crtc);
> > 495         if (ret < 0) {
> > 496                 dev_err(ipu_crtc->dev, "irq request failed with
> > %d.\n", ret);
> > 497                 goto err_out;
> > 498         }
> > 499
> > 500         disable_irq(ipu_crtc->irq);
> > 
> > This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If the IPU
> > is on, it produces an interrupt before the driver is fully set up. I
> > didn't produce a patch yet, I think I might offload this to someone
> > else. Volunteers?
> 
> Reordering the ipu_get_resources and imx_drm_add_crtc calls should resolve
> this:
> 
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Subject: [PATCH] staging: imx/drm: add crtc before registering interrupt
>  handler
> 
> If the bootloader already enabled the display, the interrupt handler
> will be called as soon as it is registered. If the CRTC is not already
> added at this time, the call to imx_drm_handle_vblank will result in
> a NULL pointer dereference.

I ain't no IPU expert, but isn't adding the component before having it fully 
inited even worse?

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Philipp Zabel]

Hi Marek,

Am Dienstag, den 08.01.2013, 18:29 +0100 schrieb Marek Vasut:
> Dear Philipp Zabel,
> 
> > Am Dienstag, den 08.01.2013, 18:09 +0100 schrieb Marek Vasut:
> > > Dear Fabio Estevam,
> > > 
> > > > On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> wrote:
> > > > > Hi Sascha,
> > > > > 
> > > > > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer
> > > > > <s.hauer@pengutronix.de>
> > > 
> > > wrote:
> > > > >> The babbage board has a DVI-I output which allows to output analog
> > > > >> and digital signals simultaneously. This patch adds support for it
> > > > >> to the devicetree. The DDC signals are not wired up on the board, so
> > > > >> DRM will fall back on default VESA modes.
> > > > >> 
> > > > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > 
> > > > > I am running linux-next 20130108, which has this patch applied and I
> > > > 
> > > > > get the following on my mx51babbage:
> > > > Ok, good news. I see a nice penguin on my monitor now.
> > > > 
> > > > Discussed with Marek and he proposed a quick workaround:
> > > > 
> > > > --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq, void
> > > > *dev_id) {
> > > > 
> > > >         struct ipu_crtc *ipu_crtc = dev_id;
> > > > 
> > > > +       if (!ipu_crtc->imx_crtc) {
> > > > +               pr_err("Spurious IPU IRQ\n");
> > > > +               return IRQ_HANDLED;
> > > > +       }
> > > > +
> > > > 
> > > >         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> > > >         
> > > >         if (ipu_crtc->newfb) {
> > > > 
> > > > It seems that this issue happened because bootloader leaves the IPU
> > > > turned on.
> > > 
> > > To elaborate more on this stuff:
> > > 
> > > 491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
> > > 492                         IPU_IRQ_EOF);
> > > 493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq,
> > > ipu_irq_handler, 0,
> > > 494                         "imx_drm", ipu_crtc);
> > > 495         if (ret < 0) {
> > > 496                 dev_err(ipu_crtc->dev, "irq request failed with
> > > %d.\n", ret);
> > > 497                 goto err_out;
> > > 498         }
> > > 499
> > > 500         disable_irq(ipu_crtc->irq);
> > > 
> > > This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If the IPU
> > > is on, it produces an interrupt before the driver is fully set up. I
> > > didn't produce a patch yet, I think I might offload this to someone
> > > else. Volunteers?
> > 
> > Reordering the ipu_get_resources and imx_drm_add_crtc calls should resolve
> > this:
> > 
> > From: Philipp Zabel <p.zabel@pengutronix.de>
> > Subject: [PATCH] staging: imx/drm: add crtc before registering interrupt
> >  handler
> > 
> > If the bootloader already enabled the display, the interrupt handler
> > will be called as soon as it is registered. If the CRTC is not already
> > added at this time, the call to imx_drm_handle_vblank will result in
> > a NULL pointer dereference.
> 
> I ain't no IPU expert, but isn't adding the component before having it fully 
> inited even worse?

Good point, how about just moving the irq request out of
ipu_get_resources into ipu_crtc_init, after adding the crtc:

From: Philipp Zabel <p.zabel@pengutronix.de>
Subject: [PATCH] staging: imx/drm: request irq only after adding the crtc

If the bootloader already enabled the display, the interrupt handler
will be called as soon as it is registered. If the CRTC is not already
added at this time, the call to imx_drm_handle_vblank will result in
a NULL pointer dereference.

Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>
---
 drivers/staging/imx-drm/ipuv3-crtc.c |   23 ++++++++++++-----------
 1 file changed, 12 insertions(+), 11 deletions(-)

diff --git a/drivers/staging/imx-drm/ipuv3-crtc.c b/drivers/staging/imx-drm/ipuv3-crtc.c
index 4b3a019..b028b0d 100644
--- a/drivers/staging/imx-drm/ipuv3-crtc.c
+++ b/drivers/staging/imx-drm/ipuv3-crtc.c
@@ -483,17 +483,6 @@ static int ipu_get_resources(struct ipu_crtc *ipu_crtc,
 		goto err_out;
 	}
 
-	ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
-			IPU_IRQ_EOF);
-	ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, ipu_irq_handler, 0,
-			"imx_drm", ipu_crtc);
-	if (ret < 0) {
-		dev_err(ipu_crtc->dev, "irq request failed with %d.\n", ret);
-		goto err_out;
-	}
-
-	disable_irq(ipu_crtc->irq);
-
 	return 0;
 err_out:
 	ipu_put_resources(ipu_crtc);
@@ -504,6 +493,7 @@ err_out:
 static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
 		struct ipu_client_platformdata *pdata)
 {
+	struct ipu_soc *ipu = dev_get_drvdata(ipu_crtc->dev->parent);
 	int ret;
 
 	ret = ipu_get_resources(ipu_crtc, pdata);
@@ -522,6 +512,17 @@ static int ipu_crtc_init(struct ipu_crtc *ipu_crtc,
 		goto err_put_resources;
 	}
 
+	ipu_crtc->irq = ipu_idmac_channel_irq(ipu, ipu_crtc->ipu_ch,
+			IPU_IRQ_EOF);
+	ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq, ipu_irq_handler, 0,
+			"imx_drm", ipu_crtc);
+	if (ret < 0) {
+		dev_err(ipu_crtc->dev, "irq request failed with %d.\n", ret);
+		goto err_put_resources;
+	}
+
+	disable_irq(ipu_crtc->irq);
+
 	return 0;
 
 err_put_resources:
-- 
1.7.10.4

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Marek Vasut]

Dear Philipp Zabel,

> Hi Marek,
> 
> Am Dienstag, den 08.01.2013, 18:29 +0100 schrieb Marek Vasut:
> > Dear Philipp Zabel,
> > 
> > > Am Dienstag, den 08.01.2013, 18:09 +0100 schrieb Marek Vasut:
> > > > Dear Fabio Estevam,
> > > > 
> > > > > On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> 
wrote:
> > > > > > Hi Sascha,
> > > > > > 
> > > > > > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer
> > > > > > <s.hauer@pengutronix.de>
> > > > 
> > > > wrote:
> > > > > >> The babbage board has a DVI-I output which allows to output
> > > > > >> analog and digital signals simultaneously. This patch adds
> > > > > >> support for it to the devicetree. The DDC signals are not wired
> > > > > >> up on the board, so DRM will fall back on default VESA modes.
> > > > > >> 
> > > > > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > 
> > > > > > I am running linux-next 20130108, which has this patch applied
> > > > > > and I
> > > > > 
> > > > > > get the following on my mx51babbage:
> > > > > Ok, good news. I see a nice penguin on my monitor now.
> > > > > 
> > > > > Discussed with Marek and he proposed a quick workaround:
> > > > > 
> > > > > --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > > @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq,
> > > > > void *dev_id) {
> > > > > 
> > > > >         struct ipu_crtc *ipu_crtc = dev_id;
> > > > > 
> > > > > +       if (!ipu_crtc->imx_crtc) {
> > > > > +               pr_err("Spurious IPU IRQ\n");
> > > > > +               return IRQ_HANDLED;
> > > > > +       }
> > > > > +
> > > > > 
> > > > >         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> > > > >         
> > > > >         if (ipu_crtc->newfb) {
> > > > > 
> > > > > It seems that this issue happened because bootloader leaves the IPU
> > > > > turned on.
> > > > 
> > > > To elaborate more on this stuff:
> > > > 
> > > > 491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu,
> > > > ipu_crtc->ipu_ch, 492                         IPU_IRQ_EOF);
> > > > 493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq,
> > > > ipu_irq_handler, 0,
> > > > 494                         "imx_drm", ipu_crtc);
> > > > 495         if (ret < 0) {
> > > > 496                 dev_err(ipu_crtc->dev, "irq request failed with
> > > > %d.\n", ret);
> > > > 497                 goto err_out;
> > > > 498         }
> > > > 499
> > > > 500         disable_irq(ipu_crtc->irq);
> > > > 
> > > > This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If the
> > > > IPU is on, it produces an interrupt before the driver is fully set
> > > > up. I didn't produce a patch yet, I think I might offload this to
> > > > someone else. Volunteers?
> > > 
> > > Reordering the ipu_get_resources and imx_drm_add_crtc calls should
> > > resolve this:
> > > 
> > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > > Subject: [PATCH] staging: imx/drm: add crtc before registering
> > > interrupt
> > > 
> > >  handler
> > > 
> > > If the bootloader already enabled the display, the interrupt handler
> > > will be called as soon as it is registered. If the CRTC is not already
> > > added at this time, the call to imx_drm_handle_vblank will result in
> > > a NULL pointer dereference.
> > 
> > I ain't no IPU expert, but isn't adding the component before having it
> > fully inited even worse?
> 
> Good point, how about just moving the irq request out of
> ipu_get_resources into ipu_crtc_init, after adding the crtc:
> 
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Subject: [PATCH] staging: imx/drm: request irq only after adding the crtc
> 
> If the bootloader already enabled the display, the interrupt handler
> will be called as soon as it is registered. If the CRTC is not already
> added at this time, the call to imx_drm_handle_vblank will result in
> a NULL pointer dereference.

Can we not just flush (and make sure it's disabled) the IRQ before requesting it 
? That'd be probably the most sane way

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Philipp Zabel]

Am Mittwoch, den 09.01.2013, 10:26 +0100 schrieb Marek Vasut:
> Dear Philipp Zabel,
> 
> > Hi Marek,
> > 
> > Am Dienstag, den 08.01.2013, 18:29 +0100 schrieb Marek Vasut:
> > > Dear Philipp Zabel,
> > > 
> > > > Am Dienstag, den 08.01.2013, 18:09 +0100 schrieb Marek Vasut:
> > > > > Dear Fabio Estevam,
> > > > > 
> > > > > > On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam <festevam@gmail.com> 
> wrote:
> > > > > > > Hi Sascha,
> > > > > > > 
> > > > > > > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer
> > > > > > > <s.hauer@pengutronix.de>
> > > > > 
> > > > > wrote:
> > > > > > >> The babbage board has a DVI-I output which allows to output
> > > > > > >> analog and digital signals simultaneously. This patch adds
> > > > > > >> support for it to the devicetree. The DDC signals are not wired
> > > > > > >> up on the board, so DRM will fall back on default VESA modes.
> > > > > > >> 
> > > > > > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > 
> > > > > > > I am running linux-next 20130108, which has this patch applied
> > > > > > > and I
> > > > > > 
> > > > > > > get the following on my mx51babbage:
> > > > > > Ok, good news. I see a nice penguin on my monitor now.
> > > > > > 
> > > > > > Discussed with Marek and he proposed a quick workaround:
> > > > > > 
> > > > > > --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > > > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > > > @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int irq,
> > > > > > void *dev_id) {
> > > > > > 
> > > > > >         struct ipu_crtc *ipu_crtc = dev_id;
> > > > > > 
> > > > > > +       if (!ipu_crtc->imx_crtc) {
> > > > > > +               pr_err("Spurious IPU IRQ\n");
> > > > > > +               return IRQ_HANDLED;
> > > > > > +       }
> > > > > > +
> > > > > > 
> > > > > >         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> > > > > >         
> > > > > >         if (ipu_crtc->newfb) {
> > > > > > 
> > > > > > It seems that this issue happened because bootloader leaves the IPU
> > > > > > turned on.
> > > > > 
> > > > > To elaborate more on this stuff:
> > > > > 
> > > > > 491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu,
> > > > > ipu_crtc->ipu_ch, 492                         IPU_IRQ_EOF);
> > > > > 493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq,
> > > > > ipu_irq_handler, 0,
> > > > > 494                         "imx_drm", ipu_crtc);
> > > > > 495         if (ret < 0) {
> > > > > 496                 dev_err(ipu_crtc->dev, "irq request failed with
> > > > > %d.\n", ret);
> > > > > 497                 goto err_out;
> > > > > 498         }
> > > > > 499
> > > > > 500         disable_irq(ipu_crtc->irq);
> > > > > 
> > > > > This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If the
> > > > > IPU is on, it produces an interrupt before the driver is fully set
> > > > > up. I didn't produce a patch yet, I think I might offload this to
> > > > > someone else. Volunteers?
> > > > 
> > > > Reordering the ipu_get_resources and imx_drm_add_crtc calls should
> > > > resolve this:
> > > > 
> > > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > > > Subject: [PATCH] staging: imx/drm: add crtc before registering
> > > > interrupt
> > > > 
> > > >  handler
> > > > 
> > > > If the bootloader already enabled the display, the interrupt handler
> > > > will be called as soon as it is registered. If the CRTC is not already
> > > > added at this time, the call to imx_drm_handle_vblank will result in
> > > > a NULL pointer dereference.
> > > 
> > > I ain't no IPU expert, but isn't adding the component before having it
> > > fully inited even worse?
> > 
> > Good point, how about just moving the irq request out of
> > ipu_get_resources into ipu_crtc_init, after adding the crtc:
> > 
> > From: Philipp Zabel <p.zabel@pengutronix.de>
> > Subject: [PATCH] staging: imx/drm: request irq only after adding the crtc
> > 
> > If the bootloader already enabled the display, the interrupt handler
> > will be called as soon as it is registered. If the CRTC is not already
> > added at this time, the call to imx_drm_handle_vblank will result in
> > a NULL pointer dereference.
> 
> Can we not just flush (and make sure it's disabled) the IRQ before requesting it 
> ? That'd be probably the most sane way

Probably, but that still would be no excuse for the interrupt handler to
be registered before it can actually handle interrupts.

regards
Philipp

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Marek Vasut]

Dear Philipp Zabel,

> Am Mittwoch, den 09.01.2013, 10:26 +0100 schrieb Marek Vasut:
> > Dear Philipp Zabel,
> > 
> > > Hi Marek,
> > > 
> > > Am Dienstag, den 08.01.2013, 18:29 +0100 schrieb Marek Vasut:
> > > > Dear Philipp Zabel,
> > > > 
> > > > > Am Dienstag, den 08.01.2013, 18:09 +0100 schrieb Marek Vasut:
> > > > > > Dear Fabio Estevam,
> > > > > > 
> > > > > > > On Tue, Jan 8, 2013 at 2:41 PM, Fabio Estevam
> > > > > > > <festevam@gmail.com>
> > 
> > wrote:
> > > > > > > > Hi Sascha,
> > > > > > > > 
> > > > > > > > On Mon, Nov 12, 2012 at 1:23 PM, Sascha Hauer
> > > > > > > > <s.hauer@pengutronix.de>
> > > > > > 
> > > > > > wrote:
> > > > > > > >> The babbage board has a DVI-I output which allows to output
> > > > > > > >> analog and digital signals simultaneously. This patch adds
> > > > > > > >> support for it to the devicetree. The DDC signals are not
> > > > > > > >> wired up on the board, so DRM will fall back on default
> > > > > > > >> VESA modes.
> > > > > > > >> 
> > > > > > > >> Signed-off-by: Sascha Hauer <s.hauer@pengutronix.de>
> > > > > > > > 
> > > > > > > > I am running linux-next 20130108, which has this patch
> > > > > > > > applied and I
> > > > > > > 
> > > > > > > > get the following on my mx51babbage:
> > > > > > > Ok, good news. I see a nice penguin on my monitor now.
> > > > > > > 
> > > > > > > Discussed with Marek and he proposed a quick workaround:
> > > > > > > 
> > > > > > > --- a/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > > > > +++ b/drivers/staging/imx-drm/ipuv3-crtc.c
> > > > > > > @@ -343,6 +343,11 @@ static irqreturn_t ipu_irq_handler(int
> > > > > > > irq, void *dev_id) {
> > > > > > > 
> > > > > > >         struct ipu_crtc *ipu_crtc = dev_id;
> > > > > > > 
> > > > > > > +       if (!ipu_crtc->imx_crtc) {
> > > > > > > +               pr_err("Spurious IPU IRQ\n");
> > > > > > > +               return IRQ_HANDLED;
> > > > > > > +       }
> > > > > > > +
> > > > > > > 
> > > > > > >         imx_drm_handle_vblank(ipu_crtc->imx_crtc);
> > > > > > >         
> > > > > > >         if (ipu_crtc->newfb) {
> > > > > > > 
> > > > > > > It seems that this issue happened because bootloader leaves the
> > > > > > > IPU turned on.
> > > > > > 
> > > > > > To elaborate more on this stuff:
> > > > > > 
> > > > > > 491         ipu_crtc->irq = ipu_idmac_channel_irq(ipu,
> > > > > > ipu_crtc->ipu_ch, 492                         IPU_IRQ_EOF);
> > > > > > 493         ret = devm_request_irq(ipu_crtc->dev, ipu_crtc->irq,
> > > > > > ipu_irq_handler, 0,
> > > > > > 494                         "imx_drm", ipu_crtc);
> > > > > > 495         if (ret < 0) {
> > > > > > 496                 dev_err(ipu_crtc->dev, "irq request failed
> > > > > > with %d.\n", ret);
> > > > > > 497                 goto err_out;
> > > > > > 498         }
> > > > > > 499
> > > > > > 500         disable_irq(ipu_crtc->irq);
> > > > > > 
> > > > > > This code in drivers/staging/imx-drm/ipuv3-crtc.c is broken. If
> > > > > > the IPU is on, it produces an interrupt before the driver is
> > > > > > fully set up. I didn't produce a patch yet, I think I might
> > > > > > offload this to someone else. Volunteers?
> > > > > 
> > > > > Reordering the ipu_get_resources and imx_drm_add_crtc calls should
> > > > > resolve this:
> > > > > 
> > > > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > > > > Subject: [PATCH] staging: imx/drm: add crtc before registering
> > > > > interrupt
> > > > > 
> > > > >  handler
> > > > > 
> > > > > If the bootloader already enabled the display, the interrupt
> > > > > handler will be called as soon as it is registered. If the CRTC is
> > > > > not already added at this time, the call to imx_drm_handle_vblank
> > > > > will result in a NULL pointer dereference.
> > > > 
> > > > I ain't no IPU expert, but isn't adding the component before having
> > > > it fully inited even worse?
> > > 
> > > Good point, how about just moving the irq request out of
> > > ipu_get_resources into ipu_crtc_init, after adding the crtc:
> > > 
> > > From: Philipp Zabel <p.zabel@pengutronix.de>
> > > Subject: [PATCH] staging: imx/drm: request irq only after adding the
> > > crtc
> > > 
> > > If the bootloader already enabled the display, the interrupt handler
> > > will be called as soon as it is registered. If the CRTC is not already
> > > added at this time, the call to imx_drm_handle_vblank will result in
> > > a NULL pointer dereference.
> > 
> > Can we not just flush (and make sure it's disabled) the IRQ before
> > requesting it ? That'd be probably the most sane way
> 
> Probably, but that still would be no excuse for the interrupt handler to
> be registered before it can actually handle interrupts.

Yep, fully agreed.

Ok, can you check if the IRQ can be somehow flushed/disabled and then apply your 
last patch (the one that pulls the IRQ registration past imx_drm_add_crtc() )? 
That'd sound to me like a reasonable solution, what do you say? Apparently 
imx_drm_add_crtc() doesn't use the IRQ, so it should be cool too.

[PATCH 7/7] ARM i.MX51 babbage: Add display support

[Fabio Estevam]

Hi Philipp,

On Tue, Jan 8, 2013 at 3:23 PM, Philipp Zabel <p.zabel@pengutronix.de> wrote:

> Reordering the ipu_get_resources and imx_drm_add_crtc calls should resolve this:
>
> From: Philipp Zabel <p.zabel@pengutronix.de>
> Subject: [PATCH] staging: imx/drm: add crtc before registering interrupt
>  handler
>
> If the bootloader already enabled the display, the interrupt handler
> will be called as soon as it is registered. If the CRTC is not already
> added at this time, the call to imx_drm_handle_vblank will result in
> a NULL pointer dereference.
>
> Signed-off-by: Philipp Zabel <p.zabel@pengutronix.de>

This fixes the issue for me, thanks:

Tested-by: Fabio Estevam <fabio.estevam@freescale.com>

[PATCH] i.MX IPU SoC support

[Shawn Guo]

On Mon, Nov 12, 2012 at 04:23:22PM +0100, Sascha Hauer wrote:
> This series adds the necessary i.MX SoC stuff to make the IPU support
> usable. Basically needed are the IPU devices in the devicetrees. This
> series also adds display support for the i.MX51 babbage which then is
> the first board for which the IPU driver works without out of tree
> stuff.
> 
> Shawn, I already sent the MIPI setup patch some time ago. From what
> I read I think we can agree on the approach on just setting the correct
> register values in the SoC code, right?
> 
For the series,

Acked-by: Shawn Guo <shawn.guo@linaro.org>