Re: [PATCH] drm/atomic: refuse changing CRTC for planes directly

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Wed, Aug 26, 2015 at 01:38:36PM -0400, Rob Clark wrote:
> On Wed, Aug 26, 2015 at 12:30 PM, Ville Syrjälä
> <ville.syrjala@linux.intel.com> wrote:
> > On Wed, Aug 26, 2015 at 12:07:30PM -0400, Rob Clark wrote:
> >> On Wed, Aug 26, 2015 at 12:03 PM, Rob Clark <robdclark@gmail.com> wrote:
> >> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> >> >> Very strictly speaking this is possible if you have special hw and
> >> >> genlocked CRTCs. In general switching a plane between two active CRTC
> >> >> just won't work so well and is probably not tested at all. Just forbid
> >> >> it.
> >> >
> >> > So, I expect msm should actually be able to do this w/ dual-dsi (where
> >> > we are using two CRTC's, w/ synchronized flushes)..
> >> >
> >> > Probably someone who has a dual-dsi panel should actually test that to
> >> > confirm.  But it seems like it should work.  Maybe we need something
> >> > in 'struct drm_crtc' so core can realize that two CRTC's are locked
> >> > together..
> >>
> >> oh, and for most drivers, switching plane between CRTCs without an
> >> off-cycle would probably also work for DSI cmd mode..
> >
> > You'd need to wait for any ongoing transfer on the old crtc to finish
> > before moving the plane. So that's not really any different than the
> > driver doing the dance with a vblank wait on a video mode display.
> 
> except that update would need to block from previous xfer anyways, so
> there isn't really a race w/ frame n+1 like there would be with video
> mode..

Why would it block if it's on a separate crtc?

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx