| Message ID | 20231204-msm8916-blsp-dma-remote-v1-1-3e49c8838c8d@gerhold.net (mailing list archive) |
|---|---|
| State | Accepted |
| Commit | 7c45b6ddbcff01f9934d11802010cfeb0879e693 |
| Headers | show |
| Series | arm64: dts: qcom: msm8916/39: Make blsp_dma controlled-remotely | expand |
On 04/12/2023 11:21, Stephan Gerhold wrote: > The blsp_dma controller is shared between the different subsystems, > which is why it is already initialized by the firmware. We should not > reinitialize it from Linux to avoid potential other users of the DMA > engine to misbehave. > > In mainline this can be described using the "qcom,controlled-remotely" > property. In the downstream/vendor kernel from Qualcomm there is an > opposite "qcom,managed-locally" property. This property is *not* set > for the qcom,sps-dma@7884000 [1] so adding "qcom,controlled-remotely" > upstream matches the behavior of the downstream/vendor kernel. > > Adding this seems to fix some weird issues with UART where both > input/output becomes garbled with certain obscure firmware versions on > some devices. > > [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.2.9.1-02310-8x16.0/arch/arm/boot/dts/qcom/msm8916.dtsi#L1466-1472 > > Cc: <stable@vger.kernel.org> # 6.5 > Fixes: a0e5fb103150 ("arm64: dts: qcom: Add msm8916 BLSP device nodes") > Signed-off-by: Stephan Gerhold <stephan@gerhold.net> > --- > This should only be backported to v6.5+ since it depends on commit > 8975dd41a9db ("dmaengine: qcom: bam_dma: allow omitting > num-{channels,ees}") which landed in v6.5. > --- > arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi > index e8a14dd7e7c2..7f8327b0dbdb 100644 > --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi > +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi > @@ -2155,6 +2155,7 @@ blsp_dma: dma-controller@7884000 { > clock-names = "bam_clk"; > #dma-cells = <1>; > qcom,ee = <0>; > + qcom,controlled-remotely; > }; > > blsp_uart1: serial@78af000 { > Reviewed-by: Bryan O'Donoghue <bryan.odonoghue@linaro.org>
diff --git a/arch/arm64/boot/dts/qcom/msm8916.dtsi b/arch/arm64/boot/dts/qcom/msm8916.dtsi index e8a14dd7e7c2..7f8327b0dbdb 100644 --- a/arch/arm64/boot/dts/qcom/msm8916.dtsi +++ b/arch/arm64/boot/dts/qcom/msm8916.dtsi @@ -2155,6 +2155,7 @@ blsp_dma: dma-controller@7884000 { clock-names = "bam_clk"; #dma-cells = <1>; qcom,ee = <0>; + qcom,controlled-remotely; }; blsp_uart1: serial@78af000 {
The blsp_dma controller is shared between the different subsystems, which is why it is already initialized by the firmware. We should not reinitialize it from Linux to avoid potential other users of the DMA engine to misbehave. In mainline this can be described using the "qcom,controlled-remotely" property. In the downstream/vendor kernel from Qualcomm there is an opposite "qcom,managed-locally" property. This property is *not* set for the qcom,sps-dma@7884000 [1] so adding "qcom,controlled-remotely" upstream matches the behavior of the downstream/vendor kernel. Adding this seems to fix some weird issues with UART where both input/output becomes garbled with certain obscure firmware versions on some devices. [1]: https://git.codelinaro.org/clo/la/kernel/msm-3.10/-/blob/LA.BR.1.2.9.1-02310-8x16.0/arch/arm/boot/dts/qcom/msm8916.dtsi#L1466-1472 Cc: <stable@vger.kernel.org> # 6.5 Fixes: a0e5fb103150 ("arm64: dts: qcom: Add msm8916 BLSP device nodes") Signed-off-by: Stephan Gerhold <stephan@gerhold.net> --- This should only be backported to v6.5+ since it depends on commit 8975dd41a9db ("dmaengine: qcom: bam_dma: allow omitting num-{channels,ees}") which landed in v6.5. --- arch/arm64/boot/dts/qcom/msm8916.dtsi | 1 + 1 file changed, 1 insertion(+)