Re: [PATCH v2 1/7] v4l2: video device: Add V4L2_CTRL_CLASS_FMTX controls
On Tue, May 12, 2009 at 12:29:54PM +0200, ext Mauro Carvalho Chehab wrote: Em Tue, 12 May 2009 08:26:40 +0200 Hans Verkuil hverk...@xs4all.nl escreveu: The only reason why such a table might end up in the kernel is if there are legal requirements forcing strict control on what is allowed for an FM transmitter in each country, and in that case a similar mechanism as is used for wifi should be used. I know we discussed this earlier, but I've forgotten the exact name of that API. If the usage of FM transmission is for very short range transmissions (for example, to listen to a phone call inside your car stereo, or to listen to your baby's room noises or to see him while you're in the kitchen), I doubt that there are any legal requirements. Such usage is called by the regulatory agencies as secondary usage[1]. The secondary usage for FM and for their adjacent frequencies (the TV range) should allow such domestic usage [2]. In general, the restriction for secondary usage is just the power level, to avoid interferences with the primary usage. In general, the secondary usage for TV and FM ranges are the same (and both ranges are adjacent). On the other hand, for FM primary usage, e. g. a FM broadcaster, the restriction is that you should transmit _ONLY_ at the authorized frequency, at the specified maximum power (that may have a different max power during the day or during the night), using strict shapes for frequency shift, and for modulation levels. It also restricts the location of the FM station, and the characteristics of the antenna beams. Such constraints require application, infrastructure and hardware control that couldn't be done at kernel level. So, I don't see how legal issues might affect this driver. [1] Maybe the specific term may change from country to country, but the idea remains the same, since this concept exists on ITU-R regulations. [2] I'm not aware of any country that forbids the usage of FM/TV ranges for domestic usage. Yet, if such country does exist, then the usage of this module should be forbidden at such country, no matter what frequency you're generating. So, again, it seems pointless to add such restriction in kernel. Right. I've to agree that there is no need to have those in kernel. Better to leave this role to user land, if some legal requirement is needed then. I'll resend the patches without the region settings. It will export only the device limits. I believe that user land can, on top of that, handle the channel spacing and frequency limits. Of course, leaving a way to set/get the preemphasis will be kept. But not bound to a region setting anymore. Cheers, Mauro Cheers, -- Eduardo Valentin -- 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 0/7] [RFC] FM Transmitter (si4713) and another changes
On Tue, May 12, 2009 at 09:55:19AM +0200, Valentin Eduardo (Nokia-D/Helsinki) wrote: What sort of platform data do you need to pass to the i2c driver? I have yet to see a valid use case for this that can't be handled in a different way. Remember that devices like this are not limited to fixed platforms, but can also be used in USB or PCI devices. Yes, sure. Well, a simple set_power procedure is an example of things that I see as platform specific. Which may be passed by platform data structures. In some platform a set power / reset line may be done by a simple gpio. but in others it may be a different procedure. The v4l2_device struct has a notify callback: you can use that one instead. That way the subdev driver doesn't have to have any knowledge about the platform it is used in. Right. I see. But in that case the brigde driver would be bound to a board specific? For instance of this very driver, I wrote a platform driver just to make its radio interface. But I don't think it is a good idea to bound the platform driver to a board specific creating a notification handler just to set the power of the i2c chip. I see this procedure as a board specific thing. As well as the IRQ line for instance. That configuration is also board specific. Which is usually passed using i2c board info. Correct me if I'm wrong. Even though I still can pass board specific to the platform driver using its platform data and then use the notify callback of v4l2_device, I still will miss the configuration for IRQ line. I don't see how to pass that to the i2c subdev by using the current helper functions. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- Eduardo Valentin -- Eduardo Valentin -- 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
Fw: tua6100_sleep: i2c error when trying to tune saa7146 based DVB card
Begin forwarded message: Date: Tue, 12 May 2009 09:42:35 +0200 From: Marc Haber mh+linux-ker...@zugschlus.de To: linux-ker...@vger.kernel.org Subject: tua6100_sleep: i2c error when trying to tune saa7146 based DVB card Recently, my entertainment PC has begun to refuse tuning to my favorite stations, logging tua6100_sleep: i2c error when I try to do so. Kaffeine says can't tune DVB. Other stations work just fine. The box has a saa7146 equipped budget DVB-S card which used to work fine previously. I have first seen this behavior in kernel 2.6.29, and still see it in 2.6.29.3. If you need any more data, please ask and I'll try to deliver it. Greetings Marc -- - Marc Haber | I don't trust Computers. They | Mailadresse im Header Mannheim, Germany | lose things.Winona Ryder | Fon: *49 621 72739834 Nordisch by Nature | How to make an American Quilt | Fax: *49 3221 2323190 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
On Wed, 13 May 2009, Oliver Endriss wrote: 02/05: dvb-ttpci: Check transport error indicator flag http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8a742338523d Are you sure this is a good idea? The cx88 driver doesn't do this. -- 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
OpenSuse 11.1 + v4l
Hi, i tried to build v4l and did tho following: pe...@linux-d9lb:~ hg clone http://linuxtv.org/hg/v4l-dvb destination directory: v4l-dvb requesting all changes adding changesets adding manifests adding file changes added 11759 changesets with 29793 changes to 2019 files updating working directory 1448 files updated, 0 files merged, 0 files removed, 0 files unresolved pe...@linux-d9lb:~ hg clone http://linuxtv.org/hg/dvb-apps destination directory: dvb-apps requesting all changes adding changesets adding manifests adding file changes added 1275 changesets with 5390 changes to 1814 files updating working directory 1315 files updated, 0 files merged, 0 files removed, 0 files unresolved pe...@linux-d9lb:~ cd v4l-dvb pe...@linux-d9lb:~/v4l-dvb hg pull -u http://linuxtv.org/hg/v4l-dvb pulling from http://linuxtv.org/hg/v4l-dvb searching for changes no changes found Doing 'make' make make -C /home/peter/v4l-dvb/v4l make[1]: Entering directory `/home/peter/v4l-dvb/v4l' No version yet, using 2.6.27.7-9-pae make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make[1]: Entering directory `/home/peter/v4l-dvb/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.27 File not found: /lib/modules/2.6.27.7-9-pae/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make[1]: Entering directory `/home/peter/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.27 File not found: /lib/modules/2.6.27.7-9-pae/build/.config at ./scripts/make_kconfig.pl line 32, IN line 4. make[1]: *** Keine Regel vorhanden, um das Target ».myconfig«, benötigt von »config-compat.h«, zu erstellen. Schluss. make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make: *** [all] Fehler 2 pe...@linux-d9lb:~/v4l-dvb Any idea's about that. Thanks Peter -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a -- 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
TT-C 1501 and the kernel 64 bit
I have TT-C 1501 DVB card. it work fine under kernel 2.6.26 (32bit). but when I use the same kernel but 64bit then I got very bad receiving. picture and tone are not to identifing. Is it a driver problem? I use the latest v4l HG. -Amir -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://linuxtv.org/hg/~mcisely/pvrusb2-dev
Em Tue, 12 May 2009 01:36:17 -0500 (CDT) Mike Isely is...@isely.net escreveu: On Mon, 11 May 2009, Mauro Carvalho Chehab wrote: Em Mon, 11 May 2009 22:09:26 -0300 Mauro Carvalho Chehab mche...@infradead.org escreveu: Em Sat, 9 May 2009 16:49:31 -0500 (CDT) Mike Isely is...@isely.net escreveu: Mauro: Please pull from http://linuxtv.org/hg/~mcisely/pvrusb2-dev for various pvrusb2 changesets. Several have to do with IR as previously discussed with Jean Delvare. He's waiting for these changes. Other stuff is more of a miscellaneous / cleanup nature. Hmm... this one failed when importing on -git: Changeset: 11749 From: Greg Kroah-Hartman gre...@suse.de Commiter: Mike Isely is...@pobox.com Date: Fri May 01 22:36:33 2009 -0500 Subject: pvrusb2: remove driver_data direct access of struct device In the near future, the driver core is going to not allow direct access to the driver_data pointer in struct device. Instead, the functions dev_get_drvdata() and dev_set_drvdata() should be used. These functions have been around since the beginning, so are backwards compatible with all older kernel versions. Priority: normal Cc: Mauro Carvalho Chehab mche...@infradead.org Cc: linux-media@vger.kernel.org $ patch -p1 -i 11749.patch patching file drivers/media/video/pvrusb2/pvrusb2-sysfs.c Reversed (or previously applied) patch detected! Assume -R? [n] It seems that you've got a Greg's patch, removed the parts that touch on other files, applied on your tree and asked me to merge it. Please, never do it, since this will cause merge problems when exporting the patches to git. Next time, just reply with an acked-by, and let Patchwork to add your ack on the original patch. I in fact did what you are asking for here (i.e. wait for it to show up on its own) before for another change that got rid of usb_settoggle(). It took a LONG time - WEEKS - for that fix to get back into v4l-dvb via the mechanism you just described. And this had the effect of breaking the v4l-dvb repository for a period of time when the kernel mainline then unpublished the usb_settoggle() function. I do NOT like to see that happen. That caused me to decide not to rely on what you are now telling me to do. I also disagree with this for another reason. What happens if, say, Greg generates a patch that I need before I can proceed with other changes? Do I just sit around and wait for it to trickle back before I can continue? That seems wrong. In addition in the past when there have been pvrusb2 changes generated from upstream you have asked if I was planning on pulling them in myself - which I've done in the past. It seems wrong on its face to tell me that I can't go get a patch that affects my driver. AND... In the case of the remove usb_settoggle() patch, I *DID* in fact add my acked-by to that patch. Greg dutifully took note of this and ensured it was part of the git patch. However when it got back into v4l-dvb, the acked-by attribution was missing. I complained about this to you and your response was that this was a fault of the pathway / mechanism and that I should basically accept this. So now you're telling me to do this anyway? Mike, As I've explained you in priv, and already talked several times at the ML, our entire mechanism of using -hg is broken, for several reasons. We should really move to -git. My intention were to start discussing it just after the end of the last merging cycle, but, unfortunately, I haven't enough time to finish some scripts to allow people to use a git sub-tree. What are the main problems with -hg and with our current merging proccess? 1) The way we work don't allow us to have the full Signed-off-by/Acked-by historic on -hg. For example, all patches submitted upstream should have the maintainers Signed-off-by (SOB). However, by doing hg pull, I can't add my SOB. If, on the other hand, I just cherry pick all patches from your tree and add my SOB, you'll need to drop your tree and clone again from mine, since the patches they will be understood by hg as a different patch. This means also that, if you have a second tree that has your patches, plus some newer patches, that you'll have to cherry-pick the newer patches on that tree, drop it and re-create [1]; 2) We have several extra efforts when picking a patch that are upstream and merge it back on our tree. This requires me to do a diff between our tree (with all backport symbols stripped) and -git, and manually seeking for each diff line on -git, in order to identify what -git patch added such line. Then, for each -git patch, I need to cherry-pick the patch and apply on our tree. On most cases, the patch doesn't apply cleanly, so I need to manually apply it. Also, in general, those patches are generally KABI changes, so they touch not only on the files at our tree, but also on
Re: [PATCH] FM1216ME_MK3 some changes
Hi 1. AGC TOP of RF part - I think need support for MK3 2. Changing to 441MHz is not critical. We can write some information about this case to Wiki or docs. for 2.: Discussed to the end if you stay at 441MHz. If you still want to have it in, just send a patch and no more info is needed. (Likely Andy is giving only examples for more difficult cases, sorry.) for 1.: I would like to be absolutely sure, that we are talking about the same tuner. I want to have the exact filters on it at least. I would also say that, if we need to implement AGC TOP control, it would be better to add it at struct v4l2_tuner (VIDIOC_G_TUNER and VIDIOC_S_TUNER), instead of adding it as a control. Good idea. For MK3 need control AGC TOP and TOP of TDA9887 For MK5 need control only TOP of TDA9887 With my best regards, Dmitry. 3.: That is what Andy noted. Following the Philips datasheet for TOP, it should be added for negative modulation, positive modulation and FM accordingly. (2 and 3 are out of discussion) If you still have some sort of Secam fire and can improve it, we must know the tuner you are on exactly. If it is the original Philips, without any such TOP suggestions over the full range in recent datasheets (???), I assume you might have them, I would say you can proceed, if you have shown that you are really still on the same tuner. 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 -- 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: OpenSuse 11.1 + v4l
On 05/13/2009 03:27 AM, Peter Forstmeier wrote: Hi, i tried to build v4l and did tho following: pe...@linux-d9lb:~ hg clone http://linuxtv.org/hg/v4l-dvb destination directory: v4l-dvb requesting all changes adding changesets adding manifests adding file changes added 11759 changesets with 29793 changes to 2019 files updating working directory 1448 files updated, 0 files merged, 0 files removed, 0 files unresolved pe...@linux-d9lb:~ hg clone http://linuxtv.org/hg/dvb-apps destination directory: dvb-apps requesting all changes adding changesets adding manifests adding file changes added 1275 changesets with 5390 changes to 1814 files updating working directory 1315 files updated, 0 files merged, 0 files removed, 0 files unresolved pe...@linux-d9lb:~ cd v4l-dvb pe...@linux-d9lb:~/v4l-dvb hg pull -u http://linuxtv.org/hg/v4l-dvb pulling from http://linuxtv.org/hg/v4l-dvb searching for changes no changes found Doing 'make' make make -C /home/peter/v4l-dvb/v4l make[1]: Entering directory `/home/peter/v4l-dvb/v4l' No version yet, using 2.6.27.7-9-pae make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make[1]: Entering directory `/home/peter/v4l-dvb/v4l' scripts/make_makefile.pl Updating/Creating .config Preparing to compile for kernel version 2.6.27 File not found: /lib/modules/2.6.27.7-9-pae/build/.config at ./scripts/make_kconfig.pl line 32,IN line 4. make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make[1]: Entering directory `/home/peter/v4l-dvb/v4l' Updating/Creating .config Preparing to compile for kernel version 2.6.27 File not found: /lib/modules/2.6.27.7-9-pae/build/.config at ./scripts/make_kconfig.pl line 32,IN line 4. make[1]: *** Keine Regel vorhanden, um das Target ».myconfig«, benötigt von »config-compat.h«, zu erstellen. Schluss. make[1]: Leaving directory `/home/peter/v4l-dvb/v4l' make: *** [all] Fehler 2 pe...@linux-d9lb:~/v4l-dvb Any idea's about that. Thanks Peter I believe you do not have the kernel header files installed. Under OpenSUSE it looks like there isn't a separate package for the kernel headers, so you just need to install the full kernel sources instead (the kernel-source RPM). -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
On Wed, May 13, 2009 at 2:52 AM, Trent Piepho xy...@speakeasy.org wrote: On Wed, 13 May 2009, Oliver Endriss wrote: 02/05: dvb-ttpci: Check transport error indicator flag http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8a742338523d Are you sure this is a good idea? The cx88 driver doesn't do this. -- 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 I agree with Trent on this one - dropping the packet at the hardware level is a bad idea. If the demodulator is incapable of setting the TEI bit (which most do) and you are forced to rely on the TSERR line, then you should be marking the TEI bit and passing the packet on. Dropping the packet at the hardware level is likely to cause confusion for app developers (why am I only getting 60% of the expected packets?) Like I said above though, in most cases I've seen the demod does all the work and there is no need to act on the TSERR line at all. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed, May 13, 2009 at 2:13 AM, kenny wang smartke...@gmail.com wrote: Hi, Devin I found another problem for my WinTV-HVR-950Q, but I am not sure if it's caused by the device driver: my tvtime sometimes (not often) lost all channels and shows a blue window. Switching channel doesn't take the channel back. I have to close tvtime and open it again, then it works normally. Don't know if it's tvtime's problem. Don't remember if the previous version has the same problem (probably does). And I don't know how to debug it or where to view any log of it. Thanks. Hello Kenny, Does the blue screen occur when you switch channels? Or does it occur when you are currently watching a channel? It's possible there is a problem where the tuning command gets screwed up. Can you give me an idea how often it occurs? One time a minute? One time an hour? One time a day? And if you could please send me a dump of dmesg the next time it happens that would help too. I suspect this is not related to the xc5000 changes. It's probably a glitch in the original 950q analog work that just hasn't been noticed yet. Devin -- Devin J. Heitmueller http://www.devinheitmueller.com AIM: devinheitmueller -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
Trent Piepho wrote: On Wed, 13 May 2009, Oliver Endriss wrote: 02/05: dvb-ttpci: Check transport error indicator flag http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8a742338523d Are you sure this is a good idea? The cx88 driver doesn't do this. Of course, for the following reasons: - The av7110 may crash if you feed it with garbage video data. - Garbage will cause chirping sound from the audio decoder. Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
Devin Heitmueller wrote: On Wed, May 13, 2009 at 2:52 AM, Trent Piepho xy...@speakeasy.org wrote: On Wed, 13 May 2009, Oliver Endriss wrote: 02/05: dvb-ttpci: Check transport error indicator flag http://endr...@linuxtv.org/hg/~endriss/v4l-dvb?cmd=changeset;node=8a742338523d Are you sure this is a good idea? The cx88 driver doesn't do this. -- 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 I agree with Trent on this one - dropping the packet at the hardware level is a bad idea. If the demodulator is incapable of setting the TEI bit (which most do) and you are forced to rely on the TSERR line, then you should be marking the TEI bit and passing the packet on. Dropping the packet at the hardware level is likely to cause confusion for app developers (why am I only getting 60% of the expected packets?) What are you talking about? This patch does not have any impact on the reception path (from tuner to application). It just discards bogus data which might crash the av7110 or cause chirping sound during replay. Like I said above though, in most cases I've seen the demod does all the work and there is no need to act on the TSERR line at all. See above. Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PULL] http://endr...@linuxtv.org/hg/~endriss/v4l-dvb
On Wed, May 13, 2009 at 12:29 PM, Oliver Endriss o.endr...@gmx.de wrote: What are you talking about? This patch does not have any impact on the reception path (from tuner to application). It just discards bogus data which might crash the av7110 or cause chirping sound during replay. Like I said above though, in most cases I've seen the demod does all the work and there is no need to act on the TSERR line at all. See above. Oliver Oh, this is a decoder, not a bridge. Nevermind. My bad. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch 1/4] radio-mr800.c: missing mutex include
Hello, On Wed, May 13, 2009 at 12:39 AM, a...@linux-foundation.org wrote: From: Alessio Igor Bogani abog...@texware.it radio-mr800.c uses struct mutex, so while linux/mutex.h seems to be pulled in indirectly by one of the headers it already includes, the right thing is to include it directly. Signed-off-by: Alessio Igor Bogani abog...@texware.it Cc: Mauro Carvalho Chehab mche...@infradead.org Signed-off-by: Andrew Morton a...@linux-foundation.org --- drivers/media/radio/radio-mr800.c | 1 + 1 file changed, 1 insertion(+) diff -puN drivers/media/radio/radio-mr800.c~radio-mr800c-missing-mutex-include drivers/media/radio/radio-mr800.c --- a/drivers/media/radio/radio-mr800.c~radio-mr800c-missing-mutex-include +++ a/drivers/media/radio/radio-mr800.c @@ -64,6 +64,7 @@ #include media/v4l2-ioctl.h #include linux/usb.h #include linux/version.h /* for KERNEL_VERSION MACRO */ +#include linux/mutex.h /* driver and module definitions */ #define DRIVER_AUTHOR Alexey Klimov klimov.li...@gmail.com _ There was discussion about this patch. http://www.mail-archive.com/linux-media@vger.kernel.org/msg03556.html Well, i'm not against this patch. -- Best regards, Klimov Alexey -- 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 May 13 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 11758:8d37e8505664 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-rc4-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-rc4-armv5-ixp: WARNINGS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-rc4-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: ERRORS linux-2.6.25.11-i686: ERRORS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-rc4-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-rc4-m32r: OK linux-2.6.22.19-mips: ERRORS linux-2.6.26-mips: ERRORS linux-2.6.27-mips: ERRORS linux-2.6.28-mips: ERRORS linux-2.6.29.1-mips: ERRORS linux-2.6.30-rc4-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-rc4-powerpc64: WARNINGS linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: ERRORS linux-2.6.25.11-x86_64: ERRORS linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-rc4-x86_64: WARNINGS sparse (linux-2.6.29.1): OK sparse (linux-2.6.30-rc4): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Wednesday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
- Original Message - From: Devin Heitmueller dheitmuel...@kernellabs.com To: Britney Fransen britney.fran...@gmail.com Cc: Devin Heitmueller devin.heitmuel...@gmail.com; Linux Media Mailing List linux-media@vger.kernel.org Sent: Tuesday, May 12, 2009 1:56 PM Subject: Re: XC5000 improvements: call for testers! On Tue, May 12, 2009 at 4:50 PM, Britney Fransen britney.fran...@gmail.com wrote: I finally had some time to do some more testing with the beta2 tree and I think most of the issues I had were user error. Not exactly sure what I did wrong before but I am not seeing the reception issues or any regressions on the digital side anymore. I think why I thought I was seeing QAM64 was because I was using the wrong tuner. With the beta2 tree my 950q is now adapter1, before it was always adapter2. That could be part of what I thought was the reception regression as well. Thanks, Britney Hello Britney, Thank you for taking the time to isolate/debug the situation. The changes should have no effect on the order of adapter1/adapter2. Could have just been a coincidence or the order in which you plugged in the devices compared to what they usually are at boot time. Glad to see that there are no longer any issues. Once I get one outstanding Pinnacle 800i fix in, I will issue a PULL request and this will go into the mainline. Cheers, Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com So when this goes main, next time we update from v4l we need the new firmware right? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed, May 13, 2009 at 3:04 PM, Timothy D. Lenz tl...@vorgon.com wrote: So when this goes main, next time we update from v4l we need the new firmware right? Yes. Now that we have the licensing straightened out, I'll also be working on getting it bundled into the distros so that users don't have to download the firmware themselves. They will get a true plug and play experience. Cheers, 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
[PATCH 0/8] ir-kbd-i2c conversion to the new i2c binding model (v3)
Hi all, Here comes an update of my conversion of ir-kbd-i2c to the new i2c binding model. I've split it into 8 pieces for easier review. Firstly there is 1 preliminary patch: 01-ir-kbd-i2c-dont-abuse-client-name.patch Then 3 patches doing the actual conversion: 02-ir-kbd-i2c-convert-to-new-style.patch 03-configure-ir-receiver.patch 04-ir-kbd-i2c-dont-bind-to-unsupported-devices.patch Then 2 patches cleaning up saa7134-input thanks to the new possibilities offered by the conversion: 05-saa7134-input-cleanup-msi-ir.patch 06-saa7134-input-cleanup-avermedia-cardbus.patch And lastly driver-specific adjustments: 07-ir-add-lirc-addresses.patch 08-pvrusb2-enable-ir_video-by-default.patch This patch set is against the v4l-dvb repository, but I didn't pay attention to the compatibility issues. I simply build-tested it on 2.6.27, 2.6.29 and 2.6.30-rc5. This patch set touches many different drivers and I can't test any of them. My only TV card with an IR receiver doesn't make use of ir-kbd-i2c. So I would warmly welcome testers. The more testing my changes can get, the better. And of course I welcome reviews and comments as well. I had to touch many drivers I don't know anything about so it is possible that I missed something. The main difference with my previous patch set is that it is adjusted to apply after Mike Isely's recent prvusb2 patches. I'll post all 8 patches as replies to this post. They can also be temporarily downloaded from: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ Additionally I've put a combined patch there, to make testing easier: http://jdelvare.pck.nerim.net/linux/ir-kbd-i2c/ir-kbd-i2c-conversion-ALL-IN-ONE.patch But for review the individual patches are much better. Thanks, -- 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
[PATCH 1/8] ir-kbd-i2c: Don't use i2c_client.name for our own needs
In the standard device driver binding model, the name field of
struct i2c_client is used to match devices to their drivers, so we
must stop using it for internal purposes. Define a separate field
in struct IR_i2c as a replacement, and use it.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/cx231xx/cx231xx-input.c |2 +-
linux/drivers/media/video/em28xx/em28xx-cards.c |6 +++---
linux/drivers/media/video/em28xx/em28xx-input.c |2 +-
linux/drivers/media/video/ir-kbd-i2c.c|5 +++--
linux/drivers/media/video/saa7134/saa7134-input.c | 12 ++--
linux/include/media/ir-kbd-i2c.h |1 +
6 files changed, 15 insertions(+), 13 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-input.c
2009-04-24 11:45:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-input.c 2009-04-29
14:30:32.0 +0200
@@ -37,7 +37,7 @@ MODULE_PARM_DESC(ir_debug, enable debug
#define i2cdprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg); \
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
}
#define dprintk(fmt, arg...) \
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-04-24 11:45:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-04-29
14:30:32.0 +0200
@@ -1948,19 +1948,19 @@ void em28xx_set_ir(struct em28xx *dev, s
case (EM2820_BOARD_TERRATEC_CINERGY_250):
ir-ir_codes = ir_codes_em_terratec;
ir-get_key = em28xx_get_key_terratec;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM28XX Terratec));
break;
case (EM2820_BOARD_PINNACLE_USB_2):
ir-ir_codes = ir_codes_pinnacle_grey;
ir-get_key = em28xx_get_key_pinnacle_usb_grey;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM28XX Pinnacle PCTV));
break;
case (EM2820_BOARD_HAUPPAUGE_WINTV_USB_2):
ir-ir_codes = ir_codes_hauppauge_new;
ir-get_key = em28xx_get_key_em_haup;
- snprintf(ir-c.name, sizeof(ir-c.name),
+ snprintf(ir-name, sizeof(ir-name),
i2c IR (EM2840 Hauppauge));
break;
case (EM2820_BOARD_MSI_VOX_USB_2):
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-input.c
2009-04-24 11:45:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-input.c 2009-04-29
14:30:32.0 +0200
@@ -41,7 +41,7 @@ MODULE_PARM_DESC(ir_debug, enable debug
#define i2cdprintk(fmt, arg...) \
if (ir_debug) { \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg); \
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg); \
}
#define dprintk(fmt, arg...) \
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-24
11:45:21.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-29
14:30:32.0 +0200
@@ -346,6 +346,7 @@ static int ir_attach(struct i2c_adapter
ir-c.adapter = adap;
ir-c.addr= addr;
+ snprintf(ir-c.name, sizeof(ir-c.name), ir-kbd);
i2c_set_clientdata(ir-c, ir);
@@ -419,7 +420,7 @@ static int ir_attach(struct i2c_adapter
}
/* Sets name */
- snprintf(ir-c.name, sizeof(ir-c.name), i2c IR (%s), name);
+ snprintf(ir-name, sizeof(ir-name), i2c IR (%s), name);
ir-ir_codes = ir_codes;
/* register i2c device
@@ -444,7 +445,7 @@ static int ir_attach(struct i2c_adapter
/* init + register input device */
ir_input_init(input_dev, ir-ir, ir_type, ir-ir_codes);
input_dev-id.bustype = BUS_I2C;
- input_dev-name = ir-c.name;
+ input_dev-name = ir-name;
input_dev-phys = ir-phys;
err = input_register_device(ir-input);
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-29 14:30:29.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-29
14:30:32.0 +0200
@@ -60,7 +60,7 @@ MODULE_PARM_DESC(disable_other_ir, disa
#define dprintk(fmt, arg...) if (ir_debug) \
printk(KERN_DEBUG %s/ir: fmt, dev-name , ## arg)
#define i2cdprintk(fmt, arg...)if (ir_debug) \
- printk(KERN_DEBUG %s/ir: fmt, ir-c.name , ## arg)
+ printk(KERN_DEBUG %s/ir: fmt, ir-name , ## arg)
/* Helper functions for RC5 and NEC decoding at GPIO16 or GPIO18 */
static int saa7134_rc5_irq(struct saa7134_dev *dev);
@@ -697,7 +697,7 @@ void saa7134_set_i2c_ir(struct saa7134_d
switch (dev-board) {
case SAA7134_BOARD_PINNACLE_PCTV_110i:
case
[PATCH 2/8] ir-kbd-i2c: Switch to the new-style device binding model
Let card drivers probe for IR receiver devices and instantiate them if
found. Ultimately it would be better if we could stop probing
completely, but I suspect this won't be possible for all card types.
There's certainly room for cleanups. For example, some drivers are
sharing I2C adapter IDs, so they also had to share the list of I2C
addresses being probed for an IR receiver. Now that each driver
explicitly says which addresses should be probed, maybe some addresses
can be dropped from some drivers.
Also, the special cases in saa7134-i2c should probably be handled on a
per-board basis. This would be more efficient and less risky than always
probing extra addresses on all boards. I'll give it a try later.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@infradead.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Andy Walls awa...@radix.net
Cc: Mike Isely is...@pobox.com
---
linux/drivers/media/video/bt8xx/bttv-i2c.c| 21 ++
linux/drivers/media/video/cx231xx/cx231xx-cards.c | 11 -
linux/drivers/media/video/cx231xx/cx231xx-i2c.c |3
linux/drivers/media/video/cx231xx/cx231xx.h |1
linux/drivers/media/video/cx23885/cx23885-i2c.c | 12 +
linux/drivers/media/video/cx88/cx88-i2c.c | 13 +
linux/drivers/media/video/em28xx/em28xx-cards.c | 20 +-
linux/drivers/media/video/em28xx/em28xx-i2c.c |3
linux/drivers/media/video/em28xx/em28xx-input.c |6
linux/drivers/media/video/em28xx/em28xx.h |1
linux/drivers/media/video/ir-kbd-i2c.c| 200 +++--
linux/drivers/media/video/ivtv/ivtv-i2c.c | 31 ++-
linux/drivers/media/video/saa7134/saa7134-i2c.c |3
linux/drivers/media/video/saa7134/saa7134-input.c | 86 +++--
linux/drivers/media/video/saa7134/saa7134.h |1
linux/include/media/ir-kbd-i2c.h |2
16 files changed, 220 insertions(+), 194 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-05-12
10:19:13.0 +0200
+++ v4l-dvb/linux/drivers/media/video/bt8xx/bttv-i2c.c 2009-05-12
11:24:19.0 +0200
@@ -405,6 +405,27 @@ int __devinit init_bttv_i2c(struct bttv
}
if (0 == btv-i2c_rc i2c_scan)
do_i2c_scan(btv-c.v4l2_dev.name, btv-i2c_client);
+
+ /* Instantiate the IR receiver device, if present */
+ if (0 == btv-i2c_rc) {
+ struct i2c_board_info info;
+ /* The external IR receiver is at i2c address 0x34 (0x35 for
+ reads). Future Hauppauge cards will have an internal
+ receiver at 0x30 (0x31 for reads). In theory, both can be
+ fitted, and Hauppauge suggest an external overrides an
+ internal.
+
+ That's why we probe 0x1a (~0x34) first. CB
+ */
+ const unsigned short addr_list[] = {
+ 0x1a, 0x18, 0x4b, 0x64, 0x30,
+ I2C_CLIENT_END
+ };
+
+ memset(info, 0, sizeof(struct i2c_board_info));
+ strlcpy(info.type, ir_video, I2C_NAME_SIZE);
+ i2c_new_probed_device(btv-c.i2c_adap, info, addr_list);
+ }
return btv-i2c_rc;
}
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-cards.c
2009-05-12 10:19:13.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-cards.c 2009-05-12
11:24:19.0 +0200
@@ -282,13 +282,16 @@ static void cx231xx_config_tuner(struct
}
/* --- */
-void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir)
+void cx231xx_register_i2c_ir(struct cx231xx *dev)
{
- if (disable_ir) {
- ir-get_key = NULL;
+ if (disable_ir)
return;
- }
+ /* REVISIT: instantiate IR device */
+}
+
+void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir)
+{
/* detect configure */
switch (dev-model) {
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-i2c.c
2009-05-12 10:19:13.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-i2c.c 2009-05-12
11:24:19.0 +0200
@@ -540,6 +540,9 @@ int cx231xx_i2c_register(struct cx231xx_
if (0 == bus-i2c_rc) {
if (i2c_scan)
cx231xx_do_i2c_scan(dev, bus-i2c_client);
+
+ /* Instantiate the IR receiver device, if present */
+ cx231xx_register_i2c_ir(dev);
} else
cx231xx_warn(%s: i2c bus %d register FAILED\n,
dev-name, bus-nr);
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx.h2009-05-12
10:19:13.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx.h 2009-05-12
11:24:19.0 +0200
@@ -747,6 +747,7 @@ extern void cx231xx_card_setup(struct cx
extern struct cx231xx_board cx231xx_boards[];
[PATCH 3/8] ir-kbd-i2c: Use initialization data
For specific boards, pass initialization data to ir-kbd-i2c instead
of modifying the settings after the device is initialized. This is
more efficient and easier to read.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/cx231xx/cx231xx-cards.c |3
linux/drivers/media/video/cx231xx/cx231xx-i2c.c | 29 --
linux/drivers/media/video/cx231xx/cx231xx.h |1
linux/drivers/media/video/em28xx/em28xx-cards.c | 31 +++---
linux/drivers/media/video/em28xx/em28xx-i2c.c | 22
linux/drivers/media/video/em28xx/em28xx.h |1
linux/drivers/media/video/ir-kbd-i2c.c| 12 ++
linux/drivers/media/video/saa7134/saa7134-i2c.c | 28 --
linux/drivers/media/video/saa7134/saa7134-input.c | 94 ++---
linux/drivers/media/video/saa7134/saa7134.h |1
linux/include/media/ir-kbd-i2c.h |7 +
11 files changed, 79 insertions(+), 150 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-cards.c
2009-05-12 11:24:19.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-cards.c 2009-05-12
11:32:50.0 +0200
@@ -288,10 +288,7 @@ void cx231xx_register_i2c_ir(struct cx23
return;
/* REVISIT: instantiate IR device */
-}
-void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir)
-{
/* detect configure */
switch (dev-model) {
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx-i2c.c
2009-05-12 11:24:19.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx-i2c.c 2009-05-12
11:32:50.0 +0200
@@ -424,34 +424,6 @@ static u32 functionality(struct i2c_adap
return I2C_FUNC_SMBUS_EMUL | I2C_FUNC_I2C;
}
-/*
- * attach_inform()
- * gets called when a device attaches to the i2c bus
- * does some basic configuration
- */
-static int attach_inform(struct i2c_client *client)
-{
- struct cx231xx_i2c *bus = i2c_get_adapdata(client-adapter);
- struct cx231xx *dev = bus-dev;
-
- switch (client-addr 1) {
- case 0x8e:
- {
- struct IR_i2c *ir = i2c_get_clientdata(client);
- dprintk1(1, attach_inform: IR detected (%s).\n,
-ir-phys);
- cx231xx_set_ir(dev, ir);
- break;
- }
- break;
-
- default:
- break;
- }
-
- return 0;
-}
-
static struct i2c_algorithm cx231xx_algo = {
.master_xfer = cx231xx_i2c_xfer,
.functionality = functionality,
@@ -465,7 +437,6 @@ static struct i2c_adapter cx231xx_adap_t
.name = cx231xx,
.id = I2C_HW_B_CX231XX,
.algo = cx231xx_algo,
- .client_register = attach_inform,
};
static struct i2c_client cx231xx_client_template = {
--- v4l-dvb.orig/linux/drivers/media/video/cx231xx/cx231xx.h2009-05-12
11:24:19.0 +0200
+++ v4l-dvb/linux/drivers/media/video/cx231xx/cx231xx.h 2009-05-12
11:32:50.0 +0200
@@ -748,7 +748,6 @@ extern struct cx231xx_board cx231xx_boar
extern struct usb_device_id cx231xx_id_table[];
extern const unsigned int cx231xx_bcount;
void cx231xx_register_i2c_ir(struct cx231xx *dev);
-void cx231xx_set_ir(struct cx231xx *dev, struct IR_i2c *ir);
int cx231xx_tuner_callback(void *ptr, int component, int command, int arg);
/* Provided by cx231xx-input.c */
--- v4l-dvb.orig/linux/drivers/media/video/em28xx/em28xx-cards.c
2009-05-12 11:24:19.0 +0200
+++ v4l-dvb/linux/drivers/media/video/em28xx/em28xx-cards.c 2009-05-12
11:32:50.0 +0200
@@ -1934,6 +1934,7 @@ static int em28xx_hint_board(struct em28
void em28xx_register_i2c_ir(struct em28xx *dev)
{
struct i2c_board_info info;
+ struct IR_i2c_init_data init_data;
const unsigned short addr_list[] = {
0x30, 0x47, I2C_CLIENT_END
};
@@ -1942,12 +1943,9 @@ void em28xx_register_i2c_ir(struct em28x
return;
memset(info, 0, sizeof(struct i2c_board_info));
+ memset(init_data, 0, sizeof(struct IR_i2c_init_data));
strlcpy(info.type, ir_video, I2C_NAME_SIZE);
- i2c_new_probed_device(dev-i2c_adap, info, addr_list);
-}
-void em28xx_set_ir(struct em28xx *dev, struct IR_i2c *ir)
-{
/* detect configure */
switch (dev-model) {
case (EM2800_BOARD_UNKNOWN):
@@ -1956,22 +1954,19 @@ void em28xx_set_ir(struct em28xx *dev, s
break;
case (EM2800_BOARD_TERRATEC_CINERGY_200):
case (EM2820_BOARD_TERRATEC_CINERGY_250):
- ir-ir_codes = ir_codes_em_terratec;
- ir-get_key = em28xx_get_key_terratec;
- snprintf(ir-name, sizeof(ir-name),
-i2c IR (EM28XX Terratec));
+ init_data.ir_codes = ir_codes_em_terratec;
+ init_data.get_key = em28xx_get_key_terratec;
+
[PATCH 4/8] ir-kbd-i2c: Don't assume all IR receivers are supported
The code in ir_probe makes the dangerous assumption that all IR
receivers are supported by the driver. The new i2c model makes it
possible for bridge drivers to instantiate IR devices before they are
supported, therefore the ir-kbd-i2c drivers must be made more robust
to not spam the logs or even crash on unsupported IR devices. Simply,
the driver will not bind to the unsupported devices.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Andy Walls awa...@radix.net
---
linux/drivers/media/video/ir-kbd-i2c.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-07
21:35:53.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ir-kbd-i2c.c 2009-04-07
22:49:10.0 +0200
@@ -307,7 +307,7 @@ static void ir_work(struct work_struct *
static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id)
{
IR_KEYTAB_TYPE *ir_codes = NULL;
- const char *name;
+ const char *name = NULL;
int ir_type;
struct IR_i2c *ir;
struct input_dev *input_dev;
@@ -389,8 +389,7 @@ static int ir_probe(struct i2c_client *c
ir_codes= ir_codes_avermedia_cardbus;
break;
default:
- /* shouldn't happen */
- printk(DEVNAME : Huh? unknown i2c address (0x%02x)?\n, addr);
+ dprintk(1, DEVNAME : Unsupported i2c address 0x%02x\n, addr);
err = -ENODEV;
goto err_out_free;
}
@@ -405,6 +404,14 @@ static int ir_probe(struct i2c_client *c
ir-get_key = init_data-get_key;
}
+ /* Make sure we are all setup before going on */
+ if (!name || !ir-get_key || !ir_codes) {
+ dprintk(1, DEVNAME : Unsupported device at address 0x%02x\n,
+ addr);
+ err = -ENODEV;
+ goto err_out_free;
+ }
+
/* Sets name */
snprintf(ir-name, sizeof(ir-name), i2c IR (%s), name);
ir-ir_codes = ir_codes;
--
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
[PATCH 5/8] saa7134: Simplify handling of IR on MSI t...@nywhere Plus
Now that we instantiate I2C IR devices explicitly, we can skip probing
altogether on boards where the I2C IR device address is known. The MSI
t...@nywhere Plus is one of these boards.
Signed-off-by: Jean Delvare kh...@linux-fr.org
---
linux/drivers/media/video/saa7134/saa7134-input.c | 28 +++--
1 file changed, 15 insertions(+), 13 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-29 15:42:53.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-29
15:53:23.0 +0200
@@ -695,9 +695,6 @@ void saa7134_probe_i2c_ir(struct saa7134
I2C_CLIENT_END
};
- const unsigned short addr_list_msi[] = {
- 0x30, I2C_CLIENT_END
- };
struct i2c_msg msg_msi = {
.addr = 0x50,
.flags = I2C_M_RD,
@@ -751,6 +748,15 @@ void saa7134_probe_i2c_ir(struct saa7134
init_data.name = MSI t...@nywhere Plus;
init_data.get_key = get_key_msi_tvanywhere_plus;
init_data.ir_codes = ir_codes_msi_tvanywhere_plus;
+ info.addr = 0x30;
+ /* MSI t...@nywhere Plus controller doesn't seem to
+ respond to probes unless we read something from
+ an existing device. Weird...
+ REVISIT: might no longer be needed */
+ rc = i2c_transfer(dev-i2c_adap, msg_msi, 1);
+ dprintk(KERN_DEBUG probe 0x%02x @ %s: %s\n,
+ msg_msi.addr, dev-i2c_adap.name,
+ (1 == rc) ? yes : no);
break;
case SAA7134_BOARD_HAUPPAUGE_HVR1110:
init_data.name = HVR 1110;
@@ -777,18 +783,14 @@ void saa7134_probe_i2c_ir(struct saa7134
if (init_data.name)
info.platform_data = init_data;
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
- if (client)
+ /* No need to probe if address is known */
+ if (info.addr) {
+ i2c_new_device(dev-i2c_adap, info);
return;
+ }
- /* MSI t...@nywhere Plus controller doesn't seem to
- respond to probes unless we read something from
- an existing device. Weird... */
- rc = i2c_transfer(dev-i2c_adap, msg_msi, 1);
- dprintk(KERN_DEBUG probe 0x%02x @ %s: %s\n,
- msg_msi.addr, dev-i2c_adap.name,
- (1 == rc) ? yes : no);
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list_msi);
+ /* Address not known, fallback to probing */
+ client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
if (client)
return;
--
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
[PATCH 6/8] saa7134: Simplify handling of IR on AVerMedia Cardbus E506R
Now that we instantiate I2C IR devices explicitly, we can skip probing
altogether on boards where the I2C IR device address is known. The
AVerMedia Cardbus E506R is one of these boards.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Tested-by: Oldrich Jedlicka oldium@seznam.cz
---
linux/drivers/media/video/saa7134/saa7134-input.c | 33 +++--
1 file changed, 5 insertions(+), 28 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/saa7134/saa7134-input.c
2009-04-30 10:38:49.0 +0200
+++ v4l-dvb/linux/drivers/media/video/saa7134/saa7134-input.c 2009-04-30
10:39:10.0 +0200
@@ -702,20 +702,6 @@ void saa7134_probe_i2c_ir(struct saa7134
.buf = NULL,
};
- unsigned char subaddr, data;
- struct i2c_msg msg_avermedia[] = { {
- .addr = 0x40,
- .flags = 0,
- .len = 1,
- .buf = subaddr,
- }, {
- .addr = 0x40,
- .flags = I2C_M_RD,
- .len = 1,
- .buf = data,
- } };
-
- struct i2c_client *client;
int rc;
if (disable_ir) {
@@ -779,6 +765,10 @@ void saa7134_probe_i2c_ir(struct saa7134
init_data.get_key = get_key_beholdm6xx;
init_data.ir_codes = ir_codes_behold;
break;
+ case SAA7134_BOARD_AVERMEDIA_CARDBUS_501:
+ case SAA7134_BOARD_AVERMEDIA_CARDBUS_506:
+ info.addr = 0x40;
+ break;
}
if (init_data.name)
@@ -790,20 +780,7 @@ void saa7134_probe_i2c_ir(struct saa7134
}
/* Address not known, fallback to probing */
- client = i2c_new_probed_device(dev-i2c_adap, info, addr_list);
- if (client)
- return;
-
- /* Special case for AVerMedia Cardbus remote */
- subaddr = 0x0d;
- rc = i2c_transfer(dev-i2c_adap, msg_avermedia, 2);
- dprintk(KERN_DEBUG probe 0x%02x/0x%02x @ %s: %s\n,
- msg_avermedia[0].addr, subaddr, dev-i2c_adap.name,
- (2 == rc) ? yes : no);
- if (2 == rc) {
- info.addr = msg_avermedia[0].addr;
- i2c_new_device(dev-i2c_adap, info);
- }
+ i2c_new_probed_device(dev-i2c_adap, info, addr_list);
}
static int saa7134_rc5_irq(struct saa7134_dev *dev)
--
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
[PATCH 7/8] ivtv: Probe more I2C addresses for IR devices
Probe I2C addresses 0x71 and 0x6b for IR receiver devices (for the
PVR150 and Adaptec cards, respectively.)
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
---
linux/drivers/media/video/ivtv/ivtv-i2c.c|7 ++-
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |2 +-
2 files changed, 7 insertions(+), 2 deletions(-)
--- v4l-dvb.orig/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-05-13
16:36:49.0 +0200
+++ v4l-dvb/linux/drivers/media/video/ivtv/ivtv-i2c.c 2009-05-13
17:50:55.0 +0200
@@ -652,7 +652,12 @@ int init_ivtv_i2c(struct ivtv *itv)
That's why we probe 0x1a (~0x34) first. CB
*/
const unsigned short addr_list[] = {
- 0x1a, 0x18, 0x64, 0x30,
+ 0x1a, /* Hauppauge IR external */
+ 0x18, /* Hauppauge IR internal */
+ 0x71, /* Hauppauge IR (PVR150) */
+ 0x64, /* Pixelview IR */
+ 0x30, /* KNC ONE IR */
+ 0x6b, /* Adaptec IR */
I2C_CLIENT_END
};
--
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
[PATCH 8/8] pvrusb2: Instantiate ir_video I2C device by default
Now that the ir-kbd-i2c driver has been converted to a new-style i2c
driver, we can instantiate the ir_video I2C device by default. The
pvr2_disable_ir_video is kept to disable the IR receiver, either
because the user doesn't use it, or for debugging purpose.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mike Isely is...@pobox.com
---
linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
--- v4l-dvb.orig/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-05-13 18:05:54.0 +0200
+++ v4l-dvb/linux/drivers/media/video/pvrusb2/pvrusb2-i2c-core.c
2009-05-13 18:06:32.0 +0200
@@ -43,7 +43,7 @@ static int ir_mode[PVR_NUM] = { [0 ... P
module_param_array(ir_mode, int, NULL, 0444);
MODULE_PARM_DESC(ir_mode,specify: 0=disable IR reception, 1=normal IR);
-static int pvr2_disable_ir_video = 1;
+static int pvr2_disable_ir_video;
module_param_named(disable_autoload_ir_video, pvr2_disable_ir_video,
int, S_IRUGO|S_IWUSR);
MODULE_PARM_DESC(disable_autoload_ir_video,
--
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
BUG in av7110_vbi_write()
Hi, it seems there is a bug in av7110_vbi_write() (av7110_v4l.c). If an user mode application tries to write more bytes than the size of the structure v4l2_slices_vbi_data, copy_from_user() will overwrite parts of the kernel stack. Regards, Hartmut -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed 13 May 2009 2:24:53 pm Devin wrote: On Wed, May 13, 2009 at 3:04 PM, Timothy D. Lenz tl...@vorgon.com wrote: So when this goes main, next time we update from v4l we need the new firmware right? Yes. Now that we have the licensing straightened out, I'll also be working on getting it bundled into the distros so that users don't have to download the firmware themselves. They will get a true plug and play experience. Devin, does this license/bundle arrangement also cover the firmware for xc3028-based devices? -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: XC5000 improvements: call for testers!
On Wed, May 13, 2009 at 6:26 PM, Vanessa Ezekowitz Devin, does this license/bundle arrangement also cover the firmware for xc3028-based devices? Unfortunately, it does not. Once I get the xc5000 stuff in though, I am planning on approaching them about getting firmware licensing under the same terms for xc3028, xc3028L, and xc4000. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] FM1216ME_MK3 some changes
Hi Dmitry, Am Mittwoch, den 13.05.2009, 07:37 +1000 schrieb Dmitri Belimov: Hi hermann Am Sonntag, den 10.05.2009, 08:52 +1000 schrieb Dmitri Belimov: Hi All. [snip] Channel designations I dug out of ivtv-tune: S38 439.250 MHz (European cable) H18 439.250 MHz (SECAM France) 47 440.250 MHz (PAL China) 059 440.250 MHz (PAL Argentina) come close, but are unaffected by the change from 442 to 441 as the bandswitch cutover point. These channels fall right on top of the cutover, but are not affected by the proposed change in any meaningful way. The VHF-High filter and VCO would still be used. Dmitri's proposed change is a don't care unless the cutover point is changed to 440 MHz. Let's pretend that the proposed cutover point is 440 MHz. NO! it is not Dmitri, can you cut one off and tell us what it is all about ? Unless you do so, all other is pointless and I likely stop to participate in such stuff. Sorry my delay. I lost subject of discussion. What main question?? 1. AGC TOP of RF part - I think need support for MK3 2. Changing to 441MHz is not critical. We can write some information about this case to Wiki or docs. for 2.: Discussed to the end if you stay at 441MHz. If you still want to have it in, just send a patch and no more info is needed. (Likely Andy is giving only examples for more difficult cases, sorry.) for 1.: I would like to be absolutely sure, that we are talking about the same tuner. I want to have the exact filters on it at least. 3.: That is what Andy noted. Following the Philips datasheet for TOP, it should be added for negative modulation, positive modulation and FM accordingly. (2 and 3 are out of discussion) If you still have some sort of Secam fire and can improve it, we must know the tuner you are on exactly. If it is the original Philips, without any such TOP suggestions over the full range in recent datasheets (???), I assume you might have them, I would say you can proceed, if you have shown that you are really still on the same tuner. This is real Philips MK3 and MK5 tuner. We have all docs from vendor. This is some photos of the MK3 hybrid tuner. I make photos of the analog MK3 little later. thanks a lot. I had only a first look on this one. There are a lot of different revisions, yours is F4 on the tuner PCB. Taifun PLL versions vary, different combinations of ceramic and SMD filters are used for the radio IF, but even on a revision C1 with Taifun 6034T A1 and tuner revision SV21 0437 (CTX918_V2 md7134) all three SAW filters are the same already. A CTX925 with your Taifun 6034T B1 had also no better performance for what I can say. PCB still has C1, but SV21 0502 tuner revision. Important to know was, that you are on original Philips tuners and SAW filters are the same. Guess this will hold for the analog FM1216ME/I MK3 too. Good decision, it are still the best tuners for analog and digital I have around, but can't talk for Secam D/K. I wonder about missing complaints during the last four years. 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
