Enabling 64 bit data type for dma_addr_t on non PPC64 architecture

Enabling 64 bit data type for dma_addr_t on non PPC64 architecture

[Tushar Tyagi]

Hello,
I'm working a new DMA hardware for PPC processors.
The processor is a 32 bit architecture having 40 bit physical address
space.=20
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.
=20
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.
=20
Currently the dma_map_single function has 2 versions based upon
CONFIG_PPC64 defined or not.
=20
Is it possible to reuse the CONFIG_PPC64 based code only pertaining to
DMA by doing the following:
=20
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.
=20
With the above modification, the function dma_map_single starts
returning 64 bit data type instead of 32.
=20
Do you have any comments or suggestions ?
=20
-thanks
TT

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

[Benjamin Herrenschmidt]

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.

Re: 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

Enabling 64 bit data type for dma_addr_t on non PPC64 architecture

[Tushar Tyagi]

Hello,
I'm working a new DMA hardware for PPC processors.
The processor is a 32 bit architecture having 40 bit physical address
space.=20
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.
=20
We want to use the Linux generic DMA layer to offload DMA operations to
the hw and the Linux code path goes through function=20
dma_async_memcpy_buf_to_buf and then dma_map_single.
=20
Currently the dma_map_single function has 2 versions based upon
CONFIG_PPC64 defined or not.
=20
Is it possible to reuse the CONFIG_PPC64 based code only pertaining to
DMA by doing the following:
=20
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.
=20
With the above modification, the function dma_map_single starts
returning 64 bit data type instead of 32.
=20
Do you have any comments or suggestions ?
=20
-thanks
TT