All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dmitry Torokhov <dmitry.torokhov@gmail.com>
To: Ulf Hansson <ulf.hansson@linaro.org>
Cc: Kevin Hilman <khilman@kernel.org>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Len Brown <len.brown@intel.com>, Pavel Machek <pavel@ucw.cz>,
	"linux-pm@vger.kernel.org" <linux-pm@vger.kernel.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	linux-samsung-soc <linux-samsung-soc@vger.kernel.org>,
	Geert Uytterhoeven <geert+renesas@glider.be>,
	Alan Stern <stern@rowland.harvard.edu>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Tomasz Figa <tomasz.figa@gmail.com>,
	Simon Horman <horms@verge.net.au>,
	Magnus Damm <magnus.damm@gmail.com>,
	Ben Dooks <ben-linux@fluff.org>,
	Kukjin Kim <kgene.kim@samsung.com>,
	Philipp Zabel <philipp.zabel@gmail.com>,
	Mark Brown <broonie@kernel.org>, Wolfram Sang <wsa@the-dreams.de>,
	Russell King <linux@arm.linux.org.uk>,
	Jack Dai <jack.dai@rock-chips.com>,
	Jinkun Hong <jinkun.hong@rock-chips.com>,
	Aaron
Subject: Re: [PATCH] PM / Domains: Fix initial default state of the need_restore flag
Date: Mon, 10 Nov 2014 10:32:24 -0800	[thread overview]
Message-ID: <20141110183224.GA5626@dtor-ws> (raw)
In-Reply-To: <CAPDyKFot-LZjazq190cY3-tawB_-ukdsmrLcD3vtidLvX68FOg@mail.gmail.com>

On Mon, Nov 10, 2014 at 04:18:50PM +0100, Ulf Hansson wrote:
> [...]
> 
> > I guess we do need it for 3.18, but when we are talking about 3.19,
> > before we make any more changes can we outline how power domains are
> > supposed to work?
> >
> > 1. How do we attach a device to power domain? Right now it seems that
> > individual buses are responsible for attaching their devices to power
> > domains. Should we move it into driver core (device_pm_add?) so that
> > device starts its life in its proper power domain?
> 
> That was the initial approach.
> 
> To my understanding, Rafael's primary reason for not accepting that
> was that it's not common, but it's platform-specific.
> http://marc.info/?l=linux-pm&m=140243462304669&w=2

I am not sure I agree with Rafael there:

 - when we are talking about the latest incarnation of power domains it
   is not really platform specific anymore (as it was when we were
   dealing with ACPI only case);

- I do not see why sirincling platform specific code around i2c, spi,
  etc bus code (which is not platform-specific) is OK, but a no-no for
  the driver ocre.

> 
> Now, even if we would reconsider doing as you propose, what would the
> actual benefit be? Obviously, we would get less amount of code to
> maintain, which is one reason, but are there more?

I think so - you would have complete picture of your power domain,
including data exposed in debugfs, etc.

> 
> >
> > 2. When do we power up the devices (and the domains)? Right now devices
> > in ACPI power domain are powered when they are attached to the power
> > domain (which coincides with probing), but generic power domains do not
> > do that. Can we add a separate API to explicitly power up the device (and
> > its domain if it is powered down) and do it again, either in device core
> > or in individual buses. This way, regardless of runtime PM or not, we
> > will have devices powered on when driver tries to bind to them. If
> > binding fails we can power down the device.
> 
> Isn't that exactly what I implemented in [1], what am I missing?

Hm, OK. I guess the title of the patch series thrown me off because as
far as I am concerned it is not a race, we simply were not powering the
domain properly for probing.

Thanks.

-- 
Dmitry

WARNING: multiple messages have this Message-ID (diff)
From: dmitry.torokhov@gmail.com (Dmitry Torokhov)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] PM / Domains: Fix initial default state of the need_restore flag
Date: Mon, 10 Nov 2014 10:32:24 -0800	[thread overview]
Message-ID: <20141110183224.GA5626@dtor-ws> (raw)
In-Reply-To: <CAPDyKFot-LZjazq190cY3-tawB_-ukdsmrLcD3vtidLvX68FOg@mail.gmail.com>

On Mon, Nov 10, 2014 at 04:18:50PM +0100, Ulf Hansson wrote:
> [...]
> 
> > I guess we do need it for 3.18, but when we are talking about 3.19,
> > before we make any more changes can we outline how power domains are
> > supposed to work?
> >
> > 1. How do we attach a device to power domain? Right now it seems that
> > individual buses are responsible for attaching their devices to power
> > domains. Should we move it into driver core (device_pm_add?) so that
> > device starts its life in its proper power domain?
> 
> That was the initial approach.
> 
> To my understanding, Rafael's primary reason for not accepting that
> was that it's not common, but it's platform-specific.
> http://marc.info/?l=linux-pm&m=140243462304669&w=2

