linux-media.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jacek Anaszewski <j.anaszewski@samsung.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: linux-media@vger.kernel.org, m.chehab@samsung.com,
	gjasny@googlemail.com, hdegoede@redhat.com,
	hans.verkuil@cisco.com, b.zolnierkie@samsung.com,
	kyungmin.park@samsung.com, sakari.ailus@linux.intel.com,
	laurent.pinchart@ideasonboard.com
Subject: Re: [PATCH/RFC v4 05/11] mediactl: Add media device graph helpers
Date: Mon, 01 Dec 2014 12:23:15 +0100	[thread overview]
Message-ID: <547C4FA3.30605@samsung.com> (raw)
In-Reply-To: <20141128170655.GO8907@valkosipuli.retiisi.org.uk>

Hi Sakari,

Thanks for a review.

On 11/28/2014 06:06 PM, Sakari Ailus wrote:
> Hi Jacek,
>
> On Fri, Nov 21, 2014 at 05:14:34PM +0100, Jacek Anaszewski wrote:
>> Add new graph helpers useful for video pipeline discovering.
>>
>> Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
>> Acked-by: Kyungmin Park <kyungmin.park@samsung.com>
>> ---
>>   utils/media-ctl/libmediactl.c |  174 +++++++++++++++++++++++++++++++++++++++++
>>   utils/media-ctl/mediactl.h    |  121 ++++++++++++++++++++++++++++
>>   2 files changed, 295 insertions(+)
>>
>> diff --git a/utils/media-ctl/libmediactl.c b/utils/media-ctl/libmediactl.c
>> index af7dd43..a476601 100644
>> --- a/utils/media-ctl/libmediactl.c
>> +++ b/utils/media-ctl/libmediactl.c
>> @@ -35,6 +35,7 @@
>>   #include <unistd.h>
>>
>>   #include <linux/media.h>
>> +#include <linux/kdev_t.h>
>>   #include <linux/videodev2.h>
>>
>>   #include "mediactl.h"
>> @@ -87,6 +88,28 @@ struct media_entity *media_get_entity_by_name(struct media_device *media,
>>   	return NULL;
>>   }
>>
>> +struct media_entity *media_get_entity_by_devname(struct media_device *media,
>> +					      const char *devname, size_t length)
>> +{
>> +	unsigned int i;
>> +
>> +	/* A match is impossible if the entity devname is longer than the maximum
>
> Over 80 characters per line.
>
>> +	 * size we can get from the kernel.
>> +	 */
>> +	if (length >= FIELD_SIZEOF(struct media_entity, devname))
>> +		return NULL;
>> +
>> +	for (i = 0; i < media->entities_count; ++i) {
>> +		struct media_entity *entity = &media->entities[i];
>> +
>> +		if (strncmp(entity->devname, devname, length) == 0 &&
>> +		    entity->devname[length] == '\0')
>> +			return entity;
>> +	}
>> +
>> +	return NULL;
>> +}
>> +
>>   struct media_entity *media_get_entity_by_id(struct media_device *media,
>>   					    __u32 id)
>>   {
>> @@ -145,6 +168,11 @@ const char *media_entity_get_devname(struct media_entity *entity)
>>   	return entity->devname[0] ? entity->devname : NULL;
>>   }
>>
>> +const char *media_entity_get_name(struct media_entity *entity)
>> +{
>> +	return entity->info.name ? entity->info.name : NULL;
>
> You could simply return entity->info.name.

Right.

>> +}
>> +
>>   struct media_entity *media_get_default_entity(struct media_device *media,
>>   					      unsigned int type)
>>   {
>> @@ -177,6 +205,152 @@ const struct media_entity_desc *media_entity_get_info(struct media_entity *entit
>>   	return &entity->info;
>>   }
>>
>> +int media_get_link_by_sink_pad(struct media_device *media,
>> +				struct media_pad *pad,
>> +				struct media_link **link)
>> +{
>> +	struct media_link *cur_link = NULL;
>> +	int i, j;
>> +
>> +	if (pad == NULL || link == NULL)
>> +		return -EINVAL;
>> +
>> +	for (i = 0; i < media->entities_count; ++i) {
>> +		for (j = 0; j < media->entities[i].num_links; ++j) {
>> +			cur_link = &media->entities[i].links[j];
>> +			if ((cur_link->flags & MEDIA_LNK_FL_ENABLED) &&
>> +			    /* check if cur_link's sink entity matches the pad parent entity */
>> +			    (cur_link->sink->entity->info.id == pad->entity->info.id) &&
>
> Hmm. This looks harder than it should be. Would it be possible loop over the
> array of links in struct media_entity instead, and look for a sink?

I thought that the entity has only outbound links as it is in case of
MEDIA_IOC_ENUM_LINKS ioctl, but it seems that it has also the
inbound ones. Nice.

>> +			    /* check if cur_link's sink pad id matches */
>> +			    (cur_link->sink->index == pad->index)) {
>> +				*link = cur_link;
>> +				return 0;
>> +			}
>> +		}
>> +	}
>> +
>> +	return -EINVAL;
>> +}
>> +
>> +int media_get_link_by_source_pad(struct media_entity *entity,
>> +				struct media_pad *pad,
>> +				struct media_link **link)
>> +{
>> +	int i;
>> +
>> +	if (entity == NULL || pad == NULL || link == NULL)
>> +		return -EINVAL;
>> +
>> +	for (i = 0; i < entity->num_links; ++i) {
>
> ...just like you do it here. :-)
>
>> +		if ((entity->links[i].flags & MEDIA_LNK_FL_ENABLED) &&
>> +		    (entity->links[i].source->index == pad->index)) {
>> +			*link = &entity->links[i];
>> +			return 0;
>> +		}
>> +	}
>> +
>> +	return -EINVAL;
>> +}
>> +
>> +int media_get_pads_by_entity(struct media_entity *entity, unsigned int type,
>
> type should be flags, and flags uses __u32 type.
>
>> +				struct media_pad **pads, int *num_pads)
>> +{
>> +	struct media_pad *entity_pads;
>> +	int cnt_pads, i;
>> +
>> +	if (entity == NULL || pads == NULL || num_pads == NULL)
>> +		return -EINVAL;
>> +
>> +	entity_pads = malloc(sizeof(*entity_pads));
>
> How about allocating room for entity->info.pads pads, and then making it
> smaller as needed?

Sounds reasonable.

>> +	cnt_pads = 0;
>
> You could use *num_pads instead of cnt_pads.
>
>> +	for (i = 0; i < entity->info.pads; ++i) {
>> +		if (entity->pads[i].flags & type) {
>> +			entity_pads = realloc(entity_pads, (i + 1) *
>> +					      sizeof(*entity_pads));
>> +			entity_pads[cnt_pads++] = entity->pads[i];
>> +		}
>> +	}
>> +
>> +	if (cnt_pads == 0)
>> +		free(entity_pads);
>> +
>> +	*pads = entity_pads;
>> +	*num_pads = cnt_pads;
>> +
>> +	return 0;
>> +}
>> +
>> +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

