On Wed, Aug 26, 2015 at 1:53 PM, Ville Syrjälä <ville.syrjala@xxxxxxxxxxxxxxx> wrote: > 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? or, well, could block.. but anyways, the more realistic scenario for 2x dsi is dual-dsi to single panel w/ the two CRTC's locked in sync.. BR, -R > -- > Ville Syrjälä > Intel OTC _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
