Patchwork Re[6]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes

login
register
mail settings
Submitter Yuri Tikhonov
Date Nov. 27, 2008, 12:59 a.m.
Message ID <8310162146.20081127035949@emcraft.com>
Download mbox | patch
Permalink /patch/11077/
State Rejected
Delegated to: Josh Boyer
Headers show

Comments

Yuri Tikhonov - Nov. 27, 2008, 12:59 a.m.
On Thursday, November 27, 2008 you wrote:

>>  I've implemented (2) (the code is below), and it works. But, 
>> admittedly, this (working) looks strange to me because of the 
>> following:
>>  To be able to use 64-bit PCI mapping on PPC32 I had to replace the
>> 'unsigned long' type of pci_dram_offset with 'resource_size_t', which 
>> on ppc440spe is 'u64'. So, in dma_alloc_coherent() I put the 64-bit 
>> value into the 'dma_addr_t' handle. I use 2.6.27 kernel for testing, 
>> which has sizeof(dma_addr_t) == sizeof(u32). Thus, 
>> dma_alloc_coherent() cuts the upper 32 bits of PCI address, and returns 
>> only low 32-bit part of PCI address to its caller. And, regardless of 
>> this fact, the PCI device does operate somehow (this is the PCI-E LSI 
>> disk controller served by the drivers/message/fusion/mptbase.c + 
>> mptsas.c drivers).
>> 
>>  I've verified that ppc440spe PCI-E bridge's BARs (PECFGn_BAR0L,H) are 
>> configured with the new, 1TB, address value:

> Strange... when I look at pci4xx_parse_dma_ranges() I see it
> specifically avoiding PCI addresses above 4G ... That needs fixing.

 Right, it avoid. I guess you haven't read my e-mail to its end, 
because my work-around patch, which I referenced there, fixes this :)

> To implement that trick you definitely need to make dma_addr_t 64 bits.

 Sure. The problem here is that the LSI (the PCI device I want to DMA 
to/from 1TB PCI addresses) driver doesn't work with this (i.e. it's 
broken in, e.g., 2.6.28-rc6) on ppc440spe-based platform. It looks 
like there is no support for 32-bit CPUs with 64-bit physical 
addresses in the LSI driver. E.g. the following mix in the 
drivers/message/fusion/mptbase.h code points to the fact that the 
driver supposes 64-bit dma_addr_t on 64-bit CPUs only:

#ifdef CONFIG_64BIT
#define CAST_U32_TO_PTR(x)      ((void *)(u64)x)
#define CAST_PTR_TO_U32(x)      ((u32)(u64)x)
#else
#define CAST_U32_TO_PTR(x)      ((void *)x)
#define CAST_PTR_TO_U32(x)      ((u32)x)
#endif


#define mpt_addr_size() \
        ((sizeof(dma_addr_t) == sizeof(u64)) ? MPI_SGE_FLAGS_64_BIT_ADDRESSING : \
                MPI_SGE_FLAGS_32_BIT_ADDRESSING)



 Regards, Yuri

 --
 Yuri Tikhonov, Senior Software Engineer
 Emcraft Systems, www.emcraft.com
Benjamin Herrenschmidt - Nov. 27, 2008, 4:07 a.m.
> > Strange... when I look at pci4xx_parse_dma_ranges() I see it
> > specifically avoiding PCI addresses above 4G ... That needs fixing.
> 
>  Right, it avoid. I guess you haven't read my e-mail to its end, 
> because my work-around patch, which I referenced there, fixes this :)

Ooops, I though I did :-)

>  Sure. The problem here is that the LSI (the PCI device I want to DMA 
> to/from 1TB PCI addresses) driver doesn't work with this (i.e. it's 
> broken in, e.g., 2.6.28-rc6) on ppc440spe-based platform. It looks 
> like there is no support for 32-bit CPUs with 64-bit physical 
> addresses in the LSI driver. E.g. the following mix in the 
> drivers/message/fusion/mptbase.h code points to the fact that the 
> driver supposes 64-bit dma_addr_t on 64-bit CPUs only:
> 
> #ifdef CONFIG_64BIT
> #define CAST_U32_TO_PTR(x)      ((void *)(u64)x)
> #define CAST_PTR_TO_U32(x)      ((u32)(u64)x)
> #else
> #define CAST_U32_TO_PTR(x)      ((void *)x)
> #define CAST_PTR_TO_U32(x)      ((u32)x)
> #endif
> 
> 
> #define mpt_addr_size() \
>         ((sizeof(dma_addr_t) == sizeof(u64)) ? MPI_SGE_FLAGS_64_BIT_ADDRESSING : \
>                 MPI_SGE_FLAGS_32_BIT_ADDRESSING)
> 

So far I don't see anything in this that hints about that brokenness...
not that it's not there, but the above macros seem unrelated.

Cheers,
Ben.

>  Regards, Yuri
> 
>  --
>  Yuri Tikhonov, Senior Software Engineer
>  Emcraft Systems, www.emcraft.com

Patch

diff --git a/arch/powerpc/sysdev/ppc4xx_pci.c b/arch/powerpc/sysdev/ppc4xx_pci.c
index afbdd48..f748c5b 100644
--- a/arch/powerpc/sysdev/ppc4xx_pci.c
+++ b/arch/powerpc/sysdev/ppc4xx_pci.c
@@ -126,10 +126,8 @@  static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
                if ((pci_space & 0x03000000) != 0x02000000)
                        continue;

-               /* We currently only support memory at 0, and pci_addr
-                * within 32 bits space
-                */
-               if (cpu_addr != 0 || pci_addr > 0xffffffff) {
+               /* We currently only support memory at 0 */
+               if (cpu_addr != 0) {
                        printk(KERN_WARNING "%s: Ignored unsupported dma range"
                               " 0x%016llx...0x%016llx -> 0x%016llx\n",
                               hose->dn->full_name,
@@ -179,18 +177,12 @@  static int __init ppc4xx_parse_dma_ranges(struct pci_controller *hose,
                return -ENXIO;
        }

-       /* Check that we are fully contained within 32 bits space */
-       if (res->end > 0xffffffff) {
-               printk(KERN_ERR "%s: dma-ranges outside of 32 bits space\n",
-                      hose->dn->full_name);
-               return -ENXIO;
-       }
  out:
        dma_offset_set = 1;
        pci_dram_offset = res->start;

-       printk(KERN_INFO "4xx PCI DMA offset set to 0x%08lx\n",
-              pci_dram_offset);
+       printk(KERN_INFO "4xx PCI DMA offset set to 0x%016llx\n",
+              (unsigned long long)pci_dram_offset);
        return 0;
 }