From patchwork Thu Nov 27 00:59:49 2008 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yuri Tikhonov X-Patchwork-Id: 11077 X-Patchwork-Delegate: jwboyer@gmail.com Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from ozlabs.org (localhost [127.0.0.1]) by ozlabs.org (Postfix) with ESMTP id 5D3D4DDE1F for ; Thu, 27 Nov 2008 12:00:29 +1100 (EST) X-Original-To: linuxppc-dev@ozlabs.org Delivered-To: linuxppc-dev@ozlabs.org Received: from ocean.emcraft.com (ocean.emcraft.com [213.221.7.182]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by ozlabs.org (Postfix) with ESMTPS id A81BEDDDDF for ; Thu, 27 Nov 2008 11:59:53 +1100 (EST) Received: from localhost ([127.0.0.1]) by ocean.emcraft.com with esmtp (Exim 4.43) id 1L5VDH-0003a1-1P; Thu, 27 Nov 2008 03:58:35 +0300 Date: Thu, 27 Nov 2008 03:59:49 +0300 From: Yuri Tikhonov Organization: EmCraft X-Priority: 3 (Normal) Message-ID: <8310162146.20081127035949@emcraft.com> To: Benjamin Herrenschmidt Subject: Re[6]: [PATCH] katmai.dts: extend DMA ranges; add dma/sysace nodes In-Reply-To: <1227746559.7356.1.camel@pasglop> References: <200811131149.14715.yur@emcraft.com> <1226568352.7178.44.camel@pasglop> <1102187680.20081114074513@emcraft.com> <1226641289.7178.117.camel@pasglop> <1767195957.20081127032002@emcraft.com> <1351427808.20081127032633@emcraft.com> <1227746559.7356.1.camel@pasglop> MIME-Version: 1.0 X-Spam-Score: -1.6 (-) X-Spam-Report: Spam detection software, running on the system "pacific.emcraft.com", has identified this incoming email as possible spam. The original message has been attached to this so you can view it (if it isn't spam) or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: 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: [...] Content analysis details: (-1.6 points, 2.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.8 ALL_TRUSTED Passed through trusted hosts only via SMTP -2.6 BAYES_00 BODY: Bayesian spam probability is 0 to 1% [score: 0.0000] 2.8 SUBJ_RE_NUM Subject is faking 'The Bat!' responses Cc: sathya.prakash@lsi.com, Wolfgang Denk , Detlev Zundel , linuxppc-dev@ozlabs.org, Ilya Yanok , Eric.Moore@lsi.com X-BeenThere: linuxppc-dev@ozlabs.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@ozlabs.org Errors-To: linuxppc-dev-bounces+patchwork-incoming=ozlabs.org@ozlabs.org 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 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; }