-----Original Message-----
From: Paul Mundt [mailto:lethal@linux-sh.org]
Sent: Tuesday, November 30, 2010 12:10 PM
To: Ville Syrj?l?
Cc: Hiremath, Vaibhav; M?ns Rullg?rd; linux-omap@vger.kernel.org; linux-
fbdev@vger.kernel.org
Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl

On Tue, Nov 30, 2010 at 03:34:40PM +0900, Paul Mundt wrote:

quoted

On Fri, Nov 26, 2010 at 02:55:39PM +0200, Ville Syrj?l? wrote:

quoted

On Fri, Nov 26, 2010 at 05:38:11PM +0530, ext Hiremath, Vaibhav wrote:

quoted

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

quoted

quoted

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

quoted

quoted

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

quoted

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

quoted

of WAITFORVSYNC for manual update displays, then we can certainly look

at

quoted

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