Received: by 2002:a25:e74b:0:0:0:0:0 with SMTP id e72csp857910ybh; Tue, 21 Jul 2020 09:29:57 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxb8YDdF+QSjAu0nhsZ5N6wvlzcZw/76m4bOYaJEc4smNq0a3HerVFi5Mlki+VdEJ2h9pww X-Received: by 2002:aa7:d7d0:: with SMTP id e16mr26963008eds.10.1595348996981; Tue, 21 Jul 2020 09:29:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1595348996; cv=none; d=google.com; s=arc-20160816; b=i1uEUyAVLgti0A+aqnRopGdLbg9wKO76uVWy3R0GCu1sIEO+3gRz3QtKqDt0TDp0i+ 8N7x+sAuBYliVRhnFxbYXvPiorA6bTBTJeUW2BR4C0LdzJ6pwE+Cergz+5cWFARcJU/4 qJYFlm5STK1eeRceEPtV70kzAfbxVNEBZ1Q6/k5zEjQNEV3AdkyIa1+L+6PLgqjUjuz6 w+wdr6TK2m/59lLm9/fJCdIGBuhb0by8Ddh3y52OtOF5wcgcMZVuB4i/uhp1/zCiauZr d4ohHilgoxBQxN6UUkXM1ECXkS6U3+y0HEhvFuGMPiZjhBbyXuw2A9ZY+yNqhrLjesVk jayA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :user-agent:references:in-reply-to:date:cc:to:from:subject :message-id; bh=FM1hq4Nins0GQAY6HrxFjJf9nZ649CRYYcRDbPRZOXk=; b=ah2yf88Ccn8xiyXOQC9UUQaCD5tunOr3yoib0jvcN4KVXyjWtgPneGBICUMI/oszy+ 6lwUaAsRcf6AfUea4J4un7HN0iL/nINembcPuOoDZ3REIgYk6zJpZyD5+fHieJi+A6Tx BTNd9Jn0XRWnigVWW6T8zxr0cc8WbGMIUfdtSH0aw/r+PAq+prHQ0K08gRzh52CGuwgd FHrOxpgSjm00u9BwVgcXPraQ9WG5CLPcSrhVTTkKT1xfXoqNkxJ6quudC9U8IBtvFqh3 YyB68hxK7W/7TzKEck4DTlz+iyW/nYsrMq7r3jyqDK0Xa7IstoOXbIx3615qL/3ah/X2 RtRQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y19si12316537ejm.324.2020.07.21.09.29.33; Tue, 21 Jul 2020 09:29:56 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728268AbgGUQ12 (ORCPT + 99 others); Tue, 21 Jul 2020 12:27:28 -0400 Received: from mx2.suse.de ([195.135.220.15]:39704 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727115AbgGUQ12 (ORCPT ); Tue, 21 Jul 2020 12:27:28 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id CD59EAD79; Tue, 21 Jul 2020 16:27:33 +0000 (UTC) Message-ID: <6db722947546221ed99d3f473f78e1a6de65d7d6.camel@suse.de> Subject: Re: [PATCH] dma-pool: Do not allocate pool memory from CMA From: Nicolas Saenz Julienne To: Amit Pundir Cc: Christoph Hellwig , Marek Szyprowski , Robin Murphy , David Rientjes , linux-rpi-kernel@lists.infradead.org, jeremy.linton@arm.com, iommu@lists.linux-foundation.org, lkml , John Stultz , Sumit Semwal Date: Tue, 21 Jul 2020 18:27:24 +0200 In-Reply-To: References: <20200708164936.9340-1-nsaenzjulienne@suse.de> <550b30a86c0785049d24c945e2c6628d491cee3a.camel@suse.de> <011994f8a717a00dcd9ed7682a1ddeb421c2c43f.camel@suse.de> <01831596e4a2a6c9c066138b23bd30435f8e5569.camel@suse.de> Content-Type: text/plain; charset="UTF-8" User-Agent: Evolution 3.36.3-0ubuntu1 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2020-07-21 at 20:52 +0530, Amit Pundir wrote: [...] > > > > Can you try booting *without* my patch and this in the kernel > > > > command > > > > line: "cma=16M@0x100000000-0x200000000". > > > > > > It doesn't boot with this added kernel command line. > > > > For the record, this placed the CMA in the [4GB, 8GB] address space > > instead of you setup's default: [3GB, 4GB]. All atomic pools fall > > in > > that memory area without my patch, which makes me think some of the > > devices on your board might not like higher addresses. > > > > Thank you Nicolas for the details. Though we don't set the CMA > alloc-ranges explicitly in upstream sdm845 dts, but I dug around and > found that CMA alloc-ranges in the downstream kernel are indeed in > lower address space. > https://github.com/MiCode/Xiaomi_Kernel_OpenSource/blob/dipper-q-oss/arch/arm64/boot/dts/qcom/sdm845.dtsi#L662 > > /* global autoconfigured region for contiguous allocations */ > linux,cma { > compatible = "shared-dma-pool"; > alloc-ranges = <0 0x00000000 0 0xffffffff>; > reusable; > alignment = <0 0x400000>; > size = <0 0x2000000>; > linux,cma-default; > }; Pretty standard, and similar to what it's being used upstream by default. > > > What happens if you boot with my troublesome patch with this in > > your > > device tree? (insert it at the bottom of sdm845-beryllium.dts) > > > > &soc { > > dma-ranges = <0 0 0 0 0x1 0>; > > }; > > > > Device still doesn't boot up to adb shell. Let's get a bigger hammer, I'm just looking for clues here. Can you apply this and provide the dmesg output. diff --git a/kernel/dma/pool.c b/kernel/dma/pool.c index 6bc74a2d5127..2160676bf488 100644 --- a/kernel/dma/pool.c +++ b/kernel/dma/pool.c @@ -268,6 +268,8 @@ void *dma_alloc_from_pool(struct device *dev, size_t size, schedule_work(&atomic_pool_work); } + dev_info(dev, "%s: size %lx, phys addr %llx, flags 0x%x\n", __func__, size, phys, flags); + return ptr; } Regards, Nicolas