From: Md Sadre Alam <quic_mdalam@quicinc.com>
To: Krzysztof Kozlowski <krzk@kernel.org>, <andersson@kernel.org>,
<konradybcio@kernel.org>, <robh@kernel.org>, <krzk+dt@kernel.org>,
<conor+dt@kernel.org>, <vkoul@kernel.org>, <Frank.Li@kernel.org>,
<linux-arm-msm@vger.kernel.org>, <devicetree@vger.kernel.org>,
<linux-kernel@vger.kernel.org>, <dmaengine@vger.kernel.org>
Cc: <quic_varada@quicinc.com>
Subject: Re: [PATCH v4 1/7] dma: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+
Date: Mon, 9 Feb 2026 17:14:55 +0530 [thread overview]
Message-ID: <0315074e-72f3-1bc4-83b1-e60d5e4aef2a@quicinc.com> (raw)
In-Reply-To: <409c2e5f-1bf2-44ed-9c0f-df762320e068@kernel.org>
Hi,
On 2/6/2026 10:42 PM, Krzysztof Kozlowski wrote:
> On 06/02/2026 11:01, Md Sadre Alam wrote:
>> BAM version 1.6.0 and later changed the behavior of the mask field in
>> command elements for read operations. In newer BAM versions, the mask
>> field for read commands contains the upper 4 bits of the destination
>> address to support 36-bit addressing, while for write commands it
>> continues to function as a traditional write mask.
>>
>> This change causes NAND enumeration failures on platforms like IPQ5424
>
> Please do not use "This commit/patch/change", but imperative mood. See
> longer explanation here:
> https://elixir.bootlin.com/linux/v6.16/source/Documentation/process/submitting-patches.rst#L94
Ok
>
>> that use BAM v1.6.0+, because the current code sets mask=0xffffffff
>> for all commands. For read commands on newer BAM versions, this results
>> in the hardware interpreting the destination address as 0xf_xxxxxxxx
>> (invalid high memory) instead of the intended 0x0_xxxxxxxx address.
>>
>> Fixed this issue by:
>> 1. Updating the bam_cmd_element structure documentation to reflect the
>> dual purpose of the mask field
>> 2. Modifying bam_prep_ce_le32() to set appropriate mask values based on
>> command type:
>> - For read commands: mask = 0 (32-bit addressing, upper bits = 0)
>> - For write commands: mask = 0xffffffff (traditional write mask)
>> 3. Maintaining backward compatibility with older BAM versions
>>
>> This fix enables proper NAND functionality on IPQ5424 and other platforms
>> using BAM v1.6.0+ while preserving compatibility with existing systems.
>
> Fixes tag? CC-stable?
This patch is not fixing an existing commit. This is to address the
update in the newer version of the hardware.
>
> Why is this part of DTS patchset? Do not combine independent work, you
> only make it difficult for maintainers to handle your work.
Will post a new version with the driver change as a separate patch.
Thanks,
Alam.
next prev parent reply other threads:[~2026-02-09 11:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-02-06 10:01 [PATCH v4 0/7] Add QPIC SPI NAND support for IPQ5424 and IPQ5332 platforms Md Sadre Alam
2026-02-06 10:01 ` [PATCH v4 1/7] dma: qcom: bam_dma: Fix command element mask field for BAM v1.6.0+ Md Sadre Alam
2026-02-06 17:12 ` Krzysztof Kozlowski
2026-02-09 11:43 ` Md Sadre Alam
2026-02-09 12:06 ` Krzysztof Kozlowski
2026-02-10 9:44 ` Md Sadre Alam
2026-02-09 11:44 ` Md Sadre Alam [this message]
2026-02-06 19:24 ` Frank Li
2026-02-06 10:01 ` [PATCH v4 2/7] arm64: dts: qcom: ipq5424: Add QPIC SPI NAND controller support Md Sadre Alam
2026-02-06 10:01 ` [PATCH v4 3/7] arm64: dts: qcom: ipq5332: " Md Sadre Alam
2026-02-06 10:01 ` [PATCH v4 4/7] arm64: dts: qcom: ipq5424-rdp466: Enable QPIC SPI NAND support Md Sadre Alam
2026-02-06 10:02 ` [PATCH v4 5/7] arm64: dts: qcom: pq5332-rdp-common: " Md Sadre Alam
2026-02-06 10:02 ` [PATCH v4 6/7] arm64: dts: qcom: ipq5424-rdp466: Remove eMMC support Md Sadre Alam
2026-02-06 10:02 ` [PATCH v4 7/7] arm64: dts: qcom: ipq5332-rdp442: " Md Sadre Alam
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=0315074e-72f3-1bc4-83b1-e60d5e4aef2a@quicinc.com \
--to=quic_mdalam@quicinc.com \
--cc=Frank.Li@kernel.org \
--cc=andersson@kernel.org \
--cc=conor+dt@kernel.org \
--cc=devicetree@vger.kernel.org \
--cc=dmaengine@vger.kernel.org \
--cc=konradybcio@kernel.org \
--cc=krzk+dt@kernel.org \
--cc=krzk@kernel.org \
--cc=linux-arm-msm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=quic_varada@quicinc.com \
--cc=robh@kernel.org \
--cc=vkoul@kernel.org \
/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