Re: bus control

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux