> -----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. 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 majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
