Re: regression : saa7134 with Pinnacle PCTV 50i (analog) can not tune anymore
On 9 Jul, hermann pitton wrote:
>
>
> Am Mittwoch, den 08.07.2009, 21:07 +0200 schrieb
> eric.patur...@orange.fr:
>> > Hi Eric,
>> >
>> > yes, arbitration lost on i2c is an error condition.
>> >
>> > As far I know we did not change the bus speed or anything, but some
>> > cards need and i2c quirk to work correctly with the clients.
>> >
>> > Mike recently changed the old quirk with good reasons and it was widely
>> > tested, also by me, without any negative effect seen.
>> >
>> > Maybe your card is a rare case needing the old quirk.
>> >
>> > You could try to change the quirk in saa7134-i2c.c
>> >
>> > static int saa7134_i2c_xfer(struct i2c_adapter *i2c_adap,
>> >struct i2c_msg *msgs, int num)
>> > {
>> >struct saa7134_dev *dev = i2c_adap->algo_data;
>> >enum i2c_status status;
>> >unsigned char data;
>> >int addr,rc,i,byte;
>> >
>> >status = i2c_get_status(dev);
>> >if (!i2c_is_idle(status))
>> >if (!i2c_reset(dev))
>> >return -EIO;
>> >
>> >d2printk("start xfer\n");
>> >d1printk(KERN_DEBUG "%s: i2c xfer:",dev->name);
>> >for (i = 0; i < num; i++) {
>> >if (!(msgs[i].flags & I2C_M_NOSTART) || 0 == i) {
>> >/* send address */
>> >d2printk("send address\n");
>> >addr = msgs[i].addr << 1;
>> >if (msgs[i].flags & I2C_M_RD)
>> >addr |= 1;
>> >if (i > 0 && msgs[i].flags & I2C_M_RD && msgs[i].addr
>> > != 0x40) {
>> >/* workaround for a saa7134 i2c bug
>> > * needed to talk to the mt352 demux
>> > * thanks to pinnacle for the hint */
>> >int quirk = 0xfe;
>> > <--
>> >d1printk(" [%02x quirk]",quirk);
>> >i2c_send_byte(dev,START,quirk);
>> >i2c_recv_byte(dev);
>> >}
>> >
>> > back to 0xfd.
>> >
>> > Cheers,
>> > Hermann
>> >
>>
>> H Hermann
>>
>> thanks for your suggestion .
>> No improvement with changing the quirk to 0xfd ,
>> I still get the same error messages :
>> i2c-adapter i2c-1: Invalid 7-bit address 0x7a
>> saa7133[0]: i2c xfer: < 8e >
>> input: i2c IR (Pinnacle PCTV) as /class/input/input4
>> ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-1/1-0047/ir0 [saa7133[0]]
>> saa7133[0]: i2c xfer: < 8f ERROR: ARB_LOST
>> saa7133[0]: i2c xfer: < 84 ERROR: NO_DEVICE
>> saa7133[0]: i2c xfer: < 86 ERROR: ARB_LOST
>> saa7133[0]: i2c xfer: < 94 ERROR: NO_DEVICE
>> saa7133[0]: i2c xfer: < 96 ERROR: ARB_LOST
>> saa7133[0]: i2c xfer: < c0 ERROR: NO_DEVICE
>> saa7133[0]: i2c xfer: < c2 ERROR: NO_DEVICE
>> saa7133[0]: i2c xfer: < c4 ERROR: NO_DEVICE
>> saa7133[0]: i2c xfer: < c6 ERROR: NO_DEVICE
>> saa7133[0]: i2c xfer: < c8 ERROR: NO_DEVICE
>>
>>
>> Regards
>>
>
> Hi Eric,
>
> thanks for your time and testing.
>
> Before we need to start with v4l-dvb bisecting.
>
> There have only been a few changes for the saa7134 driver since what
> Mauro did send for 2.6.30.
>
> Mostly for ir-kbd-i2c and for your remote was no tester found.
>
> All i2c errors seem to start from the remote and that i2c remote stuff I
> don't have and can't fake.
>
> Did you try with options saa7134 disable_ir=1 already too?
>
> Cheers,
> Hermann
>
>
Hi Hermann
I tried this morning with the option disable_ir=1 (mercurial from 7/7/2009)
there is some progress :
case 1 : modprobe saa7134
the tuner does not load any submodule
message Jul 10 06:49:04 neptune kernel: TUNER: Unable to find symbol
tda829x_probe()
Jul 10 06:49:05 neptune kernel: DVB: Unable to find symbol tda9887_attach()
Jul 10 06:51:21 neptune kernel: TUNER: Unable to find symbol tda829x_probe()
Jul 10 06:51:21 neptune kernel: DVB: Unable to find symbol tda9887_attach()
Jul 10 06:55:01 neptune kernel: TUNER: Unable to find symbol tda829x_probe()
message" neptune kernel: tuner 1-004b: Tuner has no way to set tv freq
equency " in /var/log/message
no pic with xawtv
xdtv hangs badly
tried with quirk at both values (0xfe and 0xfd )
case 2 : modprobe saa7134 with having before manualy preloaded tda827x and
tda8290
xawtv give a picture after maybe 10 sec , it is very very slow to tune (about
6 or 7 sec ) .
xdtv hangs completely , no picture , no channel change (time out and try
reset).
tried with quirk at both values (0xfe and 0xfd )
Jul 10 07:29:16 neptune kernel: tuner 1-004b: chip found @ 0x96 (saa7133[0])
Jul 10 07:29:16 neptune kernel: tda829x 1-004b: setting tuner address to 61
Jul 10 07:29:16 neptune kernel: tda829x 1-004b: type set to tda8290+75a
Jul 10 07:29:19 neptune kernel: saa7133[0]: registered device video0 [v4l2]
Jul 10 07:29:19 neptune kernel: s
Re: Afatech AF9013 DVB-T not working with mplayer radio streams
On Fri, Jul 3, 2009 at 12:01 PM, Jelle de Jong wrote: > Antti Palosaari wrote: >> On 06/26/2009 11:07 AM, Jelle de Jong wrote: >>> Hi all, >>> >>> Because i now use a new kernel and new mplayer versions I did some >>> testing again on one of my long standing issues. >>> >>> My Afatech AF9015 DVB-T USB2.0 stick does not work with mplayer, other >>> em28xx devices do work with mplayer. >>> >>> Would somebody be willing to do some tests and see if mplayers works on >>> your devices? >>> >>> Debian 2.6.30-1 >>> >>> /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://"3FM(Digitenne)" >>> >>> See the attachments for full details. >> >> For me, this works. I tested this with MT2060 tuner device, as you have >> also. If I remember correctly it worked for you also when channel is >> selected by using tzap. I don't know what mplayer does differently. >> >> Do the television channels in that same multiplex work with mplayer? >> /usr/bin/mplayer -identify -v -dvbin timeout=10 dvb://"TELEVISION CHANNEL" >> >> I added some delay for demod to wait lock. Could you try if this helps? >> http://linuxtv.org/hg/~anttip/af9015_delay/ >> >> regards >> Antti > > Hi Antti, > > I will get back to this next week, its a lot of work for me to compile > the drivers but I will see if i can get it running. (a pre-compiled > driver and some insmod for the 686 2.9.30 kernel would be an fast track > option if you want to test it a.s.a.p.) > > Thanks in advance, > > Jelle de Jong > -- > 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 > Antti, Thanks to Jelle providing an environment to debug the issue in, I isolated the problem. This is actually a combination of bugs in mplayer and the af9013 driver not handling the condition as gracefully as some other demods. First the bugs in mplayer: The following is the line from the channels.conf where tuning failed: Frequency in question: 3FM(Digitenne):72200:INVERSION_AUTO:BANDWIDTH_8_MHZ:FEC_AUTO:FEC_AUTO:QAM_AUTO:TRANSMISSION_MODE_AUTO:GUARD_INTERVAL_AUTO:HIERARCHY_AUTO:0:7142:1114 Mplayer does not support "TRANSMISSION_MODE_AUTO", "GUARD_INTERVAL_AUTO" and "QAM_AUTO" (for the constellation). In the case of the transmission mode and constellation, mplayer does not populate the field at all in the struct sent to the ioctl(), so you get whatever garbage is on the stack. For the guard interval field, it defaults to GUARD_INTERVAL_1_4 if it is an unrecognized value. I confirmed the mplayer behavior with the version Jelle has, as well as checking the source code in the svn trunk for the latest mplayer. So, why does it work with some tuners but not the af9013? Well, some demodulators check to see if *any* of the fields are "_AUTO" and if any of them are, then it puts the demod into auto mode and disregards whatever is in the other fields. However, the af9013 looks at each field, and if any of them are an unrecognized value, the code bails out in af9013_set_ofdm_params(). As a result, the tuning never actually happens. The behavior should be readily apparent if you were to put the above line into your channels.conf and try to tune (note I had to add printk() lines to af9013_set_ofdm_params() to see it bail out in the first switch statement. Anitti, do you want to take it from here, or would you prefer I rework the routine to put the device into auto mode if any of the fields are auto? 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
Ubuntu kernel 2.6.28-11/13 and KNC One clone
I just noticed something on a "minor" Ubuntu kernel upgrade. Running Linux nylon 2.6.28-11-server #42-Ubuntu SMP Fri Apr 17 02:45:36 UTC 2009 x86_64 GNU/Linux and Ubuntu update system offers 2.6.28-13. I take the upgrade and notice that in 2.6.28-13 the budget-av module will not load anymore for the KNC One DVB-S2 card. 11:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: KNC One Device 0019 Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr+ Stepping- SERR- FastB2B- DisINTx- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 123 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 23 Region 0: Memory at d0220400 (32-bit, non-prefetchable) [size=512] Kernel driver in use: budget_av Kernel modules: budget-av The only diff is that -13 will not have the last 2 lines. Nothing in dmesg that indicates any error on loading in -13. Is this worth reporting to the Ubuntu QA team or already old news? Thomas -- 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
Technotrend C-2300 problem getting channel lock
Hi ! Recently I have bought three TechnoTrend C-2300 for use in my Mythtv- system. Everything seemed to go smooth, but for a major share of the channels I have problems getting a channel lock. (Or if I do on some of them, I get a "distorted" image with lots of "bit errors" Using the latest firmware for Linux : dvb-ttpci-01.fw-2622... After poking around the Internet I found that QAM 128 has been a problem for TechnoTrend cards, and the funny thing is that my cable- provider is using QAM 128 for all channels (including the ones that works very well). As I experience problems with most of my channels I still thought maybe this would be the problem. I haven't seen posts on the issue for quite a while and realizing that the latest firmware available for these cards is dated 2005, I wondered where I can find an updated version or if anyone has a solution to my problem Best regards, johan $ lspci -vvv: 02:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Octal/Technotrend DVB-C for iTV Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 21 Region 0: Memory at feaffc00 (32-bit, non-prefetchable) [size=512] 02:0c.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Octal/Technotrend DVB-C for iTV Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 22 Region 0: Memory at feaff400 (32-bit, non-prefetchable) [size=512] 02:0d.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01) Subsystem: Technotrend Systemtechnik GmbH Octal/Technotrend DVB-C for iTV Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- SERR- Latency: 64 (3750ns min, 9500ns max) Interrupt: pin A routed to IRQ 21 Region 0: Memory at feaff000 (32-bit, non-prefetchable) [size=512] Syslog : Jul 9 19:18:48 xxx kernel: [ 53.409368] saa7146: register extension 'dvb'. Jul 9 19:18:48 xxx kernel: [ 53.409449] ACPI: PCI Interrupt :02:09.0[A] -> GSI 21 (level, low) -> IRQ 21 Jul 9 19:18:48 xxx kernel: [ 53.409492] saa7146: found saa7146 @ mem e09a6c00 (revision 1, irq 21) (0x13c2,0x000a). Jul 9 19:18:48 xxx kernel: [ 55.952909] DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-CA rev1.X) Jul 9 19:18:48 xxx kernel: [ 56.013623] adapter has MAC addr = 00:d0:5c:03:93:c2 Jul 9 19:18:48 xxx kernel: [ 56.244761] dvb-ttpci: gpioirq unknown type=0 len=0 Jul 9 19:18:48 xxx kernel: [ 56.282309] dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app80002622 Jul 9 19:18:48 xxx kernel: [ 56.282313] dvb-ttpci: firmware @ card 0 supports CI link layer interface Jul 9 19:18:48 xxx kernel: [ 56.621915] dvb-ttpci: DVB-C analog module @ card 0 detected, initializing MSP3415 Jul 9 19:18:48 xxx kernel: [ 56.733924] dvb_ttpci: saa7113 not accessible. Jul 9 19:18:48 xxx kernel: [ 56.831850] saa7146_vv: saa7146 (0): registered device video0 [v4l2] Jul 9 19:18:48 xxx kernel: [ 56.831878] saa7146_vv: saa7146 (0): registered device vbi0 [v4l2] Jul 9 19:18:48 xxx kernel: [ 56.897464] DVB: registering frontend 0 (ST STV0297 DVB-C)... Jul 9 19:18:48 xxx kernel: [ 56.897637] input: DVB on-card IR receiver as /devices/pci:00/:00:1e.0/:02:09.0/input/input6 Jul 9 19:18:48 xxx kernel: [ 56.951177] dvb-ttpci: found av7110-0. Jul 9 19:18:48 xxx kernel: [ 56.951255] saa7146: found saa7146 @ mem e0a6c400 (revision 1, irq 22) (0x13c2,0x000a). Jul 9 19:18:48 xxx kernel: [ 56.965145] DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-CA rev1.X) Jul 9 19:18:48 xxx kernel: [ 57.021978] adapter has MAC addr = 00:d0:5c:03:95:4d Jul 9 19:18:48 xxx kernel: [ 57.253096] dvb-ttpci: gpioirq unknown type=0 len=0 Jul 9 19:18:48 xxx kernel: [ 57.290649] dvb-ttpci: info @ card 1: firm f0240009, rtsl b0250018, vid 71010068, app 80002622 Jul 9 19:18:48 xxx kernel: [ 57.290653] dvb-ttpci: firmware @ card 1 supports CI link layer interface Jul 9 19:18:48 xxx kernel: [ 57.630258] dvb-ttpci: DVB-C analog module @ card 1 detected, initializing MSP3415 Jul 9 19:18:48 xxx kernel: [ 57.742249] dvb_ttpci: saa7113 not accessible. Jul 9 19:18:48 xxx kernel: [ 57.840242] saa7146_vv: saa7146 (1): registered device
[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:Thu Jul 9 19:00:03 CEST 2009 path:http://www.linuxtv.org/hg/v4l-dvb changeset: 12211:c300798213a9 gcc version: gcc (GCC) 4.3.1 hardware:x86_64 host os: 2.6.26 linux-2.6.22.19-armv5: OK linux-2.6.23.12-armv5: OK linux-2.6.24.7-armv5: OK linux-2.6.25.11-armv5: OK linux-2.6.26-armv5: OK linux-2.6.27-armv5: OK linux-2.6.28-armv5: OK linux-2.6.29.1-armv5: OK linux-2.6.30-armv5: OK linux-2.6.31-rc1-armv5: OK linux-2.6.27-armv5-ixp: WARNINGS linux-2.6.28-armv5-ixp: WARNINGS linux-2.6.29.1-armv5-ixp: WARNINGS linux-2.6.30-armv5-ixp: WARNINGS linux-2.6.31-rc1-armv5-ixp: WARNINGS 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-rc1-armv5-omap2: WARNINGS linux-2.6.22.19-i686: ERRORS linux-2.6.23.12-i686: ERRORS linux-2.6.24.7-i686: OK linux-2.6.25.11-i686: OK 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-rc1-i686: WARNINGS linux-2.6.23.12-m32r: OK linux-2.6.24.7-m32r: OK linux-2.6.25.11-m32r: OK linux-2.6.26-m32r: OK linux-2.6.27-m32r: OK linux-2.6.28-m32r: OK linux-2.6.29.1-m32r: OK linux-2.6.30-m32r: OK linux-2.6.31-rc1-m32r: OK linux-2.6.30-mips: WARNINGS linux-2.6.31-rc1-mips: WARNINGS 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-rc1-powerpc64: OK linux-2.6.22.19-x86_64: ERRORS linux-2.6.23.12-x86_64: ERRORS linux-2.6.24.7-x86_64: OK linux-2.6.25.11-x86_64: OK linux-2.6.26-x86_64: OK linux-2.6.27-x86_64: OK linux-2.6.28-x86_64: OK linux-2.6.29.1-x86_64: OK linux-2.6.30-x86_64: WARNINGS linux-2.6.31-rc1-x86_64: OK sparse (linux-2.6.30): OK sparse (linux-2.6.31-rc1): OK linux-2.6.16.61-i686: ERRORS linux-2.6.17.14-i686: ERRORS linux-2.6.18.8-i686: ERRORS linux-2.6.19.5-i686: ERRORS linux-2.6.20.21-i686: ERRORS linux-2.6.21.7-i686: ERRORS linux-2.6.16.61-x86_64: ERRORS linux-2.6.17.14-x86_64: ERRORS linux-2.6.18.8-x86_64: ERRORS linux-2.6.19.5-x86_64: ERRORS linux-2.6.20.21-x86_64: ERRORS linux-2.6.21.7-x86_64: ERRORS Detailed results are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.log Full logs are available here: http://www.xs4all.nl/~hverkuil/logs/Thursday.tar.bz2 The V4L2 specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/v4l2.html The DVB API specification from this daily build is here: http://www.xs4all.nl/~hverkuil/spec/dvbapi.pdf -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: regression : saa7134 with Pinnacle PCTV 50i (analog) can not tune anymore
Am Mittwoch, den 08.07.2009, 21:07 +0200 schrieb
eric.patur...@orange.fr:
> > Hi Eric,
> >
> > yes, arbitration lost on i2c is an error condition.
> >
> > As far I know we did not change the bus speed or anything, but some
> > cards need and i2c quirk to work correctly with the clients.
> >
> > Mike recently changed the old quirk with good reasons and it was widely
> > tested, also by me, without any negative effect seen.
> >
> > Maybe your card is a rare case needing the old quirk.
> >
> > You could try to change the quirk in saa7134-i2c.c
> >
> > static int saa7134_i2c_xfer(struct i2c_adapter *i2c_adap,
> > struct i2c_msg *msgs, int num)
> > {
> > struct saa7134_dev *dev = i2c_adap->algo_data;
> > enum i2c_status status;
> > unsigned char data;
> > int addr,rc,i,byte;
> >
> > status = i2c_get_status(dev);
> > if (!i2c_is_idle(status))
> > if (!i2c_reset(dev))
> > return -EIO;
> >
> > d2printk("start xfer\n");
> > d1printk(KERN_DEBUG "%s: i2c xfer:",dev->name);
> > for (i = 0; i < num; i++) {
> > if (!(msgs[i].flags & I2C_M_NOSTART) || 0 == i) {
> > /* send address */
> > d2printk("send address\n");
> > addr = msgs[i].addr << 1;
> > if (msgs[i].flags & I2C_M_RD)
> > addr |= 1;
> > if (i > 0 && msgs[i].flags & I2C_M_RD && msgs[i].addr
> > != 0x40) {
> > /* workaround for a saa7134 i2c bug
> > * needed to talk to the mt352 demux
> > * thanks to pinnacle for the hint */
> > int quirk = 0xfe;
> > <--
> > d1printk(" [%02x quirk]",quirk);
> > i2c_send_byte(dev,START,quirk);
> > i2c_recv_byte(dev);
> > }
> >
> > back to 0xfd.
> >
> > Cheers,
> > Hermann
> >
>
> H Hermann
>
> thanks for your suggestion .
> No improvement with changing the quirk to 0xfd ,
> I still get the same error messages :
> i2c-adapter i2c-1: Invalid 7-bit address 0x7a
> saa7133[0]: i2c xfer: < 8e >
> input: i2c IR (Pinnacle PCTV) as /class/input/input4
> ir-kbd-i2c: i2c IR (Pinnacle PCTV) detected at i2c-1/1-0047/ir0 [saa7133[0]]
> saa7133[0]: i2c xfer: < 8f ERROR: ARB_LOST
> saa7133[0]: i2c xfer: < 84 ERROR: NO_DEVICE
> saa7133[0]: i2c xfer: < 86 ERROR: ARB_LOST
> saa7133[0]: i2c xfer: < 94 ERROR: NO_DEVICE
> saa7133[0]: i2c xfer: < 96 ERROR: ARB_LOST
> saa7133[0]: i2c xfer: < c0 ERROR: NO_DEVICE
> saa7133[0]: i2c xfer: < c2 ERROR: NO_DEVICE
> saa7133[0]: i2c xfer: < c4 ERROR: NO_DEVICE
> saa7133[0]: i2c xfer: < c6 ERROR: NO_DEVICE
> saa7133[0]: i2c xfer: < c8 ERROR: NO_DEVICE
>
>
> Regards
>
Hi Eric,
thanks for your time and testing.
Before we need to start with v4l-dvb bisecting.
There have only been a few changes for the saa7134 driver since what
Mauro did send for 2.6.30.
Mostly for ir-kbd-i2c and for your remote was no tester found.
All i2c errors seem to start from the remote and that i2c remote stuff I
don't have and can't fake.
Did you try with options saa7134 disable_ir=1 already too?
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: [RFC] Anticipating lirc breakage
On Thu, 9 Jul 2009 11:44:46 -0400, Jarod Wilson wrote: > On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: > > > So, let's just forget the workarounds and go straight to the point: focus > > > on > > > merging lirc-i2c drivers. > > > > Will this happen next week? I fear not. Which is why I can't wait for > > it. And anyway, in order to merge the lirc_i2c driver, it must be > > turned into a new-style I2C driver first, so bridge drivers must be > > prepared for this, which is exactly what my patches are doing. > > For what its worth, I fixed up lirc_i2c a few days ago, and now have > it working just fine with my pvr-250 under 2.6.31-rc2. Excellent. Apparently you did not hit any problem, but if you ever do need help for the i2c side of things, just ask and I'll be happy to help. > Real Soon Now (I swear), I'm hoping to get up another head of steam > for submitting lirc upstream. Multiple drivers have received a bunch > of love in the past few weeks, so I think we're in a pretty good state > to have another go at it... > -- Jean Delvare -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Thu, Jul 9, 2009 at 11:44 AM, Jarod Wilson wrote: > On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: >> > So, let's just forget the workarounds and go straight to the point: focus >> > on >> > merging lirc-i2c drivers. >> >> Will this happen next week? I fear not. Which is why I can't wait for >> it. And anyway, in order to merge the lirc_i2c driver, it must be >> turned into a new-style I2C driver first, so bridge drivers must be >> prepared for this, which is exactly what my patches are doing. > > For what its worth, I fixed up lirc_i2c a few days ago, and now have > it working just fine with my pvr-250 under 2.6.31-rc2. > > Real Soon Now (I swear), I'm hoping to get up another head of steam > for submitting lirc upstream. Multiple drivers have received a bunch > of love in the past few weeks, so I think we're in a pretty good state > to have another go at it... > > -- > Jarod Wilson > ja...@redhat.com Jarod, This is excellent news. Keep up the good work! Devin -- Devin J. Heitmueller - Kernel Labs http://www.kernellabs.com -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Anticipating lirc breakage
On Tuesday 07 April 2009 08:36:17 Jean Delvare wrote: > > So, let's just forget the workarounds and go straight to the point: focus on > > merging lirc-i2c drivers. > > Will this happen next week? I fear not. Which is why I can't wait for > it. And anyway, in order to merge the lirc_i2c driver, it must be > turned into a new-style I2C driver first, so bridge drivers must be > prepared for this, which is exactly what my patches are doing. For what its worth, I fixed up lirc_i2c a few days ago, and now have it working just fine with my pvr-250 under 2.6.31-rc2. Real Soon Now (I swear), I'm hoping to get up another head of steam for submitting lirc upstream. Multiple drivers have received a bunch of love in the past few weeks, so I think we're in a pretty good state to have another go at it... -- Jarod Wilson ja...@redhat.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
Need Help on howto trace down a soft lock when opening a video0 device
I am currently creating a camera driver for an omap3530 processor based on omap3 camera support. I have it successfully configuring my camera and /dev/video0 shows up. However when I try to open the device using any program( xawtv , cat, etc.) The system soft locks. What I am trying to do is put printk s everywhere to track down the source of the lock. Currently I would like to know where in v4l2 would be a good place to add a printk to see it go farther than the generic open from fnctrl.h. Or maybe another technique to track down where the soft lock is occurring Thanks John Sarman -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap
Mauro, Could you please let me know what your plans are for this pull request? Murali Karicheri Software Design Engineer Texas Instruments Inc. Germantown, MD 20874 Phone : 301-515-3736 email: m-kariche...@ti.com >-Original Message- >From: Karicheri, Muralidharan >Sent: Tuesday, July 07, 2009 10:42 AM >To: 'Hans Verkuil'; linux-media@vger.kernel.org >Cc: Mauro Carvalho Chehab >Subject: RE: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap > >Mauro, > >Will you be able to pull this for 2.6.31 ? > >Thanks. > >Murali Karicheri >Software Design Engineer >Texas Instruments Inc. >Germantown, MD 20874 >Phone : 301-515-3736 >email: m-kariche...@ti.com >>-Original Message- >>From: Hans Verkuil [mailto:hverk...@xs4all.nl] >>Sent: Monday, July 06, 2009 2:25 PM >>To: linux-media@vger.kernel.org >>Cc: Karicheri, Muralidharan; Mauro Carvalho Chehab >>Subject: [PULL] http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap >> >>Hi Mauro, >> >>Please pull from http://www.linuxtv.org/hg/~hverkuil/v4l-dvb-vpfe-cap for >>the following: >> >>- tvp514x: Migration to sub-device framework >>- tvp514x: formatting comments as per kernel documentation >>- v4l: vpfe capture bridge driver for DM355 and DM6446 >>- v4l: ccdc hw device header file for vpfe capture >>- v4l: dm355 ccdc module for vpfe capture driver >>- v4l: dm644x ccdc module for vpfe capture driver >>- v4l: ccdc types used across ccdc modules for vpfe capture driver >>- v4l: common vpss module for video drivers >>- v4l: Makefile and config files for vpfe capture driver >>- v4l: davinci drivers should only be compiled for kernels >= 2.6.31. >> >>Hopefully these changes can be merged into 2.6.31. >> >>I have attached two arch/arm patches that need to be applied to the git >>tree. >>These patches should be applied after merging this tree. >> >>I've compiled this driver against the latest Linus' git tree. >> >>Thanks, >> >>Hans >> >>diffstat: >> b/linux/drivers/media/video/davinci/ccdc_hw_device.h | 110 >> b/linux/drivers/media/video/davinci/dm355_ccdc.c | 978 +++ >> b/linux/drivers/media/video/davinci/dm355_ccdc_regs.h | 310 ++ >> b/linux/drivers/media/video/davinci/dm644x_ccdc.c | 878 +++ >> b/linux/drivers/media/video/davinci/dm644x_ccdc_regs.h | 145 + >> b/linux/drivers/media/video/davinci/vpfe_capture.c | 2124 >>+ >> b/linux/drivers/media/video/davinci/vpss.c | 301 ++ >> b/linux/include/media/davinci/ccdc_types.h | 43 >> b/linux/include/media/davinci/dm355_ccdc.h | 321 ++ >> b/linux/include/media/davinci/dm644x_ccdc.h| 184 + >> b/linux/include/media/davinci/vpfe_capture.h | 198 + >> b/linux/include/media/davinci/vpfe_types.h | 51 >> b/linux/include/media/davinci/vpss.h | 69 >> linux/drivers/media/video/Kconfig | 49 >> linux/drivers/media/video/Makefile |2 >> linux/drivers/media/video/davinci/Makefile |6 >> linux/drivers/media/video/tvp514x.c| 1154 - >> linux/drivers/media/video/tvp514x_regs.h | 10 >> linux/include/media/tvp514x.h |4 >> v4l/versions.txt |7 >> 20 files changed, 6284 insertions(+), 660 deletions(-) >> >>-- >>Hans Verkuil - video4linux developer - sponsored by TANDBERG Telecom
libv4l release: 0.6.0: the upside down release
Hi All, I'm very happy to announce the first release of the next stable series: libv4l-0.6.0 This release features the following familiar features from previous 0.5.9x test releases: * Software whitebalancing * Software automatic gain and exposure for cams which lack this in hardware * Software gamma control * Fake v4l2 controls to control all these * Software flipping controls And as a new feature it now has an extended list of laptops whose camera modules (mostly uvc) are known to be mounted upside down in the frame and it will automatically correct the image for this. And ofcourse the standard addition of support for a few new camera output formats. libv4l-0.6.0 - * Recognize disabled controls and replace with fake equivalents where available * Add support for decompressing ov511 and ov518 "JPEG", by piping data through an external helper as I've failed to contact Mark W. McClelland to get permission to relicense the code. If you know a working email address for Mark W. McClelland, please let me know. * Add tons of laptop models to the upside down devices table * Support for rgb565 source format by Mauro Carvalho Chehab * Many bug fixes (see the mercurial tree for details) * Improved pac207 decompression code to also support higher compression modes of the pac207, which enables us to use higher framerates. Many many thanks to Bertrik Sikken for figuring the decompression out! Get it here: http://people.atrpms.net/~hdegoede/libv4l-0.6.0.tar.gz Regards, Hans -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Call for testers: Terratec Cinergy T XS USB support
Jelle de Jong schreef: > Devin Heitmueller wrote: >> Hello all, >> >> A few weeks ago, I did some work on support for the Terratec Cinergy T >> XS USB product. I successfully got the zl10353 version working and >> issued a PULL request last week >> (http://www.kernellabs.com/hg/~dheitmueller/em28xx-terratec-zl10353) >> >> However, the other version of the product, which contains a mt352 is >> not yet working. >> >> I am looking for people who own the device and would be willing to do >> testing of a tree to help debug the issue. Ideal candidates should >> have the experience using DVB devices under Linux in addition to some >> other known-working tuner product so we can be sure that certain >> frequencies are available and that the antenna/location work properly. >> If you are willing to provide remote SSH access for short periods of >> time if necessary, also indicate that in your email. >> >> Please email me if you are interested in helping out getting the device >> working. >> >> Thank you, >> >> Devin >> > > Not much time to do the actual coding and compiling but I will set you > up with :-) > > I will get you a dedicated machine with ssh access you can play with as > much as you like, it will be up and running next week after Wednesday. > > Have you ever heard of ssh gateways, I am kind of good at this I build > my support systems around this. So I will set you up with an account :D As said I made you a very nice dvb-t test station, you can log into it with a ssh gateway that I created for you. There are several usb dvb-t en hybrid devices attached, all with dvb-t signals, analog is also possible. I send you an additional private email with the information you need to login into the systems. You have full root access and can compile what ever you want ;-p If you got any question you can contact me on IRC with the nickname tuxcrafter or use the pct-support-chat[1] tool. Best regards, Jelle de Jong [1] https://secure.powercraft.nl/svn/packages/trunk/source/pct-support-scripts/ -- 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
Status of Lite-On TVT-1060 support (unknown frontend)
Hi
Maybe some of you have already heard some questions about the linux support of
the DVB-T card "Lite On TVT-1060", but all discussions about this card said
that it is not supported on linux for now, because nobody knows the frontend
(chip). some also said, that you'd have to unsolder the shielding to get the
name of the frontend chip and I won't try that as you may understand ;-)
I've got this "unsupported" tvt-1060 in my Asus G2S and would like to get it
run.
Operating system:
Kubuntu 9.04 Jaunty Jackalope
Kernel 2.6.28-13-generic
With the help of g00gle i have found some infos about this tv-card:
On one site, "Homocidical Teddy" wrote
"The card itself is sold as a Liteon TL-1060, however it's actually a
reference-design USB Tuner using the DibCom 7700C1 dvb-t chip and an UNKNOWN
frontend."
Found on http://forums.whirlpool.net.au/forum-replies-archive.cfm/995988.html
After reading that (especially the last posts) I did some tests and edits
(logically in the v4l-dvb source folder):
With the command "lsusb" i got the Vendor and the Product ID: "04ca:f016"
"0x04ca" for "Lite On Technology"
(to find in "~/Progs/v4l-dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h")
"0xf016" should stand for "TVT-1060" or another name of this dvb-t card... but
with "lsusb -v" the "idProduct" is empty.
This is because there is no entry for "f016" in "~/Progs/v4l-
dvb/linux/drivers/media/dvb/dvb-usb/dvb-usb-ids.h".
Well, as the patch mentioned (on the site above) and with a bit imagination
and something like that I added
#define USB_PID_LITEON_TVT_10600xf016
to the Product ID section in the file "dvb-usb-ids.h" (mentioned before)
after that i added also
{ USB_DEVICE(USB_VID_LITEON,USB_PID_LITEON_TVT_1060) },
to the line 1501 (right above the "{ 0 }" entry) in the file "~/Progs/v4l-
dvb/linux/drivers/media/dvb/dvb-usb/dib0700_devices.c"
As i found out before, there is the struct declaration "struct usb_device_id
dib0700_usb_id_table[] = { ...}") which is as you know a device table.
After these steps I took a look at "struct dvb_usb_device_properties
dib0700_devices[] = {...}" (in "dib0700_devices.c") and there was my
problem!
In this struct you can find entrys for the frontend and tuner attach
describing an adapter and also a devices list for each of these different
adapters..
NOW MY PROBLEM:
In which of these sections (starting with "{
DIB0700_DEFAULT_DEVICE_PROPERTIES,") should I add a device entry for my Lite-
On TVT-1060 ?
Or should I write a complete new one?
I have already tried this entry
{ "Lite-On TVT-1060",
{ &dib0700_usb_id_table[54], NULL },
{ NULL },
},
in the device section for the adapter "stk7700d__attach" (frontend and
tuner).
Oh, and by the way don't forget to modify "num_device_descs =", it may
prevent from errors I thinkdon't know exactly why... =)
The device entry above made my dvb-t card appear in dmesg after the command
"sudo modprobe dvb-usb-dib0700".
dmesg output:
[ 2336.075406] dib0700: loaded with support for 9 different device-types
[ 2336.075499] dvb-usb: found a 'Lite-On TVT-1060' in cold state, will try to
load a firmware
[ 2336.075502] usb 1-4: firmware: requesting dvb-usb-dib0700-1.20.fw
[ 2336.189540] dvb-usb: downloading firmware from file 'dvb-usb-
dib0700-1.20.fw'
[ 2336.392856] dib0700: firmware started successfully.
[ 2336.897028] dvb-usb: found a 'Lite-On TVT-1060' in warm state.
[ 2336.897079] dvb-usb: will pass the complete MPEG2 transport stream to the
software demuxer.
[ 2336.897224] DVB: registering new adapter (Lite-On TVT-1060)
[ 2336.945991] dib0700: stk7700d_frontend_attach: dib7000p_i2c_enumeration
failed. Cannot continue
[ 2336.945993]
[ 2336.945997] dvb-usb: no frontend was attached by 'Lite-On TVT-1060'
[ 2336.945999] dvb-usb: will pass the complete MPEG2 transport stream to the
software demuxer.
[ 2336.946320] DVB: registering new adapter (Lite-On TVT-1060)
[ 2336.947040] dvb-usb: no frontend was attached by 'Lite-On TVT-1060'
[ 2336.947094] input: IR-receiver inside an USB DVB receiver as
/devices/pci:00/:00:1a.7/usb1/1-4/input/input14
[ 2336.989093] dvb-usb: schedule remote query interval to 50 msecs.
[ 2336.989098] dvb-usb: Lite-On TVT-1060 successfully initialized and
connected.
[ 2336.989268] usbcore: registered new interface driver dvb_usb_dib0700
Now the following command shows what I have:
ls -lR /dev/dvb/
/dev/dvb/:
insgesamt 0
drwxr-xr-x 2 root root 100 2009-07-09 10:52 adapter0
drwxr-xr-x 2 root root 100 2009-07-09 10:52 adapter1
/dev/dvb/adapter0:
insgesamt 0
crw-rw+ 1 root video 212, 0 2009-07-09 10:52 demux0
crw-rw+ 1 root video 212, 1 2009-07-09 10:52 dvr0
crw-rw+ 1 root video 212, 2 2009-07-09 10:52 net0
/dev/dvb/adapter1:
insgesamt 0
crw-rw+ 1 root video 212, 3
Re: RFC: howto handle driver changes which require libv4l > x.y ?
Hi, On 07/07/2009 04:35 PM, Mauro Carvalho Chehab wrote: Em Tue, 7 Jul 2009 15:55:59 +0200 Erik Andrén escreveu: 2009/7/7 Hans de Goede: Hi All, So recently I've hit 2 issues where kernel side fixes need to go hand in hand with libv4l updates to not cause regressions. First lets discuss the 2 cases: 1) The pac207 driver currently limits the framerate (and thus the minimum exposure time) because at higher framerate the cam starts using a higher compression and we could not decompress this. Thanks to Bertrik Sikken we can now handle the higher decompression. So no I really want to enable the higher framerates as those are needed to make the cam work properly in full daylight. But if I do this, things will regress for people with an older libv4l, as that won't be able to decompress the frames 2) Several zc3xxx cams have a timing issue between the bridge and the sensor (the windows drivers have the same issue) which makes them do only 320x236 instead of 320x240. Currently we report their resolution to userspace as 320x240, leading to a bar of noise at the bottom of the screen. The fix here obviously is to report the real effective resoltion to userspace, but this will cause regressions for apps which blindly assume 320x240 is available (such as skype). The latest libv4l will make the apps happy again by giving them 320x240 by adding small black borders. Now I see 2 solutions here: a) Just make the changes, seen from the kernel side these are most certainly bugfixes. I tend towards this for case 2) b) Come up with an API to tell the libv4l version to the kernel and make these changes in the drivers conditional on the libv4l version Solution b) sounds messy and will probably lead to a lot of error prone glue code in the kernel. Fast-forward a couple of libv4l releases and you will have a nightmare maintainability scenario. If people run an old libv4l with a new kernel and run into problem, just tell them to upgrade their libv4l version. (b) seems a very bad hack, IMO. Between the two, I choose (a). Ok, So (a) it is then, I'll do a libv4l-0.6.0 release today. And put the changes depend upon libv4l-0.6.0 in my tree then as time permits, they will then go into 2.6.32 eventually which should put enough time between the libv4l release and the kernel release for most people to have the newer libv4l. 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
