From: Catalin Marinas <catalin.marinas@arm.com>
To: Michael Bohan <mbohan@codeaurora.org>
Cc: Zhou Zhu <zzhu3@marvell.com>, Bin Wang <binw@marvell.com>,
Chao Xie <cxie4@marvell.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Leo Yan <leoy@marvell.com>,
"linux-arm-msm@vger.kernel.org" <linux-arm-msm@vger.kernel.org>
Subject: Re: memcpy alignment for DEVICE_nGnRnE
Date: Wed, 9 Apr 2014 09:17:05 +0100 [thread overview]
Message-ID: <20140409081705.GB13737@arm.com> (raw)
In-Reply-To: <20140408233937.GA2100@codeaurora.org>
On Wed, Apr 09, 2014 at 12:39:37AM +0100, Michael Bohan wrote:
> On Tue, Apr 08, 2014 at 12:49:49PM +0100, Catalin Marinas wrote:
> > On Tue, Apr 08, 2014 at 01:35:47AM +0100, Michael Bohan wrote:
> > > How should we handle Device Memory with copy_from_user / copy_to_user?
> > > Should we follow the same scheme and create
> > > copy_from_user_io / copy_to_user_io, or rather enforce that the stock
> > > routines handle alignment?
> >
> > We have generic copy_from_user_toio() and copy_to_user_fromio(). Are
> > these what you need? As with the memcpy_(to|from)io, they can be further
> > optimised.
>
> It seems these existing routines are in sound. Were you thinking
> the right approach would be to move them out of sound and make
> them per-arch defined?
If you have a use-case outside of the sound subsystem, they can be made
more generic.
> What about the other two use cases: copy_from_user_fromio and
> copy_to_user_toio? Are those reasonable to add? These two APIs
> would cover the use case I had in mind.
What's the use case for these?
> Then what about the strange but possible use case where both the
> source and destination pointers are iomem? This same question
> applies for memcpy_fromio / memcpy_toio as well.
You can come up with many combinations but we first need to see a real
use of them, eliminate the alternatives and only then look at adding new
API.
> The implementations of copy_from_user_toio and
> copy_to_user_fromio are currently doing a second copy, so that
> seems bad for performance. We'd probably want to improve these as
> well if others are in agreement.
Yes, as I said they are not optimised (but good enough as a start).
--
Catalin
WARNING: multiple messages have this Message-ID (diff)
From: catalin.marinas@arm.com (Catalin Marinas)
To: linux-arm-kernel@lists.infradead.org
Subject: memcpy alignment for DEVICE_nGnRnE
Date: Wed, 9 Apr 2014 09:17:05 +0100 [thread overview]
Message-ID: <20140409081705.GB13737@arm.com> (raw)
In-Reply-To: <20140408233937.GA2100@codeaurora.org>
On Wed, Apr 09, 2014 at 12:39:37AM +0100, Michael Bohan wrote:
> On Tue, Apr 08, 2014 at 12:49:49PM +0100, Catalin Marinas wrote:
> > On Tue, Apr 08, 2014 at 01:35:47AM +0100, Michael Bohan wrote:
> > > How should we handle Device Memory with copy_from_user / copy_to_user?
> > > Should we follow the same scheme and create
> > > copy_from_user_io / copy_to_user_io, or rather enforce that the stock
> > > routines handle alignment?
> >
> > We have generic copy_from_user_toio() and copy_to_user_fromio(). Are
> > these what you need? As with the memcpy_(to|from)io, they can be further
> > optimised.
>
> It seems these existing routines are in sound. Were you thinking
> the right approach would be to move them out of sound and make
> them per-arch defined?
If you have a use-case outside of the sound subsystem, they can be made
more generic.
> What about the other two use cases: copy_from_user_fromio and
> copy_to_user_toio? Are those reasonable to add? These two APIs
> would cover the use case I had in mind.
What's the use case for these?
> Then what about the strange but possible use case where both the
> source and destination pointers are iomem? This same question
> applies for memcpy_fromio / memcpy_toio as well.
You can come up with many combinations but we first need to see a real
use of them, eliminate the alternatives and only then look at adding new
API.
> The implementations of copy_from_user_toio and
> copy_to_user_fromio are currently doing a second copy, so that
> seems bad for performance. We'd probably want to improve these as
> well if others are in agreement.
Yes, as I said they are not optimised (but good enough as a start).
--
Catalin
next prev parent reply other threads:[~2014-04-09 8:17 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <53072343.4080505@marvell.com>
2014-02-21 10:53 ` memcpy alignment for DEVICE_nGnRnE Catalin Marinas
2014-04-08 0:35 ` Michael Bohan
2014-04-08 0:35 ` Michael Bohan
2014-04-08 11:49 ` Catalin Marinas
2014-04-08 11:49 ` Catalin Marinas
2014-04-08 23:39 ` Michael Bohan
2014-04-08 23:39 ` Michael Bohan
2014-04-09 8:17 ` Catalin Marinas [this message]
2014-04-09 8:17 ` Catalin Marinas
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=20140409081705.GB13737@arm.com \
--to=catalin.marinas@arm.com \
--cc=binw@marvell.com \
--cc=cxie4@marvell.com \
--cc=leoy@marvell.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=mbohan@codeaurora.org \
--cc=zzhu3@marvell.com \
/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.