Hi Thomas,
On Mon, 2022-08-01 at 17:25 +0200, Thomas Bogendoerfer wrote:
> 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 ?
That would be the SoCs supported by MACH_REALTEK_RTL. More specifically, the
ones affected by this issue are the RTL8391M, RTL8392M, RTL8393M, and RTL8396M
which have two VPEs.
The SoC interrupt controller on these chips can route interrupts to all CPU HW
interrupts. If only IP6 and IP7 are enabled on the second VPE, anything routed
there to IP2-IP5 ends up in a black hole.
Best,
Sander
>
> > 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.
>
