OMAP: DSS2: DSI: disable manager on framedone timeout

PATCH Superseded Archit Taneja 2 participants 4 messages Jun 17, 2010 Framebuffer layer

Share & tools

Archit Taneja

author

2010-06-17 08:30 UTC #0 lore raw

PATCH 1/1 OMAP: DSS2: DSI: disable manager on framedone timeout

In the case of a dsi framedone timeout, we should set the LCD_EN bit to 0 and reset the dsi tx fifo so that the next panel update call goes through cleanly.

With the new way of handling framedone interrupts, since everything is handled in irq context, the only reason a framedone timeout occurs is because of some hardware issue.

The reset of LCD_EN and flush of TX_FIFO won't interfere with a frame in progress.

Signed-off-by Archit Taneja <[email protected]>

---
 drivers/video/omap2/dss/dsi.c |    5 +++++
 1 files changed, 5 insertions(+), 0 deletions(-)

drivers/video/omap2/dss/dsi.c +5 -0

index a6e0f64..224ff97
@@ -2764,6 +2764,7 @@ static void dsi_te_timeout(unsigned long arg)
 static void dsi_handle_framedone(int error)
 {
 	const int channel = dsi.update_channel;
+	struct omap_dss_device *device = dsi.vc[channel].dssdev;
 
 	cancel_delayed_work(&dsi.framedone_timeout_work);

@@ -2774,6 +2775,10 @@ static void dsi_handle_framedone(int error)
 
 	dsi.bta_callback = NULL;
 
+	if (error == -ETIMEDOUT) {
+		device->manager->disable(device->manager);
+		dsi_reset_tx_fifo(channel);
+	}
 	if (dsi.te_enabled) {
 		/* enable LP_RX_TO again after the TE */
 		REG_FLD_MOD(DSI_TIMING2, 1, 15, 15); /* LP_RX_TO */

Signature · 1 line

1.6.3.3

Tomi Valkeinen

2010-06-17 08:52 UTC #1 lore raw

Hi,

Quoted 10 lines · ext Archit Taneja

In the case of a dsi framedone timeout, we should set the LCD_EN bit to 0 and reset the dsi tx fifo so that the next panel update call goes through cleanly.
With the new way of handling framedone interrupts, since everything is handled in irq context, the only reason a framedone timeout occurs is because of some hardware issue.
The reset of LCD_EN and flush of TX_FIFO won't interfere with a frame in progress.

Does this work? There is the errata: 1.29. DSI: Tx FIFO flush is not supported. I've actually removed the dsi_reset_tx_fifo() function in my work tree, as I though the only way to recover is to reset the whole DSI block.

Tomi

Taneja, Archit

author

2010-06-17 09:07 UTC #2 lore raw

Hi,

Quoted 21 lines

-----Original Message-----
From: Tomi Valkeinen [mailto:[email protected]]
Sent: Thursday, June 17, 2010 2:22 PM
To: Taneja, Archit
Cc: [email protected]
Subject: Re: [PATCH] OMAP: DSS2: DSI: disable manager on framedone timeout
Hi,
Quoted 10 lines · ext Archit Taneja
In the case of a dsi framedone timeout, we should set the LCD_EN bit to 0 and reset the dsi tx fifo so that the next panel update call goes through cleanly.
With the new way of handling framedone interrupts, since everything is handled in irq context, the only reason a framedone timeout occurs is because of some hardware issue.
The reset of LCD_EN and flush of TX_FIFO won't interfere with a frame in progress.

Quoted 7 lines

Does this work? There is the errata: 1.29. DSI: Tx FIFO flush is not supported. I've actually removed the dsi_reset_tx_fifo() function in my work tree, as I though the only way to recover is to reset the whole DSI block.
Tomi

The errata is there, but things still seem to be okay, the crucial thing is disabling LCD_EN, this will at least prepare DISPC for the next frame.

I think that if a framedone timeout occurs, it is DISPC which is at fault since it generates the framedone interrupt. It is quite likely that DSI is in a ok state.

I agree it is risky to flush DSI TX fifo since it is in the errata, but we should still disable LCD_EN here because no one else disables it.

Thanks,

Archit

Taneja, Archit

author

2010-06-17 09:58 UTC #3 lore raw

Quoted 48 lines

-----Original Message-----
From: [email protected] [mailto:linux-omap- [email protected]] On Behalf Of Taneja, Archit
Sent: Thursday, June 17, 2010 2:37 PM
To: Tomi Valkeinen
Cc: [email protected]
Subject: RE: [PATCH] OMAP: DSS2: DSI: disable manager on framedone timeout
Hi,
Quoted 6 lines
-----Original Message-----
From: Tomi Valkeinen [mailto:[email protected]]
Sent: Thursday, June 17, 2010 2:22 PM
To: Taneja, Archit
Cc: [email protected]
Subject: Re: [PATCH] OMAP: DSS2: DSI: disable manager on framedone
timeout
Quoted 15 lines
Hi,
Quoted 10 lines · ext Archit Taneja
In the case of a dsi framedone timeout, we should set the LCD_EN bit to 0 and reset the dsi tx fifo so that the next panel update call goes through cleanly.
With the new way of handling framedone interrupts, since everything is handled in irq context, the only reason a framedone timeout occurs is because of some hardware issue.
The reset of LCD_EN and flush of TX_FIFO won't interfere with a frame in progress.
Quoted 7 lines
Does this work? There is the errata: 1.29. DSI: Tx FIFO flush is not supported. I've actually removed the dsi_reset_tx_fifo() function in my work tree, as I though the only way to recover is to reset the whole DSI block.
Tomi
The errata is there, but things still seem to be okay, the crucial thing is disabling LCD_EN, this will at least prepare DISPC for the next frame.
I think that if a framedone timeout occurs, it is DISPC which is at fault since it generates the framedone interrupt. It is quite likely that DSI is in a ok state.

Quoted 7 lines

I agree it is risky to flush DSI TX fifo since it is in the errata, but we should still disable LCD_EN here because no one else disables it.
Thanks,
Archit
--

Hi,

Also, the TX FIFO wouldn't flush only by calling dsi_reset_tx_fifo(), the TRM says that after changing the FIFO size to zero, we still need to disable the VC by resetting VC_EN and then wait for VC_BUSY to become 0. This is probably why calling the function itself doesn't actually start the TX flush hardware logic.

But calling manager->disable is still essential. This is because after a framedone timeout, even if we reset the whole DSI engine block, LCD_EN could still be 1 (because of a DISPC failure); and in order to send another frame, LCD_EN should be 0 at the point of starting frame transfer.