[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m1mz1yyayw.fsf@ebiederm.dsl.xmission.com>
Date: Tue, 27 Mar 2007 09:15:03 -0600
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Grant Grundler <grundler@...isc-linux.org>
Cc: Greg KH <greg@...ah.com>,
Mitch Williams <mitch.a.williams@...el.com>,
Michael Ellerman <michael@...erman.id.au>,
linux-pci@...ey.karlin.mff.cuni.cz, gregkh@...e.de,
linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
auke-jan.h.kok@...el.com
Subject: Re: [PATCH 2.6.21-rc5] MSI: read-flush MSI-X table
Grant Grundler <grundler@...isc-linux.org> writes:
> On Tue, Mar 27, 2007 at 07:23:16AM -0600, Eric W. Biederman wrote:
>> I guess I should add that I'm not certain that the code is exactly correct
>> there are weird differences between enable/disable and mask.
>
> My understanding was "enable" would clear (or ignore) pending interrupts
> and "unmask" would deliver pending interrupts. Disable and mask could
> in many implementations be the same thing as long as the enable/unmask
> difference was supported.
enable/disable are what are available to drivers. When the call
enable_irq or disable_irq. Frequently we have code to make up
for deficiencies in the hardware irq controller implementations
here.
mask/unmask are helper functions only used by the internals of the
irq implementation, and actually are required to touch the hardware.
The problem on x86 is that an ioapic will drop interrupts that come
in while it is masked. Thus we have to play software games not
to loose pending interrupts (i.e. leave the irq enabled until we
get a pending interrupt).
So I think you had the general drift although you had a couple of
details confused.
Eric
-
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