2009-12-09 19:40:00 +08:00
|
|
|
/*
|
|
|
|
* Media entity
|
|
|
|
*
|
|
|
|
* Copyright (C) 2010 Nokia Corporation
|
|
|
|
*
|
|
|
|
* Contacts: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
|
|
|
|
* Sakari Ailus <sakari.ailus@iki.fi>
|
|
|
|
*
|
|
|
|
* This program is free software; you can redistribute it and/or modify
|
|
|
|
* it under the terms of the GNU General Public License version 2 as
|
|
|
|
* published by the Free Software Foundation.
|
|
|
|
*
|
|
|
|
* This program is distributed in the hope that it will be useful,
|
|
|
|
* but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
|
|
|
|
* GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
|
|
|
* along with this program; if not, write to the Free Software
|
|
|
|
* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
|
|
|
|
*/
|
|
|
|
|
2013-06-07 23:45:11 +08:00
|
|
|
#include <linux/bitmap.h>
|
2009-12-09 19:40:00 +08:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <media/media-entity.h>
|
2010-03-08 02:04:59 +08:00
|
|
|
#include <media/media-device.h>
|
2009-12-09 19:40:00 +08:00
|
|
|
|
2015-08-14 01:42:42 +08:00
|
|
|
/**
|
|
|
|
* dev_dbg_obj - Prints in debug mode a change on some object
|
|
|
|
*
|
|
|
|
* @event_name: Name of the event to report. Could be __func__
|
|
|
|
* @gobj: Pointer to the object
|
|
|
|
*
|
|
|
|
* Enabled only if DEBUG or CONFIG_DYNAMIC_DEBUG. Otherwise, it
|
|
|
|
* won't produce any code.
|
|
|
|
*/
|
|
|
|
static inline const char *gobj_type(enum media_gobj_type type)
|
|
|
|
{
|
|
|
|
switch (type) {
|
|
|
|
case MEDIA_GRAPH_ENTITY:
|
|
|
|
return "entity";
|
|
|
|
case MEDIA_GRAPH_PAD:
|
|
|
|
return "pad";
|
|
|
|
case MEDIA_GRAPH_LINK:
|
|
|
|
return "link";
|
2015-08-20 20:07:34 +08:00
|
|
|
case MEDIA_GRAPH_INTF_DEVNODE:
|
|
|
|
return "intf-devnode";
|
2015-08-14 01:42:42 +08:00
|
|
|
default:
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-20 20:07:34 +08:00
|
|
|
static inline const char *intf_type(struct media_interface *intf)
|
|
|
|
{
|
|
|
|
switch (intf->type) {
|
|
|
|
case MEDIA_INTF_T_DVB_FE:
|
|
|
|
return "frontend";
|
|
|
|
case MEDIA_INTF_T_DVB_DEMUX:
|
|
|
|
return "demux";
|
|
|
|
case MEDIA_INTF_T_DVB_DVR:
|
|
|
|
return "DVR";
|
|
|
|
case MEDIA_INTF_T_DVB_CA:
|
|
|
|
return "CA";
|
|
|
|
case MEDIA_INTF_T_DVB_NET:
|
|
|
|
return "dvbnet";
|
|
|
|
case MEDIA_INTF_T_V4L_VIDEO:
|
|
|
|
return "video";
|
|
|
|
case MEDIA_INTF_T_V4L_VBI:
|
|
|
|
return "vbi";
|
|
|
|
case MEDIA_INTF_T_V4L_RADIO:
|
|
|
|
return "radio";
|
|
|
|
case MEDIA_INTF_T_V4L_SUBDEV:
|
|
|
|
return "v4l2-subdev";
|
|
|
|
case MEDIA_INTF_T_V4L_SWRADIO:
|
|
|
|
return "swradio";
|
|
|
|
default:
|
|
|
|
return "unknown-intf";
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2015-08-14 01:42:42 +08:00
|
|
|
static void dev_dbg_obj(const char *event_name, struct media_gobj *gobj)
|
|
|
|
{
|
|
|
|
#if defined(DEBUG) || defined (CONFIG_DYNAMIC_DEBUG)
|
|
|
|
switch (media_type(gobj)) {
|
|
|
|
case MEDIA_GRAPH_ENTITY:
|
|
|
|
dev_dbg(gobj->mdev->dev,
|
|
|
|
"%s: id 0x%08x entity#%d: '%s'\n",
|
|
|
|
event_name, gobj->id, media_localid(gobj),
|
|
|
|
gobj_to_entity(gobj)->name);
|
|
|
|
break;
|
|
|
|
case MEDIA_GRAPH_LINK:
|
|
|
|
{
|
|
|
|
struct media_link *link = gobj_to_link(gobj);
|
|
|
|
|
|
|
|
dev_dbg(gobj->mdev->dev,
|
2015-08-21 19:45:34 +08:00
|
|
|
"%s: id 0x%08x link#%d: %s#%d ==> %s#%d\n",
|
2015-08-14 01:42:42 +08:00
|
|
|
event_name, gobj->id, media_localid(gobj),
|
|
|
|
|
2015-08-21 19:45:34 +08:00
|
|
|
gobj_type(media_type(link->gobj0)),
|
|
|
|
media_localid(link->gobj0),
|
2015-08-14 01:42:42 +08:00
|
|
|
|
2015-08-21 19:45:34 +08:00
|
|
|
gobj_type(media_type(link->gobj1)),
|
|
|
|
media_localid(link->gobj1));
|
2015-08-14 01:42:42 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MEDIA_GRAPH_PAD:
|
|
|
|
{
|
|
|
|
struct media_pad *pad = gobj_to_pad(gobj);
|
|
|
|
|
|
|
|
dev_dbg(gobj->mdev->dev,
|
2015-08-22 05:26:42 +08:00
|
|
|
"%s: id 0x%08x %s%spad#%d: '%s':%d\n",
|
|
|
|
event_name, gobj->id,
|
|
|
|
pad->flags & MEDIA_PAD_FL_SINK ? " sink " : "",
|
|
|
|
pad->flags & MEDIA_PAD_FL_SOURCE ? "source " : "",
|
|
|
|
media_localid(gobj),
|
2015-08-14 01:42:42 +08:00
|
|
|
pad->entity->name, pad->index);
|
2015-08-20 20:07:34 +08:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MEDIA_GRAPH_INTF_DEVNODE:
|
|
|
|
{
|
|
|
|
struct media_interface *intf = gobj_to_intf(gobj);
|
|
|
|
struct media_intf_devnode *devnode = intf_to_devnode(intf);
|
|
|
|
|
|
|
|
dev_dbg(gobj->mdev->dev,
|
|
|
|
"%s: id 0x%08x intf_devnode#%d: %s - major: %d, minor: %d\n",
|
|
|
|
event_name, gobj->id, media_localid(gobj),
|
|
|
|
intf_type(intf),
|
|
|
|
devnode->major, devnode->minor);
|
|
|
|
break;
|
2015-08-14 01:42:42 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2015-08-25 21:28:36 +08:00
|
|
|
/**
|
|
|
|
* media_gobj_init - Initialize a graph object
|
|
|
|
*
|
|
|
|
* @mdev: Pointer to the media_device that contains the object
|
|
|
|
* @type: Type of the object
|
|
|
|
* @gobj: Pointer to the object
|
|
|
|
*
|
|
|
|
* This routine initializes the embedded struct media_gobj inside a
|
|
|
|
* media graph object. It is called automatically if media_*_create()
|
|
|
|
* 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_init(struct media_device *mdev,
|
|
|
|
enum media_gobj_type type,
|
|
|
|
struct media_gobj *gobj)
|
|
|
|
{
|
2015-08-20 07:18:35 +08:00
|
|
|
BUG_ON(!mdev);
|
|
|
|
|
2015-08-14 01:42:42 +08:00
|
|
|
gobj->mdev = mdev;
|
|
|
|
|
2015-08-14 23:47:48 +08:00
|
|
|
/* Create a per-type unique object ID */
|
|
|
|
switch (type) {
|
|
|
|
case MEDIA_GRAPH_ENTITY:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->entity_id);
|
2015-08-23 18:51:33 +08:00
|
|
|
list_add_tail(&gobj->list, &mdev->entities);
|
2015-08-14 23:47:48 +08:00
|
|
|
break;
|
2015-08-14 23:50:08 +08:00
|
|
|
case MEDIA_GRAPH_PAD:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->pad_id);
|
2015-08-23 19:00:33 +08:00
|
|
|
list_add_tail(&gobj->list, &mdev->pads);
|
2015-08-14 23:50:08 +08:00
|
|
|
break;
|
2015-08-14 23:54:36 +08:00
|
|
|
case MEDIA_GRAPH_LINK:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->link_id);
|
2015-08-23 19:00:33 +08:00
|
|
|
list_add_tail(&gobj->list, &mdev->links);
|
2015-08-14 23:54:36 +08:00
|
|
|
break;
|
2015-08-20 20:07:34 +08:00
|
|
|
case MEDIA_GRAPH_INTF_DEVNODE:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->intf_devnode_id);
|
2015-08-23 19:00:33 +08:00
|
|
|
list_add_tail(&gobj->list, &mdev->interfaces);
|
2015-08-20 20:07:34 +08:00
|
|
|
break;
|
2015-08-14 23:47:48 +08:00
|
|
|
}
|
2015-08-23 20:40:26 +08:00
|
|
|
|
|
|
|
mdev->topology_version++;
|
|
|
|
|
2015-08-14 01:42:42 +08:00
|
|
|
dev_dbg_obj(__func__, gobj);
|
2015-08-25 21:28:36 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* media_gobj_remove - Stop using a graph object on a media device
|
|
|
|
*
|
|
|
|
* @graph_obj: Pointer to the object
|
|
|
|
*
|
|
|
|
* This should be called at media_device_unregister_*() routines
|
|
|
|
*/
|
|
|
|
void media_gobj_remove(struct media_gobj *gobj)
|
|
|
|
{
|
2015-08-14 01:42:42 +08:00
|
|
|
dev_dbg_obj(__func__, gobj);
|
2015-08-23 19:00:33 +08:00
|
|
|
|
2015-08-23 20:40:26 +08:00
|
|
|
gobj->mdev->topology_version++;
|
|
|
|
|
2015-08-23 19:00:33 +08:00
|
|
|
/* Remove the object from mdev list */
|
|
|
|
list_del(&gobj->list);
|
2015-08-25 21:28:36 +08:00
|
|
|
}
|
|
|
|
|
2009-12-09 19:40:00 +08:00
|
|
|
/**
|
|
|
|
* media_entity_init - Initialize a media entity
|
|
|
|
*
|
|
|
|
* @num_pads: Total number of sink and source pads.
|
|
|
|
* @pads: Array of 'num_pads' pads.
|
|
|
|
*
|
|
|
|
* The total number of pads is an intrinsic property of entities known by the
|
|
|
|
* entity driver, while the total number of links depends on hardware design
|
|
|
|
* and is an extrinsic property unknown to the entity driver. However, in most
|
2015-08-06 20:25:57 +08:00
|
|
|
* use cases the number of links can safely be assumed to be equal to or
|
|
|
|
* larger than the number of pads.
|
2009-12-09 19:40:00 +08:00
|
|
|
*
|
2015-08-06 20:25:57 +08:00
|
|
|
* For those reasons the links array can be preallocated based on the number
|
|
|
|
* of pads and will be reallocated later if extra links need to be created.
|
2009-12-09 19:40:00 +08:00
|
|
|
*
|
|
|
|
* This function allocates a links array with enough space to hold at least
|
2015-08-06 20:25:57 +08:00
|
|
|
* 'num_pads' elements. The media_entity::max_links field will be set to the
|
|
|
|
* number of allocated elements.
|
2009-12-09 19:40:00 +08:00
|
|
|
*
|
|
|
|
* The pads array is managed by the entity driver and passed to
|
|
|
|
* media_entity_init() where its pointer will be stored in the entity structure.
|
|
|
|
*/
|
|
|
|
int
|
|
|
|
media_entity_init(struct media_entity *entity, u16 num_pads,
|
2015-08-06 20:25:57 +08:00
|
|
|
struct media_pad *pads)
|
2009-12-09 19:40:00 +08:00
|
|
|
{
|
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
entity->group_id = 0;
|
|
|
|
entity->num_links = 0;
|
|
|
|
entity->num_backlinks = 0;
|
|
|
|
entity->num_pads = num_pads;
|
|
|
|
entity->pads = pads;
|
|
|
|
|
|
|
|
for (i = 0; i < num_pads; i++) {
|
|
|
|
pads[i].entity = entity;
|
|
|
|
pads[i].index = i;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_init);
|
|
|
|
|
|
|
|
void
|
|
|
|
media_entity_cleanup(struct media_entity *entity)
|
|
|
|
{
|
[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 17:55:40 +08:00
|
|
|
struct media_link *link, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(link, tmp, &entity->links, list) {
|
|
|
|
media_gobj_remove(&link->graph_obj);
|
|
|
|
list_del(&link->list);
|
|
|
|
kfree(link);
|
|
|
|
}
|
2009-12-09 19:40:00 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_cleanup);
|
|
|
|
|
2010-03-08 03:14:14 +08:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Graph traversal
|
|
|
|
*/
|
|
|
|
|
|
|
|
static struct media_entity *
|
|
|
|
media_entity_other(struct media_entity *entity, struct media_link *link)
|
|
|
|
{
|
|
|
|
if (link->source->entity == entity)
|
|
|
|
return link->sink->entity;
|
|
|
|
else
|
|
|
|
return link->source->entity;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* push an entity to traversal stack */
|
|
|
|
static void stack_push(struct media_entity_graph *graph,
|
|
|
|
struct media_entity *entity)
|
|
|
|
{
|
|
|
|
if (graph->top == MEDIA_ENTITY_ENUM_MAX_DEPTH - 1) {
|
|
|
|
WARN_ON(1);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
graph->top++;
|
[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 17:55:40 +08:00
|
|
|
graph->stack[graph->top].link = (&entity->links)->next;
|
2010-03-08 03:14:14 +08:00
|
|
|
graph->stack[graph->top].entity = entity;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct media_entity *stack_pop(struct media_entity_graph *graph)
|
|
|
|
{
|
|
|
|
struct media_entity *entity;
|
|
|
|
|
|
|
|
entity = graph->stack[graph->top].entity;
|
|
|
|
graph->top--;
|
|
|
|
|
|
|
|
return entity;
|
|
|
|
}
|
|
|
|
|
|
|
|
#define link_top(en) ((en)->stack[(en)->top].link)
|
|
|
|
#define stack_top(en) ((en)->stack[(en)->top].entity)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* media_entity_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 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. When done the structure can
|
|
|
|
* safely be freed.
|
|
|
|
*/
|
|
|
|
void media_entity_graph_walk_start(struct media_entity_graph *graph,
|
|
|
|
struct media_entity *entity)
|
|
|
|
{
|
|
|
|
graph->top = 0;
|
|
|
|
graph->stack[graph->top].entity = NULL;
|
2013-06-07 23:45:11 +08:00
|
|
|
bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID);
|
|
|
|
|
2015-08-14 21:42:05 +08:00
|
|
|
if (WARN_ON(media_entity_id(entity) >= MEDIA_ENTITY_ENUM_MAX_ID))
|
2013-06-07 23:45:11 +08:00
|
|
|
return;
|
|
|
|
|
2015-08-14 21:42:05 +08:00
|
|
|
__set_bit(media_entity_id(entity), graph->entities);
|
2010-03-08 03:14:14 +08:00
|
|
|
stack_push(graph, entity);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
|
|
|
|
|
[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 17:55:40 +08:00
|
|
|
|
2010-03-08 03:14:14 +08:00
|
|
|
/**
|
|
|
|
* media_entity_graph_walk_next - Get the next entity in the graph
|
|
|
|
* @graph: Media graph structure
|
|
|
|
*
|
|
|
|
* Perform a depth-first traversal of the given media entities graph.
|
|
|
|
*
|
|
|
|
* The graph structure must have been previously initialized with a call to
|
|
|
|
* media_entity_graph_walk_start().
|
|
|
|
*
|
|
|
|
* Return the next entity in the graph or NULL if the whole graph have been
|
|
|
|
* traversed.
|
|
|
|
*/
|
|
|
|
struct media_entity *
|
|
|
|
media_entity_graph_walk_next(struct media_entity_graph *graph)
|
|
|
|
{
|
|
|
|
if (stack_top(graph) == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Depth first search. Push entity to stack and continue from
|
|
|
|
* top of the stack until no more entities on the level can be
|
|
|
|
* found.
|
|
|
|
*/
|
[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 17:55:40 +08:00
|
|
|
while (link_top(graph) != &(stack_top(graph)->links)) {
|
2010-03-08 03:14:14 +08:00
|
|
|
struct media_entity *entity = stack_top(graph);
|
[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 17:55:40 +08:00
|
|
|
struct media_link *link;
|
2010-03-08 03:14:14 +08:00
|
|
|
struct media_entity *next;
|
|
|
|
|
[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 17:55:40 +08:00
|
|
|
link = list_entry(link_top(graph), typeof(*link), list);
|
|
|
|
|
2010-03-08 03:14:14 +08:00
|
|
|
/* The link is not enabled so we do not follow. */
|
|
|
|
if (!(link->flags & MEDIA_LNK_FL_ENABLED)) {
|
[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 17:55:40 +08:00
|
|
|
link_top(graph) = link_top(graph)->next;
|
2010-03-08 03:14:14 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get the entity in the other end of the link . */
|
|
|
|
next = media_entity_other(entity, link);
|
2015-08-14 21:42:05 +08:00
|
|
|
if (WARN_ON(media_entity_id(next) >= MEDIA_ENTITY_ENUM_MAX_ID))
|
2013-06-07 23:45:11 +08:00
|
|
|
return NULL;
|
2010-03-08 03:14:14 +08:00
|
|
|
|
2013-06-07 23:45:11 +08:00
|
|
|
/* Has the entity already been visited? */
|
2015-08-14 21:42:05 +08:00
|
|
|
if (__test_and_set_bit(media_entity_id(next), graph->entities)) {
|
[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 17:55:40 +08:00
|
|
|
link_top(graph) = link_top(graph)->next;
|
2010-03-08 03:14:14 +08:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Push the new entity to stack and start over. */
|
[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 17:55:40 +08:00
|
|
|
link_top(graph) = link_top(graph)->next;
|
2010-03-08 03:14:14 +08:00
|
|
|
stack_push(graph, next);
|
|
|
|
}
|
|
|
|
|
|
|
|
return stack_pop(graph);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
|
|
|
|
|
2010-08-25 20:00:41 +08:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Pipeline management
|
|
|
|
*/
|
|
|
|
|
|
|
|
/**
|
|
|
|
* media_entity_pipeline_start - Mark a pipeline as streaming
|
|
|
|
* @entity: Starting entity
|
|
|
|
* @pipe: Media pipeline to be assigned to all entities in the pipeline.
|
|
|
|
*
|
|
|
|
* Mark all entities connected to a given entity through enabled links, either
|
|
|
|
* directly or indirectly, as streaming. The given pipeline object is assigned to
|
|
|
|
* every entity in the pipeline and stored in the media_entity pipe field.
|
|
|
|
*
|
|
|
|
* Calls to this function can be nested, in which case the same number of
|
|
|
|
* media_entity_pipeline_stop() calls will be required to stop streaming. The
|
|
|
|
* pipeline pointer must be identical for all nested calls to
|
|
|
|
* media_entity_pipeline_start().
|
|
|
|
*/
|
2012-01-11 17:25:15 +08:00
|
|
|
__must_check int media_entity_pipeline_start(struct media_entity *entity,
|
|
|
|
struct media_pipeline *pipe)
|
2010-08-25 20:00:41 +08:00
|
|
|
{
|
2015-08-19 23:35:21 +08:00
|
|
|
struct media_device *mdev = entity->graph_obj.mdev;
|
2010-08-25 20:00:41 +08:00
|
|
|
struct media_entity_graph graph;
|
2012-01-11 17:25:15 +08:00
|
|
|
struct media_entity *entity_err = entity;
|
[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 17:55:40 +08:00
|
|
|
struct media_link *link;
|
2012-01-11 17:25:15 +08:00
|
|
|
int ret;
|
2010-08-25 20:00:41 +08:00
|
|
|
|
|
|
|
mutex_lock(&mdev->graph_mutex);
|
|
|
|
|
|
|
|
media_entity_graph_walk_start(&graph, entity);
|
|
|
|
|
|
|
|
while ((entity = media_entity_graph_walk_next(&graph))) {
|
2015-10-02 05:07:53 +08:00
|
|
|
DECLARE_BITMAP(active, MEDIA_ENTITY_MAX_PADS);
|
|
|
|
DECLARE_BITMAP(has_no_links, MEDIA_ENTITY_MAX_PADS);
|
2012-01-11 17:25:15 +08:00
|
|
|
|
2010-08-25 20:00:41 +08:00
|
|
|
entity->stream_count++;
|
|
|
|
WARN_ON(entity->pipe && entity->pipe != pipe);
|
|
|
|
entity->pipe = pipe;
|
2012-01-11 17:25:15 +08:00
|
|
|
|
|
|
|
/* Already streaming --- no need to check. */
|
|
|
|
if (entity->stream_count > 1)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!entity->ops || !entity->ops->link_validate)
|
|
|
|
continue;
|
|
|
|
|
2013-10-13 19:00:26 +08:00
|
|
|
bitmap_zero(active, entity->num_pads);
|
|
|
|
bitmap_fill(has_no_links, entity->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 17:55:40 +08:00
|
|
|
list_for_each_entry(link, &entity->links, list) {
|
2013-10-13 19:00:26 +08:00
|
|
|
struct media_pad *pad = link->sink->entity == entity
|
|
|
|
? link->sink : link->source;
|
|
|
|
|
|
|
|
/* Mark that a pad is connected by a link. */
|
|
|
|
bitmap_clear(has_no_links, pad->index, 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Pads that either do not need to connect or
|
|
|
|
* are connected through an enabled link are
|
|
|
|
* fine.
|
|
|
|
*/
|
|
|
|
if (!(pad->flags & MEDIA_PAD_FL_MUST_CONNECT) ||
|
|
|
|
link->flags & MEDIA_LNK_FL_ENABLED)
|
|
|
|
bitmap_set(active, pad->index, 1);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Link validation will only take place for
|
|
|
|
* sink ends of the link that are enabled.
|
|
|
|
*/
|
|
|
|
if (link->sink != pad ||
|
|
|
|
!(link->flags & MEDIA_LNK_FL_ENABLED))
|
2012-01-11 17:25:15 +08:00
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = entity->ops->link_validate(link);
|
2014-10-29 07:35:04 +08:00
|
|
|
if (ret < 0 && ret != -ENOIOCTLCMD) {
|
2015-08-19 23:35:21 +08:00
|
|
|
dev_dbg(entity->graph_obj.mdev->dev,
|
2014-10-29 07:35:04 +08:00
|
|
|
"link validation failed for \"%s\":%u -> \"%s\":%u, error %d\n",
|
2015-02-12 21:43:11 +08:00
|
|
|
link->source->entity->name,
|
|
|
|
link->source->index,
|
|
|
|
entity->name, link->sink->index, ret);
|
2012-01-11 17:25:15 +08:00
|
|
|
goto error;
|
2014-10-29 07:35:04 +08:00
|
|
|
}
|
2012-01-11 17:25:15 +08:00
|
|
|
}
|
2013-10-13 19:00:26 +08:00
|
|
|
|
|
|
|
/* Either no links or validated links are fine. */
|
|
|
|
bitmap_or(active, active, has_no_links, entity->num_pads);
|
|
|
|
|
|
|
|
if (!bitmap_full(active, entity->num_pads)) {
|
|
|
|
ret = -EPIPE;
|
2015-08-19 23:35:21 +08:00
|
|
|
dev_dbg(entity->graph_obj.mdev->dev,
|
2014-10-29 07:35:04 +08:00
|
|
|
"\"%s\":%u must be connected by an enabled link\n",
|
|
|
|
entity->name,
|
2014-11-04 04:55:51 +08:00
|
|
|
(unsigned)find_first_zero_bit(
|
|
|
|
active, entity->num_pads));
|
2013-10-13 19:00:26 +08:00
|
|
|
goto error;
|
|
|
|
}
|
2010-08-25 20:00:41 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&mdev->graph_mutex);
|
2012-01-11 17:25:15 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
error:
|
|
|
|
/*
|
|
|
|
* Link validation on graph failed. We revert what we did and
|
|
|
|
* return the error.
|
|
|
|
*/
|
|
|
|
media_entity_graph_walk_start(&graph, entity_err);
|
|
|
|
|
|
|
|
while ((entity_err = media_entity_graph_walk_next(&graph))) {
|
|
|
|
entity_err->stream_count--;
|
|
|
|
if (entity_err->stream_count == 0)
|
|
|
|
entity_err->pipe = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We haven't increased stream_count further than this
|
|
|
|
* so we quit here.
|
|
|
|
*/
|
|
|
|
if (entity_err == entity)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&mdev->graph_mutex);
|
|
|
|
|
|
|
|
return ret;
|
2010-08-25 20:00:41 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_pipeline_start);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* media_entity_pipeline_stop - Mark a pipeline as not streaming
|
|
|
|
* @entity: Starting entity
|
|
|
|
*
|
|
|
|
* Mark all entities connected to a given entity through enabled links, either
|
|
|
|
* directly or indirectly, as not streaming. The media_entity pipe field is
|
|
|
|
* reset to NULL.
|
|
|
|
*
|
|
|
|
* If multiple calls to media_entity_pipeline_start() have been made, the same
|
|
|
|
* number of calls to this function are required to mark the pipeline as not
|
|
|
|
* streaming.
|
|
|
|
*/
|
|
|
|
void media_entity_pipeline_stop(struct media_entity *entity)
|
|
|
|
{
|
2015-08-19 23:35:21 +08:00
|
|
|
struct media_device *mdev = entity->graph_obj.mdev;
|
2010-08-25 20:00:41 +08:00
|
|
|
struct media_entity_graph graph;
|
|
|
|
|
|
|
|
mutex_lock(&mdev->graph_mutex);
|
|
|
|
|
|
|
|
media_entity_graph_walk_start(&graph, entity);
|
|
|
|
|
|
|
|
while ((entity = media_entity_graph_walk_next(&graph))) {
|
|
|
|
entity->stream_count--;
|
|
|
|
if (entity->stream_count == 0)
|
|
|
|
entity->pipe = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&mdev->graph_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_pipeline_stop);
|
|
|
|
|
2010-03-08 02:04:59 +08:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Module use count
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* media_entity_get - Get a reference to the parent module
|
|
|
|
* @entity: The entity
|
|
|
|
*
|
|
|
|
* Get a reference to the parent media device module.
|
|
|
|
*
|
|
|
|
* The function will return immediately if @entity is NULL.
|
|
|
|
*
|
|
|
|
* Return a pointer to the entity on success or NULL on failure.
|
|
|
|
*/
|
|
|
|
struct media_entity *media_entity_get(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
if (entity == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2015-08-19 23:35:21 +08:00
|
|
|
if (entity->graph_obj.mdev->dev &&
|
|
|
|
!try_module_get(entity->graph_obj.mdev->dev->driver->owner))
|
2010-03-08 02:04:59 +08:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return entity;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_get);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* media_entity_put - Release the reference to the parent module
|
|
|
|
* @entity: The entity
|
|
|
|
*
|
|
|
|
* Release the reference count acquired by media_entity_get().
|
|
|
|
*
|
|
|
|
* The function will return immediately if @entity is NULL.
|
|
|
|
*/
|
|
|
|
void media_entity_put(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
if (entity == NULL)
|
|
|
|
return;
|
|
|
|
|
2015-08-19 23:35:21 +08:00
|
|
|
if (entity->graph_obj.mdev->dev)
|
|
|
|
module_put(entity->graph_obj.mdev->dev->driver->owner);
|
2010-03-08 02:04:59 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_put);
|
|
|
|
|
2010-03-08 03:14:14 +08:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Links management
|
|
|
|
*/
|
|
|
|
|
2015-08-20 19:21:35 +08:00
|
|
|
static struct media_link *media_add_link(struct list_head *head)
|
2009-12-09 19:40:00 +08:00
|
|
|
{
|
[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 17:55:40 +08:00
|
|
|
struct media_link *link;
|
2009-12-09 19:40:00 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
link = kzalloc(sizeof(*link), GFP_KERNEL);
|
|
|
|
if (link == NULL)
|
|
|
|
return NULL;
|
2009-12-09 19:40:00 +08:00
|
|
|
|
2015-08-20 19:21:35 +08:00
|
|
|
list_add_tail(&link->list, head);
|
2009-12-09 19:40:00 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
return link;
|
2009-12-09 19:40:00 +08:00
|
|
|
}
|
|
|
|
|
[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 17:55:40 +08:00
|
|
|
static void __media_entity_remove_link(struct media_entity *entity,
|
|
|
|
struct media_link *link);
|
|
|
|
|
2009-12-09 19:40:00 +08:00
|
|
|
int
|
2015-08-07 19:14:38 +08:00
|
|
|
media_create_pad_link(struct media_entity *source, u16 source_pad,
|
2009-12-09 19:40:00 +08:00
|
|
|
struct media_entity *sink, u16 sink_pad, u32 flags)
|
|
|
|
{
|
|
|
|
struct media_link *link;
|
|
|
|
struct media_link *backlink;
|
|
|
|
|
|
|
|
BUG_ON(source == NULL || sink == NULL);
|
|
|
|
BUG_ON(source_pad >= source->num_pads);
|
|
|
|
BUG_ON(sink_pad >= sink->num_pads);
|
|
|
|
|
2015-08-20 19:21:35 +08:00
|
|
|
link = media_add_link(&source->links);
|
2009-12-09 19:40:00 +08:00
|
|
|
if (link == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
link->source = &source->pads[source_pad];
|
|
|
|
link->sink = &sink->pads[sink_pad];
|
|
|
|
link->flags = flags;
|
|
|
|
|
2015-08-14 23:54:36 +08:00
|
|
|
/* Initialize graph object embedded at the new link */
|
2015-08-19 23:35:21 +08:00
|
|
|
media_gobj_init(source->graph_obj.mdev, MEDIA_GRAPH_LINK,
|
|
|
|
&link->graph_obj);
|
2015-08-14 23:54:36 +08:00
|
|
|
|
2009-12-09 19:40:00 +08:00
|
|
|
/* Create the backlink. Backlinks are used to help graph traversal and
|
|
|
|
* are not reported to userspace.
|
|
|
|
*/
|
2015-08-20 19:21:35 +08:00
|
|
|
backlink = media_add_link(&sink->links);
|
2009-12-09 19:40:00 +08:00
|
|
|
if (backlink == NULL) {
|
[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 17:55:40 +08:00
|
|
|
__media_entity_remove_link(source, link);
|
2009-12-09 19:40:00 +08:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
backlink->source = &source->pads[source_pad];
|
|
|
|
backlink->sink = &sink->pads[sink_pad];
|
|
|
|
backlink->flags = flags;
|
|
|
|
|
2015-08-14 23:54:36 +08:00
|
|
|
/* Initialize graph object embedded at the new link */
|
2015-08-19 23:35:21 +08:00
|
|
|
media_gobj_init(sink->graph_obj.mdev, MEDIA_GRAPH_LINK,
|
|
|
|
&backlink->graph_obj);
|
2015-08-14 23:54:36 +08:00
|
|
|
|
2009-12-09 19:40:00 +08:00
|
|
|
link->reverse = backlink;
|
|
|
|
backlink->reverse = link;
|
|
|
|
|
|
|
|
sink->num_backlinks++;
|
[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 17:55:40 +08:00
|
|
|
sink->num_links++;
|
|
|
|
source->num_links++;
|
2009-12-09 19:40:00 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2015-08-07 19:14:38 +08:00
|
|
|
EXPORT_SYMBOL_GPL(media_create_pad_link);
|
2009-12-09 19:40:03 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
static void __media_entity_remove_link(struct media_entity *entity,
|
|
|
|
struct media_link *link)
|
2013-05-09 19:29:32 +08:00
|
|
|
{
|
[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 17:55:40 +08:00
|
|
|
struct media_link *rlink, *tmp;
|
|
|
|
struct media_entity *remote;
|
|
|
|
unsigned int r = 0;
|
|
|
|
|
|
|
|
if (link->source->entity == entity)
|
|
|
|
remote = link->sink->entity;
|
|
|
|
else
|
|
|
|
remote = link->source->entity;
|
2013-05-09 19:29:32 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
list_for_each_entry_safe(rlink, tmp, &remote->links, list) {
|
|
|
|
if (rlink != link->reverse) {
|
|
|
|
r++;
|
|
|
|
continue;
|
|
|
|
}
|
2013-05-09 19:29:32 +08:00
|
|
|
|
|
|
|
if (link->source->entity == entity)
|
[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 17:55:40 +08:00
|
|
|
remote->num_backlinks--;
|
2013-05-09 19:29:32 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
if (--remote->num_links == 0)
|
|
|
|
break;
|
2013-05-09 19:29:32 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
/* Remove the remote link */
|
|
|
|
list_del(&rlink->list);
|
|
|
|
kfree(rlink);
|
|
|
|
}
|
|
|
|
list_del(&link->list);
|
|
|
|
kfree(link);
|
|
|
|
}
|
2013-05-09 19:29:32 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
void __media_entity_remove_links(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
struct media_link *link, *tmp;
|
2013-05-09 19:29:32 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
list_for_each_entry_safe(link, tmp, &entity->links, list)
|
|
|
|
__media_entity_remove_link(entity, link);
|
2013-05-09 19:29:32 +08:00
|
|
|
|
|
|
|
entity->num_links = 0;
|
|
|
|
entity->num_backlinks = 0;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__media_entity_remove_links);
|
|
|
|
|
|
|
|
void media_entity_remove_links(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
/* Do nothing if the entity is not registered. */
|
2015-08-19 23:35:21 +08:00
|
|
|
if (entity->graph_obj.mdev == NULL)
|
2013-05-09 19:29:32 +08:00
|
|
|
return;
|
|
|
|
|
2015-08-19 23:35:21 +08:00
|
|
|
mutex_lock(&entity->graph_obj.mdev->graph_mutex);
|
2013-05-09 19:29:32 +08:00
|
|
|
__media_entity_remove_links(entity);
|
2015-08-19 23:35:21 +08:00
|
|
|
mutex_unlock(&entity->graph_obj.mdev->graph_mutex);
|
2013-05-09 19:29:32 +08:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_remove_links);
|
|
|
|
|
2009-12-09 19:40:03 +08:00
|
|
|
static int __media_entity_setup_link_notify(struct media_link *link, u32 flags)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
/* Notify both entities. */
|
|
|
|
ret = media_entity_call(link->source->entity, link_setup,
|
|
|
|
link->source, link->sink, flags);
|
|
|
|
if (ret < 0 && ret != -ENOIOCTLCMD)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = media_entity_call(link->sink->entity, link_setup,
|
|
|
|
link->sink, link->source, flags);
|
|
|
|
if (ret < 0 && ret != -ENOIOCTLCMD) {
|
|
|
|
media_entity_call(link->source->entity, link_setup,
|
|
|
|
link->source, link->sink, link->flags);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2011-03-11 22:34:35 +08:00
|
|
|
link->flags = flags;
|
2009-12-09 19:40:03 +08:00
|
|
|
link->reverse->flags = link->flags;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* __media_entity_setup_link - Configure a media link
|
|
|
|
* @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)
|
|
|
|
{
|
2011-03-11 22:34:35 +08:00
|
|
|
const u32 mask = MEDIA_LNK_FL_ENABLED;
|
2009-12-09 19:40:03 +08:00
|
|
|
struct media_device *mdev;
|
|
|
|
struct media_entity *source, *sink;
|
|
|
|
int ret = -EBUSY;
|
|
|
|
|
|
|
|
if (link == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2011-03-11 22:34:35 +08:00
|
|
|
/* The non-modifiable link flags must not be modified. */
|
|
|
|
if ((link->flags & ~mask) != (flags & ~mask))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-12-09 19:40:03 +08:00
|
|
|
if (link->flags & MEDIA_LNK_FL_IMMUTABLE)
|
|
|
|
return link->flags == flags ? 0 : -EINVAL;
|
|
|
|
|
|
|
|
if (link->flags == flags)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
source = link->source->entity;
|
|
|
|
sink = link->sink->entity;
|
|
|
|
|
2010-08-25 20:00:41 +08:00
|
|
|
if (!(link->flags & MEDIA_LNK_FL_DYNAMIC) &&
|
|
|
|
(source->stream_count || sink->stream_count))
|
|
|
|
return -EBUSY;
|
|
|
|
|
2015-08-19 23:35:21 +08:00
|
|
|
mdev = source->graph_obj.mdev;
|
2009-12-09 19:40:03 +08:00
|
|
|
|
2013-05-31 21:37:26 +08:00
|
|
|
if (mdev->link_notify) {
|
|
|
|
ret = mdev->link_notify(link, flags,
|
|
|
|
MEDIA_DEV_NOTIFY_PRE_LINK_CH);
|
2009-12-09 19:40:03 +08:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = __media_entity_setup_link_notify(link, flags);
|
|
|
|
|
2013-05-31 21:37:26 +08:00
|
|
|
if (mdev->link_notify)
|
|
|
|
mdev->link_notify(link, flags, MEDIA_DEV_NOTIFY_POST_LINK_CH);
|
2009-12-09 19:40:03 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int media_entity_setup_link(struct media_link *link, u32 flags)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2015-08-19 23:35:21 +08:00
|
|
|
mutex_lock(&link->source->entity->graph_obj.mdev->graph_mutex);
|
2009-12-09 19:40:03 +08:00
|
|
|
ret = __media_entity_setup_link(link, flags);
|
2015-08-19 23:35:21 +08:00
|
|
|
mutex_unlock(&link->source->entity->graph_obj.mdev->graph_mutex);
|
2009-12-09 19:40:03 +08:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_setup_link);
|
|
|
|
|
|
|
|
/**
|
|
|
|
* media_entity_find_link - Find a link between two pads
|
|
|
|
* @source: Source pad
|
|
|
|
* @sink: Sink pad
|
|
|
|
*
|
|
|
|
* Return 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)
|
|
|
|
{
|
|
|
|
struct media_link *link;
|
|
|
|
|
[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 17:55:40 +08:00
|
|
|
list_for_each_entry(link, &source->entity->links, list) {
|
2009-12-09 19:40:03 +08:00
|
|
|
if (link->source->entity == source->entity &&
|
|
|
|
link->source->index == source->index &&
|
|
|
|
link->sink->entity == sink->entity &&
|
|
|
|
link->sink->index == sink->index)
|
|
|
|
return link;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_find_link);
|
|
|
|
|
|
|
|
/**
|
2013-06-03 16:16:13 +08:00
|
|
|
* media_entity_remote_pad - Find the pad at the remote end of a link
|
|
|
|
* @pad: Pad at the local end of the link
|
2009-12-09 19:40:03 +08:00
|
|
|
*
|
2013-06-03 16:16:13 +08:00
|
|
|
* 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.
|
2009-12-09 19:40:03 +08:00
|
|
|
*
|
|
|
|
* Return a pointer to the pad at the remote end of the first found enabled
|
|
|
|
* link, or NULL if no enabled link has been found.
|
|
|
|
*/
|
2013-06-03 16:16:13 +08:00
|
|
|
struct media_pad *media_entity_remote_pad(struct media_pad *pad)
|
2009-12-09 19:40:03 +08:00
|
|
|
{
|
[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 17:55:40 +08:00
|
|
|
struct media_link *link;
|
2009-12-09 19:40:03 +08:00
|
|
|
|
[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 17:55:40 +08:00
|
|
|
list_for_each_entry(link, &pad->entity->links, list) {
|
2009-12-09 19:40:03 +08:00
|
|
|
if (!(link->flags & MEDIA_LNK_FL_ENABLED))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (link->source == pad)
|
|
|
|
return link->sink;
|
|
|
|
|
|
|
|
if (link->sink == pad)
|
|
|
|
return link->source;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
}
|
2013-06-03 16:16:13 +08:00
|
|
|
EXPORT_SYMBOL_GPL(media_entity_remote_pad);
|
2015-08-20 20:07:34 +08:00
|
|
|
|
|
|
|
|
2015-08-29 02:43:36 +08:00
|
|
|
static void media_interface_init(struct media_device *mdev,
|
|
|
|
struct media_interface *intf,
|
|
|
|
u32 gobj_type,
|
|
|
|
u32 intf_type, u32 flags)
|
|
|
|
{
|
|
|
|
intf->type = intf_type;
|
|
|
|
intf->flags = flags;
|
|
|
|
INIT_LIST_HEAD(&intf->links);
|
|
|
|
|
|
|
|
media_gobj_init(mdev, gobj_type, &intf->graph_obj);
|
|
|
|
}
|
|
|
|
|
2015-08-20 20:07:34 +08:00
|
|
|
/* Functions related to the media interface via device nodes */
|
|
|
|
|
|
|
|
struct media_intf_devnode *media_devnode_create(struct media_device *mdev,
|
|
|
|
u32 type, u32 flags,
|
|
|
|
u32 major, u32 minor,
|
|
|
|
gfp_t gfp_flags)
|
|
|
|
{
|
|
|
|
struct media_intf_devnode *devnode;
|
|
|
|
|
|
|
|
devnode = kzalloc(sizeof(*devnode), gfp_flags);
|
|
|
|
if (!devnode)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
devnode->major = major;
|
|
|
|
devnode->minor = minor;
|
|
|
|
|
2015-08-29 02:43:36 +08:00
|
|
|
media_interface_init(mdev, &devnode->intf, MEDIA_GRAPH_INTF_DEVNODE,
|
|
|
|
type, flags);
|
2015-08-20 20:07:34 +08:00
|
|
|
|
|
|
|
return devnode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_devnode_create);
|
|
|
|
|
|
|
|
void media_devnode_remove(struct media_intf_devnode *devnode)
|
|
|
|
{
|
2015-08-24 19:46:46 +08:00
|
|
|
media_remove_intf_links(&devnode->intf);
|
2015-08-20 20:07:34 +08:00
|
|
|
media_gobj_remove(&devnode->intf.graph_obj);
|
|
|
|
kfree(devnode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_devnode_remove);
|
2015-08-07 21:36:25 +08:00
|
|
|
|
|
|
|
struct media_link *media_create_intf_link(struct media_entity *entity,
|
|
|
|
struct media_interface *intf,
|
|
|
|
u32 flags)
|
|
|
|
{
|
|
|
|
struct media_link *link;
|
|
|
|
|
|
|
|
link = media_add_link(&intf->links);
|
|
|
|
if (link == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
link->intf = intf;
|
|
|
|
link->entity = entity;
|
|
|
|
link->flags = flags;
|
|
|
|
|
|
|
|
/* Initialize graph object embedded at the new link */
|
|
|
|
media_gobj_init(intf->graph_obj.mdev, MEDIA_GRAPH_LINK,
|
|
|
|
&link->graph_obj);
|
|
|
|
|
|
|
|
return link;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_create_intf_link);
|
|
|
|
|
|
|
|
|
|
|
|
static void __media_remove_intf_link(struct media_link *link)
|
|
|
|
{
|
|
|
|
media_gobj_remove(&link->graph_obj);
|
|
|
|
kfree(link);
|
|
|
|
}
|
|
|
|
|
|
|
|
void media_remove_intf_link(struct media_link *link)
|
|
|
|
{
|
|
|
|
mutex_lock(&link->graph_obj.mdev->graph_mutex);
|
|
|
|
__media_remove_intf_link(link);
|
|
|
|
mutex_unlock(&link->graph_obj.mdev->graph_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_remove_intf_link);
|
2015-08-24 19:46:46 +08:00
|
|
|
|
|
|
|
void __media_remove_intf_links(struct media_interface *intf)
|
|
|
|
{
|
|
|
|
struct media_link *link, *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(link, tmp, &intf->links, list)
|
|
|
|
__media_remove_intf_link(link);
|
|
|
|
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(__media_remove_intf_links);
|
|
|
|
|
|
|
|
void media_remove_intf_links(struct media_interface *intf)
|
|
|
|
{
|
|
|
|
/* Do nothing if the intf is not registered. */
|
|
|
|
if (intf->graph_obj.mdev == NULL)
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&intf->graph_obj.mdev->graph_mutex);
|
|
|
|
__media_remove_intf_links(intf);
|
|
|
|
mutex_unlock(&intf->graph_obj.mdev->graph_mutex);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_remove_intf_links);
|