I am not sure I agree with Rafael there:

 - when we are talking about the latest incarnation of power domains it
   is not really platform specific anymore (as it was when we were
   dealing with ACPI only case);

- I do not see why sirincling platform specific code around i2c, spi,
  etc bus code (which is not platform-specific) is OK, but a no-no for
  the driver ocre.

> 
> Now, even if we would reconsider doing as you propose, what would the
> actual benefit be? Obviously, we would get less amount of code to
> maintain, which is one reason, but are there more?

I think so - you would have complete picture of your power domain,
including data exposed in debugfs, etc.

> 
> >
> > 2. When do we power up the devices (and the domains)? Right now devices
> > in ACPI power domain are powered when they are attached to the power
> > domain (which coincides with probing), but generic power domains do not
> > do that. Can we add a separate API to explicitly power up the device (and
> > its domain if it is powered down) and do it again, either in device core
> > or in individual buses. This way, regardless of runtime PM or not, we
> > will have devices powered on when driver tries to bind to them. If
> > binding fails we can power down the device.
> 
> Isn't that exactly what I implemented in [1], what am I missing?

Hm, OK. I guess the title of the patch series thrown me off because as
far as I am concerned it is not a race, we simply were not powering the
domain properly for probing.

Thanks.

-- 
Dmitry

  reply	other threads:[~2014-11-10 18:32 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-11-07 13:27 [PATCH] PM / Domains: Fix initial default state of the need_restore flag Ulf Hansson
2014-11-07 13:27 ` Ulf Hansson
2014-11-07 18:52 ` Sylwester Nawrocki
2014-11-07 18:52   ` Sylwester Nawrocki
2014-11-07 19:47 ` Kevin Hilman
2014-11-07 19:47   ` Kevin Hilman
2014-11-07 21:57   ` Dmitry Torokhov
2014-11-07 21:57     ` Dmitry Torokhov
2014-11-07 22:26     ` Kevin Hilman
2014-11-07 22:26       ` Kevin Hilman
2014-11-10 15:18     ` Ulf Hansson
2014-11-10 15:18       ` Ulf Hansson
2014-11-10 18:32       ` Dmitry Torokhov [this message]
2014-11-10 18:32         ` Dmitry Torokhov
2014-11-10 19:39         ` Mark Brown
2014-11-10 19:39           ` Mark Brown
2014-11-10 20:33           ` Dmitry Torokhov
2014-11-10 20:33             ` Dmitry Torokhov
2014-11-13  2:52       ` Rafael J. Wysocki
2014-11-13 16:40         ` Ulf Hansson
2014-11-13 19:14           ` Grygorii Strashko
2014-11-13 21:59           ` Ulf Hansson
2014-11-13 17:50         ` Grygorii Strashko
2014-11-13 17:54           ` Mark Brown
2014-11-13 19:07             ` Grygorii Strashko
2014-11-13 19:11               ` Mark Brown
2014-11-13 20:22                 ` Grygorii Strashko
2014-11-14 19:16         ` Kevin Hilman
2014-11-14 23:45           ` Rafael J. Wysocki
2014-11-08  0:58 ` Rafael J. Wysocki
2014-11-08  0:58   ` Rafael J. Wysocki
  -- strict thread matches above, loose matches on Subject: below --
2014-11-10  9:24 Ulf Hansson
2014-11-10  9:24 ` Ulf Hansson

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=20141110183224.GA5626@dtor-ws \
    --to=dmitry.torokhov@gmail.com \
    --cc=ben-linux@fluff.org \
    --cc=broonie@kernel.org \
    --cc=geert+renesas@glider.be \
    --cc=gregkh@linuxfoundation.org \
    --cc=horms@verge.net.au \
    --cc=jack.dai@rock-chips.com \
    --cc=jinkun.hong@rock-chips.com \
    --cc=kgene.kim@samsung.com \
    --cc=khilman@kernel.org \
    --cc=len.brown@intel.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=linux-samsung-soc@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=magnus.damm@gmail.com \
    --cc=pavel@ucw.cz \
    --cc=philipp.zabel@gmail.com \
    --cc=rjw@rjwysocki.net \
    --cc=stern@rowland.harvard.edu \
    --cc=tomasz.figa@gmail.com \
    --cc=ulf.hansson@linaro.org \
    --cc=wsa@the-dreams.de \
    /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.