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. Patrick. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
