On 8/9/07, Steven Toth <stoth@xxxxxxxxxxxxx> wrote: > Markus Rechberger wrote: > > On 8/9/07, Steven Toth <stoth@xxxxxxxxxxxxx> 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@xxxxxxx> > >>> > >>> > >>> > >> 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. > > > http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/c0817d73a2a9/linux/drivers/media/video/em28xx/em28xx-video.c > > > > 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. > > > > > http://mcentral.de/hg/~mrec/v4l-dvb-experimental/file/f9f3e6bdd6fc/linux/drivers/media/video/em28xx/em2880-dvb.c > > > > 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: > http://linuxtv.org/hg/~stoth/hvr3000/rev/a619436699cc > > 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 channels). 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 [1]. I intended to lock the filehandles when the spinning thread has stopped. [1] [PATCH] function for checking if the dvb framework is idle Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
