All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steve Longerbeam <steve_longerbeam@mentor.com>
To: "Niklas Söderlund" <niklas.soderlund@ragnatech.se>,
	"Michael Rodin" <mrodin@de.adit-jv.com>
Cc: Mauro Carvalho Chehab <mchehab@kernel.org>,
	<linux-media@vger.kernel.org>,
	<linux-renesas-soc@vger.kernel.org>,
	<linux-kernel@vger.kernel.org>, <michael@rodin.online>,
	<efriedrich@de.adit-jv.com>, <erosca@de.adit-jv.com>
Subject: Re: [PATCH] media: rcar-vin: Move media_device_register to async completion
Date: Wed, 17 Jun 2020 11:18:11 -0700	[thread overview]
Message-ID: <888de4f6-3d89-5b74-750c-376173404832@mentor.com> (raw)
In-Reply-To: <20200617152857.GA2936315@oden.dyn.berto.se>

Hi Niklas, Michael,

On 6/17/20 8:28 AM, Niklas Söderlund wrote:
> Hi Michael,
>
> On 2020-06-17 17:15:37 +0200, Michael Rodin wrote:
>> Hi Niklas and Steve,
>>
>> On Wed, Jun 17, 2020 at 12:56:46PM +0200, Niklas Söderlund wrote:
>>> Hi Michael and Steve,
>>>
>>> On 2020-06-16 19:31:36 +0200, Michael Rodin wrote:
>>>> From: Steve Longerbeam <steve_longerbeam@mentor.com>
>>>>
>>>> The media_device is registered during driver probe, before async
>>>> completion, so it is possible for .link_notify to be called before
>>>> all devices are bound.
>>>>
>>>> Fix this by moving media_device_register() to rvin_group_notify_complete().
>>>> This ensures that all devices are now bound (the rcar-csi2 subdevices and
>>>> and video capture devices) before .link_notify can be called.
>>> I'm curious to what situation created the need for this change. I'm
>>> currently trying to take the VIN driver in the opposite direction [1]
>>> with the end goal of registering video devices at probe time and then
>>> allow the media graph to populate as devices becomes available.
>> It looks like almost all platform drivers call media_device_register() in
>> the completion callback. From my understaning it is necessary to ensure
>> that all subdevices are bound and all links are created before the user
>> can enable any link (which would trigger link_notify callback execution)
>> and set formats. If I am not mistaken, Steve could observe an "OOPS" or
>> at least it is theoretically possible.
> If an OOPS have been observed I would be interested to see it. That way
> we can fix the OOPS and keep the media graph registration where it is
> today.

It's been a long time since I looked at this on a Salvator-X. But I do 
remember there was an OOPS if an attempt was made to enable a link 
before all devices had bound. Unfortunately I no longer have access to 
RCAR h/w to prove this point.

>> Actually I found that this patch alone is not enough even if it is correct,
>> because we also have to register the media device in rvin_parallel_notify_complete()
>> in case if there is only a parallel video input device attached.
>>
>>> My reason for this is that we could have a functional pipeline inside
>>> the graph even if it's not complete. This came out of the GMSL work done
>>> a while pack where I had a faulty camera that would prevent the other 7
>>> in the system to function.
>> I agree that if a probe of a faulty subdevice fails, this should not affect
>> functionality of the other attached subdevices. The "complete" callback of
>> the async notifier is probably not executed in this case, so I guess, we
>> would have to register the media device in the "bound" callback after the first
>> subdevice has been probed? Otherwise there is not much sense to have video
>> capture devices, which are not connected to any source.
> Calling it in the bound callback is mostly the same as it is today, as
> link_notify could then be called when not all entities are in the graph.
> In fact even if we where tp move the media device registration to the t
> complete callback we have this problem if any of the subdevices are
> unbound. Then we are back to the state with a registerd media device
> where not all entities are present.
>
> I think the solution here is to address the issue (if any) in the
> link_notify callback when the graph is not fully populated.

I like the idea of allowing a functional pipeline without all devices 
bound. So I understand the desire to keep media device registration in 
probe.

So in that case I agree link_notify should be fixed if it still needs 
fixing to handle non-bound subdevices.

Steve

