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>
|
|
|
|
*
|
|
|
|
* 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 15:45:11 +00:00
|
|
|
#include <linux/bitmap.h>
|
2009-12-09 11:40:00 +00:00
|
|
|
#include <linux/module.h>
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <media/media-entity.h>
|
2010-03-07 18:04:59 +00:00
|
|
|
#include <media/media-device.h>
|
2009-12-09 11:40:00 +00:00
|
|
|
|
2015-08-13 17:42:42 +00:00
|
|
|
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 12:07:34 +00:00
|
|
|
case MEDIA_GRAPH_INTF_DEVNODE:
|
|
|
|
return "intf-devnode";
|
2015-08-13 17:42:42 +00:00
|
|
|
default:
|
|
|
|
return "unknown";
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2015-08-20 12:07:34 +00: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-12-11 14:14:58 +00: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.
|
|
|
|
*/
|
2015-08-13 17:42:42 +00: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 11:45:34 +00:00
|
|
|
"%s: id 0x%08x link#%d: %s#%d ==> %s#%d\n",
|
2015-08-13 17:42:42 +00:00
|
|
|
event_name, gobj->id, media_localid(gobj),
|
|
|
|
|
2015-08-21 11:45:34 +00:00
|
|
|
gobj_type(media_type(link->gobj0)),
|
|
|
|
media_localid(link->gobj0),
|
2015-08-13 17:42:42 +00:00
|
|
|
|
2015-08-21 11:45:34 +00:00
|
|
|
gobj_type(media_type(link->gobj1)),
|
|
|
|
media_localid(link->gobj1));
|
2015-08-13 17:42:42 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
case MEDIA_GRAPH_PAD:
|
|
|
|
{
|
|
|
|
struct media_pad *pad = gobj_to_pad(gobj);
|
|
|
|
|
|
|
|
dev_dbg(gobj->mdev->dev,
|
2015-08-21 21:26:42 +00: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-13 17:42:42 +00:00
|
|
|
pad->entity->name, pad->index);
|
2015-08-20 12:07:34 +00: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-13 17:42:42 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
}
|
|
|
|
|
2015-12-11 13:55:40 +00:00
|
|
|
void media_gobj_create(struct media_device *mdev,
|
2015-08-25 13:28:36 +00:00
|
|
|
enum media_gobj_type type,
|
|
|
|
struct media_gobj *gobj)
|
|
|
|
{
|
2015-08-19 23:18:35 +00:00
|
|
|
BUG_ON(!mdev);
|
|
|
|
|
2015-08-13 17:42:42 +00:00
|
|
|
gobj->mdev = mdev;
|
|
|
|
|
2015-08-14 15:47:48 +00: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 10:51:33 +00:00
|
|
|
list_add_tail(&gobj->list, &mdev->entities);
|
2015-08-14 15:47:48 +00:00
|
|
|
break;
|
2015-08-14 15:50:08 +00:00
|
|
|
case MEDIA_GRAPH_PAD:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->pad_id);
|
2015-08-23 11:00:33 +00:00
|
|
|
list_add_tail(&gobj->list, &mdev->pads);
|
2015-08-14 15:50:08 +00:00
|
|
|
break;
|
2015-08-14 15:54:36 +00:00
|
|
|
case MEDIA_GRAPH_LINK:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->link_id);
|
2015-08-23 11:00:33 +00:00
|
|
|
list_add_tail(&gobj->list, &mdev->links);
|
2015-08-14 15:54:36 +00:00
|
|
|
break;
|
2015-08-20 12:07:34 +00:00
|
|
|
case MEDIA_GRAPH_INTF_DEVNODE:
|
|
|
|
gobj->id = media_gobj_gen_id(type, ++mdev->intf_devnode_id);
|
2015-08-23 11:00:33 +00:00
|
|
|
list_add_tail(&gobj->list, &mdev->interfaces);
|
2015-08-20 12:07:34 +00:00
|
|
|
break;
|
2015-08-14 15:47:48 +00:00
|
|
|
}
|
2015-08-23 12:40:26 +00:00
|
|
|
|
|
|
|
mdev->topology_version++;
|
|
|
|
|
2015-08-13 17:42:42 +00:00
|
|
|
dev_dbg_obj(__func__, gobj);
|
2015-08-25 13:28:36 +00:00
|
|
|
}
|
|
|
|
|
2015-12-11 13:55:40 +00:00
|
|
|
void media_gobj_destroy(struct media_gobj *gobj)
|
2015-08-25 13:28:36 +00:00
|
|
|
{
|
2015-08-13 17:42:42 +00:00
|
|
|
dev_dbg_obj(__func__, gobj);
|
2015-08-23 11:00:33 +00:00
|
|
|
|
2015-08-23 12:40:26 +00:00
|
|
|
gobj->mdev->topology_version++;
|
|
|
|
|
2015-08-23 11:00:33 +00:00
|
|
|
/* Remove the object from mdev list */
|
|
|
|
list_del(&gobj->list);
|
2015-08-25 13:28:36 +00:00
|
|
|
}
|
|
|
|
|
2015-12-11 14:14:58 +00:00
|
|
|
int media_entity_pads_init(struct media_entity *entity, u16 num_pads,
|
|
|
|
struct media_pad *pads)
|
2009-12-09 11:40:00 +00:00
|
|
|
{
|
2015-09-08 17:10:56 +00:00
|
|
|
struct media_device *mdev = entity->graph_obj.mdev;
|
2009-12-09 11:40:00 +00:00
|
|
|
unsigned int i;
|
|
|
|
|
|
|
|
entity->num_pads = num_pads;
|
|
|
|
entity->pads = pads;
|
|
|
|
|
2015-09-08 17:10:56 +00:00
|
|
|
if (mdev)
|
|
|
|
spin_lock(&mdev->lock);
|
|
|
|
|
2009-12-09 11:40:00 +00:00
|
|
|
for (i = 0; i < num_pads; i++) {
|
|
|
|
pads[i].entity = entity;
|
|
|
|
pads[i].index = i;
|
2015-09-08 17:10:56 +00:00
|
|
|
if (mdev)
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_create(mdev, MEDIA_GRAPH_PAD,
|
2015-09-08 17:10:56 +00:00
|
|
|
&entity->pads[i].graph_obj);
|
2009-12-09 11:40:00 +00:00
|
|
|
}
|
|
|
|
|
2015-09-08 17:10:56 +00:00
|
|
|
if (mdev)
|
|
|
|
spin_unlock(&mdev->lock);
|
|
|
|
|
2009-12-09 11:40:00 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2015-12-11 09:44:40 +00:00
|
|
|
EXPORT_SYMBOL_GPL(media_entity_pads_init);
|
2009-12-09 11:40:00 +00:00
|
|
|
|
2010-03-07 19:14:14 +00: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 09:55:40 +00:00
|
|
|
graph->stack[graph->top].link = (&entity->links)->next;
|
2010-03-07 19:14:14 +00: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)
|
|
|
|
|
|
|
|
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 15:45:11 +00:00
|
|
|
bitmap_zero(graph->entities, MEDIA_ENTITY_ENUM_MAX_ID);
|
|
|
|
|
2015-08-14 13:42:05 +00:00
|
|
|
if (WARN_ON(media_entity_id(entity) >= MEDIA_ENTITY_ENUM_MAX_ID))
|
2013-06-07 15:45:11 +00:00
|
|
|
return;
|
|
|
|
|
2015-08-14 13:42:05 +00:00
|
|
|
__set_bit(media_entity_id(entity), graph->entities);
|
2010-03-07 19:14:14 +00:00
|
|
|
stack_push(graph, entity);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_graph_walk_start);
|
|
|
|
|
|
|
|
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 09:55:40 +00:00
|
|
|
while (link_top(graph) != &(stack_top(graph)->links)) {
|
2010-03-07 19:14:14 +00: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 09:55:40 +00:00
|
|
|
struct media_link *link;
|
2010-03-07 19:14:14 +00: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 09:55:40 +00:00
|
|
|
link = list_entry(link_top(graph), typeof(*link), list);
|
|
|
|
|
2010-03-07 19:14:14 +00: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 09:55:40 +00:00
|
|
|
link_top(graph) = link_top(graph)->next;
|
2010-03-07 19:14:14 +00:00
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Get the entity in the other end of the link . */
|
|
|
|
next = media_entity_other(entity, link);
|
2015-08-14 13:42:05 +00:00
|
|
|
if (WARN_ON(media_entity_id(next) >= MEDIA_ENTITY_ENUM_MAX_ID))
|
2013-06-07 15:45:11 +00:00
|
|
|
return NULL;
|
2010-03-07 19:14:14 +00:00
|
|
|
|
2013-06-07 15:45:11 +00:00
|
|
|
/* Has the entity already been visited? */
|
2015-08-14 13:42:05 +00: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 09:55:40 +00:00
|
|
|
link_top(graph) = link_top(graph)->next;
|
2010-03-07 19:14:14 +00: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 09:55:40 +00:00
|
|
|
link_top(graph) = link_top(graph)->next;
|
2010-03-07 19:14:14 +00:00
|
|
|
stack_push(graph, next);
|
|
|
|
}
|
|
|
|
|
|
|
|
return stack_pop(graph);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_graph_walk_next);
|
|
|
|
|
2010-08-25 12:00:41 +00:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Pipeline management
|
|
|
|
*/
|
|
|
|
|
2012-01-11 09:25:15 +00:00
|
|
|
__must_check int media_entity_pipeline_start(struct media_entity *entity,
|
|
|
|
struct media_pipeline *pipe)
|
2010-08-25 12:00:41 +00:00
|
|
|
{
|
2015-08-19 15:35:21 +00:00
|
|
|
struct media_device *mdev = entity->graph_obj.mdev;
|
2010-08-25 12:00:41 +00:00
|
|
|
struct media_entity_graph graph;
|
2012-01-11 09:25:15 +00: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 09:55:40 +00:00
|
|
|
struct media_link *link;
|
2012-01-11 09:25:15 +00:00
|
|
|
int ret;
|
2010-08-25 12:00:41 +00:00
|
|
|
|
|
|
|
mutex_lock(&mdev->graph_mutex);
|
|
|
|
|
|
|
|
media_entity_graph_walk_start(&graph, entity);
|
|
|
|
|
|
|
|
while ((entity = media_entity_graph_walk_next(&graph))) {
|
2015-10-01 21:07:53 +00:00
|
|
|
DECLARE_BITMAP(active, MEDIA_ENTITY_MAX_PADS);
|
|
|
|
DECLARE_BITMAP(has_no_links, MEDIA_ENTITY_MAX_PADS);
|
2012-01-11 09:25:15 +00:00
|
|
|
|
2010-08-25 12:00:41 +00:00
|
|
|
entity->stream_count++;
|
|
|
|
WARN_ON(entity->pipe && entity->pipe != pipe);
|
|
|
|
entity->pipe = pipe;
|
2012-01-11 09:25:15 +00:00
|
|
|
|
|
|
|
/* Already streaming --- no need to check. */
|
|
|
|
if (entity->stream_count > 1)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!entity->ops || !entity->ops->link_validate)
|
|
|
|
continue;
|
|
|
|
|
2013-10-13 11:00:26 +00: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 09:55:40 +00:00
|
|
|
list_for_each_entry(link, &entity->links, list) {
|
2013-10-13 11:00:26 +00: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 09:25:15 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = entity->ops->link_validate(link);
|
2014-10-28 23:35:04 +00:00
|
|
|
if (ret < 0 && ret != -ENOIOCTLCMD) {
|
2015-08-19 15:35:21 +00:00
|
|
|
dev_dbg(entity->graph_obj.mdev->dev,
|
2014-10-28 23:35:04 +00:00
|
|
|
"link validation failed for \"%s\":%u -> \"%s\":%u, error %d\n",
|
2015-02-12 13:43:11 +00:00
|
|
|
link->source->entity->name,
|
|
|
|
link->source->index,
|
|
|
|
entity->name, link->sink->index, ret);
|
2012-01-11 09:25:15 +00:00
|
|
|
goto error;
|
2014-10-28 23:35:04 +00:00
|
|
|
}
|
2012-01-11 09:25:15 +00:00
|
|
|
}
|
2013-10-13 11:00:26 +00: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 15:35:21 +00:00
|
|
|
dev_dbg(entity->graph_obj.mdev->dev,
|
2014-10-28 23:35:04 +00:00
|
|
|
"\"%s\":%u must be connected by an enabled link\n",
|
|
|
|
entity->name,
|
2014-11-03 20:55:51 +00:00
|
|
|
(unsigned)find_first_zero_bit(
|
|
|
|
active, entity->num_pads));
|
2013-10-13 11:00:26 +00:00
|
|
|
goto error;
|
|
|
|
}
|
2010-08-25 12:00:41 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&mdev->graph_mutex);
|
2012-01-11 09:25:15 +00: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 12:00:41 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_pipeline_start);
|
|
|
|
|
|
|
|
void media_entity_pipeline_stop(struct media_entity *entity)
|
|
|
|
{
|
2015-08-19 15:35:21 +00:00
|
|
|
struct media_device *mdev = entity->graph_obj.mdev;
|
2010-08-25 12:00:41 +00: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-07 18:04:59 +00:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Module use count
|
|
|
|
*/
|
|
|
|
|
|
|
|
struct media_entity *media_entity_get(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
if (entity == NULL)
|
|
|
|
return NULL;
|
|
|
|
|
2015-08-19 15:35:21 +00:00
|
|
|
if (entity->graph_obj.mdev->dev &&
|
|
|
|
!try_module_get(entity->graph_obj.mdev->dev->driver->owner))
|
2010-03-07 18:04:59 +00:00
|
|
|
return NULL;
|
|
|
|
|
|
|
|
return entity;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_get);
|
|
|
|
|
|
|
|
void media_entity_put(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
if (entity == NULL)
|
|
|
|
return;
|
|
|
|
|
2015-08-19 15:35:21 +00:00
|
|
|
if (entity->graph_obj.mdev->dev)
|
|
|
|
module_put(entity->graph_obj.mdev->dev->driver->owner);
|
2010-03-07 18:04:59 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_put);
|
|
|
|
|
2010-03-07 19:14:14 +00:00
|
|
|
/* -----------------------------------------------------------------------------
|
|
|
|
* Links management
|
|
|
|
*/
|
|
|
|
|
2015-08-20 11:21:35 +00:00
|
|
|
static struct media_link *media_add_link(struct list_head *head)
|
2009-12-09 11:40:00 +00: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 09:55:40 +00:00
|
|
|
struct media_link *link;
|
2009-12-09 11:40:00 +00: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 09:55:40 +00:00
|
|
|
link = kzalloc(sizeof(*link), GFP_KERNEL);
|
|
|
|
if (link == NULL)
|
|
|
|
return NULL;
|
2009-12-09 11:40:00 +00:00
|
|
|
|
2015-08-20 11:21:35 +00:00
|
|
|
list_add_tail(&link->list, head);
|
2009-12-09 11:40:00 +00: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 09:55:40 +00:00
|
|
|
return link;
|
2009-12-09 11:40:00 +00: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 09:55:40 +00:00
|
|
|
static void __media_entity_remove_link(struct media_entity *entity,
|
2015-12-11 13:19:38 +00:00
|
|
|
struct media_link *link)
|
|
|
|
{
|
|
|
|
struct media_link *rlink, *tmp;
|
|
|
|
struct media_entity *remote;
|
|
|
|
|
|
|
|
if (link->source->entity == entity)
|
|
|
|
remote = link->sink->entity;
|
|
|
|
else
|
|
|
|
remote = link->source->entity;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(rlink, tmp, &remote->links, list) {
|
2015-12-11 13:25:23 +00:00
|
|
|
if (rlink != link->reverse)
|
2015-12-11 13:19:38 +00:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (link->source->entity == entity)
|
|
|
|
remote->num_backlinks--;
|
|
|
|
|
|
|
|
/* Remove the remote link */
|
|
|
|
list_del(&rlink->list);
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_destroy(&rlink->graph_obj);
|
2015-12-11 13:19:38 +00:00
|
|
|
kfree(rlink);
|
|
|
|
|
|
|
|
if (--remote->num_links == 0)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
list_del(&link->list);
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_destroy(&link->graph_obj);
|
2015-12-11 13:19:38 +00:00
|
|
|
kfree(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 09:55:40 +00:00
|
|
|
|
2009-12-09 11:40:00 +00:00
|
|
|
int
|
2015-08-07 11:14:38 +00:00
|
|
|
media_create_pad_link(struct media_entity *source, u16 source_pad,
|
2009-12-09 11:40:00 +00: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 11:21:35 +00:00
|
|
|
link = media_add_link(&source->links);
|
2009-12-09 11:40:00 +00:00
|
|
|
if (link == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
link->source = &source->pads[source_pad];
|
|
|
|
link->sink = &sink->pads[sink_pad];
|
|
|
|
link->flags = flags;
|
|
|
|
|
2015-08-14 15:54:36 +00:00
|
|
|
/* Initialize graph object embedded at the new link */
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_create(source->graph_obj.mdev, MEDIA_GRAPH_LINK,
|
2015-08-19 15:35:21 +00:00
|
|
|
&link->graph_obj);
|
2015-08-14 15:54:36 +00:00
|
|
|
|
2009-12-09 11:40:00 +00:00
|
|
|
/* Create the backlink. Backlinks are used to help graph traversal and
|
|
|
|
* are not reported to userspace.
|
|
|
|
*/
|
2015-08-20 11:21:35 +00:00
|
|
|
backlink = media_add_link(&sink->links);
|
2009-12-09 11:40:00 +00: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 09:55:40 +00:00
|
|
|
__media_entity_remove_link(source, link);
|
2009-12-09 11:40:00 +00:00
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
backlink->source = &source->pads[source_pad];
|
|
|
|
backlink->sink = &sink->pads[sink_pad];
|
|
|
|
backlink->flags = flags;
|
2015-08-30 12:53:57 +00:00
|
|
|
backlink->is_backlink = true;
|
2009-12-09 11:40:00 +00:00
|
|
|
|
2015-08-14 15:54:36 +00:00
|
|
|
/* Initialize graph object embedded at the new link */
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_create(sink->graph_obj.mdev, MEDIA_GRAPH_LINK,
|
2015-08-19 15:35:21 +00:00
|
|
|
&backlink->graph_obj);
|
2015-08-14 15:54:36 +00:00
|
|
|
|
2009-12-09 11:40:00 +00: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 09:55:40 +00:00
|
|
|
sink->num_links++;
|
|
|
|
source->num_links++;
|
2009-12-09 11:40:00 +00:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2015-08-07 11:14:38 +00:00
|
|
|
EXPORT_SYMBOL_GPL(media_create_pad_link);
|
2009-12-09 11:40:03 +00: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 09:55:40 +00:00
|
|
|
void __media_entity_remove_links(struct media_entity *entity)
|
|
|
|
{
|
|
|
|
struct media_link *link, *tmp;
|
2013-05-09 11:29:32 +00: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 09:55:40 +00:00
|
|
|
list_for_each_entry_safe(link, tmp, &entity->links, list)
|
|
|
|
__media_entity_remove_link(entity, link);
|
2013-05-09 11:29:32 +00: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 15:35:21 +00:00
|
|
|
if (entity->graph_obj.mdev == NULL)
|
2013-05-09 11:29:32 +00:00
|
|
|
return;
|
|
|
|
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_lock(&entity->graph_obj.mdev->lock);
|
2013-05-09 11:29:32 +00:00
|
|
|
__media_entity_remove_links(entity);
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_unlock(&entity->graph_obj.mdev->lock);
|
2013-05-09 11:29:32 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_remove_links);
|
|
|
|
|
2009-12-09 11:40:03 +00: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 14:34:35 +00:00
|
|
|
link->flags = flags;
|
2009-12-09 11:40:03 +00:00
|
|
|
link->reverse->flags = link->flags;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int __media_entity_setup_link(struct media_link *link, u32 flags)
|
|
|
|
{
|
2011-03-11 14:34:35 +00:00
|
|
|
const u32 mask = MEDIA_LNK_FL_ENABLED;
|
2009-12-09 11:40:03 +00:00
|
|
|
struct media_device *mdev;
|
|
|
|
struct media_entity *source, *sink;
|
|
|
|
int ret = -EBUSY;
|
|
|
|
|
|
|
|
if (link == NULL)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2011-03-11 14:34:35 +00:00
|
|
|
/* The non-modifiable link flags must not be modified. */
|
|
|
|
if ((link->flags & ~mask) != (flags & ~mask))
|
|
|
|
return -EINVAL;
|
|
|
|
|
2009-12-09 11:40:03 +00: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 12:00:41 +00:00
|
|
|
if (!(link->flags & MEDIA_LNK_FL_DYNAMIC) &&
|
|
|
|
(source->stream_count || sink->stream_count))
|
|
|
|
return -EBUSY;
|
|
|
|
|
2015-08-19 15:35:21 +00:00
|
|
|
mdev = source->graph_obj.mdev;
|
2009-12-09 11:40:03 +00:00
|
|
|
|
2013-05-31 13:37:26 +00:00
|
|
|
if (mdev->link_notify) {
|
|
|
|
ret = mdev->link_notify(link, flags,
|
|
|
|
MEDIA_DEV_NOTIFY_PRE_LINK_CH);
|
2009-12-09 11:40:03 +00:00
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = __media_entity_setup_link_notify(link, flags);
|
|
|
|
|
2013-05-31 13:37:26 +00:00
|
|
|
if (mdev->link_notify)
|
|
|
|
mdev->link_notify(link, flags, MEDIA_DEV_NOTIFY_POST_LINK_CH);
|
2009-12-09 11:40:03 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int media_entity_setup_link(struct media_link *link, u32 flags)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_lock(&link->source->entity->graph_obj.mdev->lock);
|
2009-12-09 11:40:03 +00:00
|
|
|
ret = __media_entity_setup_link(link, flags);
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_unlock(&link->source->entity->graph_obj.mdev->lock);
|
2009-12-09 11:40:03 +00:00
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_entity_setup_link);
|
|
|
|
|
|
|
|
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 09:55:40 +00:00
|
|
|
list_for_each_entry(link, &source->entity->links, list) {
|
2009-12-09 11:40:03 +00: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 08:16:13 +00:00
|
|
|
struct media_pad *media_entity_remote_pad(struct media_pad *pad)
|
2009-12-09 11:40:03 +00: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 09:55:40 +00:00
|
|
|
struct media_link *link;
|
2009-12-09 11:40:03 +00: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 09:55:40 +00:00
|
|
|
list_for_each_entry(link, &pad->entity->links, list) {
|
2009-12-09 11:40:03 +00: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 08:16:13 +00:00
|
|
|
EXPORT_SYMBOL_GPL(media_entity_remote_pad);
|
2015-08-20 12:07:34 +00:00
|
|
|
|
2015-08-28 18:43:36 +00: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);
|
|
|
|
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_create(mdev, gobj_type, &intf->graph_obj);
|
2015-08-28 18:43:36 +00:00
|
|
|
}
|
|
|
|
|
2015-08-20 12:07:34 +00: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,
|
2015-09-09 11:19:25 +00:00
|
|
|
u32 major, u32 minor)
|
2015-08-20 12:07:34 +00:00
|
|
|
{
|
|
|
|
struct media_intf_devnode *devnode;
|
|
|
|
|
2015-09-09 11:19:25 +00:00
|
|
|
devnode = kzalloc(sizeof(*devnode), GFP_KERNEL);
|
2015-08-20 12:07:34 +00:00
|
|
|
if (!devnode)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
devnode->major = major;
|
|
|
|
devnode->minor = minor;
|
|
|
|
|
2015-08-28 18:43:36 +00:00
|
|
|
media_interface_init(mdev, &devnode->intf, MEDIA_GRAPH_INTF_DEVNODE,
|
|
|
|
type, flags);
|
2015-08-20 12:07:34 +00:00
|
|
|
|
|
|
|
return devnode;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_devnode_create);
|
|
|
|
|
|
|
|
void media_devnode_remove(struct media_intf_devnode *devnode)
|
|
|
|
{
|
2015-08-24 11:46:46 +00:00
|
|
|
media_remove_intf_links(&devnode->intf);
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_destroy(&devnode->intf.graph_obj);
|
2015-08-20 12:07:34 +00:00
|
|
|
kfree(devnode);
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_devnode_remove);
|
2015-08-07 13:36:25 +00: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 */
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_create(intf->graph_obj.mdev, MEDIA_GRAPH_LINK,
|
2015-08-07 13:36:25 +00:00
|
|
|
&link->graph_obj);
|
|
|
|
|
|
|
|
return link;
|
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_create_intf_link);
|
|
|
|
|
2015-08-30 00:23:44 +00:00
|
|
|
void __media_remove_intf_link(struct media_link *link)
|
2015-08-07 13:36:25 +00:00
|
|
|
{
|
2015-08-30 00:23:44 +00:00
|
|
|
list_del(&link->list);
|
2015-12-11 13:55:40 +00:00
|
|
|
media_gobj_destroy(&link->graph_obj);
|
2015-08-07 13:36:25 +00:00
|
|
|
kfree(link);
|
|
|
|
}
|
2015-08-30 00:23:44 +00:00
|
|
|
EXPORT_SYMBOL_GPL(__media_remove_intf_link);
|
2015-08-07 13:36:25 +00:00
|
|
|
|
|
|
|
void media_remove_intf_link(struct media_link *link)
|
|
|
|
{
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_lock(&link->graph_obj.mdev->lock);
|
2015-08-07 13:36:25 +00:00
|
|
|
__media_remove_intf_link(link);
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_unlock(&link->graph_obj.mdev->lock);
|
2015-08-07 13:36:25 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_remove_intf_link);
|
2015-08-24 11:46:46 +00: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;
|
|
|
|
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_lock(&intf->graph_obj.mdev->lock);
|
2015-08-24 11:46:46 +00:00
|
|
|
__media_remove_intf_links(intf);
|
2015-12-09 21:47:35 +00:00
|
|
|
spin_unlock(&intf->graph_obj.mdev->lock);
|
2015-08-24 11:46:46 +00:00
|
|
|
}
|
|
|
|
EXPORT_SYMBOL_GPL(media_remove_intf_links);
|