> -----Original Message----- > From: Paul Mundt [mailto:let...@linux-sh.org] > Sent: Tuesday, November 30, 2010 12:05 PM > To: Ville Syrj?l? > Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux- > fb...@vger.kernel.org > Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl > > 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. [Hiremath, Vaibhav] As part of this thread, I was referring to couple of other platforms like Samsung S3C, etc... and neither they do have GO bit concept nor OMAP3 like issue (I was referring to). In case of S3C, the device is capable of giving interrupt for all VFP, vsync, VBP, etc... instances if timing cycle and I believe driver makes use of vsync under WAITFORVSYNC.
Thanks, Vaibhav -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
