Re: Kworld Plus TV Hybrid PCI (DVB-T 210SE)
on Wed, 17 Mar 2010 09:12 am in the Usenet newsgroup gmane.linux.drivers.video-input-infrastructure hermann pitton wrote: [snip] unfortunately the problem with these cards is known, but no good solution for now. Best description is from Hartmut and starts here. http://www.spinics.net/lists/linux-dvb/msg26683.html [snip] Interesting link. I have one of the cards mentioned (an MSI TV(at)nywhere A/D hybrid). I've decided not to throw it away. -- Sig goes here... Peter D. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Phase 1: Proposal to convert V4L1 drivers
Hi all, Well, I certainly fired everyone up with my RFC. Based on the replies I got I do think the time is right to start the removal process. Phase 1 would be to convert the remaining V4L1 drivers. To see what needs to be done I decided to analyse the remaining V4L1 drivers: - usbvideo (really four drivers: vicam, ibmcam, konicawc, quickcam_messenger) Hans de Goede added support for the quickcam_messenger to gspca, so that driver is scheduled for removal. Devin has hardware to test the vicam driver. David Ellingsworth has hardware to test the ibmcam driver. It would be great if Devin and David can either send it to Hans de Goede or work on it themselves. The konicawc is for an Intel YC76 webcam. I found one for sale here: http://www.ecrater.com/product.php?pid=6593985 Unfortunately the seller does not ship to the Netherlands or to Norway. Can some kind US developer buy it and donate it to Hans de Goede? It's fairly expensive at $39.99, but it's for a good cause. So in theory all these drivers can be tested and converted. - bw-qcam A parallel port Connectix QuickCam webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. - c-qcam A parallel port color Connectix QuickCam webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. - w9966 A parallel port LifeView FlyCam Supra webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. - cpia_pp Parallel port webcam driver for the Creative Webcam II. I found one on eBay, so with luck I can get hold of the hardware and get it to HdG. - cpia_usb USB variant of cpia_pp. Deprecated since it is now supported by gspca. - stradis Supports the Stradis SDM-275 4:2:2 MPEG-2 video decoder. I just found one on eBay and bought it. This being an MPEG decoder I think that I will try to convert this to V4L2. It does not look like that will be very difficult. - arv Driver for the the Renesas AR module on the M32700UT platform. Looking at this driver it seems that it should be very easy to convert this to v4l2. It's very basic and has no DMA or streaming support. We can try contacting the author to see whether he can test a converted driver. Or perhaps try and find the maintainer for this platform. - ov511 - ovcamchip - w9968cf - stv680 Deprecated. Are now supported by gspca. - se401 Hans de Goede has hardware. The current V4L1 driver does not work. Kconfig mistakes: I found four errors in drivers/media/video/Kconfig: the saa7191, meye, mxb and cpia2 drivers are all marked as V4L1 only, while all support V4L2! The cpia2 driver supports both v4l1 and v4l2. I can test this driver and will look at removing the V4L1 support from that driver. Conclusion: These drivers have no hardware to test with: bw-qcam, c-qcam, arv, w9966. However, all four should be easy to convert to v4l2, even without hardware. Volunteers? Hardware is available for these drivers: se401, ibmcam, vicam. If Devin and David can either donate the hardware to HdG or do the work themselves, then these drivers can all be moved to gspca. Hardware is ordered for the stradis driver. I'll do that one. The V4L1 support should be removed from the cpia2 driver, leaving just the V4L2 API. I can do that. It is very likely that I can get hold of a cpia_pp device. I'll make sure that HdG gets it. That leaves the konicawc. We need a friendly US citizen who is willing to buy one and donate it to HdG. So if we all pitch in, then can get everything converted without having to remove drivers. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. That will also solve the problem of embedded device vendors running new kernels with old V4L1 applications. They just need to use libv4l1. The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. I'm afraid that it is unlikely that anyone will do that work for us, so it's probably best just to bite the bullet and do it ourselves. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. That will also solve the problem of embedded device vendors running new kernels with old V4L1 applications. They just need to use libv4l1. The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. I'm afraid that it is unlikely that anyone will do that work for us, so it's probably best just to bite the bullet and do it ourselves. Regards, Hans Hello Hans, I haven't followed your discussion so far (sorry!). I got a trivial question: I run a Miro PCTV pro (stereo) on one of my machines. It needs simple tuner transport / TDA 9885/6/7 analog IF demodulator, Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as kernel options to run / to be usable at all. Can you make sure that this card will still be usable after your v4l1 removal activities are finished? In other words: What happens to this v4l1 compat code which is obviously necessary for this (and other) card(s) to run? That's it what I haven't understood right now, so could you please be kind enough to explain that with a couple of words? Thanks! CS P. S.: If you make your decision to host xawtv and other apps please do not merge hybrid applications (i. e. apps made for DVB and analogue devices) as you can find them in the xawtv 4.0 pre alpha code for example in analogue trees. Rather establish extra trees for hybrid applications please. -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Saturday 20 March 2010 13:17:15 Chicken Shack wrote: Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. That will also solve the problem of embedded device vendors running new kernels with old V4L1 applications. They just need to use libv4l1. The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. I'm afraid that it is unlikely that anyone will do that work for us, so it's probably best just to bite the bullet and do it ourselves. Regards, Hans Hello Hans, I haven't followed your discussion so far (sorry!). I got a trivial question: I run a Miro PCTV pro (stereo) on one of my machines. It needs simple tuner transport / TDA 9885/6/7 analog IF demodulator, Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as kernel options to run / to be usable at all. That's the V4L2 bttv driver. What app are you using with this card? Can you make sure that this card will still be usable after your v4l1 removal activities are finished? You can easily test this by turning off the compat layer in the kernel config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so. In other words: What happens to this v4l1 compat code which is obviously necessary for this (and other) card(s) to run? That's it what I haven't understood right now, so could you please be kind enough to explain that with a couple of words? Thanks! CS P. S.: If you make your decision to host xawtv and other apps please do not merge hybrid applications (i. e. apps made for DVB and analogue devices) as you can find them in the xawtv 4.0 pre alpha code for example in analogue trees. Rather establish extra trees for hybrid applications please. These apps will each get their own tree. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- 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: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Am Samstag, den 20.03.2010, 13:37 +0100 schrieb Hans Verkuil: On Saturday 20 March 2010 13:17:15 Chicken Shack wrote: Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. That will also solve the problem of embedded device vendors running new kernels with old V4L1 applications. They just need to use libv4l1. The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. I'm afraid that it is unlikely that anyone will do that work for us, so it's probably best just to bite the bullet and do it ourselves. Regards, Hans Hello Hans, I haven't followed your discussion so far (sorry!). I got a trivial question: I run a Miro PCTV pro (stereo) on one of my machines. It needs simple tuner transport / TDA 9885/6/7 analog IF demodulator, Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as kernel options to run / to be usable at all. That's the V4L2 bttv driver. What app are you using with this card? Should rather be: What apps are you using (Plural mode)? One big mess somehow. 1. The only one that runs is tvtime. But with tvtime I cannot record streams. 2. Then I have tested zapping, which is a gnome app. No matter if I start it without parameters or with parameter LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (it's a Debian system), channel switching is simply impossible. Version is 0.10cvs6. Well, and the biggest pest are the radio apps: 1. Running gnomeradio the channel scanner does not find anything and I cannot hear anything (independent from starting mode - with or without parameters). 2. Maybe Gerd's radio solves it, but in that case recording is unclear, as it is a rather primitive GUI without recording function implied. Can you make sure that this card will still be usable after your v4l1 removal activities are finished? You can easily test this by turning off the compat layer in the kernel config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so. Hmmm. See above. If I used the parametry in a wrong way please tell me. In other words: What happens to this v4l1 compat code which is obviously necessary for this (and other) card(s) to run? That's it what I haven't understood right now, so could you please be kind enough to explain that with a couple of words? Thanks! CS P. S.: If you make your decision to host xawtv and other apps please do not merge hybrid applications (i. e. apps made for DVB and analogue devices) as you can find them in the xawtv 4.0 pre alpha code for example in analogue trees. Rather establish extra trees for hybrid applications please. These apps will each get their own tree. Regards, Hans This sounds excellent :) Best Regards Uwe P. S.: So if I take you right the kernel compat module function does not hit or point to the driver itself, but rather to the application layer? Not easy to anticipate this as a picture in my head.. -- 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
av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)
e9hack wrote: Am 13.3.2010 17:27, schrieb Hans Verkuil: If there are no further comments, then I'll post a pull request in a few days. Tested with the mxb board. It would be nice if you can verify this with the av7110. Hi hans, it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't possible to unload the module for the TT-C2300. Guys, when will you finally apply this fix? As Hartmut pointed out, changeset 14351:2eda2bcc8d6f broke the av7110 driver (and also budget-av). It is time to fix it. This bug must not go into the kernel! CU Oliver -- VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/ 4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/ Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Saturday 20 March 2010 14:51:44 Chicken Shack wrote: Am Samstag, den 20.03.2010, 13:37 +0100 schrieb Hans Verkuil: On Saturday 20 March 2010 13:17:15 Chicken Shack wrote: Am Samstag, den 20.03.2010, 10:21 +0100 schrieb Hans Verkuil: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. In principle libv4l1 should allow V4L1 apps to run fine with V4L2 drivers. That will also solve the problem of embedded device vendors running new kernels with old V4L1 applications. They just need to use libv4l1. The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. I'm afraid that it is unlikely that anyone will do that work for us, so it's probably best just to bite the bullet and do it ourselves. Regards, Hans Hello Hans, I haven't followed your discussion so far (sorry!). I got a trivial question: I run a Miro PCTV pro (stereo) on one of my machines. It needs simple tuner transport / TDA 9885/6/7 analog IF demodulator, Micronas msp3400 for Stereo tone PLUS v4l1 compat layer as kernel options to run / to be usable at all. That's the V4L2 bttv driver. What app are you using with this card? Should rather be: What apps are you using (Plural mode)? One big mess somehow. 1. The only one that runs is tvtime. But with tvtime I cannot record streams. 2. Then I have tested zapping, which is a gnome app. No matter if I start it without parameters or with parameter LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so (it's a Debian system), channel switching is simply impossible. Version is 0.10cvs6. zapping is definitely V4L2 aware. Make sure it is not trying to use V4L1. Well, and the biggest pest are the radio apps: 1. Running gnomeradio the channel scanner does not find anything and I cannot hear anything (independent from starting mode - with or without parameters). Which gnomeradio version are you using? 1.8 seems to support V4L2. Again, make sure it isn't selecting V4L1 instead of V4L2. 2. Maybe Gerd's radio solves it, but in that case recording is unclear, as it is a rather primitive GUI without recording function implied. Can you make sure that this card will still be usable after your v4l1 removal activities are finished? You can easily test this by turning off the compat layer in the kernel config. You should still be able to use your v4l1 app by using LD_PRELOAD=/usr/lib/v4l1compat.so. Hmmm. See above. If I used the parametry in a wrong way please tell me. In other words: What happens to this v4l1 compat code which is obviously necessary for this (and other) card(s) to run? That's it what I haven't understood right now, so could you please be kind enough to explain that with a couple of words? Thanks! CS P. S.: If you make your decision to host xawtv and other apps please do not merge hybrid applications (i. e. apps made for DVB and analogue devices) as you can find them in the xawtv 4.0 pre alpha code for example in analogue trees. Rather establish extra trees for hybrid applications please. These apps will each get their own tree. Regards, Hans This sounds excellent :) Best Regards Uwe P. S.: So if I take you right the kernel compat module function does not hit or point to the driver itself, but rather to the application layer? Not easy to anticipate this as a picture in my head.. The driver is V4L2, but the kernel compat layer can translate V4L1 calls to V4L2 calls. The libv4l1compat can do the same, but now in userspace instead of kernelspace. What I don't really know is whether libv4l1compat can completely replace the kernel compat layer. Of course, the best solution is to convert the V4L1 apps to using V4L2. Note that it would be useful if you can try to debug these apps a bit. I would not at all be surprised if you are looking at application bugs rather than kernel bugs. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a
[PATCH 11/24] media/radio/si470x: fix dangling pointers
Fix I2C-drivers which missed setting clientdata to NULL before freeing the structure it points to. Also fix drivers which do this _after_ the structure was freed already. Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Mauro Carvalho Chehab mche...@infradead.org --- Found using coccinelle, then reviewed. Full patchset is available via kernel-janitors, linux-i2c, and LKML. --- drivers/media/radio/si470x/radio-si470x-i2c.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/media/radio/si470x/radio-si470x-i2c.c b/drivers/media/radio/si470x/radio-si470x-i2c.c index 5466015..2dabfac 100644 --- a/drivers/media/radio/si470x/radio-si470x-i2c.c +++ b/drivers/media/radio/si470x/radio-si470x-i2c.c @@ -480,8 +480,8 @@ static __devexit int si470x_i2c_remove(struct i2c_client *client) free_irq(client-irq, radio); cancel_work_sync(radio-radio_work); video_unregister_device(radio-videodev); - kfree(radio); i2c_set_clientdata(client, NULL); + kfree(radio); return 0; } -- 1.7.0 -- 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 10/24] media/radio: fix dangling pointers
Fix I2C-drivers which missed setting clientdata to NULL before freeing the
structure it points to. Also fix drivers which do this _after_ the structure
was freed already.
Signed-off-by: Wolfram Sang w.s...@pengutronix.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
---
Found using coccinelle, then reviewed. Full patchset is available via
kernel-janitors, linux-i2c, and LKML.
---
drivers/media/radio/radio-tea5764.c |2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/media/radio/radio-tea5764.c
b/drivers/media/radio/radio-tea5764.c
index 8e718bf..8a6be0a 100644
--- a/drivers/media/radio/radio-tea5764.c
+++ b/drivers/media/radio/radio-tea5764.c
@@ -571,6 +571,7 @@ static int __devinit tea5764_i2c_probe(struct i2c_client
*client,
return 0;
errrel:
video_device_release(radio-videodev);
+ i2c_set_clientdata(client, NULL);
errfr:
kfree(radio);
return ret;
@@ -584,6 +585,7 @@ static int __devexit tea5764_i2c_remove(struct i2c_client
*client)
if (radio) {
tea5764_power_down(radio);
video_unregister_device(radio-videodev);
+ i2c_set_clientdata(client, NULL);
kfree(radio);
}
return 0;
--
1.7.0
--
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: av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)
On Saturday 20 March 2010 15:07:08 Oliver Endriss wrote: e9hack wrote: Am 13.3.2010 17:27, schrieb Hans Verkuil: If there are no further comments, then I'll post a pull request in a few days. Tested with the mxb board. It would be nice if you can verify this with the av7110. Hi hans, it works with my TT-C2300 perfectly. The main problem of your changes was: It wasn't possible to unload the module for the TT-C2300. Guys, when will you finally apply this fix? Thanks for reminding me, I frankly forgot about this. Hartmut, is the problem with unloading the module something that my patch caused? Or was that there as well before changeset 14351:2eda2bcc8d6f? Are there any kernel messages indicating why it won't unload? Regards, Hans As Hartmut pointed out, changeset 14351:2eda2bcc8d6f broke the av7110 driver (and also budget-av). It is time to fix it. This bug must not go into the kernel! CU Oliver -- 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] saa7134: add capture boards Hawell HW-404M7 and HW-808M7
Hi Hermann.
1. It's my mistake. Fixed.
2. Dead code. Removed.
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1269096094 -10800
# Node ID a91db2cf4f5774866c8c5bf906d9ac4faff9173d
# Parent 929298149eba4b6d0696124b9880113c25cd0788
saa7134: fix GPIO HW-404M7
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 18 23:47:27
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Mar 20 17:41:34
2010 +0300
@@ -5403,12 +5403,12 @@
.radio_type= UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .gpiomask = 0x01fc00,
+ .gpiomask = 0x389c00,
.inputs = {{
.name = name_comp1,
.vmux = 3,
.amux = LINE1,
- .gpio = 0x389c00,
+ .gpio = 0x01fc00,
} },
},
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Thu Mar 18 23:47:27
2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sat Mar 20 17:41:34
2010 +0300
@@ -531,7 +531,6 @@
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
- case SAA7134_BOARD_HAWELL_HW_404M7:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
В Птн, 19/03/2010 в 00:21 +0100, hermann pitton пишет:
Hi Vladimir,
thanks, your patch is already accepted, but if have a two comments.
Am Mittwoch, den 10.03.2010, 18:44 +0300 schrieb Vladimir Ermakov:
This patch adds new capture boards Hawell HW-404M7 and HW-808M7.
Those cards have 4 or 8 SAA7130 chips and for the work it only needs
initialize registers.
The value of those registers were dumped under Windows using flytest.
But board haven't EEPROM.
For the first chip:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389C00
Value: 0x00016C00
Later in the code you swapped mode (gpio mask) and value (out status).
This does not cause a functional problem in this case, but is visible
for example with saa7134 gpio_tracking=1.
Second, you did add the card to the flyvideo remotes in saa7134-input,
but this is only a line of dead code currently.
If it really has such a remote, you must also add the card to the switch
case dev-has_remote = SAA7134_REMOTE_GPIO in in the function
int saa7134_board_init1 in saa7134-cards.c or please remove it from
saa7134-input.c.
Thanks,
Hermann
Video input: 3
Audio input: Analog Line1
For other chips:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389200
Value: 0x0001
Video input: 3
Audio input: Analog Line1
Signed-off-by: Vladimir Ermakov vooon...@gmail.com
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1268232221 -10800
# Node ID 072cd67c6aabe0e700a9e4727b50ad6424cb59f5
# Parent 7a58d924fb049ff1d318514939b3a7e416670c13
saa7134: add Hawell HW-404M7 HW-808M7
diff -r 7a58d924fb04 -r 072cd67c6aab
linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 Tue Mar 09
23:00:59 2010 -0300
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Wed Mar 10
17:43:41 2010 +0300
@@ -175,3 +175,4 @@
174 - Asus Europa Hybrid OEM [1043:4847]
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
+177 - Hawell HW-404M7 / HW-808M7
diff -r 7a58d924fb04 -r 072cd67c6aab
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Tue Mar 09
23:00:59 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Wed Mar 10
17:43:41 2010 +0300
@@ -5394,6 +5394,23 @@
.amux = LINE2,
},
},
+[SAA7134_BOARD_HAWELL_HW_404M7] = {
+/* Hawell HW-404M7 Hawell HW-808M7 */
+/* Bogoslovskiy Viktor bogo...@bk.ru */
+.name = Hawell HW-404M7,
+.audio_clock = 0x0020,
+.tuner_type= UNSET,
+.radio_type= UNSET,
+.tuner_addr = ADDR_UNSET,
+.radio_addr = ADDR_UNSET,
+.gpiomask = 0x01fc00,
+.inputs = {{
+.name = name_comp1,
+.vmux = 3,
+.amux = LINE1,
+.gpio = 0x389c00,
+} },
+},
};
diff -r 7a58d924fb04 -r 072cd67c6aab
Re: av7110 and budget_av are broken! (was: Re: changeset 14351:2eda2bcc8d6f)
Hans Verkuil wrote:
On Saturday 20 March 2010 15:07:08 Oliver Endriss wrote:
e9hack wrote:
Am 13.3.2010 17:27, schrieb Hans Verkuil:
If there are no further comments, then I'll post a pull request in a
few days.
Tested with the mxb board. It would be nice if you can verify this with
the
av7110.
Hi hans,
it works with my TT-C2300 perfectly. The main problem of your changes
was: It wasn't
possible to unload the module for the TT-C2300.
Guys, when will you finally apply this fix?
Thanks for reminding me, I frankly forgot about this.
Hartmut, is the problem with unloading the module something that my patch
caused? Or was that there as well before changeset 14351:2eda2bcc8d6f?
Are there any kernel messages indicating why it won't unload?
The patch caused the problem.
You moved v4l2_device_register() from saa7146_vv_init() to
saa7146_vv_devinit(), but you did not modify av7110_v4l.c and
budget-av.c accordingly.
$ grep saa7146_vv_init v4l/*c
v4l/av7110_v4l.c: ret = saa7146_vv_init(dev, vv_data);
v4l/budget-av.c:if (0 != saa7146_vv_init(dev, vv_data)) {
v4l/hexium_gemini.c:saa7146_vv_init(dev, vv_data);
v4l/hexium_orion.c: saa7146_vv_init(dev, vv_data);
v4l/mxb.c: saa7146_vv_init(dev, vv_data);
v4l/saa7146_fops.c:int saa7146_vv_init(struct saa7146_dev* dev, struct
saa7146_ext_vv *ext_vv)
v4l/saa7146_fops.c:EXPORT_SYMBOL_GPL(saa7146_vv_init);
v4l/saa7146_fops.c:static int __init saa7146_vv_init_module(void)
v4l/saa7146_fops.c:module_init(saa7146_vv_init_module);
$ grep saa7146_vv_devinit v4l/*c
v4l/hexium_gemini.c:ret = saa7146_vv_devinit(dev);
v4l/hexium_orion.c: err = saa7146_vv_devinit(dev);
v4l/mxb.c: err = saa7146_vv_devinit(dev);
v4l/saa7146_fops.c:int saa7146_vv_devinit(struct saa7146_dev *dev)
v4l/saa7146_fops.c:EXPORT_SYMBOL_GPL(saa7146_vv_devinit);
CU
Oliver
--
VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Sat, Mar 20, 2010 at 10:14 AM, Hans Verkuil hverk...@xs4all.nl wrote: Of course, the best solution is to convert the V4L1 apps to using V4L2. On that topic, if I wanted to ensure that an application was not using any V4L1 functionality, is there any easy way to do that? For example, can I just remove the #include videodev.h and fix whatever breaks? Right now a problem is that there could easily be situations where an app uses V4L1 functionality without my knowledge, and it would be good if there were an easy way to audit the app and make sure it is doing V4L2 entirely (in fact, I had this issue in a few places with tvtime). 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
tevii s660 system slow/freeze
Dear mailinglist/Tevii, i have received a new tevii s660 yesterday. I have tried to use the device with scan but then my system freezes/slows down and i don't get any channels. Also when i create a channel list with my nova 2 hd and check if that works with vdr, then i removed the drivers from the nova card and plugged in the s660 and started vdr. But then still no picture only system freeze/slow down. I get nothing in the logs so it seems a driver issue. i have tried the drivers from the tevii site and also tried the 2.6.34rc1 kernel from ubuntu. I also tried it on 3 different systems but to no avail. in dmesg i get: [16735.496800] usbcore: deregistering interface driver dw2102 [16735.562114] dvb-usb: TeVii S660 USB successfully deinitialized and disconnected. [16737.219577] dvb-usb: found a 'TeVii S660 USB' in cold state, will try to load a firmware [16737.219593] usb 1-1: firmware: requesting dvb-usb-teviis660.fw [16737.229441] dvb-usb: downloading firmware from file 'dvb-usb-teviis660.fw' [16737.229453] dw2102: start downloading DW210X firmware [16737.350052] dvb-usb: found a 'TeVii S660 USB' in warm state. [16737.350171] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [16737.350414] DVB: registering new adapter (TeVii S660 USB) [16747.590032] dvb-usb: MAC address: 00:18:bd:5c:55:bb [16747.650033] Only Zarlink VP310/MT312/ZL10313 are supported chips. [16748.074008] DS3000 chip version: 0.192 attached. [16748.074015] dw2102: Attached ds3000+ds2020! [16748.074017] [16748.074189] DVB: registering adapter 0 frontend 0 (Montage Technology DS3000/TS2020)... [16748.076014] input: IR-receiver inside an USB DVB receiver as /devices/pci:00/:00:1d.7/usb1/1-1/input/input11 [16748.076312] dvb-usb: schedule remote query interval to 150 msecs. [16748.076327] dvb-usb: TeVii S660 USB successfully initialized and connected. [16748.076596] usbcore: registered new interface driver dw2102 and after that i only see: [16748.224312] dw2102: query RC enter [16748.224320] dw2102: query RC start [16748.246317] dw2102: query RC end [16748.396311] dw2102: query RC enter [16748.396320] dw2102: query RC start [16748.415313] dw2102: query RC end [16748.561641] dw2102: query RC enter [16748.561650] dw2102: query RC start [16748.585317] dw2102: query RC end over and over just filling the logs. i saw that it was from/for the remote but it looks like debug messages. I have tried 3 different kernels 2.6.32/3/4rc1 but they all have the same issue with the driver from 15 march. What can be wrong? Any suggestions how i can troubleshoot this? With kind regards William van de Velde new tevii S660 system slow/freeze no channels linux -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://kernellabs.com/hg/~dheitmueller/v4l-dvb-em286x-tvp5150
Hello, Please PULL from http://kernellabs.com/hg/~dheitmueller/v4l-dvb-em286x-tvp5150 for the following: em28xx: add em286x/tvp5150 reference design Thanks, 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: RFC: Phase 1: Proposal to convert V4L1 drivers
On Sat, 2010-03-20 at 09:58 +0100, Hans Verkuil wrote: Hi all, lines deleted - ov511 - ovcamchip - w9968cf - stv680 Conclusion: These drivers have no hardware to test with: bw-qcam, c-qcam, arv, w9966. However, all four should be easy to convert to v4l2, even without hardware. Volunteers? Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Hello, I have a c-qcam with par. port, so i can do some test, see page below for some information webcam: http://gkall.hobby.nl/connectix-quickcam.html -- m.vr.gr. Gerard Klaver -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 1: Proposal to convert V4L1 drivers
On Sat, Mar 20, 2010 at 4:58 AM, Hans Verkuil hverk...@xs4all.nl wrote: Hans de Goede added support for the quickcam_messenger to gspca, so that driver is scheduled for removal. Devin has hardware to test the vicam driver. David Ellingsworth has hardware to test the ibmcam driver. It would be great if Devin and David can either send it to Hans de Goede or work on it themselves. This all seems pretty reasonable. I just have to decide whether I would rather burn the time to learn the gspca framework, or just eat the cost and donate the board to Hans de Goede. I haven't used the product in eight or ten years, so it's not like I'm going to miss it. Wow, we're debating what to do about a product that hasn't been available in retail since around 2002. 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
[cron job] v4l-dvb daily build 2.6.22 and up: ERRORS, 2.6.16-2.6.21: WARNINGS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sat Mar 20 19:00:24 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 14494:929298149eba git master: f6760aa024199cfbce564311dc4bc4d47b6fb349 git media-master: 8c69c6ed6c74c94fa7ad6fa24eda452e4b212d81 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-armv5: OK linux-2.6.34-rc1-armv5: OK linux-2.6.32.6-armv5-davinci: WARNINGS linux-2.6.33-armv5-davinci: WARNINGS linux-2.6.34-rc1-armv5-davinci: WARNINGS linux-2.6.32.6-armv5-ixp: WARNINGS linux-2.6.33-armv5-ixp: WARNINGS linux-2.6.34-rc1-armv5-ixp: WARNINGS linux-2.6.32.6-armv5-omap2: WARNINGS linux-2.6.33-armv5-omap2: WARNINGS linux-2.6.34-rc1-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-i686: WARNINGS linux-2.6.34-rc1-i686: WARNINGS linux-2.6.32.6-m32r: OK linux-2.6.33-m32r: OK linux-2.6.34-rc1-m32r: OK linux-2.6.32.6-mips: WARNINGS linux-2.6.33-mips: WARNINGS linux-2.6.34-rc1-mips: WARNINGS linux-2.6.32.6-powerpc64: WARNINGS linux-2.6.33-powerpc64: WARNINGS linux-2.6.34-rc1-powerpc64: WARNINGS 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-x86_64: WARNINGS linux-2.6.34-rc1-x86_64: WARNINGS linux-git-armv5: OK linux-git-armv5-davinci: OK linux-git-armv5-ixp: OK linux-git-armv5-omap2: OK linux-git-i686: WARNINGS linux-git-m32r: OK linux-git-mips: OK linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec: ERRORS spec-git: OK sparse: ERRORS linux-2.6.16.62-i686: WARNINGS linux-2.6.17.14-i686: WARNINGS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.7-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.62-x86_64: WARNINGS linux-2.6.17.14-x86_64: WARNINGS linux-2.6.18.8-x86_64: WARNINGS 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/Saturday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Saturday.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: av7110 and budget_av are broken!
On Saturday 20 March 2010 17:03:01 e9hack wrote: Am 20.3.2010 15:20, schrieb Hans Verkuil: Hartmut, is the problem with unloading the module something that my patch caused? Or was that there as well before changeset 14351:2eda2bcc8d6f? Are there any kernel messages indicating why it won't unload? Changset 14351:2eda2bcc8d6f causes a kernel oops during unload of the module for my dvb cards. OK, I know that. But does the patch I mailed you last time fix this problem without causing new ones? If so, then I'll post that patch to the list. Regards, Hans The call trace points to dvb_ttpci. I assumed, that the FF card is affected only. It may be possible, that budget-av does crash also, if it is unload as second. -- 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: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
On Saturday 20 March 2010 17:14:12 Devin Heitmueller wrote: On Sat, Mar 20, 2010 at 10:14 AM, Hans Verkuil hverk...@xs4all.nl wrote: Of course, the best solution is to convert the V4L1 apps to using V4L2. On that topic, if I wanted to ensure that an application was not using any V4L1 functionality, is there any easy way to do that? For example, can I just remove the #include videodev.h and fix whatever breaks? That should do the trick, yes. Regards, Hans Right now a problem is that there could easily be situations where an app uses V4L1 functionality without my knowledge, and it would be good if there were an easy way to audit the app and make sure it is doing V4L2 entirely (in fact, I had this issue in a few places with tvtime). Devin -- 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: RFC: Phase 1: Proposal to convert V4L1 drivers
On Saturday 20 March 2010 09:58:49 Hans Verkuil wrote: Kconfig mistakes: I found four errors in drivers/media/video/Kconfig: the saa7191, meye, mxb and cpia2 drivers are all marked as V4L1 only, while all support V4L2! The cpia2 driver supports both v4l1 and v4l2. I can test this driver and will look at removing the V4L1 support from that driver. The pwc driver also depends on V4L1, but also contains V4L2 support. Can someone test this driver? It is easy to remove the V4L1 code, but I'm not sure how well the V4L2 code works. Regards, Hans -- Hans Verkuil - video4linux developer - sponsored by TANDBERG -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 12/24] media/video: fix dangling pointers
On Saturday 20 March 2010 15:12:53 Wolfram Sang wrote: Fix I2C-drivers which missed setting clientdata to NULL before freeing the structure it points to. Also fix drivers which do this _after_ the structure was freed already. I feel I am missing something here. Why does clientdata have to be set to NULL when we are tearing down the device anyway? And if there is a good reason for doing this, then it should be done in v4l2_device_unregister_subdev or even in the i2c core, not in each drivers. And why does coccinelle apparently find this in e.g. cs5345.c but not in saa7115.c, which has exactly the same construct? For that matter, I think almost all v4l i2c drivers do this. Regards, Hans Signed-off-by: Wolfram Sang w.s...@pengutronix.de Cc: Mauro Carvalho Chehab mche...@infradead.org --- Found using coccinelle, then reviewed. Full patchset is available via kernel-janitors, linux-i2c, and LKML. --- drivers/media/video/cs5345.c |1 + drivers/media/video/cs53l32a.c |1 + drivers/media/video/ir-kbd-i2c.c |2 ++ drivers/media/video/tda9840.c|1 + drivers/media/video/tea6415c.c |1 + drivers/media/video/tea6420.c|1 + drivers/media/video/ths7303.c|1 + 7 files changed, 8 insertions(+), 0 deletions(-) diff --git a/drivers/media/video/cs5345.c b/drivers/media/video/cs5345.c index 57dc170..cd21aa8 100644 --- a/drivers/media/video/cs5345.c +++ b/drivers/media/video/cs5345.c @@ -196,6 +196,7 @@ static int cs5345_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_device_unregister_subdev(sd); + i2c_set_clientdata(client, NULL); kfree(sd); return 0; } diff --git a/drivers/media/video/cs53l32a.c b/drivers/media/video/cs53l32a.c index 80bca8d..527f731 100644 --- a/drivers/media/video/cs53l32a.c +++ b/drivers/media/video/cs53l32a.c @@ -199,6 +199,7 @@ static int cs53l32a_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_device_unregister_subdev(sd); + i2c_set_clientdata(client, NULL); kfree(sd); return 0; } diff --git a/drivers/media/video/ir-kbd-i2c.c b/drivers/media/video/ir-kbd-i2c.c index da18d69..f29c5cd 100644 --- a/drivers/media/video/ir-kbd-i2c.c +++ b/drivers/media/video/ir-kbd-i2c.c @@ -461,6 +461,7 @@ static int ir_probe(struct i2c_client *client, const struct i2c_device_id *id) return 0; err_out_free: + i2c_set_clientdata(client, NULL); kfree(ir); return err; } @@ -476,6 +477,7 @@ static int ir_remove(struct i2c_client *client) ir_input_unregister(ir-input); /* free memory */ + i2c_set_clientdata(client, NULL); kfree(ir); return 0; } diff --git a/drivers/media/video/tda9840.c b/drivers/media/video/tda9840.c index d381fce..b608aaf 100644 --- a/drivers/media/video/tda9840.c +++ b/drivers/media/video/tda9840.c @@ -188,6 +188,7 @@ static int tda9840_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_device_unregister_subdev(sd); + i2c_set_clientdata(client, NULL); kfree(sd); return 0; } diff --git a/drivers/media/video/tea6415c.c b/drivers/media/video/tea6415c.c index 1585839..49a6606 100644 --- a/drivers/media/video/tea6415c.c +++ b/drivers/media/video/tea6415c.c @@ -164,6 +164,7 @@ static int tea6415c_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_device_unregister_subdev(sd); + i2c_set_clientdata(client, NULL); kfree(sd); return 0; } diff --git a/drivers/media/video/tea6420.c b/drivers/media/video/tea6420.c index 6bf6bc7..821085d 100644 --- a/drivers/media/video/tea6420.c +++ b/drivers/media/video/tea6420.c @@ -146,6 +146,7 @@ static int tea6420_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_device_unregister_subdev(sd); + i2c_set_clientdata(client, NULL); kfree(sd); return 0; } diff --git a/drivers/media/video/ths7303.c b/drivers/media/video/ths7303.c index 21781f8..d411a73 100644 --- a/drivers/media/video/ths7303.c +++ b/drivers/media/video/ths7303.c @@ -114,6 +114,7 @@ static int ths7303_remove(struct i2c_client *client) struct v4l2_subdev *sd = i2c_get_clientdata(client); v4l2_device_unregister_subdev(sd); + i2c_set_clientdata(client, NULL); kfree(sd); return 0; -- 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: RFC: Phase 1: Proposal to convert V4L1 drivers
Hi, On 03/20/2010 09:58 AM, Hans Verkuil wrote: Hi all, Well, I certainly fired everyone up with my RFC. Based on the replies I got I do think the time is right to start the removal process. Phase 1 would be to convert the remaining V4L1 drivers. To see what needs to be done I decided to analyse the remaining V4L1 drivers: - usbvideo (really four drivers: vicam, ibmcam, konicawc, quickcam_messenger) Hans de Goede added support for the quickcam_messenger to gspca, so that driver is scheduled for removal. Devin has hardware to test the vicam driver. David Ellingsworth has hardware to test the ibmcam driver. It would be great if Devin and David can either send it to Hans de Goede or work on it themselves. The konicawc is for an Intel YC76 webcam. I found one for sale here: http://www.ecrater.com/product.php?pid=6593985 Unfortunately the seller does not ship to the Netherlands or to Norway. Can some kind US developer buy it and donate it to Hans de Goede? It's fairly expensive at $39.99, but it's for a good cause. So in theory all these drivers can be tested and converted. - bw-qcam A parallel port Connectix QuickCam webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. It is parallel port only so lets just drop it. - c-qcam A parallel port color Connectix QuickCam webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. It is parallel port only so lets just drop it. - w9966 A parallel port LifeView FlyCam Supra webcam. To my knowledge no one has hardware to test this. However, it should not be hard to convert this to V4L2, even without having hardware since this driver doesn't do any streaming or DMA. It is parallel port only so lets just drop it. - cpia_pp Parallel port webcam driver for the Creative Webcam II. I found one on eBay, so with luck I can get hold of the hardware and get it to HdG. Although I appreaciate your effort in getting this cam into my hands, I don't know what to with it once I have it, my stance on it can be summarized as: It is parallel port only so lets just drop it. - cpia_usb USB variant of cpia_pp. Deprecated since it is now supported by gspca. Ack, note that there is no sane way to make the gspca code also support the parallel port version, so if we would like to do that we would have to keep the pp part of the old cpia1 v4l1 driver which could do both pp and usb around, and convert that v4l2. snip So if we all pitch in, then can get everything converted without having to remove drivers. I'm not sure if the parallel port attached are worth keeping support for. But if someone else is willing to convert those, sure. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 1: Proposal to convert V4L1 drivers
Hi, On 03/20/2010 10:53 PM, Hans Verkuil wrote: On Saturday 20 March 2010 09:58:49 Hans Verkuil wrote: Kconfig mistakes: I found four errors in drivers/media/video/Kconfig: the saa7191, meye, mxb and cpia2 drivers are all marked as V4L1 only, while all support V4L2! The cpia2 driver supports both v4l1 and v4l2. I can test this driver and will look at removing the V4L1 support from that driver. The pwc driver also depends on V4L1, but also contains V4L2 support. Can someone test this driver? It is easy to remove the V4L1 code, but I'm not sure how well the V4L2 code works. I've a pwc using device. Actually I've 3 identical ones (all logitech quickcam pro 4000's). The pwc driver could indeed use some love from someone, but I've not yet found / made the time to look at it. It is working with the cams I have, but gets some corner cases (like unplug while streaming) wrong. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: RFC: Phase 2/3: Move the compat code into v4l1-compat. Convert apps.
Hi, On 03/20/2010 10:21 AM, Hans Verkuil wrote: Hi all! The second phase that needs to be done to remove the v4l1 support from the kernel is that libv4l1 should replace the v4l1-compat code from the kernel. I do not know how complete the libv4l1 code is right now. I would like to know in particular whether the VIDIOCGMBUF/mmap behavior can be faked in libv4l1 if drivers do not support the cgmbuf vidioc call. Yes it can, this for example already happens when using v4l1 apps with uvcvideo (which is not possible without libv4l1). The third phase that can be done in parallel is to convert V4L1-only apps. I strongly suspect that any apps that are V4L1-only are also unmaintained. We have discussed before that we should set up git repositories for such tools (xawtv being one of the more prominent apps since it contains several v4l1-only console apps). Once we have maintainership, then we can convert these tools to v4l2 and distros and other interested parties have a place to send patches to. As said before I wouldn't mind maintaining an xawtv git tree @ linuxtv, assuming this tree were to be based on the 3.95 release. Regards, Hans -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] saa7134: add capture boards Hawell HW-404M7 and HW-808M7
Hi Vladimir,
Am Samstag, den 20.03.2010, 17:58 +0300 schrieb Vladimir Ermakov:
Hi Hermann.
1. It's my mistake. Fixed.
2. Dead code. Removed.
thanks for looking at it.
We likely need your SOB line again, since it is a new patch.
Here is my
Reviewed-by: hermann pitton hermann-pit...@arcor.de
Cheers,
Hermann
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1269096094 -10800
# Node ID a91db2cf4f5774866c8c5bf906d9ac4faff9173d
# Parent 929298149eba4b6d0696124b9880113c25cd0788
saa7134: fix GPIO HW-404M7
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.c Thu Mar 18
23:47:27 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.c Sat Mar 20
17:41:34 2010 +0300
@@ -5403,12 +5403,12 @@
.radio_type= UNSET,
.tuner_addr = ADDR_UNSET,
.radio_addr = ADDR_UNSET,
- .gpiomask = 0x01fc00,
+ .gpiomask = 0x389c00,
.inputs = {{
.name = name_comp1,
.vmux = 3,
.amux = LINE1,
- .gpio = 0x389c00,
+ .gpio = 0x01fc00,
} },
},
diff -r 929298149eba -r a91db2cf4f57
linux/drivers/media/video/saa7134/saa7134-input.c
--- a/linux/drivers/media/video/saa7134/saa7134-input.c Thu Mar 18
23:47:27 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-input.c Sat Mar 20
17:41:34 2010 +0300
@@ -531,7 +531,6 @@
switch (dev-board) {
case SAA7134_BOARD_FLYVIDEO2000:
case SAA7134_BOARD_FLYVIDEO3000:
- case SAA7134_BOARD_HAWELL_HW_404M7:
case SAA7134_BOARD_FLYTVPLATINUM_FM:
case SAA7134_BOARD_FLYTVPLATINUM_MINI2:
case SAA7134_BOARD_ROVERMEDIA_LINK_PRO_FM:
В Птн, 19/03/2010 в 00:21 +0100, hermann pitton пишет:
Hi Vladimir,
thanks, your patch is already accepted, but if have a two comments.
Am Mittwoch, den 10.03.2010, 18:44 +0300 schrieb Vladimir Ermakov:
This patch adds new capture boards Hawell HW-404M7 and HW-808M7.
Those cards have 4 or 8 SAA7130 chips and for the work it only needs
initialize registers.
The value of those registers were dumped under Windows using flytest.
But board haven't EEPROM.
For the first chip:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389C00
Value: 0x00016C00
Later in the code you swapped mode (gpio mask) and value (out status).
This does not cause a functional problem in this case, but is visible
for example with saa7134 gpio_tracking=1.
Second, you did add the card to the flyvideo remotes in saa7134-input,
but this is only a line of dead code currently.
If it really has such a remote, you must also add the card to the switch
case dev-has_remote = SAA7134_REMOTE_GPIO in in the function
int saa7134_board_init1 in saa7134-cards.c or please remove it from
saa7134-input.c.
Thanks,
Hermann
Video input: 3
Audio input: Analog Line1
For other chips:
SAA7130 (0x7130, SubVenID:1131, SubDevID:, Rev: 01)
I2C slave devices found:
No devices
GPIO pins:
Mode : 0x00389200
Value: 0x0001
Video input: 3
Audio input: Analog Line1
Signed-off-by: Vladimir Ermakov vooon...@gmail.com
# HG changeset patch
# User Vladimir Ermakov vooon...@gmail.com
# Date 1268232221 -10800
# Node ID 072cd67c6aabe0e700a9e4727b50ad6424cb59f5
# Parent 7a58d924fb049ff1d318514939b3a7e416670c13
saa7134: add Hawell HW-404M7 HW-808M7
diff -r 7a58d924fb04 -r 072cd67c6aab
linux/Documentation/video4linux/CARDLIST.saa7134
--- a/linux/Documentation/video4linux/CARDLIST.saa7134 Tue Mar 09
23:00:59 2010 -0300
+++ b/linux/Documentation/video4linux/CARDLIST.saa7134 Wed Mar 10
17:43:41 2010 +0300
@@ -175,3 +175,4 @@
174 - Asus Europa Hybrid OEM [1043:4847]
175 - Leadtek Winfast DTV1000S [107d:6655]
176 - Beholder BeholdTV 505 RDS[:5051]
+177 - Hawell HW-404M7 / HW-808M7
diff -r 7a58d924fb04 -r 072cd67c6aab
linux/drivers/media/video/saa7134/saa7134-cards.c
--- a/linux/drivers/media/video/saa7134/saa7134-cards.cTue Mar 09
23:00:59 2010 -0300
+++ b/linux/drivers/media/video/saa7134/saa7134-cards.cWed Mar 10
17:43:41 2010 +0300
@@ -5394,6 +5394,23 @@
.amux = LINE2,
},
},
+ [SAA7134_BOARD_HAWELL_HW_404M7] = {
+ /* Hawell HW-404M7 Hawell HW-808M7 */
+ /* Bogoslovskiy Viktor bogo...@bk.ru */
+ .name = Hawell HW-404M7,
+ .audio_clock = 0x0020,
+ .tuner_type= UNSET,
+ .radio_type= UNSET,
+ .tuner_addr = ADDR_UNSET,
pinnacle pctv dvb-t 2000i
Any news about this card? Some time ago i read that it was on development the pinnacle DTV bridge, but i can't find any information now about this. lspci -vvnnnx 03:07.0 Multimedia controller [0480]: Pinnacle Systems Inc. Royal TS Function 1 [11bd:0040] Subsystem: Pinnacle Systems Inc. Device [11bd:0044] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (500ns min, 4000ns max), Cache Line Size: 4 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at fdcff000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied 00: bd 11 40 00 06 00 90 02 00 00 80 04 01 20 80 00 10: 00 f0 cf fd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 bd 11 44 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 02 10 03:07.1 Multimedia controller [0480]: Pinnacle Systems Inc. RoyalTS Function 2 [11bd:0041] Subsystem: Pinnacle Systems Inc. Device [11bd:0044] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (500ns min, 4000ns max), Cache Line Size: 4 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at fdcfe000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied 00: bd 11 41 00 06 00 90 02 00 00 80 04 01 20 80 00 10: 00 e0 cf fd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 bd 11 44 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 02 10 03:07.2 Multimedia controller [0480]: Pinnacle Systems Inc. Royal TS Function 3 [11bd:0042] Subsystem: Pinnacle Systems Inc. Device [11bd:0044] Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- INTx- Latency: 32 (500ns min, 4000ns max), Cache Line Size: 4 bytes Interrupt: pin A routed to IRQ 11 Region 0: Memory at fdcfd000 (32-bit, non-prefetchable) [size=4K] Capabilities: access denied 00: bd 11 42 00 06 00 90 02 00 00 80 04 01 20 80 00 10: 00 d0 cf fd 00 00 00 00 00 00 00 00 00 00 00 00 20: 00 00 00 00 00 00 00 00 00 00 00 00 bd 11 44 00 30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 02 10 -- 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
