[linux-dvb] [RFC/PATCH] moving commonly used frontend configs to separate drivers

Andrew de Quincey adq_dvb at lidskialf.net
Sat Jul 23 15:21:01 CEST 2005


On Saturday 23 July 2005 09:30, Andreas Oberritter wrote:
> Hi,
>
> how about moving some of the board dependent stuff of the frontend
> functions out of the adapter drivers?
>
> Making the PLL functions independent of the adapter driver works by
> passing the i2c adapter pointer to the PLL callback instead of getting
> it from private data pointers (which only works for a single bus per
> adapter). So this change is needed anyway, because there can be adapters
> with multiple frontends on multiple i2c buses.
>
> I've created a patch which moves most of the code for frontends with
> known manufacturer and model into small, well maintainable files.
>
> Frontends I left out for now include those who need a request_firmware
> callback, because I am not yet sure how to get that out of the config
> structs. Maybe passing the required dev pointer to the attach function
> will be sufficient.
>
> The files have been run through Lindent and i2c error code checking has
> been improved, thus making the old functions larger. Anyway, now there
> are fewer lines of code than before, after removing all the duplicates.
>
> It even fixes a bug by accident which would not allow a ttusb device !=
> rev 2.2 be plugged in after a ttusb device with revision 2.2.
>
> Because the patch's size is 111 kilobytes I've put it on my web server:
> http://www.saftware.de/frontend.diff
>
> It's not finished yet, but I hope to get some comments from you.

Isn't this what the dvb-pll.c/h stuff was trying to achieve? Or does that have 
drawbacks? 

One thing though - the 'frontends' dir is a bit of a misnomer - it should 
really be 'demodulators', but we're kinda stuck with it now.  If you did 
this, it would be good to differentiate the non-demodulator code from the 
demodulator code - put it in a subdirectory, or prefix the filenames by 
something.. 

As to what I'd suggest for a prefix/dirname.... hmm.. its not _really_ "PLL" 
is it; since you're naming it after the tinbox and not the PLL chip itself. 
What about "dvbnim_" since most of the manufacturers call those things NIMs 
anyway?




More information about the linux-dvb mailing list