Re: [PATCH v6 07/11] arm64: dts: qcom: sm6115: Add Crypto Engine support

[Bhupesh Sharma]

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/