Hi Jacek,
Jacek Anaszewski wrote:
...
+int media_get_busy_pads_by_entity(struct media_device *media,
+ struct media_entity *entity,
+ unsigned int type,
+ struct media_pad **busy_pads,
+ int *num_busy_pads)
Are you looking for enabled links that someone else would have configured
here?
The assumption is made here that there will be no concurrent users of
a media device and an entity will have no more than one link connected
to its sink pad. If this assumption is not valid than all the links
in the pipeline would have to be defined in the media config and
the pipeline would have to be only validated not discovered.
By pipeline validation I mean checking whether all config links are
enabled
You do get an error from MEDIA_IOC_LINK_SETUP if enabling a link fails.
I think we should have a more generic solution to that. This one still
does
not guard against concurrent user space processes that attempt to
configure
the media device.
One possibility would be to add IOCTLs to grant and release exclusive
write
(i.e. change configuration) access to the device. Once streaming is
started,
exclusive access could be released by the user. I wonder what Laurent
would
think about that. I think this would be very robust --- one could
start with
resetting all the links one can, and then configure those that are
needed;
if this fails, then the pipeline is already used by someone else and
streaming cannot taken place on it. No cleanup of the configuration is
needed.
This approach would preclude having more than one pipeline configured
in a media device.
That's not true. You can *configure* a single pipeline at once, but once
that one is streaming (or write access is allowed from other file
handles again), you can configure another one that does no conflict with
the first one.
But this is definitely out of scope of this patchset (also because
this is
for the user space).
Taking into account that there are cases when it would be useful
to allow for having more than one active pipelines in a media device
I think that we would require changes in the media controller API.
I would hide from the user a possibility of reconfiguring the links
one by one, but instead provide an ioctl which would accept
a definition of a whole pipeline to be linked. Something
similar to extended controls.
A user space process calling such an ioctl would take the ownership
of the all involved sub-devices, and their linkage couldn't be
reconfigured until released.
That does not mean someone else could reconfigure the links before you
attempt to start streaming.
--
Kind regards,
Sakari Ailus
sakari.ailus@xxxxxxxxxxxxxxx
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
