Manu Abraham wrote: >>>> ts_bus_ctrl does a kind of reference counting. >>>> >>>> For readers: >>>> - fe->ops.ts_bus_ctrl(fe,1) is called during open >>>> - fe->ops.ts_bus_ctrl(fe,0) is called during close >>>> >>>> For the one and only writer: >>>> - fe->ops.ts_bus_ctrl(fe,1) is called during open >>>> - fe->ops.ts_bus_ctrl(fe,0) is called when the thread exits, >>>> usually after close >>>> >> So, how do you tell if the ts bus is already locked? >> >> >>> I didn't want to write it but this is also what I would do, and I >>> would also include the other dvb device nodes.. it doesn't make sense >>> to keep them open as non functional dummies, or even allow people to >>> open these nodes if the dvb mode is locked. >>> >> What about a device with two frontends? Maybe the DVB-T/Analog frontend is >> locked by the V4L device, but you can still use a DVB-S frontend with dvb. In >> that case the demux could still be opened and used. >> > > > This is what i stated multiple times: "lock the device bus". It is a > device property of a device with a single bus and 2 frontends. (A device > driver represents the Hardware configuration, you are not making > anything new/revolutionary here) > > Bus Locking wouldn't be necessary for a device with 2 frontends and 2 > buses (ie 1:1 ratio, locking is required in cases other than this 1:1 > case). That simple. But the general idea that carried forward was DVB > core has to do the locking, rather than individual devices, which was > conceptually wrong. > Agreed. The drivers should expose their resources and the v4l / dvb core should abstract that and deal with resource allocation on the drivers behalf. Stee _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
