"Hiremath, Vaibhav" <hvaibhav@xxxxxx> writes: >> -----Original Message----- >> From: Ville Syrjälä [mailto:ville.syrjala@xxxxxxxxx] >> Sent: Wednesday, November 24, 2010 10:01 PM >> To: Hiremath, Vaibhav >> Cc: Tomi Valkeinen; linux-omap@xxxxxxxxxxxxxxx >> 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:tomi.valkeinen@xxxxxxxxx] >> > > Sent: Wednesday, November 24, 2010 2:28 PM >> > > To: Hiremath, Vaibhav >> > > Cc: linux-omap@xxxxxxxxxxxxxxx >> > > 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. It is impossible to know what every user expects from it. A user may very well be using WAITFORVSYNC for timing purposes. If it then were to sometimes wait more than one vsync, it would be useless. > 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. The bug could still be argued to be in the application. > At least in case of OMAP, WAITFORVSYNC is useless in multiple > buffering use-case, application has to use WAITFORGO. Why does it take so long for the changes to reach the hardware? Once written to the registers, the values are latched at the next vsync, so the delay is higher up the stack. Is there any way it could be eliminated? This would not only fix the "bug" under discussion here, but also reduce the latency of page flipping. > 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. Naming is minor detail. Feel free to suggest a better one. -- Måns Rullgård mans@xxxxxxxxx -- 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
