From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lelv0143.ext.ti.com (lelv0143.ext.ti.com [198.47.23.248]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 0015017BCC; Fri, 14 Jun 2024 17:58:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.23.248 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718387914; cv=none; b=XYZ8Gej2jBL+W9qOYB4Y49BTCI3nlbTJ7aDKch88reUGsUu9Ej7rinsx99GvDtWKygCf7FyXjVtLo8OSC9eCATVxdTeOAmbjHopxAqNL21Q/nI7FFuHTF2lfO1O3hT1kTtmDv9U8bmijqS27xInxIxdXM+Bdqv4h/+4jYicqx2o= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1718387914; c=relaxed/simple; bh=hX6/vwcDgDP9auvxBpQzIAeam1ik3AqwsVBLxy+OLi0=; h=MIME-Version:Content-Type:Date:Message-ID:To:CC:Subject:From: References:In-Reply-To; b=V/MCFXHd5vG5Rvcg0s+gX5wMN46YNMs6e3axFuJlnfJbghFwAm8vt6ZoRqw9i/seqghaiEpr0CpLyyL3ZHZxG/9ilupbll6jXDIN5ZY6GOXmIu2Vfexfw3vN8BAznz1HRuO4mCQp+YcIDmZPbuIqF5htg8v7vh5+Ia4E3oI/fWg= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com; spf=pass smtp.mailfrom=ti.com; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b=oXzhxdDB; arc=none smtp.client-ip=198.47.23.248 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=ti.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=ti.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=ti.com header.i=@ti.com header.b="oXzhxdDB" Received: from fllv0034.itg.ti.com ([10.64.40.246]) by lelv0143.ext.ti.com (8.15.2/8.15.2) with ESMTP id 45EHwMTc074684; Fri, 14 Jun 2024 12:58:22 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1718387902; bh=MUF9XJqMkmkQjexFkfnks2orcYMhPl0ETqT57VwcVjo=; h=Date:To:CC:Subject:From:References:In-Reply-To; b=oXzhxdDBBN6Z7mAKkQRbcBdaAdn6UOWQDBkwBt4nVrAf4qa3npVEYqzTSr2sz6EVg dI8PntyPmFLoiZ+Cir9Ekf8g0I8TCo8FpSHR+NNmbHcBjUDotQ4487NkdDdJIn3b/E HFKc95i4HWN8j68E2KnqZvxe4aipItW+enuzZQbs= Received: from DFLE108.ent.ti.com (dfle108.ent.ti.com [10.64.6.29]) by fllv0034.itg.ti.com (8.15.2/8.15.2) with ESMTPS id 45EHwMOO024310 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 14 Jun 2024 12:58:22 -0500 Received: from DFLE115.ent.ti.com (10.64.6.36) by DFLE108.ent.ti.com (10.64.6.29) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23; Fri, 14 Jun 2024 12:58:22 -0500 Received: from lelvsmtp5.itg.ti.com (10.180.75.250) by DFLE115.ent.ti.com (10.64.6.36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.23 via Frontend Transport; Fri, 14 Jun 2024 12:58:22 -0500 Received: from localhost (rs-desk.dhcp.ti.com [128.247.81.144]) by lelvsmtp5.itg.ti.com (8.15.2/8.15.2) with ESMTP id 45EHwMHt118346; Fri, 14 Jun 2024 12:58:22 -0500 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="UTF-8" Date: Fri, 14 Jun 2024 12:58:22 -0500 Message-ID: To: Devarsh Thakkar , , , , , , , , , CC: , , , , , , Subject: Re: [PATCH 0/3] Add global CMA reserve area From: Randolph Sapp X-Mailer: aerc 0.17.0 References: <20240613150902.2173582-1-devarsht@ti.com> In-Reply-To: <20240613150902.2173582-1-devarsht@ti.com> X-EXCLAIMER-MD-CONFIG: e1e8a2fd-e40a-4ac6-ac9b-f7e9cc9ee180 On Thu Jun 13, 2024 at 10:08 AM CDT, Devarsh Thakkar wrote: > Add global CMA reserve area for AM62x, AM62A and AM62P SoCs. > These SoCs do not have MMU and hence require contiguous memory pool to > support various multimedia use-cases. > > Brandon Brnich (1): > arm64: dts: ti: k3-am62p5-sk: Reserve 576 MiB of global CMA > > Devarsh Thakkar (2): > arm64: dts: ti: k3-am62x-sk-common: Reserve 128MiB of global CMA > arm64: dts: ti: k3-am62a7-sk: Reserve 576MiB of global CMA > > arch/arm64/boot/dts/ti/k3-am62a7-sk.dts | 9 +++++++++ > arch/arm64/boot/dts/ti/k3-am62p5-sk.dts | 7 +++++++ > arch/arm64/boot/dts/ti/k3-am62x-sk-common.dtsi | 8 ++++++++ > 3 files changed, 24 insertions(+) I'm still a little torn about putting this allocation into the device tree directly as the actual required allocation size depends on the task. If it's allowed though, this series is fine for introducing those changes. = This uses the long-tested values we've been using on our tree for a bit now. The= only thing that's a little worrying is the missing range definitions for devices= with more than 32bits of addressable memory as Brandon has pointed out. Once tha= t's addressed: Reviewed-by: Randolph Sapp Specifying these regions using the kernel cmdline parameter via u-boot was brought up as a potential workaround. This is fine until you get into distr= o boot methods which will almost certainly attempt to override those. I don't know. Still a little odd. Curious how the community feels about it. Technically the user or distro can still override it with the cmdline param= eter if necessary, so this may be the best way to have a useful default.