[linux-dvb] Re: [PATCHES] Frontend kernel i2c conversion.

[Holger Waechtler <holger@qanu.de>]

Kenneth Aafløy wrote:
> > On Sun, Jul 18, 2004 at 01:04:02AM +0200, Kenneth Aafløy wrote:
> >
> > > On Sunday 18 July 2004 00:09, Ralph Metzler wrote:
> > >
> > > > No, I also considered this before implementing the FE_(UN)REGISTER
> > > > stuff but adapters with more than one I2C bus/frontend will not work
> > > > like this. It also makes the frontend driver and dvbdev depend on I2C
> > > > driver structs even if you are not using I2C.
> > > Hmm, there is no drivers in CVS which has more than one I2C bus, is
> > > there?
>
> On Sunday 18 July 2004 01:59, Ralph Metzler wrote:
>
> > No, but I know of at least one driver/hardware with more than one I2C bus.
>
> On Monday 19 July 2004 00:15, Johannes Stezenbach wrote:
>
> > It is very common for STB chips to have more than one I2C controller --
> > which doesn't mean that all I2C buses are used to connect DVB frontends,
> > but it is not unexpected for a dual-FE box to have each FE on its own I2C
> > bus.
>
> Ok, so there is hardware with both multiple I2C buses and frontends, nice to 
> know.
Also non-i2c hardware like 8-bit parallel uC-busses, SPI busses and even 
1-wire busses are common.

8-bit parallel and SPI-interfaces are usually used in chipsets shipped 
by U.S. manufacturers like Motorola and Broadcom. Even if the name 
dvb_i2c was a little misleading this code did not implemented anything 
specific to i2c -- you could simply rename every dvb_i2c_bus occurence 
to dvb_uC_bus.



> What I wonder about now, is how are these implemented multiple frontend 
> drivers implemented? Would this x extra frontend be registered together with 
> the same adapter or will there be multiple adapters, each attached to their 
> frontend?
different approaches are in use, at the end the MPEG stream routing into 
the demux will determine the naming convention in the device tree.

The frontends can be connected to different i2c addresses of the same 
bus, to difference i2c busses or to one bus splitted by i2c hubs or bus 
switches to the different frontend devices.


> > Sorry, but to get all this done properly in the way you want to do it
> > (i.e. without the kernel i2c registration callback) you will basically
> > have to reimplement the whole dvb_i2c layer again ...
>
> And that is unacceptable, is it not? Because the goal here is to remove that 
> layer completly, or have I missed something.
well -- I still can't see the deep reason for this, the recent patches 
usually added ~20-100 lines of code complexity to each file, so where is 
the point of "getting rid" of something?

wouldn't it be better to replace the from-scratch list-and-device 
handling in dvb_i2c.[hc] by the driver/bus infrastructure in 2.6 that 
provides the same functionality and to rename every dvb_i2c occurence by 
dvb_uC in order to mirror the additional flexibility of this code?

Holger