Re: [PATCH 1/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
On Fri, 4 Dec 2009, Hans Verkuil wrote:
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
new file mode 100644
index 000..5cf2a6d
--- /dev/null
+++ b/include/media/v4l2-mediabus.h
@@ -0,0 +1,61 @@
+/*
+ * Media Bus API header
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@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 V4L2_MEDIABUS_H
+#define V4L2_MEDIABUS_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.
+ */
+enum v4l2_mbus_pixelcode {
+ V4L2_MBUS_FMT_FIXED = 1,
+ V4L2_MBUS_FMT_YUYV8_2X8,
+ V4L2_MBUS_FMT_YVYU8_2X8,
+ V4L2_MBUS_FMT_UYVY8_2X8,
+ V4L2_MBUS_FMT_VYUY8_2X8,
Darn, I was so hoping that I could sign off on it, but this makes no sense
now.
Either it is:
V4L2_MBUS_FMT_YUYV8_1X8,
V4L2_MBUS_FMT_YVYU8_1X8,
V4L2_MBUS_FMT_UYVY8_1X8,
V4L2_MBUS_FMT_VYUY8_1X8
where the 'YUYV' code tells you the order of the Y, U and V samples over the
bus, or it is:
V4L2_MBUS_FMT_YUYV8_2X8_BE,
V4L2_MBUS_FMT_YUYV8_2X8_LE,
V4L2_MBUS_FMT_YVYU8_2X8_BE,
V4L2_MBUS_FMT_YVYU8_2X8_LE,
Where the BE or LE suffix tells you the order in which the YU/YV pairs are
arriving.
No. In nXk n is the number of k-bit wide _electrical_ samples of the bus
to get (an equivalent of) one _pixel_. So, for 16-bit formats on 8-bit bus
it's _definitely_ 2X8.
And no, BE and LE is the order of _samples_ within one _pixel_, not the
order of pixels within one megapixel (YU/YV pairs are arriving), but
that's also what you meant above, judging by the names.
So, I'll go with the 2X8_[LB]E variant, where
YUYV8_2X8_LE == YUYV with LE packing
YUYV8_2X8_BE == UYVY with LE packing
YVYU8_2X8_LE == YVYU with LE packing
YVYU8_2X8_BE == VYUY with LE packing
Personally I prefer the first (1X8) representation.
Just pick one of these two and you can send it again and add my signed-off-by:
Signed-off-by: Hans Verkuil hverk...@xs4all.nl
I'll make it an Acked-by. You can only put an Sob, if you forward a
patch. Otherwise you can only add an Acked-by or a Reviewed-by.
Thanks
Guennadi
Regards,
Hans
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_LE,
+ V4L2_MBUS_FMT_RGB555_2X8_PADHI_BE,
+ V4L2_MBUS_FMT_RGB565_2X8_LE,
+ V4L2_MBUS_FMT_RGB565_2X8_BE,
+ V4L2_MBUS_FMT_SBGGR8_1X8,
+ V4L2_MBUS_FMT_SBGGR10_1X10,
+ V4L2_MBUS_FMT_GREY8_1X8,
+ V4L2_MBUS_FMT_Y10_1X10,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_LE,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_LE,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
+ V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
+};
+
+/**
+ * struct v4l2_mbus_framefmt - frame format on the media bus
+ * @width: frame width
+ * @height:frame height
+ * @code: data format code
+ * @field: used interlacing type
+ * @colorspace:colorspace of the data
+ */
+struct v4l2_mbus_framefmt {
+ __u32 width;
+ __u32 height;
+ enum v4l2_mbus_pixelcodecode;
+ enum v4l2_field field;
+ enum v4l2_colorspacecolorspace;
+};
+
+#endif
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 544ce87..c53d462 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -22,6 +22,7 @@
#define _V4L2_SUBDEV_H
#include media/v4l2-common.h
+#include media/v4l2-mediabus.h
/* generic v4l2_device notify callback notification values */
#define V4L2_SUBDEV_IR_RX_NOTIFY _IOW('v', 0, u32)
@@ -207,7 +208,7 @@ struct v4l2_subdev_audio_ops {
s_std_output: set v4l2_std_id for video OUTPUT devices. This is ignored
by
video input devices.
- s_crystal_freq: sets the frequency of the crystal used to generate the
+ s_crystal_freq: sets the frequency of the crystal used to generate the
clocks in Hz. An extra flags field allows device specific configuration
regarding clock frequency dividers, etc. If not used, then set flags
to 0. If the frequency is not supported, then -EINVAL is returned.
@@ -217,6 +218,14 @@
[PATCH 1/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, it will be removed. Also add helper routines to support generic
pass-through mode for the soc-camera framework.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3 - v4: more comments addressed - thanks! Now based on the current
linux-next. Hans, as for _nXk suffixes, I preferred to preserve them to
keep all notation explicit. Without them a format like
V4L2_MBUS_FMT_SBGGR10 would be ambiguous, whether one of
V4L2_MBUS_FMT_SBGGR10_2X8_PAD*_?E or the V4L2_MBUS_FMT_SBGGR10_1X10 is
meant. I also removed struct soc_mbus_datafmt and soc_mbus_find_datafmt()
upon your request, although I'm not happy having to open-code it in about
4 drivers. But we can extract that code in a generic routine later. One of
the important advantages of that struct and function was, that they
allowed to keep supported formats in drivers centrally at just one
location, thus being able to add new or remove deprecated formats easily,
and to avoid long switch-case blocks by just calling one function to
search in the array.
Thanks
Guennadi
drivers/media/video/Makefile |2 +-
drivers/media/video/soc_mediabus.c | 157
include/media/soc_mediabus.h | 65 +++
include/media/v4l2-mediabus.h | 61 ++
include/media/v4l2-subdev.h| 19 -
5 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/soc_mediabus.c
create mode 100644 include/media/soc_mediabus.h
create mode 100644 include/media/v4l2-mediabus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..e7bc8da 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o
-obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
+obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM) += soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1)+= mx1_camera.o
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
new file mode 100644
index 000..c54cae7
--- /dev/null
+++ b/drivers/media/video/soc_mediabus.c
@@ -0,0 +1,157 @@
+/*
+ * soc-camera media bus helper routines
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-mediabus.h
+#include media/soc_mediabus.h
+
+#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
+
+static const struct soc_mbus_pixelfmt mbus_fmt[] = {
+ [MBUS_IDX(YUYV8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = YUYV,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YVYU8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .name = YVYU,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(UYVY8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = UYVY,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(VYUY8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = VYUY,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(RGB555_2X8_PADHI_LE)] = {
+ .fourcc =
Re: [PATCH 1/2 v4] v4l: add a media-bus API for configuring v4l2 subdev pixel and frame formats
On Thursday 03 December 2009 15:16:56 Guennadi Liakhovetski wrote:
Video subdevices, like cameras, decoders, connect to video bridges over
specialised busses. Data is being transferred over these busses in various
formats, which only loosely correspond to fourcc codes, describing how video
data is stored in RAM. This is not a one-to-one correspondence, therefore we
cannot use fourcc codes to configure subdevice output data formats. This patch
adds codes for several such on-the-bus formats and an API, similar to the
familiar .s_fmt(), .g_fmt(), .try_fmt(), .enum_fmt() API for configuring those
codes. After all users of the old API in struct v4l2_subdev_video_ops are
converted, it will be removed. Also add helper routines to support generic
pass-through mode for the soc-camera framework.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
v3 - v4: more comments addressed - thanks! Now based on the current
linux-next. Hans, as for _nXk suffixes, I preferred to preserve them to
keep all notation explicit. Without them a format like
V4L2_MBUS_FMT_SBGGR10 would be ambiguous, whether one of
V4L2_MBUS_FMT_SBGGR10_2X8_PAD*_?E or the V4L2_MBUS_FMT_SBGGR10_1X10 is
meant. I also removed struct soc_mbus_datafmt and soc_mbus_find_datafmt()
upon your request, although I'm not happy having to open-code it in about
4 drivers. But we can extract that code in a generic routine later. One of
the important advantages of that struct and function was, that they
allowed to keep supported formats in drivers centrally at just one
location, thus being able to add new or remove deprecated formats easily,
and to avoid long switch-case blocks by just calling one function to
search in the array.
Thanks
Guennadi
drivers/media/video/Makefile |2 +-
drivers/media/video/soc_mediabus.c | 157
include/media/soc_mediabus.h | 65 +++
include/media/v4l2-mediabus.h | 61 ++
include/media/v4l2-subdev.h| 19 -
5 files changed, 302 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/soc_mediabus.c
create mode 100644 include/media/soc_mediabus.h
create mode 100644 include/media/v4l2-mediabus.h
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index 7a2dcc3..e7bc8da 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -149,7 +149,7 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o
obj-$(CONFIG_VIDEO_CX23885) += cx23885/
obj-$(CONFIG_VIDEO_OMAP2)+= omap2cam.o
-obj-$(CONFIG_SOC_CAMERA) += soc_camera.o
+obj-$(CONFIG_SOC_CAMERA) += soc_camera.o soc_mediabus.o
obj-$(CONFIG_SOC_CAMERA_PLATFORM)+= soc_camera_platform.o
# soc-camera host drivers have to be linked after camera drivers
obj-$(CONFIG_VIDEO_MX1) += mx1_camera.o
diff --git a/drivers/media/video/soc_mediabus.c
b/drivers/media/video/soc_mediabus.c
new file mode 100644
index 000..c54cae7
--- /dev/null
+++ b/drivers/media/video/soc_mediabus.c
@@ -0,0 +1,157 @@
+/*
+ * soc-camera media bus helper routines
+ *
+ * Copyright (C) 2009, Guennadi Liakhovetski g.liakhovet...@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.
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+
+#include media/v4l2-device.h
+#include media/v4l2-mediabus.h
+#include media/soc_mediabus.h
+
+#define MBUS_IDX(f) (V4L2_MBUS_FMT_ ## f - V4L2_MBUS_FMT_FIXED - 1)
+
+static const struct soc_mbus_pixelfmt mbus_fmt[] = {
+ [MBUS_IDX(YUYV8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_YUYV,
+ .name = YUYV,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(YVYU8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_YVYU,
+ .name = YVYU,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(UYVY8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_UYVY,
+ .name = UYVY,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order = SOC_MBUS_ORDER_LE,
+ }, [MBUS_IDX(VYUY8_2X8)] = {
+ .fourcc = V4L2_PIX_FMT_VYUY,
+ .name = VYUY,
+ .bits_per_sample= 8,
+ .packing= SOC_MBUS_PACKING_2X8_PADHI,
+ .order =
