| 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
| ||
|
Message-ID: <CAO9ioeXu5D6iG-Y4vJyrckj1DaZvjO7pMJTY4J16M-fW_p6rrg@mail.gmail.com>
Date: Mon, 9 Jun 2025 01:19:58 +0300
From: Dmitry Baryshkov <dmitry.baryshkov@....qualcomm.com>
To: Akhil P Oommen <quic_akhilpo@...cinc.com>
Cc: rob.clark@....qualcomm.com, Akhil P Oommen <akhilpo@....qualcomm.com>,
Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will@...nel.org>, Sean Paul <sean@...rly.run>,
Konrad Dybcio <konradybcio@...nel.org>,
Abhinav Kumar <abhinav.kumar@...ux.dev>,
Jessica Zhang <jessica.zhang@....qualcomm.com>,
Marijn Suijten <marijn.suijten@...ainline.org>,
David Airlie <airlied@...il.com>, Simona Vetter <simona@...ll.ch>,
Bjorn Andersson <andersson@...nel.org>, Rob Herring <robh@...nel.org>,
Krzysztof Kozlowski <krzk+dt@...nel.org>,
Conor Dooley <conor+dt@...nel.org>,
linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
linux-arm-msm@...r.kernel.org, dri-devel@...ts.freedesktop.org,
freedreno@...ts.freedesktop.org, devicetree@...r.kernel.org
Subject: Re: [PATCH 3/3] arm64: dts: qcom: Add GPU support to X1P42100 SoC
On Sun, 8 Jun 2025 at 23:18, Akhil P Oommen <quic_akhilpo@...cinc.com> wrote:
>
> On 6/8/2025 8:52 PM, Dmitry Baryshkov wrote:
> > On 08/06/2025 18:20, Rob Clark wrote:
> >> On Sun, Jun 8, 2025 at 8:09 AM Dmitry Baryshkov
> >> <dmitry.baryshkov@....qualcomm.com> wrote:
> >>>
> >>> On Sun, Jun 08, 2025 at 07:10:11AM -0700, Rob Clark wrote:
> >>>> On Sat, Jun 7, 2025 at 1:17 PM Dmitry Baryshkov
> >>>> <dmitry.baryshkov@....qualcomm.com> wrote:
> >>>>>
> >>>>> On Sat, Jun 07, 2025 at 07:45:01PM +0530, Akhil P Oommen wrote:
> >>>>>> X1P42100 SoC has a new GPU called Adreno X1-45 which is a smaller
> >>>>>> version of Adreno X1-85 GPU. Describe this new GPU and also add
> >>>>>> the secure gpu firmware path that should used for X1P42100 CRD.
> >>>>>>
> >>>>>> Signed-off-by: Akhil P Oommen <akhilpo@....qualcomm.com>
> >>>>>> ---
> >>>>>> arch/arm64/boot/dts/qcom/x1e80100.dtsi | 7 ++
> >>>>>> arch/arm64/boot/dts/qcom/x1p42100-crd.dts | 4 +
> >>>>>> arch/arm64/boot/dts/qcom/x1p42100.dtsi | 121 ++++++++++++++++
> >>>>>> +++++++++++++-
> >>>>>> 3 files changed, 131 insertions(+), 1 deletion(-)
> >>>>>>
> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/x1e80100.dtsi b/arch/arm64/
> >>>>>> boot/dts/qcom/x1e80100.dtsi
> >>>>>> index
> >>>>>> a8eb4c5fe99fe6dd49af200a738b6476d87279b2..558d7d387d7710770244fcc901f461384dd9b0d4 100644
> >>>>>> --- a/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> >>>>>> +++ b/arch/arm64/boot/dts/qcom/x1e80100.dtsi
> >>>>>> @@ -8245,6 +8245,13 @@ sbsa_watchdog: watchdog@...40000 {
> >>>>>> interrupts = <GIC_SPI 0 IRQ_TYPE_LEVEL_HIGH>;
> >>>>>> };
> >>>>>>
> >>>>>> + qfprom: efuse@...c8000 {
> >>>>>> + compatible = "qcom,x1e80100-qfprom",
> >>>>>> "qcom,qfprom";
> >>>>>> + reg = <0 0x221c8000 0 0x1000>;
> >>>>>> + #address-cells = <1>;
> >>>>>> + #size-cells = <1>;
> >>>>>> + };
> >>>>>> +
> >>>>>> pmu@...91000 {
> >>>>>> compatible = "qcom,x1e80100-llcc-bwmon",
> >>>>>> "qcom,sc7280-llcc-bwmon";
> >>>>>> reg = <0 0x24091000 0 0x1000>;
> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts b/arch/
> >>>>>> arm64/boot/dts/qcom/x1p42100-crd.dts
> >>>>>> index
> >>>>>> cf07860a63e97c388909fb5721ae7b9729b6c586..cf999c2cf8d4e0af83078253fd39ece3a0c26a49 100644
> >>>>>> --- a/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> >>>>>> +++ b/arch/arm64/boot/dts/qcom/x1p42100-crd.dts
> >>>>>> @@ -15,3 +15,7 @@ / {
> >>>>>> model = "Qualcomm Technologies, Inc. X1P42100 CRD";
> >>>>>> compatible = "qcom,x1p42100-crd", "qcom,x1p42100";
> >>>>>> };
> >>>>>> +
> >>>>>> +&gpu_zap_shader {
> >>>>>> + firmware-name = "qcom/x1p42100/gen71500_zap.mbn";
> >>>>>> +};
> >>>>>> diff --git a/arch/arm64/boot/dts/qcom/x1p42100.dtsi b/arch/arm64/
> >>>>>> boot/dts/qcom/x1p42100.dtsi
> >>>>>> index
> >>>>>> 27f479010bc330eb6445269a1c46bf78ec6f1bd4..5ed461ed5cca271d43647888aa6eacac3de2ac9d 100644
> >>>>>> --- a/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> >>>>>> +++ b/arch/arm64/boot/dts/qcom/x1p42100.dtsi
> >>>>>> @@ -17,15 +17,134 @@
> >>>>>> /delete-node/ &cpu_pd9;
> >>>>>> /delete-node/ &cpu_pd10;
> >>>>>> /delete-node/ &cpu_pd11;
> >>>>>> +/delete-node/ &gpu_opp_table;
> >>>>>> /delete-node/ &pcie3_phy;
> >>>>>>
> >>>>>> &gcc {
> >>>>>> compatible = "qcom,x1p42100-gcc", "qcom,x1e80100-gcc";
> >>>>>> };
> >>>>>>
> >>>>>> -/* The GPU is physically different and will be brought up later */
> >>>>>> +&gmu {
> >>>>>> + /delete-property/ compatible;
> >>>>>> + compatible = "qcom,adreno-gmu-x145.0", "qcom,adreno-gmu";
> >>>>>> +};
> >>>>>> +
> >>>>>> +&qfprom {
> >>>>>> + gpu_speed_bin: gpu_speed_bin@119 {
> >>>>>> + reg = <0x119 0x2>;
> >>>>>> + bits = <7 9>;
> >>>>>> + };
> >>>>>> +};
> >>>>>> +
> >>>>>> &gpu {
> >>>>>> /delete-property/ compatible;
> >>>>>
> >>>>> I think, you can drop this line.
>
> I wasn't sure about this and I thought it was harmless to delete it.
> Anyway, I will remove the "delete" from both GPU and GMU nodes.
You can always run fdtdump on the compiled file and check the contents.
>
> >>>>>
> >>>>>> +
> >>>>>> + compatible = "qcom,adreno-43030c00", "qcom,adreno";
> >>>>>> +
> >>>>>> + nvmem-cells = <&gpu_speed_bin>;
> >>>>>> + nvmem-cell-names = "speed_bin";
> >>>>>> +
> >>>>>> + gpu_opp_table: opp-table {
> >>>>>> + compatible = "operating-points-v2-adreno",
> >>>>>> "operating-points-v2";
> >>>>>> +
> >>>>>> + opp-1400000000 {
> >>>>>> + opp-hz = /bits/ 64 <1400000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L4>;
> >>>>>> + opp-peak-kBps = <16500000>;
> >>>>>> + qcom,opp-acd-level = <0xa8295ffd>;
> >>>>>> + opp-supported-hw = <0x3>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-1250000000 {
> >>>>>> + opp-hz = /bits/ 64 <1250000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L3>;
> >>>>>> + opp-peak-kBps = <16500000>;
> >>>>>> + qcom,opp-acd-level = <0x882a5ffd>;
> >>>>>> + opp-supported-hw = <0x7>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-1107000000 {
> >>>>>> + opp-hz = /bits/ 64 <1107000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_TURBO_L1>;
> >>>>>> + opp-peak-kBps = <16500000>;
> >>>>>> + qcom,opp-acd-level = <0x882a5ffd>;
> >>>>>> + opp-supported-hw = <0xf>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-1014000000 {
> >>>>>> + opp-hz = /bits/ 64 <1014000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_TURBO>;
> >>>>>> + opp-peak-kBps = <14398438>;
> >>>>>> + qcom,opp-acd-level = <0xa82a5ffd>;
> >>>>>> + opp-supported-hw = <0xf>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-940000000 {
> >>>>>> + opp-hz = /bits/ 64 <940000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_NOM_L1>;
> >>>>>> + opp-peak-kBps = <14398438>;
> >>>>>> + qcom,opp-acd-level = <0xa82a5ffd>;
> >>>>>> + opp-supported-hw = <0xf>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-825000000 {
> >>>>>> + opp-hz = /bits/ 64 <825000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_NOM>;
> >>>>>> + opp-peak-kBps = <12449219>;
> >>>>>> + qcom,opp-acd-level = <0x882b5ffd>;
> >>>>>> + opp-supported-hw = <0xf>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-720000000 {
> >>>>>> + opp-hz = /bits/ 64 <720000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L2>;
> >>>>>> + opp-peak-kBps = <10687500>;
> >>>>>> + qcom,opp-acd-level = <0xa82c5ffd>;
> >>>>>> + opp-supported-hw = <0xf>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + opp-666000000-0 {
> >>>>>> + opp-hz = /bits/ 64 <666000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
> >>>>>> + opp-peak-kBps = <8171875>;
> >>>>>> + qcom,opp-acd-level = <0xa82d5ffd>;
> >>>>>> + opp-supported-hw = <0xf>;
> >>>>>> + };
> >>>>>> +
> >>>>>> + /* Only applicable for SKUs which has 666Mhz as Fmax */
> >>>>>> + opp-666000000-1 {
> >>>>>> + opp-hz = /bits/ 64 <666000000>;
> >>>>>> + opp-level = <RPMH_REGULATOR_LEVEL_SVS_L1>;
> >>>>>> + opp-peak-kBps = <16500000>;
> >>>>>
> >>>>> This looks odd, why is it so high?
> >>>>
> >>>> You want max bandwidth on max opp
> >>>
> >>> Yes, but can it actually sustain / provide this BW?
> >>>
> >>
> >> I'd have to trust Akhil on that one, but I have no reason to believe
> >> otherwise. Just pointing out we've done analogous things elsewhere
> >> (for ex, cpu bw for sc7180-lite.dtsi)
>
> Window's GPU KMD seems to vote Max bandwidth for this SKU, so I think
> this is fine. Our GPUs from last few generations can easily saturate DDR
> with the right usecase.
Ack
--
With best wishes
Dmitry
Powered by blists - more mailing lists