[linux-dvb] Re: Hybrid tuner proposal (V4L/DVB)

Markus Rechberger mrechberger at gmail.com
Mon Apr 9 18:01:11 CEST 2007

On 4/8/07, Johannes Stezenbach <js at linuxtv.org> wrote:
> On Thu, Apr 05, 2007, Markus Rechberger wrote:
> > I sent this proposal to several individual developers already around
> > 1-2 weeks ago, and received several comments, maybe I should give it a
> > try to push a very last discussion about it.
> >
> > Video4Linux/DVB Hybrid Tuner Support
> > ====================================
> ...
> > >Mauro wrote that requesting the tuner module first and afterwards call an
> > >init function within the driver
> > >which requested that module, this might be a solution for using
> > >initialization functions similar to
> > >usb_register/usb_deregister.
> > >on the other side this would break the dvb_attach approach and it might
> > >require much bigger changes in the
> > >dvb framework (?)
> > >This approach is currently partly implemented in v4l-dvb-kernel on
> > >mcentral (http://mcentral.de/hg/~mrec/v4l-dvb-kernel)
> >
> > a current implementation which uses the unified module approach and a
> > similar approach like dvb_attach can be found
> > at:
> > http://mcentral.de/hg/~mrec/v4l-dvb-experimental
> > (see tuner-core.c, v4l_dvb_tuner.h)
> In the discussions one month ago I had the impression that serveral
> people agreed on this or at least wanted to help to do the
> necessary work to get this merged.

writing != doing..

> All private comments to Markus are fine, but if there's
> any interest in getting this stuff merged, you need to show
> it publicly.

the work is available in v4l-dvb-experimental, I'm fully done with it
and people on the em28xx mailinglist are posting about current
implementation problems (there's an issue with request_firmware
actually at the moment)

> Any comments on the code are good. Not saying anything is bad.
> FWIW, I very briefly looked at
> http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/d1e8753a491b/linux/include/media/v4l_dvb_tuner.h
> and I think the V4L_OPS macro is invalid because it yields a pointer
> to a variable on the stack which just went out of scope.
> This might work by accident, but IMHO gcc is allowed to
> reuse the stack space for something else immediately after
> the closing brace.

it just gets converted into another format for that functioncall, this
is one point I'd like to discuss and improve actually it works the way
it is but it might be done in a better way.

Someone might have a better idea how to integrate this, maybe moving
that structure to SET_FRONTEND etc.

Another issue is using symbol_request there's definitelly no bug in
the code and the usecount only jumps up to 1 even if it's used 2
times, that problem is solved for the em2880-dvb/em28xx in that
repository but it's not intended to work that way I'd say.

thanks for looking at it,


More information about the linux-dvb mailing list