linux-kernel - Re: [PATCH v2] arm64: dts: qcom: sm8650: add iris DT node

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAO9ioeWaPKXHgNGPx5q34+RP59PMLD+EVK5fQsN89KC9A1ca-Q@mail.gmail.com>
Date: Mon, 28 Apr 2025 13:48:02 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: neil.armstrong@...aro.org
Cc: Konrad Dybcio <konrad.dybcio@....qualcomm.com>,
        Bjorn Andersson <andersson@...nel.org>,
        Konrad Dybcio <konradybcio@...nel.org>, Rob Herring <robh@...nel.org>,
        Krzysztof Kozlowski <krzk+dt@...nel.org>,
        Conor Dooley <conor+dt@...nel.org>, linux-arm-msm@...r.kernel.org,
        devicetree@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] arm64: dts: qcom: sm8650: add iris DT node

On Mon, 28 Apr 2025 at 11:18, Neil Armstrong <neil.armstrong@...aro.org> wrote:
>
> Hi,
>
> On 25/04/2025 23:49, Konrad Dybcio wrote:
> > On 4/24/25 6:32 PM, Neil Armstrong wrote:
> >> Add DT entries for the sm8650 iris decoder.
> >>
> >> Since the firmware is required to be signed, only enable
> >> on Qualcomm development boards where the firmware is
> >> available.
> >>
> >> Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
> >> Signed-off-by: Neil Armstrong <neil.armstrong@...aro.org>
> >> ---
> >> Changes in v2:
> >> - removed useless firmware-name
> >> - Link to v1: https://lore.kernel.org/r/20250418-topic-sm8x50-upstream-iris-8650-dt-v1-1-80a6ae50bf10@linaro.org
> >> ---
> >
> > [...]
> >
> >> +            iris: video-codec@...0000 {
> >> +                    compatible = "qcom,sm8650-iris";
> >> +                    reg = <0 0x0aa00000 0 0xf0000>;
> >> +
> >> +                    interrupts = <GIC_SPI 174 IRQ_TYPE_LEVEL_HIGH 0>;
> >> +
> >> +                    power-domains = <&videocc VIDEO_CC_MVS0C_GDSC>,
> >> +                                    <&videocc VIDEO_CC_MVS0_GDSC>,
> >> +                                    <&rpmhpd RPMHPD_MXC>,
> >> +                                    <&rpmhpd RPMHPD_MMCX>;
> >> +                    power-domain-names = "venus",
> >> +                                         "vcodec0",
> >> +                                         "mxc",
> >> +                                         "mmcx";
> >> +
> >> +                    operating-points-v2 = <&iris_opp_table>;
> >> +
> >> +                    clocks = <&gcc GCC_VIDEO_AXI0_CLK>,
> >> +                             <&videocc VIDEO_CC_MVS0C_CLK>,
> >> +                             <&videocc VIDEO_CC_MVS0_CLK>;
> >> +                    clock-names = "iface",
> >> +                                  "core",
> >> +                                  "vcodec0_core";
> >> +
> >> +                    interconnects = <&gem_noc MASTER_APPSS_PROC QCOM_ICC_TAG_ACTIVE_ONLY
> >> +                                     &config_noc SLAVE_VENUS_CFG QCOM_ICC_TAG_ACTIVE_ONLY>,
> >> +                                    <&mmss_noc MASTER_VIDEO QCOM_ICC_TAG_ALWAYS
> >> +                                     &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
> >> +                    interconnect-names = "cpu-cfg",
> >> +                                         "video-mem";
> >> +
> >> +                    /* FW load region */
> >
> > I don't think this comment brings value
>
> Right
>
> >
> >> +                    memory-region = <&video_mem>;
> >> +
> >> +                    resets = <&gcc GCC_VIDEO_AXI0_CLK_ARES>,
> >> +                             <&videocc VIDEO_CC_XO_CLK_ARES>,
> >> +                             <&videocc VIDEO_CC_MVS0C_CLK_ARES>;
> >> +                    reset-names = "bus",
> >> +                                  "xo",
> >> +                                  "core";
> >> +
> >> +                    iommus = <&apps_smmu 0x1940 0>,
> >> +                             <&apps_smmu 0x1947 0>;
> >
> > I think you may also need 0x1942 0x0 (please also make the second value / SMR
> > mask hex)> +
>
> I don't see 0x1942 in the downstream DT, and which mask should I set ? 0x1 ?
>
> >> +                    dma-coherent;
> >> +
> >> +                    /*
> >> +                     * IRIS firmware is signed by vendors, only
> >> +                     * enable in boards where the proper signed firmware
> >> +                     * is available.
> >> +                     */
> >
> > Here's to another angry media article :(
> >
> > Please keep Iris enabled.. Vikash reassured me this is not an
> > issue until the user attempts to use the decoder [1], and reading
> > the code myself I come to the same conclusion (though I haven't given
> > it a smoke test - please do that yourself, as you seem to have a better
> > set up with these platforms).
> >
> > If the userland is sane, it should throw an error and defer to CPU
> > decoding.
> >
> > This is >>unlike venus<< which if lacking firmware at probe (i.e. boot)
> > would prevent .sync_state
>
> Well sync with Bjorn who asked me to only enable on board with available firmware ;-)

I'd second him here: if there is no firmware, don't enable the device.
It's better than the users having cryptic messages in the dmesg,
trying to understand why the driver errors out.

>
> >
> > [1] https://lore.kernel.org/linux-arm-msm/98a35a51-6351-5ebb-4207-0004e89682eb@quicinc.com/
> >
> > [...]
> >
> >> +
> >> +                            opp-480000000 {
> >> +                                    opp-hz = /bits/ 64 <480000000>;
> >> +                                    required-opps = <&rpmhpd_opp_turbo>,
> >> +                                                    <&rpmhpd_opp_turbo>;
> >
> > nom (nom nom nom nom nom)
> >
> >> +                            };
> >> +
> >> +                            opp-533333334 {
> >> +                                    opp-hz = /bits/ 64 <533333334>;
> >> +                                    required-opps = <&rpmhpd_opp_turbo_l1>,
> >> +                                                    <&rpmhpd_opp_turbo_l1>;
> >
> > turbo
>
> Ack
>
> >
> > Konrad
>
> Thanks,
> Neil



-- 
With best wishes
Dmitry