Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / Atom feed
From: Rob Herring <robh@kernel.org>
To: Mohamed Mediouni <mohamed.mediouni@caramail.com>
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 12:57:34 -0600
Message-ID: <CAL_JsqK=QMKnhOoxpb+9-wUtMFR=sfqJ7pMc=O6pR4O0hT99WQ@mail.gmail.com> (raw)
In-Reply-To: <950D140B-491A-40EB-9FDB-D7173B86737B@caramail.com>

On Thu, Jan 21, 2021 at 12:09 PM Mohamed Mediouni
<mohamed.mediouni@caramail.com> wrote:
>
>
>
> > 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)

Yes, that's expected. You add the more specific compatible when you
add the feature or quirk work-around.

>
> 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.

I'd probably lean toward the marketing names, but don't really care as
long as you're consistent both for a given SoC and across generations.

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
2021-01-21 18:57               ` Rob Herring [this message]
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='CAL_JsqK=QMKnhOoxpb+9-wUtMFR=sfqJ7pMc=O6pR4O0hT99WQ@mail.gmail.com' \
    --to=robh@kernel.org \
    --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=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

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