Several additional functions are described at media-entity.c.
Moving them to the header file, to make the code cleaner and
to have all such macros at the same place.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Those media_obj_* functions are actually creating/destroying
media graph objects. So, rename them to better represent
what they're actually doing.
No functional changes.
This was created via this small shell script:
for i in $(git grep -l media_gobj_init); do sed s,media_gobj_init,media_gobj_create,g <$i >a && mv a $i; done
for i in $(git grep -l media_gobj_remove); do sed s,media_gobj_remove,media_gobj_destroy,g <$i >a && mv a $i; done
Suggested-by: Sakari Ailus <sakari.ailus@iki.fi>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Now that we moved the content of the media-framework.txt into
the kerneldoc documentation, move the per-function specific
documentation to the corresponding functions and clean it up.
It would be good if we had already the markdown kernel-doc
patches merged upstream, but, while we doesn't have it,
let's make it less ugly at device-drivers.xml.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
This function was used in the past to free the links
that were allocated by the media controller core.
However, this is not needed anymore. We should likely
get rid of the funcion on some function, but, for now,
let's just convert into an inlined function and let the
compiler to get rid of it.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Instead of using a text file, let's put it together with the
struct documentation for the Media Controller.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Both revision and group_id fields were never used and were always
initialized to zero. Remove them.
Suggested-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
With the MC next gen rework, what's left for media_entity_init()
is to just initialize the PADs. However, certain devices, like
a FLASH led/light doesn't have any input or output PAD.
So, there's no reason why calling media_entity_init() would be
mandatory. Also, despite its name, what this function actually
does is to initialize the PADs data. So, rename it to
media_entity_pads_init() in order to reflect that.
The media entity actual init happens during entity register,
at media_device_register_entity(). We should move init of
num_links and num_backlinks to it.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
We should not be creating device nodes at IRQ contexts. So,
the only flags we'll be using will be GFP_KERNEL. Let's
remove the gfp_flags, in order to make the interface simpler.
If we ever need it, it would be easy to revert those changes.
While here, remove an extra blank line.
Suggested-by: Sakari Ailus <sakari.ailus@iki.fi>
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Entities should have one or more functions. Calling it as a
type proofed to not be correct, as an entity could eventually
have more than one type.
So, rename the field as function.
Please notice that this patch doesn't extend support for
multiple function entities. Such change will happen when
we have real case drivers using it.
No functional changes.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Drivers should check if interfaces and interface links were
created. Add a must_check for them.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Due to the graph traversal algorithm currently in usage, we
need a copy of all data links. Those backlinks should not be
send to userspace, as otherwise, all links there will be
duplicated.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Only a few structs are documented on kernel-doc-nano format
(the ones added by the MC next gen patches).
Add a documentation for all structs, and ensure that they'll
be producing the documentation at the Kernel's device driver
DocBook.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
V4L2 device (and subdevice) nodes should create an interface, if the
Media Controller support is enabled.
Please notice that radio devices should not create an entity, as radio
input/output is either via wires or via ALSA.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Tuners actually have at least one connector on its input.
Add a PAD to connect it.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Some parts of the media controller are using mutexes while
others are using spin locks in order to protect creation
and removal of elements in the graph. That's wrong!
Also, the V4L2 core can remove graph elements on non-interactive
context:
BUG: sleeping function called from invalid context at include/linux/sched.h:2776
Fix it by always using spin locks for graph element addition/removal,
just like entity creation/removal is protected at media-device.c
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Just like what's done with entities, when the media controller is
unregistered, release any interface and interface links that
might still be there.
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Add functions to explicitly unregister all entity links.
This function is called automatically when an entity
link is destroyed.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Every time a graph object is added or removed, the version
of the topology changes. That's a requirement for the new
MEDIA_IOC_G_TOPOLOGY, in order to allow userspace to know
that the topology has changed after a previous call to it.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
The MC next gen API sends objects to userspace grouped by
their types.
In the case of pads and links, in order to improve performance
and have a simpler code, the best is to store them also on
separate linked lists at MC.
If we don't do that, we would need this kind of interaction
to send data to userspace (code is in structured english):
for each entity:
for each pad:
store pads
for each entity:
for each link:
store link
for each interface:
for each link:
store link
With would require one nested loop for pads and two nested
loops for links. By using separate linked lists for them,
just one loop would be enough.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Mauro Carvalho Chehab