* [PATCH 0/5] video: describe data bus formats
@ 2014-07-22 12:23 Boris BREZILLON
2014-07-22 12:23 ` [PATCH 1/5] video: move mediabus format definition to a more standard place Boris BREZILLON
` (5 more replies)
0 siblings, 6 replies; 13+ messages in thread
From: Boris BREZILLON @ 2014-07-22 12:23 UTC (permalink / raw)
To: Thierry Reding, Laurent Pinchart
Cc: David Airlie, dri-devel, linux-kernel, linux-api,
Mauro Carvalho Chehab, linux-media, 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.
The video bus formats are not documented yet (and I don't know where this doc
should be stored), but I'm pretty sure this version won't be the last one ;-).
Best Regards,
Boris
Boris BREZILLON (5):
video: move mediabus format definition to a more standard place
video: add RGB444_1X12 and RGB565_1X16 bus formats
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
drivers/gpu/drm/drm_crtc.c | 28 +++++
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, 251 insertions(+), 106 deletions(-)
create mode 100644 include/uapi/linux/video-bus-format.h
--
1.8.3.2
^ permalink raw reply [flat|nested] 13+ messages in thread* [PATCH 1/5] video: move mediabus format definition to a more standard place 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON @ 2014-07-22 12:23 ` Boris BREZILLON 2014-09-23 12:33 ` Guennadi Liakhovetski 2014-07-22 12:23 ` [PATCH 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats Boris BREZILLON ` (4 subsequent siblings) 5 siblings, 1 reply; 13+ messages in thread From: Boris BREZILLON @ 2014-07-22 12:23 UTC (permalink / raw) To: Thierry Reding, Laurent Pinchart Cc: David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media, 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> --- include/uapi/linux/Kbuild | 1 + include/uapi/linux/v4l2-mediabus.h | 183 ++++++++++++++-------------------- include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++ 3 files changed, 205 insertions(+), 106 deletions(-) create mode 100644 include/uapi/linux/video-bus-format.h diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild index 24e9033..371874b 100644 --- a/include/uapi/linux/Kbuild +++ b/include/uapi/linux/Kbuild @@ -408,6 +408,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..8c31f11 100644 --- a/include/uapi/linux/v4l2-mediabus.h +++ b/include/uapi/linux/v4l2-mediabus.h @@ -13,119 +13,90 @@ #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, - - /* 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, +#define V4L2_MBUS_FMT_FIXED VIDEO_BUS_FMT_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, +#define V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE +#define V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE +#define V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE +#define V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE VIDEO_BUS_FMT_RGB555_2X8_PADHI_LE +#define V4L2_MBUS_FMT_BGR565_2X8_BE VIDEO_BUS_FMT_BGR565_2X8_BE +#define V4L2_MBUS_FMT_BGR565_2X8_LE VIDEO_BUS_FMT_BGR565_2X8_LE +#define V4L2_MBUS_FMT_RGB565_2X8_BE VIDEO_BUS_FMT_RGB565_2X8_BE +#define V4L2_MBUS_FMT_RGB565_2X8_LE VIDEO_BUS_FMT_RGB565_2X8_LE +#define V4L2_MBUS_FMT_RGB666_1X18 VIDEO_BUS_FMT_RGB666_1X18 +#define V4L2_MBUS_FMT_RGB888_1X24 VIDEO_BUS_FMT_RGB888_1X24 +#define V4L2_MBUS_FMT_RGB888_2X12_BE VIDEO_BUS_FMT_RGB888_2X12_BE +#define V4L2_MBUS_FMT_RGB888_2X12_LE VIDEO_BUS_FMT_RGB888_2X12_LE +#define V4L2_MBUS_FMT_ARGB8888_1X32 VIDEO_BUS_FMT_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, +#define V4L2_MBUS_FMT_Y8_1X8 VIDEO_BUS_FMT_Y8_1X8 +#define V4L2_MBUS_FMT_UV8_1X8 VIDEO_BUS_FMT_UV8_1X8 +#define V4L2_MBUS_FMT_UYVY8_1_5X8 VIDEO_BUS_FMT_UYVY8_1_5X8 +#define V4L2_MBUS_FMT_VYUY8_1_5X8 VIDEO_BUS_FMT_VYUY8_1_5X8 +#define V4L2_MBUS_FMT_YUYV8_1_5X8 VIDEO_BUS_FMT_YUYV8_1_5X8 +#define V4L2_MBUS_FMT_YVYU8_1_5X8 VIDEO_BUS_FMT_YVYU8_1_5X8 +#define V4L2_MBUS_FMT_UYVY8_2X8 VIDEO_BUS_FMT_UYVY8_2X8 +#define V4L2_MBUS_FMT_VYUY8_2X8 VIDEO_BUS_FMT_VYUY8_2X8 +#define V4L2_MBUS_FMT_YUYV8_2X8 VIDEO_BUS_FMT_YUYV8_2X8 +#define V4L2_MBUS_FMT_YVYU8_2X8 VIDEO_BUS_FMT_YVYU8_2X8 +#define V4L2_MBUS_FMT_Y10_1X10 VIDEO_BUS_FMT_Y10_1X10 +#define V4L2_MBUS_FMT_UYVY10_2X10 VIDEO_BUS_FMT_UYVY10_2X10 +#define V4L2_MBUS_FMT_VYUY10_2X10 VIDEO_BUS_FMT_VYUY10_2X10 +#define V4L2_MBUS_FMT_YUYV10_2X10 VIDEO_BUS_FMT_YUYV10_2X10 +#define V4L2_MBUS_FMT_YVYU10_2X10 VIDEO_BUS_FMT_YVYU10_2X10 +#define V4L2_MBUS_FMT_Y12_1X12 VIDEO_BUS_FMT_Y12_1X12 +#define V4L2_MBUS_FMT_UYVY8_1X16 VIDEO_BUS_FMT_UYVY8_1X16 +#define V4L2_MBUS_FMT_VYUY8_1X16 VIDEO_BUS_FMT_VYUY8_1X16 +#define V4L2_MBUS_FMT_YUYV8_1X16 VIDEO_BUS_FMT_YUYV8_1X16 +#define V4L2_MBUS_FMT_YVYU8_1X16 VIDEO_BUS_FMT_YVYU8_1X16 +#define V4L2_MBUS_FMT_YDYUYDYV8_1X16 VIDEO_BUS_FMT_YDYUYDYV8_1X16 +#define V4L2_MBUS_FMT_UYVY10_1X20 VIDEO_BUS_FMT_UYVY10_1X20 +#define V4L2_MBUS_FMT_VYUY10_1X20 VIDEO_BUS_FMT_VYUY10_1X20 +#define V4L2_MBUS_FMT_YUYV10_1X20 VIDEO_BUS_FMT_YUYV10_1X20 +#define V4L2_MBUS_FMT_YVYU10_1X20 VIDEO_BUS_FMT_YVYU10_1X20 +#define V4L2_MBUS_FMT_YUV10_1X30 VIDEO_BUS_FMT_YUV10_1X30 +#define V4L2_MBUS_FMT_AYUV8_1X32 VIDEO_BUS_FMT_AYUV8_1X32 +#define V4L2_MBUS_FMT_UYVY12_2X12 VIDEO_BUS_FMT_UYVY12_2X12 +#define V4L2_MBUS_FMT_VYUY12_2X12 VIDEO_BUS_FMT_VYUY12_2X12 +#define V4L2_MBUS_FMT_YUYV12_2X12 VIDEO_BUS_FMT_YUYV12_2X12 +#define V4L2_MBUS_FMT_YVYU12_2X12 VIDEO_BUS_FMT_YVYU12_2X12 +#define V4L2_MBUS_FMT_UYVY12_1X24 VIDEO_BUS_FMT_UYVY12_1X24 +#define V4L2_MBUS_FMT_VYUY12_1X24 VIDEO_BUS_FMT_VYUY12_1X24 +#define V4L2_MBUS_FMT_YUYV12_1X24 VIDEO_BUS_FMT_YUYV12_1X24 +#define V4L2_MBUS_FMT_YVYU12_1X24 VIDEO_BUS_FMT_YVYU12_1X24 - /* JPEG compressed formats - next is 0x4002 */ - V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, +#define V4L2_MBUS_FMT_SBGGR8_1X8 VIDEO_BUS_FMT_SBGGR8_1X8 +#define V4L2_MBUS_FMT_SGBRG8_1X8 VIDEO_BUS_FMT_SGBRG8_1X8 +#define V4L2_MBUS_FMT_SGRBG8_1X8 VIDEO_BUS_FMT_SGRBG8_1X8 +#define V4L2_MBUS_FMT_SRGGB8_1X8 VIDEO_BUS_FMT_SRGGB8_1X8 +#define V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 VIDEO_BUS_FMT_SBGGR10_ALAW8_1X8 +#define V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 VIDEO_BUS_FMT_SGBRG10_ALAW8_1X8 +#define V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 VIDEO_BUS_FMT_SGRBG10_ALAW8_1X8 +#define V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 VIDEO_BUS_FMT_SRGGB10_ALAW8_1X8 +#define V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 VIDEO_BUS_FMT_SBGGR10_DPCM8_1X8 +#define V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 VIDEO_BUS_FMT_SGBRG10_DPCM8_1X8 +#define V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 VIDEO_BUS_FMT_SGRBG10_DPCM8_1X8 +#define V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 VIDEO_BUS_FMT_SRGGB10_DPCM8_1X8 +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_BE +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_LE +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_BE +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_LE +#define V4L2_MBUS_FMT_SBGGR10_1X10 VIDEO_BUS_FMT_SBGGR10_1X10 +#define V4L2_MBUS_FMT_SGBRG10_1X10 VIDEO_BUS_FMT_SGBRG10_1X10 +#define V4L2_MBUS_FMT_SGRBG10_1X10 VIDEO_BUS_FMT_SGRBG10_1X10 +#define V4L2_MBUS_FMT_SRGGB10_1X10 VIDEO_BUS_FMT_SRGGB10_1X10 +#define V4L2_MBUS_FMT_SBGGR12_1X12 VIDEO_BUS_FMT_SBGGR12_1X12 +#define V4L2_MBUS_FMT_SGBRG12_1X12 VIDEO_BUS_FMT_SGBRG12_1X12 +#define V4L2_MBUS_FMT_SGRBG12_1X12 VIDEO_BUS_FMT_SGRBG12_1X12 +#define V4L2_MBUS_FMT_SRGGB12_1X12 VIDEO_BUS_FMT_SRGGB12_1X12 - /* Vendor specific formats - next is 0x5002 */ +#define V4L2_MBUS_FMT_JPEG_1X8 VIDEO_BUS_FMT_JPEG_1X8 - /* S5C73M3 sensor specific interleaved UYVY and JPEG */ - V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001, +#define V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 VIDEO_BUS_FMT_S5C_UYVY_JPEG_1X8 - /* HSV - next is 0x6002 */ - V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001, -}; +#define V4L2_MBUS_FMT_AHSV8888_1X32 VIDEO_BUS_FMT_AHSV8888_1X32 /** * struct v4l2_mbus_framefmt - frame format on the media bus 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.8.3.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 1/5] video: move mediabus format definition to a more standard place 2014-07-22 12:23 ` [PATCH 1/5] video: move mediabus format definition to a more standard place Boris BREZILLON @ 2014-09-23 12:33 ` Guennadi Liakhovetski 2014-09-23 16:09 ` Boris BREZILLON 0 siblings, 1 reply; 13+ messages in thread From: Guennadi Liakhovetski @ 2014-09-23 12:33 UTC (permalink / raw) To: Boris BREZILLON Cc: Thierry Reding, Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media Hi Boris, On Tue, 22 Jul 2014, 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> In principle I find this a good idea, certainly it's good to reuse code. Just wondering, wouldn't it be better instead of adding those defines to define a macro like #define VIDEO_BUS_TO_MBUS(x) V4L2_MBUS_ ## x = VIDEO_BUS_ ## x and then do enum v4l2_mbus_pixelcode { VIDEO_BUS_TO_MBUS(FIXED), VIDEO_BUS_TO_MBUS(RGB444_2X8_PADHI_BE), ... }; ? I'm not very strong on this, I just think an enum is nicer than a bunch of defines and this way copy-paste errors are less likely, but if you or others strongly disagree - I won't insist :) Whether or not you decide to accept this proposal you have my Acked-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de> Thanks Guennadi > --- > include/uapi/linux/Kbuild | 1 + > include/uapi/linux/v4l2-mediabus.h | 183 ++++++++++++++-------------------- > include/uapi/linux/video-bus-format.h | 127 +++++++++++++++++++++++ > 3 files changed, 205 insertions(+), 106 deletions(-) > create mode 100644 include/uapi/linux/video-bus-format.h > > diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild > index 24e9033..371874b 100644 > --- a/include/uapi/linux/Kbuild > +++ b/include/uapi/linux/Kbuild > @@ -408,6 +408,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..8c31f11 100644 > --- a/include/uapi/linux/v4l2-mediabus.h > +++ b/include/uapi/linux/v4l2-mediabus.h > @@ -13,119 +13,90 @@ > > #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, > - > - /* 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, > +#define V4L2_MBUS_FMT_FIXED VIDEO_BUS_FMT_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, > +#define V4L2_MBUS_FMT_RGB444_2X8_PADHI_BE VIDEO_BUS_FMT_RGB444_2X8_PADHI_BE > +#define V4L2_MBUS_FMT_RGB444_2X8_PADHI_LE VIDEO_BUS_FMT_RGB444_2X8_PADHI_LE > +#define V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE VIDEO_BUS_FMT_RGB555_2X8_PADHI_BE > +#define V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE VIDEO_BUS_FMT_RGB555_2X8_PADHI_LE > +#define V4L2_MBUS_FMT_BGR565_2X8_BE VIDEO_BUS_FMT_BGR565_2X8_BE > +#define V4L2_MBUS_FMT_BGR565_2X8_LE VIDEO_BUS_FMT_BGR565_2X8_LE > +#define V4L2_MBUS_FMT_RGB565_2X8_BE VIDEO_BUS_FMT_RGB565_2X8_BE > +#define V4L2_MBUS_FMT_RGB565_2X8_LE VIDEO_BUS_FMT_RGB565_2X8_LE > +#define V4L2_MBUS_FMT_RGB666_1X18 VIDEO_BUS_FMT_RGB666_1X18 > +#define V4L2_MBUS_FMT_RGB888_1X24 VIDEO_BUS_FMT_RGB888_1X24 > +#define V4L2_MBUS_FMT_RGB888_2X12_BE VIDEO_BUS_FMT_RGB888_2X12_BE > +#define V4L2_MBUS_FMT_RGB888_2X12_LE VIDEO_BUS_FMT_RGB888_2X12_LE > +#define V4L2_MBUS_FMT_ARGB8888_1X32 VIDEO_BUS_FMT_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, > +#define V4L2_MBUS_FMT_Y8_1X8 VIDEO_BUS_FMT_Y8_1X8 > +#define V4L2_MBUS_FMT_UV8_1X8 VIDEO_BUS_FMT_UV8_1X8 > +#define V4L2_MBUS_FMT_UYVY8_1_5X8 VIDEO_BUS_FMT_UYVY8_1_5X8 > +#define V4L2_MBUS_FMT_VYUY8_1_5X8 VIDEO_BUS_FMT_VYUY8_1_5X8 > +#define V4L2_MBUS_FMT_YUYV8_1_5X8 VIDEO_BUS_FMT_YUYV8_1_5X8 > +#define V4L2_MBUS_FMT_YVYU8_1_5X8 VIDEO_BUS_FMT_YVYU8_1_5X8 > +#define V4L2_MBUS_FMT_UYVY8_2X8 VIDEO_BUS_FMT_UYVY8_2X8 > +#define V4L2_MBUS_FMT_VYUY8_2X8 VIDEO_BUS_FMT_VYUY8_2X8 > +#define V4L2_MBUS_FMT_YUYV8_2X8 VIDEO_BUS_FMT_YUYV8_2X8 > +#define V4L2_MBUS_FMT_YVYU8_2X8 VIDEO_BUS_FMT_YVYU8_2X8 > +#define V4L2_MBUS_FMT_Y10_1X10 VIDEO_BUS_FMT_Y10_1X10 > +#define V4L2_MBUS_FMT_UYVY10_2X10 VIDEO_BUS_FMT_UYVY10_2X10 > +#define V4L2_MBUS_FMT_VYUY10_2X10 VIDEO_BUS_FMT_VYUY10_2X10 > +#define V4L2_MBUS_FMT_YUYV10_2X10 VIDEO_BUS_FMT_YUYV10_2X10 > +#define V4L2_MBUS_FMT_YVYU10_2X10 VIDEO_BUS_FMT_YVYU10_2X10 > +#define V4L2_MBUS_FMT_Y12_1X12 VIDEO_BUS_FMT_Y12_1X12 > +#define V4L2_MBUS_FMT_UYVY8_1X16 VIDEO_BUS_FMT_UYVY8_1X16 > +#define V4L2_MBUS_FMT_VYUY8_1X16 VIDEO_BUS_FMT_VYUY8_1X16 > +#define V4L2_MBUS_FMT_YUYV8_1X16 VIDEO_BUS_FMT_YUYV8_1X16 > +#define V4L2_MBUS_FMT_YVYU8_1X16 VIDEO_BUS_FMT_YVYU8_1X16 > +#define V4L2_MBUS_FMT_YDYUYDYV8_1X16 VIDEO_BUS_FMT_YDYUYDYV8_1X16 > +#define V4L2_MBUS_FMT_UYVY10_1X20 VIDEO_BUS_FMT_UYVY10_1X20 > +#define V4L2_MBUS_FMT_VYUY10_1X20 VIDEO_BUS_FMT_VYUY10_1X20 > +#define V4L2_MBUS_FMT_YUYV10_1X20 VIDEO_BUS_FMT_YUYV10_1X20 > +#define V4L2_MBUS_FMT_YVYU10_1X20 VIDEO_BUS_FMT_YVYU10_1X20 > +#define V4L2_MBUS_FMT_YUV10_1X30 VIDEO_BUS_FMT_YUV10_1X30 > +#define V4L2_MBUS_FMT_AYUV8_1X32 VIDEO_BUS_FMT_AYUV8_1X32 > +#define V4L2_MBUS_FMT_UYVY12_2X12 VIDEO_BUS_FMT_UYVY12_2X12 > +#define V4L2_MBUS_FMT_VYUY12_2X12 VIDEO_BUS_FMT_VYUY12_2X12 > +#define V4L2_MBUS_FMT_YUYV12_2X12 VIDEO_BUS_FMT_YUYV12_2X12 > +#define V4L2_MBUS_FMT_YVYU12_2X12 VIDEO_BUS_FMT_YVYU12_2X12 > +#define V4L2_MBUS_FMT_UYVY12_1X24 VIDEO_BUS_FMT_UYVY12_1X24 > +#define V4L2_MBUS_FMT_VYUY12_1X24 VIDEO_BUS_FMT_VYUY12_1X24 > +#define V4L2_MBUS_FMT_YUYV12_1X24 VIDEO_BUS_FMT_YUYV12_1X24 > +#define V4L2_MBUS_FMT_YVYU12_1X24 VIDEO_BUS_FMT_YVYU12_1X24 > > - /* JPEG compressed formats - next is 0x4002 */ > - V4L2_MBUS_FMT_JPEG_1X8 = 0x4001, > +#define V4L2_MBUS_FMT_SBGGR8_1X8 VIDEO_BUS_FMT_SBGGR8_1X8 > +#define V4L2_MBUS_FMT_SGBRG8_1X8 VIDEO_BUS_FMT_SGBRG8_1X8 > +#define V4L2_MBUS_FMT_SGRBG8_1X8 VIDEO_BUS_FMT_SGRBG8_1X8 > +#define V4L2_MBUS_FMT_SRGGB8_1X8 VIDEO_BUS_FMT_SRGGB8_1X8 > +#define V4L2_MBUS_FMT_SBGGR10_ALAW8_1X8 VIDEO_BUS_FMT_SBGGR10_ALAW8_1X8 > +#define V4L2_MBUS_FMT_SGBRG10_ALAW8_1X8 VIDEO_BUS_FMT_SGBRG10_ALAW8_1X8 > +#define V4L2_MBUS_FMT_SGRBG10_ALAW8_1X8 VIDEO_BUS_FMT_SGRBG10_ALAW8_1X8 > +#define V4L2_MBUS_FMT_SRGGB10_ALAW8_1X8 VIDEO_BUS_FMT_SRGGB10_ALAW8_1X8 > +#define V4L2_MBUS_FMT_SBGGR10_DPCM8_1X8 VIDEO_BUS_FMT_SBGGR10_DPCM8_1X8 > +#define V4L2_MBUS_FMT_SGBRG10_DPCM8_1X8 VIDEO_BUS_FMT_SGBRG10_DPCM8_1X8 > +#define V4L2_MBUS_FMT_SGRBG10_DPCM8_1X8 VIDEO_BUS_FMT_SGRBG10_DPCM8_1X8 > +#define V4L2_MBUS_FMT_SRGGB10_DPCM8_1X8 VIDEO_BUS_FMT_SRGGB10_DPCM8_1X8 > +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_BE > +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE VIDEO_BUS_FMT_SBGGR10_2X8_PADHI_LE > +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_BE > +#define V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE VIDEO_BUS_FMT_SBGGR10_2X8_PADLO_LE > +#define V4L2_MBUS_FMT_SBGGR10_1X10 VIDEO_BUS_FMT_SBGGR10_1X10 > +#define V4L2_MBUS_FMT_SGBRG10_1X10 VIDEO_BUS_FMT_SGBRG10_1X10 > +#define V4L2_MBUS_FMT_SGRBG10_1X10 VIDEO_BUS_FMT_SGRBG10_1X10 > +#define V4L2_MBUS_FMT_SRGGB10_1X10 VIDEO_BUS_FMT_SRGGB10_1X10 > +#define V4L2_MBUS_FMT_SBGGR12_1X12 VIDEO_BUS_FMT_SBGGR12_1X12 > +#define V4L2_MBUS_FMT_SGBRG12_1X12 VIDEO_BUS_FMT_SGBRG12_1X12 > +#define V4L2_MBUS_FMT_SGRBG12_1X12 VIDEO_BUS_FMT_SGRBG12_1X12 > +#define V4L2_MBUS_FMT_SRGGB12_1X12 VIDEO_BUS_FMT_SRGGB12_1X12 > > - /* Vendor specific formats - next is 0x5002 */ > +#define V4L2_MBUS_FMT_JPEG_1X8 VIDEO_BUS_FMT_JPEG_1X8 > > - /* S5C73M3 sensor specific interleaved UYVY and JPEG */ > - V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001, > +#define V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 VIDEO_BUS_FMT_S5C_UYVY_JPEG_1X8 > > - /* HSV - next is 0x6002 */ > - V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001, > -}; > +#define V4L2_MBUS_FMT_AHSV8888_1X32 VIDEO_BUS_FMT_AHSV8888_1X32 > > /** > * struct v4l2_mbus_framefmt - frame format on the media bus > 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.8.3.2 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 1/5] video: move mediabus format definition to a more standard place 2014-09-23 12:33 ` Guennadi Liakhovetski @ 2014-09-23 16:09 ` Boris BREZILLON 0 siblings, 0 replies; 13+ messages in thread From: Boris BREZILLON @ 2014-09-23 16:09 UTC (permalink / raw) To: Guennadi Liakhovetski Cc: Thierry Reding, Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media Hi Guennadi, On Tue, 23 Sep 2014 14:33:20 +0200 (CEST) Guennadi Liakhovetski <g.liakhovetski@gmx.de> wrote: > Hi Boris, > > On Tue, 22 Jul 2014, 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> > > In principle I find this a good idea, certainly it's good to reuse code. > Just wondering, wouldn't it be better instead of adding those defines to > define a macro like > > #define VIDEO_BUS_TO_MBUS(x) V4L2_MBUS_ ## x = VIDEO_BUS_ ## x > > and then do > > enum v4l2_mbus_pixelcode { > VIDEO_BUS_TO_MBUS(FIXED), > VIDEO_BUS_TO_MBUS(RGB444_2X8_PADHI_BE), > ... > }; > > ? I'm not very strong on this, I just think an enum is nicer than a bunch > of defines and this way copy-paste errors are less likely, but if you or > others strongly disagree - I won't insist :) I'd say it might be a good solution if we enforce new users (including user space users) to use video_bus_format enum values instead of v4l2_mbus_pixelcode ones. But if we keep adding new values to this enum I'd say this approach is less readable than having the full names (V4L2_MBUS_XXX) expressed, because users will still have to use those full names. Anyway, I can still replace this macro list by an enum: enum v4l2_mbus_pixelcode { V4L2_MBUS_FIXED = VIDEO_BUS_FIXED, V4L2_MBUS_RGB444_2X8_PADHI_BE = VIDEO_BUS_RGB444_2X8_PADHI_BE, ... }; Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON 2014-07-22 12:23 ` [PATCH 1/5] video: move mediabus format definition to a more standard place Boris BREZILLON @ 2014-07-22 12:23 ` Boris BREZILLON 2014-07-22 12:23 ` [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info Boris BREZILLON ` (3 subsequent siblings) 5 siblings, 0 replies; 13+ messages in thread From: Boris BREZILLON @ 2014-07-22 12:23 UTC (permalink / raw) To: Thierry Reding, Laurent Pinchart Cc: David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media, 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 8c31f11..319f860 100644 --- a/include/uapi/linux/v4l2-mediabus.h +++ b/include/uapi/linux/v4l2-mediabus.h @@ -30,6 +30,8 @@ #define V4L2_MBUS_FMT_RGB888_2X12_BE VIDEO_BUS_FMT_RGB888_2X12_BE #define V4L2_MBUS_FMT_RGB888_2X12_LE VIDEO_BUS_FMT_RGB888_2X12_LE #define V4L2_MBUS_FMT_ARGB8888_1X32 VIDEO_BUS_FMT_ARGB8888_1X32 +#define V4L2_BUS_FMT_RGB444_1X12 VIDEO_BUS_FMT_RGB444_1X12 +#define V4L2_BUS_FMT_RGB565_1X16 VIDEO_BUS_FMT_RGB565_1X16 #define V4L2_MBUS_FMT_Y8_1X8 VIDEO_BUS_FMT_Y8_1X8 #define V4L2_MBUS_FMT_UV8_1X8 VIDEO_BUS_FMT_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.8.3.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON 2014-07-22 12:23 ` [PATCH 1/5] video: move mediabus format definition to a more standard place Boris BREZILLON 2014-07-22 12:23 ` [PATCH 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats Boris BREZILLON @ 2014-07-22 12:23 ` Boris BREZILLON 2014-09-23 14:04 ` Thierry Reding 2014-07-22 12:23 ` [PATCH 4/5] drm: panel: simple-panel: add support for bus_format retrieval Boris BREZILLON ` (2 subsequent siblings) 5 siblings, 1 reply; 13+ messages in thread From: Boris BREZILLON @ 2014-07-22 12:23 UTC (permalink / raw) To: Thierry Reding, Laurent Pinchart Cc: David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media, Boris BREZILLON 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 | 28 ++++++++++++++++++++++++++++ include/drm/drm_crtc.h | 8 ++++++++ 2 files changed, 36 insertions(+) diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c index c808a09..50c8395 100644 --- a/drivers/gpu/drm/drm_crtc.c +++ b/drivers/gpu/drm/drm_crtc.c @@ -825,6 +825,34 @@ 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, + int nfmts) +{ + enum video_bus_format *formats = NULL; + + if (fmts && nfmts) { + formats = kmemdup(fmts, sizeof(*fmts) * nfmts, GFP_KERNEL); + if (!formats) + return -ENOMEM; + } + + kfree(info->bus_formats); + info->bus_formats = formats; + info->nbus_formats = formats ? nfmts : 0; + + 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 e529b68..957729b 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> @@ -121,6 +122,9 @@ struct drm_display_info { enum subpixel_order subpixel_order; u32 color_formats; + const enum video_bus_format *bus_formats; + int nbus_formats; + /* Mask of supported hdmi deep color modes */ u8 edid_hdmi_dc_modes; @@ -964,6 +968,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, + int nfmts); + static inline bool drm_property_type_is(struct drm_property *property, uint32_t type) { -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info 2014-07-22 12:23 ` [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info Boris BREZILLON @ 2014-09-23 14:04 ` Thierry Reding 2014-09-23 14:15 ` Boris BREZILLON 0 siblings, 1 reply; 13+ messages in thread From: Thierry Reding @ 2014-09-23 14:04 UTC (permalink / raw) To: Boris BREZILLON Cc: Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media [-- Attachment #1: Type: text/plain, Size: 2924 bytes --] On Tue, Jul 22, 2014 at 02:23:45PM +0200, Boris BREZILLON wrote: > 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 | 28 ++++++++++++++++++++++++++++ > include/drm/drm_crtc.h | 8 ++++++++ > 2 files changed, 36 insertions(+) > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > index c808a09..50c8395 100644 > --- a/drivers/gpu/drm/drm_crtc.c > +++ b/drivers/gpu/drm/drm_crtc.c > @@ -825,6 +825,34 @@ 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, > + int nfmts) Can you make nfmts unsigned please? > +{ > + enum video_bus_format *formats = NULL; > + > + if (fmts && nfmts) { > + formats = kmemdup(fmts, sizeof(*fmts) * nfmts, GFP_KERNEL); > + if (!formats) > + return -ENOMEM; > + } > + > + kfree(info->bus_formats); > + info->bus_formats = formats; > + info->nbus_formats = formats ? nfmts : 0; And perhaps check for formats == NULL && nfmts != 0 since that's not a valid pair of values. Then you can simply assign this directly without relying on the value of formats. Also other variable names use "num_" as a prefix instead of "n", so if you're going to respin anyway might as well make the names more consistent. > + > + 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 e529b68..957729b 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> > @@ -121,6 +122,9 @@ struct drm_display_info { > enum subpixel_order subpixel_order; > u32 color_formats; > > + const enum video_bus_format *bus_formats; > + int nbus_formats; unsigned int here too, please. Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info 2014-09-23 14:04 ` Thierry Reding @ 2014-09-23 14:15 ` Boris BREZILLON 0 siblings, 0 replies; 13+ messages in thread From: Boris BREZILLON @ 2014-09-23 14:15 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media Hi Thierry, On Tue, 23 Sep 2014 16:04:40 +0200 Thierry Reding <thierry.reding@gmail.com> wrote: > On Tue, Jul 22, 2014 at 02:23:45PM +0200, Boris BREZILLON wrote: > > 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 | 28 ++++++++++++++++++++++++++++ > > include/drm/drm_crtc.h | 8 ++++++++ > > 2 files changed, 36 insertions(+) > > > > diff --git a/drivers/gpu/drm/drm_crtc.c b/drivers/gpu/drm/drm_crtc.c > > index c808a09..50c8395 100644 > > --- a/drivers/gpu/drm/drm_crtc.c > > +++ b/drivers/gpu/drm/drm_crtc.c > > @@ -825,6 +825,34 @@ 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, > > + int nfmts) > > Can you make nfmts unsigned please? Sure. > > > +{ > > + enum video_bus_format *formats = NULL; > > + > > + if (fmts && nfmts) { > > + formats = kmemdup(fmts, sizeof(*fmts) * nfmts, GFP_KERNEL); > > + if (!formats) > > + return -ENOMEM; > > + } > > + > > + kfree(info->bus_formats); > > + info->bus_formats = formats; > > + info->nbus_formats = formats ? nfmts : 0; > > And perhaps check for formats == NULL && nfmts != 0 since that's not a > valid pair of values. Then you can simply assign this directly without > relying on the value of formats. > > Also other variable names use "num_" as a prefix instead of "n", so if > you're going to respin anyway might as well make the names more > consistent. I'll rename the field and variable and add the proper check before assigning values. Thanks for your review. Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* [PATCH 4/5] drm: panel: simple-panel: add support for bus_format retrieval 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON ` (2 preceding siblings ...) 2014-07-22 12:23 ` [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info Boris BREZILLON @ 2014-07-22 12:23 ` Boris BREZILLON 2014-07-22 12:23 ` [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel Boris BREZILLON 2014-08-12 11:02 ` [PATCH 0/5] video: describe data bus formats Boris BREZILLON 5 siblings, 0 replies; 13+ messages in thread From: Boris BREZILLON @ 2014-07-22 12:23 UTC (permalink / raw) To: Thierry Reding, Laurent Pinchart Cc: David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media, Boris BREZILLON 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 3f76944..42fd6d1 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -41,6 +41,8 @@ struct panel_desc { unsigned int width; unsigned int height; } size; + + enum video_bus_format bus_format; }; struct panel_simple { @@ -89,6 +91,9 @@ static int panel_simple_get_fixed_modes(struct panel_simple *panel) 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.8.3.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON ` (3 preceding siblings ...) 2014-07-22 12:23 ` [PATCH 4/5] drm: panel: simple-panel: add support for bus_format retrieval Boris BREZILLON @ 2014-07-22 12:23 ` Boris BREZILLON 2014-09-23 14:06 ` Thierry Reding 2014-08-12 11:02 ` [PATCH 0/5] video: describe data bus formats Boris BREZILLON 5 siblings, 1 reply; 13+ messages in thread From: Boris BREZILLON @ 2014-07-22 12:23 UTC (permalink / raw) To: Thierry Reding, Laurent Pinchart Cc: David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media, Boris BREZILLON 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 42fd6d1..f1e49fd 100644 --- a/drivers/gpu/drm/panel/panel-simple.c +++ b/drivers/gpu/drm/panel/panel-simple.c @@ -428,6 +428,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 lg_lp129qe_mode = { -- 1.8.3.2 ^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel 2014-07-22 12:23 ` [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel Boris BREZILLON @ 2014-09-23 14:06 ` Thierry Reding 2014-09-23 14:13 ` Boris BREZILLON 0 siblings, 1 reply; 13+ messages in thread From: Thierry Reding @ 2014-09-23 14:06 UTC (permalink / raw) To: Boris BREZILLON Cc: Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media [-- Attachment #1: Type: text/plain, Size: 801 bytes --] On Tue, Jul 22, 2014 at 02:23:47PM +0200, Boris BREZILLON wrote: > 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 42fd6d1..f1e49fd 100644 > --- a/drivers/gpu/drm/panel/panel-simple.c > +++ b/drivers/gpu/drm/panel/panel-simple.c > @@ -428,6 +428,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = { > .width = 108, > .height = 65, > }, > + .bus_format = VIDEO_BUS_FMT_RGB888_1X24, This is really equivalent to .bpc = 8. Didn't you say you had other use-cases where .bpc wasn't sufficient? Thierry [-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --] ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel 2014-09-23 14:06 ` Thierry Reding @ 2014-09-23 14:13 ` Boris BREZILLON 0 siblings, 0 replies; 13+ messages in thread From: Boris BREZILLON @ 2014-09-23 14:13 UTC (permalink / raw) To: Thierry Reding Cc: Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media Hi Thierry, On Tue, 23 Sep 2014 16:06:13 +0200 Thierry Reding <thierry.reding@gmail.com> wrote: > On Tue, Jul 22, 2014 at 02:23:47PM +0200, Boris BREZILLON wrote: > > 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 42fd6d1..f1e49fd 100644 > > --- a/drivers/gpu/drm/panel/panel-simple.c > > +++ b/drivers/gpu/drm/panel/panel-simple.c > > @@ -428,6 +428,7 @@ static const struct panel_desc foxlink_fl500wvr00_a0t = { > > .width = 108, > > .height = 65, > > }, > > + .bus_format = VIDEO_BUS_FMT_RGB888_1X24, > > This is really equivalent to .bpc = 8. Didn't you say you had other > use-cases where .bpc wasn't sufficient? Yes, the HLCDC support RGB565 where you don't have the same number of bits for each color (Red and Blue = 5 bits, Green = 6 bits), and thus can't be encoded in the bpc field. > > Thierry -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH 0/5] video: describe data bus formats 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON ` (4 preceding siblings ...) 2014-07-22 12:23 ` [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel Boris BREZILLON @ 2014-08-12 11:02 ` Boris BREZILLON 5 siblings, 0 replies; 13+ messages in thread From: Boris BREZILLON @ 2014-08-12 11:02 UTC (permalink / raw) To: Boris BREZILLON Cc: Thierry Reding, Laurent Pinchart, David Airlie, dri-devel, linux-kernel, linux-api, Mauro Carvalho Chehab, linux-media Hi, On Tue, 22 Jul 2014 14:23:42 +0200 Boris BREZILLON <boris.brezillon@free-electrons.com> wrote: > 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. > > The video bus formats are not documented yet (and I don't know where this doc > should be stored), but I'm pretty sure this version won't be the last one ;-). Laurent, Thierry (and other DRM/KMS folks), any comments on this series ? I'd really like to get the HLCDC driver mainlined for 3.18 and it depends on this series now... Best Regards, Boris -- Boris Brezillon, Free Electrons Embedded Linux and Kernel engineering http://free-electrons.com ^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2014-09-23 16:09 UTC | newest] Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2014-07-22 12:23 [PATCH 0/5] video: describe data bus formats Boris BREZILLON 2014-07-22 12:23 ` [PATCH 1/5] video: move mediabus format definition to a more standard place Boris BREZILLON 2014-09-23 12:33 ` Guennadi Liakhovetski 2014-09-23 16:09 ` Boris BREZILLON 2014-07-22 12:23 ` [PATCH 2/5] video: add RGB444_1X12 and RGB565_1X16 bus formats Boris BREZILLON 2014-07-22 12:23 ` [PATCH 3/5] drm: add bus_formats and nbus_formats fields to drm_display_info Boris BREZILLON 2014-09-23 14:04 ` Thierry Reding 2014-09-23 14:15 ` Boris BREZILLON 2014-07-22 12:23 ` [PATCH 4/5] drm: panel: simple-panel: add support for bus_format retrieval Boris BREZILLON 2014-07-22 12:23 ` [PATCH 5/5] drm: panel: simple-panel: add bus format information for foxlink panel Boris BREZILLON 2014-09-23 14:06 ` Thierry Reding 2014-09-23 14:13 ` Boris BREZILLON 2014-08-12 11:02 ` [PATCH 0/5] video: describe data bus formats Boris BREZILLON
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).