From: Arjan van de Ven <arjan@infradead.org>
To: Steve Wise <swise@opengridcomputing.com>
Cc: rdreier@cisco.com, mshefty@ichips.intel.com,
linux-kernel@vger.kernel.org, netdev@vger.kernel.org,
openib-general@openib.org
Subject: Re: [PATCH v3 1/7] AMSO1100 Low Level Driver.
Date: Wed, 21 Jun 2006 19:13:33 +0200 [thread overview]
Message-ID: <1150910013.3057.59.camel@laptopd505.fenrus.org> (raw)
In-Reply-To: <1150907571.31600.31.camel@stevo-desktop>
> 0;
> > > +
> > > + __raw_writew(0, elem->hw_desc + C2_RXP_STATUS);
> > > + __raw_writew(0, elem->hw_desc + C2_RXP_COUNT);
> > > + __raw_writew(0, elem->hw_desc + C2_RXP_LEN);
> >
> > you seem to be a fan of the __raw_write() functions... any reason why?
> > __raw_ is not a magic "go faster" prefix....
> >
>
> In this particular case, I believe this is done to avoid a swap of '0'
> since its not necessary.
but.. that should writew() and co just autodetect (or do it at compile
time)...
(maybe it doesn't and we have an optimization opportunity here ;)
> > Also on a related note, have you checked the driver for the needed PCI
> > posting flushes?
> >
>
> Um, what's a 'PCI posting flush'? Can you point me where its
> described/used so I can see if we need it? Thanx.
ok pci posting...
basically, if you use writel() and co, the PCI bridges in the middle are
allowed (and the more fancy ones do) cache the write, to see if more
writes follow, so that the bridge can do the writes as a single burst to
the device, rather than as individual writes. This is of course great...
... except when you really want the write to hit the device before the
driver continues with other actions.
Now the PCI spec is set up such that any traffic in the other direction
(basically readl() and co) will first flush the write through the system
before the read is actually sent to the device, so doing a dummy readl()
is a good way to flush any pending posted writes.
Where does this matter?
it matters most at places such as irq enabling/disabling, IO submission
and possibly IRQ acking, but also often in eeprom-like read/write logic
(where you do manual clocking and need to do delays between the
write()'s). But in general... any place where you do writel() without
doing any readl() before doing nothing to the card for a long time, or
where you are waiting for the card to do something (or want it done NOW,
such as IRQ disabling) you need to issue a (dummy) readl() to flush
pending writes out to the hardware.
does this explanation make any sense? if not please feel free to ask any
questions, I know I'm not always very good at explaining things.
Greetings,
Arjan van de Ven
next prev parent reply other threads:[~2006-06-21 17:13 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-20 20:30 [PATCH v3 0/7][RFC] Ammasso 1100 iWARP Driver Steve Wise
2006-06-20 20:30 ` [PATCH v3 1/7] AMSO1100 Low Level Driver Steve Wise
2006-06-20 20:43 ` Arjan van de Ven
2006-06-21 16:32 ` Steve Wise
2006-06-21 17:13 ` Arjan van de Ven [this message]
2006-06-21 18:47 ` Steve Wise
2006-06-21 17:37 ` [openib-general] " Grant Grundler
2006-06-23 13:44 ` Steve Wise
2006-06-23 13:48 ` Arjan van de Ven
2006-06-23 13:56 ` Steve Wise
2006-06-23 14:04 ` Arjan van de Ven
2006-06-23 17:14 ` [openib-general] " Grant Grundler
2006-06-20 20:31 ` [PATCH v3 3/7] AMSO1100 OpenFabrics Provider Steve Wise
2006-06-20 20:31 ` [PATCH v3 4/7] AMSO1100 Memory Management Steve Wise
2006-06-20 20:31 ` [PATCH v3 5/7] AMSO1100 Message Queues Steve Wise
2006-06-20 20:31 ` [PATCH v3 6/7] AMSO1100: Privileged Verbs Queues Steve Wise
2006-06-20 20:31 ` [PATCH v3 7/7] AMSO1100 Makefiles and Kconfig changes Steve Wise
2006-06-20 21:00 ` [PATCH v3 2/7] AMSO1100 WR / Event Definitions Steve Wise
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=1150910013.3057.59.camel@laptopd505.fenrus.org \
--to=arjan@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mshefty@ichips.intel.com \
--cc=netdev@vger.kernel.org \
--cc=openib-general@openib.org \
--cc=rdreier@cisco.com \
--cc=swise@opengridcomputing.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