Re: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Mon, Nov 9, 2009 at 3:47 PM, Barry Williams wrote: > On Mon, Nov 9, 2009 at 3:17 PM, Devin Heitmueller > wrote: >> On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams wrote: >>> Devin >>> Attached is the output from dmesg, I hope you're right >>> Thanks >>> Barry >> >> Ah, based on the dmesg I can see it wasn't what I thought it was (I >> saw it was dib7000 and improperly assumed it had an xc3028 tuner like >> the rev1 board does). >> >> You should probably start a new thread on the mailing list regarding >> the problems you are having with this tuner. And you will probably >> need to bisect the v4l-dvb tree and see when the breakage was >> introduced. >> >> Devin >> >> -- >> Devin J. Heitmueller - Kernel Labs >> http://www.kernellabs.com >> > > I'd be happy to help with that however I am unfamiliar with the > concept of bisecting a tree if you could provide more info that would > be helpful and then I will start a new thread with the information I > can gather. > Thanks > Barry > I appear to be good at doing silly things I of course forgot I unplugged the antenna cable from my first box to watch normal tv so that is why it is not tuning. However now my rev 1 tuner appears to no longer be working mythtv says it is asleep here is the output from dmesg. [0.00] Initializing cgroup subsys cpuset [0.00] Initializing cgroup subsys cpu [0.00] Linux version 2.6.31-14-generic (bui...@rothera) (gcc version 4.4.1 (Ubuntu 4.4.1-4ubuntu8) ) #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 (Ubuntu 2.6.31-14.48-generic) [0.00] KERNEL supported cpus: [0.00] Intel GenuineIntel [0.00] AMD AuthenticAMD [0.00] NSC Geode by NSC [0.00] Cyrix CyrixInstead [0.00] Centaur CentaurHauls [0.00] Transmeta GenuineTMx86 [0.00] Transmeta TransmetaCPU [0.00] UMC UMC UMC UMC [0.00] BIOS-provided physical RAM map: [0.00] BIOS-e820: - 0009fc00 (usable) [0.00] BIOS-e820: 0009fc00 - 000a (reserved) [0.00] BIOS-e820: 000f - 0010 (reserved) [0.00] BIOS-e820: 0010 - 3fff (usable) [0.00] BIOS-e820: 3fff - 3fff8000 (ACPI data) [0.00] BIOS-e820: 3fff8000 - 4000 (ACPI NVS) [0.00] BIOS-e820: fec0 - fec01000 (reserved) [0.00] BIOS-e820: fee0 - fee01000 (reserved) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] DMI 2.3 present. [0.00] AMI BIOS detected: BIOS may corrupt low RAM, working around it. [0.00] e820 update range: - 0001 (usable) ==> (reserved) [0.00] last_pfn = 0x3fff0 max_arch_pfn = 0x10 [0.00] MTRR default type: uncachable [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-C7FFF write-protect [0.00] C8000-E uncachable [0.00] F-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 0 mask FC000 write-back [0.00] 1 disabled [0.00] 2 disabled [0.00] 3 disabled [0.00] 4 disabled [0.00] 5 base 0E000 mask FF800 write-combining [0.00] 6 disabled [0.00] 7 disabled [0.00] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [0.00] Scanning 0 areas for low memory corruption [0.00] modified physical RAM map: [0.00] modified: - 0001 (reserved) [0.00] modified: 0001 - 0009fc00 (usable) [0.00] modified: 0009fc00 - 000a (reserved) [0.00] modified: 000f - 0010 (reserved) [0.00] modified: 0010 - 3fff (usable) [0.00] modified: 3fff - 3fff8000 (ACPI data) [0.00] modified: 3fff8000 - 4000 (ACPI NVS) [0.00] modified: fec0 - fec01000 (reserved) [0.00] modified: fee0 - fee01000 (reserved) [0.00] modified: fff8 - 0001 (reserved) [0.00] initial memory mapped : 0 - 00c0 [0.00] init_memory_mapping: -377fe000 [0.00] Using x86 segment limits to approximate NX protection [0.00] 00 - 40 page 4k [0.00] 40 - 003740 page 2M [0.00] 003740 - 00377fe000 page 4k [0.00] kernel direct mapping tables up to 377fe000 @ 1-15000 [0.00] RAMDISK: 2f8e8000 - 3003314d [0.00] ACPI: RSDP 000fa9e0 00014 (v00 AMI ) [0.00] ACPI: RSDT 3fff 0002C (v01 AMIINT VIA_K7 0010 MSFT 0097) [0.0
Re: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Mon, Nov 9, 2009 at 3:17 PM, Devin Heitmueller wrote: > On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams wrote: >> Devin >> Attached is the output from dmesg, I hope you're right >> Thanks >> Barry > > Ah, based on the dmesg I can see it wasn't what I thought it was (I > saw it was dib7000 and improperly assumed it had an xc3028 tuner like > the rev1 board does). > > You should probably start a new thread on the mailing list regarding > the problems you are having with this tuner. And you will probably > need to bisect the v4l-dvb tree and see when the breakage was > introduced. > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > I'd be happy to help with that however I am unfamiliar with the concept of bisecting a tree if you could provide more info that would be helpful and then I will start a new thread with the information I can gather. Thanks Barry -- 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sun, Nov 8, 2009 at 11:35 PM, Barry Williams wrote: > Devin > Attached is the output from dmesg, I hope you're right > Thanks > Barry Ah, based on the dmesg I can see it wasn't what I thought it was (I saw it was dib7000 and improperly assumed it had an xc3028 tuner like the rev1 board does). You should probably start a new thread on the mailing list regarding the problems you are having with this tuner. And you will probably need to bisect the v4l-dvb tree and see when the breakage was introduced. 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sun, Nov 8, 2009 at 10:58 PM, Barry Williams wrote: > Hi Devin > I did not reboot after installing the patch somehow I thought simply > removing the module (as I had done to restore some stability to my > system) and reloading the module after the patch would be all I need. > Well I learned that is not the case my apologies for not trying that > first. So your tree fixed my second system with the rev 1 tuner. > However my first system with the rev 2 card while now stable with your > tree will not tune. > Barry Ok, good. So now we just need to nail down why the 0fe9:db98 board doesn't work. Fortunately, I think I know what that bug is too. Try this: 1. Reboot the system. 2. Perform a single tuning attempt. 3. Send the full dmesg output starting at the time the box is booted. If you're lucky, it's the issue I think it is, which will result in a one-line patch. 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Mon, Nov 9, 2009 at 1:04 PM, Devin Heitmueller wrote: > On Sun, Nov 8, 2009 at 9:01 PM, Barry Williams wrote: >> On the first box I have >> Bus 003 Device 003: ID 0fe9:db98 DVICO >> Bus 003 Device 002: ID 0fe9:db98 DVICO >> >> on the second >> Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 >> (ZL10353+xc2028/xc3028) (initialized) >> Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 >> (ZL10353+xc2028/xc3028) (initialized) > > And on which of the two systems are you still having the tuning > problem with? Also, did you reboot after you installed the patch? > > Devin > > -- > Devin J. Heitmueller - Kernel Labs > http://www.kernellabs.com > Hi Devin I did not reboot after installing the patch somehow I thought simply removing the module (as I had done to restore some stability to my system) and reloading the module after the patch would be all I need. Well I learned that is not the case my apologies for not trying that first. So your tree fixed my second system with the rev 1 tuner. However my first system with the rev 2 card while now stable with your tree will not tune. Barry -- 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sun, Nov 8, 2009 at 9:54 PM, Robert Lowery wrote: >> On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller >> wrote: >>> On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams >>> wrote: Hi Devin I tried your tree and I seem to get the same problem on one box I get the flood of 'dvb-usb: bulk message failed: -110 (1/0'. >>> >>> >>> Can you please confirm the USB ID of the board you are having the >>> problem with (by running "lsusb" from a terminal window)? >>> >>> Thanks, >>> >>> Devin >>> -- >> >> >> On the first box I have >> Bus 003 Device 003: ID 0fe9:db98 DVICO >> Bus 003 Device 002: ID 0fe9:db98 DVICO >> >> on the second >> Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 >> (ZL10353+xc2028/xc3028) (initialized) >> Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 >> (ZL10353+xc2028/xc3028) (initialized) >> -- >> 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 >> > Barry, > > I have the Dual Digital 4 rev1 card which corresponds to the 0fe9:db78 > card. 0fe9:db98 is the Dual Digital 4 rev2 card which I believe uses > completely different hardware and it's behavior is unchanged by my patch > which only targets the rev1 card. > > I suspect the problems you are still reporting are from the different > cards, completely unrelated to my fix. > > Would you be able to retest after removing the rev2 cards from the machine? > > -Rob Robert, It's worth noting that the introduction of the i2c gate stuff in the zl10353 broke essentially *all* cards that use that demod except for the one that prompted the change. I've been incrementally going through the cards and fixing it as people report it. Since both of his cards use the zl10353, it wouldn't surprise me that his other board is broken for the same reason (which would require an additional patch). 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
> On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller > wrote: >> On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams >> wrote: >>> Hi Devin >>> I tried your tree and I seem to get the same problem on one box I get >>> the flood of 'dvb-usb: bulk message failed: -110 (1/0'. >> >> >> Can you please confirm the USB ID of the board you are having the >> problem with (by running "lsusb" from a terminal window)? >> >> Thanks, >> >> Devin >> -- > > > On the first box I have > Bus 003 Device 003: ID 0fe9:db98 DVICO > Bus 003 Device 002: ID 0fe9:db98 DVICO > > on the second > Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 > (ZL10353+xc2028/xc3028) (initialized) > Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 > (ZL10353+xc2028/xc3028) (initialized) > -- > 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 > Barry, I have the Dual Digital 4 rev1 card which corresponds to the 0fe9:db78 card. 0fe9:db98 is the Dual Digital 4 rev2 card which I believe uses completely different hardware and it's behavior is unchanged by my patch which only targets the rev1 card. I suspect the problems you are still reporting are from the different cards, completely unrelated to my fix. Would you be able to retest after removing the rev2 cards from the machine? -Rob -- 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sun, Nov 8, 2009 at 9:01 PM, Barry Williams wrote: > On the first box I have > Bus 003 Device 003: ID 0fe9:db98 DVICO > Bus 003 Device 002: ID 0fe9:db98 DVICO > > on the second > Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 > (ZL10353+xc2028/xc3028) (initialized) > Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 > (ZL10353+xc2028/xc3028) (initialized) And on which of the two systems are you still having the tuning problem with? Also, did you reboot after you installed the patch? 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
Hi Barry, did you try cold-booting either system? how are you tuning? mythtv? Cheers Vince On 11/9/09, Barry Williams wrote: > On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller > wrote: >> On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams >> wrote: >>> Hi Devin >>> I tried your tree and I seem to get the same problem on one box I get >>> the flood of 'dvb-usb: bulk message failed: -110 (1/0'. >> >> >> Can you please confirm the USB ID of the board you are having the >> problem with (by running "lsusb" from a terminal window)? >> >> Thanks, >> >> Devin >> -- > > > On the first box I have > Bus 003 Device 003: ID 0fe9:db98 DVICO > Bus 003 Device 002: ID 0fe9:db98 DVICO > > on the second > Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 > (ZL10353+xc2028/xc3028) (initialized) > Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 > (ZL10353+xc2028/xc3028) (initialized) > -- > To unsubscribe from this list: send the line "unsubscribe linux-media" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners
Am Sonntag, den 08.11.2009, 22:43 -0200 schrieb Mauro Carvalho Chehab: > Em Mon, 09 Nov 2009 00:32:29 +0100 > hermann pitton escreveu: > > > > I agree. An interesting case happens with devices that uses tda10046 DVB > > > demods. > > > They have the firmware stored internally on their eeprom. Those firmwares > > > can be > > > replaced by a different version loaded in ram, but, in general, they work > > > properly with the eeprom one. So, even having the firmware load code > > > there, > > > the firmware at /lib/firmware is optional. > > > > Mauro, that could lead to some misunderstanding of the current use > > conditions, at least on saa7134. > > > > Minor annotations, the tda10046 does not store firmware internally, but > > there are cards which have an extra eeprom to store such firmware. > > > > If such a firmware eeprom is found and correctly configured, the driver > > in all cases will load the firmware from that eeprom and all other > > firmware in /lib/firmware is ignored. > > > > If not, the firmware will be loaded from /lib/firmware. > > > > For all what I know, firmware revisions 26 and 29 are both valid > > "enough", correspondents to what we can load either from TechnoTrend or > > LifeView with the getfirmware script, and might be either stored in an > > extra eeprom or loaded from host/file. > > > > Prior revisions had issues with missing freqs, in what combination ever. > > > > We also can't totally exclude, given the whole mass of such, that in > > some cases firmware eeproms might exist on some boards, but are not > > correctly configured and load from host only because of that. > > > > The tendency seen overall is that competitors save the few cents for an > > extra firmware eeprom these days ... > > Yes, I know. I have myself a Cardbus device with such eeprom (I think it has > revision 29 stored at the eeprom). > > The point is that it is not mandatory for such devices to have a firmware > at the filesystem for the device to work. So, a static indication that > devices with tda10046 need firmware is wrong, since some devices don't need > it. There are of course lots of devices needing the firmware mandatory at the file system. I try to tell that it is not a mistake, in case the device has no firmware on an extra eeprom, to store latest revision in /lib/firmware. Or tell me better ... But also, OEMs a little bit more motivated on new hardware will not count the costs of an extra firmware eeprom, if being first in having substantial amounts of chips and get a good deal for such. But that was the past. > Cheers, > Mauro Else I do totally agree. I do just point to some ambiguous conditions we should stay aware of. It is very unlikely that we can "talk" them away. Do we have all firmware loaded from eeproms possibly existing on cards is only one minor question. Maybe we miss some. Should we not even better avoid such, since still no official update for firmware eeprom flashing? To restore the bridge eeprom we seem to be not such bad now, but also the reasons for a possible corruption are far from clearly identified in case we should be involved in it. Despite of legal issues, we should have the latest revision of the tda10046 firmware at the host. As said, those having it at an extra eeprom will load it anyway from there. Cheers, Hermann -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Mon, Nov 9, 2009 at 12:22 PM, Devin Heitmueller wrote: > On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams wrote: >> Hi Devin >> I tried your tree and I seem to get the same problem on one box I get >> the flood of 'dvb-usb: bulk message failed: -110 (1/0'. > > > Can you please confirm the USB ID of the board you are having the > problem with (by running "lsusb" from a terminal window)? > > Thanks, > > Devin > -- On the first box I have Bus 003 Device 003: ID 0fe9:db98 DVICO Bus 003 Device 002: ID 0fe9:db98 DVICO on the second Bus 001 Device 003: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 (ZL10353+xc2028/xc3028) (initialized) Bus 001 Device 002: ID 0fe9:db78 DVICO FusionHDTV DVB-T Dual Digital 4 (ZL10353+xc2028/xc3028) (initialized) -- 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sun, Nov 8, 2009 at 8:43 PM, Barry Williams wrote: > Hi Devin > I tried your tree and I seem to get the same problem on one box I get > the flood of 'dvb-usb: bulk message failed: -110 (1/0'. Can you please confirm the USB ID of the board you are having the problem with (by running "lsusb" from a terminal window)? 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
Devin Heitmueller wrote: > On Sun, Nov 8, 2009 at 6:46 PM, Barry Williams wrote: >> Where would I find your local tree as I can't seem to get the patch to >> apply and I would like to take advantage of this patch asap. >> Thanks >> Barry > > I pushed out my tree with the fix: > > http://kernellabs.com/hg/~dheitmueller/misc-fixes-4 > > I haven't issued a PULL yet to put it into the mainline since I have a > couple of other things pending. > > Devin > Hi Devin I tried your tree and I seem to get the same problem on one box I get the flood of 'dvb-usb: bulk message failed: -110 (1/0'. Scan shows: 'ATAL: failed to open '/dev/dvb/adapter0/frontend0': 2 No such file or directory on adapter0' and fails to tune adapter1 with : scanning /usr/share/dvb/dvb-t/au-Adelaide using '/dev/dvb/adapter1/frontend0' and '/dev/dvb/adapter1/demux0' initial transponder 22650 1 3 9 3 1 1 0 initial transponder 17750 1 3 9 3 1 1 0 initial transponder 191625000 1 3 9 3 1 1 0 initial transponder 21950 1 3 9 3 1 1 0 initial transponder 56450 1 2 9 3 1 2 0 >>> tune to: >>> 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 22650:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE >>> (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: >>> 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 17750:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE >>> (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: >>> 191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 191625000:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE >>> (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: >>> 21950:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 21950:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_3_4:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_16:HIERARCHY_NONE >>> (tuning failed) WARNING: >>> tuning failed!!! >>> tune to: >>> 56450:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE WARNING: >>> tuning failed!!! >>> tune to: >>> 56450:INVERSION_AUTO:BANDWIDTH_7_MHZ:FEC_2_3:FEC_AUTO:QAM_64:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_8:HIERARCHY_NONE >>> (tuning failed) WARNING: >>> tuning failed!!! ERROR: initial tuning failed dumping lists (0 services) Done. On my second box with the same card I get a flood of : [12341.364016] dvb-usb: bulk message failed: -2 (4/0) [12341.364019] cxusb: i2c read failed but similar results with scan. Barry -- 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/scripts: Fix make checkpatch operation with in tree checkpatch.pl
Mauro,
make checkpatch wasn't working for me.
I found that the new version of checkpatch.pl that's in the v4l/dvb tree
doesn't emit a version number unless explicitly requested.
This patch gets 'make checkpatch' working (and complaining again) for
me.
Regards,
Andy
Signed-off-by: Andy Walls
diff -r d2aaff136907 v4l/scripts/check.pl
--- a/v4l/scripts/check.pl Thu Nov 05 19:51:24 2009 -0500
+++ b/v4l/scripts/check.pl Sun Nov 08 20:40:06 2009 -0500
@@ -56,11 +56,13 @@
}
close IN;
-my $intree_checkpatch = "scripts/checkpatch.pl --no-tree --strict";
+my $intree_checkpatch = "scripts/checkpatch.pl --version ";
if (!open IN,"$intree_checkpatch|") {
$intree_checkpatch = "v4l/".$intree_checkpatch;
open IN,"$intree_checkpatch|";
}
+$intree_checkpatch =~ s/--version/--no-tree --strict/;
+
while () {
tr/A-Z/a-z/;
if (m/version\s*:\s*([\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
Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners
Em Mon, 09 Nov 2009 00:32:29 +0100 hermann pitton escreveu: > > I agree. An interesting case happens with devices that uses tda10046 DVB > > demods. > > They have the firmware stored internally on their eeprom. Those firmwares > > can be > > replaced by a different version loaded in ram, but, in general, they work > > properly with the eeprom one. So, even having the firmware load code there, > > the firmware at /lib/firmware is optional. > > Mauro, that could lead to some misunderstanding of the current use > conditions, at least on saa7134. > > Minor annotations, the tda10046 does not store firmware internally, but > there are cards which have an extra eeprom to store such firmware. > > If such a firmware eeprom is found and correctly configured, the driver > in all cases will load the firmware from that eeprom and all other > firmware in /lib/firmware is ignored. > > If not, the firmware will be loaded from /lib/firmware. > > For all what I know, firmware revisions 26 and 29 are both valid > "enough", correspondents to what we can load either from TechnoTrend or > LifeView with the getfirmware script, and might be either stored in an > extra eeprom or loaded from host/file. > > Prior revisions had issues with missing freqs, in what combination ever. > > We also can't totally exclude, given the whole mass of such, that in > some cases firmware eeproms might exist on some boards, but are not > correctly configured and load from host only because of that. > > The tendency seen overall is that competitors save the few cents for an > extra firmware eeprom these days ... Yes, I know. I have myself a Cardbus device with such eeprom (I think it has revision 29 stored at the eeprom). The point is that it is not mandatory for such devices to have a firmware at the filesystem for the device to work. So, a static indication that devices with tda10046 need firmware is wrong, since some devices don't need it. Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sun, Nov 8, 2009 at 6:46 PM, Barry Williams wrote: > Where would I find your local tree as I can't seem to get the patch to > apply and I would like to take advantage of this patch asap. > Thanks > Barry I pushed out my tree with the fix: http://kernellabs.com/hg/~dheitmueller/misc-fixes-4 I haven't issued a PULL yet to put it into the mainline since I have a couple of other things pending. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 10/75] V4L/DVB: declare MODULE_FIRMWARE for modules using XC2028 and XC3028L tuners
Hi, Am Sonntag, den 08.11.2009, 01:20 -0200 schrieb Mauro Carvalho Chehab: > Hi Ben, > > > > It's not clear to me what this MODULE_FIRMWARE is going to be used > > > for, but if it's for some sort of module dependency system, then it > > > definitely should *not* be a dependency for em28xx. There are lots of > > > em28xx based devices that do not use the xc3028, and those users > > > should not be expected to go out and find/extract the firmware for > > > some tuner they don't have. > > > > This information is currently used by initramfs builders to find > > required firmware files. I also use this information in the Debian > > kernel upgrade script to warn if a currently loaded driver may require > > firmware in the new kernel version and the firmware is not installed. > > This is important during the transition of various drivers from built-in > > to separate firmware. > > > > Neither of these uses applies to TV tuners, but the information may > > still be useful in installers. > > > > Also, how does this approach handle the situation where there are two > > > different possible firmwares depending on the card using the firmware. > > > As in the example above, you the xc3028 can require either the xc3028 > > > or xc3028L firmware depending on the board they have. Does this > > > change now result in both firmware images being required? > > > > It really depends on how the information is used. Given that there are > > many drivers that load different firmware files for different devices > > (or even support multiple different versions with different names), it > > would be rather stupid to treat these declaration as requirements. > > I agree. An interesting case happens with devices that uses tda10046 DVB > demods. > They have the firmware stored internally on their eeprom. Those firmwares can > be > replaced by a different version loaded in ram, but, in general, they work > properly with the eeprom one. So, even having the firmware load code there, > the firmware at /lib/firmware is optional. Mauro, that could lead to some misunderstanding of the current use conditions, at least on saa7134. Minor annotations, the tda10046 does not store firmware internally, but there are cards which have an extra eeprom to store such firmware. If such a firmware eeprom is found and correctly configured, the driver in all cases will load the firmware from that eeprom and all other firmware in /lib/firmware is ignored. If not, the firmware will be loaded from /lib/firmware. For all what I know, firmware revisions 26 and 29 are both valid "enough", correspondents to what we can load either from TechnoTrend or LifeView with the getfirmware script, and might be either stored in an extra eeprom or loaded from host/file. Prior revisions had issues with missing freqs, in what combination ever. We also can't totally exclude, given the whole mass of such, that in some cases firmware eeproms might exist on some boards, but are not correctly configured and load from host only because of that. The tendency seen overall is that competitors save the few cents for an extra firmware eeprom these days ... Cheers, Hermann > - > > I don't see any reason why we should add MODULE_FIRMWARE for v4l/dvb devices. > As you said, its primary usage is focused on booting a machine, and none > of those devices would affect booting. > > As you pointed, the secondary usage doesn't seem to apply to those devices as > well, and seems to be distro-specific, since different distros use different > methods to check for firmware dependencies, generally relying at the package > metadata. To make things worse, several of those firmwares still don't have > any > redistribution rights license that would be required for its inclusion on a > distro > package. > > Also, as this macro have no current usage that would make sense for those > drivers, I'm afraid that, as time goes by, people will simply forget to > keep it updated, since they'll need to add the same firmware name on two > different places. > > That's said, for now, the better is to not add those macros for the devices > under /drivers/media. They'll just waste some space at the object file, and > require an additional maintenance care for no good reason. > > Cheers, > Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: bisected regression in tuner-xc2028 on DVICO dual digital 4
On 11/8/09, Devin Heitmueller wrote: > I think the next step at this point is for you to definitively find a > use case that does not work with the latest v4l-dvb tip and Robert's > patch, and include exactly what kernel you tested with and which board > is having the problem (including the PCI or USB ID). > > At this point, your description seems a bit vague in terms of what is > working and what is not. If you do the additional testing to narrow > down specifically the failure case you are experiencing, I will see > what I can do. I'm trying to be as clear as I can. We can forget about setups 1 and 2, they no longer have the messages from the cxusb module that I originally reported, I can tune and run signal level tests like [1]. I'm now looking at setup 3. os: ubuntu karmic i386 kernel: 2.6.31-14-generic v4l modules: hg identify returns "19c0469c02c3+ tip" If I cold boot, I see no tuning issues at the kernel level. Details of the test below. The failure I was attempting to report is that I am unable to tune with dvbscan or w_scan. I think it is due to changes in the V4L API with respect to the versions of these programs I have installed. However I am able to tune with 'tzap'. I'm not entirely sure why tzap works, but it does and it shows the v4l tip drivers are ok regarding the issue originally reported. There are two further areas I am looking into. 1. If I *warm* boot the same setup, I see "dvb-usb: bulk message failed:" in dmesg. I am working on this still to try to get a clear report for you of when and on which device it occurs. It will probably take me a week to get back to you. 2. There may be differences in performance, in that: 2.6.31-14-generic+v4l+Rob shows worse Bit Error Rates than 2.6.31-14-generic+Rob Again I have some work to do to clarify this. It seems likely it is a separate issue from this thread. > That said, I'm preparing a tree with Robert's patch since I am pretty > confident at least his particular problem is now addressed. I can see no obstacle to you going ahead with that. Thanks again. Cheers Vince Test details: I tune like this: sudo strace -t -ff -F -o tzap.strace /usr/bin/tzap -a 0 -r -c channels.conf "7 Digital(Seven Network)" In dmesg I see the firmware being loaded but no other messages: [ 1232.684884] usb 3-1: firmware: requesting xc3028-v27.fw [ 1232.743698] xc2028 1-0061: Loading 80 firmware images from xc3028-v27.fw, type: xc2028 firmware, ver 2.7 [ 1232.756391] xc2028 1-0061: Loading firmware for type=BASE F8MHZ (3), id . [ 1237.332511] xc2028 1-0061: Loading firmware for type=D2633 DTV7 (90), id . [ 1237.416510] xc2028 1-0061: Loading SCODE for type=SCODE HAS_IF_5260 (6000), id . I can successfully tune each of the 4 tuners in this way. Each time I run tzap on a tuner I've not used before, dmesg shows the firmware loading ok. [1] http://linuxtv.org/wiki/index.php/Testing_reception_quality -- 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 4/4] firedtv: port to new firewire core
The firedtv DVB driver will now work not only on top of the old ieee1394
driver stack but also on the new firewire driver stack.
Alongside to the firedtv-1394.c backend for driver binding and I/O, the
firedtv-fw.c backend is added. Depending on which of the two 1394
stacks is configured, one or the other or both backends will be built
into the firedtv driver.
This has been tested with a DVB-T and a DVB-C box on x86-64 and x86-32
together with a few different controllers (Agere FW323, a NEC chip, TI
TSB82AA2, TSB43AB22/A, VIA VT6306).
Signed-off-by: Stefan Richter
---
drivers/media/dvb/firewire/Kconfig|7 +
drivers/media/dvb/firewire/Makefile |1 +
drivers/media/dvb/firewire/firedtv-1394.c |6
drivers/media/dvb/firewire/firedtv-dvb.c | 15 +
drivers/media/dvb/firewire/firedtv-fw.c | 385 ++
drivers/media/dvb/firewire/firedtv.h | 15 +
6 files changed, 420 insertions(+), 9 deletions(-)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/Kconfig
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/Kconfig
+++ linux-2.6.31.4/drivers/media/dvb/firewire/Kconfig
@@ -1,6 +1,6 @@
config DVB_FIREDTV
tristate "FireDTV and FloppyDTV"
- depends on DVB_CORE && IEEE1394
+ depends on DVB_CORE && (FIREWIRE || IEEE1394)
help
Support for DVB receivers from Digital Everywhere
which are connected via IEEE 1394 (FireWire).
@@ -13,8 +13,11 @@ config DVB_FIREDTV
if DVB_FIREDTV
+config DVB_FIREDTV_FIREWIRE
+ def_bool FIREWIRE = y || (FIREWIRE = m && DVB_FIREDTV = m)
+
config DVB_FIREDTV_IEEE1394
- def_bool IEEE1394
+ def_bool IEEE1394 = y || (IEEE1394 = m && DVB_FIREDTV = m)
config DVB_FIREDTV_INPUT
def_bool INPUT = y || (INPUT = m && DVB_FIREDTV = m)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/Makefile
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/Makefile
+++ linux-2.6.31.4/drivers/media/dvb/firewire/Makefile
@@ -1,6 +1,7 @@
obj-$(CONFIG_DVB_FIREDTV) += firedtv.o
firedtv-y := firedtv-avc.o firedtv-ci.o firedtv-dvb.o firedtv-fe.o
+firedtv-$(CONFIG_DVB_FIREDTV_FIREWIRE) += firedtv-fw.o
firedtv-$(CONFIG_DVB_FIREDTV_IEEE1394) += firedtv-1394.o
firedtv-$(CONFIG_DVB_FIREDTV_INPUT)+= firedtv-rc.o
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -1,5 +1,5 @@
/*
- * FireDTV driver (formerly known as FireSAT)
+ * FireDTV driver -- ieee1394 I/O backend
*
* Copyright (C) 2004 Andreas Monitzer
* Copyright (C) 2007-2008 Ben Backx
@@ -261,6 +261,7 @@ static int node_update(struct unit_direc
static struct hpsb_protocol_driver fdtv_driver = {
.name = "firedtv",
+ .id_table = fdtv_id_table,
.update = node_update,
.driver = {
.probe = node_probe,
@@ -273,12 +274,11 @@ static struct hpsb_highlevel fdtv_highle
.fcp_request= fcp_request,
};
-int __init fdtv_1394_init(struct ieee1394_device_id id_table[])
+int __init fdtv_1394_init(void)
{
int ret;
hpsb_register_highlevel(&fdtv_highlevel);
- fdtv_driver.id_table = id_table;
ret = hpsb_register_protocol(&fdtv_driver);
if (ret) {
printk(KERN_ERR "firedtv: failed to register protocol\n");
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-dvb.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-dvb.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-dvb.c
@@ -297,7 +297,7 @@ struct firedtv *fdtv_alloc(struct device
#define AVC_UNIT_SPEC_ID_ENTRY 0x00a02d
#define AVC_SW_VERSION_ENTRY 0x010001
-static struct ieee1394_device_id fdtv_id_table[] = {
+const struct ieee1394_device_id fdtv_id_table[] = {
{
/* FloppyDTV S/CI and FloppyDTV S2 */
.match_flags= MATCH_FLAGS,
@@ -346,12 +346,23 @@ MODULE_DEVICE_TABLE(ieee1394, fdtv_id_ta
static int __init fdtv_init(void)
{
- return fdtv_1394_init(fdtv_id_table);
+ int ret;
+
+ ret = fdtv_fw_init();
+ if (ret < 0)
+ return ret;
+
+ ret = fdtv_1394_init();
+ if (ret < 0)
+ fdtv_fw_exit();
+
+ return ret;
}
static void __exit fdtv_exit(void)
{
fdtv_1394_exit();
+ fdtv_fw_exit();
}
module_init(fdtv_init);
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-fw.c
===
--- /dev/null
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-fw.c
@@ -0,0 +1,385 @@
+/*
+ * FireDTV driver -- firewire I/O backend
+ */
+
+
[PATCH 3/4] firedtv: add missing include, rename a constant
Add #include for dvb_dmx_swfilter_packets(). This was
already indirectly included via firedtv.h, but don't rely on it.
The 4 bytes which were referred to as FIREWIRE_HEADER_SIZE are actually
the source packet header from IEC 61883-4 (MPEG2-TS data transmission
over 1394), not e.g. the IEEE 1394 isochronous packet header. So choose
a more precise name.
Also, express the payload size as a preprocessor constant too.
Signed-off-by: Stefan Richter
---
drivers/media/dvb/firewire/firedtv-1394.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -26,13 +26,16 @@
#include
#include
+#include
+
#include "firedtv.h"
static LIST_HEAD(node_list);
static DEFINE_SPINLOCK(node_list_lock);
-#define FIREWIRE_HEADER_SIZE 4
-#define CIP_HEADER_SIZE8
+#define CIP_HEADER_SIZE8
+#define MPEG2_TS_HEADER_SIZE 4
+#define MPEG2_TS_SOURCE_PACKET_SIZE(4 + 188)
static void rawiso_activity_cb(struct hpsb_iso *iso)
{
@@ -62,20 +65,20 @@ static void rawiso_activity_cb(struct hp
buf = dma_region_i(&iso->data_buf, unsigned char,
iso->infos[packet].offset + CIP_HEADER_SIZE);
count = (iso->infos[packet].len - CIP_HEADER_SIZE) /
- (188 + FIREWIRE_HEADER_SIZE);
+ MPEG2_TS_SOURCE_PACKET_SIZE;
/* ignore empty packet */
if (iso->infos[packet].len <= CIP_HEADER_SIZE)
continue;
while (count--) {
- if (buf[FIREWIRE_HEADER_SIZE] == 0x47)
+ if (buf[MPEG2_TS_HEADER_SIZE] == 0x47)
dvb_dmx_swfilter_packets(&fdtv->demux,
- &buf[FIREWIRE_HEADER_SIZE], 1);
+ &buf[MPEG2_TS_HEADER_SIZE], 1);
else
dev_err(fdtv->device,
"skipping invalid packet\n");
- buf += 188 + FIREWIRE_HEADER_SIZE;
+ buf += MPEG2_TS_SOURCE_PACKET_SIZE;
}
}
out:
--
Stefan Richter
-=-==--= =-== -=---
http://arcgraph.de/sr/
--
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/4] firedtv: reform lock transaction backend call
Preparation for the port of firedtv to the firewire-core kernel API:
The fdtv->backend->lock() hook and thus the CMP code is slightly changed
to better fit with the new API.
Signed-off-by: Stefan Richter
---
drivers/media/dvb/firewire/firedtv-1394.c | 11 -
drivers/media/dvb/firewire/firedtv-avc.c | 50 --
drivers/media/dvb/firewire/firedtv.h |2
3 files changed, 37 insertions(+), 26 deletions(-)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -87,10 +87,15 @@ static inline struct node_entry *node_of
return container_of(fdtv->device, struct unit_directory, device)->ne;
}
-static int node_lock(struct firedtv *fdtv, u64 addr, void *data, __be32 arg)
+static int node_lock(struct firedtv *fdtv, u64 addr, __be32 data[])
{
- return hpsb_node_lock(node_of(fdtv), addr, EXTCODE_COMPARE_SWAP, data,
- (__force quadlet_t)arg);
+ int ret;
+
+ ret = hpsb_node_lock(node_of(fdtv), addr, EXTCODE_COMPARE_SWAP,
+ (__force quadlet_t *)&data[1], (__force quadlet_t)data[0]);
+ data[0] = data[1];
+
+ return ret;
}
static int node_read(struct firedtv *fdtv, u64 addr, void *data, size_t len)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-avc.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-avc.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-avc.c
@@ -1255,14 +1255,14 @@ static int cmp_read(struct firedtv *fdtv
return ret;
}
-static int cmp_lock(struct firedtv *fdtv, void *data, u64 addr, __be32 arg)
+static int cmp_lock(struct firedtv *fdtv, u64 addr, __be32 data[])
{
int ret;
if (mutex_lock_interruptible(&fdtv->avc_mutex))
return -EINTR;
- ret = fdtv->backend->lock(fdtv, addr, data, arg);
+ ret = fdtv->backend->lock(fdtv, addr, data);
if (ret < 0)
dev_err(fdtv->device, "CMP: lock I/O error\n");
@@ -1292,25 +1292,25 @@ static inline void set_opcr(__be32 *opcr
int cmp_establish_pp_connection(struct firedtv *fdtv, int plug, int channel)
{
- __be32 old_opcr, opcr;
+ __be32 old_opcr, opcr[2];
u64 opcr_address = CMP_OUTPUT_PLUG_CONTROL_REG_0 + (plug << 2);
int attempts = 0;
int ret;
- ret = cmp_read(fdtv, &opcr, opcr_address, 4);
+ ret = cmp_read(fdtv, opcr, opcr_address, 4);
if (ret < 0)
return ret;
repeat:
- if (!get_opcr_online(opcr)) {
+ if (!get_opcr_online(*opcr)) {
dev_err(fdtv->device, "CMP: output offline\n");
return -EBUSY;
}
- old_opcr = opcr;
+ old_opcr = *opcr;
- if (get_opcr_p2p_connections(opcr)) {
- if (get_opcr_channel(opcr) != channel) {
+ if (get_opcr_p2p_connections(*opcr)) {
+ if (get_opcr_channel(*opcr) != channel) {
dev_err(fdtv->device, "CMP: cannot change channel\n");
return -EBUSY;
}
@@ -1318,11 +1318,11 @@ repeat:
/* We don't allocate isochronous resources. */
} else {
- set_opcr_channel(&opcr, channel);
- set_opcr_data_rate(&opcr, 2); /* S400 */
+ set_opcr_channel(opcr, channel);
+ set_opcr_data_rate(opcr, 2); /* S400 */
/* FIXME: this is for the worst case - optimize */
- set_opcr_overhead_id(&opcr, 0);
+ set_opcr_overhead_id(opcr, 0);
/*
* FIXME: allocate isochronous channel and bandwidth at IRM
@@ -1330,13 +1330,16 @@ repeat:
*/
}
- set_opcr_p2p_connections(&opcr, get_opcr_p2p_connections(opcr) + 1);
+ set_opcr_p2p_connections(opcr, get_opcr_p2p_connections(*opcr) + 1);
- ret = cmp_lock(fdtv, &opcr, opcr_address, old_opcr);
+ opcr[1] = *opcr;
+ opcr[0] = old_opcr;
+
+ ret = cmp_lock(fdtv, opcr_address, opcr);
if (ret < 0)
return ret;
- if (old_opcr != opcr) {
+ if (old_opcr != *opcr) {
/*
* FIXME: if old_opcr.P2P_Connections > 0,
* deallocate isochronous channel and bandwidth at IRM
@@ -1354,27 +1357,30 @@ repeat:
void cmp_break_pp_connection(struct firedtv *fdtv, int plug, int channel)
{
- __be32 old_opcr, opcr;
+ __be32 old_opcr, opcr[2];
u64 opcr_address = CMP_OUTPUT_PLUG_CONTROL_REG_0 + (plug << 2);
int attempts = 0;
- if (cmp_read(fdtv, &opcr, opcr_address, 4) < 0)
+ if (cmp_read(fdtv, opcr, opcr_address, 4) < 0)
return;
repeat:
- if (!get_opcr_online(op
Re: [PATCH 2/2] gspca pac7302: add debug register write interface
From: Márton Németh
Add debug register write interface to pac7302 to be able to set
for example the edge detect mode (bit 2 register 0x55) or the
test pattern (bit 0..3, register 0x72) and test overlay (bit 4,
register 0x72) from the user space. Only write of register
page 0 is supported by this patch.
The patch was tested together with Labtec Webcam 2200 (USB ID
093a:2626).
Signed-off-by: Márton Németh
---
The patch is based on 13335:3fd924da7091 from
http://linuxtv.org/hg/~jfrancois/gspca/ .
---
diff -r 3fd924da7091 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sun Nov 08 08:41:28 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Nov 08 23:21:51 2009 +0100
@@ -68,6 +68,7 @@
#define MODULE_NAME "pac7302"
+#include
#include "gspca.h"
MODULE_AUTHOR("Thomas Kaiser tho...@kaiser-linux.li");
@@ -1164,6 +1165,55 @@
return 0;
}
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int sd_dbg_s_register(struct gspca_dev *gspca_dev,
+ struct v4l2_dbg_register *reg)
+{
+ int ret = -EINVAL;
+ __u8 index;
+ __u8 value;
+
+ /* reg->reg: bit0..15: reserved for register index (wIndex is 16bit
+ long on the USB bus)
+ */
+ if (reg->match.type == V4L2_CHIP_MATCH_HOST &&
+ reg->match.addr == 0 &&
+ (reg->reg < 0x00ff) &&
+ (reg->val <= 0x00ff)
+ ) {
+ /* Currently writing to page 0 is only supported. */
+ /* reg_w() only supports 8bit index */
+ index = reg->reg & 0x00ff;
+ value = reg->val & 0x00ff;
+
+ /* Note that there shall be no access to other page
+ by any other function between the page swith and
+ the actual register write */
+ ret = reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, index, value);
+
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0xdc, 0x01);
+ }
+ return ret;
+}
+
+static int sd_chip_ident(struct gspca_dev *gspca_dev,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ int ret = -EINVAL;
+
+ if (chip->match.type == V4L2_CHIP_MATCH_HOST &&
+ chip->match.addr == 0) {
+ chip->revision = 0;
+ chip->ident = V4L2_IDENT_UNKNOWN;
+ ret = 0;
+ }
+ return ret;
+}
+#endif
+
/* sub-driver description for pac7302 */
static struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -1176,6 +1226,10 @@
.stop0 = sd_stop0,
.pkt_scan = sd_pkt_scan,
.dq_callback = do_autogain,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+ .set_register = sd_dbg_s_register,
+ .get_chip_ident = sd_chip_ident,
+#endif
};
/* -- module initialisation -- */
--
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] gspca pac7311: stop sending URBs on first error
From: Márton Németh
It is no use to continue sending URBs if one of them already
failed.
Signed-off-by: Márton Németh
---
The patch is based on 13335:3fd924da7091 from
http://linuxtv.org/hg/~jfrancois/gspca/ .
---
diff -r 3fd924da7091 linux/drivers/media/video/gspca/pac7311.c
--- a/linux/drivers/media/video/gspca/pac7311.c Sun Nov 08 08:41:28 2009 +0100
+++ b/linux/drivers/media/video/gspca/pac7311.c Sun Nov 08 23:14:13 2009 +0100
@@ -590,16 +590,27 @@
static void sd_stopN(struct gspca_dev *gspca_dev)
{
- reg_w(gspca_dev, 0xff, 0x04);
- reg_w(gspca_dev, 0x27, 0x80);
- reg_w(gspca_dev, 0x28, 0xca);
- reg_w(gspca_dev, 0x29, 0x53);
- reg_w(gspca_dev, 0x2a, 0x0e);
- reg_w(gspca_dev, 0xff, 0x01);
- reg_w(gspca_dev, 0x3e, 0x20);
- reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
- reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
- reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream, Bit_6=LED */
+ int ret;
+
+ ret = reg_w(gspca_dev, 0xff, 0x04);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x27, 0x80);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x28, 0xca);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x29, 0x53);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x2a, 0x0e);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0xff, 0x01);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x3e, 0x20);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream,
Bit_6=LED */
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream,
Bit_6=LED */
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0x78, 0x44); /* Bit_0=start stream,
Bit_6=LED */
}
/* called on streamoff with alt 0 and on disconnect for 7311 */
--
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/4] firedtv: move remote control workqueue handling into rc source file
Preparation for the port of firedtv to the firewire-core kernel API:
Canceling of the remote control workqueue job is factored into
firedtv-rc.c. Plus trivial whitespace change.
Signed-off-by: Stefan Richter
---
drivers/media/dvb/firewire/firedtv-1394.c |5 +++--
drivers/media/dvb/firewire/firedtv-rc.c |2 ++
2 files changed, 5 insertions(+), 2 deletions(-)
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-1394.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-1394.c
@@ -212,6 +212,7 @@ static int node_probe(struct device *dev
goto fail;
avc_register_remote_control(fdtv);
+
return 0;
fail:
spin_lock_irq(&node_list_lock);
@@ -220,6 +221,7 @@ fail:
fdtv_unregister_rc(fdtv);
fail_free:
kfree(fdtv);
+
return err;
}
@@ -233,10 +235,9 @@ static int node_remove(struct device *de
list_del(&fdtv->list);
spin_unlock_irq(&node_list_lock);
- cancel_work_sync(&fdtv->remote_ctrl_work);
fdtv_unregister_rc(fdtv);
-
kfree(fdtv);
+
return 0;
}
Index: linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-rc.c
===
--- linux-2.6.31.4.orig/drivers/media/dvb/firewire/firedtv-rc.c
+++ linux-2.6.31.4/drivers/media/dvb/firewire/firedtv-rc.c
@@ -14,6 +14,7 @@
#include
#include
#include
+#include
#include "firedtv.h"
@@ -163,6 +164,7 @@ fail:
void fdtv_unregister_rc(struct firedtv *fdtv)
{
+ cancel_work_sync(&fdtv->remote_ctrl_work);
kfree(fdtv->remote_ctrl_dev->keycode);
input_unregister_device(fdtv->remote_ctrl_dev);
}
--
Stefan Richter
-=-==--= =-== -=---
http://arcgraph.de/sr/
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] DVB: firedtv: port to new firewire driver stack
The following patch series adapts the firedtv driver for FireWire-attached DVB boxes and cards to the newer firewire-core kernel API. The driver will continue to work with the older ieee1394 kernel API as well. Which of the two IEEE 1394 stacks will be used depends on which one was configured at build time. If both were built, firedtv transparently uses the stack which is bound to the FireWire controller. This patch series depends on changes to firewire-core which were merged into Linux 2.6.31. There is some non-essential functionality yet to implement: - Finish FCP support in firewire-core so that more than one AV/C device can be used on the same FireWire bus at the same time. - Enhance firedtv to use firewire-core's channel and bandwidth allocation function for proper cooperation with non-FireDTV AV/C devices on the same bus. Following as reply: [PATCH 1/4] firedtv: move remote control workqueue handling into rc source file [PATCH 2/4] firedtv: reform lock transaction backend call [PATCH 3/4] firedtv: add missing include, rename a constant [PATCH 4/4] firedtv: port to new firewire core drivers/media/dvb/firewire/Kconfig|7 drivers/media/dvb/firewire/Makefile |1 drivers/media/dvb/firewire/firedtv-1394.c | 37 +- drivers/media/dvb/firewire/firedtv-avc.c | 50 +- drivers/media/dvb/firewire/firedtv-dvb.c | 15 drivers/media/dvb/firewire/firedtv-fw.c | 385 ++ drivers/media/dvb/firewire/firedtv-rc.c |2 drivers/media/dvb/firewire/firedtv.h | 17 8 files changed, 471 insertions(+), 43 deletions(-) -- Stefan Richter -=-==--= =-== -=--- http://arcgraph.de/sr/ -- 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: bug in changeset 13239:54535665f94b ?
Mauro Carvalho Chehab schrieb:
Hi Hartmut,
Em Sun, 01 Nov 2009 16:59:26 +0100
e9hack escreveu:
Hi,
something is wrong in changeset 13239:54535665f94b. After applying it, I get
page faults
in various applications:
...
If I remove the call to release_all_pagetables() in buffer_release(), I don't
see this
page faults.
Em Mon, 2 Nov 2009 21:27:44 +0100
e9h...@googlemail.com escreveu:
the BUG is in vidioc_streamoff() for the saa7146. This function
releases all buffers first, and stops the capturing and dma tranfer of
the saa7146 as second. If the page table, which is currently used by
the saa7146, is modified by another thread, the saa7146 writes
anywhere to the physical RAM. IMHO vidioc_streamoff() must stop the
saa7146 first and may then release the buffers.
I agree. We need first to stop DMA activity, and then release the page tables.
Could you please test if the enclosed patch fixes the issue?
Cheers,
Mauro
saa7146: stop DMA before de-allocating DMA scatter/gather page buffers
Signed-off-by: Mauro Carvalho Chehab
diff --git a/linux/drivers/media/common/saa7146_video.c
b/linux/drivers/media/common/saa7146_video.c
--- a/linux/drivers/media/common/saa7146_video.c
+++ b/linux/drivers/media/common/saa7146_video.c
@@ -1334,9 +1334,9 @@ static void buffer_release(struct videob
DEB_CAP(("vbuf:%p\n",vb));
+ saa7146_dma_free(dev,q,buf);
+
release_all_pagetables(dev, buf);
-
- saa7146_dma_free(dev,q,buf);
}
static struct videobuf_queue_ops video_qops = {
Hi Mauro,
I cannot easily catch any memory overwriting done by
saa7146-capture-dma, but Hartmut is right that there is quite a chance.
I would prefer calling video_end() before videobuf_streamoff() in
vidioc_streamoff(), because this physically shuts down the capture
immediately at the hardware source. By the way, this is done in the same
sequence in video_close, where videobuf_stop (which calls
videobuf_streamoff) also gets called after video_end.
I have no negative impact with your patch and it might shutdown the dma
as well, but as said before, I don't see any immediate errors even with
the released version.
Cheers
Johann
--
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: OMAP 3 ISP and N900 sensor driver update
Aguirre, Sergio wrote: Sakari, Hi, Sergio! - The Nokia N900 (aka rx-51) sensor drivers are available (will be posted to the list shortly) - Say goodbye to v4l2-int-device, welcome the v4l2_subdevice interface (thanks to Laurent Pinchart) - Miscellaneous stability fixes and cleanups - H3A rework (by David Cohen) - Resizer rework (by Antti Koskipää) Does the v4l2_subdevice conversion had some functional regressions? Or everything is in place still? I'd guess more or less so. I'm not aware of any regressions at least. :) -- Sakari Ailus sakari.ai...@maxwell.research.nokia.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: ERRORS
This message is generated daily by a cron job that builds v4l-dvb for the kernels and architectures in the list below. Results of the daily build of v4l-dvb: date:Sun Nov 8 19:00:04 CET 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 13327:19c0469c02c3 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: WARNINGS linux-2.6.23.12-armv5: WARNINGS linux-2.6.24.7-armv5: WARNINGS linux-2.6.25.11-armv5: WARNINGS linux-2.6.26-armv5: WARNINGS linux-2.6.27-armv5: WARNINGS linux-2.6.28-armv5: WARNINGS linux-2.6.29.1-armv5: WARNINGS linux-2.6.30-armv5: WARNINGS linux-2.6.31-armv5: WARNINGS linux-2.6.32-rc3-armv5: ERRORS linux-2.6.32-rc3-armv5-davinci: ERRORS linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-armv5-ixp: WARNINGS linux-2.6.32-rc3-armv5-ixp: ERRORS linux-2.6.28-armv5-omap2: WARNINGS linux-2.6.29.1-armv5-omap2: WARNINGS linux-2.6.30-armv5-omap2: WARNINGS linux-2.6.31-armv5-omap2: ERRORS linux-2.6.32-rc3-armv5-omap2: OK linux-2.6.22.19-i686: WARNINGS linux-2.6.23.12-i686: WARNINGS linux-2.6.24.7-i686: WARNINGS linux-2.6.25.11-i686: WARNINGS linux-2.6.26-i686: WARNINGS linux-2.6.27-i686: WARNINGS linux-2.6.28-i686: WARNINGS linux-2.6.29.1-i686: WARNINGS linux-2.6.30-i686: WARNINGS linux-2.6.31-i686: WARNINGS linux-2.6.32-rc3-i686: WARNINGS linux-2.6.23.12-m32r: WARNINGS linux-2.6.24.7-m32r: WARNINGS linux-2.6.25.11-m32r: WARNINGS linux-2.6.26-m32r: WARNINGS linux-2.6.27-m32r: WARNINGS linux-2.6.28-m32r: WARNINGS linux-2.6.29.1-m32r: WARNINGS linux-2.6.30-m32r: WARNINGS linux-2.6.31-m32r: WARNINGS linux-2.6.32-rc3-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-mips: WARNINGS linux-2.6.32-rc3-mips: ERRORS linux-2.6.27-powerpc64: WARNINGS linux-2.6.28-powerpc64: WARNINGS linux-2.6.29.1-powerpc64: WARNINGS linux-2.6.30-powerpc64: WARNINGS linux-2.6.31-powerpc64: WARNINGS linux-2.6.32-rc3-powerpc64: WARNINGS linux-2.6.22.19-x86_64: WARNINGS linux-2.6.23.12-x86_64: WARNINGS linux-2.6.24.7-x86_64: WARNINGS linux-2.6.25.11-x86_64: WARNINGS linux-2.6.26-x86_64: WARNINGS linux-2.6.27-x86_64: WARNINGS linux-2.6.28-x86_64: WARNINGS linux-2.6.29.1-x86_64: WARNINGS linux-2.6.30-x86_64: WARNINGS linux-2.6.31-x86_64: WARNINGS linux-2.6.32-rc3-x86_64: ERRORS sparse (linux-2.6.31): OK sparse (linux-2.6.32-rc3): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: WARNINGS linux-2.6.19.5-i686: WARNINGS linux-2.6.20.21-i686: WARNINGS linux-2.6.21.7-i686: WARNINGS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: WARNINGS linux-2.6.19.5-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/Sunday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Sunday.tar.bz2 The V4L2 specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification failed to build, but the last compiled spec is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] drivers/media/video: correct initialization of audio_mode
From: Julia Lawall
This initialization of the value of audio_mode is the one used if nothing
matches in the subsequent switch. The variable audio_mode is subsequently
assigned to constants such as TUNER_AUDIO_MONO and TUNER_AUDIO_STEREO.
TUNER_AUDIO_STEREO has the same value as V4L2_TUNER_MODE_STEREO, so it
would seem better to use that value here.
Signed-off-by: Julia Lawall
---
drivers/media/video/saa717x.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/media/video/saa717x.c b/drivers/media/video/saa717x.c
index b15c409..a00fb25 100644
--- a/drivers/media/video/saa717x.c
+++ b/drivers/media/video/saa717x.c
@@ -1312,7 +1312,7 @@ static int saa717x_s_tuner(struct v4l2_subdev *sd, struct
v4l2_tuner *vt)
"MONO", "STEREO", "LANG1", "LANG2/SAP"
};
- audio_mode = V4L2_TUNER_MODE_STEREO;
+ audio_mode = TUNER_AUDIO_STEREO;
switch (vt->audmode) {
case V4L2_TUNER_MODE_MONO:
--
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: [don't PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Em Sun, 8 Nov 2009 18:15:30 +0100 Jean-Francois Moine escreveu: > Hi Mauro, > > May you cancel my last pull request? I will remove 2 changesets. The one you sent me early today? No problem. I didn't merge it yet Cheers, Mauro -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, I removed the 2 changesets. Please pull from http://linuxtv.org/hg/~jfrancois/v4l-dvb for the following 8 changesets: 01/08: gspca - pac7302: Remove redundant stream off command. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=1551c621e75f 02/08: gspca - pac7311/pac7302: Propagate error to higher level software. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=225a5744acf3 03/08: gspca - sonixj: Optimize code and add some comments. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=f174339c63cf 04/08: gspca - pac7302: Add red and blue balance control. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=4ddc02bee41d 05/08: gspca - main: Change version to 2.8.0. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=63484417ba70 06/08: gspca - main: Fix a compilation warning. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=da92c97c33c4 07/08: gspca - pac7302: Add white balance control. http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=aa28984b1f48 08/08: gspca - pac7302: Handle return values in sd_start(). http://linuxtv.org/hg/~jfrancois/v4l-dvb?cmd=changeset;node=3fd924da7091 gspca.c |6 - pac7302.c | 346 +++--- pac7311.c | 161 ++-- sonixj.c | 163 ++--- 4 files changed, 480 insertions(+), 196 deletions(-) Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[don't PULL] http://linuxtv.org/hg/~jfrancois/v4l-dvb/
Hi Mauro, May you cancel my last pull request? I will remove 2 changesets. Thanks. -- Ken ar c'hentañ | ** Breizh ha Linux atav! ** Jef | http://moinejf.free.fr/ -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: libv4l problem decoding frames from pac7302
Hi, On 11/08/2009 02:29 PM, Németh Márton wrote: Hi, I have some problem that libv4l cannot decode all image coming from the Labtec Webcam 2200. There are some cases when no image at all can be decoded. This case can be reproduced always for example by setting the camera to test mode to produce a color test bar. The raw data arrives from the driver (41472 bytes, see attached) and v4lconvert_convert() returns -1 and the errno is set to EAGAIN. In this case the v4lconvert_get_error_message() reports the following error message: v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0xff See: libv4lconvert/tinyjpeg.c, lines 1611-1620 for some info on the magical byte pixart puts between Huffman data blocks. The 0xff value probably is normal for the test mode, so I would start with trying to change the MCU test to also except 0xff as a valid MCU marker Regards, hans Steps to reproduce: 1. get 13327:19c0469c02c3 from http://linuxtv.org/hg/v4l-dvb/ 2. apply the patch http://www.spinics.net/lists/linux-media/msg11841.html 3. apply the patch http://www.spinics.net/lists/linux-media/msg11842.html 4. compile and install the new driver 5. plug Labtec Webcam 2200 6. start capturing 7. execute "v4l2-dbg --set-register=0x72 9", this will switch on the color test card of the webcam. Current result: v4lconvert_convert() always return -1 and errno is EAGAIN until the olor test card is not switched off with "v4l2-dbg --set-register=0x72 0". How would you start to fix this? Regards, Márton Németh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: pac7302: INFO: possible circular locking dependency detected
Hi, On 11/08/2009 10:56 AM, Németh Márton wrote: Hi, Hans de Goede wrote: [snip] About the usb control msg errors, I don't think they are related to this issue at all, no real world app ever does a streamon and an mmap at the same time. As said if we could serialize mmap and ioctl at a high enough level, things would be fine too. I am using http://moinejf.free.fr/svv.c . In the start_capturing() function it calls the VIDIOC_STREAMON ioctl in case of memory mapped mode. Is this wrong? Or do you mean under "at the same time" that VIDIOC_STREAMON and mmap() is called from different tasks/threads? Yes from 2 different threads, which are both the stream owner (so operating on the same FD). 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
MSI Digivox mini II V3.0 (rtl2832u) with Me-tv
Ok, installing the driver of this chip wasn't that easy but following several "finnish"-howtos i managed to succesfully build v4l-dvb driver for the rtl2832u-chiped MSI Digivox mini II V3.0. Here is the BUg-Report and the way i managed to isntall it: https://bugs.launchpad.net/ubuntu/+source/udev/+bug/478379 $ lsusb Bus 001 Device 005: ID 1d19:1101 $ dmesg | tail (regarded on stick-fresh-plugged-in): [ 95.620012] usb 1-1: new high speed USB device using ehci_hcd and address 5 [ 95.782039] usb 1-1: configuration #1 chosen from 1 choice [ 95.788734] dvb-usb: found a 'DK DVBT DONGLE' in warm state. [ 95.788738] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 95.790373] DVB: registering new adapter (DK DVBT DONGLE) [ 95.790607] DVB: registering adapter 0 frontend 0 (Realtek RTL2832 DVB-T)... [ 95.790629] dvb-usb: DK DVBT DONGLE successfully initialized and connected. [ 95.792426] dvb-usb: found a 'DK DVBT DONGLE' in warm state. [ 95.792430] dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer. [ 95.794467] DVB: registering new adapter (DK DVBT DONGLE) [ 95.794684] DVB: registering adapter 1 frontend 0 (Realtek RTL2832 DVB-T)... [ 95.794707] dvb-usb: DK DVBT DONGLE successfully initialized and connected. I recognized it registeres 2 adapters!? is that egular behaviour of this stick? $ scan /usr/share/dvb/dvb-t/de-Nordrhein-Westfalen - delivers all channels that i know off. example output: >>> tune to: 53800:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_2_3:FEC_AUTO:QAM_16:TRANSMISSION_MODE_8K:GUARD_INTERVAL_1_4:HIERARCHY_NONE 0x 0x4015: pmt_pid 0x0150 RTL World -- RTL Television (running) 0x 0x4016: pmt_pid 0x0160 RTL World -- RTL2 (running) 0x 0x401b: pmt_pid 0x01b0 RTL World -- Super RTL (running) 0x 0x4022: pmt_pid 0x0220 RTL World -- VOX (running) kaffeine scans all channels properly too and i can watch everything probably if i tune my antenna up to 18db, but kaffeine is kde based and i would like to have gnome/gtk based me-tv. Me-TV cannot find ANY channels (0) when i use internal scan: example output of $ me-tv --verbose 08.11.2009 15:15:43: Tuning to transponder at 53800 Hz 08.11.2009 15:15:43: Auf Signalsperre warten … (translation: waiting for signal lock) 08.11.2009 15:15:55: Poking screensaver 08.11.2009 15:15:58: Status: 0 08.11.2009 15:15:58: Currently tuned to freq 53800, symbol rate 0, inner fec 2 08.11.2009 15:15:58: Exception: Sperren des Kanals fehlgeschlagen (translation: failed to lock channel) 08.11.2009 15:15:58: Failed to tune to transponder at 53800 Hz So i tried to import the channels.conf-output that i generated with scan. Me-Tv seems to work, adds all channels, but stucks heavily and cannot show tv properly due to weak signal... The signal truely is high enough, because even increasing to 40db keeps signal on 0%, so something must be wrong with me-tv. To shoot out errors i got the same stick with afatech-9015-chip, that 100% works nice with me-tv on same antenna. So the Rtl2832U nearly works with any application except of me-tv. i really like me-tv and kaffeine is crashing all the time. Any ideas on how to fix that? -- 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
Looking for a DVB-S2 card which would work as an IRD
Hello LinuxTV gurus, Please excuse me if this list is not the best place to ask this. I am looking for a DVB-S2 card which: - is well supported by current kernel - does not have to support CI My goal is to build a simple digital TV headend. We have an encrypted signal ( 5 transponders, MPEG-4, h264 ). Basically we want to grab the existing signal, re-multiplex it (for example to add a few local channels), modulate it back and feed it to small SOs. I am aiming to build a PC equipped with a DVB-S2 card which will tune to 1 transponder , demodulate it and stream it (via Gig ethernet! ) as an MPTS to our software multiplexer. (so basically I hope to build an IRD with IP output) Once I have it in my MUX, I know what to do with it. Does the above make sense? Which card would you recommend? best, Leszek -- 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: analog support for dib0700
On Sun, Nov 8, 2009 at 3:15 AM, roshan karki wrote: > Hello, > I was wondering if you decided to write analog support for dib0700. As I > can't find anything related to it in chagelists I'm pretty sure you didn't > find enough request for it. > Hope I didn't bother you much. Hello Roshan, Please address future correspondence to the linux-media mailing list, as linux-dvb has been deprecated. Regarding dib0700 analog, there were only three people who showed any interest when I put out a call for people who wanted the functionality. Given other projects I am working on (and their much larger installed base), I couldn't justify the several weeks of development that would be required. Sorry I don't have better news. 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: bisected regression in tuner-xc2028 on DVICO dual digital 4
On Sat, Nov 7, 2009 at 9:40 PM, Devin Heitmueller wrote: > Hello Vince, > > I think the next step at this point is for you to definitively find a > use case that does not work with the latest v4l-dvb tip and Robert's > patch, and include exactly what kernel you tested with and which board > is having the problem (including the PCI or USB ID). > > At this point, your description seems a bit vague in terms of what is > working and what is not. If you do the additional testing to narrow > down specifically the failure case you are experiencing, I will see > what I can do. > > That said, I'm preparing a tree with Robert's patch since I am pretty > confident at least his particular problem is now addressed. > > Thanks, > > Devin Robert, FYI: this has been merged into my local tree (after fixing some whitespace problems introduced by the inlining of the patch into the email). I'll issue a PULL request tonight. Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] soc-camera: properly initialise the device object when reusing
Commit ef373189f62413803b7b816c972fc154c488cdc0 "fix use-after-free Oops,
resulting from a driver-core API change" fixed the Oops, but didn't correct
missing device object initialisation. This patch makes unloading and reloading
of soc-camera host- and client-drivers possible again.
Signed-off-by: Guennadi Liakhovetski
---
This is the second of the two patches, that I'm going to push upstream for
2.6.32 inclusion.
drivers/media/video/soc_camera.c | 17 -
1 files changed, 12 insertions(+), 5 deletions(-)
diff --git a/drivers/media/video/soc_camera.c b/drivers/media/video/soc_camera.c
index 36e617b..95fdeb2 100644
--- a/drivers/media/video/soc_camera.c
+++ b/drivers/media/video/soc_camera.c
@@ -1097,6 +1097,13 @@ static int default_s_crop(struct soc_camera_device *icd,
struct v4l2_crop *a)
return v4l2_subdev_call(sd, video, s_crop, a);
}
+static void soc_camera_device_init(struct device *dev, void *pdata)
+{
+ dev->platform_data = pdata;
+ dev->bus= &soc_camera_bus_type;
+ dev->release= dummy_release;
+}
+
int soc_camera_host_register(struct soc_camera_host *ici)
{
struct soc_camera_host *ix;
@@ -1158,6 +1165,7 @@ void soc_camera_host_unregister(struct soc_camera_host
*ici)
list_for_each_entry(icd, &devices, list) {
if (icd->iface == ici->nr) {
+ void *pdata = icd->dev.platform_data;
/* The bus->remove will be called */
device_unregister(&icd->dev);
/*
@@ -1169,6 +1177,7 @@ void soc_camera_host_unregister(struct soc_camera_host
*ici)
* device private data.
*/
memset(&icd->dev, 0, sizeof(icd->dev));
+ soc_camera_device_init(&icd->dev, pdata);
}
}
@@ -1200,10 +1209,7 @@ static int soc_camera_device_register(struct
soc_camera_device *icd)
* man, stay reasonable... */
return -ENOMEM;
- icd->devnum = num;
- icd->dev.bus = &soc_camera_bus_type;
-
- icd->dev.release= dummy_release;
+ icd->devnum = num;
icd->use_count = 0;
icd->host_priv = NULL;
mutex_init(&icd->video_lock);
@@ -1311,12 +1317,13 @@ static int __devinit soc_camera_pdrv_probe(struct
platform_device *pdev)
icd->iface = icl->bus_id;
icd->pdev = &pdev->dev;
platform_set_drvdata(pdev, icd);
- icd->dev.platform_data = icl;
ret = soc_camera_device_register(icd);
if (ret < 0)
goto escdevreg;
+ soc_camera_device_init(&icd->dev, icl);
+
icd->user_width = DEFAULT_WIDTH;
icd->user_height= DEFAULT_HEIGHT;
--
1.6.2.4
--
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: add more missing linux/sched.h includions
Signed-off-by: Guennadi Liakhovetski
---
Unless there are objections, I'll be asking Mauro to pull this and one
more patch later today.
drivers/media/video/mx1_camera.c |1 +
drivers/media/video/mx3_camera.c |1 +
drivers/media/video/sh_mobile_ceu_camera.c |1 +
drivers/media/video/videobuf-dma-contig.c |1 +
4 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/media/video/mx1_camera.c b/drivers/media/video/mx1_camera.c
index 5f37952..7280229 100644
--- a/drivers/media/video/mx1_camera.c
+++ b/drivers/media/video/mx1_camera.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
#include
diff --git a/drivers/media/video/mx3_camera.c b/drivers/media/video/mx3_camera.c
index dff2e5e..7db82bd 100644
--- a/drivers/media/video/mx3_camera.c
+++ b/drivers/media/video/mx3_camera.c
@@ -17,6 +17,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/drivers/media/video/sh_mobile_ceu_camera.c
b/drivers/media/video/sh_mobile_ceu_camera.c
index a2b5d39..56fc7ec 100644
--- a/drivers/media/video/sh_mobile_ceu_camera.c
+++ b/drivers/media/video/sh_mobile_ceu_camera.c
@@ -31,6 +31,7 @@
#include
#include
#include
+#include
#include
#include
diff --git a/drivers/media/video/videobuf-dma-contig.c
b/drivers/media/video/videobuf-dma-contig.c
index 635ffc7..c3065c4 100644
--- a/drivers/media/video/videobuf-dma-contig.c
+++ b/drivers/media/video/videobuf-dma-contig.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#include
struct videobuf_dma_contig_memory {
--
1.6.2.4
--
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
libv4l problem decoding frames from pac7302
Hi, I have some problem that libv4l cannot decode all image coming from the Labtec Webcam 2200. There are some cases when no image at all can be decoded. This case can be reproduced always for example by setting the camera to test mode to produce a color test bar. The raw data arrives from the driver (41472 bytes, see attached) and v4lconvert_convert() returns -1 and the errno is set to EAGAIN. In this case the v4lconvert_get_error_message() reports the following error message: v4l-convert: error decompressing JPEG: Pixart JPEG error: invalid MCU marker: 0xff Steps to reproduce: 1. get 13327:19c0469c02c3 from http://linuxtv.org/hg/v4l-dvb/ 2. apply the patch http://www.spinics.net/lists/linux-media/msg11841.html 3. apply the patch http://www.spinics.net/lists/linux-media/msg11842.html 4. compile and install the new driver 5. plug Labtec Webcam 2200 6. start capturing 7. execute "v4l2-dbg --set-register=0x72 9", this will switch on the color test card of the webcam. Current result: v4lconvert_convert() always return -1 and errno is EAGAIN until the olor test card is not switched off with "v4l2-dbg --set-register=0x72 0". How would you start to fix this? Regards, Márton Németh <>
[PATCH] v4l2-dbg: report fail reason to the user
From: Márton Németh
Report the fail reason to the user when writing a register even if
the verbose mode is switched off.
Remove duplicated code ioctl() call which may cause different ioctl()
function call in case of verbose and non verbose if not handled carefully.
Signed-off-by: Márton Németh
---
diff -r 19c0469c02c3 v4l2-apps/util/v4l2-dbg.cpp
--- a/v4l2-apps/util/v4l2-dbg.cpp Sat Nov 07 15:51:01 2009 -0200
+++ b/v4l2-apps/util/v4l2-dbg.cpp Sun Nov 08 14:13:52 2009 +0100
@@ -354,13 +354,14 @@
{
int retVal;
- if (!options[OptVerbose]) return ioctl(fd, request, parm);
retVal = ioctl(fd, request, parm);
- printf("%s: ", name);
- if (retVal < 0)
- printf("failed: %s\n", strerror(errno));
- else
- printf("ok\n");
+ if (options[OptVerbose]) {
+ printf("%s: ", name);
+ if (retVal < 0)
+ printf("failed: %s\n", strerror(errno));
+ else
+ printf("ok\n");
+ }
return retVal;
}
@@ -586,8 +587,9 @@
printf(" set to 0x%llx\n", set_reg.val);
} else {
- printf("Failed to set register 0x%08llx value
0x%llx\n",
- set_reg.reg, set_reg.val);
+ printf("Failed to set register 0x%08llx value
0x%llx: "
+ "%s\n",
+ set_reg.reg, set_reg.val,
strerror(errno));
}
set_reg.reg++;
}
--
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/2] gspca pac7302: add debug register write interface
From: Márton Németh
Add debug register write interface to pac7302 to be able to set
for example the edge detect mode (bit 2 register 0x55) or the
test pattern (bit 0..3, register 0x72) and test overlay (bit 4,
register 0x72) from the user space. Only write of register
page 0 is supported by this patch.
The patch was tested together with Labtec Webcam 2200 (USB ID
093a:2626).
Signed-off-by: Márton Németh
---
This patch replaces http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/da22d3ea5fc7
and
http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/9b3580f8fee8 .
---
diff -upr b/linux/drivers/media/video/gspca/pac7302.c
c/linux/drivers/media/video/gspca/pac7302.c
--- b/linux/drivers/media/video/gspca/pac7302.c 2009-11-08 11:39:00.0
+0100
+++ c/linux/drivers/media/video/gspca/pac7302.c 2009-11-08 11:59:00.0
+0100
@@ -53,6 +53,7 @@
#define MODULE_NAME "pac7302"
+#include
#include "gspca.h"
MODULE_AUTHOR("Thomas Kaiser tho...@kaiser-linux.li");
@@ -982,6 +983,55 @@ static int sd_getvflip(struct gspca_dev
return 0;
}
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+static int sd_dbg_s_register(struct gspca_dev *gspca_dev,
+ struct v4l2_dbg_register *reg)
+{
+ int ret = -EINVAL;
+ __u8 index;
+ __u8 value;
+
+ /* reg->reg: bit0..15: reserved for register index (wIndex is 16bit
+ long on the USB bus)
+ */
+ if (reg->match.type == V4L2_CHIP_MATCH_HOST &&
+ reg->match.addr == 0 &&
+ (reg->reg < 0x00ff) &&
+ (reg->val <= 0x00ff)
+ ) {
+ /* Currently writing to page 0 is only supported. */
+ /* reg_w() only supports 8bit index */
+ index = reg->reg & 0x00ff;
+ value = reg->val & 0x00ff;
+
+ /* Note that there shall be no access to other page
+ by any other function between the page swith and
+ the actual register write */
+ ret = reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, index, value);
+
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, 0xdc, 0x01);
+ }
+ return ret;
+}
+
+static int sd_chip_ident(struct gspca_dev *gspca_dev,
+ struct v4l2_dbg_chip_ident *chip)
+{
+ int ret = -EINVAL;
+
+ if (chip->match.type == V4L2_CHIP_MATCH_HOST &&
+ chip->match.addr == 0) {
+ chip->revision = 0;
+ chip->ident = V4L2_IDENT_UNKNOWN;
+ ret = 0;
+ }
+ return ret;
+}
+#endif
+
/* sub-driver description for pac7302 */
static struct sd_desc sd_desc = {
.name = MODULE_NAME,
@@ -994,6 +1044,10 @@ static struct sd_desc sd_desc = {
.stop0 = sd_stop0,
.pkt_scan = sd_pkt_scan,
.dq_callback = do_autogain,
+#ifdef CONFIG_VIDEO_ADV_DEBUG
+ .set_register = sd_dbg_s_register,
+ .get_chip_ident = sd_chip_ident,
+#endif
};
/* -- module initialisation -- */
--
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/2] gspca pac7302/pac7311: propagate error to higher level software
From: Márton Németh
The usb_control_msg() can fail any time. Only continue writing
sequence if there was no error with the previous write. If there
was any problem stop sending URBs and propagate the error to the
gspca_main.
Only the pac7302 driver was tested with Labtec Webcam 2200
(USB ID 093a:2626) because of lack of hardware for pac7311.
Signed-off-by: Márton Németh
---
The patch is based on the 13327:19c0469c02c3 of http://linuxtv.org/hg/v4l-dvb/ .
This patch replaces http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/2dc5e25b76c1
and http://linuxtv.org/hg/~jfrancois/v4l-dvb/rev/43be85676a49 . In addition to
those patches this patch also updates sd_stopN() function in pac7311.
---
diff -r 19c0469c02c3 linux/drivers/media/video/gspca/pac7302.c
--- a/linux/drivers/media/video/gspca/pac7302.c Sat Nov 07 15:51:01 2009 -0200
+++ b/linux/drivers/media/video/gspca/pac7302.c Sun Nov 08 11:54:26 2009 +0100
@@ -331,7 +331,7 @@
0x00
};
-static void reg_w_buf(struct gspca_dev *gspca_dev,
+static int reg_w_buf(struct gspca_dev *gspca_dev,
__u8 index,
const char *buffer, int len)
{
@@ -349,6 +349,7 @@
PDEBUG(D_ERR, "reg_w_buf(): "
"Failed to write registers to index 0x%x, error %i",
index, ret);
+ return ret;
}
#if 0 /* not used */
@@ -373,7 +374,7 @@
}
#endif
-static void reg_w(struct gspca_dev *gspca_dev,
+static int reg_w(struct gspca_dev *gspca_dev,
__u8 index,
__u8 value)
{
@@ -390,23 +391,27 @@
PDEBUG(D_ERR, "reg_w(): "
"Failed to write register to index 0x%x, value 0x%x, error %i",
index, value, ret);
+ return ret;
}
-static void reg_w_seq(struct gspca_dev *gspca_dev,
+static int reg_w_seq(struct gspca_dev *gspca_dev,
const __u8 *seq, int len)
{
+ int ret = 0;
while (--len >= 0) {
- reg_w(gspca_dev, seq[0], seq[1]);
+ if (0 <= ret)
+ ret = reg_w(gspca_dev, seq[0], seq[1]);
seq += 2;
}
+ return ret;
}
/* load the beginning of a page */
-static void reg_w_page(struct gspca_dev *gspca_dev,
+static int reg_w_page(struct gspca_dev *gspca_dev,
const __u8 *page, int len)
{
int index;
- int ret;
+ int ret = 0;
for (index = 0; index < len; index++) {
if (page[index] == SKIP)/* skip this index */
@@ -418,52 +423,61 @@
USB_DIR_OUT | USB_TYPE_VENDOR | USB_RECIP_DEVICE,
0, index, gspca_dev->usb_buf, 1,
500);
- if (ret < 0)
+ if (ret < 0) {
PDEBUG(D_ERR, "reg_w_page(): "
"Failed to write register to index 0x%x, "
"value 0x%x, error %i",
index, page[index], ret);
+ break;
+ }
}
+ return ret;
}
/* output a variable sequence */
-static void reg_w_var(struct gspca_dev *gspca_dev,
+static int reg_w_var(struct gspca_dev *gspca_dev,
const __u8 *seq,
const __u8 *page3, unsigned int page3_len,
const __u8 *page4, unsigned int page4_len)
{
int index, len;
+ int ret = 0;
for (;;) {
index = *seq++;
len = *seq++;
switch (len) {
case END_OF_SEQUENCE:
- return;
+ return ret;
case LOAD_PAGE4:
- reg_w_page(gspca_dev, page4, page4_len);
+ ret = reg_w_page(gspca_dev, page4, page4_len);
break;
case LOAD_PAGE3:
- reg_w_page(gspca_dev, page3, page3_len);
+ ret = reg_w_page(gspca_dev, page3, page3_len);
break;
default:
if (len > USB_BUF_SZ) {
PDEBUG(D_ERR|D_STREAM,
"Incorrect variable sequence");
- return;
+ return -EINVAL;
}
while (len > 0) {
if (len < 8) {
- reg_w_buf(gspca_dev, index, seq, len);
+ ret = reg_w_buf(gspca_dev,
+ index, seq, len);
+ if (ret < 0)
+ return ret;
seq += len;
break;
}
- reg_w_buf(gspca_dev, index, seq, 8);
+
Re: pac7302: INFO: possible circular locking dependency detected
Hi, Hans de Goede wrote: > [snip] > > About the usb control msg errors, I don't think they are related to this > issue at all, no real > world app ever does a streamon and an mmap at the same time. As said if we > could serialize mmap and > ioctl at a high enough level, things would be fine too. I am using http://moinejf.free.fr/svv.c . In the start_capturing() function it calls the VIDIOC_STREAMON ioctl in case of memory mapped mode. Is this wrong? Or do you mean under "at the same time" that VIDIOC_STREAMON and mmap() is called from different tasks/threads? Regards, Márton Németh -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gspca pac7302: add test pattern/overlay control
Hi,
On 11/08/2009 12:05 AM, Németh Márton wrote:
From: Márton Németh
The Labtec Webcam 2200 (USB ID 093a:2626) device can produce some
diagnostic patterns instead of the sensor image. An overlay test
pattern also exsits which can be combined with the sensor image or
with any test patterns. Add controls to activate these test modes.
Same here again, this is completely useless to an end user, with something
like v4l2ucp we can show a nice control panel (like a soundcard mixer),
to the end user. We should only show sensible stuff there, showing this to
the end user is not sensible.
Jean-Francois Moine, can you please revert the changes adding these 2 controls.
Németh, I understand having things like this may be useful for development,
what you
can do is add support for the standard v4l2 debugging interface, see:
linux/drivers/media/video/gspca/sn9c20x.c
Which allows one to export direct register control, and then use the existing
tools for this interface to modify these registers for testing purposes, or
even write a special userspace program to set things like this test mode.
(But this really does not belong to be visiable to the end user as a control
at the same level as brightness and contrast).
Regards,
Hans
Signed-off-by: Márton Németh
Cc: Thomas Kaiser
---
diff -upr c/linux/drivers/media/video/gspca/pac7302.c
d/linux/drivers/media/video/gspca/pac7302.c
--- c/linux/drivers/media/video/gspca/pac7302.c 2009-11-07 22:38:32.0
+0100
+++ d/linux/drivers/media/video/gspca/pac7302.c 2009-11-08 00:55:38.0
+0100
@@ -27,6 +27,29 @@
addresses is a - sign that register description is not valid for the
matching IC.
+ Register page 0:
+
+ Address Description
+ 0x72/- Different test patterns:
+ bit 0..3: 0 -> image, test pattern off
+1 -> white
+2 -> black
+3 -> red
+4 -> green
+5 -> blue
+6 -> cyan
+7 -> magenta
+8 -> yellow
+9 -> color bars
+ 10 -> high resolution color pattern
+ 11 -> black to white gradient from top to bottom
+ 12 -> white to black gradient from left to right
+ 13 -> white to black gradient repeats from left to
right
+ 14 -> dark gray (#11)
+ 15 -> dark gray 2 (#11)
+ bit 4: overlay some diagnostic points over the image
+ bit 5..7: no effect
+
Register page 1:
AddressDescription
@@ -57,6 +80,7 @@
0 | 0x0f..0x20 | setcolors()
0 | 0xa2..0xab | setbrightcont()
0 | 0x55 | setedgedetect()
+0 | 0x72 | settestpattern()
0 | 0xc5 | setredbalance()
0 | 0xc6 | setwhitebalance()
0 | 0xc7 | setbluebalance()
@@ -91,6 +115,8 @@ struct sd {
__u8 hflip;
__u8 vflip;
unsigned char edge_detect;
+ unsigned char test_pattern;
+ unsigned char test_overlay;
u8 sof_read;
u8 autogain_ignore_frames;
@@ -123,9 +149,14 @@ static int sd_setexposure(struct gspca_d
static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setedgedetect(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getedgedetect(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_settestpattern(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_gettestpattern(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_settestoverlay(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_gettestoverlay(struct gspca_dev *gspca_dev, __s32 *val);
#define V4L2_CID_PRIVATE_EDGE_DETECT (V4L2_CID_PRIVATE_BASE+0)
-
+#define V4L2_CID_PRIVATE_TEST_PATTERN (V4L2_CID_PRIVATE_BASE+1)
+#define V4L2_CID_PRIVATE_TEST_OVERLAY (V4L2_CID_PRIVATE_BASE+2)
static struct ctrl sd_ctrls[] = {
/* This control is pac7302 only */
@@ -307,6 +338,34 @@ static struct ctrl sd_ctrls[] = {
.set = sd_setedgedetect,
.get = sd_getedgedetect,
},
+ {
+ {
+ .id = V4L2_CID_PRIVATE_TEST_PATTERN,
+ .type= V4L2_CTRL_TYPE_MENU,
+ .name= "Test Pattern",
+ .minimum = 0,
+ .maximum = 15,
+ .step= 1,
+#define TEST_PATTERN_DEF 0
+ .default_value = TEST_PATTERN_DEF,
+ },
+ .set = sd_settestpattern,
+ .get = sd_gettestpattern,
+ },
+ {
+ {
+ .id = V4L2_CID_PRIVATE_TEST_OVERLAY,
+ .type= V4L2_CTRL_TYPE_BOOLEAN,
+ .name= "Test Overlay",
+ .minimum = 0,
+ .maximum = 1,
+ .st
Re: [PATCH] gspca pac7302: add edge detect control
Hi,
On 11/07/2009 09:45 PM, Németh Márton wrote:
From: Márton Németh
Add edge detect control to pac7302 driver. When this control is turned
on the camera image is switched to black and white and the edges are
visualized. Bit 2 on page 0, register 0x55 controls this mode on
Labtec Webcam 2200 (USB ID 093a:2626).
Signed-off-by: Márton Németh
Why would anyone want such a control ? When adding controls, please only add
controls which are potentially useful to the end user. For sensors where
we have datasheets we can easily add a 50 or so controls if we want too, but
we deliberately don't do that.
Controls really should only be added when there is no sane default which works
for 99% of all cases, in this case clearly just showing a normal picture is
a very sane default, and allowing to control this behaviour is pretty much
useless.
Regards,
Hans
---
diff -upr b/linux/drivers/media/video/gspca/pac7302.c
c/linux/drivers/media/video/gspca/pac7302.c
--- b/linux/drivers/media/video/gspca/pac7302.c 2009-11-07 21:25:15.0
+0100
+++ c/linux/drivers/media/video/gspca/pac7302.c 2009-11-07 22:38:32.0
+0100
@@ -56,6 +56,7 @@
-++---
0 | 0x0f..0x20 | setcolors()
0 | 0xa2..0xab | setbrightcont()
+0 | 0x55 | setedgedetect()
0 | 0xc5 | setredbalance()
0 | 0xc6 | setwhitebalance()
0 | 0xc7 | setbluebalance()
@@ -89,6 +90,7 @@ struct sd {
unsigned char autogain;
__u8 hflip;
__u8 vflip;
+ unsigned char edge_detect;
u8 sof_read;
u8 autogain_ignore_frames;
@@ -119,6 +121,11 @@ static int sd_setgain(struct gspca_dev *
static int sd_getgain(struct gspca_dev *gspca_dev, __s32 *val);
static int sd_setexposure(struct gspca_dev *gspca_dev, __s32 val);
static int sd_getexposure(struct gspca_dev *gspca_dev, __s32 *val);
+static int sd_setedgedetect(struct gspca_dev *gspca_dev, __s32 val);
+static int sd_getedgedetect(struct gspca_dev *gspca_dev, __s32 *val);
+
+#define V4L2_CID_PRIVATE_EDGE_DETECT (V4L2_CID_PRIVATE_BASE+0)
+
static struct ctrl sd_ctrls[] = {
/* This control is pac7302 only */
@@ -286,6 +293,21 @@ static struct ctrl sd_ctrls[] = {
.set = sd_setvflip,
.get = sd_getvflip,
},
+ {
+ {
+ .id = V4L2_CID_PRIVATE_EDGE_DETECT,
+ .type= V4L2_CTRL_TYPE_BOOLEAN,
+ .name= "Edge Detect",
+ .minimum = 0,
+ .maximum = 1,
+ .step= 1,
+#define EDGE_DETECT_DEF 0
+ .default_value = EDGE_DETECT_DEF,
+ },
+ .set = sd_setedgedetect,
+ .get = sd_getedgedetect,
+ },
+
};
static const struct v4l2_pix_format vga_mode[] = {
@@ -572,6 +594,7 @@ static int sd_config(struct gspca_dev *g
sd->autogain = AUTOGAIN_DEF;
sd->hflip = HFLIP_DEF;
sd->vflip = VFLIP_DEF;
+ sd->edge_detect = EDGE_DETECT_DEF;
return 0;
}
@@ -740,6 +763,23 @@ static int sethvflip(struct gspca_dev *g
return ret;
}
+static int setedgedetect(struct gspca_dev *gspca_dev)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+ int ret;
+ __u8 data;
+
+ ret = reg_w(gspca_dev, 0xff, 0x00); /* page 0 */
+ data = sd->edge_detect ? 0x04 : 0x00;
+ if (0<= ret)
+ ret = reg_w(gspca_dev, 0x55, data);
+
+ if (0<= ret)
+ ret = reg_w(gspca_dev, 0xdc, 0x01);
+
+ return ret;
+}
+
/* this function is called at probe and resume time for pac7302 */
static int sd_init(struct gspca_dev *gspca_dev)
{
@@ -772,6 +812,8 @@ static int sd_start(struct gspca_dev *gs
setexposure(gspca_dev);
if (0<= ret)
sethvflip(gspca_dev);
+ if (0<= ret)
+ ret = setedgedetect(gspca_dev);
/* only resolution 640x480 is supported for pac7302 */
@@ -1164,6 +1206,24 @@ static int sd_getvflip(struct gspca_dev
return 0;
}
+static int sd_setedgedetect(struct gspca_dev *gspca_dev, __s32 val)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ sd->edge_detect = val;
+ if (gspca_dev->streaming)
+ setedgedetect(gspca_dev);
+ return 0;
+}
+
+static int sd_getedgedetect(struct gspca_dev *gspca_dev, __s32 *val)
+{
+ struct sd *sd = (struct sd *) gspca_dev;
+
+ *val = sd->edge_detect;
+ return 0;
+}
+
/* sub-driver description for pac7302 */
static struct sd_desc sd_desc = {
.name = MODULE_NAME,
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.ke
Re: pac7302: INFO: possible circular locking dependency detected
Hi,
I've taken a long time to analyse the below lock dep report, and what can I say,
it is nasty.
This could happen (task could be a thread too):
Task 1: Does a readdir on sysfs
Task 1: Takes sysfs Mutex
Task 2: Does an mmap on the video device
Task 2: Takes mmap semphore
Task 1: Is now stuck waiting for mmap semaphore
Task 3: Does a streamon ioctl on video device
Task 3: Takes queue lock
Task 2: Is now stuck waiting on queue lock
Task 3: Task usb lock
Task 3: Does a usb_set_interface
Task 3: Is now stuck as usb_set_interface wants sysfs mutex
And the is nothing we can do here, as we cannot serialize mmap / ioctl calls at
the
level needed (before mmap taking the mmap semaphore).
There are 2 surprising things in here, which together cause the circular
problem:
1) A simple readdir on a sysfs dir takes the mmap semaphore
2) A simple usb_set_interface (only changing the alt setting!) takes the sysfs
mutex
1 of these 2 is new in 2.6.32 I think otherwise we would have seen this before.
So first of
all we should take this discussion to the general kernel mailing list and try
to get one
of these 2 fixed.
Alternatively we could move the usb bandwidth negotiation (which does the
usb_set_interface)
to device probe time, by pre-allocating the usb bandwidth, but we really don't
want to do that,
as that means that in multiple isoc devices configurations only the first cam
*probed* will
work (now usually only the first cam started works, which means atleast
multiple cams can
be used but not at the same time).
Regards,
Hans
p.s.
About the usb control msg errors, I don't think they are related to this issue
at all, no real
world app ever does a streamon and an mmap at the same time. As said if we
could serialize mmap and
ioctl at a high enough level, things would be fine too.
Are you seeing this issue on uhci using machines, or is it more general ? Also
keep in mind
the pac7302 is a very buggy device. I think we've had this issue (the need to
sometimes plug
it in a second time) for as long as we support it.
On 11/06/2009 10:05 PM, Németh Márton wrote:
Hi,
sometimes when I plug my Labtec Webcam 2200 and then try to start capturing I
get
no picture but some error message in dmesg. I am using 13326:40705fec2fb2 from
http://linuxtv.org/hg/v4l-dvb/ on top of Linux 2.6.32-rc6.
[ 2282.076229] usb 3-2: new full speed USB device using uhci_hcd and address 2
[ 2282.314601] usb 3-2: New USB device found, idVendor=093a, idProduct=2626
[ 2282.314622] usb 3-2: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 2282.317636] usb 3-2: configuration #1 chosen from 1 choice
[ 2282.562231] Linux video capture interface: v2.00
[ 2282.599805] gspca: main v2.7.0 registered
[ 2282.628561] gspca: probing 093a:2626
[ 2282.629052] usbcore: registered new interface driver snd-usb-audio
[ 2282.634125] gspca: /dev/video0 created
[ 2282.634563] usbcore: registered new interface driver pac7302
[ 2282.634602] pac7302: registered
[ 2298.627711]
[ 2298.627715] ===
[ 2298.627725] [ INFO: possible circular locking dependency detected ]
[ 2298.627734] 2.6.32-rc6 #1
[ 2298.627738] ---
[ 2298.627745] svv/3820 is trying to acquire lock:
[ 2298.627751] (sysfs_mutex){+.+.+.}, at: []
sysfs_get_dirent+0x15/0x4c
[ 2298.627773]
[ 2298.627775] but task is already holding lock:
[ 2298.627781] (&gspca_dev->usb_lock){+.+...}, at: []
gspca_init_transfer+0x20/0x384 [gspca_main]
[ 2298.627801]
[ 2298.627803] which lock already depends on the new lock.
[ 2298.627806]
[ 2298.627811]
[ 2298.627813] the existing dependency chain (in reverse order) is:
[ 2298.627819]
[ 2298.627821] -> #3 (&gspca_dev->usb_lock){+.+...}:
[ 2298.627833][] __lock_acquire+0x10e9/0x13ea
[ 2298.627846][] lock_acquire+0xb3/0xd0
[ 2298.627856][] mutex_lock_interruptible_nested+0x50/0x37b
[ 2298.627869][] gspca_init_transfer+0x20/0x384 [gspca_main]
[ 2298.627883][] vidioc_streamon+0x4a/0x95 [gspca_main]
[ 2298.627895][] __video_do_ioctl+0x167d/0x3688 [videodev]
[ 2298.627910][] video_ioctl2+0x2cf/0x371 [videodev]
[ 2298.627923][] v4l2_unlocked_ioctl+0x2e/0x32 [videodev]
[ 2298.627936][] vfs_ioctl+0x22/0x69
[ 2298.627947][] do_vfs_ioctl+0x484/0x4be
[ 2298.627958][] sys_ioctl+0x40/0x5a
[ 2298.627969][] sysenter_do_call+0x12/0x38
[ 2298.627981]
[ 2298.627983] -> #2 (&gspca_dev->queue_lock){+.+.+.}:
[ 2298.627994][] __lock_acquire+0x10e9/0x13ea
[ 2298.628005][] lock_acquire+0xb3/0xd0
[ 2298.628015][] mutex_lock_interruptible_nested+0x50/0x37b
[ 2298.628027][] dev_mmap+0x5a/0x1c7 [gspca_main]
[ 2298.628039][] v4l2_mmap+0x32/0x3d [videodev]
[ 2298.628052][] mmap_region+0x246/0x40b
[ 2298.628063][] do_mmap_pgoff+0x2a0/0x2f0
[ 2298.628073][] sys_mmap2+0x5a/0x7b
[ 2298.628083][] sysenter_do_call+0x1
[PATCH] pt1: Support FE_READ_SNR
pt1: Support FE_READ_SNR
Signed-off-by: HIRANO Takahito
diff -r bb412b4e19a0 -r b386a38c7a1e linux/drivers/media/dvb/pt1/va1j5jf8007s.c
--- a/linux/drivers/media/dvb/pt1/va1j5jf8007s.cSun Nov 01 03:59:42
2009 +0900
+++ b/linux/drivers/media/dvb/pt1/va1j5jf8007s.cSun Nov 08 17:37:13
2009 +0900
@@ -48,6 +48,60 @@
enum va1j5jf8007s_tune_state tune_state;
};
+static int va1j5jf8007s_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct va1j5jf8007s_state *state;
+ u8 addr;
+ int i;
+ u8 write_buf[1], read_buf[1];
+ struct i2c_msg msgs[2];
+ s32 word, x1, x2, x3, x4, x5, y;
+
+ state = fe->demodulator_priv;
+ addr = state->config->demod_address;
+
+ word = 0;
+ for (i = 0; i < 2; i++) {
+ write_buf[0] = 0xbc + i;
+
+ msgs[0].addr = addr;
+ msgs[0].flags = 0;
+ msgs[0].len = sizeof(write_buf);
+ msgs[0].buf = write_buf;
+
+ msgs[1].addr = addr;
+ msgs[1].flags = I2C_M_RD;
+ msgs[1].len = sizeof(read_buf);
+ msgs[1].buf = read_buf;
+
+ if (i2c_transfer(state->adap, msgs, 2) != 2)
+ return -EREMOTEIO;
+
+ word <<= 8;
+ word |= read_buf[0];
+ }
+
+ word -= 3000;
+ if (word < 0)
+ word = 0;
+
+ x1 = int_sqrt(word << 16) * ((15625ll << 21) / 100);
+ x2 = (s64)x1 * x1 >> 31;
+ x3 = (s64)x2 * x1 >> 31;
+ x4 = (s64)x2 * x2 >> 31;
+ x5 = (s64)x4 * x1 >> 31;
+
+ y = (58857ll << 23) / 1000;
+ y -= (s64)x1 * ((89565ll << 24) / 1000) >> 30;
+ y += (s64)x2 * ((88977ll << 24) / 1000) >> 28;
+ y -= (s64)x3 * ((50259ll << 25) / 1000) >> 27;
+ y += (s64)x4 * ((14341ll << 27) / 1000) >> 27;
+ y -= (s64)x5 * ((16346ll << 30) / 1) >> 28;
+
+ *snr = y < 0 ? 0 : y >> 15;
+ return 0;
+}
+
static int va1j5jf8007s_get_frontend_algo(struct dvb_frontend *fe)
{
return DVBFE_ALGO_HW;
@@ -536,6 +590,7 @@
FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
},
+ .read_snr = va1j5jf8007s_read_snr,
.get_frontend_algo = va1j5jf8007s_get_frontend_algo,
.read_status = va1j5jf8007s_read_status,
.tune = va1j5jf8007s_tune,
diff -r bb412b4e19a0 -r b386a38c7a1e linux/drivers/media/dvb/pt1/va1j5jf8007t.c
--- a/linux/drivers/media/dvb/pt1/va1j5jf8007t.cSun Nov 01 03:59:42
2009 +0900
+++ b/linux/drivers/media/dvb/pt1/va1j5jf8007t.cSun Nov 08 17:37:13
2009 +0900
@@ -46,6 +46,52 @@
enum va1j5jf8007t_tune_state tune_state;
};
+static int va1j5jf8007t_read_snr(struct dvb_frontend *fe, u16 *snr)
+{
+ struct va1j5jf8007t_state *state;
+ u8 addr;
+ int i;
+ u8 write_buf[1], read_buf[1];
+ struct i2c_msg msgs[2];
+ s32 word, x, y;
+
+ state = fe->demodulator_priv;
+ addr = state->config->demod_address;
+
+ word = 0;
+ for (i = 0; i < 3; i++) {
+ write_buf[0] = 0x8b + i;
+
+ msgs[0].addr = addr;
+ msgs[0].flags = 0;
+ msgs[0].len = sizeof(write_buf);
+ msgs[0].buf = write_buf;
+
+ msgs[1].addr = addr;
+ msgs[1].flags = I2C_M_RD;
+ msgs[1].len = sizeof(read_buf);
+ msgs[1].buf = read_buf;
+
+ if (i2c_transfer(state->adap, msgs, 2) != 2)
+ return -EREMOTEIO;
+
+ word <<= 8;
+ word |= read_buf[0];
+ }
+
+ if (!word)
+ return -EIO;
+
+ x = 10 * (intlog10(0x54 * 100 / word) - (2 << 24));
+ y = (24ll << 46) / 100;
+ y = ((s64)y * x >> 30) - (16ll << 40) / 1;
+ y = ((s64)y * x >> 29) + (398ll << 35) / 1;
+ y = ((s64)y * x >> 30) + (5491ll << 29) / 1;
+ y = ((s64)y * x >> 30) + (30965ll << 23) / 1;
+ *snr = y >> 15;
+ return 0;
+}
+
static int va1j5jf8007t_get_frontend_algo(struct dvb_frontend *fe)
{
return DVBFE_ALGO_HW;
@@ -393,6 +439,7 @@
FE_CAN_GUARD_INTERVAL_AUTO | FE_CAN_HIERARCHY_AUTO,
},
+ .read_snr = va1j5jf8007t_read_snr,
.get_frontend_algo = va1j5jf8007t_get_frontend_algo,
.read_status = va1j5jf8007t_read_status,
.tune = va1j5jf8007t_tune,
--
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
