Messages in this thread | | | Subject | Re: [RFC PATCH 3/7] arm64: mm: use nGnRnE instead of nGnRE on Apple processors | From | Mohamed Mediouni <> | Date | Thu, 21 Jan 2021 19:22:24 +0100 |
| |
> 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...
| |