[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode
Manasi Navare
manasi.d.navare at intel.com
Mon Oct 24 22:08:48 UTC 2016
On Mon, Oct 24, 2016 at 09:12:35AM +0200, Daniel Vetter wrote:
> On Mon, Oct 24, 2016 at 9:00 AM, Manasi Navare
> <manasi.d.navare at intel.com> wrote:
> >> I guess we just need to do some additional work on top to make sure the
> >> vblank ioctl can't see invalid state. Which would then again make upfront
> >> link trainig possible ...
Thanks for the explanation. So the atomic_commit code in the driver
calls drm_crtc_send_vblank_event(crtc, crtc->state->event);, is this
what needs to be filtered to be seen by Vblank IOCTL?
> >
> > Could you share some more details on what work would need to be done
> > for vblank? Then I can investigate it a little bit more tomor during the day.
>
> So the trouble is that drm_irq.c is still from the old pre-kms days.
> Which means it deals in int pipe instead of struct drm_crtc *, among
> other things. But we can't simply switch over because some old drivers
> (pre-kms ones) still depend upon that old code. Hence we need:
>
> 1. Duplicate most of the code in drm_irq.c into a new
> drm_crtc_vblank.c, which is only used for kms drivers. And in the
> ioctl code have a DRIVER_MODESET check and either call the new kms
> version (in drm_crtc_vblank.c) or the old one (still in drm_irq.c).
What functions need to be duplicated?
Which IOCTL are we talking about here? Do you mean in the atomic_commit_tail
where we check for driver modeset, is where we should then call the new kms version
of drm_crtc_send_vblank_event()?
>
> 2. Convert the int pipe into a drm_crtc pointer in the new kms code.
> For prettiness we could (try) to do that as much as possible.
>
> 3. Grab the drm_crtc->mutex in the ioctl code to block these races.
Again which IOCTL needs to grab the drm_crtc->mutex?
What is the end goal of thsi task, what race conditions are we trying to avoid
in case of these modesets during link training failures?
Manasi
>
> -Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the Intel-gfx
mailing list