On Sat, 02 Oct 2010 13:20:54 +1000
Benjamin Herrenschmidt <b...@kernel.crashing.org> wrote:
> On Fri, 2010-10-01 at 21:31 -0400, Josh Boyer wrote:
> > > +config ARCH_DMA_ADDR_T_64BIT
> > > + def_bool ARCH_PHYS_ADDR_T_64BIT
> > > +
> >
> > I seemed to have missed what this is about entirely. Is there some
> > place I can look that describes what that is supposed to do? The PPC
This patchset unifies dma_addr_t typedef.
> > 4xx boards set PHYS_ADDR_T_64BIT because the MMU uses 36 bit
> > addressing, but the CPU is only 32 bits. I want to make sure this DMA
> > thing isn't going to cause problems.
this patchset changes nothing. Please see below.
> Yes, we need to test a bit. Our dma_addr_t has remained 32-bit so far
> because despite the fact that we've had routinely to deal with >32-bit
> physical addresses for MMIO, physical memory support has been
> constrained afaik to 32-bit.
Really?
The current dma_addr_t is:
#if defined(__powerpc64__) || defined(CONFIG_PHYS_64BIT)
typedef u64 dma_addr_t;
#else
typedef u32 dma_addr_t;
#endif
typedef u64 dma64_addr_t;
I think that this patch doesn't change anything. Or I miss something?
@@ -22,6 +22,9 @@ config WORD_SIZE
config ARCH_PHYS_ADDR_T_64BIT
def_bool PPC64 || PHYS_64BIT
+config ARCH_DMA_ADDR_T_64BIT
+ def_bool ARCH_PHYS_ADDR_T_64BIT
+
config MMU
bool
default y
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
