On 11/29/2024 9:03 PM, Konrad Dybcio wrote:
> On 28.11.2024 11:25 AM, Neil Armstrong wrote:
>> The Adreno GPU Management Unit (GMU) can also scale the DDR Bandwidth
>> along the Frequency and Power Domain level, until now we left the OPP
>> core scale the OPP bandwidth via the interconnect path.
>>
>> In order to enable bandwidth voting via the GPU Management
>> Unit (GMU), when an opp is set by devfreq we also look for
>> the corresponding bandwidth index in the previously generated
>> bw_table and pass this value along the frequency index to the GMU.
>>
>> The AB pre-calculated vote is appended to the bandwidth index
>> to inform the GMU firmware the quantity of bandwidth we need.
>>
>> Since we now vote for all resources via the GMU, setting the OPP
>> is no more needed, so we can completely skip calling
>> dev_pm_opp_set_opp() in this situation.
>>
>> Signed-off-by: Neil Armstrong <neil.armstr...@linaro.org>
>> ---
>>  drivers/gpu/drm/msm/adreno/a6xx_gmu.c | 23 +++++++++++++++++++++--
>>  drivers/gpu/drm/msm/adreno/a6xx_gmu.h |  2 +-
>>  drivers/gpu/drm/msm/adreno/a6xx_hfi.c |  6 +++---
>>  3 files changed, 25 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c 
>> b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
>> index 
>> ee2010a01186721dd377f1655fcf05ddaff77131..c09442ecc861c4e56c81e7e775b9e57baf7d2e51
>>  100644
>> --- a/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
>> +++ b/drivers/gpu/drm/msm/adreno/a6xx_gmu.c
>> @@ -110,9 +110,11 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
>> dev_pm_opp *opp,
>>                     bool suspended)
>>  {
>>      struct adreno_gpu *adreno_gpu = to_adreno_gpu(gpu);
>> +    const struct a6xx_info *info = adreno_gpu->info->a6xx;
>>      struct a6xx_gpu *a6xx_gpu = to_a6xx_gpu(adreno_gpu);
>>      struct a6xx_gmu *gmu = &a6xx_gpu->gmu;
>>      u32 perf_index;
>> +    u32 bw_index = 0;
>>      unsigned long gpu_freq;
>>      int ret = 0;
>>  
>> @@ -125,6 +127,21 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
>> dev_pm_opp *opp,
>>              if (gpu_freq == gmu->gpu_freqs[perf_index])
>>                      break;
>>  
>> +    /* If enabled, find the corresponding DDR bandwidth index */
>> +    if (info->bcms && gmu->nr_gpu_bws > 1) {
>> +            unsigned int bw = dev_pm_opp_get_bw(opp, true, 0);
>> +
>> +            for (bw_index = 0; bw_index < gmu->nr_gpu_bws - 1; bw_index++) {
>> +                    if (bw == gmu->gpu_bw_table[bw_index])
>> +                            break;
>> +            }
>> +
>> +            if (bw_index) {
>> +                    bw_index |= AB_VOTE(gmu->gpu_ab_votes[bw_index]);
>> +                    bw_index |= AB_VOTE_ENABLE;
>> +            }
>> +    }
> 
> If we couple frequency levels with bw levels (i.e. duplicate the highest
> bandwidth a couple times), we can drop all this search logic..

Will that alter hfi table? I prefer to avoid altering GMU data. We
should not make any assumption on how fw would use the data. And we
don't want to hit any surprises on power management related things.

Lets use the GMU interfaces exactly how it is used in downstream. No
assumptions and improvisation please!

-Akhil

> 
>> +
>>      gmu->current_perf_index = perf_index;
>>      gmu->freq = gmu->gpu_freqs[perf_index];
>>  
>> @@ -140,8 +157,10 @@ void a6xx_gmu_set_freq(struct msm_gpu *gpu, struct 
>> dev_pm_opp *opp,
>>              return;
>>  
>>      if (!gmu->legacy) {
>> -            a6xx_hfi_set_freq(gmu, perf_index);
>> -            dev_pm_opp_set_opp(&gpu->pdev->dev, opp);
>> +            a6xx_hfi_set_freq(gmu, perf_index, bw_index);
>> +            /* With Bandwidth voting, we now vote for all resources, so 
>> skip OPP set */
>> +            if (!bw_index)
>> +                    dev_pm_opp_set_opp(&gpu->pdev->dev, opp);
> 
> ..and then it would come down to..
> 
> if (!info->bcms)
> 
> Konrad

Reply via email to