From: Sylwester Nawrocki <sylvester.nawrocki@gmail.com>
To: Sakari Ailus <sakari.ailus@iki.fi>
Cc: Sylwester Nawrocki <s.nawrocki@samsung.com>,
linux-media@vger.kernel.org, laurent.pinchart@ideasonboard.com,
hj210.choi@samsung.com, arun.kk@samsung.com,
shaik.ameer@samsung.com, kyungmin.park@samsung.com
Subject: Re: [REVIEW PATCH v2 10/11] media: Change media device link_notify behaviour
Date: Sun, 09 Jun 2013 21:12:22 +0200 [thread overview]
Message-ID: <51B4D396.3010808@gmail.com> (raw)
In-Reply-To: <20130606001114.GA3103@valkosipuli.retiisi.org.uk>
Hi,
On 06/06/2013 02:11 AM, Sakari Ailus wrote:
> Hi Sylwester,
>
> Thanks for the patch!
And thanks for taking time to review!
> On Fri, May 31, 2013 at 04:37:26PM +0200, Sylwester Nawrocki wrote:
> ...
>> @@ -547,25 +547,17 @@ int __media_entity_setup_link(struct media_link *link, u32 flags)
>>
>> mdev = source->parent;
>>
>> - if ((flags& MEDIA_LNK_FL_ENABLED)&& mdev->link_notify) {
>> - ret = mdev->link_notify(link->source, link->sink,
>> - MEDIA_LNK_FL_ENABLED);
>> + if (mdev->link_notify) {
>> + ret = mdev->link_notify(link, flags,
>> + MEDIA_DEV_NOTIFY_PRE_LINK_CH);
>> if (ret< 0)
>> return ret;
>> }
>>
>> ret = __media_entity_setup_link_notify(link, flags);
>> - if (ret< 0)
>> - goto err;
>>
>> - if (!(flags& MEDIA_LNK_FL_ENABLED)&& mdev->link_notify)
>> - mdev->link_notify(link->source, link->sink, 0);
>> -
>> - return 0;
>> -
>> -err:
>> - if ((flags& MEDIA_LNK_FL_ENABLED)&& mdev->link_notify)
>> - mdev->link_notify(link->source, link->sink, 0);
>> + if (mdev->link_notify)
>> + mdev->link_notify(link, flags, MEDIA_DEV_NOTIFY_POST_LINK_CH);
>
> This changes the behaviour of link_notify() so that the flags will be the
> same independently of whether there was an error. I wonder if that's
> intentional.
Yes, that's intentional. However I failed to update the omap3isp driver
link_notify handler properly to handle the link set up error case. I'll
correct that in next iteration.
> I'd think that in the case of error the flags wouldn't change from what they
> were, i.e. the flags argument would be "link->flags" instead of "flags".
The idea was to allow the link_notify handler to determine when link state
change succeeded, and when not. So the 'flags' link_notify() argument
indicates what was the intended state, while the actual state can be
determined by checking link->flags.
I considered not introducing the 'notification' argument and just comparing
'flags' and 'link->flags', but those look same before and after a call to
__media_entity_setup_link_notify() in error case.
>> return ret;
>> }
>
> ...
>
>> diff --git a/include/media/media-device.h b/include/media/media-device.h
>> index eaade98..353c4ee 100644
>> --- a/include/media/media-device.h
>> +++ b/include/media/media-device.h
>> @@ -45,6 +45,7 @@ struct device;
>> * @entities: List of registered entities
>> * @lock: Entities list lock
>> * @graph_mutex: Entities graph operation lock
>> + * @link_notify: Link state change notification callback
>> *
>> * This structure represents an abstract high-level media device. It allows easy
>> * access to entities and provides basic media device-level support. The
>> @@ -75,10 +76,14 @@ struct media_device {
>> /* Serializes graph operations. */
>> struct mutex graph_mutex;
>>
>> - int (*link_notify)(struct media_pad *source,
>> - struct media_pad *sink, u32 flags);
>> + int (*link_notify)(struct media_link *link, unsigned int flags,
>> + unsigned int notification);
>
> media_link->flags is unsigned long. The patch doesn't break anything, but it
> switches from u32/unsigned long to unsigned int/unsigned long for the field.
>
> How about making media_link->flags unsigned int (or unsigned long) at the
> same time, or not changing it? This could be fixed in a separate patch as
> well (which I'm not necessarily expect from you now). There are probably a
> number of places that would need to be changed.
Hmm, OK, I'll revert this 'flags' type change. I guess it's best to use
'unsigned int' all over, but I'll leave it out for a separate patch, for
someone to write. :)
Thanks,
Sylwester
next prev parent reply other threads:[~2013-06-09 19:12 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-31 14:37 [REVIEW PATCH v2 00/11] Media link_notify behaviour change and exynos4-is updates Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 01/11] exynos4-is: Move common functions to a separate module Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 02/11] exynos4-is: Add struct exynos_video_entity Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 03/11] exynos4-is: Preserve state of controls between /dev/video open/close Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 04/11] exynos4-is: Media graph/video device locking rework Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 05/11] exynos4-is: Do not use asynchronous runtime PM in release fop Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 06/11] exynos4-is: Use common exynos_media_pipeline data structure Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 07/11] exynos4-is: Remove WARN_ON() from __fimc_pipeline_close() Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 08/11] exynos4-is: Fix sensor subdev -> FIMC notification setup Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 09/11] exynos4-is: Add locking at fimc(-lite) subdev unregistered handler Sylwester Nawrocki
2013-05-31 14:37 ` [REVIEW PATCH v2 10/11] media: Change media device link_notify behaviour Sylwester Nawrocki
2013-06-06 0:11 ` Sakari Ailus
2013-06-09 19:12 ` Sylwester Nawrocki [this message]
2013-05-31 14:37 ` [REVIEW PATCH v2 11/11] exynos4-is: Extend link_notify handler to support fimc-is/lite pipelines Sylwester Nawrocki
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=51B4D396.3010808@gmail.com \
--to=sylvester.nawrocki@gmail.com \
--cc=arun.kk@samsung.com \
--cc=hj210.choi@samsung.com \
--cc=kyungmin.park@samsung.com \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
--cc=s.nawrocki@samsung.com \
--cc=sakari.ailus@iki.fi \
--cc=shaik.ameer@samsung.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 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.