Manu Abraham wrote: > 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. As a nice side effect of this concept, you may use standard i2ctools (i2cdump, i2cset, i2cget) to access the devices connected to a virtual bus. > 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) Does it take a long time to download the firmware? If not, I would go for the easiest way. (I guess the firmware has to be loaded after a coldstart only.) > 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 ?) You might add a firmware_request callback to the configuration struct passed to the demod_attach routine (see tda1004x driver, for example). The card driver will set this entry before calling demod_attach. For a dual download, it might point to the same routine for each demod. For the download+copy approach, you might set the callback of the second demod to a special firmware copy routine. CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
