Re: [PATCH 1/4] drm: add plane support

[Rob Clark <robdclark@gmail.com>]

On Fri, Jul 22, 2011 at 10:30 AM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Fri, 22 Jul 2011 08:52:52 -0500
> Rob Clark <robdclark@gmail.com> wrote:
>
>> On Mon, Jun 20, 2011 at 3:11 PM, Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
>> >  /**
>> > + * drm_plane_funcs - driver plane control functions
>> > + * @update_plane: update the plane configuration
>> > + */
>> > +struct drm_plane_funcs {
>> > +       int (*update_plane)(struct drm_plane *plane,
>> > +                           struct drm_crtc *crtc, struct drm_framebuffer *fb,
>> > +                           int crtc_x, int crtc_y,
>> > +                           unsigned int crtc_w, unsigned int crtc_h,
>> > +                           uint32_t src_x, uint32_t src_y,
>> > +                           uint32_t src_w, uint32_t src_h);
>> > +       void (*disable_plane)(struct drm_plane *plane);
>> > +};
>> > +
>>
>>
>> would it freak anyone out too much to ask about multi-planar formats?
>> Ie. say you have an overlay that could display I420 w/ separate Y, U,
>> & V addresses or NV12 w/ separate Y and UV addresses.  Some of the
>> SoC's out there require that chroma and luma is in different memory
>> banks.  In omap4xxx case we don't have this requirement, but we do
>> have different tiling for Y and UV  (NV12).
>>
>> Not something that directly affects this patchset.. I'm thinking more
>> along the lines of having a way to create a drm_framebuffer w/ more
>> than one GEM buffer, one per color plane.  The other option is to bury
>> this all behind a single GEM buffer.. although that seems like it
>> could get ugly/hacky.
>>
>> Am I opening a can of worms here?  ;-)
>
> Yes. :)
>
> Given the format constraints for planar, multi-buffer configs, it might
> be best to expose those as driver specific ioctls.  It's a big ugly to
> have a driver specific addfb (only because we don't have one currently)
> but should be doable for funkier things like this.
>

I'm ok with this.. we can always add a common ioctl later if we end up
with multiple drivers doing things the same way

BR,
-R

> --
> Jesse Barnes, Intel Open Source Technology Center
>