Re: [PATCH] add device node locking possibility to dvbcore

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/17/07, Oliver Endriss <o.endriss@xxxxxx> wrote:
> Steven Toth 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.
>
> ACK, should be enough to do this kind of locking.
>
> Furthermore, with this callback, the dvb_frontend_active() routine from
> ' [PATCH] function for checking if the dvb framework is idle'
> is not required at all. The callback is aware whether the frontend is
> running or not...
>
As far as I've seen the callback will be called as soon as the device
gets closed, even though the thread might still be spinning in the
background and the subsystem might still access DVB components, this
is why dvb_frontend_active is  still needed.
Closing the devicenode and that callback doesn't mean that the device is idle.

Markus

_______________________________________________
linux-dvb mailing list
linux-dvb@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb

[Index of Archives]     [Linux Media]     [Video 4 Linux]     [Asterisk]     [Samba]     [Xorg]     [Xfree86]     [Linux USB]

  Powered by Linux