/* * Media device * * Copyright (C) 2010 Nokia Corporation * * Contacts: Laurent Pinchart * Sakari Ailus * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License version 2 as * published by the Free Software Foundation. * * This program is distributed in the hope that it will be useful, * but WITHOUT ANY WARRANTY; without even the implied warranty of * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the * GNU General Public License for more details. * * You should have received a copy of the GNU General Public License * along with this program; if not, write to the Free Software * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ #ifndef _MEDIA_DEVICE_H #define _MEDIA_DEVICE_H #include #include #include #include #include /** * DOC: Media Controller * * Linux kernel media framework * ============================ * * This document describes the Linux kernel media framework, its data structures, * functions and their usage. * * * Introduction * ------------ * * The media controller API is documented in DocBook format in * Documentation/DocBook/media/v4l/media-controller.xml. This document will focus * on the kernel-side implementation of the media framework. * * * Abstract media device model * --------------------------- * * Discovering a device internal topology, and configuring it at runtime, is one * of the goals of the media framework. To achieve this, hardware devices are * modelled as an oriented graph of building blocks called entities connected * through pads. * * An entity is a basic media hardware building block. It can correspond to * a large variety of logical blocks such as physical hardware devices * (CMOS sensor for instance), logical hardware devices (a building block * in a System-on-Chip image processing pipeline), DMA channels or physical * connectors. * * A pad is a connection endpoint through which an entity can interact with * other entities. Data (not restricted to video) produced by an entity * flows from the entity's output to one or more entity inputs. Pads should * not be confused with physical pins at chip boundaries. * * A link is a point-to-point oriented connection between two pads, either * on the same entity or on different entities. Data flows from a source * pad to a sink pad. * * * Media device * ------------ * * A media device is represented by a struct media_device instance, defined in * include/media/media-device.h. Allocation of the structure is handled by the * media device driver, usually by embedding the media_device instance in a * larger driver-specific structure. * * Drivers register media device instances by calling * * media_device_register(struct media_device *mdev); * * The caller is responsible for initializing the media_device structure before * registration. The following fields must be set: * * - dev must point to the parent device (usually a pci_dev, usb_interface or * platform_device instance). * * - model must be filled with the device model name as a NUL-terminated UTF-8 * string. The device/model revision must not be stored in this field. * * The following fields are optional: * * - serial is a unique serial number stored as a NUL-terminated ASCII string. * The field is big enough to store a GUID in text form. If the hardware * doesn't provide a unique serial number this field must be left empty. * * - bus_info represents the location of the device in the system as a * NUL-terminated ASCII string. For PCI/PCIe devices bus_info must be set to * "PCI:" (or "PCIe:") followed by the value of pci_name(). For USB devices, * the usb_make_path() function must be used. This field is used by * applications to distinguish between otherwise identical devices that don't * provide a serial number. * * - hw_revision is the hardware device revision in a driver-specific format. * When possible the revision should be formatted with the KERNEL_VERSION * macro. * * - driver_version is formatted with the KERNEL_VERSION macro. The version * minor must be incremented when new features are added to the userspace API * without breaking binary compatibility. The version major must be * incremented when binary compatibility is broken. * * Upon successful registration a character device named media[0-9]+ is created. * The device major and minor numbers are dynamic. The model name is exported as * a sysfs attribute. * * Drivers unregister media device instances by calling * * media_device_unregister(struct media_device *mdev); * * Unregistering a media device that hasn't been registered is *NOT* safe. * * * Entities, pads and links * ------------------------ * * - Entities * * Entities are represented by a struct media_entity instance, defined in * include/media/media-entity.h. The structure is usually embedded into a * higher-level structure, such as a v4l2_subdev or video_device instance, * although drivers can allocate entities directly. * * Drivers initialize entity pads by calling * * media_entity_pads_init(struct media_entity *entity, u16 num_pads, * struct media_pad *pads); * * If no pads are needed, drivers could directly fill entity->num_pads * with 0 and entity->pads with NULL or to call the above function that * will do the same. * * The media_entity name, type and flags fields should be initialized before * calling media_device_register_entity(). Entities embedded in higher-level * standard structures can have some of those fields set by the higher-level * framework. * * As the number of pads is known in advance, the pads array is not allocated * dynamically but is managed by the entity driver. Most drivers will embed the * pads array in a driver-specific structure, avoiding dynamic allocation. * * Drivers must set the direction of every pad in the pads array before calling * media_entity_pads_init. The function will initialize the other pads fields. * * Unlike the number of pads, the total number of links isn't always known in * advance by the entity driver. As an initial estimate, media_entity_pads_init * pre-allocates a number of links equal to the number of pads. The links array * will be reallocated if it grows beyond the initial estimate. * * Drivers register entities with a media device by calling * * media_device_register_entity(struct media_device *mdev, * struct media_entity *entity); * * Entities are identified by a unique positive integer ID. Drivers can provide an * ID by filling the media_entity id field prior to registration, or request the * media controller framework to assign an ID automatically. Drivers that provide * IDs manually must ensure that all IDs are unique. IDs are not guaranteed to be * contiguous even when they are all assigned automatically by the framework. * * Drivers unregister entities by calling * * media_device_unregister_entity(struct media_entity *entity); * * Unregistering an entity will not change the IDs of the other entities, and the * ID will never be reused for a newly registered entity. * * When a media device is unregistered, all its entities are unregistered * automatically. No manual entities unregistration is then required. * * Drivers free resources associated with an entity by calling * * media_entity_cleanup(struct media_entity *entity); * * This function must be called during the cleanup phase after unregistering the * entity. Note that the media_entity instance itself must be freed explicitly by * the driver if required. * * Entities have flags that describe the entity capabilities and state. * * MEDIA_ENT_FL_DEFAULT indicates the default entity for a given type. * This can be used to report the default audio and video devices or the * default camera sensor. * * Logical entity groups can be defined by setting the group ID of all member * entities to the same non-zero value. An entity group serves no purpose in the * kernel, but is reported to userspace during entities enumeration. * * Media device drivers should define groups if several entities are logically * bound together. Example usages include reporting * * - ALSA, VBI and video nodes that carry the same media stream * - lens and flash controllers associated with a sensor * * - Pads * * Pads are represented by a struct media_pad instance, defined in * include/media/media-entity.h. Each entity stores its pads in a pads array * managed by the entity driver. Drivers usually embed the array in a * driver-specific structure. * * Pads are identified by their entity and their 0-based index in the pads array. * Both information are stored in the media_pad structure, making the media_pad * pointer the canonical way to store and pass link references. * * Pads have flags that describe the pad capabilities and state. * * MEDIA_PAD_FL_SINK indicates that the pad supports sinking data. * MEDIA_PAD_FL_SOURCE indicates that the pad supports sourcing data. * * One and only one of MEDIA_PAD_FL_SINK and MEDIA_PAD_FL_SOURCE must be set for * each pad. * * - Links * * Links are represented by a struct media_link instance, defined in * include/media/media-entity.h. Each entity stores all links originating at or * targeting any of its pads in a links array. A given link is thus stored * twice, once in the source entity and once in the target entity. The array is * pre-allocated and grows dynamically as needed. * * Drivers create links by calling * * media_create_pad_link(struct media_entity *source, u16 source_pad, * struct media_entity *sink, u16 sink_pad, * u32 flags); * * An entry in the link array of each entity is allocated and stores pointers * to source and sink pads. * * Links have flags that describe the link capabilities and state. * * MEDIA_LNK_FL_ENABLED indicates that the link is enabled and can be used * to transfer media data. When two or more links target a sink pad, only * one of them can be enabled at a time. * MEDIA_LNK_FL_IMMUTABLE indicates that the link enabled state can't be * modified at runtime. If MEDIA_LNK_FL_IMMUTABLE is set, then * MEDIA_LNK_FL_ENABLED must also be set since an immutable link is always * enabled. * * * Graph traversal * --------------- * * The media framework provides APIs to iterate over entities in a graph. * * To iterate over all entities belonging to a media device, drivers can use the * media_device_for_each_entity macro, defined in include/media/media-device.h. * * struct media_entity *entity; * * media_device_for_each_entity(entity, mdev) { * // entity will point to each entity in turn * ... * } * * Drivers might also need to iterate over all entities in a graph that can be * reached only through enabled links starting at a given entity. The media * framework provides a depth-first graph traversal API for that purpose. * * Note that graphs with cycles (whether directed or undirected) are *NOT* * supported by the graph traversal API. To prevent infinite loops, the graph * traversal code limits the maximum depth to MEDIA_ENTITY_ENUM_MAX_DEPTH, * currently defined as 16. * * Drivers initiate a graph traversal by calling * * media_entity_graph_walk_start(struct media_entity_graph *graph, * struct media_entity *entity); * * The graph structure, provided by the caller, is initialized to start graph * traversal at the given entity. * * Drivers can then retrieve the next entity by calling * * media_entity_graph_walk_next(struct media_entity_graph *graph); * * When the graph traversal is complete the function will return NULL. * * Graph traversal can be interrupted at any moment. No cleanup function call is * required and the graph structure can be freed normally. * * Helper functions can be used to find a link between two given pads, or a pad * connected to another pad through an enabled link * * media_entity_find_link(struct media_pad *source, * struct media_pad *sink); * * media_entity_remote_pad(struct media_pad *pad); * * Refer to the kerneldoc documentation for more information. * * * Use count and power handling * ---------------------------- * * Due to the wide differences between drivers regarding power management needs, * the media controller does not implement power management. However, the * media_entity structure includes a use_count field that media drivers can use to * track the number of users of every entity for power management needs. * * The use_count field is owned by media drivers and must not be touched by entity * drivers. Access to the field must be protected by the media device graph_mutex * lock. * * * Links setup * ----------- * * Link properties can be modified at runtime by calling * * media_entity_setup_link(struct media_link *link, u32 flags); * * The flags argument contains the requested new link flags. * * The only configurable property is the ENABLED link flag to enable/disable a * link. Links marked with the IMMUTABLE link flag can not be enabled or disabled. * * When a link is enabled or disabled, the media framework calls the * link_setup operation for the two entities at the source and sink of the link, * in that order. If the second link_setup call fails, another link_setup call is * made on the first entity to restore the original link flags. * * Media device drivers can be notified of link setup operations by setting the * media_device::link_notify pointer to a callback function. If provided, the * notification callback will be called before enabling and after disabling * links. * * Entity drivers must implement the link_setup operation if any of their links * is non-immutable. The operation must either configure the hardware or store * the configuration information to be applied later. * * Link configuration must not have any side effect on other links. If an enabled * link at a sink pad prevents another link at the same pad from being enabled, * the link_setup operation must return -EBUSY and can't implicitly disable the * first enabled link. * * * Pipelines and media streams * --------------------------- * * When starting streaming, drivers must notify all entities in the pipeline to * prevent link states from being modified during streaming by calling * * media_entity_pipeline_start(struct media_entity *entity, * struct media_pipeline *pipe); * * The function will mark all entities connected to the given entity through * enabled links, either directly or indirectly, as streaming. * * The media_pipeline instance pointed to by the pipe argument will be stored in * every entity in the pipeline. Drivers should embed the media_pipeline structure * in higher-level pipeline structures and can then access the pipeline through * the media_entity pipe field. * * Calls to media_entity_pipeline_start() can be nested. The pipeline pointer must * be identical for all nested calls to the function. * * media_entity_pipeline_start() may return an error. In that case, it will * clean up any of the changes it did by itself. * * When stopping the stream, drivers must notify the entities with * * media_entity_pipeline_stop(struct media_entity *entity); * * If multiple calls to media_entity_pipeline_start() have been made the same * number of media_entity_pipeline_stop() calls are required to stop streaming. The * media_entity pipe field is reset to NULL on the last nested stop call. * * Link configuration will fail with -EBUSY by default if either end of the link is * a streaming entity. Links that can be modified while streaming must be marked * with the MEDIA_LNK_FL_DYNAMIC flag. * * If other operations need to be disallowed on streaming entities (such as * changing entities configuration parameters) drivers can explicitly check the * media_entity stream_count field to find out if an entity is streaming. This * operation must be done with the media_device graph_mutex held. * * * Link validation * --------------- * * Link validation is performed by media_entity_pipeline_start() for any * entity which has sink pads in the pipeline. The * media_entity::link_validate() callback is used for that purpose. In * link_validate() callback, entity driver should check that the properties of * the source pad of the connected entity and its own sink pad match. It is up * to the type of the entity (and in the end, the properties of the hardware) * what matching actually means. * * Subsystems should facilitate link validation by providing subsystem specific * helper functions to provide easy access for commonly needed information, and * in the end provide a way to use driver-specific callbacks. */ struct device; /** * struct media_device - Media device * @dev: Parent device * @devnode: Media device node * @model: Device model name * @serial: Device serial number (optional) * @bus_info: Unique and stable device location identifier * @hw_revision: Hardware device revision * @driver_version: Device driver version * @topology_version: Monotonic counter for storing the version of the graph * topology. Should be incremented each time the topology changes. * @entity_id: Unique ID used on the last entity registered * @pad_id: Unique ID used on the last pad registered * @link_id: Unique ID used on the last link registered * @intf_devnode_id: Unique ID used on the last interface devnode registered * @entities: List of registered entities * @interfaces: List of registered interfaces * @pads: List of registered pads * @links: List of registered links * @lock: Entities list lock * @graph_mutex: Entities graph operation lock * @link_notify: Link state change notification callback * * This structure represents an abstract high-level media device. It allows easy * access to entities and provides basic media device-level support. The * structure can be allocated directly or embedded in a larger structure. * * The parent @dev is a physical device. It must be set before registering the * media device. * * @model is a descriptive model name exported through sysfs. It doesn't have to * be unique. */ struct media_device { /* dev->driver_data points to this struct. */ struct device *dev; struct media_devnode devnode; char model[32]; char serial[40]; char bus_info[32]; u32 hw_revision; u32 driver_version; u32 topology_version; u32 entity_id; u32 pad_id; u32 link_id; u32 intf_devnode_id; struct list_head entities; struct list_head interfaces; struct list_head pads; struct list_head links; /* Protects the graph objects creation/removal */ spinlock_t lock; /* Serializes graph operations. */ struct mutex graph_mutex; int (*link_notify)(struct media_link *link, u32 flags, unsigned int notification); }; #ifdef CONFIG_MEDIA_CONTROLLER /* Supported link_notify @notification values. */ #define MEDIA_DEV_NOTIFY_PRE_LINK_CH 0 #define MEDIA_DEV_NOTIFY_POST_LINK_CH 1 /* media_devnode to media_device */ #define to_media_device(node) container_of(node, struct media_device, devnode) int __must_check __media_device_register(struct media_device *mdev, struct module *owner); #define media_device_register(mdev) __media_device_register(mdev, THIS_MODULE) void media_device_unregister(struct media_device *mdev); int __must_check media_device_register_entity(struct media_device *mdev, struct media_entity *entity); void media_device_unregister_entity(struct media_entity *entity); struct media_device *media_device_get_devres(struct device *dev); struct media_device *media_device_find_devres(struct device *dev); /* Iterate over all entities. */ #define media_device_for_each_entity(entity, mdev) \ list_for_each_entry(entity, &(mdev)->entities, graph_obj.list) /* Iterate over all interfaces. */ #define media_device_for_each_intf(intf, mdev) \ list_for_each_entry(intf, &(mdev)->interfaces, graph_obj.list) /* Iterate over all pads. */ #define media_device_for_each_pad(pad, mdev) \ list_for_each_entry(pad, &(mdev)->pads, graph_obj.list) /* Iterate over all links. */ #define media_device_for_each_link(link, mdev) \ list_for_each_entry(link, &(mdev)->links, graph_obj.list) #else static inline int media_device_register(struct media_device *mdev) { return 0; } static inline void media_device_unregister(struct media_device *mdev) { } static inline int media_device_register_entity(struct media_device *mdev, struct media_entity *entity) { return 0; } static inline void media_device_unregister_entity(struct media_entity *entity) { } static inline struct media_device *media_device_get_devres(struct device *dev) { return NULL; } static inline struct media_device *media_device_find_devres(struct device *dev) { return NULL; } #endif /* CONFIG_MEDIA_CONTROLLER */ #endif