Re: Webcam driver not working: drivers/media/video/gspca/ov519.c device 05a9:4519
I found the datasheet for OV7660: http://www.datasheetarchive.com/OV7660-datasheet.html http://www.datasheetarchive.com/pdf-datasheets/Datasheets-25/DSA-482031.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
[PATCH] V4L/DVB: dibx000_common: Restore i2c algo pointer
Commit a90f933507859941c4a58028d7593a80f57895c4 accidentally removed
the piece of code setting the i2c algo pointer. Restore it.
That's what happens when you put two code statements on the same
line...
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Mauro Carvalho Chehab mche...@redhat.com
---
Sorry about this, I didn't notice this uncommon construct when writing
the initial patch.
This should go to Linus ASAP.
drivers/media/dvb/frontends/dibx000_common.c |1 +
1 file changed, 1 insertion(+)
--- linux-2.6.37-rc1.orig/drivers/media/dvb/frontends/dibx000_common.c
2010-11-02 09:19:35.0 +0100
+++ linux-2.6.37-rc1/drivers/media/dvb/frontends/dibx000_common.c
2010-11-05 11:13:48.0 +0100
@@ -130,6 +130,7 @@ static int i2c_adapter_init(struct i2c_a
struct dibx000_i2c_master *mst)
{
strncpy(i2c_adap-name, name, sizeof(i2c_adap-name));
+ i2c_adap-algo = algo;
i2c_adap-algo_data = NULL;
i2c_set_adapdata(i2c_adap, mst);
if (i2c_add_adapter(i2c_adap) 0)
--
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
Fwd: Re: Warnings from latest -git
Forwarding to linux-media, which I somehow removed from the list of recipients. Also removing indentation from part of my message. Don't know how that happened. -- Forwarded Message -- Subject: Re: Warnings from latest -git Date: Friday 05 November 2010 From: Chris Clayton chris2...@googlemail.com To: Mauro Carvalho Chehab mche...@redhat.com Hi again, On 2 November 2010 19:09, Chris Clayton chris2...@googlemail.com wrote: Thanks for the reply, Mauro. On Tuesday 02 November 2010, Mauro Carvalho Chehab wrote: Em 30-10-2010 04:17, Chris Clayton escreveu: Hi, Please cc me on any reply as I'm not subscribed. Building v2.6.36-9452-g2d10d87 pulled this morning, I get: warning: (DVB_USB_DIB0700 MEDIA_SUPPORT DVB_CAPTURE_DRIVERS DVB_CORE DVB_USB !DVB_FE_CUSTOMISE) selects DVB_DIB8000 which has unmet direct dependencies (MEDIA_SUPPORT DVB_CAPTURE_DRIVERS DVB_FE_CUSTOMISE DVB_CORE I2C) It certainly requires further investigation. From your config file, we have, for dib0700: CONFIG_DVB_USB_DIB0700=m CONFIG_MEDIA_SUPPORT=m CONFIG_DVB_CAPTURE_DRIVERS=y CONFIG_DVB_CORE=m CONFIG_DVB_USB=m # CONFIG_DVB_FE_CUSTOMISE is not set And, for dib8000: CONFIG_MEDIA_SUPPORT=m CONFIG_DVB_CAPTURE_DRIVERS=y # CONFIG_DVB_FE_CUSTOMISE is not set CONFIG_DVB_CORE=m CONFIG_I2C=y Both dib0700 and dib8000 were marked as m: CONFIG_DVB_DIB8000=m CONFIG_DVB_USB_DIB0700=m So, in this specific example, it actually worked, but we need to find a fix for this bug. I may be wrong, but I don't see why DVB_FE_CUSTOMISE is a dependency in these two cases. When it is not set, all the FE drivers are built. When it is set, the user selects, which drivers are to be built, but what I think the select statements are doing is select drivers without which other selections the user has made make little sense. If that's correct, the DVB_FE_CUSTOMISE can simply be removed as dependencies. I've looked at and played around with the related Kconfig files.. The conflict arises because when DVB_USB_DIB_0700 is selected, it triggers the selection of DVB_DIB8000 if !DVB_FE_CUSTOMISE. However, the menu that DVB_DIB8000 is contained in an if DVB_FE_CUSTOMIZE block and that seems to make DVB_FE_CUSTOMIZE a direct dependency for DVB_DIB8000. I guess the intention of the if block was to simply switch the display of the menu on or off. There are identical truth conflicts involving DVB_TUNER_CUSTOMISE. The only way I have been able to avoid the warnings is by removing the if blocks that guard the frontend customisation menu, but simply doing that makes the related question about customisation look silly. I don't get this warning in 2.6.36, so I've checked recent changes to kconfig and 246cf9c26bf11f2bffbecea6e5bd222eee7b1df8 looks as if it will be the culprit. It's not a regression, however. It's a deliberate change to report the type of conflict we have here. It looks like we need a different scheme for controlling the visibility of the customisation menu. I'll look at the kconfig docs and see if I can figure anything out. Chris Let me know if that makes sense and, if it does, I'll bake a patch. I've now customised anyway, so teh warnings have gone away, but can soon revert that to test a fix. Thanks Chris Cheers, Mauro -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller --- -- The more I see, the more I know. The more I know, the less I understand. Changing Man - Paul Weller -- 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: OMAP3530 ISP irqs disabled
Hello all, I got it now!!! After adding debugfs support and observing my isp like a lynx I found out that magically the ISP_CTRL register changes from [ 316.903900] omap3isp omap3isp: ###ISP CTRL=0x0020 to 0x0020c040 after an successful image read :-) This is the shift configuration that should never be touched and the syn_detect register that changes from trigger interrupts on HS falling edge to VS rising edge. I saw that the these registers get written in the ccdc_configure - isp_configure_bridge - write_regs. Let's see if I can find out the concrete bug location. cheers, Bastian 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote: 2010/11/3 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Bastian Hecht wrote: 2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. It _might_ be better to have this in isp_get(). While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. That should definitely not be necessary. The interrupts are enabled in isp_get(). As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. Are you getting any other interrupts? Basically every ISP block which is on the pipe will produce interrupts. Which ISP block is writing the images to memory for you? I read out the CCDC with this pipeline: ./media-ctl -r -l 'mt9p031 2-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-005d:0[SGRBG10 2592x1944], OMAP3 ISP CCDC:1[SGRBG10 2592x1944]' ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 I get these interrupts while reading 4 frames: [ 3962.689483] s_stream is it! enable: 1 [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ [ 3967.242614] s_stream is it! enable: 0 Maybe a stupid question, but have you set exposure and gain to a reasonable value? :-) First reaction was - that must be it! But hmmm... the flanks on the data lines of the camera are mostly high. When I press my finger on the sensor they are mostly low. The other values seem to be good too: xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within the limits of the datasheets - camera and omap isp). cam_vs raises for about 1 sec goes shortly down and comes up again. cam_hs seems to fit too. Every 20th try I get data from an image sample the other times only zeros. The CCDC is configured with a DC subtract value of 64 by default, so it subtract 64 from every pixel. If your pixel values are lower than or equal to 64 you will get a black image. As a
Re: OMAP3530 ISP irqs disabled
2010/11/5 Bastian Hecht hec...@googlemail.com: Hello all, I got it now!!! After adding debugfs support and observing my isp like a lynx I found out that magically the ISP_CTRL register changes from [ 316.903900] omap3isp omap3isp: ###ISP CTRL=0x0020 to 0x0020c040 after an successful image read :-) Sorry false alarm... the bridge gets configured correctly for my 12- to 10-bit shift and the isp listens for VS for frame starts. It just was 0x0020 after reset and had to be set correctly. This is the shift configuration that should never be touched and the syn_detect register that changes from trigger interrupts on HS falling edge to VS rising edge. I saw that the these registers get written in the ccdc_configure - isp_configure_bridge - write_regs. Let's see if I can find out the concrete bug location. cheers, Bastian 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Bastian Hecht hec...@googlemail.com: 2010/11/4 Laurent Pinchart laurent.pinch...@ideasonboard.com: Hi Bastian, On Wednesday 03 November 2010 14:38:25 Bastian Hecht wrote: 2010/11/3 Sakari Ailus sakari.ai...@maxwell.research.nokia.com: Bastian Hecht wrote: 2010/11/3 Bastian Hecht hec...@googlemail.com: Hello ISP team, I succeeded to stream the first images from the sensor to userspace using Laurent's media-ctl and yafta. Unfortunately all images are black (10MB of zeros). Once by chance I streamed some images (1 of 20 about) with content. All values were 0x400, so that I assume the values were correctly transferred for my 10-bit pixels. I shortly describe my setup: As I need xclk_a activated for my sensor to work (I2C), I activate the xclk in the isp_probe function. Early hack that I want to remove later. It _might_ be better to have this in isp_get(). While I placed my activation in mid of the probe function, I had somehow the interrupts disabled when trying to stream using yafta. So I hacked in the reenabling of the interrupts somewhere else in probe() too. That should definitely not be necessary. The interrupts are enabled in isp_get(). As I dug through the isp code I saw that it is better to place the clock activation after the final isp_put in probe() then the interrupts keep working, but this way I never got a valid picture so far. It's all a mess, I know. I try to transfer the activation to my sensor code and board-setup code like in the et8ek8 code. I enabled isr debugging (#define ISP_ISR_DEBUG) and see that only 1 HS_VS_event is generated per second. 1fps corresponds to my clocking, so 1 vs per second is fine. But shouldn't I see about 2000 hs interrupts there too? HS_VS_IRQ is described as HS or VS synchro event. Are you getting any other interrupts? Basically every ISP block which is on the pipe will produce interrupts. Which ISP block is writing the images to memory for you? I read out the CCDC with this pipeline: ./media-ctl -r -l 'mt9p031 2-005d:0-OMAP3 ISP CCDC:0[1], OMAP3 ISP CCDC:1-OMAP3 ISP CCDC output:0[1]' ./media-ctl -f 'mt9p031 2-005d:0[SGRBG10 2592x1944], OMAP3 ISP CCDC:1[SGRBG10 2592x1944]' ./yavta -f SGRBG10 -s 2592x1944 -n 4 --capture=4 --skip 3 -F /dev/video2 I get these interrupts while reading 4 frames: [ 3962.689483] s_stream is it! enable: 1 [ 3962.783843] omap3isp omap3isp: CCDC_VD0_IRQ [ 3962.799530] omap3isp omap3isp: HS_VS_IRQ [ 3963.532958] omap3isp omap3isp: CCDC_VD1_IRQ [ 3963.899505] omap3isp omap3isp: CCDC_VD0_IRQ [ 3963.914184] omap3isp omap3isp: HS_VS_IRQ [ 3964.647644] omap3isp omap3isp: CCDC_VD1_IRQ [ 3965.013153] omap3isp omap3isp: CCDC_VD0_IRQ [ 3965.028839] omap3isp omap3isp: HS_VS_IRQ [ 3965.762298] omap3isp omap3isp: CCDC_VD1_IRQ [ 3966.127838] omap3isp omap3isp: CCDC_VD0_IRQ [ 3966.143585] omap3isp omap3isp: HS_VS_IRQ [ 3966.370788] omap3isp omap3isp: OMAP3 ISP AEWB: user wants to disable module. [ 3966.370819] omap3isp omap3isp: OMAP3 ISP AEWB: module is being disabled [ 3966.370849] omap3isp omap3isp: OMAP3 ISP AF: user wants to disable module. [ 3966.370880] omap3isp omap3isp: OMAP3 ISP AF: module is being disabled [ 3966.370880] omap3isp omap3isp: OMAP3 ISP histogram: user wants to disable module. [ 3966.370910] omap3isp omap3isp: OMAP3 ISP histogram: module is being disabled [ 3966.876983] omap3isp omap3isp: CCDC_VD1_IRQ [ 3967.242492] omap3isp omap3isp: CCDC_VD0_IRQ [ 3967.242614] s_stream is it! enable: 0 Maybe a stupid question, but have you set exposure and gain to a reasonable value? :-) First reaction was - that must be it! But hmmm... the flanks on the data lines of the camera are mostly high. When I press my finger on the sensor they are mostly low. The other values seem to be good too: xclk comes in with 6Mhz and pixelclk comes out with 6Mhz (all within the limits of the datasheets - camera and omap isp). cam_vs raises for about 1 sec goes shortly down and comes up again. cam_hs seems to fit too. Every 20th
Re: [RFC PATCH 0/2] Apple remote support
On Thu, 04 Nov 2010 15:43:33 -0400, Mauro Carvalho Chehab mche...@redhat.com wrote: Em 04-11-2010 15:38, David Härdeman escreveu: On Thu, Nov 04, 2010 at 11:54:25AM -0400, Jarod Wilson wrote: Okay, so we seem to be in agreement for an approach to handling this. I'll toss something together implementing that RSN... Though I talked with Mauro about this a bit yesterday here at LPC, and we're thinking maybe we slide this support back over into the nec decoder and make it a slightly more generic use full 32 bits NEC variant we look for and/or enable/disable somehow. I've got another remote here, for a Motorola cable box, which is NEC-ish, but always fails decode w/a checksum error (got 0x, iirc), which may also need to use the full 32 bits somehow... Probably a very important protocol variant to support, particularly once we have native transmit support, as its used by plenty of cable boxes on the major carriers here in the US. I've always found the checksum tests in the NEC decoder to be unnecessary so I'm all for using a 32 bit scancode in all cases (and still using a module param to squash the ID byte of apple remotes, defaulting to yes). This means changing all existing NEC tables to have 32 bits, and add the redundant information on all of them. Yep (though we should use macros to generate scancodes) It doesn't seem a good idea to me to add a penalty for those NEC tables that follow the standard. Which penalty? Using a 32 bit scancode won't affect keytable size or lookup speed. In some corner cases, additional keytable lookups will be performed for decoded scancodes which would otherwise be deemed invalid, but at the time that decision can be made, most of the processing (reading timing events from hardware, handing them to decoders, decoding them) has already been done. If you're referring to the pain caused by changing existing keytables (thereby breaking custom keytables), I think it's inevitable. Throwing away information is not a good solution. As this subsystem progresses, there's going to be more and more reports of remotes which, intentionally or unintentionally, do not follow the NEC standard (I use that word in the most liberal sense). Using the full 32 bits allows us to support them without any module parameters or code changes. Which solution do you suggest? -- David Härdeman -- 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: OMAP3530 ISP irqs disabled
Hi Bastian (Laurent, and Sakari), I want to clarify this: I try to read images with yafta. I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. I repeat the process some times and keep checking the data. After - let's say the 6th time - the images contain exactly the data I expect. WHEN they are read they are good. I just don't want to read 20 black images before 1 image is transferred right. -Bastian I'm on to your problem, having reproduced it myself. I suspect that you're actually only getting one frame: your very first buffer. You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame. If you clear the good frame in your application once, you won't get any more non-zero frames afterwards. Or if you request more buffers, you'll have fewer non-zero frames. That's the behavior I observe. The CCDC is getting disabled by the VD1 interrupt: ispccdc_vd1_isr()-__ispccdc_handle_stopping()-__ispccdc_enable(ccdc, 0) To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem. In fact, I was still getting VD1 interrupts even though I had disabled them. Has anybody else observed that VD1 cannot be disabled? I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled. Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it: --- a/drivers/media/video/isp/ispccdc.c +++ b/drivers/media/video/isp/ispccdc.c @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc) spin_lock_irqsave(ccdc-lsc.req_lock, flags); /* We are about to stop CCDC and/without LSC */ - if ((ccdc-output CCDC_OUTPUT_MEMORY) || + if ((ccdc-output CCDC_OUTPUT_MEMORY) (ccdc-state == ISP_PIPELINE_STREAM_SINGLESHOT)) ccdc-stopping = CCDC_STOP_REQUEST; -- Michael Jones MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: OMAP3530 ISP irqs disabled
2010/11/5 Michael Jones michael.jo...@matrix-vision.de: Hi Bastian (Laurent, and Sakari), I want to clarify this: I try to read images with yafta. I read in 4 images with 5MP size (no skipping). All 4 images contain only zeros. I repeat the process some times and keep checking the data. After - let's say the 6th time - the images contain exactly the data I expect. WHEN they are read they are good. I just don't want to read 20 black images before 1 image is transferred right. -Bastian I'm on to your problem, having reproduced it myself. I suspect that you're actually only getting one frame: your very first buffer. You don't touch it, and neither does the CCDC after you requeue it, and after you've cycled through all your other buffers, you get back the non-zero frame. If you clear the good frame in your application once, you won't get any more non-zero frames afterwards. Or if you request more buffers, you'll have fewer non-zero frames. That's the behavior I observe. I can confirm the very first buffer theorem. I indeed get 1 valid frame after each reboot. First I didn'notice it because I used Laurent's yafta --skip 3 ... command line. I read 4 frames and only saved the last. Btw, heaven sent you... I keep working on this problem 1 week now and am pretty desperate. I started reading about the linux memory management system to understand all the buffer dma streaming. (well that is probably not the worst thing to sacrifice time...) Tell me if I can do something for you to help. cheers, Bastian The CCDC is getting disabled by the VD1 interrupt: ispccdc_vd1_isr()-__ispccdc_handle_stopping()-__ispccdc_enable(ccdc, 0) To test this theory I tried disabling the VD1 interrupt, but it didn't solve the problem. In fact, I was still getting VD1 interrupts even though I had disabled them. Has anybody else observed that VD1 cannot be disabled? I also found it strange that the CCDC seemed to continue to generate interrupts when it's disabled. Here's my suggestion for a fix, hopefully Laurent or Sakari can comment on it: --- a/drivers/media/video/isp/ispccdc.c +++ b/drivers/media/video/isp/ispccdc.c @@ -1477,7 +1477,7 @@ static void ispccdc_vd1_isr(struct isp_ccdc_device *ccdc) spin_lock_irqsave(ccdc-lsc.req_lock, flags); /* We are about to stop CCDC and/without LSC */ - if ((ccdc-output CCDC_OUTPUT_MEMORY) || + if ((ccdc-output CCDC_OUTPUT_MEMORY) (ccdc-state == ISP_PIPELINE_STREAM_SINGLESHOT)) ccdc-stopping = CCDC_STOP_REQUEST; -- Michael Jones MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner -- 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: 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:Fri Nov 5 19:00:05 CET 2010 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 15167:abd3aac6644e git master: 3e6dce76d99b328716b43929b9195adfee1de00c git media-master: a348e9110ddb5d494e060d989b35dd1f35359d58 gcc version: i686-linux-gcc (GCC) 4.5.1 host hardware:x86_64 host os: 2.6.32.5 linux-git-armv5: WARNINGS linux-git-armv5-davinci: WARNINGS linux-git-armv5-ixp: WARNINGS linux-git-armv5-omap2: WARNINGS linux-git-i686: WARNINGS linux-git-m32r: WARNINGS linux-git-mips: WARNINGS linux-git-powerpc64: WARNINGS linux-git-x86_64: WARNINGS spec-git: OK sparse: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Friday.tar.bz2 The 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
[PATCH 1/3] i2c: Delete unused adapter IDs
Delete unused I2C adapter IDs. Special cases are: * I2C_HW_B_RIVA was still set in driver rivafb, however no other driver is ever looking for this value, so we can safely remove it. * I2C_HW_B_HDPVR is used in staging driver lirc_zilog, however no adapter ID is ever set to this value, so the code in question never runs. As the code additionally expects that I2C_HW_B_HDPVR may not be defined, we can delete it now and let the lirc_zilog driver maintainer rewrite this piece of code. Big thanks for Hans Verkuil for doing all the hard work :) Signed-off-by: Jean Delvare kh...@linux-fr.org Cc: Hans Verkuil hverk...@xs4all.nl Cc: Jarod Wilson ja...@redhat.com --- drivers/video/riva/rivafb-i2c.c |1 - include/linux/i2c-id.h | 22 -- 2 files changed, 23 deletions(-) --- linux-2.6.37-rc1.orig/include/linux/i2c-id.h2010-11-05 13:55:17.0 +0100 +++ linux-2.6.37-rc1/include/linux/i2c-id.h 2010-11-05 15:05:32.0 +0100 @@ -32,28 +32,6 @@ */ /* --- Bit algorithm adapters */ -#define I2C_HW_B_BT848 0x010005 /* BT848 video boards */ -#define I2C_HW_B_RIVA 0x010010 /* Riva based graphics cards */ -#define I2C_HW_B_ZR36067 0x010019 /* Zoran-36057/36067 based boards */ #define I2C_HW_B_CX2388x 0x01001b /* connexant 2388x based tv cards */ -#define I2C_HW_B_EM28XX0x01001f /* em28xx video capture cards */ -#define I2C_HW_B_CX2341X 0x010020 /* Conexant CX2341X MPEG encoder cards */ -#define I2C_HW_B_CX23885 0x010022 /* conexant 23885 based tv cards (bus1) */ -#define I2C_HW_B_AU08280x010023 /* auvitek au0828 usb bridge */ -#define I2C_HW_B_CX231XX 0x010024 /* Conexant CX231XX USB based cards */ -#define I2C_HW_B_HDPVR 0x010025 /* Hauppauge HD PVR */ - -/* --- SGI adapters*/ -#define I2C_HW_SGI_VINO0x16 - -/* --- SMBus only adapters */ -#define I2C_HW_SMBUS_W9968CF 0x04000d -#define I2C_HW_SMBUS_OV511 0x04000e /* OV511(+) USB 1.1 webcam ICs */ -#define I2C_HW_SMBUS_OV518 0x04000f /* OV518(+) USB 1.1 webcam ICs */ -#define I2C_HW_SMBUS_CAFE 0x040012 /* Marvell 88ALP01 CAFE cam */ - -/* --- Miscellaneous adapters */ -#define I2C_HW_SAA7146 0x06 /* SAA7146 video decoder bus */ -#define I2C_HW_SAA7134 0x09 /* SAA7134 video decoder bus */ #endif /* LINUX_I2C_ID_H */ --- linux-2.6.37-rc1.orig/drivers/video/riva/rivafb-i2c.c 2010-11-05 13:55:17.0 +0100 +++ linux-2.6.37-rc1/drivers/video/riva/rivafb-i2c.c2010-11-05 13:55:19.0 +0100 @@ -94,7 +94,6 @@ static int __devinit riva_setup_i2c_bus( strcpy(chan-adapter.name, name); chan-adapter.owner = THIS_MODULE; - chan-adapter.id= I2C_HW_B_RIVA; chan-adapter.class = i2c_class; chan-adapter.algo_data = chan-algo; chan-adapter.dev.parent= chan-par-pdev-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 2/3] i2c: Drivers shouldn't include linux/i2c-id.h
Drivers don't need to include linux/i2c-id.h, especially not when
they don't use anything that header file provides.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Michael Hunold mich...@mihu.de
Cc: Mauro Carvalho Chehab mche...@infradead.org
---
drivers/media/common/saa7146_i2c.c|1 -
drivers/media/video/ir-kbd-i2c.c |1 -
drivers/staging/olpc_dcon/olpc_dcon.c |1 -
3 files changed, 3 deletions(-)
--- linux-2.6.37-rc1.orig/drivers/media/common/saa7146_i2c.c2010-11-02
09:19:35.0 +0100
+++ linux-2.6.37-rc1/drivers/media/common/saa7146_i2c.c 2010-11-05
15:34:25.0 +0100
@@ -391,7 +391,6 @@ static int saa7146_i2c_xfer(struct i2c_a
/*/
/* i2c-adapter helper functions */
-#include linux/i2c-id.h
/* exported algorithm data */
static struct i2c_algorithm saa7146_algo = {
--- linux-2.6.37-rc1.orig/drivers/media/video/ir-kbd-i2c.c 2010-11-02
09:19:35.0 +0100
+++ linux-2.6.37-rc1/drivers/media/video/ir-kbd-i2c.c 2010-11-05
15:34:18.0 +0100
@@ -44,7 +44,6 @@
#include linux/errno.h
#include linux/slab.h
#include linux/i2c.h
-#include linux/i2c-id.h
#include linux/workqueue.h
#include media/ir-core.h
--- linux-2.6.37-rc1.orig/drivers/staging/olpc_dcon/olpc_dcon.c 2010-11-02
09:19:37.0 +0100
+++ linux-2.6.37-rc1/drivers/staging/olpc_dcon/olpc_dcon.c 2010-11-05
15:34:14.0 +0100
@@ -17,7 +17,6 @@
#include linux/console.h
#include linux/i2c.h
#include linux/platform_device.h
-#include linux/i2c-id.h
#include linux/pci.h
#include linux/pci_ids.h
#include linux/interrupt.h
--
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 3/3] i2c: Mark i2c_adapter.id as deprecated
It's about time to make it clear that i2c_adapter.id is deprecated.
Hopefully this will remind the last user to move over to a different
strategy.
Signed-off-by: Jean Delvare kh...@linux-fr.org
Cc: Hans Verkuil hverk...@xs4all.nl
Cc: Jarod Wilson ja...@redhat.com
---
drivers/i2c/i2c-mux.c |1 -
include/linux/i2c.h |2 +-
2 files changed, 1 insertion(+), 2 deletions(-)
--- linux-2.6.37-rc1.orig/include/linux/i2c.h 2010-11-05 13:55:17.0
+0100
+++ linux-2.6.37-rc1/include/linux/i2c.h2010-11-05 15:41:20.0
+0100
@@ -353,7 +353,7 @@ struct i2c_algorithm {
*/
struct i2c_adapter {
struct module *owner;
- unsigned int id;
+ unsigned int id __deprecated;
unsigned int class; /* classes to allow probing for */
const struct i2c_algorithm *algo; /* the algorithm to access the bus */
void *algo_data;
--- linux-2.6.37-rc1.orig/drivers/i2c/i2c-mux.c 2010-11-05 16:06:18.0
+0100
+++ linux-2.6.37-rc1/drivers/i2c/i2c-mux.c 2010-11-05 16:06:33.0
+0100
@@ -120,7 +120,6 @@ struct i2c_adapter *i2c_add_mux_adapter(
snprintf(priv-adap.name, sizeof(priv-adap.name),
i2c-%d-mux (chan_id %d), i2c_adapter_id(parent), chan_id);
priv-adap.owner = THIS_MODULE;
- priv-adap.id = parent-id;
priv-adap.algo = priv-algo;
priv-adap.algo_data = priv;
priv-adap.dev.parent = parent-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] [media] gspca - main: Fix a regression with the PS3 Eye webcam
From: =?UTF-8?q?Jean-Fran=C3=A7ois=20Moine?= moin...@free.fr
commit f43402fa55bf5e7e190c176343015122f694857c upstream.
When audio is present, some alternate settings were skipped.
This prevented some webcams to work, especially when bulk transfer was used.
This patch permits to use the last or only alternate setting.
Reported-by: Antonio Ospite osp...@studenti.unina.it
Tested-by: Antonio Ospite osp...@studenti.unina.it
Signed-off-by: Jean-François Moine moin...@free.fr
Signed-off-by: Mauro Carvalho Chehab mche...@redhat.com
---
This is to be applied to 2.6.36 only, as the regression was introduced there.
I don't know how many distributors are shipping 2.6.36 and how urgent this can
be, but FYI without this change video capture on the Playstation Eye (gspca
ov534 driver) does not work at all.
Regards,
Antonio
drivers/media/video/gspca/gspca.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/media/video/gspca/gspca.c
b/drivers/media/video/gspca/gspca.c
index 0fb48c0..c64299d 100644
--- a/drivers/media/video/gspca/gspca.c
+++ b/drivers/media/video/gspca/gspca.c
@@ -652,7 +652,7 @@ static struct usb_host_endpoint *get_ep(struct gspca_dev
*gspca_dev)
: USB_ENDPOINT_XFER_ISOC;
i = gspca_dev-alt; /* previous alt setting */
if (gspca_dev-cam.reverse_alts) {
- if (gspca_dev-audio)
+ if (gspca_dev-audio i gspca_dev-nbalt - 2)
i++;
while (++i gspca_dev-nbalt) {
ep = alt_xfer(intf-altsetting[i], xfer);
@@ -660,7 +660,7 @@ static struct usb_host_endpoint *get_ep(struct gspca_dev
*gspca_dev)
break;
}
} else {
- if (gspca_dev-audio)
+ if (gspca_dev-audio i 1)
i--;
while (--i = 0) {
ep = alt_xfer(intf-altsetting[i], xfer);
--
1.7.2.3
--
To unsubscribe from this list: send the line unsubscribe linux-media in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] soc-camera fixes for 2.6.37
Hi Mauro Please, pull a couple of fixes for 2.6.37. TBH, two of them are not very critical, of which one (SOC Camera: OMAP1: typo fix) is purely cosmetical - it fixes a typo in a comment. But at least it's trivial, since it cannot cause any regressions. And the other non-critical one (SoC Camera: ov6650: minor cleanups) does change handling of an impossible switch case from silently ignoring to erroring out, which is an improvement! The following changes since commit 7655e594945289b418af39f6669fea4666a7b520: [media] af9015: Fix max I2C message size when used with tda18271 (2010-10-27 15:02:35 -0200) are available in the git repository at: git://linuxtv.org/gliakhovetski/v4l-dvb.git 2.6.37-rc1-fixes Janusz Krzysztofik (4): SoC Camera: OMAP1: update for recent framework changes SoC Camera: OMAP1: update for recent videobuf changes SOC Camera: OMAP1: typo fix SoC Camera: ov6650: minor cleanups Sascha Hauer (1): ARM mx3_camera: check for DMA engine type drivers/media/video/mx3_camera.c |4 drivers/media/video/omap1_camera.c | 16 drivers/media/video/ov6650.c |4 +--- 3 files changed, 13 insertions(+), 11 deletions(-) Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ -- To unsubscribe from this list: send the line unsubscribe linux-media in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Tevii S470 on Debian Squeeze
Thanks to Pedro i make it working, it works this way: mkdir /usr/local/src/dvb cd /usr/local/src/dvb wget http://tevii.com/100315_Beta_linux_tevii_ds3000.rar unrar x 100315_Beta_linux_tevii_ds3000.rar cp *.fw /lib/firmware tar xjvf linux-tevii-ds3000.tar.bz2 cd linux-tevii-ds3000 make make install I have the adapter, but I can't use the remote and can't compile SASC. I want to try the liplianin drivers. Is there any way to get ir working on this card? Thanks and best regards. 2010/11/4 Josu Lazkano josu.lazk...@gmail.com: Hello, I am having some problems to get working my Tevii S470 DVB-S2 PCIe card. I am using a Debian Squeeze (2.6.32-5-686) system on a Intel Atom 330 (Nvidia ION) machine. I read the LinuxTV wiki: http://www.linuxtv.org/wiki/index.php/TeVii_S470#Older_kernels These are my steps: 1. Donwloas the Tevii driver: wget -c http://tevii.com/tevii_ds3000.tar.gz tar zxfv tevii_ds3000.tar.gz su cp tevii_ds3000/dvb-fe-ds3000.fw /lib/firmware/ 2. Download s2-liplianin: hg clone http://mercurial.intuxication.org/hg/s2-liplianin 3. When I run make I have some warnings and errors: (all the log from make: http://dl.dropbox.com/u/1541853/tevii/s2-liplianin_make) make[5]: *** [/home/lazkano/s2-liplianin/v4l/ir-sysfs.o] Error 1 make[4]: *** [_module_/home/lazkano/s2-liplianin/v4l] Error 2 This is my card info: $ lspci | grep CX23885 05:00.0 Multimedia video controller: Conexant Systems, Inc. CX23885 PCI Video and Audio Decoder (rev 02) Can you help with this? Thanks for all your help and best regards -- Josu Lazkano -- Josu Lazkano -- 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
