On 12/22/2025 2:45 PM, Dmitry Baryshkov wrote: > On Mon, 22 Dec 2025 at 09:19, Akhil P Oommen <[email protected]> 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 <[email protected]> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Add gpu and rgmu nodes for qcs615 chipset. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Signed-off-by: Jie Zhang <[email protected]> >>>>>>>>>>>>>>>> Signed-off-by: Akhil P Oommen <[email protected]> >>>>>>>>>>>>>>>> --- >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> [...] >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> + 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. >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>> >> > >
