On Wed, Nov 4, 2009 at 2:45 PM, Luis R. Rodriguez <mcg...@gmail.com> wrote: > On Wed, Nov 4, 2009 at 2:31 PM, Nick Kossifidis <mickfl...@gmail.com> wrote: >> 2009/11/5 Luis R. Rodriguez <mcg...@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 <matt...@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?
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. Luis _______________________________________________ ath5k-devel mailing list ath5k-devel@lists.ath5k.org https://lists.ath5k.org/mailman/listinfo/ath5k-devel
