[PATCH v2 0/5] video: describe data bus formats

[PATCH v2 0/5] video: describe data bus formats

[Boris Brezillon]

Hello,

This patch series is a proposal to describe the different data formats used
by HW components to connect with each other.

This is just a copy of the existing V4L2_MBUS_FMT defintions with a neutral
name so that it can be used by V4L2 and DRM/KMS subsystem.

This series also makes use of this video_bus_format enum in the DRM/KMS
subsystem to define the data fomats supported on the connector <-> device
link.

Best Regards,

Boris

Changes since v1:
 - define an enum and use a macro for v4l2 bus formats definitions
 - rename nformats into num_formats
 - declare num_formats as an unsigned int

Boris BREZILLON (3):
  drm: add bus_formats and nbus_formats fields to drm_display_info
  drm: panel: simple-panel: add support for bus_format retrieval
  drm: panel: simple-panel: add bus format information for foxlink panel

Boris Brezillon (2):
  video: move mediabus format definition to a more standard place
  video: add RGB444_1X12 and RGB565_1X16 bus formats

 drivers/gpu/drm/drm_crtc.c            |  31 ++++++
 drivers/gpu/drm/panel/panel-simple.c  |   6 ++
 include/drm/drm_crtc.h                |   8 ++
 include/uapi/linux/Kbuild             |   1 +
 include/uapi/linux/v4l2-mediabus.h    | 185 +++++++++++++++-------------------
 include/uapi/linux/video-bus-format.h | 129 ++++++++++++++++++++++++
 6 files changed, 256 insertions(+), 104 deletions(-)
 create mode 100644 include/uapi/linux/video-bus-format.h

-- 
1.9.1

[PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Boris Brezillon]

Rename mediabus formats and move the enum into a separate header file so
that it can be used by DRM/KMS subsystem without any reference to the V4L2
subsystem.

Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
definitions.

Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
---
 include/uapi/linux/Kbuild             |   1 +
 include/uapi/linux/v4l2-mediabus.h    | 183 +++++++++++++++-------------------
 include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++
 3 files changed, 207 insertions(+), 104 deletions(-)
 create mode 100644 include/uapi/linux/video-bus-format.h

diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
index be88166..8712730 100644
--- a/include/uapi/linux/Kbuild
+++ b/include/uapi/linux/Kbuild
@@ -410,6 +410,7 @@ header-y += veth.h
 header-y += vfio.h
 header-y += vhost.h
 header-y += videodev2.h
+header-y += video-bus-format.h
 header-y += virtio_9p.h
 header-y += virtio_balloon.h
 header-y += virtio_blk.h
diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
index 1445e85..7b0a06c 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -13,118 +13,93 @@
 
 #include <linux/types.h>
 #include <linux/videodev2.h>
+#include <linux/video-bus-format.h>
 
-/*
- * These pixel codes uniquely identify data formats on the media bus. Mostly
- * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
- * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the
- * data format is fixed. Additionally, "2X8" means that one pixel is transferred
- * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
- * transferred over the bus: "LE" means that the least significant bits are
- * transferred first, "BE" means that the most significant bits are transferred
- * first, and "PADHI" and "PADLO" define which bits - low or high, in the
- * incomplete high byte, are filled with padding bits.
- *
- * The pixel codes are grouped by type, bus_width, bits per component, samples
- * per pixel and order of subsamples. Numerical values are sorted using generic
- * numerical sort order (8 thus comes before 10).
- *
- * As their value can't change when a new pixel code is inserted in the
- * enumeration, the pixel codes are explicitly given a numerical value. The next
- * free values for each category are listed below, update them when inserting
- * new pixel codes.
- */
-enum v4l2_mbus_pixelcode {
-	V4L2_MBUS_FMT_FIXED = 0x0001,
+#define VIDEO_BUS_TO_V4L2_MBUS(x)	V4L2_MBUS_FMT_ ## x = VIDEO_BUS_FMT_ ## x
 
-	/* RGB - next is 0x100e */
-	V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
-	V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
-	V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
-	V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
-	V4L2_MBUS_FMT_BGR565_2X8_BE = 0x1005,
-	V4L2_MBUS_FMT_BGR565_2X8_LE = 0x1006,
-	V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
-	V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
-	V4L2_MBUS_FMT_RGB666_1X18 = 0x1009,
-	V4L2_MBUS_FMT_RGB888_1X24 = 0x100a,
-	V4L2_MBUS_FMT_RGB888_2X12_BE = 0x100b,
-	V4L2_MBUS_FMT_RGB888_2X12_LE = 0x100c,
-	V4L2_MBUS_FMT_ARGB8888_1X32 = 0x100d,
+enum v4l2_mbus_pixelcode {
+	VIDEO_BUS_TO_V4L2_MBUS(FIXED),
 
-	/* YUV (including grey) - next is 0x2024 */
-	V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
-	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
-	V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
-	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
-	V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
-	V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
-	V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
-	V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
-	V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
-	V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
-	V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
-	V4L2_MBUS_FMT_UYVY10_2X10 = 0x2018,
-	V4L2_MBUS_FMT_VYUY10_2X10 = 0x2019,
-	V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b,
-	V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c,
-	V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
-	V4L2_MBUS_FMT_UYVY8_1X16 = 0x200f,
-	V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010,
-	V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011,
-	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
-	V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014,
-	V4L2_MBUS_FMT_UYVY10_1X20 = 0x201a,
-	V4L2_MBUS_FMT_VYUY10_1X20 = 0x201b,
-	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
-	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
-	V4L2_MBUS_FMT_YUV10_1X30 = 0x2016,
-	V4L2_MBUS_FMT_AYUV8_1X32 = 0x2017,
-	V4L2_MBUS_FMT_UYVY12_2X12 = 0x201c,
-	V4L2_MBUS_FMT_VYUY12_2X12 = 0x201d,
-	V4L2_MBUS_FMT_YUYV12_2X12 = 0x201e,
-	V4L2_MBUS_FMT_YVYU12_2X12 = 0x201f,
-	V4L2_MBUS_FMT_UYVY12_1X24 = 0x2020,
-	V4L2_MBUS_FMT_VYUY12_1X24 = 0x2021,
-	V4L2_MBUS_FMT_YUYV12_1X24 = 0x2022,
-	V4L2_MBUS_FMT_YVYU12_1X24 = 0x2023,
+	VIDEO_BUS_TO_V4L2_MBUS(RGB444_2X8_PADHI_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB444_2X8_PADHI_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB555_2X8_PADHI_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB555_2X8_PADHI_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(BGR565_2X8_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(BGR565_2X8_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB565_2X8_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB565_2X8_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB666_1X18),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB888_1X24),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(ARGB8888_1X32),
 
-	/* Bayer - next is 0x3019 */
-	V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
-	V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
-	V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
-	V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
-	V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
-	V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
-	V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
-	V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
-	V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
-	V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
-	V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
-	V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
-	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
-	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
-	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
-	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
-	V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
-	V4L2_MBUS_FMT_SGBRG10_1X10 = 0x300e,
-	V4L2_MBUS_FMT_SGRBG10_1X10 = 0x300a,
-	V4L2_MBUS_FMT_SRGGB10_1X10 = 0x300f,
-	V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,
-	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
-	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
-	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
+	VIDEO_BUS_TO_V4L2_MBUS(Y8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(UV8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_1_5X8),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_1_5X8),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_1_5X8),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_1_5X8),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_2X8),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_2X8),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_2X8),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_2X8),
+	VIDEO_BUS_TO_V4L2_MBUS(Y10_1X10),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY10_2X10),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY10_2X10),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV10_2X10),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU10_2X10),
+	VIDEO_BUS_TO_V4L2_MBUS(Y12_1X12),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_1X16),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_1X16),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_1X16),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_1X16),
+	VIDEO_BUS_TO_V4L2_MBUS(YDYUYDYV8_1X16),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY10_1X20),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY10_1X20),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV10_1X20),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU10_1X20),
+	VIDEO_BUS_TO_V4L2_MBUS(YUV10_1X30),
+	VIDEO_BUS_TO_V4L2_MBUS(AYUV8_1X32),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY12_2X12),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY12_2X12),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV12_2X12),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU12_2X12),
+	VIDEO_BUS_TO_V4L2_MBUS(UYVY12_1X24),
+	VIDEO_BUS_TO_V4L2_MBUS(VYUY12_1X24),
+	VIDEO_BUS_TO_V4L2_MBUS(YUYV12_1X24),
+	VIDEO_BUS_TO_V4L2_MBUS(YVYU12_1X24),
 
-	/* JPEG compressed formats - next is 0x4002 */
-	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SGBRG8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SGRBG8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SRGGB8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_ALAW8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_ALAW8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_ALAW8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_ALAW8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_DPCM8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_DPCM8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_DPCM8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_DPCM8_1X8),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADHI_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADHI_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADLO_BE),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADLO_LE),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_1X10),
+	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_1X10),
+	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_1X10),
+	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_1X10),
+	VIDEO_BUS_TO_V4L2_MBUS(SBGGR12_1X12),
+	VIDEO_BUS_TO_V4L2_MBUS(SGBRG12_1X12),
+	VIDEO_BUS_TO_V4L2_MBUS(SGRBG12_1X12),
+	VIDEO_BUS_TO_V4L2_MBUS(SRGGB12_1X12),
 
