> -----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: > > > > With this finding, in case of OMAP3 we have to use OMAPFB_WAITFORGO > > > > (breaking standard applications). > > > > > > Applications using the standard fbdev API won't work with manual > update > > > displays anyway. You need omapfb specific code to handle it so having > > > another small difference is not a big deal. > > > > > > In DirectFB the that's trivial since there's already a simple omap > > > gfxdriver where you could override the default flip functionality with > > > WAITFORGO based stuff. > > > > > > Or, as I said, you could add another standard ioctl and fix up > userspace > > > to use it where appropriate and if the kernel driver supports it. > > > > > It seems like the WAITFORGO semantics could be layered on top of drivers > > using deferred I/O pretty easily, but the question is whether this is > > something that userspace plans to make general use of or not. If the > only > > user of it in userspace code is OMAP-specific, then there's probably not > > a lot of point in moving it over to be generic, but if there are > > sufficient cases where userspace cares about this information > independent > > of WAITFORVSYNC for manual update displays, then we can certainly look > at > > moving it over for those cases. > > Also, WAITFORGO is a pretty abysmal name. It seems like what you want is > a WAITFORHWSYNC or something similar. [Hiremath, Vaibhav] Yes exactly, this name fits to the use-case and sounds ok to me. Tomi, Any comments? Thanks, Vaibhav -- 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