>> (Delayed) population of the media graph after media device registration
>> sounds also like a requirement for device tree overlay support, which would
>> also be a nice feature.
>>
>>> 1. [PATCH 0/5] media-device: Report if graph is complete
>>>
>>>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>>>> Signed-off-by: Michael Rodin <mrodin@de.adit-jv.com>
>>>> ---
>>>>   drivers/media/platform/rcar-vin/rcar-core.c | 14 ++++++--------
>>>>   1 file changed, 6 insertions(+), 8 deletions(-)
>>>>
>>>> diff --git a/drivers/media/platform/rcar-vin/rcar-core.c b/drivers/media/platform/rcar-vin/rcar-core.c
>>>> index 7440c89..e70f83b 100644
>>>> --- a/drivers/media/platform/rcar-vin/rcar-core.c
>>>> +++ b/drivers/media/platform/rcar-vin/rcar-core.c
>>>> @@ -253,7 +253,6 @@ static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
>>>>   	struct media_device *mdev = &group->mdev;
>>>>   	const struct of_device_id *match;
>>>>   	struct device_node *np;
>>>> -	int ret;
>>>>   
>>>>   	mutex_init(&group->lock);
>>>>   
>>>> @@ -266,7 +265,6 @@ static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
>>>>   	vin_dbg(vin, "found %u enabled VIN's in DT", group->count);
>>>>   
>>>>   	mdev->dev = vin->dev;
>>>> -	mdev->ops = &rvin_media_ops;
>>>>   
>>>>   	match = of_match_node(vin->dev->driver->of_match_table,
>>>>   			      vin->dev->of_node);
>>>> @@ -278,11 +276,7 @@ static int rvin_group_init(struct rvin_group *group, struct rvin_dev *vin)
>>>>   
>>>>   	media_device_init(mdev);
>>>>   
>>>> -	ret = media_device_register(&group->mdev);
>>>> -	if (ret)
>>>> -		rvin_group_cleanup(group);
>>>> -
>>>> -	return ret;
>>>> +	return 0;
>>>>   }
>>>>   
>>>>   static void rvin_group_release(struct kref *kref)
>>>> @@ -688,6 +682,8 @@ static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
>>>>   		return ret;
>>>>   	}
>>>>   
>>>> +	vin->group->mdev.ops = &rvin_media_ops;
>>>> +
>>>>   	/* Register all video nodes for the group. */
>>>>   	for (i = 0; i < RCAR_VIN_NUM; i++) {
>>>>   		if (vin->group->vin[i] &&
>>>> @@ -736,8 +732,10 @@ static int rvin_group_notify_complete(struct v4l2_async_notifier *notifier)
>>>>   		}
>>>>   	}
>>>>   	mutex_unlock(&vin->group->lock);
>>>> +	if (ret)
>>>> +		return ret;
>>>>   
>>>> -	return ret;
>>>> +	return media_device_register(&vin->group->mdev);
>>>>   }
>>>>   
>>>>   static void rvin_group_notify_unbind(struct v4l2_async_notifier *notifier,
>>>> -- 
>>>> 2.7.4
>>>>
>>> -- 
>>> Regards,
>>> Niklas Söderlund
>> -- 
>> Best Regards,
>> Michael


  reply	other threads:[~2020-06-17 18:18 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-16 17:31 [PATCH] media: rcar-vin: Move media_device_register to async completion Michael Rodin
2020-06-17 10:56 ` Niklas Söderlund
2020-06-17 15:15   ` Michael Rodin
2020-06-17 15:28     ` Niklas Söderlund
2020-06-17 18:18       ` Steve Longerbeam [this message]
2020-06-24 13:31       ` Hans Verkuil
2020-06-24 14:54         ` Niklas Söderlund
2020-07-16  9:18           ` Hans Verkuil
2020-07-17 13:59             ` Niklas Söderlund

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=888de4f6-3d89-5b74-750c-376173404832@mentor.com \
    --to=steve_longerbeam@mentor.com \
    --cc=efriedrich@de.adit-jv.com \
    --cc=erosca@de.adit-jv.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-renesas-soc@vger.kernel.org \
    --cc=mchehab@kernel.org \
    --cc=michael@rodin.online \
    --cc=mrodin@de.adit-jv.com \
    --cc=niklas.soderlund@ragnatech.se \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.