[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <733afe4f-51d8-4c5e-8c18-9843a316523e@oss.qualcomm.com>
Date: Mon, 1 Dec 2025 13:48:00 +0530
From: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
To: Krzysztof Kozlowski <krzk@...nel.org>
Cc: kpallavi@....qualcomm.com, srini@...nel.org, amahesh@....qualcomm.com,
arnd@...db.de, gregkh@...uxfoundation.org, robh@...nel.org,
krzk+dt@...nel.org, conor+dt@...nel.org, quic_bkumar@...cinc.com,
ekansh.gupta@....qualcomm.com, linux-kernel@...r.kernel.org,
quic_chennak@...cinc.com, dri-devel@...ts.freedesktop.org,
linux-arm-msm@...r.kernel.org, devicetree@...r.kernel.org,
jingyi.wang@....qualcomm.com, aiqun.yu@....qualcomm.com,
ktadakam@....qualcomm.com
Subject: Re: [PATCH v4 1/4] dt-bindings: misc: qcom,fastrpc: Add compatible
for Kaanapali
On 11/27/2025 1:00 PM, Krzysztof Kozlowski wrote:
> On Wed, Nov 26, 2025 at 03:15:42PM +0530, Kumari Pallavi wrote:
>> Add a new compatible string "qcom,kaanapali-fastrpc" to support
>> for Kaanapali SoC.
>
> ... and here you write WHY or provide background about hardware
> differences, instead of writing what you did. We see what you did easily
> - we can read the diff. Additionally your subject already said this, so
> basically your commit msg is redundant...
>
> I still do not know why Kaanapali needs this.
>
Thank you for the feedback. Let me clarify the hardware differences that
require this change:
Kaanapali introduces a new DSP IOVA formatting scheme and a hardware
revision in CDSP that expands the DMA addressable range. On previous
SoCs, DSPs used a 32-bit physical address plus a 4-bit Stream ID (SID).
Kaanapali changes:
SID placement: The SID field moves within the physical address, so the
driver must know the new sid_pos to correctly form IOVA for ADSP/CDSP.
Expanded DMA range: CDSP now supports a 34-bit physical address plus the
4-bit SID, requiring an updated DMA mask to avoid truncating valid
addresses.
To apply these changes only on Kaanapali, I introduce a SoC-specific
compatible string "qcom,kaanapali-fastrpc".
Older DTs using "qcom,fastrpc" remain valid and unchanged; the new
behavior is applied only when the Kaanapali-specific compatible is present.
https://lore.kernel.org/all/542f84ce-b840-44f9-bdf8-09611369e6bb@kernel.org/
>>
>> Signed-off-by: Kumari Pallavi <kumari.pallavi@....qualcomm.com>
>> ---
>> Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml | 5 ++++-
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
>> index 3f6199fc9ae6..6c19217d63a6 100644
>> --- a/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
>> +++ b/Documentation/devicetree/bindings/misc/qcom,fastrpc.yaml
>> @@ -18,7 +18,10 @@ description: |
>>
>> properties:
>> compatible:
>> - const: qcom,fastrpc
>> + items:
>
> No need to introduce items, wasn't here before. Just enum directly.
>
If I use enum directly, the schema will only validate a single
string—either "qcom,fastrpc" or "qcom,kaanapali-fastrpc". However, my
DTS changes introduce a compatible property with two strings: the
SoC-specific string followed by the generic fallback.
That’s why I used items in the schema—to allow an array of strings where
the first entry is "qcom,kaanapali-fastrpc" and the second is "qcom,fastrpc"
Thanks,
Pallavi>> + - enum:
>> + - qcom,kaanapali-fastrpc
>> + - qcom,fastrpc
>>
>> label:
>> enum:
>> --
>> 2.34.1
>>
Powered by blists - more mailing lists