Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Mohamed Mediouni <mohamed.mediouni@caramail.com>
To: Rob Herring <robh@kernel.org>
Cc: Mark Rutland <mark.rutland@arm.com>,
	Arnd Bergmann <arnd@kernel.org>, Marc Zyngier <maz@kernel.org>,
	Hector Martin <marcan@marcan.st>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Will Deacon <will@kernel.org>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Stan Skowronek <stan@corellium.com>
Subject: Re: [RFC PATCH 7/7] irqchip/apple-aic: add SMP support to the Apple AIC driver.
Date: Thu, 21 Jan 2021 19:08:54 +0100
Message-ID: <950D140B-491A-40EB-9FDB-D7173B86737B@caramail.com> (raw)
In-Reply-To: <CAL_Jsq+V74tMGJ==OVdsssfqTTa3TrFujfRjj0174uZNonpQSA@mail.gmail.com>



> On 21 Jan 2021, at 18:37, Rob Herring <robh@kernel.org> wrote:
> 
> On Thu, Jan 21, 2021 at 10:43 AM Mohamed Mediouni
> <mohamed.mediouni@caramail.com> wrote:
>>> On 21 Jan 2021, at 17:40, Rob Herring <robh@kernel.org> wrote:
>>> On Thu, Jan 21, 2021 at 6:52 AM Mohamed Mediouni
>>> <mohamed.mediouni@caramail.com> wrote:
>>>>> On 21 Jan 2021, at 13:44, Arnd Bergmann <arnd@kernel.org> wrote:
>>>>> On Wed, Jan 20, 2021 at 2:27 PM Mohamed Mediouni
>>>>> <mohamed.mediouni@caramail.com> wrote:
> 
> [...]
> 
>>>>>> @@ -186,8 +325,11 @@ static int __init apple_aic_init(struct device_node *node,
>>>>>>     if (WARN(!aic.base, "unable to map aic registers\n"))
>>>>>>             return -EINVAL;
>>>>>> 
>>>>>> +       aic.fast_ipi = of_property_read_bool(node, "fast-ipi");
>>>>> 
>>>>> Where is this property documented, and what decides which one to use?
>>>> It’s getting documented in the next patch set.
>>>> 
>>>> This property is there to enable support for older iPhone processors
>>>> later on, some of which do not have fast IPI support.
>>>> 
>>>> On Apple M1, fast-ipi is always on.
>>> 
>>> This should be implied by the compatible string which needs to be more
>>> specific and include the SoC name.
>>> 
>>> Rob
>> 
>> Then we’ll eventually have two aic compatible strings, aic which is compatible
>> with Apple A7 onwards and aicv2 which is a superset with fast IPI (introduced
>> on the Apple A11, 3 years ago, with no further programmer-visible changes since
>> then).
>> 
>> Does that look right?
> 
> If we did this from the start, it would evolve like this:
> 
> A7: "AAPL,a7-aic"
> A8: "AAPL,a8-aic", "AAPL,a7-aic"  # Read this as A8 AIC is backwards
> compatible with A7 AIC
> A9: "AAPL,a9-aic", "AAPL,a7-aic"
> 
> A11: "AAPL,a11-aic", "AAPL,a7-aic"
> 
> If the A11 version could work on an OS that only supported the
> original model (sounds like this is the case) Or if it's not backwards
> compatible:
> 

The A11 AIC indeed can be used by older drivers that aren’t aware
of the fast IPI path introduced on A11 just fine.

> A11: "AAPL,a11-aic"
> 
> If the A11 is different and not backwards compatible.
> 
> Then M1 could be:
> 
> M1: "AAPL,m1-aic", "AAPL,a11-aic"
> 
> Or to even support an OS with only v1 support:
> 
> M1: "AAPL,m1-aic", "AAPL,a11-aic", "AAPL,a7-aic"
> 
> You don't really need the fallback here because there isn't any
> existing OS support and the baseline is the M1.
> 
> If you want to have generic fallback compatible strings with versions,
> that's fine too. I'm not really a fan of version numbers that are just
> made up by the binding author though. Most SoC vendors don't have
> rigorous versioning of their IP and those that do seem to have a new
> version on every SoC.
> 
> The important part is *always* having an SoC specific compatible so
> you can deal with any quirk or feature without having to change the
> DTB. Everyone says blocks are 'the same' until they aren’t.
> 
Is it fine if such a SoC-specific compatible is present but with having
the driver only know about AAPL,a11-aic for example?
(To just have it when it’d be needed if ever in the future, but not uselessly
add entries to the driver that will not be currently used)

On a tangent:

The internal naming scheme used by Apple is off-by-one:

Apple A14 for example is Apple H13P (H-series 13th gen processor, Phone)
Apple M1 is Apple H13G (H-series 13th gen, G series)
(And Apple A12X is Apple H11G for example, with A12 being H11P)

Should we bother with those or use the marketing names? Especially because
the beefier SoCs might not be of the H series anyway… as the internal scheme
reveals that M1 could as well have been an A14X.

And there’s also the other internal naming scheme:
Apple A12 being t8020, Apple A12X being t8027
Apple A14 being t8101
Apple M1 being t8103

T there means the foundry at which the chip was manufactured, in the cases above TSMC.

Of course Apple itself uses both… with the marketing name being nowhere in their device
trees.

Thank you,

> Rob


_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply index

Thread overview: 55+ 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 ` [RFC PATCH 1/7] arm64: kernel: FIQ support Mohamed Mediouni
2021-01-20 13:27 ` [RFC PATCH 2/7] arm64: kernel: Add a WFI hook Mohamed Mediouni
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 10:52   ` Arnd Bergmann
2021-01-21 11:01     ` Mohamed Mediouni
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 16:47   ` Alexander Graf
2021-01-20 18:06     ` Mohamed Mediouni
2021-01-20 18:10       ` Alexander Graf
2021-01-21 11:27   ` Will Deacon
2021-01-21 11:38     ` Arnd Bergmann
2021-01-21 11:44     ` Marc Zyngier
2021-01-21 12:47       ` Will Deacon
2021-01-21 15:12         ` Mohamed Mediouni
2021-01-21 16:25           ` Marc Zyngier
2021-01-21 17:55             ` Will Deacon
2021-01-21 18:15               ` Marc Zyngier
2021-01-21 18:22                 ` Mohamed Mediouni
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 17:11   ` Alexander Graf
2021-01-20 18:04     ` Mohamed Mediouni
2021-01-20 20:16       ` Andrew Lunn
2021-01-20 21:18   ` Stan Skowronek
2021-01-21  9:48   ` Linus Walleij
2021-01-21 10:37     ` Arnd Bergmann
2021-01-21 15:29       ` Hector Martin 'marcan'
2021-01-21 17:09         ` Rob Herring
2021-01-21 17:45       ` Rob Herring
2021-01-21 16:44     ` Rob Herring
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 ` [RFC PATCH 6/7] arm64: kernel: Apple CPU start driver Mohamed Mediouni
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-21 12:44   ` Arnd Bergmann
2021-01-21 12:50     ` Mohamed Mediouni
2021-01-21 13:00       ` Arnd Bergmann
2021-01-21 13:01         ` Hector Martin 'marcan'
2021-01-21 13:22       ` Marc Zyngier
2021-01-21 13:32         ` Mark Rutland
2021-01-21 14:05           ` Marc Zyngier
2021-01-21 13:34         ` Mohamed Mediouni
2021-01-21 14:10           ` Marc Zyngier
2021-01-21 15:09             ` Arnd Bergmann
2021-01-21 15:18               ` Mohamed Mediouni
2021-01-21 16:40       ` Rob Herring
2021-01-21 16:43         ` Mohamed Mediouni
2021-01-21 17:37           ` Rob Herring
2021-01-21 18:08             ` Mohamed Mediouni [this message]
2021-01-21 18:57               ` Rob Herring
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=950D140B-491A-40EB-9FDB-D7173B86737B@caramail.com \
    --to=mohamed.mediouni@caramail.com \
    --cc=arnd@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=maz@kernel.org \
    --cc=robh@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: link

Linux-ARM-Kernel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/0 linux-arm-kernel/git/0.git
	git clone --mirror https://lore.kernel.org/linux-arm-kernel/1 linux-arm-kernel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 linux-arm-kernel linux-arm-kernel/ https://lore.kernel.org/linux-arm-kernel \
		linux-arm-kernel@lists.infradead.org
	public-inbox-index linux-arm-kernel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.infradead.lists.linux-arm-kernel


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git