From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9549DC433FF for ; Wed, 31 Jul 2019 15:48:04 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 77702206B8 for ; Wed, 31 Jul 2019 15:48:04 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1730231AbfGaPsD (ORCPT ); Wed, 31 Jul 2019 11:48:03 -0400 Received: from mx2.suse.de ([195.135.220.15]:49972 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727349AbfGaPsC (ORCPT ); Wed, 31 Jul 2019 11:48:02 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D13F2AF9A; Wed, 31 Jul 2019 15:48:00 +0000 (UTC) From: Nicolas Saenz Julienne To: catalin.marinas@arm.com, hch@lst.de, wahrenst@gmx.net, marc.zyngier@arm.com, Robin Murphy , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org Cc: phill@raspberryi.org, f.fainelli@gmail.com, will@kernel.org, linux-kernel@vger.kernel.org, robh+dt@kernel.org, eric@anholt.net, mbrugger@suse.com, nsaenzjulienne@suse.de, akpm@linux-foundation.org, frowand.list@gmail.com, m.szyprowski@samsung.com, linux-rpi-kernel@lists.infradead.org, linuxppc-dev@lists.ozlabs.org, linux-s390@vger.kernel.org Subject: [PATCH 0/8] Raspberry Pi 4 DMA addressing support Date: Wed, 31 Jul 2019 17:47:43 +0200 Message-Id: <20190731154752.16557-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi all, this series attempts to address some issues we found while bringing up the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow up of this discussion: https://lkml.org/lkml/2019/7/17/476 The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can only address the first GB: their DMA address range is 0xc0000000-0xfc000000 which is aliased to the first GB of physical memory 0x00000000-0x3c000000. Note that only some peripherals have these limitations: the ARM cores, PCIe, V3D, GENET, and 40-bit DMA channels have a wider view of the address space. Part of this is solved in arm32 by setting up the machine specific '.dma_zone_size = SZ_1G', which takes care of the allocating the coherent memory area at the right spot. Yet no buffer bouncing (needed for dma streaming) is available at the moment, but that's a story for another series. Unfortunately there is no such thing as '.dma_zone_size' in arm64 also only ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 code as if all peripherals where be able to address the first 4GB of memory. In the light of this, the series implements the following changes: - Add code that parses the device-tree in oder to find the SoC's common DMA area. - Create a ZONE_DMA whenever that area is needed and add the rest of the lower 4 GB of memory to ZONE_DMA32*. - Create the CMA area in a place suitable for all peripherals. - Inform dma-direct of the new runtime calculated min_mask*. That's all. Regards, Nicolas * These solutions where already discussed on the previous RFC (see link above). --- Nicolas Saenz Julienne (8): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size of/fdt: add function to get the SoC wide DMA addressable memory size arm64: re-introduce max_zone_dma_phys() arm64: use ZONE_DMA on DMA addressing limited devices dma-direct: turn ARCH_ZONE_DMA_BITS into a variable arm64: update arch_zone_dma_bits to fine tune dma-direct min mask mm: comment arm64's usage of 'enum zone_type' arch/arm64/Kconfig | 4 ++ arch/arm64/mm/init.c | 78 ++++++++++++++++++++++++++------- arch/powerpc/include/asm/page.h | 9 ---- arch/powerpc/mm/mem.c | 14 +++++- arch/s390/include/asm/page.h | 2 - arch/s390/mm/init.c | 1 + drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++ include/linux/dma-direct.h | 2 + include/linux/mmzone.h | 21 ++++----- include/linux/of_fdt.h | 2 + kernel/dma/direct.c | 8 ++-- 11 files changed, 168 insertions(+), 45 deletions(-) -- 2.22.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 46DE6C433FF for ; Wed, 31 Jul 2019 22:01:23 +0000 (UTC) Received: from lists.ozlabs.org (lists.ozlabs.org [203.11.71.2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id C69C220659 for ; Wed, 31 Jul 2019 22:01:22 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org C69C220659 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Received: from lists.ozlabs.org (lists.ozlabs.org [IPv6:2401:3900:2:1::3]) by lists.ozlabs.org (Postfix) with ESMTP id 45zS733k6szDqkd for ; Thu, 1 Aug 2019 08:01:19 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=suse.de (client-ip=195.135.220.15; helo=mx1.suse.de; envelope-from=nsaenzjulienne@suse.de; receiver=) Authentication-Results: lists.ozlabs.org; dmarc=none (p=none dis=none) header.from=suse.de Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 45zJBZ4wLmzDqJM for ; Thu, 1 Aug 2019 02:03:49 +1000 (AEST) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D13F2AF9A; Wed, 31 Jul 2019 15:48:00 +0000 (UTC) From: Nicolas Saenz Julienne To: catalin.marinas@arm.com, hch@lst.de, wahrenst@gmx.net, marc.zyngier@arm.com, Robin Murphy , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org Subject: [PATCH 0/8] Raspberry Pi 4 DMA addressing support Date: Wed, 31 Jul 2019 17:47:43 +0200 Message-Id: <20190731154752.16557-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Thu, 01 Aug 2019 07:55:07 +1000 X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: phill@raspberryi.org, linux-s390@vger.kernel.org, f.fainelli@gmail.com, mbrugger@suse.com, frowand.list@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, eric@anholt.net, robh+dt@kernel.org, linux-rpi-kernel@lists.infradead.org, akpm@linux-foundation.org, will@kernel.org, nsaenzjulienne@suse.de, m.szyprowski@samsung.com Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" Hi all, this series attempts to address some issues we found while bringing up the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow up of this discussion: https://lkml.org/lkml/2019/7/17/476 The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can only address the first GB: their DMA address range is 0xc0000000-0xfc000000 which is aliased to the first GB of physical memory 0x00000000-0x3c000000. Note that only some peripherals have these limitations: the ARM cores, PCIe, V3D, GENET, and 40-bit DMA channels have a wider view of the address space. Part of this is solved in arm32 by setting up the machine specific '.dma_zone_size = SZ_1G', which takes care of the allocating the coherent memory area at the right spot. Yet no buffer bouncing (needed for dma streaming) is available at the moment, but that's a story for another series. Unfortunately there is no such thing as '.dma_zone_size' in arm64 also only ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 code as if all peripherals where be able to address the first 4GB of memory. In the light of this, the series implements the following changes: - Add code that parses the device-tree in oder to find the SoC's common DMA area. - Create a ZONE_DMA whenever that area is needed and add the rest of the lower 4 GB of memory to ZONE_DMA32*. - Create the CMA area in a place suitable for all peripherals. - Inform dma-direct of the new runtime calculated min_mask*. That's all. Regards, Nicolas * These solutions where already discussed on the previous RFC (see link above). --- Nicolas Saenz Julienne (8): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size of/fdt: add function to get the SoC wide DMA addressable memory size arm64: re-introduce max_zone_dma_phys() arm64: use ZONE_DMA on DMA addressing limited devices dma-direct: turn ARCH_ZONE_DMA_BITS into a variable arm64: update arch_zone_dma_bits to fine tune dma-direct min mask mm: comment arm64's usage of 'enum zone_type' arch/arm64/Kconfig | 4 ++ arch/arm64/mm/init.c | 78 ++++++++++++++++++++++++++------- arch/powerpc/include/asm/page.h | 9 ---- arch/powerpc/mm/mem.c | 14 +++++- arch/s390/include/asm/page.h | 2 - arch/s390/mm/init.c | 1 + drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++ include/linux/dma-direct.h | 2 + include/linux/mmzone.h | 21 ++++----- include/linux/of_fdt.h | 2 + kernel/dma/direct.c | 8 ++-- 11 files changed, 168 insertions(+), 45 deletions(-) -- 2.22.0 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 1E97BC32751 for ; Wed, 31 Jul 2019 15:59:53 +0000 (UTC) Received: from mail.linuxfoundation.org (mail.linuxfoundation.org [140.211.169.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id F307E206A2 for ; Wed, 31 Jul 2019 15:59:52 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org F307E206A2 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=iommu-bounces@lists.linux-foundation.org Received: from mail.linux-foundation.org (localhost [127.0.0.1]) by mail.linuxfoundation.org (Postfix) with ESMTP id 812583EAF; Wed, 31 Jul 2019 15:59:48 +0000 (UTC) Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 7A67D3AA5 for ; Wed, 31 Jul 2019 15:48:03 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DB69AE7 for ; Wed, 31 Jul 2019 15:48:02 +0000 (UTC) X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D13F2AF9A; Wed, 31 Jul 2019 15:48:00 +0000 (UTC) From: Nicolas Saenz Julienne To: catalin.marinas@arm.com, hch@lst.de, wahrenst@gmx.net, marc.zyngier@arm.com, Robin Murphy , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org Subject: [PATCH 0/8] Raspberry Pi 4 DMA addressing support Date: Wed, 31 Jul 2019 17:47:43 +0200 Message-Id: <20190731154752.16557-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 Cc: phill@raspberryi.org, linux-s390@vger.kernel.org, f.fainelli@gmail.com, mbrugger@suse.com, frowand.list@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, eric@anholt.net, robh+dt@kernel.org, linux-rpi-kernel@lists.infradead.org, akpm@linux-foundation.org, will@kernel.org, nsaenzjulienne@suse.de X-BeenThere: iommu@lists.linux-foundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Development issues for Linux IOMMU support List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: iommu-bounces@lists.linux-foundation.org Errors-To: iommu-bounces@lists.linux-foundation.org Hi all, this series attempts to address some issues we found while bringing up the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow up of this discussion: https://lkml.org/lkml/2019/7/17/476 The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can only address the first GB: their DMA address range is 0xc0000000-0xfc000000 which is aliased to the first GB of physical memory 0x00000000-0x3c000000. Note that only some peripherals have these limitations: the ARM cores, PCIe, V3D, GENET, and 40-bit DMA channels have a wider view of the address space. Part of this is solved in arm32 by setting up the machine specific '.dma_zone_size = SZ_1G', which takes care of the allocating the coherent memory area at the right spot. Yet no buffer bouncing (needed for dma streaming) is available at the moment, but that's a story for another series. Unfortunately there is no such thing as '.dma_zone_size' in arm64 also only ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 code as if all peripherals where be able to address the first 4GB of memory. In the light of this, the series implements the following changes: - Add code that parses the device-tree in oder to find the SoC's common DMA area. - Create a ZONE_DMA whenever that area is needed and add the rest of the lower 4 GB of memory to ZONE_DMA32*. - Create the CMA area in a place suitable for all peripherals. - Inform dma-direct of the new runtime calculated min_mask*. That's all. Regards, Nicolas * These solutions where already discussed on the previous RFC (see link above). --- Nicolas Saenz Julienne (8): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size of/fdt: add function to get the SoC wide DMA addressable memory size arm64: re-introduce max_zone_dma_phys() arm64: use ZONE_DMA on DMA addressing limited devices dma-direct: turn ARCH_ZONE_DMA_BITS into a variable arm64: update arch_zone_dma_bits to fine tune dma-direct min mask mm: comment arm64's usage of 'enum zone_type' arch/arm64/Kconfig | 4 ++ arch/arm64/mm/init.c | 78 ++++++++++++++++++++++++++------- arch/powerpc/include/asm/page.h | 9 ---- arch/powerpc/mm/mem.c | 14 +++++- arch/s390/include/asm/page.h | 2 - arch/s390/mm/init.c | 1 + drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++ include/linux/dma-direct.h | 2 + include/linux/mmzone.h | 21 ++++----- include/linux/of_fdt.h | 2 + kernel/dma/direct.c | 8 ++-- 11 files changed, 168 insertions(+), 45 deletions(-) -- 2.22.0 _______________________________________________ iommu mailing list iommu@lists.linux-foundation.org https://lists.linuxfoundation.org/mailman/listinfo/iommu From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.8 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4913DC32751 for ; Wed, 31 Jul 2019 15:51:14 +0000 (UTC) Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 1CF2C206B8 for ; Wed, 31 Jul 2019 15:51:14 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="uahN/m/y" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 1CF2C206B8 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:MIME-Version:Message-Id:Date:Subject:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=EVC1Z3HCFoT05s/wfyQypwWePeHDox5hAGV9H7cCLGM=; b=uahN/m/yFoe4fm 1rJ1zmY/VyoYXhJWr4BPwZbxQaKZh+ySgt/rxbCiXq0hZF/ujAx7eLEDH7ld+/140AkbKeZERFf/n KRar2Cvl+e++L7KmsWh1T3jjSaDaHig198C83Dd2iYHHJXL6lH8n7OU2+HFZ4iXk2l1QXBpDaaQTM sczCinpeFX0BUPV/DaLyFZstghmwDWI8mEYmf5U7PJ0MbNX15kwQUMfKE9n8zqhJv8y3bt2HvUyW8 ybq2ZESdhPcUmO6SRqSFgjIxjBPSM8cdMAkVQ5lWhPNjQXBBnYQnREV22Wf4ye79oXUabBg5vERWC DWqF2dN+y2ha5dJkHkfQ==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92 #3 (Red Hat Linux)) id 1hsqsi-0004LF-UN; Wed, 31 Jul 2019 15:51:12 +0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by bombadil.infradead.org with esmtps (Exim 4.92 #3 (Red Hat Linux)) id 1hsqpg-0007Xt-JB; Wed, 31 Jul 2019 15:48:07 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id D13F2AF9A; Wed, 31 Jul 2019 15:48:00 +0000 (UTC) From: Nicolas Saenz Julienne To: catalin.marinas@arm.com, hch@lst.de, wahrenst@gmx.net, marc.zyngier@arm.com, Robin Murphy , linux-arm-kernel@lists.infradead.org, devicetree@vger.kernel.org, iommu@lists.linux-foundation.org, linux-mm@kvack.org Subject: [PATCH 0/8] Raspberry Pi 4 DMA addressing support Date: Wed, 31 Jul 2019 17:47:43 +0200 Message-Id: <20190731154752.16557-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.22.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190731_084804_797129_C6C07364 X-CRM114-Status: GOOD ( 14.26 ) X-BeenThere: linux-arm-kernel@lists.infradead.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: phill@raspberryi.org, linux-s390@vger.kernel.org, f.fainelli@gmail.com, mbrugger@suse.com, frowand.list@gmail.com, linuxppc-dev@lists.ozlabs.org, linux-kernel@vger.kernel.org, eric@anholt.net, robh+dt@kernel.org, linux-rpi-kernel@lists.infradead.org, akpm@linux-foundation.org, will@kernel.org, nsaenzjulienne@suse.de, m.szyprowski@samsung.com Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+infradead-linux-arm-kernel=archiver.kernel.org@lists.infradead.org Hi all, this series attempts to address some issues we found while bringing up the new Raspberry Pi 4 in arm64 and it's intended to serve as a follow up of this discussion: https://lkml.org/lkml/2019/7/17/476 The new Raspberry Pi 4 has up to 4GB of memory but most peripherals can only address the first GB: their DMA address range is 0xc0000000-0xfc000000 which is aliased to the first GB of physical memory 0x00000000-0x3c000000. Note that only some peripherals have these limitations: the ARM cores, PCIe, V3D, GENET, and 40-bit DMA channels have a wider view of the address space. Part of this is solved in arm32 by setting up the machine specific '.dma_zone_size = SZ_1G', which takes care of the allocating the coherent memory area at the right spot. Yet no buffer bouncing (needed for dma streaming) is available at the moment, but that's a story for another series. Unfortunately there is no such thing as '.dma_zone_size' in arm64 also only ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 code as if all peripherals where be able to address the first 4GB of memory. In the light of this, the series implements the following changes: - Add code that parses the device-tree in oder to find the SoC's common DMA area. - Create a ZONE_DMA whenever that area is needed and add the rest of the lower 4 GB of memory to ZONE_DMA32*. - Create the CMA area in a place suitable for all peripherals. - Inform dma-direct of the new runtime calculated min_mask*. That's all. Regards, Nicolas * These solutions where already discussed on the previous RFC (see link above). --- Nicolas Saenz Julienne (8): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size of/fdt: add function to get the SoC wide DMA addressable memory size arm64: re-introduce max_zone_dma_phys() arm64: use ZONE_DMA on DMA addressing limited devices dma-direct: turn ARCH_ZONE_DMA_BITS into a variable arm64: update arch_zone_dma_bits to fine tune dma-direct min mask mm: comment arm64's usage of 'enum zone_type' arch/arm64/Kconfig | 4 ++ arch/arm64/mm/init.c | 78 ++++++++++++++++++++++++++------- arch/powerpc/include/asm/page.h | 9 ---- arch/powerpc/mm/mem.c | 14 +++++- arch/s390/include/asm/page.h | 2 - arch/s390/mm/init.c | 1 + drivers/of/fdt.c | 72 ++++++++++++++++++++++++++++++ include/linux/dma-direct.h | 2 + include/linux/mmzone.h | 21 ++++----- include/linux/of_fdt.h | 2 + kernel/dma/direct.c | 8 ++-- 11 files changed, 168 insertions(+), 45 deletions(-) -- 2.22.0 _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel