On 7/23/07, Oliver Endriss <o.endriss@xxxxxx> wrote: > Manu Abraham wrote: > > Hi all, > > > > On one of the devices that i am working upon, it has a bus control entity. ie > > > > The device looks like this > > > > The device consists of > > > > 1) a BUS Interface Unit > > 2) on this bus Interface unit (BIU) there is one single physical I2C bus > > 3) a built in MASTER demodulator > > > > > > The I2C bus on the device is _not_ directly connected to any > > peripherals such as demods and or tuners. > > > > The bus goes to a control unit where the bus is split into 2 based on > > a control word sent to the Bus Control Unit (BCU) > > > > The split out bus goes out like this > > > > 1) goes to the MASTER tuner for the built in demodulator > > 2) goes to a SLAVE demodulator, which has just one switchable I2C > > output for the tuner > > > > ie , the configuration looks like 2, 2 way switches cascaded together, > > when the MASTER and SLAVE demodulators are cascaded. > > > > Looking at the device and thinking a lot, i don't see how the control > > can fit in as a part of the frontend at all, as the it has nothing to > > do with the frontend, but just the BIU. > > > > Some thought that i have, at present go like this > > > > * register independant virtual buses for each device, on device > > access, the relevant control word is appended to the BIU device > > register. > > Imho this is the preferred way. The master_xfer function of the virtual > i2c bus could setup the BCU switch, then call master_xfer of the > physical i2c bus. I _think_ only one master_xfer would be required. A control word can be just appended at the xfer. Also prefer a virtual bus approach, but then in the initial case i need to use Pb's dvb-usb infrastructure. If i were to rip it apart, prolly he would slap me. ;-) That said, both the approaches sound quite sane and good. I think the best would be that i get a complete working driver in any one possible approach and then we can dissect it up for the best approach. > > This way any existing frontend driver might be used without > modification. (Don't know if this is important.) > The current available configurations for the chips looks like this * Single MASTER AF9015 (USB Host) This is a demodulator + USB host, with a tuner having a normal i2c_bus_ctrl example, combinations available AF9015 + MT2060 (available as Reference device as well as from a couple of vendors) AF9015 + QT1010 (not a Reference design) AF9015 + MXL5003 (not a Reference design) * Dual MASTER/SLAVE AF9015 (USB Host) Dual TS mode AF9015 + AF9013 + 2 x MXL5003/5 (This one is the slightly problematic case, what i was scratching my head) The AF9013 is a vanilla demodulator, similar to anyone of the devices that we have. There are some other small complications, for example, firmware is downloaded onto the Host and then copied over the I2C bus to the SLAVE AF9013. But should be doable, just a bit pain for the time. * Single AF9013 SLAVE + with MT2060/QT1010/MXL5003/5/TDA6650 This one is seen on PCI/PCIe cards. * Dual SLAVE AF9013 Dual TS mode AF9013 x 2 The same as the Single AF9013 SLAVE, but just a dual combination Thanks, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
