Instead of using media_dev argument for dvb_create_media_graph(),
use the adapter.
That allows to create a stub for this function, if compiled
without DVB support, avoiding to add extra if's at the drivers.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
For now, let's keep the DVB-specific media controller links enabled
by default. On most devices, this is fixed anyway, so no big issue.
Ok, the demux actually have dynamic links based on the filters, but
we don't represent them yet, as the media controller currently lacks
the capability of dynamically create/delete entities.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
We need to create a DVB graph, linking the several DVB devnodes.
Add such function. Please notice that this helper function
doesn't take into account devices with multiple DVB adapters
and frontends.
For devices with multiple adapters, they should either create two
different media controller instances or to improve this function
to take the adapter ID into account.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
While on some devices the tuner is bound inside the frontend,
other devices use a separate subdevice for it.
So, in order to be more generic, better to map it with two
pads.
That will allows to use the media controller to lock the tuner
between the DVB and the V4L2 sub-drivers, on hybrid devices.
While here, change the logic to use pad 0 as sink for devices
with both sink and source pads.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
We want to represent the links between the several DVB devnodes,
so let's create PADs for them.
The DVB net devnode is a different matter, as it is not related
to the media stream, but with network. So, at least for now, let's
not add any pad for it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Provide a way to register media controller device nodes
at the DVB core.
Please notice that the dvbdev callers also require changes
for the devices to be registered via the media controller.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Since most dvb ioctls wrap their real work with dvb_usercopy, the static mutex
used in dvb_usercopy effectively is a global lock for dvb ioctls.
Unfortunately, frontend ioctls can be blocked by the frontend thread for
several seconds; this leads to unacceptable lock contention. Mitigate that by
pushing the mutex from dvb_usercopy down to the individual, device specific
ioctls.
There are 10 such ioctl functions using dvb_usercopy, either calling it
directly, or via the trivial wrapper dvb_generic_ioctl. The following already
employ their own locking and look safe:
• dvb_demux_ioctl (as per dvb_demux_do_ioctl)
• dvb_dvr_ioctl (as per dvb_dvr_do_ioctl)
• dvb_osd_ioctl (as per single non-trivial callee)
• fdtv_ca_ioctl (as per callees)
• dvb_frontend_ioctl
The following functions do not, and are thus changed to use a device specific
mutex:
• dvb_net_ioctl (as per dvb_net_do_ioctl)
• dvb_ca_en50221_io_ioctl (as per dvb_ca_en50221_io_do_ioctl)
• dvb_video_ioctl
• dvb_audio_ioctl
• dvb_ca_ioctl
Signed-off-by: Nikolaus Schulz <schulz@macnetix.de>
Signed-off-by: Michael Krufky <mkrufky@linuxtv.org>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
At commit 07d106d0, Linus pointed out that ENOIOCTLCMD should be
translated as ENOTTY to user mode.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
just like the V4L2 core, move the DVB core to drivers/media, as the
intention is to get rid of both "video" and "dvb" directories.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Mauro Carvalho Chehab