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

[Rob Clark]

On Wed, Aug 26, 2015 at 1:53 PM, Ville Syrjälä
<ville.syrjala at linux.intel.com> 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 at 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 at gmail.com> wrote:
>> >> > On Wed, Aug 26, 2015 at 11:41 AM, Daniel Vetter <daniel.vetter at 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?

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