Search Linux Wireless

Re: pci_set_mwi() and ath5k

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Nov 4, 2009 at 2:47 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote:
> On Wed, Nov 4, 2009 at 2:45 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxx> wrote:
>> On Wed, Nov 4, 2009 at 2:31 PM, Nick Kossifidis <mickflemm@xxxxxxxxx> wrote:
>>> 2009/11/5 Luis R. Rodriguez <mcgrof@xxxxxxxxxxxxxxxxxxxxxx>:
>>>> 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@xxxxxx> 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?
>
> I guess we can keep the second case allocator which relies on
> PCI_CACHE_LINE_SIZE, but if so then USB will just define its own csz
> statically always to L1_CACHE_BYTES which is fine too -- I was just
> hoping we could remove the PCI_CACHE_LINE_SIZE programming completely
> too and use a simple L1_CACHE_BYTES aligned allocator.

OK I'll leave all this crap and just annotate why its there. Right now
its just voodoo.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Bluetooth]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Device Mapper]
  Powered by Linux