| Message ID | 20161002164435.5812-1-marex@denx.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
Hi Marek, On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote: > 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 <marex@denx.de> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Fabio Estevam <fabio.estevam@nxp.com> > Cc: Shawn Guo <shawnguo@kernel.org> > --- > arch/arm/boot/dts/imx6sx.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi > index 1a473e8..9526c38 100644 > --- a/arch/arm/boot/dts/imx6sx.dtsi > +++ b/arch/arm/boot/dts/imx6sx.dtsi > @@ -1143,7 +1143,7 @@ > lcdif1: lcdif@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?
On 10/02/2016 07:43 PM, Fabio Estevam wrote: > Hi Marek, Hi! > On Sun, Oct 2, 2016 at 1:44 PM, Marek Vasut <marex@denx.de> wrote: >> 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 <marex@denx.de> >> Cc: Lucas Stach <l.stach@pengutronix.de> >> Cc: Fabio Estevam <fabio.estevam@nxp.com> >> Cc: Shawn Guo <shawnguo@kernel.org> >> --- >> arch/arm/boot/dts/imx6sx.dtsi | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi >> index 1a473e8..9526c38 100644 >> --- a/arch/arm/boot/dts/imx6sx.dtsi >> +++ b/arch/arm/boot/dts/imx6sx.dtsi >> @@ -1143,7 +1143,7 @@ >> lcdif1: lcdif@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.
Am Sonntag, den 02.10.2016, 18:44 +0200 schrieb 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. > If there is no way to ack the IRQ how is the line going low again? Some hardware state machine? > Signed-off-by: Marek Vasut <marex@denx.de> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Fabio Estevam <fabio.estevam@nxp.com> > Cc: Shawn Guo <shawnguo@kernel.org> > --- > arch/arm/boot/dts/imx6sx.dtsi | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi > index 1a473e8..9526c38 100644 > --- a/arch/arm/boot/dts/imx6sx.dtsi > +++ b/arch/arm/boot/dts/imx6sx.dtsi > @@ -1143,7 +1143,7 @@ > lcdif1: lcdif@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@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>;
On 10/10/2016 03:35 PM, Lucas Stach wrote: > Am Sonntag, den 02.10.2016, 18:44 +0200 schrieb 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. >> > 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. >> Signed-off-by: Marek Vasut <marex@denx.de> >> Cc: Lucas Stach <l.stach@pengutronix.de> >> Cc: Fabio Estevam <fabio.estevam@nxp.com> >> Cc: Shawn Guo <shawnguo@kernel.org> >> --- >> arch/arm/boot/dts/imx6sx.dtsi | 4 ++-- >> 1 file changed, 2 insertions(+), 2 deletions(-) >> >> diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi >> index 1a473e8..9526c38 100644 >> --- a/arch/arm/boot/dts/imx6sx.dtsi >> +++ b/arch/arm/boot/dts/imx6sx.dtsi >> @@ -1143,7 +1143,7 @@ >> lcdif1: lcdif@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@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>; > >
On Sun, Oct 02, 2016 at 06:44:35PM +0200, Marek Vasut wrote: > 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 <marex@denx.de> > Cc: Lucas Stach <l.stach@pengutronix.de> > Cc: Fabio Estevam <fabio.estevam@nxp.com> > Cc: Shawn Guo <shawnguo@kernel.org> Applied, thanks.
diff --git a/arch/arm/boot/dts/imx6sx.dtsi b/arch/arm/boot/dts/imx6sx.dtsi index 1a473e8..9526c38 100644 --- a/arch/arm/boot/dts/imx6sx.dtsi +++ b/arch/arm/boot/dts/imx6sx.dtsi @@ -1143,7 +1143,7 @@ lcdif1: lcdif@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@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>;
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 <marex@denx.de> Cc: Lucas Stach <l.stach@pengutronix.de> Cc: Fabio Estevam <fabio.estevam@nxp.com> Cc: Shawn Guo <shawnguo@kernel.org> --- arch/arm/boot/dts/imx6sx.dtsi | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)