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

[Bhupesh Sharma]

On Fri, 19 May 2023 at 16:12, Konrad Dybcio <konrad.dybcio@xxxxxxxxxx> wrote:
>
> On 19.05.2023 12:22, Bhupesh Sharma wrote:
> > 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.
> This is not necessarily true. Currently it's kept always-on on
> by clk_smd_rpm_handoff, but that's a hack from 10 years ago when smd
> was still new.
>
> >
> > 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.)
> It won't change since it's on anyway, but that won't be a given for long.

Right, so that's what I observe: RPM_SMD_CE1_CLK is always on by the
time crypto _probe gets called.
So, IMO let's not mix this patchset with the other fix which probably
will fix the 10-year old clk_smd_rpm handoff keeping
these clocks on.

Probably that should be a separate changeset - requiring very thorough
checks to make sure that we don't break
working platforms.

Thanks.