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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx