Re: [PATCH 2/2] Initial generic hypertransport interrupt support.

[Eric W. Biederman]

Segher Boessenkool <segher@xxxxxxxxxxxxxxxxxxx> writes:

>> As for supporting multiple irqs in plain MSI mode, I don't think
>> we want to do that.  The problem is that multiple interrupts
>> in msi mode cannot be individually routed.
>
> On some(/many/most) platforms that isn't a problem.  Platforms
> for which it is can just refuse to allocate more than one MSI
> at once.

It is a problem on all platforms that currently implement MSI.

>> I think we really want
>> to encourage vendors who are building cards with multiple MSI irqs
>> to use MSI-X.  MSI-X has a lot fewer ugly special cases and all
>> architectures can individually route the irqs.
>
> We still should support whatever hardware already exists, if
> possible.

Which hardware is this a problem for?

MSI and MSI-X only guarantee the availability of 1 irq if I recall
correctly.  More are a bonus so cards should be able to fall back
to a single irq mode.

>> If there are interesting cards that support just MSI mode and really
>> need more than one irq I would be happy to reconsider that decision
>> but my impression was that plain MSI was basically not quite flexible
>> enough to really be interesting, and supporting just one MSI irq was
>> ok but any more would lead to all kinds of strange special cases.
>
> Individual drivers can deal with those special cases if they are device-
> specific; and the platform can just refuse to do more than one MSI if
> something platform-specific would prevent correct operation.
>
> It would be nice to have the MSI and MSI-X interfaces have the same
> calling convention; in fact, they can probably be folded into one.

Examples? details? patches?

Part of the problem with plain MSI is that you can't mask irqs at the
source, in a generic way.

How do your ideas compare with my hypertransport irq implementation?

Eric
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/