From: Sander Vanheule <sander@svanheule.net>
To: Thomas Bogendoerfer <tsbogend@alpha.franken.de>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Marc Zyngier <maz@kernel.org>,
Aleksander Jan Bajkowski <olek2@wp.pl>,
Hauke Mehrtens <hauke@hauke-m.de>,
git@birger-koblitz.de, linux-mips@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] MIPS: smp-mt: enable all hardware interrupts on second VPE
Date: Thu, 07 Jul 2022 17:12:42 +0200 [thread overview]
Message-ID: <468a2c8578d099eef0e0106fe273f73f5d70ef94.camel@svanheule.net> (raw)
In-Reply-To: <20220707143930.GA14693@alpha.franken.de>
On Thu, 2022-07-07 at 16:39 +0200, Thomas Bogendoerfer wrote:
> On Thu, Jul 07, 2022 at 02:57:15PM +0200, Martin Blumenstingl wrote:
> > On Thu, Jul 7, 2022 at 12:11 PM Thomas Bogendoerfer
> > <tsbogend@alpha.franken.de> wrote:
> > [...]
> > > > - why can MIPS CPU interrupt 6 and 7 be enabled unconditionally while
> > > > 2-5 cannot be enabled unconditionally?
> > >
> > > 7 is timer interrupt and is usually wired for 34K cpus and 6 is
> > > performance counter hopefully handled as well. And I agree that
> > > this still isn't the best approach here
> > Thanks for this explanation!
> >
> > > > - seeing that there's also a mips_gic_present() check in the opposite
> > > > case of what Aleksander's patch modifies: does this indicate that
> > > > unmasking CPU interrupt lines for VPE 1 is not handled by the MIPS CPU
> > > > interrupt controller driver at all at this point (and if so: do you
> > > > have any suggestions how to properly fix this)?
> > >
> > > I haven't checked how GIC is integrated. Iirc it does something similair
> > > to Lantiq's irq controller and hides all CPU internal interrupts behind
> > > it.
> > >
> > > So I see two solutions for your problem.
> > >
> > > 1. Add "mti,cpu-interrupt-controller" to the DT and wire it up
> > I think this is the preferred way. I tried this before (if you are
> > curious, see [0] and [1]) and it didn't work.
> > Are you aware of any MIPS SoC with upstream drivers which do have
> > working IRQs on VPE 1?
>
> I don't know of such SoC. Looking at the comment in vsmp_init_secondary()
>
> /* This is Malta specific: IPI,performance and timer interrupts */
>
> there is probably some Malta board using it.
>
> > Or can you point me to the code in
> > drivers/irqchip/irq-mips-cpu.c that's responsible for enabling the
> > interrupts on VPE 1 (is it simply unmask_mips_irq)?
>
> IMHO there is the problem, irq-mips-cpu.c can only do CPU irq operations
> on the same CPU. I've checked MIPS MT specs and it's possible do
> modify CP0 registers between VPEs. Using that needs changes in
> irq-mips-cpu.c. But mabye that's not woth the effort as probably
> all SMP cabable platforms have some multi processort capable
> interrupt controller implemented.
Maybe I'm not getting this right, but as I understand vsmp_init_secondary() is
run on VPE1, changing the local c0_status on that VPE. When unmask_mips_irq() is
called from code running on VPE1, I would expect it does the same thing: enable
the requested irq on VPE1 by modifying the local c0_status register.
Since these IRQs can be configured VPE, aren't these then also per-cpu
interrupts? I have been wondering if a cascaded IRQ controller needs to take
special care with such per-cpu interrupts, but haven't been able to figure that
out until now.
Sorry if the above doesn't make much sense, but like Aleksander I've been
struggling with this and would like to understand what the proper solution is.
Best,
Sander
> I thought about another way solve the issue. By introducing a
> new function in smp-mt.c which sets the value of the interrupt
> mask for the secondary CPU, which is then used in vsmp_init_secondary().
> Not sure if this is worth the effort compared to a .boot_secondary
> override.
>
> Thomas.
>
next prev parent reply other threads:[~2022-07-07 15:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-02 19:07 Aleksander Jan Bajkowski
2022-07-03 18:15 ` Sander Vanheule
2022-07-06 7:05 ` Marc Zyngier
2022-07-06 8:19 ` Thomas Bogendoerfer
2022-07-06 9:53 ` Marc Zyngier
2022-07-07 9:57 ` Thomas Bogendoerfer
2022-07-06 9:56 ` Martin Blumenstingl
2022-07-07 10:06 ` Thomas Bogendoerfer
2022-07-07 12:57 ` Martin Blumenstingl
2022-07-07 14:39 ` Thomas Bogendoerfer
2022-07-07 15:12 ` Sander Vanheule [this message]
2022-07-09 16:11 ` Birger Koblitz
2022-07-28 15:50 ` Martin Blumenstingl
2022-08-01 15:25 ` Thomas Bogendoerfer
2022-08-01 16:02 ` Sander Vanheule
2022-08-02 7:15 ` Birger Koblitz
2022-09-10 10:53 ` Aleksander Bajkowski
2022-09-12 14:02 ` Thomas Bogendoerfer
2022-07-05 10:35 ` Thomas Bogendoerfer
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=468a2c8578d099eef0e0106fe273f73f5d70ef94.camel@svanheule.net \
--to=sander@svanheule.net \
--cc=git@birger-koblitz.de \
--cc=hauke@hauke-m.de \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=maz@kernel.org \
--cc=olek2@wp.pl \
--cc=tsbogend@alpha.franken.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
all inboxes | Powered by JetHome®