From: will.deacon@arm•com (Will Deacon)
To: linux-arm-kernel@lists•infradead.org
Subject: [PATCH] arm64: optimize memcpy_{from,to}io() and memset_io()
Date: Mon, 4 Aug 2014 10:57:19 +0100 [thread overview]
Message-ID: <20140804095719.GE15117@arm.com> (raw)
In-Reply-To: <20140802013834.GA23206@codeaurora.org>
On Sat, Aug 02, 2014 at 02:38:34AM +0100, Joonwoo Park wrote:
> On Fri, Aug 01, 2014 at 09:32:46AM +0100, Will Deacon wrote:
> > On Fri, Aug 01, 2014 at 07:30:09AM +0100, Joonwoo Park wrote:
> > > On Tue, Jul 29, 2014 at 11:28:26PM -0700, Joonwoo Park wrote:
> > > > Optimize memcpy_{from,to}io() and memset_io() by transferring in 64 bit
> > > > as much as possible with minimized barrier usage. This simplest optimization
> > > > brings faster throughput compare to current byte-by-byte read and write with
> > > > barrier in the loop. Code's skeleton is taken from the powerpc.
> >
> > Hmm, I've never really understood the use-case for memcpy_{to,from}io on
> > ARM, so getting to the bottom of that would help in reviewing this patch.
> >
> > Can you point me at the drivers which are using this for ARM please? Doing a
> Sure. This peripheral-loader.c driver now moved under drivers/soc/ so it
> can be used for ARM and ARM64.
> https://android.googlesource.com/kernel/msm.git/+/db34f44bcba24345d26b8a4b8137cf94d70afa73/arch/arm/mach-msm/peripheral-loader.c
> static int load_segment(const struct elf32_phdr *phdr, unsigned num, struct pil_device *pil)
> {
> <snip>
> while (count > 0) {
> int size;
> u8 __iomem *buf;
> size = min_t(size_t, IOMAP_SIZE, count);
> buf = ioremap(paddr, size);
> }
> <snip>
> memset(buf, 0, size);
> <snip>
Right, but that code doesn't exist in mainline afaict.
> As you can see the function load_segment() does ioremap() followed by
> memset() and memcpy() which can cause unaligned multi-byte (maybe ARM64
> traps 8byte unaligned access?) write to device memory.
> Because of this I was fixing the driver to use memset_io() and memcpy_io()
> but the existing implementations were too slow compare to the one I'm
> proposing.
>
> > blind byte-by-byte copy could easily cause problems with some peripherals,
> > so there must be an underlying assumption somewhere about how this is
> > supposed to work.
> Would you mind to explain more about the problem with byte-by-byte copying
> you're worried about?
> I thought byte-by-byte copy always safe with regard to aligned access and
> that's the reason existing implementation does byte-by-byte copy.
> I can imagine there are some peripherals don't allow per-byte access. But
> if that is the case, should they not use memset_io() and
> memcpy_{from,to}io() anyway?
Yes, if somebody tried to use memset_io to zero a bunch of control
registers, for example, you'd likely get a bunch of aborts because the
endpoint would give you a SLVERR for a byte-access to a word register.
It just seems like the expected usage of this function should be documented
somewhere to avoid it becoming highly dependent on the architecture.
Will
next prev parent reply other threads:[~2014-08-04 9:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-07-30 6:28 [PATCH] arm64: optimize memcpy_{from,to}io() and memset_io() Joonwoo Park
2014-08-01 6:30 ` Joonwoo Park
2014-08-01 8:32 ` Will Deacon
2014-08-02 1:38 ` Joonwoo Park
2014-08-04 9:57 ` Will Deacon [this message]
2014-10-03 16:31 ` Catalin Marinas
2014-10-09 2:39 ` Joonwoo Park
2014-10-09 10:16 ` Catalin Marinas
2014-10-14 4:04 ` Joonwoo Park
2014-10-14 4:12 ` Joonwoo Park
2014-10-20 13:33 ` Catalin Marinas
-- strict thread matches above, loose matches on Subject: below --
2014-10-21 0:59 Joonwoo Park
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=20140804095719.GE15117@arm.com \
--to=will.deacon@arm$(echo .)com \
--cc=linux-arm-kernel@lists$(echo .)infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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