By Date: <-- -->
By Thread: <-- -->

modprobe.conf help - multiple SAA7134 cards?

Am Mittwoch, den 17.05.2006, 22:39 +0200 schrieb Hartmut Hackmann:
> 
> 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.

[...] 

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

Hi Hartmut,

I didn't want to make some issue out of this, just tried to remind that
this is some special case, since without usage limitations also not any
priority on it.

Yes, there was something already previously, but thanks for the
interesting details in that case.

If Ben's dmesg is upon a cold boot I doubt. It could also be taken after
some modules reload attempt. To avoid to introduce new, maybe misleading
questions, Ben, can you try a cold boot, to be safe, let's say keep the
machine for 30 seconds without any power connected, and tell us if the
the second card still reports the wrong eeprom content?

Cheers,
Hermann


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