From patchwork Wed Sep 11 18:25:42 2019 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nicolas Saenz Julienne X-Patchwork-Id: 11141719 Return-Path: Received: from mail.kernel.org (pdx-korg-mail-1.web.codeaurora.org [172.30.200.123]) by pdx-korg-patchwork-2.web.codeaurora.org (Postfix) with ESMTP id 4683D14E5 for ; Wed, 11 Sep 2019 18:27:05 +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 232A52084D for ; Wed, 11 Sep 2019 18:27:05 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="DJL1wb6u" DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 232A52084D 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+patchwork-linux-arm=patchwork.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=zzz4NMbEnwvtHmqEkH9IHb0AOM6ORqVGtfS15E6hdBA=; b=DJL1wb6ukG3NnH Quc8u2Y1+S4PtH0dBlO2nw+887ITunjDe1NyZcMgK5jctKosoNbYNxoli3iOXwRMXtMtSLAB7UPs3 Qp5jOSZJpv1jyEtVGvkQwNL5603bWz170yYmdDZBFTT38kmPJXG/6NWjjcndPrirEBVFdNUrlU2hE LkzO5QnUrh7pKQKH5pDWYiHgsQ8V04IZqDkK/o6uQqk5epD5LNgMw77AhplvW6gZ4oVnvo0S1qjW5 NlA02ucUSaRBp87Y8lnn0nPSpDM2KN3GtYSq0c3pdIv4VgSGULSoVgRrP4aZ+KyZKw5Pn793sgfMb /6W4BjnzMrl4fQSi+lhg==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.92.2 #3 (Red Hat Linux)) id 1i87KU-0005XS-Bi; Wed, 11 Sep 2019 18:26:58 +0000 Received: from mx2.suse.de ([195.135.220.15] helo=mx1.suse.de) by bombadil.infradead.org with esmtps (Exim 4.92.2 #3 (Red Hat Linux)) id 1i87JT-0004bz-Ge; Wed, 11 Sep 2019 18:25:58 +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 62098AC28; Wed, 11 Sep 2019 18:25:51 +0000 (UTC) From: Nicolas Saenz Julienne To: catalin.marinas@arm.com, hch@lst.de, wahrenst@gmx.net, marc.zyngier@arm.com, robh+dt@kernel.org Subject: [PATCH v6 0/4] Raspberry Pi 4 DMA addressing support Date: Wed, 11 Sep 2019 20:25:42 +0200 Message-Id: <20190911182546.17094-1-nsaenzjulienne@suse.de> X-Mailer: git-send-email 2.23.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20190911_112555_857509_95DE5CAF X-CRM114-Status: GOOD ( 14.69 ) X-Spam-Score: -2.3 (--) X-Spam-Report: SpamAssassin version 3.4.2 on bombadil.infradead.org summary: Content analysis details: (-2.3 points) pts rule name description ---- ---------------------- -------------------------------------------------- -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at https://www.dnswl.org/, medium trust [195.135.220.15 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 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: linux-arm-kernel@lists.infradead.org, f.fainelli@gmail.com, robin.murphy@arm.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, mbrugger@suse.com, linux-rpi-kernel@lists.infradead.org, phill@raspberrypi.org, will@kernel.org, nsaenzjulienne@suse.de, m.szyprowski@samsung.com Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+patchwork-linux-arm=patchwork.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 these discussions: v5: https://lkml.org/lkml/2019/9/9/170 v4: https://lkml.org/lkml/2019/9/6/352 v3: https://lkml.org/lkml/2019/9/2/589 v2: https://lkml.org/lkml/2019/8/20/767 v1: https://lkml.org/lkml/2019/7/31/922 RFC: 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 PCIe, V3D, GENET, and 40-bit DMA channels have a wider view of the address space by virtue of being hooked up trough a second interconnect. Part of this is solved on arm32 by setting up the machine specific '.dma_zone_size = SZ_1G', which takes care of reserving the coherent memory area at the right spot. That said 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. Only ZONE_DMA32 is created which is interpreted by dma-direct and the arm64 arch 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: - Create both DMA zones in arm64, ZONE_DMA will contain the first 1G area and ZONE_DMA32 the rest of the 32 bit addressable memory. So far the RPi4 is the only arm64 device with such DMA addressing limitations so this hardcoded solution was deemed preferable. - Properly set ARCH_ZONE_DMA_BITS. - Reserve the CMA area in a place suitable for all peripherals. This series has been tested on multiple devices both by checking the zones setup matches the expectations and by double-checking physical addresses on pages allocated on the three relevant areas GFP_DMA, GFP_DMA32, GFP_KERNEL: - On an RPi4 with variations on the ram memory size. But also forcing the situation where all three memory zones are nonempty by setting a 3G ZONE_DMA32 ceiling on a 4G setup. Both with and without NUMA support. - On a Synquacer box[1] with 32G of memory. - On a Cavium ThunderX2 with 256GB of memory. - On an ACPI based Huawei TaiShan server[2] with 256G of memory. - On a QEMU virtual machine running arm64's OpenSUSE Tumbleweed. That's all. Regards, Nicolas [1] https://www.96boards.org/product/developerbox/ [2] https://e.huawei.com/en/products/cloud-computing-dc/servers/taishan-server/taishan-2280-v2 --- Changes in v6: - Fix bug in max_zone_phys() Changes in v5: - Fix issue with swiotlb initialization Changes in v4: - Rebased to linux-next - Fix issue when NUMA=n and ZONE_DMA=n - Merge two max_zone_dma*_phys() functions Changes in v3: - Fixed ZONE_DMA's size to 1G - Update mmzone.h's comment to match changes in arm64 - Remove all dma-direct patches Changes in v2: - Update comment to reflect new zones split - ZONE_DMA will never be left empty - Try another approach merging both ZONE_DMA comments into one - Address Christoph's comments - If this approach doesn't get much traction I'll just drop the patch from the series as it's not really essential Nicolas Saenz Julienne (4): arm64: mm: use arm64_dma_phys_limit instead of calling max_zone_dma_phys() arm64: rename variables used to calculate ZONE_DMA32's size arm64: use both ZONE_DMA and ZONE_DMA32 mm: refresh ZONE_DMA and ZONE_DMA32 comments in 'enum zone_type' arch/arm64/Kconfig | 4 ++ arch/arm64/include/asm/page.h | 2 + arch/arm64/mm/init.c | 71 +++++++++++++++++++++++++---------- include/linux/mmzone.h | 45 ++++++++++++---------- 4 files changed, 83 insertions(+), 39 deletions(-)