On 7/25/07, Patrick Boettcher <patrick.boettcher@xxxxxxx> wrote: > On Mon, 23 Jul 2007, Oliver Endriss 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 second this idea. Exactly like this is how I did with the dib7000/3000 > and the mt2060. It is the best and cleanest approach IMHO. > Cool. Will proceed this way then without waiting much. My plan goes this way. * dvb-usb provides the real I2C bus. * the Host BIU is registered, which registers Virtual Bus #0 and #1 * the MASTER demod get's attached to VBus #0 - 0 * the MASTER tuner get's attached as a SLAVE on to the MASTER demod on VBus #0 - 1 * the SLAVE demod get's attached to VBus #1 * the SLAVE tuner get's attached as a SLAVE on to the SLAVE demod on VBus #1 - 0 * firmware is downloaded via VBus #0 to the Host * firmware is copied from MASTER to SLAVE via VBus #0 to VBus #1 - 1 though the firmware download is a property of the demodulator, it would not be elegant from the demodulator hardware POV to download the firmware twice (the BIU host will be doing 2 transfers, one from the PC to the BIU Host and the BIU to the SLAVE) In this case the firmware has to be copied from demod #0 to demod #1 for effeciency reasons, though a dual download can be used. But AFAICS the firmware getting downloaded to the demod would be necessary in the SLAVE - SLAVE configuration as found on PCI/PCIe devices, since there is no BIU in that configuration. I think it might be better then, that the firmware download in the demodulators is conditionally done through a BIU config data structure in such a case (Thoughts ?) Thanks, Manu _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
