[linux-dvb] [RFC] Hybrid tuner refactoring, phase 1

Mauro Carvalho Chehab mchehab at infradead.org
Mon Aug 20 20:14:23 CEST 2007

Em Seg, 2007-08-20 às 11:22 -0400, Michael Krufky escreveu:
> Manu Abraham wrote:
> > You will need to handle the IOCTL calls for analog operations some
> > place, whatever you remove.
> >
> > I don't see at any place you are handling the IOCTL's directly in the
> > drivers. So you will be using callbacks from the place where you
> > are applying the ioctl's
> You are getting ahead of things, Manu.  The tuner.ko module will 
> continue to remain as the v4l2 / i2c_client interface to the tuning 
> functionality.

For now, at a first glance, the way it was mapped seems fine. The way
the struct is described, a frontend can handle digital and/or analog
tuning. This seems OK. 

Using void* priv will just create some troubles, since this will avoid
gcc to do typecast checkings for no gain.

>   We do not (yet) have to add these ioctl calls to the 
> card-level drivers, as they will continue to interact with the various 
> tuner modules via tuner.ko's i2c_client interface.
> I do have plans to remove this tuner.ko interface in the future, but 
> that is way way in the future, after most of my planned tuner 
> refactoring work is complete.  There will be a completely separate RFC 
> issued at that time.  When that happens, the card level drivers will 
> include dvb_frontend.h, just as the dvb card drivers do, and access the 
> tuning methods that way, through the dvb_frontend structure.

Removing the common ioctl handling code done by tuner.ko doesn't seem to
be nice, since this would generate overhead on other drivers that will
need to absorb the common tuner handling and probing. However, as
pointed, this should be discussed later, after finishing the tuner


I didn't reviewed yet the tea5767 changes. I expect to do it later this
week (maybe today night).

More information about the linux-dvb mailing list