svn commit: r296138 - in head/sys: arm/arm arm/include kern sys

[Svatopluk Kraus]

On Sun, Feb 28, 2016 at 5:24 AM, Alexander Kabaev <kabaev at gmail.com> wrote:
> On Sat, 27 Feb 2016 16:57:03 -0800
> Adrian Chadd <adrian.chadd at gmail.com> wrote:
>
>> hi,
>>
>> I think this was mostly shared with kan's MIPS work on the CI20 as the
>> IPI stuff via the gic is effectively the same.
>>
>> Can we make this (again) something we can share, but optionally?
>>
>>
>
> Nope, mips shares no IPI code with ARM and probably shouldn't too,
> since IPI delivery and mapping between IPI types and IRQs are very
> platform specific.
>
> --
> Alexander Kabaev


IMO, it's better for MIPS IPI stuff to not be bound to ARM one in the
beginning and vice versa. Let them evolve for some time separately to
see if there are really some common parts or not.

The ARM IPI stuff was made too general with a try to fit into
interrupt framework. Thus struct intr_irqsrc was used for an IPI
description, but it does not mean that an IPI must be bounded to PIC
methods.  Very likely, the meaning of  AISHF_NOALLOC flag in
intr_ipi_set_handler() was not stressed enough. If used, an IPI
description (filter, argument, name, counters) is created and saved in
struct intr_irqsrc, but the IPI is not bounded to any PIC and no PIC
method is called. This struct can be looked at by intr_ipi_lookup()
and intr_ipi_dispatch() can be used on any place when an IPI should be
dispatched. An IPI can be send in any way.
It means that no PIC must be involved.

That said, there is some plan to make IPI stuff on ARM more clear and simple.