On 8/17/07, Oliver Endriss <o.endriss@xxxxxx> wrote:
> Markus Rechberger wrote:
> > On 8/17/07, Oliver Endriss <o.endriss@xxxxxx> wrote:
> > > Markus Rechberger wrote:
> > > > On 8/17/07, Oliver Endriss <o.endriss@xxxxxx> wrote:
> > > > > Steven Toth wrote:
> > > > > > The ts_bus_ctrl function pointer / callback is already in the
> > > mainline,
> > > > > > check dvb_frontend.c for more details. You shouldn't need a patch
> from
> > > me.
> > > > >
> > > > > ACK, should be enough to do this kind of locking.
> > > > >
> > > > > Furthermore, with this callback, the dvb_frontend_active() routine
> from
> > > > > ' [PATCH] function for checking if the dvb framework is
> idle'
> > > > > is not required at all. The callback is aware whether the frontend
> is
> > > > > running or not...
> > > > >
> > > > As far as I've seen the callback will be called as soon as the device
> > > > gets closed, even though the thread might still be spinning in the
> > > > background and the subsystem might still access DVB components, this
> > > > is why dvb_frontend_active is still needed.
> > > > Closing the devicenode and that callback doesn't mean that the device
> is
> > > idle.
> > >
> > > Ok, this should be fixed. What about this patch:
> > >
> > > diff -r dd58780b6fb4 linux/drivers/media/dvb/dvb-core/dvb_frontend.c
> > > --- a/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Thu Aug 09
> 16:30:39
> > > 2007 +0200
> > > +++ b/linux/drivers/media/dvb/dvb-core/dvb_frontend.c Fri Aug 17
> 20:07:28
> > > 2007 +0200
> > > @@ -596,6 +596,10 @@ restart:
> > > mb();
> > >
> > > dvb_frontend_wakeup(fe);
> > > +
> > > + if (fe->ops.ts_bus_ctrl)
> > > + fe->ops.ts_bus_ctrl (fe, 0);
> > > +
> > > return 0;
> > > }
> >
> > as I wrote earlier the thread can be idle/closed even before the node
> > gets closed (you can test that with kaffeine, and you can test the
> > other case with the scan utility)
>
> How can this happen? Afaics the fe thread may continue to exist after
> the device node was closed, but not vice-versa.
>
> >
> > >
> > > @@ -1101,9 +1105,10 @@ static int dvb_frontend_release(struct i
> > >
> > > if ((file->f_flags & O_ACCMODE) != O_RDONLY)
> > > fepriv->release_jiffies = jiffies;
> > > -
> > > - if (fe->ops.ts_bus_ctrl)
> > > - fe->ops.ts_bus_ctrl (fe, 0);
> > > + else {
> > > + if (fe->ops.ts_bus_ctrl)
> > > + fe->ops.ts_bus_ctrl (fe, 0);
> > > + }
> > >
> >
> > can you explain this? to me it doesn't look right. Before it always
> > called ts_bus_ctrl and afterwards it has a dependency to the access
> > mode bits?
>
> ts_bus_ctrl does a kind of reference counting.
>
> For readers:
> - fe->ops.ts_bus_ctrl(fe,1) is called during open
> - fe->ops.ts_bus_ctrl(fe,0) is called during close
>
> For the one and only writer:
> - fe->ops.ts_bus_ctrl(fe,1) is called during open
> - fe->ops.ts_bus_ctrl(fe,0) is called when the thread exits,
> usually after close
>
in that case the thread might exit before the filehandle got closed..
so it might lock/unlock the device even with an open filehandle.
Markus
_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
