> -----Original Message----- > From: linux-omap-owner@xxxxxxxxxxxxxxx [mailto:linux-omap- > owner@xxxxxxxxxxxxxxx] On Behalf Of Måns Rullgård > Sent: Friday, November 26, 2010 2:09 PM > To: linux-omap@xxxxxxxxxxxxxxx > Subject: Re: OMAP:DSS: possible bug in WAITFOR_VSYNC ioctl > > "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> > >> > <snip...> > >> > >> 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. > [Hiremath, Vaibhav] I completely understand and agree with your statement here, but I think the finding and recommendation which I am talking about does address this. Let's consider 2 Options/use-cases - 1) Application expecting correct number of VSYNC interrupts - Here application wants to use WAITFORVSYNC ioctl to get correct number of VSYNC interrupt and do some operation (not related to buffer data or no Fbdev config change). Then WAITFORGO will work exactly same as WAITFORVSYNC. Let me state one more time "WAITFORGO makes sure that the configuration change gets applied to actual HW". If application is changing some configuration of HW, does it makes sense to return without making sure that whether it has been consumed by HW or not. 2) Application does update the buffer and synchronizes with HW on WAIFORVSYNC - As I mentioned this is un-doubtfully conformed that it has valid bug where there is chance of software going out of sync with actual HW. > > 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. > [Hiremath, Vaibhav] No, you can not. Please refer to the wiki page (http://processors.wiki.ti.com/index.php/OMAP35x_Linux_-_DSS_FAQ) which explains OMAP HW issue I am talking about. Actually with the same context I was referring to some of other devices like S3C, etc... and I believe they handle double-buffering in different way. In case of S3C, HW does support 2 sets of separate configuration to handle double buffering. Spec doesn't talk about any shadow register, when HW latches it, etc... But I believe it makes sense that, it must be getting latched on next vsync. > > 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? [Hiremath, Vaibhav] It doesn't take time to reach HW. What if application writes exactly during this period (VFP - VSYNC), could it be delay due to extra time for image creation, or anything. > 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. > [Hiremath, Vaibhav] Mat, Exactly same thing I am bringing out here, OMAP3 DSS doesn't fall under this. In case of OMAP3, the latching doesn't happen on VSYNC, it happens on VFP (Vertical front porch). There is time gap between VFP and VSYNC; this is what I am referring to. If application changes/writes during this period (after VFP and before VSYNC) you are going out of sync, that's where the tearing effect is observed. > > 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. > [Hiremath, Vaibhav] If I fail to convince on this, then I think the only left option is to make WAITFORGO ioctl generic. And put a disclaimer on WAITFORVSYNC, it must not be used in panning use-case. > -- > 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 -- 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
