> -----Original Message-----
> From: Ville Syrjälä [mailto:[email protected]]
> Sent: Wednesday, November 24, 2010 10:01 PM
> To: Hiremath, Vaibhav
> Cc: Tomi Valkeinen; [email protected]
> Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
>
> On Wed, Nov 24, 2010 at 03:39:44PM +0530, ext Hiremath, Vaibhav wrote:
> >
> > > -----Original Message-----
> > > From: Tomi Valkeinen [mailto:[email protected]]
> > > Sent: Wednesday, November 24, 2010 2:28 PM
> > > To: Hiremath, Vaibhav
> > > Cc: [email protected]
> > > Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl
> > >
> > > On Tue, 2010-11-23 at 23:46 +0530, ext Hiremath, Vaibhav wrote:
> > > > Hi,
<snip>
> >
> > > Changing it to WAITFORGO would alter the behaviour. Sometimes it would
> > > not wait at all, sometimes it could wait for multiple vsyncs.
> > [Hiremath, Vaibhav] I am quite not sure, whether it makes sense from
> application point of view to wait for vsync if config is not changed. What
> could be the use-case for such requirement, where application won't change
> anything but still would like to wait on vsync?
> >
> > And as far as wait on multiple vsync is concerned, it does make sense to
> coat "WAITFORVSYNC ioctl makes sure that your change got applied to HW".
> >
> > I am not aware of other architectures, but I believe this is something
> OMAP specific stuff. And for other platforms, WAITFORVSYNC means changes
> applied to HW (why does apps care about whether it is vsync or anything
> else?).
>
> WAITFORVSYNC waits for the next vsync (or actually vblank in many
> cases).
[Hiremath, Vaibhav] Please note that this doesn't include VFP (vertical front
porch), since you are going to get VSYNC only after VFP.
> That's it. I don't see any point in trying to shoehorn
> other functionality into it.
>
> If you want to standardise WAITFORGO type of stuff then just add
> another standard ioctl for it.
>
[Hiremath, Vaibhav] I still believe we should not only look at the name of
IOCTL (WAITFORVSYNC) and define what it should do, it may change based on your
platform/HW to get the desired functionality out of it.
I am putting fbdev mailing list in CC to get comments from other folks on what
is expected from WAITFORVSYNC, especially architectures like
- s3c-fb.c
- ps3fb.c
- atyfb_base.c
- matroxfb_crtc2.c
- sh_mobile_lcdcfb.c
Please refer the wiki page which explains the OMAP DSS issue -
http://processors.wiki.ti.com/index.php/OMAP35x_Linux_-_DSS_FAQ
I would still argue on,
In OMAP there is chance of miss-match between user application and Display HW
if user uses FBIO_WAITFORVSYNC ioctl in multi-buffer use-case.
while (1) {
Update/Create the next buffer
FBIO_PAN
FBIO_WAITFORVSYNC //assuming HW-SW stay in sync (which is not)
}
There is definitely an issue with above use-case which has been un-doubtfully
conformed now.
At least in case of OMAP, WAITFORVSYNC is useless in multiple buffering
use-case, application has to use WAITFORGO.
As far as WAITFORGO is concerned, I think GO bit concept is something OMAP
notion/term and doesn't make sense to standardize it. Atleast I am not aware of
any other architecture having GO bit.
Thanks,
Vaibhav
> --
> Ville Syrjälä
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
