Skip to contentSkip to conversation

ARM: dts: imx6sx: Fix LCDIF interrupt type

PATCH New Marek Vasut 4 participants 6 messages Oct 2, 2016 – Oct 23, 2016

Subsystems (2)
Device tree bindings Arm i.MX and Layerscape
lore
Share & tools
lore

Marek Vasut

author
#0 lore raw

PATCH 1/1 ARM: dts: imx6sx: Fix LCDIF interrupt type

The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts.

Signed-off-by Marek Vasut <[email protected]>
Cc Lucas Stach <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Shawn Guo <[email protected]>
---
 arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx6sx.dtsi +2 -2
index 1a473e8..9526c38 100644
@@ -1143,7 +1143,7 @@
 				lcdif1: lcdif at 02220000 {
 					compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 					reg = <0x02220000 0x4000>;
-					interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
 					clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
 						 <&clks IMX6SX_CLK_LCDIF_APB>,
 						 <&clks IMX6SX_CLK_DISPLAY_AXI>;

@@ -1154,7 +1154,7 @@
 				lcdif2: lcdif at 02224000 {
 					compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 					reg = <0x02224000 0x4000>;
-					interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
 					clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
 						 <&clks IMX6SX_CLK_LCDIF_APB>,
 						 <&clks IMX6SX_CLK_DISPLAY_AXI>;
Signature · 1 line
2.9.3
reviewer
#1 lore raw

PATCH 1/1 ARM: dts: imx6sx: Fix LCDIF interrupt type

Hi Marek,

Quoted 21 lines · Marek Vasut

The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts.

Signed-off-by Marek Vasut <[email protected]>
Cc Lucas Stach <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Shawn Guo <[email protected]>
---
 arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx6sx.dtsi +0 -0
index 1a473e8..9526c38 100644

arch/arm/boot/dts/imx6sx.dtsi line 1146

Quoted 5 lines
arch/arm/boot/dts/imx6sx.dtsi +1 -1
@@ -1143,7 +1143,7 @@
                                lcdif1: lcdif at 02220000 {
                                        compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
                                        reg = <0x02220000 0x4000>;
-                                       interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+                                       interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;

What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?

author
#2 lore raw

PATCH 1/1 ARM: dts: imx6sx: Fix LCDIF interrupt type

Quoted 1 line · Fabio Estevam

Hi Marek,

Hi!

Quoted 17 lines · Marek Vasut
Quoted 16 lines

The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts.

Signed-off-by Marek Vasut <[email protected]>
Cc Lucas Stach <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Shawn Guo <[email protected]>
---
 arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
Quoted 12 lines

arch/arm/boot/dts/imx6sx.dtsi line 1146

Quoted 10 lines
arch/arm/boot/dts/imx6sx.dtsi +1 -1
index 1a473e8..9526c38 100644
@@ -1143,7 +1143,7 @@
                                lcdif1: lcdif at 02220000 {
                                        compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
                                        reg = <0x02220000 0x4000>;
-                                       interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+                                       interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;

What about mx6ul and mx6sl.dtsi? Shouldn't they be also updated?

Probably, but I don't have the hardware to test MXSFB DRM/KMS driver on those. I can mail you the necessary patches if you want to try it out, the latest version is not in the ML yet as there is some DRM infrastructure work going on.

Signature · 2 lines
Best regards,
Marek Vasut
#3 lore raw

PATCH 1/1 ARM: dts: imx6sx: Fix LCDIF interrupt type

In reply to Marek Vasut

Am Sonntag, den 02.10.2016, 18:44 +0200 schrieb Marek Vasut:

Quoted 8 lines

The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts.

If there is no way to ack the IRQ how is the line going low again? Some hardware state machine?

Quoted 30 lines
Signed-off-by Marek Vasut <[email protected]>
Cc Lucas Stach <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Shawn Guo <[email protected]>
---
 arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx6sx.dtsi +2 -2
index 1a473e8..9526c38 100644
@@ -1143,7 +1143,7 @@
 				lcdif1: lcdif at 02220000 {
 					compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 					reg = <0x02220000 0x4000>;
-					interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
 					clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
 						 <&clks IMX6SX_CLK_LCDIF_APB>,
 						 <&clks IMX6SX_CLK_DISPLAY_AXI>;

@@ -1154,7 +1154,7 @@
 				lcdif2: lcdif at 02224000 {
 					compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 					reg = <0x02224000 0x4000>;
-					interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
 					clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
 						 <&clks IMX6SX_CLK_LCDIF_APB>,
 						 <&clks IMX6SX_CLK_DISPLAY_AXI>;
author
#4 lore raw

PATCH 1/1 ARM: dts: imx6sx: Fix LCDIF interrupt type

Quoted 11 lines · Lucas Stach

Am Sonntag, den 02.10.2016, 18:44 +0200 schrieb Marek Vasut:

Quoted 8 lines

The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts.

If there is no way to ack the IRQ how is the line going low again? Some hardware state machine?

My understanding is that it goes down at the end of VBLANK period.

Quoted 32 lines
Quoted 30 lines
Signed-off-by Marek Vasut <[email protected]>
Cc Lucas Stach <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Shawn Guo <[email protected]>
---
 arch/arm/boot/dts/imx6sx.dtsi | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
arch/arm/boot/dts/imx6sx.dtsi +2 -2
index 1a473e8..9526c38 100644
@@ -1143,7 +1143,7 @@
 				lcdif1: lcdif at 02220000 {
 					compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 					reg = <0x02220000 0x4000>;
-					interrupts = <GIC_SPI 5 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 5 IRQ_TYPE_EDGE_RISING>;
 					clocks = <&clks IMX6SX_CLK_LCDIF1_PIX>,
 						 <&clks IMX6SX_CLK_LCDIF_APB>,
 						 <&clks IMX6SX_CLK_DISPLAY_AXI>;

@@ -1154,7 +1154,7 @@
 				lcdif2: lcdif at 02224000 {
 					compatible = "fsl,imx6sx-lcdif", "fsl,imx28-lcdif";
 					reg = <0x02224000 0x4000>;
-					interrupts = <GIC_SPI 6 IRQ_TYPE_LEVEL_HIGH>;
+					interrupts = <GIC_SPI 6 IRQ_TYPE_EDGE_RISING>;
 					clocks = <&clks IMX6SX_CLK_LCDIF2_PIX>,
 						 <&clks IMX6SX_CLK_LCDIF_APB>,
 						 <&clks IMX6SX_CLK_DISPLAY_AXI>;
Signature · 2 lines
Best regards,
Marek Vasut
Applied
#5 lore raw

PATCH 1/1 ARM: dts: imx6sx: Fix LCDIF interrupt type

In reply to Marek Vasut
Quoted 8 lines · Marek Vasut

The LCDIF interrupt should be triggered by the rising edge of the IRQ line because we only want the interrupt to trigger once per each frame. It seems the LCDIF IRQ line cannot be explicitly de-asserted by software, so the previous behavior before this patch, where the interrupt was triggered by level-high status of the IRQ line, caused the interrupt to fire again immediatelly after it was handled, which caused the system to lock up due to the high rate of interrupts.

Quoted 4 lines
Signed-off-by Marek Vasut <[email protected]>
Cc Lucas Stach <[email protected]>
Cc Fabio Estevam <[email protected]>
Cc Shawn Guo <[email protected]>

Applied, thanks.