All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@kernel.org>
Cc: Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	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 18:15:06 +0000	[thread overview]
Message-ID: <f2b1cb981e7c3d42a9f815c2d2be08bb@kernel.org> (raw)
In-Reply-To: <20210121175525.GB22963@willie-the-truck>

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?

         M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Will Deacon <will@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,
	Mohamed Mediouni <mohamed.mediouni@caramail.com>,
	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 18:15:06 +0000	[thread overview]
Message-ID: <f2b1cb981e7c3d42a9f815c2d2be08bb@kernel.org> (raw)
In-Reply-To: <20210121175525.GB22963@willie-the-truck>

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?

         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

  reply	other threads:[~2021-01-21 18:29 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 [this message]
2021-01-21 18:15                 ` Marc Zyngier
2021-01-21 18:22                 ` Mohamed Mediouni
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=f2b1cb981e7c3d42a9f815c2d2be08bb@kernel.org \
    --to=maz@kernel.org \
    --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=mohamed.mediouni@caramail.com \
    --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: link
Be 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.