> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Taneja, Archit > Sent: Thursday, June 17, 2010 2:37 PM > To: Tomi Valkeinen > Cc: linux-omap@xxxxxxxxxxxxxxx > Subject: RE: [PATCH] OMAP: DSS2: DSI: disable manager on framedone timeout > > Hi, > > > -----Original Message----- > > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > > Sent: Thursday, June 17, 2010 2:22 PM > > To: Taneja, Archit > > Cc: linux-omap@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH] OMAP: DSS2: DSI: disable manager on framedone > timeout > > > > Hi, > > > > On Thu, 2010-06-17 at 10:29 +0200, ext Archit Taneja wrote: > > > 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 > > > 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 > -- 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. -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
