This patchset is against gregkh-pci but except for the context around
msi_lookup_irq being completely different it applies cleanly to 2.6.20-rc6
as well.
When I first looked at this problem I thought no big deal it will one
or two simple patches and that is it.
When I looked more closely I discovered that to be certain of not introducing
bugs I would have to kill msi_lock, which made the problem a little more
difficult.
The result of this patchset is that architecture hooks become:
int arch_setup_msi_irq(struct pci_dev *dev, struct msi_desc *desc);
void arch_teardown_msi_irq(unsigned int irq);
and are responsible for allocating and freeing the irq as well
as setting it up.
This touches the architecture code for i386, x86_64, and ia64 to
accomplish this.
Since I couldn't test ia64 I reviewed the code closely, and compile
tested it.
The other big change is that I added a field to irq_desc to point
at the msi_desc. This removes the conflicts with the existing pointer
fields and makes the irq -> msi_desc mapping useable outside of msi.c
The only architecture problem that isn't solvable in this context is
the problem of supporting the crazy hypervisor on the ppc RTAS, which
asks us to drive the hardware but does not give us access to the
hardware registers.
Eric
The other big change is that I added a field to irq_desc to point
at the msi_desc. This removes the conflicts with the existing pointer
fields and makes the irq -> msi_desc mapping useable outside of msi.c
I'm not even sure we would have needed that with Michael's mecanism in
fact. One other reason why I prefer it.
Basically, backends like MPIC etc... don't need it. The irq chip
operations are normal MPIC operations and don't need to know they are
done on an MSI nor what MSI etc... and thus we don't need it. Same with
RTAS.
On the other hand, x86 needs it, but then, x86 uses it's own MSI
specific irq_chip, in which case it can use irq_desc->chip_data as long
as it does it within the backend.
So I may have missed a case where a given backend might need both that
irq -> msi_desc mapping -and- use irq_desc->chip_data for other things,
but that's one thing I was hoping we could avoid with Michael's code.
The only architecture problem that isn't solvable in this context is
the problem of supporting the crazy hypervisor on the ppc RTAS, which
asks us to drive the hardware but does not give us access to the
hardware registers.
So you are saying that we should use your model while admitting that it
can't solve our problems...
I really don't understand why you seem so totally opposed to Michael's
approach which definitely looks to me like the sane thing to do. Note
that in the end, Michael's approach isn't -that- different from yours,
just a bit more abstracted.
Ben.
Benjamin Herrenschmidt wrote:
quoted
The only architecture problem that isn't solvable in this context is
the problem of supporting the crazy hypervisor on the ppc RTAS, which
asks us to drive the hardware but does not give us access to the
hardware registers.
So you are saying that we should use your model while admitting that it
can't solve our problems...
I really don't understand why you seem so totally opposed to Michael's
approach which definitely looks to me like the sane thing to do. Note
that in the end, Michael's approach isn't -that- different from yours,
just a bit more abstracted.
I think the high-level ops approach makes more sense. It's more future
proof, in addition to covering all existing implementations.
Jeff
From: Jeff Garzik <redacted>
Date: Sun, 28 Jan 2007 15:47:24 -0500
I think the high-level ops approach makes more sense. It's more future
proof, in addition to covering all existing implementations.
I totally agree with this.