From: Hector Martin <marcan@marcan.st>
To: Marc Zyngier <maz@kernel.org>
Cc: Thomas Gleixner <tglx@linutronix.de>,
Rob Herring <robh+dt@kernel.org>, Sven Peter <sven@svenpeter.dev>,
Alyssa Rosenzweig <alyssa@rosenzweig.io>,
linux-arm-kernel@lists.infradead.org,
linux-kernel@vger.kernel.org, devicetree@vger.kernel.org
Subject: Re: [PATCH 2/6] irqchip/apple-aic: Add Fast IPI support
Date: Sat, 18 Dec 2021 14:31:28 +0900 [thread overview]
Message-ID: <83631cf6-46c5-cd87-c3a7-6b619669a943@marcan.st> (raw)
In-Reply-To: <87sfuyt3nh.wl-maz@kernel.org>
On 12/12/2021 21.21, Marc Zyngier wrote:
>> +/* MPIDR fields */
>> +#define MPIDR_CPU GENMASK(7, 0)
>> +#define MPIDR_CLUSTER GENMASK(15, 8)
>
> This should be defined in terms of MPIDR_AFFINITY_LEVEL() and co.
Yeah, I found out about that macro from your PMU driver... :)
>> +static const struct aic_info aic1_fipi_info = {
>> + .version = 1,
>> +
>> + .fast_ipi = true,
>
> Do you anticipate multiple feature flags like this? If so, maybe we
> should consider biting the bullet and making this an unsigned long
> populated with discrete flags.
>
> Not something we need to decide now though.
Probably not, but who knows! It's easy to change it later, though.
>> if (read_sysreg_s(SYS_IMP_APL_IPI_SR_EL1) & IPI_SR_PENDING) {
>> - pr_err_ratelimited("Fast IPI fired. Acking.\n");
>> - write_sysreg_s(IPI_SR_PENDING, SYS_IMP_APL_IPI_SR_EL1);
>> + if (aic_irqc->info.fast_ipi) {
>
> On the other hand, this is likely to hit on the fast path. Given that
> we know at probe time whether we support SR-based IPIs, we can turn
> this into a static key and save a few fetches on every IPI. It applies
> everywhere you look at this flag at runtime.
Good point, I'll see about refactoring this to use static keys.
>> +static void aic_ipi_send_fast(int cpu)
>> +{
>> + u64 mpidr = cpu_logical_map(cpu);
>> + u64 my_mpidr = cpu_logical_map(smp_processor_id());
>
> This is the equivalent of reading MPIDR_EL1. My gut feeling is that it
> is a bit faster to access the sysreg than a percpu lookup, a function
> call and another memory access.
Yeah, I saw other IRQ drivers doing this, but I wasn't sure it made
sense over just reading MPIDR_EL1... I'll switch to that.
>> + u64 idx = FIELD_GET(MPIDR_CPU, mpidr);
>> +
>> + if (FIELD_GET(MPIDR_CLUSTER, my_mpidr) == cluster)
>> + write_sysreg_s(FIELD_PREP(IPI_RR_CPU, idx),
>> + SYS_IMP_APL_IPI_RR_LOCAL_EL1);
>> + else
>> + write_sysreg_s(FIELD_PREP(IPI_RR_CPU, idx) | FIELD_PREP(IPI_RR_CLUSTER, cluster),
>> + SYS_IMP_APL_IPI_RR_GLOBAL_EL1);
>
> Don't you need an ISB, either here or in the two callers? At the
> moment, I don't see what will force the execution of these writes, and
> they could be arbitrarily delayed.
Is there any requirement for timeliness sending IPIs? They're going to
another CPU after all, they could be arbitrarily delayed because it has
FIQs masked.
>> - if (atomic_read(this_cpu_ptr(&aic_vipi_flag)) & irq_bit)
>> - aic_ic_write(ic, AIC_IPI_SEND, AIC_IPI_SEND_CPU(smp_processor_id()));
>> + if (atomic_read(this_cpu_ptr(&aic_vipi_flag)) & irq_bit) {
>> + if (ic->info.fast_ipi)
>> + aic_ipi_send_fast(smp_processor_id());
>
> nit: if this is common enough, maybe having an aic_ipi_send_self_fast
> could be better. Needs evaluation though.
I'll do some printing to see how common self-IPIs are when running
common workloads, let's see. If it's common enough it's easy enough to add.
>> + irqc->info = *(struct aic_info *)match->data;
>
> Why the copy? All the data is const, and isn't going away.
... for now, but later patches then start computing register offsets and
putting them into this structure :)
--
Hector Martin (marcan@marcan.st)
Public Key: https://mrcn.st/pub
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2021-12-18 5:33 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-09 4:32 [PATCH 0/6] irqchip/apple-aic: Add support for AICv2 Hector Martin
2021-12-09 4:32 ` [PATCH 1/6] dt-bindings: interrupt-controller: apple, aic: Add apple, aic2 support Hector Martin
2021-12-09 17:28 ` [PATCH 1/6] dt-bindings: interrupt-controller: apple,aic: Add apple,aic2 support Rob Herring
2021-12-11 12:28 ` Hector Martin
2021-12-11 12:44 ` [PATCH 1/6] dt-bindings: interrupt-controller: apple, aic: Add apple, aic2 support Marc Zyngier
2021-12-11 12:52 ` [PATCH 1/6] dt-bindings: interrupt-controller: apple,aic: Add apple,aic2 support Hector Martin
2021-12-11 12:49 ` Mark Kettenis
2021-12-09 4:32 ` [PATCH 2/6] irqchip/apple-aic: Add Fast IPI support Hector Martin
2021-12-12 12:21 ` Marc Zyngier
2021-12-18 5:31 ` Hector Martin [this message]
2021-12-20 12:43 ` Marc Zyngier
2021-12-09 4:32 ` [PATCH 3/6] irqchip/apple-aic: Switch to irq_domain_create_tree and sparse hwirqs Hector Martin
2021-12-12 14:37 ` Marc Zyngier
2021-12-18 5:36 ` Hector Martin
2021-12-09 4:32 ` [PATCH 4/6] irqchip/apple-aic: Dynamically compute register offsets Hector Martin
2021-12-12 18:26 ` Marc Zyngier
2021-12-18 5:37 ` Hector Martin
2021-12-09 4:32 ` [PATCH 5/6] irqchip/apple-aic: Support multiple dies Hector Martin
2021-12-13 16:10 ` Marc Zyngier
2021-12-18 5:39 ` Hector Martin
2021-12-20 13:38 ` Marc Zyngier
2021-12-09 4:32 ` [PATCH 6/6] irqchip/apple-aic: Add support for AICv2 Hector Martin
2021-12-12 18:47 ` Marc Zyngier
2021-12-18 6:02 ` Hector Martin
2021-12-20 13:52 ` 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=83631cf6-46c5-cd87-c3a7-6b619669a943@marcan.st \
--to=marcan@marcan.st \
--cc=alyssa@rosenzweig.io \
--cc=devicetree@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maz@kernel.org \
--cc=robh+dt@kernel.org \
--cc=sven@svenpeter.dev \
--cc=tglx@linutronix.de \
/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).