-	/* Vendor specific formats - next is 0x5002 */
+	VIDEO_BUS_TO_V4L2_MBUS(JPEG_1X8),
 
-	/* S5C73M3 sensor specific interleaved UYVY and JPEG */
-	V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
+	VIDEO_BUS_TO_V4L2_MBUS(S5C_UYVY_JPEG_1X8),
 
-	/* HSV - next is 0x6002 */
-	V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001,
+	VIDEO_BUS_TO_V4L2_MBUS(AHSV8888_1X32),
 };
 
 /**
diff --git a/include/uapi/linux/video-bus-format.h b/include/uapi/linux/video-bus-format.h
new file mode 100644
index 0000000..4abbd5d
--- /dev/null
+++ b/include/uapi/linux/video-bus-format.h
@@ -0,0 +1,127 @@
+/*
+ * Video Bus API header
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+
+#ifndef __LINUX_VIDEO_BUS_FORMAT_H
+#define __LINUX_VIDEO_BUS_FORMAT_H
+
+/*
+ * These bus formats uniquely identify data formats on the data bus. Mostly
+ * they correspond to similarly named VIDEO_PIX_FMT_* formats, format 0 is
+ * reserved, VIDEO_BUS_FMT_FIXED shall be used by host-client pairs, where the
+ * data format is fixed. Additionally, "2X8" means that one pixel is transferred
+ * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
+ * transferred over the bus: "LE" means that the least significant bits are
+ * transferred first, "BE" means that the most significant bits are transferred
+ * first, and "PADHI" and "PADLO" define which bits - low or high, in the
+ * incomplete high byte, are filled with padding bits.
+ *
+ * The bus formats are grouped by type, bus_width, bits per component, samples
+ * per pixel and order of subsamples. Numerical values are sorted using generic
+ * numerical sort order (8 thus comes before 10).
+ *
+ * As their value can't change when a new bus format is inserted in the
+ * enumeration, the bus formats are explicitly given a numerical value. The next
+ * free values for each category are listed below, update them when inserting
+ * new pixel codes.
+ */
+enum video_bus_format {
+	VIDEO_BUS_FMT_FIXED = 0x0001,
+
+	/* RGB - next is 0x100e */
+	VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
+	VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
+	VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
+	VIDEO_BUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
+	VIDEO_BUS_FMT_BGR565_2X8_BE = 0x1005,
+	VIDEO_BUS_FMT_BGR565_2X8_LE = 0x1006,
+	VIDEO_BUS_FMT_RGB565_2X8_BE = 0x1007,
+	VIDEO_BUS_FMT_RGB565_2X8_LE = 0x1008,
+	VIDEO_BUS_FMT_RGB666_1X18 = 0x1009,
+	VIDEO_BUS_FMT_RGB888_1X24 = 0x100a,
+	VIDEO_BUS_FMT_RGB888_2X12_BE = 0x100b,
+	VIDEO_BUS_FMT_RGB888_2X12_LE = 0x100c,
+	VIDEO_BUS_FMT_ARGB8888_1X32 = 0x100d,
+
+	/* YUV (including grey) - next is 0x2024 */
+	VIDEO_BUS_FMT_Y8_1X8 = 0x2001,
+	VIDEO_BUS_FMT_UV8_1X8 = 0x2015,
+	VIDEO_BUS_FMT_UYVY8_1_5X8 = 0x2002,
+	VIDEO_BUS_FMT_VYUY8_1_5X8 = 0x2003,
+	VIDEO_BUS_FMT_YUYV8_1_5X8 = 0x2004,
+	VIDEO_BUS_FMT_YVYU8_1_5X8 = 0x2005,
+	VIDEO_BUS_FMT_UYVY8_2X8 = 0x2006,
+	VIDEO_BUS_FMT_VYUY8_2X8 = 0x2007,
+	VIDEO_BUS_FMT_YUYV8_2X8 = 0x2008,
+	VIDEO_BUS_FMT_YVYU8_2X8 = 0x2009,
+	VIDEO_BUS_FMT_Y10_1X10 = 0x200a,
+	VIDEO_BUS_FMT_UYVY10_2X10 = 0x2018,
+	VIDEO_BUS_FMT_VYUY10_2X10 = 0x2019,
+	VIDEO_BUS_FMT_YUYV10_2X10 = 0x200b,
+	VIDEO_BUS_FMT_YVYU10_2X10 = 0x200c,
+	VIDEO_BUS_FMT_Y12_1X12 = 0x2013,
+	VIDEO_BUS_FMT_UYVY8_1X16 = 0x200f,
+	VIDEO_BUS_FMT_VYUY8_1X16 = 0x2010,
+	VIDEO_BUS_FMT_YUYV8_1X16 = 0x2011,
+	VIDEO_BUS_FMT_YVYU8_1X16 = 0x2012,
+	VIDEO_BUS_FMT_YDYUYDYV8_1X16 = 0x2014,
+	VIDEO_BUS_FMT_UYVY10_1X20 = 0x201a,
+	VIDEO_BUS_FMT_VYUY10_1X20 = 0x201b,
+	VIDEO_BUS_FMT_YUYV10_1X20 = 0x200d,
+	VIDEO_BUS_FMT_YVYU10_1X20 = 0x200e,
+	VIDEO_BUS_FMT_YUV10_1X30 = 0x2016,
+	VIDEO_BUS_FMT_AYUV8_1X32 = 0x2017,
+	VIDEO_BUS_FMT_UYVY12_2X12 = 0x201c,
+	VIDEO_BUS_FMT_VYUY12_2X12 = 0x201d,
+	VIDEO_BUS_FMT_YUYV12_2X12 = 0x201e,
+	VIDEO_BUS_FMT_YVYU12_2X12 = 0x201f,
+	VIDEO_BUS_FMT_UYVY12_1X24 = 0x2020,
+	VIDEO_BUS_FMT_VYUY12_1X24 = 0x2021,
+	VIDEO_BUS_FMT_YUYV12_1X24 = 0x2022,
+	VIDEO_BUS_FMT_YVYU12_1X24 = 0x2023,
+
+	/* Bayer - next is 0x3019 */
+	VIDEO_BUS_FMT_SBGGR8_1X8 = 0x3001,
+	VIDEO_BUS_FMT_SGBRG8_1X8 = 0x3013,
+	VIDEO_BUS_FMT_SGRBG8_1X8 = 0x3002,
+	VIDEO_BUS_FMT_SRGGB8_1X8 = 0x3014,
+	VIDEO_BUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
+	VIDEO_BUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
+	VIDEO_BUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
+	VIDEO_BUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
+	VIDEO_BUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
+	VIDEO_BUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
+	VIDEO_BUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
+	VIDEO_BUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
+	VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
+	VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
+	VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
+	VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
+	VIDEO_BUS_FMT_SBGGR10_1X10 = 0x3007,
+	VIDEO_BUS_FMT_SGBRG10_1X10 = 0x300e,
+	VIDEO_BUS_FMT_SGRBG10_1X10 = 0x300a,
+	VIDEO_BUS_FMT_SRGGB10_1X10 = 0x300f,
+	VIDEO_BUS_FMT_SBGGR12_1X12 = 0x3008,
+	VIDEO_BUS_FMT_SGBRG12_1X12 = 0x3010,
+	VIDEO_BUS_FMT_SGRBG12_1X12 = 0x3011,
+	VIDEO_BUS_FMT_SRGGB12_1X12 = 0x3012,
+
+	/* JPEG compressed formats - next is 0x4002 */
+	VIDEO_BUS_FMT_JPEG_1X8 = 0x4001,
+
+	/* Vendor specific formats - next is 0x5002 */
+
+	/* S5C73M3 sensor specific interleaved UYVY and JPEG */
+	VIDEO_BUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
+
+	/* HSV - next is 0x6002 */
+	VIDEO_BUS_FMT_AHSV8888_1X32 = 0x6001,
+};
+
+#endif /* __LINUX_VIDEO_BUS_FORMAT_H */
-- 
1.9.1

