Hi Stephan, On Fri, 19 May 2023 at 15:40, Stephan Gerhold <stephan@xxxxxxxxxxx> wrote: > > Hi Bhupesh, > > Not sure if this is the latest version of this series since it's pretty > old but I didn't find a new one. Just came here because you mentioned > RB1/RB2 [1] in my bam_dma patch and they don't have any BAM defined > upstream yet. > > [1]: https://lore.kernel.org/linux-arm-msm/CAH=2Ntw0BZH=RGp14mYLhX7D6jV5O5eDKRQbby=uCy85xMDU_g@xxxxxxxxxxxxxx/ > > On Wed, Apr 05, 2023 at 12:58:32PM +0530, Bhupesh Sharma wrote: > > Add crypto engine (CE) and CE BAM related nodes and definitions to > > 'sm6115.dtsi'. > > > > Signed-off-by: Bhupesh Sharma <bhupesh.sharma@xxxxxxxxxx> > > --- > > arch/arm64/boot/dts/qcom/sm6115.dtsi | 22 ++++++++++++++++++++++ > > 1 file changed, 22 insertions(+) > > > > diff --git a/arch/arm64/boot/dts/qcom/sm6115.dtsi b/arch/arm64/boot/dts/qcom/sm6115.dtsi > > index 2a51c938bbcb..ebac026b4cc7 100644 > > --- a/arch/arm64/boot/dts/qcom/sm6115.dtsi > > +++ b/arch/arm64/boot/dts/qcom/sm6115.dtsi > > @@ -650,6 +650,28 @@ usb_hsphy: phy@1613000 { > > status = "disabled"; > > }; > > > > + cryptobam: dma-controller@1b04000 { > > + compatible = "qcom,bam-v1.7.4", "qcom,bam-v1.7.0"; > > + reg = <0x0 0x01b04000 0x0 0x24000>; > > + interrupts = <GIC_SPI 247 IRQ_TYPE_LEVEL_HIGH>; > > + #dma-cells = <1>; > > + qcom,ee = <0>; > > + qcom,controlled-remotely; > > + num-channels = <8>; > > + qcom,num-ees = <2>; > > + iommus = <&apps_smmu 0x94 0x11>, > > + <&apps_smmu 0x96 0x11>; > > + }; > > + > > + crypto: crypto@1b3a000 { > > + compatible = "qcom,sm6115-qce", "qcom,sm8150-qce", "qcom,qce"; > > + reg = <0x0 0x01b3a000 0x0 0x6000>; > > + dmas = <&cryptobam 6>, <&cryptobam 7>; > > + dma-names = "rx", "tx"; > > + iommus = <&apps_smmu 0x94 0x11>, > > + <&apps_smmu 0x96 0x11>; > > Shouldn't you have clocks = <&rpmcc RPM_SMD_CE1_CLK> here to make sure > the clock for the crypto engine is on? Your binding patch (PATCH 06/11) > says "Crypto Engine block on Qualcomm SoCs SM6115 and QCM2290 do not > require clocks strictly" but doesn't say why. > > Make sure you don't rely on having rpmcc keep unused clocks on > permanently. This is the case at the moment, but we would like to change > this [2]. Adding new users that rely on this broken behavior would just > make this effort even more complicated. > > If you also add the clock to the cryptobam then you should be able to > see the advantage of my bam_dma patch [3]. It allows you to drop > "num-channels" and "qcom,num-ees" from the cryptobam in your changes > above because it can then be read directly from the BAM registers. Thanks for pointing this out. Actually that's why I was using your patch while testing with RB1/RB2 :) Yes, so the background is that I am preparing a new version of this crypto enablement patchset. Also your assumption about the clocks being turned on by the firmware is true for RB1/RB2 devices, so enabling them via Linux is optional as per Qualcomm enggs. So, I am testing the new patchset right now with 'clock' entries provided in the .dtsi and see if that causes any issue / improvement (etc.) Will come back with updates (and a new version of this patchset) soon. Regards, Bhupesh > Thanks, > Stephan > > [2]: https://lore.kernel.org/linux-arm-msm/20230303-topic-rpmcc_sleep-v2-0-ae80a325fe94@xxxxxxxxxx/ > [3]: https://lore.kernel.org/linux-arm-msm/20230518-bamclk-dt-v1-1-82f738c897d9@xxxxxxxxxxx/
