Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sakari, On 02/26/2012 11:25 PM, Sakari Ailus wrote: I think we could use the framesize control to tell the size of the frame, or however it is done for jpeg blobs. Yes, we could add a standard framesize control to the Image Source class but it will solve only part of the problem. Nevertheless it might be worth to have it. It could be used by applications to configure subdevs directly, while the host drivers could use e.g. s/g_frame_config op for that. (I think we could continue this discussion in the context of the RFC.) Sure, let's continue in your RFC thread. The issue I see in the pass-through mode is that the user would have no information whatsoever what he's getting. This would be perhaps fixed by adding the frame format descriptor: it could contain information how to handle the data. (Just thinking out loud. :)) Do you mean a user space application by user ? Yeah. I'd like to clearly separate blob media bus pixel codes and hardware-specific blob fourccs. If we don't want to change fundamental assumptions of V4L2 we likely need separate fourccs for each weird format. I can imagine pass-through media bus pixel code but a transparent fourcc sounds like a higher abstraction. :) I agree... how about this: We currently provide the information on the media bus pixel code to the CSI-2 receivers but most of the time it's not necessary for them to know what the pixel code exactly is: it doesn't do anything with the data but writes it to memory. Bits uncompressed, compressed and the compression method are enough --- if uncompression is desired. Even pixel order isn't always needed. I don't think so. For all image formats defined by MIPI-CSI2 standard a pixel code is necessary. Sample compression or bit expansion is most of the time related to a specific image format. A MIPI-CSI2 receiver must know an exact image format, otherwise it won't be able to decode data from the low level protocol. What might make sense is to provide generic table with pixel code related information, such as bits compressed and uncompressed, pixel order, compression method and default 4CC. This doesn't look like an improvement to me, most of these information we now have in single 4-byte media bus pixel code. Do you want the drivers to search such tables by comparing all those parameters ? Custom formats would only be present in this table without individual CSI-2 receiver drivers having to know about them. Same goes with 4CC's. Media bus/fourcc translation tables will always be driver-specific. There have already been discussions about centralizing such tables IIRC. All you can have is probably just some default (statistical) fourcc, which is really useful for nothing. Having a bunch of parameters for each custom format could be useful probably only if we've dropped an assumption that each hardware specific data format gets it's own fourcc, and have exposed those parameters to the user space. The multi-planar formats complicate things further. Now the fourcc determines whether a v4l2 buffer is has more than one data plane. -- Regards, Sylwester -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sylwester,
Sylwester Nawrocki wrote:
On 02/17/2012 07:15 PM, Sakari Ailus wrote:
On Fri, Feb 17, 2012 at 03:26:29PM +0100, Sylwester Nawrocki wrote:
On 02/16/2012 08:46 PM, Sakari Ailus wrote:
On Thu, Feb 16, 2012 at 07:23:54PM +0100, Sylwester Nawrocki wrote:
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+ /* Interleaved JPEG and YUV formats - next is 0x4102 */
+ V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
Thanks for the patch. Just a tiny comment:
I'd go with a new hardware-specific buffer range, e.g. 0x5000.
Sure, that makes more sense. But I guess you mean format not buffer
range ?
Yeah, a format that begins a new range.
Guennadi also proposed an interesting idea: a pass-through format. Does
your format have dimensions that the driver would use for something or is
that just a blob?
It's just a blob for the drivers, dimensions may be needed for subdevs to
compute overall size of data for example. But the host driver, in case of
Samsung devices, basically just needs to know the total size of frame data.
I'm afraid the host would have to additionally configure subdevs in the data
pipeline in case of hardware-specific format, when we have used a single
binary blob media bus format identifier. For example MIPI-CSI2 data format
would have to be set up along the pipeline. There might be more attributes
in the future like this. Not sure if we want to go that path ?
I'll try and see how it would look like with a single pass-through format.
Probably using g/s_mbus_config operations ?
I think we could use the framesize control to tell the size of the frame, or
however it is done for jpeg blobs.
Yes, we could add a standard framesize control to the Image Source class but
it
will solve only part of the problem. Nevertheless it might be worth to have
it.
It could be used by applications to configure subdevs directly, while the
host
drivers could use e.g. s/g_frame_config op for that.
(I think we could continue this discussion in the context of the RFC.)
The issue I see in the pass-through mode is that the user would have no
information whatsoever what he's getting. This would be perhaps fixed by
adding the frame format descriptor: it could contain information how to
handle the data. (Just thinking out loud. :))
Do you mean a user space application by user ?
Yeah.
I'd like to clearly separate blob media bus pixel codes and hardware-specific
blob fourccs. If we don't want to change fundamental assumptions of V4L2
we likely need separate fourccs for each weird format.
I can imagine pass-through media bus pixel code but a transparent fourcc
sounds like a higher abstraction. :)
I agree... how about this:
We currently provide the information on the media bus pixel code to the
CSI-2 receivers but most of the time it's not necessary for them to know
what the pixel code exactly is: it doesn't do anything with the data but
writes it to memory. Bits uncompressed, compressed and the compression
method are enough --- if uncompression is desired. Even pixel order
isn't always needed.
What might make sense is to provide generic table with pixel code
related information, such as bits compressed and uncompressed, pixel
order, compression method and default 4CC.
Custom formats would only be present in this table without individual
CSI-2 receiver drivers having to know about them. Same goes with 4CC's.
Regards,
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sakari,
On 02/17/2012 07:15 PM, Sakari Ailus wrote:
On Fri, Feb 17, 2012 at 03:26:29PM +0100, Sylwester Nawrocki wrote:
On 02/16/2012 08:46 PM, Sakari Ailus wrote:
On Thu, Feb 16, 2012 at 07:23:54PM +0100, Sylwester Nawrocki wrote:
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrockis.nawro...@samsung.com
Signed-off-by: Kyungmin Parkkyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+ /* Interleaved JPEG and YUV formats - next is 0x4102 */
+ V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
Thanks for the patch. Just a tiny comment:
I'd go with a new hardware-specific buffer range, e.g. 0x5000.
Sure, that makes more sense. But I guess you mean format not buffer
range ?
Yeah, a format that begins a new range.
Guennadi also proposed an interesting idea: a pass-through format. Does
your format have dimensions that the driver would use for something or is
that just a blob?
It's just a blob for the drivers, dimensions may be needed for subdevs to
compute overall size of data for example. But the host driver, in case of
Samsung devices, basically just needs to know the total size of frame data.
I'm afraid the host would have to additionally configure subdevs in the data
pipeline in case of hardware-specific format, when we have used a single
binary blob media bus format identifier. For example MIPI-CSI2 data format
would have to be set up along the pipeline. There might be more attributes
in the future like this. Not sure if we want to go that path ?
I'll try and see how it would look like with a single pass-through format.
Probably using g/s_mbus_config operations ?
I think we could use the framesize control to tell the size of the frame, or
however it is done for jpeg blobs.
Yes, we could add a standard framesize control to the Image Source class but it
will solve only part of the problem. Nevertheless it might be worth to have it.
It could be used by applications to configure subdevs directly, while the host
drivers could use e.g. s/g_frame_config op for that.
The issue I see in the pass-through mode is that the user would have no
information whatsoever what he's getting. This would be perhaps fixed by
adding the frame format descriptor: it could contain information how to
handle the data. (Just thinking out loud. :))
Do you mean a user space application by user ?
I'd like to clearly separate blob media bus pixel codes and hardware-specific
blob fourccs. If we don't want to change fundamental assumptions of V4L2
we likely need separate fourccs for each weird format.
I can imagine pass-through media bus pixel code but a transparent fourcc
sounds like a higher abstraction. :)
I'm fine keeping this approach with sensor specific pixel code for now at
least, but we must mark it experimental IMHO.
Good point, I'm eventually going to add a relevant note in the DocBook.
--
Thanks,
Sylwester
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sakari,
On 02/16/2012 08:46 PM, Sakari Ailus wrote:
Hi Sylwester,
On Thu, Feb 16, 2012 at 07:23:54PM +0100, Sylwester Nawrocki wrote:
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+/* Interleaved JPEG and YUV formats - next is 0x4102 */
+V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
Thanks for the patch. Just a tiny comment:
I'd go with a new hardware-specific buffer range, e.g. 0x5000.
Sure, that makes more sense. But I guess you mean format not buffer range ?
Guennadi also proposed an interesting idea: a pass-through format. Does
your format have dimensions that the driver would use for something or is
that just a blob?
It's just a blob for the drivers, dimensions may be needed for subdevs to
compute overall size of data for example. But the host driver, in case of
Samsung devices, basically just needs to know the total size of frame data.
I'm afraid the host would have to additionally configure subdevs in the data
pipeline in case of hardware-specific format, when we have used a single
binary blob media bus format identifier. For example MIPI-CSI2 data format
would have to be set up along the pipeline. There might be more attributes
in the future like this. Not sure if we want to go that path ?
I'll try and see how it would look like with a single pass-through format.
Probably using g/s_mbus_config operations ?
Best regards
--
Sylwester Nawrocki
Samsung Poland RD Center
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sylwester,
On Fri, Feb 17, 2012 at 03:26:29PM +0100, Sylwester Nawrocki wrote:
On 02/16/2012 08:46 PM, Sakari Ailus wrote:
On Thu, Feb 16, 2012 at 07:23:54PM +0100, Sylwester Nawrocki wrote:
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+ /* Interleaved JPEG and YUV formats - next is 0x4102 */
+ V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
Thanks for the patch. Just a tiny comment:
I'd go with a new hardware-specific buffer range, e.g. 0x5000.
Sure, that makes more sense. But I guess you mean format not buffer range
?
Yeah, a format that begins a new range.
Guennadi also proposed an interesting idea: a pass-through format. Does
your format have dimensions that the driver would use for something or is
that just a blob?
It's just a blob for the drivers, dimensions may be needed for subdevs to
compute overall size of data for example. But the host driver, in case of
Samsung devices, basically just needs to know the total size of frame data.
I'm afraid the host would have to additionally configure subdevs in the data
pipeline in case of hardware-specific format, when we have used a single
binary blob media bus format identifier. For example MIPI-CSI2 data format
would have to be set up along the pipeline. There might be more attributes
in the future like this. Not sure if we want to go that path ?
I'll try and see how it would look like with a single pass-through format.
Probably using g/s_mbus_config operations ?
I think we could use the framesize control to tell the size of the frame, or
however it is done for jpeg blobs.
The issue I see in the pass-through mode is that the user would have no
information whatsoever what he's getting. This would be perhaps fixed by
adding the frame format descriptor: it could contain information how to
handle the data. (Just thinking out loud. :))
I'm fine keeping this approach with sensor specific pixel code for now at
least, but we must mark it experimental IMHO.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sylwester,
On Friday 17 February 2012 15:26:29 Sylwester Nawrocki wrote:
On 02/16/2012 08:46 PM, Sakari Ailus wrote:
On Thu, Feb 16, 2012 at 07:23:54PM +0100, Sylwester Nawrocki wrote:
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h
b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+ /* Interleaved JPEG and YUV formats - next is 0x4102 */
+ V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
Please remember to update Documentation/DocBook/media/v4l/subdev-formats.xml.
Thanks for the patch. Just a tiny comment:
I'd go with a new hardware-specific buffer range, e.g. 0x5000.
Sure, that makes more sense. But I guess you mean format not buffer
range ?
Guennadi also proposed an interesting idea: a pass-through format. Does
your format have dimensions that the driver would use for something or is
that just a blob?
It's just a blob for the drivers, dimensions may be needed for subdevs to
compute overall size of data for example. But the host driver, in case of
Samsung devices, basically just needs to know the total size of frame data.
I'm afraid the host would have to additionally configure subdevs in the data
pipeline in case of hardware-specific format, when we have used a single
binary blob media bus format identifier. For example MIPI-CSI2 data format
would have to be set up along the pipeline. There might be more attributes
in the future like this. Not sure if we want to go that path ?
I'll try and see how it would look like with a single pass-through format.
Probably using g/s_mbus_config operations ?
I'm not sure yet how all this should be handled exactly, but I'm pretty sure I
don't want the CSI2 receiver drivers to handle all the vendor-specific blob-
like formats explicitly. For instance your sensor could be used with the OMAP3
ISP, and I don't want to add support for V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 to the
OMAP3 ISP CSI2 driver. We need a way for CSI2 receiver drivers to map blob
formats automatically. Enumeration also needs to be handled, which makes the
problem even more complex.
--
Regards,
Laurent Pinchart
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+ /* Interleaved JPEG and YUV formats - next is 0x4102 */
+ V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
/**
--
1.7.9
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 1/6] V4L: Add V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 media bus format
Hi Sylwester,
On Thu, Feb 16, 2012 at 07:23:54PM +0100, Sylwester Nawrocki wrote:
This patch adds media bus pixel code for the interleaved JPEG/YUYV image
format used by S5C73MX Samsung cameras. The interleaved image data is
transferred on MIPI-CSI2 bus as User Defined Byte-based Data.
Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com
Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com
---
include/linux/v4l2-mediabus.h |3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/include/linux/v4l2-mediabus.h b/include/linux/v4l2-mediabus.h
index 5ea7f75..c2f0e4e 100644
--- a/include/linux/v4l2-mediabus.h
+++ b/include/linux/v4l2-mediabus.h
@@ -92,6 +92,9 @@ enum v4l2_mbus_pixelcode {
/* JPEG compressed formats - next is 0x4002 */
V4L2_MBUS_FMT_JPEG_1X8 = 0x4001,
+
+ /* Interleaved JPEG and YUV formats - next is 0x4102 */
+ V4L2_MBUS_FMT_VYUY_JPEG_I1_1X8 = 0x4101,
};
Thanks for the patch. Just a tiny comment:
I'd go with a new hardware-specific buffer range, e.g. 0x5000.
Guennadi also proposed an interesting idea: a pass-through format. Does
your format have dimensions that the driver would use for something or is
that just a blob?
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
