[Intel-gfx] [PATCH 1/3] drm/i915: add SNB and IVB video sprite support v5

[Jesse Barnes]

On Mon, 12 Dec 2011 22:56:34 +0100
Daniel Vetter <daniel at ffwll.ch> wrote:

> On Wed, Dec 07, 2011 at 12:29:21PM -0800, Jesse Barnes wrote:
> > The video sprites support various video surface formats natively and can
> > handle scaling as well.  So add support for them using the new DRM core
> > sprite support functions.
> > 
> > v2: use drm specific fourcc header and defines
> > v3: address Daniel's comments:
> >   - don't take struct mutex around register access (only needed for
> >     regs in the GT power well)
> >   - don't hold struct mutex across vblank waits
> >   - fix up update_plane API (pass obj instead of GTT offset)
> >   - add interlaced defines for sprite regs
> >   - drop unnecessary 'reg' variables
> >   - comment double buffered reg flushing
> >   Also fix w/h confusion when writing the scaling reg.
> > v4: more fixes, address more comments from Daniel, and include Hai's fix
> >   - prevent divide by zero in scaling calculation (Hai Lan)
> >   - update to Ville's new DRM_FORMAT_* types
> >   - fix sprite watermark handling (calc based on CRTC size, separate
> >     from normal display wm)
> >   - remove private refcounts now that the fb cleanups handles things
> > v5: add linear surface support
> > 
> > For this version, I tested DPMS since it came up in the last review;
> > DPMS off/on works ok when a video player is working under X, but for
> > power saving we'll probably want to do something smarter.  I'll leave
> > that for a separate patch on top.  Likewise with the refcounting/fb
> > layer handling, which are really separate cleanups.
> > 
> > Signed-off-by: Jesse Barnes <jbarnes at virtuousgeek.org>
> 
> I didn't bother to recheck the regs and and the wm stuff looks like the
> usual magic ;-) Otherwise you've implemented way more of my review
> comments than I could possibly still remember, so it must be good.
> 
> Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>

The one thing I kept out was the "disable planes in generic code"
call.  The TI guys are working on using planes to represent all planes,
not just additional overlays, so calling disable from generic code
seemed unfriendly.

Keith, this one is ready for -next.  I'll clean up the ioctl now and
re-post; without it the overlays will always sit on top without
blending, so the patch is still safe.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/intel-gfx/attachments/20111213/f94cad86/attachment.sig>