On Tue, 29 Aug 2006, Patrick Boettcher wrote: > On Mon, 28 Aug 2006, Trent Piepho wrote: > > > On 8/22/06, Patrick Boettcher <patrick.boettcher@xxxxxxx> 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? Yes. $ grep -n dvb_frontend_detach dvb-usb*.c dvb-usb-dvb.c:189: dvb_frontend_detach(d->fe); dvb-usb-dvb.c:207: dvb_frontend_detach(d->fe); > > 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. _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
