[v2,01/10,media] Move mediabus format definition to a more standard place
Commit Message
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_pixelcode now points to media_bus_format.
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/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
3 files changed, 134 insertions(+), 112 deletions(-)
create mode 100644 include/uapi/linux/media-bus-format.h
Comments
Hi Boris,
Thank you for the update.
On Thu, Nov 06, 2014 at 10:56:59AM +0100, 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_pixelcode now points to media_bus_format.
>
> 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/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
> include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
> 3 files changed, 134 insertions(+), 112 deletions(-)
> create mode 100644 include/uapi/linux/media-bus-format.h
>
> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> index b70237e..b2c23f8 100644
> --- a/include/uapi/linux/Kbuild
> +++ b/include/uapi/linux/Kbuild
> @@ -414,6 +414,7 @@ header-y += veth.h
> header-y += vfio.h
> header-y += vhost.h
> header-y += videodev2.h
> +header-y += media-bus-format.h
Could you arrange this to the list alphabetically, please?
> header-y += virtio_9p.h
> header-y += virtio_balloon.h
> header-y += virtio_blk.h
> diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
> new file mode 100644
> index 0000000..251a902
> --- /dev/null
> +++ b/include/uapi/linux/media-bus-format.h
> @@ -0,0 +1,131 @@
> +/*
> + * Media 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_MEDIA_BUS_FORMAT_H
> +#define __LINUX_MEDIA_BUS_FORMAT_H
> +
> +/*
> + * These bus formats uniquely identify data formats on the data bus. Format 0
> + * is reserved, MEDIA_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.
> + */
> +
> +#define MEDIA_BUS_FMT_ENTRY(name, val) \
> + MEDIA_BUS_FMT_ ## name = val, \
> + V4L2_MBUS_FMT_ ## name = val
> +
> +enum media_bus_format {
There's no really a need to keep the definitions inside the enum. It looks a
little bit confusing to me. That made me realise something I missed
yesterday.
There's a difference: the enum in C++ is a different thing than in C, and
the enum type isn't able to contain any other values than those defined in
the enumeration.
So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
including the enum values. Define new values for MEDIA_BUS_* equivalents
using preprocessor macros, as you've done below. Drop the definition of enum
media_bus_format, and use u32 (or uint32_t) type for the variables.
This way the enum stays intact for existing C++ applications, and new
applications will have to use a 32-bit type.
I'd like to get an ok from Hans to this as well.
> + MEDIA_BUS_FMT_ENTRY(FIXED, 0x0001),
> +
> + /* RGB - next is 0x100e */
> + MEDIA_BUS_FMT_ENTRY(RGB444_2X8_PADHI_BE, 0x1001),
> + MEDIA_BUS_FMT_ENTRY(RGB444_2X8_PADHI_LE, 0x1002),
> + MEDIA_BUS_FMT_ENTRY(RGB555_2X8_PADHI_BE, 0x1003),
> + MEDIA_BUS_FMT_ENTRY(RGB555_2X8_PADHI_LE, 0x1004),
> + MEDIA_BUS_FMT_ENTRY(BGR565_2X8_BE, 0x1005),
> + MEDIA_BUS_FMT_ENTRY(BGR565_2X8_LE, 0x1006),
> + MEDIA_BUS_FMT_ENTRY(RGB565_2X8_BE, 0x1007),
> + MEDIA_BUS_FMT_ENTRY(RGB565_2X8_LE, 0x1008),
> + MEDIA_BUS_FMT_ENTRY(RGB666_1X18, 0x1009),
> + MEDIA_BUS_FMT_ENTRY(RGB888_1X24, 0x100a),
> + MEDIA_BUS_FMT_ENTRY(RGB888_2X12_BE, 0x100b),
> + MEDIA_BUS_FMT_ENTRY(RGB888_2X12_LE, 0x100c),
> + MEDIA_BUS_FMT_ENTRY(ARGB8888_1X32, 0x100d),
> +
> + /* YUV (including grey) - next is 0x2024 */
> + MEDIA_BUS_FMT_ENTRY(Y8_1X8, 0x2001),
> + MEDIA_BUS_FMT_ENTRY(UV8_1X8, 0x2015),
> + MEDIA_BUS_FMT_ENTRY(UYVY8_1_5X8, 0x2002),
> + MEDIA_BUS_FMT_ENTRY(VYUY8_1_5X8, 0x2003),
> + MEDIA_BUS_FMT_ENTRY(YUYV8_1_5X8, 0x2004),
> + MEDIA_BUS_FMT_ENTRY(YVYU8_1_5X8, 0x2005),
> + MEDIA_BUS_FMT_ENTRY(UYVY8_2X8, 0x2006),
> + MEDIA_BUS_FMT_ENTRY(VYUY8_2X8, 0x2007),
> + MEDIA_BUS_FMT_ENTRY(YUYV8_2X8, 0x2008),
> + MEDIA_BUS_FMT_ENTRY(YVYU8_2X8, 0x2009),
> + MEDIA_BUS_FMT_ENTRY(Y10_1X10, 0x200a),
> + MEDIA_BUS_FMT_ENTRY(UYVY10_2X10, 0x2018),
> + MEDIA_BUS_FMT_ENTRY(VYUY10_2X10, 0x2019),
> + MEDIA_BUS_FMT_ENTRY(YUYV10_2X10, 0x200b),
> + MEDIA_BUS_FMT_ENTRY(YVYU10_2X10, 0x200c),
> + MEDIA_BUS_FMT_ENTRY(Y12_1X12, 0x2013),
> + MEDIA_BUS_FMT_ENTRY(UYVY8_1X16, 0x200f),
> + MEDIA_BUS_FMT_ENTRY(VYUY8_1X16, 0x2010),
> + MEDIA_BUS_FMT_ENTRY(YUYV8_1X16, 0x2011),
> + MEDIA_BUS_FMT_ENTRY(YVYU8_1X16, 0x2012),
> + MEDIA_BUS_FMT_ENTRY(YDYUYDYV8_1X16, 0x2014),
> + MEDIA_BUS_FMT_ENTRY(UYVY10_1X20, 0x201a),
> + MEDIA_BUS_FMT_ENTRY(VYUY10_1X20, 0x201b),
> + MEDIA_BUS_FMT_ENTRY(YUYV10_1X20, 0x200d),
> + MEDIA_BUS_FMT_ENTRY(YVYU10_1X20, 0x200e),
> + MEDIA_BUS_FMT_ENTRY(YUV10_1X30, 0x2016),
> + MEDIA_BUS_FMT_ENTRY(AYUV8_1X32, 0x2017),
> + MEDIA_BUS_FMT_ENTRY(UYVY12_2X12, 0x201c),
> + MEDIA_BUS_FMT_ENTRY(VYUY12_2X12, 0x201d),
> + MEDIA_BUS_FMT_ENTRY(YUYV12_2X12, 0x201e),
> + MEDIA_BUS_FMT_ENTRY(YVYU12_2X12, 0x201f),
> + MEDIA_BUS_FMT_ENTRY(UYVY12_1X24, 0x2020),
> + MEDIA_BUS_FMT_ENTRY(VYUY12_1X24, 0x2021),
> + MEDIA_BUS_FMT_ENTRY(YUYV12_1X24, 0x2022),
> + MEDIA_BUS_FMT_ENTRY(YVYU12_1X24, 0x2023),
> +
> + /* Bayer - next is 0x3019 */
> + MEDIA_BUS_FMT_ENTRY(SBGGR8_1X8, 0x3001),
> + MEDIA_BUS_FMT_ENTRY(SGBRG8_1X8, 0x3013),
> + MEDIA_BUS_FMT_ENTRY(SGRBG8_1X8, 0x3002),
> + MEDIA_BUS_FMT_ENTRY(SRGGB8_1X8, 0x3014),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_ALAW8_1X8, 0x3015),
> + MEDIA_BUS_FMT_ENTRY(SGBRG10_ALAW8_1X8, 0x3016),
> + MEDIA_BUS_FMT_ENTRY(SGRBG10_ALAW8_1X8, 0x3017),
> + MEDIA_BUS_FMT_ENTRY(SRGGB10_ALAW8_1X8, 0x3018),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_DPCM8_1X8, 0x300b),
> + MEDIA_BUS_FMT_ENTRY(SGBRG10_DPCM8_1X8, 0x300c),
> + MEDIA_BUS_FMT_ENTRY(SGRBG10_DPCM8_1X8, 0x3009),
> + MEDIA_BUS_FMT_ENTRY(SRGGB10_DPCM8_1X8, 0x300d),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADHI_BE, 0x3003),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADHI_LE, 0x3004),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADLO_BE, 0x3005),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADLO_LE, 0x3006),
> + MEDIA_BUS_FMT_ENTRY(SBGGR10_1X10, 0x3007),
> + MEDIA_BUS_FMT_ENTRY(SGBRG10_1X10, 0x300e),
> + MEDIA_BUS_FMT_ENTRY(SGRBG10_1X10, 0x300a),
> + MEDIA_BUS_FMT_ENTRY(SRGGB10_1X10, 0x300f),
> + MEDIA_BUS_FMT_ENTRY(SBGGR12_1X12, 0x3008),
> + MEDIA_BUS_FMT_ENTRY(SGBRG12_1X12, 0x3010),
> + MEDIA_BUS_FMT_ENTRY(SGRBG12_1X12, 0x3011),
> + MEDIA_BUS_FMT_ENTRY(SRGGB12_1X12, 0x3012),
> +
> + /* JPEG compressed formats - next is 0x4002 */
> + MEDIA_BUS_FMT_ENTRY(JPEG_1X8, 0x4001),
> +
> + /* Vendor specific formats - next is 0x5002 */
> +
> + /* S5C73M3 sensor specific interleaved UYVY and JPEG */
> + MEDIA_BUS_FMT_ENTRY(S5C_UYVY_JPEG_1X8, 0x5001),
> +
> + /* HSV - next is 0x6002 */
> + MEDIA_BUS_FMT_ENTRY(AHSV8888_1X32, 0x6001),
> +};
> +
> +#endif /* __LINUX_MEDIA_BUS_FORMAT_H */
> diff --git a/include/uapi/linux/v4l2-mediabus.h b/include/uapi/linux/v4l2-mediabus.h
> index 1445e85..d30526c 100644
> --- a/include/uapi/linux/v4l2-mediabus.h
> +++ b/include/uapi/linux/v4l2-mediabus.h
> @@ -13,119 +13,9 @@
>
> #include <linux/types.h>
> #include <linux/videodev2.h>
> +#include <linux/media-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,
> -
> - /* 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,
> -
> - /* 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,
> -
> - /* JPEG compressed formats - next is 0x4002 */
> - V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
> -
> - /* Vendor specific formats - next is 0x5002 */
> -
> - /* S5C73M3 sensor specific interleaved UYVY and JPEG */
> - V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
> -
> - /* HSV - next is 0x6002 */
> - V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001,
> -};
> +#define v4l2_mbus_pixelcode media_bus_format
>
> /**
> * struct v4l2_mbus_framefmt - frame format on the media bus
Em Fri, 07 Nov 2014 13:43:59 +0200
Sakari Ailus <sakari.ailus@iki.fi> escreveu:
>> +enum media_bus_format {
>
> There's no really a need to keep the definitions inside the enum. It looks a
> little bit confusing to me. That made me realise something I missed
> yesterday.
>
> There's a difference: the enum in C++ is a different thing than in C, and
> the enum type isn't able to contain any other values than those defined in
> the enumeration.
>
> So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
> including the enum values. Define new values for MEDIA_BUS_* equivalents
> using preprocessor macros, as you've done below. Drop the definition of enum
> media_bus_format, and use u32 (or uint32_t) type for the variables.
>
> This way the enum stays intact for existing C++ applications, and new
> applications will have to use a 32-bit type.
Yeah, enums at the public API is bad, as any change there can potentially
cause C++ apps to break.
On Fri, 7 Nov 2014 13:43:59 +0200
Sakari Ailus <sakari.ailus@iki.fi> wrote:
> Hi Boris,
>
> Thank you for the update.
>
> On Thu, Nov 06, 2014 at 10:56:59AM +0100, 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_pixelcode now points to media_bus_format.
> >
> > 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/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
> > include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
> > 3 files changed, 134 insertions(+), 112 deletions(-)
> > create mode 100644 include/uapi/linux/media-bus-format.h
> >
> > diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
> > index b70237e..b2c23f8 100644
> > --- a/include/uapi/linux/Kbuild
> > +++ b/include/uapi/linux/Kbuild
> > @@ -414,6 +414,7 @@ header-y += veth.h
> > header-y += vfio.h
> > header-y += vhost.h
> > header-y += videodev2.h
> > +header-y += media-bus-format.h
>
> Could you arrange this to the list alphabetically, please?
>
> > header-y += virtio_9p.h
> > header-y += virtio_balloon.h
> > header-y += virtio_blk.h
> > diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
> > new file mode 100644
> > index 0000000..251a902
> > --- /dev/null
> > +++ b/include/uapi/linux/media-bus-format.h
> > @@ -0,0 +1,131 @@
> > +/*
> > + * Media 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_MEDIA_BUS_FORMAT_H
> > +#define __LINUX_MEDIA_BUS_FORMAT_H
> > +
> > +/*
> > + * These bus formats uniquely identify data formats on the data bus. Format 0
> > + * is reserved, MEDIA_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.
> > + */
> > +
> > +#define MEDIA_BUS_FMT_ENTRY(name, val) \
> > + MEDIA_BUS_FMT_ ## name = val, \
> > + V4L2_MBUS_FMT_ ## name = val
> > +
> > +enum media_bus_format {
>
> There's no really a need to keep the definitions inside the enum. It looks a
> little bit confusing to me. That made me realise something I missed
> yesterday.
>
> There's a difference: the enum in C++ is a different thing than in C, and
> the enum type isn't able to contain any other values than those defined in
> the enumeration.
>
> So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
> including the enum values. Define new values for MEDIA_BUS_* equivalents
> using preprocessor macros, as you've done below. Drop the definition of enum
> media_bus_format, and use u32 (or uint32_t) type for the variables.
>
> This way the enum stays intact for existing C++ applications, and new
> applications will have to use a 32-bit type.
>
Fair enough. If Hans agree I'll rework the series and drop the
media_bus_format enum.
Thanks,
Boris
On 11/07/14 12:43, Sakari Ailus wrote:
> Hi Boris,
>
> Thank you for the update.
>
> On Thu, Nov 06, 2014 at 10:56:59AM +0100, 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_pixelcode now points to media_bus_format.
>>
>> 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/media-bus-format.h | 131 ++++++++++++++++++++++++++++++++++
>> include/uapi/linux/v4l2-mediabus.h | 114 +----------------------------
>> 3 files changed, 134 insertions(+), 112 deletions(-)
>> create mode 100644 include/uapi/linux/media-bus-format.h
>>
>> diff --git a/include/uapi/linux/Kbuild b/include/uapi/linux/Kbuild
>> index b70237e..b2c23f8 100644
>> --- a/include/uapi/linux/Kbuild
>> +++ b/include/uapi/linux/Kbuild
>> @@ -414,6 +414,7 @@ header-y += veth.h
>> header-y += vfio.h
>> header-y += vhost.h
>> header-y += videodev2.h
>> +header-y += media-bus-format.h
>
> Could you arrange this to the list alphabetically, please?
>
>> header-y += virtio_9p.h
>> header-y += virtio_balloon.h
>> header-y += virtio_blk.h
>> diff --git a/include/uapi/linux/media-bus-format.h b/include/uapi/linux/media-bus-format.h
>> new file mode 100644
>> index 0000000..251a902
>> --- /dev/null
>> +++ b/include/uapi/linux/media-bus-format.h
>> @@ -0,0 +1,131 @@
>> +/*
>> + * Media 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_MEDIA_BUS_FORMAT_H
>> +#define __LINUX_MEDIA_BUS_FORMAT_H
>> +
>> +/*
>> + * These bus formats uniquely identify data formats on the data bus. Format 0
>> + * is reserved, MEDIA_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.
>> + */
>> +
>> +#define MEDIA_BUS_FMT_ENTRY(name, val) \
>> + MEDIA_BUS_FMT_ ## name = val, \
>> + V4L2_MBUS_FMT_ ## name = val
>> +
>> +enum media_bus_format {
>
> There's no really a need to keep the definitions inside the enum. It looks a
> little bit confusing to me. That made me realise something I missed
> yesterday.
>
> There's a difference: the enum in C++ is a different thing than in C, and
> the enum type isn't able to contain any other values than those defined in
> the enumeration.
>
> So what I propose is the following. Keep enum v4l2_mbus_pixelcode around,
> including the enum values. Define new values for MEDIA_BUS_* equivalents
> using preprocessor macros, as you've done below. Drop the definition of enum
> media_bus_format, and use u32 (or uint32_t) type for the variables.
>
> This way the enum stays intact for existing C++ applications, and new
> applications will have to use a 32-bit type.
>
> I'd like to get an ok from Hans to this as well.
OK, let's do this. Let's keep enum v4l2_mbus_pixelcode but only under #ifndef
__KERNEL and with a comment that this enum is deprecated and frozen and that
the values from the new header should be used.
And make the new MEDIA_BUS_FMT_ values defines instead of an enum.
Regards,
Hans
--
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
@@ -414,6 +414,7 @@ header-y += veth.h
header-y += vfio.h
header-y += vhost.h
header-y += videodev2.h
+header-y += media-bus-format.h
header-y += virtio_9p.h
header-y += virtio_balloon.h
header-y += virtio_blk.h
new file mode 100644
@@ -0,0 +1,131 @@
+/*
+ * Media 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_MEDIA_BUS_FORMAT_H
+#define __LINUX_MEDIA_BUS_FORMAT_H
+
+/*
+ * These bus formats uniquely identify data formats on the data bus. Format 0
+ * is reserved, MEDIA_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.
+ */
+
+#define MEDIA_BUS_FMT_ENTRY(name, val) \
+ MEDIA_BUS_FMT_ ## name = val, \
+ V4L2_MBUS_FMT_ ## name = val
+
+enum media_bus_format {
+ MEDIA_BUS_FMT_ENTRY(FIXED, 0x0001),
+
+ /* RGB - next is 0x100e */
+ MEDIA_BUS_FMT_ENTRY(RGB444_2X8_PADHI_BE, 0x1001),
+ MEDIA_BUS_FMT_ENTRY(RGB444_2X8_PADHI_LE, 0x1002),
+ MEDIA_BUS_FMT_ENTRY(RGB555_2X8_PADHI_BE, 0x1003),
+ MEDIA_BUS_FMT_ENTRY(RGB555_2X8_PADHI_LE, 0x1004),
+ MEDIA_BUS_FMT_ENTRY(BGR565_2X8_BE, 0x1005),
+ MEDIA_BUS_FMT_ENTRY(BGR565_2X8_LE, 0x1006),
+ MEDIA_BUS_FMT_ENTRY(RGB565_2X8_BE, 0x1007),
+ MEDIA_BUS_FMT_ENTRY(RGB565_2X8_LE, 0x1008),
+ MEDIA_BUS_FMT_ENTRY(RGB666_1X18, 0x1009),
+ MEDIA_BUS_FMT_ENTRY(RGB888_1X24, 0x100a),
+ MEDIA_BUS_FMT_ENTRY(RGB888_2X12_BE, 0x100b),
+ MEDIA_BUS_FMT_ENTRY(RGB888_2X12_LE, 0x100c),
+ MEDIA_BUS_FMT_ENTRY(ARGB8888_1X32, 0x100d),
+
+ /* YUV (including grey) - next is 0x2024 */
+ MEDIA_BUS_FMT_ENTRY(Y8_1X8, 0x2001),
+ MEDIA_BUS_FMT_ENTRY(UV8_1X8, 0x2015),
+ MEDIA_BUS_FMT_ENTRY(UYVY8_1_5X8, 0x2002),
+ MEDIA_BUS_FMT_ENTRY(VYUY8_1_5X8, 0x2003),
+ MEDIA_BUS_FMT_ENTRY(YUYV8_1_5X8, 0x2004),
+ MEDIA_BUS_FMT_ENTRY(YVYU8_1_5X8, 0x2005),
+ MEDIA_BUS_FMT_ENTRY(UYVY8_2X8, 0x2006),
+ MEDIA_BUS_FMT_ENTRY(VYUY8_2X8, 0x2007),
+ MEDIA_BUS_FMT_ENTRY(YUYV8_2X8, 0x2008),
+ MEDIA_BUS_FMT_ENTRY(YVYU8_2X8, 0x2009),
+ MEDIA_BUS_FMT_ENTRY(Y10_1X10, 0x200a),
+ MEDIA_BUS_FMT_ENTRY(UYVY10_2X10, 0x2018),
+ MEDIA_BUS_FMT_ENTRY(VYUY10_2X10, 0x2019),
+ MEDIA_BUS_FMT_ENTRY(YUYV10_2X10, 0x200b),
+ MEDIA_BUS_FMT_ENTRY(YVYU10_2X10, 0x200c),
+ MEDIA_BUS_FMT_ENTRY(Y12_1X12, 0x2013),
+ MEDIA_BUS_FMT_ENTRY(UYVY8_1X16, 0x200f),
+ MEDIA_BUS_FMT_ENTRY(VYUY8_1X16, 0x2010),
+ MEDIA_BUS_FMT_ENTRY(YUYV8_1X16, 0x2011),
+ MEDIA_BUS_FMT_ENTRY(YVYU8_1X16, 0x2012),
+ MEDIA_BUS_FMT_ENTRY(YDYUYDYV8_1X16, 0x2014),
+ MEDIA_BUS_FMT_ENTRY(UYVY10_1X20, 0x201a),
+ MEDIA_BUS_FMT_ENTRY(VYUY10_1X20, 0x201b),
+ MEDIA_BUS_FMT_ENTRY(YUYV10_1X20, 0x200d),
+ MEDIA_BUS_FMT_ENTRY(YVYU10_1X20, 0x200e),
+ MEDIA_BUS_FMT_ENTRY(YUV10_1X30, 0x2016),
+ MEDIA_BUS_FMT_ENTRY(AYUV8_1X32, 0x2017),
+ MEDIA_BUS_FMT_ENTRY(UYVY12_2X12, 0x201c),
+ MEDIA_BUS_FMT_ENTRY(VYUY12_2X12, 0x201d),
+ MEDIA_BUS_FMT_ENTRY(YUYV12_2X12, 0x201e),
+ MEDIA_BUS_FMT_ENTRY(YVYU12_2X12, 0x201f),
+ MEDIA_BUS_FMT_ENTRY(UYVY12_1X24, 0x2020),
+ MEDIA_BUS_FMT_ENTRY(VYUY12_1X24, 0x2021),
+ MEDIA_BUS_FMT_ENTRY(YUYV12_1X24, 0x2022),
+ MEDIA_BUS_FMT_ENTRY(YVYU12_1X24, 0x2023),
+
+ /* Bayer - next is 0x3019 */
+ MEDIA_BUS_FMT_ENTRY(SBGGR8_1X8, 0x3001),
+ MEDIA_BUS_FMT_ENTRY(SGBRG8_1X8, 0x3013),
+ MEDIA_BUS_FMT_ENTRY(SGRBG8_1X8, 0x3002),
+ MEDIA_BUS_FMT_ENTRY(SRGGB8_1X8, 0x3014),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_ALAW8_1X8, 0x3015),
+ MEDIA_BUS_FMT_ENTRY(SGBRG10_ALAW8_1X8, 0x3016),
+ MEDIA_BUS_FMT_ENTRY(SGRBG10_ALAW8_1X8, 0x3017),
+ MEDIA_BUS_FMT_ENTRY(SRGGB10_ALAW8_1X8, 0x3018),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_DPCM8_1X8, 0x300b),
+ MEDIA_BUS_FMT_ENTRY(SGBRG10_DPCM8_1X8, 0x300c),
+ MEDIA_BUS_FMT_ENTRY(SGRBG10_DPCM8_1X8, 0x3009),
+ MEDIA_BUS_FMT_ENTRY(SRGGB10_DPCM8_1X8, 0x300d),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADHI_BE, 0x3003),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADHI_LE, 0x3004),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADLO_BE, 0x3005),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_2X8_PADLO_LE, 0x3006),
+ MEDIA_BUS_FMT_ENTRY(SBGGR10_1X10, 0x3007),
+ MEDIA_BUS_FMT_ENTRY(SGBRG10_1X10, 0x300e),
+ MEDIA_BUS_FMT_ENTRY(SGRBG10_1X10, 0x300a),
+ MEDIA_BUS_FMT_ENTRY(SRGGB10_1X10, 0x300f),
+ MEDIA_BUS_FMT_ENTRY(SBGGR12_1X12, 0x3008),
+ MEDIA_BUS_FMT_ENTRY(SGBRG12_1X12, 0x3010),
+ MEDIA_BUS_FMT_ENTRY(SGRBG12_1X12, 0x3011),
+ MEDIA_BUS_FMT_ENTRY(SRGGB12_1X12, 0x3012),
+
+ /* JPEG compressed formats - next is 0x4002 */
+ MEDIA_BUS_FMT_ENTRY(JPEG_1X8, 0x4001),
+
+ /* Vendor specific formats - next is 0x5002 */
+
+ /* S5C73M3 sensor specific interleaved UYVY and JPEG */
+ MEDIA_BUS_FMT_ENTRY(S5C_UYVY_JPEG_1X8, 0x5001),
+
+ /* HSV - next is 0x6002 */
+ MEDIA_BUS_FMT_ENTRY(AHSV8888_1X32, 0x6001),
+};
+
+#endif /* __LINUX_MEDIA_BUS_FORMAT_H */
@@ -13,119 +13,9 @@
#include <linux/types.h>
#include <linux/videodev2.h>
+#include <linux/media-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,
-
- /* 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,
-
- /* 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,
-
- /* JPEG compressed formats - next is 0x4002 */
- V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
-
- /* Vendor specific formats - next is 0x5002 */
-
- /* S5C73M3 sensor specific interleaved UYVY and JPEG */
- V4L2_MBUS_FMT_S5C_UYVY_JPEG_1X8 = 0x5001,
-
- /* HSV - next is 0x6002 */
- V4L2_MBUS_FMT_AHSV8888_1X32 = 0x6001,
-};
+#define v4l2_mbus_pixelcode media_bus_format
/**
* struct v4l2_mbus_framefmt - frame format on the media bus