Linux kernel mirror (for testing) git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
kernel os linux

[media] DocBook: Add documentation about the demux API

There are several stuff at media's kdapi.xml that don't
belong there, as it documents the Kernel internal ABI, and
not the userspace API.

Add the documentation here. The hole kdapi.xml will be
removed on a latter patch, after we finish documenting
what's there at the proper places.

Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>

+71 -6
+71 -6
Documentation/DocBook/device-drivers.tmpl
··· 239 239 </sect1> 240 240 <sect1><title>Digital TV (DVB) devices</title> 241 241 !Idrivers/media/dvb-core/dvb_ca_en50221.h 242 - !Idrivers/media/dvb-core/demux.h 243 242 !Idrivers/media/dvb-core/dvb_frontend.h 244 243 !Idrivers/media/dvb-core/dvb_math.h 245 244 !Idrivers/media/dvb-core/dvb_ringbuffer.h 246 245 !Idrivers/media/dvb-core/dvbdev.h 247 - </sect1> 248 - <sect1><title>Remote Controller devices</title> 246 + <sect1><title>Digital TV Demux API</title> 247 + <para>The kernel demux API defines a driver-internal interface for 248 + registering low-level, hardware specific driver to a hardware 249 + independent demux layer. It is only of interest for Digital TV 250 + device driver writers. The header file for this API is named 251 + <constant>demux.h</constant> and located in 252 + <constant>drivers/media/dvb-core</constant>.</para> 253 + 254 + <para>The demux API should be implemented for each demux in the 255 + system. It is used to select the TS source of a demux and to manage 256 + the demux resources. When the demux client allocates a resource via 257 + the demux API, it receives a pointer to the API of that 258 + resource.</para> 259 + <para>Each demux receives its TS input from a DVB front-end or from 260 + memory, as set via this demux API. In a system with more than one 261 + front-end, the API can be used to select one of the DVB front-ends 262 + as a TS source for a demux, unless this is fixed in the HW platform. 263 + The demux API only controls front-ends regarding to their connections 264 + with demuxes; the APIs used to set the other front-end parameters, 265 + such as tuning, are not defined in this document.</para> 266 + <para>The functions that implement the abstract interface demux should 267 + be defined static or module private and registered to the Demux 268 + core for external access. It is not necessary to implement every 269 + function in the struct <constant>dmx_demux</constant>. For example, 270 + a demux interface might support Section filtering, but not PES 271 + filtering. The API client is expected to check the value of any 272 + function pointer before calling the function: the value of NULL means 273 + that the &#8220;function is not available&#8221;.</para> 274 + <para>Whenever the functions of the demux API modify shared data, 275 + the possibilities of lost update and race condition problems should 276 + be addressed, e.g. by protecting parts of code with mutexes.</para> 277 + <para>Note that functions called from a bottom half context must not 278 + sleep. Even a simple memory allocation without using GFP_ATOMIC can 279 + result in a kernel thread being put to sleep if swapping is needed. 280 + For example, the Linux kernel calls the functions of a network device 281 + interface from a bottom half context. Thus, if a demux API function 282 + is called from network device code, the function must not sleep. 283 + </para> 284 + </sect1> 285 + 286 + <section id="demux_callback_api"> 287 + <title>Demux Callback API</title> 288 + <para>This kernel-space API comprises the callback functions that 289 + deliver filtered data to the demux client. Unlike the other DVB 290 + kABIs, these functions are provided by the client and called from 291 + the demux code.</para> 292 + <para>The function pointers of this abstract interface are not 293 + packed into a structure as in the other demux APIs, because the 294 + callback functions are registered and used independent of each 295 + other. As an example, it is possible for the API client to provide 296 + several callback functions for receiving TS packets and no 297 + callbacks for PES packets or sections.</para> 298 + <para>The functions that implement the callback API need not be 299 + re-entrant: when a demux driver calls one of these functions, 300 + the driver is not allowed to call the function again before 301 + the original call returns. If a callback is triggered by a 302 + hardware interrupt, it is recommended to use the Linux 303 + &#8220;bottom half&#8221; mechanism or start a tasklet instead of 304 + making the callback function call directly from a hardware 305 + interrupt.</para> 306 + <para>This mechanism is implemented by 307 + <link linkend='API-dmx-ts-cb'>dmx_ts_cb()</link> and 308 + <link linkend='API-dmx-section-cb'>dmx_section_cb()</link>.</para> 309 + </section> 310 + 311 + !Idrivers/media/dvb-core/demux.h 312 + </sect1> 313 + <sect1><title>Remote Controller devices</title> 249 314 !Iinclude/media/rc-core.h 250 315 !Iinclude/media/lirc_dev.h 251 - </sect1> 252 - <sect1><title>Media Controller devices</title> 316 + </sect1> 317 + <sect1><title>Media Controller devices</title> 253 318 !Iinclude/media/media-device.h 254 319 !Iinclude/media/media-devnode.h 255 320 !Iinclude/media/media-entity.h 256 - </sect1> 321 + </sect1> 257 322 258 323 </chapter> 259 324