Re: Enabling 64 bit data type for dma_addr_t on non PPC64 architecture

[Benjamin Herrenschmidt <benh@kernel.crashing.org>]

On Fri, 2008-04-25 at 19:52 -0700, Tushar Tyagi wrote:
> Hello,
> I'm working a new DMA hardware for PPC processors.
> The processor is a 32 bit architecture having 40 bit physical address
> space. 
> So we need the 32 bit processor code base but we want the type
> dma_addr_t to represent 64 bit data, without enabling the CONFIG_PPC64
> flag.

That shouldn't be a big issue, we already support 64 bits resources,
extending dma_addr_t shouldn't too hard.

> We want to use the Linux generic DMA layer to offload DMA operations to
> the hw and the Linux code path goes through function
> dma_async_memcpy_buf_to_buf and then dma_map_single.
>  
> Currently the dma_map_single function has 2 versions based upon
> CONFIG_PPC64 defined or not.
>  
> Is it possible to reuse the CONFIG_PPC64 based code only pertaining to
> DMA by doing the following:

It's possible, it might be a good idea even as it would allow to have
different implementations for different busses, which is in fact needed
for some things like 4xx if we start changing the mapping between
different PCI bridges vs. SoCs. In fact, I think there's been some
patches from Becky Bruce posted in februrary for doing just that, which
I totally forgot to review...
 
> Add a new flag called CONFIG_DMA64 along with CONFIG_PPC64 and
> __powerpc64__ flags, enabling our code to use the generic DMA layer with
> 64 bit data type for dma_addr_t.
>  
> With the above modification, the function dma_map_single starts
> returning 64 bit data type instead of 32.
>  
> Do you have any comments or suggestions ?

I'd suggest working with Becky on her initial patch and using that as
the basis for your stuff. I'll try to give it a good review asap.

Cheers,
Ben.