[PATCH v2 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats

[Boris Brezillon]

Add RGB444 format using a 12 bits bus and RGB565 using a 16 bits bus.

These formats will later be used by atmel-hlcdc driver.

Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
---
 include/uapi/linux/v4l2-mediabus.h    | 2 ++
 include/uapi/linux/video-bus-format.h | 4 +++-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
index 7b0a06c..05336d6 100644
--- a/include/uapi/linux/v4l2-mediabus.h
+++ b/include/uapi/linux/v4l2-mediabus.h
@@ -33,6 +33,8 @@ enum v4l2_mbus_pixelcode {
 	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
 	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
 	VIDEO_BUS_TO_V4L2_MBUS(ARGB8888_1X32),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB444_1X12),
+	VIDEO_BUS_TO_V4L2_MBUS(RGB565_1X16),
 
 	VIDEO_BUS_TO_V4L2_MBUS(Y8_1X8),
 	VIDEO_BUS_TO_V4L2_MBUS(UV8_1X8),
diff --git a/include/uapi/linux/video-bus-format.h b/include/uapi/linux/video-bus-format.h
index 4abbd5d..f85f7ee 100644
--- a/include/uapi/linux/video-bus-format.h
+++ b/include/uapi/linux/video-bus-format.h
@@ -34,7 +34,7 @@
 enum video_bus_format {
 	VIDEO_BUS_FMT_FIXED = 0x0001,
 
-	/* RGB - next is 0x100e */
+	/* RGB - next is 0x1010 */
 	VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
 	VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
 	VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
@@ -48,6 +48,8 @@ enum video_bus_format {
 	VIDEO_BUS_FMT_RGB888_2X12_BE = 0x100b,
 	VIDEO_BUS_FMT_RGB888_2X12_LE = 0x100c,
 	VIDEO_BUS_FMT_ARGB8888_1X32 = 0x100d,
+	VIDEO_BUS_FMT_RGB444_1X12 = 0x100e,
+	VIDEO_BUS_FMT_RGB565_1X16 = 0x100f,
 
 	/* YUV (including grey) - next is 0x2024 */
 	VIDEO_BUS_FMT_Y8_1X8 = 0x2001,
-- 
1.9.1

[PATCH v2 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info

[Boris Brezillon]

From: Boris BREZILLON <boris.brezillon@free-electrons.com>

Add bus_formats and nbus_formats fields and
drm_display_info_set_bus_formats helper function to specify the bus
formats supported by a given display.

This information can be used by display controller drivers to configure
the output interface appropriately (i.e. RGB565, RGB666 or RGB888 on raw
RGB or LVDS busses).

Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
---
 drivers/gpu/drm/drm_crtc.c | 31 +++++++++++++++++++++++++++++++
 include/drm/drm_crtc.h     |  8 ++++++++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c
index 90e7730..c31420f 100644
--- a/drivers/gpu/drm/drm_crtc.c
+++ b/drivers/gpu/drm/drm_crtc.c
@@ -852,6 +852,37 @@ static void drm_mode_remove(struct drm_connector *connector,
 	drm_mode_destroy(connector->dev, mode);
 }
 
+/*
+ * drm_display_info_set_bus_formats - set the supported bus formats
+ * @info: display info to store bus formats in
+ * @fmts: array containing the supported bus formats
+ * @nfmts: the number of entries in the fmts array
+ *
+ * Store the suppported bus formats in display info structure.
+ */
+int drm_display_info_set_bus_formats(struct drm_display_info *info,
+				     const enum video_bus_format *fmts,
+				     unsigned int num_fmts)
+{
+	enum video_bus_format *formats = NULL;
+
+	if (!fmts && num_fmts)
+		return -EINVAL;
+
+	if (fmts && num_fmts) {
+		formats = kmemdup(fmts, sizeof(*fmts) * num_fmts, GFP_KERNEL);
+		if (!formats)
+			return -ENOMEM;
+	}
+
+	kfree(info->bus_formats);
+	info->bus_formats = formats;
+	info->num_bus_formats = num_fmts;
+
+	return 0;
+}
+EXPORT_SYMBOL(drm_display_info_set_bus_formats);
+
 /**
  * drm_connector_init - Init a preallocated connector
  * @dev: DRM device
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index f1105d0..488f779 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -31,6 +31,7 @@
 #include <linux/idr.h>
 #include <linux/fb.h>
 #include <linux/hdmi.h>
+#include <linux/video-bus-format.h>
 #include <drm/drm_mode.h>
 #include <drm/drm_fourcc.h>
 #include <drm/drm_modeset_lock.h>
@@ -130,6 +131,9 @@ struct drm_display_info {
 	enum subpixel_order subpixel_order;
 	u32 color_formats;
 
+	const enum video_bus_format *bus_formats;
+	int num_bus_formats;
+
 	/* Mask of supported hdmi deep color modes */
 	u8 edid_hdmi_dc_modes;
 
@@ -975,6 +979,10 @@ extern int drm_mode_connector_set_path_property(struct drm_connector *connector,
 extern int drm_mode_connector_update_edid_property(struct drm_connector *connector,
 						struct edid *edid);
 
+extern int drm_display_info_set_bus_formats(struct drm_display_info *info,
+					    const enum video_bus_format *fmts,
+					    unsigned int nfmts);
+
 static inline bool drm_property_type_is(struct drm_property *property,
 		uint32_t type)
 {
-- 
1.9.1

[PATCH v2 4/5] drm: panel: simple-panel: add support for bus_format retrieval

[Boris Brezillon]

From: Boris BREZILLON <boris.brezillon@free-electrons.com>

Provide a way to specify panel requirement in terms of supported media bus
format (particularly useful for panels connected to an RGB or LVDS bus).

Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index 4ce1db0..eb3a17e 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -61,6 +61,8 @@ struct panel_desc {
 		unsigned int disable;
 		unsigned int unprepare;
 	} delay;
+
+	enum video_bus_format bus_format;
 };
 
 struct panel_simple {
@@ -111,6 +113,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel)
 	connector->display_info.bpc = panel->desc->bpc;
 	connector->display_info.width_mm = panel->desc->size.width;
 	connector->display_info.height_mm = panel->desc->size.height;
+	if (panel->desc->bus_format)
+		drm_display_info_set_bus_formats(&connector->display_info,
+						 &panel->desc->bus_format, 1);
 
 	return num;
 }
-- 
1.9.1

[PATCH v2 5/5] drm: panel: simple-panel: add bus format information for foxlink panel

[Boris Brezillon]

From: Boris BREZILLON <boris.brezillon@free-electrons.com>

Foxlink's fl500wvr00-a0t supports RGB888 format.

Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
---
 drivers/gpu/drm/panel/panel-simple.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c b/drivers/gpu/drm/panel/panel-simple.c
index eb3a17e..11bff3f 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -521,6 +521,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = {
 		.width = 108,
 		.height = 65,
 	},
+	.bus_format = VIDEO_BUS_FMT_RGB888_1X24,
 };
 
 static const struct drm_display_mode innolux_n116bge_mode = {
-- 
1.9.1

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Boris BREZILLON]

On Mon, 29 Sep 2014 16:02:39 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> wrote:

> Rename mediabus formats and move the enum into a separate header file so
> that it can be used by DRM/KMS subsystem without any reference to the V4L2
> subsystem.
> 
> Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
> definitions.

I forgot to change the commit message: v4l2_mbus_pixelcode is now an
enum that takes its values from the VIDEO_BUS_FMT_ definitions (as
suggested by Guennadi).


> 
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>  include/uapi/linux/Kbuild             |   1 +
>  include/uapi/linux/v4l2-mediabus.h    | 183 +++++++++++++++-------------------
>  include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++
>  3 files changed, 207 insertions(+), 104 deletions(-)
>  create mode 100644 include/uapi/linux/video-bus-format.h
> 
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index be88166..8712730 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -410,6 +410,7 @@ header-y += veth.h
>  header-y += vfio.h
>  header-y += vhost.h
>  header-y += videodev2.h
> +header-y += video-bus-format.h
>  header-y += virtio_9p.h
>  header-y += virtio_balloon.h
>  header-y += virtio_blk.h
> diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
> index 1445e85..7b0a06c 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -13,118 +13,93 @@
>  
>  #include <linux/types.h>
>  #include <linux/videodev2.h>
> +#include <linux/video-bus-format.h>
>  
> -/*
> - * These pixel codes uniquely identify data formats on the media bus. Mostly
> - * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
> - * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the
> - * data format is fixed. Additionally, "2X8" means that one pixel is transferred
> - * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
> - * transferred over the bus: "LE" means that the least significant bits are
> - * transferred first, "BE" means that the most significant bits are transferred
> - * first, and "PADHI" and "PADLO" define which bits - low or high, in the
> - * incomplete high byte, are filled with padding bits.
> - *
> - * The pixel codes are grouped by type, bus_width, bits per component, samples
> - * per pixel and order of subsamples. Numerical values are sorted using generic
> - * numerical sort order (8 thus comes before 10).
> - *
> - * As their value can't change when a new pixel code is inserted in the
> - * enumeration, the pixel codes are explicitly given a numerical value. The next
> - * free values for each category are listed below, update them when inserting
> - * new pixel codes.
> - */
> -enum v4l2_mbus_pixelcode {
> -	V4L2_MBUS_FMT_FIXED = 0x0001,
> +#define VIDEO_BUS_TO_V4L2_MBUS(x)	V4L2_MBUS_FMT_ ## x = VIDEO_BUS_FMT_ ## x
>  
> -	/* RGB - next is 0x100e */
> -	V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
> -	V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
> -	V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
> -	V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
> -	V4L2_MBUS_FMT_BGR565_2X8_BE = 0x1005,
> -	V4L2_MBUS_FMT_BGR565_2X8_LE = 0x1006,
> -	V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> -	V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
> -	V4L2_MBUS_FMT_RGB666_1X18 = 0x1009,
> -	V4L2_MBUS_FMT_RGB888_1X24 = 0x100a,
> -	V4L2_MBUS_FMT_RGB888_2X12_BE = 0x100b,
> -	V4L2_MBUS_FMT_RGB888_2X12_LE = 0x100c,
> -	V4L2_MBUS_FMT_ARGB8888_1X32 = 0x100d,
> +enum v4l2_mbus_pixelcode {
> +	VIDEO_BUS_TO_V4L2_MBUS(FIXED),
>  
> -	/* YUV (including grey) - next is 0x2024 */
> -	V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> -	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> -	V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> -	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> -	V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
> -	V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
> -	V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
> -	V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
> -	V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
> -	V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
> -	V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
> -	V4L2_MBUS_FMT_UYVY10_2X10 = 0x2018,
> -	V4L2_MBUS_FMT_VYUY10_2X10 = 0x2019,
> -	V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b,
> -	V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c,
> -	V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
> -	V4L2_MBUS_FMT_UYVY8_1X16 = 0x200f,
> -	V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010,
> -	V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011,
> -	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> -	V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014,
> -	V4L2_MBUS_FMT_UYVY10_1X20 = 0x201a,
> -	V4L2_MBUS_FMT_VYUY10_1X20 = 0x201b,
> -	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> -	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> -	V4L2_MBUS_FMT_YUV10_1X30 = 0x2016,
> -	V4L2_MBUS_FMT_AYUV8_1X32 = 0x2017,
> -	V4L2_MBUS_FMT_UYVY12_2X12 = 0x201c,
> -	V4L2_MBUS_FMT_VYUY12_2X12 = 0x201d,
> -	V4L2_MBUS_FMT_YUYV12_2X12 = 0x201e,
> -	V4L2_MBUS_FMT_YVYU12_2X12 = 0x201f,
> -	V4L2_MBUS_FMT_UYVY12_1X24 = 0x2020,
> -	V4L2_MBUS_FMT_VYUY12_1X24 = 0x2021,
> -	V4L2_MBUS_FMT_YUYV12_1X24 = 0x2022,
> -	V4L2_MBUS_FMT_YVYU12_1X24 = 0x2023,
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB444_2X8_PADHI_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB444_2X8_PADHI_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB555_2X8_PADHI_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB555_2X8_PADHI_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(BGR565_2X8_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(BGR565_2X8_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB565_2X8_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB565_2X8_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB666_1X18),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB888_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(ARGB8888_1X32),
>  
> -	/* Bayer - next is 0x3019 */
> -	V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
> -	V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
> -	V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
> -	V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
> -	V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> -	V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> -	V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> -	V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
> -	V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
> -	V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
> -	V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
> -	V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
> -	V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
> -	V4L2_MBUS_FMT_SGBRG10_1X10 = 0x300e,
> -	V4L2_MBUS_FMT_SGRBG10_1X10 = 0x300a,
> -	V4L2_MBUS_FMT_SRGGB10_1X10 = 0x300f,
> -	V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,
> -	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> -	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> -	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> +	VIDEO_BUS_TO_V4L2_MBUS(Y8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(UV8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(Y10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(Y12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(YDYUYDYV8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUV10_1X30),
> +	VIDEO_BUS_TO_V4L2_MBUS(AYUV8_1X32),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY12_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY12_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV12_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU12_1X24),
>  
> -	/* JPEG compressed formats - next is 0x4002 */
> -	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADHI_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADHI_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADLO_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADLO_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB12_1X12),
>  
> -	/* Vendor specific formats - next is 0x5002 */
> +	VIDEO_BUS_TO_V4L2_MBUS(JPEG_1X8),
>  
> -	/* S5C73M3 sensor specific interleaved UYVY and JPEG */
> -	V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
> +	VIDEO_BUS_TO_V4L2_MBUS(S5C_UYVY_JPEG_1X8),
>  
> -	/* HSV - next is 0x6002 */
> -	V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001,
> +	VIDEO_BUS_TO_V4L2_MBUS(AHSV8888_1X32),
>  };
>  
>  /**
> diff --git a/include/uapi/linux/video-bus-format.h b/include/uapi/linux/video-bus-format.h
> new file mode 100644
> index 0000000..4abbd5d
> --- /dev/null
> +++ b/include/uapi/linux/video-bus-format.h
> @@ -0,0 +1,127 @@
> +/*
> + * Video Bus API header
> + *
> + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __LINUX_VIDEO_BUS_FORMAT_H
> +#define __LINUX_VIDEO_BUS_FORMAT_H
> +
> +/*
> + * These bus formats uniquely identify data formats on the data bus. Mostly
> + * they correspond to similarly named VIDEO_PIX_FMT_* formats, format 0 is
> + * reserved, VIDEO_BUS_FMT_FIXED shall be used by host-client pairs, where the
> + * data format is fixed. Additionally, "2X8" means that one pixel is transferred
> + * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
> + * transferred over the bus: "LE" means that the least significant bits are
> + * transferred first, "BE" means that the most significant bits are transferred
> + * first, and "PADHI" and "PADLO" define which bits - low or high, in the
> + * incomplete high byte, are filled with padding bits.
> + *
> + * The bus formats are grouped by type, bus_width, bits per component, samples
> + * per pixel and order of subsamples. Numerical values are sorted using generic
> + * numerical sort order (8 thus comes before 10).
> + *
> + * As their value can't change when a new bus format is inserted in the
> + * enumeration, the bus formats are explicitly given a numerical value. The next
> + * free values for each category are listed below, update them when inserting
> + * new pixel codes.
> + */
> +enum video_bus_format {
> +	VIDEO_BUS_FMT_FIXED = 0x0001,
> +
> +	/* RGB - next is 0x100e */
> +	VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
> +	VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
> +	VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
> +	VIDEO_BUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
> +	VIDEO_BUS_FMT_BGR565_2X8_BE = 0x1005,
> +	VIDEO_BUS_FMT_BGR565_2X8_LE = 0x1006,
> +	VIDEO_BUS_FMT_RGB565_2X8_BE = 0x1007,
> +	VIDEO_BUS_FMT_RGB565_2X8_LE = 0x1008,
> +	VIDEO_BUS_FMT_RGB666_1X18 = 0x1009,
> +	VIDEO_BUS_FMT_RGB888_1X24 = 0x100a,
> +	VIDEO_BUS_FMT_RGB888_2X12_BE = 0x100b,
> +	VIDEO_BUS_FMT_RGB888_2X12_LE = 0x100c,
> +	VIDEO_BUS_FMT_ARGB8888_1X32 = 0x100d,
> +
> +	/* YUV (including grey) - next is 0x2024 */
> +	VIDEO_BUS_FMT_Y8_1X8 = 0x2001,
> +	VIDEO_BUS_FMT_UV8_1X8 = 0x2015,
> +	VIDEO_BUS_FMT_UYVY8_1_5X8 = 0x2002,
> +	VIDEO_BUS_FMT_VYUY8_1_5X8 = 0x2003,
> +	VIDEO_BUS_FMT_YUYV8_1_5X8 = 0x2004,
> +	VIDEO_BUS_FMT_YVYU8_1_5X8 = 0x2005,
> +	VIDEO_BUS_FMT_UYVY8_2X8 = 0x2006,
> +	VIDEO_BUS_FMT_VYUY8_2X8 = 0x2007,
> +	VIDEO_BUS_FMT_YUYV8_2X8 = 0x2008,
> +	VIDEO_BUS_FMT_YVYU8_2X8 = 0x2009,
> +	VIDEO_BUS_FMT_Y10_1X10 = 0x200a,
> +	VIDEO_BUS_FMT_UYVY10_2X10 = 0x2018,
> +	VIDEO_BUS_FMT_VYUY10_2X10 = 0x2019,
> +	VIDEO_BUS_FMT_YUYV10_2X10 = 0x200b,
> +	VIDEO_BUS_FMT_YVYU10_2X10 = 0x200c,
> +	VIDEO_BUS_FMT_Y12_1X12 = 0x2013,
> +	VIDEO_BUS_FMT_UYVY8_1X16 = 0x200f,
> +	VIDEO_BUS_FMT_VYUY8_1X16 = 0x2010,
> +	VIDEO_BUS_FMT_YUYV8_1X16 = 0x2011,
> +	VIDEO_BUS_FMT_YVYU8_1X16 = 0x2012,
> +	VIDEO_BUS_FMT_YDYUYDYV8_1X16 = 0x2014,
> +	VIDEO_BUS_FMT_UYVY10_1X20 = 0x201a,
> +	VIDEO_BUS_FMT_VYUY10_1X20 = 0x201b,
> +	VIDEO_BUS_FMT_YUYV10_1X20 = 0x200d,
> +	VIDEO_BUS_FMT_YVYU10_1X20 = 0x200e,
> +	VIDEO_BUS_FMT_YUV10_1X30 = 0x2016,
> +	VIDEO_BUS_FMT_AYUV8_1X32 = 0x2017,
> +	VIDEO_BUS_FMT_UYVY12_2X12 = 0x201c,
> +	VIDEO_BUS_FMT_VYUY12_2X12 = 0x201d,
> +	VIDEO_BUS_FMT_YUYV12_2X12 = 0x201e,
> +	VIDEO_BUS_FMT_YVYU12_2X12 = 0x201f,
> +	VIDEO_BUS_FMT_UYVY12_1X24 = 0x2020,
> +	VIDEO_BUS_FMT_VYUY12_1X24 = 0x2021,
> +	VIDEO_BUS_FMT_YUYV12_1X24 = 0x2022,
> +	VIDEO_BUS_FMT_YVYU12_1X24 = 0x2023,
> +
> +	/* Bayer - next is 0x3019 */
> +	VIDEO_BUS_FMT_SBGGR8_1X8 = 0x3001,
> +	VIDEO_BUS_FMT_SGBRG8_1X8 = 0x3013,
> +	VIDEO_BUS_FMT_SGRBG8_1X8 = 0x3002,
> +	VIDEO_BUS_FMT_SRGGB8_1X8 = 0x3014,
> +	VIDEO_BUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> +	VIDEO_BUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> +	VIDEO_BUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> +	VIDEO_BUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
> +	VIDEO_BUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
> +	VIDEO_BUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
> +	VIDEO_BUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
> +	VIDEO_BUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
> +	VIDEO_BUS_FMT_SBGGR10_1X10 = 0x3007,
> +	VIDEO_BUS_FMT_SGBRG10_1X10 = 0x300e,
> +	VIDEO_BUS_FMT_SGRBG10_1X10 = 0x300a,
> +	VIDEO_BUS_FMT_SRGGB10_1X10 = 0x300f,
> +	VIDEO_BUS_FMT_SBGGR12_1X12 = 0x3008,
> +	VIDEO_BUS_FMT_SGBRG12_1X12 = 0x3010,
> +	VIDEO_BUS_FMT_SGRBG12_1X12 = 0x3011,
> +	VIDEO_BUS_FMT_SRGGB12_1X12 = 0x3012,
> +
> +	/* JPEG compressed formats - next is 0x4002 */
> +	VIDEO_BUS_FMT_JPEG_1X8 = 0x4001,
> +
> +	/* Vendor specific formats - next is 0x5002 */
> +
> +	/* S5C73M3 sensor specific interleaved UYVY and JPEG */
> +	VIDEO_BUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
> +
> +	/* HSV - next is 0x6002 */
> +	VIDEO_BUS_FMT_AHSV8888_1X32 = 0x6001,
> +};
> +
> +#endif /* __LINUX_VIDEO_BUS_FORMAT_H */



-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1117 bytes --]

On Mon, Sep 29, 2014 at 04:02:39PM +0200, Boris Brezillon wrote:
> Rename mediabus formats and move the enum into a separate header file so
> that it can be used by DRM/KMS subsystem without any reference to the V4L2
> subsystem.
> 
> Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
> definitions.
> 
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>  include/uapi/linux/Kbuild             |   1 +
>  include/uapi/linux/v4l2-mediabus.h    | 183 +++++++++++++++-------------------
>  include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++
>  3 files changed, 207 insertions(+), 104 deletions(-)
>  create mode 100644 include/uapi/linux/video-bus-format.h

Hi Mauro,

Do you have any objections to me merging patches 1 and 2 through the
drm/panel tree given the dependency of the later patches in the series
on these new constants? If you want I can provide a stable branch once
v3.18-rc1 is out for you to pull into you tree to resolve possible
conflicts.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Laurent Pinchart]

Hi Boris,

Thank you for the patch.

On Monday 29 September 2014 16:02:39 Boris Brezillon wrote:
> Rename mediabus formats and move the enum into a separate header file so
> that it can be used by DRM/KMS subsystem without any reference to the V4L2
> subsystem.
> 
> Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
> definitions.
> 
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>  include/uapi/linux/Kbuild             |   1 +
>  include/uapi/linux/v4l2-mediabus.h    | 183 +++++++++++++------------------
>  include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++
>  3 files changed, 207 insertions(+), 104 deletions(-)
>  create mode 100644 include/uapi/linux/video-bus-format.h

One of the self-inflicted rules in V4L2 is to properly document every new 
media bus format when adding it to the kernel. The documentation is located in 
Documentation/DocBook/media/v4l/subdev-formats.xml. If we move the formats to 
a centralized header (which I believe is a good idea), we should also update 
the documentation, and possibly its location. I really want to avoid getting 
undocumented formats merged, and this will happen if we don't make the rule 
clear and/or don't make the documentation easily accessible.

Incidentally, patch 2/5 in this series is missing a documentation update ;-)

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Boris Brezillon]

On Mon, 29 Sep 2014 23:41:09 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> Hi Boris,
> 
> Thank you for the patch.
> 
> On Monday 29 September 2014 16:02:39 Boris Brezillon wrote:
> > Rename mediabus formats and move the enum into a separate header file so
> > that it can be used by DRM/KMS subsystem without any reference to the V4L2
> > subsystem.
> > 
> > Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
> > definitions.
> > 
> > Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> > Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> > ---
> >  include/uapi/linux/Kbuild             |   1 +
> >  include/uapi/linux/v4l2-mediabus.h    | 183 +++++++++++++------------------
> >  include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++
> >  3 files changed, 207 insertions(+), 104 deletions(-)
> >  create mode 100644 include/uapi/linux/video-bus-format.h
> 
> One of the self-inflicted rules in V4L2 is to properly document every new 
> media bus format when adding it to the kernel. The documentation is located in 
> Documentation/DocBook/media/v4l/subdev-formats.xml. If we move the formats to 
> a centralized header (which I believe is a good idea), we should also update 
> the documentation, and possibly its location. I really want to avoid getting 
> undocumented formats merged, and this will happen if we don't make the rule 
> clear and/or don't make the documentation easily accessible.

Any idea where this new documentation should go
(Documentation/DocBook/video/video-bus-formats.xml) ?

> 
> Incidentally, patch 2/5 in this series is missing a documentation update ;-)

Yep, regarding this patch, I wonder if it's really necessary to add
new formats to the v4l2_mbus_pixelcode enum.
If we want to move to this new common definition (across the video
related subsytems), we should deprecate the old enum
v4l2_mbus_pixelcode, and this start by not adding new formats, don't
you think ?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 890 bytes --]

On Tue, Sep 30, 2014 at 09:37:57AM +0200, Boris Brezillon wrote:
> On Mon, 29 Sep 2014 23:41:09 +0300
> Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
[...]
> > Incidentally, patch 2/5 in this series is missing a documentation update ;-)
> 
> Yep, regarding this patch, I wonder if it's really necessary to add
> new formats to the v4l2_mbus_pixelcode enum.
> If we want to move to this new common definition (across the video
> related subsytems), we should deprecate the old enum
> v4l2_mbus_pixelcode, and this start by not adding new formats, don't
> you think ?

