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