Hi Sakari,
On 12/01/2014 01:30 PM, Sakari Ailus wrote:
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.
My intention here was to discuss the situation when there is more
than one active link connected to an entity sink pad(s).
There are two options:
a) more than one active link connected to the same sink pad
(I don't know if this has been ever considered a valid arrangement)
b) more than one active link connected to separate sink pads
if the same entity.
In both cases discovering a pipeline will require different approach
than in the recent patch set, where there are only configurable
links expected in the media config and those fixed aren't taken
into account. After the config links are set up, the pipeline
is discovered by walking from the sink entity upstream, until
the entity with no sink pads is encountered.
If more than one link is connected to the sink pad(s) of
an entity the situation becomes ambiguous.
Therefore I propose to define all the links for the pipeline
in the media config. The fixed links could be marked with
relevant flags. By validating the pipeline I meant checking
whether all links from the media configuration file are
active.
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.
OK, I missed that.
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.
Therefore this ioctl should lock media device until VIDIOC_STREAMON
on the configured pipeline. I am not sure about other implications and
feasibility of such a design though.
Best Regards,
Jacek Anaszewski
--
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
