drm: add an fb creation ioctl that takes a pixel format v5

To properly support the various plane formats supported by different
hardware, the kernel must know the pixel format of a framebuffer object.
So add a new ioctl taking a format argument corresponding to a fourcc
name from the new drm_fourcc.h header file.  Implement the fb creation
hooks in terms of the new mode_fb_cmd2 using helpers where the old
bpp/depth values are needed.

v2: create DRM specific fourcc header file for sharing with libdrm etc
v3: fix rebase failure and use DRM fourcc codes in intel_display.c and
    update commit message
v4: make fb_cmd2 handle field into an array for multi-object formats
    pull in Ville's fix for the memcpy in drm_plane_init
    apply Ville's cleanup to zero out fb_cmd2 arg in drm_mode_addfb
v5: add 'flags' field for interlaced support (from Ville)

Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Alan Cox <alan@lxorguk.ukuu.org.uk>
Reviewed-by: Rob Clark <rob.clark@linaro.org>
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Signed-off-by: Dave Airlie <airlied@redhat.com>

1 files changed, 63 insertions, 0 deletions

diff --git a/include/drm/drm_fourcc.h b/include/drm/drm_fourcc.h
new file mode 100644
index 0000000000000..48c3d107a8fad
--- /dev/null
+++ b/include/drm/drm_fourcc.h
@@ -0,0 +1,63 @@
+/*
+ * Copyright 2011 Intel Corporation
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a
+ * copy of this software and associated documentation files (the "Software"),
+ * to deal in the Software without restriction, including without limitation
+ * the rights to use, copy, modify, merge, publish, distribute, sublicense,
+ * and/or sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice (including the next
+ * paragraph) shall be included in all copies or substantial portions of the
+ * Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+ * VA LINUX SYSTEMS AND/OR ITS SUPPLIERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
+ * OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
+ * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+#ifndef DRM_FOURCC_H
+#define DRM_FOURCC_H
+
+/*
+ * We don't use the V4L header because
+ * 1) the fourcc codes are well defined and trivial to construct
+ * 2) we don't want user apps to have to pull in v4l headers just for fourcc
+ * 3) the v4l fourcc codes are mixed up with a bunch of other code and are
+ *    part of the v4l API, so changing them to something linux-generic isn't
+ *    feasible
+ *
+ * So the below includes the fourcc codes used by the DRM and its drivers,
+ * along with potential device specific codes.
+ */
+
+#include <linux/types.h>
+
+#define fourcc_code(a,b,c,d) ((u32)(a) | ((u32)(b) << 8) | \
+			      ((u32)(c) << 16) | ((u32)(d) << 24))
+
+/* RGB codes */
+#define DRM_FOURCC_RGB332 fourcc_code('R','G','B','1')
+#define DRM_FOURCC_RGB555 fourcc_code('R','G','B','O')
+#define DRM_FOURCC_RGB565 fourcc_code('R','G','B','P')
+#define DRM_FOURCC_RGB24  fourcc_code('R','G','B','3')
+#define DRM_FOURCC_RGB32  fourcc_code('R','G','B','4')
+
+#define DRM_FOURCC_BGR24  fourcc_code('B','G','R','3')
+#define DRM_FOURCC_BGR32  fourcc_code('B','G','R','4')
+
+/* YUV codes */
+#define DRM_FOURCC_YUYV   fourcc_code('Y', 'U', 'Y', 'V')
+#define DRM_FOURCC_YVYU   fourcc_code('Y', 'V', 'Y', 'U')
+#define DRM_FOURCC_UYVY   fourcc_code('U', 'Y', 'V', 'Y')
+#define DRM_FOURCC_VYUY   fourcc_code('V', 'Y', 'U', 'Y')
+
+/* DRM specific codes */
+#define DRM_INTEL_RGB30   fourcc_code('R','G','B','0') /* RGB x:10:10:10 */
+
+#endif /* DRM_FOURCC_H */