[linux-dvb] [PATCH] add device node locking possibility to dvbcore

Markus Rechberger mrechberger at gmail.com
Wed Aug 15 16:35:51 CEST 2007


On 8/15/07, Steven Toth <stoth at hauppauge.com> wrote:
> Steven Toth wrote:
> > Markus Rechberger wrote:
> >
> >> 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.
> >>>>
> >>>>
> >>>>
> >>>
> 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



More information about the linux-dvb mailing list