[ Fixed up the top-posting, please don't ]
On 2/18/26 11:09, Michele Palazzi wrote:
> On 2/18/26 10:41, Michel Dänzer wrote:
>> On 2/18/26 01:31, Michele Palazzi wrote:
>>>
>>> diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> index a8a59126b2d2..35987ce80c71 100644
>>> --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
>>> @@ -10168,8 +10168,7 @@ static void amdgpu_dm_commit_planes(struct
>>> drm_atomic_state *state,
>>> } else if (cursor_update && acrtc_state->active_planes > 0) {
>>> spin_lock_irqsave(&pcrtc->dev->event_lock, flags);
>>> if (acrtc_attach->base.state->event) {
>>> - drm_crtc_vblank_get(pcrtc);
>>> - acrtc_attach->event = acrtc_attach->base.state->event;
>>> + drm_crtc_send_vblank_event(pcrtc,
>>> acrtc_attach->base.state->event);
>>
>> Can this code run before start of vblank? If yes, the event would have the
>> wrong sequence number and timestamp.
>
> Yes, but the original code path had the same problem.
Are you sure?
I'd expect the original code to send the event only when an interrupt fires
during vblank, at which point the values are correct.
> Would drm_crtc_arm_vblank_event() be more appropriate here? The concern is
> that it reintroduces the starvation race if the vblank off-delay fires before
> the interrupt.
Not sure that could happen, some of the issues discussed in the comment above
drm_crtc_arm_vblank_event might apply though.
--
Earthling Michel Dänzer \ GNOME / Xwayland / Mesa developer
https://redhat.com \ Libre software enthusiast
