Hi, Guys
Trent Piepho wrote:
On Fri, 31 Mar 2006, Gunther Mayer wrote:
1) lspci -vn after a cold boot wihtout loading the module
2) lspci -vn after a warm boot without loading the module (not loaded
since the machine was powered up)
3) lspci -vn after a warm boot where the module was loaded prior to
the reboot
Thanks this proves:
- warm boot leaves the PCI subsystem ID intact
- loading the saa7134 module corrupts some state on the card,
so on the next reboot the PCI subsystem ID is corrput
I think it might be safe to narrow it down a bit more than that. This is what
James found in the eeprom when his card works:
saa7134[1]: subsystem: 185b:c900, board: Compro Videomate DVB-T300
saa7134[1]: i2c eeprom 00: 5b 18 00 c9 54 20 1c 00 43 43 a9 1c 55 d2 b2 92
Notice that the first four bytes in the eeprom are the subsystem ID. The
saa7134 will read the subsystem ID from a I2C connected eeprom when it resets.
In this case, the eeprom looks like it should.
Now here is the eeprom when the card doesn't work:
saa7134[1]: i2c eeprom 00: 02 10 00 01 04 00 1c 00 40 03 00 10 04 00 82 10
It's totally different! This should not happen. Clearly something the linux
driver is doing is messing up the eeprom.
The linux code leaves the address counter in the eeprom at 128, instead of 0.
I thought maybe the saa7134 didn't reset the eeprom address to 0 before trying
to read from it, and so was reading from the wrong location. But that doesn't
explain why the driver eeprom dump returns totally different data. It must be
something else.
What happens if you cold boot, load the driver, unload it, then load it again?
Is the eeprom data messed up on the second load? In other words, does the
driver mess up the eeprom immediately, or does it only happen after a warm
boot?
I just found the problem!
The point is that there are 2 eeproms on the card, both are on address 0xa0.
One is directly connected to the saa7134 and provides the correct device ID.
The other one is the firmware eeprom connected to the "silent" I2C port of the
tda10046, together with the tuner. The driver does not find the tuner and can
not program it if the I2C bridge in the tda10046 is not set transparent.
This is done in the saa7134_board_init2() function. But as a result, the bridge
is transparent almost all time after board init. As a result, there is an address
conflict after warm boot. It does not destroy the hardware but causes the bad
reads.
It is not easy to work around this problem. The code in the init function must
remain, the only thing we could do is to add bridge handling code in the tuner
driver. But this currently is only necessary for this card.
Any better ideas ?
Hartmut
_______________________________________________
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
