David S. Miller wrote:
> From: David Brownell <david-b@pacbell.net>
>
> Should the dma mapping APIs try to detect the "DMA buffer starts in
> middle of non-coherent cacheline" case, and fail?
>
> This brings back another issue, returning failure from pci_map_*()
> and friends which currently cannot happen.
An issue that'll get fixed, yes? :)
I'd suspect ((dma_addr_t)0) would be a reasonable error return.
At least some hardware treats such values like software would
treat null pointers. No call syntax change necessary, which
might be good or bad depending on how you feel tomorrow.
> Remember please that specifically the DMA mapping APIs encourage use
> of consistent memory for small data objects. ...
> ... The non-consistent end of the APIs is
> meant for long contiguous buffers, not small chunks.
And in between, a nice huge grey area to play with and argue about!
> This is one of the reasons I want to fix this by making people use
> either consistent memory or PCI pools (which is consistent memory
> too).
For that model, I would prefer tools more like a kmalloc than the
pci_pool, which is most like a kmem_cache_t. The particular objects
in question are a bit small to use page-or-bigger allocators, too.
The problem for APIs like USB is that they haven't yet exposed DMA
addresses. Doing that, giving folk a choice from the "non-consistent
end of the APIs", would be a big change.
Oh no -- I just had an evil thought. Now that we have the device model
code partially in place, shouldn't we have DMA memory calls talk in
terms of "struct device" not "struct pci_device"? That'd be the way
to have _one_ API for dma mapping (and consistent memory allocation),
working for PCI, USB, and any other bus framework that comes along.
Nah ... forget I said that. Too logical, it could never happen! ;)
- Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Jun 15 2002 - 22:00:24 EST