Re: [PATCH v5 09/35] v4l: Add subdev selections documentation
Hi Sakari, Hopefully it's not too late to make a few minor suggestions. On 03/06/2012 05:32 PM, Sakari Ailus wrote: Add documentation for V4L2 subdev selection API. This changes also experimental V4L2 subdev API so that scaling now works through selection API only. Signed-off-by: Sakari Ailussakari.ai...@iki.fi [snip] + +paraOn sink pads, cropping is applied relatively to the s/relatively/relative/ + current pad format. The pad format represents the image size as + received by the sub-device from the previous block in the + pipeline, and the crop rectangle represents the sub-image that + will be transmitted further inside the sub-device for + processing./para [snip] +paraOn source pads, cropping is similar to sink pads, with the + exception that the source size from which the cropping is + performed, is the COMPOSE rectangle on the sink pad. In both + sink and source pads, the crop rectangle must be entirely + containted inside the source image size for the crop s/containted/contained/ + operation./para + +paraThe drivers should always use the closest possible + rectangle the user requests on all selection targets, unless + specificly told otherwise. s/specificly/specifically/ +constantV4L2_SUBDEV_SEL_FLAG_SIZE_GE/constant and +constantV4L2_SUBDEV_SEL_FLAG_SIZE_LE/constant flags may be + used to round the image size either up or down.xref + linkend=v4l2-subdev-selection-flags/xref/para +/section [snip] +constantV4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG/constant flag. This + flag causes that no propagation of the changes are allowed in + any circumstances. This may also cause the accessed rectangle to This flag causes that sounds ungrammatical. I suggest: This flag causes no propagation of the changes to be allowed under any circumstances. [snip] Michael MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner, Erhard Meier -- 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] omap_vout: Set DSS overlay_info only if paddr is non zero
The omap_vout driver tries to set the DSS overlay_info using set_overlay_info()
when the physical address for the overlay is still not configured. This happens
in omap_vout_probe() and vidioc_s_fmt_vid_out().
The calls to omapvid_init(which internally calls set_overlay_info()) are removed
from these functions. They don't need to be called as the omap_vout_device
struct anyway maintains the overlay related changes made. Also, remove the
explicit call to set_overlay_info() in vidioc_streamon(), this was used to set
the paddr, this isn't needed as omapvid_init() does the same thing later.
These changes are required as the DSS2 driver since 3.3 kernel doesn't let you
set the overlay info with paddr as 0.
Signed-off-by: Archit Taneja arc...@ti.com
---
drivers/media/video/omap/omap_vout.c | 36 -
1 files changed, 5 insertions(+), 31 deletions(-)
diff --git a/drivers/media/video/omap/omap_vout.c
b/drivers/media/video/omap/omap_vout.c
index 1fb7d5b..dffcf66 100644
--- a/drivers/media/video/omap/omap_vout.c
+++ b/drivers/media/video/omap/omap_vout.c
@@ -1157,13 +1157,6 @@ static int vidioc_s_fmt_vid_out(struct file *file, void
*fh,
/* set default crop and win */
omap_vout_new_format(vout-pix, vout-fbuf, vout-crop, vout-win);
- /* Save the changes in the overlay strcuture */
- ret = omapvid_init(vout, 0);
- if (ret) {
- v4l2_err(vout-vid_dev-v4l2_dev, failed to change mode\n);
- goto s_fmt_vid_out_exit;
- }
-
ret = 0;
s_fmt_vid_out_exit:
@@ -1664,20 +1657,6 @@ static int vidioc_streamon(struct file *file, void *fh,
enum v4l2_buf_type i)
omap_dispc_register_isr(omap_vout_isr, vout, mask);
- for (j = 0; j ovid-num_overlays; j++) {
- struct omap_overlay *ovl = ovid-overlays[j];
-
- if (ovl-manager ovl-manager-device) {
- struct omap_overlay_info info;
- ovl-get_overlay_info(ovl, info);
- info.paddr = addr;
- if (ovl-set_overlay_info(ovl, info)) {
- ret = -EINVAL;
- goto streamon_err1;
- }
- }
- }
-
/* First save the configuration in ovelray structure */
ret = omapvid_init(vout, addr);
if (ret)
@@ -2071,11 +2050,12 @@ static int __init omap_vout_create_video_devices(struct
platform_device *pdev)
}
video_set_drvdata(vfd, vout);
- /* Configure the overlay structure */
- ret = omapvid_init(vid_dev-vouts[k], 0);
- if (!ret)
- goto success;
+ dev_info(pdev-dev, : registered and initialized
+video device %d\n, vfd-minor);
+ if (k == (pdev-num_resources - 1))
+ return 0;
+ continue;
error2:
if (vout-vid_info.rotation_type == VOUT_ROT_VRFB)
omap_vout_release_vrfb(vout);
@@ -2085,12 +2065,6 @@ error1:
error:
kfree(vout);
return ret;
-
-success:
- dev_info(pdev-dev, : registered and initialized
-video device %d\n, vfd-minor);
- if (k == (pdev-num_resources - 1))
- return 0;
}
return -ENODEV;
--
1.7.5.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: A second easycap driver implementation
Hi, On 03/06/2012 10:04 PM, Ezequiel García wrote: Hello, After some research on v4l2 and videbuf2, and considering that easycap driver is pretty outdated I've decided to start writing a new driver from scratch. I am using the excellent vivi driver and some usb video capture drivers as a starting point. And of course, I'm using the current easycap implementation as a reference (it works pretty well). I have a couple of doubts regarding the development itself (how to trace properly, where to allocate urbs, and such) but perhaps the maintainers prefer to take a look at the code. However, currently the driver is just a skeleton: it does all v4l2 and videobuf2 intialization but it doesn't actually stream video or submit urbs. So, 1. Should I try to have something more finished before submit or can I submit as it is? 2. In any case, how should I submit it? (Considering there is already a working driver). Have you considered instead slowly moving the existing easycap driver over to all the new infrastructure we have now. For starters replace its buffer management with videobuf2, then in another patch replace some other bits, etc. ? See what I've done to the pwc driver :) OTOH if you already have a new more modern driver ready, then I say go ahead and submit it. I would suggest to add it to staging too, and make the 2 kconfig options conflict, so enabling one would allow the user to no longer select the other (with a note about this in the help text). And then hopefully soon we will see a follow up patch removing the old driver, and then moving the new one out of staging. Which ever path you choose: Thanks for working 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
RE: [PATCH] media: fimc-lite: Add new driver for camera interface
Hi Sylwester,
Thanks for your comment.
On 03/04/2012 07:17 AM, Sylwester Nawrocki wrote:
Hi Sungchun,
On 02/15/2012 07:05 AM, Sungchun Kang wrote:
This patch adds support fimc-lite device which is a new device for
camera interface on EXYNOS5 SoCs.
It's also available in the Exynos4 SoC and I was planning adding it at
the s5p-fimc driver eventually. It may take some time though since it
is not described in the datasheets I have.
You're right, Fimc-lite is used exynos4(4212 and 4412 except 4210) and exynos5.
But we decided to use mc in exynos5 only.
And exynos4 has fimc-lite and fimc, on the other hand, exynos5 fimc-lite and
g-scaler.
Also, fimc-lite can memory operation like as fimc and SFR is quite different.
This device supports the followings as key feature.
1) Multiple input
- ITU-R BT 601 mode
- MIPI(CSI) mode
2) Multiple output
- DMA mode
- Direct FIFO mode
Signed-off-by: Sungchun Kangsungchun.k...@samsung.com
NOTE : This patch is based on
media: media-dev: Add media devices for EXYNOS5.
---
drivers/media/video/Kconfig|3 +-
drivers/media/video/Makefile |2 +-
drivers/media/video/exynos/Kconfig | 20 +
drivers/media/video/exynos/Makefile|4 +
drivers/media/video/exynos/fimc-lite/Kconfig | 22 +
drivers/media/video/exynos/fimc-lite/Makefile |6 +
.../media/video/exynos/fimc-lite/fimc-lite-core.c | 1921
.../media/video/exynos/fimc-lite/fimc-lite-core.h | 310
.../media/video/exynos/fimc-lite/fimc-lite-reg.c | 332
.../media/video/exynos/fimc-lite/fimc-lite-reg.h | 135 ++
include/media/exynos_camera.h | 59 +
include/media/exynos_flite.h | 39 +
12 files changed, 2851 insertions(+), 2 deletions(-)
create mode 100644 drivers/media/video/exynos/Kconfig
create mode 100644 drivers/media/video/exynos/Makefile
create mode 100644 drivers/media/video/exynos/fimc-lite/Kconfig
create mode 100644 drivers/media/video/exynos/fimc-lite/Makefile
create mode 100644 drivers/media/video/exynos/fimc-lite/fimc-lite-
core.c
create mode 100644 drivers/media/video/exynos/fimc-lite/fimc-lite-
core.h
create mode 100644 drivers/media/video/exynos/fimc-lite/fimc-lite-
reg.c
create mode 100644 drivers/media/video/exynos/fimc-lite/fimc-lite-
reg.h
create mode 100644 include/media/exynos_camera.h
create mode 100644 include/media/exynos_flite.h
...
+if VIDEO_EXYNOS_FIMC_LITE VIDEOBUF2_CMA_PHYS comment Reserved
+memory configurations
+config VIDEO_SAMSUNG_MEMSIZE_FLITE0
+ int Memory size in kbytes for FLITE0
+ default 10240
+
+config VIDEO_SAMSUNG_MEMSIZE_FLITE1
+ int Memory size in kbytes for FLITE1
+ default 10240
+endif
There is no VIDEOBUF2_CMA_PHYS allocator in the mainline and there
should be no need for it. CMA should be used through the dma mapping
framework, see https://lkml.org/lkml/2012/2/22/309.
Ah...
My mistake.:-)
diff --git a/drivers/media/video/exynos/fimc-lite/Makefile
b/drivers/media/video/exynos/fimc-lite/Makefile
new file mode 100644
index 000..431d199
--- /dev/null
+++ b/drivers/media/video/exynos/fimc-lite/Makefile
@@ -0,0 +1,6 @@
+ifeq ($(CONFIG_ARCH_EXYNOS5),y)
+fimc-lite-objs := fimc-lite-core.o fimc-lite-reg.o else
+fimc-lite-objs := fimc-lite-core.o fimc-lite-reg.o endif
+obj-$(CONFIG_VIDEO_EXYNOS_FIMC_LITE) += fimc-lite.o
diff --git a/drivers/media/video/exynos/fimc-lite/fimc-lite-core.c
b/drivers/media/video/exynos/fimc-lite/fimc-lite-core.c
new file mode 100644
index 000..9bb1c88
--- /dev/null
+++ b/drivers/media/video/exynos/fimc-lite/fimc-lite-core.c
@@ -0,0 +1,1921 @@
+/*
+ * Register interface file for Samsung Camera Interface (FIMC-Lite)
+driver
+ *
+ * Copyright (c) 2011 Samsung Electronics
2011 - 2012 ?
OK. I will fix it.
+ *
+ * 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.
+*/
+
+#includelinux/module.h
+#includelinux/kernel.h
+#includelinux/errno.h
+#includelinux/interrupt.h
+#includelinux/device.h
+#includelinux/platform_device.h
+#includelinux/slab.h
+#includelinux/i2c.h
+#includemedia/exynos_mc.h
+#includemedia/videobuf2-dma-contig.h
+
+#include fimc-lite-core.h
+
+#define MODULE_NAMEexynos-fimc-lite
+#define DEFAULT_FLITE_SINK_WIDTH 800
+#define DEFAULT_FLITE_SINK_HEIGHT 480
+
+static struct flite_fmt flite_formats[] = {
+ {
+ .name = YUV422 8-bit 1 plane(UYVY),
+ .pixelformat= V4L2_PIX_FMT_UYVY,
+ .depth = { 16 },
+ .code = V4L2_MBUS_FMT_UYVY8_2X8,
+
RE: [PATCH 1/3] v4l: add contorl definitions for codec devices.
Hi Hans, hi Jeongtae,
From: Hans Verkuil [mailto:hverk...@xs4all.nl]
Sent: 02 March 2012 09:13
Hi Jeongtae!
Some review notes below...
On Friday, March 02, 2012 03:17:40 Jeongtae Park wrote:
Add control definitions for controls specific to codec devices.
Signed-off-by: Jeongtae Park jtp.p...@samsung.com
Cc: Marek Szyprowski m.szyprow...@samsung.com
Cc: Kamil Debski k.deb...@samsung.com
---
include/linux/videodev2.h | 51
++--
1 files changed, 48 insertions(+), 3 deletions(-)
diff --git a/include/linux/videodev2.h b/include/linux/videodev2.h
index b739d7d..a19512a 100644
--- a/include/linux/videodev2.h
+++ b/include/linux/videodev2.h
@@ -359,7 +359,9 @@ struct v4l2_pix_format {
/* two non contiguous planes - one Y, one Cr + Cb interleaved */
#define V4L2_PIX_FMT_NV12M v4l2_fourcc('N', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 */
+#define V4L2_PIX_FMT_NV21M v4l2_fourcc('N', 'M', '2', '1') /* 21
Y/CrCb 4:2:0 */
#define V4L2_PIX_FMT_NV12MT v4l2_fourcc('T', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 64x32 macroblocks */
+#define V4L2_PIX_FMT_NV12MT_16X16 v4l2_fourcc('V', 'M', '1', '2') /* 12
Y/CbCr 4:2:0 16x16 macroblocks */
/* three non contiguous planes - Y, Cb, Cr */
#define V4L2_PIX_FMT_YUV420M v4l2_fourcc('Y', 'M', '1', '2') /* 12
YUV420 planar */
@@ -392,6 +394,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_MPEG v4l2_fourcc('M', 'P', 'E', 'G') /* MPEG-
1/2/4 Multiplexed */
#define V4L2_PIX_FMT_H264 v4l2_fourcc('H', '2', '6', '4') /* H264
with start codes */
#define V4L2_PIX_FMT_H264_NO_SC v4l2_fourcc('A', 'V', 'C', '1') /* H264
without start codes */
+#define V4L2_PIX_FMT_H264_MVC v4l2_fourcc('M', '2', '6', '4') /* H264 MVC
*/
#define V4L2_PIX_FMT_H263 v4l2_fourcc('H', '2', '6', '3') /* H263
*/
#define V4L2_PIX_FMT_MPEG1v4l2_fourcc('M', 'P', 'G', '1') /* MPEG-1
ES */
#define V4L2_PIX_FMT_MPEG2v4l2_fourcc('M', 'P', 'G', '2') /* MPEG-2
ES */
@@ -399,6 +402,7 @@ struct v4l2_pix_format {
#define V4L2_PIX_FMT_XVID v4l2_fourcc('X', 'V', 'I', 'D') /* Xvid
*/
#define V4L2_PIX_FMT_VC1_ANNEX_G v4l2_fourcc('V', 'C', '1', 'G') /* SMPTE
421M Annex G compliant stream */
#define V4L2_PIX_FMT_VC1_ANNEX_L v4l2_fourcc('V', 'C', '1', 'L') /* SMPTE
421M Annex L compliant stream */
+#define V4L2_PIX_FMT_VP8 v4l2_fourcc('V', 'P', '8', '0') /* VP8 */
Note that these new formats need to be documented in the spec as well.
/* Vendor-specific formats */
#define V4L2_PIX_FMT_CPIA1v4l2_fourcc('C', 'P', 'I', 'A') /* cpia1
YUV */
@@ -1458,17 +1462,18 @@ enum v4l2_mpeg_video_header_mode {
};
#define V4L2_CID_MPEG_VIDEO_MAX_REF_PIC
(V4L2_CID_MPEG_BASE+217)
#define V4L2_CID_MPEG_VIDEO_MB_RC_ENABLE
(V4L2_CID_MPEG_BASE+218)
-#define V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BYTES
(V4L2_CID_MPEG_BASE+219)
+#define V4L2_CID_MPEG_VIDEO_MULTI_SLICE_MAX_BITS
(V4L2_CID_MPEG_BASE+219)
Why change from bytes to bits? That changes the meaning of this control.
We had a discussion about this on irc with Hans. Let me paste a snippet:
Jun 08 09:58:36 kdebski hverkuil: in the first email you have wrote
that you would like to add some more comments on the codec controls after you
get yourself familiar with the standard. any progress on that?
Jun 08 10:06:17 hverkuil kdebski: yes, I want to go through the docbook
patch again and check each item against the standard docs I have.
Jun 08 10:06:48 hverkuil I'll just make notes here as I go along and you
can comment on it.
Jun 08 10:08:02 hverkuil I want to finish my review today if possible.
Jun 08 10:10:12 hverkuil kdebski: VIDEO_MAX_REF_PIC: is this H264
specific or is it also valid for MPEG4?
Jun 08 10:18:36 hverkuil kdebski: VIDEO_MULTI_SLICE_MODE: MAX_BITS: is
this specific to your encoder, or is this part of the standard? And why is it
in bits instead of bytes?
Jun 08 10:22:01 kdebski I have had a look at the most recent
documentation for MFC and MAX_REF_PIC disappeared, previously I have
categorised it as H264 only
Jun 08 10:24:15 kdebski in ffmpeg documentation it seems as a control
that can be used in other codecs as well
Jun 08 10:25:37 kdebski VIDEO_MULTI_SLICE_MODE: MAX_BITS it can be set
in x264 with --slice-max-size (it is in bytes there)
Jun 08 10:26:10 hverkuil Ah, so that slice mode is for x264, not h264?
Jun 08 10:26:33 kdebski hverkuil: for MFC it is bits
Jun 08 10:26:56 kdebski x264 is an open source h264 encoder
Jun 08 10:28:20 hverkuil so with MAX_BITS you can get variable number of
MBs per slice, right?
Jun 08 10:28:56 kdebski yes
Jun 08 10:29:00 hverkuil I think I'd call it MAX_BYTES.
Although I wasn't too convinced whether it should be BITS or BYTES we have made
a choice. It is in the mainline kernel. It is part of the API - changing it now
Re: [PATCH v5 25/35] omap3isp: Collect entities that are part of the pipeline
Hi Sakari,
Thanks for the patch.
On Tuesday 06 March 2012 18:33:06 Sakari Ailus wrote:
Collect entities which are part of the pipeline into a single bit mask.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c |9 +
drivers/media/video/omap3isp/ispvideo.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d34f690..4bc9cca 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -970,6 +970,8 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) {
struct isp_video_fh *vfh = to_isp_video_fh(fh);
struct isp_video *video = video_drvdata(file);
+ struct media_entity_graph graph;
+ struct media_entity *entity;
enum isp_pipeline_state state;
struct isp_pipeline *pipe;
struct isp_video *far_end;
@@ -992,6 +994,8 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) pipe = video-video.entity.pipe
? to_isp_pipeline(video-video.entity) : video-pipe;
+ pipe-entities = 0;
+
This could be move right before the graph walk code below to keep both parts
together. However, pipe-entities would then be invalid (instead of always 0)
in the link validation operations. That can be considered as an issue, so I'm
fine if you prefer leaving this assignment here.
if (video-isp-pdata-set_constraints)
video-isp-pdata-set_constraints(video-isp, true);
pipe-l3_ick = clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
@@ -1001,6 +1005,11 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) if (ret 0)
goto err_pipeline_start;
+ entity = video-video.entity;
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph)))
+ pipe-entities |= 1 entity-id;
+
To avoid walking the graph one more time, what about moving this to
isp_video_far_end() where we already walk the graph (and moving the
isp_video_far_end() call earlier in this function) ? You could possible rename
isp_video_far_end() to something a bit more in line with its new purpose then.
/* Verify that the currently configured format matches the output of
* the connected subdev.
*/
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h index d91bdb91..0423c9d 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -96,6 +96,7 @@ struct isp_pipeline {
enum isp_pipeline_stream_state stream_state;
struct isp_video *input;
struct isp_video *output;
+ u32 entities;
unsigned long l3_ick;
unsigned int max_rate;
atomic_t frame_number;
--
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 v5 27/35] omap3isp: Introduce isp_video_check_external_subdevs()
Hi Sakari,
Thanks for the patch.
On Tuesday 06 March 2012 18:33:08 Sakari Ailus wrote:
isp_video_check_external_subdevs() will retrieve external subdev's
bits-per-pixel and pixel rate for the use of other ISP subdevs at streamon
time. isp_video_check_external_subdevs() is called after pipeline
validation.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index 4bc9cca..ef5c770 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -934,6 +934,77 @@ isp_video_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *b) file-f_flags O_NONBLOCK);
}
+static int isp_video_check_external_subdevs(struct isp_pipeline *pipe)
+{
+ struct isp_device *isp =
+ container_of(pipe, struct isp_video, pipe)-isp;
Any reason not to pass isp_device * from the caller to this function ?
+ struct media_entity *ents[] = {
+ isp-isp_csi2a.subdev.entity,
+ isp-isp_csi2c.subdev.entity,
+ isp-isp_ccp2.subdev.entity,
+ isp-isp_ccdc.subdev.entity
+ };
+ struct media_pad *source_pad;
+ struct media_entity *source = NULL;
+ struct media_entity *sink;
+ struct v4l2_subdev_format fmt;
+ struct v4l2_ext_controls ctrls;
+ struct v4l2_ext_control ctrl;
+ int i;
i is allowed to be unsigned in this driver as well ;-)
+ int ret = 0;
+
+ for (i = 0; i ARRAY_SIZE(ents); i++) {
+ /* Is the entity part of the pipeline? */
+ if (!(pipe-entities (1 ents[i]-id)))
+ continue;
+
+ /* ISP entities have always sink pad == 0. Find source. */
+ source_pad = media_entity_remote_source(ents[i]-pads[0]);
+
Don't you usually avoid blank lines between a variable assignment and checking
it for an error condition ?
+ if (source_pad == NULL)
+ continue;
+
+ source = source_pad-entity;
+ sink = ents[i];
+ break;
+ }
+
+ if (!source || media_entity_type(source) != MEDIA_ENT_T_V4L2_SUBDEV)
+ return 0;
+
+ pipe-external = media_entity_to_v4l2_subdev(source);
+
+ fmt.pad = source_pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(media_entity_to_v4l2_subdev(sink),
+pad, get_fmt, NULL, fmt);
+ BUG_ON(ret 0);
That's a bit harsh. I'd rather return an error.
+
+ pipe-external_bpp = omap3isp_video_format_info(
+ fmt.format.code)-bpp;
Maybe you could teachs emacs that 78 characters fit in a 80-columns line ? :-)
+
+ memset(ctrls, 0, sizeof(ctrls));
+ memset(ctrl, 0, sizeof(ctrl));
+
+ ctrl.id = V4L2_CID_PIXEL_RATE;
+
+ ctrls.ctrl_class = V4L2_CTRL_ID2CLASS(ctrl.id);
You can leave ctrl_class to 0.
+ ctrls.count = 1;
+ ctrls.controls = ctrl;
+
+ ret = v4l2_g_ext_ctrls(pipe-external-ctrl_handler, ctrls);
+ if (ret 0) {
+ dev_warn(isp-dev,
+ no pixel rate control in subdev %s\n,
No need to split this either.
+ pipe-external-name);
+ return ret;
+ }
+
+ pipe-external_rate = ctrl.value64;
+
+ return 0;
+}
+
/*
* Stream management
*
@@ -1010,6 +1081,10 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) while ((entity = media_entity_graph_walk_next(graph)))
pipe-entities |= 1 entity-id;
+ ret = isp_video_check_external_subdevs(pipe);
+ if (ret 0)
+ goto err_check_format;
+
/* Verify that the currently configured format matches the output of
* the connected subdev.
*/
--
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 v5 25/35] omap3isp: Collect entities that are part of the pipeline
Hi Sakari,
Another comment.
On Tuesday 06 March 2012 18:33:06 Sakari Ailus wrote:
Collect entities which are part of the pipeline into a single bit mask.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
[snip]
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h index d91bdb91..0423c9d 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -96,6 +96,7 @@ struct isp_pipeline {
enum isp_pipeline_stream_state stream_state;
struct isp_video *input;
struct isp_video *output;
+ u32 entities;
unsigned long l3_ick;
unsigned int max_rate;
atomic_t frame_number;
Could you please update the structure documentation ?
@entities: Bitmask of entities in the pipeline (indexed by entity ID)
--
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 v5 28/35] omap3isp: Use external rate instead of vpcfg
Hi Sakari, Thanks for the patch. On Tuesday 06 March 2012 18:33:09 Sakari Ailus wrote: From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Access pipe-external_rate instead of isp_ccdc.vpcfg.pixelclk. Also remove means to set the value for isp_ccdc_vpcfg.pixelclk. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Very nice. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This also means that implementing support for the V4L2_CID_PIXEL_RATE control is required in the sensor drivers to be used with the OMAP3 ISP. I'll submit patches. -- 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 v5 30/35] omap3isp: Move CCDC link validation to ccdc_link_validate()
Hi Sakari,
Thanks for the patch.
On Tuesday 06 March 2012 18:33:11 Sakari Ailus wrote:
Perform CCDC link validation in ccdc_link_validate() instead of
isp_video_validate_pipeline(). Also perform maximum data rate check in
isp_video_check_external_subdevs().
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
[snip]
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index 6d4ad87..51075b3 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
[snip]
@@ -950,6 +867,7 @@ static int isp_video_check_external_subdevs(struct
isp_pipeline *pipe) struct v4l2_subdev_format fmt;
struct v4l2_ext_controls ctrls;
struct v4l2_ext_control ctrl;
+ unsigned int rate = UINT_MAX;
You can move this variable inside the if statement below.
int i;
int ret = 0;
@@ -1002,6 +920,16 @@ static int isp_video_check_external_subdevs(struct
isp_pipeline *pipe)
pipe-external_rate = ctrl.value64;
+ if (pipe-entities (1 isp-isp_ccdc.subdev.entity.id)) {
+ /*
+ * Check that maximum allowed CCDC pixel rate isn't
+ * exceeded by the pixel rate.
What's wrong with 80 columns, really ? :-)
+ */
+ omap3isp_ccdc_max_rate(isp-isp_ccdc, rate);
+ if (pipe-external_rate rate)
+ return -ENOSPC;
+ }
+
return 0;
}
Pending those two changes,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
--
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 v5 32/35] omap3isp: Add resizer data rate configuration to resizer_link_validate
Hi Sakari, Thanks for the patch. On Tuesday 06 March 2012 18:33:13 Sakari Ailus wrote: The configuration of many other blocks depend on resizer maximum data rate. Get the value from resizer at link validation time. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com -- 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 v5 33/35] omap3isp: Find source pad from external entity
Hi Sakari,
Thanks for the patch.
On Tuesday 06 March 2012 18:33:14 Sakari Ailus wrote:
No longer assume pad number 0 is the source pad of the external entity. Find
the source pad from the external entity and use it instead.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
(with one comment below)
---
drivers/media/video/omap3isp/isp.c | 13 -
1 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/omap3isp/isp.c
b/drivers/media/video/omap3isp/isp.c index f54953d..0718b0a 100644
--- a/drivers/media/video/omap3isp/isp.c
+++ b/drivers/media/video/omap3isp/isp.c
@@ -1744,6 +1744,7 @@ static int isp_register_entities(struct isp_device
*isp) struct media_entity *input;
unsigned int flags;
unsigned int pad;
+ unsigned int i;
sensor = isp_register_subdev_group(isp, subdevs-subdevs);
if (sensor == NULL)
@@ -1791,7 +1792,17 @@ static int isp_register_entities(struct isp_device
*isp) goto done;
}
- ret = media_entity_create_link(sensor-entity, 0, input, pad,
+ for (i = 0; i sensor-entity.num_pads; i++)
+ if (sensor-entity.pads[i].flags MEDIA_PAD_FL_SOURCE)
+ break;
While not strictly needed, I find the code easier to read with brackets for
the for statement. It's up to you though.
+ if (i == sensor-entity.num_pads) {
+ dev_err(isp-dev,
+ no source pads in external entities\n);
+ ret = -EINVAL;
+ goto done;
+ }
+
+ ret = media_entity_create_link(sensor-entity, i, input, pad,
flags);
if (ret 0)
goto done;
--
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 0/3] Multi Format Codec 6.x driver for Exynos5
Hi Jeongtae, I have applied your patches to the kernel I am using with my Exynos4, so I am still using MFC 5.1. Unfortunately after applying your patches the MFC 5.1 device no longer works. Did you test you patches with MFC 5.1? Adding support to MFC 6.0 should not break the support for older hardware. I have run the decoding example application and had received the following error: [ 135.929705] samsung-pd samsung-pd.0: enable finished [ 135.978223] Unable to handle kernel paging request at virtual address e087 [ 135.987409] pgd = db21 [ 135.988637] [e087] *pgd=5b825811, *pte=, *ppte= [ 135.994891] Internal error: Oops: 807 [#1] PREEMPT [ 135.999660] Modules linked in: [ 136.002701] CPU: 0Not tainted (3.2.0+ #3334) [ 136.007395] PC is at s5p_mfc_reset+0x58/0x29c [ 136.011732] LR is at get_parent_ip+0x10/0x2c [ 136.015982] pc : [c0262460]lr : [c001d628]psr: 6013 [ 136.015988] sp : db2add90 ip : 0001 fp : [ 136.027437] r10: dbb90964 r9 : 6013 r8 : db022004 [ 136.032645] r7 : db0791e0 r6 : r5 : dbb90800 r4 : dbb90800 [ 136.039155] r3 : e088 r2 : 0fee r1 : a013 r0 : [ 136.045667] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user [ 136.052783] Control: 10c53c7d Table: 5b210059 DAC: 0015 [ 136.058512] Process v4l2_decode (pid: 2872, stack limit = 0xdb2ac2e8) [ 136.064934] Stack: (0xdb2add90 to 0xdb2ae000) [!snip!] [ 136.232472] [c0262460] (s5p_mfc_reset+0x58/0x29c) from [c0262aa0] (s5p_mfc_init_hw+0x68/0x41c) [ 136.241405] [c0262aa0] (s5p_mfc_init_hw+0x68/0x41c) from [c025c89c] (s5p_mfc_open+0x254/0x45c) [ 136.250349] [c025c89c] (s5p_mfc_open+0x254/0x45c) from [c0240a08] (v4l2_open+0xb0/0xe8) [ 136.258682] [c0240a08] (v4l2_open+0xb0/0xe8) from [c008df68] (chrdev_open+0x174/0x194) [ 136.266931] [c008df68] (chrdev_open+0x174/0x194) from [c00896f8] (__dentry_open+0x1dc/0x2e8) [ 136.275694] [c00896f8] (__dentry_open+0x1dc/0x2e8) from [c00898b4] (nameidata_to_filp+0x50/0x5c) [ 136.284808] [c00898b4] (nameidata_to_filp+0x50/0x5c) from [c00979c4] (do_last+0x560/0x6a0) [ 136.293398] [c00979c4] (do_last+0x560/0x6a0) from [c0097bc8] (path_openat+0xc4/0x394) [ 136.301556] [c0097bc8] (path_openat+0xc4/0x394) from [c0097f78] (do_filp_open+0x30/0x7c) [ 136.309978] [c0097f78] (do_filp_open+0x30/0x7c) from [c0089380] (do_sys_open+0xd8/0x174) [ 136.318401] [c0089380] (do_sys_open+0xd8/0x174) from [c000dbc0] (ret_fast_syscall+0x0/0x30) [ 136.327076] Code: 0a00 e12fff33 e59430a0 e3002fee (e5032001) [ 136.341366] ---[ end trace 14efbfaf5f28c406 ]--- This has nothing to do with the BYTES/BITS change that would break encoding. From: Jeongtae Park [mailto:jtp.p...@samsung.com] Sent: 02 March 2012 03:16 Hi Everyone, This patch series is the 1st version of the MFC 6.x driver based on MFC 5.1 driver I would be grateful for your comments. This patch series contains: [PATCH 1/3] v4l: add contorl definitions for codec devices. [PATCH 2/3] v4l2-ctrl: add codec controls support to the control framework [PATCH 3/3] MFC: update MFC v4l2 driver to support MFC6.x Best regards, Jeongtae Park Patch summary: Jeongtae Park (3): v4l: add contorl definitions for codec devices. v4l2-ctrl: add codec controls support to the control framework MFC: update MFC v4l2 driver to support MFC6.x drivers/media/video/Kconfig | 15 +- drivers/media/video/s5p-mfc/Makefile |7 +- drivers/media/video/s5p-mfc/regs-mfc-v6.h| 671 +++ drivers/media/video/s5p-mfc/regs-mfc.h | 29 + drivers/media/video/s5p-mfc/s5p_mfc.c| 157 ++- drivers/media/video/s5p-mfc/s5p_mfc_cmd.c|4 +- drivers/media/video/s5p-mfc/s5p_mfc_cmd.h|3 + drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c | 129 ++ drivers/media/video/s5p-mfc/s5p_mfc_common.h | 125 ++- drivers/media/video/s5p-mfc/s5p_mfc_ctrl.c | 113 ++- drivers/media/video/s5p-mfc/s5p_mfc_dec.c| 212 +++- drivers/media/video/s5p-mfc/s5p_mfc_enc.c| 364 +-- drivers/media/video/s5p-mfc/s5p_mfc_intr.c |1 - drivers/media/video/s5p-mfc/s5p_mfc_opr.c| 266 +++-- drivers/media/video/s5p-mfc/s5p_mfc_opr.h| 20 +- drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c | 1670 ++ drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h | 137 +++ drivers/media/video/s5p-mfc/s5p_mfc_shm.c| 27 +- drivers/media/video/s5p-mfc/s5p_mfc_shm.h| 13 +- drivers/media/video/v4l2-ctrls.c | 41 +- include/linux/videodev2.h| 51 +- 21 files changed, 3675 insertions(+), 380 deletions(-) create mode 100644 drivers/media/video/s5p-mfc/regs-mfc-v6.h create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_cmd_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.c create mode 100644 drivers/media/video/s5p-mfc/s5p_mfc_opr_v6.h Best wishes, -- Kamil Debski Linux
Re: [PATCH v3 5/5] v4l: Add driver for Micron MT9M032 camera sensor
Hi Sakari,
On Wednesday 07 March 2012 01:16:33 Sakari Ailus wrote:
Hi Laurent,
Thanks for the patch.
I have a few comments below. Just one fairly general question: locking.
Shouldn't you serialise accesses to sensor registers and your data,
possibly by using a mutex?
I guess I should, yes... :-) will fix.
Laurent Pinchart wrote:
From: Martin Hostettler mar...@neutronstar.dyndns.org
The MT9M032 is a parallel 1.6MP sensor from Micron controlled through I2C.
The driver creates a V4L2 subdevice. It currently supports cropping, gain,
exposure and v/h flipping controls in monochrome mode with an
external pixel clock.
Signed-off-by: Martin Hostettler mar...@neutronstar.dyndns.org
[Lots of clean up, fixes and enhancements]
Signed-off-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
[snip]
diff --git a/drivers/media/video/Makefile b/drivers/media/video/Makefile
index d1304e1..8e037e9 100644
--- a/drivers/media/video/Makefile
+++ b/drivers/media/video/Makefile
@@ -82,6 +82,7 @@ obj-$(CONFIG_VIDEO_AS3645A) += as3645a.o
obj-$(CONFIG_SOC_CAMERA_IMX074)+= imx074.o
obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o
+obj-$(CONFIG_VIDEO_MT9M032) += mt9m032.o
I would put this among the other subdev sensor drivers instead.
Good point.
obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o
obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o
obj-$(CONFIG_SOC_CAMERA_MT9T112) += mt9t112.o
diff --git a/drivers/media/video/mt9m032.c b/drivers/media/video/mt9m032.c
new file mode 100644
index 000..c3d69aa
--- /dev/null
+++ b/drivers/media/video/mt9m032.c
[snip]
+static u32 mt9m032_row_time(struct mt9m032 *sensor, unsigned int width)
+{
+ unsigned int effective_width;
+ u32 ns;
+
+ effective_width = width + 716; /* emperical value */
Why empirical value? This should be directly related to image width
(before binning) and horizontal blanking.
Ask Martin :-)
I don't have access to the documentation nor the hardware, so I'd rather keep
the value as-is for now.
+ ns = div_u64(10ULL * effective_width, sensor-pix_clock);
+ dev_dbg(to_dev(sensor), MT9M032 line time: %u ns\n, ns);
+ return ns;
+}
[snip]
+static int mt9m032_setup_pll(struct mt9m032 *sensor)
+{
+ static const struct aptina_pll_limits limits = {
+ .ext_clock_min = 800,
+ .ext_clock_max = 1650,
+ .int_clock_min = 200,
+ .int_clock_max = 2400,
+ .out_clock_min = 32200,
+ .out_clock_max = 69300,
+ .pix_clock_max = 9900,
+ .n_min = 1,
+ .n_max = 64,
+ .m_min = 16,
+ .m_max = 255,
+ .p1_min = 1,
+ .p1_max = 128,
+ };
+
+ struct i2c_client *client = v4l2_get_subdevdata(sensor-subdev);
+ struct mt9m032_platform_data *pdata = sensor-pdata;
+ struct aptina_pll pll;
+ int ret;
+
+ pll.ext_clock = pdata-ext_clock;
+ pll.pix_clock = pdata-pix_clock;
You could initialise these in the declaration.
Yes, but I would find that less readable :-)
+ ret = aptina_pll_calculate(client-dev, limits, pll);
+ if (ret 0)
+ return ret;
+
+ sensor-pix_clock = pll.pix_clock;
+
+ ret = mt9m032_write(client, MT9M032_PLL_CONFIG1,
+ (pll.m MT9M032_PLL_CONFIG1_MUL_SHIFT)
+ | (pll.p1 - 1));
+ if (!ret)
+ ret = mt9m032_write(client, MT9P031_PLL_CONFIG2, pll.n - 1);
+ if (!ret)
+ ret = mt9m032_write(client, MT9P031_PLL_CONTROL,
+ MT9P031_PLL_CONTROL_PWRON |
+ MT9P031_PLL_CONTROL_USEPLL);
+ if (!ret) /* more reserved, Continuous, Master Mode */
+ ret = mt9m032_write(client, MT9M032_READ_MODE1, 0x8006);
+ if (!ret) /* Set 14-bit mode, select 7 divider */
+ ret = mt9m032_write(client, MT9M032_FORMATTER1, 0x111e);
I hope the datasheet is public. :-)
If there is one in a known URL it wouldn't hurt to refer to it, I think.
It's not public, and I don't have access to it (yet at least). I would have
modified this otherwise.
+ return ret;
+}
[snip]
+/**
+ * __mt9m032_get_pad_crop() - get crop rect
+ * @sensor: pointer to the sensor struct
+ * @fh: filehandle for getting the try crop rect from
+ * @which: select try or active crop rect
+ *
+ * Returns a pointer the current active or fh relative try crop rect
+ */
+static struct v4l2_rect *
+__mt9m032_get_pad_crop(struct mt9m032 *sensor, struct v4l2_subdev_fh *fh,
+ enum v4l2_subdev_format_whence which)
+{
+ switch (which) {
+ case V4L2_SUBDEV_FORMAT_TRY:
+ return v4l2_subdev_get_try_crop(fh, 0);
+ case V4L2_SUBDEV_FORMAT_ACTIVE:
+ return sensor-crop;
+
Re: [PATCH v5 34/35] smiapp: Generic SMIA++/SMIA PLL calculator
Hi Sakari,
Thanks for the patch.
On Tuesday 06 March 2012 18:33:15 Sakari Ailus wrote:
From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
Calculate PLL configuration based on input data: sensor configuration, board
properties and sensor-specific limits.
Signed-off-by: Sakari Ailus sakari.ai...@maxwell.research.nokia.com
[snip]
diff --git a/drivers/media/video/smiapp-pll.c
b/drivers/media/video/smiapp-pll.c new file mode 100644
index 000..3a999c0
--- /dev/null
+++ b/drivers/media/video/smiapp-pll.c
[snip]
+int smiapp_pll_calculate(struct device *dev, struct smiapp_pll_limits
*limits,
+ struct smiapp_pll *pll)
+{
[snip]
+ /*
+ * Some sensors perform analogue binning and some do this
+ * digitally. The ones doing this digitally can be roughly be
+ * found out using this formula. The ones doing this digitally
+ * should run at higher clock rate, so smaller divisor is used
+ * on video timing side.
+ */
+ if (limits-min_line_length_pck_bin limits-min_line_length_pck
+ / pll-binning_horizontal)
+ vt_op_binning_div = pll-binning_horizontal;
+ else
+ vt_op_binning_div = 1;
+ dev_dbg(dev, vt_op_binning_div: %d\n, vt_op_binning_div);
+
+ /*
+ * Profile 2 supports vt_pix_clk_div E [4, 10]
+ *
+ * Horizontal binning can be used as a base for difference in
+ * divisors. One must make sure that horizontal blanking is
+ * enough to accommodate the CSI-2 sync codes.
+ *
+ * Take scaling factor into account as well.
+ *
+ * Find absolute limits for the factor of vt divider.
+ */
+ dev_dbg(dev, scale_m: %d\n, pll-scale_m);
+ min_vt_div = DIV_ROUND_UP(pll-op_pix_clk_div * pll-op_sys_clk_div
+ * pll-scale_n,
I still need
if (pll-flags SMIAPP_PLL_FLAG_DUAL_READOUT)
num_readout_paths = 2;
else
num_readout_paths = 1;
min_vt_div = DIV_ROUND_UP(pll-op_pix_clk_div * pll-op_sys_clk_div
* pll-scale_n * num_readout_paths,
for the AR0330 driver, but I can add that later.
+ lane_op_clock_ratio * vt_op_binning_div
+ * pll-scale_m);
[snip]
+ /*
+ * Find pix_div such that a legal pix_div * sys_div results
+ * into a value which is not smaller than div, the desired
+ * divisor.
+ */
+ for (vt_div = min_vt_div; vt_div = max_vt_div;
+ vt_div += 2 - (vt_div 1)) {
+ for (sys_div = min_sys_div;
+ sys_div = max_sys_div;
+ sys_div += 2 - (sys_div 1)) {
+ int pix_div = DIV_ROUND_UP(vt_div, sys_div);
+
+ if (pix_div
+ limits-min_vt_pix_clk_div
+ || pix_div
+ limits-max_vt_pix_clk_div) {
if (pix_div limits-min_vt_pix_clk_div ||
pix_div limits-max_vt_pix_clk_div) {
+ dev_dbg(dev,
+ pix_div %d too small or too big
(%d--%d)\n,
+ pix_div,
+ limits-min_vt_pix_clk_div,
+ limits-max_vt_pix_clk_div);
+ continue;
+ }
+
+ /* Check if this one is better. */
+ if (pix_div * sys_div
+ = ALIGN(min_vt_div, best_pix_div))
+ best_pix_div = pix_div;
+ }
+ if (best_pix_div INT_MAX 1)
+ break;
+ }
[snip]
diff --git a/drivers/media/video/smiapp/smiapp-core.c
b/drivers/media/video/smiapp/smiapp-core.c new file mode 100644
index 000..879fb1e
--- /dev/null
+++ b/drivers/media/video/smiapp/smiapp-core.c
[snip]
+static void smiapp_get_crop_compose(struct v4l2_subdev *subdev,
+ struct v4l2_subdev_fh *fh,
+ struct v4l2_rect **crops,
+ struct v4l2_rect **comps, int which)
+{
+ struct smiapp_subdev *ssd = to_smiapp_subdev(subdev);
+ int i;
Can you guess ? :-)
+
+ if (which == V4L2_SUBDEV_FORMAT_ACTIVE) {
+ if (crops)
+ for (i = 0; i subdev-entity.num_pads; i++)
+ crops[i] = ssd-crop[i];
+ if (comps)
+ *comps = ssd-compose;
+ } else {
+ if (crops) {
+ for (i = 0; i subdev-entity.num_pads; i++) {
+ crops[i] = v4l2_subdev_get_try_crop(fh, i);
+ BUG_ON(!crops[i]);
+ }
+ }
+
Re: Lockup on second streamon with omap3-isp
Le 6 mars 2012 18:08, jean-philippe francois jp.franc...@cynove.com a écrit : Hi, I have a custom dm3730 board, running a 3.2.0 kernel. The board is equipped with an aptina MT9J sensor on parallel interface. Whenever I try to run yavta twice, the second run leads to a soft lockup in omap3isp_video_queue_streamon (see below) What can I do / test to debug this issue ? Examining the offset, The code is stuck in the for_each loop, but I fail to see why. I added list manipulation and spinlock debugging, without detecting any problem. # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x4023e000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x4034d000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x40444000. 0 (0) [-] 4294967295 307200 bytes 100.397705 100.397796 7.817 fps 1 (1) [-] 4294967295 307200 bytes 100.495666 100.495788 10.208 fps 2 (2) [-] 4294967295 307200 bytes 100.593658 100.593750 10.205 fps 3 (0) [-] 4294967295 307200 bytes 100.691619 100.691741 10.208 fps 4 (1) [-] 4294967295 307200 bytes 100.789611 100.789703 10.205 fps 5 (2) [-] 4294967295 307200 bytes 100.887573 100.887695 10.208 fps 6 (0) [-] 4294967295 307200 bytes 100.985565 100.985656 10.205 fps 7 (1) [-] 4294967295 307200 bytes 101.083526 101.083709 10.208 fps 8 (2) [-] 4294967295 307200 bytes 101.181488 101.181610 10.208 fps 9 (0) [-] 4294967295 307200 bytes 101.279480 101.279571 10.205 fps Captured 10 frames in 1.009796 seconds (9.902989 fps, 3042198.137254 B/s). 3 buffers released. [1]+ Done httpd # get.vga Device /dev/video2 opened. Device `OMAP3 ISP CCDC output' on `media' is a video capture device. Video format set: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 Video format: SGRBG8 (47425247) 640x480 (stride 640) buffer size 307200 3 buffers requested. length: 307200 offset: 0 Buffer 0 mapped at address 0x40285000. length: 307200 offset: 307200 Buffer 1 mapped at address 0x40314000. length: 307200 offset: 614400 Buffer 2 mapped at address 0x403bb000. BUG: soft lockup - CPU#0 stuck for 22s! [yavta:495] Modules linked in: ks8851_mll omap3_isp fpgacam(O) Pid: 495, comm: yavta CPU: 0 Tainted: G O (3.2.0 #52) PC is at __do_softirq+0x50/0x110 LR is at __do_softirq+0x38/0x110 pc : [c003746c] lr : [c0037454] psr: 2113 sp : ce8e5c88 ip : cf406140 fp : r10: cee90800 r9 : 000a r8 : ce8e4000 r7 : 0002 r6 : r5 : r4 : 0025 r3 : c044e580 r2 : r1 : 0002 r0 : Flags: nzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user Control: 10c5387d Table: 8e858019 DAC: 0015 [c00123b0] (unwind_backtrace+0x0/0xec) from [c00646c4] (watchdog_timer_fn+0xd8/0x128) [c00646c4] (watchdog_timer_fn+0xd8/0x128) from [c004e640] (__run_hrtimer+0x68/0xe4) [c004e640] (__run_hrtimer+0x68/0xe4) from [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) [c004e8b0] (hrtimer_interrupt+0x11c/0x2a4) from [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) [c0018f44] (omap2_gp_timer_interrupt+0x24/0x34) from [c0064df8] (handle_irq_event_percpu+0x28/0x110) [c0064df8] (handle_irq_event_percpu+0x28/0x110) from [c0064f34] (handle_irq_event+0x54/0x74) [c0064f34] (handle_irq_event+0x54/0x74) from [c00676f8] (handle_level_irq+0xb4/0x100) [c00676f8] (handle_level_irq+0xb4/0x100) from [c0064a28] (generic_handle_irq+0x28/0x30) [c0064a28] (generic_handle_irq+0x28/0x30) from [c000e570] (handle_IRQ+0x60/0x84) [c000e570] (handle_IRQ+0x60/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [c003746c] (__do_softirq+0x50/0x110) [c003746c] (__do_softirq+0x50/0x110) from [c00376f0] (irq_exit+0x48/0x9c)omap3isp_video_queue_streamon [c00376f0] (irq_exit+0x48/0x9c) from [c000e574] (handle_IRQ+0x64/0x84) [c000e574] (handle_IRQ+0x64/0x84) from [c000d874] (__irq_svc+0x34/0x98) [c000d874] (__irq_svc+0x34/0x98) from [bf007864] (+0x6c/0xa0 [omap3_isp]) [bf007864] (omap3isp_video_queue_streamon+0x6c/0xa0 [omap3_isp]) from [bf0096cc] (isp_video_streamon+0x178/0x258 [omap3_isp]) [bf0096cc] (isp_video_streamon+0x178/0x258 [omap3_isp]) from [c022cae4] (__video_do_ioctl+0x1b9c/0x4894) [c022cae4] (__video_do_ioctl+0x1b9c/0x4894) from [c022ae08] (video_usercopy+0x1b8/0x298) [c022ae08] (video_usercopy+0x1b8/0x298) from [c0229d48] (v4l2_ioctl+0x68/0x114) [c0229d48] (v4l2_ioctl+0x68/0x114) from [c00a2514] (vfs_ioctl+0x20/0x3c) [c00a2514] (vfs_ioctl+0x20/0x3c) from [c00a2d9c] (do_vfs_ioctl+0x1ac/0x1c4) [c00a2d9c] (do_vfs_ioctl+0x1ac/0x1c4) from [c00a2de8] (sys_ioctl+0x34/0x54) [c00a2de8] (sys_ioctl+0x34/0x54) from [c000dcc0] (ret_fast_syscall+0x0/0x30)
Re: A second easycap driver implementation
Hi, Have you considered instead slowly moving the existing easycap driver over to all the new infrastructure we have now. For starters replace its buffer management with videobuf2, then in another patch replace some other bits, etc. ? See what I've done to the pwc driver :) Yes. And that was what I was doing until now. Yet, after some work it seemed much easier to simply start over from scratch. Besides, it's being a great learning experience :) So, since the driver is not yet working I guess there is no point in submitting anything. Instead, anyone the wants to help I can send what I have now or we can start working through github. If someone owns this device, it would be a *huge* help with testing. However, as soon as this is capturing video I would like to put it on staging, so everyone can help. Is this possible? 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 v5 25/35] omap3isp: Collect entities that are part of the pipeline
Hi Laurent,
On Wed, Mar 07, 2012 at 11:50:19AM +0100, Laurent Pinchart wrote:
Hi Sakari,
Another comment.
On Tuesday 06 March 2012 18:33:06 Sakari Ailus wrote:
Collect entities which are part of the pipeline into a single bit mask.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
[snip]
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h index d91bdb91..0423c9d 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -96,6 +96,7 @@ struct isp_pipeline {
enum isp_pipeline_stream_state stream_state;
struct isp_video *input;
struct isp_video *output;
+ u32 entities;
unsigned long l3_ick;
unsigned int max_rate;
atomic_t frame_number;
Could you please update the structure documentation ?
@entities: Bitmask of entities in the pipeline (indexed by entity ID)
Sure. I'll take that from your patch. ;-)
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Wed, 7 Mar 2012 09:59:28 +1100 Xavion xavio...@gmail.com wrote: root@Desktop /etc/motion # tail /var/log/kernel.log Mar 6 08:34:17 Desktop kernel: [ 7240.125167] gspca_main: ISOC data error: [0] len=0, status=-18 ... Hmm, error -18 is EXDEV, which according to Documentation/usb/error-codes.txt is: -EXDEV ISO transfer only partially completed (only set in iso_frame_desc[n].status, not urb-status) I've seen those before, and I think we should simply ignore them rather then log an error for them. Jean-Francois, what do you think? I'll let you guys decide what to do about this, but remember that I'm here to help if you need more testing done. If you want my opinion, I'd be leaning towards trying to prevent any errors that appear regularly. Hi, It seems that the webcams handled by the driver sn9c20x work the same as the ones handled by sonixj. In this last driver, I adjust the JPEG compression to avoid the errors USB FIFO full, and I think that these errors also raise the URB error -18 with the sn9c20x. I will need some time to put a same code into the sn9c20x, then I'd be glad to have it tested. There was an other problem in the driver sonixj: the end of frame marker was not always at the right place. Xavion, as you have ms-windows, may you do some USB traces with this system? I need a capture sequence of about 15 seconds (not more) with big luminosity changes. This isn't even the proper SXGA resolution, which is supposed to be 1280x1024. The Sonix website claims that their SN9C201 webcam can provide up to a 1.3 MP (SXGA) video size! Do you happen to know of any inexpensive webcams that are capable of true SXGA in Linux? `-- lsusb | grep Cam Bus 001 Device 006: ID 0c45:627b Microdia PC Camera (SN9C201 + OV7660) The sensor ov7660 can do VGA only (640x480). Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it? -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- 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: A second easycap driver implementation
On Wed, Mar 07, 2012 at 11:32:23AM -0300, Ezequiel García wrote: Hi, Have you considered instead slowly moving the existing easycap driver over to all the new infrastructure we have now. For starters replace its buffer management with videobuf2, then in another patch replace some other bits, etc. ? See what I've done to the pwc driver :) Yes. And that was what I was doing until now. Yet, after some work it seemed much easier to simply start over from scratch. Besides, it's being a great learning experience :) So, since the driver is not yet working I guess there is no point in submitting anything. Instead, anyone the wants to help I can send what I have now or we can start working through github. If someone owns this device, it would be a *huge* help with testing. However, as soon as this is capturing video I would like to put it on staging, so everyone can help. Is this possible? Yes it is, just send the patches to the correct people (note I don't control the drivers/staging/media subdirectory.) good luck, greg k-h -- 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] af9015: fix i2c failures for dual-tuner devices
On 22.01.2012 22:13, Gordon Hecker wrote:
The i2c failures were caused by enabling both i2c gates
at the same time while putting the tuners asleep.
This patch removes the init() and sleep() callbacks from the tuner,
to prevent frontend.c from calling
i2c_gate_ctrl
tuner init / sleep
i2c_gate_ctrl
without holding the lock.
tuner init() and sleep() are instead called in frontend init() and
sleep().
Signed-off-by: Gordon Hecker ghec...@gmx.de
---
drivers/media/dvb/dvb-usb/af9015.c | 31 +++
drivers/media/dvb/dvb-usb/af9015.h |2 ++
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/af9015.c
b/drivers/media/dvb/dvb-usb/af9015.c
index e755d76..b69b43b 100644
--- a/drivers/media/dvb/dvb-usb/af9015.c
+++ b/drivers/media/dvb/dvb-usb/af9015.c
@@ -1141,7 +1141,18 @@ static int af9015_af9013_init(struct dvb_frontend *fe)
return -EAGAIN;
ret = priv-init[adap-id](fe);
+ if (ret)
+ goto err_unlock;
+
+ if (priv-tuner_ops_init[adap-id]) {
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ ret = priv-tuner_ops_init[adap-id](fe);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+ }
+err_unlock:
mutex_unlock(adap-dev-usb_mutex);
return ret;
@@ -1157,8 +1168,19 @@ static int af9015_af9013_sleep(struct dvb_frontend *fe)
if (mutex_lock_interruptible(adap-dev-usb_mutex))
return -EAGAIN;
+ if (priv-tuner_ops_sleep[adap-id]) {
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 1);
+ ret = priv-tuner_ops_sleep[adap-id](fe);
+ if (fe-ops.i2c_gate_ctrl)
+ fe-ops.i2c_gate_ctrl(fe, 0);
+ if (ret)
+ goto err_unlock;
+ }
+
ret = priv-sleep[adap-id](fe);
+err_unlock:
mutex_unlock(adap-dev-usb_mutex);
return ret;
@@ -1283,6 +1305,7 @@ static struct mxl5007t_config af9015_mxl5007t_config = {
static int af9015_tuner_attach(struct dvb_usb_adapter *adap)
{
int ret;
+ struct af9015_state *state = adap-dev-priv;
deb_info(%s:\n, __func__);
switch (af9015_af9013_config[adap-id].tuner) {
@@ -1340,6 +1363,14 @@ static int af9015_tuner_attach(struct dvb_usb_adapter
*adap)
err(Unknown tuner id:%d,
af9015_af9013_config[adap-id].tuner);
}
+
+ state-tuner_ops_sleep[adap-id] =
+ adap-fe_adap[0].fe-ops.tuner_ops.sleep;
+ adap-fe_adap[0].fe-ops.tuner_ops.sleep = 0;
+
+ state-tuner_ops_init[adap-id] =
+ adap-fe_adap[0].fe-ops.tuner_ops.init;
+ adap-fe_adap[0].fe-ops.tuner_ops.init = 0;
return ret;
}
diff --git a/drivers/media/dvb/dvb-usb/af9015.h
b/drivers/media/dvb/dvb-usb/af9015.h
index f619063..ee2ec5b 100644
--- a/drivers/media/dvb/dvb-usb/af9015.h
+++ b/drivers/media/dvb/dvb-usb/af9015.h
@@ -108,6 +108,8 @@ struct af9015_state {
int (*read_status[2]) (struct dvb_frontend *fe, fe_status_t *status);
int (*init[2]) (struct dvb_frontend *fe);
int (*sleep[2]) (struct dvb_frontend *fe);
+ int (*tuner_ops_init[2]) (struct dvb_frontend *fe);
+ int (*tuner_ops_sleep[2]) (struct dvb_frontend *fe);
};
struct af9015_config {
Both tuners perform stable.
Tested on mythbackend multiple streams simultaneously.
+1
rgds,
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
Re: Technotrend TT-Connect CT 3650 and dvb_ca
Hi Johan, I have a similar problem which happens every few days with this card. For me it helps to remove and reinsert the kernel module whenever this happens. rmmod -f dvb_usb_ttusb2 modprobe dvb_usb_ttusb2 see also the following unresolved threads: http://www.spinics.net/lists/linux-media/msg43531.html http://www.spinics.net/lists/linux-media/msg43813.html Martin On Tue, 2012-03-06 at 21:40 +0100, Johan Henæs wrote: Hello Everyone ! I have three DVB-C devices of the type mentioned, connected to my mythtv-server which have been working great for a long time. As my cable provider now are planning to start encrypting all channels, I have bought a Xcrypt CAM module as needed. I soon realised that I needed to upgrade the kernel and are now running kernel /: 3.2.0-17-generic #27-Ubuntu SMP Fri Feb 24 22:03:50 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux/ . When inserting the module everything looks well : /dvb_ca adapter 0: DVB CAM detected and initialised successfully/ The problems start when trying to watch an encrypted channel. I do get a channel lock in myth, so far so good, but no picture... In my syslog I see the following : /dvb_ca adapter 0: CAM tried to send a buffer larger than the link buffer size (32896 255)! dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size! dvb_ca adapter 0: DVB CAM link initialisation failed :(/ Any ideas on what might be wrong ? Best regards, Johan -- 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 signature.asc Description: This is a digitally signed message part
Re: A second easycap driver implementation
Em 07-03-2012 12:43, gregkh escreveu: On Wed, Mar 07, 2012 at 11:32:23AM -0300, Ezequiel García wrote: Hi, Have you considered instead slowly moving the existing easycap driver over to all the new infrastructure we have now. For starters replace its buffer management with videobuf2, then in another patch replace some other bits, etc. ? See what I've done to the pwc driver :) Yes. And that was what I was doing until now. Yet, after some work it seemed much easier to simply start over from scratch. Yes, the driver is weird, as it encapsulates the demod code inside it , instead of using the saa7115 driver, that covers most of saa711x devices, including saa7113. Btw, is this driver really needed? The em28xx driver has support for the Easy Cap Capture DC-60 model (I had access to one of those in the past, and I know that the driver works properly). What's the chipset using on your Easycap device? If it is not an Empiatech em28xx USB bridge, then it makes sense to have a separate driver for it. Otherwise, it is just easier and better to add support for your device there. Besides, it's being a great learning experience :) So, since the driver is not yet working I guess there is no point in submitting anything. Instead, anyone the wants to help I can send what I have now or we can start working through github. If someone owns this device, it would be a *huge* help with testing. However, as soon as this is capturing video I would like to put it on staging, so everyone can help. Is this possible? Yes it is, just send the patches to the correct people (note I don't control the drivers/staging/media subdirectory.) good luck, greg k-h -- 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: A second easycap driver implementation
On Wed, Mar 7, 2012 at 1:35 PM, Mauro Carvalho Chehab mche...@redhat.com wrote: Yes, the driver is weird, as it encapsulates the demod code inside it , instead of using the saa7115 driver, that covers most of saa711x devices, including saa7113. Btw, is this driver really needed? The em28xx driver has support for the Easy Cap Capture DC-60 model (I had access to one of those in the past, and I know that the driver works properly). What's the chipset using on your Easycap device? Chipset is STK116. I'm not entirely sure but is seems that there are to models: DC60 and DC60+. Apparently, the former would be using STK1160. If it is not an Empiatech em28xx USB bridge, then it makes sense to have a separate driver for it. Otherwise, it is just easier and better to add support for your device there. Ok, I'll take a look at the em28xx driver and also at the saa711x to see how would it be possible to add support for this device. Perhaps, we'll end up with a separate driver but based on some common code. 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: A second easycap driver implementation
Em 07-03-2012 13:45, Ezequiel García escreveu:
On Wed, Mar 7, 2012 at 1:35 PM, Mauro Carvalho Chehab
mche...@redhat.com wrote:
Yes, the driver is weird, as it encapsulates the demod code
inside it , instead of using the saa7115 driver, that covers most
of saa711x devices, including saa7113.
Btw, is this driver really needed? The em28xx driver has support
for the Easy Cap Capture DC-60 model (I had access to one of those
in the past, and I know that the driver works properly).
What's the chipset using on your Easycap device?
Chipset is STK116. I'm not entirely sure but is seems that
there are to models: DC60 and DC60+.
Hmmm... so there are two different chipsets for DC60.
Apparently, the former would be using STK1160.
If it is not an Empiatech em28xx USB bridge, then it makes sense
to have a separate driver for it. Otherwise, it is just easier
and better to add support for your device there.
Ok, I'll take a look at the em28xx driver and also at the saa711x
to see how would it be possible to add support for this device.
em28xx is a good reference.
The usage of saa711x is simple. All you need to do is to implement
an I2C bus at your easycap driver, load the module, and then, redirect
any demod ioctl call to the I2C bus, like:
static int vidioc_querystd(struct file *file, void *priv, v4l2_std_id *norm)
{
struct em28xx_fh *fh = priv;
struct em28xx *dev = fh-dev;
intrc;
rc = check_dev(dev);
if (rc 0)
return rc;
v4l2_device_call_all(dev-v4l2_dev, 0, video, querystd, norm);
return 0;
}
An I2C device has an address that needs to be send through the I2C
bus.
The saa711x devices use one of the I2C addresses below:
static unsigned short saa711x_addrs[] = {
0x4a 1, 0x48 1, /* SAA7111, SAA7111A and SAA7113 */
0x42 1, 0x40 1, /* SAA7114, SAA7115 and SAA7118 */
I2C_CLIENT_END };
It is not clear, from the easycap code, where the I2C address
is stored:
int write_saa(struct usb_device *p, u16 reg0, u16 set0)
{
if (!p)
return -ENODEV;
SET(p, 0x200, 0x00);
SET(p, 0x204, reg0);
SET(p, 0x205, set0);
SET(p, 0x200, 0x01);
return wait_i2c(p);
}
int read_saa(struct usb_device *p, u16 reg0)
{
u8 igot;
if (!p)
return -ENODEV;
SET(p, 0x208, reg0);
SET(p, 0x200, 0x20);
if (0 != wait_i2c(p))
return -1;
igot = 0;
GET(p, 0x0209, igot);
return igot;
}
Maybe they're stored on some other register, or maybe this device
has the I2C hardcoded (with would be very ugly and unlikely, but
I won't doubt that some vendor might be doing that).
Anyway, if you take a look at cx231xx and tm6000, you'll see that
some I2C bad implementations require a per-address type of logic.
Perhaps, we'll end up with a separate driver but based on
some common code.
As it is not an em28xx, a separate implementation for the stk chipset
is required. You should not need to re-invent the wheel for saa711x.
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 v5 25/35] omap3isp: Collect entities that are part of the pipeline
Hi Laurent,
On Wed, Mar 07, 2012 at 11:35:02AM +0100, Laurent Pinchart wrote:
On Tuesday 06 March 2012 18:33:06 Sakari Ailus wrote:
Collect entities which are part of the pipeline into a single bit mask.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c |9 +
drivers/media/video/omap3isp/ispvideo.h |1 +
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d34f690..4bc9cca 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -970,6 +970,8 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) {
struct isp_video_fh *vfh = to_isp_video_fh(fh);
struct isp_video *video = video_drvdata(file);
+ struct media_entity_graph graph;
+ struct media_entity *entity;
enum isp_pipeline_state state;
struct isp_pipeline *pipe;
struct isp_video *far_end;
@@ -992,6 +994,8 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) pipe = video-video.entity.pipe
? to_isp_pipeline(video-video.entity) : video-pipe;
+ pipe-entities = 0;
+
This could be move right before the graph walk code below to keep both parts
together. However, pipe-entities would then be invalid (instead of always 0)
in the link validation operations. That can be considered as an issue, so I'm
fine if you prefer leaving this assignment here.
That's what I also thought, so let's leave it there.
if (video-isp-pdata-set_constraints)
video-isp-pdata-set_constraints(video-isp, true);
pipe-l3_ick = clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
@@ -1001,6 +1005,11 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) if (ret 0)
goto err_pipeline_start;
+ entity = video-video.entity;
+ media_entity_graph_walk_start(graph, entity);
+ while ((entity = media_entity_graph_walk_next(graph)))
+ pipe-entities |= 1 entity-id;
+
To avoid walking the graph one more time, what about moving this to
isp_video_far_end() where we already walk the graph (and moving the
isp_video_far_end() call earlier in this function) ? You could possible
rename
isp_video_far_end() to something a bit more in line with its new purpose then.
isp_video_get_graph_data()?
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5.1 25/35] omap3isp: Collect entities that are part of the pipeline
Collect entities which are part of the pipeline into a single bit mask.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 48 ---
drivers/media/video/omap3isp/ispvideo.h |2 +
2 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index d34f690..7411076 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -255,8 +255,9 @@ isp_video_remote_subdev(struct isp_video *video, u32 *pad)
}
/* Return a pointer to the ISP video instance at the far end of the pipeline.
*/
-static struct isp_video *
-isp_video_far_end(struct isp_video *video)
+static int isp_video_get_graph_data(struct isp_video *video,
+ struct isp_pipeline *pipe,
+ enum isp_pipeline_state *state)
{
struct media_entity_graph graph;
struct media_entity *entity = video-video.entity;
@@ -267,6 +268,8 @@ isp_video_far_end(struct isp_video *video)
media_entity_graph_walk_start(graph, entity);
while ((entity = media_entity_graph_walk_next(graph))) {
+ pipe-entities |= 1 entity-id;
+
if (entity == video-video.entity)
continue;
@@ -281,7 +284,21 @@ isp_video_far_end(struct isp_video *video)
}
mutex_unlock(mdev-graph_mutex);
- return far_end;
+
+ if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ *state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
+ pipe-input = far_end;
+ pipe-output = video;
+ } else {
+ if (far_end == NULL)
+ return -EPIPE;
+
+ *state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
+ pipe-input = video;
+ pipe-output = far_end;
+ }
+
+ return 0;
}
/*
@@ -972,7 +989,6 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
struct isp_video *video = video_drvdata(file);
enum isp_pipeline_state state;
struct isp_pipeline *pipe;
- struct isp_video *far_end;
unsigned long flags;
int ret;
@@ -992,6 +1008,8 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
pipe = video-video.entity.pipe
? to_isp_pipeline(video-video.entity) : video-pipe;
+ pipe-entities = 0;
+
if (video-isp-pdata-set_constraints)
video-isp-pdata-set_constraints(video-isp, true);
pipe-l3_ick = clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
@@ -1011,25 +1029,9 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
video-bpl_padding = ret;
video-bpl_value = vfh-format.fmt.pix.bytesperline;
- /* Find the ISP video node connected at the far end of the pipeline and
-* update the pipeline.
-*/
- far_end = isp_video_far_end(video);
-
- if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
- pipe-input = far_end;
- pipe-output = video;
- } else {
- if (far_end == NULL) {
- ret = -EPIPE;
- goto err_check_format;
- }
-
- state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
- pipe-input = video;
- pipe-output = far_end;
- }
+ ret = isp_video_get_graph_data(video, pipe, state);
+ if (ret 0)
+ goto err_check_format;
/* Validate the pipeline and update its state. */
ret = isp_video_validate_pipeline(pipe);
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h
index d91bdb91..c9187cb 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++ b/drivers/media/video/omap3isp/ispvideo.h
@@ -88,6 +88,7 @@ enum isp_pipeline_state {
/*
* struct isp_pipeline - An ISP hardware pipeline
* @error: A hardware error occurred during capture
+ * @entities: Bitmask of entities in the pipeline (indexed by entity ID)
*/
struct isp_pipeline {
struct media_pipeline pipe;
@@ -96,6 +97,7 @@ struct isp_pipeline {
enum isp_pipeline_stream_state stream_state;
struct isp_video *input;
struct isp_video *output;
+ u32 entities;
unsigned long l3_ick;
unsigned int max_rate;
atomic_t frame_number;
--
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: Technotrend TT-Connect CT 3650 and dvb_ca
On Mar 7, 2012, at 5:23 PM, Martin MAURER wrote: Hi Johan, I have a similar problem which happens every few days with this card. For me it helps to remove and reinsert the kernel module whenever this happens. rmmod -f dvb_usb_ttusb2 modprobe dvb_usb_ttusb2 Thanks a lot, Martin ! My challenge is that it happens every time i try to watch an encrypted channel :-( Best, Johan-- 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 v5 27/35] omap3isp: Introduce isp_video_check_external_subdevs()
Hi Laurent,
Thanks for the comments!
On Wed, Mar 07, 2012 at 11:43:31AM +0100, Laurent Pinchart wrote:
On Tuesday 06 March 2012 18:33:08 Sakari Ailus wrote:
isp_video_check_external_subdevs() will retrieve external subdev's
bits-per-pixel and pixel rate for the use of other ISP subdevs at streamon
time. isp_video_check_external_subdevs() is called after pipeline
validation.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index 4bc9cca..ef5c770 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -934,6 +934,77 @@ isp_video_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *b) file-f_flags O_NONBLOCK);
}
+static int isp_video_check_external_subdevs(struct isp_pipeline *pipe)
+{
+ struct isp_device *isp =
+ container_of(pipe, struct isp_video, pipe)-isp;
Any reason not to pass isp_device * from the caller to this function ?
I didn't simply because it was unnecessary. Should I? pipe is needed in
any case.
+ struct media_entity *ents[] = {
+ isp-isp_csi2a.subdev.entity,
+ isp-isp_csi2c.subdev.entity,
+ isp-isp_ccp2.subdev.entity,
+ isp-isp_ccdc.subdev.entity
+ };
+ struct media_pad *source_pad;
+ struct media_entity *source = NULL;
+ struct media_entity *sink;
+ struct v4l2_subdev_format fmt;
+ struct v4l2_ext_controls ctrls;
+ struct v4l2_ext_control ctrl;
+ int i;
i is allowed to be unsigned in this driver as well ;-)
unsigned... we meet again!
+ int ret = 0;
+
+ for (i = 0; i ARRAY_SIZE(ents); i++) {
+ /* Is the entity part of the pipeline? */
+ if (!(pipe-entities (1 ents[i]-id)))
+ continue;
+
+ /* ISP entities have always sink pad == 0. Find source. */
+ source_pad = media_entity_remote_source(ents[i]-pads[0]);
+
Don't you usually avoid blank lines between a variable assignment and
checking
it for an error condition ?
We do. Fixed.
+ if (source_pad == NULL)
+ continue;
+
+ source = source_pad-entity;
+ sink = ents[i];
+ break;
+ }
+
+ if (!source || media_entity_type(source) != MEDIA_ENT_T_V4L2_SUBDEV)
+ return 0;
+
+ pipe-external = media_entity_to_v4l2_subdev(source);
+
+ fmt.pad = source_pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(media_entity_to_v4l2_subdev(sink),
+ pad, get_fmt, NULL, fmt);
+ BUG_ON(ret 0);
That's a bit harsh. I'd rather return an error.
This is a driver BUG(). At the very least it's WARN() and return an error...
I think I'll do dev_warn(message) and return the error.
I actually add the same for the case where source is NULL --- that's also a
driver bug.
+
+ pipe-external_bpp = omap3isp_video_format_info(
+ fmt.format.code)-bpp;
Maybe you could teachs emacs that 78 characters fit in a 80-columns line ? :-)
That's 79, not 78. And I need to scroll to the end of the line you wrote to
see it after it has been prefixed with . :-D
I think I've been renaming things and as a result it did fit on a single
line.
+
+ memset(ctrls, 0, sizeof(ctrls));
+ memset(ctrl, 0, sizeof(ctrl));
+
+ ctrl.id = V4L2_CID_PIXEL_RATE;
+
+ ctrls.ctrl_class = V4L2_CTRL_ID2CLASS(ctrl.id);
You can leave ctrl_class to 0.
Fixed.
+ ctrls.count = 1;
+ ctrls.controls = ctrl;
+
+ ret = v4l2_g_ext_ctrls(pipe-external-ctrl_handler, ctrls);
+ if (ret 0) {
+ dev_warn(isp-dev,
+no pixel rate control in subdev %s\n,
No need to split this either.
Fixed.
Kind regards,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 28/35] omap3isp: Use external rate instead of vpcfg
On Wed, Mar 07, 2012 at 11:53:19AM +0100, Laurent Pinchart wrote: Hi Sakari, Thanks for the patch. On Tuesday 06 March 2012 18:33:09 Sakari Ailus wrote: From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Access pipe-external_rate instead of isp_ccdc.vpcfg.pixelclk. Also remove means to set the value for isp_ccdc_vpcfg.pixelclk. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Very nice. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This also means that implementing support for the V4L2_CID_PIXEL_RATE control is required in the sensor drivers to be used with the OMAP3 ISP. I'll submit patches. Thanks! Let's see how we deal with the affected drivers... -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 30/35] omap3isp: Move CCDC link validation to ccdc_link_validate()
Hi Laurent,
Thanks for the comments.
On Wed, Mar 07, 2012 at 12:00:48PM +0100, Laurent Pinchart wrote:
On Tuesday 06 March 2012 18:33:11 Sakari Ailus wrote:
Perform CCDC link validation in ccdc_link_validate() instead of
isp_video_validate_pipeline(). Also perform maximum data rate check in
isp_video_check_external_subdevs().
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
[snip]
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index 6d4ad87..51075b3 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
[snip]
@@ -950,6 +867,7 @@ static int isp_video_check_external_subdevs(struct
isp_pipeline *pipe) struct v4l2_subdev_format fmt;
struct v4l2_ext_controls ctrls;
struct v4l2_ext_control ctrl;
+ unsigned int rate = UINT_MAX;
You can move this variable inside the if statement below.
Fixed.
int i;
int ret = 0;
@@ -1002,6 +920,16 @@ static int isp_video_check_external_subdevs(struct
isp_pipeline *pipe)
pipe-external_rate = ctrl.value64;
+ if (pipe-entities (1 isp-isp_ccdc.subdev.entity.id)) {
+ /*
+* Check that maximum allowed CCDC pixel rate isn't
+* exceeded by the pixel rate.
What's wrong with 80 columns, really ? :-)
Is it said somewhere in CodingStyle the comments have to be wrapped at 80
characters and no earlier? It's like speed limits: you are allowed to drive
slower than the limit. :-)
+*/
+ omap3isp_ccdc_max_rate(isp-isp_ccdc, rate);
+ if (pipe-external_rate rate)
+ return -ENOSPC;
+ }
+
return 0;
}
Pending those two changes,
Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com
Thanks. :-)
Cheers,
--
Sakari Ailus
e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 33/35] omap3isp: Find source pad from external entity
Hi Laurent, Thanks for the review!! On Wed, Mar 07, 2012 at 12:04:01PM +0100, Laurent Pinchart wrote: On Tuesday 06 March 2012 18:33:14 Sakari Ailus wrote: No longer assume pad number 0 is the source pad of the external entity. Find the source pad from the external entity and use it instead. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com (with one comment below) --- drivers/media/video/omap3isp/isp.c | 13 - 1 files changed, 12 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/omap3isp/isp.c b/drivers/media/video/omap3isp/isp.c index f54953d..0718b0a 100644 --- a/drivers/media/video/omap3isp/isp.c +++ b/drivers/media/video/omap3isp/isp.c @@ -1744,6 +1744,7 @@ static int isp_register_entities(struct isp_device *isp) struct media_entity *input; unsigned int flags; unsigned int pad; + unsigned int i; sensor = isp_register_subdev_group(isp, subdevs-subdevs); if (sensor == NULL) @@ -1791,7 +1792,17 @@ static int isp_register_entities(struct isp_device *isp) goto done; } - ret = media_entity_create_link(sensor-entity, 0, input, pad, + for (i = 0; i sensor-entity.num_pads; i++) + if (sensor-entity.pads[i].flags MEDIA_PAD_FL_SOURCE) + break; While not strictly needed, I find the code easier to read with brackets for the for statement. It's up to you though. Brackets added. -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 09/35] v4l: Add subdev selections documentation
Hi Michael, Thanks for the comments. On Wed, Mar 07, 2012 at 09:53:42AM +0100, Michael Jones wrote: Hi Sakari, Hopefully it's not too late to make a few minor suggestions. On 03/06/2012 05:32 PM, Sakari Ailus wrote: Add documentation for V4L2 subdev selection API. This changes also experimental V4L2 subdev API so that scaling now works through selection API only. Signed-off-by: Sakari Ailussakari.ai...@iki.fi [snip] + +paraOn sink pads, cropping is applied relatively to the s/relatively/relative/ + current pad format. The pad format represents the image size as + received by the sub-device from the previous block in the + pipeline, and the crop rectangle represents the sub-image that + will be transmitted further inside the sub-device for + processing./para [snip] +paraOn source pads, cropping is similar to sink pads, with the + exception that the source size from which the cropping is + performed, is the COMPOSE rectangle on the sink pad. In both + sink and source pads, the crop rectangle must be entirely + containted inside the source image size for the crop s/containted/contained/ + operation./para + +paraThe drivers should always use the closest possible + rectangle the user requests on all selection targets, unless + specificly told otherwise. s/specificly/specifically/ +constantV4L2_SUBDEV_SEL_FLAG_SIZE_GE/constant and +constantV4L2_SUBDEV_SEL_FLAG_SIZE_LE/constant flags may be + used to round the image size either up or down.xref + linkend=v4l2-subdev-selection-flags/xref/para +/section [snip] +constantV4L2_SUBDEV_SEL_FLAG_KEEP_CONFIG/constant flag. This + flag causes that no propagation of the changes are allowed in + any circumstances. This may also cause the accessed rectangle to This flag causes that sounds ungrammatical. I suggest: This flag causes no propagation of the changes to be allowed under any circumstances. Applied all of them. Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH v5.1 27/35] omap3isp: Introduce isp_video_check_external_subdevs()
isp_video_check_external_subdevs() will retrieve external subdev's
bits-per-pixel and pixel rate for the use of other ISP subdevs at streamon
time. isp_video_check_external_subdevs() is called after pipeline
validation.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 79 +++
1 files changed, 79 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c
index 7411076..f3b82cae4 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -951,6 +951,81 @@ isp_video_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *b)
file-f_flags O_NONBLOCK);
}
+static int isp_video_check_external_subdevs(struct isp_pipeline *pipe)
+{
+ struct isp_device *isp =
+ container_of(pipe, struct isp_video, pipe)-isp;
+ struct media_entity *ents[] = {
+ isp-isp_csi2a.subdev.entity,
+ isp-isp_csi2c.subdev.entity,
+ isp-isp_ccp2.subdev.entity,
+ isp-isp_ccdc.subdev.entity
+ };
+ struct media_pad *source_pad;
+ struct media_entity *source = NULL;
+ struct media_entity *sink;
+ struct v4l2_subdev_format fmt;
+ struct v4l2_ext_controls ctrls;
+ struct v4l2_ext_control ctrl;
+ unsigned int i;
+ int ret = 0;
+
+ for (i = 0; i ARRAY_SIZE(ents); i++) {
+ /* Is the entity part of the pipeline? */
+ if (!(pipe-entities (1 ents[i]-id)))
+ continue;
+
+ /* ISP entities have always sink pad == 0. Find source. */
+ source_pad = media_entity_remote_source(ents[i]-pads[0]);
+ if (source_pad == NULL)
+ continue;
+
+ source = source_pad-entity;
+ sink = ents[i];
+ break;
+ }
+
+ if (!source) {
+ dev_warn(isp-dev, can't find source, failing now\n);
+ return ret;
+ }
+
+ if (media_entity_type(source) != MEDIA_ENT_T_V4L2_SUBDEV)
+ return 0;
+
+ pipe-external = media_entity_to_v4l2_subdev(source);
+
+ fmt.pad = source_pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(media_entity_to_v4l2_subdev(sink),
+ pad, get_fmt, NULL, fmt);
+ if (unlikely(ret 0)) {
+ dev_warn(isp-dev, get_fmt returned null!\n);
+ return ret;
+ }
+
+ pipe-external_bpp = omap3isp_video_format_info(fmt.format.code)-bpp;
+
+ memset(ctrls, 0, sizeof(ctrls));
+ memset(ctrl, 0, sizeof(ctrl));
+
+ ctrl.id = V4L2_CID_PIXEL_RATE;
+
+ ctrls.count = 1;
+ ctrls.controls = ctrl;
+
+ ret = v4l2_g_ext_ctrls(pipe-external-ctrl_handler, ctrls);
+ if (ret 0) {
+ dev_warn(isp-dev, no pixel rate control in subdev %s\n,
+pipe-external-name);
+ return ret;
+ }
+
+ pipe-external_rate = ctrl.value64;
+
+ return 0;
+}
+
/*
* Stream management
*
@@ -1033,6 +1108,10 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type)
if (ret 0)
goto err_check_format;
+ ret = isp_video_check_external_subdevs(pipe);
+ if (ret 0)
+ goto err_check_format;
+
/* Validate the pipeline and update its state. */
ret = isp_video_validate_pipeline(pipe);
if (ret 0)
--
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: [PATCH v5 28/35] omap3isp: Use external rate instead of vpcfg
On Wed, Mar 07, 2012 at 11:53:19AM +0100, Laurent Pinchart wrote: Hi Sakari, Thanks for the patch. On Tuesday 06 March 2012 18:33:09 Sakari Ailus wrote: From: Sakari Ailus sakari.ai...@maxwell.research.nokia.com Access pipe-external_rate instead of isp_ccdc.vpcfg.pixelclk. Also remove means to set the value for isp_ccdc_vpcfg.pixelclk. Signed-off-by: Sakari Ailus sakari.ai...@iki.fi Very nice. Acked-by: Laurent Pinchart laurent.pinch...@ideasonboard.com This also means that implementing support for the V4L2_CID_PIXEL_RATE control is required in the sensor drivers to be used with the OMAP3 ISP. I'll submit patches. My tree is here if you wish to try it: URL:http://git.linuxtv.org/sailus/media_tree.git/shortlog/refs/heads/media-for-3.4 Cheers, -- Sakari Ailus e-mail: sakari.ai...@iki.fi jabber/XMPP/Gmail: sai...@retiisi.org.uk -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v5 27/35] omap3isp: Introduce isp_video_check_external_subdevs()
Hi Sakari,
On Wednesday 07 March 2012 19:49:46 Sakari Ailus wrote:
On Wed, Mar 07, 2012 at 11:43:31AM +0100, Laurent Pinchart wrote:
On Tuesday 06 March 2012 18:33:08 Sakari Ailus wrote:
isp_video_check_external_subdevs() will retrieve external subdev's
bits-per-pixel and pixel rate for the use of other ISP subdevs at
streamon
time. isp_video_check_external_subdevs() is called after pipeline
validation.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index 4bc9cca..ef5c770 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -934,6 +934,77 @@ isp_video_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *b) file-f_flags O_NONBLOCK);
}
+static int isp_video_check_external_subdevs(struct isp_pipeline *pipe)
+{
+ struct isp_device *isp =
+ container_of(pipe, struct isp_video, pipe)-isp;
Any reason not to pass isp_device * from the caller to this function ?
I didn't simply because it was unnecessary. Should I? pipe is needed in
any case.
It will look simpler (in my opinion), and will probably generate less code, so
I think you should.
+ struct media_entity *ents[] = {
+ isp-isp_csi2a.subdev.entity,
+ isp-isp_csi2c.subdev.entity,
+ isp-isp_ccp2.subdev.entity,
+ isp-isp_ccdc.subdev.entity
+ };
+ struct media_pad *source_pad;
+ struct media_entity *source = NULL;
+ struct media_entity *sink;
+ struct v4l2_subdev_format fmt;
+ struct v4l2_ext_controls ctrls;
+ struct v4l2_ext_control ctrl;
+ int i;
i is allowed to be unsigned in this driver as well ;-)
unsigned... we meet again!
+ int ret = 0;
+
+ for (i = 0; i ARRAY_SIZE(ents); i++) {
+ /* Is the entity part of the pipeline? */
+ if (!(pipe-entities (1 ents[i]-id)))
+ continue;
+
+ /* ISP entities have always sink pad == 0. Find source. */
+ source_pad = media_entity_remote_source(ents[i]-pads[0]);
+
Don't you usually avoid blank lines between a variable assignment and
checking it for an error condition ?
We do. Fixed.
+ if (source_pad == NULL)
+ continue;
+
+ source = source_pad-entity;
+ sink = ents[i];
+ break;
+ }
+
+ if (!source || media_entity_type(source) != MEDIA_ENT_T_V4L2_SUBDEV)
+ return 0;
+
+ pipe-external = media_entity_to_v4l2_subdev(source);
+
+ fmt.pad = source_pad-index;
+ fmt.which = V4L2_SUBDEV_FORMAT_ACTIVE;
+ ret = v4l2_subdev_call(media_entity_to_v4l2_subdev(sink),
+pad, get_fmt, NULL, fmt);
+ BUG_ON(ret 0);
That's a bit harsh. I'd rather return an error.
This is a driver BUG(). At the very least it's WARN() and return an error...
I think I'll do dev_warn(message) and return the error.
dev_warn + return error sounds good.
I actually add the same for the case where source is NULL --- that's also a
driver bug.
+
+ pipe-external_bpp = omap3isp_video_format_info(
+ fmt.format.code)-bpp;
Maybe you could teachs emacs that 78 characters fit in a 80-columns line ?
:-)
That's 79, not 78. And I need to scroll to the end of the line you wrote to
see it after it has been prefixed with . :-D
I think I've been renaming things and as a result it did fit on a single
line.
+
+ memset(ctrls, 0, sizeof(ctrls));
+ memset(ctrl, 0, sizeof(ctrl));
+
+ ctrl.id = V4L2_CID_PIXEL_RATE;
+
+ ctrls.ctrl_class = V4L2_CTRL_ID2CLASS(ctrl.id);
You can leave ctrl_class to 0.
Fixed.
+ ctrls.count = 1;
+ ctrls.controls = ctrl;
+
+ ret = v4l2_g_ext_ctrls(pipe-external-ctrl_handler, ctrls);
+ if (ret 0) {
+ dev_warn(isp-dev,
+ no pixel rate control in subdev %s\n,
No need to split this either.
Fixed.
--
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
cron job: media_tree daily build: WARNINGS
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:Wed Mar 7 19:00:19 CET 2012 git hash:e8ca6d20a65d9d94693a0ed99b12d95b882dc859 gcc version: i686-linux-gcc (GCC) 4.6.2 host hardware:x86_64 host os: 3.1-2.slh.1-amd64 linux-git-arm-eabi-enoxys: WARNINGS linux-git-arm-eabi-omap: WARNINGS linux-git-armv5-ixp: WARNINGS 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-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-rc1-i686: 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-rc1-x86_64: WARNINGS apps: WARNINGS spec-git: WARNINGS sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.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: [PATCH] Add CI support to az6007 driver
Jose Alberto Reguero skrev 2012-03-06 00:23: On Lunes, 5 de marzo de 2012 21:42:48 Roger Mårtensson escribió: No. I tested the patch with DVB-T an watch encrypted channels with vdr without problems. I don't know why you can't. I don't know gnutv. Try with other software if you want. I have done some more testing and it works.. Sort of. :-) First let me walk through the dmesg. First I reinsert the CAM-card: Mar 7 20:12:36 tvpc kernel: [ 959.717666] dvb_ca adapter 2: DVB CAM detected and initialised successfully The next lines are when I start Kaffeine. Kaffeine gets a lock on the encrypted channel and starts viewing it. Mar 7 20:13:02 tvpc kernel: [ 986.359195] mt2063: detected a mt2063 B3 Mar 7 20:13:03 tvpc kernel: [ 987.368964] drxk: SCU_RESULT_INVPAR while sending cmd 0x0203 with params: Mar 7 20:13:03 tvpc kernel: [ 987.368974] drxk: 02 00 00 00 10 00 05 00 03 02.. Mar 7 20:13:06 tvpc kernel: [ 990.286628] dvb_ca adapter 2: DVB CAM detected and initialised successfully And now my sort of-comment. When I change the to another encrypted channel in kaffeine I get nothing. To be able to view this channel I need to restart kaffeine. The only thing that seems different in the logs are that when restarting kaffeine I get the CAM detected and initialised but when changing channels I do not get that line. Maybe there should be another reinit of the CAM somewhere? (just a guess) -- 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] [media] dib0700: unlock mutexes on error paths
dib0700_i2c_xfer [_new and _legacy] leave i2c_mutex locked on error paths.
The patch adds appropriate unlocks.
Found by Linux Driver Verification project (linuxtesting.org).
Signed-off-by: Alexey Khoroshilov khoroshi...@ispras.ru
---
drivers/media/dvb/dvb-usb/dib0700_core.c |9 ++---
1 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/dib0700_core.c
b/drivers/media/dvb/dvb-usb/dib0700_core.c
index 070e82a..8ec22c4 100644
--- a/drivers/media/dvb/dvb-usb/dib0700_core.c
+++ b/drivers/media/dvb/dvb-usb/dib0700_core.c
@@ -228,7 +228,7 @@ static int dib0700_i2c_xfer_new(struct i2c_adapter *adap,
struct i2c_msg *msg,
/* Write request */
if (mutex_lock_interruptible(d-usb_mutex) 0) {
err(could not acquire lock);
- return 0;
+ break;
}
st-buf[0] = REQUEST_NEW_I2C_WRITE;
st-buf[1] = msg[i].addr 1;
@@ -270,11 +270,14 @@ static int dib0700_i2c_xfer_legacy(struct i2c_adapter
*adap,
struct dib0700_state *st = d-priv;
int i,len;
- if (mutex_lock_interruptible(d-i2c_mutex) 0)
+ if (mutex_lock_interruptible(d-i2c_mutex) 0) {
+ err(could not acquire lock);
return -EAGAIN;
+ }
if (mutex_lock_interruptible(d-usb_mutex) 0) {
+ mutex_unlock(d-i2c_mutex);
err(could not acquire lock);
- return 0;
+ return -EAGAIN;
}
for (i = 0; i num; i++) {
--
1.7.4.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: [PATCH 3.0.y 0/4] Re: lirc_serial spuriously claims assigned port and irq to be in use
On Fri, Mar 02, 2012 at 02:39:13PM -0600, Jonathan Nieder wrote: Ben Hutchings wrote: On Thu, 2012-03-01 at 21:45 -0600, Jonathan Nieder wrote: Would some of these patches (e.g., at least patches 1, 2, and 5) be appropriate for inclusion in the 3.0.y and 3.2.y stable kernels from kernel.org? Assuming they haven't caused any regressions, I think everything except 9b98d6067971 (4/5) would be appropriate. Great. Here are the aforementioned patches rebased against 3.0.y, in the hope that some interested person can confirm they still work. The only backporting needed was to adjust to the lack of drivers/staging/lirc - drivers/staging/media/lirc renaming. So they should also go to 3.2-stable, right? greg k-h -- 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 3.0.y 0/4] Re: lirc_serial spuriously claims assigned port and irq to be in use
Greg Kroah-Hartman wrote: On Fri, Mar 02, 2012 at 02:39:13PM -0600, Jonathan Nieder wrote: Ben Hutchings wrote: On Thu, 2012-03-01 at 21:45 -0600, Jonathan Nieder wrote: Would some of these patches (e.g., at least patches 1, 2, and 5) be appropriate for inclusion in the 3.0.y and 3.2.y stable kernels from kernel.org? Assuming they haven't caused any regressions, I think everything except 9b98d6067971 (4/5) would be appropriate. Great. Here are the aforementioned patches rebased against 3.0.y, [...] So they should also go to 3.2-stable, right? Yes. Thanks, Jonathan -- 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: A second easycap driver implementation
Hi Mauro,
em28xx is a good reference.
I'm looking at it.
In fact, I have a first question: why there is a limit to the number of devices
the driver support? I found the same idea in easycap original
implementation, but I
can't understand why do we have to limit in such a way.
/* Check to see next free device and mark as used */
do {
nr = find_first_zero_bit(em28xx_devused, EM28XX_MAXBOARDS);
if (nr = EM28XX_MAXBOARDS) {
/* No free device slots */
printk(DRIVER_NAME : Supports only %i em28xx
boards.\n,
EM28XX_MAXBOARDS);
retval = -ENOMEM;
goto err_no_slot;
}
} while (test_and_set_bit(nr, em28xx_devused));
It is not clear, from the easycap code, where the I2C address
is stored:
int write_saa(struct usb_device *p, u16 reg0, u16 set0)
{
if (!p)
return -ENODEV;
SET(p, 0x200, 0x00);
SET(p, 0x204, reg0);
SET(p, 0x205, set0);
SET(p, 0x200, 0x01);
return wait_i2c(p);
}
I think i2c_address it is near registers 0x200/0x204, which gets
initialised at setup_stk().
I'll have a closer look.
Thanks for your comments,
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: A second easycap driver implementation
Em 07-03-2012 17:39, Ezequiel García escreveu:
Hi Mauro,
em28xx is a good reference.
I'm looking at it.
In fact, I have a first question: why there is a limit to the number of
devices
the driver support? I found the same idea in easycap original
implementation, but I
can't understand why do we have to limit in such a way.
/* Check to see next free device and mark as used */
do {
nr = find_first_zero_bit(em28xx_devused, EM28XX_MAXBOARDS);
if (nr = EM28XX_MAXBOARDS) {
/* No free device slots */
printk(DRIVER_NAME : Supports only %i em28xx
boards.\n,
EM28XX_MAXBOARDS);
retval = -ENOMEM;
goto err_no_slot;
}
} while (test_and_set_bit(nr, em28xx_devused));
There are several reasons for that, including a few historical ones. One of
them
is that the number of reserved v4l char devices is limited (well, V4L core
now supports dynamic allocation). Another one is a few modprobe arrays for
em28xx.
Anyway, an USB 2.0 bus only supports one uncompressed video stream.
It is not clear, from the easycap code, where the I2C address
is stored:
int write_saa(struct usb_device *p, u16 reg0, u16 set0)
{
if (!p)
return -ENODEV;
SET(p, 0x200, 0x00);
SET(p, 0x204, reg0);
SET(p, 0x205, set0);
SET(p, 0x200, 0x01);
return wait_i2c(p);
}
I think i2c_address it is near registers 0x200/0x204, which gets
initialised at setup_stk().
I'll have a closer look.
Ok.
Thanks for your comments,
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 3.0.y 0/4] Re: lirc_serial spuriously claims assigned port and irq to be in use
On Wed, Mar 07, 2012 at 12:04:07PM -0800, Greg Kroah-Hartman wrote: On Fri, Mar 02, 2012 at 02:39:13PM -0600, Jonathan Nieder wrote: Ben Hutchings wrote: On Thu, 2012-03-01 at 21:45 -0600, Jonathan Nieder wrote: Would some of these patches (e.g., at least patches 1, 2, and 5) be appropriate for inclusion in the 3.0.y and 3.2.y stable kernels from kernel.org? Assuming they haven't caused any regressions, I think everything except 9b98d6067971 (4/5) would be appropriate. Great. Here are the aforementioned patches rebased against 3.0.y, in the hope that some interested person can confirm they still work. The only backporting needed was to adjust to the lack of drivers/staging/lirc - drivers/staging/media/lirc renaming. So they should also go to 3.2-stable, right? Yes, only for 3.2 a simple cherry-pick should work. Ben. -- Ben Hutchings We get into the habit of living before acquiring the habit of thinking. - Albert Camus -- 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 3/3] wl128x: Add sysfs based support for FM features
On Mon, Mar 5, 2012 at 10:24 AM, halli manjunatha hallima...@gmail.com wrote: On Fri, Mar 2, 2012 at 3:22 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Wednesday, February 29, 2012 18:19:27 halli manjunatha wrote: On Wed, Feb 29, 2012 at 5:25 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Tuesday, February 28, 2012 23:52:21 halli manjunatha wrote: On Tue, Feb 28, 2012 at 4:05 AM, Hans Verkuil hverk...@xs4all.nl wrote: On Monday, February 27, 2012 17:29:18 halli manjunatha wrote: Hi Hans, Agreed I don't mind to create new controls for below things 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RDS AF turn ON/OFF 3) FM RX RSSI level set/get 4) FM TX Alternate Frequency set/get 5) FM RX De-Emphasis mode set/get However, previously you have suggested me to hide few controls (like band selection) from the user but few of our application wanted controls like above and that is why I have created the sysfs entries. Please suggest me how can I move forward with new controls or with sysfs? The first question is which of these controls are general to FM receivers or transmitters, and which are specific to this chipset. The chipset specific controls should be private controls (look at V4L2_CID_MPEG_CX2341X_BASE in videodev2.h how those are defined). The others should be defined as new controls of the FM_TX class or the FM_RX class. The FM_RX class should be defined as a new class as it doesn't exist at the moment. Don't forget to document these controls clearly. With regards to the band selection: I remember that there was a discussion, but not the details. Do you have a link to that discussion? I can't find it (at least not quickly :-) ). Below features are generic to all FM receivers so we can add new CID's for below features 1) FM RX RDS AF turn ON/OFF 2) FM TX Alternate Frequency set/get About other 3 features its different issue, 1) FM RX Band selection (US/Europe, Japan and Russian bands) 2) FM RX RSSI level set/get 3) FM RX De-Emphasis mode set/get All these 3 features are generic to any FM receiver, only question is does all FM receivers wants to expose these controls to application writer? Good question, and there is no good answer at the moment. See e.g. this IRC discussion: http://www.spinics.net/lists/linux-media/msg44023.html In the absence of a good solution to this problem I am inclined to make these controls driver specific but marked experimental. The experimental tag allows us to eventually make it a generic control without too much hassle. Agreed, I will make them driver specific and mark them as experimental. Example Band selection, every FM receiver at the minimum supports both Europe and Japan band, now the question is should we add a CID to switch between these two bands? If we decide to add a band selection control, then that would be a menu control (since there are up to three bands) and it would only be implemented by drivers that need it. What I am still not clear on is *why* you would want this control. What is the reason your customers want this? What does it allow you to do that can't be done today? There are 2 reasons for this, First, our chip supports weather band, unlike other bands (Europe, Japan and Russian) user may wants to switch to weather band and wants to listen to weather report and again switches back to normal band. OK, that makes sense. Are the RX and TX independent with regards to band selection? Yes - RX and TX are independent of band selection Make sure that when the band is changed the rangelow and rangehigh values are also changed. If the current frequency is out of that range, then the frequency should be clamped to the closest value frequency. Although an alternative strategy might be to remember the last used frequency for each band. That might make more sense in the case of switching between a normal band and the weather band. We need to define and document which strategy should be used here. As of now when I switch to new band I just set the frequency to lowest of the new band. In this way user can seek and tune to what ever channel he wants. Hans, Which implementation you wants? start with the lowest of the new band or closer to the frequency of old band? do we need to remember the present frequency of the band before switching to new band? Please let me know your views. Since this feature is required by all FM receivers shall I make this as a generic CID? BTW, is the receiver for the weather band implemented as a separate receiver? I read that some devices can listen to the normal band and interrupt that when a weather report is broadcast on the weather band. That implies two receivers and it would require a rethink. Also, is this feature really implemented as separate frequency ranges in
[PATCH 1/4] lmedm04 v1.98 Remove clear halt
These were in the original lme2510 device driver. Removing them significantly speeds up the driver. All tuners tested. Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- drivers/media/dvb/dvb-usb/lmedm04.c |6 +- 1 files changed, 1 insertions(+), 5 deletions(-) diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c b/drivers/media/dvb/dvb-usb/lmedm04.c index 3e6ed28..a251583 100644 --- a/drivers/media/dvb/dvb-usb/lmedm04.c +++ b/drivers/media/dvb/dvb-usb/lmedm04.c @@ -177,12 +177,8 @@ static int lme2510_usb_talk(struct dvb_usb_device *d, /* the read/write capped at 64 */ memcpy(buff, wbuf, (wlen 64) ? wlen : 64); - ret |= usb_clear_halt(d-udev, usb_sndbulkpipe(d-udev, 0x01)); - ret |= lme2510_bulk_write(d-udev, buff, wlen , 0x01); - ret |= usb_clear_halt(d-udev, usb_rcvbulkpipe(d-udev, 0x01)); - ret |= lme2510_bulk_read(d-udev, buff, (rlen 64) ? rlen : 64 , 0x01); @@ -1290,5 +1286,5 @@ module_usb_driver(lme2510_driver); MODULE_AUTHOR(Malcolm Priestley tvbox...@gmail.com); MODULE_DESCRIPTION(LME2510(C) DVB-S USB2.0); -MODULE_VERSION(1.97); +MODULE_VERSION(1.98); MODULE_LICENSE(GPL); -- 1.7.9 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] lmedm04 ver 1.99 support for m88rs2000 v2
Support for m88rs2000 module.
The driver also attempts to overcome occasional lock problems.
Call backs are now used for read_status, signal level and SNR.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/dvb-usb/lmedm04.c | 274 +--
drivers/media/dvb/dvb-usb/lmedm04.h |1 +
2 files changed, 197 insertions(+), 78 deletions(-)
diff --git a/drivers/media/dvb/dvb-usb/lmedm04.c
b/drivers/media/dvb/dvb-usb/lmedm04.c
index a251583..5dde06d 100644
--- a/drivers/media/dvb/dvb-usb/lmedm04.c
+++ b/drivers/media/dvb/dvb-usb/lmedm04.c
@@ -77,6 +77,7 @@
#include stv0299.h
#include dvb-pll.h
#include z0194a.h
+#include m88rs2000.h
@@ -106,12 +107,14 @@ static int pid_filter;
module_param_named(pid, pid_filter, int, 0644);
MODULE_PARM_DESC(pid, set default 0=default 1=off 2=on);
+
DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
#define TUNER_DEFAULT 0x0
#define TUNER_LG 0x1
#define TUNER_S73950x2
#define TUNER_S01940x3
+#define TUNER_RS2000 0x4
struct lme2510_state {
u8 id;
@@ -120,6 +123,8 @@ struct lme2510_state {
u8 signal_level;
u8 signal_sn;
u8 time_key;
+ u8 last_key;
+ u8 key_timeout;
u8 i2c_talk_onoff;
u8 i2c_gate;
u8 i2c_tuner_gate_w;
@@ -127,6 +132,7 @@ struct lme2510_state {
u8 i2c_tuner_addr;
u8 stream_on;
u8 pid_size;
+ u8 pid_off;
void *buffer;
struct urb *lme_urb;
void *usb_buffer;
@@ -192,9 +198,14 @@ static int lme2510_usb_talk(struct dvb_usb_device *d,
static int lme2510_stream_restart(struct dvb_usb_device *d)
{
- static u8 stream_on[] = LME_ST_ON_W;
+ struct lme2510_state *st = d-priv;
+ u8 all_pids[] = LME_ALL_PIDS;
+ u8 stream_on[] = LME_ST_ON_W;
int ret;
- u8 rbuff[10];
+ u8 rbuff[1];
+ if (st-pid_off)
+ ret = lme2510_usb_talk(d, all_pids, sizeof(all_pids),
+ rbuff, sizeof(rbuff));
/*Restart Stream Command*/
ret = lme2510_usb_talk(d, stream_on, sizeof(stream_on),
rbuff, sizeof(rbuff));
@@ -301,6 +312,14 @@ static void lme2510_int_response(struct urb *lme_urb)
((ibuf[2] 0x01) 0x03);
}
break;
+ case TUNER_RS2000:
+ if (ibuf[2] 0)
+ st-signal_lock = 0xff;
+ else
+ st-signal_lock = 0xf0;
+ st-signal_level = ibuf[4];
+ st-signal_sn = ibuf[5];
+ st-time_key = ibuf[7];
default:
break;
}
@@ -352,19 +371,20 @@ static int lme2510_int_read(struct dvb_usb_adapter *adap)
static int lme2510_pid_filter_ctrl(struct dvb_usb_adapter *adap, int onoff)
{
struct lme2510_state *st = adap-dev-priv;
- static u8 clear_pid_reg[] = LME_CLEAR_PID;
+ static u8 clear_pid_reg[] = LME_ALL_PIDS;
static u8 rbuf[1];
int ret;
deb_info(1, PID Clearing Filter);
- ret = mutex_lock_interruptible(adap-dev-i2c_mutex);
- if (ret 0)
- return -EAGAIN;
+ mutex_lock(adap-dev-i2c_mutex);
- if (!onoff)
+ if (!onoff) {
ret |= lme2510_usb_talk(adap-dev, clear_pid_reg,
sizeof(clear_pid_reg), rbuf, sizeof(rbuf));
+ st-pid_off = true;
+ } else
+ st-pid_off = false;
st-pid_size = 0;
@@ -382,11 +402,9 @@ static int lme2510_pid_filter(struct dvb_usb_adapter
*adap, int index, u16 pid,
pid, index, onoff);
if (onoff) {
- ret = mutex_lock_interruptible(adap-dev-i2c_mutex);
- if (ret 0)
- return -EAGAIN;
- ret |= lme2510_enable_pid(adap-dev, index, pid);
- mutex_unlock(adap-dev-i2c_mutex);
+ mutex_lock(adap-dev-i2c_mutex);
+ ret |= lme2510_enable_pid(adap-dev, index, pid);
+ mutex_unlock(adap-dev-i2c_mutex);
}
@@ -418,9 +436,6 @@ static int lme2510_msg(struct dvb_usb_device *d,
int ret = 0;
struct lme2510_state *st = d-priv;
- if (mutex_lock_interruptible(d-i2c_mutex) 0)
- return -EAGAIN;
-
if (st-i2c_talk_onoff == 1) {
ret = lme2510_usb_talk(d, wbuf, wlen, rbuf, rlen);
@@ -463,10 +478,12 @@ static int lme2510_msg(struct dvb_usb_device *d,
}
}
break;
+ case TUNER_RS2000:
default:
break;
[PATCH 3/4] m88rs2000 1.12 v2 DVB-S frontend and tuner module.
Support for m88rs2000 chip used in lmedm04 driver.
Note there are still lock problems.
Slow channel change due to the large block of registers sent in set_frontend.
Version 2 differences.
Front end is completely shut down when in sleep mode. This allow user to regain
control of device.
Kaffeine scan problem solved by removing register calls from get_frontend.
Kaffeine seems to call get_frontend when updating signal data. This can happen
in the middle of a tune stalling the driver.
Change calculations to those in the DS3000 driver.
Signed-off-by: Malcolm Priestley tvbox...@gmail.com
---
drivers/media/dvb/frontends/Kconfig |7 +
drivers/media/dvb/frontends/Makefile|1 +
drivers/media/dvb/frontends/m88rs2000.c | 906 +++
drivers/media/dvb/frontends/m88rs2000.h | 66 +++
4 files changed, 980 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/dvb/frontends/m88rs2000.c
create mode 100644 drivers/media/dvb/frontends/m88rs2000.h
diff --git a/drivers/media/dvb/frontends/Kconfig
b/drivers/media/dvb/frontends/Kconfig
index 2995204..2124670 100644
--- a/drivers/media/dvb/frontends/Kconfig
+++ b/drivers/media/dvb/frontends/Kconfig
@@ -705,6 +705,14 @@ config DVB_IT913X_FE
A DVB-T tuner module.
Say Y when you want to support this frontend.
+config DVB_M88RS2000
+ tristate M88RS2000 DVB-S demodulator and tuner
+ depends on DVB_CORE I2C
+ default m if DVB_FE_CUSTOMISE
+ help
+ A DVB-S tuner module.
+ Say Y when you want to support this frontend.
+
comment Tools to develop new frontends
config DVB_DUMMY_FE
diff --git a/drivers/media/dvb/frontends/Makefile
b/drivers/media/dvb/frontends/Makefile
index 7f85e64..03cefb3 100644
--- a/drivers/media/dvb/frontends/Makefile
+++ b/drivers/media/dvb/frontends/Makefile
@@ -97,4 +97,5 @@ obj-$(CONFIG_DVB_IT913X_FE) += it913x-fe.o
obj-$(CONFIG_DVB_A8293) += a8293.o
obj-$(CONFIG_DVB_TDA10071) += tda10071.o
obj-$(CONFIG_DVB_RTL2830) += rtl2830.o
+obj-$(CONFIG_DVB_M88RS2000) += m88rs2000.o
diff --git a/drivers/media/dvb/frontends/m88rs2000.c
b/drivers/media/dvb/frontends/m88rs2000.c
new file mode 100644
index 000..ecafce5
--- /dev/null
+++ b/drivers/media/dvb/frontends/m88rs2000.c
@@ -0,0 +1,906 @@
+/*
+ Driver for M88RS2000 demodulator and tuner
+
+ Copyright (C) 2012 Malcolm Priestley (tvbox...@gmail.com)
+ Beta Driver
+
+ Include various calculation code from DS3000 driver.
+ Copyright (C) 2009 Konstantin Dimitrov.
+
+ 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; either version 2 of the License, or
+ (at your option) any later version.
+
+ 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+
+*/
+#include linux/init.h
+#include linux/module.h
+#include linux/device.h
+#include linux/jiffies.h
+#include linux/string.h
+#include linux/slab.h
+#include linux/types.h
+
+
+#include dvb_frontend.h
+#include m88rs2000.h
+
+struct m88rs2000_state {
+ struct i2c_adapter *i2c;
+ const struct m88rs2000_config *config;
+ struct dvb_frontend frontend;
+ u8 no_lock_count;
+ u32 tuner_frequency;
+ u32 symbol_rate;
+ fe_code_rate_t fec_inner;
+ u8 tuner_level;
+ int errmode;
+};
+
+static int m88rs2000_debug;
+
+module_param_named(debug, m88rs2000_debug, int, 0644);
+MODULE_PARM_DESC(debug, set debugging level (1=info (or-able)).);
+
+#define dprintk(level, args...) do { \
+ if (level m88rs2000_debug) \
+ printk(KERN_DEBUG m88rs2000-fe: args); \
+} while (0)
+
+#define deb_info(args...) dprintk(0x01, args)
+#define info(format, arg...) \
+ printk(KERN_INFO m88rs2000-fe: format \n , ## arg)
+
+static int m88rs2000_writereg(struct m88rs2000_state *state, u8 tuner,
+ u8 reg, u8 data)
+{
+ int ret;
+ u8 addr = (tuner == 0) ? state-config-tuner_addr :
+ state-config-demod_addr;
+ u8 buf[] = { reg, data };
+ struct i2c_msg msg = {
+ .addr = addr,
+ .flags = 0,
+ .buf = buf,
+ .len = 2
+ };
+
+ ret = i2c_transfer(state-i2c, msg, 1);
+
+ if (ret != 1)
+ deb_info(%s: writereg error (reg == 0x%02x, val == 0x%02x,
+ ret == %i)\n, __func__, reg, data, ret);
+
+ return (ret != 1) ? -EREMOTEIO : 0;
+}
+
+static int
[PATCH 4/4] lmedm04 RS2000 Firmware details
Signed-off-by: Malcolm Priestley tvbox...@gmail.com --- Documentation/dvb/lmedm04.txt | 11 +++ 1 files changed, 11 insertions(+), 0 deletions(-) diff --git a/Documentation/dvb/lmedm04.txt b/Documentation/dvb/lmedm04.txt index 10b5f04..f4b720a 100644 --- a/Documentation/dvb/lmedm04.txt +++ b/Documentation/dvb/lmedm04.txt @@ -66,5 +66,16 @@ dd if=US290D.sys ibs=1 skip=36856 count=3976 of=dvb-usb-lme2510-s0194.fw For LME2510C dd if=US290D.sys ibs=1 skip=33152 count=3697 of=dvb-usb-lme2510c-s0194.fw +- + +The m88rs2000 tuner driver can be found in windows/system32/drivers + +US2B0D.sys (dated 29 Jun 2010) + +dd if=US2B0D.sys ibs=1 skip=34432 count=3871 of=dvb-usb-lme2510c-rs2000.fw + +We need to modify id of rs2000 firmware or it will warm boot id 3344:1120. + +echo -ne \\xF0\\x22 | dd conv=notrunc bs=1 count=2 seek=266 of=dvb-usb-lme2510c-rs2000.fw Copy the firmware file(s) to /lib/firmware -- 1.7.9 -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] media: media-dev: Add media devices for EXYNOS5
Hi Sungchun, On 03/05/2012 11:53 AM, Sungchun Kang wrote: On 03/01/2012 07:44 AM, Sylwester Nawrocki wrote: On 02/15/2012 07:02 AM, Sungchun Kang wrote: Since the EXYNOS5 SoCs have various multimedia IPs such as Gscaler, FIMC-LITE, and MIXER, and so on. Additionally, media controller interface is needed to configure connection between them and to control each IPs. This patch adds support media device for EXYNOS5 SoCs. Actually, there are three media devices such as below diagram which are using media control framework. Since they are not belong to one hardware block, we need to manage it for connecting with each devices. Follwing is detailed list of them: * Gscaler: general scaler Support memory to memory interface Support output interface from memory to display device(LCD, TV) Support capture interface from device(FIMC-LITE, FIMD) to memory * MIPI-CSIS Support interconnection(subdev interface) between devices Is there any difference in s5p/exynos4 and exynos5 MIPI-CSIS devices ? I suspect there isn't and the existing MIPI-CSIS driver can be used for exynos5 too. It is same hardware, and driver is almost identical. But I copied from s5p-fimc directory to exynos directory, because we use media controller framework in each other hardware. - reference from my first mail I see, you register the subdevs in a bit different way. You're not justified to copy the code all around though :-) Code duplication in short term might look like a quick and easy solution, but it's more a recipe for disaster. Certainly there is no place for such in the mainline. Technically, supporting your sub-devices registration method in the s5p-csis module is rather trivial (thanks to that I've designed it as an independent driver), except that the initialization scheme you've adopted doesn't seem right to me. Do you have plans on how to instantiate your exynos5 media drivers, including sensor/video encoder subdevs, from the device tree ? I bet you'll find easier to do it in the case, where the media device driver coordinates (sub)devices' probing/initialization. Surely, you are author of mipi-csis driver in s5p-fimc directory and I re-used most of your code. So, I will not submit mipi-csis driver. But you need it, so we should agree on the directory/files layout and the kernel APIs to allow the common modules to be freely reused. I've seen patches for the other devices, like HDMI/TV out, JPEG, etc. They are basically extending the existing drivers/media/video/s5p-* drivers. I wonder, if we could do something similar with FIMC, e.g. rename drivers/media/video/s5p-fimc to drivers/media/video/fimc and implement there an uniform user interface for as many SoC revisions as possible ? Common headers would have been in include/media, and include/video if needed. What do you think ? * FIMC-LITE Support capture interface from device(Sensor, MIPI-CSIS) to memory Support interconnection(subdev interface) between devices This device is also present on exynos4212/4412 SoCs. Can you tell what's difference between FIMC-LITE on Exynos4 and Exynos5 ? Either we need separate FIMC-LITE drivers or we need a shared one. I'd like to clarify this first. * MIXER Support output interface from memory to device(HDMI) Support interconnection(subdev interface) between devices * FIMD Support framebuffer interface Support subdev interface to display frames sent from Gscaler What about Exynos DRM driver ? Do you have any plans to integrate the V4L2 and the DRM driver ? IMHO DRM is more appropriate for some tasks on display side, like 2D operations, multiple outputs, windows, blending, etc. I don't know about DRM, can you explain to me about it, or let me know mail-thread? I'm no expert in the DRM area, you might get better results contacting Mr. Inki Dae, Seung-Wo Kim or Joonyoung Shim directly. Please check this site for an ELCE presentation slides: http://elinux.org/ELCE_2011_Presentations_redirect#Table_of_Presentations (DRM Driver Development For Embedded Systems) * Rotator Support memory to memory interface * m2m-scaler Support only memory to memory interface * And so on... 1) media 0 LCD Output path consists of Gscaler and FIMD(display controller). ++ +--+ | Gscaler-output | -- | FIMD | -- LCD ++ +--+ HDMI Output path consists of Gscaler, Mixer and HDMI. ++ +---+ +--+ | Gscaler-output | -- | MIXER | -- | HDMI | -- TV ++ +---+ +--+ ++ +---+ +---+ +-+ 2) media 1 Camera Capture path consists of MIPI-CSIS, FIMC-LITE and Gscaler ++ +---+ +-+ | Sensor | -- | FIMC-LITE | -- | Gscaler-capture | ++ +---+ +-+
Re: [PATCH v5.1 25/35] omap3isp: Collect entities that are part of the pipeline
Hi Sakari,
Thanks for the patch.
On Wednesday 07 March 2012 19:22:56 Sakari Ailus wrote:
Collect entities which are part of the pipeline into a single bit mask.
Signed-off-by: Sakari Ailus sakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 48
--- drivers/media/video/omap3isp/ispvideo.h |
2 +
2 files changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index d34f690..7411076 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -255,8 +255,9 @@ isp_video_remote_subdev(struct isp_video *video, u32
*pad) }
/* Return a pointer to the ISP video instance at the far end of the
pipeline. */ -static struct isp_video *
-isp_video_far_end(struct isp_video *video)
+static int isp_video_get_graph_data(struct isp_video *video,
+ struct isp_pipeline *pipe,
+ enum isp_pipeline_state *state)
{
struct media_entity_graph graph;
struct media_entity *entity = video-video.entity;
@@ -267,6 +268,8 @@ isp_video_far_end(struct isp_video *video)
media_entity_graph_walk_start(graph, entity);
while ((entity = media_entity_graph_walk_next(graph))) {
+ pipe-entities |= 1 entity-id;
+
if (entity == video-video.entity)
continue;
The loop will stop as soon as it find a video node at the other end of the
pipeline. As media_entity_graph_walk_next() doesn't guarantee any graph search
order, you should avoid stopping the loop before having walked all entities,
otherwise you could miss some.
Something like
while ((entity = media_entity_graph_walk_next(graph))) {
struct isp_video *node;
pipe-entities |= 1 entity-id;
if (entity == video-video.entity)
continue;
if (media_entity_type(entity) != MEDIA_ENT_T_DEVNODE)
continue;
node = to_isp_video(media_entity_to_video_device(entity));
if (node-type != video-type)
far_end = node;
}
should do (feel free to rename node to something else, I have little
imagination so late at night).
@@ -281,7 +284,21 @@ isp_video_far_end(struct isp_video *video)
}
mutex_unlock(mdev-graph_mutex);
- return far_end;
+
+ if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
+ *state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
+ pipe-input = far_end;
+ pipe-output = video;
+ } else {
+ if (far_end == NULL)
+ return -EPIPE;
+
+ *state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
+ pipe-input = video;
+ pipe-output = far_end;
+ }
+
+ return 0;
}
/*
@@ -972,7 +989,6 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) struct isp_video *video = video_drvdata(file);
enum isp_pipeline_state state;
struct isp_pipeline *pipe;
- struct isp_video *far_end;
unsigned long flags;
int ret;
@@ -992,6 +1008,8 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) pipe = video-video.entity.pipe
? to_isp_pipeline(video-video.entity) : video-pipe;
+ pipe-entities = 0;
+
if (video-isp-pdata-set_constraints)
video-isp-pdata-set_constraints(video-isp, true);
pipe-l3_ick = clk_get_rate(video-isp-clock[ISP_CLK_L3_ICK]);
@@ -1011,25 +1029,9 @@ isp_video_streamon(struct file *file, void *fh, enum
v4l2_buf_type type) video-bpl_padding = ret;
video-bpl_value = vfh-format.fmt.pix.bytesperline;
- /* Find the ISP video node connected at the far end of the pipeline and
- * update the pipeline.
- */
- far_end = isp_video_far_end(video);
-
- if (video-type == V4L2_BUF_TYPE_VIDEO_CAPTURE) {
- state = ISP_PIPELINE_STREAM_OUTPUT | ISP_PIPELINE_IDLE_OUTPUT;
- pipe-input = far_end;
- pipe-output = video;
- } else {
- if (far_end == NULL) {
- ret = -EPIPE;
- goto err_check_format;
- }
-
- state = ISP_PIPELINE_STREAM_INPUT | ISP_PIPELINE_IDLE_INPUT;
- pipe-input = video;
- pipe-output = far_end;
- }
+ ret = isp_video_get_graph_data(video, pipe, state);
+ if (ret 0)
+ goto err_check_format;
/* Validate the pipeline and update its state. */
ret = isp_video_validate_pipeline(pipe);
diff --git a/drivers/media/video/omap3isp/ispvideo.h
b/drivers/media/video/omap3isp/ispvideo.h index d91bdb91..c9187cb 100644
--- a/drivers/media/video/omap3isp/ispvideo.h
+++
Re: [PATCH v5 27/35] omap3isp: Introduce isp_video_check_external_subdevs()
Hi Laurent,
Laurent Pinchart wrote:
On Wednesday 07 March 2012 19:49:46 Sakari Ailus wrote:
On Wed, Mar 07, 2012 at 11:43:31AM +0100, Laurent Pinchart wrote:
On Tuesday 06 March 2012 18:33:08 Sakari Ailus wrote:
isp_video_check_external_subdevs() will retrieve external subdev's
bits-per-pixel and pixel rate for the use of other ISP subdevs at
streamon
time. isp_video_check_external_subdevs() is called after pipeline
validation.
Signed-off-by: Sakari Ailussakari.ai...@iki.fi
---
drivers/media/video/omap3isp/ispvideo.c | 75
1 files changed, 75 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/omap3isp/ispvideo.c
b/drivers/media/video/omap3isp/ispvideo.c index 4bc9cca..ef5c770 100644
--- a/drivers/media/video/omap3isp/ispvideo.c
+++ b/drivers/media/video/omap3isp/ispvideo.c
@@ -934,6 +934,77 @@ isp_video_dqbuf(struct file *file, void *fh, struct
v4l2_buffer *b) file-f_flags O_NONBLOCK);
}
+static int isp_video_check_external_subdevs(struct isp_pipeline *pipe)
+{
+ struct isp_device *isp =
+ container_of(pipe, struct isp_video, pipe)-isp;
Any reason not to pass isp_device * from the caller to this function ?
I didn't simply because it was unnecessary. Should I? pipe is needed in
any case.
It will look simpler (in my opinion), and will probably generate less code, so
I think you should.
I'll change that for a new version tomorrow.
--
Sakari Ailus
sakari.ai...@iki.fi
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Theodore As to getting that kind of resolution out of a webcam, though, it would be a rather tough go due to the amount of data which has to pass over the wire even if it is compressed data. The frame rate would be pretty atrocious. Therefore, you are probably not going to see that kind of resolution in an inexpensive webcam, at least until USB 3 comes into common use. Thanks for offering your thoughts on this matter. It looks like I'll have to keep checking eBay for cheap USB v3 (HD) webcams periodically. For the record, I've only got Motion set to capture four frames per second at the moment. Perhaps for now if you want that kind of resolution and do not care about the frame rate very much, you would be better off to buy a slightly fancier camera and do something like using gphoto2 to take timed shots. I prefer the idea of captured motion to that of timed snapshots. The captured images and videos are automatically uploaded to my Dropbox account. As I'm only a 'free' user, I must limit the storage space that these files consume. -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
Hi Jean-Francois It seems that the webcams handled by the driver sn9c20x work the same as the ones handled by sonixj. In this last driver, I adjust the JPEG compression to avoid the errors USB FIFO full, and I think that these errors also raise the URB error -18 with the sn9c20x. I will need some time to put a same code into the sn9c20x, then I'd be glad to have it tested. There was an other problem in the driver sonixj: the end of frame marker was not always at the right place. Xavion, as you have ms-windows, may you do some USB traces with this system? I need a capture sequence of about 15 seconds (not more) with big luminosity changes. I've never needed to capture USB data manually until now, so I'm not sure of which (free) Windows application I should use. I'm assuming that a software-only analyser would be good enough to provide the information you're wanting. I'm guessing that continuously blocking and unblocking the webcam's vision will suffice for big luminosity changes. Let me know if that's not going to cut it and I'll repeatedly toggle the switch for the ceiling light in my lounge-room (at night) instead. I just tried to get the data using three different USB packet sniffers. The unfortunate results on my 32-bit Windows XP laptop are listed below. BTW, what size should the log-file have been after capturing the fifteen seconds you're wanting? * BusDog: Couldn't find the webcam device * SniffUSB: The log file was 100+ MiB in size * SnoopyPro: Couldn't capture any packets The sensor ov7660 can do VGA only (640x480). Otherwise, I uploaded a new gspca test version (2.15.3) with the JPEG compression control (default 80%). May you try it? I've downloaded and tested GSPCA v2.15.3. I'm sorry to nitpick, but you still had 2.15.1 listed near the top of the gspca.h file. I'm also sorry to report that GSPCA v2.15.3 caused the following fatal errors with my SN9C201 webcam: `-- tail /var/log/kernel.log Mar 8 10:21:09 Desktop kernel: [13758.712077] usb 1-5.5: new high-speed USB device number 10 using ehci_hcd Mar 8 10:21:09 Desktop kernel: [13758.852838] Linux media interface: v0.10 Mar 8 10:21:09 Desktop kernel: [13758.857354] Linux video capture interface: v2.00 Mar 8 10:21:09 Desktop kernel: [13758.858018] gspca_main: v2.15.3 registered Mar 8 10:21:09 Desktop kernel: [13758.858357] gspca_main: gspca_sn9c20x-2.15.3 probing 0c45:627b Mar 8 10:21:09 Desktop kernel: [13758.886556] gspca_sn9c20x: OV7660 sensor detected Mar 8 10:21:09 Desktop kernel: [13758.886647] input: gspca_sn9c20x as /devices/pci:00/:00:1d.7/usb1/1-5/1-5.5/input/input16 Mar 8 10:21:09 Desktop kernel: [13758.886791] gspca_main: video0 created Mar 8 10:21:09 Desktop kernel: [13758.886823] usbcore: registered new interface driver gspca_sn9c20x Mar 8 10:22:04 Desktop kernel: [13813.347291] gspca_sn9c20x: Set 640x480 `-- tail /var/log/errors.log Mar 8 10:24:09 Desktop motion: [1] Error starting stream VIDIOC_STREAMON: Input/output error Mar 8 10:24:09 Desktop motion: [1] ioctl (VIDIOCGCAP): Inappropriate ioctl for device Mar 8 10:24:09 Desktop motion: [1] Could not fetch initial image from camera Mar 8 10:24:09 Desktop motion: [1] Motion continues using width and height from config file(s) Mar 8 10:24:10 Desktop motion: [1] Retrying until successful connection with camera Mar 8 10:24:10 Desktop motion: [1] Error requesting buffers 4 for memory map. VIDIOC_REQBUFS: Device or resource busy Mar 8 10:24:10 Desktop motion: [1] ioctl (VIDIOCGCAP): Inappropriate ioctl for device Mar 8 10:24:20 Desktop motion: [1] Retrying until successful connection with camera Mar 8 10:24:20 Desktop motion: [1] Error requesting buffers 4 for memory map. VIDIOC_REQBUFS: Device or resource busy Mar 8 10:24:20 Desktop motion: [1] ioctl (VIDIOCGCAP): Inappropriate ioctl for device -- 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: My Microdia (SN9C201) webcam doesn't work properly in Linux anymore
On Thu, 8 Mar 2012, Xavion wrote: Hi Theodore As to getting that kind of resolution out of a webcam, though, it would be a rather tough go due to the amount of data which has to pass over the wire even if it is compressed data. The frame rate would be pretty atrocious. Therefore, you are probably not going to see that kind of resolution in an inexpensive webcam, at least until USB 3 comes into common use. Thanks for offering your thoughts on this matter. You are welcome. It looks like I'll have to keep checking eBay for cheap USB v3 (HD) webcams periodically. Which somebody will need to support because they will probably not work out of the box with an OEM driver CD ;-) For the record, I've only got Motion set to capture four frames per second at the moment. Perhaps for now if you want that kind of resolution and do not care about the frame rate very much, you would be better off to buy a slightly fancier camera and do something like using gphoto2 to take timed shots. I prefer the idea of captured motion to that of timed snapshots. The captured images and videos are automatically uploaded to my Dropbox account. As I'm only a 'free' user, I must limit the storage space that these files consume. Some of the cheap cameras do work pretty well, actually. But as far as I know any resolution better than 640*480 seems to be pretty unusual. Lots of interpolated higher resolution meaning they have inflated the pictures, of course. But some of the 640x480 cameras do better than others. And also I should point out that if 4 fps is OK with you then some of the cameras do not even do compression. If you could get hold of an old SQ905 camera that will do 640x480 it runs on bulk transport and there is no compression of frame data at all. Also, what is interesting is that with all the cheap cameras they cut corners, of course. But the SQ905 cameras always seemed to me to tend to have better optics than a lot of the other cheap cams. Where they really cut down on features was with the controller chip. It will do practically nothing compared to some others. The SQ905 used to be advertised as the cheapest camera controller chip on the market, once upon a time. But the images one gets from those cameras sometimes are not half bad. Also I should mention that if one wants to get better images out then it is best somehow to capture and save the raw data and process it later. This is true for any camera which either produces an uncompressed bitmap raw image, and also for any camera which does compression of said bitmap image before sending it down to the computer. Everything but JPEG, pretty much. Why is this? Because the image processing used with webcams must necessarily have speed as the number one priority, else the frame rate suffers severely. If one is not thus constrained, it is possible to do a much better job with that raw data. But remember that you can maximize image quality, or you can maximize frame rate. Choose one of the two. Theodore Kilgore -- 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
