Re: [PATCH v3 5/6] arm64: dts: qcom: sm6150: Add gpu and rgmu nodes

[Akhil P Oommen <akhilpo@oss.qualcomm.com>]

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.
>