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

[Holger Waechtler <holger@qanu.de>]

Andrew de Quincey wrote:
> Hi, here is what Holger and I have been working on for the last couple of 
> days.
>
> Main features:
> * Frontends converted to demodulator library modules.
> * Kernel i2c code removed from frontends.
> * Frontends configurable by card drivers.
> * Impossible to NOT load the appropriate frontend.
> * Frontends selected explicitly - no autoprobing unless done intelligently by 
> the card driver.
> * PLLs removed from frontend drivers.
>
> Note: although we've removed the kernel i2c code from the frontends, the card 
> drivers are still using it to access the physical i2c buses (it is now up to 
> the card driver as to how to interface to i2c/whatever bus).
>
> 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).
>
>
> 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.
>
>
> 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.
>
>
>
> Holger - sorry if I've missed any pros/cons, just reply with additional ones.
no, sounds correct...

maybe two additions:

 - keeping the PLLs in the card driver prevents them from getting
   accidentally changed when optimizing code for other cards. (has
   happened quite often in the past, the most extreme example is the
   stv0299, check the CVS logs - )

 - all DEBI functions should get moved to a budget_debi.c file,
   all msp430 related functions to a file called budget_msp430_ir.c,
   all ciintf_XXX functions to a file called budget_ciintf.c.
   This makes the budget driver code also library-alike, every card
   driver is free to choose which parts of the library it needs.

Take the code as sample code, budget.c should get renamed to 
budget_tda1004x.c to indicate that it only handles the tda1004x-based 
cards. The PCI ids not matching this card need to get removed from the 
PCI device ID table.

The return value of tda10045_init() needs to get checked in order to 
avoid that the driver accidentally attaches to the wrong card.

hope that's enough to explain the concept more in detail,
what do you think?

Holger