[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1215848240.7549.168.camel@pasglop>
Date: Sat, 12 Jul 2008 17:37:20 +1000
From: Benjamin Herrenschmidt <benh@...nel.crashing.org>
To: Matthew Wilcox <matthew@....cx>
Cc: linux-pci@...r.kernel.org, linux-kernel@...r.kernel.org,
grundler@...isc-linux.org, mingo@...e.hu, tglx@...utronix.de,
jgarzik@...ox.com, linux-ide@...r.kernel.org,
suresh.b.siddha@...el.com, jbarnes@...tuousgeek.org,
rdunlap@...otime.net, mtk.manpages@...il.com
Subject: Re: Multiple MSI, take 4
On Fri, 2008-07-11 at 15:16 -0600, Matthew Wilcox wrote:
> Here we go with take 4. Changes:
>
> - Check the requested number of interrupts against the maximum number
> the device claims to support. Thanks to Hidetoshi Seto for pointing
> out this oversight.
> - Implemented Eric's suggestion of using a single IRQ and storing the
> data with it.
> - As a result, don't try to support the mode in the AHCI driver where
> the excess ports all share the last interrupt. It could be done, but
> it would be rather messy and I don't have hardware that supports that
> mode anyway.
>
> I'm fairly comfortable with the subchannel notion we're introducing
> here. It's more flexible than MSI and doesn't impose a penalty on
> architectures which don't implement it. It makes some things more
> complex, but it makes other things simpler, so I think it's a wash from
> a cleanliness standpoint.
I prefer you initial approach. If those are effectively one interrupt,
you end up with the whole IRQ_INPROGRESS logic going bonkers trying to
prevent them from occuring at the same time and possibly losing some.
I think the masking "issue" is mostly a non-issue as I explained in
other emails.
Cheers,
Ben.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists