Le 03/10/24 - 18:29, Ville Syrjälä a écrit : > On Thu, Oct 03, 2024 at 05:07:35PM +0200, Louis Chauvet wrote: > > > > > > > diff --git a/drivers/gpu/drm/vkms/vkms_crtc.c b/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > index a40295c18b48..780681ea77e4 100644 > > > > > --- a/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > +++ b/drivers/gpu/drm/vkms/vkms_crtc.c > > > > > @@ -64,7 +64,7 @@ static int vkms_enable_vblank(struct drm_crtc *crtc) > > > > > struct drm_vblank_crtc *vblank = drm_crtc_vblank_crtc(crtc); > > > > > struct vkms_output *out = drm_crtc_to_vkms_output(crtc); > > > > > > > > > > - drm_calc_timestamping_constants(crtc, &crtc->mode); > > > > > + drm_calc_timestamping_constants(crtc, &crtc->legacy.mode); > > > > > > > > drm_calc_timestamping_constants(crtc, &crtc->state->mode); > > > > > > This one doesn't look safe. You want to call that during your atomic > > > commit already. > > > > > > > This was already not safe with the previous implementation? Or it is only > > unsafe because now I use state->mode instead of legacy.mode? > > Yeah, if you want to look at obj->state then you need the corresponding > lock. > > obj->state is also not necessarily the correct state you want because > a parallel commit could have already swapped in a new state but the > hardware is still on the old state. > > Basically 99.9% of code should never even look at obj->state, and > instead should always use the for_each_new_<obj>_in_state() > and drm_atomic_get_new_<obj>_state() stuff. Currently that is a > pipe dream though because a lot of drivers haven't been fixed to > do things properly. If we ever manage to fix everything then we > could remove the stall hacks from drm_atomic_helper_swap_state() > and allow a commit pipeline of arbitrary length. > > > > > After inspecting the code, I think I don't need to call it as: > > > > In `vkms_atomic_commit_tail` (used in > > `@vkms_mode_config_helpers.atomic_commit_tail`), we call > > `drm_atomic_helper_commit_modeset_disables`, which call > > `drm_atomic_helper_calc_timestamping_constants` which call > > `drm_calc_timestamping_constants` for every CRTC. > > Slightly odd place for it, but I think that's just because it was > originally part of drm_atomic_helper_update_legacy_modeset_state() > and I didn't bother looking for a better home for it when I split > it out. But seems like it should work fine as is. I just send a patch for this! Thanks for your help! [1]:https://lore.kernel.org/all/20241003-remove-legacy-v1-1-0b7db1f1a1a6@xxxxxxxxxxx/ > > > > I tested kms_vblank, all of them are SUCCESS/SKIP, do you know other tests > > that can trigger bugs? > > You would explicitly have to race commits against vblank_enable. > Could of course sprinkle sleep()s around to widen the race window > if you're really keen to hit it. > > -- > Ville Syrjälä > Intel -- Louis Chauvet, Bootlin Embedded Linux and Kernel engineering https://bootlin.com
