Re: [PATCH 7/8] drm/irq: Implement a generic vblank_wait function

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jul 30, 2014 at 05:36:21PM +0300, Ville Syrjälä wrote:
> On Wed, Jul 30, 2014 at 04:20:25PM +0200, Thierry Reding wrote:
> > On Wed, Jul 30, 2014 at 05:32:28PM +0900, Michel Dänzer wrote:
> > > On 30.07.2014 17:22, Daniel Vetter wrote:
> > > > On Wed, Jul 30, 2014 at 11:59:33AM +0900, Michel Dänzer wrote:
> > > >> On 30.07.2014 06:32, Daniel Vetter wrote:
> > > >>> + * due to lack of driver support or because the crtc is off.
> > > >>> + */
> > > >>> +void drm_crtc_vblank_wait(struct drm_crtc *crtc)
> > > >>> +{
> > > >>> +	drm_vblank_wait(crtc->dev, drm_crtc_index(crtc));
> > > >>> +}
> > > >>> +EXPORT_SYMBOL(drm_crtc_vblank_wait);
> > > >>> +
> > > >>> +/**
> > > >>
> > > >> Maybe the function names should be *_vblank_wait_next() or something to
> > > >> clarify the purpose and reduce potential confusion versus drm_wait_vblank().
> > > > 
> > > > Yeah that name is just transferred from the i915 driver. What about
> > > > drm_wait_one_vblank()/drm_crtc_wait_one_vblank()?
> > > 
> > > I don't care that much :), go ahead.
> > 
> > Just my two cents: our downstream kernel has a helper somewhat like this
> > which waits for a specified number of frames (apparently this is useful
> > for some panels that require up to 5 or 6 frames before they display the
> > correct image on screen). So perhaps something like this could work:
> > 
> > 	void drm_wait_vblank_count(struct drm_device *dev, unsigned int crtc,
> > 				   unsigned int count)
> > 	{
> > 		u32 last;
> > 		int ret;
> > 
> > 		ret = drm_vblank_get(dev, crtc);
> > 		if (WARN_ON(ret))
> > 			return;
> > 
> > 		while (count--) {
> > 			last = drm_vblank_count(dev, crtc);
> > 
> > 			...
> > 		}
> > 
> > 		drm_vblank_put(dev, crtc);
> > 	}
> 
> Would be nicer to wait for an absolute vblank count instead IMO. Or
> if you want to pass a relative count in just convert it to an absolute
> count first and wait for it (taking wraparound into account obviously).

Yeah I've conisidered to to a generic version, but don't though about all
the ways I'll get wrap-around wrong and decided that we better postpone
this until there's a real need. We can easily extract it later on ...
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/intel-gfx





[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux