consistent_dma_mask is a ghost?
A message that is not in the archive (sent off-list or not yet received): [email protected]
Quoted 5 lines
This means that only _two_ platforms, ia64 and
x86_64, have means to use that information, and other platforms useset_dma_mask()anddev->dma_maskfor consistent (coherent) allocations ignoringconsistent_dma_maskat all (and possibly allocating memory from invalid region, if the masks are not equal).
Platforms which worked correctly before continue to work correctly thereafter. IMHO, the whole thing is a kludge, designed to support AIC7xxx on SGI SN-2, and that's about all it does. There's a device which uses fewer DMA bits when it accesses its mailbox than when it accesses data. Since the mailbox is allocated in consistent memory, this can be used as a clue to restrict the allocation. This is a fragile, opaque construct and it's conceptually wrong (what if the driver accessed device mailboxes through streaming mappings?), but it works for its purpose. Just don't use it in your drivers and you'll be fine.
-- Pete
Quoted 5 lines · Pete Zaitcev
Platforms which worked correctly before continue to work correctly thereafter. IMHO, the whole thing is a kludge, designed to support AIC7xxx on SGI SN-2, and that's about all it does. There's a device which uses fewer DMA bits when it accesses its mailbox than when it accesses data.
Same is true for megaraid, aacraid and several other cards, but they just keep changing the pci mask at runtime. Thats in some ways even uglier but works for now
Quoted 4 lines · Pete Zaitcev
Platforms which worked correctly before continue to work correctly thereafter. IMHO, the whole thing is a kludge, designed to support AIC7xxx on SGI SN-2, and that's about all it does.
I'm a little confused. I assume the driver is not in the official tree and this SN-2 uses either Itanium or Opteron CPU.
Quoted 8 lines
There's a device which uses fewer DMA bits
when it accesses its mailbox than when it accesses data. Since the mailbox is allocated in consistent memory, this can be used as a clue to restrict the allocation. This is a fragile, opaque construct and it's conceptually wrong (what if the driver accessed device mailboxes through streaming mappings?), but it works for its purpose. Just don't use it in your drivers and you'll be fine.
Right, but at least the documentation needs a fix. I also have a device which needs different masks for streaming and consistent allocations (4 GB for DMA streaming but only 256 MB for memory shared directly between main CPU and on-board one) and I was hoping that setting the consistent dma mask to 256MB (-1) would actually have some meaning (while it's NOP on most platforms).
The question is: would it be better to only fix the docs to reflect reality, or let the kludge die and fix AIC7xxx driver instead? I understand it could be trivially done in the driver, i.e. by setting dma_mask to correct value just before the consistent allocation is requested. It should have little impact (if any) on performance, even if the driver needs it for normal operation rather than for init only.
Or, should we do it the other way around? Instead of fixing docs, we can fix the code to actually support setting the consistent dma mask reliably (at least the easy part).
Signature · 2 lines
Krzysztof Halasa Network Administrator