Re: [RFC] update DRM core vblank code to be more power friendly

[Jesse B. <jb...@vi...>]

On Monday, June 11, 2007 11:14:45 Ian Romanick wrote:
> Jesse Barnes wrote:
> > We've had some IRC and off-list discussions about how to improve the
> > DRM's vblank code to be a bit more power friendly.  The core requirement
> > is that we only enable vblank interrupts when a client is actually
> > waiting for a vblank event (be it a signal or a wakeup).
> >
> > This patch updates the DRM core, requiring drivers to provide vblank
> > enable and disable hooks, as well as a counter updater, and adds some
> > i915 code to use it.
> >
> > When the DRM vblank code is called, the core will update the counter,
> > add the desired sequence value to it, and either setup a signal or
> > wait for the desired sequence number to be hit, enabling vblanks around
> > the operation.  Once complete, vblank interrupts will again be disabled
> > to save power.
> >
> > The patch doesn't yet deal with two obvious cases (and probably more
> > that I'm missing, it's untested yet):
> >   - the hardware counter resets on mode switch, we need to rebase
> >     the appropriate last_counter at that point so it's not treated as
> >     a counter wrap
> >   - a client interested in signals but also blocked on a vblank event
> >     may cause vblanks to be disabled if it received signal at the wrong
> >     time
> >
> > I'll be happy to fix it up and/or restructure as requested.  I think the
> > basic approach should be fairly sound (even devices that don't support a
> > counter register could fake it using total time/vrefresh or similar), but
> > if not I'd love to hear about it. :)
>
> The problem is that a few of the GLX extensions (e.g.,
> GLX_SGI_video_sync and GLX_OML_sync_control) allow applications to query
> the vblank counter directly.  I don't know of other hardware that
> maintains an actual counter.  I know that MGA doesn't, and I'm pretty
> sure that Via doesn't either.

Right, we still have to expose the counter.  But that just means calling the 
update_vblank_counter hook before returning it to userspace.

And of course, another option for devices that don't have vblank count 
registers (aside from the 'fake it based on time' mentioned above) would be 
to just leave interrupts enabled and do the counting there as usual.  That 
would make the enable/disable hooks no-ops, and the update_vblank_counter 
into a simple return of the latest value.

Jesse