Re: [PATCH 3/4] soc-camera: add support for camera-host controls
On Fri, 12 Jun 2009, Dongsoo, Nathaniel Kim wrote: Hello Guennadi, So let's assume that camera interface device can process V4L2_CID_SHARPNESS and even external camera device can process that, then according to your patch both of camera interface and external camera device can be issued to process V4L2_CID_SHARPNESS which I guess will make image sharpened twice. Am I getting the patch right? Please, do not top-post! I am sorry, is it really so difficult to understand + ret = ici-ops-set_ctrl(icd, ctrl); + if (ret != -ENOIOCTLCMD) + return ret; which means just one thing: the camera host (interface if you like) driver decides, whether it wants client's control to be called, in which case it has to return -ENOIOCTLCMD, or it returns any other code (0 or a negative error code), then the client will not be called. If I'm getting right, it might be better to give user make a choice through platform data or some sort of variable which can make a choice between camera interface and camera device to process the CID. It could be just in aspect of manufacturer mind, we do love to make a choice between same features in different devices in easy way. So never mind if my idea is not helpful making your driver elegant :-) So far it seems too much to me. Let's wait until we get a case where it really makes sense for platform code to decide who processes certain controls. I think giving the host driver the power to decide should be ok for now. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GPL code for Omnivision USB video camera available.
On 06/12/2009 03:02 AM, Erik de Castro Lopo wrote: Hi all, I have a driver for a USB video camera that I'd like to see added to the mainline kernel, mainly so I don't have to fix breakage due to constant changes in the kernel :-). The code is GPL and is available here: http://stage.bcode.com/erikd/ovcamchip and the history of this code is here: http://stage.bcode.com/erikd/ovcamchip/README My problem is that I am way too busy to sheperd this into the kernel myself. If someone is willing to work on getting this in, I can send them a camera to keep. If getting paid is more likely to help someone focus on the task then that is also a possibility. Any takers? Please email me privately. This looks to me like its just ov51x-jpeg made to compile with the latest kernel. Did you make any functional changes? Note that ov51x-jpeg is not acceptable as is as it does in kernel decompression of the ov51x jpeg-like compression format. I'm currently finishing up adding ov511(+) and ov518(+) support to the gspca ov519 subdriver. And I've already added support for decompressing their format in userspace to libv4l. Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline. I've already announced my work on getting the ov511(+) and ov518(+) supported properly in the mainline kernel there. May I ask what cam you have? I could certainly use more people testing this. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[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: - v4l: i2c modules must be linked before the v4l2 drivers This fixes the linking bug introduced in 2.6.30. I've also attached a diff with the same changes that applies directly to the 2.6.30 release. Thanks, Hans diffstat: Makefile | 70 +-- saa7134/Makefile |3 -- 2 files changed, 38 insertions(+), 35 deletions(-) -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom diff -ur linux/drivers/media/video.org/Makefile linux/drivers/media/video/Makefile --- linux/drivers/media/video.org/Makefile 2009-06-12 08:42:20.0 +0200 +++ linux/drivers/media/video/Makefile 2009-06-12 00:45:46.0 +0200 @@ -12,6 +12,8 @@ videodev-objs := v4l2-dev.o v4l2-ioctl.o v4l2-device.o +# V4L2 core modules + obj-$(CONFIG_VIDEO_DEV) += videodev.o v4l2-int-device.o ifeq ($(CONFIG_COMPAT),y) obj-$(CONFIG_VIDEO_DEV) += v4l2-compat-ioctl32.o @@ -23,21 +25,15 @@ obj-$(CONFIG_VIDEO_DEV) += v4l1-compat.o endif -obj-$(CONFIG_VIDEO_TUNER) += tuner.o +# All i2c modules must come first: -obj-$(CONFIG_VIDEO_BT848) += bt8xx/ -obj-$(CONFIG_VIDEO_IR_I2C) += ir-kbd-i2c.o +obj-$(CONFIG_VIDEO_TUNER) += tuner.o obj-$(CONFIG_VIDEO_TVAUDIO) += tvaudio.o obj-$(CONFIG_VIDEO_TDA7432) += tda7432.o obj-$(CONFIG_VIDEO_TDA9875) += tda9875.o - obj-$(CONFIG_VIDEO_SAA6588) += saa6588.o obj-$(CONFIG_VIDEO_SAA5246A) += saa5246a.o obj-$(CONFIG_VIDEO_SAA5249) += saa5249.o -obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o -obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o -obj-$(CONFIG_VIDEO_W9966) += w9966.o - obj-$(CONFIG_VIDEO_TDA9840) += tda9840.o obj-$(CONFIG_VIDEO_TEA6415C) += tea6415c.o obj-$(CONFIG_VIDEO_TEA6420) += tea6420.o @@ -54,11 +50,40 @@ obj-$(CONFIG_VIDEO_BT856) += bt856.o obj-$(CONFIG_VIDEO_BT866) += bt866.o obj-$(CONFIG_VIDEO_KS0127) += ks0127.o +obj-$(CONFIG_VIDEO_VINO) += indycam.o +obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o +obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o +obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o +obj-$(CONFIG_VIDEO_CS5345) += cs5345.o +obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o +obj-$(CONFIG_VIDEO_M52790) += m52790.o +obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o +obj-$(CONFIG_VIDEO_WM8775) += wm8775.o +obj-$(CONFIG_VIDEO_WM8739) += wm8739.o +obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o +obj-$(CONFIG_VIDEO_CX25840) += cx25840/ +obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o +obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o +obj-$(CONFIG_VIDEO_OV7670) += ov7670.o +obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o +obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o -obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_SOC_CAMERA_MT9M001) += mt9m001.o +obj-$(CONFIG_SOC_CAMERA_MT9M111) += mt9m111.o +obj-$(CONFIG_SOC_CAMERA_MT9T031) += mt9t031.o +obj-$(CONFIG_SOC_CAMERA_MT9V022) += mt9v022.o +obj-$(CONFIG_SOC_CAMERA_OV772X) += ov772x.o +obj-$(CONFIG_SOC_CAMERA_TW9910) += tw9910.o +# And now the v4l2 drivers: + +obj-$(CONFIG_VIDEO_BT848) += bt8xx/ +obj-$(CONFIG_VIDEO_ZORAN) += zoran/ +obj-$(CONFIG_VIDEO_CQCAM) += c-qcam.o +obj-$(CONFIG_VIDEO_BWQCAM) += bw-qcam.o +obj-$(CONFIG_VIDEO_W9966) += w9966.o obj-$(CONFIG_VIDEO_PMS) += pms.o -obj-$(CONFIG_VIDEO_VINO) += vino.o indycam.o +obj-$(CONFIG_VIDEO_VINO) += vino.o obj-$(CONFIG_VIDEO_STRADIS) += stradis.o obj-$(CONFIG_VIDEO_CPIA) += cpia.o obj-$(CONFIG_VIDEO_CPIA_PP) += cpia_pp.o @@ -69,17 +94,7 @@ obj-$(CONFIG_VIDEO_EM28XX) += em28xx/ obj-$(CONFIG_VIDEO_CX231XX) += cx231xx/ obj-$(CONFIG_VIDEO_USBVISION) += usbvision/ -obj-$(CONFIG_VIDEO_TVP5150) += tvp5150.o -obj-$(CONFIG_VIDEO_TVP514X) += tvp514x.o obj-$(CONFIG_VIDEO_PVRUSB2) += pvrusb2/ -obj-$(CONFIG_VIDEO_MSP3400) += msp3400.o -obj-$(CONFIG_VIDEO_CS5345) += cs5345.o -obj-$(CONFIG_VIDEO_CS53L32A) += cs53l32a.o -obj-$(CONFIG_VIDEO_M52790) += m52790.o -obj-$(CONFIG_VIDEO_TLV320AIC23B) += tlv320aic23b.o -obj-$(CONFIG_VIDEO_WM8775) += wm8775.o -obj-$(CONFIG_VIDEO_WM8739) += wm8739.o -obj-$(CONFIG_VIDEO_VP27SMPX) += vp27smpx.o obj-$(CONFIG_VIDEO_OVCAMCHIP) += ovcamchip/ obj-$(CONFIG_VIDEO_CPIA2) += cpia2/ obj-$(CONFIG_VIDEO_MXB) += mxb.o @@ -92,19 +107,12 @@ obj-$(CONFIG_VIDEOBUF_VMALLOC) += videobuf-vmalloc.o obj-$(CONFIG_VIDEOBUF_DVB) += videobuf-dvb.o obj-$(CONFIG_VIDEO_BTCX) += btcx-risc.o -obj-$(CONFIG_VIDEO_TVEEPROM) += tveeprom.o obj-$(CONFIG_VIDEO_M32R_AR_M64278) += arv.o -obj-$(CONFIG_VIDEO_CX25840) += cx25840/ -obj-$(CONFIG_VIDEO_UPD64031A) += upd64031a.o -obj-$(CONFIG_VIDEO_UPD64083) += upd64083.o obj-$(CONFIG_VIDEO_CX2341X) += cx2341x.o obj-$(CONFIG_VIDEO_CAFE_CCIC) += cafe_ccic.o -obj-$(CONFIG_VIDEO_OV7670) += ov7670.o - -obj-$(CONFIG_VIDEO_TCM825X) += tcm825x.o obj-$(CONFIG_USB_DABUSB)+= dabusb.o obj-$(CONFIG_USB_OV511) += ov511.o @@ -134,24 +142,21 @@ obj-$(CONFIG_VIDEO_VIVI) += vivi.o obj-$(CONFIG_VIDEO_CX23885) += cx23885/ +obj-$(CONFIG_VIDEO_OMAP2) += omap2cam.o +obj-$(CONFIG_SOC_CAMERA)
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 5 changesets: 01/05: gspca - spca505: Reinitialize the webcam at resume time. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=61038fe967ba 02/05: gspca - ov519: Add support for the ov518 bridge. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=1deebaddcd75 03/05: gspca - doc: Add the 05a9:a518 webcam to the Documentation. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=fad82d75076a 04/05: gspca - main: Skip disabled controls. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=e86acef4fcfe 05/05: gspca - ov534: Do the ov772x work again. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=42367b10eb99 Documentation/video4linux/gspca.txt |5 drivers/media/video/gspca/gspca.c | 122 drivers/media/video/gspca/ov519.c | 520 +--- drivers/media/video/gspca/ov534.c |4 drivers/media/video/gspca/spca505.c | 14 include/linux/videodev2.h |3 6 files changed, 562 insertions(+), 106 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 3/4] soc-camera: add support for camera-host controls
On Fri, Jun 12, 2009 at 3:30 PM, Guennadi Liakhovetskig.liakhovet...@gmx.de wrote: On Fri, 12 Jun 2009, Dongsoo, Nathaniel Kim wrote: Hello Guennadi, So let's assume that camera interface device can process V4L2_CID_SHARPNESS and even external camera device can process that, then according to your patch both of camera interface and external camera device can be issued to process V4L2_CID_SHARPNESS which I guess will make image sharpened twice. Am I getting the patch right? Please, do not top-post! Sorry for top-posting. just forgot the netiquette. I am sorry, is it really so difficult to understand + ret = ici-ops-set_ctrl(icd, ctrl); + if (ret != -ENOIOCTLCMD) + return ret; which means just one thing: the camera host (interface if you like) driver decides, whether it wants client's control to be called, in which case it has to return -ENOIOCTLCMD, or it returns any other code (0 or a negative error code), then the client will not be called. yes I understand what you intended. but what I wanted to tell you was with this way, user should modify the camera host driver if they want to make camera host to return -ENOIOCTLCMD. If I'm getting right, it might be better to give user make a choice through platform data or some sort of variable which can make a choice between camera interface and camera device to process the CID. It could be just in aspect of manufacturer mind, we do love to make a choice between same features in different devices in easy way. So never mind if my idea is not helpful making your driver elegant :-) So far it seems too much to me. Let's wait until we get a case where it really makes sense for platform code to decide who processes certain controls. I think giving the host driver the power to decide should be ok for now. I totally understand. you are already doing a great job. I won't push you. Cheers, Nate Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- = DongSoo, Nathaniel Kim Engineer Mobile S/W Platform Lab. Digital Media Communications RD Centre Samsung Electronics CO., LTD. e-mail : dongsoo@gmail.com dongsoo45@samsung.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4l-dvb-maintainer] 2.6.30: missing audio device in bttv
On Fri, 12 Jun 2009 01:18:20 +0200, Hans Verkuil wrote: On Friday 12 June 2009 01:07:46 Mauro Carvalho Chehab wrote: I suspect that we'll need to work with the initialization order after the new i2c binding model to avoid such troubles. I remember that we had a similar issue with alsa and saa7134. At the end, Linus [1] had to do add this, as a quick hack (unfortunately, it is still there - it seems that alsa guys forgot about that issue): late_initcall(saa7134_alsa_init); On that time, he suggested the usage of subsys_initcall() for alsa. I suspect that we'll need to do the same for I2C and for V4L core. I'm not sure what would be the alternative to be done with i2c ancillary drivers. Maybe one alternative would be to use fs_initcall, that seems to be already used by some non-fs related calls, like cpu governor [2]. As long as the i2c modules come first there shouldn't be any problem. That's pretty easy to arrange. So the i2c core inits first, then i2c drivers, then v4l2 drivers. That's the proper order. This is already what we have in 2.6.30 as far as I can see. The ir-kbd-i2c module needed to be after the v4l2 modules since that still relies on autoprobing. If it comes first, then it seems to mess up tveeprom for some reason. Once ir-kbd-i2c no longer does autoprobing, then it probably should move back to the other i2c modules. Hopefully this will happen in the next few days :) -- Jean Delvare -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] SDMC DM1105N not being detected
On 6 June 2009 23:37:47 Simon Kenyon wrote:
Igor M. Liplianin wrote:
On 5 June 2009 21:41:46 Simon Kenyon wrote:
Simon Kenyon wrote:
Simon Kenyon wrote:
the picture seems to be breaking up badly
will revert to my version and see if that fixes it
[sorry for the delay. i was away on business]
i've checked and your original code, modified to compile and including
my changes to control the LNB works very well; the patch you posted
does not. i have swapped between the two and rebooted several times to
make sure.
i will do a diff and see what the differences are
regards
--
simon
the main changes seem to be a reworking of the interrupt handling and
some i2c changes
--
simon
How fast is your system?
reasonably fast
it is a dual core AMD64 X2 running at 3.1GHz
Main change is to move demuxing from interrupt to work handler.
So I prepaired another patch, with separate work queue.
May be you find some time to test.
I wonder CPU usage and interrupts count(cat /proc/interrupts) while viewing
DVB.
I guess your card generates a lot of unnecessary(unknown ?) irq's.
Another idea is to increase dma buffer.
# HG changeset patch
# User Igor M. Liplianin liplia...@me.by
# Date 1244794252 -10800
# Node ID cd2cbde46892c2ad8258dd3162c5585e542afd50
# Parent bff77ec331161c660be7a60bf6139df000758480
Add support for yet another SDMC DM1105 based DVB-S card.
From: Igor M. Liplianin liplia...@me.by
Add support for SDMC DM1105 based DVB-S cards with PCI ID 195d:1105
Signed-off-by: Igor M. Liplianin liplia...@me.by
diff -r bff77ec33116 -r cd2cbde46892 linux/drivers/media/dvb/dm1105/dm1105.c
--- a/linux/drivers/media/dvb/dm1105/dm1105.c Thu Jun 11 18:44:23 2009 -0300
+++ b/linux/drivers/media/dvb/dm1105/dm1105.c Fri Jun 12 11:10:52 2009 +0300
@@ -51,6 +51,9 @@
#ifndef PCI_VENDOR_ID_TRIGEM
#define PCI_VENDOR_ID_TRIGEM 0x109f
#endif
+#ifndef PCI_VENDOR_ID_AXESS
+#define PCI_VENDOR_ID_AXESS 0x195d
+#endif
#ifndef PCI_DEVICE_ID_DM1105
#define PCI_DEVICE_ID_DM1105 0x036f
#endif
@@ -60,6 +63,9 @@
#ifndef PCI_DEVICE_ID_DW2004
#define PCI_DEVICE_ID_DW2004 0x2004
#endif
+#ifndef PCI_DEVICE_ID_DM05
+#define PCI_DEVICE_ID_DM05 0x1105
+#endif
/* --- */
/* sdmc dm1105 registers */
@@ -150,6 +156,11 @@
#define DM1105_LNB_13V0x00010100
#define DM1105_LNB_18V0x0100
+/* GPIO's for LNB power control for Axess DM05 */
+#define DM05_LNB_MASK0x
+#define DM05_LNB_13V0x0002
+#define DM05_LNB_18V0x0003
+
static int ir_debug;
module_param(ir_debug, int, 0644);
MODULE_PARM_DESC(ir_debug, enable debugging information for IR decoding);
@@ -188,6 +199,8 @@
/* irq */
struct work_struct work;
+ struct workqueue_struct *wq;
+ char wqn[16];
/* dma */
dma_addr_t dma_addr;
@@ -316,15 +329,25 @@
static int dm1105dvb_set_voltage(struct dvb_frontend *fe, fe_sec_voltage_t voltage)
{
struct dm1105dvb *dm1105dvb = frontend_to_dm1105dvb(fe);
+ u32 lnb_mask, lnb_13v, lnb_18v;
- if (voltage == SEC_VOLTAGE_18) {
- outl(DM1105_LNB_MASK, dm_io_mem(DM1105_GPIOCTR));
- outl(DM1105_LNB_18V, dm_io_mem(DM1105_GPIOVAL));
- } else {
- /*LNB ON-13V by default!*/
- outl(DM1105_LNB_MASK, dm_io_mem(DM1105_GPIOCTR));
- outl(DM1105_LNB_13V, dm_io_mem(DM1105_GPIOVAL));
- }
+ switch (dm1105dvb-pdev-subsystem_device) {
+ case PCI_DEVICE_ID_DM05:
+ lnb_mask = DM05_LNB_MASK;
+ lnb_13v = DM05_LNB_13V;
+ lnb_18v = DM05_LNB_18V;
+ break;
+ default:
+ lnb_mask = DM1105_LNB_MASK;
+ lnb_13v = DM1105_LNB_13V;
+ lnb_18v = DM1105_LNB_18V;
+ }
+
+ outl(lnb_mask, dm_io_mem(DM1105_GPIOCTR));
+ if (voltage == SEC_VOLTAGE_18)
+ outl(lnb_18v , dm_io_mem(DM1105_GPIOVAL));
+ else
+ outl(lnb_13v, dm_io_mem(DM1105_GPIOVAL));
return 0;
}
@@ -463,7 +486,7 @@
case (INTSTS_TSIRQ | INTSTS_IR):
dm1105dvb-nextwrp = inl(dm_io_mem(DM1105_WRP)) -
inl(dm_io_mem(DM1105_STADR));
- schedule_work(dm1105dvb-work);
+ queue_work(dm1105dvb-wq, dm1105dvb-work);
break;
case INTSTS_IR:
dm1105dvb-ir.ir_command = inl(dm_io_mem(DM1105_IRCODE));
@@ -599,46 +622,44 @@
int ret;
switch (dm1105dvb-pdev-subsystem_device) {
- case PCI_DEVICE_ID_DW2002:
- dm1105dvb-fe = dvb_attach(
- stv0299_attach, sharp_z0194a_config,
- dm1105dvb-i2c_adap);
-
- if (dm1105dvb-fe) {
- dm1105dvb-fe-ops.set_voltage =
- dm1105dvb_set_voltage;
- dvb_attach(dvb_pll_attach, dm1105dvb-fe, 0x60,
- dm1105dvb-i2c_adap, DVB_PLL_OPERA1);
- }
-
- if (!dm1105dvb-fe) {
- dm1105dvb-fe = dvb_attach(
-stv0288_attach, earda_config,
-dm1105dvb-i2c_adap);
- if (dm1105dvb-fe) {
-dm1105dvb-fe-ops.set_voltage =
- dm1105dvb_set_voltage;
-dvb_attach(stb6000_attach, dm1105dvb-fe, 0x61,
- dm1105dvb-i2c_adap);
- }
- }
-
- if (!dm1105dvb-fe) {
- dm1105dvb-fe = dvb_attach(
-si21xx_attach, serit_config,
-dm1105dvb-i2c_adap);
- if (dm1105dvb-fe)
-dm1105dvb-fe-ops.set_voltage =
-
Re: [PATCH] adding support for setting bus parameters in sub device
On Wed, 10 Jun 2009, Hans Verkuil wrote: On Wednesday 10 June 2009 23:30:55 Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Hans Verkuil wrote: My view of this would be that the board specification specifies the sensor (and possibly other chips) that are on the board. And to me it makes sense that that also supplies the bus settings. I agree that it is not complex code, but I think it is also unnecessary code. Why negotiate if you can just set it? Why force all platforms to set it if the driver is perfectly capable do this itself? As I said - this is not a platform-specific feature, it's chip-specific. What good would it make to have all platforms using mt9t031 to specify, that yes, the chip can use both falling and rising pclk edge, but only active high vsync and hsync? ??? You will just tell the chip what to use. So you set 'use falling edge' and either set 'active high vsync/hsync' or just leave that out since you know the mt9t031 has that fixed. You don't specify in the platform data what the chip can support, that's not relevant. You know what the host expects and you pass that information on to the chip. A board designer knows what the host supports, knows what the sensor supports, and knows if he added any inverters on the board, and based on all that information he can just setup these parameters for the sensor chip. Settings that are fixed on the sensor chip he can just ignore, he only need to specify those settings that the sensor really needs. I'd like to have this resolved somehow (preferably my way of ourse:-)), here once again (plus some new) my main arguments: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! 2. what if you do have an inverter between the two? You'd have to tell the sensor to use active high, and the host to use active low, i.e., you need two sets of flags. 3. all soc-camera boards rely on this autonegotiation. Do we really want (and have) to add this useless information back to them? Back - because, yes, we've been there we've done that before, but then we switched to the current autonegotiation, which we are perfectly happy with so far (anyone dares to object?:-)). 4. the autonegiation code is simple and small, so, I really don't see a reason to hardcode something, that we can perfectly autoconfigure. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] adding support for setting bus parameters in sub device
On Wed, 10 Jun 2009, Hans Verkuil wrote: On Wednesday 10 June 2009 23:30:55 Guennadi Liakhovetski wrote: On Wed, 10 Jun 2009, Hans Verkuil wrote: My view of this would be that the board specification specifies the sensor (and possibly other chips) that are on the board. And to me it makes sense that that also supplies the bus settings. I agree that it is not complex code, but I think it is also unnecessary code. Why negotiate if you can just set it? Why force all platforms to set it if the driver is perfectly capable do this itself? As I said - this is not a platform-specific feature, it's chip-specific. What good would it make to have all platforms using mt9t031 to specify, that yes, the chip can use both falling and rising pclk edge, but only active high vsync and hsync? ??? You will just tell the chip what to use. So you set 'use falling edge' and either set 'active high vsync/hsync' or just leave that out since you know the mt9t031 has that fixed. You don't specify in the platform data what the chip can support, that's not relevant. You know what the host expects and you pass that information on to the chip. A board designer knows what the host supports, knows what the sensor supports, and knows if he added any inverters on the board, and based on all that information he can just setup these parameters for the sensor chip. Settings that are fixed on the sensor chip he can just ignore, he only need to specify those settings that the sensor really needs. I'd like to have this resolved somehow (preferably my way of ourse:-)), here once again (plus some new) my main arguments: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. 2. what if you do have an inverter between the two? You'd have to tell the sensor to use active high, and the host to use active low, i.e., you need two sets of flags. You obviously need to set this for both the host and for the sub-device. The s_bus op in v4l2_subdev is meant to set the sub-device. Setting this up for the host is a platform/board issue. 3. all soc-camera boards rely on this autonegotiation. Do we really want (and have) to add this useless information back to them? Back - because, yes, we've been there we've done that before, but then we switched to the current autonegotiation, which we are perfectly happy with so far (anyone dares to object?:-)). Well, I do :-) This is not useless information and particularly at high clock frequencies (e.g. 74.25 MHz or higher) you do want to have full control over this. Remember that this API is not only meant for sensor devices, but also for HDTV video receivers. 4. the autonegiation code is simple and small, so, I really don't see a reason to hardcode something, that we can perfectly autoconfigure. The fact that that code exists doesn't mean that we also have to use it. While I am not a hardware engineer myself, I do work closely together with them. And having seen some of the tricky things that can go wrong with timings I think there is a very good case against autoconfiguring these things. For simple designs where the timings aren't critical I am sure that autoconfiguring works fine, but when you get to HD quality video streaming then it does become an issue. And this will become ever more important in the future as the pixel clock frequencies keep increasing. 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] adding support for setting bus parameters in sub device
On Fri, 12 Jun 2009, Hans Verkuil wrote: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. I'd say this is different. You're talking about cases where you _want_ to be able to configure it explicitly, I am saying you do not have to _force_ all to do this. Now, this selection only makes sense if both are configurable, right? In this case, e.g., pxa270 driver does support platform-specified preference. So, if both the host and the client can configure either polarity in the software you _can_ still specify the preferred one in platform data and it will be used. I think, the ability to specify inverters and the preferred polarity should cover all possible cases. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] ASUS 'My Cinema Europa Hybrid' (P7131 DVB-T) [SAA7134] Firmware oddities
Sam Spilsbury wrote: Hi everyone, So It's my first time to LinuxTV hacking, debugging etc, so I apologize if I've failed to provide anything essential. Anyways, I've just bought a ASUS 'My Cinema Europa Hybrid' (P7131 DVB-T) which has the Phillips saa7131 chipset in it (supported by the saa7131 module et al). There is a problem getting the firmware in this card to boot correctly - I may have the wrong card number and I cannot use i2c because it detects it as UNKNOWN/GENERIC (i.e type 0) which doesn't work. According to /usr/share/doc/linux/video4linux etc my card number should be either 78, 111 or 112. Specifying card=x seems to make the module somewhat recognize the card, and even though I have the firmware - it won't actually boot. This is shown by the fact that all dvb operations essentially just time out and the fact that I cannot scan channels in software like tvtime. I might be wrong though. Here is relevant output which might assist in helping the problem: dmesg log c saa7130/34: v4l2 driver version 0.2.14 loaded saa7134[0]: found at :00:09.0, rev: 1, irq: 18, latency: 32, mmio: 0xeb007000 saa7134[0]: subsystem: 1043:4847, board: ASUSTeK P7131 Dual [card=78,insmod option] saa7134[0]: board init: gpio is 20 input: saa7134 IR (ASUSTeK P7131 Dual) as /devices/pci:00/:00:09.0/input/input7 tuner' 3-0043: chip found @ 0x86 (saa7134[0]) tda9887 3-0043: creating new instance tda9887 3-0043: tda988[5/6/7] found saa7134[0]: i2c eeprom 00: 43 10 47 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7134[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 02 03 ff 03 04 08 ff 00 2a ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 02 00 c2 86 10 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: registered device radio0 DVB: registering new adapter (saa7134[0]) DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: trying to boot from eeprom tda1004x: found firmware revision 26 -- ok saa7134[0]/dvb: could not access tda8290 I2C gate tda827x_probe_version: could not read from tuner at addr: 0xc2 = Relevant bits of lspci = 00:09.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: ASUSTeK Computer Inc. Device 4847 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 18 Region 0: Memory at eb007000 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Kernel driver in use: saa7134 Kernel modules: saa7134 Any help would be greatly appreciated however I understand if this isn't a fixable issue. If so it would be nice to know where I could buy (online) TV Tuner cards with a composite input, are the old PCI type and of course work well with Linux (Fedora 10 at least). Thanks in advance, Sam Hi Sam and everyone First off I'm new to the LinuxTV mailing list and just like Sam this is my first time hacking, debugging etc. I also have an ASUS 'My Cinema Europa Hybrid' and it is currently unsupported right now. However looking over the hardware component's on the card itself, it seems that the individual components seem to be supported and we merely have to get all the components interacting with each other. The card has a: * Philips SAA7134HL video decoder, which is supported by the saa7134 driver * Philips TDA10046A digital demodulator, which is supported by the tda1004x driver * Philips
USERPTR buffer exchange mechanism
Hi, I would like to explore what level of support is available in the v4l buffer exchange mechanism for USERPTR buffer exchange. In our internal release, we had a hack to support this feature. We use contiguous buffers in our user ptr hack implementation. The buffers are allocated in a kernel module that export api to pass the physical address of the allocated buffer to the user application. In the v4l2 driver, USERPTR IO mechanism will be requested, and in QBUF, the ptr passed to the driver is the above physical address. One thing we observed was that even in this case, we had to use index in the buffer structure without which it doesn't work. Anyone has any insight into how to port this capability to the open source kernel v4l2 driver? In other words, can I use userptr IO mechanism and pass contigous buffer address like above? If so, Is there a driver example I can refer to port this to my vpfe capture driver? Thanks in advance. Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH 0/10 - v2] ARM: DaVinci: Video: DM355/DM6446 VPFE Capture driver
This is the version v2 of the patch series. This is the reworked version of the driver based on comments received against the last version of the patch. I'll be glad to see this get to mainline ... it's seeming closer and closer! What's the merge plan though? I had hopes for 2.6.31.real-soon but several of the later patches comment Not sure if it can go in 2.6.31, but this has less comments to address then I can send a updated version next week. 2.6.32 is the targeted release. Applies to Davinci GIT Tree which implies not -next. DM355 patches are in the -next tree. Is this just an oversight (tracking -next can be a PITA!) or is there some other dependency? One dependency is the tvp514x sub device patch migration patch from Vaibhav. This is put for review, but couldn't see any comments. I have split the patches such that v4l2 part can applies independently followed by platform part. All of the platform part has Applies to Davinci GIT tree in the patch description and v4l2 part has Applies to v4l-dvb. The v4l2 part can go with out the platform changes, but platform part is dependent on the v4l2 part. I am not sure if I have answered your question. - -- 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] adding support for setting bus parameters in sub device
On Friday 12 June 2009 14:59:03 Guennadi Liakhovetski wrote: On Fri, 12 Jun 2009, Hans Verkuil wrote: 1. it is very unusual that the board designer has to mandate what signal polarity has to be used - only when there's additional logic between the capture device and the host. So, we shouldn't overload all boards with this information. Board-code authors will be grateful to us! I talked to my colleague who actually designs boards like that about what he would prefer. His opinion is that he wants to set this himself, rather than leave it as the result of a software negotiation. It simplifies verification and debugging the hardware, and in addition there may be cases where subtle timing differences between e.g. sampling on a falling edge vs rising edge can actually become an important factor, particularly on high frequencies. I'd say this is different. You're talking about cases where you _want_ to be able to configure it explicitly, I am saying you do not have to _force_ all to do this. Now, this selection only makes sense if both are configurable, right? In this case, e.g., pxa270 driver does support platform-specified preference. So, if both the host and the client can configure either polarity in the software you _can_ still specify the preferred one in platform data and it will be used. I think, the ability to specify inverters and the preferred polarity should cover all possible cases. In my opinion you should always want to set this explicitly. This is not something you want to leave to chance. Say you autoconfigure this. Now someone either changes the autoconf algorithm, or a previously undocumented register was discovered for the i2c device and it can suddenly configure the polarity of some signal that was previously thought to be fixed, or something else happens causing a different polarity to be negotiated. Suddenly the board doesn't work because it was never verified or tested with that different polarity. Or worse: it glitches only 0.001% of the time. That's going to be a nasty bug to find. You generally verify your board with specific bus settings, and that's what should also be configured explicitly. Sure, it is nice not to have to think about this. The problem is that I believe that you *have* to think about it. The longer I think about this, the more convinced I am that relying on autoconfiguration is a bad design. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-dvb] ASUS 'My Cinema Europa Hybrid' (P7131 DVB-T) [SAA7134] Firmware oddities
Hi, Am Samstag, den 13.06.2009, 00:23 +1000 schrieb chatura: Sam Spilsbury wrote: Hi everyone, So It's my first time to LinuxTV hacking, debugging etc, so I apologize if I've failed to provide anything essential. Anyways, I've just bought a ASUS 'My Cinema Europa Hybrid' (P7131 DVB-T) which has the Phillips saa7131 chipset in it (supported by the saa7131 module et al). There is a problem getting the firmware in this card to boot correctly - I may have the wrong card number and I cannot use i2c because it detects it as UNKNOWN/GENERIC (i.e type 0) which doesn't work. According to /usr/share/doc/linux/video4linux etc my card number should be either 78, 111 or 112. Specifying card=x seems to make the module somewhat recognize the card, and even though I have the firmware - it won't actually boot. This is shown by the fact that all dvb operations essentially just time out and the fact that I cannot scan channels in software like tvtime. I might be wrong though. Here is relevant output which might assist in helping the problem: dmesg log c saa7130/34: v4l2 driver version 0.2.14 loaded saa7134[0]: found at :00:09.0, rev: 1, irq: 18, latency: 32, mmio: 0xeb007000 saa7134[0]: subsystem: 1043:4847, board: ASUSTeK P7131 Dual [card=78,insmod option] saa7134[0]: board init: gpio is 20 input: saa7134 IR (ASUSTeK P7131 Dual) as /devices/pci:00/:00:09.0/input/input7 tuner' 3-0043: chip found @ 0x86 (saa7134[0]) tda9887 3-0043: creating new instance tda9887 3-0043: tda988[5/6/7] found saa7134[0]: i2c eeprom 00: 43 10 47 48 54 20 1c 00 43 43 a9 1c 55 d2 b2 92 saa7134[0]: i2c eeprom 10: 00 ff 82 0e ff 20 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 20: 01 40 01 02 03 ff 03 04 08 ff 00 2a ff ff ff ff saa7134[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 40: ff 02 00 c2 86 10 ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff saa7134[0]: registered device video0 [v4l2] saa7134[0]: registered device vbi0 saa7134[0]: registered device radio0 DVB: registering new adapter (saa7134[0]) DVB: registering frontend 0 (Philips TDA10046H DVB-T)... tda1004x: setting up plls for 48MHz sampling clock tda1004x: timeout waiting for DSP ready tda1004x: found firmware revision 0 -- invalid tda1004x: trying to boot from eeprom tda1004x: found firmware revision 26 -- ok saa7134[0]/dvb: could not access tda8290 I2C gate tda827x_probe_version: could not read from tuner at addr: 0xc2 = Relevant bits of lspci = 00:09.0 Multimedia controller: Philips Semiconductors SAA7134/SAA7135HL Video Broadcast Decoder (rev 01) Subsystem: ASUSTeK Computer Inc. Device 4847 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (21000ns min, 8000ns max) Interrupt: pin A routed to IRQ 18 Region 0: Memory at eb007000 (32-bit, non-prefetchable) [size=1K] Capabilities: [40] Power Management version 1 Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 PME-Enable- DSel=0 DScale=1 PME- Kernel driver in use: saa7134 Kernel modules: saa7134 Any help would be greatly appreciated however I understand if this isn't a fixable issue. If so it would be nice to know where I could buy (online) TV Tuner cards with a composite input, are the old PCI type and of course work well with Linux (Fedora 10 at least). Thanks in advance, Sam Hi Sam and everyone First off I'm new to the LinuxTV mailing list and just like Sam this is my first time hacking, debugging etc. I also have an ASUS 'My Cinema Europa Hybrid' and it is currently unsupported right now. However looking over the hardware component's on the card itself, it seems that the individual components seem to be supported and we merely have to get all the components interacting with each other. The
Re: [PATCH (V2)] TVP514x: Migration to sub-device framework - Is it approved ???
On Friday 12 June 2009 18:04:34 Karicheri, Muralidharan wrote: Hi, This patch is sent for review last month. I have posted a vpfe capture driver patch that is dependent on this one. Is this one close to approval or what is the plan? I see some updates required to this patch based on my patch for supporting bus parameter which is being reviewed currently. I'll review this tomorrow. I'm planning to go through my pending reviews this weekend. It's been piling up the last few weeks due to travel and a very busy period at work. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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 (V2)] TVP514x: Migration to sub-device framework - Is it approved ???
Hans, Greatly appreciated, given the ton of issues you are currently busy with! Let me know, after review, your feel about possible merge plan for these patches. 2.6.31 or 2.6.32 Regards, Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 email: m-kariche...@ti.com -Original Message- From: Hans Verkuil [mailto:hverk...@xs4all.nl] Sent: Friday, June 12, 2009 12:18 PM To: Karicheri, Muralidharan Cc: linux-media@vger.kernel.org Subject: Re: [PATCH (V2)] TVP514x: Migration to sub-device framework - Is it approved ??? On Friday 12 June 2009 18:04:34 Karicheri, Muralidharan wrote: Hi, This patch is sent for review last month. I have posted a vpfe capture driver patch that is dependent on this one. Is this one close to approval or what is the plan? I see some updates required to this patch based on my patch for supporting bus parameter which is being reviewed currently. I'll review this tomorrow. I'm planning to go through my pending reviews this weekend. It's been piling up the last few weeks due to travel and a very busy period at work. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom -- 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
Fwd: [PATCH 2/2] uvc: Added two webcams with 'No FID' quirk.
From: Robert Krakora rob.krak...@messagenetsystems.com
Added two webcams with 'No FID' quirk.
Priority: normal
Signed-off-by: Robert Krakora rob.krak...@messagenetsystems.com
diff -r bff77ec33116 linux/drivers/media/video/uvc/uvc_driver.c
--- a/linux/drivers/media/video/uvc/uvc_driver.cThu Jun 11
18:44:23 2009 -0300
+++ b/linux/drivers/media/video/uvc/uvc_driver.cFri Jun 12
11:35:04 2009 -0400
@@ -1919,6 +1919,24 @@
.bInterfaceSubClass = 1,
.bInterfaceProtocol = 0,
.driver_info = UVC_QUIRK_STREAM_NO_FID },
+ /* Suyin Corp. HP Webcam */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x064e,
+ .idProduct= 0xa110,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_STREAM_NO_FID },
+ /* Creative Live! Cam Optia AF */
+ { .match_flags = USB_DEVICE_ID_MATCH_DEVICE
+ | USB_DEVICE_ID_MATCH_INT_INFO,
+ .idVendor = 0x041e,
+ .idProduct= 0x406d,
+ .bInterfaceClass = USB_CLASS_VIDEO,
+ .bInterfaceSubClass = 1,
+ .bInterfaceProtocol = 0,
+ .driver_info = UVC_QUIRK_STREAM_NO_FID },
/* Aveo Technology USB 2.0 Camera */
{ .match_flags = USB_DEVICE_ID_MATCH_DEVICE
| USB_DEVICE_ID_MATCH_INT_INFO,
--
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
[PATCHv7 1/9] v4l2-subdev.h: Add g_modulator callbacks to subdev api
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/include/media/v4l2-subdev.h |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/linux/include/media/v4l2-subdev.h
b/linux/include/media/v4l2-subdev.h
index 5dcb367..4dc3788 100644
--- a/linux/include/media/v4l2-subdev.h
+++ b/linux/include/media/v4l2-subdev.h
@@ -137,6 +137,8 @@ struct v4l2_subdev_tuner_ops {
int (*g_frequency)(struct v4l2_subdev *sd, struct v4l2_frequency *freq);
int (*g_tuner)(struct v4l2_subdev *sd, struct v4l2_tuner *vt);
int (*s_tuner)(struct v4l2_subdev *sd, struct v4l2_tuner *vt);
+ int (*g_modulator)(struct v4l2_subdev *sd, struct v4l2_modulator *vm);
+ int (*s_modulator)(struct v4l2_subdev *sd, struct v4l2_modulator *vm);
int (*s_type_addr)(struct v4l2_subdev *sd, struct tuner_setup *type);
int (*s_config)(struct v4l2_subdev *sd, const struct
v4l2_priv_tun_config *config);
int (*s_standby)(struct v4l2_subdev *sd);
--
1.6.2.GIT
--
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
[PATCHv7 2/9] v4l2: video device: Add V4L2_CTRL_CLASS_FM_TX controls
This patch adds a new class of extended controls. This class
is intended to support FM Radio Modulators properties such as:
rds, audio limiters, audio compression, pilot tone generation,
tuning power levels and preemphasis properties.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/include/linux/videodev2.h | 34 ++
1 files changed, 34 insertions(+), 0 deletions(-)
diff --git a/linux/include/linux/videodev2.h b/linux/include/linux/videodev2.h
index b8cffc9..9733435 100644
--- a/linux/include/linux/videodev2.h
+++ b/linux/include/linux/videodev2.h
@@ -806,6 +806,7 @@ struct v4l2_ext_controls {
#define V4L2_CTRL_CLASS_USER 0x0098/* Old-style 'user' controls */
#define V4L2_CTRL_CLASS_MPEG 0x0099/* MPEG-compression controls */
#define V4L2_CTRL_CLASS_CAMERA 0x009a /* Camera class controls */
+#define V4L2_CTRL_CLASS_FM_TX 0x009b /* FM Modulator control class */
#define V4L2_CTRL_ID_MASK(0x0fff)
#define V4L2_CTRL_ID2CLASS(id)((id) 0x0fffUL)
@@ -1144,6 +1145,39 @@ enum v4l2_exposure_auto_type {
#define V4L2_CID_PRIVACY (V4L2_CID_CAMERA_CLASS_BASE+16)
+/* FM Modulator class control IDs */
+#define V4L2_CID_FM_TX_CLASS_BASE (V4L2_CTRL_CLASS_FM_TX | 0x900)
+#define V4L2_CID_FM_TX_CLASS (V4L2_CTRL_CLASS_FM_TX | 1)
+
+#define V4L2_CID_RDS_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 1)
+#define V4L2_CID_RDS_PI
(V4L2_CID_FM_TX_CLASS_BASE + 2)
+#define V4L2_CID_RDS_PTY (V4L2_CID_FM_TX_CLASS_BASE + 3)
+#define V4L2_CID_RDS_PS_NAME (V4L2_CID_FM_TX_CLASS_BASE + 4)
+#define V4L2_CID_RDS_RADIO_TEXT
(V4L2_CID_FM_TX_CLASS_BASE + 5)
+
+#define V4L2_CID_AUDIO_LIMITER_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 6)
+#define V4L2_CID_AUDIO_LIMITER_RELEASE_TIME(V4L2_CID_FM_TX_CLASS_BASE + 7)
+#define V4L2_CID_AUDIO_LIMITER_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 8)
+
+#define V4L2_CID_AUDIO_COMPRESSION_ENABLED (V4L2_CID_FM_TX_CLASS_BASE + 9)
+#define V4L2_CID_AUDIO_COMPRESSION_GAIN
(V4L2_CID_FM_TX_CLASS_BASE + 10)
+#define V4L2_CID_AUDIO_COMPRESSION_THRESHOLD (V4L2_CID_FM_TX_CLASS_BASE + 11)
+#define V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME (V4L2_CID_FM_TX_CLASS_BASE + 12)
+#define V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME
(V4L2_CID_FM_TX_CLASS_BASE + 13)
+
+#define V4L2_CID_PILOT_TONE_ENABLED(V4L2_CID_FM_TX_CLASS_BASE + 14)
+#define V4L2_CID_PILOT_TONE_DEVIATION (V4L2_CID_FM_TX_CLASS_BASE + 15)
+#define V4L2_CID_PILOT_TONE_FREQUENCY (V4L2_CID_FM_TX_CLASS_BASE + 16)
+
+#define V4L2_CID_PREEMPHASIS (V4L2_CID_FM_TX_CLASS_BASE + 17)
+enum v4l2_fm_tx_preemphasis {
+ V4L2_FM_TX_PREEMPHASIS_DISABLED = 0,
+ V4L2_FM_TX_PREEMPHASIS_50_uS= 1,
+ V4L2_FM_TX_PREEMPHASIS_75_uS= 2,
+};
+#define V4L2_CID_TUNE_POWER_LEVEL (V4L2_CID_FM_TX_CLASS_BASE + 18)
+#define V4L2_CID_TUNE_ANTENNA_CAPACITOR
(V4L2_CID_FM_TX_CLASS_BASE + 19)
+
/*
* T U N I N G
*/
--
1.6.2.GIT
--
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
[PATCHv7 8/9] FMTx: si4713: Add Kconfig and Makefile entries
Simple add Makefile and Kconfig entries. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- linux/drivers/media/radio/Kconfig | 22 ++ linux/drivers/media/radio/Makefile |2 ++ 2 files changed, 24 insertions(+), 0 deletions(-) diff --git a/linux/drivers/media/radio/Kconfig b/linux/drivers/media/radio/Kconfig index 3315cac..6c6a409 100644 --- a/linux/drivers/media/radio/Kconfig +++ b/linux/drivers/media/radio/Kconfig @@ -339,6 +339,28 @@ config RADIO_ZOLTRIX_PORT help Enter the I/O port of your Zoltrix radio card. +config I2C_SI4713 + tristate I2C driver for Silicon Labs Si4713 device + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 I2C device. + This device driver supports only i2c bus. + + To compile this driver as a module, choose M here: the + module will be called si4713. + +config RADIO_SI4713 + tristate Silicon Labs Si4713 FM Radio Transmitter support + depends on I2C VIDEO_V4L2 + ---help--- + Say Y here if you want support to Si4713 FM Radio Transmitter. + This device can transmit audio through FM. It can transmit + EDS and EBDS signals as well. This module is the v4l2 radio + interface for the i2c driver of this device. + + To compile this driver as a module, choose M here: the + module will be called radio-si4713. + config USB_DSBR tristate D-Link/GemTek USB FM radio support depends on USB VIDEO_V4L2 diff --git a/linux/drivers/media/radio/Makefile b/linux/drivers/media/radio/Makefile index 0f2b35b..34ae761 100644 --- a/linux/drivers/media/radio/Makefile +++ b/linux/drivers/media/radio/Makefile @@ -15,6 +15,8 @@ obj-$(CONFIG_RADIO_ZOLTRIX) += radio-zoltrix.o obj-$(CONFIG_RADIO_GEMTEK) += radio-gemtek.o obj-$(CONFIG_RADIO_GEMTEK_PCI) += radio-gemtek-pci.o obj-$(CONFIG_RADIO_TRUST) += radio-trust.o +obj-$(CONFIG_I2C_SI4713) += si4713-i2c.o +obj-$(CONFIG_RADIO_SI4713) += radio-si4713.o obj-$(CONFIG_RADIO_MAESTRO) += radio-maestro.o obj-$(CONFIG_USB_DSBR) += dsbr100.o obj-$(CONFIG_USB_SI470X) += radio-si470x.o -- 1.6.2.GIT -- 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
[PATCHv7 4/9] v4l2-ctl: Add support for FM TX controls
This patch adds simple support for FM TX extended controls
on v4l2-ctl utility.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
v4l2-apps/util/v4l2-ctl.cpp | 36
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/v4l2-apps/util/v4l2-ctl.cpp b/v4l2-apps/util/v4l2-ctl.cpp
index 2c7290f..45a2310 100644
--- a/v4l2-apps/util/v4l2-ctl.cpp
+++ b/v4l2-apps/util/v4l2-ctl.cpp
@@ -148,6 +148,7 @@ typedef std::vectorstruct v4l2_ext_control ctrl_list;
static ctrl_list user_ctrls;
static ctrl_list mpeg_ctrls;
static ctrl_list camera_ctrls;
+static ctrl_list fm_tx_ctrls;
typedef std::mapstd::string, unsigned ctrl_strmap;
static ctrl_strmap ctrl_str2id;
@@ -2166,6 +2167,8 @@ set_vid_fmt_error:
mpeg_ctrls.push_back(ctrl);
else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_CAMERA)
camera_ctrls.push_back(ctrl);
+ else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_FM_TX)
+ fm_tx_ctrls.push_back(ctrl);
else
user_ctrls.push_back(ctrl);
}
@@ -2212,6 +2215,22 @@ set_vid_fmt_error:
}
}
}
+ if (fm_tx_ctrls.size()) {
+ ctrls.ctrl_class = V4L2_CTRL_CLASS_FM_TX;
+ ctrls.count = fm_tx_ctrls.size();
+ ctrls.controls = fm_tx_ctrls[0];
+ if (doioctl(fd, VIDIOC_S_EXT_CTRLS, ctrls,
VIDIOC_S_EXT_CTRLS)) {
+ if (ctrls.error_idx = ctrls.count) {
+ fprintf(stderr, Error setting FM
Modulator controls: %s\n,
+ strerror(errno));
+ }
+ else {
+ fprintf(stderr, %s: %s\n,
+
ctrl_id2str[fm_tx_ctrls[ctrls.error_idx].id].c_str(),
+ strerror(errno));
+ }
+ }
+ }
}
/* Get options */
@@ -2429,6 +2448,7 @@ set_vid_fmt_error:
mpeg_ctrls.clear();
camera_ctrls.clear();
user_ctrls.clear();
+ fm_tx_ctrls.clear();
for (ctrl_get_list::iterator iter = get_ctrls.begin();
iter != get_ctrls.end(); ++iter) {
struct v4l2_ext_control ctrl = { 0 };
@@ -2443,6 +2463,8 @@ set_vid_fmt_error:
mpeg_ctrls.push_back(ctrl);
else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_CAMERA)
camera_ctrls.push_back(ctrl);
+ else if (V4L2_CTRL_ID2CLASS(ctrl.id) ==
V4L2_CTRL_CLASS_FM_TX)
+ fm_tx_ctrls.push_back(ctrl);
else
user_ctrls.push_back(ctrl);
}
@@ -2481,6 +2503,20 @@ set_vid_fmt_error:
printf(%s: %d\n,
ctrl_id2str[ctrl.id].c_str(), ctrl.value);
}
}
+ if (fm_tx_ctrls.size()) {
+ ctrls.ctrl_class = V4L2_CTRL_CLASS_FM_TX;
+ ctrls.count = fm_tx_ctrls.size();
+ ctrls.controls = fm_tx_ctrls[0];
+ doioctl(fd, VIDIOC_G_EXT_CTRLS, ctrls,
VIDIOC_G_EXT_CTRLS);
+ for (unsigned i = 0; i fm_tx_ctrls.size(); i++) {
+ struct v4l2_ext_control ctrl = fm_tx_ctrls[i];
+
+ if (ctrl_id2type[ctrl.id] ==
V4L2_CTRL_TYPE_STRING)
+ printf(%s: '%s'\n,
ctrl_id2str[ctrl.id].c_str(), ctrl.string);
+ else
+ printf(%s: %d\n,
ctrl_id2str[ctrl.id].c_str(), ctrl.value);
+ }
+ }
}
if (options[OptGetTuner]) {
--
1.6.2.GIT
--
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
[PATCHv7 9/9] FMTx: si4713: Add document file
This patch adds a document file for si4713 device driver. It describes the driver interfaces and organization. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- linux/Documentation/video4linux/si4713.txt | 137 1 files changed, 137 insertions(+), 0 deletions(-) create mode 100644 linux/Documentation/video4linux/si4713.txt diff --git a/linux/Documentation/video4linux/si4713.txt b/linux/Documentation/video4linux/si4713.txt new file mode 100644 index 000..46e5e58 --- /dev/null +++ b/linux/Documentation/video4linux/si4713.txt @@ -0,0 +1,137 @@ +Driver for I2C radios for the Silicon Labs Si4713 FM Radio Transmitters + +Copyright (c) 2009 Nokia Corporation +Contact: Eduardo Valentin eduardo.valen...@nokia.com + + +Information about the Device + +This chip is a Silicon Labs product. It is a I2C device, currently on 0Ã63 address. +Basically, it has transmission and signal noise level measurement features. + +The Si4713 integrates transmit functions for FM broadcast stereo transmission. +The chip also allows integrated receive power scanning to identify low signal +power FM channels. + +The chip is programmed using commands and responses. There are also several +properties which can change the behavior of this chip. + +Users must comply with local regulations on radio frequency (RF) transmission. + +Device driver description += +There are two modules to handle this device. One is a I2C device driver +and the other is a platform driver. + +The I2C device driver exports a v4l2-subdev interface to the kernel. +All properties can also be accessed by v4l2 extended controls interface, by +using the v4l2-subdev calls (g_ext_ctrls, s_ext_ctrls). + +The platform device driver exports a v4l2 radio device interface to user land. +So, it uses the I2C device driver as a sub device in order to send the user +commands to the actual device. Basically it is a wrapper to the I2C device driver. + +Applications can use v4l2 radio API to specify frequency of operation, mute state, +etc. But mostly of its properties will be present in the extended controls. + +When the v4l2 mute property is set to 1 (true), the driver will turn the chip off. + +Properties description +== + +The properties can be accessed using v4l2 extended controls. +Here is an output from v4l2-ctl util: + +# v4l2-ctl -d /dev/radio0 -l --all +Driver Info: +Driver name : radio-si4713 +Card type : Silicon Labs Si4713 Modulator +Bus info : +Driver version: 0 +Capabilities : 0x0008 +Modulator +Audio output: 0 (FM Modulator Audio Out) +Frequency: 1408000 (88000.00 MHz) +Video Standard = 0x +Modulator: +Name : FM Modulator +Capabilities : 62.5 Hz stereo +Frequency range : 76.0 MHz - 108.0 MHz +Available subchannels: mono stereo + +User Controls + + mute (bool) : default=1 value=0 + +FM Radio Modulator Controls + +rds_feature_enabled (bool) : default=1 value=1 + rds_program_id (int) : min=0 max=65535 step=1 default=0 value=0 + rds_program_type (int) : min=0 max=31 step=1 default=0 value=0 +rds_ps_name (str) : value='Si4713 ' len=8 +' len=9 rds_radio_text (str) : value='Si4713 + audio_limiter_feature_enabled (bool) : default=1 value=1 + audio_limiter_release_time (int) : min=250 max=102390 step=50 default=5010 value=5010 flags=slider +audio_limiter_deviation (int) : min=0 max=9 step=10 default=66250 value=66250 flags=slider +audio_compression_feature_enabl (bool) : default=1 value=1 + audio_compression_gain (int) : min=0 max=20 step=1 default=15 value=15 flags=slider +audio_compression_threshold (int) : min=-40 max=0 step=1 default=-40 value=-40 flags=slider + audio_compression_attack_time (int) : min=0 max=5000 step=500 default=0 value=2000 flags=slider + audio_compression_release_time (int) : min=10 max=100 step=10 default=100 value=100 flags=slider + pilot_tone_feature_enabled (bool) : default=1 value=1 + pilot_tone_deviation (int) : min=0 max=9 step=10 default=6750 value=6750 flags=slider + pilot_tone_frequency (int) : min=0 max=19000 step=1 default=19000 value=19000 flags=slider + pre_emphasis_settings (menu) : min=0 max=2 default=1 value=2 + tune_power_level (int) : min=0 max=120 step=1 default=88 value=88 flags=slider + tune_antenna_capacitor (int) : min=0 max=191 step=1 default=0 value=110 flags=slider + +Here is a summary of them: + +* Pilot is an audible tone sent by the device. + +pilot_frequency - Configures the frequency of the stereo pilot tone. +pilot_deviation - Configures pilot tone frequency deviation level. +pilot_enabled - Enables or disables the pilot
[PATCHv7 6/9] FMTx: si4713: Add files to add radio interface for si4713
This patch adds files which creates the radio interface
for si4713 FM transmitter (modulator) devices.
In order to do the real access to device registers, this
driver uses the v4l2 subdev interface exported by si4713 i2c driver.
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/drivers/media/radio/radio-si4713.c | 325 ++
linux/include/media/si4713.h | 40
2 files changed, 365 insertions(+), 0 deletions(-)
create mode 100644 linux/drivers/media/radio/radio-si4713.c
create mode 100644 linux/include/media/si4713.h
diff --git a/linux/drivers/media/radio/radio-si4713.c
b/linux/drivers/media/radio/radio-si4713.c
new file mode 100644
index 000..4c23120
--- /dev/null
+++ b/linux/drivers/media/radio/radio-si4713.c
@@ -0,0 +1,325 @@
+/*
+ * drivers/media/radio/radio-si4713.c
+ *
+ * Platform Driver for Silicon Labs Si4713 FM Radio Transmitter:
+ *
+ * Copyright (c) 2008 Instituto Nokia de Tecnologia - INdT
+ * Contact: Eduardo Valentin eduardo.valen...@nokia.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; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ */
+
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/version.h
+#include linux/platform_device.h
+#include linux/i2c.h
+#include linux/videodev2.h
+#include media/v4l2-device.h
+#include media/v4l2-common.h
+#include media/v4l2-ioctl.h
+#include media/si4713.h
+
+/* Driver state struct */
+struct radio_si4713_device {
+ struct v4l2_device v4l2_dev;
+ struct video_device *radio_dev;
+};
+
+/* module parameters */
+static int radio_nr = -1; /* radio device minor (-1 == auto assign) */
+
+/* radio_si4713_fops - file operations interface */
+static const struct v4l2_file_operations radio_si4713_fops = {
+ .owner = THIS_MODULE,
+ .ioctl = video_ioctl2,
+};
+
+/* Video4Linux Interface */
+static int radio_si4713_fill_audout(struct v4l2_audioout *vao)
+{
+ /* TODO: check presence of audio output */
+ memset(vao, 0, sizeof(*vao));
+ strlcpy(vao-name, FM Modulator Audio Out, 32);
+
+ return 0;
+}
+
+static int radio_si4713_enumaudout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ return radio_si4713_fill_audout(vao);
+}
+
+static int radio_si4713_g_audout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ int rval = radio_si4713_fill_audout(vao);
+
+ vao-index = 0;
+
+ return rval;
+}
+
+static int radio_si4713_s_audout(struct file *file, void *priv,
+ struct v4l2_audioout *vao)
+{
+ if (vao-index != 0)
+ return -EINVAL;
+
+ return radio_si4713_fill_audout(vao);
+}
+
+/* radio_si4713_querycap - query device capabilities */
+static int radio_si4713_querycap(struct file *file, void *priv,
+ struct v4l2_capability *capability)
+{
+ struct radio_si4713_device *rsdev;
+
+ rsdev = video_get_drvdata(video_devdata(file));
+
+ strlcpy(capability-driver, radio-si4713, sizeof(capability-driver));
+ strlcpy(capability-card, Silicon Labs Si4713 Modulator,
+ sizeof(capability-card));
+ capability-capabilities = V4L2_CAP_MODULATOR;
+
+ return 0;
+}
+
+/* radio_si4713_queryctrl - enumerate control items */
+static int radio_si4713_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 user_ctrls[] = {
+ V4L2_CID_USER_CLASS,
+ V4L2_CID_AUDIO_MUTE,
+ 0
+ };
+
+ /* Must be sorted from low to high control ID! */
+ static const u32 fmtx_ctrls[] = {
+ V4L2_CID_FM_TX_CLASS,
+ V4L2_CID_RDS_ENABLED,
+ V4L2_CID_RDS_PI,
+ V4L2_CID_RDS_PTY,
+ V4L2_CID_RDS_PS_NAME,
+ V4L2_CID_RDS_RADIO_TEXT,
+ V4L2_CID_AUDIO_LIMITER_ENABLED,
+ V4L2_CID_AUDIO_LIMITER_RELEASE_TIME,
+ V4L2_CID_AUDIO_LIMITER_DEVIATION,
+
[PATCHv7 3/9] v4l2: video device: Add FM_TX controls default configurations
Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com
---
linux/drivers/media/video/v4l2-common.c | 50 +++
1 files changed, 50 insertions(+), 0 deletions(-)
diff --git a/linux/drivers/media/video/v4l2-common.c
b/linux/drivers/media/video/v4l2-common.c
index 5cfd727..9b6cf9f 100644
--- a/linux/drivers/media/video/v4l2-common.c
+++ b/linux/drivers/media/video/v4l2-common.c
@@ -345,6 +345,12 @@ const char **v4l2_ctrl_get_menu(u32 id)
Sepia,
NULL
};
+ static const char *fm_tx_preemphasis[] = {
+ No preemphasis,
+ 50 useconds,
+ 75 useconds,
+ NULL,
+ };
switch (id) {
case V4L2_CID_MPEG_AUDIO_SAMPLING_FREQ:
@@ -383,6 +389,8 @@ const char **v4l2_ctrl_get_menu(u32 id)
return camera_exposure_auto;
case V4L2_CID_COLORFX:
return colorfx;
+ case V4L2_CID_PREEMPHASIS:
+ return fm_tx_preemphasis;
default:
return NULL;
}
@@ -481,6 +489,28 @@ const char *v4l2_ctrl_get_name(u32 id)
case V4L2_CID_ZOOM_CONTINUOUS: return Zoom, Continuous;
case V4L2_CID_PRIVACY: return Privacy;
+ /* FM Radio Modulator control */
+ case V4L2_CID_FM_TX_CLASS: return FM Radio Modulator
Controls;
+ case V4L2_CID_RDS_ENABLED: return RDS Feature Enabled;
+ case V4L2_CID_RDS_PI: return RDS Program ID;
+ case V4L2_CID_RDS_PTY: return RDS Program Type;
+ case V4L2_CID_RDS_PS_NAME: return RDS PS Name;
+ case V4L2_CID_RDS_RADIO_TEXT: return RDS Radio Text;
+ case V4L2_CID_AUDIO_LIMITER_ENABLED:return Audio Limiter Feature
Enabled;
+ case V4L2_CID_AUDIO_LIMITER_RELEASE_TIME: return Audio Limiter Release
Time;
+ case V4L2_CID_AUDIO_LIMITER_DEVIATION: return Audio Limiter
Deviation;
+ case V4L2_CID_AUDIO_COMPRESSION_ENABLED: return Audio Compression
Feature Enabled;
+ case V4L2_CID_AUDIO_COMPRESSION_GAIN: return Audio Compression Gain;
+ case V4L2_CID_AUDIO_COMPRESSION_THRESHOLD: return Audio Compression
Threshold;
+ case V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME: return Audio Compression
Attack Time;
+ case V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME: return Audio Compression
Release Time;
+ case V4L2_CID_PILOT_TONE_ENABLED: return Pilot Tone Feature
Enabled;
+ case V4L2_CID_PILOT_TONE_DEVIATION: return Pilot Tone Deviation;
+ case V4L2_CID_PILOT_TONE_FREQUENCY: return Pilot Tone Frequency;
+ case V4L2_CID_PREEMPHASIS: return Pre-emphasis settings;
+ case V4L2_CID_TUNE_POWER_LEVEL: return Tune Power Level;
+ case V4L2_CID_TUNE_ANTENNA_CAPACITOR: return Tune Antenna Capacitor;
+
default:
return NULL;
}
@@ -513,6 +543,10 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl, s32
min, s32 max, s32 ste
case V4L2_CID_EXPOSURE_AUTO_PRIORITY:
case V4L2_CID_FOCUS_AUTO:
case V4L2_CID_PRIVACY:
+ case V4L2_CID_RDS_ENABLED:
+ case V4L2_CID_AUDIO_LIMITER_ENABLED:
+ case V4L2_CID_AUDIO_COMPRESSION_ENABLED:
+ case V4L2_CID_PILOT_TONE_ENABLED:
qctrl-type = V4L2_CTRL_TYPE_BOOLEAN;
min = 0;
max = step = 1;
@@ -541,12 +575,18 @@ int v4l2_ctrl_query_fill(struct v4l2_queryctrl *qctrl,
s32 min, s32 max, s32 ste
case V4L2_CID_MPEG_STREAM_VBI_FMT:
case V4L2_CID_EXPOSURE_AUTO:
case V4L2_CID_COLORFX:
+ case V4L2_CID_PREEMPHASIS:
qctrl-type = V4L2_CTRL_TYPE_MENU;
step = 1;
break;
+ case V4L2_CID_RDS_PS_NAME:
+ case V4L2_CID_RDS_RADIO_TEXT:
+ qctrl-type = V4L2_CTRL_TYPE_STRING;
+ break;
case V4L2_CID_USER_CLASS:
case V4L2_CID_CAMERA_CLASS:
case V4L2_CID_MPEG_CLASS:
+ case V4L2_CID_FM_TX_CLASS:
qctrl-type = V4L2_CTRL_TYPE_CTRL_CLASS;
qctrl-flags |= V4L2_CTRL_FLAG_READ_ONLY;
min = max = step = def = 0;
@@ -575,6 +615,16 @@ 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_AUDIO_LIMITER_RELEASE_TIME:
+ case V4L2_CID_AUDIO_LIMITER_DEVIATION:
+ case V4L2_CID_AUDIO_COMPRESSION_GAIN:
+ case V4L2_CID_AUDIO_COMPRESSION_THRESHOLD:
+ case V4L2_CID_AUDIO_COMPRESSION_ATTACK_TIME:
+ case V4L2_CID_AUDIO_COMPRESSION_RELEASE_TIME:
+ case V4L2_CID_PILOT_TONE_DEVIATION:
+ case V4L2_CID_PILOT_TONE_FREQUENCY:
+ case V4L2_CID_TUNE_POWER_LEVEL:
+ case
[PATCHv7 5/9] v4l2-spec: Add documentation description for FM TX extended control class
This single patch adds documentation description for FM Modulator (FM_TX) Extended Control Class and its Control IDs. The text was added under Extended Controls section. Signed-off-by: Eduardo Valentin eduardo.valen...@nokia.com --- v4l2-spec/Makefile |1 + v4l2-spec/biblio.sgml | 10 +++ v4l2-spec/controls.sgml | 205 +++ 3 files changed, 216 insertions(+), 0 deletions(-) diff --git a/v4l2-spec/Makefile b/v4l2-spec/Makefile index 7a19924..bfe2965 100644 --- a/v4l2-spec/Makefile +++ b/v4l2-spec/Makefile @@ -242,6 +242,7 @@ ENUMS = \ v4l2_power_line_frequency \ v4l2_priority \ v4l2_tuner_type \ + v4l2_fm_tx_preemphasis \ STRUCTS = \ v4l2_audio \ diff --git a/v4l2-spec/biblio.sgml b/v4l2-spec/biblio.sgml index b013ece..0921849 100644 --- a/v4l2-spec/biblio.sgml +++ b/v4l2-spec/biblio.sgml @@ -11,6 +11,16 @@ url=http://www.eia.org;http://www.eia.org/ulink)/corpauthor Service/title /biblioentry +biblioentry id=en50067 + abbrevENnbsp;50067/abbrev + authorgroup + corpauthorCENELEC European Committee for Electrotechnical Standardization +(ulink url=http://www.cenelec.eu;http://www.cenelec.eu/ulink)/corpauthor + /authorgroup + titleEN 50067 Specification of the radio data system (RDS) for +VHF/FM sound broadcasting in the frequency range from 87,5 to 108,0 MHz/title +/biblioentry + biblioentry id=en300294 abbrevENnbsp;300nbsp;294/abbrev authorgroup diff --git a/v4l2-spec/controls.sgml b/v4l2-spec/controls.sgml index 477a970..0bb6f00 100644 --- a/v4l2-spec/controls.sgml +++ b/v4l2-spec/controls.sgml @@ -458,6 +458,12 @@ video is actually encoded into that format./para paraUnfortunately, the original control API lacked some features needed for these new uses and so it was extended into the (not terribly originally named) extended control API./para + + paraEven though the MPEG encoding API was the first effort +to use the Extended Control API, nowadays there are also other classes +of Extended Controls, such as Camera Controls and FM Transmitter Controls. +The Extended Controls API as well as all Extended Controls classes are +described in the following text./para /section section @@ -1816,6 +1822,205 @@ control must support read access and may support write access./entry /tgroup /table /section + +section id=fm-tx-controls + titleFM Transmitter Control Reference/title + + paraThe FM Transmitter (FM_TX) class includes controls for common features of +FM transmissions capable devices. Currently this class include parameters for audio +compression, pilot tone generation, audio deviation limiter, RDS transmission and +tuning power features./para + + table pgwide=1 frame=none id=fm-tx-control-id + titleFM_TX Control IDs/title + + tgroup cols=4 + colspec colname=c1 colwidth=1* + colspec colname=c2 colwidth=6* + colspec colname=c3 colwidth=2* + colspec colname=c4 colwidth=6* + spanspec namest=c1 nameend=c2 spanname=id + spanspec namest=c2 nameend=c4 spanname=descr + thead + row + entry spanname=id align=leftID/entry + entry align=leftType/entry + /rowrow rowsep=1entry spanname=descr align=leftDescription/entry + /row + /thead + tbody valign=top + rowentry/entry/row + row + entry spanname=idconstantV4L2_CID_FM_TX_CLASS/constantnbsp;/entry + entryclass/entry + /rowrowentry spanname=descrThe FM_TX class +descriptor. Calling VIDIOC-QUERYCTRL; for this control will return a +description of this control class./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_ENABLED/constantnbsp;/entry + entryboolean/entry + /row + rowentry spanname=descrEnables or disables the RDS transmission feature./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PI/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Identification field +for transmission./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PTY/constantnbsp;/entry + entryinteger/entry + /row + rowentry spanname=descrSets the RDS Programme Type field for transmission. +This coding of up to 31 pre-defined programme types./entry + /row + row + entry spanname=idconstantV4L2_CID_RDS_PS_NAME/constantnbsp;/entry + entrystring/entry + /row + rowentry spanname=descrSets the Programme Service name (PS_NAME) for transmission. +It is intended for static display on a receiver. It is the primary aid to listeners in programme service +identification and selection. The use of PS to transmit text other than a single eight character name is not
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Fri Jun 12 19:00:07 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11965:bff77ec33116 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: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.22.19-i686: OK linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS 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.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-mips: WARNINGS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS 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.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS sparse (linux-2.6.30): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS 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: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS 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/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The V4L2 specification from this daily build 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
[PATCH -next] v4l: expose function outside of ifdef/endif block
From: Randy Dunlap randy.dun...@oracle.com Move v4l_bound_align_image() outside of an #ifdef CONFIG_I2C block so that it is always built. Fixes a build error: vivi.c:(.text+0x48e26): undefined reference to `v4l_bound_align_image' Signed-off-by: Randy Dunlap randy.dun...@oracle.com --- drivers/media/video/v4l2-common.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- linux-next-20090612.orig/drivers/media/video/v4l2-common.c +++ linux-next-20090612/drivers/media/video/v4l2-common.c @@ -915,6 +915,7 @@ const unsigned short *v4l2_i2c_tuner_add return NULL; } EXPORT_SYMBOL_GPL(v4l2_i2c_tuner_addrs); +#endif /* Clamp x to be between min and max, aligned to a multiple of 2^align. min * and max don't have to be aligned, but there must be at least one valid @@ -986,5 +987,3 @@ void v4l_bound_align_image(u32 *w, unsig } } EXPORT_SYMBOL_GPL(v4l_bound_align_image); - -#endif -- ~Randy LPC 2009, Sept. 23-25, Portland, Oregon http://linuxplumbersconf.org/2009/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH -next] v4l: expose function outside of ifdef/endif block
On Fri, 12 Jun 2009, Randy Dunlap wrote: From: Randy Dunlap randy.dun...@oracle.com Move v4l_bound_align_image() outside of an #ifdef CONFIG_I2C block so that it is always built. Fixes a build error: clamp_align() should be moved as well, since it's only used by v4l_bound_align_image(). I'm attaching an alternate version that fixes this. Labeled the endif too. drivers/media/video/v4l2-common.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- linux-next-20090612.orig/drivers/media/video/v4l2-common.c +++ linux-next-20090612/drivers/media/video/v4l2-common.c @@ -915,6 +915,7 @@ const unsigned short *v4l2_i2c_tuner_add return NULL; } EXPORT_SYMBOL_GPL(v4l2_i2c_tuner_addrs); +#endif /* Clamp x to be between min and max, aligned to a multiple of 2^align. min * and max don't have to be aligned, but there must be at least one valid @@ -986,5 +987,3 @@ void v4l_bound_align_image(u32 *w, unsig } } EXPORT_SYMBOL_GPL(v4l_bound_align_image); - -#endif# HG changeset patch # User Trent Piepho xy...@speakeasy.org # Date 1244834958 25200 # Node ID 23bd6516eafcc06ffb590073e744c7e17382aef9 # Parent 01fd4e3bd1c0fb52cb15acbd22ca7f4857170e6e v4l2: Move bounding code outside I2C ifdef block From: Trent Piepho xy...@speakeasy.org Move v4l_bound_align_image() and clamp_align() outside of an ifdef block for I2C related code. Can cause an undefined reference to `v4l_bound_align_image' if I2C isn't enabled. Priority: high Signed-off-by: Trent Piepho xy...@speakeasy.org Reported-by: Randy Dunlap randy.dun...@oracle.com diff -r 01fd4e3bd1c0 -r 23bd6516eafc linux/drivers/media/video/v4l2-common.c --- a/linux/drivers/media/video/v4l2-common.c Thu Jun 11 15:31:22 2009 -0700 +++ b/linux/drivers/media/video/v4l2-common.c Fri Jun 12 12:29:18 2009 -0700 @@ -997,6 +997,8 @@ const unsigned short *v4l2_i2c_tuner_add } EXPORT_SYMBOL_GPL(v4l2_i2c_tuner_addrs); +#endif /* defined(CONFIG_I2C) */ + /* Clamp x to be between min and max, aligned to a multiple of 2^align. min * and max don't have to be aligned, but there must be at least one valid * value. E.g., min=17,max=31,align=4 is not allowed as there are no multiples @@ -1067,5 +1069,3 @@ void v4l_bound_align_image(u32 *w, unsig } } EXPORT_SYMBOL_GPL(v4l_bound_align_image); - -#endif
Re: [linux-dvb] Remote af9015 Conceptronic
The IR tables are hardcoded in the driver that can be found at: http://linuxtv.org/hg/~jhoogenraad/rtl2831-r2 It has 3 sets parameters, and by default is set to tthe NEC one. ir_protocol Specify RTL2381 remote: 0=NEC, 1=RC5, 2=Conceptronic (defaults to 0) sudo modprobe -r dvb_usb_rtl2831u sudo modprobe dvb-usb-rtl2831u ir_protocol=2 to be compliant with the Conceptronic IR Daniel Sanchez wrote: Hi, I'm have Conceptronic USB2.0 DVB-T CTVDIGRCU V3.0 and remote not working, In method 'af9015_read_config' set IR mode: 4 and set rc_key_map to NULL; Why I'm read ir_table to set? It's possible follow this instructions? http://linuxtv.org/wiki/index.php/Remote_controllers-V4L#How_to_add_remote_control_support_to_a_card_.28GPIO_remotes.29 Thanks ___ linux-dvb users mailing list For V4L/DVB development, please use instead linux-media@vger.kernel.org linux-...@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb -- Jan Hoogenraad Hoogenraad Interface Services Postbus 2717 3500 GS Utrecht -- 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] generic image bounds setting and alignment function
Trent Piepho xy...@speakeasy.org writes: On Mon, 1 Jun 2009, Robert Jarzmik wrote: Trent Piepho xy...@speakeasy.org writes: Please pull from http://linuxtv.org/hg/~tap/v4l-dvb If I'm not mistaken, these lines are an equivalent of : balign = 1 align; if (align) x = ALIGN(x + 1 - balign/2, balign); Isn't that simpler to read ? I don't think so, it's not obvious that it will round to the nearest value. You have to look up ALIGN and then __ALIGN_MASK and see that it will in effect add balign - 1 and then reduce x + 1 - balign/2 + balign - 1 into x + balign/2. You're thinking from your code. x = ALIGN(x + 1 - balign/2, balign); That means : take x, add 1, substract half of alignment, and return nearest aligned value. IOW, by substracting half of the alignment, you have the guarantee that if you're at a distance of less half alignment from aligned value N, result will be N. It also generates worse code. You'd think the compiled would be able to optimize it into the same code, but it doesn't. Unless there is some issue with how it will work with negative values that causes a subtle difference. That's a sensible argument. I presume you checked the assembly here. I'm still thinking a balign/2 is clearer than (1 (align - 1)), but well, as it appears I'm the only one bothered, let's go ahead. What about the comment codying style comment of pxa_camera ? -- Robert -- 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: s5h1411_readreg: readreg error (ret == -5)
I am unable to reproduce the s5h1411 error here. However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder if Hauppauge has changed chips on newer devices and so you're running a different tuner module. That would explain the different behavior. Unfortunately it also means it will be very difficult for me to track the problem down here since I don't have that device variant. -Mike -- Mike Isely isely @ isely (dot) net PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8 -- 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: s5h1411_readreg: readreg error (ret == -5)
On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
I am unable to reproduce the s5h1411 error here.
However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder
if Hauppauge has changed chips on newer devices and so you're running a
different tuner module.
The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:
static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
.frontend_attach = pvr2_s5h1409_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
.frontend_attach = pvr2_s5h1411_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
.description = WinTV HVR-1950 Model Category 750xx,
...
.dvb_props = pvr2_750xx_dvb_props,
#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = WinTV HVR-1950 Model Category 751xx,
...
.dvb_props = pvr2_751xx_dvb_props,
#endif
};
That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track
the problem down here since I don't have that device variant.
If you have more than 1 HVR-1950, maybe one is a 751xx variant.
When I ran into I2C errors often, it was because of PCI bus errors
screwing up the bit banging. Obviously, that's not the case here.
-Andy
-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: s5h1411_readreg: readreg error (ret == -5)
Well now I feel like an idiot. Thanks for pointing that out in my own
code :-)
Still digging through this.
-Mike
On Fri, 12 Jun 2009, Andy Walls wrote:
On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
I am unable to reproduce the s5h1411 error here.
However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder
if Hauppauge has changed chips on newer devices and so you're running a
different tuner module.
The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:
static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
.frontend_attach = pvr2_s5h1409_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
.frontend_attach = pvr2_s5h1411_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
.description = WinTV HVR-1950 Model Category 750xx,
...
.dvb_props = pvr2_750xx_dvb_props,
#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = WinTV HVR-1950 Model Category 751xx,
...
.dvb_props = pvr2_751xx_dvb_props,
#endif
};
That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track
the problem down here since I don't have that device variant.
If you have more than 1 HVR-1950, maybe one is a 751xx variant.
When I ran into I2C errors often, it was because of PCI bus errors
screwing up the bit banging. Obviously, that's not the case here.
-Andy
-Mike
--
Mike Isely
isely @ isely (dot) net
PGP: 03 54 43 4D 75 E5 CC 92 71 16 01 E2 B5 F5 C1 E8
--
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: s5h1411_readreg: readreg error (ret == -5)
Hi,
Am Freitag, den 12.06.2009, 16:27 -0500 schrieb Mike Isely:
Well now I feel like an idiot. Thanks for pointing that out in my own
code :-)
Still digging through this.
-Mike
despite of that and to feed the weasel.
We'll have to look through different drivers, if we can make more use of
potential present device information in the eeproms.
There are always OEMs not following for example the Philips eeprom
layout in all details, most visible on different primary analog/hybrid
tuner type enumeration, and I don't even claim to know the latter in all
details,
and it needs more work on it,
but we have a lot of congruence for details in the 16 bytes including
0x40 and up from it across most manufacturers, including Hauppauge.
According to Hartmut, unfortunately not active currently, even different
LNA types, more and more devices with such do appear, are encoded in the
eeprom, if the OEM follows the plan. I don't know where yet, but might
be worth some time to try to find it out.
I had some hopes that this would also be known for the Hauppauge
eeproms, but seems not.
The most undiscovered configurations seem to be such ones about antenna
inputs and their switching. Again according to Hartmut, and he did not
know exactly what is going on here, some for us and him at this point
unknown checksums are used to derive even that information :(
For what I can see, and I might be of course still wrong, we can also
not determine plain digital tuner types, digital demodulator types of
any kind and the type of possibly present second and third tuners, but
at least their addresses, regularly shared by multiple chips, become
often visible. (some OEMs have only 0xff still for all that)
Cheers,
Hermann
On Fri, 12 Jun 2009, Andy Walls wrote:
On Fri, 2009-06-12 at 15:33 -0500, Mike Isely wrote:
I am unable to reproduce the s5h1411 error here.
However my HVR-1950 loads the s5h1409 module - NOT s5h1411.ko; I wonder
if Hauppauge has changed chips on newer devices and so you're running a
different tuner module.
The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:
static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
.frontend_attach = pvr2_s5h1409_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
.frontend_attach = pvr2_s5h1411_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
.description = WinTV HVR-1950 Model Category 750xx,
...
.dvb_props = pvr2_750xx_dvb_props,
#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = WinTV HVR-1950 Model Category 751xx,
...
.dvb_props = pvr2_751xx_dvb_props,
#endif
};
That would explain the different behavior.
Unfortunately it also means it will be very difficult for me to track
the problem down here since I don't have that device variant.
If you have more than 1 HVR-1950, maybe one is a 751xx variant.
When I ran into I2C errors often, it was because of PCI bus errors
screwing up the bit banging. Obviously, that's not the case here.
-Andy
-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: GPL code for Omnivision USB video camera available.
Hans de Goede wrote: This looks to me like its just ov51x-jpeg made to compile with the latest kernel. Its more than that. This driver supports a number of cameras and the only one we (bCODE) are really interested in is the ovfx2 driver. Did you make any functional changes? I believe the ovfx2 driver is completely new. Also I wonder if you're subscribed to the (low trafic) ov51x-jpeg mailinglist, that seems to be the right thing todo for someone who tries to get that driver in to the mainline. Sorry its the ovfx2 that I'm interested in pushing into the kernel. May I ask what cam you have? I could certainly use more people testing this. It looks like this on the USB bus: Bus 007 Device 002: ID 05a9:2800 OmniVision Technologies, Inc. Cheers, Erik -- === erik de castro lopo senior design engineer bCODE level 2, 2a glen street milsons point sydney nsw 2061 australia tel +61 (0)2 9954 4411 fax +61 (0)2 9954 4422 www.bcode.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: s5h1411_readreg: readreg error (ret == -5)
On Fri, 12 Jun 2009, Andy Walls wrote:
The digital demodulator driver to use is hardcoded in pvrusb2-devattr.c:
static const struct pvr2_dvb_props pvr2_750xx_dvb_props = {
.frontend_attach = pvr2_s5h1409_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
static const struct pvr2_dvb_props pvr2_751xx_dvb_props = {
.frontend_attach = pvr2_s5h1411_attach,
.tuner_attach= pvr2_tda18271_8295_attach,
};
...
static const struct pvr2_device_desc pvr2_device_750xx = {
.description = WinTV HVR-1950 Model Category 750xx,
...
.dvb_props = pvr2_750xx_dvb_props,
#endif
};
...
static const struct pvr2_device_desc pvr2_device_751xx = {
.description = WinTV HVR-1950 Model Category 751xx,
...
.dvb_props = pvr2_751xx_dvb_props,
#endif
And, just to verify the obvious:
WinTV-HVR-1950
NTSC/ATSC/QAM
75111 LF
REV C3E9
(with a very nice light green RoHS sticker)
--
Roger
http://rogerx.freeshell.org
--
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: s5h1411_readreg: readreg error (ret == -5)
On Sat, 2009-06-13 at 02:07 +0200, hermann pitton wrote: [snip] The most undiscovered configurations seem to be such ones about antenna inputs and their switching. Again according to Hartmut, and he did not know exactly what is going on here, some for us and him at this point unknown checksums are used to derive even that information :( From my brief research on the Internet, I didn't see any chip specs published for the s5h1411. :-/ -- Roger http://rogerx.freeshell.org -- 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: s5h1411_readreg: readreg error (ret == -5)
On Fri, 2009-06-12 at 16:27 -0500, Mike Isely wrote: Well now I feel like an idiot. Thanks for pointing that out in my own code :-) Well, that wasn't my objective, but you're welcome! ;) Don't worry. I can almost guarantee you'll have an opportunity to return the favor sometime in the future. :) Regards, Andy Still digging through this. -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
