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