From: Jie Zhang <quic_jiezh@quicinc.com>
Add gpu and rgmu nodes for qcs615 chipset.
Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
---
arch/arm64/boot/dts/qcom/talos.dtsi | 116 ++++++++++++++++++++++++++++++++++++
1 file changed, 116 insertions(+)
diff --git a/arch/arm64/boot/dts/qcom/talos.dtsi b/arch/arm64/boot/dts/qcom/talos.dtsi
index 743c840e496d..12d6b296b562 100644
--- a/arch/arm64/boot/dts/qcom/talos.dtsi
+++ b/arch/arm64/boot/dts/qcom/talos.dtsi
@@ -647,6 +647,11 @@ rproc_adsp_mem: rproc-adsp@95900000 {
reg = <0x0 0x95900000 0x0 0x1e00000>;
no-map;
};
+
+ pil_gpu_mem: pil-gpu@97715000 {
+ reg = <0x0 0x97715000 0x0 0x2000>;
+ no-map;
+ };
};
soc: soc@0 {
@@ -1826,6 +1831,117 @@ data-pins {
};
};
+ gpu: gpu@5000000 {
+ compatible = "qcom,adreno-612.0", "qcom,adreno";
+ reg = <0x0 0x05000000 0x0 0x90000>,
+ <0x0 0x0509e000 0x0 0x1000>,
+ <0x0 0x05061000 0x0 0x800>;
+ reg-names = "kgsl_3d0_reg_memory",
+ "cx_mem",
+ "cx_dbgc";
+
+ clocks = <&gpucc GPU_CC_GX_GFX3D_CLK>;
+ clock-names = "core";
+
+ interrupts = <GIC_SPI 300 IRQ_TYPE_LEVEL_HIGH>;
+
+ interconnects = <&gem_noc MASTER_GFX3D QCOM_ICC_TAG_ALWAYS
+ &mc_virt SLAVE_EBI1 QCOM_ICC_TAG_ALWAYS>;
+ interconnect-names = "gfx-mem";
+
+ iommus = <&adreno_smmu 0x0 0x401>;
+
+ operating-points-v2 = <&gpu_opp_table>;
+ power-domains = <&rpmhpd RPMHPD_CX>;
+
+ qcom,gmu = <&gmu>;
+
+ #cooling-cells = <2>;
+
+ status = "disabled";
+
+ gpu_zap_shader: zap-shader {
+ memory-region = <&pil_gpu_mem>;
+ };
+
+ gpu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-845000000 {
+ opp-hz = /bits/ 64 <845000000>;
+ required-opps = <&rpmhpd_opp_turbo>;
+ opp-peak-kBps = <7050000>;
+ };
+
+ opp-745000000 {
+ opp-hz = /bits/ 64 <745000000>;
+ required-opps = <&rpmhpd_opp_nom_l1>;
+ opp-peak-kBps = <6075000>;
+ };
+
+ opp-650000000 {
+ opp-hz = /bits/ 64 <650000000>;
+ required-opps = <&rpmhpd_opp_nom>;
+ opp-peak-kBps = <5287500>;
+ };
+
+ opp-500000000 {
+ opp-hz = /bits/ 64 <500000000>;
+ required-opps = <&rpmhpd_opp_svs_l1>;
+ opp-peak-kBps = <3975000>;
+ };
+
+ opp-435000000 {
+ opp-hz = /bits/ 64 <435000000>;
+ required-opps = <&rpmhpd_opp_svs>;
+ opp-peak-kBps = <3000000>;
+ };
+
+ opp-290000000 {
+ opp-hz = /bits/ 64 <290000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ opp-peak-kBps = <1762500>;
+ };
+ };
+ };
+
+ gmu: gmu@506a000 {
+ compatible = "qcom,adreno-rgmu-612.0", "qcom,adreno-rgmu";
+ reg = <0x0 0x0506a000 0x0 0x34000>;
+
+ clocks = <&gpucc GPU_CC_CX_GMU_CLK>,
+ <&gpucc GPU_CC_CXO_CLK>,
+ <&gcc GCC_DDRSS_GPU_AXI_CLK>,
+ <&gcc GCC_GPU_MEMNOC_GFX_CLK>,
+ <&gpucc GPU_CC_HLOS1_VOTE_GPU_SMMU_CLK>;
+ clock-names = "gmu",
+ "cxo",
+ "axi",
+ "memnoc",
+ "smmu_vote";
+
+ power-domains = <&gpucc CX_GDSC>,
+ <&gpucc GX_GDSC>;
+ power-domain-names = "cx",
+ "gx";
+
+ interrupts = <GIC_SPI 304 IRQ_TYPE_LEVEL_HIGH>,
+ <GIC_SPI 305 IRQ_TYPE_LEVEL_HIGH>;
+ interrupt-names = "oob",
+ "gmu";
+
+ operating-points-v2 = <&gmu_opp_table>;
+
+ gmu_opp_table: opp-table {
+ compatible = "operating-points-v2";
+
+ opp-200000000 {
+ opp-hz = /bits/ 64 <200000000>;
+ required-opps = <&rpmhpd_opp_low_svs>;
+ };
+ };
+ };
+
gpucc: clock-controller@5090000 {
compatible = "qcom,qcs615-gpucc";
reg = <0 0x05090000 0 0x9000>;
--
2.51.0On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> From: Jie Zhang <quic_jiezh@quicinc.com>
>
> Add gpu and rgmu nodes for qcs615 chipset.
>
> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> ---
[...]
> + gpu_opp_table: opp-table {
> + compatible = "operating-points-v2";
> +
> + opp-845000000 {
> + opp-hz = /bits/ 64 <845000000>;
> + required-opps = <&rpmhpd_opp_turbo>;
> + opp-peak-kBps = <7050000>;
> + };
I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
or mobile parts specifically?
[...]
> +
> + opp-745000000 {
> + opp-hz = /bits/ 64 <745000000>;
> + required-opps = <&rpmhpd_opp_nom_l1>;
> + opp-peak-kBps = <6075000>;
> + };
> +
> + opp-650000000 {
> + opp-hz = /bits/ 64 <650000000>;
> + required-opps = <&rpmhpd_opp_nom>;
> + opp-peak-kBps = <5287500>;
> + };
Here the freq map says 700 MHz
> + opp-500000000 {
> + opp-hz = /bits/ 64 <500000000>;
> + required-opps = <&rpmhpd_opp_svs_l1>;
> + opp-peak-kBps = <3975000>;
> + };
550
Konrad
On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> > From: Jie Zhang <quic_jiezh@quicinc.com>
> >
> > Add gpu and rgmu nodes for qcs615 chipset.
> >
> > Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> > Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> > ---
>
> [...]
>
> > + gpu_opp_table: opp-table {
> > + compatible = "operating-points-v2";
> > +
> > + opp-845000000 {
> > + opp-hz = /bits/ 64 <845000000>;
> > + required-opps = <&rpmhpd_opp_turbo>;
> > + opp-peak-kBps = <7050000>;
> > + };
>
> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> or mobile parts specifically?
msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
here.
>
> [...]
>
> > +
> > + opp-745000000 {
> > + opp-hz = /bits/ 64 <745000000>;
> > + required-opps = <&rpmhpd_opp_nom_l1>;
> > + opp-peak-kBps = <6075000>;
> > + };
> > +
> > + opp-650000000 {
> > + opp-hz = /bits/ 64 <650000000>;
> > + required-opps = <&rpmhpd_opp_nom>;
> > + opp-peak-kBps = <5287500>;
> > + };
>
> Here the freq map says 700 MHz
>
> > + opp-500000000 {
> > + opp-hz = /bits/ 64 <500000000>;
> > + required-opps = <&rpmhpd_opp_svs_l1>;
> > + opp-peak-kBps = <3975000>;
> > + };
>
> 550
>
> Konrad
--
With best wishes
Dmitry
On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>
>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>
>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>> ---
>>
>> [...]
>>
>>> + gpu_opp_table: opp-table {
>>> + compatible = "operating-points-v2";
>>> +
>>> + opp-845000000 {
>>> + opp-hz = /bits/ 64 <845000000>;
>>> + required-opps = <&rpmhpd_opp_turbo>;
>>> + opp-peak-kBps = <7050000>;
>>> + };
>>
>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>> or mobile parts specifically?
>
> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> here.
The IoT/Auto variants have a different frequency plan compared to the
mobile variant. I reviewed the downstream code and this aligns with that
except the 290Mhz corner. We can remove that one.
Here we are describing the IoT variant of Talos. So we can ignore the
speedbins from the mobile variant until that is supported.
-Akhil.
>
>>
>> [...]
>>
>>> +
>>> + opp-745000000 {
>>> + opp-hz = /bits/ 64 <745000000>;
>>> + required-opps = <&rpmhpd_opp_nom_l1>;
>>> + opp-peak-kBps = <6075000>;
>>> + };
>>> +
>>> + opp-650000000 {
>>> + opp-hz = /bits/ 64 <650000000>;
>>> + required-opps = <&rpmhpd_opp_nom>;
>>> + opp-peak-kBps = <5287500>;
>>> + };
>>
>> Here the freq map says 700 MHz
>>
>>> + opp-500000000 {
>>> + opp-hz = /bits/ 64 <500000000>;
>>> + required-opps = <&rpmhpd_opp_svs_l1>;
>>> + opp-peak-kBps = <3975000>;
>>> + };
>>
>> 550
>>
>> Konrad
>
On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> > On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>
> >>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>
> >>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>> ---
> >>
> >> [...]
> >>
> >>> + gpu_opp_table: opp-table {
> >>> + compatible = "operating-points-v2";
> >>> +
> >>> + opp-845000000 {
> >>> + opp-hz = /bits/ 64 <845000000>;
> >>> + required-opps = <&rpmhpd_opp_turbo>;
> >>> + opp-peak-kBps = <7050000>;
> >>> + };
> >>
> >> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >> or mobile parts specifically?
> >
> > msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> > here.
>
> The IoT/Auto variants have a different frequency plan compared to the
> mobile variant. I reviewed the downstream code and this aligns with that
> except the 290Mhz corner. We can remove that one.
>
> Here we are describing the IoT variant of Talos. So we can ignore the
> speedbins from the mobile variant until that is supported.
No, we are describing just Talos, which hopefully covers both mobile and
non-mobile platforms.
--
With best wishes
Dmitry
On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>
>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>
>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> + gpu_opp_table: opp-table {
>>>>> + compatible = "operating-points-v2";
>>>>> +
>>>>> + opp-845000000 {
>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>> + opp-peak-kBps = <7050000>;
>>>>> + };
>>>>
>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>> or mobile parts specifically?
>>>
>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>> here.
>>
>> The IoT/Auto variants have a different frequency plan compared to the
>> mobile variant. I reviewed the downstream code and this aligns with that
>> except the 290Mhz corner. We can remove that one.
>>
>> Here we are describing the IoT variant of Talos. So we can ignore the
>> speedbins from the mobile variant until that is supported.
>
> No, we are describing just Talos, which hopefully covers both mobile and
> non-mobile platforms.
We cannot assume that.
Even if we assume that there is no variation in silicon, the firmware
(AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
wise to use the configuration that is commercialized, especially when it
is power related.
-Akhil.
>
>
On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> > On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>
> >>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>
> >>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>> ---
> >>>>
> >>>> [...]
> >>>>
> >>>>> + gpu_opp_table: opp-table {
> >>>>> + compatible = "operating-points-v2";
> >>>>> +
> >>>>> + opp-845000000 {
> >>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>> + opp-peak-kBps = <7050000>;
> >>>>> + };
> >>>>
> >>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>> or mobile parts specifically?
> >>>
> >>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>> here.
> >>
> >> The IoT/Auto variants have a different frequency plan compared to the
> >> mobile variant. I reviewed the downstream code and this aligns with that
> >> except the 290Mhz corner. We can remove that one.
> >>
> >> Here we are describing the IoT variant of Talos. So we can ignore the
> >> speedbins from the mobile variant until that is supported.
> >
> > No, we are describing just Talos, which hopefully covers both mobile and
> > non-mobile platforms.
>
> We cannot assume that.
>
> Even if we assume that there is no variation in silicon, the firmware
> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> wise to use the configuration that is commercialized, especially when it
> is power related.
How does it affect the speed bins? I'd really prefer if we:
- describe OPP tables and speed bins here
- remove speed bins cell for the Auto / IoT boards
- make sure that the driver uses the IoT bin if there is no speed bin
declared in the GPU.
--
With best wishes
Dmitry
On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>
>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>
>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> + gpu_opp_table: opp-table {
>>>>>>> + compatible = "operating-points-v2";
>>>>>>> +
>>>>>>> + opp-845000000 {
>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>> + };
>>>>>>
>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>> or mobile parts specifically?
>>>>>
>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>> here.
>>>>
>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>> except the 290Mhz corner. We can remove that one.
>>>>
>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>> speedbins from the mobile variant until that is supported.
>>>
>>> No, we are describing just Talos, which hopefully covers both mobile and
>>> non-mobile platforms.
>>
>> We cannot assume that.
>>
>> Even if we assume that there is no variation in silicon, the firmware
>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>> wise to use the configuration that is commercialized, especially when it
>> is power related.
>
> How does it affect the speed bins? I'd really prefer if we:
> - describe OPP tables and speed bins here
> - remove speed bins cell for the Auto / IoT boards
> - make sure that the driver uses the IoT bin if there is no speed bin
> declared in the GPU.
>
The frequency plan is different between mobile and IoT. Are you
proposing to describe a union of OPP table from both mobile and IoT?
Another wrinkle we need to address is that, so far, we have never had a
dt binding where opp-supp-hw property exist without the speedbin cells.
And that adds a bit of complexity on the driver side because, today, the
KMD relies on the presence of speed bin cells to decide whether to
select bin via opp_supp_hw API or not. Also, we may have to reserve this
combination (opp bins without speedbin cells) to help KMD detect that it
should use socinfo APIs instead of speedbin cells on certain chipsets.
-Akhil
On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> > On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> >> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> >>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>
> >>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>>>
> >>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>>>> ---
> >>>>>>
> >>>>>> [...]
> >>>>>>
> >>>>>>> + gpu_opp_table: opp-table {
> >>>>>>> + compatible = "operating-points-v2";
> >>>>>>> +
> >>>>>>> + opp-845000000 {
> >>>>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>>>> + opp-peak-kBps = <7050000>;
> >>>>>>> + };
> >>>>>>
> >>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>>>> or mobile parts specifically?
> >>>>>
> >>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>>>> here.
> >>>>
> >>>> The IoT/Auto variants have a different frequency plan compared to the
> >>>> mobile variant. I reviewed the downstream code and this aligns with that
> >>>> except the 290Mhz corner. We can remove that one.
> >>>>
> >>>> Here we are describing the IoT variant of Talos. So we can ignore the
> >>>> speedbins from the mobile variant until that is supported.
> >>>
> >>> No, we are describing just Talos, which hopefully covers both mobile and
> >>> non-mobile platforms.
> >>
> >> We cannot assume that.
> >>
> >> Even if we assume that there is no variation in silicon, the firmware
> >> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> >> wise to use the configuration that is commercialized, especially when it
> >> is power related.
> >
> > How does it affect the speed bins? I'd really prefer if we:
> > - describe OPP tables and speed bins here
> > - remove speed bins cell for the Auto / IoT boards
> > - make sure that the driver uses the IoT bin if there is no speed bin
> > declared in the GPU.
> >
>
> The frequency plan is different between mobile and IoT. Are you
> proposing to describe a union of OPP table from both mobile and IoT?
Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
has speed bins. How comes we don't have bins for the IoT variant?
Mobile bins: 0, 177, 187, 156, 136, 105, 73
Auto bins: 0, 177, 156, 136, 105, 73
Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
starting from bit 21).
Mobile freqs:
0: 845M, 745M, 700M, 550M, 435M, 290M
177: 845M, 745M, 700M, 550M, 435M, 290M
187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
156: 745M, 700M, 550M, 435M, 290M
136: 650M, 550M, 435M, 290M
105: 500M, 435M, 290M
73: 350M, 290M
Auto freqs:
0: 845M, 745M, 650M, 500M, 435M
177: 845M, 745M, 650M, 500M, 435M
156: 745M, 650M, 500M, 435M
136: 650M, 500M, 435M
105: 500M, 435M
73: 350M
290M was a part of the freq table, but later it was removed as "not
required", so probably it can be brought back, but I'm not sure how to
handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
I'm a bit persistent here because I really want to avoid the situation
where we define a bin-less OPP table and later we face binned QCS615
chips (which is possible since both SM and SA were binned).
Also I don't see separate QFPROM memory map definitions for Mobile, IoT
and Auto SKUs. If you have access to the QCS615 hardware, what is the
value written in that fuse area?
> Another wrinkle we need to address is that, so far, we have never had a
> dt binding where opp-supp-hw property exist without the speedbin cells.
> And that adds a bit of complexity on the driver side because, today, the
> KMD relies on the presence of speed bin cells to decide whether to
> select bin via opp_supp_hw API or not. Also, we may have to reserve this
> combination (opp bins without speedbin cells) to help KMD detect that it
> should use socinfo APIs instead of speedbin cells on certain chipsets.
We already have "machine" as another axis in the GPU catalog. I'd
suggest defining separate speed bins for mobile and auto/IoT in the DT
(0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
mapping those by the machine compat.
--
With best wishes
Dmitry
On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>
>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>>
>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>>> ---
>>>>>>>>
>>>>>>>> [...]
>>>>>>>>
>>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>>> +
>>>>>>>>> + opp-845000000 {
>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>>> + };
>>>>>>>>
>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>>> or mobile parts specifically?
>>>>>>>
>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>>> here.
>>>>>>
>>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>>> except the 290Mhz corner. We can remove that one.
>>>>>>
>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>>> speedbins from the mobile variant until that is supported.
>>>>>
>>>>> No, we are describing just Talos, which hopefully covers both mobile and
>>>>> non-mobile platforms.
>>>>
>>>> We cannot assume that.
>>>>
>>>> Even if we assume that there is no variation in silicon, the firmware
>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>>>> wise to use the configuration that is commercialized, especially when it
>>>> is power related.
>>>
>>> How does it affect the speed bins? I'd really prefer if we:
>>> - describe OPP tables and speed bins here
>>> - remove speed bins cell for the Auto / IoT boards
>>> - make sure that the driver uses the IoT bin if there is no speed bin
>>> declared in the GPU.
>>>
>>
>> The frequency plan is different between mobile and IoT. Are you
>> proposing to describe a union of OPP table from both mobile and IoT?
>
> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
> has speed bins. How comes we don't have bins for the IoT variant?
>
> Mobile bins: 0, 177, 187, 156, 136, 105, 73
> Auto bins: 0, 177, 156, 136, 105, 73
>
> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
> starting from bit 21).
>
> Mobile freqs:
> 0: 845M, 745M, 700M, 550M, 435M, 290M
> 177: 845M, 745M, 700M, 550M, 435M, 290M
> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
> 156: 745M, 700M, 550M, 435M, 290M
> 136: 650M, 550M, 435M, 290M
> 105: 500M, 435M, 290M
> 73: 350M, 290M
>
> Auto freqs:
> 0: 845M, 745M, 650M, 500M, 435M
> 177: 845M, 745M, 650M, 500M, 435M
> 156: 745M, 650M, 500M, 435M
> 136: 650M, 500M, 435M
> 105: 500M, 435M
> 73: 350M
>
> 290M was a part of the freq table, but later it was removed as "not
> required", so probably it can be brought back, but I'm not sure how to
> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
>
> I'm a bit persistent here because I really want to avoid the situation
> where we define a bin-less OPP table and later we face binned QCS615
> chips (which is possible since both SM and SA were binned).
Why is that a problem as long as KMD can handle it without breaking
backward compatibility?
>
> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
> and Auto SKUs. If you have access to the QCS615 hardware, what is the
> value written in that fuse area?
>
>> Another wrinkle we need to address is that, so far, we have never had a
>> dt binding where opp-supp-hw property exist without the speedbin cells.
>> And that adds a bit of complexity on the driver side because, today, the
>> KMD relies on the presence of speed bin cells to decide whether to
>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
>> combination (opp bins without speedbin cells) to help KMD detect that it
>> should use socinfo APIs instead of speedbin cells on certain chipsets.
If it is a soft fuse, it could fall into an unused region in qfprom. On
other IoT chipsets like Lemans, Product teams preferred a soft fuse
instead of the hard fuse. The downside of the hard fuse that it should
be blown from factory and not flexible to update from software later in
the program.
-Akhil.
>
> We already have "machine" as another axis in the GPU catalog. I'd
> suggest defining separate speed bins for mobile and auto/IoT in the DT
> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
> mapping those by the machine compat.
>
On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>
>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>>>
>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>>>> ---
>>>>>>>>>
>>>>>>>>> [...]
>>>>>>>>>
>>>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>>>> +
>>>>>>>>>> + opp-845000000 {
>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>>>> + };
>>>>>>>>>
>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>>>> or mobile parts specifically?
>>>>>>>>
>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>>>> here.
>>>>>>>
>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>>>> except the 290Mhz corner. We can remove that one.
>>>>>>>
>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>>>> speedbins from the mobile variant until that is supported.
>>>>>>
>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
>>>>>> non-mobile platforms.
>>>>>
>>>>> We cannot assume that.
>>>>>
>>>>> Even if we assume that there is no variation in silicon, the firmware
>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>>>>> wise to use the configuration that is commercialized, especially when it
>>>>> is power related.
>>>>
>>>> How does it affect the speed bins? I'd really prefer if we:
>>>> - describe OPP tables and speed bins here
>>>> - remove speed bins cell for the Auto / IoT boards
>>>> - make sure that the driver uses the IoT bin if there is no speed bin
>>>> declared in the GPU.
>>>>
>>>
>>> The frequency plan is different between mobile and IoT. Are you
>>> proposing to describe a union of OPP table from both mobile and IoT?
>>
>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
>> has speed bins. How comes we don't have bins for the IoT variant?
>>
>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
>> Auto bins: 0, 177, 156, 136, 105, 73
>>
>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
>> starting from bit 21).
>>
>> Mobile freqs:
>> 0: 845M, 745M, 700M, 550M, 435M, 290M
>> 177: 845M, 745M, 700M, 550M, 435M, 290M
>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
>> 156: 745M, 700M, 550M, 435M, 290M
>> 136: 650M, 550M, 435M, 290M
>> 105: 500M, 435M, 290M
>> 73: 350M, 290M
>>
>> Auto freqs:
>> 0: 845M, 745M, 650M, 500M, 435M
>> 177: 845M, 745M, 650M, 500M, 435M
>> 156: 745M, 650M, 500M, 435M
>> 136: 650M, 500M, 435M
>> 105: 500M, 435M
>> 73: 350M
>>
>> 290M was a part of the freq table, but later it was removed as "not
>> required", so probably it can be brought back, but I'm not sure how to
>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
>>
>> I'm a bit persistent here because I really want to avoid the situation
>> where we define a bin-less OPP table and later we face binned QCS615
>> chips (which is possible since both SM and SA were binned).
>
> Why is that a problem as long as KMD can handle it without breaking
> backward compatibility?
I replied too soon. I see your point. Can't we keep separate OPP tables
when that happen? That is neat-er than complicating the driver, isn't it?
>
>>
>> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
>> and Auto SKUs. If you have access to the QCS615 hardware, what is the
>> value written in that fuse area?
>>
>>> Another wrinkle we need to address is that, so far, we have never had a
>>> dt binding where opp-supp-hw property exist without the speedbin cells.
>>> And that adds a bit of complexity on the driver side because, today, the
>>> KMD relies on the presence of speed bin cells to decide whether to
>>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
>>> combination (opp bins without speedbin cells) to help KMD detect that it
>>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
> If it is a soft fuse, it could fall into an unused region in qfprom. On
> other IoT chipsets like Lemans, Product teams preferred a soft fuse
> instead of the hard fuse. The downside of the hard fuse that it should
> be blown from factory and not flexible to update from software later in
> the program.
This response is for your comment above. Adding to that, the value for
the hard fuse is mostly likely to be '0' (unfused), but all internal
parts are always unfused. Maybe it is 'practically' harmless to use the
freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
mobile, Auto and IoT. I am not sure.
I am trying to play safe here as this is dt. We don't want to configure
the wrong thing now and later struggle to correct it. It is safe to
defer things which we don't know.
-Akhil.
>
> -Akhil.
>
>>
>> We already have "machine" as another axis in the GPU catalog. I'd
>> suggest defining separate speed bins for mobile and auto/IoT in the DT
>> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
>> mapping those by the machine compat.
>>
>
On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
> > On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
> >> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
> >>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> >>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> >>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> >>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>
> >>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>>>>>>
> >>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>>>>>>> ---
> >>>>>>>>>
> >>>>>>>>> [...]
> >>>>>>>>>
> >>>>>>>>>> + gpu_opp_table: opp-table {
> >>>>>>>>>> + compatible = "operating-points-v2";
> >>>>>>>>>> +
> >>>>>>>>>> + opp-845000000 {
> >>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>>>>>>> + opp-peak-kBps = <7050000>;
> >>>>>>>>>> + };
> >>>>>>>>>
> >>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>>>>>>> or mobile parts specifically?
> >>>>>>>>
> >>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>>>>>>> here.
> >>>>>>>
> >>>>>>> The IoT/Auto variants have a different frequency plan compared to the
> >>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
> >>>>>>> except the 290Mhz corner. We can remove that one.
> >>>>>>>
> >>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
> >>>>>>> speedbins from the mobile variant until that is supported.
> >>>>>>
> >>>>>> No, we are describing just Talos, which hopefully covers both mobile and
> >>>>>> non-mobile platforms.
> >>>>>
> >>>>> We cannot assume that.
> >>>>>
> >>>>> Even if we assume that there is no variation in silicon, the firmware
> >>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> >>>>> wise to use the configuration that is commercialized, especially when it
> >>>>> is power related.
> >>>>
> >>>> How does it affect the speed bins? I'd really prefer if we:
> >>>> - describe OPP tables and speed bins here
> >>>> - remove speed bins cell for the Auto / IoT boards
> >>>> - make sure that the driver uses the IoT bin if there is no speed bin
> >>>> declared in the GPU.
> >>>>
> >>>
> >>> The frequency plan is different between mobile and IoT. Are you
> >>> proposing to describe a union of OPP table from both mobile and IoT?
> >>
> >> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
> >> has speed bins. How comes we don't have bins for the IoT variant?
> >>
> >> Mobile bins: 0, 177, 187, 156, 136, 105, 73
> >> Auto bins: 0, 177, 156, 136, 105, 73
> >>
> >> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
> >> starting from bit 21).
> >>
> >> Mobile freqs:
> >> 0: 845M, 745M, 700M, 550M, 435M, 290M
> >> 177: 845M, 745M, 700M, 550M, 435M, 290M
> >> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
> >> 156: 745M, 700M, 550M, 435M, 290M
> >> 136: 650M, 550M, 435M, 290M
> >> 105: 500M, 435M, 290M
> >> 73: 350M, 290M
> >>
> >> Auto freqs:
> >> 0: 845M, 745M, 650M, 500M, 435M
> >> 177: 845M, 745M, 650M, 500M, 435M
> >> 156: 745M, 650M, 500M, 435M
> >> 136: 650M, 500M, 435M
> >> 105: 500M, 435M
> >> 73: 350M
> >>
> >> 290M was a part of the freq table, but later it was removed as "not
> >> required", so probably it can be brought back, but I'm not sure how to
> >> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
> >>
> >> I'm a bit persistent here because I really want to avoid the situation
> >> where we define a bin-less OPP table and later we face binned QCS615
> >> chips (which is possible since both SM and SA were binned).
> >
> > Why is that a problem as long as KMD can handle it without breaking
> > backward compatibility?
>
> I replied too soon. I see your point. Can't we keep separate OPP tables
> when that happen? That is neat-er than complicating the driver, isn't it?
I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
as a max freq without speed bins. Later some of the chips shipped in
IQ-615 are characterized as not belonging to bin 0 / not supporting 845
MHz. The users end up overclocking those chips, because the DTB doesn't
make any difference.
>
> >
> >>
> >> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
> >> and Auto SKUs. If you have access to the QCS615 hardware, what is the
> >> value written in that fuse area?
> >>
> >>> Another wrinkle we need to address is that, so far, we have never had a
> >>> dt binding where opp-supp-hw property exist without the speedbin cells.
> >>> And that adds a bit of complexity on the driver side because, today, the
> >>> KMD relies on the presence of speed bin cells to decide whether to
> >>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
> >>> combination (opp bins without speedbin cells) to help KMD detect that it
> >>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
>
> > If it is a soft fuse, it could fall into an unused region in qfprom. On
> > other IoT chipsets like Lemans, Product teams preferred a soft fuse
> > instead of the hard fuse. The downside of the hard fuse that it should
> > be blown from factory and not flexible to update from software later in
> > the program.
>
> This response is for your comment above. Adding to that, the value for
> the hard fuse is mostly likely to be '0' (unfused), but all internal
> parts are always unfused. Maybe it is 'practically' harmless to use the
> freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
> mobile, Auto and IoT. I am not sure.
>
> I am trying to play safe here as this is dt. We don't want to configure
> the wrong thing now and later struggle to correct it. It is safe to
> defer things which we don't know.
What is "soft fuse"? Why do we need an extra entity in addition to the
one that was defined for auto / mobile units?
>
> -Akhil.
>
> >
> > -Akhil.
> >
> >>
> >> We already have "machine" as another axis in the GPU catalog. I'd
> >> suggest defining separate speed bins for mobile and auto/IoT in the DT
> >> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
> >> mapping those by the machine compat.
> >>
> >
>
--
With best wishes
Dmitry
On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>
>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>>>>>
>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>>>>>> ---
>>>>>>>>>>>
>>>>>>>>>>> [...]
>>>>>>>>>>>
>>>>>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>>>>>> +
>>>>>>>>>>>> + opp-845000000 {
>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>>>>>> + };
>>>>>>>>>>>
>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>>>>>> or mobile parts specifically?
>>>>>>>>>>
>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>>>>>> here.
>>>>>>>>>
>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>>>>>> except the 290Mhz corner. We can remove that one.
>>>>>>>>>
>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>>>>>> speedbins from the mobile variant until that is supported.
>>>>>>>>
>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
>>>>>>>> non-mobile platforms.
>>>>>>>
>>>>>>> We cannot assume that.
>>>>>>>
>>>>>>> Even if we assume that there is no variation in silicon, the firmware
>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>>>>>>> wise to use the configuration that is commercialized, especially when it
>>>>>>> is power related.
>>>>>>
>>>>>> How does it affect the speed bins? I'd really prefer if we:
>>>>>> - describe OPP tables and speed bins here
>>>>>> - remove speed bins cell for the Auto / IoT boards
>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
>>>>>> declared in the GPU.
>>>>>>
>>>>>
>>>>> The frequency plan is different between mobile and IoT. Are you
>>>>> proposing to describe a union of OPP table from both mobile and IoT?
>>>>
>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
>>>> has speed bins. How comes we don't have bins for the IoT variant?
>>>>
>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
>>>> Auto bins: 0, 177, 156, 136, 105, 73
>>>>
>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
>>>> starting from bit 21).
>>>>
>>>> Mobile freqs:
>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
>>>> 156: 745M, 700M, 550M, 435M, 290M
>>>> 136: 650M, 550M, 435M, 290M
>>>> 105: 500M, 435M, 290M
>>>> 73: 350M, 290M
>>>>
>>>> Auto freqs:
>>>> 0: 845M, 745M, 650M, 500M, 435M
>>>> 177: 845M, 745M, 650M, 500M, 435M
>>>> 156: 745M, 650M, 500M, 435M
>>>> 136: 650M, 500M, 435M
>>>> 105: 500M, 435M
>>>> 73: 350M
>>>>
>>>> 290M was a part of the freq table, but later it was removed as "not
>>>> required", so probably it can be brought back, but I'm not sure how to
>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
>>>>
>>>> I'm a bit persistent here because I really want to avoid the situation
>>>> where we define a bin-less OPP table and later we face binned QCS615
>>>> chips (which is possible since both SM and SA were binned).
>>>
>>> Why is that a problem as long as KMD can handle it without breaking
>>> backward compatibility?
>>
>> I replied too soon. I see your point. Can't we keep separate OPP tables
>> when that happen? That is neat-er than complicating the driver, isn't it?
>
> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
> as a max freq without speed bins. Later some of the chips shipped in
> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
> MHz. The users end up overclocking those chips, because the DTB doesn't
> make any difference.
That is unlikely, because the characterization and other similiar
activities are completed and finalized before ramp up at foundries.
Nobody likes to RMA tons of chipsets.
Anyway, this hypothetical scenarios is a problem even when we use the
hard fuse.
>
>>
>>>
>>>>
>>>> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
>>>> and Auto SKUs. If you have access to the QCS615 hardware, what is the
>>>> value written in that fuse area?
>>>>
>>>>> Another wrinkle we need to address is that, so far, we have never had a
>>>>> dt binding where opp-supp-hw property exist without the speedbin cells.
>>>>> And that adds a bit of complexity on the driver side because, today, the
>>>>> KMD relies on the presence of speed bin cells to decide whether to
>>>>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
>>>>> combination (opp bins without speedbin cells) to help KMD detect that it
>>>>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
>>
>>> If it is a soft fuse, it could fall into an unused region in qfprom. On
>>> other IoT chipsets like Lemans, Product teams preferred a soft fuse
>>> instead of the hard fuse. The downside of the hard fuse that it should
>>> be blown from factory and not flexible to update from software later in
>>> the program.
>>
>> This response is for your comment above. Adding to that, the value for
>> the hard fuse is mostly likely to be '0' (unfused), but all internal
>> parts are always unfused. Maybe it is 'practically' harmless to use the
>> freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
>> mobile, Auto and IoT. I am not sure.
>>
>> I am trying to play safe here as this is dt. We don't want to configure
>> the wrong thing now and later struggle to correct it. It is safe to
>> defer things which we don't know.
>
> What is "soft fuse"? Why do we need an extra entity in addition to the
> one that was defined for auto / mobile units?
The hard fuse (freq limiter one) has to be blown at a very early stage
in the chip manufacturing. Instead of that, a soft fuse region which is
updated by the firmware during the cold boot is used to provide a hint
to KMD about the supported GPU fmax. I was told that this provides
better operational flexibility to the Product team.
-Akhil
>
>>
>> -Akhil.
>>
>>>
>>> -Akhil.
>>>
>>>>
>>>> We already have "machine" as another axis in the GPU catalog. I'd
>>>> suggest defining separate speed bins for mobile and auto/IoT in the DT
>>>> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
>>>> mapping those by the machine compat.
>>>>
>>>
>>
>
On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
> > On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
> >> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
> >>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
> >>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
> >>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> >>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> >>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> >>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>>>>>>>>> ---
> >>>>>>>>>>>
> >>>>>>>>>>> [...]
> >>>>>>>>>>>
> >>>>>>>>>>>> + gpu_opp_table: opp-table {
> >>>>>>>>>>>> + compatible = "operating-points-v2";
> >>>>>>>>>>>> +
> >>>>>>>>>>>> + opp-845000000 {
> >>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>>>>>>>>> + opp-peak-kBps = <7050000>;
> >>>>>>>>>>>> + };
> >>>>>>>>>>>
> >>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>>>>>>>>> or mobile parts specifically?
> >>>>>>>>>>
> >>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>>>>>>>>> here.
> >>>>>>>>>
> >>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
> >>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
> >>>>>>>>> except the 290Mhz corner. We can remove that one.
> >>>>>>>>>
> >>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
> >>>>>>>>> speedbins from the mobile variant until that is supported.
> >>>>>>>>
> >>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
> >>>>>>>> non-mobile platforms.
> >>>>>>>
> >>>>>>> We cannot assume that.
> >>>>>>>
> >>>>>>> Even if we assume that there is no variation in silicon, the firmware
> >>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> >>>>>>> wise to use the configuration that is commercialized, especially when it
> >>>>>>> is power related.
> >>>>>>
> >>>>>> How does it affect the speed bins? I'd really prefer if we:
> >>>>>> - describe OPP tables and speed bins here
> >>>>>> - remove speed bins cell for the Auto / IoT boards
> >>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
> >>>>>> declared in the GPU.
> >>>>>>
> >>>>>
> >>>>> The frequency plan is different between mobile and IoT. Are you
> >>>>> proposing to describe a union of OPP table from both mobile and IoT?
> >>>>
> >>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
> >>>> has speed bins. How comes we don't have bins for the IoT variant?
> >>>>
> >>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
> >>>> Auto bins: 0, 177, 156, 136, 105, 73
> >>>>
> >>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
> >>>> starting from bit 21).
> >>>>
> >>>> Mobile freqs:
> >>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
> >>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
> >>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
> >>>> 156: 745M, 700M, 550M, 435M, 290M
> >>>> 136: 650M, 550M, 435M, 290M
> >>>> 105: 500M, 435M, 290M
> >>>> 73: 350M, 290M
> >>>>
> >>>> Auto freqs:
> >>>> 0: 845M, 745M, 650M, 500M, 435M
> >>>> 177: 845M, 745M, 650M, 500M, 435M
> >>>> 156: 745M, 650M, 500M, 435M
> >>>> 136: 650M, 500M, 435M
> >>>> 105: 500M, 435M
> >>>> 73: 350M
> >>>>
> >>>> 290M was a part of the freq table, but later it was removed as "not
> >>>> required", so probably it can be brought back, but I'm not sure how to
> >>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
> >>>>
> >>>> I'm a bit persistent here because I really want to avoid the situation
> >>>> where we define a bin-less OPP table and later we face binned QCS615
> >>>> chips (which is possible since both SM and SA were binned).
> >>>
> >>> Why is that a problem as long as KMD can handle it without breaking
> >>> backward compatibility?
> >>
> >> I replied too soon. I see your point. Can't we keep separate OPP tables
> >> when that happen? That is neat-er than complicating the driver, isn't it?
> >
> > I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
> > as a max freq without speed bins. Later some of the chips shipped in
> > IQ-615 are characterized as not belonging to bin 0 / not supporting 845
> > MHz. The users end up overclocking those chips, because the DTB doesn't
> > make any difference.
>
> That is unlikely, because the characterization and other similiar
> activities are completed and finalized before ramp up at foundries.
> Nobody likes to RMA tons of chipsets.
>
> Anyway, this hypothetical scenarios is a problem even when we use the
> hard fuse.
So, are you promising that while there were several characterization
bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
to the max freq?
>
> >
> >>
> >>>
> >>>>
> >>>> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
> >>>> and Auto SKUs. If you have access to the QCS615 hardware, what is the
> >>>> value written in that fuse area?
> >>>>
> >>>>> Another wrinkle we need to address is that, so far, we have never had a
> >>>>> dt binding where opp-supp-hw property exist without the speedbin cells.
> >>>>> And that adds a bit of complexity on the driver side because, today, the
> >>>>> KMD relies on the presence of speed bin cells to decide whether to
> >>>>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
> >>>>> combination (opp bins without speedbin cells) to help KMD detect that it
> >>>>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
> >>
> >>> If it is a soft fuse, it could fall into an unused region in qfprom. On
> >>> other IoT chipsets like Lemans, Product teams preferred a soft fuse
> >>> instead of the hard fuse. The downside of the hard fuse that it should
> >>> be blown from factory and not flexible to update from software later in
> >>> the program.
> >>
> >> This response is for your comment above. Adding to that, the value for
> >> the hard fuse is mostly likely to be '0' (unfused), but all internal
> >> parts are always unfused. Maybe it is 'practically' harmless to use the
> >> freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
> >> mobile, Auto and IoT. I am not sure.
> >>
> >> I am trying to play safe here as this is dt. We don't want to configure
> >> the wrong thing now and later struggle to correct it. It is safe to
> >> defer things which we don't know.
> >
> > What is "soft fuse"? Why do we need an extra entity in addition to the
> > one that was defined for auto / mobile units?
>
> The hard fuse (freq limiter one) has to be blown at a very early stage
> in the chip manufacturing. Instead of that, a soft fuse region which is
> updated by the firmware during the cold boot is used to provide a hint
> to KMD about the supported GPU fmax. I was told that this provides
> better operational flexibility to the Product team.
Do you have an upstream example by chance?
>
> -Akhil
>
> >
> >>
> >> -Akhil.
> >>
> >>>
> >>> -Akhil.
> >>>
> >>>>
> >>>> We already have "machine" as another axis in the GPU catalog. I'd
> >>>> suggest defining separate speed bins for mobile and auto/IoT in the DT
> >>>> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
> >>>> mapping those by the machine compat.
> >>>>
> >>>
> >>
> >
>
>
--
With best wishes
Dmitry
On 12/13/2025 12:58 AM, Dmitry Baryshkov wrote:
> On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
>> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
>>> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
>>>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
>>>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
>>>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
>>>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>>>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>
>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>
>>>>>>>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>>>>>>>> +
>>>>>>>>>>>>>> + opp-845000000 {
>>>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>
>>>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>>>>>>>> or mobile parts specifically?
>>>>>>>>>>>>
>>>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>>>>>>>> here.
>>>>>>>>>>>
>>>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>>>>>>>> except the 290Mhz corner. We can remove that one.
>>>>>>>>>>>
>>>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>>>>>>>> speedbins from the mobile variant until that is supported.
>>>>>>>>>>
>>>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
>>>>>>>>>> non-mobile platforms.
>>>>>>>>>
>>>>>>>>> We cannot assume that.
>>>>>>>>>
>>>>>>>>> Even if we assume that there is no variation in silicon, the firmware
>>>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>>>>>>>>> wise to use the configuration that is commercialized, especially when it
>>>>>>>>> is power related.
>>>>>>>>
>>>>>>>> How does it affect the speed bins? I'd really prefer if we:
>>>>>>>> - describe OPP tables and speed bins here
>>>>>>>> - remove speed bins cell for the Auto / IoT boards
>>>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
>>>>>>>> declared in the GPU.
>>>>>>>>
>>>>>>>
>>>>>>> The frequency plan is different between mobile and IoT. Are you
>>>>>>> proposing to describe a union of OPP table from both mobile and IoT?
>>>>>>
>>>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
>>>>>> has speed bins. How comes we don't have bins for the IoT variant?
>>>>>>
>>>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
>>>>>> Auto bins: 0, 177, 156, 136, 105, 73
>>>>>>
>>>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
>>>>>> starting from bit 21).
>>>>>>
>>>>>> Mobile freqs:
>>>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
>>>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
>>>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
>>>>>> 156: 745M, 700M, 550M, 435M, 290M
>>>>>> 136: 650M, 550M, 435M, 290M
>>>>>> 105: 500M, 435M, 290M
>>>>>> 73: 350M, 290M
>>>>>>
>>>>>> Auto freqs:
>>>>>> 0: 845M, 745M, 650M, 500M, 435M
>>>>>> 177: 845M, 745M, 650M, 500M, 435M
>>>>>> 156: 745M, 650M, 500M, 435M
>>>>>> 136: 650M, 500M, 435M
>>>>>> 105: 500M, 435M
>>>>>> 73: 350M
>>>>>>
>>>>>> 290M was a part of the freq table, but later it was removed as "not
>>>>>> required", so probably it can be brought back, but I'm not sure how to
>>>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
>>>>>>
>>>>>> I'm a bit persistent here because I really want to avoid the situation
>>>>>> where we define a bin-less OPP table and later we face binned QCS615
>>>>>> chips (which is possible since both SM and SA were binned).
>>>>>
>>>>> Why is that a problem as long as KMD can handle it without breaking
>>>>> backward compatibility?
>>>>
>>>> I replied too soon. I see your point. Can't we keep separate OPP tables
>>>> when that happen? That is neat-er than complicating the driver, isn't it?
>>>
>>> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
>>> as a max freq without speed bins. Later some of the chips shipped in
>>> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
>>> MHz. The users end up overclocking those chips, because the DTB doesn't
>>> make any difference.
>>
>> That is unlikely, because the characterization and other similiar
>> activities are completed and finalized before ramp up at foundries.
>> Nobody likes to RMA tons of chipsets.
>>
>> Anyway, this hypothetical scenarios is a problem even when we use the
>> hard fuse.
>
> So, are you promising that while there were several characterization
> bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
> to the max freq?
I have cross checked with our Product team. I can confirm that for both
internal and external SKUs of Talos IoT currently, there is only a
single bin for GPU with Fmax 845Mhz.
>
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
>>>>>> and Auto SKUs. If you have access to the QCS615 hardware, what is the
>>>>>> value written in that fuse area?
>>>>>>
>>>>>>> Another wrinkle we need to address is that, so far, we have never had a
>>>>>>> dt binding where opp-supp-hw property exist without the speedbin cells.
>>>>>>> And that adds a bit of complexity on the driver side because, today, the
>>>>>>> KMD relies on the presence of speed bin cells to decide whether to
>>>>>>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
>>>>>>> combination (opp bins without speedbin cells) to help KMD detect that it
>>>>>>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
>>>>
>>>>> If it is a soft fuse, it could fall into an unused region in qfprom. On
>>>>> other IoT chipsets like Lemans, Product teams preferred a soft fuse
>>>>> instead of the hard fuse. The downside of the hard fuse that it should
>>>>> be blown from factory and not flexible to update from software later in
>>>>> the program.
>>>>
>>>> This response is for your comment above. Adding to that, the value for
>>>> the hard fuse is mostly likely to be '0' (unfused), but all internal
>>>> parts are always unfused. Maybe it is 'practically' harmless to use the
>>>> freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
>>>> mobile, Auto and IoT. I am not sure.
>>>>
>>>> I am trying to play safe here as this is dt. We don't want to configure
>>>> the wrong thing now and later struggle to correct it. It is safe to
>>>> defer things which we don't know.
>>>
>>> What is "soft fuse"? Why do we need an extra entity in addition to the
>>> one that was defined for auto / mobile units?
>>
>> The hard fuse (freq limiter one) has to be blown at a very early stage
>> in the chip manufacturing. Instead of that, a soft fuse region which is
>> updated by the firmware during the cold boot is used to provide a hint
>> to KMD about the supported GPU fmax. I was told that this provides
>> better operational flexibility to the Product team.
>
> Do you have an upstream example by chance?
We use soft fuse for Lemans IoT.
-Akhil.
>
>>
>> -Akhil
>>
>>>
>>>>
>>>> -Akhil.
>>>>
>>>>>
>>>>> -Akhil.
>>>>>
>>>>>>
>>>>>> We already have "machine" as another axis in the GPU catalog. I'd
>>>>>> suggest defining separate speed bins for mobile and auto/IoT in the DT
>>>>>> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
>>>>>> mapping those by the machine compat.
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>
On Mon, 22 Dec 2025 at 09:19, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
>
> On 12/13/2025 12:58 AM, Dmitry Baryshkov wrote:
> > On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
> >> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
> >>> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
> >>>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
> >>>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
> >>>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
> >>>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> >>>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> >>>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> >>>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >>>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [...]
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> + gpu_opp_table: opp-table {
> >>>>>>>>>>>>>> + compatible = "operating-points-v2";
> >>>>>>>>>>>>>> +
> >>>>>>>>>>>>>> + opp-845000000 {
> >>>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
> >>>>>>>>>>>>>> + };
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>>>>>>>>>>> or mobile parts specifically?
> >>>>>>>>>>>>
> >>>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>>>>>>>>>>> here.
> >>>>>>>>>>>
> >>>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
> >>>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
> >>>>>>>>>>> except the 290Mhz corner. We can remove that one.
> >>>>>>>>>>>
> >>>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
> >>>>>>>>>>> speedbins from the mobile variant until that is supported.
> >>>>>>>>>>
> >>>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
> >>>>>>>>>> non-mobile platforms.
> >>>>>>>>>
> >>>>>>>>> We cannot assume that.
> >>>>>>>>>
> >>>>>>>>> Even if we assume that there is no variation in silicon, the firmware
> >>>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> >>>>>>>>> wise to use the configuration that is commercialized, especially when it
> >>>>>>>>> is power related.
> >>>>>>>>
> >>>>>>>> How does it affect the speed bins? I'd really prefer if we:
> >>>>>>>> - describe OPP tables and speed bins here
> >>>>>>>> - remove speed bins cell for the Auto / IoT boards
> >>>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
> >>>>>>>> declared in the GPU.
> >>>>>>>>
> >>>>>>>
> >>>>>>> The frequency plan is different between mobile and IoT. Are you
> >>>>>>> proposing to describe a union of OPP table from both mobile and IoT?
> >>>>>>
> >>>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
> >>>>>> has speed bins. How comes we don't have bins for the IoT variant?
> >>>>>>
> >>>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
> >>>>>> Auto bins: 0, 177, 156, 136, 105, 73
> >>>>>>
> >>>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
> >>>>>> starting from bit 21).
> >>>>>>
> >>>>>> Mobile freqs:
> >>>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>> 156: 745M, 700M, 550M, 435M, 290M
> >>>>>> 136: 650M, 550M, 435M, 290M
> >>>>>> 105: 500M, 435M, 290M
> >>>>>> 73: 350M, 290M
> >>>>>>
> >>>>>> Auto freqs:
> >>>>>> 0: 845M, 745M, 650M, 500M, 435M
> >>>>>> 177: 845M, 745M, 650M, 500M, 435M
> >>>>>> 156: 745M, 650M, 500M, 435M
> >>>>>> 136: 650M, 500M, 435M
> >>>>>> 105: 500M, 435M
> >>>>>> 73: 350M
> >>>>>>
> >>>>>> 290M was a part of the freq table, but later it was removed as "not
> >>>>>> required", so probably it can be brought back, but I'm not sure how to
> >>>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
> >>>>>>
> >>>>>> I'm a bit persistent here because I really want to avoid the situation
> >>>>>> where we define a bin-less OPP table and later we face binned QCS615
> >>>>>> chips (which is possible since both SM and SA were binned).
> >>>>>
> >>>>> Why is that a problem as long as KMD can handle it without breaking
> >>>>> backward compatibility?
> >>>>
> >>>> I replied too soon. I see your point. Can't we keep separate OPP tables
> >>>> when that happen? That is neat-er than complicating the driver, isn't it?
> >>>
> >>> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
> >>> as a max freq without speed bins. Later some of the chips shipped in
> >>> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
> >>> MHz. The users end up overclocking those chips, because the DTB doesn't
> >>> make any difference.
> >>
> >> That is unlikely, because the characterization and other similiar
> >> activities are completed and finalized before ramp up at foundries.
> >> Nobody likes to RMA tons of chipsets.
> >>
> >> Anyway, this hypothetical scenarios is a problem even when we use the
> >> hard fuse.
> >
> > So, are you promising that while there were several characterization
> > bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
> > to the max freq?
>
> I have cross checked with our Product team. I can confirm that for both
> internal and external SKUs of Talos IoT currently, there is only a
> single bin for GPU with Fmax 845Mhz.
Okay. Thanks for the confirmation.
What happens when somebody starts working on a phone using SM6150 SoC
(e.g. Xiaomi Redmi Note 7 Pro)?
Likewise, If I understand correctly, QCS615 RIDE aka ADP Air uses an
auto SKU rather than the IoT one (please correct me if I'm wrong
here).
>
> >
> >>
> >>>
> >>>>
> >>>>>
> >>>>>>
> >>>>>> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
> >>>>>> and Auto SKUs. If you have access to the QCS615 hardware, what is the
> >>>>>> value written in that fuse area?
> >>>>>>
> >>>>>>> Another wrinkle we need to address is that, so far, we have never had a
> >>>>>>> dt binding where opp-supp-hw property exist without the speedbin cells.
> >>>>>>> And that adds a bit of complexity on the driver side because, today, the
> >>>>>>> KMD relies on the presence of speed bin cells to decide whether to
> >>>>>>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
> >>>>>>> combination (opp bins without speedbin cells) to help KMD detect that it
> >>>>>>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
> >>>>
> >>>>> If it is a soft fuse, it could fall into an unused region in qfprom. On
> >>>>> other IoT chipsets like Lemans, Product teams preferred a soft fuse
> >>>>> instead of the hard fuse. The downside of the hard fuse that it should
> >>>>> be blown from factory and not flexible to update from software later in
> >>>>> the program.
> >>>>
> >>>> This response is for your comment above. Adding to that, the value for
> >>>> the hard fuse is mostly likely to be '0' (unfused), but all internal
> >>>> parts are always unfused. Maybe it is 'practically' harmless to use the
> >>>> freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
> >>>> mobile, Auto and IoT. I am not sure.
> >>>>
> >>>> I am trying to play safe here as this is dt. We don't want to configure
> >>>> the wrong thing now and later struggle to correct it. It is safe to
> >>>> defer things which we don't know.
> >>>
> >>> What is "soft fuse"? Why do we need an extra entity in addition to the
> >>> one that was defined for auto / mobile units?
> >>
> >> The hard fuse (freq limiter one) has to be blown at a very early stage
> >> in the chip manufacturing. Instead of that, a soft fuse region which is
> >> updated by the firmware during the cold boot is used to provide a hint
> >> to KMD about the supported GPU fmax. I was told that this provides
> >> better operational flexibility to the Product team.
> >
> > Do you have an upstream example by chance?
>
> We use soft fuse for Lemans IoT.
>
> -Akhil.
>
> >
> >>
> >> -Akhil
> >>
> >>>
> >>>>
> >>>> -Akhil.
> >>>>
> >>>>>
> >>>>> -Akhil.
> >>>>>
> >>>>>>
> >>>>>> We already have "machine" as another axis in the GPU catalog. I'd
> >>>>>> suggest defining separate speed bins for mobile and auto/IoT in the DT
> >>>>>> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
> >>>>>> mapping those by the machine compat.
> >>>>>>
> >>>>>
> >>>>
> >>>
> >>
> >>
> >
>
--
With best wishes
Dmitry
On 12/22/2025 2:45 PM, Dmitry Baryshkov wrote:
> On Mon, 22 Dec 2025 at 09:19, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
>>
>> On 12/13/2025 12:58 AM, Dmitry Baryshkov wrote:
>>> On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
>>>> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
>>>>> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
>>>>>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
>>>>>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
>>>>>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
>>>>>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>>>>>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>>>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>>>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>> + opp-845000000 {
>>>>>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>>>>>>>>>> or mobile parts specifically?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>
>>>>>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>>>>>>>>>> except the 290Mhz corner. We can remove that one.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>>>>>>>>>> speedbins from the mobile variant until that is supported.
>>>>>>>>>>>>
>>>>>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
>>>>>>>>>>>> non-mobile platforms.
>>>>>>>>>>>
>>>>>>>>>>> We cannot assume that.
>>>>>>>>>>>
>>>>>>>>>>> Even if we assume that there is no variation in silicon, the firmware
>>>>>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>>>>>>>>>>> wise to use the configuration that is commercialized, especially when it
>>>>>>>>>>> is power related.
>>>>>>>>>>
>>>>>>>>>> How does it affect the speed bins? I'd really prefer if we:
>>>>>>>>>> - describe OPP tables and speed bins here
>>>>>>>>>> - remove speed bins cell for the Auto / IoT boards
>>>>>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
>>>>>>>>>> declared in the GPU.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The frequency plan is different between mobile and IoT. Are you
>>>>>>>>> proposing to describe a union of OPP table from both mobile and IoT?
>>>>>>>>
>>>>>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
>>>>>>>> has speed bins. How comes we don't have bins for the IoT variant?
>>>>>>>>
>>>>>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
>>>>>>>> Auto bins: 0, 177, 156, 136, 105, 73
>>>>>>>>
>>>>>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
>>>>>>>> starting from bit 21).
>>>>>>>>
>>>>>>>> Mobile freqs:
>>>>>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
>>>>>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
>>>>>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
>>>>>>>> 156: 745M, 700M, 550M, 435M, 290M
>>>>>>>> 136: 650M, 550M, 435M, 290M
>>>>>>>> 105: 500M, 435M, 290M
>>>>>>>> 73: 350M, 290M
>>>>>>>>
>>>>>>>> Auto freqs:
>>>>>>>> 0: 845M, 745M, 650M, 500M, 435M
>>>>>>>> 177: 845M, 745M, 650M, 500M, 435M
>>>>>>>> 156: 745M, 650M, 500M, 435M
>>>>>>>> 136: 650M, 500M, 435M
>>>>>>>> 105: 500M, 435M
>>>>>>>> 73: 350M
>>>>>>>>
>>>>>>>> 290M was a part of the freq table, but later it was removed as "not
>>>>>>>> required", so probably it can be brought back, but I'm not sure how to
>>>>>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
>>>>>>>>
>>>>>>>> I'm a bit persistent here because I really want to avoid the situation
>>>>>>>> where we define a bin-less OPP table and later we face binned QCS615
>>>>>>>> chips (which is possible since both SM and SA were binned).
>>>>>>>
>>>>>>> Why is that a problem as long as KMD can handle it without breaking
>>>>>>> backward compatibility?
>>>>>>
>>>>>> I replied too soon. I see your point. Can't we keep separate OPP tables
>>>>>> when that happen? That is neat-er than complicating the driver, isn't it?
>>>>>
>>>>> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
>>>>> as a max freq without speed bins. Later some of the chips shipped in
>>>>> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
>>>>> MHz. The users end up overclocking those chips, because the DTB doesn't
>>>>> make any difference.
>>>>
>>>> That is unlikely, because the characterization and other similiar
>>>> activities are completed and finalized before ramp up at foundries.
>>>> Nobody likes to RMA tons of chipsets.
>>>>
>>>> Anyway, this hypothetical scenarios is a problem even when we use the
>>>> hard fuse.
>>>
>>> So, are you promising that while there were several characterization
>>> bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
>>> to the max freq?
>>
>> I have cross checked with our Product team. I can confirm that for both
>> internal and external SKUs of Talos IoT currently, there is only a
>> single bin for GPU with Fmax 845Mhz.
>
> Okay. Thanks for the confirmation.
>
> What happens when somebody starts working on a phone using SM6150 SoC
> (e.g. Xiaomi Redmi Note 7 Pro)?
Update it in a way without disturbing the qcs615-ride.dtb? It is safe if
we add speedbin for Mobile in future, because KMD can correctly handle both.
> Likewise, If I understand correctly, QCS615 RIDE aka ADP Air uses an
> auto SKU rather than the IoT one (please correct me if I'm wrong
> here).
>
AFAIK, IoT variant is QCS615 and Auto variants uses SA6155P chipset.
Both chipsets are functionally same except some fuses.
-Akhil
>>
>>>
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> Also I don't see separate QFPROM memory map definitions for Mobile, IoT
>>>>>>>> and Auto SKUs. If you have access to the QCS615 hardware, what is the
>>>>>>>> value written in that fuse area?
>>>>>>>>
>>>>>>>>> Another wrinkle we need to address is that, so far, we have never had a
>>>>>>>>> dt binding where opp-supp-hw property exist without the speedbin cells.
>>>>>>>>> And that adds a bit of complexity on the driver side because, today, the
>>>>>>>>> KMD relies on the presence of speed bin cells to decide whether to
>>>>>>>>> select bin via opp_supp_hw API or not. Also, we may have to reserve this
>>>>>>>>> combination (opp bins without speedbin cells) to help KMD detect that it
>>>>>>>>> should use socinfo APIs instead of speedbin cells on certain chipsets.\
>>>>>>
>>>>>>> If it is a soft fuse, it could fall into an unused region in qfprom. On
>>>>>>> other IoT chipsets like Lemans, Product teams preferred a soft fuse
>>>>>>> instead of the hard fuse. The downside of the hard fuse that it should
>>>>>>> be blown from factory and not flexible to update from software later in
>>>>>>> the program.
>>>>>>
>>>>>> This response is for your comment above. Adding to that, the value for
>>>>>> the hard fuse is mostly likely to be '0' (unfused), but all internal
>>>>>> parts are always unfused. Maybe it is 'practically' harmless to use the
>>>>>> freq-limiter hard fuse for now, because 845Mhz is the Fmax for '0' on
>>>>>> mobile, Auto and IoT. I am not sure.
>>>>>>
>>>>>> I am trying to play safe here as this is dt. We don't want to configure
>>>>>> the wrong thing now and later struggle to correct it. It is safe to
>>>>>> defer things which we don't know.
>>>>>
>>>>> What is "soft fuse"? Why do we need an extra entity in addition to the
>>>>> one that was defined for auto / mobile units?
>>>>
>>>> The hard fuse (freq limiter one) has to be blown at a very early stage
>>>> in the chip manufacturing. Instead of that, a soft fuse region which is
>>>> updated by the firmware during the cold boot is used to provide a hint
>>>> to KMD about the supported GPU fmax. I was told that this provides
>>>> better operational flexibility to the Product team.
>>>
>>> Do you have an upstream example by chance?
>>
>> We use soft fuse for Lemans IoT.
>>
>> -Akhil.
>>
>>>
>>>>
>>>> -Akhil
>>>>
>>>>>
>>>>>>
>>>>>> -Akhil.
>>>>>>
>>>>>>>
>>>>>>> -Akhil.
>>>>>>>
>>>>>>>>
>>>>>>>> We already have "machine" as another axis in the GPU catalog. I'd
>>>>>>>> suggest defining separate speed bins for mobile and auto/IoT in the DT
>>>>>>>> (0x1 - 0x20 for mobile, 0x100 - 0x1000 for auto) and then in the driver
>>>>>>>> mapping those by the machine compat.
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>
>>
>
>
On Mon, 22 Dec 2025 at 12:54, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
>
> On 12/22/2025 2:45 PM, Dmitry Baryshkov wrote:
> > On Mon, 22 Dec 2025 at 09:19, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
> >>
> >> On 12/13/2025 12:58 AM, Dmitry Baryshkov wrote:
> >>> On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
> >>>> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
> >>>>> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
> >>>>>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
> >>>>>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
> >>>>>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
> >>>>>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> >>>>>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> >>>>>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >>>>>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>>>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> [...]
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> + gpu_opp_table: opp-table {
> >>>>>>>>>>>>>>>> + compatible = "operating-points-v2";
> >>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>> + opp-845000000 {
> >>>>>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
> >>>>>>>>>>>>>>>> + };
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>>>>>>>>>>>>> or mobile parts specifically?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
> >>>>>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
> >>>>>>>>>>>>> except the 290Mhz corner. We can remove that one.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
> >>>>>>>>>>>>> speedbins from the mobile variant until that is supported.
> >>>>>>>>>>>>
> >>>>>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
> >>>>>>>>>>>> non-mobile platforms.
> >>>>>>>>>>>
> >>>>>>>>>>> We cannot assume that.
> >>>>>>>>>>>
> >>>>>>>>>>> Even if we assume that there is no variation in silicon, the firmware
> >>>>>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> >>>>>>>>>>> wise to use the configuration that is commercialized, especially when it
> >>>>>>>>>>> is power related.
> >>>>>>>>>>
> >>>>>>>>>> How does it affect the speed bins? I'd really prefer if we:
> >>>>>>>>>> - describe OPP tables and speed bins here
> >>>>>>>>>> - remove speed bins cell for the Auto / IoT boards
> >>>>>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
> >>>>>>>>>> declared in the GPU.
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> The frequency plan is different between mobile and IoT. Are you
> >>>>>>>>> proposing to describe a union of OPP table from both mobile and IoT?
> >>>>>>>>
> >>>>>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
> >>>>>>>> has speed bins. How comes we don't have bins for the IoT variant?
> >>>>>>>>
> >>>>>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
> >>>>>>>> Auto bins: 0, 177, 156, 136, 105, 73
> >>>>>>>>
> >>>>>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
> >>>>>>>> starting from bit 21).
> >>>>>>>>
> >>>>>>>> Mobile freqs:
> >>>>>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>>>> 156: 745M, 700M, 550M, 435M, 290M
> >>>>>>>> 136: 650M, 550M, 435M, 290M
> >>>>>>>> 105: 500M, 435M, 290M
> >>>>>>>> 73: 350M, 290M
> >>>>>>>>
> >>>>>>>> Auto freqs:
> >>>>>>>> 0: 845M, 745M, 650M, 500M, 435M
> >>>>>>>> 177: 845M, 745M, 650M, 500M, 435M
> >>>>>>>> 156: 745M, 650M, 500M, 435M
> >>>>>>>> 136: 650M, 500M, 435M
> >>>>>>>> 105: 500M, 435M
> >>>>>>>> 73: 350M
> >>>>>>>>
> >>>>>>>> 290M was a part of the freq table, but later it was removed as "not
> >>>>>>>> required", so probably it can be brought back, but I'm not sure how to
> >>>>>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
> >>>>>>>>
> >>>>>>>> I'm a bit persistent here because I really want to avoid the situation
> >>>>>>>> where we define a bin-less OPP table and later we face binned QCS615
> >>>>>>>> chips (which is possible since both SM and SA were binned).
> >>>>>>>
> >>>>>>> Why is that a problem as long as KMD can handle it without breaking
> >>>>>>> backward compatibility?
> >>>>>>
> >>>>>> I replied too soon. I see your point. Can't we keep separate OPP tables
> >>>>>> when that happen? That is neat-er than complicating the driver, isn't it?
> >>>>>
> >>>>> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
> >>>>> as a max freq without speed bins. Later some of the chips shipped in
> >>>>> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
> >>>>> MHz. The users end up overclocking those chips, because the DTB doesn't
> >>>>> make any difference.
> >>>>
> >>>> That is unlikely, because the characterization and other similiar
> >>>> activities are completed and finalized before ramp up at foundries.
> >>>> Nobody likes to RMA tons of chipsets.
> >>>>
> >>>> Anyway, this hypothetical scenarios is a problem even when we use the
> >>>> hard fuse.
> >>>
> >>> So, are you promising that while there were several characterization
> >>> bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
> >>> to the max freq?
> >>
> >> I have cross checked with our Product team. I can confirm that for both
> >> internal and external SKUs of Talos IoT currently, there is only a
> >> single bin for GPU with Fmax 845Mhz.
> >
> > Okay. Thanks for the confirmation.
> >
> > What happens when somebody starts working on a phone using SM6150 SoC
> > (e.g. Xiaomi Redmi Note 7 Pro)?
>
> Update it in a way without disturbing the qcs615-ride.dtb? It is safe if
> we add speedbin for Mobile in future, because KMD can correctly handle both.
Corresponding entry in a6xx_catalog.c will receive speed bin
information. Will that break compatibility with the existing
qcs615-ride.dtb?
>
> > Likewise, If I understand correctly, QCS615 RIDE aka ADP Air uses an
> > auto SKU rather than the IoT one (please correct me if I'm wrong
> > here).
> >
>
> AFAIK, IoT variant is QCS615 and Auto variants uses SA6155P chipset.
> Both chipsets are functionally same except some fuses.
Ah, ok. I wasn't sure if we are using QCS615 or SA6155P in the Ride devices.
--
With best wishes
Dmitry
On 12/22/2025 4:54 PM, Dmitry Baryshkov wrote:
> On Mon, 22 Dec 2025 at 12:54, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
>>
>> On 12/22/2025 2:45 PM, Dmitry Baryshkov wrote:
>>> On Mon, 22 Dec 2025 at 09:19, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
>>>>
>>>> On 12/13/2025 12:58 AM, Dmitry Baryshkov wrote:
>>>>> On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
>>>>>> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
>>>>>>> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
>>>>>>>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
>>>>>>>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
>>>>>>>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
>>>>>>>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
>>>>>>>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
>>>>>>>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
>>>>>>>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>>>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>>>>>>>>>>>> ---
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> [...]
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>>>>>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>>>>>>>>>>>> +
>>>>>>>>>>>>>>>>>> + opp-845000000 {
>>>>>>>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>>>>>>>>>>>> + };
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>>>>>>>>>>>> or mobile parts specifically?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>>>>>>>>>>>> here.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>>>>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>>>>>>>>>>>> except the 290Mhz corner. We can remove that one.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>>>>>>>>>>>> speedbins from the mobile variant until that is supported.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
>>>>>>>>>>>>>> non-mobile platforms.
>>>>>>>>>>>>>
>>>>>>>>>>>>> We cannot assume that.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Even if we assume that there is no variation in silicon, the firmware
>>>>>>>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
>>>>>>>>>>>>> wise to use the configuration that is commercialized, especially when it
>>>>>>>>>>>>> is power related.
>>>>>>>>>>>>
>>>>>>>>>>>> How does it affect the speed bins? I'd really prefer if we:
>>>>>>>>>>>> - describe OPP tables and speed bins here
>>>>>>>>>>>> - remove speed bins cell for the Auto / IoT boards
>>>>>>>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
>>>>>>>>>>>> declared in the GPU.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The frequency plan is different between mobile and IoT. Are you
>>>>>>>>>>> proposing to describe a union of OPP table from both mobile and IoT?
>>>>>>>>>>
>>>>>>>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
>>>>>>>>>> has speed bins. How comes we don't have bins for the IoT variant?
>>>>>>>>>>
>>>>>>>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
>>>>>>>>>> Auto bins: 0, 177, 156, 136, 105, 73
>>>>>>>>>>
>>>>>>>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
>>>>>>>>>> starting from bit 21).
>>>>>>>>>>
>>>>>>>>>> Mobile freqs:
>>>>>>>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
>>>>>>>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
>>>>>>>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
>>>>>>>>>> 156: 745M, 700M, 550M, 435M, 290M
>>>>>>>>>> 136: 650M, 550M, 435M, 290M
>>>>>>>>>> 105: 500M, 435M, 290M
>>>>>>>>>> 73: 350M, 290M
>>>>>>>>>>
>>>>>>>>>> Auto freqs:
>>>>>>>>>> 0: 845M, 745M, 650M, 500M, 435M
>>>>>>>>>> 177: 845M, 745M, 650M, 500M, 435M
>>>>>>>>>> 156: 745M, 650M, 500M, 435M
>>>>>>>>>> 136: 650M, 500M, 435M
>>>>>>>>>> 105: 500M, 435M
>>>>>>>>>> 73: 350M
>>>>>>>>>>
>>>>>>>>>> 290M was a part of the freq table, but later it was removed as "not
>>>>>>>>>> required", so probably it can be brought back, but I'm not sure how to
>>>>>>>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
>>>>>>>>>>
>>>>>>>>>> I'm a bit persistent here because I really want to avoid the situation
>>>>>>>>>> where we define a bin-less OPP table and later we face binned QCS615
>>>>>>>>>> chips (which is possible since both SM and SA were binned).
>>>>>>>>>
>>>>>>>>> Why is that a problem as long as KMD can handle it without breaking
>>>>>>>>> backward compatibility?
>>>>>>>>
>>>>>>>> I replied too soon. I see your point. Can't we keep separate OPP tables
>>>>>>>> when that happen? That is neat-er than complicating the driver, isn't it?
>>>>>>>
>>>>>>> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
>>>>>>> as a max freq without speed bins. Later some of the chips shipped in
>>>>>>> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
>>>>>>> MHz. The users end up overclocking those chips, because the DTB doesn't
>>>>>>> make any difference.
>>>>>>
>>>>>> That is unlikely, because the characterization and other similiar
>>>>>> activities are completed and finalized before ramp up at foundries.
>>>>>> Nobody likes to RMA tons of chipsets.
>>>>>>
>>>>>> Anyway, this hypothetical scenarios is a problem even when we use the
>>>>>> hard fuse.
>>>>>
>>>>> So, are you promising that while there were several characterization
>>>>> bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
>>>>> to the max freq?
>>>>
>>>> I have cross checked with our Product team. I can confirm that for both
>>>> internal and external SKUs of Talos IoT currently, there is only a
>>>> single bin for GPU with Fmax 845Mhz.
>>>
>>> Okay. Thanks for the confirmation.
>>>
>>> What happens when somebody starts working on a phone using SM6150 SoC
>>> (e.g. Xiaomi Redmi Note 7 Pro)?
>>
>> Update it in a way without disturbing the qcs615-ride.dtb? It is safe if
>> we add speedbin for Mobile in future, because KMD can correctly handle both.
>
> Corresponding entry in a6xx_catalog.c will receive speed bin
> information. Will that break compatibility with the existing
> qcs615-ride.dtb?
>
It won't. KMD will select a bin in OPP table only when a speedbin nvmem
cell is present. If the nvmem cell is not present, it will ignore the
speedbin table in the catalog.
-Akhil
>>
>>> Likewise, If I understand correctly, QCS615 RIDE aka ADP Air uses an
>>> auto SKU rather than the IoT one (please correct me if I'm wrong
>>> here).
>>>
>>
>> AFAIK, IoT variant is QCS615 and Auto variants uses SA6155P chipset.
>> Both chipsets are functionally same except some fuses.
>
> Ah, ok. I wasn't sure if we are using QCS615 or SA6155P in the Ride devices.
>
On Mon, Dec 22, 2025 at 11:59:34PM +0530, Akhil P Oommen wrote:
> On 12/22/2025 4:54 PM, Dmitry Baryshkov wrote:
> > On Mon, 22 Dec 2025 at 12:54, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
> >>
> >> On 12/22/2025 2:45 PM, Dmitry Baryshkov wrote:
> >>> On Mon, 22 Dec 2025 at 09:19, Akhil P Oommen <akhilpo@oss.qualcomm.com> wrote:
> >>>>
> >>>> On 12/13/2025 12:58 AM, Dmitry Baryshkov wrote:
> >>>>> On Fri, Dec 12, 2025 at 01:01:44AM +0530, Akhil P Oommen wrote:
> >>>>>> On 12/11/2025 6:56 PM, Dmitry Baryshkov wrote:
> >>>>>>> On Thu, Dec 11, 2025 at 05:22:40PM +0530, Akhil P Oommen wrote:
> >>>>>>>> On 12/11/2025 4:42 PM, Akhil P Oommen wrote:
> >>>>>>>>> On 12/11/2025 6:06 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>> On Thu, Dec 11, 2025 at 02:40:52AM +0530, Akhil P Oommen wrote:
> >>>>>>>>>>> On 12/6/2025 2:04 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>>>> On Fri, Dec 05, 2025 at 03:59:09PM +0530, Akhil P Oommen wrote:
> >>>>>>>>>>>>> On 12/4/2025 7:49 PM, Dmitry Baryshkov wrote:
> >>>>>>>>>>>>>> On Thu, Dec 04, 2025 at 03:43:33PM +0530, Akhil P Oommen wrote:
> >>>>>>>>>>>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
> >>>>>>>>>>>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
> >>>>>>>>>>>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
> >>>>>>>>>>>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
> >>>>>>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
> >>>>>>>>>>>>>>>>>> ---
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> [...]
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> + gpu_opp_table: opp-table {
> >>>>>>>>>>>>>>>>>> + compatible = "operating-points-v2";
> >>>>>>>>>>>>>>>>>> +
> >>>>>>>>>>>>>>>>>> + opp-845000000 {
> >>>>>>>>>>>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
> >>>>>>>>>>>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
> >>>>>>>>>>>>>>>>>> + opp-peak-kBps = <7050000>;
> >>>>>>>>>>>>>>>>>> + };
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
> >>>>>>>>>>>>>>>>> or mobile parts specifically?
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
> >>>>>>>>>>>>>>>> here.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> The IoT/Auto variants have a different frequency plan compared to the
> >>>>>>>>>>>>>>> mobile variant. I reviewed the downstream code and this aligns with that
> >>>>>>>>>>>>>>> except the 290Mhz corner. We can remove that one.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
> >>>>>>>>>>>>>>> speedbins from the mobile variant until that is supported.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> No, we are describing just Talos, which hopefully covers both mobile and
> >>>>>>>>>>>>>> non-mobile platforms.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> We cannot assume that.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Even if we assume that there is no variation in silicon, the firmware
> >>>>>>>>>>>>> (AOP, TZ, HYP etc) is different between mobile and IoT version. So it is
> >>>>>>>>>>>>> wise to use the configuration that is commercialized, especially when it
> >>>>>>>>>>>>> is power related.
> >>>>>>>>>>>>
> >>>>>>>>>>>> How does it affect the speed bins? I'd really prefer if we:
> >>>>>>>>>>>> - describe OPP tables and speed bins here
> >>>>>>>>>>>> - remove speed bins cell for the Auto / IoT boards
> >>>>>>>>>>>> - make sure that the driver uses the IoT bin if there is no speed bin
> >>>>>>>>>>>> declared in the GPU.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> The frequency plan is different between mobile and IoT. Are you
> >>>>>>>>>>> proposing to describe a union of OPP table from both mobile and IoT?
> >>>>>>>>>>
> >>>>>>>>>> Okay, this prompted me to check the sa6155p.dtsi from msm-4.14... And it
> >>>>>>>>>> has speed bins. How comes we don't have bins for the IoT variant?
> >>>>>>>>>>
> >>>>>>>>>> Mobile bins: 0, 177, 187, 156, 136, 105, 73
> >>>>>>>>>> Auto bins: 0, 177, 156, 136, 105, 73
> >>>>>>>>>>
> >>>>>>>>>> Both Mobile and Auto chips used the same NVMEM cell (0x6004, 8 bits
> >>>>>>>>>> starting from bit 21).
> >>>>>>>>>>
> >>>>>>>>>> Mobile freqs:
> >>>>>>>>>> 0: 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>>>>>> 177: 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>>>>>> 187: 895M, 845M, 745M, 700M, 550M, 435M, 290M
> >>>>>>>>>> 156: 745M, 700M, 550M, 435M, 290M
> >>>>>>>>>> 136: 650M, 550M, 435M, 290M
> >>>>>>>>>> 105: 500M, 435M, 290M
> >>>>>>>>>> 73: 350M, 290M
> >>>>>>>>>>
> >>>>>>>>>> Auto freqs:
> >>>>>>>>>> 0: 845M, 745M, 650M, 500M, 435M
> >>>>>>>>>> 177: 845M, 745M, 650M, 500M, 435M
> >>>>>>>>>> 156: 745M, 650M, 500M, 435M
> >>>>>>>>>> 136: 650M, 500M, 435M
> >>>>>>>>>> 105: 500M, 435M
> >>>>>>>>>> 73: 350M
> >>>>>>>>>>
> >>>>>>>>>> 290M was a part of the freq table, but later it was removed as "not
> >>>>>>>>>> required", so probably it can be brought back, but I'm not sure how to
> >>>>>>>>>> handle 650 MHz vs 700 MHz and 500 MHz vs 550 MHz differences.
> >>>>>>>>>>
> >>>>>>>>>> I'm a bit persistent here because I really want to avoid the situation
> >>>>>>>>>> where we define a bin-less OPP table and later we face binned QCS615
> >>>>>>>>>> chips (which is possible since both SM and SA were binned).
> >>>>>>>>>
> >>>>>>>>> Why is that a problem as long as KMD can handle it without breaking
> >>>>>>>>> backward compatibility?
> >>>>>>>>
> >>>>>>>> I replied too soon. I see your point. Can't we keep separate OPP tables
> >>>>>>>> when that happen? That is neat-er than complicating the driver, isn't it?
> >>>>>>>
> >>>>>>> I have different story in mind. We ship DTB for IQ-615 listing 845 MHz
> >>>>>>> as a max freq without speed bins. Later some of the chips shipped in
> >>>>>>> IQ-615 are characterized as not belonging to bin 0 / not supporting 845
> >>>>>>> MHz. The users end up overclocking those chips, because the DTB doesn't
> >>>>>>> make any difference.
> >>>>>>
> >>>>>> That is unlikely, because the characterization and other similiar
> >>>>>> activities are completed and finalized before ramp up at foundries.
> >>>>>> Nobody likes to RMA tons of chipsets.
> >>>>>>
> >>>>>> Anyway, this hypothetical scenarios is a problem even when we use the
> >>>>>> hard fuse.
> >>>>>
> >>>>> So, are you promising that while there were several characterization
> >>>>> bins for SM6150 and SA6155P, there is only one bin for QCS615, going up
> >>>>> to the max freq?
> >>>>
> >>>> I have cross checked with our Product team. I can confirm that for both
> >>>> internal and external SKUs of Talos IoT currently, there is only a
> >>>> single bin for GPU with Fmax 845Mhz.
> >>>
> >>> Okay. Thanks for the confirmation.
> >>>
> >>> What happens when somebody starts working on a phone using SM6150 SoC
> >>> (e.g. Xiaomi Redmi Note 7 Pro)?
> >>
> >> Update it in a way without disturbing the qcs615-ride.dtb? It is safe if
> >> we add speedbin for Mobile in future, because KMD can correctly handle both.
> >
> > Corresponding entry in a6xx_catalog.c will receive speed bin
> > information. Will that break compatibility with the existing
> > qcs615-ride.dtb?
> >
>
> It won't. KMD will select a bin in OPP table only when a speedbin nvmem
> cell is present. If the nvmem cell is not present, it will ignore the
> speedbin table in the catalog.
I'm not extremely happy (and I'd prefer if we have added GPU bins in
this patchset), but technically you are correct and it can be done
separately, when somebody will work on those phones.
Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
>
> -Akhil
>
> >>
> >>> Likewise, If I understand correctly, QCS615 RIDE aka ADP Air uses an
> >>> auto SKU rather than the IoT one (please correct me if I'm wrong
> >>> here).
> >>>
> >>
> >> AFAIK, IoT variant is QCS615 and Auto variants uses SA6155P chipset.
> >> Both chipsets are functionally same except some fuses.
> >
> > Ah, ok. I wasn't sure if we are using QCS615 or SA6155P in the Ride devices.
> >
>
--
With best wishes
Dmitry
On 12/4/25 11:13 AM, Akhil P Oommen wrote:
> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>
>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>
>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>> ---
>>>
>>> [...]
>>>
>>>> + gpu_opp_table: opp-table {
>>>> + compatible = "operating-points-v2";
>>>> +
>>>> + opp-845000000 {
>>>> + opp-hz = /bits/ 64 <845000000>;
>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>> + opp-peak-kBps = <7050000>;
>>>> + };
>>>
>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>> or mobile parts specifically?
>>
>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>> here.
>
> The IoT/Auto variants have a different frequency plan compared to the
> mobile variant. I reviewed the downstream code and this aligns with that
> except the 290Mhz corner. We can remove that one.
>
> Here we are describing the IoT variant of Talos. So we can ignore the
> speedbins from the mobile variant until that is supported.
Writing this reply took probably only slightly less time than fixing
the issue.. I really see no point in kicking the can down the road
Konrad
On 12/4/2025 7:01 PM, Konrad Dybcio wrote:
> On 12/4/25 11:13 AM, Akhil P Oommen wrote:
>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>
>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>
>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>> ---
>>>>
>>>> [...]
>>>>
>>>>> + gpu_opp_table: opp-table {
>>>>> + compatible = "operating-points-v2";
>>>>> +
>>>>> + opp-845000000 {
>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>> + opp-peak-kBps = <7050000>;
>>>>> + };
>>>>
>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>> or mobile parts specifically?
>>>
>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>> here.
>>
>> The IoT/Auto variants have a different frequency plan compared to the
>> mobile variant. I reviewed the downstream code and this aligns with that
>> except the 290Mhz corner. We can remove that one.
>>
>> Here we are describing the IoT variant of Talos. So we can ignore the
>> speedbins from the mobile variant until that is supported.
>
> Writing this reply took probably only slightly less time than fixing
> the issue.. I really see no point in kicking the can down the road
We don't know the speedbin fuse register and the values applicable for
this IoT chipset. Currently, there is only a single variant and no SKUs
for this chipset. We can add them when those decisions are taken by the
relevant folks from Product team.
-Akhil.
>
> Konrad
On 12/5/25 2:41 PM, Akhil P Oommen wrote:
> On 12/4/2025 7:01 PM, Konrad Dybcio wrote:
>> On 12/4/25 11:13 AM, Akhil P Oommen wrote:
>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>
>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>
>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>> ---
>>>>>
>>>>> [...]
>>>>>
>>>>>> + gpu_opp_table: opp-table {
>>>>>> + compatible = "operating-points-v2";
>>>>>> +
>>>>>> + opp-845000000 {
>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>> + opp-peak-kBps = <7050000>;
>>>>>> + };
>>>>>
>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>> or mobile parts specifically?
>>>>
>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>> here.
>>>
>>> The IoT/Auto variants have a different frequency plan compared to the
>>> mobile variant. I reviewed the downstream code and this aligns with that
>>> except the 290Mhz corner. We can remove that one.
>>>
>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>> speedbins from the mobile variant until that is supported.
>>
>> Writing this reply took probably only slightly less time than fixing
>> the issue.. I really see no point in kicking the can down the road
>
> We don't know the speedbin fuse register and the values applicable for
> this IoT chipset. Currently, there is only a single variant and no SKUs
> for this chipset. We can add them when those decisions are taken by the
> relevant folks from Product team.
If there's only a single variant right now, could you simply read back
the value and report it where necessary to make sure the internal teams
are aware?
There's surely *some* value fused into the cell..
Konrad
On 12/5/2025 7:22 PM, Konrad Dybcio wrote:
> On 12/5/25 2:41 PM, Akhil P Oommen wrote:
>> On 12/4/2025 7:01 PM, Konrad Dybcio wrote:
>>> On 12/4/25 11:13 AM, Akhil P Oommen wrote:
>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>
>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>
>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>> ---
>>>>>>
>>>>>> [...]
>>>>>>
>>>>>>> + gpu_opp_table: opp-table {
>>>>>>> + compatible = "operating-points-v2";
>>>>>>> +
>>>>>>> + opp-845000000 {
>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>> + };
>>>>>>
>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>> or mobile parts specifically?
>>>>>
>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>> here.
>>>>
>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>> except the 290Mhz corner. We can remove that one.
>>>>
>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>> speedbins from the mobile variant until that is supported.
>>>
>>> Writing this reply took probably only slightly less time than fixing
>>> the issue.. I really see no point in kicking the can down the road
>>
>> We don't know the speedbin fuse register and the values applicable for
>> this IoT chipset. Currently, there is only a single variant and no SKUs
>> for this chipset. We can add them when those decisions are taken by the
>> relevant folks from Product team.
>
> If there's only a single variant right now, could you simply read back
> the value and report it where necessary to make sure the internal teams
> are aware?
>
> There's surely *some* value fused into the cell..
We don't know which register to read at the moment. It could be the hard
fuse register or some soft fuse register at an arbitrary location.
It is better to leave it as it is for now. Who knows, maybe there won't
any SKUs at all.
-Akhil
>
> Konrad
On 12/5/25 3:05 PM, Akhil P Oommen wrote:
> On 12/5/2025 7:22 PM, Konrad Dybcio wrote:
>> On 12/5/25 2:41 PM, Akhil P Oommen wrote:
>>> On 12/4/2025 7:01 PM, Konrad Dybcio wrote:
>>>> On 12/4/25 11:13 AM, Akhil P Oommen wrote:
>>>>> On 11/26/2025 6:12 AM, Dmitry Baryshkov wrote:
>>>>>> On Sat, Nov 22, 2025 at 03:03:10PM +0100, Konrad Dybcio wrote:
>>>>>>> On 11/21/25 10:52 PM, Akhil P Oommen wrote:
>>>>>>>> From: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>>
>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset.
>>>>>>>>
>>>>>>>> Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com>
>>>>>>>> Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com>
>>>>>>>> ---
>>>>>>>
>>>>>>> [...]
>>>>>>>
>>>>>>>> + gpu_opp_table: opp-table {
>>>>>>>> + compatible = "operating-points-v2";
>>>>>>>> +
>>>>>>>> + opp-845000000 {
>>>>>>>> + opp-hz = /bits/ 64 <845000000>;
>>>>>>>> + required-opps = <&rpmhpd_opp_turbo>;
>>>>>>>> + opp-peak-kBps = <7050000>;
>>>>>>>> + };
>>>>>>>
>>>>>>> I see another speed of 895 @ turbo_l1, perhaps that's for speedbins
>>>>>>> or mobile parts specifically?
>>>>>>
>>>>>> msm-4.14 defines 7 speedbins for SM6150. Akhil, I don't see any of them
>>>>>> here.
>>>>>
>>>>> The IoT/Auto variants have a different frequency plan compared to the
>>>>> mobile variant. I reviewed the downstream code and this aligns with that
>>>>> except the 290Mhz corner. We can remove that one.
>>>>>
>>>>> Here we are describing the IoT variant of Talos. So we can ignore the
>>>>> speedbins from the mobile variant until that is supported.
>>>>
>>>> Writing this reply took probably only slightly less time than fixing
>>>> the issue.. I really see no point in kicking the can down the road
>>>
>>> We don't know the speedbin fuse register and the values applicable for
>>> this IoT chipset. Currently, there is only a single variant and no SKUs
>>> for this chipset. We can add them when those decisions are taken by the
>>> relevant folks from Product team.
>>
>> If there's only a single variant right now, could you simply read back
>> the value and report it where necessary to make sure the internal teams
>> are aware?
>>
>> There's surely *some* value fused into the cell..
>
> We don't know which register to read at the moment. It could be the hard
> fuse register or some soft fuse register at an arbitrary location.
>
> It is better to leave it as it is for now. Who knows, maybe there won't
> any SKUs at all.
Please don't take it the wrong way, but who else would know that? :/
Konrad
On Sat, Nov 22, 2025 at 03:22:19AM +0530, Akhil P Oommen wrote: > From: Jie Zhang <quic_jiezh@quicinc.com> > > Add gpu and rgmu nodes for qcs615 chipset. > > Signed-off-by: Jie Zhang <quic_jiezh@quicinc.com> > Signed-off-by: Akhil P Oommen <akhilpo@oss.qualcomm.com> > --- > arch/arm64/boot/dts/qcom/talos.dtsi | 116 ++++++++++++++++++++++++++++++++++++ > 1 file changed, 116 insertions(+) > Reviewed-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com> -- With best wishes Dmitry
© 2016 - 2026 Red Hat, Inc.