From patchwork Tue Jan 12 07:40:48 2010 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: David Miller X-Patchwork-Id: 42686 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by ozlabs.org (Postfix) with ESMTP id BCE34B7C72 for ; Tue, 12 Jan 2010 18:40:42 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750920Ab0ALHkl (ORCPT ); Tue, 12 Jan 2010 02:40:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750965Ab0ALHkl (ORCPT ); Tue, 12 Jan 2010 02:40:41 -0500 Received: from 74-93-104-97-Washington.hfc.comcastbusiness.net ([74.93.104.97]:39329 "EHLO sunset.davemloft.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750920Ab0ALHkk (ORCPT ); Tue, 12 Jan 2010 02:40:40 -0500 Received: from localhost (localhost [127.0.0.1]) by sunset.davemloft.net (Postfix) with ESMTP id 4CC5C24C141; Mon, 11 Jan 2010 23:40:49 -0800 (PST) Date: Mon, 11 Jan 2010 23:40:48 -0800 (PST) Message-Id: <20100111.234048.249682808.davem@davemloft.net> To: kristoffer@gaisler.com Cc: sparclinux@vger.kernel.org Subject: Re: [PATCH 2/2] Added leon3_dma_ops and LEON specific mmu_inval_dma_area From: David Miller In-Reply-To: <4B0A80A4.4020704@gaisler.com> References: <4B03B435.9010607@gaisler.com> <20091118.013246.24143194.davem@davemloft.net> <4B0A80A4.4020704@gaisler.com> X-Mailer: Mew version 6.3 on Emacs 23.1 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org From: Kristoffer Glembo Date: Mon, 23 Nov 2009 13:31:32 +0100 > We did yes. You said that mem_map is not offset at phys_base and then > of > course we don't need to add it in page_to_phys. Is mem_map not offset > because typically sp_banks[].base_addr = 0? In our case we pass in one > sp_banks entry which has base_addr = 0x40000000. Looking at this code, I can't see how virt_to_page() works right now at all :-) mem_map[] is offset by pfn_base This is why __va() and __pa() account for it. Can you see if your machine boots with the patch at the end of this email applied? Others can feel free to test this too :-) Really, if pfn_base/phys_base are non-zero, it's quite amazing how a sparc32 machine could sucessfully boot with the code as-is. Looking more deeply, I guess it could work if you use CONFIG_SLUB. Or, you use CONFIG_SLAB and SLABs are never destroyed and SLAB growing never fails (kmem_freepages() uses virt_to_page()). And I'm guessing that's why using virt_to_page() in the DMA mapping implementation failed for you Kristoffer, it would be the only common path it would be used on sparc32. Anyways, testing of this change by anyone with sparc32 boxes would be much appreciated. Thanks! --- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/arch/sparc/include/asm/page_32.h b/arch/sparc/include/asm/page_32.h index f72080b..156707b 100644 --- a/arch/sparc/include/asm/page_32.h +++ b/arch/sparc/include/asm/page_32.h @@ -143,7 +143,7 @@ extern unsigned long pfn_base; #define phys_to_virt __va #define ARCH_PFN_OFFSET (pfn_base) -#define virt_to_page(kaddr) (mem_map + ((((unsigned long)(kaddr)-PAGE_OFFSET)>>PAGE_SHIFT))) +#define virt_to_page(kaddr) pfn_to_page(__pa(kaddr) >> PAGE_SHIFT) #define pfn_valid(pfn) (((pfn) >= (pfn_base)) && (((pfn)-(pfn_base)) < max_mapnr)) #define virt_addr_valid(kaddr) ((((unsigned long)(kaddr)-PAGE_OFFSET)>>PAGE_SHIFT) < max_mapnr)