[PATCH] drm: vc4: adapt to new behaviour of drm_crtc.c

[Eric Anholt]

Andrzej Pietrasiewicz <andrzej.p at samsung.com> writes:

> When drm_crtc_init_with_planes() was orignally added
> (in drm_crtc.c, e13161af80c185ecd8dc4641d0f5df58f9e3e0af
> drm: Add drm_crtc_init_with_planes() (v2)), it only checked for "primary"
> being non-null. If that was the case, it modified primary->possible_crtcs.
>
> Then, when support for cursor planes was added
> (fc1d3e44ef7c1db93384150fdbf8948dcf949f15 drm: Allow drivers to register
> cursor planes with crtc), the same behaviour was implemented for cursor
> planes.
>
> vc4_plane_init() since its inception has passed 0xff as "possible_crtcs"
> parameter to drm_universal_plane_init(). With a change in drm_crtc.c
> (7abc7d47510c75dd984380ebf819616e574c9604 drm: don't override
> possible_crtcs for primary/cursor planes) passing 0xff results in primary's
> and cursor's possible_crtcs set to 0xff. Consequently, these planes
> (incorrectly) match many crtcs. This patch gives drm_ctc_init_with_planes()
> a chance to properly set possible_crtcs for primary and cursor planes.
>
> Signed-off-by: Andrzej Pietrasiewicz <andrzej.p at samsung.com>

Thanks for the detailed explanation!

I think the cursor's possible_crtcs is getting set in vc4_crtc.c (since
we don't pass the cursor into drm_crtc_init_with_planes()).  I was also
skeptical that there would be an actual visible bug, since our planes
aren't really attached to the CRTCs other than the CRTC putting the
plane's dlist entry into their dlist.  However, I think if you stole
CRTC 1's primary plane for CRTC 0 instead of CRTC 0's primary, the
primary plane would appear on top of the overlays and cursor of CRTC 0.

7abc7d47510c75dd984380ebf819616e574c9604 appears only in 4.10-rc*.  I
think I want to add to the commit message:

Fixes: 7abc7d47510c ("drm: don't override possible_crtcs for primary/cursor planes")

and push this to drm-misc-fixes.  drm-misc maintainers, can you confirm
that this is the right way to handle it?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 832 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20170207/bf392a33/attachment.sig>