I agree in general, but I think it could prove problematic in practice.
If somebody wants to use one of the new codes but is using the V4L2 enum
they have a problem.

That said, given that there is now a unified enum people will hopefully
start converting drivers to it instead.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Boris Brezillon]

On Tue, 30 Sep 2014 10:39:53 +0200
Thierry Reding <thierry.reding@gmail.com> wrote:

> On Tue, Sep 30, 2014 at 09:37:57AM +0200, Boris Brezillon wrote:
> > On Mon, 29 Sep 2014 23:41:09 +0300
> > Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:
> [...]
> > > Incidentally, patch 2/5 in this series is missing a documentation update ;-)
> > 
> > Yep, regarding this patch, I wonder if it's really necessary to add
> > new formats to the v4l2_mbus_pixelcode enum.
> > If we want to move to this new common definition (across the video
> > related subsytems), we should deprecate the old enum
> > v4l2_mbus_pixelcode, and this start by not adding new formats, don't
> > you think ?
> 
> I agree in general, but I think it could prove problematic in practice.
> If somebody wants to use one of the new codes but is using the V4L2 enum
> they have a problem.
> 
> That said, given that there is now a unified enum people will hopefully
> start converting drivers to it instead.

I'm more worried about user-space lib/programs as this header is part
of the uapi...

