[PATCH] mediabus: add MIPI CSI-2 pixel format codes
Add pixel format codes, defined in the MIPI CSI-2 specification.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Even though it affects the same enum as my patch from yesterday, they are
independent, Hans and Laurent CCed just to avoid possible conflicts, when
further patching this file.
include/media/v4l2-mediabus.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index a870965..b0dcace 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,32 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
V4L2_MBUS_FMT_SGRBG8_1X8,
+ /* MIPI CSI-2 codes */
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_L,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB888,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB666,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB565,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB555,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB444,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW6,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW7,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW8,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW12,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW14,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_NULL,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_BLANKING,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_EMBEDDED8,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_1,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_2,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_3,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_4,
};
/**
--
1.6.2.4
--
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: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
Hi Guennadi,
On Friday 23 July 2010 10:13:37 Guennadi Liakhovetski wrote:
Add pixel format codes, defined in the MIPI CSI-2 specification.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Even though it affects the same enum as my patch from yesterday, they are
independent, Hans and Laurent CCed just to avoid possible conflicts, when
further patching this file.
include/media/v4l2-mediabus.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index a870965..b0dcace 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,32 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
V4L2_MBUS_FMT_SGRBG8_1X8,
+ /* MIPI CSI-2 codes */
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_L,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB888,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB666,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB565,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB555,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB444,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW6,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW7,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW8,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW12,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW14,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_NULL,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_BLANKING,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_EMBEDDED8,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_1,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_2,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_3,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_4,
I don't think I like this. Take the raw formats for instance, they're used for
Bayer RGB. V4L2_MBUS_FMT_MIPI_CSI2_RAW8 could map to any Bayer format (GRBG,
RGGB, ...). Why don't we just use standard pixel codes ?
};
/**
--
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
Re: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
On Fri, 23 Jul 2010, Laurent Pinchart wrote:
Hi Guennadi,
On Friday 23 July 2010 10:13:37 Guennadi Liakhovetski wrote:
Add pixel format codes, defined in the MIPI CSI-2 specification.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Even though it affects the same enum as my patch from yesterday, they are
independent, Hans and Laurent CCed just to avoid possible conflicts, when
further patching this file.
include/media/v4l2-mediabus.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-mediabus.h
index a870965..b0dcace 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,32 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
V4L2_MBUS_FMT_SGRBG8_1X8,
+ /* MIPI CSI-2 codes */
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_L,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB888,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB666,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB565,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB555,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB444,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW6,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW7,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW8,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW12,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW14,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_NULL,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_BLANKING,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_EMBEDDED8,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_1,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_2,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_3,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_4,
I don't think I like this. Take the raw formats for instance, they're used
for
Bayer RGB. V4L2_MBUS_FMT_MIPI_CSI2_RAW8 could map to any Bayer format (GRBG,
RGGB, ...). Why don't we just use standard pixel codes ?
Well, the idea was to keep them cleanly separated: CSI connections only
deal with CSI codes, parallel connections with parallel codes. In
principle, the above codes are supposed to specify the bus type, right? A
NX8 format is an 8-bit parallel bus, etc. CSI doesn't fit into any of
those. So, from that PoV you do need separate codes, I think.
That said, using these new CSI codes is difficult...
Ok, how about this: looking at the spec, there is a layer chart of the
MIPI CSI-2 data-flow. It shows some arbitrary data format at the
application level, lane-based serial connection on the wire, but between
them there is a fixed 8-bit data bus, say, at the lane-management layer.
So, we just agree to take that as our CSI bus view. In fact, we _have_ to
use a more generic pixel code scheme, than the CSI formats, because, say,
with CSI codes there's no way to say, that it's actually Bayer data, that
the sensor is sending, using the CSI RAW8 format.
So, Laurent, you're right, this is not going to work. Thanks for pointing
this out!
cat mediabus-add-MIPI-CSI-2-pixel-format-codes.patch /dev/null
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
Hi Laurent,
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Friday, July 23, 2010 10:35 AM
To: Guennadi Liakhovetski
Cc: Linux Media Mailing List; Hans Verkuil
Subject: Re: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
Hi Guennadi,
On Friday 23 July 2010 10:13:37 Guennadi Liakhovetski wrote:
Add pixel format codes, defined in the MIPI CSI-2 specification.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Even though it affects the same enum as my patch from yesterday, they
are
independent, Hans and Laurent CCed just to avoid possible conflicts,
when
further patching this file.
include/media/v4l2-mediabus.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-
mediabus.h
index a870965..b0dcace 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,32 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
V4L2_MBUS_FMT_SGRBG8_1X8,
+ /* MIPI CSI-2 codes */
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_L,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB888,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB666,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB565,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB555,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB444,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW6,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW7,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW8,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW12,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW14,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_NULL,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_BLANKING,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_EMBEDDED8,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_1,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_2,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_3,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_4,
I don't think I like this. Take the raw formats for instance, they're
used for
Bayer RGB. V4L2_MBUS_FMT_MIPI_CSI2_RAW8 could map to any Bayer format
(GRBG,
RGGB, ...). Why don't we just use standard pixel codes ?
As far as I understand on some media buses exact pixel formats are not
defined,
although we still need information to configure the bus.
MIPI CSI-2 seem an example of such to me, e.g. we do configure MIPI
interface
to *_USER_1 format but over the bus is transferred JPEG data.
I guess we could try to use standard pixel codes but then we would
probably have
to map from any format to specific MIPI format code to configure the
hardware.
Moreover MIPI formats are quite specific, for instance for RAW12 in 32-bit
sample
(from MSb to LSb) we have dummy 8-bits, then 12-bit of actual data and
remaining
12 dummy bits.
};
/**
--
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
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
[patch -next] V4L: media/IR: testing the wrong variable
There is a typo here. We meant to test rbuf instead of drv. We already tested drv earlier. Signed-off-by: Dan Carpenter erro...@gmail.com diff --git a/drivers/media/IR/ir-lirc-codec.c b/drivers/media/IR/ir-lirc-codec.c index 178bc5b..87e 100644 --- a/drivers/media/IR/ir-lirc-codec.c +++ b/drivers/media/IR/ir-lirc-codec.c @@ -192,7 +192,7 @@ static int ir_lirc_register(struct input_dev *input_dev) return rc; rbuf = kzalloc(sizeof(struct lirc_buffer), GFP_KERNEL); - if (!drv) + if (!rbuf) goto rbuf_alloc_failed; rc = lirc_buffer_init(rbuf, sizeof(int), LIRCBUF_SIZE); -- 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
[patch -next] V4L: au0828: move dereference below sanity checks
This function has sanity checks to make sure that dev is non-null. I
moved the dereference down below the checks. In the current code dev
is never actually null.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index d97e0a2..7989a7b 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -441,7 +441,7 @@ static void au0828_copy_vbi(struct au0828_dev *dev,
unsigned char *outp, unsigned long len)
{
unsigned char *startwrite, *startread;
- int bytesperline = dev-vbi_width;
+ int bytesperline;
int i, j = 0;
if (dev == NULL) {
@@ -464,6 +464,8 @@ static void au0828_copy_vbi(struct au0828_dev *dev,
return;
}
+ bytesperline = dev-vbi_width;
+
if (dma_q-pos + len buf-vb.size)
len = buf-vb.size - dma_q-pos;
--
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
[patch -next] V4L: ivtv: remove unneeded NULL checks
In ivtvfb_callback_cleanup() we dereference itv before checking that
it's NULL. itv is assigned with container_of() which basically never
returns a NULL pointer so the check is pointless. I removed it, along
with a similar check in ivtvfb_callback_init().
I considered adding a check for v4l2_dev, but I looked at the code and I
don't think that can be NULL either.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 2c2d862..be03a71 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1239,7 +1239,7 @@ static int __init ivtvfb_callback_init(struct device
*dev, void *p)
struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (ivtvfb_init_card(itv) == 0) {
IVTVFB_INFO(Framebuffer registered on %s\n,
itv-v4l2_dev.name);
@@ -1255,7 +1255,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
struct osd_info *oi = itv-osd_info;
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(itv-osd_info-ivtvfb_info)) {
IVTVFB_WARN(Framebuffer %d is in use, cannot unload\n,
itv-instance);
--
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: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
Hi Sylwester
On Fri, 23 Jul 2010, Sylwester Nawrocki wrote:
Hi Laurent,
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Friday, July 23, 2010 10:35 AM
To: Guennadi Liakhovetski
Cc: Linux Media Mailing List; Hans Verkuil
Subject: Re: [PATCH] mediabus: add MIPI CSI-2 pixel format codes
Hi Guennadi,
On Friday 23 July 2010 10:13:37 Guennadi Liakhovetski wrote:
Add pixel format codes, defined in the MIPI CSI-2 specification.
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Even though it affects the same enum as my patch from yesterday, they
are
independent, Hans and Laurent CCed just to avoid possible conflicts,
when
further patching this file.
include/media/v4l2-mediabus.h | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-mediabus.h b/include/media/v4l2-
mediabus.h
index a870965..b0dcace 100644
--- a/include/media/v4l2-mediabus.h
+++ b/include/media/v4l2-mediabus.h
@@ -41,6 +41,32 @@ enum v4l2_mbus_pixelcode {
V4L2_MBUS_FMT_SBGGR10_2X8_PADHI_BE,
V4L2_MBUS_FMT_SBGGR10_2X8_PADLO_BE,
V4L2_MBUS_FMT_SGRBG8_1X8,
+ /* MIPI CSI-2 codes */
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_L,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_8_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV420_10_CSPS,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_8,
+ V4L2_MBUS_FMT_MIPI_CSI2_YUV422_10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB888,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB666,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB565,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB555,
+ V4L2_MBUS_FMT_MIPI_CSI2_RGB444,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW6,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW7,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW8,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW10,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW12,
+ V4L2_MBUS_FMT_MIPI_CSI2_RAW14,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_NULL,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_BLANKING,
+ V4L2_MBUS_FMT_MIPI_CSI2_GEN_EMBEDDED8,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_1,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_2,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_3,
+ V4L2_MBUS_FMT_MIPI_CSI2_USER_4,
I don't think I like this. Take the raw formats for instance, they're
used for
Bayer RGB. V4L2_MBUS_FMT_MIPI_CSI2_RAW8 could map to any Bayer format
(GRBG,
RGGB, ...). Why don't we just use standard pixel codes ?
As far as I understand on some media buses exact pixel formats are not
defined,
although we still need information to configure the bus.
MIPI CSI-2 seem an example of such to me, e.g. we do configure MIPI
interface
to *_USER_1 format but over the bus is transferred JPEG data.
I guess we could try to use standard pixel codes but then we would
probably have
to map from any format to specific MIPI format code to configure the
hardware.
Moreover MIPI formats are quite specific, for instance for RAW12 in 32-bit
sample
(from MSb to LSb) we have dummy 8-bits, then 12-bit of actual data and
remaining
12 dummy bits.
I think, we have to approach this problem from the other side - from the
user perspective. A RAW8 format tells nothing to mplayer or gstreamer,
whereas they shall understand 8-bit Bayer. Similarly, the sensor will
know, that for sending of 8-bit Bayer data it'll use RAW8. So, on the
receiver side, as you correctly point out, you will have to configure
which data format to receive. If 8-bit Bayer is sent by the sensor, you
will guess, that it should be RAW8. If RGB565 is expected you'll know what
to set too. The problem arises with USER? formats. Only the sensor will
know, that when requested JPEG, it will user USER1, for MPEG-4 it will use
USER2. And there's currently no way to know this in the bridge / host
driver... So, at latest, when we get such a sensor, we'll have to decide
how to map those. Until then I would just propose to continue using the
existing mediabus formats and hope, that their mapping to CSI formats is
of a many-to-one nature...
Thanks
Guennadi
---
Guennadi Liakhovetski, Ph.D.
Freelance Open-Source Software Developer
http://www.open-technology.de/
--
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: [patch -next] V4L: ivtv: remove unneeded NULL checks
On Fri, 2010-07-23 at 12:12 +0200, Dan Carpenter wrote:
In ivtvfb_callback_cleanup() we dereference itv before checking that
it's NULL. itv is assigned with container_of() which basically never
returns a NULL pointer so the check is pointless. I removed it, along
with a similar check in ivtvfb_callback_init().
I considered adding a check for v4l2_dev, but I looked at the code and I
don't think that can be NULL either.
Signed-off-by: Dan Carpenter erro...@gmail.com
Hi Dan,
Thanks, but Jiri Slaby already caught this one:
https://patchwork.kernel.org/patch/112725/
I'm going to let Mauro pick up Jiri's patch out of patchwork.
Regards,
Andy
diff --git a/drivers/media/video/ivtv/ivtvfb.c
b/drivers/media/video/ivtv/ivtvfb.c
index 2c2d862..be03a71 100644
--- a/drivers/media/video/ivtv/ivtvfb.c
+++ b/drivers/media/video/ivtv/ivtvfb.c
@@ -1239,7 +1239,7 @@ static int __init ivtvfb_callback_init(struct device
*dev, void *p)
struct v4l2_device *v4l2_dev = dev_get_drvdata(dev);
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (ivtvfb_init_card(itv) == 0) {
IVTVFB_INFO(Framebuffer registered on %s\n,
itv-v4l2_dev.name);
@@ -1255,7 +1255,7 @@ static int ivtvfb_callback_cleanup(struct device *dev,
void *p)
struct ivtv *itv = container_of(v4l2_dev, struct ivtv, v4l2_dev);
struct osd_info *oi = itv-osd_info;
- if (itv (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT)) {
+ if (itv-v4l2_cap V4L2_CAP_VIDEO_OUTPUT) {
if (unregister_framebuffer(itv-osd_info-ivtvfb_info)) {
IVTVFB_WARN(Framebuffer %d is in use, cannot unload\n,
itv-instance);
--
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
--
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: [patch -next] V4L: ivtv: remove unneeded NULL checks
On Fri, Jul 23, 2010 at 07:46:47AM -0400, Andy Walls wrote: On Fri, 2010-07-23 at 12:12 +0200, Dan Carpenter wrote: In ivtvfb_callback_cleanup() we dereference itv before checking that it's NULL. itv is assigned with container_of() which basically never returns a NULL pointer so the check is pointless. I removed it, along with a similar check in ivtvfb_callback_init(). I considered adding a check for v4l2_dev, but I looked at the code and I don't think that can be NULL either. Signed-off-by: Dan Carpenter erro...@gmail.com Hi Dan, Thanks, but Jiri Slaby already caught this one: https://patchwork.kernel.org/patch/112725/ I'm going to let Mauro pick up Jiri's patch out of patchwork. Wow. It's remarkable how similar they are even down to the change log. regards, dan carpenter -- 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] Per-subdev, host-specific data
Hi everybody, Trying to implement support for multiple sensors connected to the same OMAP3 ISP input (all but one of the sensors need to be kept in reset obviously), I need to associate host-specific data to the sensor subdevs. The terms host and bridge are considered as synonyms in the rest of this e- mail. The OMAP3 ISP platform data has interface configuration parameters for the two CSI2 (a and c), CCP2 and parallel interfaces. The parameters are used to configure the bus when a sensor is selected. To support multiple sensors on the same input, the parameters need to be specified per-sensor, and not ISP- wide. No issue in the platform data. Board codes declare an array of structures that embed a struct v4l2_subdev_i2c_board_info instance and an OMAP3 ISP-specific interface configuration structure. At runtime, when a sensor is selected, I need to access the OMAP3 ISP-specific interface configuration structure for the selected sensor. At that point all I have is a v4l2_subdev structure pointer, without a way to get back to the interface configuration structure. The only point in the code where the v4l2_subdev and the interface configuration data are both known and could be linked together is in the host driver's probe function, where the v4l2_subdev instances are created. I have two solutions there: - store the v4l2_subdev pointer and the interface configuration data pointer in a host-specific array, and perform a an array lookup operation at runtime with the v4l2_subdev pointer as a key - add a void *host_priv field to the v4l2_subdev structure, store the interface configuration data pointer in that field, and use the field at runtime The second solution seems cleaner but requires an additional field in v4l2_subdev. Opinions and other comments will be appreciated. -- 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
Re: [patch -next] V4L: au0828: move dereference below sanity checks
On Fri, Jul 23, 2010 at 6:09 AM, Dan Carpenter erro...@gmail.com wrote:
This function has sanity checks to make sure that dev is non-null. I
moved the dereference down below the checks. In the current code dev
is never actually null.
Signed-off-by: Dan Carpenter erro...@gmail.com
diff --git a/drivers/media/video/au0828/au0828-video.c
b/drivers/media/video/au0828/au0828-video.c
index d97e0a2..7989a7b 100644
--- a/drivers/media/video/au0828/au0828-video.c
+++ b/drivers/media/video/au0828/au0828-video.c
@@ -441,7 +441,7 @@ static void au0828_copy_vbi(struct au0828_dev *dev,
unsigned char *outp, unsigned long len)
{
unsigned char *startwrite, *startread;
- int bytesperline = dev-vbi_width;
+ int bytesperline;
int i, j = 0;
if (dev == NULL) {
@@ -464,6 +464,8 @@ static void au0828_copy_vbi(struct au0828_dev *dev,
return;
}
+ bytesperline = dev-vbi_width;
+
if (dma_q-pos + len buf-vb.size)
len = buf-vb.size - dma_q-pos;
In reality the check for dev can be removed since it will *never*
happen (I added it during some debugging, as can be seen by the rest
of the NULL checks).
Either way though, this patch is fine.
Acked-by: Devin Heitmueller dheitmuel...@kernellabs.com
--
Devin J. Heitmueller - Kernel Labs
http://www.kernellabs.com
--
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: [patch -next] V4L: media/IR: testing the wrong variable
On Fri, Jul 23, 2010 at 12:08:26PM +0200, Dan Carpenter wrote: There is a typo here. We meant to test rbuf instead of drv. We already tested drv earlier. Signed-off-by: Dan Carpenter erro...@gmail.com Gah. I swear that got fixed once already... Thanks! Acked-by: Jarod Wilson ja...@redhat.com -- Jarod Wilson ja...@redhat.com -- 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] Per-subdev, host-specific data
On Friday 23 July 2010 15:01:29 Laurent Pinchart wrote: Hi everybody, Trying to implement support for multiple sensors connected to the same OMAP3 ISP input (all but one of the sensors need to be kept in reset obviously), I need to associate host-specific data to the sensor subdevs. The terms host and bridge are considered as synonyms in the rest of this e- mail. The OMAP3 ISP platform data has interface configuration parameters for the two CSI2 (a and c), CCP2 and parallel interfaces. The parameters are used to configure the bus when a sensor is selected. To support multiple sensors on the same input, the parameters need to be specified per-sensor, and not ISP- wide. No issue in the platform data. Board codes declare an array of structures that embed a struct v4l2_subdev_i2c_board_info instance and an OMAP3 ISP-specific interface configuration structure. At runtime, when a sensor is selected, I need to access the OMAP3 ISP-specific interface configuration structure for the selected sensor. At that point all I have is a v4l2_subdev structure pointer, without a way to get back to the interface configuration structure. The only point in the code where the v4l2_subdev and the interface configuration data are both known and could be linked together is in the host driver's probe function, where the v4l2_subdev instances are created. I have two solutions there: - store the v4l2_subdev pointer and the interface configuration data pointer in a host-specific array, and perform a an array lookup operation at runtime with the v4l2_subdev pointer as a key - add a void *host_priv field to the v4l2_subdev structure, store the interface configuration data pointer in that field, and use the field at runtime The second solution seems cleaner but requires an additional field in v4l2_subdev. Opinions and other comments will be appreciated. There is a third option: the grp_id field is owned by the host driver, so you could make that an index into a host specific array. That said, I think having a host_priv field isn't a bad idea. Although if we do this, then I think the existing priv field should be renamed to drv_priv to prevent confusion. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG, part of Cisco -- 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] Per-subdev, host-specific data
Hi Hans, On Friday 23 July 2010 15:46:29 Hans Verkuil wrote: On Friday 23 July 2010 15:01:29 Laurent Pinchart wrote: Hi everybody, Trying to implement support for multiple sensors connected to the same OMAP3 ISP input (all but one of the sensors need to be kept in reset obviously), I need to associate host-specific data to the sensor subdevs. The terms host and bridge are considered as synonyms in the rest of this e- mail. The OMAP3 ISP platform data has interface configuration parameters for the two CSI2 (a and c), CCP2 and parallel interfaces. The parameters are used to configure the bus when a sensor is selected. To support multiple sensors on the same input, the parameters need to be specified per-sensor, and not ISP- wide. No issue in the platform data. Board codes declare an array of structures that embed a struct v4l2_subdev_i2c_board_info instance and an OMAP3 ISP-specific interface configuration structure. At runtime, when a sensor is selected, I need to access the OMAP3 ISP-specific interface configuration structure for the selected sensor. At that point all I have is a v4l2_subdev structure pointer, without a way to get back to the interface configuration structure. The only point in the code where the v4l2_subdev and the interface configuration data are both known and could be linked together is in the host driver's probe function, where the v4l2_subdev instances are created. I have two solutions there: - store the v4l2_subdev pointer and the interface configuration data pointer in a host-specific array, and perform a an array lookup operation at runtime with the v4l2_subdev pointer as a key - add a void *host_priv field to the v4l2_subdev structure, store the interface configuration data pointer in that field, and use the field at runtime The second solution seems cleaner but requires an additional field in v4l2_subdev. Opinions and other comments will be appreciated. There is a third option: the grp_id field is owned by the host driver, so you could make that an index into a host specific array. Good point. That said, I think having a host_priv field isn't a bad idea. Although if we do this, then I think the existing priv field should be renamed to drv_priv to prevent confusion. As Guennadi, Sakari and you all agree that the host_priv field is a good idea, I'll submit a patch. Thanks. -- 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
RE: [RFC] Per-subdev, host-specific data
Hello, -Original Message- From: linux-media-ow...@vger.kernel.org [mailto:linux-media- ow...@vger.kernel.org] On Behalf Of Laurent Pinchart Sent: Friday, July 23, 2010 3:01 PM To: Linux Media Mailing List Cc: Sakari Ailus; Guennadi Liakhovetski Subject: [RFC] Per-subdev, host-specific data Hi everybody, Trying to implement support for multiple sensors connected to the same OMAP3 ISP input (all but one of the sensors need to be kept in reset obviously), I need to associate host-specific data to the sensor subdevs. The terms host and bridge are considered as synonyms in the rest of this e- mail. The OMAP3 ISP platform data has interface configuration parameters for the two CSI2 (a and c), CCP2 and parallel interfaces. The parameters are used to configure the bus when a sensor is selected. To support multiple sensors on the same input, the parameters need to be specified per-sensor, and not ISP- wide. No issue in the platform data. Board codes declare an array of structures that embed a struct v4l2_subdev_i2c_board_info instance and an OMAP3 ISP- specific interface configuration structure. At runtime, when a sensor is selected, I need to access the OMAP3 ISP- specific interface configuration structure for the selected sensor. At that point all I have is a v4l2_subdev structure pointer, without a way to get back to the interface configuration structure. The only point in the code where the v4l2_subdev and the interface configuration data are both known and could be linked together is in the host driver's probe function, where the v4l2_subdev instances are created. I have two solutions there: - store the v4l2_subdev pointer and the interface configuration data pointer in a host-specific array, and perform a an array lookup operation at runtime with the v4l2_subdev pointer as a key - add a void *host_priv field to the v4l2_subdev structure, store the interface configuration data pointer in that field, and use the field at runtime The second solution seems cleaner but requires an additional field in v4l2_subdev. Opinions and other comments will be appreciated. I like the solution with an additional void *host_priv field, it could also possibly be useful for the notify() callback to v4l2_subdev parent. On our SoCs we also need some camera host interface specific data to be attached to image sensor subdevice and later passed to host driver. So host_priv field in v4l2_subdev would be nice feature to have. -- 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 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: [SAMPLE v2 04/12] v4l-subdev: Add pads operations
Laurent,
Could you explain the probe and active usage using an example such as
below?
Link1Link2
input sensor - ccdc - video node.
Assume Link2 we can have either format 1 or format 2 for capture.
Thanks.
Murali Karicheri
Software Design Engineer
Texas Instruments Inc.
Germantown, MD 20874
email: m-kariche...@ti.com
-Original Message-
From: linux-media-ow...@vger.kernel.org [mailto:linux-media-
ow...@vger.kernel.org] On Behalf Of Laurent Pinchart
Sent: Wednesday, July 21, 2010 10:42 AM
To: linux-media@vger.kernel.org
Cc: sakari.ai...@maxwell.research.nokia.com
Subject: [SAMPLE v2 04/12] v4l-subdev: Add pads operations
Add a v4l2_subdev_pad_ops structure for the operations that need to be
performed at the pad level such as format-related operations.
The format at the output of a subdev usually depends on the format at
its input(s). The try format operation is thus not suitable for probing
format at individual pads, as it can't modify the device state and thus
can't remember the format probed at the input to compute the output
format.
To fix the problem, pass an extra argument to the get/set format
operations to select the 'probe' or 'active' format.
The probe format is used when probing the subdev. Setting the probe
format must not change the device configuration but can store data for
later reuse. Data storage is provided at the file-handle level so
applications probing the subdev concurently won't interfere with each
other.
The active format is used when configuring the subdev. It's identical to
the format handled by the usual get/set operations.
Pad format-related operations use v4l2_mbus_framefmt instead of
v4l2_format.
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
---
include/media/v4l2-subdev.h | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/include/media/v4l2-subdev.h b/include/media/v4l2-subdev.h
index 01b4135..684ab60 100644
--- a/include/media/v4l2-subdev.h
+++ b/include/media/v4l2-subdev.h
@@ -41,6 +41,7 @@ struct v4l2_device;
struct v4l2_event_subscription;
struct v4l2_fh;
struct v4l2_subdev;
+struct v4l2_subdev_fh;
struct tuner_setup;
/* decode_vbi_line */
@@ -398,6 +399,25 @@ struct v4l2_subdev_ir_ops {
struct v4l2_subdev_ir_parameters *params);
};
+enum v4l2_subdev_format {
+ V4L2_SUBDEV_FORMAT_PROBE = 0,
+ V4L2_SUBDEV_FORMAT_ACTIVE = 1,
+};
+
+struct v4l2_subdev_pad_ops {
+ int (*enum_mbus_code)(struct v4l2_subdev *sd, struct v4l2_subdev_fh
*fh,
+struct v4l2_subdev_pad_mbus_code_enum *code);
+ int (*enum_frame_size)(struct v4l2_subdev *sd,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_subdev_frame_size_enum *fse);
+ int (*get_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ unsigned int pad, struct v4l2_mbus_framefmt *fmt,
+ enum v4l2_subdev_format which);
+ int (*set_fmt)(struct v4l2_subdev *sd, struct v4l2_subdev_fh *fh,
+ unsigned int pad, struct v4l2_mbus_framefmt *fmt,
+ enum v4l2_subdev_format which);
+};
+
struct v4l2_subdev_ops {
const struct v4l2_subdev_core_ops *core;
const struct v4l2_subdev_tuner_ops *tuner;
@@ -406,6 +426,7 @@ struct v4l2_subdev_ops {
const struct v4l2_subdev_vbi_ops*vbi;
const struct v4l2_subdev_ir_ops *ir;
const struct v4l2_subdev_sensor_ops *sensor;
+ const struct v4l2_subdev_pad_ops*pad;
};
#define V4L2_SUBDEV_NAME_SIZE 32
--
1.7.1
--
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
--
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
[PATCH v3 1/8] ARM: Samsung: Add register definitions for Samsung S5P SoC camera interface
Add register definitions for the camera interface/video postprocessor contained in Samsung's S5P SoC series. Signed-off-by: Sylwester Nawrocki s.nawro...@samsung.com Signed-off-by: Kyungmin Park kyungmin.p...@samsung.com Reviewed-by: Pawel Osciak p.osc...@samsung.com Reviewed-by: Marek Szyprowski m.szyprow...@samsung.com --- arch/arm/plat-samsung/include/plat/regs-fimc.h | 294 1 files changed, 294 insertions(+), 0 deletions(-) create mode 100644 arch/arm/plat-samsung/include/plat/regs-fimc.h diff --git a/arch/arm/plat-samsung/include/plat/regs-fimc.h b/arch/arm/plat-samsung/include/plat/regs-fimc.h new file mode 100644 index 000..7f3141c --- /dev/null +++ b/arch/arm/plat-samsung/include/plat/regs-fimc.h @@ -0,0 +1,294 @@ +/* arch/arm/plat-s5p/include/plat/regs-fimc.h + * + * Register definition file for Samsung Camera Interface (FIMC) driver + * + * Copyright (c) 2010 Samsung Electronics + * + * 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 REGS_FIMC_H_ +#define REGS_FIMC_H_ + +#define S5P_CIOYSA(__x)(0x18 + (__x) * 4) +#define S5P_CIOCBSA(__x) (0x28 + (__x) * 4) +#define S5P_CIOCRSA(__x) (0x38 + (__x) * 4) + +/* Input source format */ +#define S5P_CISRCFMT 0x00 +#define S5P_CISRCFMT_ITU601_8BIT (1 31) +#define S5P_CISRCFMT_ITU601_16BIT (1 29) +#define S5P_CISRCFMT_ORDER422_YCBYCR (0 14) +#define S5P_CISRCFMT_ORDER422_YCRYCB (1 14) +#define S5P_CISRCFMT_ORDER422_CBYCRY (2 14) +#define S5P_CISRCFMT_ORDER422_CRYCBY (3 14) +#define S5P_CISRCFMT_HSIZE(x) ((x) 16) +#define S5P_CISRCFMT_VSIZE(x) ((x) 0) + +/* Window offset */ +#define S5P_CIWDOFST 0x04 +#define S5P_CIWDOFST_WINOFSEN (1 31) +#define S5P_CIWDOFST_CLROVFIY (1 30) +#define S5P_CIWDOFST_CLROVRLB (1 29) +#define S5P_CIWDOFST_WINHOROFST_MASK (0x7ff 16) +#define S5P_CIWDOFST_CLROVFICB (1 15) +#define S5P_CIWDOFST_CLROVFICR (1 14) +#define S5P_CIWDOFST_WINHOROFST(x) ((x) 16) +#define S5P_CIWDOFST_WINVEROFST(x) ((x) 0) +#define S5P_CIWDOFST_WINVEROFST_MASK (0xfff 0) + +/* Global control */ +#define S5P_CIGCTRL0x08 +#define S5P_CIGCTRL_SWRST (1 31) +#define S5P_CIGCTRL_CAMRST_A (1 30) +#define S5P_CIGCTRL_SELCAM_ITU_A (1 29) +#define S5P_CIGCTRL_SELCAM_ITU_MASK(1 29) +#define S5P_CIGCTRL_TESTPAT_NORMAL (0 27) +#define S5P_CIGCTRL_TESTPAT_COLOR_BAR (1 27) +#define S5P_CIGCTRL_TESTPAT_HOR_INC(2 27) +#define S5P_CIGCTRL_TESTPAT_VER_INC(3 27) +#define S5P_CIGCTRL_TESTPAT_MASK (3 27) +#define S5P_CIGCTRL_TESTPAT_SHIFT (27) +#define S5P_CIGCTRL_INVPOLPCLK (1 26) +#define S5P_CIGCTRL_INVPOLVSYNC(1 25) +#define S5P_CIGCTRL_INVPOLHREF (1 24) +#define S5P_CIGCTRL_IRQ_OVFEN (1 22) +#define S5P_CIGCTRL_HREF_MASK (1 21) +#define S5P_CIGCTRL_IRQ_LEVEL (1 20) +#define S5P_CIGCTRL_IRQ_CLR(1 19) +#define S5P_CIGCTRL_IRQ_ENABLE (1 16) +#define S5P_CIGCTRL_SHDW_DISABLE (1 12) +#define S5P_CIGCTRL_SELCAM_MIPI_A (1 7) +#define S5P_CIGCTRL_CAMIF_SELWB(1 6) +#define S5P_CIGCTRL_INVPOLHSYNC(1 4) +#define S5P_CIGCTRL_SELCAM_MIPI(1 3) +#define S5P_CIGCTRL_INTERLACE (1 0) + +/* Window offset 2 */ +#define S5P_CIWDOFST2 0x14 +#define S5P_CIWDOFST2_HOROFF_MASK (0xfff 16) +#define S5P_CIWDOFST2_VEROFF_MASK (0xfff 0) +#define S5P_CIWDOFST2_HOROFF(x)((x) 16) +#define S5P_CIWDOFST2_VEROFF(x)((x) 0) + +/* Output DMA Y plane start address */ +#define S5P_CIOYSA10x18 +#define S5P_CIOYSA20x1c +#define S5P_CIOYSA30x20 +#define S5P_CIOYSA40x24 + +/* Output DMA Cb plane start address */ +#define S5P_CIOCBSA1 0x28 +#define S5P_CIOCBSA2 0x2c +#define S5P_CIOCBSA3 0x30 +#define S5P_CIOCBSA4 0x34 + +/* Output DMA Cr plane start address */ +#define S5P_CIOCRSA1 0x38 +#define S5P_CIOCRSA2 0x3c +#define S5P_CIOCRSA3 0x40 +#define S5P_CIOCRSA4 0x44 + +/* Target image format */ +#define S5P_CITRGFMT 0x48 +#define S5P_CITRGFMT_INROT90 (1 31) +#define S5P_CITRGFMT_YCBCR420 (0 29) +#define S5P_CITRGFMT_YCBCR422 (1 29) +#define S5P_CITRGFMT_YCBCR422_1P (2 29) +#define S5P_CITRGFMT_RGB (3 29) +#define S5P_CITRGFMT_FMT_MASK (3 29) +#define S5P_CITRGFMT_HSIZE_MASK(0xfff 16) +#define S5P_CITRGFMT_FLIP_SHIFT
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jul 23 19:00:21 CEST 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14993:9652f85e688a git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 41c5f984b67b331064e69acc9fca5e99bf73d400 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-armv5: OK linux-2.6.34-armv5: WARNINGS linux-2.6.35-rc1-armv5: ERRORS linux-2.6.32.6-armv5-davinci: OK linux-2.6.33-armv5-davinci: OK linux-2.6.34-armv5-davinci: WARNINGS linux-2.6.35-rc1-armv5-davinci: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-armv5-ixp: WARNINGS linux-2.6.35-rc1-armv5-ixp: ERRORS linux-2.6.32.6-armv5-omap2: OK linux-2.6.33-armv5-omap2: OK linux-2.6.34-armv5-omap2: WARNINGS linux-2.6.35-rc1-armv5-omap2: ERRORS linux-2.6.22.19-i686: ERRORS linux-2.6.23.17-i686: ERRORS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: OK linux-2.6.32.6-i686: OK linux-2.6.33-i686: OK linux-2.6.34-i686: WARNINGS linux-2.6.35-rc1-i686: ERRORS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-m32r: WARNINGS linux-2.6.35-rc1-m32r: ERRORS linux-2.6.32.6-mips: OK linux-2.6.33-mips: OK linux-2.6.34-mips: WARNINGS linux-2.6.35-rc1-mips: ERRORS linux-2.6.32.6-powerpc64: OK linux-2.6.33-powerpc64: OK linux-2.6.34-powerpc64: WARNINGS linux-2.6.35-rc1-powerpc64: ERRORS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.17-x86_64: ERRORS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: OK linux-2.6.32.6-x86_64: OK linux-2.6.33-x86_64: OK linux-2.6.34-x86_64: WARNINGS linux-2.6.35-rc1-x86_64: ERRORS linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: OK linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- 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] Per-subdev, host-specific data
On Fri, 2010-07-23 at 16:31 +0200, Laurent Pinchart wrote: Hi Hans, On Friday 23 July 2010 15:46:29 Hans Verkuil wrote: On Friday 23 July 2010 15:01:29 Laurent Pinchart wrote: Hi everybody, Trying to implement support for multiple sensors connected to the same OMAP3 ISP input (all but one of the sensors need to be kept in reset obviously), I need to associate host-specific data to the sensor subdevs. The terms host and bridge are considered as synonyms in the rest of this e- mail. The OMAP3 ISP platform data has interface configuration parameters for the two CSI2 (a and c), CCP2 and parallel interfaces. The parameters are used to configure the bus when a sensor is selected. To support multiple sensors on the same input, the parameters need to be specified per-sensor, and not ISP- wide. No issue in the platform data. Board codes declare an array of structures that embed a struct v4l2_subdev_i2c_board_info instance and an OMAP3 ISP-specific interface configuration structure. At runtime, when a sensor is selected, I need to access the OMAP3 ISP-specific interface configuration structure for the selected sensor. At that point all I have is a v4l2_subdev structure pointer, without a way to get back to the interface configuration structure. The only point in the code where the v4l2_subdev and the interface configuration data are both known and could be linked together is in the host driver's probe function, where the v4l2_subdev instances are created. I have two solutions there: - store the v4l2_subdev pointer and the interface configuration data pointer in a host-specific array, and perform a an array lookup operation at runtime with the v4l2_subdev pointer as a key - add a void *host_priv field to the v4l2_subdev structure, store the interface configuration data pointer in that field, and use the field at runtime The second solution seems cleaner but requires an additional field in v4l2_subdev. Opinions and other comments will be appreciated. Why isn't v4l2_set_subdevdata(sd, private_ptr); sufficient? The cx18-av-core.[ch] files use that to get a bridge instance pointer from a v4l2_subdev. Or is it that the v4l2_subdev infrastructure help functions for I2C connected devices already claim that? Regards, Andy There is a third option: the grp_id field is owned by the host driver, so you could make that an index into a host specific array. Good point. That said, I think having a host_priv field isn't a bad idea. Although if we do this, then I think the existing priv field should be renamed to drv_priv to prevent confusion. As Guennadi, Sakari and you all agree that the host_priv field is a good idea, I'll submit a patch. Thanks. -- 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: Mystique SaTiX-S2 Dual
OJ a écrit : I am using this card: http://www.linuxtv.org/wiki/index.php/Mystique_SaTiX-S2_Dual (v2) According to the wiki I should use the ngene driver, but I am not able to compile it. Downloaded the latest version from Mercury yesterday. Error message when compiling: $ make ngene make -C /home/olejl/src/v4l-dvb/v4l ngene make[1]: Entering directory `/home/olejl/src/v4l-dvb/v4l' cc -I. ngene.o -o ngene /usr/lib/gcc/x86_64-linux-gnu/4.4.3/../../../../lib/crt1.o: In function `_start': (.text+0x20): undefined reference to `main' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:202: undefined reference to `__wake_up' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:211: undefined reference to `_spin_lock' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:250: undefined reference to `_spin_lock' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `tasklet_schedule': /usr/src/linux-headers-2.6.32-23-generic/include/linux/interrupt.h:469: undefined reference to `__tasklet_schedule' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:218: undefined reference to `__wake_up' ngene.o: In function `tasklet_schedule': /usr/src/linux-headers-2.6.32-23-generic/include/linux/interrupt.h:469: undefined reference to `__tasklet_schedule' ngene.o: In function `irq_handler': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:239: undefined reference to `printk' ngene.o: In function `demux_tasklet': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:103: undefined reference to `_spin_lock_irq' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `raw_local_irq_enable': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:864: undefined reference to `pv_irq_ops' ngene.o: In function `demux_tasklet': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:173: undefined reference to `_spin_lock_irq' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:139: undefined reference to `printk' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `raw_local_irq_enable': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:864: undefined reference to `pv_irq_ops' ngene.o: In function `demux_tasklet': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:146: undefined reference to `printk' ngene.o: In function `ngene_stop': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1602: undefined reference to `down' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1603: undefined reference to `i2c_del_adapter' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1604: undefined reference to `i2c_del_adapter' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1612: undefined reference to `free_irq' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:1615: undefined reference to `pci_disable_msi' ngene.o: In function `ngene_command': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:380: undefined reference to `down' ngene.o: In function `ngene_command_mutex': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:328: undefined reference to `_spin_lock_irq' ngene.o: In function `__raw_spin_unlock': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:769: undefined reference to `pv_lock_ops' ngene.o: In function `raw_local_irq_enable': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/paravirt.h:864: undefined reference to `pv_irq_ops' ngene.o: In function `ngene_command_mutex': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `autoremove_wake_function' ngene.o: In function `get_current': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/current.h:14: undefined reference to `per_cpu__current_task' ngene.o: In function `ngene_command_mutex': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `prepare_to_wait' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `schedule_timeout' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:341: undefined reference to `finish_wait' /home/olejl/src/v4l-dvb/v4l/ngene-core.c:351: undefined reference to `printk' ngene.o: In function `memcpy_fromio': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/io_64.h:151: undefined reference to `__memcpy_fromio' ngene.o: In function `dump_command_io': /home/olejl/src/v4l-dvb/v4l/ngene-core.c:278: undefined reference to `printk' ngene.o: In function `memcpy_fromio': /usr/src/linux-headers-2.6.32-23-generic/arch/x86/include/asm/io_64.h:151: undefined reference to `__memcpy_fromio' ngene.o: In function `dump_command_io':
