Tomi Valkeinen wrote: 2010/11/30 Tomi Valkeinen <tomi.valkeinen@xxxxxxxxx>: > On Tue, 2010-11-30 at 12:29 +0530, ext Hiremath, Vaibhav wrote: >> > -----Original Message----- >> > From: Paul Mundt [mailto:lethal@xxxxxxxxxxxx] >> > Sent: Tuesday, November 30, 2010 12:10 PM >> > To: Ville Syrj?l? >> > Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@xxxxxxxxxxxxxxx; linux- >> > fbdev@xxxxxxxxxxxxxxx >> > Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl >> > >> > On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote: <snip> > OMAP has user writeable shadow registers and hidden real registers for > display controller. The shadow registers are latched to real registers > on VFP, but only if GO bit has been set. The GO bit is cleared by the HW > when latching has been done. > > If the GO bit is set, we cannot touch the shadow registers because we > don't know when the VFP will happen. That's why there's additionally a > SW cache for the config, so that we don't need to block when the GO bit > is up and the user wants to change the config. The driver "flushes" the > SW config to real registers in VSYNC interrupt handler. Does the driver flush the config to real register directly not a shadow register in VSYNC ISR? Does it mean display controller use the config flushed to the real register from the VSYNC ? I don't know OMAP in detail. But as I know other SoCs also work like it. Can Go bit is cleared by SW ? And does each overlay(FB) have its own Go bit ? If Go bit can be cleared by SW, how do you think about the following scheme ? When user wants to change the config, clear the Go bit although Go bit has been already set. And set the config shadow register and then re-set the go bit. It can make one Vsync delay for the first user who has wanted to change the config. But it can reduce the delay for the second user. And WAITFORGO can be removed. BTW as I know, Android also uses WAITFORVSYNC for multiple buffering. <snip> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html > BRs, -- To unsubscribe from this list: send the line "unsubscribe linux-fbdev" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
