modprobe.conf help - multiple SAA7134 cards?

[Hartmut Hackmann <hartmut.hackmann (at) t-online.de>]

hermann pitton wrote:
> Am Dienstag, den 16.05.2006, 17:20 -0700 schrieb Charlie Liu:
>
> > Use "options saa7134 card=70,70" or run "modprobe saa7134 card=70,70" , you
> > will get device node /dev/video0 linked to your 1st card and /dev/video1
> > linked to your 2nd card. Both working at same time.
> >
> > Charlie X. Liu at http://www.sensoray.com
>
>
> Hi Charlie,
>
> Michael Tokarew recommended the same already and Ben has success,
> but what seems strange to me is that two cards claimed to be identically
> come up with different subsystem IDs, else card=99,99 should work too ;)
> The also different gpio init might not indicate much, if not after boot
> up.
>
> Cheers,
> Hermann
>
>
>
> > -----Original Message-----
> > From: video4linux-list-bounces (at) redhat.com
> > [mailto:video4linux-list-bounces (at) redhat.com]On Behalf Of Ben Lancaster
> > Sent: Tuesday, May 16, 2006 2:19 PM
> > To: video4linux-list (at) redhat.com
> > Subject: modprobe.conf help - multiple SAA7134 cards?
> >
> >
> > Hey,
> >
> > I have two identical Phillips SAA7134 based cards (Compro VideoMate
> > DVBT300), what do I need to add to my /etc/modprobe.conf (on an FC4
> > system) to get it to pick up both cards?
> >
> > dmesg and lspci shows both cards as existing, however the second card
> > isn't picked up as a VideoMate:
> >
> > $ dmesg | grep saa7134
> > saa7134[0]: found at 0000:00:0c.0, rev: 1, irq: 18, latency: 32,
> > mmio: 0xcfffb800
> > saa7134[0]: subsystem: 185b:c900, board: Compro Videomate DVB-T300
>
>                          ^^^^^^^^^
>
> > [card=70,insmod option]
> > saa7134[0]: board init: gpio is 841100
> > input: saa7134 IR (Compro Videomate DV as /class/input/input0
> > --snip--
> > tuner 0-0061: chip found  (at)  0xc2 (saa7134[0])
> > tuner 0-0068: chip found  (at)  0xd0 (saa7134[0])
> > tda9887 0-0043: chip found  (at)  0x86 (saa7134[0])
> > saa7134[0]: registered device video0 [v4l2]
> > saa7134[0]: registered device vbi0
> > saa7134[1]: found at 0000:00:0d.0, rev: 1, irq: 19, latency: 32,
> > mmio: 0xcfffb400
> > saa7134[1]: subsystem: 1850:0000, board: UNKNOWN/GENERIC
>
>                          ^^^^^^^^^
>
> > [card=0,autodetected]
> > saa7134[1]: board init: gpio is 840500
> > tuner 1-0061: chip found  (at)  0xc2 (saa7134[1])
> > tuner 1-0068: chip found  (at)  0xd0 (saa7134[1])
> > tda9887 1-0043: chip found  (at)  0x86 (saa7134[1])
> > --snip--
> > saa7134[1]: registered device video1 [v4l2]
> > saa7134[1]: registered device vbi1
> >
> > $ lspci | grep saa7134
> > 00:0c.0 Multimedia controller: Philips Semiconductors SAA7134 Video
> > Broadcast Decoder (rev 01)
> > 00:0d.0 Multimedia controller: Philips Semiconductors SAA7134 Video
> > Broadcast Decoder (rev 01)
> >
> > Further more, later on in dmesg, you can see:
> >
> > DVB: registering new adapter (saa7134[0]).
> >
> > ...but no corresponding line for the second card, saa7134[1].
> >
> > My modprobe.conf contains:
> >
> > # Compro Videomate T300 driver
> > alias char-major-81 saa7134
> > options saa7134 card=70
> >
> > Any pointers?
> >
> > Thanks!
> >
> > Ben

The issue with the different subsystem IDs basically is known, but
in this occurence it is strange.
What happens on the board is an address conflict of the I2C eeproms.
There are 2 of these on the board, both have the address 0xa0.
- one is attached directly to the SAA7134 and contains the
  subsystem ID and the board configuration.
- the other one is the firmware eeprom for the channel decoder and
  it is connected parallel to the tuner after the I2C bridge of the
  channel decoder.
After reset, the I2C bridge should be open and so there should be
only one eeprom visible and the subsytem ID should be read correctly.
But the point is that the tuner also is invisible. So i need to make
the bridge transparent in an early initialization stage and keep it
in this stage in all analog modes, otherwise communication with the
tuner will fail.
The other issue is that the reset of the channel decoder is not
connected to the PCI reset. It is a simple RC circuit.
This explains why the cards are not detected properly if the PC is
rebooted without power cycling: the I2C bridge is still transparent
and the eeproms collide.
Somebody already proposed to resolve this with a board specific
_fini function and i intend to do this as soon as i have some time
for it.
But this does not explain the issue mentioned above because both
bridges should be open at first initialization....

Hartmut

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