public inbox for linux-omap@vger.kernel.org
 help / color / mirror / Atom feed
From: Sakari Ailus <sakari.ailus@maxwell.research.nokia.com>
To: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	linux-media@vger.kernel.org, linux-omap@vger.kernel.org,
	linux-kernel@vger.kernel.org, lrg@slimlogic.co.uk,
	lennart@poettering.net
Subject: Re: [RFC/PATCH v6 05/12] media: Reference count and power handling
Date: Thu, 25 Nov 2010 19:49:05 +0200	[thread overview]
Message-ID: <4CEEA191.1000706@maxwell.research.nokia.com> (raw)
In-Reply-To: <201011251643.17313.laurent.pinchart@ideasonboard.com>

Laurent Pinchart wrote:
> Hi Mark,

Hi Laurent, others,

> On Thursday 25 November 2010 14:49:08 Mark Brown wrote:
>> On Thu, Nov 25, 2010 at 03:28:12AM +0100, Laurent Pinchart wrote:
>>> 	If the entity is of node type, the power change is distributed to
>>> 	all connected entities. For non-nodes it only affects that very
>>> 	node. A mutex is used to serialise access to the entity graph.
>>
>> ASoC has its own power management stuff which doesn't *quite* map onto
>> this one as-is.  The power determination stuff is essentially identical
>> (and this is actually nicer) but we have a separate postprocessing stage
>> that actually applies the changes in a sequence which minimises audible
>> issues caused by doing things in a bad order (eg, power down a PGA
>> before you turn off inputs).  This is noddy enough to implement, though
>> - we just need a pre and post run notifications to set up and implement
>> the changes I think.
> 
> That sounds feasible. Sakari, you've implemented power management, what do you 
> think about this ?

I first have to admit that I don't know ALSA almost at all.

Currently when two media entities are connected they will be powered up
for the duration of the link setup, just in case the drivers would need
to access hardware for some reason. I don't think we have a need for
that at the moment, it's so just because it seemed to be the right thing
to do.

Essentially the idea is that the drivers do not need to be involved with
the power state handling and the device would be powered always when
they are run, but not be powered when it's not necessary.

That feature put aside, then what's left is what Laurent described; the
entities will be powered up based on opening subdev and video nodes
(V4L2 case, for ALSA it'd be different kind of ALSA nodes). But I don't
think there's necessarily even need to remove this feature.

Subdev is a V4L2 specific concept and I don't know if ALSA would benefit
from something similar. If you want to be able to access the individual
enties from user space, then similar arrangement might be useful.

There are use cases to only use subdev nodes on V4L2: camera LED flash
in torch mode, for example. There is no need to power on the rest of the
system.

I don't see a problem in applying restrictions on power on / off
sequence. They would probably be useful also on the V4L2 side in the future.


Could the restrictions be described as dependencies only, i.e. entity 1
power-up requires entity 2 to be powered first, also meaning that entity
2 could be powered down only after entity 1 has been powered down?

This type of restrictions would fit quite well to the current model as
it would essentially mean just media_entity_get() for the dependent
entities, and media_entity_put() when the original entity is powered
down. This would work recursively.

In the case of audio, most if not all devices (right?) would be always
powered up in certain order. At the same time this would be good for the
flash in torch mode case.


Comments, opinions? :-)


Best regards,

-- 
Sakari Ailus
sakari.ailus@maxwell.research.nokia.com

  reply	other threads:[~2010-11-25 17:49 UTC|newest]

