Re: Hauppauge WinTV regreession from 2.6.24 to 2.6.25

[hermann pitton <hermann-pitton@xxxxxxxx>]

Am Sonntag, den 20.04.2008, 18:18 +0200 schrieb Gert Vervoort:
> hermann pitton wrote:
> > Hi,
> >
> > Am Sonntag, den 20.04.2008, 13:26 +0100 schrieb Ian Pickworth:
> >   
> >> Gert Vervoort wrote:
> >>     
> >>> Ian Pickworth wrote:
> >>>       
> >>>> I am testing a kernel upgrade from 2.6.24.to 2.6.25, and the drivers 
> >>>> for   the Hauppauge WinTV appear to have suffered some regression 
> >>>> between the two kernel versions.
> >>>>
> >>>> The problem is that the tuner is not being detected and set correctly 
> >>>> for either the video or the radio device on the card.
> >>>>
> >>>>         
> >>> Similar issue here with a Leadtek Winfast 2000XP card. Video works, but 
> >>> radio doesn't.
> >>> For my card I can workaround the issue by adding the "tuner=38" option 
> >>> to the cx88xx module.
> >>>
> >>>   Gert
> >>>       
> >> That workaround works for me as well - with "tuner=38" for cx88xx I can 
> >> now tune to both video and radio channels.
> >>
> >> So it looks like its just the auto detection that has regressed in 2.6.25.
> >>
> >> Thanks
> >> Regards
> >> Ian
> >>
> >>
> >>     
> >
> > just read this and that's good, but if all cards with eeprom detection
> > are affected, we have a problem.
> >
> > I copy in what I had as reply for the previous mail so far.
> >
> > >From the build date I expect the released 2.6.25. One could disable
> > tuner-simple and tda9885/6/7 support on customizing analog tuner support
> > on this kernel, but that is not the case.
> >
> > Mauro did something to get the tuner type set earlier to avoid other
> > troubles, but this looks like setting the tuner from eeprom detection
> > fails now, since it is already set previously and a tuner callback with
> > the correct tuner from eeprom doesn't happen.
> >
> > I can see something similar on saa7134 and a md7134. (card=12, tuner=38)
> > That tuner detection from eeprom was not 100% reliable since a while,
> > but only _sometimes_ a FMD1216ME was set instead the FM1216ME MK3.
> >
> > Currently this will always fail on 2.6.25 if tuner=38 is not forced.
> >
> > Since 2.6.25 tda9887 is out of the tuner module again, old tda9887 port
> > and qss options against the tuner module will make it fail to load too,
> > but this gives an error in dmesg, what is not the case here, just to
> > note it for others.
> >
> > saa7134[3]: found at 0000:01:0a.0, rev: 1, irq: 16, latency: 64, mmio: 0xe8003000
> > saa7134[3]: subsystem: 16be:0003, board: Medion 7134 [card=12,insmod option]
> > saa7134[3]: board init: gpio is 0
> > tuner' 5-0043: chip found @ 0x86 (saa7134[3])
> > tda9887 5-0043: tda988[5/6/7] found
> > All bytes are equal. It is not a TEA5767
> > tuner' 5-0060: chip found @ 0xc0 (saa7134[3])
> > tuner-simple 5-0060: type set to 63 (Philips FMD1216ME MK3 Hybrid Tuner)
> > saa7134[3]: i2c eeprom 00: be 16 03 00 08 20 1c 55 43 43 a9 1c 55 43 43 a9
> > saa7134[3]: i2c eeprom 10: ff ff ff ff 15 00 0e 01 0c c0 08 00 00 00 00 00
> > saa7134[3]: i2c eeprom 20: 00 00 00 e3 ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 40: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 50: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 60: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 70: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 80: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom 90: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom a0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom b0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom c0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom d0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom e0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3]: i2c eeprom f0: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
> > saa7134[3] Tuner type is 38    <----------------------
> >
> > saa7134[3]: registered device video3 [v4l2]
> > saa7134[3]: registered device vbi3
> > saa7134[3]: registered device radio2
> >
> > Gert, do we have more regressions for the WinFast 2000XP?
> >
> >   
> With the tuner type set manual things seem to work normally.
> Teletext does not seem to work, but when I booted into 2.6.24 again, I 
> got the same problem. Haven't used teletext for a long time, so I can't 
> remember the last kernel version where it did work.

Still all slots are full with saa713x stuff we recently added support
for or needs some fixes, but yes, at least Mauro had it working on cx88.

