Lines Matching refs:the
4 This document describes the Linux kernel media framework, its data structures,
13 on the kernel-side implementation of the media framework.
20 of the goals of the media framework. To achieve this, hardware devices are
32 flows from the entity's output to one or more entity inputs. Pads should
36 on the same entity or on different entities. Data flows from a source
44 include/media/media-device.h. Allocation of the structure is handled by the
45 media device driver, usually by embedding the media_device instance in a
52 The caller is responsible for initializing the media_device structure before
55 - dev must point to the parent device (usually a pci_dev, usb_interface or
58 - model must be filled with the device model name as a NUL-terminated UTF-8
64 The field is big enough to store a GUID in text form. If the hardware
67 - bus_info represents the location of the device in the system as a
69 "PCI:" (or "PCIe:") followed by the value of pci_name(). For USB devices,
70 the usb_make_path() function must be used. This field is used by
74 - hw_revision is the hardware device revision in a driver-specific format.
75 When possible the revision should be formatted with the KERNEL_VERSION
78 - driver_version is formatted with the KERNEL_VERSION macro. The version
79 minor must be incremented when new features are added to the userspace API
111 higher-level standard structures can have some of those fields set by the
114 As the number of pads is known in advance, the pads array is not allocated
115 dynamically but is managed by the entity driver. Most drivers will embed the
118 Drivers must set the direction of every pad in the pads array before calling
119 media_entity_init. The function will initialize the other pads fields.
121 Unlike the number of pads, the total number of links isn't always known in
122 advance by the entity driver. As an initial estimate, media_entity_init
123 pre-allocates a number of links equal to the number of pads plus an optional
125 the initial estimate.
133 ID by filling the media_entity id field prior to registration, or request the
136 contiguous even when they are all assigned automatically by the framework.
142 Unregistering an entity will not change the IDs of the other entities, and the
152 This function must be called during the cleanup phase after unregistering the
153 entity. Note that the media_entity instance itself must be freed explicitly by
154 the driver if required.
156 Entities have flags that describe the entity capabilities and state.
158 MEDIA_ENT_FL_DEFAULT indicates the default entity for a given type.
159 This can be used to report the default audio and video devices or the
162 Logical entity groups can be defined by setting the group ID of all member
163 entities to the same non-zero value. An entity group serves no purpose in the
165 field belongs to the media device driver and must not by touched by entity
171 - ALSA, VBI and video nodes that carry the same media stream
178 managed by the entity driver. Drivers usually embed the array in a
181 Pads are identified by their entity and their 0-based index in the pads array.
182 Both information are stored in the media_pad structure, making the media_pad
183 pointer the canonical way to store and pass link references.
185 Pads have flags that describe the pad capabilities and state.
187 MEDIA_PAD_FL_SINK indicates that the pad supports sinking data.
188 MEDIA_PAD_FL_SOURCE indicates that the pad supports sourcing data.
198 twice, once in the source entity and once in the target entity. The array is
207 An entry in the link array of each entity is allocated and stores pointers
210 Links have flags that describe the link capabilities and state.
212 MEDIA_LNK_FL_ENABLED indicates that the link is enabled and can be used
215 MEDIA_LNK_FL_IMMUTABLE indicates that the link enabled state can't be
226 To iterate over all entities belonging to a media device, drivers can use the
241 supported by the graph traversal API. To prevent infinite loops, the graph
242 traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH,
250 The graph structure, provided by the caller, is initialized to start graph
251 traversal at the given entity.
253 Drivers can then retrieve the next entity by calling
257 When the graph traversal is complete the function will return NULL.
260 required and the graph structure can be freed normally.
270 Refer to the kerneldoc documentation for more information.
276 Due to the wide differences between drivers regarding power management needs,
277 the media controller does not implement power management. However, the
279 track the number of users of every entity for power management needs.
282 drivers. Access to the field must be protected by the media device graph_mutex
293 The flags argument contains the requested new link flags.
295 The only configurable property is the ENABLED link flag to enable/disable a
296 link. Links marked with the IMMUTABLE link flag can not be enabled or disabled.
298 When a link is enabled or disabled, the media framework calls the
299 link_setup operation for the two entities at the source and sink of the link,
300 in that order. If the second link_setup call fails, another link_setup call is
301 made on the first entity to restore the original link flags.
303 Media device drivers can be notified of link setup operations by setting the
304 media_device::link_notify pointer to a callback function. If provided, the
308 Entity drivers must implement the link_setup operation if any of their links
309 is non-immutable. The operation must either configure the hardware or store
310 the configuration information to be applied later.
313 link at a sink pad prevents another link at the same pad from being enabled,
314 the link_setup operation must return -EBUSY and can't implicitly disable the
321 When starting streaming, drivers must notify all entities in the pipeline to
327 The function will mark all entities connected to the given entity through
330 The media_pipeline instance pointed to by the pipe argument will be stored in
331 every entity in the pipeline. Drivers should embed the media_pipeline structure
332 in higher-level pipeline structures and can then access the pipeline through
333 the media_entity pipe field.
336 be identical for all nested calls to the function.
339 clean up any of the changes it did by itself.
341 When stopping the stream, drivers must notify the entities with
345 If multiple calls to media_entity_pipeline_start() have been made the same
347 media_entity pipe field is reset to NULL on the last nested stop call.
349 Link configuration will fail with -EBUSY by default if either end of the link is
351 with the MEDIA_LNK_FL_DYNAMIC flag.
354 changing entities configuration parameters) drivers can explicitly check the
356 operation must be done with the media_device graph_mutex held.
363 entity which has sink pads in the pipeline. The
365 link_validate() callback, entity driver should check that the properties of
366 the source pad of the connected entity and its own sink pad match. It is up
367 to the type of the entity (and in the end, the properties of the hardware)
372 in the end provide a way to use driver-specific callbacks.