Thread overview: 63+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-25  2:28 [RFC/PATCH v6 00/12] Media controller (core and V4L2) Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 01/12] media: Media device node support Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 02/12] media: Media device Laurent Pinchart
2010-11-25  9:33   ` Clemens Ladisch
2010-11-25 14:42     ` Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 03/12] media: Entities, pads and links Laurent Pinchart
2010-11-25  9:38   ` Clemens Ladisch
2010-11-25 13:41     ` Mark Brown
2010-11-25 15:29       ` [RFC/PATCH v6 03/12] [alsa-devel] " Laurent Pinchart
2010-11-25 15:35         ` [RFC/PATCH v6 03/12] " Mark Brown
2010-11-25 15:21     ` [RFC/PATCH v6 03/12] [alsa-devel] " Laurent Pinchart
2010-11-25 15:28       ` [RFC/PATCH v6 03/12] " Mark Brown
2010-11-26  9:10       ` Clemens Ladisch
2010-12-13 16:10         ` Clemens Ladisch
2010-12-14 12:00           ` [alsa-devel] " Laurent Pinchart
2010-12-14 12:40             ` Hans Verkuil
2010-12-14 12:53               ` Laurent Pinchart
2010-12-14 13:49                 ` Clemens Ladisch
2010-12-14 23:50                   ` Laurent Pinchart
2010-12-21 16:49                     ` [alsa-devel] " Hans Verkuil
2010-12-14 13:31             ` Clemens Ladisch
2010-12-14 13:54               ` Takashi Iwai
2010-12-14 14:25               ` Laurent Pinchart
2010-12-14 15:30                 ` Clemens Ladisch
2010-12-14 14:51               ` [alsa-devel] " Hans Verkuil
2010-12-14 14:57                 ` Laurent Pinchart
2010-12-14 14:49           ` [alsa-devel] " Sakari Ailus
2010-11-25 13:36   ` Mark Brown
2010-11-25 15:40     ` Laurent Pinchart
2010-11-25 15:49       ` Mark Brown
2010-11-26 14:13         ` Laurent Pinchart
2010-11-26 14:14           ` Mark Brown
2010-11-28 12:34             ` Laurent Pinchart
2010-11-28 15:57               ` Hans Verkuil
2010-11-25  2:28 ` [RFC/PATCH v6 04/12] media: Entity graph traversal Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 05/12] media: Reference count and power handling Laurent Pinchart
2010-11-25 13:49   ` Mark Brown
2010-11-25 15:43     ` Laurent Pinchart
2010-11-25 17:49       ` Sakari Ailus [this message]
2010-11-25 21:47         ` Mark Brown
2010-11-28 12:33           ` Laurent Pinchart
2010-11-28 18:25             ` Mark Brown
2010-11-25  2:28 ` [RFC/PATCH v6 06/12] media: Media device information query Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 07/12] media: Entities, pads and links enumeration Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 08/12] media: Links setup Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 09/12] media: Entity locking and pipeline management Laurent Pinchart
2010-11-25 13:53   ` Mark Brown
2010-11-25 15:47     ` Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 10/12] v4l: Add a media_device pointer to the v4l2_device structure Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 11/12] v4l: Make video_device inherit from media_entity Laurent Pinchart
2010-11-25 11:38   ` Hans Verkuil
2010-11-25 14:37     ` Laurent Pinchart
2010-11-25  2:28 ` [RFC/PATCH v6 12/12] v4l: Make v4l2_subdev " Laurent Pinchart
2010-11-25 14:28 ` [RFC/PATCH v6 00/12] Media controller (core and V4L2) Mark Brown
2010-11-26 14:07   ` Laurent Pinchart
     [not found] ` <201012031119.36771.laurent.pinchart@ideasonboard.com>
     [not found]   ` <201012031306.18520.hverkuil@xs4all.nl>
2010-12-03 13:50     ` [RFC/PATCH v6 03/12] media: Entities, pads and links Laurent Pinchart
2010-12-03 14:54       ` Mark Brown
2010-12-07 17:13         ` Hans Verkuil
2010-12-07 17:55           ` Mark Brown
2010-12-07 18:11             ` Hans Verkuil
2010-12-07 19:03               ` Mark Brown
2010-12-09 12:53                 ` Laurent Pinchart
2010-12-10 16:35                 ` Sakari Ailus

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=4CEEA191.1000706@maxwell.research.nokia.com \
    --to=sakari.ailus@maxwell.research.nokia.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=lennart@poettering.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-media@vger.kernel.org \
    --cc=linux-omap@vger.kernel.org \
    --cc=lrg@slimlogic.co.uk \
    /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