[linux-dvb] Re: Proposal for new frontend architecture

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Wednesday 22 Sep 2004 18:39, Gerd Knorr wrote:
> On Wed, Sep 22, 2004 at 07:10:28PM +0200, Holger Waechtler wrote:
> > Gerd Knorr wrote:
> > >... and makes it harder for people which use kernel i2c anyway for other
> > >reasons.
> >
> > why? please elaborate.
>
> Because we'll need again that shitty glue layer which links the dvb-i2c
> private stuff to the kernel-i2c.  We just killed that for good reasons.

Actually, thats not quite true. I went through the same reasoning myself - 
this is why I originally didn't like Holger's idea. I eventually saw he 
wasn't meaning that at all. You see, all the frontends have two "glue" 
functions along the lines of cx22702_writereg() and cx22702_readreg() anyway.

In the proposal, we removed all the i2c stuff, and put those two functions as 
fields in the initialisation structure, and called those instead. A sample 
init structure is:

struct cx22702_data {
  int (*writereg)(struct cx22702_data* data, int reg, int data);
  int (*readereg)(struct cx22702_data* data, int reg);
 int (*pll_init)(...)
 int (*pll_write)(...)
 void* private;

 ... other init params
}

You'd pass that as a parameter to the cx22702_init() function.

then, in the card driver, you implemented those two functions:

int cx88_writereg(struct cx22702_data* data int reg, int data) {
 struct i2c_adapter * adap = (struct i2c_adapter*) data->private;
 return i2c_xfer(adap, CARD_SPECIFIC_DEVICE_ADDRESS, reg, data);
}

and likewise for cx88_readreg().

You'd also implement the card-specific PLL functions.

So theres no additional glue - we're simply moving the existing readreg() and 
writereg() "glue" from the frontends into the adapters. Kernel i2c is still 
used - just not directly by the frontends.