> I did notice messages caused by the nvidia binary blob:
> 
> NVRM: bad caching on address 0xffff810039654000: actual 0x173 != 
> expected 0x17b
> NVRM: please see the README section on Cache Aliasing for more information
> cx88[0]: video y / packed - dma channel status dump
> cx88[0]:   cmds: initial risc: 0x1ec19000
> cx88[0]:   cmds: cdt base    : 0x00180440
> cx88[0]:   cmds: cdt size    : 0x0000000c
> cx88[0]:   cmds: iq base     : 0x00180400
> cx88[0]:   cmds: iq size     : 0x00000010
> cx88[0]:   cmds: risc pc     : 0x1ec6c5d8
> cx88[0]:   cmds: iq wr ptr   : 0x00000109
> cx88[0]:   cmds: iq rd ptr   : 0x0000010d
> cx88[0]:   cmds: cdt current : 0x00000458
> cx88[0]:   cmds: pci target  : 0x1ec6ab80
> cx88[0]:   cmds: line / byte : 0x00900000
> cx88[0]:   risc0: 0x80008200 [ sync resync count=512 ]
> cx88[0]:   risc1: 0x1c000480 [ write sol eol count=1152 ]
> cx88[0]:   risc2: 0x1ec1a480 [ arg #1 ]
> cx88[0]:   risc3: 0x18000280 [ write sol count=640 ]
> cx88[0]:   iq 0: 0x1ec1ad80 [ write sol eol irq2 23 22 cnt0 resync 13 
> count=3456 ]
> cx88[0]:   iq 1: 0x14000200 [ arg #1 ]
> cx88[0]:   iq 2: 0x1ec1b000 [ write sol eol irq2 23 22 cnt0 resync 13 12 
> count=0 ]
> cx88[0]:   iq 3: 0x1c000480 [ arg #1 ]
> cx88[0]:   iq 4: 0x1ec1b680 [ write sol eol irq2 23 22 cnt0 resync 13 12 
> count=1664 ]
> cx88[0]:   iq 5: 0x18000080 [ arg #1 ]
> cx88[0]:   iq 6: 0x1ec1bf80 [ write sol eol irq2 23 22 cnt0 resync 13 12 
> count=3968 ]
> cx88[0]:   iq 7: 0x14000400 [ arg #1 ]
> cx88[0]:   iq 8: 0x1ec1c000 [ write sol eol irq2 23 22 cnt0 resync 14 
> count=0 ]
> cx88[0]:   iq 9: 0x1ec6a000 [ arg #1 ]
> cx88[0]:   iq a: 0x1c000480 [ write sol eol count=1152 ]
> cx88[0]:   iq b: 0x1ec6a700 [ arg #1 ]
> cx88[0]:   iq c: 0x80008200 [ sync resync count=512 ]
> cx88[0]:   iq d: 0x1c000480 [ write sol eol count=1152 ]
> cx88[0]:   iq e: 0x1ec1a480 [ arg #1 ]
> cx88[0]:   iq f: 0x18000280 [ write sol count=640 ]
> cx88[0]:   iq 10: 0x00180c00 [ arg #1 ]
> cx88[0]: fifo: 0x00180c00 -> 0x183400
> cx88[0]: ctrl: 0x00180400 -> 0x180460
> cx88[0]:   ptr1_reg: 0x00181680
> cx88[0]:   ptr2_reg: 0x00180468
> cx88[0]:   cnt1_reg: 0x00000038
> cx88[0]:   cnt2_reg: 0x00000000
> cx88[0]/0: [ffff810026028600/1] timeout - dma=0x1ec6c000
> 
> When using the xorg nv driver, these message do not occur.

On the saa7134 and ATI fglrx no issues so far, else I'm using also the
xorg nv driver without issues.

> 
> > OT, but do you remember on which kernel your saa7134-empress worked
> > last? There are problems too and Frederic Cand reported a 2.6.9 working
> > or a snapshot around that time ported. That would be odd.
> >   
> Can't remember at which kernel version I've used it last. Since I left 
> Philips Research about 3 years ago, I do not have access anymore to a 
> board with a empress MPEG-2 encoder.
> 

Ah, thanks, didn't know that. There have been always only _very few_
people with these cards and you did pretty much work on them.

There are currently some Creatix CTX946 around. (creatix.de) 
They seem to come with some of the recent Medion Multimedia PCs and
there are also some traders on ebay, with obviously substantial
quantities, one selling them as cheap as 29€ plus shipping and declared
as new.

The cards do already support analog and DVB-T, but I don't know yet from
what point the driver bugs start and where the physical configuration of
the card and encoder is not yet sufficient. The latter is very likely
the case as well, since I have been back to 2.6.12 already.

There is also the new Behold M6 Extra now, also without safe ground for
the encoder currently.

At least the potential mute problem Nickolay and me introduced by adding
digital mute support for the new cards without analog audio out is
fixed.

Mauro, Mike and all, you are aware of the just reported tuner detection
issues. They seem to be also on current v4l-dvb.

Thanks,
Hermann
 

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@xxxxxxxxxx?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list