From: Mohamed Mediouni <mohamed.mediouni@caramail.com> To: Marc Zyngier <maz@kernel.org> Cc: Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Catalin Marinas <catalin.marinas@arm.com>, Mark Rutland <mark.rutland@arm.com>, Hector Martin <marcan@marcan.st>, linux-kernel@vger.kernel.org, Stan Skowronek <stan@corellium.com> Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Date: Thu, 21 Jan 2021 19:22:24 +0100 [thread overview] Message-ID: <A85F09CC-0203-4560-A65F-F9754535345B@caramail.com> (raw) In-Reply-To: <f2b1cb981e7c3d42a9f815c2d2be08bb@kernel.org> > On 21 Jan 2021, at 19:15, Marc Zyngier <maz@kernel.org> wrote: > > On 2021-01-21 17:55, Will Deacon wrote: >> On Thu, Jan 21, 2021 at 04:25:54PM +0000, Marc Zyngier wrote: >>> On 2021-01-21 15:12, Mohamed Mediouni wrote: >>>> Please ignore that patch. >>>> >>>> It turns out that the PCIe controller on Apple M1 expects posted >>>> writes and so the memory range for it ought to be set nGnRE. >>>> So, we need to use nGnRnE for on-chip MMIO and nGnRE for PCIe BARs. >>>> >>>> The MAIR approach isn’t adequate for such a thing, so we’ll have to >>>> look elsewhere. >>> Well, there isn't many alternative to having a memory type defined >>> in MAIR if you want to access your PCIe devices with specific >>> semantics. >>> It probably means defining a memory type for PCI only, but: >>> - we only have a single free MT entry, and I'm not sure we can >>> afford to waste this on a specific platform (can we re-purpose >>> GRE instead?), >> We already have an nGnRnE MAIR for config space accesses. > > I'm confused. If M1 needs nGnRE for PCI, and overrides nGnRE to nE > for its in-SoC accesses, where does nGnRE goes? > > Or do you propose that it is the page tables that get a different > MT index? > That MAIR patch that I added overrides nGnRE accesses to nGnRnE. Linux tries to access to those SoC devices using nGnRE as the device memory type without that workaround. Maybe have a device tree property to override the used device memory type for a given device on the SoC? Or that’s too big for what’s at the end just one particular set of SoCs? But what the hardware wants is accesses to in-SoC devices being nGnRnE and access to the PCIe BARs being nGnRE. So both have to be supported… > M. > -- > Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Mohamed Mediouni <mohamed.mediouni@caramail.com> To: Marc Zyngier <maz@kernel.org> Cc: Mark Rutland <mark.rutland@arm.com>, Catalin Marinas <catalin.marinas@arm.com>, Hector Martin <marcan@marcan.st>, linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>, Linux ARM <linux-arm-kernel@lists.infradead.org>, Stan Skowronek <stan@corellium.com> Subject: Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Date: Thu, 21 Jan 2021 19:22:24 +0100 [thread overview] Message-ID: <A85F09CC-0203-4560-A65F-F9754535345B@caramail.com> (raw) In-Reply-To: <f2b1cb981e7c3d42a9f815c2d2be08bb@kernel.org> > On 21 Jan 2021, at 19:15, Marc Zyngier <maz@kernel.org> wrote: > > On 2021-01-21 17:55, Will Deacon wrote: >> On Thu, Jan 21, 2021 at 04:25:54PM +0000, Marc Zyngier wrote: >>> On 2021-01-21 15:12, Mohamed Mediouni wrote: >>>> Please ignore that patch. >>>> >>>> It turns out that the PCIe controller on Apple M1 expects posted >>>> writes and so the memory range for it ought to be set nGnRE. >>>> So, we need to use nGnRnE for on-chip MMIO and nGnRE for PCIe BARs. >>>> >>>> The MAIR approach isn’t adequate for such a thing, so we’ll have to >>>> look elsewhere. >>> Well, there isn't many alternative to having a memory type defined >>> in MAIR if you want to access your PCIe devices with specific >>> semantics. >>> It probably means defining a memory type for PCI only, but: >>> - we only have a single free MT entry, and I'm not sure we can >>> afford to waste this on a specific platform (can we re-purpose >>> GRE instead?), >> We already have an nGnRnE MAIR for config space accesses. > > I'm confused. If M1 needs nGnRE for PCI, and overrides nGnRE to nE > for its in-SoC accesses, where does nGnRE goes? > > Or do you propose that it is the page tables that get a different > MT index? > That MAIR patch that I added overrides nGnRE accesses to nGnRnE. Linux tries to access to those SoC devices using nGnRE as the device memory type without that workaround. Maybe have a device tree property to override the used device memory type for a given device on the SoC? Or that’s too big for what’s at the end just one particular set of SoCs? But what the hardware wants is accesses to in-SoC devices being nGnRnE and access to the PCIe BARs being nGnRE. So both have to be supported… > M. > -- > Jazz is not dead. It just smells funny... _______________________________________________ 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-01-21 18:31 UTC|newest] Thread overview: 110+ messages / expand[flat|nested] mbox.gz Atom feed top 2021-01-20 13:27 [RFC PATCH 0/7] Linux on Apple Silicon Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-20 13:27 ` [RFC PATCH 1/7] arm64: kernel: FIQ support Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-20 13:27 ` [RFC PATCH 2/7] arm64: kernel: Add a WFI hook Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-20 16:46 ` Alexander Graf 2021-01-20 16:46 ` Alexander Graf [not found] ` <94C20F55-D3B8-4349-B26F-9EA8AAEBF639@caramail.com> 2021-01-21 12:33 ` Hector Martin 'marcan' 2021-01-21 12:33 ` Hector Martin 'marcan' 2021-01-21 10:52 ` Arnd Bergmann 2021-01-21 10:52 ` Arnd Bergmann 2021-01-21 11:01 ` Mohamed Mediouni 2021-01-21 11:01 ` Mohamed Mediouni 2021-01-21 11:36 ` Arnd Bergmann 2021-01-21 11:36 ` Arnd Bergmann 2021-01-20 13:27 ` [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-20 16:47 ` Alexander Graf 2021-01-20 16:47 ` Alexander Graf 2021-01-20 18:06 ` Mohamed Mediouni 2021-01-20 18:06 ` Mohamed Mediouni 2021-01-20 18:10 ` Alexander Graf 2021-01-20 18:10 ` Alexander Graf 2021-01-21 11:27 ` Will Deacon 2021-01-21 11:27 ` Will Deacon 2021-01-21 11:38 ` Arnd Bergmann 2021-01-21 11:38 ` Arnd Bergmann 2021-01-21 11:44 ` Marc Zyngier 2021-01-21 11:44 ` Marc Zyngier 2021-01-21 12:47 ` Will Deacon 2021-01-21 12:47 ` Will Deacon 2021-01-21 15:12 ` Mohamed Mediouni 2021-01-21 15:12 ` Mohamed Mediouni 2021-01-21 16:25 ` Marc Zyngier 2021-01-21 16:25 ` Marc Zyngier 2021-01-21 17:55 ` Will Deacon 2021-01-21 17:55 ` Will Deacon 2021-01-21 18:15 ` Marc Zyngier 2021-01-21 18:15 ` Marc Zyngier 2021-01-21 18:22 ` Mohamed Mediouni [this message] 2021-01-21 18:22 ` Mohamed Mediouni 2021-01-21 18:22 ` Will Deacon 2021-01-21 18:22 ` Will Deacon 2021-01-20 13:27 ` [RFC PATCH 4/7] irqchip/apple-aic: Add support for Apple AIC Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-20 17:11 ` Alexander Graf 2021-01-20 17:11 ` Alexander Graf 2021-01-20 18:04 ` Mohamed Mediouni 2021-01-20 18:04 ` Mohamed Mediouni 2021-01-20 20:16 ` Andrew Lunn 2021-01-20 20:16 ` Andrew Lunn 2021-01-20 21:18 ` Stan Skowronek 2021-01-20 21:18 ` Stan Skowronek 2021-01-21 9:48 ` Linus Walleij 2021-01-21 9:48 ` Linus Walleij 2021-01-21 10:37 ` Arnd Bergmann 2021-01-21 10:37 ` Arnd Bergmann 2021-01-21 15:29 ` Hector Martin 'marcan' 2021-01-21 15:29 ` Hector Martin 'marcan' 2021-01-21 17:09 ` Rob Herring 2021-01-21 17:09 ` Rob Herring 2021-01-21 17:45 ` Rob Herring 2021-01-21 17:45 ` Rob Herring 2021-01-21 16:44 ` Rob Herring 2021-01-21 16:44 ` Rob Herring 2021-01-21 16:53 ` Hector Martin 'marcan' 2021-01-21 16:53 ` Hector Martin 'marcan' 2021-01-20 13:27 ` [RFC PATCH 5/7] arm64/Kconfig: Add Apple Silicon SoC platform Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-20 13:27 ` [RFC PATCH 6/7] arm64: kernel: Apple CPU start driver Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-21 11:14 ` Arnd Bergmann 2021-01-21 11:14 ` Arnd Bergmann 2021-01-20 13:27 ` [RFC PATCH 7/7] irqchip/apple-aic: add SMP support to the Apple AIC driver Mohamed Mediouni 2021-01-20 13:27 ` Mohamed Mediouni 2021-01-21 12:44 ` Arnd Bergmann 2021-01-21 12:44 ` Arnd Bergmann 2021-01-21 12:50 ` Mohamed Mediouni 2021-01-21 12:50 ` Mohamed Mediouni 2021-01-21 13:00 ` Arnd Bergmann 2021-01-21 13:00 ` Arnd Bergmann 2021-01-21 13:01 ` Hector Martin 'marcan' 2021-01-21 13:01 ` Hector Martin 'marcan' 2021-01-21 13:22 ` Marc Zyngier 2021-01-21 13:22 ` Marc Zyngier 2021-01-21 13:32 ` Mark Rutland 2021-01-21 13:32 ` Mark Rutland 2021-01-21 14:05 ` Marc Zyngier 2021-01-21 14:05 ` Marc Zyngier 2021-01-21 13:34 ` Mohamed Mediouni 2021-01-21 13:34 ` Mohamed Mediouni 2021-01-21 14:10 ` Marc Zyngier 2021-01-21 14:10 ` Marc Zyngier 2021-01-21 15:09 ` Arnd Bergmann 2021-01-21 15:09 ` Arnd Bergmann 2021-01-21 15:18 ` Mohamed Mediouni 2021-01-21 15:18 ` Mohamed Mediouni 2021-01-21 16:40 ` Rob Herring 2021-01-21 16:40 ` Rob Herring 2021-01-21 16:43 ` Mohamed Mediouni 2021-01-21 16:43 ` Mohamed Mediouni 2021-01-21 17:37 ` Rob Herring 2021-01-21 17:37 ` Rob Herring 2021-01-21 18:08 ` Mohamed Mediouni 2021-01-21 18:08 ` Mohamed Mediouni 2021-01-21 18:57 ` Rob Herring 2021-01-21 18:57 ` Rob Herring 2021-02-02 19:15 ` Linus Walleij 2021-02-02 19:15 ` Linus Walleij
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=A85F09CC-0203-4560-A65F-F9754535345B@caramail.com \ --to=mohamed.mediouni@caramail.com \ --cc=catalin.marinas@arm.com \ --cc=linux-arm-kernel@lists.infradead.org \ --cc=linux-kernel@vger.kernel.org \ --cc=marcan@marcan.st \ --cc=mark.rutland@arm.com \ --cc=maz@kernel.org \ --cc=stan@corellium.com \ --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.