On Fri, 2009-03-13 at 10:10 +0100, ext Hiremath, Vaibhav wrote: > > Thanks, > Vaibhav Hiremath > > > -----Original Message----- > > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > > Sent: Friday, March 13, 2009 2:01 PM > > To: Hiremath, Vaibhav > > Cc: linux-omap@xxxxxxxxxxxxxxx > > Subject: RE: Suspend/Resume support with Omap2fb > > > > Hi, > > > > On Thu, 2009-03-12 at 19:26 +0100, ext Hiremath, Vaibhav wrote: > > > Hi, > > > > > > Finally I could able to find the root-cause, actually some of the > > previous observations miss-led me to dig into power management, > > suspend/resume path and clock structure. But after bit debugging and > > with the help of Sanjeev, we got the rid of it. > > > > > > The issue is with DSS2 library, inside function > > "dpi_display_suspend". It calls dispc_enable_lcd_out(0), but doesn't > > wait till the frame-done interrupt. And due to this I was getting > > some abrupt behavior in suspend/resume path. > > > Actually in the beginning I overlooked legacy frame-buffer driver, > > which handles this scenario perfectly. > > > > dispc_enable_lcd_out(0) waits for FRAMEDONE. Please use the latest > > DSS2 > > version from my git repository =). > > > [Hiremath, Vaibhav] Ohhh great, but I think yesterday only I pulled changes from your repository, and it was not there. > > Ok, but it's great that you merged the change. No, it's been there for quite a while... (weeks, months, I don't remember). Tomi -- 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
