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

[Gerd Knorr <kraxel@bytesex.org>]

> > It's the question whether enhancing the i2c-core in that way is going to 
> > be accepted. Do other drivers really benefit from the possibility of 
> > having a well-defined interface as well or it this simply bloat?
> 
> I'd go for enhancing kernel i2c.  I even think we don't have to actually
> touch the i2c-core to do that.  Asking kernel-i2c not to probe is just a
> matter of clearing the I2C_DF_NOTIFY flag in i2c_driver.  Then do
> something like this ...
> 
> struct dvb_fe_i2c_client {

> struct dvb_fe_i2c_client* <fe-name>_create(

To throw some real code into the discussion:  I've implemented that as
proof-of-concept for cx88-dvb adapter with cx22702 frontent.  The code
can be found in the latest video4linux cvs snapshot

	=> http://dl.bytesex.org/cvs-snapshots/

FE_REGISTER is gone, no autoprobing, uses kernel i2c everythere,
registeres the clients so it is nicely visible in sysfs.  I've also
reworked the driver in general.

Havn't tried to split away the pll code yet.  The functions to program
the pll are pretty generic now through, they can likely moved to some
pll library module (and then shared with other fe drivers) without much
trouble.

It's also smaller now, the current dvb cvs version:

  -rw-r--r--  1 cvs    users 23966 Sep 16 09:51 cx22702.c

and my one:

  -rw-r--r--  1 kraxel users 18942 Sep 23 15:44 cx22702.c
  -rw-r--r--  1 kraxel users   244 Sep 23 15:39 cx22702.h

It's a litte bit unfair through as the eeprom decoding stuff has been
moved to cx88-cards.c, but its still a nice improvement ;)

  Gerd

-- 
return -ENOSIG;