From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com>,
linux-media@vger.kernel.org
Subject: Re: [RFC/PATCH 05/10] media: Reference count and power handling
Date: Mon, 19 Jul 2010 14:20:33 +0300 [thread overview]
Message-ID: <4C443501.4030401@maxwell.research.nokia.com> (raw)
In-Reply-To: <cf2ca57033486758e0b039ce4c133a3e.squirrel@webmail.xs4all.nl>
Hans Verkuil wrote:
>
>> Hi Hans,
>>
>> And thanks for the comments!
>>
>> Hans Verkuil wrote:
>> ...
>>>> +/*
>>>> + * Apply use count change to an entity and change power state based on
>>>> + * new use count.
>>>> + */
>>>> +static int media_entity_power_apply_one(struct media_entity *entity,
>>>> int change)
>>>> +{
>>>> + int ret = 0;
>>>> +
>>>> + if (entity->use_count == 0 && change > 0 &&
>>>> + entity->ops && entity->ops->set_power) {
>>>> + ret = entity->ops->set_power(entity, 1);
>>>> + if (ret)
>>>> + return ret;
>>>> + }
>>>> +
>>>> + media_entity_use_apply_one(entity, change);
>>>> +
>>>> + if (entity->use_count == 0 && change < 0 &&
>>>> + entity->ops && entity->ops->set_power)
>>>> + ret = entity->ops->set_power(entity, 0);
>>>
>>> Shouldn't this code be executed before the call to
>>> media_entity_use_apply_one()?
>>> Or at least call media_entity_use_apply_one(entity, -change) in case of
>>> an
>>> error? Since it failed to power off the entity it should ensure that the
>>> use_count
>>> remains > 0.
Forgot to answer this one.
The first entity->ops->set_power() is called to power on the device.
This will be done when the use_count was 0 and change is positive, i.e.
we're asked to power on the entity. The actual use count is not changed
in case of a failure.
The latter entity->ops->set_power() is called to power the device off.
media_entity_use_apply_one() is called first to apply the change since
the change isn't necessarily -1 or 1.The change was already applied to
the entity->use_count that's why the comparison against 0. And the
change was negative, i.e. the device is to be powered off.
So I don't think there's an error in use_count calculation. But the
second set_power() to power the device off shouldn't set ret at all and
the function should return zero at the end.
Then I think it'd be correct. Things can currently go wrong when
media_entity_power_apply() is called from
media_entity_node_power_change() with a negative change.
>>
>> My assumption originally was that powering the device off always
>> succeeds. Things become interesting if powering off really fails. For
>> example, the power state is related to open file handles. Do you deny
>> closing the file handle if the related power state change isn't possible?
>>
>> It's indeed a good question what should be done in that case. Some
>> things do go wrong there anyway. I could think of leaving it for drivers
>> themselves to handle if there's something that can be done.
>>
>> The power state change for a device can involve an I2C transaction, for
>> example, which really can fail in practice.
>
> There are two issue here: my comment above was limited to the fact that as
> far as I can see the use_count will be off by one if the power off fails.
> That should be fixed.
>
> The other issue is what to do when power off fails. There are a few
> possible schemes:
>
> 1) Just power off everything, ignoring any failures (although they should
> be reported in the kernel log). Probably what you want in practice.
> 2) Revert to the previous state (that's what happening in your code).
> Sounds nice, but what do you do next?
In one case, yes, as far as I can see, entities could have been powered
on again as a result of a failed power off. But that's a bug. :-)
> 3) Add a boolean to choose whether to forcefully power off everything
> (i.e. case 1), or report an error and restore the state (case 2).
>
> Frankly, I'm in favor of the simple solution: case 1. When you get i2c
> errors when powering off you are probably experiencing lots of other
> problems as well.
I fully agree.
Cheers,
--
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com
next prev parent reply other threads:[~2010-07-19 11:20 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-07-14 13:30 [RFC/PATCH 00/10] Media controller (core and V4L2) Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 01/10] media: Media device node support Laurent Pinchart
2010-07-18 10:58 ` Hans Verkuil
2010-07-19 10:56 ` Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 02/10] media: Media device Laurent Pinchart
2010-07-15 14:16 ` Aguirre, Sergio
2010-07-16 8:53 ` Laurent Pinchart
2010-07-16 14:22 ` Aguirre, Sergio
2010-07-15 14:22 ` Aguirre, Sergio
2010-07-16 8:56 ` Laurent Pinchart
2010-07-16 14:20 ` Aguirre, Sergio
2010-07-18 15:32 ` Muralidharan Karicheri
2010-07-19 11:23 ` Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 03/10] media: Entities, pads and links Laurent Pinchart
2010-07-15 14:35 ` Aguirre, Sergio
2010-07-16 9:10 ` Laurent Pinchart
2010-07-16 14:22 ` Aguirre, Sergio
2010-07-18 11:53 ` Hans Verkuil
2010-07-19 12:12 ` Laurent Pinchart
2010-07-19 13:05 ` Hans Verkuil
2010-07-14 13:30 ` [RFC/PATCH 04/10] media: Entity graph traversal Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 05/10] media: Reference count and power handling Laurent Pinchart
2010-07-18 11:47 ` Hans Verkuil
2010-07-19 9:26 ` Sakari Ailus
2010-07-19 9:55 ` Hans Verkuil
2010-07-19 11:20 ` Sakari Ailus [this message]
2010-07-20 14:47 ` Laurent Pinchart
2010-07-20 15:18 ` Sakari Ailus
2010-07-14 13:30 ` [RFC/PATCH 06/10] media: Entities, pads and links enumeration Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 07/10] media: Links setup Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 08/10] v4l: Add a media_device pointer to the v4l2_device structure Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 09/10] v4l: Make video_device inherit from media_entity Laurent Pinchart
2010-07-14 13:30 ` [RFC/PATCH 10/10] v4l: Make v4l2_subdev " Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 00/12] Further V4L2 API additions and OMAP3 ISP driver Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 01/12] v4l: Move the media/v4l2-mediabus.h header to include/linux Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 02/12] v4l: Add 16 bit YUYV and SGRBG10 media bus format codes Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 03/12] v4l: Create v4l2 subdev file handle structure Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 04/12] v4l-subdev: Add pads operations Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 05/12] v4l: v4l2_subdev userspace format API Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 06/12] v4l: Add subdev userspace API to enumerate and configure frame interval Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 07/12] v4l: Add crop ioctl to V4L2 subdev API Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 08/12] v4l: subdev: Generic ioctl support Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 09/12] ARM: OMAP3: Update Camera ISP definitions for OMAP3630 Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 10/12] omap3: Export omap3isp platform device structure Laurent Pinchart
2010-07-14 14:07 ` [SAMPLE 11/12] omap34xxcam: Register the ISP platform device during omap34xxcam probe Laurent Pinchart
2010-07-14 14:26 ` [SAMPLE 12/12] OMAP3 ISP driver Laurent Pinchart
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=4C443501.4030401@maxwell.research.nokia.com \
--to=sakari.ailus@maxwell.research.nokia.com \
--cc=hverkuil@xs4all.nl \
--cc=laurent.pinchart@ideasonboard.com \
--cc=linux-media@vger.kernel.org \
/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.