public inbox for linux-media@vger.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox