aboutsummaryrefslogtreecommitdiffstats
path: root/Documentation/media-framework.txt
diff options
context:
space:
mode:
Diffstat (limited to 'Documentation/media-framework.txt')
-rw-r--r--Documentation/media-framework.txt151
1 files changed, 151 insertions, 0 deletions
diff --git a/Documentation/media-framework.txt b/Documentation/media-framework.txt
index 1844c3f10728..0257bad2a104 100644
--- a/Documentation/media-framework.txt
+++ b/Documentation/media-framework.txt
@@ -13,6 +13,30 @@ Documentation/DocBook/v4l/media-controller.xml. This document will focus on
13the kernel-side implementation of the media framework. 13the kernel-side implementation of the media framework.
14 14
15 15
16Abstract media device model
17---------------------------
18
19Discovering a device internal topology, and configuring it at runtime, is one
20of the goals of the media framework. To achieve this, hardware devices are
21modeled as an oriented graph of building blocks called entities connected
22through pads.
23
24An entity is a basic media hardware building block. It can correspond to
25a large variety of logical blocks such as physical hardware devices
26(CMOS sensor for instance), logical hardware devices (a building block
27in a System-on-Chip image processing pipeline), DMA channels or physical
28connectors.
29
30A pad is a connection endpoint through which an entity can interact with
31other entities. Data (not restricted to video) produced by an entity
32flows from the entity's output to one or more entity inputs. Pads should
33not be confused with physical pins at chip boundaries.
34
35A link is a point-to-point oriented connection between two pads, either
36on the same entity or on different entities. Data flows from a source
37pad to a sink pad.
38
39
16Media device 40Media device
17------------ 41------------
18 42
@@ -65,3 +89,130 @@ Drivers unregister media device instances by calling
65 media_device_unregister(struct media_device *mdev); 89 media_device_unregister(struct media_device *mdev);
66 90
67Unregistering a media device that hasn't been registered is *NOT* safe. 91Unregistering a media device that hasn't been registered is *NOT* safe.
92
93
94Entities, pads and links
95------------------------
96
97- Entities
98
99Entities are represented by a struct media_entity instance, defined in
100include/media/media-entity.h. The structure is usually embedded into a
101higher-level structure, such as a v4l2_subdev or video_device instance,
102although drivers can allocate entities directly.
103
104Drivers initialize entities by calling
105
106 media_entity_init(struct media_entity *entity, u16 num_pads,
107 struct media_pad *pads, u16 extra_links);
108
109The media_entity name, type, flags, revision and group_id fields can be
110initialized before or after calling media_entity_init. Entities embedded in
111higher-level standard structures can have some of those fields set by the
112higher-level framework.
113
114As the number of pads is known in advance, the pads array is not allocated
115dynamically but is managed by the entity driver. Most drivers will embed the
116pads array in a driver-specific structure, avoiding dynamic allocation.
117
118Drivers must set the direction of every pad in the pads array before calling
119media_entity_init. The function will initialize the other pads fields.
120
121Unlike the number of pads, the total number of links isn't always known in
122advance by the entity driver. As an initial estimate, media_entity_init
123pre-allocates a number of links equal to the number of pads plus an optional
124number of extra links. The links array will be reallocated if it grows beyond
125the initial estimate.
126
127Drivers register entities with a media device by calling
128
129 media_device_register_entity(struct media_device *mdev,
130 struct media_entity *entity);
131
132Entities are identified by a unique positive integer ID. Drivers can provide an
133ID by filling the media_entity id field prior to registration, or request the
134media controller framework to assign an ID automatically. Drivers that provide
135IDs manually must ensure that all IDs are unique. IDs are not guaranteed to be
136contiguous even when they are all assigned automatically by the framework.
137
138Drivers unregister entities by calling
139
140 media_device_unregister_entity(struct media_entity *entity);
141
142Unregistering an entity will not change the IDs of the other entities, and the
143ID will never be reused for a newly registered entity.
144
145When a media device is unregistered, all its entities are unregistered
146automatically. No manual entities unregistration is then required.
147
148Drivers free resources associated with an entity by calling
149
150 media_entity_cleanup(struct media_entity *entity);
151
152This function must be called during the cleanup phase after unregistering the
153entity. Note that the media_entity instance itself must be freed explicitly by
154the driver if required.
155
156Entities have flags that describe the entity capabilities and state.
157
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
160 default camera sensor.
161
162Logical entity groups can be defined by setting the group ID of all member
163entities to the same non-zero value. An entity group serves no purpose in the
164kernel, but is reported to userspace during entities enumeration. The group_id
165field belongs to the media device driver and must not by touched by entity
166drivers.
167
168Media device drivers should define groups if several entities are logically
169bound together. Example usages include reporting
170
171 - ALSA, VBI and video nodes that carry the same media stream
172 - lens and flash controllers associated with a sensor
173
174- Pads
175
176Pads are represented by a struct media_pad instance, defined in
177include/media/media-entity.h. Each entity stores its pads in a pads array
178managed by the entity driver. Drivers usually embed the array in a
179driver-specific structure.
180
181Pads are identified by their entity and their 0-based index in the pads array.
182Both information are stored in the media_pad structure, making the media_pad
183pointer the canonical way to store and pass link references.
184
185Pads have flags that describe the pad capabilities and state.
186
187 MEDIA_PAD_FL_SINK indicates that the pad supports sinking data.
188 MEDIA_PAD_FL_SOURCE indicates that the pad supports sourcing data.
189
190One and only one of MEDIA_PAD_FL_SINK and MEDIA_PAD_FL_SOURCE must be set for
191each pad.
192
193- Links
194
195Links are represented by a struct media_link instance, defined in
196include/media/media-entity.h. Each entity stores all links originating at or
197targetting any of its pads in a links array. A given link is thus stored
198twice, once in the source entity and once in the target entity. The array is
199pre-allocated and grows dynamically as needed.
200
201Drivers create links by calling
202
203 media_entity_create_link(struct media_entity *source, u16 source_pad,
204 struct media_entity *sink, u16 sink_pad,
205 u32 flags);
206
207An entry in the link array of each entity is allocated and stores pointers
208to source and sink pads.
209
210Links have flags that describe the link capabilities and state.
211
212 MEDIA_LNK_FL_ENABLED indicates that the link is enabled and can be used
213 to transfer media data. When two or more links target a sink pad, only
214 one of them can be enabled at a time.
215 MEDIA_LNK_FL_IMMUTABLE indicates that the link enabled state can't be
216 modified at runtime. If MEDIA_LNK_FL_IMMUTABLE is set, then
217 MEDIA_LNK_FL_ENABLED must also be set since an immutable link is always
218 enabled.