Enabling 64 bit data type for dma_addr_t on non PPC64 architecture

[Becky Bruce]

On Apr 25, 2008, at 10:38 PM, Benjamin Herrenschmidt wrote:
>
> 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.

Actually, Ben, wait on that review - I've made significant changes to  
those patches, including some bugfixes for HIGHMEM and will be posting  
the revised version soon (hopefully later today or tomorrow).   I'm  
behind a bit on the top-of-tree so I'll need to bring them up to date  
and do some testing before I post.  I think the newer version is  
cleaner than the last but can still probably use some improvement.

I've also got a patch that enables larger physical addressing in  
general - it changes the page table/mmu handling to allow for larger  
physical addresses on MPC8641; BookE parts will need a slightly  
different set of changes (some of which are already in place, but I've  
not done any work/testing on BookE at this point).  I'll try to get a  
version of that out this week as well - it needs some cleanup and  
testing on the latest tree.

Cheers,
Becky