Re: [PATCH v2 4/4] Add support to libv4l to use orientation from VIDIOC_ENUMINPUT
On 03/30/2009 12:28 AM, Adam Baker wrote:
Add check to libv4l of the sensor orientation as reported by
VIDIOC_ENUMINPUT
Signed-off-by: Adam Bakerli...@baker-net.org.uk
Looks good, thanks. I'll apply this to my libv4l tree, as soon
as its certain that the matching kernel changes will go in to
the kernel without any API changes.
Thanks Regards,
Hans
---
diff -r a647c2dfa989 v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.c
--- a/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.cTue Jan 20
11:25:54 2009 +0100
+++ b/v4l2-apps/lib/libv4l/libv4lconvert/libv4lconvert.cSun Mar 29
22:59:56 2009 +0100
@@ -29,6 +29,11 @@
#define MIN(a,b) (((a)(b))?(a):(b))
#define ARRAY_SIZE(x) ((int)sizeof(x)/(int)sizeof((x)[0]))
+/* Workaround this potentially being missing from videodev2.h */
+#ifndef V4L2_IN_ST_VFLIP
+#define V4L2_IN_ST_VFLIP 0x0020 /* Output is flipped vertically */
+#endif
+
/* Note for proper functioning of v4lconvert_enum_fmt the first entries in
supported_src_pixfmts must match with the entries in supported_dst_pixfmts
*/
#define SUPPORTED_DST_PIXFMTS \
@@ -134,6 +139,7 @@
int i, j;
struct v4lconvert_data *data = calloc(1, sizeof(struct v4lconvert_data));
struct v4l2_capability cap;
+ struct v4l2_input input;
if (!data)
return NULL;
@@ -161,6 +167,13 @@
/* Check if this cam has any special flags */
data-flags = v4lconvert_get_flags(data-fd);
+ if ((syscall(SYS_ioctl, fd, VIDIOC_G_INPUT,input.index) == 0)
+ (syscall(SYS_ioctl, fd, VIDIOC_ENUMINPUT,input) == 0)) {
+/* Don't yet support independent HFLIP and VFLIP so getting
+ * image the right way up is highest priority. */
+if (input.status V4L2_IN_ST_VFLIP)
+ data-flags |= V4LCONVERT_ROTATE_180;
+ }
if (syscall(SYS_ioctl, fd, VIDIOC_QUERYCAP,cap) == 0) {
if (!strcmp((char *)cap.driver, uvcvideo))
data-flags |= V4LCONVERT_IS_UVC;
--
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] soc-camera: fix breakage caused by 1fa5ae857bb14f6046205171d98506d8112dd74e
soc-camera re-uses struct devices multiple times in calls to device_register(),
therefore it has to reset the embedded struct kobject to avoid the tried to
init an initialized object error, which then also erases its name. Now with
the transition to kobject's name for device names, we have to re-initialise the
name before each call to device_register().
Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de
---
Kay, is this an acceptable fix? Or should I rather replace
memset(icd-dev.kobj, 0, sizeof(icd-dev.kobj));
with just some variant of
kobj-state_initialized = 0;
?
drivers/media/video/soc_camera.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 6d8bfd4..0e890cc 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -764,7 +764,10 @@ static int soc_camera_s_register(struct file *file, void
*fh,
static int device_register_link(struct soc_camera_device *icd)
{
- int ret = device_register(icd-dev);
+ int ret = dev_set_name(icd-dev, %u-%u, icd-iface, icd-devnum);
+
+ if (!ret)
+ ret = device_register(icd-dev);
if (ret 0) {
/* Prevent calling device_unregister() */
@@ -1060,7 +1063,6 @@ int soc_camera_device_register(struct soc_camera_device
*icd)
icd-devnum = num;
icd-dev.bus = soc_camera_bus_type;
- dev_set_name(icd-dev, %u-%u, icd-iface, icd-devnum);
icd-dev.release= dummy_release;
icd-use_count = 0;
--
1.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: [Patch] IR support for TeVii S460 DVB-S card
-Ursprüngliche Nachricht- Von: Igor M. Liplianin liplia...@me.by Gesendet: 29.03.09 09:36:06 An: Mauro Chehab mche...@infradead.org Betreff: Re: [Patch] IR support for TeVii S460 DVB-S card [..] http://mercurial.intuxication.org/hg/s2-liplianin/rev/c1672468ea88 Did you see my repository? Oh, I'm shure, you did! Just for the record: You're completely wrong. -- B. S. __ Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele ausländische Netze zum gleichen Preis! https://produkte.web.de/webde_sms/sms -- 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
[PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb
Hi Mauro, Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb for the following: - cx25840: cleanup: remove intermediate 'ioctl' step - cx18: remove intermediate 'ioctl' step - v4l: replace 'ioctl' references in v4l i2c drivers - tuner: remove V4L1 code from this driver. - v4l2-subdev: add enum_framesizes and enum_frameintervals. - au8522: remove unused I2C_DRIVERID - cx25840: fix 'unused variable' warning. Basically a bunch of cleanups in preparation of the final phase. Note the removal of the V4L1 code in the tuner. Since all i2c drivers are now fully v4l2 the V4L1 code could be removed from this module. Thanks, Hans diffstat: drivers/media/dvb/frontends/au8522_decoder.c |1 drivers/media/video/cx18/cx18-av-audio.c | 122 - drivers/media/video/cx18/cx18-av-core.c | 29 -- drivers/media/video/cx18/cx18-av-core.h |9 drivers/media/video/cx18/cx18-av-vbi.c | 333 +-- drivers/media/video/cx25840/cx25840-audio.c | 121 - drivers/media/video/cx25840/cx25840-core.c | 26 -- drivers/media/video/cx25840/cx25840-core.h |8 drivers/media/video/cx25840/cx25840-vbi.c| 328 -- drivers/media/video/ks0127.c | 23 - drivers/media/video/saa7115.c|4 drivers/media/video/tuner-core.c | 146 --- drivers/media/video/tvp5150.c|8 drivers/media/video/vpx3220.c|8 include/media/v4l2-subdev.h |2 15 files changed, 490 insertions(+), 678 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v4] ov772x: add edge contrl support
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
v3 - v4
o comment fix
o change edge ctrl setting order
o considered edge auto control mode and manual control mode
o add DSP auto register comment
drivers/media/video/ov772x.c | 52 ++---
include/media/ov772x.h | 25
2 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 34c9819..182daa5 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -169,11 +169,11 @@
#define GAM15 0x8C /* Gamma Curve 15th segment input end point */
#define SLOP0x8D /* Gamma curve highest segment slope */
#define DNSTH 0x8E /* De-noise threshold */
-#define EDGE0 0x8F /* Edge enhancement control 0 */
-#define EDGE1 0x90 /* Edge enhancement control 1 */
+#define EDGE0 0x8F /* Edge strength control when manual mode */
+#define EDGE1 0x90 /* Edge threshold control when manual mode */
#define DNSOFF 0x91 /* Auto De-noise threshold control */
-#define EDGE2 0x92 /* Edge enhancement strength low point control */
-#define EDGE3 0x93 /* Edge enhancement strength high point control */
+#define EDGE2 0x92 /* Edge strength upper limit when Auto mode */
+#define EDGE3 0x93 /* Edge strength lower limit when Auto mode */
#define MTX10x94 /* Matrix coefficient 1 */
#define MTX20x95 /* Matrix coefficient 2 */
#define MTX30x96 /* Matrix coefficient 3 */
@@ -358,6 +358,14 @@
#define VOSZ_VGA0xF0
#define VOSZ_QVGA 0x78
+/* DSPAUTO (DSP Auto Function ON/OFF Control) */
+#define AWB_ACTRL 0x80 /* AWB auto threshold control */
+#define DENOISE_ACTRL 0x40 /* De-noise auto threshold control */
+#define EDGE_ACTRL 0x20 /* Edge enhancement auto strength control */
+#define UV_ACTRL0x10 /* UV adjust auto slope control */
+#define SCAL0_ACTRL 0x08 /* Auto scaling factor control */
+#define SCAL1_2_ACTRL 0x04 /* Auto scaling factor control */
+
/*
* ID
*/
@@ -816,6 +824,42 @@ static int ov772x_set_params(struct ov772x_priv *priv, u32
width, u32 height,
ov772x_reset(priv-client);
/*
+* set Edge Ctrl
+*/
+ if (priv-info-flags OV772X_FLAG_MAN_EDGE) {
+ /*
+* Edge auto strength is set by default.
+* Remove this bit when manual strength.
+*/
+ ret = ov772x_mask_set(priv-client, DSPAUTO,
+ EDGE_ACTRL, 0x00);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv-client, EDGE1, 0x0F,
+ priv-info-edgectrl.reg_b);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv-client, EDGE0, 0x1F,
+ priv-info-edgectrl.reg_a);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ } else if (priv-info-edgectrl.reg_a priv-info-edgectrl.reg_b) {
+
+ ret = ov772x_mask_set(priv-client, EDGE2, 0xFF,
+ priv-info-edgectrl.reg_a);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv-client, EDGE3, 0xFF,
+ priv-info-edgectrl.reg_b);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+ }
+
+ /*
* set size format
*/
ret = ov772x_write_array(priv-client, priv-win-regs);
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 57db48d..75d1f15 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -16,11 +16,36 @@
/* for flags */
#define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
#define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
+#define OV772X_FLAG_MAN_EDGE 0x0004 /* Manual edge control (default Auto)
*/
+/*
+ * for Edge ctrl
+ *
+ * if OV772X_FLAG_MAN_EDGE
+ *reg_a : strength
+ *reg_b : threshold
+ * else (Auto Edge Control)
+ *reg_a : strength upper limit
+ *reg_b : strength lower limit
+ */
+struct ov772x_edge_ctrl {
+ unsigned char reg_a;
+ unsigned char reg_b;
+};
+
+#define OV772X_EDGECTRL(a, b) \
+ {.reg_a = (a),\
+.reg_b = (b),\
+ }
+
+/*
+ * ov772x camera info
+ */
struct ov772x_camera_info {
unsigned long buswidth;
unsigned long flags;
struct soc_camera_link link;
+ struct ov772x_edge_ctrl edgectrl;
};
#endif /* __OV772X_H__ */
--
1.5.6.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx88
On Mon, 30 Mar 2009 13:38:51 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
On Monday 30 March 2009 13:31:55 Mauro Carvalho Chehab wrote:
On Sun, 29 Mar 2009 15:36:46 +0200
Hans Verkuil hverk...@xs4all.nl wrote:
Hi Mauro,
Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-cx88 for the
following:
- cx88: convert to v4l2_subdev.
I only noticed this, when I tried to compile with an old kernel:
diff --git a/linux/drivers/media/video/cx88/cx88-video.c
b/linux/drivers/media/
video/cx88/cx88-video.c
snip/
+#if LINUX_VERSION_CODE = KERNEL_VERSION(2, 6, 22)
+ static struct i2c_board_info rtc_info = {
+ I2C_BOARD_INFO(isl1208, 0x6f)
+ };
+
request_module(rtc-isl1208);
+ core-i2c_rtc = i2c_new_device(core-i2c_adap, rtc_info);
+#else
+ request_module(rtc-isl1208);
+#endif
+ }
Where is the isl1208 driver? I can't see it.
It's an rtc (real-time clock) driver that's part of the drivers/rtc
subdirectory in the kernel. Apparently this particular board needs to set up
this rtc device by loading this driver for proper operation.
Hmm... weird...
For what purpose we need this driver? The other Isil drivers are power
control
drivers for DVB. If this is the case, we should move this code to cx88-dvb.
It's perfectly OK where it is. But since that driver was also converted to
the new style API we need to use i2c_new_device to load it since just calling
request_module will no longer work for this driver. Hence this change in the
code.
Ok.
Cheers,
Mauro
--
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 5/5] saa7121 driver for s6000 data port
On 03/30/2009 12:03 PM, Hans Verkuil wrote: What exactly do you need? If there is something missing, then it should be added. But my guess is that you can pass such information via the s_routing callback. That's what all other drivers that use v4l2_subdev do. The s_routing callback looks very limited. One can pass only two u32 values. The parameters that have to be negotiated are: - What is the on-wire video format? - how many data lines are connected? - synchronization using embedded SAV/EAV codes or using dedicated pins? - polarity of sync lines? - valid CRC and line number in digital blanking? - what is the layout of the digital image? - how many odd lines are there? how many even? (including blanking) - how many horizontal pixels? (incl. blanking) - where is the active region? - on which pixels/lines do we start/end horizontal/vertical sync? It seems the soc-camera framework is a better choice here, but to make it work with the saa7121 one would first have to implement support for video output. This framework will also be converted to use v4l2_subdev for the communication with i2c drivers. So it shouldn't matter which one I chose? Actually, I recommend that you first look at the existing saa7127.c source. I don't know how many differences there are between the saa7121 and saa7127, but perhaps support for the saa7121 can be added there rather than introducing a new driver. Of course, that only works if the differences are not too big. The chips appear to be very similar, sharing most of the registers. However, the aforementioned problem still exists with this driver. A driver connecting this sub device must know beforehand that it has to send standard BT.656 video frames with SAV/EAV codes. Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055 Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 emlix - your embedded linux partner -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/3] New V4L2 CIDs for OMAP class of Devices.
On Friday 20 March 2009 06:19:57 Hardik Shah wrote:
Added V4L2_CID_BG_COLOR for background color setting.
Added V4L2_CID_ROTATION for rotation setting.
Above two ioclts are indepth discussed. Posting
again with the driver usage.
V4L2 supports chroma keying added new flags for the
source chroma keying which is exactly opposite of the
chorma keying supported by V4L2. In current implementation
video data is replaced by the graphics buffer data for some
specific color. While for the source chroma keying grahics
data is replaced by the video data for some specific color.
Both are exactly opposite so are mutually exclusive
Signed-off-by: Brijesh Jadav brijes...@ti.com
Signed-off-by: Hardik Shah hardik.s...@ti.com
Signed-off-by: Vaibhav Hiremath hvaib...@ti.com
---
linux/drivers/media/video/v4l2-common.c |7 +++
linux/include/linux/videodev2.h |6 +-
2 files changed, 12 insertions(+), 1 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 3c42316..fa408f0 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -422,6 +422,8 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_CHROMA_AGC: return Chroma AGC;
case V4L2_CID_COLOR_KILLER: return Color Killer;
case V4L2_CID_COLORFX: return Color Effects;
+ case V4L2_CID_ROTATION: return Rotation;
I'm having second thoughts about this name. I think V4L2_CID_ROTATE is better,
since it is an action ('you rotate an image') rather than a status ('what is
the rotation of an image').
What do you think?
+ case V4L2_CID_BG_COLOR: return Background color;
/* MPEG controls */
case V4L2_CID_MPEG_CLASS: return MPEG Encoder Controls;
@@ -547,6 +549,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
break;
+ case V4L2_CID_BG_COLOR:
+ qctrl-type = V4L2_CTRL_TYPE_INTEGER;
+ step = 1;
+ break;
Set the min to 0 and max to 0xff.
default:
qctrl-type = V4L2_CTRL_TYPE_INTEGER;
break;
@@ -571,6 +577,7 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
case V4L2_CID_BLUE_BALANCE:
case V4L2_CID_GAMMA:
case V4L2_CID_SHARPNESS:
+ case V4L2_CID_BG_COLOR:
This definitely isn't a slider control.
qctrl-flags |= V4L2_CTRL_FLAG_SLIDER;
break;
case V4L2_CID_PAN_RELATIVE:
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index 2c83935..592d1c8 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -548,6 +548,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_CAP_LOCAL_ALPHA0x0010
#define V4L2_FBUF_CAP_GLOBAL_ALPHA 0x0020
#define V4L2_FBUF_CAP_LOCAL_INV_ALPHA0x0040
+#define V4L2_FBUF_CAP_SRC_CHROMAKEY 0x0080
/* Flags for the 'flags' field. */
#define V4L2_FBUF_FLAG_PRIMARY 0x0001
#define V4L2_FBUF_FLAG_OVERLAY 0x0002
@@ -555,6 +556,7 @@ struct v4l2_framebuffer {
#define V4L2_FBUF_FLAG_LOCAL_ALPHA 0x0008
#define V4L2_FBUF_FLAG_GLOBAL_ALPHA 0x0010
#define V4L2_FBUF_FLAG_LOCAL_INV_ALPHA 0x0020
+#define V4L2_FBUF_FLAG_SRC_CHROMAKEY 0x0040
struct v4l2_clip {
struct v4l2_rectc;
@@ -882,6 +884,8 @@ enum v4l2_power_line_frequency {
#define V4L2_CID_CHROMA_AGC (V4L2_CID_BASE+29)
#define V4L2_CID_COLOR_KILLER (V4L2_CID_BASE+30)
#define V4L2_CID_COLORFX (V4L2_CID_BASE+31)
+#define V4L2_CID_ROTATION(V4L2_CID_BASE+32)
+#define V4L2_CID_BG_COLOR (V4L2_CID_BASE+33)
enum v4l2_colorfx {
V4L2_COLORFX_NONE = 0,
V4L2_COLORFX_BW = 1,
@@ -889,7 +893,7 @@ enum v4l2_colorfx {
};
/* last CID + 1 */
-#define V4L2_CID_LASTP1 (V4L2_CID_BASE+32)
+#define V4L2_CID_LASTP1 (V4L2_CID_BASE+34)
/* MPEG-class control IDs defined by V4L2 */
#define V4L2_CID_MPEG_BASE (V4L2_CTRL_CLASS_MPEG | 0x900)
--
1.5.6
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: Status of v4l2_subdev conversion
On Monday 30 March 2009 14:37:22 Alexey Klimov wrote: Hello, Hans On Sun, Mar 29, 2009 at 4:22 PM, Hans Verkuil hverk...@xs4all.nl wrote: Hi Mauro, For your information, this is the current status: - Steve Toth tested the HVR-1800 for me, so I've posted the pull request for the converted cx23885 driver. - The cx88 driver is also finished. I'm waiting for a last test by Jean Delvare before I post that one as well. - Added support for saa6588 to saa7134: needed to drop the legacy i2c API from saa6588. This is in my pull request for my v4l-dvb tree. - Douglas has almost finished the em28xx driver conversion. - Jean Delvare is working on the ir-kbd-i2c conversion. That last conversion is stand-alone (i.e. has no impact on the internal v4l API) and I don't think it prevents pushing our v4l-dvb changes to 2.6.30. When the first four items are finished and merged into v4l-dvb, then I have a to do a few final cleanup actions to make everything ready for the 2.6.30 merge: - Remove v4l2-i2c-drv-legacy.h from the remaining i2c drivers. Remove the files v4l2-i2c-drv-legacy.h and v4l2-common.c since these are no longer used. Cleanup v4l2-common.h since the internal ioctls are no longer needed. Update v4l2-framework.txt, removing any references to the legacy behavior. - Fix two subdev callbacks that are in the wrong place (s_std belongs to the video ops, s_standby belongs to the tuner ops). - Add a load_fw callback to the core ops and use that were appropriate instead of the init callback. Analyze whether the init callback can be removed altogether. - Analyze how the probe addresses are used in the v4l2 drivers and move those lists over to the appropriate i2c driver headers. - Add enum_frameintervals and enum_framesizes callbacks for use with omap. - Check for any remaining uses of I2C_DRIVERID and remove them. This shouldn't take much time to implement. So, if you converted pci-isa radio drivers to v4l2_device. Should dsbr100, si470x, and mr800 be converted to v4l2_device too ? Eventually, yes. But I did those pci-isa radio drivers basically for fun and because I got hold of two of those ISA cards so I could test it as well. However, this v4l2_device conversion isn't urgent, unlike the v4l2_subdev conversion. But it will have to be done eventually, and it is pretty trivial at the moment. So I'd appreciate it if you could spend a bit of time on it. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 1/3] Documentation for new V4L2 CIDs added.
Hi Hardik, OK, so it took a little longer than a week. So sue me :-) Here is the review:On Friday 20 March 2009 06:19:49 Hardik Shah wrote: 1. Updated for V4L2_CID_BG_COLOR 2. Updated for V4L2_CID_ROTATION Both of the above are discussed in length with community 3. Updated for new flags and capability field added to v4l2_frame buffer structure. Signed-off-by: Brijesh Jadav brijes...@ti.com Signed-off-by: Hardik Shah hardik.s...@ti.com Signed-off-by: Vaibhav Hiremath hvaib...@ti.com --- v4l2-spec/controls.sgml | 19 ++- v4l2-spec/vidioc-g-fbuf.sgml | 19 +++ 2 files changed, 37 insertions(+), 1 deletions(-) diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..79e2c28 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -281,10 +281,27 @@ minimum value disables backlight compensation./entry constantV4L2_COLORFX_SEPIA/constant (2)./entry /row row + entryconstantV4L2_CID_ROTATION/constant/entry + entryinteger/entry + entryRotates the image by specified angle. Common angles are 90, 270, +and 180. Rotating the image to 90 and 270 will reverse the height and width of +the display window. Its is necessary to set the new height and width of the picture Typo: 'Its' - 'It' +using S_FMT ioctl see xref linkend=vidioc-g-fmt according to the rotation angle selected/entry + /row + row + entryconstantV4L2_CID_BG_COLOR/constant/entry + entryinteger/entry + entrySets the background color on the current output device. Typo: 'on' - 'of' +Background color needs to be specified in the RGB24 format. The supplied 32 +bit value is intepreted as Bits 0-7 Red color information, Bits 8-15 Green color +information, Bits 16-23 Blue color information and Bits 24-31 must be +zero./entry + /row + row entryconstantV4L2_CID_LASTP1/constant/entry entry/entry entryEnd of the predefined control IDs (currently -constantV4L2_CID_COLORFX/constant + 1)./entry +constantV4L2_CID_BG_COLOR/constant + 1)./entry /row row entryconstantV4L2_CID_PRIVATE_BASE/constant/entry diff --git a/v4l2-spec/vidioc-g-fbuf.sgml b/v4l2-spec/vidioc-g-fbuf.sgml index 6781b53..27d1e29 100644 --- a/v4l2-spec/vidioc-g-fbuf.sgml +++ b/v4l2-spec/vidioc-g-fbuf.sgml @@ -336,6 +336,13 @@ alpha value. Alpha blending makes no sense for destructive overlays./entry inverted alpha channel of the framebuffer or VGA signal. Alpha blending makes no sense for destructive overlays./entry /row + row + entryconstantV4L2_FBUF_CAP_SRC_CHROMAKEY/constant/entry + entry0x0080/entry + entryThe device supports source chorma keying. Framebuffer Typo: chorma - chroma +images will be replaced by the video images. Exactly +opposite of constantV4L2_FBUF_CAP_CHROMAKEY/constant/entry Hmm. This is a bit obscure. CAP_CHROMAKEY means that framebuffer pixels with the chromakey color are replaced by video pixels. CAP_SRC_CHROMAKEY means that video pixels with the chromakey color are replaced by the framebuffer pixels. At least the way I read it this is the opposite of what you wrote. It pays to be very precise here since it can get confusing very quickly. + /row /tbody /tgroup /table @@ -411,6 +418,18 @@ images, but with an inverted alpha value. The blend function is: output = framebuffer pixel * (1 - alpha) + video pixel * alpha. The actual alpha depth depends on the framebuffer pixel format./entry /row + row + entryconstantV4L2_FBUF_FLAG_SRC_CHROMAKEY/constant/entry + entry0x0040/entry + entryUse chroma-keying. The chroma-key color is Write: 'Use source chroma-keying.' to prevent confusion with V4L2_FBUF_FLAG_CHROMAKEY. +determined by the structfieldchromakey/structfield field of +v4l2-window; and negotiated with the VIDIOC-S-FMT; ioctl, see xref +linkend=overlay and xref linkend=osd. +Since any one of the chorma keying can be active at a time as both Typo: chorma - chroma +of them are exactly opposite same structfieldchromakey/structfield Typo: 'opposite same' - 'opposite the same' +field of v4l2-window; can be used to set the chroma key for source +keying also./entry + /row /tbody /tgroup /table -- 1.5.6 Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 5/5] saa7121 driver for s6000 data port
On 03/26/2009 04:08 PM, Hans Verkuil wrote: I've been working on a new framework for devices like this and almost all i2c v4l drivers are now converted to v4l2_subdev in our v4l-dvb tree. It will also be merged in 2.6.30. Please take a look at v4l2-framework.txt in the v4l-dvb repository for more information. I'm sure you will have questions later, please don't hesitate to ask! It's a recent development but very much needed. Otherwise we will end up with a lot of duplicate i2c drivers, each tied to their own platform or framework. That's clearly something we do not want. Hi Hans, the problem I see with the v4l2-framework in this case is that in its current state it does not allow to exchange information regarding the bus parameters between the sub device and the controller. It seems the soc-camera framework is a better choice here, but to make it work with the saa7121 one would first have to implement support for video output. What do you recommend? Daniel -- Dipl.-Math. Daniel Glöckner, emlix GmbH, http://www.emlix.com Fon +49 551 30664-0, Fax -11, Bahnhofsallee 1b, 37081 Göttingen, Germany Geschäftsführung: Dr. Uwe Kracke, Dr. Cord Seele, Ust-IdNr.: DE 205 198 055 Sitz der Gesellschaft: Göttingen, Amtsgericht Göttingen HR B 3160 emlix - your embedded linux partner -- 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 5/5] saa7121 driver for s6000 data port
On Monday 30 March 2009 14:12:10 Daniel Glöckner wrote: On 03/30/2009 12:03 PM, Hans Verkuil wrote: What exactly do you need? If there is something missing, then it should be added. But my guess is that you can pass such information via the s_routing callback. That's what all other drivers that use v4l2_subdev do. The s_routing callback looks very limited. One can pass only two u32 values. If a driver needs it, it can be extended. In particular I always thought that a third config value would be useful. The parameters that have to be negotiated are: - What is the on-wire video format? That might go to such a config value. - how many data lines are connected? routing - synchronization using embedded SAV/EAV codes or using dedicated pins? config value and/or routing. - polarity of sync lines? config - valid CRC and line number in digital blanking? Do you really need to control these? - what is the layout of the digital image? - how many odd lines are there? how many even? (including blanking) - how many horizontal pixels? (incl. blanking) - where is the active region? - on which pixels/lines do we start/end horizontal/vertical sync? It's a PAL/NTSC encoder, so the standard specified with s_std_output will map to the corresponding values that you need to put in. This is knowledge that the i2c driver implements. It seems the soc-camera framework is a better choice here, but to make it work with the saa7121 one would first have to implement support for video output. This framework will also be converted to use v4l2_subdev for the communication with i2c drivers. So it shouldn't matter which one I chose? You will have to do the work anyway. Better to go with the new framework then having to do the work twice. Actually, I recommend that you first look at the existing saa7127.c source. I don't know how many differences there are between the saa7121 and saa7127, but perhaps support for the saa7121 can be added there rather than introducing a new driver. Of course, that only works if the differences are not too big. The chips appear to be very similar, sharing most of the registers. However, the aforementioned problem still exists with this driver. A driver connecting this sub device must know beforehand that it has to send standard BT.656 video frames with SAV/EAV codes. So? If some future driver wants to do this differently, then we add the necessary code to the i2c driver. It's not fixed in stone, you know :-) Basically a driver only implements what can be tested. There is little point in adding a full feature set for a device if you are unable to test the code as well. So if a newer board appears in the future that needs to use something new, then we add support for that to the i2c driver. Looking at the datasheets I don't think you should make a new driver for this. Unless something crops up that makes it hard to use saa7127.c I think you should extend that driver to support saa7121 and add support for the missing functionality. But only what is necessary for your setup. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 5/5] saa7121 driver for s6000 data port
On Monday 30 March 2009 11:56:25 Daniel Glöckner wrote: On 03/26/2009 04:08 PM, Hans Verkuil wrote: I've been working on a new framework for devices like this and almost all i2c v4l drivers are now converted to v4l2_subdev in our v4l-dvb tree. It will also be merged in 2.6.30. Please take a look at v4l2-framework.txt in the v4l-dvb repository for more information. I'm sure you will have questions later, please don't hesitate to ask! It's a recent development but very much needed. Otherwise we will end up with a lot of duplicate i2c drivers, each tied to their own platform or framework. That's clearly something we do not want. Hi Hans, the problem I see with the v4l2-framework in this case is that in its current state it does not allow to exchange information regarding the bus parameters between the sub device and the controller. What exactly do you need? If there is something missing, then it should be added. But my guess is that you can pass such information via the s_routing callback. That's what all other drivers that use v4l2_subdev do. It seems the soc-camera framework is a better choice here, but to make it work with the saa7121 one would first have to implement support for video output. This framework will also be converted to use v4l2_subdev for the communication with i2c drivers. What do you recommend? Actually, I recommend that you first look at the existing saa7127.c source. I don't know how many differences there are between the saa7121 and saa7127, but perhaps support for the saa7121 can be added there rather than introducing a new driver. Of course, that only works if the differences are not too big. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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] V4L2 Driver for OMAP3/3 DSS.
Hi Hans, -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Monday, March 30, 2009 6:37 PM To: Shah, Hardik Cc: linux-media@vger.kernel.org; linux-o...@vger.kernel.org; Jadav, Brijesh R; Hiremath, Vaibhav Subject: Re: [PATCH 3/3] V4L2 Driver for OMAP3/3 DSS. On Friday 20 March 2009 06:20:08 Hardik Shah wrote: This is the version 3rd of the driver. This is a review patch since the DSS2 library is not accepted. Most of the community comments are addressed like 1. V4L2 Driver for OMAP3/3 DSS. 2. Conversion of the custom ioctls to standard V4L2 ioctls like alpha blending, color keying, rotation and back ground color setting 3. Re-organised the code as per community comments. [Shah, Hardik] I will be fixing it and resend the patches in 2-3 days. Regards, Hardik -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2/4] ARM: DaVinci: DM646x Video: VPIF driver
On Thursday 26 March 2009 14:22:20 Chaithrika U S wrote:
Video Port Interface driver
Add VPIF driver for DM646x. This code be used by the display and
capture drivers.
Signed-off-by: Chaithrika U S chaithr...@ti.com
---
Applies to v4l-dvb repository
drivers/media/video/davinci/vpif.c | 320 +
drivers/media/video/davinci/vpif.h | 668
2 files changed, 988 insertions(+), 0 deletions(-)
create mode 100644 drivers/media/video/davinci/vpif.c
create mode 100644 drivers/media/video/davinci/vpif.h
diff --git a/drivers/media/video/davinci/vpif.c
b/drivers/media/video/davinci/vpif.c
new file mode 100644
index 000..902e5ce
--- /dev/null
+++ b/drivers/media/video/davinci/vpif.c
@@ -0,0 +1,320 @@
+/*
+ * vpif - DM646x Video Port Interface driver
+ * VPIF is a receiver and transmitter for video data. It has two channels(0,
1)
+ * that receiveing video byte stream and two channels(2, 3) for video output.
+ * The hardware supports SDTV, HDTV formats, raw data capture.
+ * Currently, the driver supports NTSC and PAL standards.
+ *
+ * Copyright (C) 2009 Texas Instruments Incorporated - http://www.ti.com/
+ *
+ * This program is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation version 2.
+ *
+ * This program is distributed .as is. WITHOUT ANY WARRANTY of any
+ * kind, whether express or implied; without even the implied warranty
+ * of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ */
+
+#include linux/init.h
+#include linux/module.h
+#include linux/kernel.h
+
+#include vpif.h
+
+MODULE_DESCRIPTION(TI DaVinci Video Port Interface driver);
+MODULE_LICENSE(GPL);
+
+#define VPIF_CH0_MAX_MODES (22)
+#define VPIF_CH1_MAX_MODES (02)
+#define VPIF_CH2_MAX_MODES (15)
+#define VPIF_CH3_MAX_MODES (02)
+
+/* This structure is used to keep track of VPIF size register's offsets */
+struct vpif_registers {
+ u32 h_cfg, v_cfg_00, v_cfg_01, v_cfg_02, v_cfg, ch_ctrl;
+ u32 line_offset, vanc0_strt, vanc0_size, vanc1_strt;
+ u32 vanc1_size, width_mask, len_mask;
+ u8 max_modes;
+};
+
+static struct vpif_registers vpifregs[VPIF_NUM_CHANNELS] = {
+ /* Channel0 */
+ {
+ VPIF_CH0_H_CFG, VPIF_CH0_V_CFG_00, VPIF_CH0_V_CFG_01,
+ VPIF_CH0_V_CFG_02, VPIF_CH0_V_CFG_03, VPIF_CH0_CTRL,
+ VPIF_CH0_IMG_ADD_OFST, 0, 0, 0, 0, 0x1FFF, 0xFFF,
+ VPIF_CH0_MAX_MODES,
+ },
+ /* Channel1 */
+ {
+ VPIF_CH1_H_CFG, VPIF_CH1_V_CFG_00, VPIF_CH1_V_CFG_01,
+ VPIF_CH1_V_CFG_02, VPIF_CH1_V_CFG_03, VPIF_CH1_CTRL,
+ VPIF_CH1_IMG_ADD_OFST, 0, 0, 0, 0, 0x1FFF, 0xFFF,
+ VPIF_CH1_MAX_MODES,
+ },
+ /* Channel2 */
+ {
+ VPIF_CH2_H_CFG, VPIF_CH2_V_CFG_00, VPIF_CH2_V_CFG_01,
+ VPIF_CH2_V_CFG_02, VPIF_CH2_V_CFG_03, VPIF_CH2_CTRL,
+ VPIF_CH2_IMG_ADD_OFST, VPIF_CH2_VANC0_STRT, VPIF_CH2_VANC0_SIZE,
+ VPIF_CH2_VANC1_STRT, VPIF_CH2_VANC1_SIZE, 0x7FF, 0x7FF,
+ VPIF_CH2_MAX_MODES
+ },
+ /* Channel3 */
+ {
+ VPIF_CH3_H_CFG, VPIF_CH3_V_CFG_00, VPIF_CH3_V_CFG_01,
+ VPIF_CH3_V_CFG_02, VPIF_CH3_V_CFG_03, VPIF_CH3_CTRL,
+ VPIF_CH3_IMG_ADD_OFST, VPIF_CH3_VANC0_STRT, VPIF_CH3_VANC0_SIZE,
+ VPIF_CH3_VANC1_STRT, VPIF_CH3_VANC1_SIZE, 0x7FF, 0x7FF,
+ VPIF_CH3_MAX_MODES
+ },
+};
+
+static struct vpif_channel_config_params ch0_params[VPIF_CH0_MAX_MODES] = {
+ {
+ NTSC, 720, 480, 30, 0, 1, 268, 1440, 1, 23, 263, 266,
+ 286, 525, 525, 0, 1, 0, V4L2_STD_NTSC,
+ },
+ {
+ PAL, 720, 576, 25, 0, 1, 280, 1440, 1, 23, 311, 313,
+ 336, 624, 625, 0, 1, 0, V4L2_STD_PAL,
+ },
+};
This still feels wrong to me. This driver is here just to setup the VPIF
registers. This mode information doesn't belong here, instead it really
belongs to the display/capture drivers.
Just look at how vpif_get_std_info() is implemented: it's nothing more
than a complicated way of doing a table lookup to get hold of the format
timings for a particular standard. Just do it directly in vpif_display.c.
I'm convinced it will simplify both sources.
+static struct vpif_channel_config_params
+ *vpif_config_params[VPIF_NUM_CHANNELS] = {
+ ch0_params,
+ ch0_params,
+ ch0_params,
+ ch0_params,
+};
+
+/* vpif_set_mode_info:
+ * This function is used to set horizontal and vertical config parameters
+ * As per the standard in the channel, configure the values of L1, L3,
+ * L5, L7 L9, L11 in VPIF Register , also write width and height
+ */
+static void vpif_set_mode_info(u8 index, u8 channel_id, u8 config_channel_id)
+{
+
Re: [patch 5/5] saa7121 driver for s6000 data port
On Monday 30 March 2009 15:36:42 Daniel Glöckner wrote: On 03/30/2009 02:50 PM, Hans Verkuil wrote: On Monday 30 March 2009 14:12:10 Daniel Glöckner wrote: - valid CRC and line number in digital blanking? Do you really need to control these? Not on this board.. It's a PAL/NTSC encoder, so the standard specified with s_std_output will map to the corresponding values that you need to put in. This is knowledge that the i2c driver implements. There is a micron camera connected to the controller that can output any resolution up to 1600x1200 and we don't have standard ids for all those HD formats supported by encoders like the ADV7197. It would be really nice to have an interface that covers all this while being symmetric for input and output. This is a known issue. I expect to see some proposals for this in the near future since Texas Instruments need this as well for their davinci architecture. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- 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 v4] ov772x: add edge contrl support
On Mon, 30 Mar 2009, Kuninori Morimoto wrote:
Signed-off-by: Kuninori Morimoto morimoto.kunin...@renesas.com
---
v3 - v4
o comment fix
o change edge ctrl setting order
o considered edge auto control mode and manual control mode
o add DSP auto register comment
Ok, I understand more now. So, this edge (which I still don't know what it
actually does. Some sort of contrast?) can function in either automatic or
in manual mode. In Automatic mode you set lower and upper points in
registers EDGE2 and EDGE3, in manual mode you set strength and threshold
in registers EDGE0 and EDGE1. So, just one more question:
drivers/media/video/ov772x.c | 52 ++---
include/media/ov772x.h | 25
2 files changed, 73 insertions(+), 4 deletions(-)
diff --git a/drivers/media/video/ov772x.c b/drivers/media/video/ov772x.c
index 34c9819..182daa5 100644
--- a/drivers/media/video/ov772x.c
+++ b/drivers/media/video/ov772x.c
@@ -169,11 +169,11 @@
#define GAM15 0x8C /* Gamma Curve 15th segment input end point */
#define SLOP0x8D /* Gamma curve highest segment slope */
#define DNSTH 0x8E /* De-noise threshold */
-#define EDGE0 0x8F /* Edge enhancement control 0 */
-#define EDGE1 0x90 /* Edge enhancement control 1 */
+#define EDGE0 0x8F /* Edge strength control when manual mode */
+#define EDGE1 0x90 /* Edge threshold control when manual mode */
#define DNSOFF 0x91 /* Auto De-noise threshold control */
-#define EDGE2 0x92 /* Edge enhancement strength low point control */
-#define EDGE3 0x93 /* Edge enhancement strength high point control */
+#define EDGE2 0x92 /* Edge strength upper limit when Auto mode */
+#define EDGE3 0x93 /* Edge strength lower limit when Auto mode */
#define MTX10x94 /* Matrix coefficient 1 */
#define MTX20x95 /* Matrix coefficient 2 */
#define MTX30x96 /* Matrix coefficient 3 */
@@ -358,6 +358,14 @@
#define VOSZ_VGA0xF0
#define VOSZ_QVGA 0x78
+/* DSPAUTO (DSP Auto Function ON/OFF Control) */
+#define AWB_ACTRL 0x80 /* AWB auto threshold control */
+#define DENOISE_ACTRL 0x40 /* De-noise auto threshold control */
+#define EDGE_ACTRL 0x20 /* Edge enhancement auto strength control */
+#define UV_ACTRL0x10 /* UV adjust auto slope control */
+#define SCAL0_ACTRL 0x08 /* Auto scaling factor control */
+#define SCAL1_2_ACTRL 0x04 /* Auto scaling factor control */
+
/*
* ID
*/
@@ -816,6 +824,42 @@ static int ov772x_set_params(struct ov772x_priv *priv,
u32 width, u32 height,
ov772x_reset(priv-client);
/*
+ * set Edge Ctrl
+ */
+ if (priv-info-flags OV772X_FLAG_MAN_EDGE) {
+ /*
+ * Edge auto strength is set by default.
+ * Remove this bit when manual strength.
+ */
+ ret = ov772x_mask_set(priv-client, DSPAUTO,
+ EDGE_ACTRL, 0x00);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv-client, EDGE1, 0x0F,
+ priv-info-edgectrl.reg_b);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv-client, EDGE0, 0x1F,
+ priv-info-edgectrl.reg_a);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ } else if (priv-info-edgectrl.reg_a priv-info-edgectrl.reg_b) {
+
+ ret = ov772x_mask_set(priv-client, EDGE2, 0xFF,
+ priv-info-edgectrl.reg_a);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+
+ ret = ov772x_mask_set(priv-client, EDGE3, 0xFF,
+ priv-info-edgectrl.reg_b);
+ if (ret 0)
+ goto ov772x_set_fmt_error;
+ }
+
+ /*
* set size format
*/
ret = ov772x_write_array(priv-client, priv-win-regs);
diff --git a/include/media/ov772x.h b/include/media/ov772x.h
index 57db48d..75d1f15 100644
--- a/include/media/ov772x.h
+++ b/include/media/ov772x.h
@@ -16,11 +16,36 @@
/* for flags */
#define OV772X_FLAG_VFLIP 0x0001 /* Vertical flip image */
#define OV772X_FLAG_HFLIP 0x0002 /* Horizontal flip image */
+#define OV772X_FLAG_MAN_EDGE 0x0004 /* Manual edge control (default
Auto) */
+/*
+ * for Edge ctrl
+ *
+ * if OV772X_FLAG_MAN_EDGE
+ *reg_a : strength
+ *reg_b : threshold
+ * else (Auto Edge Control)
+ *reg_a : strength upper limit
+ *reg_b : strength lower limit
+ */
+struct ov772x_edge_ctrl {
+ unsigned char reg_a;
+ unsigned char reg_b;
+};
+
+#define OV772X_EDGECTRL(a, b) \
+ {.reg_a = (a),\
+ .reg_b = (b),
[RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail-thread, actually I was on vacation. As proposed by Sakari, I do agree with the approach of having V4L2 interface for memory-to-memory operation of the ISP (like resizer and previewer), but I would like to bring some important aspects/issues here - - Some drawbacks of V4L2-buf layer framework for such kind of devices - Need for backward compatibility. Drawbacks for V4L2-Buf layer - - 1} In case of resizer driver, the input buffer will always be different than output buffer. In case of Mmapped buffer there is no issue, since driver allocates maximum of input and output. User doesn't have control on this, although there is loss of memory from system point of view. In case of User Pointer Exchange, User would expect and may allocate different sizes of buffers for input and output which V4L2-buf layer doesn't support with single queue. And to address this, I think here we need to have either of following approaches - - Use two separate buffer queues, one for input and another for output. - Or hack the driver for v4l2_buffer, internally using different buffer params for input and output. [Not recommended] Please note that sometimes application receives buffers from another driver or from some codecs engine that's why input and output buffer will never be of same size. 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to give low level details about this - When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages. In 'get_user_pages' it checks for IOMEM flag and returns error, which is expected behavior from Kernel point of view. We are trying to map buffer which is already mapped to kernel by another driver. One thing I am not able to understand, how nobody came across such use-case which is very common. And to address this issue we need to add support for IOMEM in V4L2-buf layer. NOTE: Currently both of these issues have been addressed as a custom implementation for our internal use case. Backward Compatibility - --- This is an important aspect, since similar hardware modules are available on Davinci as well as on OMAP and their driver interface is completely different. On Davinci, resizer driver is supported through plane char driver interface which handles all data/buffer processing and control paths. It maintains internal queue for priority of resizing tasks and stuff. The driver is present under /drivers/char/Davinci. Here I feel, V4L2 way is better, since all image processing drivers should go under drivers/media/video/. And again we can make use of readily available V4L2 framework interface for data and control path to manage buffers. We should enhance V4L2 framework to support such devices. Proposed Required Changes - -- I am putting some high level changes required to be done for supporting such devices - - Enhancement in V4L2-buf layer for above issues - Will be directly using sub-device frame-work and have to enhance it to support such devices. - Below are the parameters we need to configure for Resizer from user application - __s32 in_hsize;/* input frame horizontal size.*/ __s32 in_vsize;/* input frame vertical size */ __s32 in_pitch;/* offset between 2 rows of input frame.*/ __s32 inptyp; /* for determining 16 bit or 8 bit data.*/ __s32 vert_starting_pixel; /* vertical starting pixel in input.*/ __s32 horz_starting_pixel; /* horizontal starting pixel in input.*/ __s32 cbilin; /* filter with luma or bi-linear interpolation.*/ __s32 pix_fmt; /* UYVY or YUYV */ __s32 out_hsize; /* output frame horizontal size. */ __s32 out_vsize; /* output frame vertical size.*/ __s32 out_pitch; /* offset between 2 rows of output frame.*/ __s32 hstph; /* for specifying horizontal starting phase.*/ __s32 vstph; /* for specifying vertical starting phase.*/ __u16 tap4filt_coeffs[32]; /* horizontal filtercoefficients.*/ __u16 tap7filt_coeffs[32]; /* vertical filter coefficients. */ struct rsz_yenh yenh_params; (Pasted from previous patches posted by Sergio) Putting one sample proposal using VIDIOC_S_FMT - APPROACH 1 - -- Either we can add this under struct v4l2_format or need to enhance stuct v4l2_crop to support such device. We can use 'VIDIOC_S_FMT' ioctl to configure the resizer parameters. From top level it will look something like - struct v4l2_buffer buf; struct
[PATCH] mt9m001: fix advertised pixel clock polarity
MT9M001 datasheet says, that the data is ready on the falling edge of the pixel clock, but the driver wrongly sets the SOCAM_PCLK_SAMPLE_RISING flag. Changing this doesn't seem to produce any visible difference, still, it is better to comply to the datasheet. Reported-by: Sascha Oppermann opperm...@garage-computers.com Signed-off-by: Guennadi Liakhovetski g.liakhovet...@gmx.de --- Objections? drivers/media/video/mt9m001.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/video/mt9m001.c b/drivers/media/video/mt9m001.c index fa7e509..684f62f 100644 --- a/drivers/media/video/mt9m001.c +++ b/drivers/media/video/mt9m001.c @@ -207,7 +207,7 @@ static unsigned long mt9m001_query_bus_param(struct soc_camera_device *icd) struct mt9m001 *mt9m001 = container_of(icd, struct mt9m001, icd); struct soc_camera_link *icl = mt9m001-client-dev.platform_data; /* MT9M001 has all capture_format parameters fixed */ - unsigned long flags = SOCAM_PCLK_SAMPLE_RISING | + unsigned long flags = SOCAM_PCLK_SAMPLE_FALLING | SOCAM_HSYNC_ACTIVE_HIGH | SOCAM_VSYNC_ACTIVE_HIGH | SOCAM_DATA_ACTIVE_HIGH | SOCAM_MASTER; -- 1.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: BT656 Support and MMDC support on top of OMAP3EVM
Thanks, Vaibhav Hiremath -Original Message- From: Hiremath, Vaibhav Sent: Thursday, March 19, 2009 5:57 PM To: linux-media@vger.kernel.org Cc: linux-o...@vger.kernel.org; psp_vi...@list.ti.com - Video discussion list for PSP Video team (May contain non-TIers) Subject: [PSP_VIDEO] BT656 Support and MMDC support on top of OMAP3EVM Hi, I am getting some private requests for supporting BT656 and Multi- Media Daughter card on top of latest Kernel + Sakari's latest ISP- Camera patches/repository. So I am posting the patch supporting BT656 and MMDC support with all the review comments fixed (received from earlier posts). Please note that, hence forth I will try to avoid submitting patches on top of V4L2-int framework. The next immediate activity would be migration to sub-device framework. Sakari, How about merging these patches (BT656 support patch) into your repository so that I don't have to maintain and re-submit the patches again and again. [Hiremath, Vaibhav] Sakari, I have not heard back anything from you on this, if you don't see any issues then I request you to merge these patches into your private branch/repository. So that people will be able to use it directly. If you feel it should be done, then please let me know if you have any review comments I will try to fix immediately and provide you a patch. The patches are following this mail. Thanks, Vaibhav Hiremath -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Op 30 mrt 2009, om 16:34 heeft Hiremath, Vaibhav het volgende geschreven: Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail-thread, actually I was on vacation. I extracted a patch from that branch, but I can't figure out how to actually enable the resizer on beagleboard, overo and omapzoom, since the patches to do that seem to be missing from the branches of the ISP tree. Any clue where I can get those? Also, any test apps for the new code? AIUI dmai doesn't understand the new code yet. regards, Koen PGP.sig Description: Dit deel van het bericht is digitaal ondertekend
Re: [linuxtv-commits] [hg:v4l-dvb] v4l2-ioctl: Check format for S_PARM and G_PARM
On Sun, 29 Mar 2009, Hans Verkuil wrote: On Sunday 29 March 2009 13:03:13 Trent Piepho wrote: How does overlay depend on video capture in any way? It's perfectly reasonable for a driver to support _only_ overlay and not video capture. The zr36067 chip is only designed to support uncompressed data for video overlay for example. Allowing uncompressed video capture is a hack that the driver didn't have at one point. Ah. Live and learn. In that case the spec is out of date and needs to be updated. Do you mean there is something in the spec that makes overlay depend on video capture? Or that s/g_parm don't mention buffer types other than video capture and video output? No, I agree with the spec in that I see no use case for it. Should there be one, then I'd like to see that in an actual driver implementation and in that case the spec should be adjusted as well. How about getting the frame rate of video overlay? Works with bttv. Hmm, I grepped only on s_parm, not on g_parm. It would be nice to use s_parm with drivers like bttv to reduce the frame rate. With multi-chip capture cards running out of bus bandwidth is a big problem. Reducing the frame rate is one way to deal with it. The bt8x8 and cx2388x chips do have a temporal decimation feature and I've tried to add support for it but I never got it to work correctly. In addition, g/s_parm is only used in combination with webcams/sensors for which overlays and vbi are irrelevant. There are several drivers for non-webcams, like bttv, saa7134, and saa7146, that support g_parm. Why is returning the frame rate for video capture not valid? Why does the number of buffers used for read() mode only make sense for webcams? OK, I'd forgot to check for the usage of g_parm. My bad. There is also a default g_parm handler in video_ioctl2 that might be used if the driver doesn't provide one. I don't know what drivers actually use it. Thinking about it now, I think what makes the most sense is to use capture for VIDEO_OVERLAY, VBI_CAPTURE, and SLICED_VBI_CAPTURE. And use output for VBI_OUTPUT, SLICED_VBI_OUTPUT and VIDEO_OUTPUT_OVERLAY. You're absolutely correct. I was too hasty. Can you update the spec to reflect this? I'll try, but I hear the doc build system is quite a challenge. I also wonder whether check_fmt shouldn't check for the presence of the s_fmt callbacks instead of try_fmt since try_fmt is an optional ioctl. I noticed that too. saa7146 doesn't have a try_fmt call for vbi_capture but is apparently supposed to support it. I sent a message about that earlier. I saw that. So why not check for s_fmt instead of try_fmt? That would solve this potential problem. Because that's clearly a change that belongs in another patch. OK, great. My patch just called check_fmt() for s/g_parm. I haven't touched check_fmt(). But you're right that try_fmt is optional so it makes a bad test. Maybe it should use g_fmt? saa7146 doesn't provide a s_fmt call either for vbi capture, only g_fmt. Though maybe this is a bug in saa7146? It seems like any driver that provides g_fmt can always just use that same method for s_fmt as well and be correct. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC PATCH V2] Add camera (CSI) driver for MX1
From: Paulius Zaleckas paulius.zalec...@teltonika.lt Signed-off-by: Paulius Zaleckas paulius.zalec...@teltonika.lt --- arch/arm/mach-mx1/Makefile |7 arch/arm/mach-mx1/ksym_mx1.c| 20 + arch/arm/mach-mx1/mx1_camera_fiq.S | 35 + arch/arm/plat-mxc/include/mach/memory.h |8 arch/arm/plat-mxc/include/mach/mx1_camera.h | 39 + drivers/media/video/Kconfig |9 drivers/media/video/Makefile|1 drivers/media/video/mx1_camera.c| 838 +++ 8 files changed, 955 insertions(+), 2 deletions(-) create mode 100644 arch/arm/mach-mx1/ksym_mx1.c create mode 100644 arch/arm/mach-mx1/mx1_camera_fiq.S create mode 100644 arch/arm/plat-mxc/include/mach/mx1_camera.h create mode 100644 drivers/media/video/mx1_camera.c diff --git a/arch/arm/mach-mx1/Makefile b/arch/arm/mach-mx1/Makefile index b969719..4fbdbbd 100644 --- a/arch/arm/mach-mx1/Makefile +++ b/arch/arm/mach-mx1/Makefile @@ -4,7 +4,12 @@ # Object file lists. -obj-y += generic.o clock.o devices.o +obj-y += generic.o clock.o devices.o ksym_mx1.o + +# Support for CMOS sensor interface +ifdef CONFIG_VIDEO_MX1 +obj-y += mx1_camera_fiq.o +endif # Specific board support obj-$(CONFIG_ARCH_MX1ADS) += mx1ads.o diff --git a/arch/arm/mach-mx1/ksym_mx1.c b/arch/arm/mach-mx1/ksym_mx1.c new file mode 100644 index 000..d771b2c --- /dev/null +++ b/arch/arm/mach-mx1/ksym_mx1.c @@ -0,0 +1,20 @@ +/* + * Exported ksyms of ARCH_MX1 + * + * Copyright (C) 2008, Darius Augulis augulis.dar...@gmail.com + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#include linux/platform_device.h +#include linux/module.h + +#if defined(CONFIG_VIDEO_MX1) || defined(CONFIG_VIDEO_MX1_MODULE) +#include mach/mx1_camera.h + +/* IMX camera FIQ handler */ +EXPORT_SYMBOL(mx1_camera_sof_fiq_start); +EXPORT_SYMBOL(mx1_camera_sof_fiq_end); +#endif diff --git a/arch/arm/mach-mx1/mx1_camera_fiq.S b/arch/arm/mach-mx1/mx1_camera_fiq.S new file mode 100644 index 000..9c69aa6 --- /dev/null +++ b/arch/arm/mach-mx1/mx1_camera_fiq.S @@ -0,0 +1,35 @@ +/* + * Copyright (C) 2008 Paulius Zaleckas paulius.zalec...@teltonika.lt + * + * Based on linux/arch/arm/lib/floppydma.S + * Copyright (C) 1995, 1996 Russell King + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ +#include linux/linkage.h +#include asm/assembler.h + + .text + .global mx1_camera_sof_fiq_end + .global mx1_camera_sof_fiq_start +mx1_camera_sof_fiq_start: + @ enable dma + ldr r12, [r9] + orr r12, r12, #0x0001 + str r12, [r9] + @ unmask DMA interrupt + ldr r12, [r8] + bic r12, r12, r13 + str r12, [r8] + @ disable SOF interrupt + ldr r12, [r10] + bic r12, r12, #0x0001 + str r12, [r10] + @ clear SOF flag + mov r12, #0x0001 + str r12, [r11] + @ return from FIQ + subspc, lr, #4 +mx1_camera_sof_fiq_end: diff --git a/arch/arm/plat-mxc/include/mach/memory.h b/arch/arm/plat-mxc/include/mach/memory.h index 0b80839..c6f2170 100644 --- a/arch/arm/plat-mxc/include/mach/memory.h +++ b/arch/arm/plat-mxc/include/mach/memory.h @@ -19,4 +19,12 @@ #define PHYS_OFFSETUL(0x8000) #endif +#if defined(CONFIG_VIDEO_MX1) || defined(CONFIG_VIDEO_MX1_MODULE) +/* + * Increase size of DMA-consistent memory region. + * This is required for i.MX camera driver to capture at least four VGA frames. + */ +#define CONSISTENT_DMA_SIZE SZ_8M +#endif /* CONFIG_VIDEO_MX1 */ + #endif /* __ASM_ARCH_MXC_MEMORY_H__ */ diff --git a/arch/arm/plat-mxc/include/mach/mx1_camera.h b/arch/arm/plat-mxc/include/mach/mx1_camera.h new file mode 100644 index 000..1bf03e8 --- /dev/null +++ b/arch/arm/plat-mxc/include/mach/mx1_camera.h @@ -0,0 +1,39 @@ +/* + * mx1_camera.h - i.MX1/i.MXL camera driver header file + * + * Copyright (c) 2008, Paulius Zaleckas paulius.zalec...@teltonika.lt + * Copyright (C) 2009, Darius Augulis augulis.dar...@gmail.com + * + * Based on PXA camera.h file: + * Copyright (C) 2003, Intel Corporation + * Copyright (C) 2008, Guennadi Liakhovetski ker...@pengutronix.de + * + * This program is free software; you can redistribute it and/or modify + * it under the terms of the GNU General Public License version 2 as + * published by the Free Software Foundation. + */ + +#ifndef __ASM_ARCH_CAMERA_H_ +#define __ASM_ARCH_CAMERA_H_ + +#define MX1_CAMERA_DP
Fw: patch: s2255drv driver removal problem fixed
C/C to the right mailing list, to allow Patchwork to catch this.
Forwarded message:
Date: Mon, 30 Mar 2009 07:59:56 -0700 (PDT)
From: Dean A. d...@sensoray.com
To: video4linux-l...@redhat.com, mche...@infradead.org
Cc: e...@redhat.com, erro...@gmail.com, marcin.slus...@gmail.com
Subject: patch: s2255drv driver removal problem fixed
From: Dean Anderson d...@sensoray.com
This patch fixes kfree problem on driver removal, fixes streamoff problem
and removes unnecessary videobuf_waiton from free_buffer function.
Signed-off-by: Dean Anderson d...@sensoray.com
--- linux/drivers/media/video/s2255drv.c.orig 2009-03-30 07:30:25.0
-0700
+++ linux/drivers/media/video/s2255drv.c2009-03-30 07:44:32.0
-0700
@@ -723,7 +723,6 @@
{
dprintk(4, %s\n, __func__);
- videobuf_waiton(buf-vb, 0, 0);
videobuf_vmalloc_free(buf-vb);
buf-vb.state = VIDEOBUF_NEEDS_INIT;
}
@@ -1325,7 +1324,6 @@
static int vidioc_streamoff(struct file *file, void *priv, enum v4l2_buf_type
i)
{
- int res;
struct s2255_fh *fh = priv;
struct s2255_dev *dev = fh-dev;
@@ -1339,9 +1337,7 @@
return -EINVAL;
}
s2255_stop_acquire(dev, fh-channel);
- res = videobuf_streamoff(fh-vb_vidq);
- if (res 0)
- return res;
+ videobuf_streamoff(fh-vb_vidq);
res_free(dev, fh);
return 0;
}
@@ -1708,13 +1704,13 @@
kfree(dev-fw_data);
usb_put_dev(dev-udev);
dprintk(1, %s, __func__);
- kfree(dev);
while (!list_empty(s2255_devlist)) {
list = s2255_devlist.next;
list_del(list);
}
mutex_unlock(dev-open_lock);
+ kfree(dev);
}
static int s2255_close(struct file *file)
Cheers,
Mauro
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Patch for 2.6.29 stable series: remove #ifdef MODULE nonsense
Hi Mike, The attached patch should be queued for 2.6.29.X. It corresponds to changeset 11098 (v4l2-common: remove incorrect MODULE test) in our v4l-dvb tree and is part of the initial set of git patches going into 2.6.30. Without this patch loading ivtv as a module while v4l2-common is compiled into the kernel will cause a delayed load of the i2c modules that ivtv needs since request_module is never called directly. While it is nice to see the delayed load in action, it is not so nice in that ivtv fails to do a lot of necessary i2c initializations and will oops later on with a division-by-zero. Thanks to Mark Lord for reporting this and helping me figure out what was wrong. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG --- drivers/media/video/v4l2-common.c.orig 2009-03-30 18:25:24.0 +0200 +++ drivers/media/video/v4l2-common.c 2009-03-30 18:27:04.0 +0200 @@ -910,10 +910,10 @@ struct i2c_board_info info; BUG_ON(!dev); -#ifdef MODULE + if (module_name) request_module(module_name); -#endif + /* Setup the i2c board info with the device type and the device address. */ memset(info, 0, sizeof(info)); @@ -958,10 +958,10 @@ struct i2c_board_info info; BUG_ON(!dev); -#ifdef MODULE + if (module_name) request_module(module_name); -#endif + /* Setup the i2c board info with the device type and the device address. */ memset(info, 0, sizeof(info));
Re: Patch for 2.6.29 stable series: remove #ifdef MODULE nonsense
Hans Verkuil wrote: Hi Mike, The attached patch should be queued for 2.6.29.X. It corresponds to changeset 11098 (v4l2-common: remove incorrect MODULE test) in our v4l-dvb tree and is part of the initial set of git patches going into 2.6.30. Without this patch loading ivtv as a module while v4l2-common is compiled into the kernel will cause a delayed load of the i2c modules that ivtv needs since request_module is never called directly. While it is nice to see the delayed load in action, it is not so nice in that ivtv fails to do a lot of necessary i2c initializations and will oops later on with a division-by-zero. Thanks to Mark Lord for reporting this and helping me figure out what was wrong. Regards, Hans Got it, thanks. In the future, please point to hash codes rather than revision ID's -- my rev IDs are not the same as yours, but hash codes are always unique. I'll queue this the moment Linus merges Mauro's pending request. Cheers, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Patch for 2.6.29 stable series: remove #ifdef MODULE nonsense
Michael Krufky wrote:
Hans Verkuil wrote:
Hi Mike,
The attached patch should be queued for 2.6.29.X. It corresponds to
changeset 11098 (v4l2-common: remove incorrect MODULE test) in our
v4l-dvb tree and is part of the initial set of git patches going into
2.6.30.
Without this patch loading ivtv as a module while v4l2-common is
compiled into the kernel will cause a delayed load of the i2c modules
that ivtv needs since request_module is never called directly.
While it is nice to see the delayed load in action, it is not so nice
in that ivtv fails to do a lot of necessary i2c initializations and
will oops later on with a division-by-zero.
Thanks to Mark Lord for reporting this and helping me figure out what
was wrong.
Regards,
Hans
Got it, thanks.
In the future, please point to hash codes rather than revision ID's --
my rev IDs are not the same as yours, but hash codes are always unique.
I'll queue this the moment Linus merges Mauro's pending request.
..
Can either of you guys figure out how to get this patch (or something
equivalent) merged? It's been pending for some time now.
Thanks.
Message-ID: 49884ccb.3070...@rtr.ca
Date: Tue, 03 Feb 2009 08:55:23 -0500
From: Mark Lord l...@rtr.ca
MIME-Version: 1.0
To: video4linux-l...@redhat.com, Linux Kernel linux-ker...@vger.kernel.org
Subject: [PATCH] ir-kbd-i2c: support Hauppauge HVR-1600 R/C port
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
(resending, with video4linux-l...@redhat.com this time)
Update the ir-kbd-i2c driver to recognize the remote-control port
on the Hauppauge HV-1600 hybrid tuner card.
Signed-off-by: Mark Lord ml...@pobox.com
--- old/drivers/media/video/ir-kbd-i2c.c2008-12-24 18:26:37.0
-0500
+++ linux/drivers/media/video/ir-kbd-i2c.c 2009-02-01 13:08:19.0
-0500
@@ -354,6 +354,11 @@
} else {
ir_codes= ir_codes_rc5_tv;
}
+ } else if (adap-id == I2C_HW_B_CX2341X) {
+ name= Hauppauge;
+ ir_type = IR_TYPE_RC5;
+ ir-get_key = get_key_haup_xvr;
+ ir_codes= ir_codes_hauppauge_new;
} else {
/* Handled by saa7134-input */
name= SAA713x remote;
@@ -449,7 +454,7 @@
That's why we probe 0x1a (~0x34) first. CB
*/
- static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30, -1};
+ static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30, 0x71,
-1};
static const int probe_saa7134[] = { 0x7a, 0x47, 0x71, 0x2d, -1 };
static const int probe_em28XX[] = { 0x30, 0x47, -1 };
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -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: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
On Monday 30 March 2009 16:34:42 Hiremath, Vaibhav wrote: Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail-thread, actually I was on vacation. As proposed by Sakari, I do agree with the approach of having V4L2 interface for memory-to-memory operation of the ISP (like resizer and previewer), but I would like to bring some important aspects/issues here - - Some drawbacks of V4L2-buf layer framework for such kind of devices - Need for backward compatibility. Drawbacks for V4L2-Buf layer - - 1} In case of resizer driver, the input buffer will always be different than output buffer. In case of Mmapped buffer there is no issue, since driver allocates maximum of input and output. User doesn't have control on this, although there is loss of memory from system point of view. In case of User Pointer Exchange, User would expect and may allocate different sizes of buffers for input and output which V4L2-buf layer doesn't support with single queue. And to address this, I think here we need to have either of following approaches - - Use two separate buffer queues, one for input and another for output. - Or hack the driver for v4l2_buffer, internally using different buffer params for input and output. [Not recommended] Please note that sometimes application receives buffers from another driver or from some codecs engine that's why input and output buffer will never be of same size. 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to give low level details about this - When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages. In 'get_user_pages' it checks for IOMEM flag and returns error, which is expected behavior from Kernel point of view. We are trying to map buffer which is already mapped to kernel by another driver. One thing I am not able to understand, how nobody came across such use-case which is very common. And to address this issue we need to add support for IOMEM in V4L2-buf layer. NOTE: Currently both of these issues have been addressed as a custom implementation for our internal use case. Backward Compatibility - --- This is an important aspect, since similar hardware modules are available on Davinci as well as on OMAP and their driver interface is completely different. On Davinci, resizer driver is supported through plane char driver interface which handles all data/buffer processing and control paths. It maintains internal queue for priority of resizing tasks and stuff. The driver is present under /drivers/char/Davinci. Here I feel, V4L2 way is better, since all image processing drivers should go under drivers/media/video/. And again we can make use of readily available V4L2 framework interface for data and control path to manage buffers. We should enhance V4L2 framework to support such devices. Proposed Required Changes - -- I am putting some high level changes required to be done for supporting such devices - - Enhancement in V4L2-buf layer for above issues - Will be directly using sub-device frame-work and have to enhance it to support such devices. - Below are the parameters we need to configure for Resizer from user application - __s32 in_hsize;/* input frame horizontal size.*/ __s32 in_vsize;/* input frame vertical size */ __s32 in_pitch;/* offset between 2 rows of input frame.*/ __s32 inptyp; /* for determining 16 bit or 8 bit data.*/ __s32 vert_starting_pixel; /* vertical starting pixel in input.*/ __s32 horz_starting_pixel; /* horizontal starting pixel in input.*/ __s32 cbilin; /* filter with luma or bi-linear interpolation.*/ __s32 pix_fmt; /* UYVY or YUYV */ __s32 out_hsize; /* output frame horizontal size. */ __s32 out_vsize; /* output frame vertical size.*/ __s32 out_pitch; /* offset between 2 rows of output frame.*/ __s32 hstph; /* for specifying horizontal starting phase.*/ __s32 vstph; /* for specifying vertical starting phase.*/ __u16 tap4filt_coeffs[32]; /* horizontal filtercoefficients.*/ __u16 tap7filt_coeffs[32]; /* vertical filter coefficients. */ struct rsz_yenh yenh_params; (Pasted from previous patches posted by Sergio) Putting one sample proposal using VIDIOC_S_FMT - APPROACH 1 - -- Either we can add this under struct v4l2_format or need to enhance stuct v4l2_crop to support such device. We can use 'VIDIOC_S_FMT' ioctl to configure the resizer
Re: bttv ir patch from Mark Lord
Michael Krufky wrote:
Mark Lord wrote:
Michael Krufky wrote:
Hans Verkuil wrote:
Hi Mike,
The attached patch should be queued for 2.6.29.X. It corresponds to
changeset 11098 (v4l2-common: remove incorrect MODULE test) in our
v4l-dvb tree and is part of the initial set of git patches going
into 2.6.30.
Without this patch loading ivtv as a module while v4l2-common is
compiled into the kernel will cause a delayed load of the i2c
modules that ivtv needs since request_module is never called directly.
While it is nice to see the delayed load in action, it is not so
nice in that ivtv fails to do a lot of necessary i2c initializations
and will oops later on with a division-by-zero.
Thanks to Mark Lord for reporting this and helping me figure out
what was wrong.
Regards,
Hans
Got it, thanks.
In the future, please point to hash codes rather than revision ID's
-- my rev IDs are not the same as yours, but hash codes are always
unique.
I'll queue this the moment Linus merges Mauro's pending request.
..
Can either of you guys figure out how to get this patch (or something
equivalent) merged? It's been pending for some time now.
Thanks.
Message-ID: 49884ccb.3070...@rtr.ca
Date: Tue, 03 Feb 2009 08:55:23 -0500
From: Mark Lord l...@rtr.ca
MIME-Version: 1.0
To: video4linux-l...@redhat.com, Linux Kernel
linux-ker...@vger.kernel.org
Subject: [PATCH] ir-kbd-i2c: support Hauppauge HVR-1600 R/C port
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
(resending, with video4linux-l...@redhat.com this time)
Update the ir-kbd-i2c driver to recognize the remote-control port
on the Hauppauge HV-1600 hybrid tuner card.
Signed-off-by: Mark Lord ml...@pobox.com
--- old/drivers/media/video/ir-kbd-i2c.c2008-12-24
18:26:37.0 -0500
+++ linux/drivers/media/video/ir-kbd-i2c.c2009-02-01
13:08:19.0 -0500
@@ -354,6 +354,11 @@
} else {
ir_codes= ir_codes_rc5_tv;
}
+} else if (adap-id == I2C_HW_B_CX2341X) {
+name= Hauppauge;
+ir_type = IR_TYPE_RC5;
+ir-get_key = get_key_haup_xvr;
+ir_codes= ir_codes_hauppauge_new;
} else {
/* Handled by saa7134-input */
name= SAA713x remote;
@@ -449,7 +454,7 @@
That's why we probe 0x1a (~0x34) first. CB
*/
-static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30, -1};
+static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30,
0x71, -1};
static const int probe_saa7134[] = { 0x7a, 0x47, 0x71, 0x2d, -1 };
static const int probe_em28XX[] = { 0x30, 0x47, -1 };
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -1 };
looks like a zilog, and you should use LIRC for that.
..
It's a Hauppauge remote port, just like the one on the (supported) PVR-250.
And I don't want the LIRC monstrosity when there's a perfectly good
kernel driver to run it directly. The patch does not prevent others
from using LIRC.
PLEASE DO NOT HIJAAK unrelated threads with unrelated emails.
..
Hijack, not HIJAAK. :)
thanks.
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[review] dsbr100 radio: convert to to v4l2_device
Hello, Hans and Douglas, and others
This is review version for dsbr100 radio.
Hans, if you can a bit of free time to look and make comments it will be
very good.
I'm still confused about messages like v4l2_err and about unplugging
procedure.
I tested it with my radio device and it works(unplugging works also
without oopses).
Douglas, if you can find some free time to test patch it will be very
good too :)
--
diff -r f86c84534cb4 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Mar 29 22:54:35 2009 -0300
+++ b/linux/drivers/media/radio/dsbr100.c Mon Mar 30 21:00:51 2009 +0400
@@ -32,6 +32,9 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
History:
+
+ Version 0.45:
+ Converted to v4l2_device.
Version 0.44:
Add suspend/resume functions, fix unplug of device,
@@ -88,7 +91,7 @@
#include linux/slab.h
#include linux/input.h
#include linux/videodev2.h
-#include media/v4l2-common.h
+#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include linux/usb.h
#include compat.h
@@ -98,39 +101,8 @@
*/
#include linux/version.h /* for KERNEL_VERSION MACRO */
-#define DRIVER_VERSION v0.44
-#define RADIO_VERSION KERNEL_VERSION(0, 4, 4)
-
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = Mute,
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- },
-/* HINT: the disabled controls are only here to satify kradio and such apps */
- { .id = V4L2_CID_AUDIO_VOLUME,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BALANCE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BASS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_TREBLE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_LOUDNESS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
-};
+#define DRIVER_VERSION v0.45
+#define RADIO_VERSION KERNEL_VERSION(0, 4, 5)
#define DRIVER_AUTHOR Markus Demleitner msdem...@tucana.harvard.edu
#define DRIVER_DESC D-Link DSB-R100 USB FM radio driver
@@ -168,6 +140,8 @@
struct dsbr100_device {
struct usb_device *usbdev;
struct video_device videodev;
+ struct v4l2_device v4l2_dev;
+
u8 *transfer_buffer;
struct mutex lock; /* buffer locking */
int curfreq;
@@ -387,6 +361,7 @@
mutex_unlock(radio-lock);
video_unregister_device(radio-videodev);
+ v4l2_device_unregister(radio-v4l2_dev);
}
@@ -482,14 +457,11 @@
static int vidioc_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *qc)
{
- int i;
+ switch (qc-id) {
+ case V4L2_CID_AUDIO_MUTE:
+ return v4l2_ctrl_query_fill(qc, 0, 1, 1, 1);
+ }
- for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
- if (qc-id qc-id == radio_qctrl[i].id) {
- memcpy(qc, (radio_qctrl[i]), sizeof(*qc));
- return 0;
- }
- }
return -EINVAL;
}
@@ -686,22 +658,15 @@
.vidioc_s_input = vidioc_s_input,
};
-/* V4L2 interface */
-static struct video_device dsbr100_videodev_data = {
- .name = D-Link DSB-R 100,
- .fops = usb_dsbr100_fops,
- .ioctl_ops = usb_dsbr100_ioctl_ops,
- .release= usb_dsbr100_video_device_release,
-};
-
/* check if the device is present and register with v4l and usb if it is */
static int usb_dsbr100_probe(struct usb_interface *intf,
const struct usb_device_id *id)
{
struct dsbr100_device *radio;
+ struct v4l2_device *v4l2_dev;
int retval;
- radio = kmalloc(sizeof(struct dsbr100_device), GFP_KERNEL);
+ radio = kzalloc(sizeof(struct dsbr100_device), GFP_KERNEL);
if (!radio)
return -ENOMEM;
@@ -713,17 +678,35 @@
return -ENOMEM;
}
+ v4l2_dev = radio-v4l2_dev;
+ strlcpy(v4l2_dev-name, dsbr100, sizeof(v4l2_dev-name));
+
+ retval = v4l2_device_register(intf-dev, v4l2_dev);
+ if (retval 0) {
+ v4l2_err(v4l2_dev, couldn't register v4l2_device\n);
+ kfree(radio-transfer_buffer);
+ kfree(radio);
+ return retval;
+ }
+
+ strlcpy(radio-videodev.name, v4l2_dev-name,
sizeof(radio-videodev.name));
+ radio-videodev.v4l2_dev = v4l2_dev;
+ radio-videodev.fops = usb_dsbr100_fops;
+
Re: bttv ir patch from Mark Lord
On Monday 30 March 2009 19:06:28 Mark Lord wrote:
Michael Krufky wrote:
Mark Lord wrote:
Michael Krufky wrote:
Hans Verkuil wrote:
Hi Mike,
The attached patch should be queued for 2.6.29.X. It corresponds to
changeset 11098 (v4l2-common: remove incorrect MODULE test) in our
v4l-dvb tree and is part of the initial set of git patches going
into 2.6.30.
Without this patch loading ivtv as a module while v4l2-common is
compiled into the kernel will cause a delayed load of the i2c
modules that ivtv needs since request_module is never called
directly.
While it is nice to see the delayed load in action, it is not so
nice in that ivtv fails to do a lot of necessary i2c initializations
and will oops later on with a division-by-zero.
Thanks to Mark Lord for reporting this and helping me figure out
what was wrong.
Regards,
Hans
Got it, thanks.
In the future, please point to hash codes rather than revision ID's
-- my rev IDs are not the same as yours, but hash codes are always
unique.
I'll queue this the moment Linus merges Mauro's pending request.
..
Can either of you guys figure out how to get this patch (or something
equivalent) merged? It's been pending for some time now.
Thanks.
Message-ID: 49884ccb.3070...@rtr.ca
Date: Tue, 03 Feb 2009 08:55:23 -0500
From: Mark Lord l...@rtr.ca
MIME-Version: 1.0
To: video4linux-l...@redhat.com, Linux Kernel
linux-ker...@vger.kernel.org Subject: [PATCH] ir-kbd-i2c: support
Hauppauge HVR-1600 R/C port Content-Type: text/plain; charset=UTF-8;
format=flowed
Content-Transfer-Encoding: 7bit
(resending, with video4linux-l...@redhat.com this time)
Update the ir-kbd-i2c driver to recognize the remote-control port
on the Hauppauge HV-1600 hybrid tuner card.
Signed-off-by: Mark Lord ml...@pobox.com
--- old/drivers/media/video/ir-kbd-i2c.c2008-12-24
18:26:37.0 -0500 +++ linux/drivers/media/video/ir-kbd-i2c.c
2009-02-01 13:08:19.0 -0500 @@ -354,6 +354,11 @@
} else {
ir_codes= ir_codes_rc5_tv;
}
+} else if (adap-id == I2C_HW_B_CX2341X) {
+name= Hauppauge;
+ir_type = IR_TYPE_RC5;
+ir-get_key = get_key_haup_xvr;
+ir_codes= ir_codes_hauppauge_new;
} else {
/* Handled by saa7134-input */
name= SAA713x remote;
@@ -449,7 +454,7 @@
That's why we probe 0x1a (~0x34) first. CB
*/
-static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64, 0x30,
-1}; +static const int probe_bttv[] = { 0x1a, 0x18, 0x4b, 0x64,
0x30, 0x71, -1}; static const int probe_saa7134[] = { 0x7a, 0x47,
0x71, 0x2d, -1 }; static const int probe_em28XX[] = { 0x30, 0x47, -1
};
static const int probe_cx88[] = { 0x18, 0x6b, 0x71, -1 };
looks like a zilog, and you should use LIRC for that.
..
It's a Hauppauge remote port, just like the one on the (supported)
PVR-250. And I don't want the LIRC monstrosity when there's a perfectly
good kernel driver to run it directly. The patch does not prevent others
from using LIRC.
PLEASE DO NOT HIJAAK unrelated threads with unrelated emails.
..
Hijack, not HIJAAK. :)
Resending to copy linux-kernel again.
Please do not edit/delete lists from the email headers, thanks.
thanks.
It's best to wait a bit. Jean Delvare is working on this ir-kbd-i2c driver
right now and when he's finished it should be much easier to add this. Most
importantly you can add this new i2c address to the cx18 driver rather than
add it to the probe_bttv list, which is rather overloaded anyway.
He should be finished within 1-3 weeks I guess. Probably sooner rather than
later. Just watch the linux-media list for it.
Regards,
Hans
--
Hans Verkuil - video4linux developer - sponsored by TANDBERG
--
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: bttv ir patch from Mark Lord
Hans Verkuil wrote: It's best to wait a bit. Jean Delvare is working on this ir-kbd-i2c driver right now and when he's finished it should be much easier to add this. Most importantly you can add this new i2c address to the cx18 driver rather than add it to the probe_bttv list, which is rather overloaded anyway. He should be finished within 1-3 weeks I guess. Probably sooner rather than later. Just watch the linux-media list for it. .. Thanks. I'll just watch for it arriving upstream in 2.6.31 (?) then, if the current ir-kbd-i2c patch doesn't end up in 2.6.30 already. Good idea on the cleanup in there, too. It was looking a bit tattered around the edges, and my patch doesn't really help much with that aspect. :) Cheers -- 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] v4l-dvb daily build 2.6.22 and up: OK, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Mon Mar 30 19:00:06 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11317:ff5430b54ac2 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29-armv5: OK linux-2.6.27-armv5-ixp: OK linux-2.6.28-armv5-ixp: OK linux-2.6.29-armv5-ixp: OK linux-2.6.28-armv5-omap2: OK linux-2.6.29-armv5-omap2: OK linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: OK linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK linux-2.6.26-i686: OK linux-2.6.27-i686: OK linux-2.6.28-i686: OK linux-2.6.29-i686: OK linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29-m32r: OK linux-2.6.22.19-mips: OK linux-2.6.26-mips: OK linux-2.6.27-mips: OK linux-2.6.28-mips: OK linux-2.6.29-mips: OK linux-2.6.27-powerpc64: OK linux-2.6.28-powerpc64: OK linux-2.6.29-powerpc64: OK linux-2.6.22.19-x86_64: OK linux-2.6.23.12-x86_64: OK linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29-x86_64: OK fw/apps: OK sparse (linux-2.6.29): ERRORS linux-2.6.16.61-i686: WARNINGS linux-2.6.17.14-i686: OK linux-2.6.18.8-i686: OK linux-2.6.19.5-i686: OK linux-2.6.20.21-i686: OK linux-2.6.21.7-i686: OK linux-2.6.16.61-x86_64: WARNINGS linux-2.6.17.14-x86_64: OK linux-2.6.18.8-x86_64: OK linux-2.6.19.5-x86_64: OK linux-2.6.20.21-x86_64: OK linux-2.6.21.7-x86_64: OK Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Monday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- 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: AverMedia Volar Black HD (A850)
hei, Could someone please test this asap? I am still hoping I can get this 2.6.30 and there is not too much time... http://linuxtv.org/hg/~anttip/af9015_aver_a850/ It must not be big issue anymore to get this working... regards Antti -- http://palosaari.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: AverMedia Volar Black HD (A850)
Sorry, I was at work today. I just downloaded the latest version. It works a lot better than the previous one (the device_nums are correct in the af9015.c and it seems the frontend is correctly initialized now). Here is the /var/log/messages : Mar 30 21:30:26 blastor kernel: [ 2829.680263] usb 5-4.4: new high speed USB device using ehci_hcd and address 11 Mar 30 21:30:26 blastor kernel: [ 2829.776572] usb 5-4.4: configuration #1 chosen from 1 choice Mar 30 21:30:26 blastor kernel: [ 2829.777269] af9015_usb_probe: interface:0 Mar 30 21:30:26 blastor kernel: [ 2829.781867] af9015_read_config: IR mode:0 Mar 30 21:30:26 blastor kernel: [ 2829.786071] af9015_read_config: TS mode:1 Mar 30 21:30:26 blastor kernel: [ 2829.804042] af9015_read_config: [0] xtal:2 set adc_clock:28000 Mar 30 21:30:26 blastor kernel: [ 2829.806990] af9015_read_config: [0] IF1:36125 Mar 30 21:30:26 blastor kernel: [ 2829.809859] af9015_read_config: [0] MT2060 IF1:0 Mar 30 21:30:26 blastor kernel: [ 2829.811355] af9015_read_config: [0] tuner id:13 Mar 30 21:30:26 blastor kernel: [ 2829.812861] af9015_read_config: [1] xtal:2 set adc_clock:28000 Mar 30 21:30:26 blastor kernel: [ 2829.815734] af9015_read_config: [1] IF1:36125 Mar 30 21:30:26 blastor kernel: [ 2829.818731] af9015_read_config: [1] MT2060 IF1:1220 Mar 30 21:30:26 blastor kernel: [ 2829.820234] af9015_read_config: [1] tuner id:130 Mar 30 21:30:26 blastor kernel: [ 2829.820239] af9015_read_config: ugly and broken AverMedia A850 device detected, will hack configuration... Mar 30 21:30:26 blastor kernel: [ 2829.820611] af9015_identify_state: reply:01 Mar 30 21:30:26 blastor kernel: [ 2829.820616] dvb-usb: found a 'AVerMedia A850' in cold state, will try to load a firmware Mar 30 21:30:26 blastor kernel: [ 2829.820619] firmware: requesting dvb-usb-af9015.fw Mar 30 21:30:26 blastor kernel: [ 2829.839678] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' Mar 30 21:30:26 blastor kernel: [ 2829.839686] af9015_download_firmware: Mar 30 21:30:26 blastor kernel: [ 2829.927037] dvb-usb: found a 'AVerMedia A850' in warm state. Mar 30 21:30:26 blastor kernel: [ 2829.927130] i2c-adapter i2c-5: SMBus Quick command not supported, can't probe for chips Mar 30 21:30:26 blastor kernel: [ 2829.927139] i2c-adapter i2c-5: SMBus Quick command not supported, can't probe for chips Mar 30 21:30:26 blastor kernel: [ 2829.927152] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Mar 30 21:30:26 blastor kernel: [ 2829.929261] DVB: registering new adapter (AVerMedia A850) Mar 30 21:30:26 blastor kernel: [ 2829.929635] af9015_af9013_frontend_attach: init I2C Mar 30 21:30:26 blastor kernel: [ 2829.929638] af9015_i2c_init: Mar 30 21:30:26 blastor kernel: [ 2829.929676] i2c-adapter i2c-6: SMBus Quick command not supported, can't probe for chips Mar 30 21:30:26 blastor kernel: [ 2829.929686] i2c-adapter i2c-6: SMBus Quick command not supported, can't probe for chips Mar 30 21:30:26 blastor kernel: [ 2829.964978] 00: 2c 8f a3 0b 00 00 00 00 ca 07 0a 85 01 01 01 02 Mar 30 21:30:26 blastor kernel: [ 2829.988831] 10: 03 80 00 fa fa 10 40 ef 00 30 31 30 31 30 37 30 Mar 30 21:30:26 blastor kernel: [ 2830.012576] 20: 33 30 37 30 30 30 30 31 ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.036627] 30: 01 01 38 01 00 08 02 01 1d 8d 00 00 0d ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.060015] 40: ff ff ff ff ff 08 02 00 1d 8d c4 04 82 ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.083685] 50: ff ff ff ff ff 26 00 00 04 03 09 04 14 03 41 00 Mar 30 21:30:26 blastor kernel: [ 2830.107431] 60: 56 00 65 00 72 00 4d 00 65 00 64 00 69 00 61 00 Mar 30 21:30:26 blastor kernel: [ 2830.131178] 70: 14 03 41 00 38 00 35 00 30 00 20 00 44 00 56 00 Mar 30 21:30:26 blastor kernel: [ 2830.155049] 80: 42 00 54 00 20 03 33 00 30 00 31 00 34 00 37 00 Mar 30 21:30:26 blastor kernel: [ 2830.179420] 90: 35 00 34 00 30 00 30 00 37 00 33 00 36 00 30 00 Mar 30 21:30:26 blastor kernel: [ 2830.203166] a0: 30 00 30 00 00 ff ff ff ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.227038] b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.250412] c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.274282] d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.297904] e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.321900] f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 30 21:30:26 blastor kernel: [ 2830.324902] af9013: firmware version:4.95.0 Mar 30 21:30:26 blastor kernel: [ 2830.330900] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... Mar 30 21:30:26 blastor kernel: [ 2830.330957] af9015_tuner_attach: Mar 30 21:30:26 blastor kernel: [ 2830.331167] MXL5005S: Attached at address 0xc6 Mar 30 21:30:26 blastor kernel: [ 2830.331172] dvb-usb: AVerMedia A850
Re: AverMedia Volar Black HD (A850)
Olivier MENUEL wrote: Sorry, I was at work today. I just downloaded the latest version. It works a lot better than the previous one (the device_nums are correct in the af9015.c and it seems the frontend is correctly initialized now). Here is the /var/log/messages : Looks just correct! I tried a scan with kaffeine : the blue light is on when scanning (which is a pretty good news), but I can't find any channels : the signal goes up to 85% but SNR stays at 0% and no channel is found ... hmm, not AverMedia A850 issue. I should look this later... But I tried a scan with the scan command line and everything worked fine ! I found all channels and it seems to work really fine with vlc !!! :) Now I need some more tests. I can see from logs GPIO0 and GPIO1 are set differently. 1) reference design GPIOs: If that works you don't need to test more. http://linuxtv.org/hg/~anttip/af9015_aver_a850_2/ 2) GPIO1 tuner looks like tuner is connected to this GPIO If that works no need to test more. http://linuxtv.org/hg/~anttip/af9015_aver_a850_GPIO1/ 3) GPIO0 tuner last test if nothing before works http://linuxtv.org/hg/~anttip/af9015_aver_a850_GPIO0/ regards Antti -- http://palosaari.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: Problems with Hauppauge HVR 1600 and cx18 driver
On Sun, 29 Mar 2009, Andy Walls wrote:
On Sun, 2009-03-29 at 01:24 -0700, Trent Piepho wrote:
wait_event() should take care of this. wait_event(q, test) basically does:
for(;;) {
// point A
add_me_to_waitqueue(q);
set_current_state(TASK_UNINTERRUPTIBLE);
if (test)
break;
// point B
schedule();
}
clean_up_wait_stuff();
As you know, the condition is checked even before this loop is entered,
to avoid even being even added to a waitqueue. (Thank God for ctags...)
I think the initial check of the condition is just an optimization and
everything will still work without it. Seeing as all this is inlined, I
wonder if it's a good optimization...
As you may have noticed, the original code was using
wait_event_timeout() before like this:
CX18_DEBUG_HI_IRQ(sending interrupt SW1: %x to send %s\n,
irq, info-name);
cx18_write_reg_expect(cx, irq, SW1_INT_SET, irq, irq);
ret = wait_event_timeout(
*waitq,
cx18_readl(cx, mb-ack) == cx18_readl(cx,
mb-request),
timeout);
Because waiting for the ack back is the right thing to do, but certainly
waiting too long is not warranted.
This gave me the occasional log message like this:
1: cx18-0: irq: sending interrupt SW1: 8 to send CX18_CPU_DE_SET_MDL
2: cx18-0: irq: received interrupts SW1: 0 SW2: 8 HW2: 0
3: cx18-0: irq: received interrupts SW1: 1 SW2: 0 HW2: 0
4: cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 10 msecs
for RPU acknowledgement
Where line 1 is the driver notifiying the firmware with a SW1 interrupt.
Line 2 is the firmware responding back to the cx18_irq_handler() with
the Ack interrupt in SW2 (the flags match, 8 8, by design).
Line 3 is an unrelated incoming video buffer notification for the cx18
driver.
Line 4 is the wait_event_timeout() timing out.
Could it be that the wait_event doesn't actually run and check its
condition until _after_ line 3? In that case SW2 != 8 and so it goes back
to sleep? Calling wake_up() just makes the processes on the waitq
runnable, they don't actually run until later, possibly much later.
If your event occurs and wake_up() is called at point A, then the test
should be true when it's checked and schedule() is never called. If the
event happens at point B, then the process' state will have been changed to
TASK_RUNNING by wake_up(), remember it's already on the waitqueue at this
point, and schedule() won't sleep.
OK, for some reason, I thought schedule() and schedule_timeout() would
go to sleep anyway.
AFAIK, they'll still cause the kernel schedule a process. Maybe a
different process. But the original process is still in TASK_RUNNING state
and so still in the run queue and will get run again. If it was in
TASK_(UN)INTERRUPTIBLE state then it wouldn't be in the run queue and
wouldn't run again until something woke it up.
I think what's probably happening is the test, cx18_readl(cx, mb-ack) ==
cx18_readl(cx, mb-request), is somehow not true even though the ack has
been received.
A PCI bus read error could be the culprit here. That's the only thing I
can think of. We only get one notification via IRQ from the firmware.
Maybe a new request was added?
No, I lock the respective epu2apu or epu2cpu mailboxes respectively with
a mutex.
But in your log:
1: cx18-0: irq: sending interrupt SW1: 8 to send CX18_CPU_DE_SET_MDL
2: cx18-0: irq: received interrupts SW1: 0 SW2: 8 HW2: 0
3: cx18-0: irq: received interrupts SW1: 1 SW2: 0 HW2: 0
4: cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 10 msecs
for RPU acknowledgement
Isn't the wait_event_timeout() waiting until line 4? And doesn't line 3
mean something has changed the registers? Changed them before the
wait_event finished?
I think calling wait_event()'s with something that tests a hardware
register is a little iffy. It's better if the irq handler sets some driver
state flag (atomically!) that indicates the event you were waiting for has
happened and then you check that flag.
I was toying with setting an atomic while in the IRQ handler. But then
I realized when we get the ack interrupt, the firmware should actually
be done. So really the wakeup() is the only indicator I really need.
Checking for ack == req is just a formality I guess.
If you use an interruptible timeout, then you could get interrupted with a
signal before the irq handler has woken you.
There wasn't a wait_timeout(), so I had tried something like this in my
first iteration:
It's called sleep_on_timeout(q, timeout).
--
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
Status of analog support for DViCO FusionHDTV7 Dual Express?
From this thread: http://www.linuxtv.org/pipermail/linux-dvb/2008-September/029432.html It appears that progress was being made on the analog support for the DViCO FusionHDTV7 Dual Express, but the chain of emails appears to have stopped. I just purchased one of these devices and I was wondering what I can do to help get analog support up and running. Any suggestions? Thanks, Dave -- 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/4] ARM: DaVinci: DM646x Video: Add VPIF display driver
On Mon, 30 Mar 2009, Hans Verkuil wrote:
On Thursday 26 March 2009 14:22:32 Chaithrika U S wrote:
+ /* one field is displayed configure the next
+ frame if it is available else hold on current
+ frame */
Comment isn't in standard format with *'s on the side. If you split this
into multiple functions like Hans suggested it wouldn't be indented so
much.
+static int vpif_enum_fmt_vid_out(struct file *file, void *priv,
+ struct v4l2_fmtdesc *fmt)
+{
+ unsigned int index = 0;
+
+ if (fmt-index != 0) {
+ v4l2_err(vpif_obj.v4l2_dev, Invalid format index\n);
+ return -EINVAL;
+ }
+
+ /* Fill in the information about format */
+ index = fmt-index;
+ memset(fmt, 0, sizeof(*fmt));
For most if not all of these functions v4l2_ioctl2 will take care of zeroing
the structs.
It is supposed to be all of them. If there are any I missed let me know so
I can fix it.
+static int vpif_g_fmt_vid_out(struct file *file, void *priv,
+ struct v4l2_format *fmt)
+{
[...]
+ /* Check the validity of the buffer type */
+ if (common-fmt.type != fmt-type)
+ return -EINVAL;
+
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT != fmt-type) {
+ if (vid_ch-std_info.vbi_supported == 0)
+ return -EINVAL;
+ }
All XXX_fmt_vid_out methods will only be called with fmt-type equal to
VIDEO_OUTPUT. You don't need to check.
+static int vpif_s_fmt_vid_out(struct file *file, void *priv,
+ struct v4l2_format *fmt)
+{
+ if (V4L2_BUF_TYPE_VIDEO_OUTPUT == fmt-type) {
Don't need this check.
+ struct v4l2_pix_format *pixfmt = fmt-fmt.pix;
+ /* Check for valid field format */
+ ret = vpif_check_format(channel, pixfmt);
+ if (ret)
+ return ret;
Rather than fail if the format requested isn't acceptable to the driver,
you should modify the requested format to something that is. For example,
if you need an even number of lines and they ask for an odd number, reduce
the number of lines by 1 instead of failing.
+static int vpif_enum_output(struct file *file, void *fh,
+ struct v4l2_output *output)
+{
+
+ struct vpif_config *config = vpif_dev-platform_data;
+ int index = output-index;
+
+ memset(output, 0, sizeof(*output));
+ if (index config-output_count) {
+ v4l2_dbg(1, debug, vpif_obj.v4l2_dev,
+ Invalid output index\n);
+ return -EINVAL;
+ }
+
+ output-index = index;
Another save index, memset, restore index sequence that isn't needed.
+#define ISALIGNED(a)(0 == (a%8))
Here you need parenthesis: (0 == ((a) % 8))
If 'a' isn't unsigned, then (0 == ((a) 7)) will be more efficient. For
unsigned values the compiler should be able to make the transformation to
using instead of %, but not for signed.
+struct vpif_config_params {
+ u8 min_numbuffers;
+ u8 numbuffers[VPIF_DISPLAY_NUM_CHANNELS];
+ u32 min_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
+ u32 channel_bufsize[VPIF_DISPLAY_NUM_CHANNELS];
+};
If you put the larger fields first the structure will be padded less.
--
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
Correct signal strength and SNR output for DViCO FusionHDTV7 Dual Express?
I am trying to get a MythTV setup working with a DViCO FusionHDTV7 Dual Express using Mythbuntu 8.10 and I have been able to generate a channels.conf file using the latest v4l-dvb source code and the scan utility that comes with the dvb-utils in Mythbuntu (the dvbscan utility in latest dvb-apps source code give me the error Unable to query frontend status). I am also able to watch channels using mplayer, but the the problem is that MythTV does not identify any channels. I am able to watch channels using MythTV, but I have to manually enter the channel data since the tuning is not working. The belief is that the signal strength and SNR output must be incorrect and that is causing the problem with MythTV. I would like to help get this fixed, so others don't have the problems that I have run into, so what can I do to help get the signal strength and SNR outputs working? If it's helpful, I have attached an example output using azap with one of the channels that I can watch with mplayer: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 503028615 Hz video pid 0x0011, audio pid 0x0014 status 01 | signal e000 | snr e450 | ber | unc | status 1f | signal 00ff | snr 00ff | ber | unc | FE_HAS_LOCK status 1f | signal 00ff | snr 00ff | ber 0ab7 | unc 0ab7 | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK Thanks, Dave -- 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: Correct signal strength and SNR output for DViCO FusionHDTV7 Dual Express?
On Mon, Mar 30, 2009 at 5:37 PM, Dave Johansen davejohan...@gmail.com wrote: I am trying to get a MythTV setup working with a DViCO FusionHDTV7 Dual Express using Mythbuntu 8.10 and I have been able to generate a channels.conf file using the latest v4l-dvb source code and the scan utility that comes with the dvb-utils in Mythbuntu (the dvbscan utility in latest dvb-apps source code give me the error Unable to query frontend status). I am also able to watch channels using mplayer, but the the problem is that MythTV does not identify any channels. I am able to watch channels using MythTV, but I have to manually enter the channel data since the tuning is not working. The belief is that the signal strength and SNR output must be incorrect and that is causing the problem with MythTV. I would like to help get this fixed, so others don't have the problems that I have run into, so what can I do to help get the signal strength and SNR outputs working? If it's helpful, I have attached an example output using azap with one of the channels that I can watch with mplayer: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 503028615 Hz video pid 0x0011, audio pid 0x0014 status 01 | signal e000 | snr e450 | ber | unc | status 1f | signal 00ff | snr 00ff | ber | unc | FE_HAS_LOCK status 1f | signal 00ff | snr 00ff | ber 0ab7 | unc 0ab7 | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK Thanks, Dave That is a great signal reading. 0xfa = 25.0 dB , 0xff = 25.5 dB ... so, you're teetering between 25.0 and 25.5 -- you have a great signal. SNR is reported in 0.1 dB by the driver that your device uses. Ignore what mythtv says about signal status -- userspace cant read kernelspace signal statistics properly yet. Regards, Mike -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Correct signal strength and SNR output for DViCO FusionHDTV7 Dual Express?
On Mon, Mar 30, 2009 at 5:37 PM, Dave Johansen davejohan...@gmail.com wrote: I am trying to get a MythTV setup working with a DViCO FusionHDTV7 Dual Express using Mythbuntu 8.10 and I have been able to generate a channels.conf file using the latest v4l-dvb source code and the scan utility that comes with the dvb-utils in Mythbuntu (the dvbscan utility in latest dvb-apps source code give me the error Unable to query frontend status). I am also able to watch channels using mplayer, but the the problem is that MythTV does not identify any channels. I am able to watch channels using MythTV, but I have to manually enter the channel data since the tuning is not working. The belief is that the signal strength and SNR output must be incorrect and that is causing the problem with MythTV. I would like to help get this fixed, so others don't have the problems that I have run into, so what can I do to help get the signal strength and SNR outputs working? If it's helpful, I have attached an example output using azap with one of the channels that I can watch with mplayer: using '/dev/dvb/adapter0/frontend0' and '/dev/dvb/adapter0/demux0' tuning to 503028615 Hz video pid 0x0011, audio pid 0x0014 status 01 | signal e000 | snr e450 | ber | unc | status 1f | signal 00ff | snr 00ff | ber | unc | FE_HAS_LOCK status 1f | signal 00ff | snr 00ff | ber 0ab7 | unc 0ab7 | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK status 1f | signal 00fa | snr 00fa | ber | unc | FE_HAS_LOCK Thanks, Dave Hello Dave, There has been an ongoing discussion about the representation of SNR and strength to applications such as MythTV. Currently it is very inconsistent across drivers. To my knowledge, MythTV does not rely on either of these fields during its scanning. It relies entirely on the FE_HAS_LOCK to make it's determination. You should probably see what additional logging capabilities are available in MythTV. Also, you might want to see if you can change the lock timeout in your application, as some applications may have the interval set to a value too short, which results in it timing out before the lock is acquired. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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: [review] dsbr100 radio: convert to to v4l2_device
On Monday 30 March 2009 19:09:47 Alexey Klimov wrote:
Hello, Hans and Douglas, and others
This is review version for dsbr100 radio.
Hans, if you can a bit of free time to look and make comments it will be
very good.
I'm still confused about messages like v4l2_err and about unplugging
procedure.
For a simple device like this unregistering the v4l2_device in the disconnect
is OK. Although the best method would be to call v4l2_device_disconnect()
in the disconnect function and postpone the v4l2_device_unregister() until the
usb_dsbr100_video_device_release function.
What is really missing in the v4l2 core is a release function that is called
when the last video device node is closed. The video_release function is only
called when that particular video device is released, but for drivers that
open multiple device nodes you still have to put in administration to wait
until really the last user of any device node disappears.
I might add a feature like that to the v4l2 core in the future. It shouldn't
be too hard.
Anyway, that's not relevant for a simple USB radio device :-)
Re: the v4l2_err functions: v4l2_device_register sets up a standard unique
driver prefix that can be used for logging. Since the 'name' can be
overwritten by the driver you have more flexibility than the standard
dev_info functions. I also have some ideas on how to improve there functions.
I tested it with my radio device and it works(unplugging works also
without oopses).
Douglas, if you can find some free time to test patch it will be very
good too :)
--
diff -r f86c84534cb4 linux/drivers/media/radio/dsbr100.c
--- a/linux/drivers/media/radio/dsbr100.c Sun Mar 29 22:54:35 2009 -0300
+++ b/linux/drivers/media/radio/dsbr100.c Mon Mar 30 21:00:51 2009 +0400
@@ -32,6 +32,9 @@
Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
History:
+
+ Version 0.45:
+ Converted to v4l2_device.
Version 0.44:
Add suspend/resume functions, fix unplug of device,
@@ -88,7 +91,7 @@
#include linux/slab.h
#include linux/input.h
#include linux/videodev2.h
-#include media/v4l2-common.h
+#include media/v4l2-device.h
#include media/v4l2-ioctl.h
#include linux/usb.h
#include compat.h
@@ -98,39 +101,8 @@
*/
#include linux/version.h /* for KERNEL_VERSION MACRO */
-#define DRIVER_VERSION v0.44
-#define RADIO_VERSION KERNEL_VERSION(0, 4, 4)
-
-static struct v4l2_queryctrl radio_qctrl[] = {
- {
- .id= V4L2_CID_AUDIO_MUTE,
- .name = Mute,
- .minimum = 0,
- .maximum = 1,
- .default_value = 1,
- .type = V4L2_CTRL_TYPE_BOOLEAN,
- },
-/* HINT: the disabled controls are only here to satify kradio and such apps
*/
- { .id = V4L2_CID_AUDIO_VOLUME,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BALANCE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_BASS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_TREBLE,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
- {
- .id = V4L2_CID_AUDIO_LOUDNESS,
- .flags = V4L2_CTRL_FLAG_DISABLED,
- },
-};
+#define DRIVER_VERSION v0.45
+#define RADIO_VERSION KERNEL_VERSION(0, 4, 5)
#define DRIVER_AUTHOR Markus Demleitner msdem...@tucana.harvard.edu
#define DRIVER_DESC D-Link DSB-R100 USB FM radio driver
@@ -168,6 +140,8 @@
struct dsbr100_device {
struct usb_device *usbdev;
struct video_device videodev;
+ struct v4l2_device v4l2_dev;
+
u8 *transfer_buffer;
struct mutex lock; /* buffer locking */
int curfreq;
@@ -387,6 +361,7 @@
mutex_unlock(radio-lock);
video_unregister_device(radio-videodev);
+ v4l2_device_unregister(radio-v4l2_dev);
}
@@ -482,14 +457,11 @@
static int vidioc_queryctrl(struct file *file, void *priv,
struct v4l2_queryctrl *qc)
{
- int i;
+ switch (qc-id) {
+ case V4L2_CID_AUDIO_MUTE:
+ return v4l2_ctrl_query_fill(qc, 0, 1, 1, 1);
+ }
- for (i = 0; i ARRAY_SIZE(radio_qctrl); i++) {
- if (qc-id qc-id == radio_qctrl[i].id) {
- memcpy(qc, (radio_qctrl[i]), sizeof(*qc));
- return 0;
- }
- }
return -EINVAL;
}
@@ -686,22 +658,15 @@
.vidioc_s_input = vidioc_s_input,
};
-/* V4L2 interface */
-static struct video_device dsbr100_videodev_data = {
- .name = D-Link DSB-R 100,
- .fops = usb_dsbr100_fops,
- .ioctl_ops = usb_dsbr100_ioctl_ops,
- .release=
Reading a packet at a time
The DVB API guarantees that read() on a file descriptor on which DMX_SET_FILTER has been called reads one whole section at a time as long as the provided buffer is large enough. Is there a corresponding guarantee for DMX_SET_PES_FILTER ie can I rely on being able to read whole TS or PES packets from a dvr device? -- TH * http://www.realh.co.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: [PULL] http://linuxtv.org/hg/~pinchartl/uvcvideo/
On Mon, 30 Mar 2009 23:16:09 +0200 Laurent Pinchart laurent.pinch...@skynet.be wrote: Hi Mauro, On Monday 30 March 2009 05:49:36 Mauro Carvalho Chehab wrote: Hi Laurent, On Sun, 29 Mar 2009 14:45:07 +0200 Laurent Pinchart laurent.pinch...@skynet.be wrote: uvcvideo: Add support for Syntek cameras found in JAOtech Smart Terminals Please prefer using make commit to commit your patches. It will run some sanity scripts that will help you to not forget something. Sorry. I wanted to commit only a subset of modified files and I used hg commit directly for that purpose. Ah, ok. Here, I have a hgeditor script for such cases (enclosed). You'll need to copy or symlink the v4l hg_prep_msg.pl as /usr/local/bin/hg_prep_msg.pl in order to use it, and properly setup the hgrc for using it to generate the hg commit msgs. I'll be more careful next time. No problem. This time, you forgot the From: on the above patch. In order to avoid attributing a patch to the wrong author at -git, I need to manually fix the lack of the From: meta-tag. Since I saw only your SOB, I've credited this patch to you. Please let me know ASAP if my hint were wrong. Nothing wrong, thanks for fixing this. Good! Cheers, Mauro hgeditor Description: Binary data
Re: AverMedia Volar Black HD (A850)
Here are my tests : http://linuxtv.org/hg/~anttip/af9015_aver_a850_2/ : Mar 31 00:16:27 blastor kernel: [12790.692333] usb 5-4.4: new high speed USB device using ehci_hcd and address 13 Mar 31 00:16:27 blastor kernel: [12790.788517] usb 5-4.4: configuration #1 chosen from 1 choice Mar 31 00:16:27 blastor kernel: [12790.789245] af9015_usb_probe: interface:0 Mar 31 00:16:27 blastor kernel: [12790.793278] af9015_read_config: IR mode:0 Mar 31 00:16:27 blastor kernel: [12790.795755] af9015_read_config: TS mode:1 Mar 31 00:16:27 blastor kernel: [12790.798681] af9015_read_config: [0] xtal:2 set adc_clock:28000 Mar 31 00:16:27 blastor kernel: [12790.801555] af9015_read_config: [0] IF1:36125 Mar 31 00:16:27 blastor kernel: [12790.804556] af9015_read_config: [0] MT2060 IF1:0 Mar 31 00:16:27 blastor kernel: [12790.805935] af9015_read_config: [0] tuner id:13 Mar 31 00:16:27 blastor kernel: [12790.807424] af9015_read_config: [1] xtal:2 set adc_clock:28000 Mar 31 00:16:27 blastor kernel: [12790.810300] af9015_read_config: [1] IF1:36125 Mar 31 00:16:27 blastor kernel: [12790.830517] af9015_read_config: [1] MT2060 IF1:1220 Mar 31 00:16:27 blastor kernel: [12790.836368] af9015_read_config: [1] tuner id:130 Mar 31 00:16:27 blastor kernel: [12790.836376] af9015_read_config: AverMedia A850: overriding config Mar 31 00:16:27 blastor kernel: [12790.836805] af9015_identify_state: reply:01 Mar 31 00:16:27 blastor kernel: [12790.836810] dvb-usb: found a 'AverMedia AVerTV Volar Black HD (A850)' in cold state, will try to load a firmware Mar 31 00:16:27 blastor kernel: [12790.836813] firmware: requesting dvb-usb-af9015.fw Mar 31 00:16:27 blastor kernel: [12790.872856] dvb-usb: downloading firmware from file 'dvb-usb-af9015.fw' Mar 31 00:16:27 blastor kernel: [12790.872864] af9015_download_firmware: Mar 31 00:16:27 blastor kernel: [12790.964480] dvb-usb: found a 'AverMedia AVerTV Volar Black HD (A850)' in warm state. Mar 31 00:16:27 blastor kernel: [12790.964570] i2c-adapter i2c-5: SMBus Quick command not supported, can't probe for chips Mar 31 00:16:27 blastor kernel: [12790.964579] i2c-adapter i2c-5: SMBus Quick command not supported, can't probe for chips Mar 31 00:16:27 blastor kernel: [12790.964594] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. Mar 31 00:16:27 blastor kernel: [12790.966730] DVB: registering new adapter (AverMedia AVerTV Volar Black HD (A850)) Mar 31 00:16:27 blastor kernel: [12790.967156] af9015_af9013_frontend_attach: init I2C Mar 31 00:16:27 blastor kernel: [12790.967160] af9015_i2c_init: Mar 31 00:16:27 blastor kernel: [12790.967196] i2c-adapter i2c-6: SMBus Quick command not supported, can't probe for chips Mar 31 00:16:27 blastor kernel: [12790.967216] i2c-adapter i2c-6: SMBus Quick command not supported, can't probe for chips Mar 31 00:16:27 blastor kernel: [12791.004560] 00: 2c 8f a3 0b 00 00 00 00 ca 07 0a 85 01 01 01 02 Mar 31 00:16:27 blastor kernel: [12791.028769] 10: 03 80 00 fa fa 10 40 ef 00 30 31 30 31 30 37 30 Mar 31 00:16:27 blastor kernel: [12791.052023] 20: 33 30 37 30 30 30 30 31 ff ff ff ff ff ff ff ff Mar 31 00:16:27 blastor kernel: [12791.075878] 30: 01 01 38 01 00 08 02 01 1d 8d 00 00 0d ff ff ff Mar 31 00:16:27 blastor kernel: [12791.099499] 40: ff ff ff ff ff 08 02 00 1d 8d c4 04 82 ff ff ff Mar 31 00:16:27 blastor kernel: [12791.123372] 50: ff ff ff ff ff 26 00 00 04 03 09 04 14 03 41 00 Mar 31 00:16:27 blastor kernel: [12791.147194] 60: 56 00 65 00 72 00 4d 00 65 00 64 00 69 00 61 00 Mar 31 00:16:27 blastor kernel: [12791.170869] 70: 14 03 41 00 38 00 35 00 30 00 20 00 44 00 56 00 Mar 31 00:16:27 blastor kernel: [12791.195111] 80: 42 00 54 00 20 03 33 00 30 00 31 00 34 00 37 00 Mar 31 00:16:27 blastor kernel: [12791.219359] 90: 35 00 34 00 30 00 30 00 37 00 33 00 36 00 30 00 Mar 31 00:16:27 blastor kernel: [12791.243602] a0: 30 00 30 00 00 ff ff ff ff ff ff ff ff ff ff ff Mar 31 00:16:27 blastor kernel: [12791.267347] b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 31 00:16:27 blastor kernel: [12791.291469] c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 31 00:16:27 blastor kernel: [12791.315592] d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 31 00:16:27 blastor kernel: [12791.339711] e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 31 00:16:28 blastor kernel: [12791.363335] f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff Mar 31 00:16:28 blastor kernel: [12791.366460] af9013: firmware version:4.95.0 Mar 31 00:16:28 blastor kernel: [12791.372472] DVB: registering adapter 0 frontend 0 (Afatech AF9013 DVB-T)... Mar 31 00:16:28 blastor kernel: [12791.372532] af9015_tuner_attach: Mar 31 00:16:28 blastor kernel: [12791.372770] MXL5005S: Attached at address 0xc6 Mar 31 00:16:28 blastor kernel: [12791.372776] dvb-usb: AverMedia AVerTV Volar Black HD (A850) successfully initialized and connected. Mar 31 00:16:28 blastor kernel: [12791.372778] af9015_init: Mar 31 00:16:28 blastor
Re: AverMedia Volar Black HD (A850)
Olivier MENUEL wrote: Here are my tests : http://linuxtv.org/hg/~anttip/af9015_aver_a850_2/ : I found why kaffeine was not working : I needed to check all offset checkboxes when scanning. Like Thomas, I get these messages in /var/log/messages when scanning or changing channel : af9015_pid_filter_ctrl: onoff:0 (with kaffeine, scan or vlc) That's normal behaviour. dvb-usb-framework calls .pid_filter_ctrl(0) callback to ensure pid-filter is disabled. Those logs will not seen normally when debug-logs are disabled. I found a weird thing though with kaffeine (that may be a wrong setting somewhere in kaffeine though, it's the first time I use a DVB device on linux). If I stop kaffeine and restart it I can't access the channels I just scanned anymore : I get an error message : Tuning to: NRJ12 / autocount: 0 Using DVB device 0:0 Afatech AF9013 DVB-T tuning DVB-T to 498167000 Hz inv:2 bw:0 fecH:9 fecL:9 mod:6 tm:2 gi:4 hier:4 . Not able to lock to the signal on the given frequency Frontend closed Tuning delay: 1062 ms I need to switch channels several times and eventually it works : I can now change channels without any problems ! But if I quit and restart kaffeine, I get the same problem again No problem with VLC. hmm, no idea. Sometimes I have also seen rather similar problems when switching channels but restarting Totem solves problem. I did full band w_scan and it founds all muxes I can receive (4xDVB-T + 1xDVB-H). I haven't tested Kaffeine. Except that everything seems to work perfectly fine ! I'm not sure exactly what you want me to test though. GPI01 : Seems quite similar to previous one. Everything seems fine too (except the weird kaffeine issue). In the logs I get the same message : af9015_pid_filter_ctrl: onoff:0 Finally, I tested GPI00 : Working fine too, seems exactly like previous ones. I hope I installed these correctly and did not mess up between the different drivers. Let me know if something seems weird or if you want me to test something else. I'm really glad it finally works ;) Thanks a lot. For me it seems like tuner is not connected to GPIO pin at all. I will wait someone else, Thomas?, will test. Testing this (af9015_aver_a850_2) tree is enough if it works: http://linuxtv.org/hg/~anttip/af9015_aver_a850_2/ regards Antti -- http://palosaari.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: Problems with Hauppauge HVR 1600 and cx18 driver
On Mon, 2009-03-30 at 13:54 -0700, Trent Piepho wrote:
On Sun, 29 Mar 2009, Andy Walls wrote:
On Sun, 2009-03-29 at 01:24 -0700, Trent Piepho wrote:
wait_event() should take care of this. wait_event(q, test) basically
does:
for(;;) {
// point A
add_me_to_waitqueue(q);
set_current_state(TASK_UNINTERRUPTIBLE);
if (test)
break;
// point B
schedule();
}
clean_up_wait_stuff();
As you know, the condition is checked even before this loop is entered,
to avoid even being even added to a waitqueue. (Thank God for ctags...)
I think the initial check of the condition is just an optimization and
everything will still work without it. Seeing as all this is inlined, I
wonder if it's a good optimization...
I guess it depends on how expensive prepare_to_wait() is since it
acquires a spinlock.
But now that you mention inlining. I now have to check if this sequence
that I thought didn't work:
prepare_to_wait(waitq, w, TASK_UNINTERRUPTIBLE);
cx18_write_reg_expect(cx, irq, SW1_INT_SET, irq, irq);
if (req != cx18_readl(cx, mb-ack))
ret = schedule_timeout(timeout);
finish_wait(waitq, w);
is actually getting reordered. I bet constituent parts of the first two
lines may be. That would certainly explain things.
As you may have noticed, the original code was using
wait_event_timeout() before like this:
CX18_DEBUG_HI_IRQ(sending interrupt SW1: %x to send %s\n,
irq, info-name);
cx18_write_reg_expect(cx, irq, SW1_INT_SET, irq, irq);
ret = wait_event_timeout(
*waitq,
cx18_readl(cx, mb-ack) == cx18_readl(cx,
mb-request),
timeout);
Because waiting for the ack back is the right thing to do, but certainly
waiting too long is not warranted.
This gave me the occasional log message like this:
1: cx18-0: irq: sending interrupt SW1: 8 to send CX18_CPU_DE_SET_MDL
2: cx18-0: irq: received interrupts SW1: 0 SW2: 8 HW2: 0
3: cx18-0: irq: received interrupts SW1: 1 SW2: 0 HW2: 0
4: cx18-0: warning: sending CX18_CPU_DE_SET_MDL timed out waiting 10 msecs
for RPU acknowledgement
Where line 1 is the driver notifiying the firmware with a SW1 interrupt.
Line 2 is the firmware responding back to the cx18_irq_handler() with
the Ack interrupt in SW2 (the flags match, 8 8, by design).
Line 3 is an unrelated incoming video buffer notification for the cx18
driver.
Line 4 is the wait_event_timeout() timing out.
Could it be that the wait_event doesn't actually run and check its
condition until _after_ line 3?
SW2: 8 is a firmware response to us setting the outgoing SW1 to 8.
SW2 getting cleared is done by cx18_irq_handler and its helper:
static void xpu_ack(struct cx18 *cx, u32 sw2)
{
// Wake up the process waiting on the EPU - CPU mailbox ack
// This one has a flag value of 8
if (sw2 IRQ_CPU_TO_EPU_ACK)
wake_up(cx-mb_cpu_waitq);
// Wake up the process waiting on the EPU - APU mailbox ack
if (sw2 IRQ_APU_TO_EPU_ACK)
wake_up(cx-mb_apu_waitq);
}
irqreturn_t cx18_irq_handler(int irq, void *dev_id)
{
struct cx18 *cx = (struct cx18 *)dev_id;
u32 sw1, sw2, hw2;
// Get the status of SW2
sw2 = cx18_read_reg(cx, SW2_INT_STATUS) cx-sw2_irq_mask;
// Clear any status of SW2 that were found set
if (sw2)
cx18_write_reg_expect(cx, sw2, SW2_INT_STATUS, ~sw2, sw2);
// Act on any SW2 interrupts found set
if (sw2)
xpu_ack(cx, sw2);
return (sw1 || sw2 || hw2) ? IRQ_HANDLED : IRQ_NONE;
}
In that case SW2 != 8 and so it goes back
to sleep?
If SW2 got set back to 0 (or != 8), that means we cleared it ourselves.
We only do that slightly prior to waking up the proper waitq.
Calling wake_up() just makes the processes on the waitq
runnable, they don't actually run until later, possibly much later.
Hmm. Maybe then we're yielding the processor and then simply running
much later.
If that's the case, I may be stuck with shorter timeouts with polls. :(
If your event occurs and wake_up() is called at point A, then the test
should be true when it's checked and schedule() is never called. If the
event happens at point B, then the process' state will have been changed
to
TASK_RUNNING by wake_up(), remember it's already on the waitqueue at this
point, and schedule() won't sleep.
OK, for some reason, I thought schedule() and schedule_timeout() would
go to sleep anyway.
AFAIK, they'll still cause the kernel schedule a process. Maybe a
different process. But the original process is still in TASK_RUNNING state
and so still in the run queue and will get run again. If it was in
TASK_(UN)INTERRUPTIBLE state then it wouldn't be in the run queue
XC5000 DVB-T/DMB-TH support
Does anyone know how to get XC5000 working for DVB-T, especially 8MHz bandwidth? Current driver only supports ATSC with 6MHz bandwidth only. It seems there is a trick at setting compensated RF frequency. DVB-T 8MHz support would probably works for DMB-TH, but DMB-TH settings is very welcome. Regards, David -- 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: XC5000 DVB-T/DMB-TH support
On Tue, Mar 31, 2009 at 10:57 AM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
On Mon, Mar 30, 2009 at 10:47 PM, David Wong davidtlw...@gmail.com wrote:
Does anyone know how to get XC5000 working for DVB-T, especially 8MHz
bandwidth?
Current driver only supports ATSC with 6MHz bandwidth only.
It seems there is a trick at setting compensated RF frequency.
DVB-T 8MHz support would probably works for DMB-TH, but DMB-TH
settings is very welcome.
Regards,
David
--
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
All of my xc5000 work has been with ATSC/QAM, so I can't say
authoritatively what is required to make it work.
Well, at a minimum you will have to modify xc5000_set_params to
support setting priv-video_standard to DTV8. Beyond that, I don't
think you need to do anything specific for DVB-T.
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
I have tried followings in xc5000_set_params()
if (fe-ops.info.type == FE_ATSC) {
...
} else if (fe-ops.info.type == FE_OFDM) {
switch (params-u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
printk(xc5000 bandwidth 6MHz\n);
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
break;
case BANDWIDTH_7_MHZ:
printk(xc5000 bandwidth 7MHz\n);
priv-bandwidth = BANDWIDTH_7_MHZ;
priv-video_standard = DTV7;
break;
case BANDWIDTH_8_MHZ:
printk(xc5000 bandwidth 8MHz\n);
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = DTV8;
break;
default:
printk(xc5000 bandwidth not set!\n);
return -EINVAL;
}
priv-rf_mode = XC_RF_MODE_AIR;
priv-freq_hz = params-frequency - 175;
}
But no success yet.
I am wondering the -175 compensation for DTV8.
BTW, The xc_debug_dump() could get more information like firmware
build number and tuner total gain
diff -r 2276e777f950 linux/drivers/media/common/tuners/xc5000.c
--- a/linux/drivers/media/common/tuners/xc5000.cThu Mar 26 22:17:48
2009 -0300
+++ b/linux/drivers/media/common/tuners/xc5000.cMon Mar 30 16:23:11
2009 +0800
@@ -84,6 +84,7 @@
#define XREG_IF_OUT 0x05
#define XREG_SEEK_MODE0x07
#define XREG_POWER_DOWN 0x0A
+#define XREG_OUTPUT_AMP 0x0B
#define XREG_SIGNALSOURCE 0x0D /* 0=Air, 1=Cable */
#define XREG_SMOOTHEDCVBS 0x0E
#define XREG_XTALFREQ 0x0F
@@ -100,6 +101,8 @@
#define XREG_VERSION 0x07
#define XREG_PRODUCT_ID 0x08
#define XREG_BUSY 0x09
+#define XREG_BUILD_NUM0x0D
+#define XREG_TOTAL_GAIN 0x0F
/*
Basic firmware description. This will remain with
@@ -468,7 +485,8 @@
static int xc_get_version(struct xc5000_priv *priv,
u8 *hw_majorversion, u8 *hw_minorversion,
- u8 *fw_majorversion, u8 *fw_minorversion)
+ u8 *fw_majorversion, u8 *fw_minorversion,
+ u16 *fw_buildnum)
{
u16 data;
int result;
@@ -481,6 +499,11 @@
(*hw_minorversion) = (data 8) 0x0F;
(*fw_majorversion) = (data 4) 0x0F;
(*fw_minorversion) = data 0x0F;
+
+ result = xc_read_reg(priv, XREG_BUILD_NUM, data);
+ if (result)
+ return result;
+ *fw_buildnum = data;
return 0;
}
@@ -506,6 +529,11 @@
static int xc_get_quality(struct xc5000_priv *priv, u16 *quality)
{
return xc_read_reg(priv, XREG_QUALITY, quality);
+}
+
+static int xc_get_total_gain(struct xc5000_priv *priv, u16 *gain)
+{
+ return xc_read_reg(priv, XREG_TOTAL_GAIN, gain);
}
static u16 WaitForLock(struct xc5000_priv *priv)
@@ -626,8 +654,10 @@
u32 hsync_freq_hz = 0;
u16 frame_lines;
u16 quality;
+ u16 gain;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
+ u16 fw_buildnum = 0;
/* Wait for stats to stabilize.
* Frame Lines needs two frame times after initial lock
@@ -646,10 +676,11 @@
lock_status);
xc_get_version(priv, hw_majorversion, hw_minorversion,
- fw_majorversion, fw_minorversion);
- dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x\n,
+ fw_majorversion, fw_minorversion, fw_buildnum);
+ dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x build %d\n,
hw_majorversion, hw_minorversion,
- fw_majorversion, fw_minorversion);
+ fw_majorversion, fw_minorversion,
+ fw_buildnum);
xc_get_hsync_freq(priv,
Re: XC5000 DVB-T/DMB-TH support
On Mon, Mar 30, 2009 at 11:39 PM, David Wong davidtlw...@gmail.com wrote:
On Tue, Mar 31, 2009 at 10:57 AM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
On Mon, Mar 30, 2009 at 10:47 PM, David Wong davidtlw...@gmail.com wrote:
Does anyone know how to get XC5000 working for DVB-T, especially 8MHz
bandwidth?
Current driver only supports ATSC with 6MHz bandwidth only.
It seems there is a trick at setting compensated RF frequency.
DVB-T 8MHz support would probably works for DMB-TH, but DMB-TH
settings is very welcome.
Regards,
David
--
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
All of my xc5000 work has been with ATSC/QAM, so I can't say
authoritatively what is required to make it work.
Well, at a minimum you will have to modify xc5000_set_params to
support setting priv-video_standard to DTV8. Beyond that, I don't
think you need to do anything specific for DVB-T.
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
I have tried followings in xc5000_set_params()
if (fe-ops.info.type == FE_ATSC) {
...
} else if (fe-ops.info.type == FE_OFDM) {
switch (params-u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
printk(xc5000 bandwidth 6MHz\n);
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
break;
case BANDWIDTH_7_MHZ:
printk(xc5000 bandwidth 7MHz\n);
priv-bandwidth = BANDWIDTH_7_MHZ;
priv-video_standard = DTV7;
break;
case BANDWIDTH_8_MHZ:
printk(xc5000 bandwidth 8MHz\n);
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = DTV8;
break;
default:
printk(xc5000 bandwidth not set!\n);
return -EINVAL;
}
priv-rf_mode = XC_RF_MODE_AIR;
priv-freq_hz = params-frequency - 175;
}
But no success yet.
I am wondering the -175 compensation for DTV8.
BTW, The xc_debug_dump() could get more information like firmware
build number and tuner total gain
diff -r 2276e777f950 linux/drivers/media/common/tuners/xc5000.c
--- a/linux/drivers/media/common/tuners/xc5000.c Thu Mar 26 22:17:48
2009 -0300
+++ b/linux/drivers/media/common/tuners/xc5000.c Mon Mar 30 16:23:11
2009 +0800
@@ -84,6 +84,7 @@
#define XREG_IF_OUT 0x05
#define XREG_SEEK_MODE 0x07
#define XREG_POWER_DOWN 0x0A
+#define XREG_OUTPUT_AMP 0x0B
#define XREG_SIGNALSOURCE 0x0D /* 0=Air, 1=Cable */
#define XREG_SMOOTHEDCVBS 0x0E
#define XREG_XTALFREQ 0x0F
@@ -100,6 +101,8 @@
#define XREG_VERSION 0x07
#define XREG_PRODUCT_ID 0x08
#define XREG_BUSY 0x09
+#define XREG_BUILD_NUM 0x0D
+#define XREG_TOTAL_GAIN 0x0F
/*
Basic firmware description. This will remain with
@@ -468,7 +485,8 @@
static int xc_get_version(struct xc5000_priv *priv,
u8 *hw_majorversion, u8 *hw_minorversion,
- u8 *fw_majorversion, u8 *fw_minorversion)
+ u8 *fw_majorversion, u8 *fw_minorversion,
+ u16 *fw_buildnum)
{
u16 data;
int result;
@@ -481,6 +499,11 @@
(*hw_minorversion) = (data 8) 0x0F;
(*fw_majorversion) = (data 4) 0x0F;
(*fw_minorversion) = data 0x0F;
+
+ result = xc_read_reg(priv, XREG_BUILD_NUM, data);
+ if (result)
+ return result;
+ *fw_buildnum = data;
return 0;
}
@@ -506,6 +529,11 @@
static int xc_get_quality(struct xc5000_priv *priv, u16 *quality)
{
return xc_read_reg(priv, XREG_QUALITY, quality);
+}
+
+static int xc_get_total_gain(struct xc5000_priv *priv, u16 *gain)
+{
+ return xc_read_reg(priv, XREG_TOTAL_GAIN, gain);
}
static u16 WaitForLock(struct xc5000_priv *priv)
@@ -626,8 +654,10 @@
u32 hsync_freq_hz = 0;
u16 frame_lines;
u16 quality;
+ u16 gain;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
+ u16 fw_buildnum = 0;
/* Wait for stats to stabilize.
* Frame Lines needs two frame times after initial lock
@@ -646,10 +676,11 @@
lock_status);
xc_get_version(priv, hw_majorversion, hw_minorversion,
- fw_majorversion, fw_minorversion);
- dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x\n,
+ fw_majorversion, fw_minorversion, fw_buildnum);
+ dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x build %d\n,
hw_majorversion, hw_minorversion,
-
Re: XC5000 DVB-T/DMB-TH support
On Tue, Mar 31, 2009 at 11:46 AM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
On Mon, Mar 30, 2009 at 11:39 PM, David Wong davidtlw...@gmail.com wrote:
On Tue, Mar 31, 2009 at 10:57 AM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
On Mon, Mar 30, 2009 at 10:47 PM, David Wong davidtlw...@gmail.com wrote:
Does anyone know how to get XC5000 working for DVB-T, especially 8MHz
bandwidth?
Current driver only supports ATSC with 6MHz bandwidth only.
It seems there is a trick at setting compensated RF frequency.
DVB-T 8MHz support would probably works for DMB-TH, but DMB-TH
settings is very welcome.
Regards,
David
--
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
All of my xc5000 work has been with ATSC/QAM, so I can't say
authoritatively what is required to make it work.
Well, at a minimum you will have to modify xc5000_set_params to
support setting priv-video_standard to DTV8. Beyond that, I don't
think you need to do anything specific for DVB-T.
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
I have tried followings in xc5000_set_params()
if (fe-ops.info.type == FE_ATSC) {
...
} else if (fe-ops.info.type == FE_OFDM) {
switch (params-u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
printk(xc5000 bandwidth 6MHz\n);
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
break;
case BANDWIDTH_7_MHZ:
printk(xc5000 bandwidth 7MHz\n);
priv-bandwidth = BANDWIDTH_7_MHZ;
priv-video_standard = DTV7;
break;
case BANDWIDTH_8_MHZ:
printk(xc5000 bandwidth 8MHz\n);
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = DTV8;
break;
default:
printk(xc5000 bandwidth not set!\n);
return -EINVAL;
}
priv-rf_mode = XC_RF_MODE_AIR;
priv-freq_hz = params-frequency - 175;
}
But no success yet.
I am wondering the -175 compensation for DTV8.
BTW, The xc_debug_dump() could get more information like firmware
build number and tuner total gain
diff -r 2276e777f950 linux/drivers/media/common/tuners/xc5000.c
--- a/linux/drivers/media/common/tuners/xc5000.c Thu Mar 26 22:17:48
2009 -0300
+++ b/linux/drivers/media/common/tuners/xc5000.c Mon Mar 30 16:23:11
2009 +0800
@@ -84,6 +84,7 @@
#define XREG_IF_OUT 0x05
#define XREG_SEEK_MODE 0x07
#define XREG_POWER_DOWN 0x0A
+#define XREG_OUTPUT_AMP 0x0B
#define XREG_SIGNALSOURCE 0x0D /* 0=Air, 1=Cable */
#define XREG_SMOOTHEDCVBS 0x0E
#define XREG_XTALFREQ 0x0F
@@ -100,6 +101,8 @@
#define XREG_VERSION 0x07
#define XREG_PRODUCT_ID 0x08
#define XREG_BUSY 0x09
+#define XREG_BUILD_NUM 0x0D
+#define XREG_TOTAL_GAIN 0x0F
/*
Basic firmware description. This will remain with
@@ -468,7 +485,8 @@
static int xc_get_version(struct xc5000_priv *priv,
u8 *hw_majorversion, u8 *hw_minorversion,
- u8 *fw_majorversion, u8 *fw_minorversion)
+ u8 *fw_majorversion, u8 *fw_minorversion,
+ u16 *fw_buildnum)
{
u16 data;
int result;
@@ -481,6 +499,11 @@
(*hw_minorversion) = (data 8) 0x0F;
(*fw_majorversion) = (data 4) 0x0F;
(*fw_minorversion) = data 0x0F;
+
+ result = xc_read_reg(priv, XREG_BUILD_NUM, data);
+ if (result)
+ return result;
+ *fw_buildnum = data;
return 0;
}
@@ -506,6 +529,11 @@
static int xc_get_quality(struct xc5000_priv *priv, u16 *quality)
{
return xc_read_reg(priv, XREG_QUALITY, quality);
+}
+
+static int xc_get_total_gain(struct xc5000_priv *priv, u16 *gain)
+{
+ return xc_read_reg(priv, XREG_TOTAL_GAIN, gain);
}
static u16 WaitForLock(struct xc5000_priv *priv)
@@ -626,8 +654,10 @@
u32 hsync_freq_hz = 0;
u16 frame_lines;
u16 quality;
+ u16 gain;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
+ u16 fw_buildnum = 0;
/* Wait for stats to stabilize.
* Frame Lines needs two frame times after initial lock
@@ -646,10 +676,11 @@
lock_status);
xc_get_version(priv, hw_majorversion, hw_minorversion,
- fw_majorversion, fw_minorversion);
- dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x\n,
+ fw_majorversion, fw_minorversion, fw_buildnum);
+ dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x
Re: XC5000 DVB-T/DMB-TH support
On Mon, Mar 30, 2009 at 11:03 PM, David Wong davidtlw...@gmail.com wrote:
On Tue, Mar 31, 2009 at 11:46 AM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
On Mon, Mar 30, 2009 at 11:39 PM, David Wong davidtlw...@gmail.com wrote:
On Tue, Mar 31, 2009 at 10:57 AM, Devin Heitmueller
devin.heitmuel...@gmail.com wrote:
On Mon, Mar 30, 2009 at 10:47 PM, David Wong davidtlw...@gmail.com wrote:
Does anyone know how to get XC5000 working for DVB-T, especially 8MHz
bandwidth?
Current driver only supports ATSC with 6MHz bandwidth only.
It seems there is a trick at setting compensated RF frequency.
DVB-T 8MHz support would probably works for DMB-TH, but DMB-TH
settings is very welcome.
Regards,
David
--
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
All of my xc5000 work has been with ATSC/QAM, so I can't say
authoritatively what is required to make it work.
Well, at a minimum you will have to modify xc5000_set_params to
support setting priv-video_standard to DTV8. Beyond that, I don't
think you need to do anything specific for DVB-T.
Devin
--
Devin J. Heitmueller
http://www.devinheitmueller.com
AIM: devinheitmueller
I have tried followings in xc5000_set_params()
if (fe-ops.info.type == FE_ATSC) {
...
} else if (fe-ops.info.type == FE_OFDM) {
switch (params-u.ofdm.bandwidth) {
case BANDWIDTH_6_MHZ:
printk(xc5000 bandwidth 6MHz\n);
priv-bandwidth = BANDWIDTH_6_MHZ;
priv-video_standard = DTV6;
break;
case BANDWIDTH_7_MHZ:
printk(xc5000 bandwidth 7MHz\n);
priv-bandwidth = BANDWIDTH_7_MHZ;
priv-video_standard = DTV7;
break;
case BANDWIDTH_8_MHZ:
printk(xc5000 bandwidth 8MHz\n);
priv-bandwidth = BANDWIDTH_8_MHZ;
priv-video_standard = DTV8;
break;
default:
printk(xc5000 bandwidth not set!\n);
return -EINVAL;
}
priv-rf_mode = XC_RF_MODE_AIR;
priv-freq_hz = params-frequency - 175;
}
But no success yet.
I am wondering the -175 compensation for DTV8.
BTW, The xc_debug_dump() could get more information like firmware
build number and tuner total gain
diff -r 2276e777f950 linux/drivers/media/common/tuners/xc5000.c
--- a/linux/drivers/media/common/tuners/xc5000.c Thu Mar 26 22:17:48
2009 -0300
+++ b/linux/drivers/media/common/tuners/xc5000.c Mon Mar 30 16:23:11
2009 +0800
@@ -84,6 +84,7 @@
#define XREG_IF_OUT 0x05
#define XREG_SEEK_MODE 0x07
#define XREG_POWER_DOWN 0x0A
+#define XREG_OUTPUT_AMP 0x0B
#define XREG_SIGNALSOURCE 0x0D /* 0=Air, 1=Cable */
#define XREG_SMOOTHEDCVBS 0x0E
#define XREG_XTALFREQ 0x0F
@@ -100,6 +101,8 @@
#define XREG_VERSION 0x07
#define XREG_PRODUCT_ID 0x08
#define XREG_BUSY 0x09
+#define XREG_BUILD_NUM 0x0D
+#define XREG_TOTAL_GAIN 0x0F
/*
Basic firmware description. This will remain with
@@ -468,7 +485,8 @@
static int xc_get_version(struct xc5000_priv *priv,
u8 *hw_majorversion, u8 *hw_minorversion,
- u8 *fw_majorversion, u8 *fw_minorversion)
+ u8 *fw_majorversion, u8 *fw_minorversion,
+ u16 *fw_buildnum)
{
u16 data;
int result;
@@ -481,6 +499,11 @@
(*hw_minorversion) = (data 8) 0x0F;
(*fw_majorversion) = (data 4) 0x0F;
(*fw_minorversion) = data 0x0F;
+
+ result = xc_read_reg(priv, XREG_BUILD_NUM, data);
+ if (result)
+ return result;
+ *fw_buildnum = data;
return 0;
}
@@ -506,6 +529,11 @@
static int xc_get_quality(struct xc5000_priv *priv, u16 *quality)
{
return xc_read_reg(priv, XREG_QUALITY, quality);
+}
+
+static int xc_get_total_gain(struct xc5000_priv *priv, u16 *gain)
+{
+ return xc_read_reg(priv, XREG_TOTAL_GAIN, gain);
}
static u16 WaitForLock(struct xc5000_priv *priv)
@@ -626,8 +654,10 @@
u32 hsync_freq_hz = 0;
u16 frame_lines;
u16 quality;
+ u16 gain;
u8 hw_majorversion = 0, hw_minorversion = 0;
u8 fw_majorversion = 0, fw_minorversion = 0;
+ u16 fw_buildnum = 0;
/* Wait for stats to stabilize.
* Frame Lines needs two frame times after initial lock
@@ -646,10 +676,11 @@
lock_status);
xc_get_version(priv, hw_majorversion, hw_minorversion,
- fw_majorversion, fw_minorversion);
- dprintk(1, *** HW: V%02x.%02x, FW: V%02x.%02x\n,
+ fw_majorversion,
Re: [PATCH] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
On Tue, Mar 17, 2009 at 11:55 AM, David Wong davidtlw...@gmail.com wrote: This patch contains the unified driver for Legend Silicon LGS8913 and LGS8GL5. It should replace lgs8gl5.c in media/dvb/frontends David T.L. Wong David, The questions you posed tonight on a separate thread about making the xc5000 work with this device prompts the question: Do you know that this driver you submitted actually works? Have you successfully achieved lock with this driver and been able to view the stream? It is great to see the improvements and more generic support, but if you don't have it working in at least one device, then it probably shouldn't be submitted upstream yet, and it definitely should not be replacing an existing driver. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework
Thanks, Vaibhav Hiremath -Original Message- From: Aguirre Rodriguez, Sergio Alberto Sent: Monday, March 30, 2009 9:10 PM To: Hiremath, Vaibhav; linux-media@vger.kernel.org Cc: DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux- o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Hans Verkuil; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: RE: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hi Vaibhav, Please find some comments below -Original Message- From: Hiremath, Vaibhav Sent: Monday, March 30, 2009 8:35 AM To: linux-media@vger.kernel.org Cc: Aguirre Rodriguez, Sergio Alberto; DongSoo(Nathaniel) Kim; Toivonen Tuukka.O (Nokia-D/Oulu); linux-o...@vger.kernel.org; Nagalla, Hari; Sakari Ailus; Hans Verkuil; Jadav, Brijesh R; R, Sivaraj; Hadli, Manjunath; Shah, Hardik; Kumar, Purushotam Subject: [RFC] Stand-alone Resizer/Previewer Driver support under V4L2 framework Hi, With reference to the mail-thread started by Sakari on Resizer driver interface, http://marc.info/?l=linux-omapm=123628392325716w=2 I would like to bring some issues and propose changes to adapt such devices under V4L2 framework. Sorry for delayed response on this mail- thread, actually I was on vacation. As proposed by Sakari, I do agree with the approach of having V4L2 interface for memory-to-memory operation of the ISP (like resizer and previewer), but I would like to bring some important aspects/issues here - - Some drawbacks of V4L2-buf layer framework for such kind of devices - Need for backward compatibility. Drawbacks for V4L2-Buf layer - - 1} In case of resizer driver, the input buffer will always be different than output buffer. In case of Mmapped buffer there is no issue, since driver allocates maximum of input and output. User doesn't have control on this, although there is loss of memory from system point of view. In case of User Pointer Exchange, User would expect and may allocate different sizes of buffers for input and output which V4L2-buf layer doesn't support with single queue. And to address this, I think here we need to have either of following approaches - - Use two separate buffer queues, one for input and another for output. - Or hack the driver for v4l2_buffer, internally using different buffer params for input and output. [Not recommended] Please note that sometimes application receives buffers from another driver or from some codecs engine that's why input and output buffer will never be of same size. 2) V4L2-buf layer doesn't support IOMEM coming from user application. Just to give low level details about this - When application tries to configure for 'V4L2_MEMORY_USERPTR' with buffer coming from another driver (which is iomampped), then QUEUEBUF ioctl will fail from 'videobuf_iolock' -- videobuf_dma_init_user_locked -- get_user_pages. In 'get_user_pages' it checks for IOMEM flag and returns error, which is expected behavior from Kernel point of view. We are trying to map buffer which is already mapped to kernel by another driver. I'm not sure if I understood the problem right... Can you please help me clarify? So, basically the problem is that both drivers needs to associate a single buffer with 2 different DMA transfers at the same time (one from other driver, and other from ISP) Is that correct? [Hiremath, Vaibhav] No, Let's take real-time example here, say you have 128 Mb DDR available with you and you have asked linux to use only say 80Mb. And rest of the memory you are mapping to kernel from some another driver using ioremap. This is valid use-case, since most of application does this due to memory fragmentation. Now you want to use this ioremapped buffer for your capture driver as a use pointer exchange mechanism. And here it fails due to issues as I explained before. One thing I am not able to understand, how nobody came across such use- case which is very common. And to address this issue we need to add support for IOMEM in V4L2-buf layer. NOTE: Currently both of these issues have been addressed as a custom implementation for our internal use case. Backward Compatibility - --- This is an important aspect, since similar hardware modules are available on Davinci as well as on OMAP and their driver interface is completely different. On Davinci, resizer driver is supported through plane char driver interface which handles all data/buffer processing and control paths. It maintains internal queue for priority of resizing tasks and stuff. The driver is present under /drivers/char/Davinci. Here I feel, V4L2 way is better, since all image processing drivers should go under drivers/media/video/. And again we can
Re: [PATCH] Support for Legend Silicon LGS8913/LGS8GL5/LGS8GXX China DMB-TH digital demodulator
Devin The unified LGS8GXX driver surely work on some DMB-TH devices I have. They are: TECHGEAR HDTVC USB (also for MagicPro ProHDTV USB as they are the same hardware with same USB ID) ASUS U3100 Mini DMB-TH USB Timothy Lee tested with this unified driver for his MagicPro ProHDTV USB too. ASUS patch is sent to Alan Knowles, don't know his result yet. David On Tue, Mar 31, 2009 at 12:54 PM, Devin Heitmueller devin.heitmuel...@gmail.com wrote: On Tue, Mar 17, 2009 at 11:55 AM, David Wong davidtlw...@gmail.com wrote: This patch contains the unified driver for Legend Silicon LGS8913 and LGS8GL5. It should replace lgs8gl5.c in media/dvb/frontends David T.L. Wong David, The questions you posed tonight on a separate thread about making the xc5000 work with this device prompts the question: Do you know that this driver you submitted actually works? Have you successfully achieved lock with this driver and been able to view the stream? It is great to see the improvements and more generic support, but if you don't have it working in at least one device, then it probably shouldn't be submitted upstream yet, and it definitely should not be replacing an existing driver. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- 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
