From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
To: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Cc: Marc Zyngier <maz@kernel.org>,
Sander Vanheule <sander@svanheule.net>,
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: Mon, 1 Aug 2022 17:25:59 +0200 [thread overview]
Message-ID: <20220801152559.GA9041@alpha.franken.de> (raw)
In-Reply-To: <CAFBinCBq3ydoxtj1VG=kjqbq5NjP1ZnQe_dOAS2Gjm2fNkK9Yg@mail.gmail.com>
On Thu, Jul 28, 2022 at 05:50:10PM +0200, Martin Blumenstingl wrote:
> I think for the Realtek SoC's this would be problematic because it's
> using MIPS_GENERIC. My understanding is that in an ideal world all
which SOC are these ?
> platforms would switch to MIPS_GENERIC.
> As an alternative to making irq-mips-cpu capable of changing another
> CPU's registers: would you also be happy with a change that implements
> the following idea (pseudocode) in vsmp_init_secondary():
> struct device_node *root_node = of_find_node_by_path("/");
>
> if (mips_gic_present() ||
> of_device_is_compatible(root_node, "lantiq,xrx200") ||
> of_device_is_compatible(root_node, "realtek,some-relevant-soc"))
> change_c0_status(ST0_IM, STATUSF_IP2 | STATUSF_IP3 |
> STATUSF_IP4 | STATUSF_IP5 |
> STATUSF_IP6 | STATUSF_IP7);
> else
> ...
>
> of_node_put(root_node);
>
> That way we don't risk enabling interrupt lines which shouldn't be
> enabled (on SoCs which we don't know).
> And also it would not cause any issues with MIPS_GENERIC support.
well it's not exactly the abstraction I'm looking for, but it's ok for me
as a short term way to move forward.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessarily a
good idea. [ RFC1925, 2.3 ]
next prev parent reply other threads:[~2022-08-01 15:26 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-07-02 19:07 [PATCH] MIPS: smp-mt: enable all hardware interrupts on second VPE 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
2022-07-09 16:11 ` Birger Koblitz
2022-07-28 15:50 ` Martin Blumenstingl
2022-08-01 15:25 ` Thomas Bogendoerfer [this message]
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=20220801152559.GA9041@alpha.franken.de \
--to=tsbogend@alpha.franken.de \
--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=sander@svanheule.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.