[linux-dvb] Re: Suggestion for autoprobing of i2c devices fix

[John Dalgliesh <johnd@defyne.org>]

On Sat, 11 Sep 2004, Andrew de Quincey wrote:
>
> Ralph is right I think - i2c_driver should really have an equivalent of the
> "class" field from i2c_adapter in them - to permit adapters to ignore devices
> which do not match their class automatically.
>
> If we used the same I2C_CLASS_* bitfield as in i2c_adapter, then this could be
> done by a simple AND operation.
>
> To disable autoprobing, I would suggest adding a new flag to the flags in
> i2c_device - I2C_DF_NOPROBE. If this is set, the driver will not be included
> in autoprobing scans of buses.
>
> We will also need a flag in i2c_adapter indicating the same thing - that the
> adapter should not be autoprobed.
>
> And we will need a new i2c function to request an i2c driver by name to
> attempt to attach itself to a given i2c adapter (e.g. i2c_request_driver)
>
> For DVB, the card driver init would work something like as follows:
> * initialise board
> * setup i2c adapter with NOPROBE enabled.
> * determine which demod to use (from PCIIDS/eeprom etc).
> * request_module the appropriate module.
> * use i2c_request_driver() to attach the frontend driver to the bus.
> * assming that worked, use FE_IDENTIFY to determine the exact frontend, and
> FE_CONFIGURE to set up the frontend with the board-specific configuration.
>
> what do you think?

Sorry to come into this a bit late, but here's my 2c: Why are you always
trying to solve this in code? This seems like the perfect process to be
data driven to me. No strings/ids bloating the kernel, and you can change
things without recompiling.

Dead simple example:
File with list of boards. For each board list of i2c drivers and where to
find them (and any data that they understand that you want to pass them).
Of course if your board uses something other than i2c then you will have a
list of some-other-bus devices.

e.g. (ASCII formatted):

board TechnoTrend_DVB-T_2003:
  interface saa7146
  pciids 0x13C21011
  i2c_components:
    demod tda1004x:
      address 0x08
      special_config_setting "dgdkjgnkdfjng"
    tuner tdm1316l:
      address 0x65
board DVICO_FusionHDTV_DVB-T1:
  interface cx88
  pciids 0x18ACDB00
  gpio_default: 0x00000101
  i2c_components:
    demod mt352:
      address 0x08
      tuner_addr 0x61
      tuner_type lg_z201
etc. etc. etc.

Another way to do it would be to have a config file for each module,
listing the ways that it could get itself instantiated. (This is similar
to what I have in my Mac DVB drivers. Each driver on the Mac gets
instantiated by defining a 'personality dictionary'. For a PCI driver this
contains the pci ids. But you can put whatever you like in here in order
to match your driver. And dictionary automatically gets added to the
properties of your driver so it can look into it and get extra settings
out. It's all in XML too which is nice.)

e.g. The file 'tda1004x_personalities':

0:
  parent saa7146:
    pciids 0x13C21011   # only if necessary - if probing not good enough
  address 0x08
  special_config_setting "sddsgdfgdfgdf"
1:
  parent ttusb:
    usbids 0x0B481003
  address 0x08
  special_config_setting "sdgfdfgdfgdf"
etc. etc. etc.

I don't see that there'd be any problems extending this for new cards or
for putting parts of binary drivers in there too. You can just add fields
as you need them interpreted by the driver. e.g. if the tda1004x is always
on i2c address 8 then just omit that field for it. It can probe that
address after it has satisfied one of the entries in the list of
personalities.

Maybe I don't understand the issues in linux, but it certainly seems that
trying to do this configuration stuff in code is the wrong way to go about
it.

{P^/