But let's be optimistic here and keep porting new formats to
v4l2_mbus_pixelcode enum ;-).

Anyway, I still don't know where to put the documentation. Dropping a
new video format doc without any context (I mean subdev-formats.xml is
included in media documentation, but there's no generic video doc yet)
is a bit weird...

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Laurent Pinchart]

Hi Boris,

On Tuesday 30 September 2014 11:44:23 Boris Brezillon wrote:
> On Tue, 30 Sep 2014 10:39:53 +0200 Thierry Reding wrote:
> > On Tue, Sep 30, 2014 at 09:37:57AM +0200, Boris Brezillon wrote:
> >> On Mon, 29 Sep 2014 23:41:09 +0300 Laurent Pinchart wrote:
> >
> > [...]
> > 
> >>> Incidentally, patch 2/5 in this series is missing a documentation
> >>> update ;-)
> >>
> >> Yep, regarding this patch, I wonder if it's really necessary to add
> >> new formats to the v4l2_mbus_pixelcode enum.
> >> If we want to move to this new common definition (across the video
> >> related subsytems), we should deprecate the old enum
> >> v4l2_mbus_pixelcode, and this start by not adding new formats, don't
> >> you think ?
> > 
> > I agree in general, but I think it could prove problematic in practice.
> > If somebody wants to use one of the new codes but is using the V4L2 enum
> > they have a problem.
> > 
> > That said, given that there is now a unified enum people will hopefully
> > start converting drivers to it instead.
> 
> I'm more worried about user-space lib/programs as this header is part
> of the uapi...
> 
> But let's be optimistic here and keep porting new formats to
> v4l2_mbus_pixelcode enum ;-).

