[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <87h76mahsl.wl-maz@kernel.org>
Date: Thu, 21 Apr 2022 10:48:26 +0100
From: Marc Zyngier <maz@...nel.org>
To: Linus Walleij <linus.walleij@...aro.org>,
Sander Vanheule <sander@...nheule.net>
Cc: linux-gpio@...r.kernel.org, devicetree@...r.kernel.org,
Bartosz Golaszewski <brgl@...ev.pl>,
Rob Herring <robh+dt@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Bert Vermeulen <bert@...t.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v1 3/6] gpio: realtek-otto: Support per-cpu interrupts
On Thu, 21 Apr 2022 00:04:16 +0100,
Linus Walleij <linus.walleij@...aro.org> wrote:
>
> On Sat, Apr 9, 2022 at 9:56 PM Sander Vanheule <sander@...nheule.net> wrote:
>
> > On SoCs with multiple cores, it is possible that the GPIO interrupt
> > controller supports assigning specific pins to one or more cores.
> >
> > IRQ balancing can be performed on a line-by-line basis if the parent
> > interrupt is routed to all available cores, which is the default upon
> > initialisation.
> >
> > Signed-off-by: Sander Vanheule <sander@...nheule.net>
>
> That sounds complicated.
>
> Sounds like something the IRQ maintainer (Marc Z) should
> have a quick look at.
This is pretty odd indeed. There seem to be a direct mapping between
the GPIOs and the CPU it interrupts (or at least that's what the code
seem to express). However, I don't see a direct relation between the
CPUs and the chained interrupt. It isn't even clear if this interrupt
itself is per-CPU.
So this begs a few questions:
- is the affinity actually affecting the target CPU? or is it
affecting the target mux?
- how is the affinity of the mux interrupt actually enforced?
M.
--
Without deviation from the norm, progress is not possible.
Powered by blists - more mailing lists