linux-stable/include/media/media-entity.h

1451 lines
47 KiB
C
Raw Normal View History

/* SPDX-License-Identifier: GPL-2.0-only */
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
/*
* Media entity
*
* Copyright (C) 2010 Nokia Corporation
*
* Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
* Sakari Ailus <sakari.ailus@iki.fi>
*/
#ifndef _MEDIA_ENTITY_H
#define _MEDIA_ENTITY_H
#include <linux/bitmap.h>
#include <linux/bug.h>
#include <linux/container_of.h>
#include <linux/fwnode.h>
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
#include <linux/list.h>
#include <linux/media.h>
#include <linux/minmax.h>
#include <linux/types.h>
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
/* Enums used internally at the media controller to represent graphs */
/**
* enum media_gobj_type - type of a graph object
*
* @MEDIA_GRAPH_ENTITY: Identify a media entity
* @MEDIA_GRAPH_PAD: Identify a media pad
* @MEDIA_GRAPH_LINK: Identify a media link
* @MEDIA_GRAPH_INTF_DEVNODE: Identify a media Kernel API interface via
* a device node
*/
enum media_gobj_type {
MEDIA_GRAPH_ENTITY,
MEDIA_GRAPH_PAD,
MEDIA_GRAPH_LINK,
MEDIA_GRAPH_INTF_DEVNODE,
};
#define MEDIA_BITS_PER_TYPE 8
#define MEDIA_BITS_PER_ID (32 - MEDIA_BITS_PER_TYPE)
#define MEDIA_ID_MASK GENMASK_ULL(MEDIA_BITS_PER_ID - 1, 0)
/* Structs to represent the objects that belong to a media graph */
/**
* struct media_gobj - Define a graph object.
*
* @mdev: Pointer to the struct &media_device that owns the object
* @id: Non-zero object ID identifier. The ID should be unique
* inside a media_device, as it is composed by
* %MEDIA_BITS_PER_TYPE to store the type plus
* %MEDIA_BITS_PER_ID to store the ID
* @list: List entry stored in one of the per-type mdev object lists
*
* All objects on the media graph should have this struct embedded
*/
struct media_gobj {
struct media_device *mdev;
u32 id;
struct list_head list;
};
#define MEDIA_ENTITY_ENUM_MAX_DEPTH 16
/**
* struct media_entity_enum - An enumeration of media entities.
*
* @bmap: Bit map in which each bit represents one entity at struct
* media_entity->internal_idx.
* @idx_max: Number of bits in bmap
*/
struct media_entity_enum {
unsigned long *bmap;
int idx_max;
};
/**
* struct media_graph - Media graph traversal state
*
* @stack: Graph traversal stack; the stack contains information
* on the path the media entities to be walked and the
* links through which they were reached.
* @stack.entity: pointer to &struct media_entity at the graph.
* @stack.link: pointer to &struct list_head.
* @ent_enum: Visited entities
* @top: The top of the stack
*/
struct media_graph {
struct {
struct media_entity *entity;
struct list_head *link;
} stack[MEDIA_ENTITY_ENUM_MAX_DEPTH];
struct media_entity_enum ent_enum;
int top;
};
/**
* struct media_pipeline - Media pipeline related information
*
* @allocated: Media pipeline allocated and freed by the framework
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
* @mdev: The media device the pipeline is part of
* @pads: List of media_pipeline_pad
* @start_count: Media pipeline start - stop count
*/
struct media_pipeline {
bool allocated;
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
struct media_device *mdev;
struct list_head pads;
int start_count;
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
};
/**
* struct media_pipeline_pad - A pad part of a media pipeline
*
* @list: Entry in the media_pad pads list
* @pipe: The media_pipeline that the pad is part of
* @pad: The media pad
*
* This structure associate a pad with a media pipeline. Instances of
* media_pipeline_pad are created by media_pipeline_start() when it builds the
* pipeline, and stored in the &media_pad.pads list. media_pipeline_stop()
* removes the entries from the list and deletes them.
*/
struct media_pipeline_pad {
struct list_head list;
struct media_pipeline *pipe;
struct media_pad *pad;
};
/**
* struct media_pipeline_pad_iter - Iterator for media_pipeline_for_each_pad
*
* @cursor: The current element
*/
struct media_pipeline_pad_iter {
struct list_head *cursor;
};
/**
* struct media_pipeline_entity_iter - Iterator for media_pipeline_for_each_entity
*
* @ent_enum: The entity enumeration tracker
* @cursor: The current element
*/
struct media_pipeline_entity_iter {
struct media_entity_enum ent_enum;
struct list_head *cursor;
};
/**
* struct media_link - A link object part of a media graph.
*
* @graph_obj: Embedded structure containing the media object common data
* @list: Linked list associated with an entity or an interface that
* owns the link.
* @gobj0: Part of a union. Used to get the pointer for the first
* graph_object of the link.
* @source: Part of a union. Used only if the first object (gobj0) is
* a pad. In that case, it represents the source pad.
* @intf: Part of a union. Used only if the first object (gobj0) is
* an interface.
* @gobj1: Part of a union. Used to get the pointer for the second
* graph_object of the link.
[media] get rid of a number of problems at the cross references As warned by linuxdoc[1] tool, using: $ for i in $(git grep kernel-doc Documentation/media/kapi/|cut -d: -f4); do kernel-lintdoc --sloppy $i; done include/media/v4l2-dev.h:118 :WARN: function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-mc.h:56 [kernel-doc WARN] : enum name from comment differs: if_vid_dec_index <--> if_vid_dec_pad_index include/media/v4l2-mc.h:71 [kernel-doc WARN] : enum name from comment differs: if_aud_dec_index <--> if_aud_dec_pad_index include/media/v4l2-mem2mem.h:396 [kernel-doc WARN] : function name from comment differs: v4l2_m2m_num_src_bufs_ready <--> v4l2_m2m_num_dst_bufs_ready drivers/media/dvb-core/dvb_math.h:28 [kernel-doc WARN] : function name from comment differs: cintlog2 <--> intlog2 include/media/v4l2-subdev.h:215 [kernel-doc WARN] : struct name from comment differs: s_radio <--> v4l2_subdev_tuner_ops include/media/v4l2-subdev.h:890 [kernel-doc WARN] : function name from comment differs: v4l2_set_subdevdata <--> v4l2_set_subdev_hostdata include/media/v4l2-subdev.h:901 [kernel-doc WARN] : function name from comment differs: v4l2_get_subdevdata <--> v4l2_get_subdev_hostdata drivers/media/dvb-core/dvb_ringbuffer.h:196 [kernel-doc WARN] : function name from comment differs: dvb_ringbuffer_writeuser <--> dvb_ringbuffer_write_user include/media/videobuf2-core.h:399 [kernel-doc WARN] : struct name from comment differs: vb2_ops <--> vb2_buf_ops include/media/media-entity.h:132 [kernel-doc ERROR] : duplicate parameter definition 'source' include/media/media-entity.h:477 [kernel-doc WARN] : function name from comment differs: media_entity_enum_test <--> media_entity_enum_test_and_set include/media/media-entity.h:535 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_pad include/media/media-entity.h:544 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_link include/media/media-entity.h:553 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_intf include/media/media-entity.h:562 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> intf_to_devnode include/media/rc-core.h:234 [kernel-doc WARN] : function name from comment differs: rc_open <--> rc_close include/media/v4l2-ctrls.h:397 [kernel-doc WARN] : missing initial short description of 'v4l2_ctrl_handler_init' include/media/v4l2-dev.h:118 [kernel-doc WARN] : function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-event.h:225 [kernel-doc WARN] : missing initial short description of 'v4l2_src_change_event_subscribe' [1] https://return42.github.io/linuxdoc/linux.html The above are real issues at the documentation. On several cases, caused by cut-and-paste. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22 10:59:03 +00:00
* @sink: Part of a union. Used only if the second object (gobj1) is
* a pad. In that case, it represents the sink pad.
* @entity: Part of a union. Used only if the second object (gobj1) is
* an entity.
* @reverse: Pointer to the link for the reverse direction of a pad to pad
* link.
* @flags: Link flags, as defined in uapi/media.h (MEDIA_LNK_FL_*)
* @is_backlink: Indicate if the link is a backlink.
*/
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
struct media_link {
struct media_gobj graph_obj;
[media] media: convert links from array to list The entire logic that represent graph links were developed on a time where there were no needs to dynamic remove links. So, although links are created/removed one by one via some functions, they're stored as an array inside the entity struct. As the array may grow, there's a logic inside the code that checks if the amount of space is not enough to store the needed links. If it isn't the core uses krealloc() to change the size of the link, with is bad, as it leaves the memory fragmented. So, convert links into a list. Also, currently, both source and sink entities need the link at the graph traversal logic inside media_entity. So there's a logic duplicating all links. That makes it to spend twice the memory needed. This is not a big deal for today's usage, where the number of links are not big. Yet, if during the MC workshop discussions, it was said that IIO graphs could have up to 4,000 entities. So, we may want to remove the duplication on some future. The problem is that it would require a separate linked list to store the backlinks inside the entity, or to use a more complex algorithm to do graph backlink traversal, with is something that the current graph traversal inside the core can't cope with. So, let's postpone a such change if/when it is actually needed. It should also be noticed that the media_link structure uses 44 bytes on 32-bit architectures and 84 bytes on 64-bit architecture. It will thus be allocated out of the 64-bytes and 96-bytes pools respectively. That's a 12.5% memory waste on 64-bit architectures and 31.25% on 32-bit architecture. A linked list is less efficient than an array in this case, but this could later be optimized if we can get rid of the reverse links (with would reduce memory allocation by 50%). Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-08-07 09:55:40 +00:00
struct list_head list;
union {
struct media_gobj *gobj0;
struct media_pad *source;
struct media_interface *intf;
};
union {
struct media_gobj *gobj1;
struct media_pad *sink;
struct media_entity *entity;
};
struct media_link *reverse;
unsigned long flags;
bool is_backlink;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
};
/**
* enum media_pad_signal_type - type of the signal inside a media pad
*
* @PAD_SIGNAL_DEFAULT:
* Default signal. Use this when all inputs or all outputs are
* uniquely identified by the pad number.
* @PAD_SIGNAL_ANALOG:
* The pad contains an analog signal. It can be Radio Frequency,
* Intermediate Frequency, a baseband signal or sub-carriers.
* Tuner inputs, IF-PLL demodulators, composite and s-video signals
* should use it.
* @PAD_SIGNAL_DV:
* Contains a digital video signal, with can be a bitstream of samples
* taken from an analog TV video source. On such case, it usually
* contains the VBI data on it.
* @PAD_SIGNAL_AUDIO:
* Contains an Intermediate Frequency analog signal from an audio
* sub-carrier or an audio bitstream. IF signals are provided by tuners
* and consumed by audio AM/FM decoders. Bitstream audio is provided by
* an audio decoder.
*/
enum media_pad_signal_type {
PAD_SIGNAL_DEFAULT = 0,
PAD_SIGNAL_ANALOG,
PAD_SIGNAL_DV,
PAD_SIGNAL_AUDIO,
};
/**
* struct media_pad - A media pad graph object.
*
* @graph_obj: Embedded structure containing the media object common data
* @entity: Entity this pad belongs to
* @index: Pad index in the entity pads array, numbered from 0 to n
* @num_links: Number of links connected to this pad
* @sig_type: Type of the signal inside a media pad
* @flags: Pad flags, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* (seek for ``MEDIA_PAD_FL_*``)
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
* @pipe: Pipeline this pad belongs to. Use media_entity_pipeline() to
* access this field.
*/
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
struct media_pad {
struct media_gobj graph_obj; /* must be first field in struct */
struct media_entity *entity;
u16 index;
u16 num_links;
enum media_pad_signal_type sig_type;
unsigned long flags;
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
/*
* The fields below are private, and should only be accessed via
* appropriate functions.
*/
struct media_pipeline *pipe;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
};
/**
* struct media_entity_operations - Media entity operations
* @get_fwnode_pad: Return the pad number based on a fwnode endpoint or
* a negative value on error. This operation can be used
* to map a fwnode to a media pad number. Optional.
* @link_setup: Notify the entity of link changes. The operation can
* return an error, in which case link setup will be
* cancelled. Optional.
* @link_validate: Return whether a link is valid from the entity point of
* view. The media_pipeline_start() function
* validates all links by calling this operation. Optional.
* @has_pad_interdep: Return whether two pads of the entity are
* interdependent. If two pads are interdependent they are
* part of the same pipeline and enabling one of the pads
* means that the other pad will become "locked" and
* doesn't allow configuration changes. pad0 and pad1 are
* guaranteed to not both be sinks or sources. Never call
* the .has_pad_interdep() operation directly, always use
* media_entity_has_pad_interdep().
* Optional: If the operation isn't implemented all pads
* will be considered as interdependent.
*
* .. note::
*
* Those these callbacks are called with struct &media_device.graph_mutex
* mutex held.
*/
struct media_entity_operations {
int (*get_fwnode_pad)(struct media_entity *entity,
struct fwnode_endpoint *endpoint);
int (*link_setup)(struct media_entity *entity,
const struct media_pad *local,
const struct media_pad *remote, u32 flags);
int (*link_validate)(struct media_link *link);
bool (*has_pad_interdep)(struct media_entity *entity, unsigned int pad0,
unsigned int pad1);
};
/**
* enum media_entity_type - Media entity type
*
* @MEDIA_ENTITY_TYPE_BASE:
* The entity isn't embedded in another subsystem structure.
* @MEDIA_ENTITY_TYPE_VIDEO_DEVICE:
* The entity is embedded in a struct video_device instance.
* @MEDIA_ENTITY_TYPE_V4L2_SUBDEV:
* The entity is embedded in a struct v4l2_subdev instance.
*
* Media entity objects are often not instantiated directly, but the media
* entity structure is inherited by (through embedding) other subsystem-specific
* structures. The media entity type identifies the type of the subclass
* structure that implements a media entity instance.
*
* This allows runtime type identification of media entities and safe casting to
* the correct object type. For instance, a media entity structure instance
* embedded in a v4l2_subdev structure instance will have the type
* %MEDIA_ENTITY_TYPE_V4L2_SUBDEV and can safely be cast to a &v4l2_subdev
* structure using the container_of() macro.
*/
enum media_entity_type {
MEDIA_ENTITY_TYPE_BASE,
MEDIA_ENTITY_TYPE_VIDEO_DEVICE,
MEDIA_ENTITY_TYPE_V4L2_SUBDEV,
};
/**
* struct media_entity - A media entity graph object.
*
* @graph_obj: Embedded structure containing the media object common data.
* @name: Entity name.
* @obj_type: Type of the object that implements the media_entity.
* @function: Entity main function, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* (seek for ``MEDIA_ENT_F_*``)
* @flags: Entity flags, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* (seek for ``MEDIA_ENT_FL_*``)
* @num_pads: Number of sink and source pads.
* @num_links: Total number of links, forward and back, enabled and disabled.
* @num_backlinks: Number of backlinks
* @internal_idx: An unique internal entity specific number. The numbers are
* re-used if entities are unregistered or registered again.
* @pads: Pads array with the size defined by @num_pads.
* @links: List of data links.
* @ops: Entity operations.
* @use_count: Use count for the entity.
* @info: Union with devnode information. Kept just for backward
* compatibility.
* @info.dev: Contains device major and minor info.
* @info.dev.major: device node major, if the device is a devnode.
* @info.dev.minor: device node minor, if the device is a devnode.
*
* .. note::
*
media: media-entity: Simplify media_pipeline_start() The media_pipeline_start() function has two purposes: it constructs a pipeline by recording the entities that are part of it, gathered from a graph walk, and validate the media links. The pipeline pointer is stored in the media_entity structure as part of this process, and the entity's stream count is increased, to record that the entity is streaming. When multiple video nodes are present in a pipeline, media_pipeline_start() is typically called on all of them, with the same pipeline pointer. This is taken into account in media_pipeline_start() by skipping validation for entities that are already part of the pipeline, while returning an error if an entity is part of a different pipeline. It turns out that this process is overly complicated. When media_pipeline_start() is called for the first time, it constructs the full pipeline, adding all entities and validating all the links. Subsequent calls to media_pipeline_start() are then nearly no-ops, they only increase the stream count on the pipeline and on all entities. The media_entity stream_count field is used for two purposes: checking if the entity is streaming, and detecting when a call to media_pipeline_stop() balances needs to reset the entity pipe pointer to NULL. The former can easily be replaced by a check of the pipe pointer. Simplify media_pipeline_start() by avoiding the pipeline walk on all calls but the first one, and drop the media_entity stream_count field. media_pipeline_stop() is updated accordingly. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> [Sakari Ailus: Drop redundant '!= NULL' as discussed] Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com>
2022-01-13 15:00:42 +00:00
* The @use_count reference count must never be negative, but is a signed
* integer on purpose: a simple ``WARN_ON(<0)`` check can be used to detect
* reference count bugs that would make it negative.
*/
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
struct media_entity {
struct media_gobj graph_obj; /* must be first field in struct */
const char *name;
enum media_entity_type obj_type;
u32 function;
unsigned long flags;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
u16 num_pads;
u16 num_links;
u16 num_backlinks;
int internal_idx;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
struct media_pad *pads;
struct list_head links;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
const struct media_entity_operations *ops;
int use_count;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
union {
struct {
u32 major;
u32 minor;
} dev;
} info;
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
};
/**
* media_entity_for_each_pad - Iterate on all pads in an entity
* @entity: The entity the pads belong to
* @iter: The iterator pad
*
* Iterate on all pads in a media entity.
*/
#define media_entity_for_each_pad(entity, iter) \
for (iter = (entity)->pads; \
iter < &(entity)->pads[(entity)->num_pads]; \
++iter)
/**
* struct media_interface - A media interface graph object.
*
* @graph_obj: embedded graph object
* @links: List of links pointing to graph entities
* @type: Type of the interface as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* (seek for ``MEDIA_INTF_T_*``)
* @flags: Interface flags as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* (seek for ``MEDIA_INTF_FL_*``)
*
* .. note::
*
* Currently, no flags for &media_interface is defined.
*/
struct media_interface {
struct media_gobj graph_obj;
struct list_head links;
u32 type;
u32 flags;
};
/**
* struct media_intf_devnode - A media interface via a device node.
*
* @intf: embedded interface object
* @major: Major number of a device node
* @minor: Minor number of a device node
*/
struct media_intf_devnode {
struct media_interface intf;
/* Should match the fields at media_v2_intf_devnode */
u32 major;
u32 minor;
};
/**
* media_entity_id() - return the media entity graph object id
*
* @entity: pointer to &media_entity
*/
static inline u32 media_entity_id(struct media_entity *entity)
{
return entity->graph_obj.id;
}
/**
* media_type() - return the media object type
*
* @gobj: Pointer to the struct &media_gobj graph object
*/
static inline enum media_gobj_type media_type(struct media_gobj *gobj)
{
return gobj->id >> MEDIA_BITS_PER_ID;
}
/**
* media_id() - return the media object ID
*
* @gobj: Pointer to the struct &media_gobj graph object
*/
static inline u32 media_id(struct media_gobj *gobj)
{
return gobj->id & MEDIA_ID_MASK;
}
/**
* media_gobj_gen_id() - encapsulates type and ID on at the object ID
*
* @type: object type as define at enum &media_gobj_type.
* @local_id: next ID, from struct &media_device.id.
*/
static inline u32 media_gobj_gen_id(enum media_gobj_type type, u64 local_id)
{
u32 id;
id = type << MEDIA_BITS_PER_ID;
id |= local_id & MEDIA_ID_MASK;
return id;
}
/**
* is_media_entity_v4l2_video_device() - Check if the entity is a video_device
* @entity: pointer to entity
*
* Return: %true if the entity is an instance of a video_device object and can
* safely be cast to a struct video_device using the container_of() macro, or
* %false otherwise.
*/
static inline bool is_media_entity_v4l2_video_device(struct media_entity *entity)
{
return entity && entity->obj_type == MEDIA_ENTITY_TYPE_VIDEO_DEVICE;
}
/**
* is_media_entity_v4l2_subdev() - Check if the entity is a v4l2_subdev
* @entity: pointer to entity
*
* Return: %true if the entity is an instance of a &v4l2_subdev object and can
* safely be cast to a struct &v4l2_subdev using the container_of() macro, or
* %false otherwise.
*/
static inline bool is_media_entity_v4l2_subdev(struct media_entity *entity)
{
return entity && entity->obj_type == MEDIA_ENTITY_TYPE_V4L2_SUBDEV;
}
/**
* media_entity_enum_init - Initialise an entity enumeration
*
* @ent_enum: Entity enumeration to be initialised
* @mdev: The related media device
*
* Return: zero on success or a negative error code.
*/
__must_check int media_entity_enum_init(struct media_entity_enum *ent_enum,
struct media_device *mdev);
/**
* media_entity_enum_cleanup - Release resources of an entity enumeration
*
* @ent_enum: Entity enumeration to be released
*/
void media_entity_enum_cleanup(struct media_entity_enum *ent_enum);
/**
* media_entity_enum_zero - Clear the entire enum
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum: Entity enumeration to be cleared
*/
static inline void media_entity_enum_zero(struct media_entity_enum *ent_enum)
{
bitmap_zero(ent_enum->bmap, ent_enum->idx_max);
}
/**
* media_entity_enum_set - Mark a single entity in the enum
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum: Entity enumeration
* @entity: Entity to be marked
*/
static inline void media_entity_enum_set(struct media_entity_enum *ent_enum,
struct media_entity *entity)
{
if (WARN_ON(entity->internal_idx >= ent_enum->idx_max))
return;
__set_bit(entity->internal_idx, ent_enum->bmap);
}
/**
* media_entity_enum_clear - Unmark a single entity in the enum
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum: Entity enumeration
* @entity: Entity to be unmarked
*/
static inline void media_entity_enum_clear(struct media_entity_enum *ent_enum,
struct media_entity *entity)
{
if (WARN_ON(entity->internal_idx >= ent_enum->idx_max))
return;
__clear_bit(entity->internal_idx, ent_enum->bmap);
}
/**
* media_entity_enum_test - Test whether the entity is marked
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum: Entity enumeration
* @entity: Entity to be tested
*
* Returns %true if the entity was marked.
*/
static inline bool media_entity_enum_test(struct media_entity_enum *ent_enum,
struct media_entity *entity)
{
if (WARN_ON(entity->internal_idx >= ent_enum->idx_max))
return true;
return test_bit(entity->internal_idx, ent_enum->bmap);
}
/**
[media] get rid of a number of problems at the cross references As warned by linuxdoc[1] tool, using: $ for i in $(git grep kernel-doc Documentation/media/kapi/|cut -d: -f4); do kernel-lintdoc --sloppy $i; done include/media/v4l2-dev.h:118 :WARN: function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-mc.h:56 [kernel-doc WARN] : enum name from comment differs: if_vid_dec_index <--> if_vid_dec_pad_index include/media/v4l2-mc.h:71 [kernel-doc WARN] : enum name from comment differs: if_aud_dec_index <--> if_aud_dec_pad_index include/media/v4l2-mem2mem.h:396 [kernel-doc WARN] : function name from comment differs: v4l2_m2m_num_src_bufs_ready <--> v4l2_m2m_num_dst_bufs_ready drivers/media/dvb-core/dvb_math.h:28 [kernel-doc WARN] : function name from comment differs: cintlog2 <--> intlog2 include/media/v4l2-subdev.h:215 [kernel-doc WARN] : struct name from comment differs: s_radio <--> v4l2_subdev_tuner_ops include/media/v4l2-subdev.h:890 [kernel-doc WARN] : function name from comment differs: v4l2_set_subdevdata <--> v4l2_set_subdev_hostdata include/media/v4l2-subdev.h:901 [kernel-doc WARN] : function name from comment differs: v4l2_get_subdevdata <--> v4l2_get_subdev_hostdata drivers/media/dvb-core/dvb_ringbuffer.h:196 [kernel-doc WARN] : function name from comment differs: dvb_ringbuffer_writeuser <--> dvb_ringbuffer_write_user include/media/videobuf2-core.h:399 [kernel-doc WARN] : struct name from comment differs: vb2_ops <--> vb2_buf_ops include/media/media-entity.h:132 [kernel-doc ERROR] : duplicate parameter definition 'source' include/media/media-entity.h:477 [kernel-doc WARN] : function name from comment differs: media_entity_enum_test <--> media_entity_enum_test_and_set include/media/media-entity.h:535 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_pad include/media/media-entity.h:544 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_link include/media/media-entity.h:553 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_intf include/media/media-entity.h:562 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> intf_to_devnode include/media/rc-core.h:234 [kernel-doc WARN] : function name from comment differs: rc_open <--> rc_close include/media/v4l2-ctrls.h:397 [kernel-doc WARN] : missing initial short description of 'v4l2_ctrl_handler_init' include/media/v4l2-dev.h:118 [kernel-doc WARN] : function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-event.h:225 [kernel-doc WARN] : missing initial short description of 'v4l2_src_change_event_subscribe' [1] https://return42.github.io/linuxdoc/linux.html The above are real issues at the documentation. On several cases, caused by cut-and-paste. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22 10:59:03 +00:00
* media_entity_enum_test_and_set - Test whether the entity is marked,
* and mark it
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum: Entity enumeration
* @entity: Entity to be tested
*
* Returns %true if the entity was marked, and mark it before doing so.
*/
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
static inline bool
media_entity_enum_test_and_set(struct media_entity_enum *ent_enum,
struct media_entity *entity)
{
if (WARN_ON(entity->internal_idx >= ent_enum->idx_max))
return true;
return __test_and_set_bit(entity->internal_idx, ent_enum->bmap);
}
/**
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* media_entity_enum_empty - Test whether the entire enum is empty
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum: Entity enumeration
*
* Return: %true if the entity was empty.
*/
static inline bool media_entity_enum_empty(struct media_entity_enum *ent_enum)
{
return bitmap_empty(ent_enum->bmap, ent_enum->idx_max);
}
/**
* media_entity_enum_intersects - Test whether two enums intersect
*
[media] media-entity.h fix documentation for several parameters Several parameters added by the media_ent_enum patches were declared with wrong argument names: include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-device.h:333: warning: No description found for parameter 'entity_internal_idx_max' include/media/media-device.h:354: warning: No description found for parameter 'ent_enum' include/media/media-device.h:354: warning: Excess function parameter 'e' description in 'media_entity_enum_init' include/media/media-entity.h:397: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:397: warning: Excess function parameter 'e' description in 'media_entity_enum_zero' include/media/media-entity.h:409: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:409: warning: Excess function parameter 'e' description in 'media_entity_enum_set' include/media/media-entity.h:424: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:424: warning: Excess function parameter 'e' description in 'media_entity_enum_clear' include/media/media-entity.h:441: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:441: warning: Excess function parameter 'e' description in 'media_entity_enum_test' include/media/media-entity.h:458: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:458: warning: Excess function parameter 'e' description in 'media_entity_enum_test_and_set' include/media/media-entity.h:474: warning: No description found for parameter 'ent_enum' include/media/media-entity.h:474: warning: Excess function parameter 'e' description in 'media_entity_enum_empty' include/media/media-entity.h:474: warning: Excess function parameter 'entity' description in 'media_entity_enum_empty' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum1' include/media/media-entity.h:489: warning: No description found for parameter 'ent_enum2' include/media/media-entity.h:489: warning: Excess function parameter 'e' description in 'media_entity_enum_intersects' include/media/media-entity.h:489: warning: Excess function parameter 'f' description in 'media_entity_enum_intersects' Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-12-16 15:58:31 +00:00
* @ent_enum1: First entity enumeration
* @ent_enum2: Second entity enumeration
*
* Return: %true if entity enumerations @ent_enum1 and @ent_enum2 intersect,
* otherwise %false.
*/
static inline bool media_entity_enum_intersects(
struct media_entity_enum *ent_enum1,
struct media_entity_enum *ent_enum2)
{
WARN_ON(ent_enum1->idx_max != ent_enum2->idx_max);
return bitmap_intersects(ent_enum1->bmap, ent_enum2->bmap,
min(ent_enum1->idx_max, ent_enum2->idx_max));
}
/**
* gobj_to_entity - returns the struct &media_entity pointer from the
* @gobj contained on it.
*
* @gobj: Pointer to the struct &media_gobj graph object
*/
#define gobj_to_entity(gobj) \
container_of(gobj, struct media_entity, graph_obj)
/**
[media] get rid of a number of problems at the cross references As warned by linuxdoc[1] tool, using: $ for i in $(git grep kernel-doc Documentation/media/kapi/|cut -d: -f4); do kernel-lintdoc --sloppy $i; done include/media/v4l2-dev.h:118 :WARN: function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-mc.h:56 [kernel-doc WARN] : enum name from comment differs: if_vid_dec_index <--> if_vid_dec_pad_index include/media/v4l2-mc.h:71 [kernel-doc WARN] : enum name from comment differs: if_aud_dec_index <--> if_aud_dec_pad_index include/media/v4l2-mem2mem.h:396 [kernel-doc WARN] : function name from comment differs: v4l2_m2m_num_src_bufs_ready <--> v4l2_m2m_num_dst_bufs_ready drivers/media/dvb-core/dvb_math.h:28 [kernel-doc WARN] : function name from comment differs: cintlog2 <--> intlog2 include/media/v4l2-subdev.h:215 [kernel-doc WARN] : struct name from comment differs: s_radio <--> v4l2_subdev_tuner_ops include/media/v4l2-subdev.h:890 [kernel-doc WARN] : function name from comment differs: v4l2_set_subdevdata <--> v4l2_set_subdev_hostdata include/media/v4l2-subdev.h:901 [kernel-doc WARN] : function name from comment differs: v4l2_get_subdevdata <--> v4l2_get_subdev_hostdata drivers/media/dvb-core/dvb_ringbuffer.h:196 [kernel-doc WARN] : function name from comment differs: dvb_ringbuffer_writeuser <--> dvb_ringbuffer_write_user include/media/videobuf2-core.h:399 [kernel-doc WARN] : struct name from comment differs: vb2_ops <--> vb2_buf_ops include/media/media-entity.h:132 [kernel-doc ERROR] : duplicate parameter definition 'source' include/media/media-entity.h:477 [kernel-doc WARN] : function name from comment differs: media_entity_enum_test <--> media_entity_enum_test_and_set include/media/media-entity.h:535 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_pad include/media/media-entity.h:544 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_link include/media/media-entity.h:553 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_intf include/media/media-entity.h:562 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> intf_to_devnode include/media/rc-core.h:234 [kernel-doc WARN] : function name from comment differs: rc_open <--> rc_close include/media/v4l2-ctrls.h:397 [kernel-doc WARN] : missing initial short description of 'v4l2_ctrl_handler_init' include/media/v4l2-dev.h:118 [kernel-doc WARN] : function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-event.h:225 [kernel-doc WARN] : missing initial short description of 'v4l2_src_change_event_subscribe' [1] https://return42.github.io/linuxdoc/linux.html The above are real issues at the documentation. On several cases, caused by cut-and-paste. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22 10:59:03 +00:00
* gobj_to_pad - returns the struct &media_pad pointer from the
* @gobj contained on it.
*
* @gobj: Pointer to the struct &media_gobj graph object
*/
#define gobj_to_pad(gobj) \
container_of(gobj, struct media_pad, graph_obj)
/**
[media] get rid of a number of problems at the cross references As warned by linuxdoc[1] tool, using: $ for i in $(git grep kernel-doc Documentation/media/kapi/|cut -d: -f4); do kernel-lintdoc --sloppy $i; done include/media/v4l2-dev.h:118 :WARN: function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-mc.h:56 [kernel-doc WARN] : enum name from comment differs: if_vid_dec_index <--> if_vid_dec_pad_index include/media/v4l2-mc.h:71 [kernel-doc WARN] : enum name from comment differs: if_aud_dec_index <--> if_aud_dec_pad_index include/media/v4l2-mem2mem.h:396 [kernel-doc WARN] : function name from comment differs: v4l2_m2m_num_src_bufs_ready <--> v4l2_m2m_num_dst_bufs_ready drivers/media/dvb-core/dvb_math.h:28 [kernel-doc WARN] : function name from comment differs: cintlog2 <--> intlog2 include/media/v4l2-subdev.h:215 [kernel-doc WARN] : struct name from comment differs: s_radio <--> v4l2_subdev_tuner_ops include/media/v4l2-subdev.h:890 [kernel-doc WARN] : function name from comment differs: v4l2_set_subdevdata <--> v4l2_set_subdev_hostdata include/media/v4l2-subdev.h:901 [kernel-doc WARN] : function name from comment differs: v4l2_get_subdevdata <--> v4l2_get_subdev_hostdata drivers/media/dvb-core/dvb_ringbuffer.h:196 [kernel-doc WARN] : function name from comment differs: dvb_ringbuffer_writeuser <--> dvb_ringbuffer_write_user include/media/videobuf2-core.h:399 [kernel-doc WARN] : struct name from comment differs: vb2_ops <--> vb2_buf_ops include/media/media-entity.h:132 [kernel-doc ERROR] : duplicate parameter definition 'source' include/media/media-entity.h:477 [kernel-doc WARN] : function name from comment differs: media_entity_enum_test <--> media_entity_enum_test_and_set include/media/media-entity.h:535 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_pad include/media/media-entity.h:544 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_link include/media/media-entity.h:553 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_intf include/media/media-entity.h:562 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> intf_to_devnode include/media/rc-core.h:234 [kernel-doc WARN] : function name from comment differs: rc_open <--> rc_close include/media/v4l2-ctrls.h:397 [kernel-doc WARN] : missing initial short description of 'v4l2_ctrl_handler_init' include/media/v4l2-dev.h:118 [kernel-doc WARN] : function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-event.h:225 [kernel-doc WARN] : missing initial short description of 'v4l2_src_change_event_subscribe' [1] https://return42.github.io/linuxdoc/linux.html The above are real issues at the documentation. On several cases, caused by cut-and-paste. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22 10:59:03 +00:00
* gobj_to_link - returns the struct &media_link pointer from the
* @gobj contained on it.
*
* @gobj: Pointer to the struct &media_gobj graph object
*/
#define gobj_to_link(gobj) \
container_of(gobj, struct media_link, graph_obj)
/**
[media] get rid of a number of problems at the cross references As warned by linuxdoc[1] tool, using: $ for i in $(git grep kernel-doc Documentation/media/kapi/|cut -d: -f4); do kernel-lintdoc --sloppy $i; done include/media/v4l2-dev.h:118 :WARN: function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-mc.h:56 [kernel-doc WARN] : enum name from comment differs: if_vid_dec_index <--> if_vid_dec_pad_index include/media/v4l2-mc.h:71 [kernel-doc WARN] : enum name from comment differs: if_aud_dec_index <--> if_aud_dec_pad_index include/media/v4l2-mem2mem.h:396 [kernel-doc WARN] : function name from comment differs: v4l2_m2m_num_src_bufs_ready <--> v4l2_m2m_num_dst_bufs_ready drivers/media/dvb-core/dvb_math.h:28 [kernel-doc WARN] : function name from comment differs: cintlog2 <--> intlog2 include/media/v4l2-subdev.h:215 [kernel-doc WARN] : struct name from comment differs: s_radio <--> v4l2_subdev_tuner_ops include/media/v4l2-subdev.h:890 [kernel-doc WARN] : function name from comment differs: v4l2_set_subdevdata <--> v4l2_set_subdev_hostdata include/media/v4l2-subdev.h:901 [kernel-doc WARN] : function name from comment differs: v4l2_get_subdevdata <--> v4l2_get_subdev_hostdata drivers/media/dvb-core/dvb_ringbuffer.h:196 [kernel-doc WARN] : function name from comment differs: dvb_ringbuffer_writeuser <--> dvb_ringbuffer_write_user include/media/videobuf2-core.h:399 [kernel-doc WARN] : struct name from comment differs: vb2_ops <--> vb2_buf_ops include/media/media-entity.h:132 [kernel-doc ERROR] : duplicate parameter definition 'source' include/media/media-entity.h:477 [kernel-doc WARN] : function name from comment differs: media_entity_enum_test <--> media_entity_enum_test_and_set include/media/media-entity.h:535 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_pad include/media/media-entity.h:544 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_link include/media/media-entity.h:553 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_intf include/media/media-entity.h:562 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> intf_to_devnode include/media/rc-core.h:234 [kernel-doc WARN] : function name from comment differs: rc_open <--> rc_close include/media/v4l2-ctrls.h:397 [kernel-doc WARN] : missing initial short description of 'v4l2_ctrl_handler_init' include/media/v4l2-dev.h:118 [kernel-doc WARN] : function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-event.h:225 [kernel-doc WARN] : missing initial short description of 'v4l2_src_change_event_subscribe' [1] https://return42.github.io/linuxdoc/linux.html The above are real issues at the documentation. On several cases, caused by cut-and-paste. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22 10:59:03 +00:00
* gobj_to_intf - returns the struct &media_interface pointer from the
* @gobj contained on it.
*
* @gobj: Pointer to the struct &media_gobj graph object
*/
#define gobj_to_intf(gobj) \
container_of(gobj, struct media_interface, graph_obj)
/**
[media] get rid of a number of problems at the cross references As warned by linuxdoc[1] tool, using: $ for i in $(git grep kernel-doc Documentation/media/kapi/|cut -d: -f4); do kernel-lintdoc --sloppy $i; done include/media/v4l2-dev.h:118 :WARN: function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-mc.h:56 [kernel-doc WARN] : enum name from comment differs: if_vid_dec_index <--> if_vid_dec_pad_index include/media/v4l2-mc.h:71 [kernel-doc WARN] : enum name from comment differs: if_aud_dec_index <--> if_aud_dec_pad_index include/media/v4l2-mem2mem.h:396 [kernel-doc WARN] : function name from comment differs: v4l2_m2m_num_src_bufs_ready <--> v4l2_m2m_num_dst_bufs_ready drivers/media/dvb-core/dvb_math.h:28 [kernel-doc WARN] : function name from comment differs: cintlog2 <--> intlog2 include/media/v4l2-subdev.h:215 [kernel-doc WARN] : struct name from comment differs: s_radio <--> v4l2_subdev_tuner_ops include/media/v4l2-subdev.h:890 [kernel-doc WARN] : function name from comment differs: v4l2_set_subdevdata <--> v4l2_set_subdev_hostdata include/media/v4l2-subdev.h:901 [kernel-doc WARN] : function name from comment differs: v4l2_get_subdevdata <--> v4l2_get_subdev_hostdata drivers/media/dvb-core/dvb_ringbuffer.h:196 [kernel-doc WARN] : function name from comment differs: dvb_ringbuffer_writeuser <--> dvb_ringbuffer_write_user include/media/videobuf2-core.h:399 [kernel-doc WARN] : struct name from comment differs: vb2_ops <--> vb2_buf_ops include/media/media-entity.h:132 [kernel-doc ERROR] : duplicate parameter definition 'source' include/media/media-entity.h:477 [kernel-doc WARN] : function name from comment differs: media_entity_enum_test <--> media_entity_enum_test_and_set include/media/media-entity.h:535 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_pad include/media/media-entity.h:544 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_link include/media/media-entity.h:553 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> gobj_to_intf include/media/media-entity.h:562 [kernel-doc WARN] : function name from comment differs: gobj_to_entity <--> intf_to_devnode include/media/rc-core.h:234 [kernel-doc WARN] : function name from comment differs: rc_open <--> rc_close include/media/v4l2-ctrls.h:397 [kernel-doc WARN] : missing initial short description of 'v4l2_ctrl_handler_init' include/media/v4l2-dev.h:118 [kernel-doc WARN] : function name from comment differs: v4l2_prio_close <--> v4l2_prio_check include/media/v4l2-event.h:225 [kernel-doc WARN] : missing initial short description of 'v4l2_src_change_event_subscribe' [1] https://return42.github.io/linuxdoc/linux.html The above are real issues at the documentation. On several cases, caused by cut-and-paste. Fix them. Signed-off-by: Mauro Carvalho Chehab <mchehab@s-opensource.com>
2016-09-22 10:59:03 +00:00
* intf_to_devnode - returns the struct media_intf_devnode pointer from the
* @intf contained on it.
*
* @intf: Pointer to struct &media_intf_devnode
*/
#define intf_to_devnode(intf) \
container_of(intf, struct media_intf_devnode, intf)
/**
* media_gobj_create - Initialize a graph object
*
* @mdev: Pointer to the &media_device that contains the object
* @type: Type of the object
* @gobj: Pointer to the struct &media_gobj graph object
*
* This routine initializes the embedded struct &media_gobj inside a
* media graph object. It is called automatically if ``media_*_create``
* function calls are used. However, if the object (entity, link, pad,
* interface) is embedded on some other object, this function should be
* called before registering the object at the media controller.
*/
void media_gobj_create(struct media_device *mdev,
enum media_gobj_type type,
struct media_gobj *gobj);
/**
* media_gobj_destroy - Stop using a graph object on a media device
*
* @gobj: Pointer to the struct &media_gobj graph object
*
* This should be called by all routines like media_device_unregister()
* that remove/destroy media graph objects.
*/
void media_gobj_destroy(struct media_gobj *gobj);
/**
* media_entity_pads_init() - Initialize the entity pads
*
* @entity: entity where the pads belong
* @num_pads: total number of sink and source pads
* @pads: Array of @num_pads pads.
*
* The pads array is managed by the entity driver and passed to
* media_entity_pads_init() where its pointer will be stored in the
* &media_entity structure.
*
* If no pads are needed, drivers could either directly fill
* &media_entity->num_pads with 0 and &media_entity->pads with %NULL or call
* this function that will do the same.
*
* 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.
*/
int media_entity_pads_init(struct media_entity *entity, u16 num_pads,
[media] media: convert links from array to list The entire logic that represent graph links were developed on a time where there were no needs to dynamic remove links. So, although links are created/removed one by one via some functions, they're stored as an array inside the entity struct. As the array may grow, there's a logic inside the code that checks if the amount of space is not enough to store the needed links. If it isn't the core uses krealloc() to change the size of the link, with is bad, as it leaves the memory fragmented. So, convert links into a list. Also, currently, both source and sink entities need the link at the graph traversal logic inside media_entity. So there's a logic duplicating all links. That makes it to spend twice the memory needed. This is not a big deal for today's usage, where the number of links are not big. Yet, if during the MC workshop discussions, it was said that IIO graphs could have up to 4,000 entities. So, we may want to remove the duplication on some future. The problem is that it would require a separate linked list to store the backlinks inside the entity, or to use a more complex algorithm to do graph backlink traversal, with is something that the current graph traversal inside the core can't cope with. So, let's postpone a such change if/when it is actually needed. It should also be noticed that the media_link structure uses 44 bytes on 32-bit architectures and 84 bytes on 64-bit architecture. It will thus be allocated out of the 64-bytes and 96-bytes pools respectively. That's a 12.5% memory waste on 64-bit architectures and 31.25% on 32-bit architecture. A linked list is less efficient than an array in this case, but this could later be optimized if we can get rid of the reverse links (with would reduce memory allocation by 50%). Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
2015-08-07 09:55:40 +00:00
struct media_pad *pads);
/**
* media_entity_cleanup() - free resources associated with an entity
*
* @entity: entity where the pads belong
*
* This function must be called during the cleanup phase after unregistering
* the entity (currently, it does nothing).
*
* Calling media_entity_cleanup() on a media_entity whose memory has been
* zeroed but that has not been initialized with media_entity_pad_init() is
* valid and is a no-op.
*/
#if IS_ENABLED(CONFIG_MEDIA_CONTROLLER)
static inline void media_entity_cleanup(struct media_entity *entity) {}
#else
#define media_entity_cleanup(entity) do { } while (false)
#endif
/**
* media_get_pad_index() - retrieves a pad index from an entity
*
* @entity: entity where the pads belong
* @pad_type: the type of the pad, one of MEDIA_PAD_FL_* pad types
* @sig_type: type of signal of the pad to be search
*
* This helper function finds the first pad index inside an entity that
* satisfies both @is_sink and @sig_type conditions.
*
* Return:
*
* On success, return the pad number. If the pad was not found or the media
* entity is a NULL pointer, return -EINVAL.
*/
int media_get_pad_index(struct media_entity *entity, u32 pad_type,
enum media_pad_signal_type sig_type);
/**
* media_create_pad_link() - creates a link between two entities.
*
* @source: pointer to &media_entity of the source pad.
* @source_pad: number of the source pad in the pads array
* @sink: pointer to &media_entity of the sink pad.
* @sink_pad: number of the sink pad in the pads array.
* @flags: Link flags, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* ( seek for ``MEDIA_LNK_FL_*``)
*
* Valid values for flags:
*
* %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.
*
* .. note::
*
* Before calling this function, media_entity_pads_init() and
* media_device_register_entity() should be called previously for both ends.
*/
__must_check int media_create_pad_link(struct media_entity *source,
u16 source_pad, struct media_entity *sink,
u16 sink_pad, u32 flags);
/**
* media_create_pad_links() - creates a link between two entities.
*
* @mdev: Pointer to the media_device that contains the object
* @source_function: Function of the source entities. Used only if @source is
* NULL.
* @source: pointer to &media_entity of the source pad. If NULL, it will use
* all entities that matches the @sink_function.
* @source_pad: number of the source pad in the pads array
* @sink_function: Function of the sink entities. Used only if @sink is NULL.
* @sink: pointer to &media_entity of the sink pad. If NULL, it will use
* all entities that matches the @sink_function.
* @sink_pad: number of the sink pad in the pads array.
* @flags: Link flags, as defined in include/uapi/linux/media.h.
* @allow_both_undefined: if %true, then both @source and @sink can be NULL.
* In such case, it will create a crossbar between all entities that
* matches @source_function to all entities that matches @sink_function.
* If %false, it will return 0 and won't create any link if both @source
* and @sink are NULL.
*
* Valid values for flags:
*
* A %MEDIA_LNK_FL_ENABLED flag indicates that the link is enabled and can be
* used to transfer media data. If multiple links are created and this
* flag is passed as an argument, only the first created link will have
* this flag.
*
* A %MEDIA_LNK_FL_IMMUTABLE flag 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.
*
* It is common for some devices to have multiple source and/or sink entities
* of the same type that should be linked. While media_create_pad_link()
* creates link by link, this function is meant to allow 1:n, n:1 and even
* cross-bar (n:n) links.
*
* .. note::
*
* Before calling this function, media_entity_pads_init() and
* media_device_register_entity() should be called previously for the
* entities to be linked.
*/
int media_create_pad_links(const struct media_device *mdev,
const u32 source_function,
struct media_entity *source,
const u16 source_pad,
const u32 sink_function,
struct media_entity *sink,
const u16 sink_pad,
u32 flags,
const bool allow_both_undefined);
void __media_entity_remove_links(struct media_entity *entity);
/**
* media_entity_remove_links() - remove all links associated with an entity
*
* @entity: pointer to &media_entity
*
* .. note::
*
* This is called automatically when an entity is unregistered via
* media_device_register_entity().
*/
void media_entity_remove_links(struct media_entity *entity);
/**
* __media_entity_setup_link - Configure a media link without locking
* @link: The link being configured
* @flags: Link configuration flags
*
* The bulk of link setup is handled by the two entities connected through the
* link. This function notifies both entities of the link configuration change.
*
* If the link is immutable or if the current and new configuration are
* identical, return immediately.
*
* The user is expected to hold link->source->parent->mutex. If not,
* media_entity_setup_link() should be used instead.
*/
int __media_entity_setup_link(struct media_link *link, u32 flags);
/**
* media_entity_setup_link() - changes the link flags properties in runtime
*
* @link: pointer to &media_link
* @flags: the requested new link flags
*
* The only configurable property is the %MEDIA_LNK_FL_ENABLED link flag
* to enable/disable a link. Links marked with the
* %MEDIA_LNK_FL_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.
*
* .. note::
*
* The valid values of the flags for the link is the same as described
* on media_create_pad_link(), for pad to pad links or the same as described
* on media_create_intf_link(), for interface to entity links.
*/
int media_entity_setup_link(struct media_link *link, u32 flags);
/**
* media_entity_find_link - Find a link between two pads
* @source: Source pad
* @sink: Sink pad
*
* Return: returns a pointer to the link between the two entities. If no
* such link exists, return %NULL.
*/
struct media_link *media_entity_find_link(struct media_pad *source,
struct media_pad *sink);
/**
* media_pad_remote_pad_first - Find the first pad at the remote end of a link
* @pad: Pad at the local end of the link
*
* Search for a remote pad connected to the given pad by iterating over all
* links originating or terminating at that pad until an enabled link is found.
*
* Return: returns a pointer to the pad at the remote end of the first found
* enabled link, or %NULL if no enabled link has been found.
*/
struct media_pad *media_pad_remote_pad_first(const struct media_pad *pad);
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
/**
* media_pad_remote_pad_unique - Find a remote pad connected to a pad
* @pad: The pad
*
* Search for and return a remote pad connected to @pad through an enabled
* link. If multiple (or no) remote pads are found, an error is returned.
*
* The uniqueness constraint makes this helper function suitable for entities
* that support a single active source at a time on a given pad.
*
* Return: A pointer to the remote pad, or one of the following error pointers
* if an error occurs:
*
* * -ENOTUNIQ - Multiple links are enabled
* * -ENOLINK - No connected pad found
*/
struct media_pad *media_pad_remote_pad_unique(const struct media_pad *pad);
/**
* media_entity_remote_pad_unique - Find a remote pad connected to an entity
* @entity: The entity
* @type: The type of pad to find (MEDIA_PAD_FL_SINK or MEDIA_PAD_FL_SOURCE)
*
* Search for and return a remote pad of @type connected to @entity through an
* enabled link. If multiple (or no) remote pads match these criteria, an error
* is returned.
*
* The uniqueness constraint makes this helper function suitable for entities
* that support a single active source or sink at a time.
*
* Return: A pointer to the remote pad, or one of the following error pointers
* if an error occurs:
*
* * -ENOTUNIQ - Multiple links are enabled
* * -ENOLINK - No connected pad found
*/
struct media_pad *
media_entity_remote_pad_unique(const struct media_entity *entity,
unsigned int type);
/**
* media_entity_remote_source_pad_unique - Find a remote source pad connected to
* an entity
* @entity: The entity
*
* Search for and return a remote source pad connected to @entity through an
* enabled link. If multiple (or no) remote pads match these criteria, an error
* is returned.
*
* The uniqueness constraint makes this helper function suitable for entities
* that support a single active source at a time.
*
* Return: A pointer to the remote pad, or one of the following error pointers
* if an error occurs:
*
* * -ENOTUNIQ - Multiple links are enabled
* * -ENOLINK - No connected pad found
*/
static inline struct media_pad *
media_entity_remote_source_pad_unique(const struct media_entity *entity)
{
return media_entity_remote_pad_unique(entity, MEDIA_PAD_FL_SOURCE);
}
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
/**
* media_pad_is_streaming - Test if a pad is part of a streaming pipeline
* @pad: The pad
*
* Return: True if the pad is part of a pipeline started with the
* media_pipeline_start() function, false otherwise.
*/
static inline bool media_pad_is_streaming(const struct media_pad *pad)
{
return pad->pipe;
}
/**
* media_entity_is_streaming - Test if an entity is part of a streaming pipeline
* @entity: The entity
*
* Return: True if the entity is part of a pipeline started with the
* media_pipeline_start() function, false otherwise.
*/
static inline bool media_entity_is_streaming(const struct media_entity *entity)
{
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
struct media_pad *pad;
media_entity_for_each_pad(entity, pad) {
if (media_pad_is_streaming(pad))
return true;
}
return false;
}
/**
* media_entity_pipeline - Get the media pipeline an entity is part of
* @entity: The entity
*
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
* DEPRECATED: use media_pad_pipeline() instead.
*
* This function returns the media pipeline that an entity has been associated
* with when constructing the pipeline with media_pipeline_start(). The pointer
* remains valid until media_pipeline_stop() is called.
*
* In general, entities can be part of multiple pipelines, when carrying
* multiple streams (either on different pads, or on the same pad using
* multiplexed streams). This function is to be used only for entities that
* do not support multiple pipelines.
*
* Return: The media_pipeline the entity is part of, or NULL if the entity is
* not part of any pipeline.
*/
struct media_pipeline *media_entity_pipeline(struct media_entity *entity);
media: mc: entity: Rewrite media_pipeline_start() [Note: the code is mostly from Laurent but the patch description is from Tomi] The media_pipeline_start() and media_pipeline_stop() functions use the media graph walk API to traverse the graph and validate the pipeline. The graph walk traverses the media graph following links between the entities. Also, while the pipeline can't change between the start and stop calls, the graph is walked again from scratch at stop time, or any time a driver needs to inspect the pipeline. With the upcoming multiplexed streams support we will need a bit more intelligent pipeline construction, as e.g. two independent streams may be passing through a single entity via separate pads in which case those pads should not be part of the same pipeline. This patch essentially rewrites the media_pipeline_start/stop so that a pipeline is defined as a set of pads instead of entities and the media graph traversal considers the pad interdependencies when choosing which links to follow. Currently all the entity's pads are considered as interdependent. This means that the behavior with all the current drivers stays the same, but in the future we can define a more fine-grained pipeline construction. Additionally the media pipeline's pads are cached at media_pipeline_start() time, and re-used at media_pipeline_stop() which avoid the need to re-walk the whole graph as the previous implementation did. Also, caching pads in the pipeline can serve in the future as the foundation to provide a better API than the media graph walk to drivers to iterate over pads and entities in the pipeline. Note that the old media_pipeline_start/stop used the media graph walk API. The new version does not use the media graph walk API, but instead a new implementation. There are two reasons for not changing the graph walk: it proved to be rather difficult to change the graph walk to have the features implemented in this patch, and second, this keeps the backward compatibility of the graph walk as there are users of the graph walk API The long term plan is that all the existing code would be converted to use the new cached pipeline, thus allowing us to remove the graph walk. Signed-off-by: Laurent Pinchart <laurent.pinchart+renesas@ideasonboard.com> Signed-off-by: Tomi Valkeinen <tomi.valkeinen@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@linux.intel.com> Signed-off-by: Mauro Carvalho Chehab <mchehab@kernel.org>
2022-08-31 14:13:37 +00:00
/**
* media_pad_pipeline - Get the media pipeline a pad is part of
* @pad: The pad
*
* This function returns the media pipeline that a pad has been associated
* with when constructing the pipeline with media_pipeline_start(). The pointer
* remains valid until media_pipeline_stop() is called.
*
* Return: The media_pipeline the pad is part of, or NULL if the pad is
* not part of any pipeline.
*/
struct media_pipeline *media_pad_pipeline(struct media_pad *pad);
/**
* media_entity_get_fwnode_pad - Get pad number from fwnode
*
* @entity: The entity
* @fwnode: Pointer to the fwnode_handle which should be used to find the pad
* @direction_flags: Expected direction of the pad, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* (seek for ``MEDIA_PAD_FL_*``)
*
* This function can be used to resolve the media pad number from
* a fwnode. This is useful for devices which use more complex
* mappings of media pads.
*
* If the entity does not implement the get_fwnode_pad() operation
* then this function searches the entity for the first pad that
* matches the @direction_flags.
*
* Return: returns the pad number on success or a negative error code.
*/
int media_entity_get_fwnode_pad(struct media_entity *entity,
const struct fwnode_handle *fwnode,
unsigned long direction_flags);
/**
* media_graph_walk_init - Allocate resources used by graph walk.
*
* @graph: Media graph structure that will be used to walk the graph
* @mdev: Pointer to the &media_device that contains the object
*
* This function is deprecated, use media_pipeline_for_each_pad() instead.
*
* The caller is required to hold the media_device graph_mutex during the graph
* walk until the graph state is released.
*
* Returns zero on success or a negative error code otherwise.
*/
__must_check int media_graph_walk_init(
struct media_graph *graph, struct media_device *mdev);
/**
* media_graph_walk_cleanup - Release resources used by graph walk.
*
* @graph: Media graph structure that will be used to walk the graph
*
* This function is deprecated, use media_pipeline_for_each_pad() instead.
*/
void media_graph_walk_cleanup(struct media_graph *graph);
/**
* media_graph_walk_start - Start walking the media graph at a
* given entity
*
* @graph: Media graph structure that will be used to walk the graph
* @entity: Starting entity
*
* This function is deprecated, use media_pipeline_for_each_pad() instead.
*
* Before using this function, media_graph_walk_init() must be
* used to allocate resources used for walking the graph. This
* function initializes the graph traversal structure to walk the
* entities graph starting at the given entity. The traversal
* structure must not be modified by the caller during graph
* traversal. After the graph walk, the resources must be released
* using media_graph_walk_cleanup().
*/
void media_graph_walk_start(struct media_graph *graph,
struct media_entity *entity);
/**
* media_graph_walk_next - Get the next entity in the graph
* @graph: Media graph structure
*
* This function is deprecated, use media_pipeline_for_each_pad() instead.
*
* Perform a depth-first traversal of the given media entities graph.
*
* The graph structure must have been previously initialized with a call to
* media_graph_walk_start().
*
* Return: returns the next entity in the graph or %NULL if the whole graph
* have been traversed.
*/
struct media_entity *media_graph_walk_next(struct media_graph *graph);
/**
* media_pipeline_start - Mark a pipeline as streaming
* @pad: Starting pad
* @pipe: Media pipeline to be assigned to all pads in the pipeline.
*
* Mark all pads connected to a given pad through enabled links, either
* directly or indirectly, as streaming. The given pipeline object is assigned
* to every pad in the pipeline and stored in the media_pad pipe field.
*
* Calls to this function can be nested, in which case the same number of
* media_pipeline_stop() calls will be required to stop streaming. The
* pipeline pointer must be identical for all nested calls to
* media_pipeline_start().
*/
__must_check int media_pipeline_start(struct media_pad *pad,
struct media_pipeline *pipe);
/**
* __media_pipeline_start - Mark a pipeline as streaming
*
* @pad: Starting pad
* @pipe: Media pipeline to be assigned to all pads in the pipeline.
*
* ..note:: This is the non-locking version of media_pipeline_start()
*/
__must_check int __media_pipeline_start(struct media_pad *pad,
struct media_pipeline *pipe);
/**
* media_pipeline_stop - Mark a pipeline as not streaming
* @pad: Starting pad
*
* Mark all pads connected to a given pad through enabled links, either
* directly or indirectly, as not streaming. The media_pad pipe field is
* reset to %NULL.
*
* If multiple calls to media_pipeline_start() have been made, the same
* number of calls to this function are required to mark the pipeline as not
* streaming.
*/
void media_pipeline_stop(struct media_pad *pad);
/**
* __media_pipeline_stop - Mark a pipeline as not streaming
*
* @pad: Starting pad
*
* .. note:: This is the non-locking version of media_pipeline_stop()
*/
void __media_pipeline_stop(struct media_pad *pad);
struct media_pad *
__media_pipeline_pad_iter_next(struct media_pipeline *pipe,
struct media_pipeline_pad_iter *iter,
struct media_pad *pad);
/**
* media_pipeline_for_each_pad - Iterate on all pads in a media pipeline
* @pipe: The pipeline
* @iter: The iterator (struct media_pipeline_pad_iter)
* @pad: The iterator pad
*
* Iterate on all pads in a media pipeline. This is only valid after the
* pipeline has been built with media_pipeline_start() and before it gets
* destroyed with media_pipeline_stop().
*/
#define media_pipeline_for_each_pad(pipe, iter, pad) \
for (pad = __media_pipeline_pad_iter_next((pipe), iter, NULL); \
pad != NULL; \
pad = __media_pipeline_pad_iter_next((pipe), iter, pad))
/**
* media_pipeline_entity_iter_init - Initialize a pipeline entity iterator
* @pipe: The pipeline
* @iter: The iterator
*
* This function must be called to initialize the iterator before using it in a
* media_pipeline_for_each_entity() loop. The iterator must be destroyed by a
* call to media_pipeline_entity_iter_cleanup after the loop (including in code
* paths that break from the loop).
*
* The same iterator can be used in multiple consecutive loops without being
* destroyed and reinitialized.
*
* Return: 0 on success or a negative error code otherwise.
*/
int media_pipeline_entity_iter_init(struct media_pipeline *pipe,
struct media_pipeline_entity_iter *iter);
/**
* media_pipeline_entity_iter_cleanup - Destroy a pipeline entity iterator
* @iter: The iterator
*
* This function must be called to destroy iterators initialized with
* media_pipeline_entity_iter_init().
*/
void media_pipeline_entity_iter_cleanup(struct media_pipeline_entity_iter *iter);
struct media_entity *
__media_pipeline_entity_iter_next(struct media_pipeline *pipe,
struct media_pipeline_entity_iter *iter,
struct media_entity *entity);
/**
* media_pipeline_for_each_entity - Iterate on all entities in a media pipeline
* @pipe: The pipeline
* @iter: The iterator (struct media_pipeline_entity_iter)
* @entity: The iterator entity
*
* Iterate on all entities in a media pipeline. This is only valid after the
* pipeline has been built with media_pipeline_start() and before it gets
* destroyed with media_pipeline_stop(). The iterator must be initialized with
* media_pipeline_entity_iter_init() before iteration, and destroyed with
* media_pipeline_entity_iter_cleanup() after (including in code paths that
* break from the loop).
*/
#define media_pipeline_for_each_entity(pipe, iter, entity) \
for (entity = __media_pipeline_entity_iter_next((pipe), iter, NULL); \
entity != NULL; \
entity = __media_pipeline_entity_iter_next((pipe), iter, entity))
/**
* media_pipeline_alloc_start - Mark a pipeline as streaming
* @pad: Starting pad
*
* media_pipeline_alloc_start() is similar to media_pipeline_start() but instead
* of working on a given pipeline the function will use an existing pipeline if
* the pad is already part of a pipeline, or allocate a new pipeline.
*
* Calls to media_pipeline_alloc_start() must be matched with
* media_pipeline_stop().
*/
__must_check int media_pipeline_alloc_start(struct media_pad *pad);
/**
* media_devnode_create() - creates and initializes a device node interface
*
* @mdev: pointer to struct &media_device
* @type: type of the interface, as given by
* :ref:`include/uapi/linux/media.h <media_header>`
* ( seek for ``MEDIA_INTF_T_*``) macros.
* @flags: Interface flags, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* ( seek for ``MEDIA_INTF_FL_*``)
* @major: Device node major number.
* @minor: Device node minor number.
*
* Return: if succeeded, returns a pointer to the newly allocated
* &media_intf_devnode pointer.
*
* .. note::
*
* Currently, no flags for &media_interface is defined.
*/
struct media_intf_devnode *
__must_check media_devnode_create(struct media_device *mdev,
u32 type, u32 flags,
u32 major, u32 minor);
/**
* media_devnode_remove() - removes a device node interface
*
* @devnode: pointer to &media_intf_devnode to be freed.
*
* When a device node interface is removed, all links to it are automatically
* removed.
*/
void media_devnode_remove(struct media_intf_devnode *devnode);
/**
* media_create_intf_link() - creates a link between an entity and an interface
*
* @entity: pointer to %media_entity
* @intf: pointer to %media_interface
* @flags: Link flags, as defined in
* :ref:`include/uapi/linux/media.h <media_header>`
* ( seek for ``MEDIA_LNK_FL_*``)
*
*
* Valid values for flags:
*
* %MEDIA_LNK_FL_ENABLED
* Indicates that the interface is connected to the entity hardware.
* That's the default value for interfaces. An interface may be disabled if
* the hardware is busy due to the usage of some other interface that it is
* currently controlling the hardware.
*
* A typical example is an hybrid TV device that handle only one type of
* stream on a given time. So, when the digital TV is streaming,
* the V4L2 interfaces won't be enabled, as such device is not able to
* also stream analog TV or radio.
*
* .. note::
*
* Before calling this function, media_devnode_create() should be called for
* the interface and media_device_register_entity() should be called for the
* interface that will be part of the link.
*/
struct media_link *
__must_check media_create_intf_link(struct media_entity *entity,
struct media_interface *intf,
u32 flags);
/**
* __media_remove_intf_link() - remove a single interface link
*
* @link: pointer to &media_link.
*
* .. note:: This is an unlocked version of media_remove_intf_link()
*/
void __media_remove_intf_link(struct media_link *link);
/**
* media_remove_intf_link() - remove a single interface link
*
* @link: pointer to &media_link.
*
* .. note:: Prefer to use this one, instead of __media_remove_intf_link()
*/
void media_remove_intf_link(struct media_link *link);
/**
* __media_remove_intf_links() - remove all links associated with an interface
*
* @intf: pointer to &media_interface
*
* .. note:: This is an unlocked version of media_remove_intf_links().
*/
void __media_remove_intf_links(struct media_interface *intf);
/**
* media_remove_intf_links() - remove all links associated with an interface
*
* @intf: pointer to &media_interface
*
* .. note::
*
* #) This is called automatically when an entity is unregistered via
* media_device_register_entity() and by media_devnode_remove().
*
* #) Prefer to use this one, instead of __media_remove_intf_links().
*/
void media_remove_intf_links(struct media_interface *intf);
/**
* media_entity_call - Calls a struct media_entity_operations operation on
* an entity
*
* @entity: entity where the @operation will be called
* @operation: type of the operation. Should be the name of a member of
* struct &media_entity_operations.
*
* This helper function will check if @operation is not %NULL. On such case,
* it will issue a call to @operation\(@entity, @args\).
*/
#define media_entity_call(entity, operation, args...) \
(((entity)->ops && (entity)->ops->operation) ? \
(entity)->ops->operation((entity) , ##args) : -ENOIOCTLCMD)
/**
* media_create_ancillary_link() - create an ancillary link between two
* instances of &media_entity
*
* @primary: pointer to the primary &media_entity
* @ancillary: pointer to the ancillary &media_entity
*
* Create an ancillary link between two entities, indicating that they
* represent two connected pieces of hardware that form a single logical unit.
* A typical example is a camera lens controller being linked to the sensor that
* it is supporting.
*
* The function sets both MEDIA_LNK_FL_ENABLED and MEDIA_LNK_FL_IMMUTABLE for
* the new link.
*/
struct media_link *
media_create_ancillary_link(struct media_entity *primary,
struct media_entity *ancillary);
/**
* __media_entity_next_link() - Iterate through a &media_entity's links
*
* @entity: pointer to the &media_entity
* @link: pointer to a &media_link to hold the iterated values
* @link_type: one of the MEDIA_LNK_FL_LINK_TYPE flags
*
* Return the next link against an entity matching a specific link type. This
* allows iteration through an entity's links whilst guaranteeing all of the
* returned links are of the given type.
*/
struct media_link *__media_entity_next_link(struct media_entity *entity,
struct media_link *link,
unsigned long link_type);
/**
* for_each_media_entity_data_link() - Iterate through an entity's data links
*
* @entity: pointer to the &media_entity
* @link: pointer to a &media_link to hold the iterated values
*
* Iterate over a &media_entity's data links
*/
#define for_each_media_entity_data_link(entity, link) \
for (link = __media_entity_next_link(entity, NULL, \
MEDIA_LNK_FL_DATA_LINK); \
link; \
link = __media_entity_next_link(entity, link, \
MEDIA_LNK_FL_DATA_LINK))
[media] media: Entities, pads and links As video hardware pipelines become increasingly complex and configurable, the current hardware description through v4l2 subdevices reaches its limits. In addition to enumerating and configuring subdevices, video camera drivers need a way to discover and modify at runtime how those subdevices are connected. This is done through new elements called entities, pads and links. 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. Links are stored in the source entity. To make backwards graph walk faster, a copy of all links is also stored in the sink entity. The copy is known as a backlink and is only used to help graph traversal. The entity API is made of three functions: - media_entity_init() initializes an entity. The caller must provide an array of pads as well as an estimated number of links. The links array is allocated dynamically and will be reallocated if it grows beyond the initial estimate. - media_entity_cleanup() frees resources allocated for an entity. It must be called during the cleanup phase after unregistering the entity and before freeing it. - media_entity_create_link() creates a link between two entities. An entry in the link array of each entity is allocated and stores pointers to source and sink pads. When a media device is unregistered, all its entities are unregistered automatically. The code is based on Hans Verkuil <hverkuil@xs4all.nl> initial work. Signed-off-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Signed-off-by: Sakari Ailus <sakari.ailus@iki.fi> Acked-by: Hans Verkuil <hverkuil@xs4all.nl> Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
2009-12-09 11:40:00 +00:00
#endif