]> git.proxmox.com Git - mirror_ubuntu-artful-kernel.git/blame - Documentation/media/kapi/dtv-core.rst
doc-rst: kernel-doc: fix a change introduced by mistake
[mirror_ubuntu-artful-kernel.git] / Documentation / media / kapi / dtv-core.rst
CommitLineData
684ffa2d
MCC
1Digital TV (DVB) devices
2------------------------
3
4Digital TV Common functions
5---------------------------
6
7.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
8
9.. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h
10
11.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
12
13
d2f01985
MCC
14
15.. kernel-doc:: drivers/media/dvb-core/dvb_math.h
16 :export: drivers/media/dvb-core/dvb_math.c
17
18.. kernel-doc:: drivers/media/dvb-core/dvbdev.h
19 :export: drivers/media/dvb-core/dvbdev.c
20
21
22
684ffa2d
MCC
23Digital TV Frontend kABI
24------------------------
25
26Digital TV Frontend
27~~~~~~~~~~~~~~~~~~~
28
29The Digital TV Frontend kABI defines a driver-internal interface for
30registering low-level, hardware specific driver to a hardware independent
31frontend layer. It is only of interest for Digital TV device driver writers.
32The header file for this API is named dvb_frontend.h and located in
33drivers/media/dvb-core.
34
35Before using the Digital TV frontend core, the bridge driver should attach
d2f01985
MCC
36the frontend demod, tuner and SEC devices and call
37:cpp:func:`dvb_register_frontend()`,
684ffa2d 38in order to register the new frontend at the subsystem. At device
d2f01985
MCC
39detach/removal, the bridge driver should call
40:cpp:func:`dvb_unregister_frontend()` to
41remove the frontend from the core and then :cpp:func:`dvb_frontend_detach()`
42to free the memory allocated by the frontend drivers.
684ffa2d 43
d2f01985
MCC
44The drivers should also call :cpp:func:`dvb_frontend_suspend()` as part of
45their handler for the :c:type:`device_driver`.\ ``suspend()``, and
46:cpp:func:`dvb_frontend_resume()` as
47part of their handler for :c:type:`device_driver`.\ ``resume()``.
684ffa2d 48
d2f01985 49A few other optional functions are provided to handle some special cases.
684ffa2d
MCC
50
51.. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h
52
53
54Digital TV Demux kABI
55---------------------
56
57Digital TV Demux
58~~~~~~~~~~~~~~~~
59
60The Kernel Digital TV Demux kABI defines a driver-internal interface for
61registering low-level, hardware specific driver to a hardware independent
62demux layer. It is only of interest for Digital TV device driver writers.
63The header file for this kABI is named demux.h and located in
64drivers/media/dvb-core.
65
66The demux kABI should be implemented for each demux in the system. It is
67used to select the TS source of a demux and to manage the demux resources.
68When the demux client allocates a resource via the demux kABI, it receives
69a pointer to the kABI of that resource.
70
71Each demux receives its TS input from a DVB front-end or from memory, as
72set via this demux kABI. In a system with more than one front-end, the kABI
73can be used to select one of the DVB front-ends as a TS source for a demux,
74unless this is fixed in the HW platform.
75
76The demux kABI only controls front-ends regarding to their connections with
77demuxes; the kABI used to set the other front-end parameters, such as
78tuning, are devined via the Digital TV Frontend kABI.
79
80The functions that implement the abstract interface demux should be defined
81static or module private and registered to the Demux core for external
82access. It is not necessary to implement every function in the struct
83&dmx_demux. For example, a demux interface might support Section filtering,
84but not PES filtering. The kABI client is expected to check the value of any
d2f01985 85function pointer before calling the function: the value of ``NULL`` means
684ffa2d
MCC
86that the function is not available.
87
88Whenever the functions of the demux API modify shared data, the
89possibilities of lost update and race condition problems should be
90addressed, e.g. by protecting parts of code with mutexes.
91
92Note that functions called from a bottom half context must not sleep.
d2f01985 93Even a simple memory allocation without using ``GFP_ATOMIC`` can result in a
684ffa2d
MCC
94kernel thread being put to sleep if swapping is needed. For example, the
95Linux Kernel calls the functions of a network device interface from a
96bottom half context. Thus, if a demux kABI function is called from network
97device code, the function must not sleep.
98
99
100
101Demux Callback API
102------------------
103
104Demux Callback
105~~~~~~~~~~~~~~
106
107This kernel-space API comprises the callback functions that deliver filtered
108data to the demux client. Unlike the other DVB kABIs, these functions are
109provided by the client and called from the demux code.
110
111The function pointers of this abstract interface are not packed into a
112structure as in the other demux APIs, because the callback functions are
113registered and used independent of each other. As an example, it is possible
114for the API client to provide several callback functions for receiving TS
115packets and no callbacks for PES packets or sections.
116
117The functions that implement the callback API need not be re-entrant: when
118a demux driver calls one of these functions, the driver is not allowed to
119call the function again before the original call returns. If a callback is
120triggered by a hardware interrupt, it is recommended to use the Linux
121bottom half mechanism or start a tasklet instead of making the callback
122function call directly from a hardware interrupt.
123
d2f01985 124This mechanism is implemented by :cpp:func:`dmx_ts_cb()` and :cpp:func:`dmx_section_cb()`
684ffa2d
MCC
125callbacks.
126
684ffa2d
MCC
127.. kernel-doc:: drivers/media/dvb-core/demux.h
128
684ffa2d
MCC
129Digital TV Conditional Access kABI
130----------------------------------
131
132.. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h