On Thu, 14 Jun 2007, Michael Krufky wrote:
> Luca Olivetti wrote:
> > En/na Trent Piepho ha escrit:
> >> On Thu, 14 Jun 2007, Luca Olivetti wrote:
> >>> Well, I'm doing the attach myself to attach the tuner to the frontend
> >>> the first time it is opened, so if I remove the code there will be at
> >>> least one reference to the mt2060 (or qt1010, depending on the model) so
> >>> it cannot be unloaded.
> >>
> >> The tuner gets attached once when you call dvb_attach() from
> >> af9005_fe_init. It will get detached once when dvb_frontend_detach() is
> >> called. Everything balanced.
> >
> > but dvb_frontent_detach doesnt' know anynthing about the tuner (since
> > it's in the frontend private data), so if I don't do the put_symbol
> > myself in af9005_fe_release (as I do the dvb_attach myself in
> > af9005_fe_init) there will be a dangling reference count, yes?
>
> You are incorrect -- dvb_frontend_detach has access to the entire "struct
> dvb_frontend *fe" , and dvb-core will call fe->ops.tuner_ops.release function
> itself and dvb_frontend_detach will handle the module detachment.
Exactly, the dvb_frontend struct contains the tuner. In fact, the pointer
returned by the tuner attach functions is just the dvb_frontend pointer you
passed in. The tuner attach functions don't return a new tuner object (there
is no dvb_tuner object), they add the tuner functions into the frontend. One
could have a frontend with no tuner.
In af9005_fe_set_frontend(), you do this:
ret = state->tuner->ops.tuner_ops.set_params(state->tuner, fep);
What you should do is:
ret = fe->ops.tuner_ops.set_params(state->tuner, fep);
I don't think you need the state->tuner field really. Just replace all the
"state->tuner->ops..." with "fe->ops...". And change (state->tuner != NULL)
to (fe->ops.tuner_ops.release != NULL), or add a one bit flag
state->tuner_is_attached and use that.
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
