Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <905b4150-6e15-4172-10cf-19aa0ebf817c@quicinc.com>
Date:   Thu, 20 Apr 2023 10:47:34 -0700
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101
 Thunderbird/102.10.0
Subject: Re: [Freedreno] [PATCH 02/11] drm/msm/dpu: use the actual lm maximum
 width instead of a hardcoded value
Content-Language: en-US
To:     Dmitry Baryshkov <dmitry.baryshkov@linaro.org>,
        Arnaud Vrac <avrac@freebox.fr>,
        Rob Clark <robdclark@gmail.com>,
        Abhinav Kumar <quic_abhinavk@quicinc.com>,
        Sean Paul <sean@poorly.run>, David Airlie <airlied@gmail.com>,
        Daniel Vetter <daniel@ffwll.ch>
CC:     <linux-arm-msm@vger.kernel.org>, <freedreno@lists.freedesktop.org>,
        <linux-kernel@vger.kernel.org>, <dri-devel@lists.freedesktop.org>
References: <20230419-dpu-tweaks-v1-0-d1bac46db075@freebox.fr>
 <20230419-dpu-tweaks-v1-2-d1bac46db075@freebox.fr>
 <6e807c05-a990-5692-3f84-2e4153c8c278@linaro.org>
From:   Jeykumar Sankaran <quic_jeykumar@quicinc.com>
In-Reply-To: <6e807c05-a990-5692-3f84-2e4153c8c278@linaro.org>
Content-Type: text/plain; charset="UTF-8"; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 4/19/2023 3:23 PM, Dmitry Baryshkov wrote:
> On 19/04/2023 17:41, Arnaud Vrac wrote:
>> This avoids using two LMs instead of one when the display width is lower
>> than the maximum supported value. For example on MSM8996/MSM8998, the
>> actual maxwidth is 2560, so we would use two LMs for 1280x720 or
>> 1920x1080 resolutions, while one is enough.
>>
>> Signed-off-by: Arnaud Vrac <avrac@freebox.fr>
> 
> While this looks correct (and following what we have in 4.4), later 
> vendor kernels specify the topology explicitly. Probably we should check 
> this with the hw guys, because it might be the following case: even 
> though a single LM can supply the mode, it will spend more power 
> compared to two LMs.
> 
> 
Yes. 2 LM split will allow the HW to run in lower mdp core clock. Can 
you maintain the split_threshold in the hw catalog until per mode 
topology is available?

Jeykumar S
>> ---
>>   drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c | 10 +++++-----
>>   1 file changed, 5 insertions(+), 5 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c 
>> b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> index 1dc5dbe585723..dd2914726c4f6 100644
>> --- a/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> +++ b/drivers/gpu/drm/msm/disp/dpu1/dpu_encoder.c
>> @@ -53,8 +53,6 @@
>>   #define IDLE_SHORT_TIMEOUT    1
>> -#define MAX_HDISPLAY_SPLIT 1080
>> -
>>   /* timeout in frames waiting for frame done */
>>   #define DPU_ENCODER_FRAME_DONE_TIMEOUT_FRAMES 5
>> @@ -568,10 +566,12 @@ static struct msm_display_topology 
>> dpu_encoder_get_topology(
>>        */
>>       if (intf_count == 2)
>>           topology.num_lm = 2;
>> -    else if (!dpu_kms->catalog->caps->has_3d_merge)
>> -        topology.num_lm = 1;
>> +    else if (dpu_kms->catalog->caps->has_3d_merge &&
>> +         dpu_kms->catalog->mixer_count > 0 &&
>> +         mode->hdisplay > dpu_kms->catalog->mixer[0].sblk->maxwidth)
>> +        topology.num_lm = 2;
>>       else
>> -        topology.num_lm = (mode->hdisplay > MAX_HDISPLAY_SPLIT) ? 2 : 1;
>> +        topology.num_lm = 1;
>>       if (crtc_state->ctm)
>>           topology.num_dspp = topology.num_lm;
>>
>