As a user recently noted, the qcom,bam-dma binding document
describes the BAM DMA node incorrectly. Fix the same by making
it consistent with the node present inside 'qcom-msm8974' dts
file.
While at it also make two minor cleanups:
- mention Bjorn's new email ID in the document, and
- add SDM845 in the comment line for the SoCs on which
qcom,bam-v1.7.0 version is supported.
Fixes: 4f46cc1b88b3 ("dt-bindings: dma: Convert Qualcomm BAM DMA binding to json format")
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Cc: [email protected]
Signed-off-by: Bhupesh Sharma <[email protected]>
---
Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
index 9bf3a1b164f1..003098caf709 100644
--- a/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
+++ b/Documentation/devicetree/bindings/dma/qcom,bam-dma.yaml
@@ -8,7 +8,7 @@ title: Qualcomm Technologies Inc BAM DMA controller
maintainers:
- Andy Gross <[email protected]>
- - Bjorn Andersson <[email protected]>
+ - Bjorn Andersson <[email protected]>
allOf:
- $ref: "dma-controller.yaml#"
@@ -20,7 +20,7 @@ properties:
- qcom,bam-v1.3.0
# MSM8974, APQ8074 and APQ8084
- qcom,bam-v1.4.0
- # MSM8916
+ # MSM8916 and SDM845
- qcom,bam-v1.7.0
clocks:
@@ -90,8 +90,8 @@ examples:
dma-controller@f9944000 {
compatible = "qcom,bam-v1.4.0";
- reg = <0xf9944000 0x15000>;
- interrupts = <GIC_SPI 94 IRQ_TYPE_LEVEL_HIGH>;
+ reg = <0xf9944000 0x19000>;
+ interrupts = <GIC_SPI 239 IRQ_TYPE_LEVEL_HIGH>;
clocks = <&gcc GCC_BLSP2_AHB_CLK>;
clock-names = "bam_clk";
#dma-cells = <1>;
--
2.37.1
On 18/09/2022 09:11, Bhupesh Sharma wrote:
> As a user recently noted, the qcom,bam-dma binding document
> describes the BAM DMA node incorrectly.
It's a bit confusing - what is exactly incorrectly described by binding?
You did not make any changes to the binding itself...
Best regards,
Krzysztof
On 9/18/22 2:19 PM, Krzysztof Kozlowski wrote:
> On 18/09/2022 09:11, Bhupesh Sharma wrote:
>> As a user recently noted, the qcom,bam-dma binding document
>> describes the BAM DMA node incorrectly.
>
> It's a bit confusing - what is exactly incorrectly described by binding?
> You did not make any changes to the binding itself...
Sorry for the late reply. Your comment just skipped through my mail
filters :(
I understand your point. I should have made the commit message more
descriptive (infact now I look at it, I see some key words are actually
missing from the commit message).
The commit message should infact read as:
"As a user recently noted, the qcom,bam-dma binding document
describes the BAM DMA node *in the example section* incorrectly. Fix the
same by making it consistent with the node present inside 'qcom-msm8974'
dts file, *namely the 'reg' and 'interrupt' values which are incorrect.
While looking at the example in the binding document, the user noted
that its incorrect when compared with both the 'msm8974' upstream as
well as downstream dts files.*
I hope the bold text (which I added above), helps clear the purpose of
the patch better.
Please let me know your views.
Thanks,
Bhupesh
On 25/09/2022 21:55, Bhupesh Sharma wrote:
>
> On 9/18/22 2:19 PM, Krzysztof Kozlowski wrote:
>> On 18/09/2022 09:11, Bhupesh Sharma wrote:
>>> As a user recently noted, the qcom,bam-dma binding document
>>> describes the BAM DMA node incorrectly.
>>
>> It's a bit confusing - what is exactly incorrectly described by binding?
>> You did not make any changes to the binding itself...
>
> Sorry for the late reply. Your comment just skipped through my mail
> filters :(
>
> I understand your point. I should have made the commit message more
> descriptive (infact now I look at it, I see some key words are actually
> missing from the commit message).
>
> The commit message should infact read as:
>
> "As a user recently noted, the qcom,bam-dma binding document
> describes the BAM DMA node *in the example section* incorrectly. Fix the
OK, now it makes sense :)
Best regards,
Krzysztof