devicetree.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org,
	linux-kernel@vger.kernel.org, Will Deacon <will@kernel.org>,
	Hector Martin <marcan@marcan.st>, Sven Peter <sven@svenpeter.dev>,
	Alyssa Rosenzweig <alyssa@rosenzweig.io>,
	Rob Herring <robh+dt@kernel.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	Dougall <dougallj@gmail.com>,
	kernel-team@android.com
Subject: Re: [PATCH v2 3/8] irqchip/apple-aic: Add cpumasks for E and P cores
Date: Fri, 03 Dec 2021 16:32:10 +0000	[thread overview]
Message-ID: <87zgphlkdx.wl-maz@kernel.org> (raw)
In-Reply-To: <Yaed7VAlwwCBcP13@FVFF77S0Q05N>

On Wed, 01 Dec 2021 16:08:13 +0000,
Mark Rutland <mark.rutland@arm.com> wrote:
> 
> On Wed, Dec 01, 2021 at 01:49:04PM +0000, Marc Zyngier wrote:
> > In order to be able to tell the core IRQ code about the affinity
> > of the PMU interrupt in later patches, compute the cpumasks of the
> > P and E cores at boot time.
> > 
> > This relies on the affinity scheme used by the vendor, which seems
> > to work for the couple of SoCs that are out in the wild.
> 
> ... but may change at any arbitrary point in future?

Crystal balls are in short supply, sorry! ;-)

> Can we please put the affinity in the DT, like we do for other SoCs and
> devices?
> 
> I don't think we should treat this HW specially in this regard; we certaintly
> don't want other folk hard-coding system topology in their irqchip driver, and
> it should be possible to do something like the ppi-partitions binding, no?

The PPI partition is totally overkill here. What it deals with is
multiple devices sharing a single PPI across the system.

Here, we can invent our own interrupt number, so the sharing is
avoided by construction (the joy of not having an interrupt controller
the first place!).

I'm happy to stick the affinity in the DT (after all, it is likely
that other devices on these systems have the same requirements) and
have it consumed by the irqchip driver. I only need to find a way that
doesn't completely invalidate the existing binding...

	M.

-- 
Without deviation from the norm, progress is not possible.

  reply	other threads:[~2021-12-03 16:32 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-01 13:49 [PATCH v2 0/8] drivers/perf: CPU PMU driver for Apple M1 Marc Zyngier
2021-12-01 13:49 ` [PATCH v2 1/8] dt-bindings: arm-pmu: Document Apple PMU compatible strings Marc Zyngier
2021-12-12  7:27   ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 2/8] dt-bindings: apple,aic: Add CPU PMU per-cpu pseudo-interrupts Marc Zyngier
2021-12-12  7:26   ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 3/8] irqchip/apple-aic: Add cpumasks for E and P cores Marc Zyngier
2021-12-01 16:08   ` Mark Rutland
2021-12-03 16:32     ` Marc Zyngier [this message]
2021-12-12  7:22       ` Hector Martin
2021-12-12  7:30   ` Hector Martin
2021-12-13 14:43     ` Marc Zyngier
2021-12-01 13:49 ` [PATCH v2 4/8] irqchip/apple-aic: Wire PMU interrupts Marc Zyngier
2021-12-12  7:25   ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 5/8] irqchip/apple-aic: Move PMU-specific registers to their own include file Marc Zyngier
2021-12-12  7:23   ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 6/8] arm64: apple: t8301: Add PMU nodes Marc Zyngier
2021-12-12  7:26   ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 7/8] drivers/perf: arm_pmu: Handle 47 bit counters Marc Zyngier
2021-12-12  7:26   ` Hector Martin
2021-12-01 13:49 ` [PATCH v2 8/8] drivers/perf: Add Apple icestorm/firestorm CPU PMU driver Marc Zyngier
2021-12-01 16:58   ` Mark Rutland
2021-12-01 17:56     ` Alyssa Rosenzweig
2021-12-02 15:39     ` Marc Zyngier
2021-12-02 16:14       ` Mark Rutland
2021-12-03 11:22         ` Marc Zyngier
2021-12-03 12:04           ` Mark Rutland
2021-12-03 16:22             ` Marc Zyngier

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=87zgphlkdx.wl-maz@kernel.org \
    --to=maz@kernel.org \
    --cc=alyssa@rosenzweig.io \
    --cc=devicetree@vger.kernel.org \
    --cc=dougallj@gmail.com \
    --cc=kernel-team@android.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marcan@marcan.st \
    --cc=mark.rutland@arm.com \
    --cc=robh+dt@kernel.org \
    --cc=sven@svenpeter.dev \
    --cc=tglx@linutronix.de \
    --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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).