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

[Gerd Knorr <kraxel@bytesex.org>]

On Tue, Sep 21, 2004 at 06:07:12PM +0200, Andreas Oberritter wrote:
> Am Di, den 21.09.2004 schrieb Gerd Knorr um 17:19:
> > > Well, I dislike using "I2C commands" for the following reason: On
> > > embedded STBs the I2C bus is usually not bound to a PCI/USB device like
> > > in the PC world. You can use the in-kernel drivers for the MPC8xx and
> > > IBM4xx platforms for example.
> > 
> > i.e. the dvb i2c devices are hooked up to the platforms i2c bus which
> > is present there anyway for other reasons?  Roughly compareable to having
> > a pc-based embedded dvb board with the dvb chips connected to the smbus of
> > the chipset pc chipset?
> 
> Yes, exactly.

Hmm, ok.  Lets step back and have a look at the basic problems we'll
have:

Problem #1: Register the frontend with the correct dvb adapter.  The
i2c frontend driver is separate from the dvb adapter driver, which is
basically a good thing to reuse the fe code for different adapters.  
But the frontend needs to know which adapter it should register to, no
matter which order the modules are loaded.  There might be three
modules involved: i2c adapter. dvb adapter, frontend.  If dvb adapter +
frontend are in the same module the whole thing isn't needed, one can
just register the fe directly.

Current way to do that: i2c_driver->command(FE_REGISTER)

Problem #2: Figure config info for the frontend.  Althrough the code can
be largely reused a few details differ from adapter to adapter and the
frontend driver needs to know.  Maybe not for all hardware through.

Current way to do that: string compare on the i2c_adapter->name field.
Pretty ugly.  You probably don't want to give your MPC8xx platform i2c
adapter different names depending on the i2c frontend which is connected
there, do you?

Next idea: add i2c_adapter->command() hook to have a way for the fe to
get config info from the adapter (and maybe other communication needed).
The adapter usually some per-card config info anyway and just pass that
down to the fe looks fine.  Turned out there are a few drawbacks on
that:
 - i2c adapter and dvb adapter not nessesarely that closely related
   that this approach looks reasonable (see above).
 - greg and other guys on lkml doesn't like the idea much because it's
   not type-safe.
Guess that isn't going to happen.

Thanks to sysfs it would also be possible for the frontend drivers to
walk around in the device tree and figure pci/usb vendor/device ids of
the underlying PCI card / USB device, then decide based on that how to
handle the specific card.  Not sure whenever that would work for all
hardware, cards which have config info stored in a eeprom come to mind.

Problem #3: Try to get auto-probing unter control.  .class should help
here alot.  For the remaining cases the idea is (was?) to also use
i2c_adapter->command() to get some config info and decide based on that
whenever to probe that adapter or not.  Walking the device tree to get
more info should work here as well.


Suggestion from lkml: don't autoprobe at all but have init functions
which ask the i2c_driver to attach to a specific i2c bus.  The init
function would be driver specific (cx22702_create() for example) and
therefore could also take some config info as parameter.  It would also
create a symbol dependency between the fe driver and the dvb adapter.

Drawback is that a dvb adapter driver which might have different
frontends attached depending on the card would load _all_ modules and
use one only _one_ of them (thus waste some RAM), which I don't like
very much.

On the other hand it would solve all three issues in one go:  Problem #3
is gone because we don't autoprobe any more, and Problems #1 + #2 can be
trivialy solved in a type-safe way by passing some args to
<frontend>_create().  We would automatically insmod the frontend for the
dvb adapter, which certainly would make life easier for the users.  We
would also get rid of some module load order issues because the dvb
adapter will allways be loaded last and unloaded first due to the symbol
dependency.  Hmm, not bad after all ...

  Gerd

-- 
return -ENOSIG;