Re: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
Hans Verkuil wrote: > On Wednesday 27 January 2010 22:48:24 Hans Verkuil wrote: >> This message is generated daily by a cron job that builds v4l-dvb for >> the kernels and architectures in the list below. > > It's up and running again. Note that I upgraded to the latest gcc 4.4.3. > I also updated all the kernels to their latest dot release. I'm happy to hear that this regular check is running again. I think this is an important tool to increase quality of v4l subsystem. Regards, Márton Németh -- 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
cx18 fix patches
Hi Andy, I've made two fix patches to solve the issues with cx18 compilation. My original intention were to send you an email for your ack. Unfortunately, those got added at the wrong branch and went upstream. That proofs that my scripts aren't reliable yet, and that I need an independent tree for such patches... I hope I have enough disk for all those trees... As we can't rebase the -git tree without breaking the replicas, I'd like you to review the patches: http://git.linuxtv.org/v4l-dvb.git?a=commit;h=701ca4249401fe9705a66ad806e933f15cb42489 http://git.linuxtv.org/v4l-dvb.git?a=commit;h=dd01705f6a6f732ca95d20959a90dd46482530df If a committed patch is bad, the remaining solution is to write a patch reverting it, and generating some dirty at the git logs. So, I hope both patches are ok... Please test. Sorry for the mess. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: saa7134 and üPD61151 MPEG2 coder
HIi Hans
> Hi Dmitri,
>
> Just a quick note: the video4linux mailinglist is obsolete, just use
> linux-media.
OK
> On Wednesday 27 January 2010 06:36:37 Dmitri Belimov wrote:
> > Hi Hans.
> >
> > I finished saa7134 part of SPI. Please review saa7134-spi.c and
> > diff saa7134-core and etc. I wrote config of SPI to board
> > structure. Use this config for register master and slave devices.
> >
> > SPI other then I2C, do not need call request_module. Udev do it.
> > I spend 10 days for understanding :(
>
> I'm almost certain that spi works the same way as i2c and that means
> that you must call request_module. Yes, udev will load it for you,
> but that is a delayed load: i.e. the module may not be loaded when we
> need it. The idea behind this is that usually i2c or spi modules are
> standalone, but in the context of v4l such modules are required to be
> present before the bridge can properly configure itself.
>
> The easiest way to ensure the correct load sequence is to do a
> request_module at the start.
>
> Now, I haven't compiled this, but I think this will work:
>
> struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
>struct spi_master *master, struct spi_board_info *info)
> {
> struct v4l2_subdev *sd = NULL;
> struct spi_device *spi;
>
> BUG_ON(!v4l2_dev);
>
> if (module_name)
> request_module(module_name);
>
> spi = spi_new_device(master, info);
>
> if (spi == NULL || spi->dev.driver == NULL)
> goto error;
>
>if (!try_module_get(spi->dev.driver->owner))
>goto error;
>
>sd = spi_get_drvdata(spi);
>
>/* Register with the v4l2_device which increases the module's
> use count as well. */
>
>if (v4l2_device_register_subdev(v4l2_dev, sd))
>sd = NULL;
>
>/* Decrease the module use count to match the first
> try_module_get. */ module_put(spi->dev.driver->owner);
>
> error:
>/* If we have a client but no subdev, then something went
> wrong and we must unregister the client. */
>
>if (spi && sd == NULL)
>spi_unregister_device(spi);
>
>return sd;
> }
> EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
Not work
[6.048195] Linux video capture interface: v2.00
[6.112987] saa7130/34: v4l2 driver version 0.2.15 loaded
[6.113067] saa7134 :04:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ 19
[6.113117] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency:
32, mmio: 0xe510
[6.113176] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7
[card=171,autodetected]
[6.113241] saa7133[0]: board init: gpio is 20
[6.113292] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared IRQs
[6.264512] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00
00 00 00 01
[6.265136] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.265731] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.266327] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.266922] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.267517] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.268113] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.268718] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.269313] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.269908] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.270503] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.271098] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.271693] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.272289] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff
ff ff ff ff
[6.272895] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff
ff ff ff ff
[6.273490] saa7133[0]: i2c eeprom f0: 42 54 56 30 30 30 30 ff ff ff ff ff
ff ff ff ff
[6.360023] tuner 1-0061: chip found @ 0xc2 (saa7133[0])
[6.401952] xc5000 1-0061: creating new instance
[6.412005] xc5000: Successfully identified at address 0x61
[6.412054] xc5000: Firmware has not been loaded previously
[6.477742] HDA Intel :00:1b.0: PCI INT A -> GSI 16 (level, low) -> IRQ
16
[6.477816] HDA Intel :00:1b.0: setting latency timer to 64
[ 34.752763] saa7134 :04:01.0: spi master registered: bus_num=32766
num_chipselect=1
[ 34.752823] saa7133[0]: found muPD61151 MPEG encoder
[ 34.752883] befor request_module
[ 240.476013] INFO: task modprobe:1404 blocked for more than 120 seconds.
[ 240.476016] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this
Re: [PULL] firmware for Sensoray s2255 driver
Hi David, Mauro Carvalho Chehab wrote: > The following changes since commit c024a251e1dd1a39de610bbdc2af65b36e42637d: > David Woodhouse (1): > Merge from fixed from-kernel tree to fix Matrox firmware binaries > > are available in the git repository at: > > ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git > master Sensoray sent us two more firmwares, under the same licence. So, I've added them on my tree also. For one of his driver to work, they'll need also the Micronas go7007 firmware. This firmware gives redistribution rights, but the condition for it is unusual: it requires that the README file of their public driver to be shipped together with the firmware. So, I added the clauses at WHENCE licence (based on their readme file), and added their unmodified README, just renaming it as "README.go7007". I hope that's the right way of doing it. The 2 Sensoray patches, plus the go7007 firmware are at: ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git go7007 So, please pull from it if you're comfortable. This is the contents of the "go7007" branch: Mauro Carvalho Chehab (3): Firmware for Sensoray s2255 webcam drivers Additional firmwares for Sensoray s2255 webcam drivers Add firmwares for go7007 driver README.go7007 | 375 +++ WHENCE | 33 + f2255usb.bin| Bin 0 -> 180760 bytes go7007fw.bin| Bin 0 -> 30800 bytes go7007tv.bin| Bin 0 -> 124668 bytes s2250.fw| Bin 0 -> 9508 bytes s2250_loader.fw | Bin 0 -> 1092 bytes 7 files changed, 408 insertions(+), 0 deletions(-) create mode 100644 README.go7007 create mode 100644 f2255usb.bin create mode 100644 go7007fw.bin create mode 100644 go7007tv.bin create mode 100644 s2250.fw create mode 100644 s2250_loader.fw --- If, however, you think that the way the go7007 were imported is incorrect, then please pull at least the two Sensoray patches from the "master" branch. This is the contents for just the "master" branch, at ssh://master.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Mauro Carvalho Chehab (2): Firmware for Sensoray s2255 webcam drivers Additional firmwares for Sensoray s2255 webcam drivers WHENCE | 14 ++ f2255usb.bin| Bin 0 -> 180760 bytes s2250.fw| Bin 0 -> 9508 bytes s2250_loader.fw | Bin 0 -> 1092 bytes 4 files changed, 14 insertions(+), 0 deletions(-) create mode 100644 f2255usb.bin create mode 100644 s2250.fw create mode 100644 s2250_loader.fw -- 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
AF9015 with tuner TDA18218
Hi, I've an adapter with USB ID 15a4:9016, with an AF9015 and tuner TDA18218. This is the fifth adatper that I try, 3 currently work, one should work, but I've no success, and this not work. I've seen in previous posts that it is not supported for now, but many people have done some experiment and some have obtained something, but nothing of full working. I want to know if it's possible to write a working driver using datasheet and starting from the code of TDA18271 using the difference from datasheet (at a first look they seems very similar); I'm not a programmer, but I'm able to do some logic operation if someone can explain me what I must do. I can do tester and report log of usbsnnop too, but starting from it and write a driver is too hard for me. If someone with this adapter want to try some experiment with me and work on it, I'm available to cowork. Thanks to all, Sebastian -- 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
[Q] udev and soc-camera
Hello, I have a system that is built with OpenEmbedded where I use a mt9t031 camera with the soc-camera framework. The mt9t031 works ok with the current kernel and system. However, udev does not create the /dev/video0 device node. I have to create it manually with mknod and then it works well. If I unbind the device on the soc-camera bus (and then eventually rebind it), udev then creates the node correctly. This looks like a "timing" issue at "coldstart". OpenEmbedded currently builds udev 141 and I am using kernel 2.6.33-rc5 (but this was already like that with earlier kernels). Is this problem something known or has at least someone already experienced that problem ? Thanks and best regards Val -- Valentin Longchamp, PhD Student, EPFL-STI-LSRO1 valentin.longch...@epfl.ch, Phone: +41216937827 http://people.epfl.ch/valentin.longchamp MEB3494, Station 9, CH-1015 Lausanne -- 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: IR device at I2C address 0x7a
Hi Jean, Am Mittwoch, den 27.01.2010, 10:38 +0100 schrieb Jean Delvare: > Hi Hermann, > > Sorry for the late answer. > > On Sun, 10 Jan 2010 22:55:05 +0100, hermann pitton wrote: > > Am Sonntag, den 10.01.2010, 09:51 +0100 schrieb Jean Delvare: > > > On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote: > > > > Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: > > > > > Then I would suggest the following patch: > > > > > > > > > > * * * * * > > > > > > > > > > From: Jean Delvare > > > > > Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants > > > > > > > > > > Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 > > > > > Analog (card=146). However, by the time we find out, some > > > > > card-specific initialization is missed. In particular, the fact that > > > > > the IR is GPIO-based. Set it when we change the card type. > > > > > > > > > > Signed-off-by: Jean Delvare > > > > > Tested-by: Daro > > > > > > > > just to note it, the ASUS TV-FM 7135 with USB remote is different to the > > > > Asus My Cinema P7134 Analog only, not only for the remote, but also for > > > > inputs, but they have the same PCI subsystem. > > > > > > > > > --- > > > > > linux/drivers/media/video/saa7134/saa7134-cards.c |1 + > > > > > 1 file changed, 1 insertion(+) > > > > > > > > > > --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c > > > > > 2009-12-11 09:47:47.0 +0100 > > > > > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c > > > > > 2010-01-09 16:23:17.0 +0100 > > > > > @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d > > > > > printk(KERN_INFO "%s: P7131 analog only, using " > > > > > "entry of %s\n", > > > > > dev->name, saa7134_boards[dev->board].name); > > > > > + dev->has_remote = SAA7134_REMOTE_GPIO; > > > > > } > > > > > break; > > > > > case SAA7134_BOARD_HAUPPAUGE_HVR1150: > > > > > > > > > > > > > > > * * * * * > > > > > > > > Must have been broken at that time, IIRC. > > > > > > What must have been broken, and when? You are confusing. > > > > Sorry, I missed that thread until now. > > The above patch was tried previously by Roman. > > > > For the record, here is a link. > > http://www.spinics.net/lists/vfl/msg38869.html > > Thanks for the pointer, this was very helpful. I had missed the fact > that the call to saa7134_input_init1() was before the card number > change. So indeed my patch was insufficient. > > Roman's strategy to move saa7134_input_init1() to the late init section > seems good to me. Honestly, I can't think of a good reason to init the > remote control early. I doubt that anything else depends on that. > > I'll send an updated patch shortly. thanks for your time looking closer into it. Unfortunately I did not have any during the last two months. If we pass all the testing, your here announced and later following patch should be the best possible solution, as it stands now. To give some historical notes, Gerd did try to avoid eeprom detection on the saa7134 driver, likely hoping to see better PCI subsystem use by the manufacturers, since bttv was already very complex and difficult to maintain with all the specific detection stuff and workarounds. However, Hartmut Hackmann and me had to discover, that we still see the same disease with some saa713x OEMs, the same PCI subsystem for very different cards ... Hence we started with some eeprom detection, known now for having caused trouble already through all the ever ongoing changing init procedures we always have and very bad for transparent maintenance. For all, and for Asus specifically, this is still a unique case on the saa713x driver, IIRC. The rest is fine on Asus. To print something for that card like "for IR you have to set the card=number" should be also still enough. To remind, we run into those problems, because OEMs don't follow the rules of the chip manufacturer, excluding others by will on their m$ drivers, when initially buying greater amounts of chips. So we always run only after the tsunamis and it is not worth it, to give those breaking rules previously, some kind of moral instance to get their devices better detected on GNU/Linux later. Anyway, let's try. Cheers, Hermann -- 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] firmware for Sensoray s2255 driver
The following changes since commit c024a251e1dd1a39de610bbdc2af65b36e42637d: David Woodhouse (1): Merge from fixed from-kernel tree to fix Matrox firmware binaries are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-firmware.git master Mauro Carvalho Chehab (1): Firmware for Sensoray s2255 webcam drivers WHENCE | 13 + f2255usb.bin | Bin 0 -> 180760 bytes 2 files changed, 13 insertions(+), 0 deletions(-) create mode 100644 f2255usb.bin -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: ERRORS
On Wednesday 27 January 2010 22:48:24 Hans Verkuil wrote: > This message is generated daily by a cron job that builds v4l-dvb for > the kernels and architectures in the list below. It's up and running again. Note that I upgraded to the latest gcc 4.4.3. I also updated all the kernels to their latest dot release. I'm only building the i686 and x86_64 on all kernels from 2.6.16 onwards. All other architectures are only built for 2.6.32 and 2.6.33. If someone wants to build one of those for older kernels also, then just let me know. Regards, Hans > > Results of the daily build of v4l-dvb: > > date:Wed Jan 27 21:00:05 CET 2010 > path:http://www.linuxtv.org/hg/v4l-dvb > changeset: 14064:31eaa9423f98 > gcc version: i686-linux-gcc (GCC) 4.4.3 > host hardware:x86_64 > host os: 2.6.32.5 > > linux-2.6.32.6-armv5: OK > linux-2.6.33-rc5-armv5: OK > linux-2.6.32.6-armv5-davinci: WARNINGS > linux-2.6.33-rc5-armv5-davinci: WARNINGS > linux-2.6.32.6-armv5-dm365: ERRORS > linux-2.6.33-rc5-armv5-dm365: ERRORS > linux-2.6.32.6-armv5-ixp: WARNINGS > linux-2.6.33-rc5-armv5-ixp: WARNINGS > linux-2.6.32.6-armv5-omap2: WARNINGS > linux-2.6.33-rc5-armv5-omap2: WARNINGS > linux-2.6.22.19-i686: WARNINGS > linux-2.6.23.17-i686: WARNINGS > linux-2.6.24.7-i686: WARNINGS > linux-2.6.25.20-i686: WARNINGS > linux-2.6.26.8-i686: WARNINGS > linux-2.6.27.44-i686: WARNINGS > linux-2.6.28.10-i686: WARNINGS > linux-2.6.29.1-i686: WARNINGS > linux-2.6.30.10-i686: WARNINGS > linux-2.6.31.12-i686: WARNINGS > linux-2.6.32.6-i686: WARNINGS > linux-2.6.33-rc5-i686: WARNINGS > linux-2.6.32.6-m32r: OK > linux-2.6.33-rc5-m32r: OK > linux-2.6.32.6-mips: WARNINGS > linux-2.6.33-rc5-mips: WARNINGS > linux-2.6.32.6-powerpc64: ERRORS > linux-2.6.33-rc5-powerpc64: ERRORS > linux-2.6.22.19-x86_64: WARNINGS > linux-2.6.23.17-x86_64: WARNINGS > linux-2.6.24.7-x86_64: WARNINGS > linux-2.6.25.20-x86_64: WARNINGS > linux-2.6.26.8-x86_64: WARNINGS > linux-2.6.27.44-x86_64: WARNINGS > linux-2.6.28.10-x86_64: WARNINGS > linux-2.6.29.1-x86_64: WARNINGS > linux-2.6.30.10-x86_64: WARNINGS > linux-2.6.31.12-x86_64: WARNINGS > linux-2.6.32.6-x86_64: WARNINGS > linux-2.6.33-rc5-x86_64: WARNINGS > spec: OK > sparse (linux-2.6.32.6): ERRORS > sparse (linux-2.6.33-rc5): ERRORS > linux-2.6.16.62-i686: ERRORS > linux-2.6.17.14-i686: ERRORS > linux-2.6.18.8-i686: ERRORS > linux-2.6.19.7-i686: OK > linux-2.6.20.21-i686: WARNINGS > linux-2.6.21.7-i686: WARNINGS > linux-2.6.16.62-x86_64: ERRORS > linux-2.6.17.14-x86_64: ERRORS > linux-2.6.18.8-x86_64: ERRORS > linux-2.6.19.7-x86_64: WARNINGS > linux-2.6.20.21-x86_64: WARNINGS > linux-2.6.21.7-x86_64: WARNINGS > > Detailed results are available here: > > http://www.xs4all.nl/~hverkuil/logs/Wednesday.log > > Full logs are available here: > > http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 > > The V4L-DVB specification from this daily build is here: > > http://www.xs4all.nl/~hverkuil/spec/media.html > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- 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
[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:Wed Jan 27 21:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14064:31eaa9423f98 gcc version: i686-linux-gcc (GCC) 4.4.3 host hardware:x86_64 host os: 2.6.32.5 linux-2.6.32.6-armv5: OK linux-2.6.33-rc5-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-rc5-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-dm365: ERRORS linux-2.6.33-rc5-armv5-dm365: ERRORS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-rc5-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-rc5-armv5-omap2: WARNINGS linux-2.6.22.19-i686: WARNINGS linux-2.6.23.17-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.20-i686: WARNINGS linux-2.6.26.8-i686: WARNINGS linux-2.6.27.44-i686: WARNINGS linux-2.6.28.10-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30.10-i686: WARNINGS linux-2.6.31.12-i686: WARNINGS linux-2.6.32.6-i686: WARNINGS linux-2.6.33-rc5-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-rc5-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-rc5-mips: WARNINGS linux-2.6.32.6-powerpc64: ERRORS linux-2.6.33-rc5-powerpc64: ERRORS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.17-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.20-x86_64: WARNINGS linux-2.6.26.8-x86_64: WARNINGS linux-2.6.27.44-x86_64: WARNINGS linux-2.6.28.10-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30.10-x86_64: WARNINGS linux-2.6.31.12-x86_64: WARNINGS linux-2.6.32.6-x86_64: WARNINGS linux-2.6.33-rc5-x86_64: WARNINGS spec: OK sparse (linux-2.6.32.6): ERRORS sparse (linux-2.6.33-rc5): ERRORS linux-2.6.16.62-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.7-i686: OK linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.7-x86_64: WARNINGS linux-2.6.20.21-x86_64: WARNINGS linux-2.6.21.7-x86_64: WARNINGS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L-DVB specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/media.html -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote:
> You didn't reply to my most important objection:
>
> On Wed, 27 Jan 2010, Németh Márton wrote:
>
>> diff -r 31eaa9423f98 linux/include/media/soc_camera.h
>> --- a/linux/include/media/soc_camera.h Mon Jan 25 15:04:15 2010 -0200
>> +++ b/linux/include/media/soc_camera.h Wed Jan 27 20:49:57 2010 +0100
>> @@ -264,9 +264,8 @@
>> common_flags;
>> }
>>
>> -static inline void soc_camera_limit_side(unsigned int *start,
>> -unsigned int *length, unsigned int start_min,
>> -unsigned int length_min, unsigned int length_max)
>> +static inline void soc_camera_limit_side(int *start, int *length,
>> +int start_min, int length_min, int length_max)
>> {
>> if (*length < length_min)
>> *length = length_min;
>
> I still do not believe this function will work equally well with signed
> parameters, as it works with unsigned ones.
I implemented some test cases to find out whether the
soc_camera_limit_side() works correctly or not. My biggest problem is that I'm
not sure what is the expected working of the soc_camera_limit_side() function.
Nevertheless I tried expect some values, you can probably verify whether my
expectations are correct or not (see the test attached).
The signed and unsigned version of the function works differently because
the unsigned version cannot accept negative values. These values will be
implicitly casted to an unsigned value which means that they will be interpreted
as a big positive value.
Here are the test results:
Test Case 1: PASSED
Test Case 2: PASSED
Test Case 3: FAILED: start=50, length=8, start_unsigned=0, length_unsigned=1600
Test Case 4: PASSED
Test Case 5: PASSED
Test Case 6: PASSED
Test Case 7: PASSED
Test Case 8: PASSED
There is a difference in case 3, but which is the correct one?
Regard,
Márton Németh
#include
static inline void soc_camera_limit_side_UNSIGNED(unsigned int *start, unsigned int *length,
unsigned int start_min, unsigned int length_min, unsigned int length_max)
{
if (*length < length_min)
*length = length_min;
else if (*length > length_max)
*length = length_max;
if (*start < start_min)
*start = start_min;
else if (*start > start_min + length_max - *length)
*start = start_min + length_max - *length;
}
static inline void soc_camera_limit_side(int *start, int *length,
int start_min, int length_min, int length_max)
{
if (*length < length_min)
*length = length_min;
else if (*length > length_max)
*length = length_max;
if (*start < start_min)
*start = start_min;
else if (*start > start_min + length_max - *length)
*start = start_min + length_max - *length;
}
int main() {
int start, length;
unsigned int start_unsigned, length_unsigned;
printf("Test Case 1: ");
start = 0;
length = 8;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(&start, &length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(&start_unsigned, &length_unsigned, 0, 8, 1600);
if (start == 0 && length == 8 && start_unsigned == start && length_unsigned == length) {
printf("PASSED\n");
} else {
printf("FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n", start, length, start_unsigned, length_unsigned);
}
printf("Test Case 2: ");
start = -5;
length = 1600;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(&start, &length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(&start_unsigned, &length_unsigned, 0, 8, 1600);
if (start == 0 && length == 1600 && start_unsigned == start && length_unsigned == length) {
printf("PASSED\n");
} else {
printf("FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n", start, length, start_unsigned, length_unsigned);
}
printf("Test Case 3: ");
start = 50;
length = -15;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(&start, &length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(&start_unsigned, &length_unsigned, 0, 8, 1600);
if (start == 50 && length == 8 && start_unsigned == start && length_unsigned == length) {
printf("PASSED\n");
} else {
printf("FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n", start, length, start_unsigned, length_unsigned);
}
printf("Test Case 4: ");
start = 500;
length = 2000;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(&start, &length, 0, 8, 1600);
soc_camera_limit_side_UNSIGNED(&start_unsigned, &length_unsigned, 0, 8, 1600);
if (start == 0 && length == 1600 && start_unsigned == start && length_unsigned == length) {
printf("PASSED\n");
} else {
printf("FAILED: start=%i, length=%i, start_unsigned=%i, length_unsigned=%i\n", start, length, start_unsigned, length_unsigned);
}
printf("Test Case 5: ");
start = -20;
length = 1600;
start_unsigned = start;
length_unsigned = length;
soc_camera_limit_side(&start, &length, 100, 8, 1600);
soc_camera_limit_side_UNSIGNED(&start_unsigned, &length_unsigned, 100,
Re: dmesg output with Pinnacle PCTV USB Stick
On Wed, Jan 27, 2010 at 4:00 PM, Sebastian Spiess wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Hi there, > below is my dmesh output for my Pinnacle PCTV Hybrid Pro > > hope it helps > > [ 8899.390876] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, > interface 0, class 0) Are you absolutely sure this is a PCTV Hybrid Pro? What is the exact model number? Does it have the A/V cable for composite/svideo input? Based on the USB ID, I would have assumed this was a model "70e", which is a digital only device. It's on my TODO list, but it's a really low priority given how old it is. I actually did spend some time working on it, but ran into problems and without the hardware concluded it wasn't worth the time. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
dmesg output with Pinnacle PCTV USB Stick
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there, below is my dmesh output for my Pinnacle PCTV Hybrid Pro hope it helps [ 8899.390876] em28xx: New device USB 2870 Device @ 480 Mbps (eb1a:2870, interface 0, class 0) [ 8899.391162] em28xx #0: chip ID is em2870 [ 8899.474026] em28xx #0: i2c eeprom 00: 1a eb 67 95 1a eb 70 28 c0 12 81 00 6a 22 00 00 [ 8899.474096] em28xx #0: i2c eeprom 10: 00 00 04 57 02 0d 00 00 00 00 00 00 00 00 00 00 [ 8899.474162] em28xx #0: i2c eeprom 20: 44 00 00 00 f0 10 02 00 00 00 00 00 5b 00 00 00 [ 8899.474227] em28xx #0: i2c eeprom 30: 00 00 20 40 20 80 02 20 01 01 00 00 6d e0 a3 49 [ 8899.474311] em28xx #0: i2c eeprom 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474376] em28xx #0: i2c eeprom 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474441] em28xx #0: i2c eeprom 60: 00 00 00 00 00 00 00 00 00 00 22 03 55 00 53 00 [ 8899.474506] em28xx #0: i2c eeprom 70: 42 00 20 00 32 00 38 00 37 00 30 00 20 00 44 00 [ 8899.474571] em28xx #0: i2c eeprom 80: 65 00 76 00 69 00 63 00 65 00 00 00 00 00 00 00 [ 8899.474640] em28xx #0: i2c eeprom 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474706] em28xx #0: i2c eeprom a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474789] em28xx #0: i2c eeprom b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474854] em28xx #0: i2c eeprom c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474919] em28xx #0: i2c eeprom d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.474984] em28xx #0: i2c eeprom e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.475048] em28xx #0: i2c eeprom f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 8899.475117] em28xx #0: EEPROM ID= 0x9567eb1a, EEPROM hash = 0xf0ff19c0 [ 8899.475141] em28xx #0: EEPROM info: [ 8899.475146] em28xx #0: No audio on board. [ 8899.475151] em28xx #0: 500mA max power [ 8899.475175] em28xx #0: Table at 0x04, strings=0x226a, 0x, 0x [ 8899.491654] em28xx #0: Identified as Unknown EM2750/28xx video grabber (card=1) [ 8899.527409] em28xx #0: found i2c device @ 0xa0 [eeprom] [ 8899.535029] em28xx #0: found i2c device @ 0xc0 [tuner (analog)] [ 8899.550027] em28xx #0: Your board has no unique USB ID and thus need a hint to be detected. [ 8899.550054] em28xx #0: You may try to use card= insmod option to workaround that. [ 8899.550061] em28xx #0: Please send an email with this log to: [ 8899.550085] em28xx #0: V4L Mailing List [ 8899.550091] em28xx #0: Board eeprom hash is 0xf0ff19c0 [ 8899.550115] em28xx #0: Board i2c devicelist hash is 0x4b800080 [ 8899.550121] em28xx #0: Here is a list of valid choices for the card= insmod option: [ 8899.550128] em28xx #0: card=0 -> Unknown EM2800 video grabber [ 8899.550153] em28xx #0: card=1 -> Unknown EM2750/28xx video grabber [ 8899.550160] em28xx #0: card=2 -> Terratec Cinergy 250 USB [ 8899.550188] em28xx #0: card=3 -> Pinnacle PCTV USB 2 [ 8899.550212] em28xx #0: card=4 -> Hauppauge WinTV USB 2 [ 8899.550219] em28xx #0: card=5 -> MSI VOX USB 2.0 [ 8899.550242] em28xx #0: card=6 -> Terratec Cinergy 200 USB [ 8899.550249] em28xx #0: card=7 -> Leadtek Winfast USB II [ 8899.550255] em28xx #0: card=8 -> Kworld USB2800 [ 8899.550280] em28xx #0: card=9 -> Pinnacle Dazzle DVC 90/100/101/107 / Kaiser Baas Video to DVD maker [ 8899.550287] em28xx #0: card=10 -> Hauppauge WinTV HVR 900 [ 8899.550312] em28xx #0: card=11 -> Terratec Hybrid XS [ 8899.550318] em28xx #0: card=12 -> Kworld PVR TV 2800 RF [ 8899.550342] em28xx #0: card=13 -> Terratec Prodigy XS [ 8899.550349] em28xx #0: card=14 -> SIIG AVTuner-PVR / Pixelview Prolink PlayTV USB 2.0 [ 8899.550374] em28xx #0: card=15 -> V-Gear PocketTV [ 8899.550380] em28xx #0: card=16 -> Hauppauge WinTV HVR 950 [ 8899.550405] em28xx #0: card=17 -> Pinnacle PCTV HD Pro Stick [ 8899.550411] em28xx #0: card=18 -> Hauppauge WinTV HVR 900 (R2) [ 8899.550436] em28xx #0: card=19 -> EM2860/SAA711X Reference Design [ 8899.550443] em28xx #0: card=20 -> AMD ATI TV Wonder HD 600 [ 8899.550468] em28xx #0: card=21 -> eMPIA Technology, Inc. GrabBeeX+ Video Encoder [ 8899.550475] em28xx #0: card=22 -> EM2710/EM2750/EM2751 webcam grabber [ 8899.550499] em28xx #0: card=23 -> Huaqi DLCW-130 [ 8899.550505] em28xx #0: card=24 -> D-Link DUB-T210 TV Tuner [ 8899.550530] em28xx #0: card=25 -> Gadmei UTV310 [ 8899.550536] em28xx #0: card=26 -> Hercules Smart TV USB 2.0 [ 8899.550543] em28xx #0: card=27 -> Pinnacle PCTV USB 2 (Philips FM1216ME) [ 8899.550568] em28xx #0: card=28 -> Leadtek Winfast USB II Deluxe [ 8899.550574] em28xx #0: card=29 -> [ 8899.550599] em28xx #0: card=30 -> Videology 20K14XUSB USB2.0 [ 8899.550605] em28xx #0: card=31 -> Usbgear VD204v9 [ 8899.550629] em28xx #0: card=32 -> Supercomp USB 2.0 TV [ 8899.550635] em28xx #0: card=33 -> [ 8899.550659] em28xx #0: card=34 -> Terratec Ci
Re: [mythtv] go7007 based devices
TJ wrote: > > Hans Verkuil wrote: >> On Thursday 21 January 2010 09:07:47 TJ wrote: >>> Jelle Foks wrote: TJ wrote: > I am curious how many people are successfully using go7007 based > capture devices > with mythtv. I've done some patch work on go7007 driver to make it v4l2 > compliant and was thinking of updating mythtv to stop using > proprietary go7007 > ioctls, but wanted to feel the ground first. > -TJ > > PS: jelle you on this list? > Yep, I'm on it, but I guess I don't check on it very often ;-)... >>> You sure don't :) >>> Myself, I'm using a bunch of plextors (with the go7007 chip), both M402's without tuner and TV402's with tuner on my mythbackend in the closet, using Ubuntu with a 2.6.31-11-generic-pae kernel and drivers that I made by combining the driver from the kernel staging tree and an older version that still worked, as I posted (with more details) on my blog at http://go70007.imploder.org . Somebody replied on the blog that it also works on 2.6.32.2, on ARM even... I actually don't know who maintains the go7007 driver in the staging tree, but I don't think it was the v4l guys. >> Actually, it is. So the linux-media list is the appropriate place to post >> patches on. >> It is currently maintained by Pete Eberlein from Sensoray. >> >>> Try this patch. It runs against kernel source. I tried it on 2.6.32, >>> 2.6.32-r1 >>> and -r2. I basically did some general cleanup on the go7007 driver in the >>> kernel >>> tree, added few standard v4l2 commands and *temporarily* put back in >>> proprietary >>> go7007 ioctls from your package for continued mythtv support. I also added >>> support for ADS Tech DVD Xpress DX2 board (which was the main reason I got >>> into >>> it). It runs well on my DX2 boxes. I've got about 100 of them and am >>> currently >>> testing it on 5. >> Please post this as well to the linux-media list. It would be great if >> someone would be >> willing to do more work on this driver and get it out of staging into the >> mainline. It's >> getting close, but it's not there yet. >> >> Regards, >> >> Hans >> > > Hans, My brother, pardon my ignorance, but would you please be so kind and > shed > some light for me on which way I should go. > > I was in touch with Pete on linux-media list and he's done quite a bit of work > on updating the driver in the current linux-media hg tree. > > My patch runs against official linux kernel 2.6.32.x but won't run against hg > tree. > > So, my thoughts were to go 2 ways: > > 1. Update my patch against current linux development kernel (2.6.33-rc5? or > -next?) and submit it to be included with the next kernel release. It would > still be in the staging category, but at least people will be able to > immediately take advantage of the following things: > > - ADS Tech DX2 support (which I added, actually ported from some earlier > release) > - Mythtv support (as I included original ioctls) > - Mythtv will now be able to be patched to use standard ioctls (I also kept > and > expanded all standard ioctls) > - I found and fixt a few minor bugs > > 2. Keep working against current linux-media hg tree and tell people to hang > tight. This might take a while though, cuz between now and Sept-Oct this year > I > won't be able to put a lot of time into it (worken on a big project). > > The things I dunno about and would appreciate anyone shedding some light on > are: > > a. Is the current linux-media hg tree going to be included in 2.6.33 kernel? > If > so, then option 1 above is out of the question and I will keep working with > Pete > on the current hg driver. > > b. If the things didn't change much in the kernel tree since 2.6.32, I can > probably quickly update my patch and submit it for inclusion into 2.6.33. > > If that's the case, which kernel should I make the patch against? Should I > just > git 2.6.33-rc5? > > Who do I submit my patch to? > > Again sorry for my ignorance, I don't do much collaborative work, but I am > willing to help out the community. :) Let me answer to your questions: The better is to generate your patch against the development -git tree: http://git.linuxtv.org/v4l-dvb.git This tree is merged upstream, at the upstream linux-next tree, and have all the patches that will go to 2.6.34 (patches against -rc trees are only for bug fixes). As the -hg tree has the same code as -git (it is manually updated when a change happens on -git), it is safe to generate your patch against -hg. The patch is handled by me, but you should send it to linux-media@vger.kernel.org only. If the patch doesn't have any whitespace trobules, it will be catched by http://patchwork.kernel.org, and I'll be able to see it at the web interface. You can read more about how to submit a patch at: http://linuxtv.org/wiki/index.php/Maintaining_Git_trees http://linuxtv.org/hg/v4l-dvb/raw-file/tip/README
Re: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
Stefan Ringel wrote: > Hi, > > I have a problem with usb bulk transfer. After a while, as I scan digital > channel (it found a few channel), it wrote this in the log: > > Jan 26 21:58:35 linux-v5dy kernel: [ 548.756585] tm6000: status != 0 > > I updated the tm6000_urb_received function so that I can read the Error code > and it logged: > > Jan 27 17:41:28 linux-v5dy kernel: [ 3121.892793] tm6000: status = 0xffb5 Probablt it is this error: #define EOVERFLOW 75 /* Value too large for defined data type */ It would be good to make it display the error as a signed int. the tm6000-video error handler has some common causes for those status. In this particular case: case -EOVERFLOW: errmsg = "Babble (bad cable?)"; break; This looks the same kind of errors I was receiving during the development of the driver: a large amount of frames are got broken, even if the device is programmed with the exact values used on the original driver. On my tests, changing the URB size were changing the position where such errors were occurring. > > Can you help me? Who I can calculate urb size? Take a look on tm6000-video: size = usb_maxpacket(dev->udev, pipe, usb_pipeout(pipe)); if (size > dev->max_isoc_in) size = dev->max_isoc_in; It depends on the alternate interface used. The driver should select an alternate interface that is capable of receiving the entire size of a message. Maybe the tm6000 driver is missing the code that selects this size. Take a look on em28xx-core, at em28xx_set_alternate() code for an example on how this should work. The calculated size there assumes that each pixel has 16 bits, and has some magic that were experimentally tested on that device. Cheers, Mauro. -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] soc_camera: match signedness of soc_camera_limit_side()
You didn't reply to my most important objection:
On Wed, 27 Jan 2010, Németh Márton wrote:
> diff -r 31eaa9423f98 linux/include/media/soc_camera.h
> --- a/linux/include/media/soc_camera.hMon Jan 25 15:04:15 2010 -0200
> +++ b/linux/include/media/soc_camera.hWed Jan 27 20:49:57 2010 +0100
> @@ -264,9 +264,8 @@
> common_flags;
> }
>
> -static inline void soc_camera_limit_side(unsigned int *start,
> - unsigned int *length, unsigned int start_min,
> - unsigned int length_min, unsigned int length_max)
> +static inline void soc_camera_limit_side(int *start, int *length,
> + int start_min, int length_min, int length_max)
> {
> if (*length < length_min)
> *length = length_min;
I still do not believe this function will work equally well with signed
parameters, as it works with unsigned ones.
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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
On Wednesday 27 January 2010 21:02:30 Németh Márton wrote: > Hello Hans, > > Hans Verkuil wrote: > > This message is generated daily by a cron job that builds v4l-dvb for > > the kernels and architectures in the list below. > > The last cron message I saw was on 23rd January, 2010. All warnings and errors > were fixed since then ;-) or is there some problem with the cron job? The build server and my whole home network for that matter were undergoing a big upgrade. New harddisks and especially a new linux distro. It's now finished and the daily build has just started. So you should see the cron message in about two hours (it's a bit late today, tomorrow it is back to the normal schedule). Regards, Hans > > Regarsd, > > Márton Németh > > -- 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: [mythtv] go7007 based devices
Hans Verkuil wrote: > On Thursday 21 January 2010 09:07:47 TJ wrote: >> Jelle Foks wrote: >>> TJ wrote: I am curious how many people are successfully using go7007 based capture devices with mythtv. I've done some patch work on go7007 driver to make it v4l2 compliant and was thinking of updating mythtv to stop using proprietary go7007 ioctls, but wanted to feel the ground first. -TJ PS: jelle you on this list? >>> Yep, I'm on it, but I guess I don't check on it very often ;-)... >> You sure don't :) >> >>> Myself, I'm using a bunch of plextors (with the go7007 chip), both >>> M402's without tuner and TV402's with tuner on my mythbackend in the >>> closet, using Ubuntu with a 2.6.31-11-generic-pae kernel and drivers >>> that I made by combining the driver from the kernel staging tree and an >>> older version that still worked, as I posted (with more details) on my >>> blog at http://go70007.imploder.org . Somebody replied on the blog that >>> it also works on 2.6.32.2, on ARM even... I actually don't know who >>> maintains the go7007 driver in the staging tree, but I don't think it >>> was the v4l guys. > > Actually, it is. So the linux-media list is the appropriate place to post > patches on. > It is currently maintained by Pete Eberlein from Sensoray. > >> Try this patch. It runs against kernel source. I tried it on 2.6.32, >> 2.6.32-r1 >> and -r2. I basically did some general cleanup on the go7007 driver in the >> kernel >> tree, added few standard v4l2 commands and *temporarily* put back in >> proprietary >> go7007 ioctls from your package for continued mythtv support. I also added >> support for ADS Tech DVD Xpress DX2 board (which was the main reason I got >> into >> it). It runs well on my DX2 boxes. I've got about 100 of them and am >> currently >> testing it on 5. > > Please post this as well to the linux-media list. It would be great if > someone would be > willing to do more work on this driver and get it out of staging into the > mainline. It's > getting close, but it's not there yet. > > Regards, > > Hans > Hans, My brother, pardon my ignorance, but would you please be so kind and shed some light for me on which way I should go. I was in touch with Pete on linux-media list and he's done quite a bit of work on updating the driver in the current linux-media hg tree. My patch runs against official linux kernel 2.6.32.x but won't run against hg tree. So, my thoughts were to go 2 ways: 1. Update my patch against current linux development kernel (2.6.33-rc5? or -next?) and submit it to be included with the next kernel release. It would still be in the staging category, but at least people will be able to immediately take advantage of the following things: - ADS Tech DX2 support (which I added, actually ported from some earlier release) - Mythtv support (as I included original ioctls) - Mythtv will now be able to be patched to use standard ioctls (I also kept and expanded all standard ioctls) - I found and fixt a few minor bugs 2. Keep working against current linux-media hg tree and tell people to hang tight. This might take a while though, cuz between now and Sept-Oct this year I won't be able to put a lot of time into it (worken on a big project). The things I dunno about and would appreciate anyone shedding some light on are: a. Is the current linux-media hg tree going to be included in 2.6.33 kernel? If so, then option 1 above is out of the question and I will keep working with Pete on the current hg driver. b. If the things didn't change much in the kernel tree since 2.6.32, I can probably quickly update my patch and submit it for inclusion into 2.6.33. If that's the case, which kernel should I make the patch against? Should I just git 2.6.33-rc5? Who do I submit my patch to? Again sorry for my ignorance, I don't do much collaborative work, but I am willing to help out the community. :) -TJ -- 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: [cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
Hello Hans, Hans Verkuil wrote: > This message is generated daily by a cron job that builds v4l-dvb for > the kernels and architectures in the list below. The last cron message I saw was on 23rd January, 2010. All warnings and errors were fixed since then ;-) or is there some problem with the cron job? Regarsd, Márton Németh -- 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] soc_camera: match signedness of soc_camera_limit_side()
From: Márton Németh
The parameters of soc_camera_limit_side() are either a pointer to
a structure element from v4l2_rect, or constants. The structure elements
of the v4l2_rect are signed (see ) so do the computations
also with signed values.
The *s_crop() functions may receive negative numbers through the c field of
struct v4l2_crop. These negative values then limited by the start_min and
length_min parameters of soc_camera_limit_side().
This will remove the following sparse warning (see "make C=1"):
* incorrect type in argument 1 (different signedness)
expected unsigned int *start
got signed int *
Signed-off-by: Márton Németh
---
diff -r 31eaa9423f98 linux/drivers/media/video/mt9v022.c
--- a/linux/drivers/media/video/mt9v022.c Mon Jan 25 15:04:15 2010 -0200
+++ b/linux/drivers/media/video/mt9v022.c Wed Jan 27 20:49:57 2010 +0100
@@ -326,7 +326,7 @@
if (ret < 0)
return ret;
- dev_dbg(&client->dev, "Frame %ux%u pixel\n", rect.width, rect.height);
+ dev_dbg(&client->dev, "Frame %dx%d pixel\n", rect.width, rect.height);
mt9v022->rect = rect;
diff -r 31eaa9423f98 linux/drivers/media/video/rj54n1cb0c.c
--- a/linux/drivers/media/video/rj54n1cb0c.cMon Jan 25 15:04:15 2010 -0200
+++ b/linux/drivers/media/video/rj54n1cb0c.cWed Jan 27 20:49:57 2010 +0100
@@ -555,15 +555,15 @@
return ret;
}
-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
- u32 *out_w, u32 *out_h);
+static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+ s32 *out_w, s32 *out_h);
static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
{
struct i2c_client *client = sd->priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
struct v4l2_rect *rect = &a->c;
- unsigned int dummy = 0, output_w, output_h,
+ int dummy = 0, output_w, output_h,
input_w = rect->width, input_h = rect->height;
int ret;
@@ -577,7 +577,7 @@
output_w = (input_w * 1024 + rj54n1->resize / 2) / rj54n1->resize;
output_h = (input_h * 1024 + rj54n1->resize / 2) / rj54n1->resize;
- dev_dbg(&client->dev, "Scaling for %ux%u : %u = %ux%u\n",
+ dev_dbg(&client->dev, "Scaling for %dx%d : %d = %dx%d\n",
input_w, input_h, rj54n1->resize, output_w, output_h);
ret = rj54n1_sensor_scale(sd, &input_w, &input_h, &output_w, &output_h);
@@ -638,12 +638,12 @@
* the output one, updates the window sizes and returns an error or the resize
* coefficient on success. Note: we only use the "Fixed Scaling" on this
camera.
*/
-static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
- u32 *out_w, u32 *out_h)
+static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
+ s32 *out_w, s32 *out_h)
{
struct i2c_client *client = sd->priv;
struct rj54n1 *rj54n1 = to_rj54n1(client);
- unsigned int skip, resize, input_w = *in_w, input_h = *in_h,
+ int skip, resize, input_w = *in_w, input_h = *in_h,
output_w = *out_w, output_h = *out_h;
u16 inc_sel, wb_bit8, wb_left, wb_right, wb_top, wb_bottom;
unsigned int peak, peak_50, peak_60;
@@ -655,7 +655,7 @@
* case we have to either reduce the input window to equal or below
* 512x384 or the output window to equal or below 1/2 of the input.
*/
- if (output_w > max(512U, input_w / 2)) {
+ if (output_w > max(512, input_w / 2)) {
if (2 * output_w > RJ54N1_MAX_WIDTH) {
input_w = RJ54N1_MAX_WIDTH;
output_w = RJ54N1_MAX_WIDTH / 2;
@@ -663,11 +663,11 @@
input_w = output_w * 2;
}
- dev_dbg(&client->dev, "Adjusted output width: in %u, out %u\n",
+ dev_dbg(&client->dev, "Adjusted output width: in %d, out %d\n",
input_w, output_w);
}
- if (output_h > max(384U, input_h / 2)) {
+ if (output_h > max(384, input_h / 2)) {
if (2 * output_h > RJ54N1_MAX_HEIGHT) {
input_h = RJ54N1_MAX_HEIGHT;
output_h = RJ54N1_MAX_HEIGHT / 2;
@@ -675,7 +675,7 @@
input_h = output_h * 2;
}
- dev_dbg(&client->dev, "Adjusted output height: in %u, out %u\n",
+ dev_dbg(&client->dev, "Adjusted output height: in %d, out %d\n",
input_h, output_h);
}
@@ -749,7 +749,7 @@
* improve the image quality or stability for larger frames (see comment
* above), but I didn't check the framerate.
*/
- skip = min(resize / 1024, (unsigned)15);
+ skip = min(resize / 1024, 15);
inc_sel = 1 << skip;
@@ -819,7 +819,7 @@
*out_w
Re: Terratec Cinergy Hybrid XE (TM6010 Mediachip)
Hi, I have a problem with usb bulk transfer. After a while, as I scan digital channel (it found a few channel), it wrote this in the log: Jan 26 21:58:35 linux-v5dy kernel: [ 548.756585] tm6000: status != 0 I updated the tm6000_urb_received function so that I can read the Error code and it logged: Jan 27 17:41:28 linux-v5dy kernel: [ 3121.892793] tm6000: status = 0xffb5 Can you help me? Who I can calculate urb size? Cheers Stefan Ringel -- Stefan Ringel -- 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: Setting up white balance on a t613 camera
Yes, as wrote in the code, it tied to whitebalance. Also note that , as Jean wrote, there's are many different values wrote on some registers, that we don't really know what they are used for, so, i would like to go for the most non intrusive option, since, some of this whitebalance regs, have been adjusted time to time to meet other t613 users requirment's, and maybe implementing the r/b balance would be the way to go. If you want, i can write it so you can test it, or if you prefeer you can take a look at http://linuxtv.org/hg/~jfrancois/gspca/file/21f2eeb240db/linux/drivers/media/video/gspca/sonixj.c at how its done as an example. Since i only had this webcam for 1 week, i always relay on the some group of users that are willing to test each change always. Best Regadrs. Costantino Leandro On Wed, Jan 27, 2010 at 3:37 PM, Jean-Francois Moine wrote: > On Wed, 27 Jan 2010 15:17:53 -0200 > Nicolau Werneck wrote: > >> Answering my own question, and also a question in the t613 source >> code... >> >> Yes, the need for the "reg_w(gspca_dev, 0x2087);", 0x2088 and 0x2089 >> commands are definitely tied to the white balance. These three set up >> the default values I found out. And (X << 8 + 87) sets up the red >> channel parameter in general, and 88 is for green and 89 for blue. >> >> That means I can already just play with them and see what happens. My >> personal problem is that I bought this new lens, and the image is way >> too bright, and changing that seems to help. But I would like to offer >> these as parameters the user can set using v4l2 programs. I can try >> making that big change myself, but help from a more experienced >> developer would be certainly much appreciated!... > > Hello Nicolau, > > The white balance is set in setwhitebalance(). Four registers are > changed: 87, 88, 89 and 80. > > Looking at the traces I have, these 4 registers are loaded together only > one time in an exchange at startup time. Then, the white balance > control adjusts only blue and red values while reloading the same value > for the green register (that's what is done for other webcams), and the > register 80 is not touched. In the different traces, the register 80 > may be initialized to various values as 3c, ac or 38 and it is not > touched later. I do not know what it is used for. > > I may also notice that the green value in the white balance exchanges > may have an other value than the default 20. I do not know which is the > associated control in the ms-win driver. If it is exposure, you are > done. So, one trivial patch is: > > - add the exposure control with min: 0x10, max: 0x40, def: 0x20. > > - modify the whitebalance control with min: -16, max +16, def:0. > > - there is no function setexposure() because the exposure is the value > of green register. Both controls exposure and white balance call the > function setwhitebalance(). > > - in the function setwhitebalance(), set the green value to the > exposure, the red value to (exposure + whitebalance) and blue value > to (exposure - whitebalance) and load only the registers 87, 88 and > 89. > > An other way could be to implement the blue and red balances in the > same scheme, and to remove the whitebalance. > > Cheers. > > -- > 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 > -- 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: Setting up white balance on a t613 camera
On Wed, 27 Jan 2010 15:17:53 -0200 Nicolau Werneck wrote: > Answering my own question, and also a question in the t613 source > code... > > Yes, the need for the "reg_w(gspca_dev, 0x2087);", 0x2088 and 0x2089 > commands are definitely tied to the white balance. These three set up > the default values I found out. And (X << 8 + 87) sets up the red > channel parameter in general, and 88 is for green and 89 for blue. > > That means I can already just play with them and see what happens. My > personal problem is that I bought this new lens, and the image is way > too bright, and changing that seems to help. But I would like to offer > these as parameters the user can set using v4l2 programs. I can try > making that big change myself, but help from a more experienced > developer would be certainly much appreciated!... Hello Nicolau, The white balance is set in setwhitebalance(). Four registers are changed: 87, 88, 89 and 80. Looking at the traces I have, these 4 registers are loaded together only one time in an exchange at startup time. Then, the white balance control adjusts only blue and red values while reloading the same value for the green register (that's what is done for other webcams), and the register 80 is not touched. In the different traces, the register 80 may be initialized to various values as 3c, ac or 38 and it is not touched later. I do not know what it is used for. I may also notice that the green value in the white balance exchanges may have an other value than the default 20. I do not know which is the associated control in the ms-win driver. If it is exposure, you are done. So, one trivial patch is: - add the exposure control with min: 0x10, max: 0x40, def: 0x20. - modify the whitebalance control with min: -16, max +16, def:0. - there is no function setexposure() because the exposure is the value of green register. Both controls exposure and white balance call the function setwhitebalance(). - in the function setwhitebalance(), set the green value to the exposure, the red value to (exposure + whitebalance) and blue value to (exposure - whitebalance) and load only the registers 87, 88 and 89. An other way could be to implement the blue and red balances in the same scheme, and to remove the whitebalance. Cheers. -- 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] soc_camera: match signedness of soc_camera_limit_side()
On Wed, 27 Jan 2010, Németh Márton wrote:
> Guennadi Liakhovetski wrote:
[snip]
> > And these:
> >
> > if (output_w > max(512U, input_w / 2)) {
> > if (output_h > max(384U, input_h / 2)) {
> >
> > would now produce compiler warnings... Have you actually tried to compile
> > your patch? You'll also have to change formats in dev_dbg() calls here...
>
> Interesting to hear about compiler warnings. I don't get them if I apply the
> patch
> on top of version 14064:31eaa9423f98 of http://linuxtv.org/hg/v4l-dvb/ . What
> is your compiler version?
Well, it's my built-in mental compiler, I haven't started versioning it
yet;) Strange, that (your) compiler doesn't complain - max() does
type-checking and now it's signed against unsigned, hm... In any case,
that one is easy to fix - just remove the "U"s, but I'm wondering why the
compiler didn't shout and whether there can be other similar mismatches...
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] soc_camera: match signedness of soc_camera_limit_side()
Guennadi Liakhovetski wrote:
> On Sat, 23 Jan 2010, Németh Márton wrote:
>
>> From: Márton Németh
>>
>> The parameters of soc_camera_limit_side() are either a pointer to
>> a structure element from v4l2_rect, or constants. The structure elements
>> of the v4l2_rect are signed (see ) so do the computations
>> also with signed values.
>>
>> This will remove the following sparse warning (see "make C=1"):
>> * incorrect type in argument 1 (different signedness)
>>expected unsigned int *start
>>got signed int *
>
> Well, it is interesting, but insufficient. And, unfortunately, I don't
> have a good (and easy) recipe for how to fix this properly.
>
> The problem is, that in soc_camera_limit_side all tests and arithmetics
> are performed with unsigned in mind, now, if you change them to signed,
> think what happens, if some of them are negative. No, I don't know when
> negative members of struct v4l2_rect make sense, having them signed
> doesn't seem a very good idea to me. But they cannot be changed - that's a
> part of the user-space API...
>
> Casting all parameters inside that inline to unsigned would be way too
> ugly. Maybe we could at least keep start_min, length_min, and length_max
> unsigned, and only change start and length to signed, and only cast those
> two inside the function. Then, if you grep through all the drivers,
> there's only one location, where soc_camera_limit_side() is called with
> the latter 3 parameters not constant - two calls in
> sh_mobile_ceu_camera.c. So, to keep sparse happy, you'd have to cast
> there. Ideally, you would also add checks there for negative values...
I'll have a look to see what can be done to handle the negative values properly.
>> Signed-off-by: Márton Németh
>> ---
>> diff -r 2a50a0a1c951 linux/include/media/soc_camera.h
>> --- a/linux/include/media/soc_camera.h Sat Jan 23 00:14:32 2010 -0200
>> +++ b/linux/include/media/soc_camera.h Sat Jan 23 10:09:41 2010 +0100
>> @@ -264,9 +264,8 @@
>> common_flags;
>> }
>>
>> -static inline void soc_camera_limit_side(unsigned int *start,
>> -unsigned int *length, unsigned int start_min,
>> -unsigned int length_min, unsigned int length_max)
>> +static inline void soc_camera_limit_side(int *start, int *length,
>> +int start_min, int length_min, int length_max)
>> {
>> if (*length < length_min)
>> *length = length_min;
>> diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c
>> --- a/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 00:14:32 2010 -0200
>> +++ b/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 10:09:41 2010 +0100
>> @@ -555,15 +555,15 @@
>> return ret;
>> }
>>
>> -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
>> - u32 *out_w, u32 *out_h);
>> +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
>> + s32 *out_w, s32 *out_h);
>>
>> static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
>> {
>> struct i2c_client *client = sd->priv;
>> struct rj54n1 *rj54n1 = to_rj54n1(client);
>> struct v4l2_rect *rect = &a->c;
>> -unsigned int dummy = 0, output_w, output_h,
>> +int dummy = 0, output_w, output_h,
>> input_w = rect->width, input_h = rect->height;
>> int ret;
>
> And these:
>
> if (output_w > max(512U, input_w / 2)) {
> if (output_h > max(384U, input_h / 2)) {
>
> would now produce compiler warnings... Have you actually tried to compile
> your patch? You'll also have to change formats in dev_dbg() calls here...
Interesting to hear about compiler warnings. I don't get them if I apply the
patch
on top of version 14064:31eaa9423f98 of http://linuxtv.org/hg/v4l-dvb/ . What
is your compiler version?
I used the attached configuration. Maybe some other options has to be
turned on?
localhost:/usr/src/linuxtv.org/v4l-dvb$ patch -p1
<../soc_camera_signedness.patch
patching file linux/include/media/soc_camera.h
patching file linux/drivers/media/video/rj54n1cb0c.c
localhost:/usr/src/linuxtv.org/v4l-dvb$ make C=1 2>&1 |tee result1.txt
make -C /usr/src/linuxtv.org/v4l-dvb/v4l
make[1]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l'
creating symbolic links...
make -C firmware prep
make[2]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
make[2]: Leaving directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
make -C firmware
make[2]: Entering directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
make[2]: Nothing to be done for `default'.
make[2]: Leaving directory `/usr/src/linuxtv.org/v4l-dvb/v4l/firmware'
Kernel build directory is /lib/modules/2.6.33-rc4/build
make -C /lib/modules/2.6.33-rc4/build SUBDIRS=/usr/src/linuxtv.org/v4l-dvb/v4l
modules
make[2]: Entering directory `/usr/src/linuxtv.org/pinchartl/uvcvideo/v4l-dvb'
CHECK /usr/src/linuxtv.org/v4l-dvb/v4l/mt9m001.c
CC [M] /usr/src/l
Re: Setting up white balance on a t613 camera
Answering my own question, and also a question in the t613 source code... Yes, the need for the "reg_w(gspca_dev, 0x2087);", 0x2088 and 0x2089 commands are definitely tied to the white balance. These three set up the default values I found out. And (X << 8 + 87) sets up the red channel parameter in general, and 88 is for green and 89 for blue. That means I can already just play with them and see what happens. My personal problem is that I bought this new lens, and the image is way too bright, and changing that seems to help. But I would like to offer these as parameters the user can set using v4l2 programs. I can try making that big change myself, but help from a more experienced developer would be certainly much appreciated!... ++nicolau On Wed, Jan 27, 2010 at 02:37:09PM -0200, Nicolau Werneck wrote: > Hello again, people. I believe I have found in my log the commands > that are setting up that white balance parameters. I am pasting an > excerpt of the log at the end. (I changed the subject now that is > seems this is actually the way I should follow) > > It looks to me that in that SetupPacket vector the "88" encodes what > channel to set. 87 for red, 88 for blue and 89 for green. The > following value is the level, which is default to 0x20. > > The question now is how do I offer to set up that parameter in the > driver? What function can I use to transmits a vector that way, so I > can make a hacky test? > > In other words: would it be possible or me to just cut and paste some > code in the driver to implement that? Or will I be finally forced to > actually learn what I am doing? :) > > regards, > >++nicolau -- Nicolau Werneck 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- 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 1/2] radio: Add radio-timb
On Wednesday 27 January 2010 17:22:08 Richard Röjfors wrote:
> This patch add supports for the radio system on the Intel Russellville board.
>
> It's a In-Vehicle Infotainment board with a radio tuner and DSP.
>
> This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
> when needed.
>
> The RDS support is done by I/O memory accesses.
>
> Signed-off-by: Richard Röjfors
> ---
> diff --git a/drivers/media/radio/radio-timb.c
> b/drivers/media/radio/radio-timb.c
> new file mode 100644
> index 000..276b105
> --- /dev/null
> +++ b/drivers/media/radio/radio-timb.c
> @@ -0,0 +1,469 @@
> +/*
> + * radio-timb.c Timberdale FPGA Radio driver
> + * Copyright (c) 2009 Intel Corporation
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +#define DRIVER_NAME "timb-radio"
> +
> +#define RDS_BLOCK_SIZE 4
> +#define RDS_BUFFER_SIZE (RDS_BLOCK_SIZE * 100)
> +
> +struct timbradio {
> + struct mutexlock; /* for mutual exclusion */
> + void __iomem*membase;
> + struct timb_radio_platform_data pdata;
> + struct v4l2_subdev *sd_tuner;
> + struct v4l2_subdev *sd_dsp;
> + struct video_device *video_dev;
> + struct v4l2_device v4l2_dev;
> + /* RDS related */
> + int open_count;
> + int rds_irq;
> + wait_queue_head_t read_queue;
> + unsigned char buffer[RDS_BUFFER_SIZE];
> + unsigned int rd_index;
> + unsigned int wr_index;
> +};
> +
> +
> +static int timbradio_vidioc_querycap(struct file *file, void *priv,
> + struct v4l2_capability *v)
> +{
> + strlcpy(v->driver, DRIVER_NAME, sizeof(v->driver));
> + strlcpy(v->card, "Timberdale Radio", sizeof(v->card));
> + snprintf(v->bus_info, sizeof(v->bus_info), "platform:"DRIVER_NAME);
> + v->version = KERNEL_VERSION(0, 0, 1);
> + v->capabilities =
> + V4L2_CAP_TUNER | V4L2_CAP_RADIO | V4L2_CAP_RDS_CAPTURE;
> + return 0;
> +}
> +
> +static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
> + struct v4l2_tuner *v)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd_tuner, tuner, g_tuner, v);
> +}
> +
> +static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
> + struct v4l2_tuner *v)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd_tuner, tuner, s_tuner, v);
> +}
> +
> +static int timbradio_vidioc_g_input(struct file *filp, void *priv,
> + unsigned int *i)
> +{
> + *i = 0;
> + return 0;
> +}
> +
> +static int timbradio_vidioc_s_input(struct file *filp, void *priv,
> + unsigned int i)
> +{
> + return i ? -EINVAL : 0;
> +}
> +
> +static int timbradio_vidioc_g_audio(struct file *file, void *priv,
> + struct v4l2_audio *a)
> +{
> + a->index = 0;
> + strlcpy(a->name, "Radio", sizeof(a->name));
> + a->capability = V4L2_AUDCAP_STEREO;
> + return 0;
> +}
> +
> +
> +static int timbradio_vidioc_s_audio(struct file *file, void *priv,
> + struct v4l2_audio *a)
> +{
> + return a->index ? -EINVAL : 0;
> +}
> +
> +static int timbradio_vidioc_s_frequency(struct file *file, void *priv,
> + struct v4l2_frequency *f)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd_tuner, tuner, s_frequency, f);
> +}
> +
> +static int timbradio_vidioc_g_frequency(struct file *file, void *priv,
> + struct v4l2_frequency *f)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd_tuner, tuner, g_frequency, f);
> +}
> +
> +static int timbradio_vidioc_queryctrl(struct file *file, void *priv,
> + struct v4l2_queryctrl *qc)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd_dsp, core, queryctrl, qc);
> +}
> +
> +static int timbradio_vidioc_g_ctrl(struct file *file, void *priv,
> + struct v4l2_control *ctrl)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd_dsp, core, g_ctrl, ctrl);
> +}
> +
> +static int timbradio_vidioc_s_ctrl(struct file *file, void *priv,
> + struct v4l2_control *ctrl)
> +{
> + struct timbradio *tr = video_drvdata(file);
> + return v4l2_subdev_call(tr->sd
Re: [PATCH v2 2/2] radio: Add radio-timb to the Kconfig and Makefile
On Wednesday 27 January 2010 17:22:10 Richard Röjfors wrote: > This patch adds radio-timb to the Makefile and Kconfig. > > Signed-off-by: Richard Röjfors > --- > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig > index 3f40f37..46fd8c4 100644 > --- a/drivers/media/radio/Kconfig > +++ b/drivers/media/radio/Kconfig > @@ -429,4 +429,14 @@ config RADIO_TEF6862 > To compile this driver as a module, choose M here: the > module will be called TEF6862. > > +config RADIO_TIMBERDALE > + tristate "Enable the Timberdale radio driver" > + depends on MFD_TIMBERDALE && VIDEO_V4L2 && HAS_IOMEM I think you need a dependency on I2C as well. Regards, Hans > + select RADIO_TEF6862 > + select RADIO_SAA7706H > + ---help--- > + This is a kind of umbrella driver for the Radio Tuner and DSP > + found behind the Timberdale FPGA on the Russellville board. > + Enable this driver will automatically select the DSP and tuner. > + > endif # RADIO_ADAPTERS > diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile > index 01922ad..8973850 100644 > --- a/drivers/media/radio/Makefile > +++ b/drivers/media/radio/Makefile > @@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/ > obj-$(CONFIG_USB_MR800) += radio-mr800.o > obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o > obj-$(CONFIG_RADIO_TEF6862) += tef6862.o > +obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o > > EXTRA_CFLAGS += -Isound > > -- 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 v2 2/2] radio: Add radio-timb to the Kconfig and Makefile
On Wed, 27 Jan 2010 17:22:10 +0100 Richard Röjfors wrote: > This patch adds radio-timb to the Makefile and Kconfig. > > Signed-off-by: Richard Röjfors > --- > diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig > index 3f40f37..46fd8c4 100644 > --- a/drivers/media/radio/Kconfig > +++ b/drivers/media/radio/Kconfig > @@ -429,4 +429,14 @@ config RADIO_TEF6862 > To compile this driver as a module, choose M here: the > module will be called TEF6862. > > +config RADIO_TIMBERDALE > + tristate "Enable the Timberdale radio driver" > + depends on MFD_TIMBERDALE && VIDEO_V4L2 && HAS_IOMEM > + select RADIO_TEF6862 > + select RADIO_SAA7706H > + ---help--- > + This is a kind of umbrella driver for the Radio Tuner and DSP > + found behind the Timberdale FPGA on the Russellville board. > + Enable this driver will automatically select the DSP and tuner. Enabling > + > endif # RADIO_ADAPTERS > diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile > index 01922ad..8973850 100644 > --- a/drivers/media/radio/Makefile > +++ b/drivers/media/radio/Makefile > @@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/ > obj-$(CONFIG_USB_MR800) += radio-mr800.o > obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o > obj-$(CONFIG_RADIO_TEF6862) += tef6862.o > +obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o > > EXTRA_CFLAGS += -Isound > > -- --- ~Randy -- 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
Setting up white balance on a t613 camera
Hello again, people. I believe I have found in my log the commands that are setting up that white balance parameters. I am pasting an excerpt of the log at the end. (I changed the subject now that is seems this is actually the way I should follow) It looks to me that in that SetupPacket vector the "88" encodes what channel to set. 87 for red, 88 for blue and 89 for green. The following value is the level, which is default to 0x20. The question now is how do I offer to set up that parameter in the driver? What function can I use to transmits a vector that way, so I can make a hacky test? In other words: would it be possible or me to just cut and paste some code in the driver to implement that? Or will I be finally forced to actually learn what I am doing? :) regards, ++nicolau (...) [61857 ms] <<< URB 393 coming back <<< -- URB_FUNCTION_CONTROL_TRANSFER: PipeHandle = 89fecb10 TransferFlags= 000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK) TransferBufferLength = TransferBuffer = TransferBufferMDL= UrbLink = SetupPacket = : 40 00 00 00 88 1c 00 00 [61910 ms] UsbSnoop - DispatchAny(bac00610) : IRP_MJ_INTERNAL_DEVICE_CONTROL [61910 ms] UsbSnoop - MyDispatchInternalIOCTL(bac01e80) : fdo=89cf58b0, Irp=89473e48, IRQL=0 [61910 ms] >>> URB 394 going down >>> -- URB_FUNCTION_VENDOR_DEVICE: TransferFlags = (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) TransferBufferLength = TransferBuffer = TransferBufferMDL= no data supplied UrbLink = RequestTypeReservedBits = Request = Value = Index = 1e88 [61913 ms] UsbSnoop - MyInternalIOCTLCompletion(bac01db0) : fido=, Irp=89473e48, Context=898d8fe8, IRQL=2 [61913 ms] <<< URB 394 coming back <<< -- URB_FUNCTION_CONTROL_TRANSFER: PipeHandle = 89fecb10 TransferFlags= 000a (USBD_TRANSFER_DIRECTION_OUT, USBD_SHORT_TRANSFER_OK) TransferBufferLength = TransferBuffer = TransferBufferMDL= UrbLink = SetupPacket = : 40 00 00 00 88 1e 00 00 [61950 ms] UsbSnoop - DispatchAny(bac00610) : IRP_MJ_INTERNAL_DEVICE_CONTROL [61950 ms] UsbSnoop - MyDispatchInternalIOCTL(bac01e80) : fdo=89cf58b0, Irp=89f97008, IRQL=0 [61950 ms] >>> URB 395 going down >>> -- URB_FUNCTION_VENDOR_DEVICE: TransferFlags = (USBD_TRANSFER_DIRECTION_OUT, ~USBD_SHORT_TRANSFER_OK) TransferBufferLength = TransferBuffer = TransferBufferMDL= no data supplied UrbLink = RequestTypeReservedBits = Request = Value = Index = 2088 (...) On Tue, Jan 26, 2010 at 07:37:26PM +0100, Jean-Francois Moine wrote: > On Tue, 26 Jan 2010 15:00:53 -0200 > Nicolau Werneck wrote: > > > Hello. I have this very cheap webcam that I sent a patch to support on > > gspca the other day. The specific driver is the t613. > > > > I changed the lens of this camera, and now my images are all too > > bright, what I believe is due to the much larger aperture of this new > > lens. So I would like to try setting up a smaller exposure time on the > > camera (I would like to do that for other reasons too). > > > > The problem is there's no "exposure" option to be set when I call > > programs such as v4lctl. Does that mean there is definitely no way for > > me to control the exposure time? The hardware itself was not designed > > to allow me do that? Or is there still a chance I can create some C > > program that might do it, for example? > [snip] > > Hello Nicolau, > > There are brightness, contrast, colors, autogain and some other video > controls for the t613 webcams. You must use a v4l2 compliant program to > change them, as vlc or v4l2ucp (but not cheese). > > Regards. > > -- > 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 -- Nicolau Werneck 1AAB 4050 1999 BDFF 4862 http://www.lti.pcs.usp.br/~nwerneck 4A33 D2B5 648B 4789 0327 Linux user #460716 -- 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 v2 2/2] radio: Add radio-timb to the Kconfig and Makefile
This patch adds radio-timb to the Makefile and Kconfig. Signed-off-by: Richard Röjfors --- diff --git a/drivers/media/radio/Kconfig b/drivers/media/radio/Kconfig index 3f40f37..46fd8c4 100644 --- a/drivers/media/radio/Kconfig +++ b/drivers/media/radio/Kconfig @@ -429,4 +429,14 @@ config RADIO_TEF6862 To compile this driver as a module, choose M here: the module will be called TEF6862. +config RADIO_TIMBERDALE + tristate "Enable the Timberdale radio driver" + depends on MFD_TIMBERDALE && VIDEO_V4L2 && HAS_IOMEM + select RADIO_TEF6862 + select RADIO_SAA7706H + ---help--- + This is a kind of umbrella driver for the Radio Tuner and DSP + found behind the Timberdale FPGA on the Russellville board. + Enable this driver will automatically select the DSP and tuner. + endif # RADIO_ADAPTERS diff --git a/drivers/media/radio/Makefile b/drivers/media/radio/Makefile index 01922ad..8973850 100644 --- a/drivers/media/radio/Makefile +++ b/drivers/media/radio/Makefile @@ -24,5 +24,6 @@ obj-$(CONFIG_RADIO_SI470X) += si470x/ obj-$(CONFIG_USB_MR800) += radio-mr800.o obj-$(CONFIG_RADIO_TEA5764) += radio-tea5764.o obj-$(CONFIG_RADIO_TEF6862) += tef6862.o +obj-$(CONFIG_RADIO_TIMBERDALE) += radio-timb.o EXTRA_CFLAGS += -Isound -- 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 v2 1/2] radio: Add radio-timb
This patch add supports for the radio system on the Intel Russellville board.
It's a In-Vehicle Infotainment board with a radio tuner and DSP.
This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
when needed.
The RDS support is done by I/O memory accesses.
Signed-off-by: Richard Röjfors
---
diff --git a/drivers/media/radio/radio-timb.c b/drivers/media/radio/radio-timb.c
new file mode 100644
index 000..276b105
--- /dev/null
+++ b/drivers/media/radio/radio-timb.c
@@ -0,0 +1,469 @@
+/*
+ * radio-timb.c Timberdale FPGA Radio driver
+ * Copyright (c) 2009 Intel Corporation
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#define DRIVER_NAME "timb-radio"
+
+#define RDS_BLOCK_SIZE 4
+#define RDS_BUFFER_SIZE (RDS_BLOCK_SIZE * 100)
+
+struct timbradio {
+ struct mutexlock; /* for mutual exclusion */
+ void __iomem*membase;
+ struct timb_radio_platform_data pdata;
+ struct v4l2_subdev *sd_tuner;
+ struct v4l2_subdev *sd_dsp;
+ struct video_device *video_dev;
+ struct v4l2_device v4l2_dev;
+ /* RDS related */
+ int open_count;
+ int rds_irq;
+ wait_queue_head_t read_queue;
+ unsigned char buffer[RDS_BUFFER_SIZE];
+ unsigned int rd_index;
+ unsigned int wr_index;
+};
+
+
+static int timbradio_vidioc_querycap(struct file *file, void *priv,
+ struct v4l2_capability *v)
+{
+ strlcpy(v->driver, DRIVER_NAME, sizeof(v->driver));
+ strlcpy(v->card, "Timberdale Radio", sizeof(v->card));
+ snprintf(v->bus_info, sizeof(v->bus_info), "platform:"DRIVER_NAME);
+ v->version = KERNEL_VERSION(0, 0, 1);
+ v->capabilities =
+ V4L2_CAP_TUNER | V4L2_CAP_RADIO | V4L2_CAP_RDS_CAPTURE;
+ return 0;
+}
+
+static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_tuner, tuner, g_tuner, v);
+}
+
+static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
+ struct v4l2_tuner *v)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_tuner, tuner, s_tuner, v);
+}
+
+static int timbradio_vidioc_g_input(struct file *filp, void *priv,
+ unsigned int *i)
+{
+ *i = 0;
+ return 0;
+}
+
+static int timbradio_vidioc_s_input(struct file *filp, void *priv,
+ unsigned int i)
+{
+ return i ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_g_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ a->index = 0;
+ strlcpy(a->name, "Radio", sizeof(a->name));
+ a->capability = V4L2_AUDCAP_STEREO;
+ return 0;
+}
+
+
+static int timbradio_vidioc_s_audio(struct file *file, void *priv,
+ struct v4l2_audio *a)
+{
+ return a->index ? -EINVAL : 0;
+}
+
+static int timbradio_vidioc_s_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_tuner, tuner, s_frequency, f);
+}
+
+static int timbradio_vidioc_g_frequency(struct file *file, void *priv,
+ struct v4l2_frequency *f)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_tuner, tuner, g_frequency, f);
+}
+
+static int timbradio_vidioc_queryctrl(struct file *file, void *priv,
+ struct v4l2_queryctrl *qc)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_dsp, core, queryctrl, qc);
+}
+
+static int timbradio_vidioc_g_ctrl(struct file *file, void *priv,
+ struct v4l2_control *ctrl)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_dsp, core, g_ctrl, ctrl);
+}
+
+static int timbradio_vidioc_s_ctrl(struct file *file, void *priv,
+ struct v4l2_control *ctrl)
+{
+ struct timbradio *tr = video_drvdata(file);
+ return v4l2_subdev_call(tr->sd_dsp, core, s_ctrl, ctrl);
+}
+
+static const struct v4l2_ioctl_ops timbradio_ioctl_ops = {
+ .vidioc_querycap= timbradio_vidioc_querycap,
+ .vidioc_g_tuner = timbradio_vidioc_g_tuner,
+ .vidioc_s_tuner = timbradio_vidioc_
[PATCH v2 0/2] radio: Add radio-timb
On the intel russellville board there is a radio DSP, radio tuner and a RDS block. This umbrella driver uses two subdevs (DSP and tuner), and reads RDS data. Updated after feedback from Hans Verkuil. Thanks Hans! Patch1: The actual code Patch2: Add the radio-timb to Kconfig and Makefile --Richard -- 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] soc_camera: match signedness of soc_camera_limit_side()
On Sat, 23 Jan 2010, Németh Márton wrote:
> From: Márton Németh
>
> The parameters of soc_camera_limit_side() are either a pointer to
> a structure element from v4l2_rect, or constants. The structure elements
> of the v4l2_rect are signed (see ) so do the computations
> also with signed values.
>
> This will remove the following sparse warning (see "make C=1"):
> * incorrect type in argument 1 (different signedness)
>expected unsigned int *start
>got signed int *
Well, it is interesting, but insufficient. And, unfortunately, I don't
have a good (and easy) recipe for how to fix this properly.
The problem is, that in soc_camera_limit_side all tests and arithmetics
are performed with unsigned in mind, now, if you change them to signed,
think what happens, if some of them are negative. No, I don't know when
negative members of struct v4l2_rect make sense, having them signed
doesn't seem a very good idea to me. But they cannot be changed - that's a
part of the user-space API...
Casting all parameters inside that inline to unsigned would be way too
ugly. Maybe we could at least keep start_min, length_min, and length_max
unsigned, and only change start and length to signed, and only cast those
two inside the function. Then, if you grep through all the drivers,
there's only one location, where soc_camera_limit_side() is called with
the latter 3 parameters not constant - two calls in
sh_mobile_ceu_camera.c. So, to keep sparse happy, you'd have to cast
there. Ideally, you would also add checks there for negative values...
>
> Signed-off-by: Márton Németh
> ---
> diff -r 2a50a0a1c951 linux/include/media/soc_camera.h
> --- a/linux/include/media/soc_camera.hSat Jan 23 00:14:32 2010 -0200
> +++ b/linux/include/media/soc_camera.hSat Jan 23 10:09:41 2010 +0100
> @@ -264,9 +264,8 @@
> common_flags;
> }
>
> -static inline void soc_camera_limit_side(unsigned int *start,
> - unsigned int *length, unsigned int start_min,
> - unsigned int length_min, unsigned int length_max)
> +static inline void soc_camera_limit_side(int *start, int *length,
> + int start_min, int length_min, int length_max)
> {
> if (*length < length_min)
> *length = length_min;
> diff -r 2a50a0a1c951 linux/drivers/media/video/rj54n1cb0c.c
> --- a/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 00:14:32 2010 -0200
> +++ b/linux/drivers/media/video/rj54n1cb0c.c Sat Jan 23 10:09:41 2010 +0100
> @@ -555,15 +555,15 @@
> return ret;
> }
>
> -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
> -u32 *out_w, u32 *out_h);
> +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
> +s32 *out_w, s32 *out_h);
>
> static int rj54n1_s_crop(struct v4l2_subdev *sd, struct v4l2_crop *a)
> {
> struct i2c_client *client = sd->priv;
> struct rj54n1 *rj54n1 = to_rj54n1(client);
> struct v4l2_rect *rect = &a->c;
> - unsigned int dummy = 0, output_w, output_h,
> + int dummy = 0, output_w, output_h,
> input_w = rect->width, input_h = rect->height;
> int ret;
And these:
if (output_w > max(512U, input_w / 2)) {
if (output_h > max(384U, input_h / 2)) {
would now produce compiler warnings... Have you actually tried to compile
your patch? You'll also have to change formats in dev_dbg() calls here...
>
> @@ -638,8 +638,8 @@
> * the output one, updates the window sizes and returns an error or the
> resize
> * coefficient on success. Note: we only use the "Fixed Scaling" on this
> camera.
> */
> -static int rj54n1_sensor_scale(struct v4l2_subdev *sd, u32 *in_w, u32 *in_h,
> -u32 *out_w, u32 *out_h)
> +static int rj54n1_sensor_scale(struct v4l2_subdev *sd, s32 *in_w, s32 *in_h,
> +s32 *out_w, s32 *out_h)
> {
> struct i2c_client *client = sd->priv;
> struct rj54n1 *rj54n1 = to_rj54n1(client);
> @@ -1017,7 +1017,7 @@
> struct i2c_client *client = sd->priv;
> struct rj54n1 *rj54n1 = to_rj54n1(client);
> const struct rj54n1_datafmt *fmt;
> - unsigned int output_w, output_h, max_w, max_h,
> + int output_w, output_h, max_w, max_h,
> input_w = rj54n1->rect.width, input_h = rj54n1->rect.height;
> int ret;
and here.
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 1/2] radio: Add radio-timb
Hans Verkuil wrote: >> The first time we run we could definitely do a 4l2_i2c_new_subdev*, but what >> if I rmmod the driver >> and insmod it again? When we do the do an open, then v4l2_i2c_new_subdev* >> would fail because the >> device is only on the bus and probed. So I would have to look for it anyway. >> Or am I wrong? I found >> this like the only generic way(?) > > Not sure I understand you. When you call v4l2_device_unregister any registered > i2c devices will be automatically unloaded from the i2c bus. So when you do a > new modprobe, then it is as if you did it for the first time. > > This should work. If not, then let me know and we can look at it. Thanks for the explanation! It should work, I will update accordingly. > >>> Is there a reason why you want to load them only on first use? It is >>> customary >>> to load them when this driver is loaded. Exceptions to that may be if the >>> i2c >>> device needs to load a firmware: this can be slow over i2c and so should be >>> postponed until the i2c driver is needed for the first time. >> The main reason is actually that this is a platform device which might come >> available before the I2C >> bus in the system. So we postpone the use of the bus until needed, because >> we know for sure it's >> available at that point. > > The i2c busses are always initialized first. That's a change that went in a > few > kernel releases ago. Ok, in this case the I2C bus sits on top of a MFD device which might be installed late to reduce bootup time. Bootup time is actually also a reason to keep this code in open rather than in probe. --Richard -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2, RFC] gspca: add input support for interrupt endpoints
Hi,
On 01/27/2010 07:34 AM, Németh Márton wrote:
Hello Jean-Francois,
do you have any comments or suggestions about this patch?
I've been playing around a bit with the latest incarnation
of this patch (with the resubmit issue fixed), and I can report
that it works very well. Once this is merged I've got patches
ready to add button support to pac207, pac7311 and zc3xx cameras
and more will follow as time permits.
Regards,
Hans
Regards,
Márton Németh
Hans de Goede wrote:
Hi,
Looks good to me now.
Regards,
Hans
On 01/18/2010 09:01 PM, Németh Márton wrote:
From: Márton Németh
Add support functions for interrupt endpoint based input handling.
Signed-off-by: Márton Németh
---
diff -r 875c200a19dc linux/drivers/media/video/gspca/gspca.c
--- a/linux/drivers/media/video/gspca/gspca.c Sun Jan 17 07:58:51 2010 +0100
+++ b/linux/drivers/media/video/gspca/gspca.c Mon Jan 18 20:43:55 2010 +0100
@@ -3,6 +3,9 @@
*
* Copyright (C) 2008-2009 Jean-Francois Moine (http://moinejf.free.fr)
*
+ * Camera button input handling by Márton Németh
+ * Copyright (C) 2009-2010 Márton Németh
+ *
* 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
@@ -41,6 +44,9 @@
#include "gspca.h"
+#include
+#include
+
/* global values */
#define DEF_NURBS 3 /* default number of URBs */
#if DEF_NURBS> MAX_NURBS
@@ -112,6 +118,186 @@
.close = gspca_vm_close,
};
+/*
+ * Input and interrupt endpoint handling functions
+ */
+#ifdef CONFIG_INPUT
+#if LINUX_VERSION_CODE< KERNEL_VERSION(2, 6, 19)
+static void int_irq(struct urb *urb, struct pt_regs *regs)
+#else
+static void int_irq(struct urb *urb)
+#endif
+{
+ struct gspca_dev *gspca_dev = (struct gspca_dev *) urb->context;
+ int ret;
+
+ ret = urb->status;
+ switch (ret) {
+ case 0:
+ if (gspca_dev->sd_desc->int_pkt_scan(gspca_dev,
+ urb->transfer_buffer, urb->actual_length)< 0) {
+ PDEBUG(D_ERR, "Unknown packet received");
+ }
+ break;
+
+ case -ENOENT:
+ case -ECONNRESET:
+ case -ENODEV:
+ case -ESHUTDOWN:
+ /* Stop is requested either by software or hardware is gone,
+* keep the ret value non-zero and don't resubmit later.
+*/
+ break;
+
+ default:
+ PDEBUG(D_ERR, "URB error %i, resubmitting", urb->status);
+ urb->status = 0;
+ ret = 0;
+ }
+
+ if (ret == 0) {
+ ret = usb_submit_urb(urb, GFP_ATOMIC);
+ if (ret< 0)
+ PDEBUG(D_ERR, "Resubmit URB failed with error %i", ret);
+ }
+}
+
+static int gspca_input_connect(struct gspca_dev *dev)
+{
+ struct input_dev *input_dev;
+ int err = 0;
+
+ dev->input_dev = NULL;
+ if (dev->sd_desc->int_pkt_scan) {
+ input_dev = input_allocate_device();
+ if (!input_dev)
+ return -ENOMEM;
+
+ usb_make_path(dev->dev, dev->phys, sizeof(dev->phys));
+ strlcat(dev->phys, "/input0", sizeof(dev->phys));
+
+ input_dev->name = dev->sd_desc->name;
+ input_dev->phys = dev->phys;
+
+ usb_to_input_id(dev->dev,&input_dev->id);
+
+ input_dev->evbit[0] = BIT_MASK(EV_KEY);
+ input_dev->keybit[BIT_WORD(KEY_CAMERA)] = BIT_MASK(KEY_CAMERA);
+ input_dev->dev.parent =&dev->dev->dev;
+
+ err = input_register_device(input_dev);
+ if (err) {
+ PDEBUG(D_ERR, "Input device registration failed "
+ "with error %i", err);
+ input_dev->dev.parent = NULL;
+ input_free_device(input_dev);
+ } else {
+ dev->input_dev = input_dev;
+ }
+ } else
+ err = -EINVAL;
+
+ return err;
+}
+
+static int alloc_and_submit_int_urb(struct gspca_dev *gspca_dev,
+ struct usb_endpoint_descriptor *ep)
+{
+ unsigned int buffer_len;
+ int interval;
+ struct urb *urb;
+ struct usb_device *dev;
+ void *buffer = NULL;
+ int ret = -EINVAL;
+
+ buffer_len = ep->wMaxPacketSize;
+ interval = ep->bInterval;
+ PDEBUG(D_PROBE, "found int in endpoint: 0x%x, "
+ "buffer_len=%u, interval=%u",
+ ep->bEndpointAddress, buffer_len, interval);
+
+ dev = gspca_dev->dev;
+
+ urb = usb_alloc_urb(0, GFP_KERNEL);
+ if (!urb) {
+ ret = -ENOMEM;
+ goto error;
+ }
+
+ buffer = usb_buffer_alloc(dev, ep->wMaxPacketSize,
+
Re: Setting up the exposure time of a webcam
HI Nicolau remember to send a SOB if the patch is working, and any change let me know so i can test with others t613 users. Best Regards On Tue, Jan 26, 2010 at 3:37 PM, Jean-Francois Moine wrote: > On Tue, 26 Jan 2010 15:00:53 -0200 > Nicolau Werneck wrote: > >> Hello. I have this very cheap webcam that I sent a patch to support on >> gspca the other day. The specific driver is the t613. >> >> I changed the lens of this camera, and now my images are all too >> bright, what I believe is due to the much larger aperture of this new >> lens. So I would like to try setting up a smaller exposure time on the >> camera (I would like to do that for other reasons too). >> >> The problem is there's no "exposure" option to be set when I call >> programs such as v4lctl. Does that mean there is definitely no way for >> me to control the exposure time? The hardware itself was not designed >> to allow me do that? Or is there still a chance I can create some C >> program that might do it, for example? > [snip] > > Hello Nicolau, > > There are brightness, contrast, colors, autogain and some other video > controls for the t613 webcams. You must use a v4l2 compliant program to > change them, as vlc or v4l2ucp (but not cheese). > > Regards. > > -- > 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 > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] radio: Add radio-timb
On Friday 22 January 2010 20:36:32 Richard Röjfors wrote:
> Hans Verkuil wrote:
> > On Friday 22 January 2010 13:38:28 Richard Röjfors wrote:
> >> This patch add supports for the radio system on the Intel Russellville
> >> board.
> >>
> >> It's a In-Vehicle Infotainment board with a radio tuner and DSP.
> >>
> >> This umbrella driver has the DSP and tuner as V4L2 subdevs and calls them
> >> when needed.
> >>
> >> The RDS support is done by I/O memory accesses.
> >
> > I gather from this source that you weren't aware of the RDS interface
> > specification:
> >
> > http://www.linuxtv.org/downloads/v4l-dvb-apis/ch04s11.html
> >
> > Please use the V4L2_CAP_RDS_CAPTURE capability in querycap and use the
> > struct v4l2_rds_data when reading the RDS data. Let us know if you run into
> > problems doing this. This API was only formalized in 2.6.32 (although based
> > on previous implementations), so it is pretty recent.
>
> Thanks, I'll look into this. I like the idea of harmonising the RDS API. The
> driver is actually
> older than 2.6.32 so I wasn't aware of it.
>
> >
> > Some more comments below.
> >
> >> Signed-off-by: Richard Röjfors
> >> ---
> >> diff --git a/drivers/media/radio/radio-timb.c
> >> b/drivers/media/radio/radio-timb.c
> >> new file mode 100644
> >> index 000..3dbe9ad
> >> --- /dev/null
> >> +++ b/drivers/media/radio/radio-timb.c
> >> @@ -0,0 +1,543 @@
> >> +/*
> >> + * radio-timb.c Timberdale FPGA Radio driver
> >> + * Copyright (c) 2009 Intel Corporation
> >> + *
> >> + * This program is free software; you can redistribute it and/or modify
> >> + * it under the terms of the GNU General Public License version 2 as
> >> + * published by the Free Software Foundation.
> >> + *
> >> + * This program is distributed in the hope that it will be useful,
> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> >> + * GNU General Public License for more details.
> >> + *
> >> + * You should have received a copy of the GNU General Public License
> >> + * along with this program; if not, write to the Free Software
> >> + * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
> >> + */
> >> +
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +#include
> >> +
> >> +#define DRIVER_NAME "timb-radio"
> >> +
> >> +#define RDS_BLOCK_SIZE 4
> >> +#define RDS_BUFFER_SIZE (RDS_BLOCK_SIZE * 100)
> >> +
> >> +struct timbradio {
> >> + struct mutexlock; /* for mutual exclusion */
> >> + void __iomem*membase;
> >> + struct timb_radio_platform_data pdata;
> >> + struct v4l2_subdev *sd_tuner;
> >> + struct module *tuner_owner;
> >> + struct v4l2_subdev *sd_dsp;
> >> + struct module *dsp_owner;
> >> + struct video_device *video_dev;
> >> + /* RDS related */
> >> + int open_count;
> >> + int rds_irq;
> >> + wait_queue_head_t read_queue;
> >> + unsigned char buffer[RDS_BUFFER_SIZE];
> >> + unsigned int rd_index;
> >> + unsigned int wr_index;
> >> +};
> >> +
> >> +
> >> +static int timbradio_vidioc_querycap(struct file *file, void *priv,
> >> + struct v4l2_capability *v)
> >> +{
> >> + strlcpy(v->driver, DRIVER_NAME, sizeof(v->driver));
> >> + strlcpy(v->card, "Timberdale Radio", sizeof(v->card));
> >> + snprintf(v->bus_info, sizeof(v->bus_info), "platform:"DRIVER_NAME);
> >> + v->version = KERNEL_VERSION(0, 0, 1);
> >> + v->capabilities = V4L2_CAP_TUNER | V4L2_CAP_RADIO;
> >> + return 0;
> >> +}
> >> +
> >> +static int timbradio_vidioc_g_tuner(struct file *file, void *priv,
> >> + struct v4l2_tuner *v)
> >> +{
> >> + struct timbradio *tr = video_drvdata(file);
> >> + int ret;
> >> +
> >> + mutex_lock(&tr->lock);
> >> + ret = v4l2_subdev_call(tr->sd_tuner, tuner, g_tuner, v);
> >> + mutex_unlock(&tr->lock);
> >
> > I'm not sure whether it is appropriate (or even needed!) to do the locking
> > here.
> > Perhaps it is better to do the locking in the tuner driver? This is just an
> > idea. I do not have the datasheets, so I don't know what is reasonable here.
> >
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +static int timbradio_vidioc_s_tuner(struct file *file, void *priv,
> >> + struct v4l2_tuner *v)
> >> +{
> >> + struct timbradio *tr = video_drvdata(file);
> >> + int ret;
> >> +
> >> + mutex_lock(&tr->lock);
> >> + ret = v4l2_subdev_call(tr->sd_tuner, tuner, s_tuner, v);
> >> + mutex_unlock(&tr->lock);
> >> +
> >> + return ret;
> >> +}
> >> +
> >> +static int timbradio_vidioc_g_input(struct file *filp, void *priv,
> >> + unsigned int *i)
> >> +{
> >> + *i = 0;
> >> + return 0;
> >> +}
> >> +
> >> +static int timbradio_vidioc_s_input(struct file *filp, void *priv,
> >> + unsigned int i)
> >> +{
> >> + return i ? -EINVAL : 0;
> >> +}
> >> +
> >> +static int timbrad
RE: help: Leadtek DTV2000 DS
> >> Date: Wed, 27 Jan 2010 02:21:32 +0200 >> From: cr...@iki.fi >> To: gavin_r...@hotmail.com >> CC: linux-media@vger.kernel.org >> Subject: Re: help: Leadtek DTV2000 DS >> >> Terve Gavin, >> >> On 01/25/2010 01:44 PM, Gavin Ramm wrote: >>> Tried the current build of v4l-dvb (as of 25/01/2010) for a Leadtek >>> DTV2000 DS. >>> product site : >>> http://www.leadtek.com/eng/tv_tuner/overview.asp?lineid=6&pronameid=530&check=f >>> >>> The chipset are AF9015 + AF9013 and the tuner is TDA18211.. >>> Im running it on mythdora 10.21 *fedora 10* i've had no luck with this. >>> >>> Any help would be great.. im willing to test.. >> >> I added support for that device, could you test now? >> http://linuxtv.org/hg/~anttip/af9015/ >> >>> >>> >>> I created a channels.conf via the output tried in xine and it worked.. >>> tried in mythtv and it picked a few up only by importing the channels.conf. >>> The auto scan in mythtv didn't work (which is out of scope i'd say) >>> _ >> >> >> The card is up and running within mythtv also, forgot i rebuilt the box and >> didn't change it back to Australian freq... >> >> thanks alot for the help!! >> >> gav >> _ > > celebrated too soon! > > the adpater0 works but all the other adapters1/2/3 do not find anything. > > I've ran the identical "scan -a 1 /usr/share/dvb/dvb-t/au-Bendigo" on them > all and only the first one works.. > > I've changed the physical arial cables also, this didn't help.. > > I have 2x of the cards installed. > > -gav > _ Ok first up sorry for the "spamming" of message.. I took an old card out that was also in the box.. rebooted my pc and now it looks like they're all working.. Tried via "scan -a 0 /usr/share/dvb/dvb-t/au-Bendigo" for 0 1 2 and 3 and they all got channels. then tried on my mythfrontend and i could view channels on all adapters.. -gav _ Search for properties that match your lifestyle! Start searching NOW! http://clk.atdmt.com/NMN/go/157631292/direct/01/-- 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: saa7134 and üPD61151 MPEG2 coder
Hi Dmitri,
Just a quick note: the video4linux mailinglist is obsolete, just use
linux-media.
On Wednesday 27 January 2010 06:36:37 Dmitri Belimov wrote:
> Hi Hans.
>
> I finished saa7134 part of SPI. Please review saa7134-spi.c and diff
> saa7134-core and etc.
> I wrote config of SPI to board structure. Use this config for register master
> and slave devices.
>
> SPI other then I2C, do not need call request_module. Udev do it.
> I spend 10 days for understanding :(
I'm almost certain that spi works the same way as i2c and that means that you
must call request_module. Yes, udev will load it for you, but that is a delayed
load: i.e. the module may not be loaded when we need it. The idea behind this
is that usually i2c or spi modules are standalone, but in the context of v4l
such modules are required to be present before the bridge can properly configure
itself.
The easiest way to ensure the correct load sequence is to do a request_module
at the start.
Now, I haven't compiled this, but I think this will work:
struct v4l2_subdev *v4l2_spi_new_subdev(struct v4l2_device *v4l2_dev,
struct spi_master *master, struct spi_board_info *info)
{
struct v4l2_subdev *sd = NULL;
struct spi_device *spi;
BUG_ON(!v4l2_dev);
if (module_name)
request_module(module_name);
spi = spi_new_device(master, info);
if (spi == NULL || spi->dev.driver == NULL)
goto error;
if (!try_module_get(spi->dev.driver->owner))
goto error;
sd = spi_get_drvdata(spi);
/* Register with the v4l2_device which increases the module's
use count as well. */
if (v4l2_device_register_subdev(v4l2_dev, sd))
sd = NULL;
/* Decrease the module use count to match the first try_module_get. */
module_put(spi->dev.driver->owner);
error:
/* If we have a client but no subdev, then something went wrong and
we must unregister the client. */
if (spi && sd == NULL)
spi_unregister_device(spi);
return sd;
}
EXPORT_SYMBOL_GPL(v4l2_spi_new_subdev);
Note that you mixed up the spi master and spi client in your original code. So
it is no wonder you experienced crashes.
Also note that there is no need for a separate v4l2_spi_new_subdev_board
function.
And in v4l2_spi_subdev_init() you should use spi_set_drvdata instead of
dev_set_drvdata.
I hope this helps.
Regards,
Hans
>
> I need help with v4l2-common.c -> function v4l2_spi_new_subdev_board
> The module of SPI slave loading after some time and spi device hasn't
> v4l2_subdev structure
> for v4l2_device_register_subdev.
>
> Now I get kernel crash when call v4l2_device_register_subdev.
>
> Need use a callback metod or other. I don't know.
>
> Copy to Mauro Carvalho Chehab and mailing lists for review my code too.
>
> Dmesg log without call v4l2_device_register_subdev.
> [4.742279] Linux video capture interface: v2.00
> [4.816171] saa7130/34: v4l2 driver version 0.2.15 loaded
> [4.816253] saa7134 :04:01.0: PCI INT A -> GSI 19 (level, low) -> IRQ
> 19
> [4.816304] saa7133[0]: found at :04:01.0, rev: 209, irq: 19, latency:
> 32, mmio: 0xe510
> [4.816363] saa7133[0]: subsystem: 5ace:7595, board: Beholder BeholdTV X7
> [card=171,autodetected]
> [4.816430] saa7133[0]: board init: gpio is 20
> [4.816481] IRQ 19/saa7133[0]: IRQF_DISABLED is not guaranteed on shared
> IRQs
> [4.976010] saa7133[0]: i2c eeprom 00: ce 5a 95 75 54 20 00 00 00 00 00 00
> 00 00 00 01
> [4.976635] saa7133[0]: i2c eeprom 10: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.977231] saa7133[0]: i2c eeprom 20: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.977827] saa7133[0]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.978423] saa7133[0]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.979019] saa7133[0]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.979615] saa7133[0]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.980223] saa7133[0]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.980820] saa7133[0]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.981416] saa7133[0]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.982012] saa7133[0]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.982608] saa7133[0]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.983204] saa7133[0]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.983800] saa7133[0]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.984437] saa7133[0]: i2c eeprom e0: 00 00 00 00 ff ff ff ff ff ff ff ff
> ff ff ff ff
> [4.985033] saa7133[0]: i2c eeprom f0: 42 54 56
RE: help: Leadtek DTV2000 DS
> Date: Wed, 27 Jan 2010 02:21:32 +0200 > From: cr...@iki.fi > To: gavin_r...@hotmail.com > CC: linux-media@vger.kernel.org > Subject: Re: help: Leadtek DTV2000 DS > > Terve Gavin, > > On 01/25/2010 01:44 PM, Gavin Ramm wrote: >> Tried the current build of v4l-dvb (as of 25/01/2010) for a Leadtek >> DTV2000 DS. >> product site : >> http://www.leadtek.com/eng/tv_tuner/overview.asp?lineid=6&pronameid=530&check=f >> >> The chipset are AF9015 + AF9013 and the tuner is TDA18211.. >> Im running it on mythdora 10.21 *fedora 10* i've had no luck with this. >> >> Any help would be great.. im willing to test.. > > I added support for that device, could you test now? > http://linuxtv.org/hg/~anttip/af9015/ > >> >> >> I created a channels.conf via the output tried in xine and it worked.. tried >> in mythtv and it picked a few up only by importing the channels.conf. The >> auto scan in mythtv didn't work (which is out of scope i'd say) >> _ > > > The card is up and running within mythtv also, forgot i rebuilt the box and > didn't change it back to Australian freq... > > thanks alot for the help!! > > gav > _ celebrated too soon! the adpater0 works but all the other adapters1/2/3 do not find anything. I've ran the identical "scan -a 1 /usr/share/dvb/dvb-t/au-Bendigo" on them all and only the first one works.. I've changed the physical arial cables also, this didn't help.. I have 2x of the cards installed. -gav _ Time for a new car? Sell your old one fast! http://clk.atdmt.com/NMN/go/157637060/direct/01/-- 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] saa7134: Fix IR support of some ASUS TV-FM 7135 variants
From: Jean Delvare
Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants
Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131
Analog (card=146). However, by the time we find out, some
card-specific initialization is missed. In particular, the fact that
the IR is GPIO-based. Set it when we change the card type.
We also have to move the initialization of IR until after the card
number has been changed. I hope that this won't cause any problem.
Signed-off-by: Jean Delvare
Cc: Daro
Cc: Roman Kellner
---
This needs testing, both from ASUS TV-FM 7135 users, and from other
users of the saa7134 driver. I don't have any supported device so I
couldn't test this change.
linux/drivers/media/video/saa7134/saa7134-cards.c |1 +
linux/drivers/media/video/saa7134/saa7134-core.c |2 +-
linux/drivers/media/video/saa7134/saa7134-input.c |2 +-
linux/drivers/media/video/saa7134/saa7134.h |2 +-
4 files changed, 4 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c
2010-01-25 21:25:58.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c 2010-01-27
10:22:35.0 +0100
@@ -7299,6 +7299,7 @@ int saa7134_board_init2(struct saa7134_d
printk(KERN_INFO "%s: P7131 analog only, using "
"entry of %s\n",
dev->name, saa7134_boards[dev->board].name);
+ dev->has_remote = SAA7134_REMOTE_GPIO;
}
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1150:
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-core.c
2010-01-25 21:25:50.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-core.c2010-01-27
10:39:55.0 +0100
@@ -735,7 +735,6 @@ static int saa7134_hwinit1(struct saa713
saa7134_vbi_init1(dev);
if (card_has_mpeg(dev))
saa7134_ts_init1(dev);
- saa7134_input_init1(dev);
saa7134_hw_enable1(dev);
@@ -781,6 +780,7 @@ static int saa7134_hwinit2(struct saa713
dprintk("hwinit2\n");
+ saa7134_input_init2(dev);
saa7134_video_init2(dev);
saa7134_tvaudio_init2(dev);
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2010-01-25 21:25:50.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2010-01-27
10:33:23.0 +0100
@@ -506,7 +506,7 @@ void saa7134_ir_stop(struct saa7134_dev
del_timer_sync(&dev->remote->timer);
}
-int saa7134_input_init1(struct saa7134_dev *dev)
+int saa7134_input_init2(struct saa7134_dev *dev)
{
struct card_ir *ir;
struct input_dev *input_dev;
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134.h2010-01-25
21:25:50.0 +0100
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134.h 2010-01-27
10:34:57.0 +0100
@@ -812,7 +812,7 @@ void saa7134_irq_oss_done(struct saa7134
/* --- */
/* saa7134-input.c */
-int saa7134_input_init1(struct saa7134_dev *dev);
+int saa7134_input_init2(struct saa7134_dev *dev);
void saa7134_input_fini(struct saa7134_dev *dev);
void saa7134_input_irq(struct saa7134_dev *dev);
#if LINUX_VERSION_CODE < KERNEL_VERSION(2, 6, 30)
--
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: help: Leadtek DTV2000 DS
>>> >>> >>> Date: Wed, 27 Jan 2010 02:21:32 +0200 From: cr...@iki.fi To: gavin_r...@hotmail.com CC: linux-media@vger.kernel.org Subject: Re: help: Leadtek DTV2000 DS Terve Gavin, On 01/25/2010 01:44 PM, Gavin Ramm wrote: > Tried the current build of v4l-dvb (as of 25/01/2010) for a Leadtek > DTV2000 DS. > product site : > http://www.leadtek.com/eng/tv_tuner/overview.asp?lineid=6&pronameid=530&check=f > > The chipset are AF9015 + AF9013 and the tuner is TDA18211.. > Im running it on mythdora 10.21 *fedora 10* i've had no luck with this. > > Any help would be great.. im willing to test.. I added support for that device, could you test now? http://linuxtv.org/hg/~anttip/af9015/ > > > I created a channels.conf via the output tried in xine and it worked.. tried > in mythtv and it picked a few up only by importing the channels.conf. The > auto scan in mythtv didn't work (which is out of scope i'd say) > _ The card is up and running within mythtv also, forgot i rebuilt the box and didn't change it back to Australian freq... thanks alot for the help!! gav _ Time for a new car? Sell your old one fast! http://clk.atdmt.com/NMN/go/157637060/direct/01/-- 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: problem with libdvben50221 and powercam pro V4 [almost solved]
pierre.gronlier wrote: > pierre gronlier wrote, On 01/24/2010 11:03 PM: >> DUBOST Brice crans.ens-cachan.fr> writes: >>> Manu Abraham a écrit : Hi Brice, On Mon, Jan 25, 2010 at 12:09 AM, DUBOST Brice crans.ens-cachan.fr> wrote: > Hello > > Powercam just made a new version of their cam, the version 4 > > Unfortunately this CAM doesn't work with gnutv and applications based on > libdvben50221 > > This cam return TIMEOUT errors (en50221_stdcam_llci_poll: Error reported > by stack:-3) after showing the supported ressource id. > > The problem is that this camreturns two times the list of supported ids > (as shown in the log) this behavior make the llci_lookup_callback > (en50221_stdcam_llci.c line 338) failing to give the good ressource_id > at the second call because there is already a session number (in the > test app the session number is not tested) > > I solved the problem commenting out the test for the session number as > showed in the joined patch (against the latest dvb-apps, cloned today) >> I will run some tests with a TT3200 card too and a Netup card tomorrow. >> >> Regarding the cam returning two times the list of valid cam ids, wouldn't be >> better if the manufacturer corrects it in the cam firmware ? >> What says the en50221 norm about it ? >> > > Indeed, with the patch applied, the command gnutv -adapter 0 -cammenu is > working fine with a netup card too. > > I will try to update to the last revision of pcam firmware (v4.2) and > report this behaviour to the manufacturer. > Hello, a bit more information on this issue Just for information, Here I attach you the log of another test I did, the CAM answers the list of available Ids several times (each time you change it basically) on the same session. Manu : the test in the libdvben50221 was intended to deal with which case ? I notice also that the decoding can fail if the PMT_ASK is sent between the two ca_list answer at the beginning (this is a bit boring). Regards -- Brice Found a CAM on adapter1... waiting... en50221_tl_register_slot slotid: 0 tcid: 1 Press a key to enter menu 00:Host originated transport connection 1 connected 00:Public resource lookup callback 1 1 1 00:CAM connecting to resource 00010041, session_number 1 00:CAM successfully connected to resource 00010041, session_number 1 00:test_rm_reply_callback 00:test_rm_enq_callback 00:Public resource lookup callback 2 1 1 00:CAM connecting to resource 00020041, session_number 2 00:CAM successfully connected to resource 00020041, session_number 2 00:test_ai_callback Application type: 01 Application manufacturer: 02ca Manufacturer code: 3000 Menu string: PCAM V4.1 00:Public resource lookup callback 3 1 1 00:CAM connecting to resource 00030041, session_number 3 00:CAM successfully connected to resource 00030041, session_number 3 00:test_ca_info_callback Supported CA ID: 0500 00:Connection to resource 00030041, session_number 3 closed 00:Public resource lookup callback 3 1 1 00:CAM connecting to resource 00030041, session_number 3 00:CAM successfully connected to resource 00030041, session_number 3 00:test_ca_info_callback Supported CA ID: 0500 00:Public resource lookup callback 64 1 1 00:CAM connecting to resource 00400041, session_number 4 00:CAM successfully connected to resource 00400041, session_number 4 00:test_mmi_display_control_callback cmd_id: 01 mode: 01 00:test_mmi_menu_callback title: PCAM V4.1 sub_title: Select a language bottom: item 1: English item 2: French item 3: Spanish item 4: German item 5: Russian item 6: Arabic A item 7: Arabic B raw_length: 0 1 00:test_mmi_menu_callback title: PCAM V4.1 sub_title: Main Menu bottom: Select one and press 'OK' to continue item 1: SmartCard & PIN item 2: CAS item 3: VP: 21680 item 4: Download Status raw_length: 0 2 00:test_mmi_menu_callback title: PCAM V4.1 sub_title: Currently selected CAS: bottom: Please select 'Yes' or 'No' and press 'OK' to continue item 1: Do you want to change it? item 2: No item 3: Yes raw_length: 0 3 00:test_mmi_menu_callback title: PCAM V4.1 sub_title: Currently selected CAS: bottom: Please select an option and press 'OK' to continue item 1: ALL item 2: Embedded Channels & PIN [OFF] item 3: MOSAIC-S [OFF] item 4: MOSAIC-V [ON] item 5: MOSAIC-I [OFF] item 6: MOSAIC-B [OFF] item 7: MOSAIC-C [OFF] item 8: MOSAIC-X [OFF] item 9: KEYFLY [OFF] raw_length: 0 3 00:test_mmi_menu_callback title: PCAM V4.1 sub_title: Currently selected CAS: bottom: Please select an option and press 'OK' to continue item 1: ALL item 2: Embedded Channels & PIN [OFF] item 3: MOSAIC-S [ON] item 4: MOSAIC-V [ON] item 5: MOSAIC-I [OFF] item 6: MOSAIC-B [OFF] item 7: MOSAIC-C [OFF] item 8: MOSAIC-X [OFF] item 9: KEYFLY [OFF] raw_length: 0 00:Connection to resource 00030041, session_number 3 closed 00:Public resource
Re: IR device at I2C address 0x7a
Hi Hermann, Sorry for the late answer. On Sun, 10 Jan 2010 22:55:05 +0100, hermann pitton wrote: > Am Sonntag, den 10.01.2010, 09:51 +0100 schrieb Jean Delvare: > > On Sun, 10 Jan 2010 00:18:46 +0100, hermann pitton wrote: > > > Am Samstag, den 09.01.2010, 17:14 +0100 schrieb Jean Delvare: > > > > Then I would suggest the following patch: > > > > > > > > * * * * * > > > > > > > > From: Jean Delvare > > > > Subject: saa7134: Fix IR support of some ASUS TV-FM 7135 variants > > > > > > > > Some variants of the ASUS TV-FM 7135 are handled as the ASUSTeK P7131 > > > > Analog (card=146). However, by the time we find out, some > > > > card-specific initialization is missed. In particular, the fact that > > > > the IR is GPIO-based. Set it when we change the card type. > > > > > > > > Signed-off-by: Jean Delvare > > > > Tested-by: Daro > > > > > > just to note it, the ASUS TV-FM 7135 with USB remote is different to the > > > Asus My Cinema P7134 Analog only, not only for the remote, but also for > > > inputs, but they have the same PCI subsystem. > > > > > > > --- > > > > linux/drivers/media/video/saa7134/saa7134-cards.c |1 + > > > > 1 file changed, 1 insertion(+) > > > > > > > > --- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-cards.c > > > > 2009-12-11 09:47:47.0 +0100 > > > > +++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-cards.c > > > > 2010-01-09 16:23:17.0 +0100 > > > > @@ -7257,6 +7257,7 @@ int saa7134_board_init2(struct saa7134_d > > > >printk(KERN_INFO "%s: P7131 analog only, using " > > > >"entry of %s\n", > > > >dev->name, saa7134_boards[dev->board].name); > > > > + dev->has_remote = SAA7134_REMOTE_GPIO; > > > >} > > > >break; > > > > case SAA7134_BOARD_HAUPPAUGE_HVR1150: > > > > > > > > > > > > * * * * * > > > > > > Must have been broken at that time, IIRC. > > > > What must have been broken, and when? You are confusing. > > Sorry, I missed that thread until now. > The above patch was tried previously by Roman. > > For the record, here is a link. > http://www.spinics.net/lists/vfl/msg38869.html Thanks for the pointer, this was very helpful. I had missed the fact that the call to saa7134_input_init1() was before the card number change. So indeed my patch was insufficient. Roman's strategy to move saa7134_input_init1() to the late init section seems good to me. Honestly, I can't think of a good reason to init the remote control early. I doubt that anything else depends on that. I'll send an updated patch shortly. -- 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
