On 12/22/2025 4:54 PM, Dmitry Baryshkov wrote: > On Mon, 22 Dec 2025 at 12:54, Akhil P Oommen <[email protected]> wrote: >> >> 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. > > 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. >
