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