Steven Toth wrote: > Trent Piepho wrote: > > On Fri, 17 Aug 2007, Markus Rechberger wrote: > > > >>>> 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. > >>> > > > > Yes, how can that happen? What will make the dvb frontend thread exit before > > the device is closed? > > > > I don't know. I should probably spend sometime reminding myself of the > purpose of the thread. It cannot happen, unless someone kills the thread... > > Maybe it would be a good idea to do what Andreas suggested and have the > > frontend release function block until the frontend thread has exited. AFAIK, > > the thread hanging around after the device is closed does nothing but cause > > problems. It's a very common FAQ, "Q: Why does it mythtv not work if I > > change from a digital channel to an analog one? A: You need to set > > dvb_shutdown_timeout to 0." What's the purpose of dvb_shutdown_timeout > 0? Does anyone know, why dvb_shutdown_timeout was introduced initially? I don't have a problem if it will be removed, but I suspect there was a reason for it. Anyway, we should set the default to 0. > We should be clear that the ts_bus_ctrl isn't design to lock or version > count in any way. The purpose of the callback is to allow the bridge to > determine whether the it has sufficient hardware resources to allow the > ops open to complete (assuming that the callers wants data). The best > example of this todate has been the HVR1300 sub-drivers in which a V4L > and DVB ops structures both need to access frontends on the single PCI bus. Ok, then it is probably used the wrong way in dvb_frontend.c. It should only be called for - the first open of the fe device and - the last close of the fe device (or maybe when the frontend thread exits, whichever comes later). For multiple tuners ts_bus_ctrl is responsible to do the right thing. > Having a DVB application interfere with the V4L application's use of the > bus isn't acceptable. > > Personally, I think ts_bus_ctrl needs to be replaced with a single > resource allocation/deallocation mechanism that extends beyond simple > bus negotiation into tuners, demods, encoders and other devices. > > >>> 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 > >>> > > > > So, how do you tell if the ts bus is already locked? > > > > > > Until now it's never been a requirement. Simply try to lock it. If it fails, you know that it is taken. ;-) > >> I didn't want to write it but this is also what I would do, and I > >> would also include the other dvb device nodes.. it doesn't make sense > >> to keep them open as non functional dummies, or even allow people to > >> open these nodes if the dvb mode is locked. > >> > > > > What about a device with two frontends? Maybe the DVB-T/Analog frontend is > > locked by the V4L device, but you can still use a DVB-S frontend with dvb. In > > that case the demux could still be opened and used. > > > > > The HVR1300 (and HVR3000 / 4000) prohibit this by using ts_bus_ctrl, > these are good examples. Btw, someone reported at vdr-portal, that cx88_dvb does not allow the frontend to be opened more than once anymore. Seems to be caused by calling the ts_bus_ctrl hook in dvb_frontend. Note that it should always be possible to open the fe for additional readers. femon can be run concurrently, for example. CU Oliver -- ---------------------------------------------------------------- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ---------------------------------------------------------------- _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
