All of lore.kernel.org
 help / color / mirror / Atom feed
From: Harry Wentland <harry.wentland@amd.com>
To: Alex Deucher <alexdeucher@gmail.com>,
	Kenneth Feng <kenneth.feng@amd.com>
Cc: amd-gfx@lists.freedesktop.org, kevinyang.wang@amd.com,
	alexander.deucher@amd.com
Subject: Re: [PATCH] drm/amd/display: reset the workload type when using MALL
Date: Fri, 7 Mar 2025 10:30:45 -0500	[thread overview]
Message-ID: <6299383a-ecd4-4800-b261-e46dd75353df@amd.com> (raw)
In-Reply-To: <CADnq5_OH7iumFq2MJ_LjpAwYzf34G60dUh_rug6HWBrkq=8Xxg@mail.gmail.com>



On 2025-03-07 09:48, Alex Deucher wrote:
> On Thu, Mar 6, 2025 at 10:45 PM Kenneth Feng <kenneth.feng@amd.com> wrote:
>>
>> Reset the workload type when using MALL.
>> When there is no activity on the screen, dal requestes dmcub
>> to use MALL. However, gfx ring is not empty at the same time.
>> Currrently the workload type is set to 3D fullscreen when gfx
>> ring has jobs. No activity on the screen and the gfx ring empty
>> state can not be synchronized to each other. By removing the
>> 3D fullscreen workload when there is no activity on screen, the
>> event can be passed down to dmcub->pmfw, since pmfw only allows
>> MALL when the workload type setting is bootup default, then MALL
>> can be really used. And this does not impact the thread to detect
>> the ring jobs and can set back to the 3D fullscreen later.
>>
>> Signed-off-by: Kenneth Feng <kenneth.feng@amd.com>
>> ---
>>  drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c | 10 +++++++++-
>>  1 file changed, 9 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
>> index 36a830a7440f..154936166896 100644
>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_crtc.c
>> @@ -244,6 +244,8 @@ static void amdgpu_dm_crtc_vblank_control_worker(struct work_struct *work)
>>         struct vblank_control_work *vblank_work =
>>                 container_of(work, struct vblank_control_work, work);
>>         struct amdgpu_display_manager *dm = vblank_work->dm;
>> +       int r;
>> +       struct amdgpu_device *adev = drm_to_adev(dm->ddev);
>>
>>         mutex_lock(&dm->dc_lock);
>>
>> @@ -271,8 +273,14 @@ static void amdgpu_dm_crtc_vblank_control_worker(struct work_struct *work)
>>                         vblank_work->acrtc->dm_irq_params.allow_sr_entry);
>>         }
>>
>> -       if (dm->active_vblank_irq_count == 0)
>> +       if (dm->active_vblank_irq_count == 0) {
>> +               r = amdgpu_dpm_switch_power_profile(adev, PP_SMC_POWER_PROFILE_FULLSCREEN3D, false);
> 
> To keep this balanced, you should get a reference when we disable the
> optimizations.  Also if ROCm applications are running, the compute
> profile will be active so that should be decremented too or if VCN
> jobs are running the video profile may be active as well.  On the
> other hand, if users have apps running when the display is off, maybe
> they don't want the idle optimizations in the first place.
> Alternatively, we could have a suspend/resume workload profile
> function that sets a flag in sw_smu which sets the default workload
> profile and skips all updates to the workload profile while that flag
> is set.  The swsmu will still track the ref counts and then when we
> resume the workload profile handling, we can restore all of the
> workloads profiles based on the ref counts.
> 

I don't think it's a good idea for DM to explicitly switch
power profiles.

Generally the display driver interacts with PM in
two ways:
- indicate min clocks that are needed for real-time operation
  of DCN
- allow various state switches when the driver knows they
  won't impact real-time operation of DCN

Harry

> Alex
> 
> 
>> +               if (r)
>> +            dev_warn(adev->dev, "(%d) failed to disable fullscreen 3D  power profile mode\n",
>> +                                        r);
>> +
>>                 dc_allow_idle_optimizations(dm->dc, true);
>> +       }
>>
>>         mutex_unlock(&dm->dc_lock);
>>
>> --
>> 2.34.1
>>


      reply	other threads:[~2025-03-07 15:30 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-07  3:44 [PATCH] drm/amd/display: reset the workload type when using MALL Kenneth Feng
2025-03-07 14:48 ` Alex Deucher
2025-03-07 15:30   ` Harry Wentland [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6299383a-ecd4-4800-b261-e46dd75353df@amd.com \
    --to=harry.wentland@amd.com \
    --cc=alexander.deucher@amd.com \
    --cc=alexdeucher@gmail.com \
    --cc=amd-gfx@lists.freedesktop.org \
    --cc=kenneth.feng@amd.com \
    --cc=kevinyang.wang@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.