]>
Commit | Line | Data |
---|---|---|
684ffa2d MCC |
1 | Digital TV (DVB) devices |
2 | ------------------------ | |
3 | ||
4 | Digital TV Common functions | |
5 | --------------------------- | |
6 | ||
7 | .. kernel-doc:: drivers/media/dvb-core/dvb_math.h | |
8 | ||
684ffa2d MCC |
9 | .. kernel-doc:: drivers/media/dvb-core/dvbdev.h |
10 | ||
b6df512a MCC |
11 | Digital TV Ring buffer |
12 | ---------------------- | |
13 | ||
14 | Those routines implement ring buffers used to handle digital TV data and | |
15 | copy it from/to userspace. | |
16 | ||
17 | .. note:: | |
18 | ||
19 | 1) For performance reasons read and write routines don't check buffer sizes | |
20 | and/or number of bytes free/available. This has to be done before these | |
21 | routines are called. For example: | |
22 | ||
23 | .. code-block:: c | |
24 | ||
25 | /* write @buflen: bytes */ | |
26 | free = dvb_ringbuffer_free(rbuf); | |
27 | if (free >= buflen) | |
28 | count = dvb_ringbuffer_write(rbuf, buffer, buflen); | |
29 | else | |
30 | /* do something */ | |
31 | ||
32 | /* read min. 1000, max. @bufsize: bytes */ | |
33 | avail = dvb_ringbuffer_avail(rbuf); | |
34 | if (avail >= 1000) | |
35 | count = dvb_ringbuffer_read(rbuf, buffer, min(avail, bufsize)); | |
36 | else | |
37 | /* do something */ | |
38 | ||
39 | 2) If there is exactly one reader and one writer, there is no need | |
40 | to lock read or write operations. | |
41 | Two or more readers must be locked against each other. | |
42 | Flushing the buffer counts as a read operation. | |
43 | Resetting the buffer counts as a read and write operation. | |
44 | Two or more writers must be locked against each other. | |
45 | ||
46 | .. kernel-doc:: drivers/media/dvb-core/dvb_ringbuffer.h | |
d2f01985 MCC |
47 | |
48 | ||
684ffa2d MCC |
49 | Digital TV Frontend kABI |
50 | ------------------------ | |
51 | ||
52 | Digital TV Frontend | |
53 | ~~~~~~~~~~~~~~~~~~~ | |
54 | ||
55 | The Digital TV Frontend kABI defines a driver-internal interface for | |
56 | registering low-level, hardware specific driver to a hardware independent | |
57 | frontend layer. It is only of interest for Digital TV device driver writers. | |
58 | The header file for this API is named dvb_frontend.h and located in | |
59 | drivers/media/dvb-core. | |
60 | ||
61 | Before using the Digital TV frontend core, the bridge driver should attach | |
d2f01985 | 62 | the frontend demod, tuner and SEC devices and call |
7b998bae | 63 | :c:func:`dvb_register_frontend()`, |
684ffa2d | 64 | in order to register the new frontend at the subsystem. At device |
d2f01985 | 65 | detach/removal, the bridge driver should call |
7b998bae MCC |
66 | :c:func:`dvb_unregister_frontend()` to |
67 | remove the frontend from the core and then :c:func:`dvb_frontend_detach()` | |
d2f01985 | 68 | to free the memory allocated by the frontend drivers. |
684ffa2d | 69 | |
7b998bae | 70 | The drivers should also call :c:func:`dvb_frontend_suspend()` as part of |
d2f01985 | 71 | their handler for the :c:type:`device_driver`.\ ``suspend()``, and |
7b998bae | 72 | :c:func:`dvb_frontend_resume()` as |
d2f01985 | 73 | part of their handler for :c:type:`device_driver`.\ ``resume()``. |
684ffa2d | 74 | |
d2f01985 | 75 | A few other optional functions are provided to handle some special cases. |
684ffa2d MCC |
76 | |
77 | .. kernel-doc:: drivers/media/dvb-core/dvb_frontend.h | |
78 | ||
79 | ||
80 | Digital TV Demux kABI | |
81 | --------------------- | |
82 | ||
83 | Digital TV Demux | |
84 | ~~~~~~~~~~~~~~~~ | |
85 | ||
86 | The Kernel Digital TV Demux kABI defines a driver-internal interface for | |
87 | registering low-level, hardware specific driver to a hardware independent | |
88 | demux layer. It is only of interest for Digital TV device driver writers. | |
89 | The header file for this kABI is named demux.h and located in | |
90 | drivers/media/dvb-core. | |
91 | ||
92 | The demux kABI should be implemented for each demux in the system. It is | |
93 | used to select the TS source of a demux and to manage the demux resources. | |
94 | When the demux client allocates a resource via the demux kABI, it receives | |
95 | a pointer to the kABI of that resource. | |
96 | ||
97 | Each demux receives its TS input from a DVB front-end or from memory, as | |
98 | set via this demux kABI. In a system with more than one front-end, the kABI | |
99 | can be used to select one of the DVB front-ends as a TS source for a demux, | |
100 | unless this is fixed in the HW platform. | |
101 | ||
102 | The demux kABI only controls front-ends regarding to their connections with | |
103 | demuxes; the kABI used to set the other front-end parameters, such as | |
104 | tuning, are devined via the Digital TV Frontend kABI. | |
105 | ||
106 | The functions that implement the abstract interface demux should be defined | |
107 | static or module private and registered to the Demux core for external | |
108 | access. It is not necessary to implement every function in the struct | |
109 | &dmx_demux. For example, a demux interface might support Section filtering, | |
110 | but not PES filtering. The kABI client is expected to check the value of any | |
d2f01985 | 111 | function pointer before calling the function: the value of ``NULL`` means |
684ffa2d MCC |
112 | that the function is not available. |
113 | ||
114 | Whenever the functions of the demux API modify shared data, the | |
115 | possibilities of lost update and race condition problems should be | |
116 | addressed, e.g. by protecting parts of code with mutexes. | |
117 | ||
118 | Note that functions called from a bottom half context must not sleep. | |
d2f01985 | 119 | Even a simple memory allocation without using ``GFP_ATOMIC`` can result in a |
684ffa2d MCC |
120 | kernel thread being put to sleep if swapping is needed. For example, the |
121 | Linux Kernel calls the functions of a network device interface from a | |
122 | bottom half context. Thus, if a demux kABI function is called from network | |
123 | device code, the function must not sleep. | |
124 | ||
125 | ||
126 | ||
127 | Demux Callback API | |
128 | ------------------ | |
129 | ||
130 | Demux Callback | |
131 | ~~~~~~~~~~~~~~ | |
132 | ||
133 | This kernel-space API comprises the callback functions that deliver filtered | |
134 | data to the demux client. Unlike the other DVB kABIs, these functions are | |
135 | provided by the client and called from the demux code. | |
136 | ||
137 | The function pointers of this abstract interface are not packed into a | |
138 | structure as in the other demux APIs, because the callback functions are | |
139 | registered and used independent of each other. As an example, it is possible | |
140 | for the API client to provide several callback functions for receiving TS | |
141 | packets and no callbacks for PES packets or sections. | |
142 | ||
143 | The functions that implement the callback API need not be re-entrant: when | |
144 | a demux driver calls one of these functions, the driver is not allowed to | |
145 | call the function again before the original call returns. If a callback is | |
146 | triggered by a hardware interrupt, it is recommended to use the Linux | |
147 | bottom half mechanism or start a tasklet instead of making the callback | |
148 | function call directly from a hardware interrupt. | |
149 | ||
1b81f010 | 150 | This mechanism is implemented by :c:func:`dmx_ts_cb()` and :c:func:`dmx_section_cb()` |
684ffa2d MCC |
151 | callbacks. |
152 | ||
684ffa2d MCC |
153 | .. kernel-doc:: drivers/media/dvb-core/demux.h |
154 | ||
684ffa2d MCC |
155 | Digital TV Conditional Access kABI |
156 | ---------------------------------- | |
157 | ||
158 | .. kernel-doc:: drivers/media/dvb-core/dvb_ca_en50221.h |