> 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.

> 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.

Best Regards,
Jacek Anaszewski

  reply	other threads:[~2014-12-01 11:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-21 16:14 [PATCH/RFC v4 00/11] Add a plugin for Exynos4 camera Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 01/11] mediactl: Introduce v4l2_subdev structure Jacek Anaszewski
2014-11-25 11:36   ` Sakari Ailus
2014-11-25 12:22     ` Jacek Anaszewski
2014-11-26 10:20       ` Sakari Ailus
2014-11-21 16:14 ` [PATCH/RFC v4 02/11] mediactl: Add support for v4l2 controls Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 03/11] mediactl: Separate entity and pad parsing Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 04/11] mediatext: Add library Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 05/11] mediactl: Add media device graph helpers Jacek Anaszewski
2014-11-28 17:06   ` Sakari Ailus
2014-12-01 11:23     ` Jacek Anaszewski [this message]
2014-12-01 12:30       ` Sakari Ailus
2014-12-01 14:21         ` Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 06/11] mediactl: Add media_device creation helpers Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 07/11] media-ctl: libv4l2subdev: add VYUY8_2X8 mbus code Jacek Anaszewski
2014-11-28 17:10   ` Sakari Ailus
2014-11-21 16:14 ` [PATCH/RFC v4 08/11] mediactl: Add support for media device pipelines Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 09/11] mediactl: Close only pipeline sub-devices Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 10/11] mediactl: Add media device ioctl API Jacek Anaszewski
2014-11-21 16:14 ` [PATCH/RFC v4 11/11] Add a libv4l plugin for Exynos4 camera Jacek Anaszewski
2014-11-27  8:41   ` Sakari Ailus
2014-11-28 13:29     ` Jacek Anaszewski
2015-02-27  9:32     ` Jacek Anaszewski
2015-03-15 19:07   ` Gregor Jasny
2015-03-16  8:54     ` Jacek Anaszewski
2015-03-15 19:12   ` Gregor Jasny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=547C4FA3.30605@samsung.com \
    --to=j.anaszewski@samsung.com \
    --cc=b.zolnierkie@samsung.com \
    --cc=gjasny@googlemail.com \
    --cc=hans.verkuil@cisco.com \
    --cc=hdegoede@redhat.com \
    --cc=kyungmin.park@samsung.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=linux-media@vger.kernel.org \
    --cc=m.chehab@samsung.com \
    --cc=sakari.ailus@iki.fi \
    --cc=sakari.ailus@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).