[Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode
Daniel Vetter
daniel at ffwll.ch
Tue Oct 25 06:35:34 UTC 2016
On Mon, Oct 24, 2016 at 02:38:17PM -0400, Sean Paul wrote:
> On Mon, Oct 24, 2016 at 3:12 AM, Daniel Vetter <daniel at ffwll.ch> 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 ...
> >>
> >> 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.
>
> Why duplicate all of this code? That seems a bit wasteful.
>
> Can't we just add the inverse of drm_crtc_pipe() (coincidentally, I
> also suggested we introduce this function in "drm: zte: add initial
> vou drm driver"), and use those to map between pipe and crtc where
> appropriate? The crtc locks could be acquired/dropped based on
> DRIVER_MODESET in drm_irq.c
Only if you have a DRIVER_MODESET. For DRIVER_LEGACY this code all still
needs to work, without there ever being a drm_crtc. If you try to squeeze
kms and non-kms paths into one function that will be seriously ugly, and a
complete maintenance pain. Copypasting is imo the sound approach here.
That way we can let the old non-kms code rot unchanged until it's really
dead.
> Unrelated to the vblank discussion: This functionality is pretty
> similar to what happens on suspend/resume. Any chance we can share?
Hm, what do you mean?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the Intel-gfx
mailing list