All of lore.kernel.org
 help / color / mirror / Atom feed
From: Gert Vervoort <gert.vervoort@hccnet.nl>
To: hermann pitton <hermann-pitton@arcor.de>
Cc: video4linux-list@redhat.com
Subject: Re: Hauppauge WinTV regreession from 2.6.24 to 2.6.25
Date: Sun, 20 Apr 2008 18:18:32 +0200	[thread overview]
Message-ID: <480B6CD8.7040702@hccnet.nl> (raw)
In-Reply-To: <1208696771.3349.49.camel@pc10.localdom.local>

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.

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.


> 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.

  Gert



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

  reply	other threads:[~2008-04-20 16:18 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-04-19 20:57 Hauppauge WinTV regreession from 2.6.24 to 2.6.25 Ian Pickworth
2008-04-20  0:47 ` hermann pitton
2008-04-20  9:15   ` Ian Pickworth
2008-04-20 11:20 ` Gert Vervoort
2008-04-20 12:26   ` Ian Pickworth
2008-04-20 13:06     ` hermann pitton
2008-04-20 16:18       ` Gert Vervoort [this message]
2008-04-20 21:16         ` hermann pitton
2008-04-24  3:55           ` hermann pitton
2008-04-25 13:56             ` Mauro Carvalho Chehab
2008-04-25 14:40               ` Michael Krufky
2008-04-25 14:45                 ` Mauro Carvalho Chehab
2008-04-25 15:06                   ` mkrufky
2008-04-25 21:48                     ` hermann pitton
2008-04-25 23:41                       ` hermann pitton
2008-04-26 11:59                     ` Mauro Carvalho Chehab
2008-04-26 12:58                       ` Ian Pickworth
2008-04-26 14:06                         ` Mauro Carvalho Chehab
2008-04-26 22:10                           ` hermann pitton
2008-04-26 23:19                             ` Mauro Carvalho Chehab
2008-04-27 20:15                               ` hermann pitton
2008-04-27 21:18                                 ` [linux-dvb] " Hartmut Hackmann
2008-04-28  1:01                                   ` hermann pitton
2008-04-28 14:21                                   ` Mauro Carvalho Chehab
2008-04-28 14:14                                 ` Mauro Carvalho Chehab
2008-04-25 15:03                 ` Mauro Carvalho Chehab
2008-04-25 16:55                   ` Gert Vervoort
2008-04-25 17:02                     ` Gert Vervoort
     [not found]                     ` <20080426090725.4a0fdcd4@gaivota>
2008-04-26 14:23                       ` Gert Vervoort
2008-04-26 15:38                         ` Mauro Carvalho Chehab
2008-04-26 16:59                           ` Gert Vervoort

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=480B6CD8.7040702@hccnet.nl \
    --to=gert.vervoort@hccnet.nl \
    --cc=hermann-pitton@arcor.de \
    --cc=video4linux-list@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.