All of lore.kernel.org
 help / color / mirror / Atom feed
From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v9] mfd: Add anatop mfd driver
Date: Thu, 15 Mar 2012 15:52:54 +0000	[thread overview]
Message-ID: <201203151552.54617.arnd@arndb.de> (raw)
In-Reply-To: <20120315120948.GG3138@opensource.wolfsonmicro.com>

On Thursday 15 March 2012, Mark Brown wrote:
> There were some other mutterings about using regmap for memory mapped
> devices, mostly from the point of view of building framework features
> like this on top of it.  regmap currently makes some assumptions that
> the I/O is going to be slow so approximately any amount of CPU time can
> usefully be spent on avoiding I/O but we can probably do something about
> that.  It also uses mutexes to lock I/O which might not be the most
> sensible thing for memory mapped devices, but again that's solveable.
> Right now there's no memory mapping support but there's no reason that
> can't be added.
> 
> In short, it does seem sensible to want to have some support for this
> for devices that use appropriate idioms.

Ok, I see. 

I guess there is no reason to change anything in Paul's patch now, but
we can keep this in mind if we see a lot of similar drivers in the future.

Thanks,

	Arnd

WARNING: multiple messages have this Message-ID (diff)
From: Arnd Bergmann <arnd@arndb.de>
To: linux-arm-kernel@lists.infradead.org
Cc: Mark Brown <broonie@opensource.wolfsonmicro.com>,
	linaro-dev@lists.linaro.org, Samuel Ortiz <sameo@linux.intel.com>,
	patches@linaro.org, linux-kernel@vger.kernel.org,
	Venu Byravarasu <vbyravarasu@nvidia.com>,
	Peter Korsgaard <jacmet@sunsite.dk>,
	"Ying-Chun Liu \(PaulLiu\)" <paul.liu@linaro.org>
Subject: Re: [PATCH v9] mfd: Add anatop mfd driver
Date: Thu, 15 Mar 2012 15:52:54 +0000	[thread overview]
Message-ID: <201203151552.54617.arnd@arndb.de> (raw)
In-Reply-To: <20120315120948.GG3138@opensource.wolfsonmicro.com>

On Thursday 15 March 2012, Mark Brown wrote:
> There were some other mutterings about using regmap for memory mapped
> devices, mostly from the point of view of building framework features
> like this on top of it.  regmap currently makes some assumptions that
> the I/O is going to be slow so approximately any amount of CPU time can
> usefully be spent on avoiding I/O but we can probably do something about
> that.  It also uses mutexes to lock I/O which might not be the most
> sensible thing for memory mapped devices, but again that's solveable.
> Right now there's no memory mapping support but there's no reason that
> can't be added.
> 
> In short, it does seem sensible to want to have some support for this
> for devices that use appropriate idioms.

Ok, I see. 

I guess there is no reason to change anything in Paul's patch now, but
we can keep this in mind if we see a lot of similar drivers in the future.

Thanks,

	Arnd

  reply	other threads:[~2012-03-15 15:52 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-03-15  7:43 [PATCH v9] mfd: Add anatop mfd driver Ying-Chun Liu (PaulLiu)
2012-03-15  7:43 ` Ying-Chun Liu (PaulLiu)
2012-03-15  9:07 ` Arnd Bergmann
2012-03-15  9:07   ` Arnd Bergmann
2012-03-15 12:09   ` Mark Brown
2012-03-15 12:09     ` Mark Brown
2012-03-15 15:52     ` Arnd Bergmann [this message]
2012-03-15 15:52       ` Arnd Bergmann

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=201203151552.54617.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-arm-kernel@lists.infradead.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.