[linux-dvb] [PATCH] add device node locking possibility to dvbcore
mrechberger at gmail.com
Thu Aug 9 21:12:58 CEST 2007
On 8/9/07, Steven Toth <stoth at hauppauge.com> wrote:
> Markus Rechberger wrote:
> > On 8/9/07, Steven Toth <stoth at hauppauge.com> wrote:
> >> Markus Rechberger wrote:
> >>> Following patch adds a rather primitive way to temporary lock dvb
> >>> devicenodes, this can be useful for hybrid devices which use the
> >>> video4linux framework for the analogue TV part and the dvb framework for
> >>> digital TV if only one mode can be accessed at a time.
> >>> Signed-off-by: Markus Rechberger <markus.rechberger at amd.com>
> >> Call me dumb but I don't understand how this patch helps v4l devices. :)
> >> Allocation/management of a single card resource doesn't belong inside
> >> the dvb framework, these answers need to come from the bridge-frameworks
> >> (via callbacks from dvb-core or the analog equivalent) who are better
> >> placed to make the decision about hybrid tuners, bus capacity or
> >> allocation, in use devices.
> >> As a working example, I added similar support in my older HVR3000 tree
> >> where two frontends share a single transport bus. The code is old but it
> >> demonstrates a solution, much the my earlier patches for shared
> >> DVB/Blackbird boards also.
> >> I understand how this patch helps the current dvb tree, it stops
> >> multiple people opening a device but that's it. ... Or, maybe I've just
> >> missed to point.
> > Hi Steve,
> > the bridge framework triggers locking these filehandles.
> > line 434
> > this locks the dvb nodes if someone tries to open the v4l devicenode,
> > it first checks if there's still something active at the DVB side.
> > Line 471 - 484 if this would go into the dvb core we'd have a callback
> > for locking the device nodes.
> Your comment about lines 471-484 make sense, but that code is not
> referenced via a callback (that I can see in the DVB patch) ... which is
> what I expected to see.
> To do this cleanly in the dvb-core (or any v4l-core) I suggest requires
> callbacks into the bridge-frameworks and I didn't see those callbacks
> clearly defined in either your original patch, or your follow up
> patches. I was pretty sure I did something similar for the
> DVB/MpegEncoder shared bus support.
> Have you seen this? http://linuxtv.org/hg/~stoth/hvr3000/rev/4b846f1d939b
> Or more importantly this:
> Can we just re-use that?
I had a look at it, could it be that you missed that the thread keeps
spinning in the background and does register writes after a devicenode
has been closed? (eg. using the scan utility for scanning for dvb
This was a problem with the hvr900, the thread still tried to access
the dvb demod and all the writes failed. That for I submitted .
I intended to lock the filehandles when the spinning thread has stopped.
 [PATCH] function for checking if the dvb framework is idle
More information about the linux-dvb