[RFC/PATCH 0/16] Ops based MSI Implementation

[Michael Ellerman]

On Sat, 2007-01-27 at 23:16 -0700, Eric W. Biederman wrote:
> Michael Ellerman <michael at ellerman.id.au> writes:
> 
> > I guess I wasn't clear enough in my original post, but I fully expect
> > that I'll need to tweak parts of the core to make Intel fit. That's
> > still a work in progress.
> 
> Ok.  To be very clear.
> 
> Any plan that does not involve using drivers/pci/msi.c for the
> raw hardware operations is flawed.  Yes that code is a mess
> but it works today, and appears to capture all of the requirements.
> Where there are issues that code should be fixed not ignored.

Which is what I plan to do. I already have a patch which turns the
current code into a backend for my code, its ugly as hell, it maintains
msi_info and the msi_descs which is stupid, but it seems to work.

We should probably just stop talking until I've got that series worked
out and posted, and then you can tell me what you think of it :)

> The architecture specific bits of the current msi code roughly
> correspond to your alloc and free routines.  All that is
> needed going from generic code to architecture specific code
> is the ability to allocate and free an msi irq.  You have
> a lot more operations than that and it is overkill.

Except you keep ignoring the hypervisor case, which we have to support.
I realise you'd rather not think about it, sure it's ugly, but that's
our reality. We could isolate all of that in arch/powerpc, but Greg has
said he doesn't want two implementations, and I think in the long term
that's the right approach - we should be able to come up with a common
implementation.

> As a practical measure you current operations are such a bad fit
> for the architectures a port would be very difficult.  Basically
> setup_msi_message is simply a bad idea.  You need to use a
> write_msi_message call from the architecture to the generic code
> instead.

i386's msi_compose_msg() would just become setup_msi_message(), the
setup of the irq chip etc. would go in alloc. For irq affinity, for now
we'll just keep exporting read/write_msi_msg(). But I don't see what the
fundamental problem is.

> I have some patches cooking to cleanup msi.c so it can be used
> as is.  I'm pretty much their but it looks like I need to slay
> msi_lock to make things sane.

If you can post them soon that would be good. I'm already heavily
hacking the intel code to work as a backend for me so anything you do
will conflict with that work.

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20070128/3003e6b6/attachment.pgp>