Hi, The "right" way for the target CPU to interact with host CPU memory (and vice versa, for mostly what it's worth) is to have the copy engine copy (ie, "DMA") the pieces between them. This may be for diagnostic purposes, but it's not supposed to be used like this for doing wifi data exchange, right? :-P
Now, there /may/ be some alignment hilarity in various bits of code and/or hardware. Eg, Merlin (AR9280) requires its descriptors to be within a 4k block - the code to iterate through the descriptor physical address space didn't do a "val = val + offset", it did something in verilog like "val = (val & 0xffffc000) | (offset & 0x3fff)". This meant if you allocated a descriptor that started just before the end of a 4k physmem aligned block, you'd end up with exciting results. I don't know if there are any situations like this in the ath10k hardware, but I'm sure there will be some gotchas somewhere. In any case, if ath10k is consuming too much bounce buffers, the calls to allocate memory aren't working right and should be restricted to 32 bit addresses. Whether that's by using the DMA memory API (before it's mapped) or passing in GFP_DMA32 is a fun debate. (My test hardware arrived, so I'll test this all out today on Peregrine-v2 and see if the driver works.) -adrian -adrian _______________________________________________ ath10k mailing list [email protected] http://lists.infradead.org/mailman/listinfo/ath10k
