From: Mark Rutland <mark.rutland@arm.com>
To: Rich Felker <dalias@libc.org>
Cc: devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-sh@vger.kernel.org,
Ian Campbell <ijc+devicetree@hellion.org.uk>,
Kumar Gala <galak@codeaurora.org>,
Pawel Moll <pawel.moll@arm.com>, Rob Herring <robh+dt@kernel.org>
Subject: Re: [PATCH v3 02/12] of: add J-Core cpu bindings
Date: Fri, 27 May 2016 10:13:59 +0100 [thread overview]
Message-ID: <20160527091359.GA24469@leverpostej> (raw)
In-Reply-To: <20160526153323.GX21636@brightrain.aerifal.cx>
On Thu, May 26, 2016 at 11:33:23AM -0400, Rich Felker wrote:
> On Thu, May 26, 2016 at 11:38:29AM +0100, Mark Rutland wrote:
> > On Wed, May 25, 2016 at 07:04:08PM -0400, Rich Felker wrote:
> > > On Wed, May 25, 2016 at 11:22:15AM +0100, Mark Rutland wrote:
> > > > * How must the value be written?
> > > > - Which endianness?
> > >
> > > CPU native.
> >
> > Ok. I take it that a CPU's endianness cannot be switched onthe fly,
> > then? Or does the hardware backing the release-addr register handle
> > arbitrary endianness dynamically?
>
> No, it's not switched on the fly.
>
> > If you want to reuse the same HW block across configurations where CPU
> > endianness differs, it may make sense to define an endianness
> > regardless, to simplify integration concerns.
>
> The existing cpus are all big-endian, but I believe at one point there
> was talk that it's easy to get a little-endian version if you want. In
> any case the value is to be read by the cpu, so cpu endianness (i.e.
> no endianness, just a value) is the only thing that makes sense to
> specify. Adding a fixed endian spec independent of cpu endianness just
> complicates both hardware and kernel implementation and its only
> benefit seems to be supporting runtime-switchable chips where the
> entry-point code has to select the endianness to match the rest of the
> kernel.
Sure. If endianness isn't runtime switchable, and there is no near-term
plan to add that, then my concerns do not apply.
[...]
> > If you do /memreserve/ the region rather than carving it out of memory
> > nodes, you will also need to define semantics for memreserve. Typically
> > memreserve meaans that the OS should not perform any stores to the
> > region, but is permitted to map it with some architecture-specific
> > cacheable attributes.
>
> My interpretation of memreserve is just that it marks memory ranges
> that the kernel cannot use for allocatable memory for its own
> purposes, despite otherwise possibly lying in the range of a "memory"
> node. I would not interpret it as excluding accesses by drivers that
> were told to use specific addresses in the "reserved" range as part of
> their DT bindings.
Yes, this is strictly more correct than my wording.
Given the lack of MMU or cache configration beynd on/off, it doesn't
sound like there are any arch-specific memory attribute rules to
document.
[...]
> > My questions about SMP are largely orthogonal to DT; I simply have
> > experience in dealing with that for arm64, and am aware of some of the
> > pain points that were not immediately obvious.
>
> OK, thanks for clarifying that. This is actually really helpful
> feedback to have but I wasn't sure if you wanted me to consider it
> part of what needs to be done for DT binding or for consideration in
> designing and documenting the SMP architecture.
Sorry for that; in retrospect I probably should have sent the boot
protocol comments as a separate reply.
[...]
> OK. I'll strip it down to just the parts that are relevant for non-SMP
> and submit the patch adding SMP bindings along with the SMP kernel
> patches.
That sounds good to me.
Thanks,
Mark,
next prev parent reply other threads:[~2016-05-27 9:14 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-25 5:43 [PATCH v3 00/12] J-core J2 cpu and SoC peripherals support Rich Felker
2016-05-25 5:43 ` [PATCH v3 01/12] of: add vendor prefix for J-Core Rich Felker
2016-05-25 13:18 ` Rob Herring
2016-07-27 5:31 ` Rich Felker
2016-08-04 22:27 ` Rich Felker
2016-08-30 21:13 ` Rob Herring
2016-05-25 5:43 ` [PATCH v3 12/12] sh: add device tree source for J2 FPGA on Mimas v2 board Rich Felker
2016-05-25 10:33 ` Mark Rutland
2016-05-25 23:15 ` Rich Felker
2016-05-26 10:39 ` Mark Rutland
2016-05-25 5:43 ` [PATCH v3 02/12] of: add J-Core cpu bindings Rich Felker
2016-05-25 10:22 ` Mark Rutland
2016-05-25 23:04 ` Rich Felker
2016-05-26 7:54 ` Geert Uytterhoeven
2016-05-26 10:38 ` Mark Rutland
2016-05-26 15:33 ` Rich Felker
2016-05-27 9:13 ` Mark Rutland [this message]
2016-05-26 21:44 ` Rob Landley
2016-05-27 11:51 ` Afzal Mohammed
2016-05-25 5:43 ` [PATCH v3 09/12] clocksource: add J-Core timer/clocksource driver Rich Felker
2016-05-25 5:43 ` [PATCH v3 03/12] of: add J-Core interrupt controller bindings Rich Felker
2016-05-25 10:25 ` Mark Rutland
2016-05-25 23:08 ` Rich Felker
2016-05-25 5:43 ` [PATCH v3 11/12] sh: add defconfig for J-Core J2 Rich Felker
2016-05-25 5:43 ` [PATCH v3 07/12] sh: add AT_HWCAP flag for J-Core cas.l instruction Rich Felker
2016-05-25 5:43 ` [PATCH v3 10/12] spi: add driver for J-Core SPI controller Rich Felker
2016-05-25 10:17 ` Mark Brown
2016-05-27 1:16 ` Rich Felker
2016-05-27 11:27 ` Mark Brown
2016-05-25 5:43 ` [PATCH v3 04/12] of: add J-Core timer bindings Rich Felker
2016-06-01 13:58 ` Rob Herring
2016-06-01 17:53 ` Rich Felker
2016-06-01 21:53 ` Rich Felker
2016-06-01 22:36 ` Rob Herring
2016-06-02 1:34 ` Rich Felker
2016-06-02 22:44 ` Rob Herring
2016-06-23 21:16 ` Rich Felker
2016-07-14 22:18 ` Rich Felker
2016-05-25 5:43 ` [PATCH v3 05/12] of: add J-Core SPI master bindings Rich Felker
2016-05-25 19:04 ` Rob Herring
2016-05-25 5:43 ` [PATCH v3 06/12] sh: add support for J-Core J2 processor Rich Felker
2016-05-25 5:43 ` [PATCH v3 08/12] irqchip: add J-Core AIC driver Rich Felker
2016-07-15 1:27 ` Rich Felker
2016-07-15 18:19 ` Rich Felker
2016-07-15 15:35 ` Paul Gortmaker
2016-07-15 15:41 ` Rich Felker
2016-07-15 16:19 ` Jason Cooper
2016-07-15 17:02 ` Rich Felker
2016-05-25 7:22 ` [PATCH v3 00/12] J-core J2 cpu and SoC peripherals support Geert Uytterhoeven
2016-05-25 9:54 ` Mark Brown
2016-05-25 22:24 ` Rich Felker
2016-05-26 0:42 ` Mark Brown
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=20160527091359.GA24469@leverpostej \
--to=mark.rutland@arm.com \
--cc=dalias@libc.org \
--cc=devicetree@vger.kernel.org \
--cc=galak@codeaurora.org \
--cc=ijc+devicetree@hellion.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sh@vger.kernel.org \
--cc=pawel.moll@arm.com \
--cc=robh+dt@kernel.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).