Re: [Intel-gfx] [PATCH 1/5] drm: Add atomic helper to redo a modeset on current mode

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx> wrote:
> > On Mon, Oct 24, 2016 at 9:00 AM, Manasi Navare
> > <manasi.d.navare@xxxxxxxxx> 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
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/dri-devel




[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux