> -----Original Message----- > From: Tomi Valkeinen [mailto:tomi.valkeinen@xxxxxxxxx] > Sent: Tuesday, November 30, 2010 7:02 PM > To: Hiremath, Vaibhav > Cc: Paul Mundt; Ville Syrj?l?; M?ns Rullg?rd; linux-omap@xxxxxxxxxxxxxxx; > linux-fbdev@xxxxxxxxxxxxxxx > Subject: RE: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl > > 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: > > > > On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote: > > > > > On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav > wrote: <snip> > > > a WAITFORHWSYNC or something similar. > > [Hiremath, Vaibhav] Yes exactly, this name fits to the use-case and > sounds ok to me. > > > > Tomi, > > Any comments? > > Ah, I seem to have been dropped out from this mail thread... > > Yes, WAITFORHWSYNC sounds much better. > > But there seems to be some misunderstanding of what this is about. > Deferred IO or manual update displays are not directly related to this. > This is about configuration registers, ie. address, size, etc. of the > framebuffer, not about the contents of the framebuffer. > > The reason why WAITFORGO was implemented is: > > 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. > > This is why the user may need to wait multiple vsyncs until the config > has really been written to the real HW registers, and WAITFORGO waits > for this. But if there has not been any config changes, WAITFORGO > doesn't wait at all. > > So WAITFORVSYNC and WAITFORGO do quite a different thing on OMAP. It is > true what Hiremath says, WAITFORVSYNC is difficult (impossible?) to use > properly on OMAP as if the config write happens between VFP and VSYNC, > the config is not actually yet in the real registers. > > But I'm still not comfortable with just moving WAITFORGO over > WAITFORVSYNC. At least we should then change WAITFORGO to always wait at > least for the next vsync, so that it wouldn't return immediately when > there are no pending changes. This would make WAITFORGO act like > WAITFORVSYNC in many cases, but not always. > > And to add to the confusion, there are multiple overlays on OMAP. They > may be currently shared by multiple users (for example omapfb and v4l2). > If the user uses WAITFORVSYNC, the call will return for every vsync, as > expected. If he uses WAITFORGO, the call will return in random number of > vsyncs from the user's point of view, because the other user may be > competing from the same resource. > > One could still argue that always using WAITFORGO is better, as there's > the problem with WAITFORVSYNC that Hiremath described. But then again, > WAITFORGO acts differently than what (I think) WAITFORVSYNC should do. > > So summa summarum, I didn't know how to solve this perfectly earlier, > and thus I implemented WAITFORGO, and I still don't know what would be > the perfect solution. > [Hiremath, Vaibhav] We did not had a closure on this topic, so summarizing our discussion here, Let's keep FBIO_WAITFORVSYNC (or OMAPFB_WAITFORVSYNC) ioctl as is, since as of now the way we understand this ioctl is, it should barely wait for next vsync. Change the OMAPFB_WAITFORGO to (standard) FBIO_WAITFORHWSYNC, currently this will be used in OMAP2/3 Fb-display driver. Thanks, Vaibhav > 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
