Re: [PATCH/RFC v4 05/11] mediactl: Add media device graph helpers

[Jacek Anaszewski <j.anaszewski@samsung.com>]

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