I think we should try to keep the two in sync, until we can remove the 
v4l2_mbus_pixelcode enum (I know, I'm being utopian here).

However, I really want all pixel codes to be properly documented, regardless 
of whether we add them to v4l2_mbus_pixelcode or not.

> Anyway, I still don't know where to put the documentation. Dropping a
> new video format doc without any context (I mean subdev-formats.xml is
> included in media documentation, but there's no generic video doc yet)
> is a bit weird...

Now that's a good question. We could start a generic video docbook 
documentation. As I expect more infrastructure to be shared between V4L2 and 
DRM (and, who knows, FBDEV...) over time, I think that would be a good move. 
However docbook doesn't seem to be in the DRM developers' good books, so this 
might be frown upon. We could also use a plain text, kerneldoc-like format for 
the common documentation, but the formats would then disappear from the V4L2 
documentation, which isn't a very good idea. For that reason I would favour 
docbook.

I've CC'ed Hans Verkuil who might want to share his opinion on the matter.

-- 
Regards,

Laurent Pinchart

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Boris Brezillon]

Hi Laurent,

On Wed, 01 Oct 2014 00:00:50 +0300
Laurent Pinchart <laurent.pinchart@ideasonboard.com> wrote:

> Hi Boris,
> 
> On Tuesday 30 September 2014 11:44:23 Boris Brezillon wrote:
> > On Tue, 30 Sep 2014 10:39:53 +0200 Thierry Reding wrote:
> > > On Tue, Sep 30, 2014 at 09:37:57AM +0200, Boris Brezillon wrote:
> > >> On Mon, 29 Sep 2014 23:41:09 +0300 Laurent Pinchart wrote:
> > >
> > > [...]
> > > 
> > >>> Incidentally, patch 2/5 in this series is missing a documentation
> > >>> update ;-)
> > >>
> > >> Yep, regarding this patch, I wonder if it's really necessary to add
> > >> new formats to the v4l2_mbus_pixelcode enum.
> > >> If we want to move to this new common definition (across the video
> > >> related subsytems), we should deprecate the old enum
> > >> v4l2_mbus_pixelcode, and this start by not adding new formats, don't
> > >> you think ?
> > > 
> > > I agree in general, but I think it could prove problematic in practice.
> > > If somebody wants to use one of the new codes but is using the V4L2 enum
> > > they have a problem.
> > > 
> > > That said, given that there is now a unified enum people will hopefully
> > > start converting drivers to it instead.
> > 
> > I'm more worried about user-space lib/programs as this header is part
> > of the uapi...
> > 
> > But let's be optimistic here and keep porting new formats to
> > v4l2_mbus_pixelcode enum ;-).
> 
> I think we should try to keep the two in sync, until we can remove the 
> v4l2_mbus_pixelcode enum (I know, I'm being utopian here).
> 
> However, I really want all pixel codes to be properly documented, regardless 
> of whether we add them to v4l2_mbus_pixelcode or not.
> 
> > Anyway, I still don't know where to put the documentation. Dropping a
> > new video format doc without any context (I mean subdev-formats.xml is
> > included in media documentation, but there's no generic video doc yet)
> > is a bit weird...
> 
> Now that's a good question. We could start a generic video docbook 
> documentation. As I expect more infrastructure to be shared between V4L2 and 
> DRM (and, who knows, FBDEV...) over time, I think that would be a good move. 
> However docbook doesn't seem to be in the DRM developers' good books, so this 
> might be frown upon. We could also use a plain text, kerneldoc-like format for 
> the common documentation, but the formats would then disappear from the V4L2 
> documentation, which isn't a very good idea. For that reason I would favour 
> docbook.
> 
> I've CC'ed Hans Verkuil who might want to share his opinion on the matter.
> 

I started to write a video-formats.xml file (actually I copied the
subdev-formats.xml file and renamed v4l2-mbus into video-bus :-)), but
these files cannot be used without the proper video_api.tmpl file, and
I don't feel like I'm the one that should start writing this
documentation (or at least I'd need some help).

Anyway, even if you think I should write this doc, can we get this
series mainlined first so that my HLCDC driver can make it into 3.19 ?

Best Regards,

Boris

-- 
Boris Brezillon, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com

Re: [PATCH v2 1/5] video: move mediabus format definition to a more standard place

[Hans Verkuil]

Hi Boris, Laurent,

My apologies, I missed this patch when it was posted.

First of all, please convert all existing kernel drivers that use V4L2_MBUS_FMT
to the new macro. It's easy to automate, and I see no reason why we shouldn't
do this.

If you don't do that now, then we'll be stuck with two naming conventions
in the kernel for a long time.

Actually, to be explicit, I will NACK this if this conversion isn't done
as part of the patch series.

Also add something like:

#ifdef __KERNEL__
#error Use video-bus-format.h instead of v4l2-mediabus.h
#else
#warning Use video-bus-format.h instead of v4l2-mediabus.h
#endif

to the old header to prevent future drivers from using it. I'm not sure
about the warning when included by userspace applications. I personally
think it makes sense. While everyone claims now to keep the two headers
in sync, I think that in practice this will not work. Freezing the old
header and only adding new values to the new header is better.

Secondly, is there any reason why this shouldn't be named media-bus-format.h
instead? Besides regular video these busses can also carry VBI data or even
audio. I prefer the more generic term 'media'. Besides, it's already called a
mediabus format, just with a V4L2 prefix, so why not keep that name? Less
confusing for existing users of this header.

Thirdly, as others mentioned, the updated documentation must be part of the
patch series. I'll NACK it if it isn't. One reason why V4L2 has really good
API documentation is the strict requirement that patches that touch on the
userspace API must also update documentation.

It happened too often that developers swear up and down that they will update
the documentation later, and then they don't.

So, based on the above points:

Nacked-by: Hans Verkuil <hans.verkuil@cisco.com>

But it really shouldn't be hard to fix it because I do like the idea behind
it very much.

Apologies once again for the late reply and thanks to Laurent for asking me
to review this.

Regards,

	Hans

On 09/29/2014 04:02 PM, Boris Brezillon wrote:
> Rename mediabus formats and move the enum into a separate header file so
> that it can be used by DRM/KMS subsystem without any reference to the V4L2
> subsystem.
> 
> Old V4L2_MBUS_FMT_ definitions are now macros that points to VIDEO_BUS_FMT_
> definitions.
> 
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>
> Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> ---
>  include/uapi/linux/Kbuild             |   1 +
>  include/uapi/linux/v4l2-mediabus.h    | 183 +++++++++++++++-------------------
>  include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++
>  3 files changed, 207 insertions(+), 104 deletions(-)
>  create mode 100644 include/uapi/linux/video-bus-format.h
> 
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index be88166..8712730 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -410,6 +410,7 @@ header-y += veth.h
>  header-y += vfio.h
>  header-y += vhost.h
>  header-y += videodev2.h
> +header-y += video-bus-format.h
>  header-y += virtio_9p.h
>  header-y += virtio_balloon.h
>  header-y += virtio_blk.h
> diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
> index 1445e85..7b0a06c 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -13,118 +13,93 @@
>  
>  #include <linux/types.h>
>  #include <linux/videodev2.h>
> +#include <linux/video-bus-format.h>
>  
> -/*
> - * These pixel codes uniquely identify data formats on the media bus. Mostly
> - * they correspond to similarly named V4L2_PIX_FMT_* formats, format 0 is
> - * reserved, V4L2_MBUS_FMT_FIXED shall be used by host-client pairs, where the
> - * data format is fixed. Additionally, "2X8" means that one pixel is transferred
> - * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
> - * transferred over the bus: "LE" means that the least significant bits are
> - * transferred first, "BE" means that the most significant bits are transferred
> - * first, and "PADHI" and "PADLO" define which bits - low or high, in the
> - * incomplete high byte, are filled with padding bits.
> - *
> - * The pixel codes are grouped by type, bus_width, bits per component, samples
> - * per pixel and order of subsamples. Numerical values are sorted using generic
> - * numerical sort order (8 thus comes before 10).
> - *
> - * As their value can't change when a new pixel code is inserted in the
> - * enumeration, the pixel codes are explicitly given a numerical value. The next
> - * free values for each category are listed below, update them when inserting
> - * new pixel codes.
> - */
> -enum v4l2_mbus_pixelcode {
> -	V4L2_MBUS_FMT_FIXED = 0x0001,
> +#define VIDEO_BUS_TO_V4L2_MBUS(x)	V4L2_MBUS_FMT_ ## x = VIDEO_BUS_FMT_ ## x
>  
> -	/* RGB - next is 0x100e */
> -	V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
> -	V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
> -	V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
> -	V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
> -	V4L2_MBUS_FMT_BGR565_2X8_BE = 0x1005,
> -	V4L2_MBUS_FMT_BGR565_2X8_LE = 0x1006,
> -	V4L2_MBUS_FMT_RGB565_2X8_BE = 0x1007,
> -	V4L2_MBUS_FMT_RGB565_2X8_LE = 0x1008,
> -	V4L2_MBUS_FMT_RGB666_1X18 = 0x1009,
> -	V4L2_MBUS_FMT_RGB888_1X24 = 0x100a,
> -	V4L2_MBUS_FMT_RGB888_2X12_BE = 0x100b,
> -	V4L2_MBUS_FMT_RGB888_2X12_LE = 0x100c,
> -	V4L2_MBUS_FMT_ARGB8888_1X32 = 0x100d,
> +enum v4l2_mbus_pixelcode {
> +	VIDEO_BUS_TO_V4L2_MBUS(FIXED),
>  
> -	/* YUV (including grey) - next is 0x2024 */
> -	V4L2_MBUS_FMT_Y8_1X8 = 0x2001,
> -	V4L2_MBUS_FMT_UV8_1X8 = 0x2015,
> -	V4L2_MBUS_FMT_UYVY8_1_5X8 = 0x2002,
> -	V4L2_MBUS_FMT_VYUY8_1_5X8 = 0x2003,
> -	V4L2_MBUS_FMT_YUYV8_1_5X8 = 0x2004,
> -	V4L2_MBUS_FMT_YVYU8_1_5X8 = 0x2005,
> -	V4L2_MBUS_FMT_UYVY8_2X8 = 0x2006,
> -	V4L2_MBUS_FMT_VYUY8_2X8 = 0x2007,
> -	V4L2_MBUS_FMT_YUYV8_2X8 = 0x2008,
> -	V4L2_MBUS_FMT_YVYU8_2X8 = 0x2009,
> -	V4L2_MBUS_FMT_Y10_1X10 = 0x200a,
> -	V4L2_MBUS_FMT_UYVY10_2X10 = 0x2018,
> -	V4L2_MBUS_FMT_VYUY10_2X10 = 0x2019,
> -	V4L2_MBUS_FMT_YUYV10_2X10 = 0x200b,
> -	V4L2_MBUS_FMT_YVYU10_2X10 = 0x200c,
> -	V4L2_MBUS_FMT_Y12_1X12 = 0x2013,
> -	V4L2_MBUS_FMT_UYVY8_1X16 = 0x200f,
> -	V4L2_MBUS_FMT_VYUY8_1X16 = 0x2010,
> -	V4L2_MBUS_FMT_YUYV8_1X16 = 0x2011,
> -	V4L2_MBUS_FMT_YVYU8_1X16 = 0x2012,
> -	V4L2_MBUS_FMT_YDYUYDYV8_1X16 = 0x2014,
> -	V4L2_MBUS_FMT_UYVY10_1X20 = 0x201a,
> -	V4L2_MBUS_FMT_VYUY10_1X20 = 0x201b,
> -	V4L2_MBUS_FMT_YUYV10_1X20 = 0x200d,
> -	V4L2_MBUS_FMT_YVYU10_1X20 = 0x200e,
> -	V4L2_MBUS_FMT_YUV10_1X30 = 0x2016,
> -	V4L2_MBUS_FMT_AYUV8_1X32 = 0x2017,
> -	V4L2_MBUS_FMT_UYVY12_2X12 = 0x201c,
> -	V4L2_MBUS_FMT_VYUY12_2X12 = 0x201d,
> -	V4L2_MBUS_FMT_YUYV12_2X12 = 0x201e,
> -	V4L2_MBUS_FMT_YVYU12_2X12 = 0x201f,
> -	V4L2_MBUS_FMT_UYVY12_1X24 = 0x2020,
> -	V4L2_MBUS_FMT_VYUY12_1X24 = 0x2021,
> -	V4L2_MBUS_FMT_YUYV12_1X24 = 0x2022,
> -	V4L2_MBUS_FMT_YVYU12_1X24 = 0x2023,
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB444_2X8_PADHI_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB444_2X8_PADHI_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB555_2X8_PADHI_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB555_2X8_PADHI_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(BGR565_2X8_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(BGR565_2X8_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB565_2X8_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB565_2X8_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB666_1X18),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB888_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(ARGB8888_1X32),
>  
> -	/* Bayer - next is 0x3019 */
> -	V4L2_MBUS_FMT_SBGGR8_1X8 = 0x3001,
> -	V4L2_MBUS_FMT_SGBRG8_1X8 = 0x3013,
> -	V4L2_MBUS_FMT_SGRBG8_1X8 = 0x3002,
> -	V4L2_MBUS_FMT_SRGGB8_1X8 = 0x3014,
> -	V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> -	V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> -	V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> -	V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
> -	V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
> -	V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
> -	V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
> -	V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
> -	V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
> -	V4L2_MBUS_FMT_SBGGR10_1X10 = 0x3007,
> -	V4L2_MBUS_FMT_SGBRG10_1X10 = 0x300e,
> -	V4L2_MBUS_FMT_SGRBG10_1X10 = 0x300a,
> -	V4L2_MBUS_FMT_SRGGB10_1X10 = 0x300f,
> -	V4L2_MBUS_FMT_SBGGR12_1X12 = 0x3008,
> -	V4L2_MBUS_FMT_SGBRG12_1X12 = 0x3010,
> -	V4L2_MBUS_FMT_SGRBG12_1X12 = 0x3011,
> -	V4L2_MBUS_FMT_SRGGB12_1X12 = 0x3012,
> +	VIDEO_BUS_TO_V4L2_MBUS(Y8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(UV8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_1_5X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_2X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(Y10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU10_2X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(Y12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(YDYUYDYV8_1X16),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU10_1X20),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUV10_1X30),
> +	VIDEO_BUS_TO_V4L2_MBUS(AYUV8_1X32),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU12_2X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(UYVY12_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(VYUY12_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(YUYV12_1X24),
> +	VIDEO_BUS_TO_V4L2_MBUS(YVYU12_1X24),
>  
> -	/* JPEG compressed formats - next is 0x4002 */
> -	V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_ALAW8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_DPCM8_1X8),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADHI_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADHI_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADLO_BE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_2X8_PADLO_LE),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB10_1X10),
> +	VIDEO_BUS_TO_V4L2_MBUS(SBGGR12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGBRG12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(SGRBG12_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(SRGGB12_1X12),
>  
> -	/* Vendor specific formats - next is 0x5002 */
> +	VIDEO_BUS_TO_V4L2_MBUS(JPEG_1X8),
>  
> -	/* S5C73M3 sensor specific interleaved UYVY and JPEG */
> -	V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
> +	VIDEO_BUS_TO_V4L2_MBUS(S5C_UYVY_JPEG_1X8),
>  
> -	/* HSV - next is 0x6002 */
> -	V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001,
> +	VIDEO_BUS_TO_V4L2_MBUS(AHSV8888_1X32),
>  };
>  
>  /**
> diff --git a/include/uapi/linux/video-bus-format.h b/include/uapi/linux/video-bus-format.h
> new file mode 100644
> index 0000000..4abbd5d
> --- /dev/null
> +++ b/include/uapi/linux/video-bus-format.h
> @@ -0,0 +1,127 @@
> +/*
> + * Video Bus API header
> + *
> + * Copyright (C) 2009, Guennadi Liakhovetski <g.liakhovetski@gmx.de>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +
> +#ifndef __LINUX_VIDEO_BUS_FORMAT_H
> +#define __LINUX_VIDEO_BUS_FORMAT_H
> +
> +/*
> + * These bus formats uniquely identify data formats on the data bus. Mostly
> + * they correspond to similarly named VIDEO_PIX_FMT_* formats, format 0 is
> + * reserved, VIDEO_BUS_FMT_FIXED shall be used by host-client pairs, where the
> + * data format is fixed. Additionally, "2X8" means that one pixel is transferred
> + * in two 8-bit samples, "BE" or "LE" specify in which order those samples are
> + * transferred over the bus: "LE" means that the least significant bits are
> + * transferred first, "BE" means that the most significant bits are transferred
> + * first, and "PADHI" and "PADLO" define which bits - low or high, in the
> + * incomplete high byte, are filled with padding bits.
> + *
> + * The bus formats are grouped by type, bus_width, bits per component, samples
> + * per pixel and order of subsamples. Numerical values are sorted using generic
> + * numerical sort order (8 thus comes before 10).
> + *
> + * As their value can't change when a new bus format is inserted in the
> + * enumeration, the bus formats are explicitly given a numerical value. The next
> + * free values for each category are listed below, update them when inserting
> + * new pixel codes.
> + */
> +enum video_bus_format {
> +	VIDEO_BUS_FMT_FIXED = 0x0001,
> +
> +	/* RGB - next is 0x100e */
> +	VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
> +	VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
> +	VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
> +	VIDEO_BUS_FMT_RGB555_2X8_PADHI_LE = 0x1004,
> +	VIDEO_BUS_FMT_BGR565_2X8_BE = 0x1005,
> +	VIDEO_BUS_FMT_BGR565_2X8_LE = 0x1006,
> +	VIDEO_BUS_FMT_RGB565_2X8_BE = 0x1007,
> +	VIDEO_BUS_FMT_RGB565_2X8_LE = 0x1008,
> +	VIDEO_BUS_FMT_RGB666_1X18 = 0x1009,
> +	VIDEO_BUS_FMT_RGB888_1X24 = 0x100a,
> +	VIDEO_BUS_FMT_RGB888_2X12_BE = 0x100b,
> +	VIDEO_BUS_FMT_RGB888_2X12_LE = 0x100c,
> +	VIDEO_BUS_FMT_ARGB8888_1X32 = 0x100d,
> +
> +	/* YUV (including grey) - next is 0x2024 */
> +	VIDEO_BUS_FMT_Y8_1X8 = 0x2001,
> +	VIDEO_BUS_FMT_UV8_1X8 = 0x2015,
> +	VIDEO_BUS_FMT_UYVY8_1_5X8 = 0x2002,
> +	VIDEO_BUS_FMT_VYUY8_1_5X8 = 0x2003,
> +	VIDEO_BUS_FMT_YUYV8_1_5X8 = 0x2004,
> +	VIDEO_BUS_FMT_YVYU8_1_5X8 = 0x2005,
> +	VIDEO_BUS_FMT_UYVY8_2X8 = 0x2006,
> +	VIDEO_BUS_FMT_VYUY8_2X8 = 0x2007,
> +	VIDEO_BUS_FMT_YUYV8_2X8 = 0x2008,
> +	VIDEO_BUS_FMT_YVYU8_2X8 = 0x2009,
> +	VIDEO_BUS_FMT_Y10_1X10 = 0x200a,
> +	VIDEO_BUS_FMT_UYVY10_2X10 = 0x2018,
> +	VIDEO_BUS_FMT_VYUY10_2X10 = 0x2019,
> +	VIDEO_BUS_FMT_YUYV10_2X10 = 0x200b,
> +	VIDEO_BUS_FMT_YVYU10_2X10 = 0x200c,
> +	VIDEO_BUS_FMT_Y12_1X12 = 0x2013,
> +	VIDEO_BUS_FMT_UYVY8_1X16 = 0x200f,
> +	VIDEO_BUS_FMT_VYUY8_1X16 = 0x2010,
> +	VIDEO_BUS_FMT_YUYV8_1X16 = 0x2011,
> +	VIDEO_BUS_FMT_YVYU8_1X16 = 0x2012,
> +	VIDEO_BUS_FMT_YDYUYDYV8_1X16 = 0x2014,
> +	VIDEO_BUS_FMT_UYVY10_1X20 = 0x201a,
> +	VIDEO_BUS_FMT_VYUY10_1X20 = 0x201b,
> +	VIDEO_BUS_FMT_YUYV10_1X20 = 0x200d,
> +	VIDEO_BUS_FMT_YVYU10_1X20 = 0x200e,
> +	VIDEO_BUS_FMT_YUV10_1X30 = 0x2016,
> +	VIDEO_BUS_FMT_AYUV8_1X32 = 0x2017,
> +	VIDEO_BUS_FMT_UYVY12_2X12 = 0x201c,
> +	VIDEO_BUS_FMT_VYUY12_2X12 = 0x201d,
> +	VIDEO_BUS_FMT_YUYV12_2X12 = 0x201e,
> +	VIDEO_BUS_FMT_YVYU12_2X12 = 0x201f,
> +	VIDEO_BUS_FMT_UYVY12_1X24 = 0x2020,
> +	VIDEO_BUS_FMT_VYUY12_1X24 = 0x2021,
> +	VIDEO_BUS_FMT_YUYV12_1X24 = 0x2022,
> +	VIDEO_BUS_FMT_YVYU12_1X24 = 0x2023,
> +
> +	/* Bayer - next is 0x3019 */
> +	VIDEO_BUS_FMT_SBGGR8_1X8 = 0x3001,
> +	VIDEO_BUS_FMT_SGBRG8_1X8 = 0x3013,
> +	VIDEO_BUS_FMT_SGRBG8_1X8 = 0x3002,
> +	VIDEO_BUS_FMT_SRGGB8_1X8 = 0x3014,
> +	VIDEO_BUS_FMT_SBGGR10_ALAW8_1X8 = 0x3015,
> +	VIDEO_BUS_FMT_SGBRG10_ALAW8_1X8 = 0x3016,
> +	VIDEO_BUS_FMT_SGRBG10_ALAW8_1X8 = 0x3017,
> +	VIDEO_BUS_FMT_SRGGB10_ALAW8_1X8 = 0x3018,
> +	VIDEO_BUS_FMT_SBGGR10_DPCM8_1X8 = 0x300b,
> +	VIDEO_BUS_FMT_SGBRG10_DPCM8_1X8 = 0x300c,
> +	VIDEO_BUS_FMT_SGRBG10_DPCM8_1X8 = 0x3009,
> +	VIDEO_BUS_FMT_SRGGB10_DPCM8_1X8 = 0x300d,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_BE = 0x3003,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_LE = 0x3004,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_BE = 0x3005,
> +	VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_LE = 0x3006,
> +	VIDEO_BUS_FMT_SBGGR10_1X10 = 0x3007,
> +	VIDEO_BUS_FMT_SGBRG10_1X10 = 0x300e,
> +	VIDEO_BUS_FMT_SGRBG10_1X10 = 0x300a,
> +	VIDEO_BUS_FMT_SRGGB10_1X10 = 0x300f,
> +	VIDEO_BUS_FMT_SBGGR12_1X12 = 0x3008,
> +	VIDEO_BUS_FMT_SGBRG12_1X12 = 0x3010,
> +	VIDEO_BUS_FMT_SGRBG12_1X12 = 0x3011,
> +	VIDEO_BUS_FMT_SRGGB12_1X12 = 0x3012,
> +
> +	/* JPEG compressed formats - next is 0x4002 */
> +	VIDEO_BUS_FMT_JPEG_1X8 = 0x4001,
> +
> +	/* Vendor specific formats - next is 0x5002 */
> +
> +	/* S5C73M3 sensor specific interleaved UYVY and JPEG */
> +	VIDEO_BUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
> +
> +	/* HSV - next is 0x6002 */
> +	VIDEO_BUS_FMT_AHSV8888_1X32 = 0x6001,
> +};
> +
> +#endif /* __LINUX_VIDEO_BUS_FORMAT_H */
> 

Re: [PATCH v2 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats

[Mauro Carvalho Chehab]

Em Mon, 29 Sep 2014 16:02:40 +0200
Boris Brezillon <boris.brezillon@free-electrons.com> escreveu:

> Add RGB444 format using a 12 bits bus and RGB565 using a 16 bits bus.
> 
> These formats will later be used by atmel-hlcdc driver.
> 
> Signed-off-by: Boris BREZILLON <boris.brezillon@free-electrons.com>

Not sure if it is too late, but this patch were hidden somewere on my
queue... so:

Acked-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

> ---
>  include/uapi/linux/v4l2-mediabus.h    | 2 ++
>  include/uapi/linux/video-bus-format.h | 4 +++-
>  2 files changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
> index 7b0a06c..05336d6 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -33,6 +33,8 @@ enum v4l2_mbus_pixelcode {
>  	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_BE),
>  	VIDEO_BUS_TO_V4L2_MBUS(RGB888_2X12_LE),
>  	VIDEO_BUS_TO_V4L2_MBUS(ARGB8888_1X32),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB444_1X12),
> +	VIDEO_BUS_TO_V4L2_MBUS(RGB565_1X16),
>  
>  	VIDEO_BUS_TO_V4L2_MBUS(Y8_1X8),
>  	VIDEO_BUS_TO_V4L2_MBUS(UV8_1X8),
> diff --git a/include/uapi/linux/video-bus-format.h b/include/uapi/linux/video-bus-format.h
> index 4abbd5d..f85f7ee 100644
> --- a/include/uapi/linux/video-bus-format.h
> +++ b/include/uapi/linux/video-bus-format.h
> @@ -34,7 +34,7 @@
>  enum video_bus_format {
>  	VIDEO_BUS_FMT_FIXED = 0x0001,
>  
> -	/* RGB - next is 0x100e */
> +	/* RGB - next is 0x1010 */
>  	VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE = 0x1001,
>  	VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE = 0x1002,
>  	VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE = 0x1003,
> @@ -48,6 +48,8 @@ enum video_bus_format {
>  	VIDEO_BUS_FMT_RGB888_2X12_BE = 0x100b,
>  	VIDEO_BUS_FMT_RGB888_2X12_LE = 0x100c,
>  	VIDEO_BUS_FMT_ARGB8888_1X32 = 0x100d,
> +	VIDEO_BUS_FMT_RGB444_1X12 = 0x100e,
> +	VIDEO_BUS_FMT_RGB565_1X16 = 0x100f,
>  
>  	/* YUV (including grey) - next is 0x2024 */
>  	VIDEO_BUS_FMT_Y8_1X8 = 0x2001,