Brad Campbell wrote: > Manu Abraham wrote: >> I have stopped working on the DST as it is. All the FTA cards and the >> DSTMCI (revamped firmware) based ones work fine, but there are quite a >> lot of hardware other than which falls into these 2 categories. So, >> AFAICS, the DST-CI falls into the latter. This is a limitation arising >> from improper parsing of the PCMCIA Card Information Structure tuples. >> Did figure this out alongwith the Aston guys in France, while trying to >> get it working with their CAM's. > > I've never even tried to use it with a CAM, even as FTA it's been a dog.. > > It's one of those cards that sometimes just stops responding and requires a > long power cycle to > bring back.
Well, i had figured out the problem what causes this, but to fix the issue it was more than fixing a driver: the problem lay in fact, that the i2c probes by a client on the i2c master caused a freeze of the i2c master. Normally, when you think a i2c client/master, there is the PCI bridge which is the i2c master and a slave device such as a demodulator, which is the i2c slave. In the case of any DST based device, what happens is that: the DST is a SLAVE to the PCI bus master, while the DST is a I2C MASTER for the SLAVE demodulator. It is a piggyback kind of configuration. There is nothing wrong with this configuration, but normally, we shouldn't be probing on an I2C bus, ie: probing is similar to ask a Remote device on the bus to ACK at non-existant addresses. in some cases, this causes a lock up of the SLAVE. This i have seen happening to the STV0299, MB86A15, MB86A16 and the STB0899 demodulators as well, you send many unnecessary requests, the demodulator just freezes, which later on fails to provide any RACK (Remote ACK) In the case of the DST, when it is probed the SLAVE initially (ie the DST ASIC) freezes similarly to the demodulator issue that i mentioned above. (THE DST-CI and friends do have a STV0299 demodulator behind the DST pseudo bridge) When the DST freezes, well you've had it, no frontend, not even powering up the demodulator and PLL (the RF frontend) This is the problem as it is completely well debugged down. This though well debugged for a fix it would be quite a large effort requiring a large rewrite in many parts of the BT878 driver. Now, only the SAA7146 and Mantis bridges explicitly do not allow probing, ie the i2c low level transfer functions are used, rather than the higher level i2c client method, where probing is employed. So, in this case you don't see the freeze on the probe on the I2C bus. We ran into the same problem on the Mantis bridge where a probe was done by a SAA711x decoder on all available PCI bridges, where the SAA711x on an ivtv card caused a probe on the Mantis bridge which caused a lockup of the whole system even! The problem was solved by allowing the SAA711x to probe on certain bridges only. Well, i tried to fix the DST problem by writing an 878 driver from scratch a CX878 driver, it was done quite a lot, but then with more work coming in and lot of noise, i abandoned the CX878 efforts as that it was quite a large task which wasn't much rewarding.(read only complaints to be received) Well, such problems arise from the core issue that drivers once made spaghetti, hard to fix them in any way .. :-( > Under 2.6.17 and below I can at least talk to the ASIC, but later than that > and the i2c is just a There were I2C changes around the 2.6.17 - 18 era iirc. > pain. I tossed it in favour of a Pinnacle 450e USB unit which thankfully > fired up 1st go and has > been rock solid. Ah, you mean the STB0899 + STB6100 + Cypress USB bridge. Well, the STB0899 is quite a very complex demodulator due to the dual demodulator on it (DVB-S2/DVB-S) Though it looks quite fine, it still has some way to go. Had struggled with the STB0899 for quite a long time, due to it's complex nature. In fact the Pinnacle device is nothing but a Technotrend USB clone. STM was very happy on this front and still providing support in this arena, with regards to their demodulators. > Ok, if you don't want it I'll add it to the "archive of obsolete PCI > hardware" :) In fact don't have the time to look at hardware any further immediately, too many different hardware around that needs to be supported, directly from the vendor. Well, this is something different as opposed to earlier, as the vendors are fully supporting the development on these stuff. For example, i was even given a development board from Trident to fiddle around with their chipset, for the upcoming hardware, by different card manufacturers. The same with AFA Technologies. The development model shifted a bit from the old freelance model a bit to vendors supporting the development for their chips. Manu
