From: Hector Martin <marcan@marcan.st> To: Will Deacon <will@kernel.org> Cc: SoC Team <soc@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Marc Zyngier <maz@kernel.org>, Rob Herring <robh+dt@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, DTML <devicetree@vger.kernel.org>, Olof Johansson <olof@lixom.net>, Arnd Bergmann <arnd@kernel.org>, Mark Kettenis <mark.kettenis@xs4all.nl> Subject: Re: [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it Date: Wed, 10 Feb 2021 21:24:15 +0900 [thread overview] Message-ID: <475f7586-cabf-1169-8800-cdd2c012a5a6@marcan.st> (raw) In-Reply-To: <CAK8P3a2Ad+xmmMWgznOHPpxgCXKWFYfpHBqt_49_UuxrwFSq+A@mail.gmail.com> 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). 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(). 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. 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. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub
WARNING: multiple messages have this Message-ID (diff)
From: Hector Martin <marcan@marcan.st> To: Will Deacon <will@kernel.org> Cc: DTML <devicetree@vger.kernel.org>, Arnd Bergmann <arnd@kernel.org>, Marc Zyngier <maz@kernel.org>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, SoC Team <soc@kernel.org>, Rob Herring <robh+dt@kernel.org>, Olof Johansson <olof@lixom.net>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Mark Kettenis <mark.kettenis@xs4all.nl> Subject: Re: [PATCH 13/18] arm64: ioremap: use nGnRnE mappings on platforms that require it Date: Wed, 10 Feb 2021 21:24:15 +0900 [thread overview] Message-ID: <475f7586-cabf-1169-8800-cdd2c012a5a6@marcan.st> (raw) Message-ID: <20210210122415.zmUxJFCphIBHjExp8PaZVr_TaQqMTeNSJILucngPlrk@z> (raw) In-Reply-To: <CAK8P3a2Ad+xmmMWgznOHPpxgCXKWFYfpHBqt_49_UuxrwFSq+A@mail.gmail.com> 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). 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(). 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. 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. -- Hector Martin (marcan@marcan.st) Public Key: https://mrcn.st/pub _______________________________________________ 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 12:28 UTC|newest] Thread overview: 240+ 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 ` Hector Martin 2021-02-04 20:39 ` [PATCH 01/18] dt-bindings: vendor-prefixes: add AAPL prefix Hector Martin 2021-02-04 20:39 ` Hector Martin 2021-02-08 10:27 ` Krzysztof Kozlowski 2021-02-08 10:27 ` Krzysztof Kozlowski 2021-02-08 17:32 ` Rob Herring 2021-02-08 17:32 ` Rob Herring 2021-02-08 18:12 ` Krzysztof Kozlowski 2021-02-08 18:12 ` Krzysztof Kozlowski 2021-02-08 19:59 ` Arnd Bergmann 2021-02-08 19:59 ` Arnd Bergmann 2021-02-08 23:17 ` Hector Martin 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 02/18] dt-bindings: arm: cpus: Add AAPL, firestorm " 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 ` Hector Martin 2021-02-04 20:39 ` [PATCH 04/18] arm64: Kconfig: Introduce CONFIG_ARCH_APPLE Hector Martin 2021-02-04 20:39 ` Hector Martin 2021-02-06 13:17 ` Marc Zyngier 2021-02-06 13:17 ` Marc Zyngier 2021-02-07 8:05 ` Hector Martin 'marcan' 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 20:39 ` Hector Martin 2021-02-04 23:55 ` kernel test robot 2021-02-04 23:55 ` kernel test robot 2021-02-04 23:55 ` kernel test robot 2021-02-05 9:44 ` Hector Martin 'marcan' 2021-02-05 9:44 ` Hector Martin 'marcan' 2021-02-05 2:19 ` kernel test robot 2021-02-05 2:19 ` kernel test robot 2021-02-05 2:19 ` kernel test robot 2021-02-06 13:15 ` Marc Zyngier 2021-02-06 13:15 ` Marc Zyngier 2021-02-07 9:12 ` Hector Martin 'marcan' 2021-02-07 9:12 ` Hector Martin 'marcan' 2021-02-07 9:26 ` Hector Martin 'marcan' 2021-02-07 9:26 ` Hector Martin 'marcan' 2021-02-08 9:36 ` Krzysztof Kozlowski 2021-02-08 9:36 ` Krzysztof Kozlowski 2021-02-08 16:14 ` Hector Martin 2021-02-08 16:14 ` Hector Martin 2021-02-08 10:34 ` Marc Zyngier 2021-02-08 10:34 ` Marc Zyngier 2021-02-08 16:18 ` Hector Martin 2021-02-08 16:18 ` Hector Martin 2021-02-08 16:46 ` Greg Kroah-Hartman 2021-02-08 16:46 ` Greg Kroah-Hartman 2021-02-08 23:22 ` Hector Martin 2021-02-08 23:22 ` Hector Martin 2021-02-08 10:54 ` Krzysztof Kozlowski 2021-02-08 10:54 ` Krzysztof Kozlowski 2021-02-08 16:10 ` Hector Martin 2021-02-08 16:10 ` Hector Martin 2021-02-08 18:37 ` Krzysztof Kozlowski 2021-02-08 18:37 ` Krzysztof Kozlowski 2021-02-08 23:23 ` Hector Martin 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 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 20:39 ` Hector Martin 2021-02-04 21:16 ` Arnd Bergmann 2021-02-04 21:16 ` Arnd Bergmann 2021-02-04 21:27 ` Hector Martin 'marcan' 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-04 20:39 ` Hector Martin 2021-02-06 13:58 ` Marc Zyngier 2021-02-06 13:58 ` Marc Zyngier 2021-02-07 8:28 ` Hector Martin 'marcan' 2021-02-07 8:28 ` Hector Martin 'marcan' 2021-02-08 11:29 ` Marc Zyngier 2021-02-08 11:29 ` Marc Zyngier 2021-02-08 15:51 ` Hector Martin 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 ` Hector Martin 2021-02-04 20:39 ` [PATCH 10/18] arm64: Introduce FIQ support Hector Martin 2021-02-04 20:39 ` Hector Martin 2021-02-06 15:37 ` Marc Zyngier 2021-02-06 15:37 ` Marc Zyngier 2021-02-06 16:22 ` Arnd Bergmann 2021-02-06 16:22 ` Arnd Bergmann 2021-02-07 8:36 ` Hector Martin 'marcan' 2021-02-07 8:36 ` Hector Martin 'marcan' 2021-02-07 12:25 ` Arnd Bergmann 2021-02-07 12:25 ` Arnd Bergmann 2021-02-07 15:38 ` Hector Martin 'marcan' 2021-02-07 15:38 ` Hector Martin 'marcan' 2021-02-07 18:49 ` Arnd Bergmann 2021-02-07 18:49 ` Arnd Bergmann 2021-02-08 23:34 ` Hector Martin 2021-02-08 23:34 ` Hector Martin 2021-02-07 8:47 ` Hector Martin 'marcan' 2021-02-07 8:47 ` Hector Martin 'marcan' 2021-02-08 11:30 ` Marc Zyngier 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-04 20:39 ` Hector Martin 2021-02-06 15:46 ` Marc Zyngier 2021-02-06 15:46 ` Marc Zyngier 2021-02-07 9:23 ` Hector Martin 'marcan' 2021-02-07 9:23 ` Hector Martin 'marcan' 2021-02-08 12:05 ` Marc Zyngier 2021-02-08 12:05 ` Marc Zyngier 2021-02-08 15:48 ` Hector Martin 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 2021-02-04 22:25 ` Arnd Bergmann 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 20:39 ` Hector Martin 2021-02-04 22:21 ` Arnd Bergmann 2021-02-04 22:21 ` Arnd Bergmann 2021-02-08 22:57 ` Arnd Bergmann 2021-02-08 22:57 ` Arnd Bergmann 2021-02-08 23:20 ` Mark Kettenis 2021-02-08 23:20 ` Mark Kettenis 2021-02-09 0:25 ` Hector Martin 2021-02-09 0:25 ` Hector Martin 2021-02-09 9:15 ` Arnd Bergmann 2021-02-09 9:15 ` Arnd Bergmann 2021-02-09 9:58 ` Mark Kettenis 2021-02-09 9:58 ` Mark Kettenis 2021-02-09 11:22 ` Hector Martin 2021-02-09 11:22 ` Hector Martin 2021-02-09 9:35 ` Arnd Bergmann 2021-02-09 9:35 ` Arnd Bergmann 2021-02-10 12:24 ` Hector Martin [this message] 2021-02-10 12:24 ` Hector Martin 2021-02-10 13:40 ` Mark Kettenis 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-04 20:39 ` Hector Martin 2021-02-09 23:07 ` Rob Herring 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 20:39 ` Hector Martin 2021-02-04 21:37 ` Arnd Bergmann 2021-02-04 21:37 ` Arnd Bergmann 2021-02-04 22:04 ` Hector Martin 'marcan' 2021-02-04 22:04 ` Hector Martin 'marcan' 2021-02-04 23:04 ` Arnd Bergmann 2021-02-04 23:04 ` Arnd Bergmann 2021-02-05 7:41 ` Hector Martin 'marcan' 2021-02-05 7:41 ` Hector Martin 'marcan' 2021-02-05 10:33 ` Arnd Bergmann 2021-02-05 10:33 ` Arnd Bergmann 2021-02-05 2:27 ` kernel test robot 2021-02-05 2:27 ` kernel test robot 2021-02-05 2:27 ` kernel test robot 2021-02-05 9:45 ` Hector Martin 'marcan' 2021-02-05 9:45 ` Hector Martin 'marcan' 2021-02-08 9:25 ` Marc Zyngier 2021-02-08 9:25 ` Marc Zyngier 2021-02-08 10:29 ` Arnd Bergmann 2021-02-08 10:29 ` Arnd Bergmann 2021-02-08 11:13 ` Hector Martin 'marcan' 2021-02-08 11:13 ` Hector Martin 'marcan' 2021-02-08 11:21 ` Arnd Bergmann 2021-02-08 11:21 ` Arnd Bergmann 2021-02-08 11:36 ` Marc Zyngier 2021-02-08 11:36 ` Marc Zyngier 2021-02-08 12:17 ` Arnd Bergmann 2021-02-08 12:17 ` Arnd Bergmann 2021-02-08 15:31 ` Hector Martin 2021-02-08 15:31 ` Hector Martin 2021-02-09 6:20 ` 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 ` Hector Martin 2021-02-04 20:39 ` [PATCH 17/18] dt-bindings: display: add AAPL,simple-framebuffer Hector Martin 2021-02-04 20:39 ` Hector Martin 2021-02-04 20:39 ` [PATCH 18/18] arm64: apple: Add initial Mac Mini 2020 (M1) devicetree Hector Martin 2021-02-04 20:39 ` Hector Martin 2021-02-04 21:29 ` Arnd Bergmann 2021-02-04 21:29 ` Arnd Bergmann 2021-02-04 21:44 ` Hector Martin 'marcan' 2021-02-04 21:44 ` Hector Martin 'marcan' 2021-02-04 23:08 ` Arnd Bergmann 2021-02-04 23:08 ` Arnd Bergmann 2021-02-05 7:11 ` Hector Martin 'marcan' 2021-02-05 7:11 ` Hector Martin 'marcan' 2021-02-05 12:43 ` Arnd Bergmann 2021-02-05 12:43 ` Arnd Bergmann 2021-02-08 11:04 ` Krzysztof Kozlowski 2021-02-08 11:04 ` Krzysztof Kozlowski 2021-02-08 11:56 ` Hector Martin 'marcan' 2021-02-08 11:56 ` Hector Martin 'marcan' 2021-02-08 12:13 ` Krzysztof Kozlowski 2021-02-08 12:13 ` Krzysztof Kozlowski 2021-02-08 12:40 ` Arnd Bergmann 2021-02-08 12:40 ` Arnd Bergmann 2021-02-08 14:12 ` Hector Martin 2021-02-08 14:12 ` Hector Martin 2021-02-08 17:58 ` Rob Herring 2021-02-08 17:58 ` Rob Herring 2021-02-09 0:32 ` Hector Martin 2021-02-09 0:32 ` Hector Martin 2021-02-08 19:14 ` Rob Herring 2021-02-08 19:14 ` Rob Herring 2021-02-09 0:49 ` Hector Martin 2021-02-09 0:49 ` Hector Martin 2021-02-09 2:05 ` Rob Herring 2021-02-09 2:05 ` Rob Herring 2021-02-10 10:19 ` Tony Lindgren 2021-02-10 10:19 ` Tony Lindgren 2021-02-10 11:07 ` Hector Martin 2021-02-10 11:07 ` Hector Martin 2021-02-10 11:34 ` Tony Lindgren 2021-02-10 11:34 ` Tony Lindgren 2021-02-10 11:43 ` Hector Martin 2021-02-10 11:43 ` Hector Martin 2021-02-10 12:24 ` Daniel Palmer 2021-02-10 12:24 ` Daniel Palmer 2021-02-10 12:24 ` Daniel Palmer 2021-02-10 12:54 ` Tony Lindgren 2021-02-10 12:54 ` Tony Lindgren 2021-02-10 12:56 ` Hector Martin 2021-02-10 12:56 ` Hector Martin 2021-02-10 12:55 ` Krzysztof Kozlowski 2021-02-10 12:55 ` Krzysztof Kozlowski 2021-02-10 13:19 ` Tony Lindgren 2021-02-10 13:19 ` Tony Lindgren 2021-02-10 13:25 ` Krzysztof Kozlowski 2021-02-10 13:25 ` Krzysztof Kozlowski 2021-02-08 12:27 ` Marc Zyngier 2021-02-08 12:27 ` Marc Zyngier 2021-02-08 14:53 ` Hector Martin 2021-02-08 14:53 ` Hector Martin 2021-02-08 15:36 ` Marc Zyngier 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-04 22:43 ` Arnd Bergmann 2021-02-05 11:35 ` Hector Martin 'marcan' 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=475f7586-cabf-1169-8800-cdd2c012a5a6@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=mark.kettenis@xs4all.nl \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.