From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Arjan van de Ven <arjan@infradead.org>
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Utz Bacher <utz.bacher@de.ibm.com>,
Jens Osterkamp <Jens.Osterkamp@de.ibm.com>,
linuxppc64-dev@ozlabs.org, Jeff Garzik <jgarzik@pobox.com>
Subject: Re: [PATCH] net: add driver for the NIC on Cell Blades
Date: Thu, 30 Jun 2005 09:48:20 +1000 [thread overview]
Message-ID: <1120088901.31924.31.camel@gaston> (raw)
In-Reply-To: <1120030346.3196.21.camel@laptopd505.fenrus.org>
> >
> > Could you be more specific? My guess would be that the 'sync' in writel
> > takes care of this. Should there be an extra mmiowb() in here or are
> > you referring to some other problem?
>
> different problem. the sync will get the byte out of the cpu. It won't
> get it out of the pci bridges...
>
> In short, pci bridges are allowed to buffer (post) writes until data
> traffic in the other direction happens (eg readl() or dma).
>
> In cases where you want your writel to hit the device instantly (and
> disabling irqs is generally one of those) you need to flush this posting
> cache with a dummy readl().
As I keep repeating over and over again, nothing will guarantee that
your interrupt is actually disabled here, not even a readl(). You _must_
make sure you are ready for a spurrious interrupt coming in, though in
that case, the interrupt will probably be very short.
The thing is, interrupts (not MSIs tho, but the problem is still
potentially there at the APIC level) are totally asynchronous to PCI
transactions. By the time you readl() back (and thus flush your PCI
posting buffers), or are approx. sure that the chip will have
de-asserted it's IRQ line (oh well, that isn't even sure, it may take a
few cycles depending on the HW you have there). But the IRQ may already
have been "captured" by the PIC, or even by several layers of PICs. By
the time the IRQ de-assertion propagates all the way to the CPU, you may
already have taken it.
Since those PCI IRQs are level, hopefully, it will go down real soon
(unless you have a misconfigured PIC along the chain), so it most cases,
it's just a matter of ignoring it. If it's safe, just read your device
IRQ status reg and your IRQ routine will "notice" that there is nothing
to do. (Note that returning IRQ_NONE there may confuse the core, heh !).
If it's not, then you need a local variable indicating that you did
indeed mask interrupts, and that cause your handler to just bail out. It
may get re-entered a couple of time, but ultimately, the IRQ will go
down.
Ben
prev parent reply other threads:[~2005-06-29 23:48 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-06-28 13:28 [PATCH] net: add driver for the NIC on Cell Blades Arnd Bergmann
2005-06-28 13:47 ` [PATCH] net: add missing include to netdevice.h Arnd Bergmann
2005-06-28 22:59 ` David S. Miller
2005-06-28 13:53 ` [PATCH] net: add driver for the NIC on Cell Blades Arjan van de Ven
2005-06-29 0:38 ` Arnd Bergmann
2005-06-29 7:32 ` Arjan van de Ven
2005-06-29 12:55 ` Arnd Bergmann
2005-06-29 23:48 ` Benjamin Herrenschmidt [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1120088901.31924.31.camel@gaston \
--to=benh@kernel.crashing.org \
--cc=Jens.Osterkamp@de.ibm.com \
--cc=arjan@infradead.org \
--cc=jgarzik@pobox.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc64-dev@ozlabs.org \
--cc=netdev@vger.kernel.org \
--cc=utz.bacher@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).