Interrupts on all CPUs

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Interrupts on all CPUs

Andrew Turner
We have a problem on ARM where some interrupts need to be unmasked on
all CPUs in an SMP environment. The main place we need this is with the
timer driver as the hardware can send interrupts to the requested CPU.

Until now we have hacked around this by unmasking the three interrupts
the timer hardware uses when we enable the non-boot CPU. Luckily these
interrupts values have been common across all SoCs, however there is no
requirement for this to be the case.

To fix this I'm proposing adding a flag to bus_setup_intr to add
support for per-cpu interrupts. The architecture code is then expected
to perform whatever is needed to handle this.

I have attached a proof of concept patch that adds support to arm64 for
this. When we setup an interrupt with the flag set it will record this
so when the non-boot CPUs are enabled they can unmask the interrupt. It
will then signal to any running CPUs to unmask the given interrupt.

I would expect this could be extended to other architectures, however I
only know the arm and arm64 code, and am only able to test there.

Andrew
_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"

0001-WIP-Allow-per-cpu-interrupts.patch (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Interrupts on all CPUs

meloun
 > We have a problem on ARM where some interrupts need to be unmasked on

> all CPUs in an SMP environment. The main place we need this is with the
> timer driver as the hardware can send interrupts to the requested CPU.
>
> Until now we have hacked around this by unmasking the three interrupts
> the timer hardware uses when we enable the non-boot CPU. Luckily these
> interrupts values have been common across all SoCs, however there is no
> requirement for this to be the case.
>
> To fix this I'm proposing adding a flag to bus_setup_intr to add
> support for per-cpu interrupts. The architecture code is then expected
> to perform whatever is needed to handle this.
>
> I have attached a proof of concept patch that adds support to arm64 for
> this. When we setup an interrupt with the flag set it will record this
> so when the non-boot CPUs are enabled they can unmask the interrupt. It
> will then signal to any running CPUs to unmask the given interrupt.
>
> I would expect this could be extended to other architectures, however I
> only know the arm and arm64 code, and am only able to test there.
>
> Andrew

I don’t think that this patch solves the problem. In some case, we must
initialize per core hardware before we can enable interrupt for it.
This is for example, case of the qcom Krait per core devices.
I'm thinking about something like that config_intrhook for registering
“secondary_attach()” functions  from each appropriate driver. The list
can be executed as part of secondary_init(), in same order as registered.
This, of course implies existence of specific SGI and PPI variant of
bus_setup_interrupt() that have core ID as argument and allows multiple
activation.
Moreover, this approach removed necessary of direct calls for
initialization of secondary cores in gic and timer drivers.
What do you think?
Michal

_______________________________________________
[hidden email] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-arch
To unsubscribe, send any mail to "[hidden email]"