On 8/15/07, Steven Toth <stoth@xxxxxxxxxxxxx> wrote: > Steven Toth wrote: > > Markus Rechberger wrote: > > > >> 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? > >>> > >>> > >>> > >> Since I don't see any move forward from anyone again, can you extract > >> that locking callback and submit it independently? I can work around > >> the issue that the dvb core still tries to access DVB components after > >> a device has been closed, although you might have to verify that issue > >> within your drivers too. > >> > >> > >> > > Sure, I'll prepare a patch later this evening. > > > > > 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. > Ok I'm fine with that one so far. thanks, Markus _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
