From: Marek Szyprowski <m.szyprowski@samsung.com>
To: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>,
Ye Li <ye.li@oss.nxp.com>,
robh@kernel.org, robin.murphy@arm.com
Cc: saravanak@google.com, quic_obabatun@quicinc.com,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org,
iommu@lists.linux.dev, william.zhang@broadcom.com,
kernel@oss.qualcomm.com, will@kernel.org, djakov@kernel.org,
aisheng.dong@nxp.com, joy.zou@nxp.com, frank.li@nxp.com,
jason.hui.liu@nxp.com
Subject: Re: [PATCH v4] of: reserved_mem: Restructure call site for dma_contiguous_early_fixup()
Date: Mon, 1 Dec 2025 08:51:16 +0100 [thread overview]
Message-ID: <be70bdc4-bddd-4afe-8574-7e0889fd381c@samsung.com> (raw)
In-Reply-To: <306596c4-cc91-4500-b705-50e619e9f38e@oss.qualcomm.com>
On 01.12.2025 07:31, Oreoluwa Babatunde wrote:
> On 11/28/2025 4:43 AM, Marek Szyprowski wrote:
>> On 26.11.2025 02:37, Ye Li wrote:
>>> On 8/11/2025 7:07 PM, Marek Szyprowski wrote:
>>>> On 06.08.2025 19:24, Oreoluwa Babatunde wrote:
>>>>> Restructure the call site for dma_contiguous_early_fixup() to
>>>>> where the reserved_mem nodes are being parsed from the DT so that
>>>>> dma_mmu_remap[] is populated before dma_contiguous_remap() is called.
>>>>>
>>>>> Fixes: 8a6e02d0c00e ("of: reserved_mem: Restructure how the reserved
>>>>> memory regions are processed")
>>>>> Signed-off-by: Oreoluwa Babatunde <oreoluwa.babatunde@oss.qualcomm.com>
>>>>> Tested-by: William Zhang <william.zhang@broadcom.com>
>>>> Thanks, applied to dma-mapping-fixes branch.
>>>>
>>>> Best regards
>>> Hi Oreoluwa,
>>>
>>> We observed this patch causing kernel boot hang on iMX6 (armv7)
>>> platforms if using "cma=" kernel parameter. It only happens when the
>>> size assigned in
>>> "cma=" parameter is smaller than cma default size in dts.
>>>
>>> For example, we use "cma=96M" in command line and below reserved
>>> memory node (160M) in dts.
>>>
>>> reserved-memory {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> ranges;
>>>
>>> linux,cma {
>>> compatible = "shared-dma-pool";
>>> reusable;
>>> size = <0xa000000>;
>>> linux,cma-default;
>>> };
>>> };
>>>
>>> The root cause is this patch moving the dma_contiguous_early_fixup
>>> from rmem_cma_setup to __reserved_mem_alloc_size. rmem_cma_setup can
>>> skip the cma reserved memory if command line has cma parameter.
>>> However, the __reserved_mem_alloc_size won't do it. So this leads to
>>> have two cma regions added to dma_mmu_remap, one from dts, the other
>>> from command line. But the reserved memory of memblock that only
>>> records the cma from command line is inconsistent with dma_mmu_remap.
>>> The dma_contiguous_remap clears the MMU paging for the region of
>>> dma_mmu_remap firstly, then create a new mapping by iotable_init. For
>>> the cma from dts, this causes incorrect memory mapping cleared. Then
>>> any allocation from memblock in iotable_init hitting to the area will
>>> meet MMU mapping issue.
>>>
> Hi Ye Li,
>
> Thanks for pointing this out. From what I see in the code, if "cma="
> kernel parameter is being used to configure the default cma region, then we
> should skip adding the DT defined region to dma_mmu_remap array.
>
> I will work on a fix which does this and share here when it is done.
I wonder how to avoid adding more such checks to
drivers/of/of_reserved_mem.c and making this code even more tangled and
spaghetti-like... I've briefly scanned that code and it is already quite
hard to follow, especially after commits 8a6e02d0c00e ("of:
reserved_mem: Restructure how the reserved memory regions are
processed") and 2c223f7239f3 ("of: reserved_mem: Restructure call site
for dma_contiguous_early_fixup()")... I wonder how many reserved memory
regions are used on real machines? Maybe instead of complicating this
code even more it is enough to make this configurable via Kconfig and
restore pre-8a6e02d0c00e version?
>>> From commit, I don't understand what issue does this patch fix. Can
>>> you look into the regression and provide a fix patch.
> Please see below conversation for details on the original issue this patch fixes:
> https://lore.kernel.org/all/5aa94f41-c689-443b-8665-c6913ff5ba8f@broadcom.com/
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
next prev parent reply other threads:[~2025-12-01 7:51 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CGME20250806172503eucas1p264d6731c73592fcc380b0dcc21cdeadf@eucas1p2.samsung.com>
2025-08-06 17:24 ` Oreoluwa Babatunde
2025-08-11 11:07 ` Marek Szyprowski
2025-11-26 1:37 ` Ye Li
2025-11-28 12:43 ` Marek Szyprowski
2025-12-01 6:31 ` Oreoluwa Babatunde
2025-12-01 7:51 ` Marek Szyprowski [this message]
2025-12-02 6:54 ` Oreoluwa Babatunde
2025-12-10 0:29 ` Oreoluwa Babatunde
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=be70bdc4-bddd-4afe-8574-7e0889fd381c@samsung.com \
--to=m.szyprowski@samsung.com \
--cc=aisheng.dong@nxp.com \
--cc=devicetree@vger.kernel.org \
--cc=djakov@kernel.org \
--cc=frank.li@nxp.com \
--cc=iommu@lists.linux.dev \
--cc=jason.hui.liu@nxp.com \
--cc=joy.zou@nxp.com \
--cc=kernel@oss.qualcomm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oreoluwa.babatunde@oss.qualcomm.com \
--cc=quic_obabatun@quicinc.com \
--cc=robh@kernel.org \
--cc=robin.murphy@arm.com \
--cc=saravanak@google.com \
--cc=will@kernel.org \
--cc=william.zhang@broadcom.com \
--cc=ye.li@oss.nxp.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®