From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: Hector Martin <marcan@marcan.st>
Cc: devicetree@vger.kernel.org, arnd@kernel.org, maz@kernel.org,
linux-kernel@vger.kernel.org, soc@kernel.org, robh+dt@kernel.org,
olof@lixom.net, will@kernel.org,
linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it
Date: Wed, 10 Feb 2021 14:40:43 +0100 (CET) [thread overview]
Message-ID: <c1bc32139ad12bd8@bloch.sibelius.xs4all.nl> (raw)
In-Reply-To: <475f7586-cabf-1169-8800-cdd2c012a5a6@marcan.st> (message from Hector Martin on Wed, 10 Feb 2021 21:24:15 +0900)
> From: Hector Martin <marcan@marcan.st>
> Date: Wed, 10 Feb 2021 21:24:15 +0900
Hi Hector,
Since device tree bindings are widely used outside the Linux tree,
here are some thoughts from a U-Boot and OpenBSD perspective.
> Hi Will, I'm pulling you in at Marc's suggestion. Do you have an opinion
> on what the better solution to this problem is?
>
> The executive summary is that Apple SoCs require nGnRnE memory mappings
> for MMIO, except for PCI space which uses nGnRE. ARM64 currently uses
> nGnRE everywhere. Solutions discussed in this thread and elsewhere include:
>
> 1. Something similar to the current hacky patch (which isn't really
> intended as a real solution...); change ioremap to default to nGnRnE
> using some kind of platform-level flag in the DT, then figure out how to
> get the PCI drivers to bypass that. This requires changing almost every
> PCI driver, since most of them use plain ioremap().
>
> 2. A per-device DT property that tells of_address_to_resource to set a
> flag in the struct resource, which is then used by
> devm_ioremap_resource/of_iomap to pick a new ioremap_ variant for nGnRnE
> (introduce ioremap_np() for nonposted?) (PCI would work with this
> inasmuch as it would not support it, and thus fall back to the current
> nGnRE default, which is correct for PCI...). This requires changing
> DT-binding drivers that we depend on to not use plain ioremap() (if any
> do so), but that is a finite subset (unlike PCI which involves
> potentially every driver, because thunderbolt).
That solution is not dissimilar to how "dma-coherent", "big-endian"
and "little-endian" properties work. U-Boot could simply ignore the
property since it already has a memory map with the required memory
attributes for each SoC. I don't see any issue with this for the
OpenBSD kernel either.
The number of existing drivers that would need to be changed is small.
The dwc3 core driver already uses devm_ioremap_resource(). The nvme
driver uses plain ioremap() in the PCI-specific part of the driver,
but that will need new glue for a platform driver anyway.
As things stand now that leaves us with the samsung serial driver
which uses devm_ioremap(). That could be turned into a
devm_iomap_resource() without much trouble I think.
> 3. Encode the mapping type in the address of child devices, either
> abusing the high bits of the reg or introducing an extra DT cell there,
> introduce a new OF bus type that strips those away via a ranges mapping
> and sets flags in the struct resource, similar to what the PCI bus does
> with its 3-cell ranges, then do as (2) above and make
> devm_ioremap_resource/of_iomap use it:
>
> On 09/02/2021 07.57, Arnd Bergmann wrote:
> > #define MAP_NONPOSTED 0x80000000
> >
> > arm-io { /* name for adt, should be changed */
> > compatible = "apple,m1-internal-bus";
> > #address-cells = <2>; /* or maybe <3> if we want */
> > #size-cells = <2>;
> > ranges =
> > /* on-chip MMIO */
> > <(MAP_NONPOSTED | 0x2) 0x0 0x2 0x0 0x1 0x0>,
> >
> > /* first PCI: 2GB control, 4GB memory space */
> > <(MAP_NONPOSTED | 0x3) 0x80000000 0x3 0x80000000 0x0 0x80000000>,
> > <0x4 0x0 0x4 0x0 0x1 0x0>,
> [...]
>
> > The MAP_NONPOSTED flag then gets interpreted by the .translate() and
> > .get_flags() callbacks of "struct of_bus" in the kernel, where it is put into
> > a "struct resource" flag, and interpreted when the resource gets mapped.
> >
> > The PCI host controller nests inside of the node above, and (in theory)
> > uses the same trick to distinguish between prefetchable and non-prefetchable
> > memory, except in practice this is handled in device drivers that already
> > know whether to call ioremap() or ioremap_wc().
Using the high bit in the address would be awkward I think. For
example in U-Boot I'd have to mask that bit away but doing so in a
per-SoC way would be ugly. Unless you map the high bit away using a
ranges property for the bus.
Using #address-cells = <3> wll cause some fallout as well as it is
convenient to store addresses as 64-bit integers. I've written code
that just panics if that isn't possible.
> 4. Introduce a new top-level DT element in the style of reserved-memory,
> that describes address ranges and the mapping type to use. This could be
> implemented entirely in arch code, having arm64's ioremap look up the
> address in a structure populated from this.
This isn't a strange idea either. For UEFI such a mapping already
exists as a separate table that encodes the cache attributes of
certain memory regions.
> As an additional wrinkle, earlycon is almost certainly going to need a
> special path to handle this very early, before OF stuff is available; it
> also uses fixmap instead of ioremap, which has its own idea about what
> type of mapping to use.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-02-10 13:44 UTC|newest]
Thread overview: 118+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-04 20:39 [PATCH 00/18] Apple M1 SoC platform bring-up Hector Martin
2021-02-04 20:39 ` [PATCH 01/18] dt-bindings: vendor-prefixes: add AAPL prefix Hector Martin
2021-02-08 10:27 ` Krzysztof Kozlowski
2021-02-08 17:32 ` Rob Herring
2021-02-08 18:12 ` Krzysztof Kozlowski
2021-02-08 19:59 ` Arnd Bergmann
2021-02-08 23:17 ` Hector Martin
2021-02-04 20:39 ` [PATCH 02/18] dt-bindings: arm: cpus: Add AAPL, firestorm & icestorm compatibles Hector Martin
2021-02-04 20:39 ` [PATCH 03/18] dt-bindings: arm: AAPL: Add bindings for Apple ARM platforms Hector Martin
2021-02-04 20:39 ` [PATCH 04/18] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE Hector Martin
2021-02-06 13:17 ` Marc Zyngier
2021-02-07 8:05 ` Hector Martin 'marcan'
2021-02-04 20:39 ` [PATCH 05/18] tty: serial: samsung_tty: add support for Apple UARTs Hector Martin
2021-02-04 23:55 ` kernel test robot
2021-02-05 9:44 ` Hector Martin 'marcan'
2021-02-05 2:19 ` kernel test robot
2021-02-06 13:15 ` Marc Zyngier
2021-02-07 9:12 ` Hector Martin 'marcan'
2021-02-07 9:26 ` Hector Martin 'marcan'
2021-02-08 9:36 ` Krzysztof Kozlowski
2021-02-08 16:14 ` Hector Martin
2021-02-08 10:34 ` Marc Zyngier
2021-02-08 16:18 ` Hector Martin
2021-02-08 16:46 ` Greg Kroah-Hartman
2021-02-08 23:22 ` Hector Martin
2021-02-08 10:54 ` Krzysztof Kozlowski
2021-02-08 16:10 ` Hector Martin
2021-02-08 18:37 ` Krzysztof Kozlowski
2021-02-08 23:23 ` Hector Martin
2021-02-04 20:39 ` [PATCH 06/18] dt-bindings: serial: samsung: Add AAPL, s5l-uart compatible Hector Martin
2021-02-04 20:39 ` [PATCH 07/18] tty: serial: samsung_tty: enable for ARCH_APPLE Hector Martin
2021-02-04 21:16 ` Arnd Bergmann
2021-02-04 21:27 ` Hector Martin 'marcan'
2021-02-04 20:39 ` [PATCH 08/18] arm64: cpufeature: Add a feature for FIQ support Hector Martin
2021-02-06 13:58 ` Marc Zyngier
2021-02-07 8:28 ` Hector Martin 'marcan'
2021-02-08 11:29 ` Marc Zyngier
2021-02-08 15:51 ` Hector Martin
2021-02-04 20:39 ` [PATCH 09/18] arm64: cputype: Add CPU types for the Apple M1 big/little cores Hector Martin
2021-02-04 20:39 ` [PATCH 10/18] arm64: Introduce FIQ support Hector Martin
2021-02-06 15:37 ` Marc Zyngier
2021-02-06 16:22 ` Arnd Bergmann
2021-02-07 8:36 ` Hector Martin 'marcan'
2021-02-07 12:25 ` Arnd Bergmann
2021-02-07 15:38 ` Hector Martin 'marcan'
2021-02-07 18:49 ` Arnd Bergmann
2021-02-08 23:34 ` Hector Martin
2021-02-07 8:47 ` Hector Martin 'marcan'
2021-02-08 11:30 ` Marc Zyngier
2021-02-04 20:39 ` [PATCH 11/18] arm64: Kconfig: Require FIQ support for ARCH_APPLE Hector Martin
2021-02-06 15:46 ` Marc Zyngier
2021-02-07 9:23 ` Hector Martin 'marcan'
2021-02-08 12:05 ` Marc Zyngier
2021-02-08 15:48 ` Hector Martin
2021-02-04 20:39 ` [PATCH 12/18] arm64: setup: Use nGnRnE IO mappings for fixmap on Apple platforms Hector Martin
2021-02-04 22:25 ` Arnd Bergmann
2021-02-04 20:39 ` [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it Hector Martin
2021-02-04 22:21 ` Arnd Bergmann
2021-02-08 22:57 ` Arnd Bergmann
2021-02-08 23:20 ` Mark Kettenis
2021-02-09 0:25 ` Hector Martin
2021-02-09 9:15 ` Arnd Bergmann
2021-02-09 9:58 ` Mark Kettenis
2021-02-09 11:22 ` Hector Martin
2021-02-09 9:35 ` Arnd Bergmann
2021-02-10 12:24 ` Hector Martin
2021-02-10 13:40 ` Mark Kettenis [this message]
2021-02-04 20:39 ` [PATCH 14/18] dt-bindings: interrupt-controller: Add DT bindings for apple-aic Hector Martin
2021-02-09 23:07 ` Rob Herring
2021-02-04 20:39 ` [PATCH 15/18] irqchip/apple-aic: Add support for the Apple Interrupt Controller Hector Martin
2021-02-04 21:37 ` Arnd Bergmann
2021-02-04 22:04 ` Hector Martin 'marcan'
2021-02-04 23:04 ` Arnd Bergmann
2021-02-05 7:41 ` Hector Martin 'marcan'
2021-02-05 10:33 ` Arnd Bergmann
2021-02-05 2:27 ` kernel test robot
2021-02-05 9:45 ` Hector Martin 'marcan'
2021-02-08 9:25 ` Marc Zyngier
2021-02-08 10:29 ` Arnd Bergmann
2021-02-08 11:13 ` Hector Martin 'marcan'
2021-02-08 11:21 ` Arnd Bergmann
2021-02-08 11:36 ` Marc Zyngier
2021-02-08 12:17 ` Arnd Bergmann
2021-02-08 15:31 ` Hector Martin
2021-02-09 6:20 ` Hector Martin
2021-02-04 20:39 ` [PATCH 16/18] irqchip/apple-aic: Add SMP / IPI support Hector Martin
2021-02-04 20:39 ` [PATCH 17/18] dt-bindings: display: add AAPL,simple-framebuffer Hector Martin
2021-02-04 20:39 ` [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree Hector Martin
2021-02-04 21:29 ` Arnd Bergmann
2021-02-04 21:44 ` Hector Martin 'marcan'
2021-02-04 23:08 ` Arnd Bergmann
2021-02-05 7:11 ` Hector Martin 'marcan'
2021-02-05 12:43 ` Arnd Bergmann
2021-02-08 11:04 ` Krzysztof Kozlowski
2021-02-08 11:56 ` Hector Martin 'marcan'
2021-02-08 12:13 ` Krzysztof Kozlowski
2021-02-08 12:40 ` Arnd Bergmann
2021-02-08 14:12 ` Hector Martin
2021-02-08 17:58 ` Rob Herring
2021-02-09 0:32 ` Hector Martin
2021-02-08 19:14 ` Rob Herring
2021-02-09 0:49 ` Hector Martin
2021-02-09 2:05 ` Rob Herring
2021-02-10 10:19 ` Tony Lindgren
2021-02-10 11:07 ` Hector Martin
2021-02-10 11:34 ` Tony Lindgren
2021-02-10 11:43 ` Hector Martin
2021-02-10 12:24 ` Daniel Palmer
2021-02-10 12:54 ` Tony Lindgren
2021-02-10 12:56 ` Hector Martin
2021-02-10 12:55 ` Krzysztof Kozlowski
2021-02-10 13:19 ` Tony Lindgren
2021-02-10 13:25 ` Krzysztof Kozlowski
2021-02-08 12:27 ` Marc Zyngier
2021-02-08 14:53 ` Hector Martin
2021-02-08 15:36 ` Marc Zyngier
2021-02-04 22:43 ` [PATCH 00/18] Apple M1 SoC platform bring-up Arnd Bergmann
2021-02-05 11:35 ` Hector Martin 'marcan'
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=c1bc32139ad12bd8@bloch.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=arnd@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=marcan@marcan.st \
--cc=maz@kernel.org \
--cc=olof@lixom.net \
--cc=robh+dt@kernel.org \
--cc=soc@kernel.org \
--cc=will@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).