how to use dvb_attach (was: Re: [linux-dvb] Re: Error unloading
WinTV NOVA T USB2)
xyzzy at speakeasy.org
Tue Aug 29 23:27:38 CEST 2006
On Tue, 29 Aug 2006, Patrick Boettcher wrote:
> On Mon, 28 Aug 2006, Trent Piepho wrote:
> > > On 8/22/06, Patrick Boettcher <patrick.boettcher at desy.de> wrote:
> > > > The wrong use_count for the dib3000mc is most likely because I'm not using
> > > > the dvb_attach-function for attaching the demod/frontend, because the
> > > > prototype of the dib3000mc_attach is not exactly the same as for other
> > > > demod-drivers.
> > > >
> > > > Why? Because with the dib3000mc_attach (and with the future coming
> > > > dib7000m_attach and dib7000p_attach) we can attach more than one demod at
> > > > the same time - will be used on devices arriving late fall/autumn).
> > > >
> > > > Can someone please advise me how to proceed?
> > You should not use dvb_frontend_detach() unless you are using dvb_attach(),
> > which you are not using.
> Am I using dvb_frontend_detach?
$ grep -n dvb_frontend_detach dvb-usb*.c
> > I think it would make a lot more sense if you had dib3000mc_attach() just
> > attach one frontend, like all the other front-end attach functions.
> For whom would it make more sense? My understanding of the attach-function
> is not, that it only has to attach exactly one frontend. If I missed
> something in the dvb_attach-discussion I'm sorry.
This is how all the other attach functions work. They return a pointer the
to the struct dvb_frontend that was attached or NULL on failure. Except
dib3000mc_attach() which is totally different. It makes it harder when you
one thing which doesn't work the way everything else does. In fact, I see
from this patch http://linuxtv.org/hg/v4l-dvb?cmd=changeset;node=4468 that
even you got it wrong when using dib3000mc_attach()
I also think that attaching one frontend with the attach function and
calling it multiple times would make the code over all simpler.
> > If something has multiple front-ends, just call the attach function
> > multiple times.
> For the so-called I2C-enumeration of the DiBcom-demods (to get all the
> demod reachable by I2C) it is necessary to have some information which is
> present in the config-struct. I actually don't like to change all that,
That would be dib3000mc_i2c_enumeration(demod,no_of_demods,default_addr),
which is never actually called in the current code?
It does not look like it needs anything in the dib3000mc_config structure,
only all the frontend pointers and the default i2c address.
It looks like it remaps the demods to different I2C addresses? Could you
just have a function that does this after all the demods have been
attached? Or just re-map them one at a time as they are attached? Have a
parameter to dib3000mc_attach that specifies the I2C address to re-map too
or 0 to not remap.
> > Why is dibusb_dib3000mb_frontend_attach() in dibusb-mb.c, and
> > dibusb_dib3000mc_frontend_attach in dibusb-common.c?
> Why why why? *sigh*. You can believe me, there is a reason:
> At first dibusb_dib3000mc_frontend_attach was only located in dibusb-mc.c,
> then a device appeared with the 3000mc inside but with USB firmware
> interface which normally only used with the 3000mb onboard. So, I put the
> dibusb_dib3000mc_frontend_attach in common, because it was used by two
> different modules.
This makes everything which uses dibusb-common depend on the 3000mc
demodulator module. Why not just put dibusb_dib3000mc_frontend_attach(),
the dvb-usb wrapper for the frontend attach function, in dib3000mc.c?
> > BTW, the error path in dib3000mc_attach() is broken.
> Thanks, but where? I'm too blind to see it.
It de-references uninitialized front-end pointers. I suppose that this
goes to show that the way the front-end attach function tries to do
multiple frontends at once makes it too complex.
More information about the linux-dvb