<p>Hi Jesse,</p>
<p>2011/11/15 Jesse Barnes <<a href="mailto:jbarnes@virtuousgeek.org">jbarnes@virtuousgeek.org</a>><br>
><br>
> To properly support the various plane formats supported by different<br>
> hardware, the kernel must know the pixel format of a framebuffer object.<br>
> So add a new ioctl taking a format argument corresponding to a fourcc<br>
> name from the new drm_fourcc.h header file. Implement the fb creation<br>
> hooks in terms of the new mode_fb_cmd2 using helpers where the old<br>
> bpp/depth values are needed.<br>
><br>
> v2: create DRM specific fourcc header file for sharing with libdrm etc<br>
> v3: fix rebase failure and use DRM fourcc codes in intel_display.c and<br>
> update commit message<br>
> v4: make fb_cmd2 handle field into an array for multi-object formats<br>
> pull in Ville's fix for the memcpy in drm_plane_init<br>
> apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb<br>
> v5: add 'flags' field for interlaced support (from Ville)<br>
><br>
> Signed-off-by: Ville Syrjälä <<a href="mailto:ville.syrjala@linux.intel.com">ville.syrjala@linux.intel.com</a>><br>
> Acked-by: Alan Cox <<a href="mailto:alan@lxorguk.ukuu.org.uk">alan@lxorguk.ukuu.org.uk</a>><br>
> Reviewed-by: Rob Clark <<a href="mailto:rob.clark@linaro.org">rob.clark@linaro.org</a>><br>
> Signed-off-by: Jesse Barnes <<a href="mailto:jbarnes@virtuousgeek.org">jbarnes@virtuousgeek.org</a>><br>
> ---<br>
> drivers/gpu/drm/drm_crtc.c | 111 +++++++++++++++++++++++++++--<br>
> drivers/gpu/drm/drm_crtc_helper.c | 51 ++++++++++++-<br>
> drivers/gpu/drm/drm_drv.c | 1 +<br>
> drivers/gpu/drm/i915/intel_display.c | 39 ++++++-----<br>
> drivers/gpu/drm/i915/intel_drv.h | 2 +-<br>
> drivers/gpu/drm/i915/intel_fb.c | 11 ++--<br>
> drivers/gpu/drm/nouveau/nouveau_display.c | 6 +-<br>
> drivers/gpu/drm/nouveau/nouveau_fb.h | 2 +-<br>
> drivers/gpu/drm/nouveau/nouveau_fbcon.c | 13 ++--<br>
> drivers/gpu/drm/radeon/radeon_display.c | 8 +-<br>
> drivers/gpu/drm/radeon/radeon_fb.c | 18 +++--<br>
> drivers/gpu/drm/radeon/radeon_mode.h | 2 +-<br>
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.c | 22 ++++--<br>
> drivers/gpu/drm/vmwgfx/vmwgfx_kms.h | 1 +<br>
> drivers/staging/gma500/framebuffer.c | 2 +-<br>
> include/drm/drm.h | 1 +<br>
> include/drm/drm_crtc.h | 9 ++-<br>
> include/drm/drm_crtc_helper.h | 4 +-<br>
> include/drm/drm_fourcc.h | 63 ++++++++++++++++<br>
> include/drm/drm_mode.h | 27 +++++++<br>
> 20 files changed, 327 insertions(+), 66 deletions(-)<br>
> create mode 100644 include/drm/drm_fourcc.h<br>
></p>
<p><snip></p>
<p>> diff --git a/drivers/staging/gma500/framebuffer.c b/drivers/staging/gma500/framebuffer.c<br>
> index 3f39a37..1e77229 100644<br>
> --- a/drivers/staging/gma500/framebuffer.c<br>
> +++ b/drivers/staging/gma500/framebuffer.c<br>
> @@ -546,7 +546,7 @@ out_err1:<br>
> */<br>
> static struct drm_framebuffer *psb_user_framebuffer_create<br>
> (struct drm_device *dev, struct drm_file *filp,<br>
> - struct drm_mode_fb_cmd *cmd)<br>
> + struct drm_mode_fb_cmd2 *cmd)<br>
> {<br>
> struct gtt_range *r;<br>
> struct drm_gem_object *obj;</p>
<p>I have no idea that this staging driver is really used or not, but anyway if drm_mode_fb_cmd2 is<br>
used here, then also it looks like that *cmd->handle* and *psb_framebuffer_create(dev, cmd, r)*<br>
are changed.</p>
<p>psb_framebuffer_create() and psb_framebuffer_init() still use drm_mode_fb_cmd, so maybe<br>
changed like vmwgfx_kms.c.</p>
<p><snip></p>
<p>> +++ b/include/drm/drm_mode.h<br>
> @@ -266,6 +266,33 @@ struct drm_mode_fb_cmd {<br>
> __u32 handle;<br>
> };<br>
><br>
> +#define DRM_MODE_FB_INTERLACED (1<<0 /* for interlaced framebuffers */<br>
> +<br>
> +struct drm_mode_fb_cmd2 {<br>
> + __u32 fb_id;<br>
> + __u32 width, height;<br>
> + __u32 pixel_format; /* fourcc code from drm_fourcc.h */<br>
> + __u32 flags; /* see above flags */<br>
> +<br>
> + /*<br>
> + * In case of planar formats, this ioctl allows up to 4<br>
> + * buffer objects with offets and pitches per plane.<br>
> + * The pitch and offset order is dictated by the fourcc,<br>
> + * e.g. NV12 (<a href="http://fourcc.org/yuv.php#NV12">http://fourcc.org/yuv.php#NV12</a>) is described as:<br>
> + *<br>
> + * YUV 4:2:0 image with a plane of 8 bit Y samples<br>
> + * followed by an interleaved U/V plane containing<br>
> + * 8 bit 2x2 subsampled colour difference samples.<br>
> + *<br>
> + * So it would consist of Y as offset[0] and UV as<br>
> + * offeset[1]. Note that offset[0] will generally<br>
> + * be 0.<br>
> + */<br>
> + __u32 handles[4];<br>
> + __u32 pitches[4]; /* pitch for each plane */<br>
> + __u32 offsets[4]; /* offset of each plane */<br>
> +};</p>
<p><snip></p>
<p>Regards,<br>
- Seung-Woo Kim</p>