linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hector Martin <marcan@marcan.st>
To: Hector Martin <marcan@marcan.st>, soc@kernel.org
Cc: linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>,
	robh+dt@kernel.org, Arnd Bergmann <arnd@kernel.org>,
	linux-kernel@vger.kernel.org, devicetree@vger.kernel.org,
	Olof Johansson <olof@lixom.net>
Subject: [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it
Date: Fri,  5 Feb 2021 05:39:46 +0900	[thread overview]
Message-ID: <20210204203951.52105-14-marcan@marcan.st> (raw)
In-Reply-To: <20210204203951.52105-1-marcan@marcan.st>

This follows from the fixmap patch, but relates to the general case.
This is a hack, and incomplete. Read on for discussion.

The problem: on Apple ARM platforms, SoC MMIO needs to use nGnRnE
mappings: writes using nGnRE are blackholed. This seems to be by design,
and there doesn't seem to be any fabric configuration or other bit we
can flip to make the problem go away.

As an additional confounding factor, reportedly PCIe MMIO BAR mappings
conversely *do* need to use nGnRE to work properly. So we can't even get
away with a single ioremap setting, but need to discriminate based on
what bus the device is in. Since these devices have Thunderbolt, all PCI
devices in the tree are potentially in scope. Ugh.

Ideas:

(1) Set up some devicetree property to default to nGnRnE at the platform
    level, and then make PCI drivers use nGnRE.

    This will require changing the PCI code to make pci_ioremap_bar do
    something other than a plain ioremap().

    Unfortunately, of the ~630 PCI drivers in the tree, only ~90 use
    pci_ioremap_bar(). This would require a tree-wide cleanup to
    introduce something akin to pci_ioremap(), and make all PCI
    drivers use it instead of naked ioremap().

    Currently there are three ioremap variants:

    ioremap()
    ioremap_wc()
    ioremap_uc() (not normally used on arm64)

    None of these really capture the nGnRE vs nGnRnE distinction. If
    a new variant is introduced in common code, we'd have to provide
    a default implementation that falls back to regular ioremap() on
    other arches. Something like ioremap() vs. ioremap_np() (nonposted)?

(2) The converse of (1): keep the nGnRE default, but introduce special
    casing to the OF binding code to use nGnRnE when instructed to do so
    on these platforms. This means of_iomap() needs changing.

    The advantage of this approach is that the set of possible non-PCI
    drivers that are useful on these SoCs is bounded, so not all drivers
    that don't go through that path need to be fixed.

    Additionally, this could take advantage of the OF address
    translation stuff to be smarter about deciding to use nGnRnE, e.g.
    doing it based on a property of the parent bus node.

    Of note, some devices (like samsung_tty) go through the platform
    device framework, which eventually goes into devm code. So
    of_address_to_resource would need to set some flag on the struct
    resource, that can then be used by both of_iomap() and
    devm_ioremap_resource() and friends to eventually call the right
    ioremap variant.

    The ioremap considerations from (1) apply here too.

(3) Do it at a lower level, in ioremap() itself. This requires that
    ioremap() somehow discriminates based on address range to pick what
    kind of mapping to make.

    Declaring these address ranges would be an issue. Options:

    a) An out of band list in a DT node, a la /reserved-memory

    b) Something based on the existing DT hierarchy, where we can scan
       bus ranges and locate buses with a property that says "nGnRnE" or
       "nGnRE" and dynamically build the list based on that.

    The advantage of this option is that it doesn't touch non-arch code.
    The disadvantage is that it adds a complete new bespoke mechanism to
    the DT, and that it does not let device drivers actually select the
    IO mode, which might be desirable in the future anyway for some
    devices.

All discussion and additional ideas welcome.

Signed-off-by: Hector Martin <marcan@marcan.st>
---
 arch/arm64/include/asm/io.h | 9 ++++++++-
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
index 5ea8656a2030..f2609a4f5019 100644
--- a/arch/arm64/include/asm/io.h
+++ b/arch/arm64/include/asm/io.h
@@ -167,7 +167,14 @@ extern void __iomem *__ioremap(phys_addr_t phys_addr, size_t size, pgprot_t prot
 extern void iounmap(volatile void __iomem *addr);
 extern void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size);
 
