Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: Proposal for new frontend architecture
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
Home |
Main Index |
Thread Index