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@xxxxxxxxxxxxxxx> 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@xxxxxxxxx> wrote: > >> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter <daniel.vetter@xxxxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
