public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mark Brown <broonie@opensource.wolfsonmicro.com>
To: Stephen Warren <swarren@wwwdotorg.org>
Cc: linux-kernel@vger.kernel.org, Stephen Warren <swarren@nvidia.com>
Subject: Re: [PATCH 5/6] regmap: add runtime PM calls to debugfs file IO
Date: Wed, 4 Apr 2012 23:19:21 +0100	[thread overview]
Message-ID: <20120404221920.GF10787@opensource.wolfsonmicro.com> (raw)
In-Reply-To: <1333576113-13196-5-git-send-email-swarren@wwwdotorg.org>

[-- Attachment #1: Type: text/plain, Size: 1300 bytes --]

On Wed, Apr 04, 2012 at 03:48:32PM -0600, Stephen Warren wrote:

> It's quite probably that devices need to be active in order for their
> registers to be read/written. In normal regmap usage by drivers, it's the
> responsibility of the driver to assure this if needed. However, regmap
> debugfs file handling is outside the driver's control, so we need to
> explicitly ensure this.

This feels wrong, it's too invasive on the device.  If we're in cache
only mode (which we should be if the device is off and we have a cache)
then I'd expect us to error out if we can't satisfy the read from cache
rather than wake the device up which might be terribly expensive and
cause register writes which change the device state we were trying to
inspect, and if we have a cache then we might not need to interact with
the hardware at all at which point the wakeup would've been needless.
It's certainly not what I'd expect a diagnostic interface to be doing,
I'd expect it to reflect the current state of the device.

Now, quite how the mmio bus deals with access to a suspended device is
probably platform specific and certainly more fun than at least I2C (SPI
has issues since it's hard to tell if the device is there or not and the
MISO line might be undriven but at least you'll not lock up or anything).

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

  reply	other threads:[~2012-04-04 22:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-04-04 21:48 [PATCH 1/6] regmap: introduce fast_io busses, and use a spinlock for them Stephen Warren
2012-04-04 21:48 ` [PATCH 2/6] regmap: allow regmap instances to be named Stephen Warren
2012-04-06  3:44   ` Paul Gortmaker
2012-04-06  5:12     ` Stephen Warren
2012-04-04 21:48 ` [PATCH 3/6] regmap: introduce explicit bus_context for bus callbacks Stephen Warren
2012-04-04 21:48 ` [PATCH 4/6] regmap: add MMIO bus support Stephen Warren
2012-04-04 22:59   ` Mark Brown
2012-04-04 23:15     ` Stephen Warren
2012-04-05  8:38       ` Mark Brown
2012-04-04 21:48 ` [PATCH 5/6] regmap: add runtime PM calls to debugfs file IO Stephen Warren
2012-04-04 22:19   ` Mark Brown [this message]
2012-04-04 21:48 ` [PATCH 6/6] regmap: prevent division by zero in rbtree_show Stephen Warren
2012-04-04 22:24   ` Mark Brown

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=20120404221920.GF10787@opensource.wolfsonmicro.com \
    --to=broonie@opensource.wolfsonmicro.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=swarren@nvidia.com \
    --cc=swarren@wwwdotorg.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