Linux wireless drivers development
 help / color / mirror / Atom feed
From: "Luis R. Rodriguez" <mcgrof@gmail.com>
To: Nick Kossifidis <mickflemm@gmail.com>
Cc: "Luis R. Rodriguez" <mcgrof@bombadil.infradead.org>,
	Matthew Wilcox <matthew@wil.cx>,
	linux-wireless <linux-wireless@vger.kernel.org>,
	ath5k-devel@lists.ath5k.org,
	Stephen Hemminger <shemminger@vyatta.com>,
	Kyle McMartin <kyle@mcmartin.ca>
Subject: Re: pci_set_mwi() and ath5k
Date: Wed, 4 Nov 2009 14:45:30 -0800	[thread overview]
Message-ID: <43e72e890911041445s4e69aa46nda01d423c1bd8f7d@mail.gmail.com> (raw)
In-Reply-To: <40f31dec0911041431i6f718bf1x1e52d9e12ab22060@mail.gmail.com>

On Wed, Nov 4, 2009 at 2:31 PM, Nick Kossifidis <mickflemm@gmail.com> wrote:
> 2009/11/5 Luis R. Rodriguez <mcgrof@bombadil.infradead.org>:
>> On Wed, Nov 04, 2009 at 02:04:11PM -0800, Luis R. Rodriguez wrote:
>>> On Wed, Nov 4, 2009 at 2:00 PM, Matthew Wilcox <matthew@wil.cx> wrote:
>>> > On Wed, Nov 04, 2009 at 01:52:30PM -0800, Luis R. Rodriguez wrote:
>>> >> > Even better: I just confirmation from our systems team that our legacy
>>> >> > devices and 11n PCI devices don't support MWR so I'll remove all that
>>> >> > cruft crap.
>>> >>
>>> >> I meant MWI of course.
>>> >
>>> > Yes, but they don't necessarily just use cacheline size for MWI ... some
>>> > devices use cacheline size for setting up data structures.  Might be
>>> > worth just checking explicitly that they don't use the cacheline size
>>> > register for anything.
>>>
>>> Oh right -- so the typical Atheros hack for this is to check the cache
>>> line size, and if its 0 set it to L1_CACHE_BYTES. Then eventually read
>>> from PCI_CACHE_LINE_SIZE pci config to align the skb data. So what I
>>> was doing now is removing all this cruft and replacing it with a
>>> generic allocator for atheros drivers that aligns simply to the
>>> L1_CACHE_BYTES. Sound kosher?
>>
>> Something like this:
>>
>
> According to comments inside MadWiFi AR5210 needs cache line align
> else we get corruptions.

For what though?

> I don't know if this is correct for all
> platforms or later cards but since we (plan to) support AR5210 i guess
> we should leave it there. We need to test this a lot on various
> archs/cards before applying it.

There are two cases where we can use the PCI_CACHE_LINE_SIZE:

1) Hardware has been designed to use it on some block to align some data somehow
2) Software uses it to align skb->data for performance/hw purposes

I believe the second case can be handled by using L1_CACHE_BYTES
instead and I'd at least like to change our common skb allocator to
use that.

The first case is where it seems there may be some skepticism as to
whether or not hw really did not rely on it and I agree its safer to
keep the programming of the  PCI_CACHE_LINE_SIZE in case it has a
bogus value.

Does this seem reasonable?

  Luis

  reply	other threads:[~2009-11-04 22:45 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-04 20:04 pci_set_mwi() and ath5k Luis R. Rodriguez
2009-11-04 20:12 ` Nick Kossifidis
2009-11-04 21:30   ` Luis R. Rodriguez
2009-11-04 21:36     ` Luis R. Rodriguez
2009-11-04 21:52       ` Luis R. Rodriguez
2009-11-04 21:52         ` Luis R. Rodriguez
2009-11-04 22:00           ` Matthew Wilcox
2009-11-04 22:04             ` Luis R. Rodriguez
2009-11-04 22:14               ` Luis R. Rodriguez
2009-11-04 22:28                 ` Luis R. Rodriguez
2009-11-04 22:29                 ` Matthew Wilcox
2009-11-04 22:39                   ` Luis R. Rodriguez
2009-11-04 22:31                 ` Nick Kossifidis
2009-11-04 22:45                   ` Luis R. Rodriguez [this message]
2009-11-04 22:47                     ` Luis R. Rodriguez
2009-11-04 23:14                       ` Luis R. Rodriguez
2009-11-05  0:16                     ` Nick Kossifidis
2009-11-05  2:55                 ` Bob Copeland

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=43e72e890911041445s4e69aa46nda01d423c1bd8f7d@mail.gmail.com \
    --to=mcgrof@gmail.com \
    --cc=ath5k-devel@lists.ath5k.org \
    --cc=kyle@mcmartin.ca \
    --cc=linux-wireless@vger.kernel.org \
    --cc=matthew@wil.cx \
    --cc=mcgrof@bombadil.infradead.org \
    --cc=mickflemm@gmail.com \
    --cc=shemminger@vyatta.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