[PATCH] Add missing else case.
From 59306435992d9349f10ad82a8adf14d98becbbe8 Mon Sep 17 00:00:00 2001 From: Hans Petter Selasky hsela...@c2i.net Date: Fri, 3 Aug 2012 08:34:05 +0200 Subject: [PATCH] Add missing else case. Signed-off-by: Hans Petter Selasky hsela...@c2i.net --- drivers/media/common/tuners/tuner-xc2028.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/media/common/tuners/tuner-xc2028.c b/drivers/media/common/tuners/tuner-xc2028.c index ea0550e..49e63ec 100644 --- a/drivers/media/common/tuners/tuner-xc2028.c +++ b/drivers/media/common/tuners/tuner-xc2028.c @@ -1414,8 +1414,8 @@ static int xc2028_set_config(struct dvb_frontend *fe, void *priv_cfg) tuner_err(Failed to request firmware %s\n, priv-fname); priv-state = XC2028_NODEV; - } - priv-state = XC2028_WAITING_FIRMWARE; + } else + priv-state = XC2028_WAITING_FIRMWARE; } mutex_unlock(priv-lock); -- 1.7.10.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
Re: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Bhupesh, On Wednesday 01 August 2012 21:29:30 Bhupesh SHARMA wrote: On Wednesday, August 01, 2012 6:46 PM Laurent Pinchart wrote: On Wednesday 01 August 2012 14:26:33 Bhupesh SHARMA wrote: Hi Laurent, I have a query for you regarding the support and testing of MJPEG frame type in the UVC webcam gadget. I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are supported. I was trying the same out and got confused because the data arriving from a real video capture video supporting JPEG will have no fixed size. We will have the JPEG defined Start-of-Frame and End-of- Frame markers defining the boundary of the JPEG frame. But for almost all JPEG video capture devices even if we have kept a frame size of VGA initially, the final frame size will be a compressed version (with the compression depending on the nature of the scene, so a flat scene will have high compression and hence less frame size) of VGA and will not be equal to 640 * 480. So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept as 614400 in webcam.c (see [1]). The dwMaxVideoFrameBufferSize value must be larger than or equal to the largest MJPEG frame size. As I have no idea what that value is, I've kept the same size as for uncompressed frames, which should be big enough (and most probably too big). .. Yes, so that means that the user-space application should set the length of the buffer being queued at the UVC side equal to the length of the buffer dequeued from the V4L2 side, to ensure that varying length JPEG frames are correctly handled. You should copy the bytesused field from the captured v4l2_buffer to the output v4l2_buffer. The length field stores the total buffer size, not the number of bytes used. I will try with these changes in the user-space daemon. -- 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: [v7] media: coda: Add driver for Coda video codec.
Hi Javier,
Glad to see the vpu patch. I'd like to try it on imx6. What else
do I need to do besides add vpu devices in dts? Do you have a gst
plugin or any other test program to test it?
Please also see below comments.
On Mon, Jul 23, 2012 at 11:31:01AM +, Javier Martin wrote:
Coda is a range of video codecs from ChipsMedia that
support H.264, H.263, MPEG4 and other video standards.
Currently only support for the codadx6 included in the
i.MX27 SoC is added. H.264 and MPEG4 video encoding
are the only supported capabilities by now.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v6:
- Cosmetic fixes pointed out by Sakari.
- Now passes 'v4l2-compliance'.
---
drivers/media/video/Kconfig |9 +
drivers/media/video/Makefile |1 +
drivers/media/video/coda.c | 1848
++
drivers/media/video/coda.h | 216 +
4 files changed, 2074 insertions(+)
create mode 100644 drivers/media/video/coda.c
create mode 100644 drivers/media/video/coda.h
[...]
+static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct coda_ctx *ctx = vb2_get_drv_priv(q);
+ struct v4l2_device *v4l2_dev = ctx-dev-v4l2_dev;
+ u32 bitstream_buf, bitstream_size;
+ struct coda_dev *dev = ctx-dev;
+ struct coda_q_data *q_data_src, *q_data_dst;
+ u32 dst_fourcc;
+ struct vb2_buffer *buf;
+ struct vb2_queue *src_vq;
+ u32 value;
+ int i = 0;
+
+ if (count 1)
+ return -EINVAL;
+
+ if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ ctx-rawstreamon = 1;
+ else
+ ctx-compstreamon = 1;
+
+ /* Don't start the coda unless both queues are on */
+ if (!(ctx-rawstreamon ctx-compstreamon))
+ return 0;
+
Remove spaces above.
+ ctx-gopcounter = ctx-params.gop_size - 1;
+
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ buf = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ bitstream_buf = vb2_dma_contig_plane_dma_addr(buf, 0);
+ q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
+ bitstream_size = q_data_dst-sizeimage;
+ dst_fourcc = q_data_dst-fmt-fourcc;
+
+ /* Find out whether coda must encode or decode */
+ if (q_data_src-fmt-type == CODA_FMT_RAW
+ q_data_dst-fmt-type == CODA_FMT_ENC) {
+ ctx-inst_type = CODA_INST_ENCODER;
+ } else if (q_data_src-fmt-type == CODA_FMT_ENC
+q_data_dst-fmt-type == CODA_FMT_RAW) {
+ ctx-inst_type = CODA_INST_DECODER;
+ v4l2_err(v4l2_dev, decoding not supported.\n);
+ return -EINVAL;
+ } else {
+ v4l2_err(v4l2_dev, couldn't tell instance type.\n);
+ return -EINVAL;
+ }
+
+ if (!coda_is_initialized(dev)) {
+ v4l2_err(v4l2_dev, coda is not initialized.\n);
+ return -EFAULT;
+ }
+ coda_write(dev, ctx-parabuf.paddr, CODA_REG_BIT_PARA_BUF_ADDR);
+ coda_write(dev, bitstream_buf, CODA_REG_BIT_RD_PTR(ctx-idx));
+ coda_write(dev, bitstream_buf, CODA_REG_BIT_WR_PTR(ctx-idx));
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+ coda_write(dev, CODADX6_STREAM_BUF_DYNALLOC_EN |
+ CODADX6_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
+ break;
+ default:
+ coda_write(dev, CODA7_STREAM_BUF_DYNALLOC_EN |
+ CODA7_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
+ }
+
+ /* Configure the coda */
+ coda_write(dev, 0x4c00, CODA_REG_BIT_SEARCH_RAM_BASE_ADDR);
+
+ /* Could set rotation here if needed */
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+ value = (q_data_src-width CODADX6_PICWIDTH_MASK)
CODADX6_PICWIDTH_OFFSET;
longer than 80 characters. Could you run checkpatch to do further check?
+ break;
+ default:
+ value = (q_data_src-width CODA7_PICWIDTH_MASK)
CODA7_PICWIDTH_OFFSET;
+ }
+ value |= (q_data_src-height CODA_PICHEIGHT_MASK)
CODA_PICHEIGHT_OFFSET;
+ coda_write(dev, value, CODA_CMD_ENC_SEQ_SRC_SIZE);
+ coda_write(dev, ctx-params.framerate,
+CODA_CMD_ENC_SEQ_SRC_F_RATE);
+
[...]
+static int coda_firmware_request(struct coda_dev *dev)
+{
+ char *fw = dev-devtype-firmware;
+
+ dev_dbg(dev-plat_dev-dev, requesting firmware '%s' for %s\n, fw,
+ coda_product_name(dev-devtype-product));
+
+ return request_firmware_nowait(THIS_MODULE, true,
+ fw, dev-plat_dev-dev, GFP_KERNEL, dev, coda_fw_callback);
why not remove the wrapper and call request_firmware_nowait directly?
+}
+
+enum coda_platform {
+ CODA_IMX27,
+};
+
+static struct coda_devtype
Re: [v7] media: coda: Add driver for Coda video codec.
On Fri August 3 2012 10:24:43 Richard Zhao wrote:
Hi Javier,
Glad to see the vpu patch. I'd like to try it on imx6. What else
do I need to do besides add vpu devices in dts? Do you have a gst
plugin or any other test program to test it?
Please also see below comments.
On Mon, Jul 23, 2012 at 11:31:01AM +, Javier Martin wrote:
Coda is a range of video codecs from ChipsMedia that
support H.264, H.263, MPEG4 and other video standards.
Currently only support for the codadx6 included in the
i.MX27 SoC is added. H.264 and MPEG4 video encoding
are the only supported capabilities by now.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v6:
- Cosmetic fixes pointed out by Sakari.
- Now passes 'v4l2-compliance'.
---
drivers/media/video/Kconfig |9 +
drivers/media/video/Makefile |1 +
drivers/media/video/coda.c | 1848
++
drivers/media/video/coda.h | 216 +
4 files changed, 2074 insertions(+)
create mode 100644 drivers/media/video/coda.c
create mode 100644 drivers/media/video/coda.h
[...]
+static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct coda_ctx *ctx = vb2_get_drv_priv(q);
+ struct v4l2_device *v4l2_dev = ctx-dev-v4l2_dev;
+ u32 bitstream_buf, bitstream_size;
+ struct coda_dev *dev = ctx-dev;
+ struct coda_q_data *q_data_src, *q_data_dst;
+ u32 dst_fourcc;
+ struct vb2_buffer *buf;
+ struct vb2_queue *src_vq;
+ u32 value;
+ int i = 0;
+
+ if (count 1)
+ return -EINVAL;
+
+ if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ ctx-rawstreamon = 1;
+ else
+ ctx-compstreamon = 1;
+
+ /* Don't start the coda unless both queues are on */
+ if (!(ctx-rawstreamon ctx-compstreamon))
+ return 0;
+
Remove spaces above.
+ ctx-gopcounter = ctx-params.gop_size - 1;
+
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ buf = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ bitstream_buf = vb2_dma_contig_plane_dma_addr(buf, 0);
+ q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
+ bitstream_size = q_data_dst-sizeimage;
+ dst_fourcc = q_data_dst-fmt-fourcc;
+
+ /* Find out whether coda must encode or decode */
+ if (q_data_src-fmt-type == CODA_FMT_RAW
+ q_data_dst-fmt-type == CODA_FMT_ENC) {
+ ctx-inst_type = CODA_INST_ENCODER;
+ } else if (q_data_src-fmt-type == CODA_FMT_ENC
+ q_data_dst-fmt-type == CODA_FMT_RAW) {
+ ctx-inst_type = CODA_INST_DECODER;
+ v4l2_err(v4l2_dev, decoding not supported.\n);
+ return -EINVAL;
+ } else {
+ v4l2_err(v4l2_dev, couldn't tell instance type.\n);
+ return -EINVAL;
+ }
+
+ if (!coda_is_initialized(dev)) {
+ v4l2_err(v4l2_dev, coda is not initialized.\n);
+ return -EFAULT;
+ }
+ coda_write(dev, ctx-parabuf.paddr, CODA_REG_BIT_PARA_BUF_ADDR);
+ coda_write(dev, bitstream_buf, CODA_REG_BIT_RD_PTR(ctx-idx));
+ coda_write(dev, bitstream_buf, CODA_REG_BIT_WR_PTR(ctx-idx));
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+ coda_write(dev, CODADX6_STREAM_BUF_DYNALLOC_EN |
+ CODADX6_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
+ break;
+ default:
+ coda_write(dev, CODA7_STREAM_BUF_DYNALLOC_EN |
+ CODA7_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
+ }
+
+ /* Configure the coda */
+ coda_write(dev, 0x4c00, CODA_REG_BIT_SEARCH_RAM_BASE_ADDR);
+
+ /* Could set rotation here if needed */
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+ value = (q_data_src-width CODADX6_PICWIDTH_MASK)
CODADX6_PICWIDTH_OFFSET;
longer than 80 characters. Could you run checkpatch to do further check?
This is a checkpatch warning, not an error. One should use one's own judgement
whether
to take action or not. It is more important that the code is readable than that
it fits
within 80 characters, although long lines can be an indication of poor
readability.
In this case I personally don't think it will be easier to read if this line is
split up.
Regards,
Hans
--
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: [v7] media: coda: Add driver for Coda video codec.
On Fri, Aug 03, 2012 at 10:47:01AM +0200, Hans Verkuil wrote:
On Fri August 3 2012 10:24:43 Richard Zhao wrote:
Hi Javier,
Glad to see the vpu patch. I'd like to try it on imx6. What else
do I need to do besides add vpu devices in dts? Do you have a gst
plugin or any other test program to test it?
Please also see below comments.
On Mon, Jul 23, 2012 at 11:31:01AM +, Javier Martin wrote:
Coda is a range of video codecs from ChipsMedia that
support H.264, H.263, MPEG4 and other video standards.
Currently only support for the codadx6 included in the
i.MX27 SoC is added. H.264 and MPEG4 video encoding
are the only supported capabilities by now.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
Acked-by: Hans Verkuil hans.verk...@cisco.com
Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com
---
Changes since v6:
- Cosmetic fixes pointed out by Sakari.
- Now passes 'v4l2-compliance'.
---
drivers/media/video/Kconfig |9 +
drivers/media/video/Makefile |1 +
drivers/media/video/coda.c | 1848
++
drivers/media/video/coda.h | 216 +
4 files changed, 2074 insertions(+)
create mode 100644 drivers/media/video/coda.c
create mode 100644 drivers/media/video/coda.h
[...]
+static int coda_start_streaming(struct vb2_queue *q, unsigned int count)
+{
+ struct coda_ctx *ctx = vb2_get_drv_priv(q);
+ struct v4l2_device *v4l2_dev = ctx-dev-v4l2_dev;
+ u32 bitstream_buf, bitstream_size;
+ struct coda_dev *dev = ctx-dev;
+ struct coda_q_data *q_data_src, *q_data_dst;
+ u32 dst_fourcc;
+ struct vb2_buffer *buf;
+ struct vb2_queue *src_vq;
+ u32 value;
+ int i = 0;
+
+ if (count 1)
+ return -EINVAL;
+
+ if (q-type == V4L2_BUF_TYPE_VIDEO_OUTPUT)
+ ctx-rawstreamon = 1;
+ else
+ ctx-compstreamon = 1;
+
+ /* Don't start the coda unless both queues are on */
+ if (!(ctx-rawstreamon ctx-compstreamon))
+ return 0;
+
Remove spaces above.
+ ctx-gopcounter = ctx-params.gop_size - 1;
+
+ q_data_src = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_OUTPUT);
+ buf = v4l2_m2m_next_dst_buf(ctx-m2m_ctx);
+ bitstream_buf = vb2_dma_contig_plane_dma_addr(buf, 0);
+ q_data_dst = get_q_data(ctx, V4L2_BUF_TYPE_VIDEO_CAPTURE);
+ bitstream_size = q_data_dst-sizeimage;
+ dst_fourcc = q_data_dst-fmt-fourcc;
+
+ /* Find out whether coda must encode or decode */
+ if (q_data_src-fmt-type == CODA_FMT_RAW
+ q_data_dst-fmt-type == CODA_FMT_ENC) {
+ ctx-inst_type = CODA_INST_ENCODER;
+ } else if (q_data_src-fmt-type == CODA_FMT_ENC
+q_data_dst-fmt-type == CODA_FMT_RAW) {
+ ctx-inst_type = CODA_INST_DECODER;
+ v4l2_err(v4l2_dev, decoding not supported.\n);
+ return -EINVAL;
+ } else {
+ v4l2_err(v4l2_dev, couldn't tell instance type.\n);
+ return -EINVAL;
+ }
+
+ if (!coda_is_initialized(dev)) {
+ v4l2_err(v4l2_dev, coda is not initialized.\n);
+ return -EFAULT;
+ }
+ coda_write(dev, ctx-parabuf.paddr, CODA_REG_BIT_PARA_BUF_ADDR);
+ coda_write(dev, bitstream_buf, CODA_REG_BIT_RD_PTR(ctx-idx));
+ coda_write(dev, bitstream_buf, CODA_REG_BIT_WR_PTR(ctx-idx));
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+ coda_write(dev, CODADX6_STREAM_BUF_DYNALLOC_EN |
+ CODADX6_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
+ break;
+ default:
+ coda_write(dev, CODA7_STREAM_BUF_DYNALLOC_EN |
+ CODA7_STREAM_BUF_PIC_RESET, CODA_REG_BIT_STREAM_CTRL);
+ }
+
+ /* Configure the coda */
+ coda_write(dev, 0x4c00, CODA_REG_BIT_SEARCH_RAM_BASE_ADDR);
+
+ /* Could set rotation here if needed */
+ switch (dev-devtype-product) {
+ case CODA_DX6:
+ value = (q_data_src-width CODADX6_PICWIDTH_MASK)
CODADX6_PICWIDTH_OFFSET;
longer than 80 characters. Could you run checkpatch to do further check?
This is a checkpatch warning, not an error. One should use one's own
judgement whether
to take action or not. It is more important that the code is readable than
that it fits
within 80 characters, although long lines can be an indication of poor
readability.
Yes, you are right. I don't insist but I like cut it off except for
files like register definition with aligned lines.
In this case I personally don't think it will be easier to read if this line
is split up.
My point here is checkpatch.
total: 2 errors, 30 warnings, 2086 lines checked
Thanks
Richard
Regards,
Hans
--
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: [Workshop-2011] Media summit/KS-2012 proposals
On Fri August 3 2012 07:37:13 Jun Nie wrote: 2012/8/1 Hans Verkuil hverk...@xs4all.nl: On Tue 31 July 2012 19:58:23 Mauro Carvalho Chehab wrote: In order to sum-up the discussions around the media summit, this is what we've got so far: Proposals proposed by =|= Common device tree bindings for media devices Sylvester Nawrocki / Guennadi Liakhovetski ALSA and V4L/Media Controller Steven Toth / Laurent Pinchart ARM and needed features for V4L/DVB Steven Toth Intel media SDK Steven Toth V4L compiance tool Hans Verkuil V4L2 API ambiguities Hans Verkuil Media Controller library Laurent Pincart / Sakari Ailus SoC Vendors feedback – how to help them to go upstream – Android's V4L2 cam library Laurent Pincart / Guennadi Liakhovetski / Palash Bandyopadhyay / Naveen Krishnamurthy Synchronization, shared resource and optimizations Pawel Osciak V4L2/DVB issues from userspace perspective Rémi Denis-Courmont As we'll have only one day for the summit, we may need to remove some themes, or maybe to get an extra time during LPC for the remaining discussions. Possible attendents: === Guennadi Liakhovetski Laurent Pinchart Mauro Carvalho Chehab Michael Krufky Naveen Krishnamurthy +1 seat from ST (waiting Naveen to define who will be the other seat) Palash Bandyopadhyay Pawel Osciak Rémi Denis-Courmont Sakari Ailus Steven Toth Sylvester Nawrocki Am I missing something? Are there other proposals or people intending to participate? Yes: I would like to discuss how to add support for HDMI CEC to the kernel. In particularly I need some feedback from the GPU driver developers on what their ideas are, since CEC is something that touches both V4L2 and GPU. I am not familiar with CEC implementation in GPU. As far as I am aware there isn't any. But CEC should be independent in functionality with audio/video though it is A/V related. I prefer to support only CEC frame TX/RX in kernel. CEC include different category features that need parsing and may need application interaction. Venders may also configure some features as not supported. If kernel support more than TX/RX, policy may be separated to user space part and kernel space part. The kernel interface also becomes complex, maybe ambiguous too. An user space library is more suitable for this task to interact with OS/media player/audio control/etc. I wish that were possible. Our current implementation internally is as you proposed, but we recently discovered that for HDMI 1.4a this won't fly. There the CEC channel is also used for control of the ethernet and audio return channel, and even for hotplug detect in some cases. That's something that has to be handled entirely in kernelspace. So some parts of the CEC protocol have to be internally processed, other parts have to be processed in userspace. This really complicates things and it makes it even more important that the subsystems that need CEC work together on this. Regards, Hans -- 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 1/6] libdvbv5: EIT parser
Signed-off-by: André Roth neol...@gmail.com
---
lib/include/descriptors/desc_event_short.h | 51 +
lib/include/descriptors/desc_language.h |4 +-
lib/include/descriptors/desc_network_name.h |4 +-
lib/include/descriptors/eit.h | 80
lib/include/descriptors/pat.h |6 +-
lib/include/descriptors/sdt.h |4 +-
lib/libdvbv5/Makefile.am|4 +-
lib/libdvbv5/descriptors.c | 65 +---
lib/libdvbv5/descriptors/desc_event_short.c | 89 ++
lib/libdvbv5/descriptors/desc_service.c |8 +-
lib/libdvbv5/descriptors/eit.c | 107 +++
lib/libdvbv5/descriptors/nit.c |5 +-
lib/libdvbv5/descriptors/pat.c |8 +-
lib/libdvbv5/descriptors/pmt.c | 23 +++---
lib/libdvbv5/descriptors/sdt.c | 16 +++--
lib/libdvbv5/dvb-scan.c | 14 +++-
16 files changed, 439 insertions(+), 49 deletions(-)
create mode 100644 lib/include/descriptors/desc_event_short.h
create mode 100644 lib/include/descriptors/eit.h
create mode 100644 lib/libdvbv5/descriptors/desc_event_short.c
create mode 100644 lib/libdvbv5/descriptors/eit.c
diff --git a/lib/include/descriptors/desc_event_short.h
b/lib/include/descriptors/desc_event_short.h
new file mode 100644
index 000..1809ffb
--- /dev/null
+++ b/lib/include/descriptors/desc_event_short.h
@@ -0,0 +1,51 @@
+/*
+ * Copyright (c) 2011-2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * Copyright (c) 2012 - Andre Roth neol...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation version 2
+ * of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ * Or, point your browser to
http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+ *
+ */
+
+#ifndef _DESC_EVENT_SHORT_H
+#define _DESC_EVENT_SHORT_H
+
+#include stdint.h
+#include unistd.h /* ssize_t */
+
+struct dvb_desc_event_short {
+ uint8_t type;
+ uint8_t length;
+ struct dvb_desc *next;
+
+ unsigned char language[4];
+ char *name;
+ char *text;
+} __attribute__((packed));
+
+struct dvb_v5_fe_parms;
+
+#ifdef __cplusplus
+extern C {
+#endif
+
+ssize_t dvb_desc_event_short_init(struct dvb_v5_fe_parms *parms, const uint8_t
*buf, struct dvb_desc *desc);
+void dvb_desc_event_short_print (struct dvb_v5_fe_parms *parms, const struct
dvb_desc *desc);
+
+#ifdef __cplusplus
+}
+#endif
+
+#endif
diff --git a/lib/include/descriptors/desc_language.h
b/lib/include/descriptors/desc_language.h
index eca9cdb..8829bf1 100644
--- a/lib/include/descriptors/desc_language.h
+++ b/lib/include/descriptors/desc_language.h
@@ -19,8 +19,8 @@
*
*/
-#ifndef _LANGUAGE_H
-#define _LANGUAGE_H
+#ifndef _DESC_LANGUAGE_H
+#define _DESC_LANGUAGE_H
#include stdint.h
#include unistd.h /* ssize_t */
diff --git a/lib/include/descriptors/desc_network_name.h
b/lib/include/descriptors/desc_network_name.h
index 706b36c..ece0fd9 100644
--- a/lib/include/descriptors/desc_network_name.h
+++ b/lib/include/descriptors/desc_network_name.h
@@ -19,8 +19,8 @@
*
*/
-#ifndef _NETWORK_NAME_H
-#define _NETWORK_NAME_H
+#ifndef _DESC_NETWORK_NAME_H
+#define _DESC_NETWORK_NAME_H
#include stdint.h
#include unistd.h /* ssize_t */
diff --git a/lib/include/descriptors/eit.h b/lib/include/descriptors/eit.h
new file mode 100644
index 000..4cf7cc1
--- /dev/null
+++ b/lib/include/descriptors/eit.h
@@ -0,0 +1,80 @@
+/*
+ * Copyright (c) 2011-2012 - Mauro Carvalho Chehab mche...@redhat.com
+ * Copyright (c) 2012 - Andre Roth neol...@gmail.com
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License
+ * as published by the Free Software Foundation version 2
+ * of the License.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ * Or, point your browser to
[PATCH 2/6] libdvbv5: allow more options in set_pesfilter
Signed-off-by: André Roth neol...@gmail.com
---
lib/include/dvb-demux.h |4 +++-
lib/libdvbv5/dvb-demux.c | 14 ++
utils/dvb/dvbv5-zap.c| 17 +
3 files changed, 22 insertions(+), 13 deletions(-)
diff --git a/lib/include/dvb-demux.h b/lib/include/dvb-demux.h
index 240d471..25cd56c 100644
--- a/lib/include/dvb-demux.h
+++ b/lib/include/dvb-demux.h
@@ -29,6 +29,8 @@
#ifndef _DVB_DEMUX_H
#define _DVB_DEMUX_H
+#include linux/dvb/dmx.h
+
#ifdef __cplusplus
extern C {
#endif
@@ -36,7 +38,7 @@ extern C {
int dvb_dmx_open(int adapter, int demux, unsigned verbose);
void dvb_dmx_close(int dmx_fd);
-int set_pesfilter(int dmxfd, int pid, int pes_type, int dvr);
+int dvb_set_pesfilter(int dmxfd, int pid, dmx_pes_type_t type, dmx_output_t
output, int buffersize);
int get_pmt_pid(const char *dmxdev, int sid);
diff --git a/lib/libdvbv5/dvb-demux.c b/lib/libdvbv5/dvb-demux.c
index 7ece976..138b58a 100644
--- a/lib/libdvbv5/dvb-demux.c
+++ b/lib/libdvbv5/dvb-demux.c
@@ -38,7 +38,6 @@
#include fcntl.h
#include stdlib.h /* free */
-#include linux/dvb/dmx.h
#include dvb-demux.h
int dvb_dmx_open(int adapter, int demux, unsigned verbose)
@@ -56,26 +55,25 @@ void dvb_dmx_close(int dmx_fd)
close( dmx_fd);
}
-int set_pesfilter(int dmxfd, int pid, int pes_type, int dvr)
+int dvb_set_pesfilter(int dmxfd, int pid, dmx_pes_type_t type, dmx_output_t
output, int buffersize)
{
struct dmx_pes_filter_params pesfilter;
/* ignore this pid to allow radio services */
if (pid 0 ||
pid = 0x1fff ||
- (pid == 0 pes_type != DMX_PES_OTHER))
+ (pid == 0 type != DMX_PES_OTHER))
return 0;
- if (dvr) {
- int buffersize = 64 * 1024;
+ if (buffersize) {
if (ioctl(dmxfd, DMX_SET_BUFFER_SIZE, buffersize) == -1)
- perror(DMX_SET_BUFFER_SIZE failed);
+ perror(DMX_SET_BUFFER_SIZE failed);
}
pesfilter.pid = pid;
pesfilter.input = DMX_IN_FRONTEND;
- pesfilter.output = dvr ? DMX_OUT_TS_TAP : DMX_OUT_DECODER;
- pesfilter.pes_type = pes_type;
+ pesfilter.output = output;
+ pesfilter.pes_type = type;
pesfilter.flags = DMX_IMMEDIATE_START;
if (ioctl(dmxfd, DMX_SET_PES_FILTER, pesfilter) == -1) {
diff --git a/utils/dvb/dvbv5-zap.c b/utils/dvb/dvbv5-zap.c
index f7e3c4a..6445149 100644
--- a/utils/dvb/dvbv5-zap.c
+++ b/utils/dvb/dvbv5-zap.c
@@ -550,14 +550,18 @@ int main(int argc, char **argv)
perror(opening pat demux failed);
return -1;
}
- if (set_pesfilter(pat_fd, 0, DMX_PES_OTHER, args.dvr) 0)
+ if (dvb_set_pesfilter(pat_fd, 0, DMX_PES_OTHER,
+ args.dvr ? DMX_OUT_TS_TAP : DMX_OUT_DECODER,
+ args.dvr ? 64 * 1024 : 0) 0)
return -1;
if ((pmt_fd = open(args.demux_dev, O_RDWR)) 0) {
perror(opening pmt demux failed);
return -1;
}
- if (set_pesfilter(pmt_fd, pmtpid, DMX_PES_OTHER, args.dvr) 0)
+ if (dvb_set_pesfilter(pmt_fd, pmtpid, DMX_PES_OTHER,
+ args.dvr ? DMX_OUT_TS_TAP : DMX_OUT_DECODER,
+ args.dvr ? 64 * 1024 : 0) 0)
return -1;
}
@@ -568,7 +572,10 @@ int main(int argc, char **argv)
PERROR(failed opening '%s', args.demux_dev);
return -1;
}
- if (set_pesfilter(video_fd, vpid, DMX_PES_VIDEO, args.dvr) 0)
+ printf( dvb_set_pesfilter %d\n, vpid );
+ if (dvb_set_pesfilter(video_fd, vpid, DMX_PES_VIDEO,
+ args.dvr ? DMX_OUT_TS_TAP : DMX_OUT_DECODER,
+ args.dvr ? 64 * 1024 : 0) 0)
return -1;
}
@@ -580,7 +587,9 @@ int main(int argc, char **argv)
return -1;
}
- if (set_pesfilter(audio_fd, apid, DMX_PES_AUDIO, args.dvr) 0)
+ if (dvb_set_pesfilter(audio_fd, apid, DMX_PES_AUDIO,
+ args.dvr ? DMX_OUT_TS_TAP : DMX_OUT_DECODER,
+ args.dvr ? 64 * 1024 : 0) 0)
return -1;
}
--
1.7.2.5
--
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 4/6] libdvbv5: added dmx stop function
Signed-off-by: André Roth neol...@gmail.com
---
lib/include/dvb-demux.h |1 +
lib/libdvbv5/dvb-demux.c |5 +
2 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/lib/include/dvb-demux.h b/lib/include/dvb-demux.h
index afd6840..923016e 100644
--- a/lib/include/dvb-demux.h
+++ b/lib/include/dvb-demux.h
@@ -37,6 +37,7 @@ extern C {
int dvb_dmx_open(int adapter, int demux);
void dvb_dmx_close(int dmx_fd);
+void dvb_dmx_stop(int dmx_fd);
int dvb_set_pesfilter(int dmxfd, int pid, dmx_pes_type_t type, dmx_output_t
output, int buffersize);
diff --git a/lib/libdvbv5/dvb-demux.c b/lib/libdvbv5/dvb-demux.c
index d07e6cf..6ed2dcd 100644
--- a/lib/libdvbv5/dvb-demux.c
+++ b/lib/libdvbv5/dvb-demux.c
@@ -55,6 +55,11 @@ void dvb_dmx_close(int dmx_fd)
close( dmx_fd);
}
+void dvb_dmx_stop(int dmx_fd)
+{
+ (void) ioctl( dmx_fd, DMX_STOP);
+}
+
int dvb_set_pesfilter(int dmxfd, int pid, dmx_pes_type_t type, dmx_output_t
output, int buffersize)
{
struct dmx_pes_filter_params pesfilter;
--
1.7.2.5
--
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 5/6] libdvbv5: added abort flag
Signed-off-by: André Roth neol...@gmail.com
---
lib/include/dvb-fe.h |1 +
lib/libdvbv5/dvb-fe.c |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/lib/include/dvb-fe.h b/lib/include/dvb-fe.h
index 8b795cb..b2c3587 100644
--- a/lib/include/dvb-fe.h
+++ b/lib/include/dvb-fe.h
@@ -88,6 +88,7 @@ struct dvb_v5_fe_parms {
unsigneddiseqc_wait;
unsignedfreq_offset;
+ int abort;
dvb_logfunc logfunc;
};
diff --git a/lib/libdvbv5/dvb-fe.c b/lib/libdvbv5/dvb-fe.c
index 1636948..8ed73b6 100644
--- a/lib/libdvbv5/dvb-fe.c
+++ b/lib/libdvbv5/dvb-fe.c
@@ -69,6 +69,7 @@ struct dvb_v5_fe_parms *dvb_fe_open2(int adapter, int
frontend, unsigned verbose
parms-verbose = verbose;
parms-fd = fd;
parms-sat_number = -1;
+parms-abort = 0;
parms-logfunc = logfunc;
if (ioctl(fd, FE_GET_INFO, parms-info) == -1) {
--
1.7.2.5
--
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 3/6] libdvbv5: dvb_dmx_open nonblocking
Signed-off-by: André Roth neol...@gmail.com
---
lib/include/dvb-demux.h |2 +-
lib/libdvbv5/dvb-demux.c |4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/include/dvb-demux.h b/lib/include/dvb-demux.h
index 25cd56c..afd6840 100644
--- a/lib/include/dvb-demux.h
+++ b/lib/include/dvb-demux.h
@@ -35,7 +35,7 @@
extern C {
#endif
-int dvb_dmx_open(int adapter, int demux, unsigned verbose);
+int dvb_dmx_open(int adapter, int demux);
void dvb_dmx_close(int dmx_fd);
int dvb_set_pesfilter(int dmxfd, int pid, dmx_pes_type_t type, dmx_output_t
output, int buffersize);
diff --git a/lib/libdvbv5/dvb-demux.c b/lib/libdvbv5/dvb-demux.c
index 138b58a..d07e6cf 100644
--- a/lib/libdvbv5/dvb-demux.c
+++ b/lib/libdvbv5/dvb-demux.c
@@ -40,11 +40,11 @@
#include dvb-demux.h
-int dvb_dmx_open(int adapter, int demux, unsigned verbose)
+int dvb_dmx_open(int adapter, int demux)
{
char* demux_name = NULL;
asprintf(demux_name, /dev/dvb/adapter%i/demux%i, adapter, demux );
- int fd_demux = open( demux_name, O_RDWR );
+ int fd_demux = open( demux_name, O_RDWR | O_NONBLOCK );
free( demux_name );
return fd_demux;
}
--
1.7.2.5
--
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: [v7] media: coda: Add driver for Coda video codec.
Hi Richard, thank you for your review. This patch has been reviewed and acked by several people: Reviewed-by: Philipp Zabelp.za...@pengutronix.de Reviewed-by: Sylwester Nawrocki s.nawro...@samsung.com Acked-by: Hans Verkuil hans.verk...@cisco.com For this reason a pull request has already been sent to Mauro recently: http://patchwork.linuxtv.org/patch/13483/ In this case I personally don't think it will be easier to read if this line is split up. My point here is checkpatch. total: 2 errors, 30 warnings, 2086 lines checked Thank you for noticing this. I have solved it in my tree so that Mauro can pull for 3.7. You can find it here: https://github.com/jmartinc/video_visstrim.git for_3.6 Regarding your i.MX6 question, maybe Philippe will be able to help you since I am only interested on i.MX27. However, the driver was developed considering much of his suggestions so that adding support for different chips later is as straightforward as possible. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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] [BUG] Re: dvb_usb_lmedm04 crash Kernel (rs2000)
On 08/03/2012 01:31 AM, Malcolm Priestley wrote: On Thu, 2012-08-02 at 23:54 +0300, Antti Palosaari wrote: Moi Malcolm, Any idea why this seems to crash Kernel just when device is plugged? Hi Antti Yes, there missing error handling when no firmware file found. It seems that this is more of a problem with udev-182+. However, so far udev-182 is only a problem on first ever plug. Regards Malcolm Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- drivers/media/dvb/dvb-usb/lmedm04.c |4 1 file changed, 4 insertions(+) diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c b/drivers/media/dvb/dvb-usb/lmedm04.c index 25d1031..26ba5bc 100644 --- a/drivers/media/dvb/dvb-usb/lmedm04.c +++ b/drivers/media/dvb/dvb-usb/lmedm04.c @@ -878,6 +878,10 @@ static int lme_firmware_switch(struct usb_device *udev, int cold) fw_lme = fw_c_rs2000; ret = request_firmware(fw, fw_lme, udev-dev); dvb_usb_lme2510_firmware = TUNER_RS2000; + if (ret == 0) + break; + info(FRM No Firmware Found - please install); + cold_fw = 0; break; default: fw_lme = fw_c_s7395; Do we need fw blob anymore!? http://www.spinics.net/lists/hotplug/msg05257.html … Firmware is loaded natively by udev now, the external 'firmware' binary is no longer used. … Cheers, poma -- 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 for 3.6] videobuf2: fix sparse warning
Fix symbol 'vb2_vmalloc_memops' was not declared. Should it be static?
sparse warning.
Signed-off-by: Nicolas Thery nicolas.th...@st.com
---
drivers/media/video/videobuf2-vmalloc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/media/video/videobuf2-vmalloc.c
b/drivers/media/video/videobuf2-vmalloc.c
index 6b5ca6c..94efa04 100644
--- a/drivers/media/video/videobuf2-vmalloc.c
+++ b/drivers/media/video/videobuf2-vmalloc.c
@@ -18,6 +18,7 @@
#include linux/vmalloc.h
#include media/videobuf2-core.h
+#include media/videobuf2-vmalloc.h
#include media/videobuf2-memops.h
struct vb2_vmalloc_buf {
--
1.7.11.3
--
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
Vacations.
Hi, I will be out of the office until August the 19th. I just wanted to send a reminder of some patches that I have pending. For Mauro 3.7: [PULL] video_visstrim for 3.6 [PATCH] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks. For Guennadi: [PATCH 1/4] i.MX27: Fix emma-prp and csi clocks. [PATCH 2/4] media: mx2_camera: Mark i.MX25 support as BROKEN. [PATCH 3/4] Schedule removal of i.MX25 support in mx2_camera.c [PATCH v2] media: mx2_camera: Fix clock handling for i.MX27. For Sascha: [PATCH v2] Visstrim SM10: Use mo_version to decide board video mode. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.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 2/2 v2] i.MX27: Visstrim_M10: Add support for deinterlacing driver.
On Thu, Jul 12, 2012 at 01:35:29PM +0200, Javier Martin wrote:
Visstrim_M10 have a tvp5150 whose video output must be deinterlaced.
The new mem2mem deinterlacing driver is very useful for that purpose.
Signed-off-by: Javier Martin javier.mar...@vista-silicon.com
---
Changes since v1:
- Removed commented out code.
---
arch/arm/mach-imx/mach-imx27_visstrim_m10.c | 27
++-
1 file changed, 26 insertions(+), 1 deletion(-)
diff --git a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
index 214e4ff..dbef59d 100644
--- a/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
+++ b/arch/arm/mach-imx/mach-imx27_visstrim_m10.c
@@ -232,7 +232,7 @@ static void __init visstrim_camera_init(void)
static void __init visstrim_reserve(void)
{
/* reserve 4 MiB for mx2-camera */
- mx2_camera_base = arm_memblock_steal(2 * MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base = arm_memblock_steal(3 * MX2_CAMERA_BUF_SIZE,
MX2_CAMERA_BUF_SIZE);
}
@@ -419,6 +419,30 @@ static void __init visstrim_coda_init(void)
return;
}
+/* DMA deinterlace */
+static struct platform_device visstrim_deinterlace = {
+ .name = m2m-deinterlace,
+ .id = 0,
+};
+
+static void __init visstrim_deinterlace_init(void)
+{
+ int ret = -ENOMEM;
+ struct platform_device *pdev = visstrim_deinterlace;
+ int dma;
+
+ ret = platform_device_register(pdev);
ret is unused.
Better use platform_device_register_simple().
+
+ dma = dma_declare_coherent_memory(pdev-dev,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ mx2_camera_base + 2 *
MX2_CAMERA_BUF_SIZE,
+ MX2_CAMERA_BUF_SIZE,
+ DMA_MEMORY_MAP |
DMA_MEMORY_EXCLUSIVE);
Shouldn't this be done before registering the device?
+ if (!(dma DMA_MEMORY_MAP))
+ return;
+}
if (!flag) return; else return ?
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917- |
--
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
[GIT PULL FOR v3.6] One DocBook fix and a few si470x v4l2-compliance fixes
Two trivial fixes for 3.6. Regards, Hans The following changes since commit 24ed693da0cefede7382d498dd5e9a83f0a21c38: [media] DVB: dib0700, remove double \n's from log (2012-07-31 00:36:03 -0300) are available in the git repository at: git://linuxtv.org/hverkuil/media_tree.git sifixes for you to fetch changes up to f4b0bd3f7230c3be81a410a25487baddda6417b6: si470x: v4l2-compliance fixes. (2012-08-03 16:16:59 +0200) Hans Verkuil (2): DocBook: Remove a spurious character. si470x: v4l2-compliance fixes. Documentation/DocBook/media/v4l/vidioc-g-tuner.xml |2 +- drivers/media/radio/si470x/radio-si470x-common.c |3 +++ drivers/media/radio/si470x/radio-si470x-i2c.c |5 +++-- drivers/media/radio/si470x/radio-si470x-usb.c |2 +- 4 files changed, 8 insertions(+), 4 deletions(-) -- 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: [PATH v3 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP
Hi Sylwester
Thank you for the review.
On 2 August 2012 21:11, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote:
Hi Sangwook,
On 08/02/2012 03:42 PM, Sangwook Lee wrote:
The following 2 patches add driver for S5K4ECGX sensor with embedded ISP
SoC,
and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor
from Samsung
Changes since v2:
- added GPIO (reset/stby) and regulators
- updated I2C read/write, based on s5k6aa datasheet
- fixed set_fmt errors
- reduced register tables a bit
- removed vmalloc
It looks like a great improvement, well done! Thanks!
In the S5K4CAGX sensor datasheet, that can be found on the internet,
there is 0x...0x002E registers description, which look very much
same as in S5K6AAFX case and likely is also valid for S5K4CAGX.
[snip]
What do you think about converting s5k4ecgx_img_regs arrays (it has
over 2700 entries) to a firmware file and adding some simple parser
to the driver ? Then we would have the problem solved in most part.
Thanks, fair enough. let me try this.
Regarding various preview resolution set up, the difference in all
those s5k4ecgx_*_preview[] arrays is rather small, only register
values differ, e.g. for 640x480 and 720x480 there is only 8 different
entries:
Ok, let me reduce table size again.
$ diff -a s5k4ec_640.txt s5k4ec_720.txt
1c1
static const struct regval_list s5k4ecgx_640_preview[] = {
---
static const struct regval_list s5k4ecgx_720_preview[] = {
3c3
{ 0x7252, 0x0780 },
---
{ 0x7252, 0x06a8 },
5c5
[snip]
{ 0x7256, 0x000c },
{ 0x72a6, 0x02d
[snip]
Could you please try to implement a function that replaces those tables,
based s5k6aa_set_prev_config() and s5k6aa_set_output_framefmt() ?
I was thinking about this, but this seems to be is a bit time-consuming because
I have to do this just due to lack of s5k4ecgx hardware information.
let me try it later once
this patch is accepted.
Thanks
Sangwook
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: [PATH v3 1/2] v4l: Add factory register values form S5K4ECGX sensor
Hi Sylwester
On 2 August 2012 21:50, Sylwester Nawrocki sylvester.nawro...@gmail.com wrote:
On 08/02/2012 03:42 PM, Sangwook Lee wrote:
Add factory default settings for S5K4ECGX sensor registers,
which was copied from the reference code of Samsung S.LSI.
Signed-off-by: Sangwook Leesangwook@linaro.org
---
drivers/media/video/s5k4ecgx_regs.h | 3105
+++
1 file changed, 3105 insertions(+)
create mode 100644 drivers/media/video/s5k4ecgx_regs.h
diff --git a/drivers/media/video/s5k4ecgx_regs.h
b/drivers/media/video/s5k4ecgx_regs.h
new file mode 100644
index 000..ef87c09
--- /dev/null
+++ b/drivers/media/video/s5k4ecgx_regs.h
@@ -0,0 +1,3105 @@
+/*
+ * Samsung S5K4ECGX register tables for default values
+ *
+ * Copyright (C) 2012 Linaro
+ * Copyright (C) 2012 Insignal Co,. Ltd
+ *
+ * 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 __DRIVERS_MEDIA_VIDEO_S5K4ECGX_H__
+#define __DRIVERS_MEDIA_VIDEO_S5K4ECGX_H__
+
+struct regval_list {
+ u32 addr;
+ u16 val;
+};
+
+/*
+ * FIXME:
+ * The tables are default values of a S5K4ECGX sensor EVT1.1
+ * from Samsung LSI. currently there is no information available
+ * to the public in order to reduce these tables size.
+ */
+static const struct regval_list s5k4ecgx_apb_regs[] = {
sniiip
+/* configure 30 fps */
+static const struct regval_list s5k4ecgx_fps_30[] = {
It really depends on sensor master clock frequency (as specified
in FIMC driver platform data) and PLL setting what the resulting
frame rate will be.
+ { 0x72b4, 0x0052 },
Looks surprising! Are we really just disabling horizontal/vertical
image mirror here ?
I believe, this setting values are used still in Galaxy Nexus.
It might be some reasons to set this values in the product, but I am not
sure of this.
+ { 0x72d2, 0x },
REG_0TC_PCFG_uCaptureMirror
+ { 0x7266, 0x },
REG_TC_GP_ActivePrevConfig
+ { 0x726a, 0x0001 },
REG_TC_GP_PrevOpenAfterChange
+ { 0x724e, 0x0001 },
REG_TC_GP_NewConfigSync
+ { 0x7268, 0x0001 },
REG_TC_GP_PrevConfigChanged
Please have a look how it is handled in s5k6aa driver, it all looks
pretty similar.
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_effect_normal[] = {
+ { 0x723c, 0x },
Just one register, why do we need an array for it ? And of course
0x is default value after reset, so it seems sort of pointless
doing this I2C write to set the default image effect value (disabled).
These are possible values as found in the datasheet:
0x723C REG_TC_GP_SpecialEffects 0x 2 RW Special effect
0 : Normal
1 : MONOCHROME (BW)
2 : Negative Mono
3 : Negative Color
4 : Sepia
5 : AQUA
6 : Reddish
7 : Bluish
8 : Greenish
9 : Sketch
10 : Emboss color
11 : Emboss Mono
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_wb_auto[] = {
+ { 0x74e6, 0x077f },
Ditto - register REG_TC_DBG_AutoAlgEnBits. And 0x077f is the default
value after reset...
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_iso_auto[] = {
+ { 0x7938, 0x },
+ { 0x7f2a, 0x0001 },
+ { 0x74e6, 0x077f },
+ { 0x74d0, 0x },
+ { 0x74d2, 0x },
+ { 0x74d4, 0x0001 },
+ { 0x76c2, 0x0200 },
+ { 0x, 0x },
+};
+
+static const struct regval_list s5k4ecgx_contrast_default[] = {
+ { 0x7232, 0x },
No need for an array, it's REG_TC_UserContrast.
+ { 0x, 0x },
+};
+
[snip]
+ { 0x, 0x },
+};
You already use a sequence of i2c writes in s5k4ecgx_s_ctrl() function
for V4L2_CID_SHARPNESS control. So why not just create e.g.
s5k4ecgx_set_saturation() and send this array to /dev/null ?
Also, invoking v4l2_ctrl_handler_setup() will cause a call to
s5k4ecgx_s_ctrl()
with default sharpness value (as specified during the control's creation).
So I would say this array is redundant in two ways... :)
Thanks, let me change this.
--
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: Vacations.
Hi Javier On Fri, 3 Aug 2012, javier Martin wrote: Hi, I will be out of the office until August the 19th. I just wanted to send a reminder of some patches that I have pending. For Mauro 3.7: [PULL] video_visstrim for 3.6 [PATCH] media: i.MX27: Fix mx2_emmaprp mem2mem driver clocks. For Guennadi: [PATCH 1/4] i.MX27: Fix emma-prp and csi clocks. As I mentioned several times, the above patch is not for me. Have a nice vacation. Thanks Guennadi [PATCH 2/4] media: mx2_camera: Mark i.MX25 support as BROKEN. [PATCH 3/4] Schedule removal of i.MX25 support in mx2_camera.c [PATCH v2] media: mx2_camera: Fix clock handling for i.MX27. For Sascha: [PATCH v2] Visstrim SM10: Use mo_version to decide board video mode. Regards. -- Javier Martin Vista Silicon S.L. CDTUC - FASE C - Oficina S-345 Avda de los Castros s/n 39005- Santander. Cantabria. Spain +34 942 25 32 60 www.vista-silicon.com --- 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: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget
Hi Laurent, -Original Message- From: Laurent Pinchart [mailto:laurent.pinch...@ideasonboard.com] Sent: Friday, August 03, 2012 1:45 PM To: Bhupesh SHARMA Cc: linux-...@vger.kernel.org; linux-media@vger.kernel.org Subject: Re: Query regarding the support and testing of MJPEG frame type in the UVC webcam gadget Hi Bhupesh, On Wednesday 01 August 2012 21:29:30 Bhupesh SHARMA wrote: On Wednesday, August 01, 2012 6:46 PM Laurent Pinchart wrote: On Wednesday 01 August 2012 14:26:33 Bhupesh SHARMA wrote: Hi Laurent, I have a query for you regarding the support and testing of MJPEG frame type in the UVC webcam gadget. I see that in the webcam.c gadget, the 720p and VGA MJPEG uvc formats are supported. I was trying the same out and got confused because the data arriving from a real video capture video supporting JPEG will have no fixed size. We will have the JPEG defined Start-of-Frame and End-of- Frame markers defining the boundary of the JPEG frame. But for almost all JPEG video capture devices even if we have kept a frame size of VGA initially, the final frame size will be a compressed version (with the compression depending on the nature of the scene, so a flat scene will have high compression and hence less frame size) of VGA and will not be equal to 640 * 480. So I couldn't exactly get why the dwMaxVideoFrameBufferSize is kept as 614400 in webcam.c (see [1]). The dwMaxVideoFrameBufferSize value must be larger than or equal to the largest MJPEG frame size. As I have no idea what that value is, I've kept the same size as for uncompressed frames, which should be big enough (and most probably too big). .. Yes, so that means that the user-space application should set the length of the buffer being queued at the UVC side equal to the length of the buffer dequeued from the V4L2 side, to ensure that varying length JPEG frames are correctly handled. You should copy the bytesused field from the captured v4l2_buffer to the output v4l2_buffer. The length field stores the total buffer size, not the number of bytes used. Yes, you are right. It should be bytesused field instead of the length field. Regards, Bhupesh -- 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] cpia2: Declare MODULE_FIRMWARE usage
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hans.verk...@cisco.com
Cc: linux-media@vger.kernel.org
Signed-off-by: Tim Gardner tim.gard...@canonical.com
---
drivers/media/video/cpia2/cpia2_core.c |6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/media/video/cpia2/cpia2_core.c
b/drivers/media/video/cpia2/cpia2_core.c
index 17188e2..187012c 100644
--- a/drivers/media/video/cpia2/cpia2_core.c
+++ b/drivers/media/video/cpia2/cpia2_core.c
@@ -31,11 +31,15 @@
#include cpia2.h
+#include linux/module.h
#include linux/slab.h
#include linux/mm.h
#include linux/vmalloc.h
#include linux/firmware.h
+#define FIRMWARE cpia2/stv0672_vp4.bin
+MODULE_FIRMWARE(FIRMWARE);
+
/* #define _CPIA2_DEBUG_ */
#ifdef _CPIA2_DEBUG_
@@ -898,7 +902,7 @@ static int cpia2_send_onebyte_command(struct camera_data
*cam,
static int apply_vp_patch(struct camera_data *cam)
{
const struct firmware *fw;
- const char fw_name[] = cpia2/stv0672_vp4.bin;
+ const char fw_name[] = FIRMWARE;
int i, ret;
struct cpia2_command cmd;
--
1.7.9.5
--
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: linux-next: Tree for Aug 3 (media/radio/radio-shark)
On 08/02/2012 08:51 PM, Stephen Rothwell wrote: Hi all, OK, so the merge window is closed. Time to clean up your trees and then start adding new stuff to them. Changes since 20120802: on i386: ERROR: snd_tea575x_init [drivers/media/radio/radio-shark.ko] undefined! ERROR: snd_tea575x_exit [drivers/media/radio/radio-shark.ko] undefined! Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/i386 3.6.0-rc1 Kernel Configuration # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y CONFIG_INSTRUCTION_DECODER=y CONFIG_OUTPUT_FORMAT=elf32-i386 CONFIG_ARCH_DEFCONFIG=arch/x86/configs/i386_defconfig CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_MMU=y # CONFIG_NEED_DMA_MAP_STATE is not set CONFIG_NEED_SG_DMA_LENGTH=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_GPIO=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_HAS_CPU_RELAX=y CONFIG_ARCH_HAS_DEFAULT_IDLE=y CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y CONFIG_ARCH_HAS_CPU_AUTOPROBE=y CONFIG_HAVE_SETUP_PER_CPU_AREA=y CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y # CONFIG_ZONE_DMA32 is not set # CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y CONFIG_ARCH_HWEIGHT_CFLAGS=-fcall-saved-ecx -fcall-saved-edx CONFIG_ARCH_SUPPORTS_UPROBES=y CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config CONFIG_HAVE_IRQ_WORK=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_CROSS_COMPILE= CONFIG_LOCALVERSION= # CONFIG_LOCALVERSION_AUTO is not set CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y # CONFIG_KERNEL_GZIP is not set # CONFIG_KERNEL_BZIP2 is not set CONFIG_KERNEL_LZMA=y # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set CONFIG_DEFAULT_HOSTNAME=(none) CONFIG_SWAP=y # CONFIG_SYSVIPC is not set CONFIG_BSD_PROCESS_ACCT=y CONFIG_BSD_PROCESS_ACCT_V3=y CONFIG_FHANDLE=y CONFIG_HAVE_GENERIC_HARDIRQS=y # # IRQ subsystem # CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_IRQ_DOMAIN=y # CONFIG_IRQ_DOMAIN_DEBUG is not set CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_KTIME_SCALAR=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # # RCU Subsystem # CONFIG_TINY_RCU=y # CONFIG_PREEMPT_RCU is not set # CONFIG_TREE_RCU_TRACE is not set CONFIG_IKCONFIG=m CONFIG_IKCONFIG_PROC=y CONFIG_LOG_BUF_SHIFT=17 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_FREEZER=y CONFIG_CGROUP_DEVICE=y # CONFIG_CPUSETS is not set CONFIG_CGROUP_CPUACCT=y CONFIG_RESOURCE_COUNTERS=y # CONFIG_MEMCG is not set CONFIG_CGROUP_PERF=y # CONFIG_CGROUP_SCHED is not set CONFIG_BLK_CGROUP=y CONFIG_DEBUG_BLK_CGROUP=y # CONFIG_CHECKPOINT_RESTORE is not set CONFIG_NAMESPACES=y CONFIG_UTS_NS=y # CONFIG_PID_NS is not set # CONFIG_SCHED_AUTOGROUP is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_SYSFS_DEPRECATED_V2 is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE= CONFIG_RD_GZIP=y CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set CONFIG_RD_XZ=y CONFIG_RD_LZO=y CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_ANON_INODES=y CONFIG_EXPERT=y CONFIG_UID16=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y # CONFIG_HOTPLUG is not set CONFIG_PRINTK=y # CONFIG_BUG is not set CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_HAVE_PCSPKR_PLATFORM=y # CONFIG_BASE_FULL is not set # CONFIG_FUTEX is not set CONFIG_EPOLL=y CONFIG_SIGNALFD=y # CONFIG_TIMERFD is not set CONFIG_EVENTFD=y # CONFIG_SHMEM is not set # CONFIG_AIO is not set CONFIG_EMBEDDED=y CONFIG_HAVE_PERF_EVENTS=y CONFIG_PERF_USE_VMALLOC=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y CONFIG_DEBUG_PERF_USE_VMALLOC=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_COMPAT_BRK is not set # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set # CONFIG_PROFILING is not set CONFIG_HAVE_OPROFILE=y CONFIG_OPROFILE_NMI_TIMER=y # CONFIG_KPROBES is not set # CONFIG_JUMP_LABEL is not set CONFIG_HAVE_EFFICIENT_UNALIGNED_ACCESS=y CONFIG_HAVE_IOREMAP_PROT=y CONFIG_HAVE_KPROBES=y CONFIG_HAVE_KRETPROBES=y CONFIG_HAVE_OPTPROBES=y CONFIG_HAVE_ARCH_TRACEHOOK=y CONFIG_HAVE_DMA_ATTRS=y CONFIG_HAVE_DMA_CONTIGUOUS=y CONFIG_GENERIC_SMP_IDLE_THREAD=y CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y CONFIG_HAVE_DMA_API_DEBUG=y CONFIG_HAVE_HW_BREAKPOINT=y
[PATCH] em28xx: Fix height setting on non-progressive captures
This was introduced on commit c2a6b54a9: em28xx: fix: don't do image interlacing on webcams It is a known bug that has already been reported several times and confirmed by Mauro. Tested by compilation only. Signed-off-by: Ezequiel Garcia elezegar...@gmail.com --- Hi, I have no idea why this hasn't been fixed before. See this mail for Mauro's confirmation http://www.digipedia.pl/usenet/thread/18550/7691/#post7685 where he requested a patch on reporter. I guess the patch never came in. Regards, Ezequiel. --- drivers/media/video/em28xx/em28xx-core.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/em28xx/em28xx-core.c b/drivers/media/video/em28xx/em28xx-core.c index de2cb20..6daa861 100644 --- a/drivers/media/video/em28xx/em28xx-core.c +++ b/drivers/media/video/em28xx/em28xx-core.c @@ -786,7 +786,7 @@ int em28xx_resolution_set(struct em28xx *dev) dev-vbi_height = 18; if (!dev-progressive) - height = norm_maxh(dev); + height = height / 2; em28xx_set_outfmt(dev); -- 1.7.4.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] em28xx: Fix height setting on non-progressive captures
On Fri, Aug 3, 2012 at 2:52 PM, Ezequiel Garcia elezegar...@gmail.com wrote: This was introduced on commit c2a6b54a9: em28xx: fix: don't do image interlacing on webcams It is a known bug that has already been reported several times and confirmed by Mauro. Tested by compilation only. I wonder if it's possible to get an Ack or a Tested-By from any of the em28xx owners? Also, Devin: you mentioned in an old mail [1] you had some patches for em28xx, but you had no time to put them into shape for submission. If you want to, send then to me (or the full em28xx tree) and I can try to submit the patches. Thanks, Ezequiel. [1] http://www.mail-archive.com/linux-media@vger.kernel.org/msg48232.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] em28xx: Fix height setting on non-progressive captures
On Fri, Aug 3, 2012 at 2:11 PM, Ezequiel Garcia elezegar...@gmail.com wrote: On Fri, Aug 3, 2012 at 2:52 PM, Ezequiel Garcia elezegar...@gmail.com wrote: This was introduced on commit c2a6b54a9: em28xx: fix: don't do image interlacing on webcams It is a known bug that has already been reported several times and confirmed by Mauro. Tested by compilation only. I wonder if it's possible to get an Ack or a Tested-By from any of the em28xx owners? This shouldn't be accepted upstream without testing at least on x86. I did make such a change to make it work in my ARM tree, but I don't fully understand the nature of the change and I'm not completely confident it's correct for x86 (based on my reading of the datasheet and how the accumulator field is structured in the em28xx chip). Also, I actually don't have any progressive devices (I've got probably a dozen em28xx devices, but they are all interlaced capture), which made me particularly hesitant to submit this patch. Also, Devin: you mentioned in an old mail [1] you had some patches for em28xx, but you had no time to put them into shape for submission. If you want to, send then to me (or the full em28xx tree) and I can try to submit the patches. Yeah, probably not a bad idea. I've been sitting on the tree because they haven't been tested on any other platforms and some of them are not necessarily generally suitable for the mainline kernel. And of course the tree needs to be parsed out into an actual patch series, and each patch has to be individually validated across multiple devices to ensure they don't cause breakage (they were tested on an em2863, but I have no idea if they cause problems on other chips such as the em2820 or em2880). All that said, I'm not really sure what the benefit would be in sending you the tree if you don't actually have any hardware to test with. The last thing we need is more crap being sent upstream that is compile tested only since that's where many of the regressions come from (well meaning people sending completely untested 'cleanup patches' can cause more harm than good). Devin -- 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] em28xx: Fix height setting on non-progressive captures
Hi Devin,
Thanks for answering.
On Fri, Aug 3, 2012 at 3:26 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Fri, Aug 3, 2012 at 2:11 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
On Fri, Aug 3, 2012 at 2:52 PM, Ezequiel Garcia elezegar...@gmail.com
wrote:
This was introduced on commit c2a6b54a9:
em28xx: fix: don't do image interlacing on webcams
It is a known bug that has already been reported several times
and confirmed by Mauro.
Tested by compilation only.
I wonder if it's possible to get an Ack or a Tested-By from any of the
em28xx owners?
This shouldn't be accepted upstream without testing at least on x86.
I did make such a change to make it work in my ARM tree, but I don't
fully understand the nature of the change and I'm not completely
confident it's correct for x86 (based on my reading of the datasheet
and how the accumulator field is structured in the em28xx chip).
Also, I actually don't have any progressive devices (I've got probably
a dozen em28xx devices, but they are all interlaced capture), which
made me particularly hesitant to submit this patch.
Wait a minute, unless I completely misunderstood the bug (which is possible),
I think this patch is straightforward.
By the look of this hunk on commit c2a6b54a:
-8--
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 5b78e19..339fffd 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -720,7 +720,10 @@ int em28xx_resolution_set(struct em28xx *dev)
{
int width, height;
width = norm_maxw(dev);
- height = norm_maxh(dev) 1;
+ height = norm_maxh(dev);
+
+ if (!dev-progressive)
+ height = norm_maxh(dev);
-8--
It seems to me that for non-progressive the height should just be
height = height / 2 (or height = height 1)
as was before, and as my patch is doing. It seems to driver will
merge the interlaced
frames and so the expected height is half the real height.
I hope I got it right.
That said and no matter how straightforward may be, which I'm not sure,
I also want the patch to get tested before being accepted.
Also, Devin: you mentioned in an old mail [1] you had some patches for
em28xx,
but you had no time to put them into shape for submission.
If you want to, send then to me (or the full em28xx tree) and I can
try to submit
the patches.
Yeah, probably not a bad idea. I've been sitting on the tree because
they haven't been tested on any other platforms and some of them are
not necessarily generally suitable for the mainline kernel. And of
course the tree needs to be parsed out into an actual patch series,
and each patch has to be individually validated across multiple
devices to ensure they don't cause breakage (they were tested on an
em2863, but I have no idea if they cause problems on other chips such
as the em2820 or em2880).
All that said, I'm not really sure what the benefit would be in
sending you the tree if you don't actually have any hardware to test
with. The last thing we need is more crap being sent upstream that is
compile tested only since that's where many of the regressions come
from (well meaning people sending completely untested 'cleanup
patches' can cause more harm than good).
Mmm, you're right. I was rather thinking in patches that fixes obvious
(whatever that may be) things and assuming these patches could get some
community testing.
So: never mind, bad idea. I've sent enough zero-test patches, which
only means more work for Mauro :-(
Thanks,
Ezequiel.
--
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] em28xx: Fix height setting on non-progressive captures
On Fri, Aug 3, 2012 at 2:42 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Wait a minute, unless I completely misunderstood the bug (which is possible),
I think this patch is straightforward.
By the look of this hunk on commit c2a6b54a:
-8--
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 5b78e19..339fffd 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -720,7 +720,10 @@ int em28xx_resolution_set(struct em28xx *dev)
{
int width, height;
width = norm_maxw(dev);
- height = norm_maxh(dev) 1;
+ height = norm_maxh(dev);
+
+ if (!dev-progressive)
+ height = norm_maxh(dev);
-8--
It seems to me that for non-progressive the height should just be
height = height / 2 (or height = height 1)
as was before, and as my patch is doing. It seems to driver will
merge the interlaced
frames and so the expected height is half the real height.
I hope I got it right.
That said and no matter how straightforward may be, which I'm not sure,
I also want the patch to get tested before being accepted.
So my concern here is that I don't actually know what that code does
on x86 (what does height end up being equal to?). On ARM it results
in height being zero, but on x86 I don't know what it will do (and the
fact that it works on x86 despite the change makes me worry about a
regression being introduced).
In other words, it might be working just out of dumb luck and making
the code behave like it does on ARM may cause problems for devices
other than the one I tested with.
I guess I'm worried that the broken code might be a no-op on x86 and
the height ends up still being 480 (or 576 for PAL), in which case
cutting the size of the accumulator window in half may introduce
problems not being seen before.
Devin
--
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] em28xx: Fix height setting on non-progressive captures
On Fri, Aug 3, 2012 at 3:55 PM, Devin Heitmueller
dheitmuel...@kernellabs.com wrote:
On Fri, Aug 3, 2012 at 2:42 PM, Ezequiel Garcia elezegar...@gmail.com wrote:
Wait a minute, unless I completely misunderstood the bug (which is possible),
I think this patch is straightforward.
By the look of this hunk on commit c2a6b54a:
-8--
diff --git a/drivers/media/video/em28xx/em28xx-core.c
b/drivers/media/video/em28xx/em28xx-core.c
index 5b78e19..339fffd 100644
--- a/drivers/media/video/em28xx/em28xx-core.c
+++ b/drivers/media/video/em28xx/em28xx-core.c
@@ -720,7 +720,10 @@ int em28xx_resolution_set(struct em28xx *dev)
{
int width, height;
width = norm_maxw(dev);
- height = norm_maxh(dev) 1;
+ height = norm_maxh(dev);
+
+ if (!dev-progressive)
+ height = norm_maxh(dev);
-8--
It seems to me that for non-progressive the height should just be
height = height / 2 (or height = height 1)
as was before, and as my patch is doing. It seems to driver will
merge the interlaced
frames and so the expected height is half the real height.
I hope I got it right.
That said and no matter how straightforward may be, which I'm not sure,
I also want the patch to get tested before being accepted.
So my concern here is that I don't actually know what that code does
on x86 (what does height end up being equal to?). On ARM it results
in height being zero, but on x86 I don't know what it will do (and the
fact that it works on x86 despite the change makes me worry about a
regression being introduced).
In other words, it might be working just out of dumb luck and making
the code behave like it does on ARM may cause problems for devices
other than the one I tested with.
I guess I'm worried that the broken code might be a no-op on x86 and
the height ends up still being 480 (or 576 for PAL), in which case
cutting the size of the accumulator window in half may introduce
problems not being seen before.
I agree with you. It's very odd that is working as it is.
As a final word, I believe you confused this patch affecting
progressive capture,
when actually it only affects non-progressive (interlaced) capture devices,
so perhaps you could give it a try yourself.
That is: *if* I got you right, and *if* you're not too busy.
Thanks,
Ezequiel.
--
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: s5p-fimc capturing interlaced BT656
Hi Mike, On 08/02/2012 02:48 PM, Mike Dyer wrote: Hi All, I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 video decoder. I notice that the capture driver ignores the field interlace flags reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also seems each field ends up in it's own frame, using only half the height. s5p-fimc driver doesn't support the interlaced video capture, as we had no such use case yet. Patches adding it are welcome. What would need to be done to store both fields in a single frame, for example in a V4L2_FIELD_INTERLACE_TB/BT format? Firstly, it would good to figure out FIMC register settings that would allow storing both fields in a single frame. I _suspect_ it's as simple as setting CAM_INTERLACE bit in CIGCTRL register. Have you perhaps tried it already ? For a quick test a patch as below might be sufficient. diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c index 1fc4ce8..19afa1a 100644 --- a/drivers/media/video/s5p-fimc/fimc-reg.c +++ b/drivers/media/video/s5p-fimc/fimc-reg.c @@ -576,6 +576,8 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc, if (cam-flags V4L2_MBUS_FIELD_EVEN_LOW) cfg |= FIMC_REG_CIGCTRL_INVPOLFIELD; + cfg |= FIMC_REG_CIGCTRL_INTERLACE; + writel(cfg, fimc-regs + FIMC_REG_CIGCTRL); return 0; -- 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
cron job: media_tree daily build: ERRORS
This message is generated daily by a cron job that builds media_tree for the kernels and architectures in the list below. Results of the daily build of media_tree: date:Fri Aug 3 19:00:19 CEST 2012 git hash:24ed693da0cefede7382d498dd5e9a83f0a21c38 gcc version: i686-linux-gcc (GCC) 4.7.1 host hardware:x86_64 host os: 3.4.07-marune linux-git-arm-eabi-davinci: ERRORS linux-git-arm-eabi-exynos: ERRORS linux-git-arm-eabi-omap: ERRORS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-x86_64: WARNINGS linux-2.6.34-x86_64: WARNINGS linux-2.6.35.3-x86_64: WARNINGS linux-2.6.36-x86_64: WARNINGS linux-2.6.37-x86_64: WARNINGS linux-2.6.38.2-x86_64: WARNINGS linux-2.6.39.1-x86_64: WARNINGS linux-3.0-x86_64: WARNINGS linux-3.1-x86_64: WARNINGS linux-3.2.1-x86_64: WARNINGS linux-3.3-x86_64: WARNINGS linux-3.4-x86_64: WARNINGS linux-3.5-x86_64: ERRORS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-i686: WARNINGS linux-2.6.34-i686: WARNINGS linux-2.6.35.3-i686: WARNINGS linux-2.6.36-i686: WARNINGS linux-2.6.37-i686: WARNINGS linux-2.6.38.2-i686: WARNINGS linux-2.6.39.1-i686: WARNINGS linux-3.0-i686: WARNINGS linux-3.1-i686: WARNINGS linux-3.2.1-i686: WARNINGS linux-3.3-i686: WARNINGS linux-3.4-i686: WARNINGS linux-3.5-i686: ERRORS apps: WARNINGS spec-git: WARNINGS sparse: 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: s5p-fimc capturing interlaced BT656
Hi Sylwester, On Fri, 2012-08-03 at 21:17 +0200, Sylwester Nawrocki wrote: Hi Mike, On 08/02/2012 02:48 PM, Mike Dyer wrote: Hi All, I'm using the S5PV210 camera IF and capturing BT656 video from a TVP5150 video decoder. I notice that the capture driver ignores the field interlace flags reported by the 'sensor' and always uses 'V4L2_FIELD_NONE'. It also seems each field ends up in it's own frame, using only half the height. s5p-fimc driver doesn't support the interlaced video capture, as we had no such use case yet. Patches adding it are welcome. What would need to be done to store both fields in a single frame, for example in a V4L2_FIELD_INTERLACE_TB/BT format? Firstly, it would good to figure out FIMC register settings that would allow storing both fields in a single frame. I _suspect_ it's as simple as setting CAM_INTERLACE bit in CIGCTRL register. Have you perhaps tried it already ? For a quick test a patch as below might be sufficient. diff --git a/drivers/media/video/s5p-fimc/fimc-reg.c b/drivers/media/video/s5p-fimc/fimc-reg.c index 1fc4ce8..19afa1a 100644 --- a/drivers/media/video/s5p-fimc/fimc-reg.c +++ b/drivers/media/video/s5p-fimc/fimc-reg.c @@ -576,6 +576,8 @@ int fimc_hw_set_camera_polarity(struct fimc_dev *fimc, if (cam-flags V4L2_MBUS_FIELD_EVEN_LOW) cfg |= FIMC_REG_CIGCTRL_INVPOLFIELD; + cfg |= FIMC_REG_CIGCTRL_INTERLACE; + writel(cfg, fimc-regs + FIMC_REG_CIGCTRL); return 0; -- Thanks, Sylwester I have indeed tried setting that, but with no effect. However, checking through the datasheet for the FIMC I discovered a DMA output (CIOCTRL) register bit called 'Weave_Out'. The description is: Even and Odd fields can be weaved together and combined to form a complete progressive frame by hardware. This field is useful for interlace DMA output mode (Interlace_out or CAM_INTERLACE). Even field address (1st frame start address) is used weave address. Odd fields address (2nd frame start address) is ignored. This does produce full sized frames, but I still seem to only be getting one field per frame, with a blank line inserted between each real line. Setting both interlace and weave doesn't seem to help. So, something still missing... I wonder if the irq handler is getting called for each field, maybe we need to wait for two interrupts before dequeing the frame? Cheers, Mike -- 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: s5p-fimc capturing interlaced BT656
On 08/03/2012 10:01 PM, Mike Dyer wrote: I have indeed tried setting that, but with no effect. However, checking through the datasheet for the FIMC I discovered a DMA output (CIOCTRL) register bit called 'Weave_Out'. The description is: Even and Odd fields can be weaved together and combined to form a complete progressive frame by hardware. This field is useful for interlace DMA output mode (Interlace_out or CAM_INTERLACE). Even field address (1st frame start address) is used weave address. Odd fields address (2nd frame start address) is ignored. This does produce full sized frames, but I still seem to only be getting one field per frame, with a blank line inserted between each real line. Setting both interlace and weave doesn't seem to help. So, something still missing... I wonder if the irq handler is getting called for each field, maybe we need to wait for two interrupts before dequeing the frame? Hmm, might be worth to try. But I'm wondering if the output DMA handling doesn't need to be reworked for that. According to the datasheet (Figure 2-20 Frame Buffer Control), even fields are written to DMA buffer with even index (e.g. 0) and odd fields are written to DMA buffer with odd index (e.g. 1). So possibly, if we set same address at two DMA buffer start address registers (e.g. FIMC_REG_CIOYSA(0), FIMC_REG_CIOYSA(1)) then even and odd frame will be written to proper memory location ? This might not be very difficult to implement. -- 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: [PATH v3 0/2] Add v4l2 subdev driver for S5K4ECGX sensor with embedded SoC ISP
Hi Sangwook,
On 08/03/2012 04:24 PM, Sangwook Lee wrote:
Hi Sylwester
Thank you for the review.
On 2 August 2012 21:11, Sylwester Nawrockisylvester.nawro...@gmail.com
wrote:
On 08/02/2012 03:42 PM, Sangwook Lee wrote:
The following 2 patches add driver for S5K4ECGX sensor with embedded ISP
SoC,
and minor v4l2 control API enhancement. S5K4ECGX is 5M CMOS Image sensor
from Samsung
Changes since v2:
- added GPIO (reset/stby) and regulators
- updated I2C read/write, based on s5k6aa datasheet
- fixed set_fmt errors
- reduced register tables a bit
- removed vmalloc
It looks like a great improvement, well done! Thanks!
In the S5K4CAGX sensor datasheet, that can be found on the internet,
there is 0x...0x002E registers description, which look very much
same as in S5K6AAFX case and likely is also valid for S5K4CAGX.
[snip]
What do you think about converting s5k4ecgx_img_regs arrays (it has
over 2700 entries) to a firmware file and adding some simple parser
to the driver ? Then we would have the problem solved in most part.
Thanks, fair enough. let me try this.
All right, thanks.
Regarding various preview resolution set up, the difference in all
those s5k4ecgx_*_preview[] arrays is rather small, only register
values differ, e.g. for 640x480 and 720x480 there is only 8 different
entries:
Ok, let me reduce table size again.
I don't think it's worth the effort to work around those tables.
They may just be removed entirely. I'll see if I can find time to
prepare a function replacing them. All required information seems
to be available in the datasheet.
$ diff -a s5k4ec_640.txt s5k4ec_720.txt
1c1
static const struct regval_list s5k4ecgx_640_preview[] = {
---
static const struct regval_list s5k4ecgx_720_preview[] = {
3c3
{ 0x7252, 0x0780 },
---
{ 0x7252, 0x06a8 },
5c5
[snip]
{ 0x7256, 0x000c },
{ 0x72a6, 0x02d
[snip]
Could you please try to implement a function that replaces those tables,
based s5k6aa_set_prev_config() and s5k6aa_set_output_framefmt() ?
I was thinking about this, but this seems to be is a bit time-consuming
because
I have to do this just due to lack of s5k4ecgx hardware information.
let me try it later once
this patch is accepted.
Yes, I know it's not trivial and requires some work... Let me try
to cook up something myself, as I have already some experience with
S5K6AAFX. Those firmware arrays are evil, and no good driver shall
rely on them.. :-)
And we have plenty time now, until v3.7 merge window.
--
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: [PATH v3 1/2] v4l: Add factory register values form S5K4ECGX sensor
Hi Sangwook,
On 08/03/2012 05:05 PM, Sangwook Lee wrote:
+/* configure 30 fps */
+static const struct regval_list s5k4ecgx_fps_30[] = {
It really depends on sensor master clock frequency (as specified
in FIMC driver platform data) and PLL setting what the resulting
frame rate will be.
+ { 0x72b4, 0x0052 },
Looks surprising! Are we really just disabling horizontal/vertical
image mirror here ?
I believe, this setting values are used still in Galaxy Nexus.
It might be some reasons to set this values in the product, but I am not
sure of this.
My point was that some entries in this table allegedly are setting image
mirroring, even though the array name suggests it should be only setting
frame rate to 30 fps. This is just bad practice. If you would have added
HFLIP/VFLIP controls, the register values would have been trashed every
time frame rate is set. Someone would have eventually have had to get rid
of this s5k4ecgx_fps_30 array, in order to add new features.
[snip]
+ { 0x, 0x },
+};
You already use a sequence of i2c writes in s5k4ecgx_s_ctrl() function
for V4L2_CID_SHARPNESS control. So why not just create e.g.
s5k4ecgx_set_saturation() and send this array to /dev/null ?
Also, invoking v4l2_ctrl_handler_setup() will cause a call to
s5k4ecgx_s_ctrl()
with default sharpness value (as specified during the control's creation).
So I would say this array is redundant in two ways... :)
Thanks, let me change this.
Thanks, please at least remove those single entry arrays, with the
resolution arrays gone as well and the biggest array converted to
firmware blob I don't see a reason why this driver couldn't be accepted
upstream.
--
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: Asus PVR-416
On Wed, 2012-08-01 at 07:40 -0400, Jerry Haggard wrote: I swapped PCI slots (there's 2), blew it and no change. I put it back to the firmware from atrpms, and nothing has changed. Is the checksum mismatch from what's loaded onto the card or is it the checksum of what's on the disk? I've been obsessed with getting the right firmware since I assume the checksum was from what's on the disc. Is that wrong? And again, thanks for the help. The MPEG encoder firmware used for the blackbird designs (GPIO connected CX23416 or CX23417) should be the same one used with ivtv (PCI connected CX23415 or CX23416) - it's the same hardware. The firmware I happen to have on my machine: $ ls -al /lib/firmware/v4l-cx2341x-enc.fw -rwxr-xr-x. 1 root root 376836 Feb 17 2007 /lib/firmware/v4l-cx2341x-enc.fw $ sha256sum -b /lib/firmware/v4l-cx2341x-enc.fw 56530c3884feaf587500d42fce47099f9f3af222e3c18f1a9f3d7f0fa916630a */lib/firmware/v4l-cx2341x-enc.fw Which has a size that agrees with the cx88 driver here: http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx88/cx88-blackbird.c#l62 The checksum being done by the cx88 driver is here: http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx88/cx88-blackbird.c#l471 A 2's complement sum of the 1's complement of the data in the file, is compared to the sum of the data read back from the device. If you have a *single* PCI bus error in the memory_read() or memory_write() functions, you're done/dead: http://git.linuxtv.org/media_tree.git/blob/staging/for_v3.6:/drivers/media/video/cx88/cx88-blackbird.c#l250 A failed PCI read will return 0x according to the PCI specifications. I hope that helps you understand what might be going on, and where you might need to ivestiagte further. Regards, Andy On Wed, Aug 1, 2012 at 7:16 AM, Jerry Haggard xen2x...@gmail.com wrote: I've played with it a bit more. I cut the firmware out of the driver as suggested here: http://www.mythtv.org/wiki/AVerMedia_M150-D What I get is: cx88[0]/2-bb: Firmware and/or mailbox pointer not initialized or corrupted cx88-mpeg driver manager :01:01.2: firmware: requesting v4l-cx2341x-enc.fw cx88[0]/2-bb: ERROR: Firmware size mismatch (have 262144, expected 376836) What I always got before was: cx88[0]: subsystem: 1043:4823, board: ASUS PVR-416 [card=12,autodetected], frontend(s): 0 cx88[0]: TV tuner type 43, Radio tuner type -1 IR RC5(x) protocol handler initialized IR RC6 protocol handler initialized All bytes are equal. It is not a TEA5767 tuner 15-0060: Tuner -1 found with type(s) Radio TV. IR JVC protocol handler initialized IR Sony protocol handler initialized tda9887 15-0043: creating new instance tda9887 15-0043: tda988[5/6/7] found tuner 15-0043: Tuner 74 found with type(s) Radio TV. IR SANYO protocol handler initialized IR MCE Keyboard/mouse protocol handler initialized lirc_dev: IR Remote Control driver registered, major 248 IR LIRC bridge handler initialized tuner-simple 15-0060: creating new instance tuner-simple 15-0060: type set to 43 (Philips NTSC MK3 (FM1236MK3 or FM1236/F)) cx88[0]/0: found at :01:01.0, rev: 5, irq: 21, latency: 64, mmio: 0xdd00 IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs cx88[0]/0: registered device video0 [v4l2] cx88[0]/0: registered device vbi0 cx88[0]/0: registered device radio0 cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.9 loaded cx88[0]/2: cx2388x 8802 Driver Manager cx88-mpeg driver manager :01:01.2: PCI INT A - GSI 21 (level, low) - IRQ 21 cx88[0]/2: found at :01:01.2, rev: 5, irq: 21, latency: 64, mmio: 0xde00 IRQ 21/cx88[0]: IRQF_DISABLED is not guaranteed on shared IRQs cx2388x blackbird driver version 0.0.9 loaded cx88/2: registering cx8802 driver, type: blackbird access: shared cx88[0]/2: subsystem: 1043:4823, board: ASUS PVR-416 [card=12] cx88[0]/2: cx23416 based mpeg encoder (blackbird reference design) cx88[0]/2-bb: Firmware and/or mailbox pointer not initialized or corrupted cx88-mpeg driver manager :01:01.2: firmware: requesting v4l-cx2341x-enc.fw parport_pc 00:06: reported by Plug and Play ACPI parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE,EPP] ppdev: user-space parallel port driver cx88[0]/2-bb: ERROR: Firmware load failed (checksum mismatch). cx88[0]/2: registered device video1 [mpeg]
