From: will.deacon@arm.com (Will Deacon)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions
Date: Mon, 20 May 2013 17:04:07 +0100 [thread overview]
Message-ID: <20130520160407.GS31359@mudshark.cambridge.arm.com> (raw)
In-Reply-To: <20130520151158.GA3520@MacBook-Pro.local>
On Mon, May 20, 2013 at 04:11:58PM +0100, Catalin Marinas wrote:
> On Mon, May 20, 2013 at 03:24:59PM +0100, Will Deacon wrote:
> > On Mon, May 20, 2013 at 03:18:09PM +0100, Catalin Marinas wrote:
> > > As I mentioned in the past, I don't agree with exposing the "LPAE"
> > > feature to user-space, it's not a feature that user space should care
> > > about. An atomic double hwcap is better and you can even make this per
> > > CPU via __v7_proc.
> >
> > I don't buy the argument that this could be per-CPU: doubleword atomicity
> > requires support in the whole system -- not just in the CPU. The only way we
> > can rely on it, is by guarantees made in the architecture, which are made
> > as part of LPAE.
>
> Well, you know that for A7/A15 you have this feature as they support
> LPAE. You can have it as a generic LPAE test (only that the ARM ARM
> isn't entirely clear here, so for people asking in the future we could
> say it's a feature of the A7/A15/etc.)
No, as far as Linux is concerned, it's a feature of any system claiming to
have support for LPAE. Given that we allocate page tables using our usual
allocators, all memory that we map as normal must be capable of doubleword
atomics. We make use of this in our atomic64_{read,set} implementations.
> > If this just boils down to a naming issue, thn I'm happy to change it, but
> > we *are* reporting whether LPAE is supported and I can't think of a better
> > name than that.
>
> Given that the ARM ARM isn't clear (though this is the case on the
> actual implementations), user space may not necessarily assume that
> LPAE==atomic doubles. That's why I think reporting the actual atomic
> feature is better.
The ARM ARM isn't too bad: it's just avoiding mandating 64-bit-wide paths
around the entire SoC (and I've checked this with the architects). The only
way we can probe this feature is using the MMFR0 and checking if LPAE is
supported, and that's exactly what userspace will need to rely on. We can
change the name, but the probe code will remain the same so I'm not sure it
makes anything clearer. We had "atomicd" originally, but that sounds like a
techno band.
Will
next prev parent reply other threads:[~2013-05-20 16:04 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-05-17 17:07 [PATCH 00/14] Random LPAE-related patches Will Deacon
2013-05-17 17:07 ` [PATCH 01/14] ARM: LPAE: use signed arithmetic for mask definitions Will Deacon
2013-05-17 17:07 ` [PATCH 02/14] ARM: LPAE: use phys_addr_t in alloc_init_pud() Will Deacon
2013-05-17 17:07 ` [PATCH 03/14] ARM: LPAE: use phys_addr_t in free_memmap() Will Deacon
2013-05-17 17:07 ` [PATCH 04/14] ARM: LPAE: use phys_addr_t for initrd location Will Deacon
2013-05-17 17:07 ` [PATCH 05/14] ARM: LPAE: use phys_addr_t in switch_mm() Will Deacon
2013-05-17 17:07 ` [PATCH 06/14] ARM: LPAE: use 64-bit accessors for TTBR registers Will Deacon
2013-05-17 17:07 ` [PATCH 07/14] ARM: LPAE: factor out T1SZ and TTBR1 computations Will Deacon
2013-05-17 17:07 ` [PATCH 08/14] ARM: LPAE: accomodate >32-bit addresses for page table base Will Deacon
2013-05-17 17:07 ` [PATCH 09/14] ARM: mm: use physical addresses in highmem sanity checks Will Deacon
2013-05-17 17:07 ` [PATCH 10/14] ARM: fix type of PHYS_PFN_OFFSET to unsigned long Will Deacon
2013-05-17 17:07 ` [PATCH 11/14] ARM: mm: cleanup checks for membank overlap with vmalloc area Will Deacon
2013-05-17 17:07 ` [PATCH 12/14] ARM: mm: clean up membank size limit checks Will Deacon
2013-05-17 17:07 ` [PATCH 13/14] ARM: lpae: fix definition of PTE_HWTABLE_PTRS Will Deacon
2013-05-17 17:07 ` [PATCH 14/14] ARM: elf: add new hwcap for identifying atomic ldrd/strd instructions Will Deacon
2013-05-20 14:18 ` Catalin Marinas
2013-05-20 14:24 ` Will Deacon
2013-05-20 15:11 ` Catalin Marinas
2013-05-20 16:04 ` Will Deacon [this message]
2013-05-20 17:13 ` Catalin Marinas
2013-05-21 18:02 ` Will Deacon
2013-05-22 8:43 ` Catalin Marinas
2013-05-21 18:48 ` Rob Herring
2013-05-22 8:47 ` Catalin Marinas
2013-05-22 18:09 ` Will Deacon
2013-05-23 8:50 ` Catalin Marinas
2013-05-17 18:23 ` [PATCH 00/14] Random LPAE-related patches Santosh Shilimkar
2013-05-30 13:31 ` Subash Patel
2013-05-30 15:03 ` Will Deacon
2013-05-31 0:38 ` Kukjin Kim
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=20130520160407.GS31359@mudshark.cambridge.arm.com \
--to=will.deacon@arm.com \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).