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

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

Hi,

On 13.09.2004 18:55, Andrew de Quincey wrote:
> * Frontends configurable by card drivers.
> * Impossible to NOT load the appropriate frontend.
> * Frontends selected explicitly - no autoprobing unless done
> intelligently by the card driver.

Did you think about the dvb-ttpci driver? AFAIK it works with ves1820, 
grundig_29504-401, stv0299, ves1x93 and sp887x frontends. Your approach 
will introduce functional dependencies to all these modules (ie. all 
modules will be autoloaded). This is certainly not what you want. Same 
goes for some budget cards.

If we just do a request_module() and then do some kind of i2c client 
FE_CONFIGURE ioctl with frontend specific init data, then we don't.

I think I'll prepare some example code for the stv0299 driver, which is 
cluttered.

> * Frontends converted to demodulator library modules.
I fail to see the point where this brings any benefits, it just pollutes 
the kernel namespace and introduces functional dependencies.

> * Kernel i2c code removed from frontends.
I see that you do firmware loading through the pci device. This does not 
work with the dvb-ttpci driver, because it already requests the firmware 
this way.

> * PLLs removed from frontend drivers.
> The only thing we couldn't agree on was the PLL stuff. We did agree that the 
> code should be removed from the demod drivers, but it was how to do it that 
> was the problem. Therefore, here are worked examples of the 
> tda1004x/budget-ci with both proposals - tell us which is best (assuming you 
> like the whole idea of course).
Point taken. PLLs are evil, just look at stv0299.c. But it's not just 
the demod code. All sort of stuff is hw dependend, stv0299 is a good 
example: symbolrate, inversion and configuration depend on the driver, too.

> holgers proposal:
> PLLs are implemented by the card driver itself.
>
> Pros:
> * Simple
> * i2c interface greatly simplifed (write_demod() to write a byte to the demod 
> - no need for the frontend driver to know addresses).
>
> Cons:
> * Duplication of PLL code between card drivers if more than one card uses the 
> same PLL.
Shouldn't be a problem, just two or three functions if I understand 
correctly.

> andrews proposal:
> Common PLLs moved to a pll library if they're used by more than one card. The 
> PLL library is a seperate module in its own right containing implementations 
> of common PLLs. (cards are still free to implement their own PLL drivers if 
> they want to).
>
> Pros:
> * Common PLLs share the same implementation (some PLLs are tricky to get 
> exactly right).
> * Mini-i2c interface is more flexible (although more complex)
>
> Cons:
> * More complex, so therefore more susceptible to coding errors.
> * The PLL code itself is usally quite small - maybe the added complexity is 
> overkill.
Yes, IMO the complexity is overkill.

Ok, my suggestion still is:

To get the autoprobing right:
- add "ADAP_NO_PROBE" flag to i2c adapter, so no automatic probing
- use request_module() in driver to request frontend modules which must 
be there because of PCI id identification (for example there is only one 
pci id for dvb-c dvb-ttpci cards)
- add a probe_this_i2c_id_on_this_i2c_bus() function to i2c-core
- afterwards walk the i2c client list on the dvb-adapter. If the wanted 
device is there, register the dvb devices, if not -ENODEV.

To get the configuration out of the frontend driver:
- PLL functions are implemented by the driver, not the frontend and are
provided when FE_REGISTER is called.
- when PLL access is necessary, functions from the driver are called
- same goes for other stuff like voltage, symbolrate, inversion and 
other settings

I don't feel comfortable tossing away the current infrastructure just to 
solve the two above problems which don't look too complicated to solve 
with the existing stuff.

Hopefully I can provide some sample code for my proposals tomorrow.

CU
Michael.