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

[Michael Hunold <hunold-ml@web.de>]

Hi,

the discussion is getting quite cluttered, so I try to discuss only one 
topic at a time. Hope this helps.

There is a parallel, non-dvb discussion about adding 
i2c_adapter->command() on LKML now named "[PATCH][2.6] Add command 
function to struct i2c_adapter".

I didn't succeed in CCing linux-dvb, so please have a look at that 
discussion separately.

On 22.09.2004 13:32, Gerd Knorr wrote:
> 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. 
I think we have to find a consensus on what a "frontend" actually is. 
From the discussion I learned that there is no such thing as a i2c 
frontend device. The frontend is the combination of chipsets inside the 
tin box.

If we want to keep separate i2c client drivers, then there should be a 
plain demod driver. The pll configuration and *everything* related to 
dvb frontends should be handled by the dvb driver. The demod driver only 
provides a common interface for getting informations out and related 
configuration into the device. FE_SET_FRONTEND needs to program nearly 
all helper chipsets, but the demod only needs litte informations. 
FE_READ_STATUS on the other hand only needs a simply "give me your 
configuration" function.

It's a big question, if keeping a kernel i2c demod driver is really a 
good thing. There is the i2c_client->command() interface that can be 
used to give commands from the adapter to the client. As we have seen, 
there is sometimes the need to have a client->adapter communication as 
well, so we proposed i2c_adapter->command(). Greg K-H and others dislike 
this idea, because it's not type safe. I now agree with that.

Ok, but what's the solution now?

Similar to the results of the LKML discussion, it's perhaps time to say 
good-bye to generic i2c busses. In the case of PCI dvb cards, there is 
only a dvb i2c bus, where most of the time known helper chipsets can be 
found. So there should be some kind of dvb i2c bus with a well-defined 
interface (say: function pointers) so that client drivers and adapters 
can speak with each other (similar to the ioctl approach, but type safe)

The adapter registers this special bus within the system and requests 
other modules to join in. The dvb i2c adapters provide functions for dvb 
i2c clients to query h/w dependent informations. If an dvb i2c client 
joins the bus, they provide functions for the dvb i2c adapter to call 
certain actions in a type-safe manner.

In that scenario, we can strip down the frontend drivers to plain demod 
drivers and either provide other pll drivers or keep the pll stuff 
inside the adapter driver.

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?

For example my tea6415c or tea6420c drivers, these device are matrix 
switches and really dumb. The adapter currently use the ioctl interface 
to control the configuration of the matrix.

IMO having a "well-defined interface" in that case doesn't really help, 
because there is only one function ("set input a to output b") these 
chipsets have.

> 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.
We have to keep in mind the problems on set-top-box systems. There, we 
only have one i2c bus that can have it all: dvb "frontend", thermal 
sensors, audio/video multiplexer, analog/digital converters and 
digital/analog converters.

If we are going to have well-defined interfaces on a i2c bus, then on 
these systems the adapter that registers the i2c bus needs to provide 
interfaces to all of these subsystems if required, ie. if it ask a 
audio/video multiplexer to attach, then it needs to provide a different 
set of interface functions, so attaching a device involves providing 
interface functions.

One big problem is that vendor-kernels using the current i2c 
implementation in 2.4 and 2.6 must be supported. They simply register an 
i2c adapter in a separate module (sometimes in-kernel) and are done with 
it. There is no way to allow client->adapter or adapter->client 
communication. When we introduced FE_(UN)REGISTER this became evident: 
the kernel i2c drivers needed to be patched -- sometimes this is not 
possible.

If we want to follow the idea of providing interfaces, then we perhaps 
need to create a completely separate infrastructure that achieves this 
and we cannot extend the existing i2c interface.

CU
Michael.