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

[Andrew de Quincey <adq_dvb@lidskialf.net>]

On Tuesday 14 Sep 2004 15:52, you wrote:
> 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.

Yeah, you're right. I think Holger's idea is to split up dvb-ttpci into 
seperate drivers, one for each device supporting each frontend. I'm not sure 
I like that.

> > * 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.

I thought it was ok, as long as each firmware request used a different name 
for the firmware? If this isn't the case, then yeah, this is a killer.

> 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.

We'd still need to be able to say which i2c device in particular should probe 
- certain of the frontends are clashing as well.

> 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 get you - so most of the frontend code would be the same as it currently is, 
except we'd add an FE_REGISTER command... would this be kinda like what I 
proposed before with the FE_CONFIGURE ioctl and the frontend-specific data 
structures?

This does have the major advantage that the code changes are much smaller.

> 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.

Cool - as long we find *a* way to fix it, I'm happy.