On Friday 22 May 2009, FUJITA Tomonori wrote:
> I'm not sure. And only mips internally uses CONFIG_DMA_COHERENT.
>
> The reason why many architectures need architecture-specific
> alloc_coherent() is not about coherent or not.
>
> I like a new helper header file having only generic functions without
> any ifdef.
Ok, fair enough. Fixing dma_alloc_coherent to handle
coherent_dma_mask and debug_dma correctly would also
make it even bigger, and it was already doing more than
you'd want from a commonly used inline function.
It may be useful to put it into kernel/dma-coherent.c
under an #ifdef, but I'll leave this one alone for now.
I'll leave dma_alloc_coherent and dma_free_coherent
as extern declarations then, and leave out the
simple dma_coherent_dev() and dma_cache_sync() that
all architectures would need to override.
dma_get_cache_alignment() is still less generic than
the other functions, as this is still architecture
specific. Should I leave that out as well then?
One more idea I had was to rename all the functions in
this file from dma_* to dma_linear_*. This would mean
that all architectures using it would still need to
do something like #define dma_map_sg dma_linear_map_sg
for each function they want to use but can easily chose
to provide their own ones for those they need different.
It might also help architectures that work with dma_ops,
which could then define their own
struct dma_ops dma_ops_linear = {
.map_single = dma_linear_map_single,
.map_sg = dma_linear_map_sg,
...
};
Would you prefer me to do it this way, or just keep the
standard function names as in the current patch?
Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
