From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from fllvem-ot04.ext.ti.com (fllvem-ot04.ext.ti.com [198.47.19.246]) (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 EA09C2E9749; Wed, 9 Jul 2025 15:56:05 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=198.47.19.246 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752076568; cv=none; b=tIHRWk99nxwDmeUycTNdKckewpMdmaH0Dbj/IB8cIwdyeq7ZLmfcqAATOn0itZUgHYqQddrAOha5gd4Wgc67EVDmBr5F+lOER8+7F8z1SwO+6gMn5DOvnqQ3bNEHiQXuVU4+pYxJTbVg0xNmEpoLEO7I0xhNomQDv+1LCmNSQXA= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1752076568; c=relaxed/simple; bh=G6jJF6k3GnUuuy4PcW4fUs7pcOeRqnQwVp5EqqLKCDw=; h=Message-ID:Date:MIME-Version:Subject:To:CC:References:From: In-Reply-To:Content-Type; b=D5a6SFzEDT5cUhr0BS63QZAl7VP4bmiWqBhwDp1YKBsjSbxEUSHs7VcNQHGdXOwZH9pMA8lzhifaQ4SkfOJaeYrdsjXc5cAMpU9yeR77ANSMROZ8XEc9APToro/vif3c+rkfDQLk3aw8Je8xwFl79nzZNMkTWVOeHCzjzvxsdho= 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=m/wnR0mE; arc=none smtp.client-ip=198.47.19.246 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="m/wnR0mE" Received: from lelvem-sh01.itg.ti.com ([10.180.77.71]) by fllvem-ot04.ext.ti.com (8.15.2/8.15.2) with ESMTP id 569FtgxY1505172; Wed, 9 Jul 2025 10:55:42 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ti.com; s=ti-com-17Q1; t=1752076542; bh=MfT0l7g5qijaXkNJNgIEaao8kUCMjEOWRY9UATjc5Fs=; h=Date:Subject:To:CC:References:From:In-Reply-To; b=m/wnR0mEUQArPldBkTx+ov0ZYMSWaEU3JA2vN1d+CzuxUhpF8siwhchRvgnzumej3 SjD3lNbs5iG+FDBPKrEhj7llrTiTJ3YmiKitqpdUWmlXFe3+9kUVwKX7DQJ6Fs7Dgt mngh3D5MNBPGFUqXGHnDY6HOP6E+BFZMQDBJ+lp0= Received: from DFLE20.ent.ti.com (dfle20.ent.ti.com [10.64.6.57]) by lelvem-sh01.itg.ti.com (8.18.1/8.18.1) with ESMTPS id 569Ftf0v282164 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Wed, 9 Jul 2025 10:55:41 -0500 Received: from DFLE113.ent.ti.com (10.64.6.34) by DFLE20.ent.ti.com (10.64.6.57) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256) id 15.2.1748.24; Wed, 9 Jul 2025 10:55:41 -0500 Received: from lelvem-mr06.itg.ti.com (10.180.75.8) by DFLE113.ent.ti.com (10.64.6.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256_P256) id 15.1.2507.55 via Frontend Transport; Wed, 9 Jul 2025 10:55:41 -0500 Received: from [10.250.35.60] ([10.250.35.60]) by lelvem-mr06.itg.ti.com (8.18.1/8.18.1) with ESMTP id 569FteH03927392; Wed, 9 Jul 2025 10:55:40 -0500 Message-ID: <8b36f958-3406-421d-ab94-5e49f911f92e@ti.com> Date: Wed, 9 Jul 2025 10:55:40 -0500 Precedence: bulk X-Mailing-List: devicetree@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v6 1/2] dma/contiguous: Add helper to test reserved memory type To: Maxime Ripard , Rob Herring , Saravana Kannan , Sumit Semwal , Benjamin Gaignard , Brian Starkey , John Stultz , "T.J. Mercier" , =?UTF-8?Q?Christian_K=C3=B6nig?= , Krzysztof Kozlowski , Conor Dooley , Marek Szyprowski , Robin Murphy CC: Jared Kangas , Mattijs Korpershoek , , , , , , References: <20250709-dma-buf-ecc-heap-v6-0-dac9bf80f35d@kernel.org> <20250709-dma-buf-ecc-heap-v6-1-dac9bf80f35d@kernel.org> Content-Language: en-US From: Andrew Davis In-Reply-To: <20250709-dma-buf-ecc-heap-v6-1-dac9bf80f35d@kernel.org> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: 7bit X-C2ProcessedOrg: 333ef613-75bf-4e12-a4b1-8e3623f5dcea On 7/9/25 7:44 AM, Maxime Ripard wrote: > A given reserved-memory region can be of multiple types. > > We have currently four types defined in the tree: contiguous, backed by > CMA, coherent and swiotlb, backed by their respective allocators, and a > platform-specific one for tegra. > > However, some users, like dma-buf heaps, might be interested in the > exact type of a reserved memory region they are getting. It would thus > be useful to have helpers to test if a given region is of a given type. > > Since we only care about CMA for now though, let's create one for CMA > only. > > Signed-off-by: Maxime Ripard > --- > include/linux/dma-map-ops.h | 13 +++++++++++++ > kernel/dma/contiguous.c | 7 +++++++ > 2 files changed, 20 insertions(+) > > diff --git a/include/linux/dma-map-ops.h b/include/linux/dma-map-ops.h > index f48e5fb88bd5dd346094bbf2ce1b79e5f5bfe1a6..ea646acb6367bd062619b337013db221749f85ab 100644 > --- a/include/linux/dma-map-ops.h > +++ b/include/linux/dma-map-ops.h > @@ -153,10 +153,23 @@ static inline void dma_free_contiguous(struct device *dev, struct page *page, > { > __free_pages(page, get_order(size)); > } > #endif /* CONFIG_DMA_CMA*/ > > +#if defined(CONFIG_DMA_CMA) && defined(CONFIG_OF_RESERVED_MEM) > +struct reserved_mem; > + > +bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem); > +#else > +struct reserved_mem; > + > +static inline bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem) > +{ > + return false; > +} > +#endif > + Should this all go in linux/of_reserved_mem.h? > #ifdef CONFIG_DMA_DECLARE_COHERENT > int dma_declare_coherent_memory(struct device *dev, phys_addr_t phys_addr, > dma_addr_t device_addr, size_t size); > void dma_release_coherent_memory(struct device *dev); > int dma_alloc_from_dev_coherent(struct device *dev, ssize_t size, > diff --git a/kernel/dma/contiguous.c b/kernel/dma/contiguous.c > index 8df0dfaaca18eeb0a20145512ba64425d2e7601e..ace4982e928e404315cf38551e1596f7ed445156 100644 > --- a/kernel/dma/contiguous.c > +++ b/kernel/dma/contiguous.c > @@ -493,6 +493,13 @@ static int __init rmem_cma_setup(struct reserved_mem *rmem) > &rmem->base, (unsigned long)rmem->size / SZ_1M); > > return 0; > } > RESERVEDMEM_OF_DECLARE(cma, "shared-dma-pool", rmem_cma_setup); > + > +bool of_reserved_mem_is_contiguous(const struct reserved_mem *rmem) Needing to check where the reserved mem comes from seems wrong, it hints that the reserved mem region drivers, like this one, are not in full control of their regions. Instead of looping over all the regions in DT in the next patch and searching for the owner, how about the owner (this driver) call into __add_cma_heap() if it chooses to expose the region in that way. (I know RESERVEDMEM_OF_DECLARE callbacks are done very early and the CMA-Heap driver might not be able to deal with adding heaps at this point, so maybe keeping a table the heaps driver can later iterate over would also work). Andrew > +{ > + return rmem->ops == &rmem_cma_ops; > +} > +EXPORT_SYMBOL_GPL(of_reserved_mem_is_contiguous); > + > #endif >