All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.