lkml.org 
[lkml]   [2005]   [Oct]   [20]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
SubjectRe: [patch 2.6.14-rc4] b44: alternate allocation option for DMA descriptors
FromBenjamin Herrenschmidt <>
DateThu, 20 Oct 2005 17:17:05 +1000
Digg This
On Tue, 2005-10-18 at 21:30 -0400, John W. Linville wrote:
This is a (final?) hack to support the odd DMA allocation requirements of the b44 hardware. The b44 hardware has a 30-bit DMA mask. On x86, anything less than a 32-bit DMA mask forces allocations into the 16MB GFP_DMA range. The memory there is somewhat limited, often resulting in an inability to initialize the b44 driver.

This hack uses streaming DMA allocation APIs in order to provide an alternative in case the GFP_DMA allocation fails. It is somewhat ugly, but not much worse than the similar existing hacks to support SKB allocations in the same driver. FWIW, I have received positive feedback on this from several Fedora users.

I'm not sure what you are trying to do here ... If pci_alloc_* failed, you do kmalloc(...,GFP_KERNEL) which can give you memory above your DMA mask. Then, you use dma_map_* but that won't help much more neither. Unless you have an iommu (or swiotlb) _and_ that implements arbitrary DMA masks support (which it typically doesn't it's often 32 bits vs. 64 bits) it won't help, you'll get into your error case.
So basically, what you are doing is: if allocation fails, you try to get memory using GFP_KERNEL. If it happens to be in the low 2Gb of memory, use it, if not, drop it.

Did I get that right ?

Note that the Broadcom wireless (which is currently being reverse engineered) seem to suffer from the same stupid DMA engine...
Ben.

\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2005-10-20 07:23    [W:0.125 / U:8.210 seconds]
©2003-2005 Jasper Spaans