-#define ioremap(addr, size)		__ioremap((addr), (size), __pgprot(PROT_DEVICE_nGnRE))
+/*
+ * Some platforms require nGnRnE for MMIO.
+ */
+extern bool arm64_use_ne_io;
+
+#define ioremap(addr, size)		__ioremap((addr), (size), \
+						  arm64_use_ne_io ? __pgprot(PROT_DEVICE_nGnRnE) \
+								  : __pgprot(PROT_DEVICE_nGnRE))
 #define ioremap_wc(addr, size)		__ioremap((addr), (size), __pgprot(PROT_NORMAL_NC))
 
 /*
-- 
2.30.0


  parent reply	other threads:[~2021-02-04 20:44 UTC|newest]

Thread overview: 82+ 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 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
     [not found]   ` <87k0rll4i8.wl-maz@kernel.org>
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
     [not found]   ` <87lfc1l4lo.wl-maz@kernel.org>
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
     [not found]       ` <73116feaa00de9173d1f2c35ce16e08f@kernel.org>
2021-02-08 16:18         ` Hector Martin
     [not found]           ` <YCFq3DqOzv4//6Vw@kroah.com>
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
     [not found]   ` <CAK8P3a1n+C5V5J24myy_h67DVp2YTN5Hd=tCWjPUYZcrAX4hCg@mail.gmail.com>
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
     [not found]   ` <87im75l2lp.wl-maz@kernel.org>
2021-02-07  8:28     ` Hector Martin 'marcan'
     [not found]       ` <87czxalrwc.wl-maz@kernel.org>
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
     [not found]   ` <87h7mpky0f.wl-maz@kernel.org>
     [not found]     ` <CAK8P3a0-Qk1WAUaCWeX8Zypphpadan3YAOES9t7LFYBOJkXKog@mail.gmail.com>
2021-02-07  8:36       ` Hector Martin 'marcan'
     [not found]         ` <CAK8P3a1R51_nqfMWG7SxScJNJEQ3qvp-cynABKEDaQ4O9REM=Q@mail.gmail.com>
2021-02-07 15:38           ` Hector Martin 'marcan'
     [not found]             ` <CAK8P3a1vmUJ0EpzU2+u2gy8WHCVV5ur9u-oTzU2BP=ddbXQeLQ@mail.gmail.com>
2021-02-08 23:34               ` Hector Martin
2021-02-07  8:47     ` Hector Martin 'marcan'
2021-02-04 20:39 ` [PATCH 11/18] arm64: Kconfig: Require FIQ support for ARCH_APPLE Hector Martin
     [not found]   ` <87ft29kxmp.wl-maz@kernel.org>
2021-02-07  9:23     ` Hector Martin 'marcan'
     [not found]       ` <2a93bf0df74df8cb022e61d69d1de88e@kernel.org>
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 20:39 ` Hector Martin [this message]
     [not found]   ` <CAK8P3a2Ad+xmmMWgznOHPpxgCXKWFYfpHBqt_49_UuxrwFSq+A@mail.gmail.com>
2021-02-08 23:20     ` [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it Mark Kettenis
2021-02-09  0:25       ` Hector Martin
     [not found]         ` <CAK8P3a043eO4p2o6tizR2x7a1TZHMqO7TdX53JC4bTZnbQd9iQ@mail.gmail.com>
2021-02-09  9:58           ` Mark Kettenis
2021-02-09 11:22           ` Hector Martin
2021-02-10 12:24     ` Hector Martin
2021-02-10 13:40       ` Mark Kettenis
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
     [not found]   ` <CAK8P3a1zbLM0s_GwkJ0AJQ8cocS-zcsWWKhOB7B99OtRYyDE7g@mail.gmail.com>
2021-02-04 22:04     ` Hector Martin 'marcan'
     [not found]       ` <CAK8P3a14vsLkCujd_XBAOAjL2h878gxkaoKPpaxL4jddZZcc-A@mail.gmail.com>
2021-02-05  7:41         ` Hector Martin 'marcan'
2021-02-05  2:27   ` kernel test robot
2021-02-05  9:45     ` Hector Martin 'marcan'
     [not found]   ` <87eehqlxlr.wl-maz@kernel.org>
     [not found]     ` <CAK8P3a25eFFrMG-9QknFZ6Ckc3-gkiLK=jQdnyTMgn-z4X0RHQ@mail.gmail.com>
2021-02-08 11:13       ` Hector Martin 'marcan'
     [not found]       ` <87a6selrkt.wl-maz@kernel.org>
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
     [not found]   ` <CAK8P3a3v6emxavbyjFhY+WdvH1t4EPMZSjEsSx0M+cRqjRCO1g@mail.gmail.com>
2021-02-04 21:44     ` Hector Martin 'marcan'
     [not found]       ` <CAK8P3a2DawQA-PD5aqbkVPB7UxuohN0oe9mJPe8488pUryotJQ@mail.gmail.com>
2021-02-05  7:11         ` Hector Martin 'marcan'
2021-02-08 11:04   ` Krzysztof Kozlowski
2021-02-08 11:56     ` Hector Martin 'marcan'
2021-02-08 12:13       ` Krzysztof Kozlowski
     [not found]         ` <CAK8P3a0yBC3dui6vcz+NByWD-3LqRj-2MF89jpjb_k8r5xmNRA@mail.gmail.com>
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-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
     [not found]   ` <a2825482e2f68c2f8cad7cb564414759@kernel.org>
2021-02-08 14:53     ` Hector Martin
2021-02-05 11:35 ` [PATCH 00/18] Apple M1 SoC platform bring-up 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=20210204203951.52105-14-marcan@marcan.st \
    --to=marcan@marcan.st \
    --cc=arnd@kernel.org \
    --cc=devicetree@vger.kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=maz@kernel.org \
    --cc=olof@lixom.net \
    --cc=robh+dt@kernel.org \
    --cc=soc@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).