Hi,
> mtk_drm_find_possible_crtc_by_comp() assumed that the main path will
> always have the CRTC with id 0, the ext id 1 and the third id 2. This
> is only true if the paths are all available. But paths are optional
> (see
> also comment in mtk_drm_kms_init()), e.g. the main path might not be
> enabled or available at all. Then the CRTC IDs will shift one up, e.g.
> ext will be 0 and the third path will be 1.
>
> To fix that, dynamically calculate the IDs by the presence of the
> paths.
>
> While at it, make the return code a signed one and return -ENOENT if no
> path is found and handle the error in the callers.
>
> Fixes: 5aa8e7647676 ("drm/mediatek: dpi/dsi: Change the getting
> possible_crtc way")
> Suggested-by: Nícolas F. R. A. Prado <nfrapr...@collabora.com>
> Signed-off-by: Michael Walle <mwa...@kernel.org>
> Reviewed-by: Nícolas F. R. A. Prado <nfrapr...@collabora.com>
> Tested-by: Nícolas F. R. A. Prado <nfrapr...@collabora.com>
Is there anything wrong with these two patches? They are now lingering
around for more than two months.
Unfortunately, patch 2/2 won't apply anymore because of commit
01389b324c97 ("drm/mediatek: Add connector dynamic selection
capability). And I'm a bit puzzled for what the crtc_id is used
there because I guess it will have the same problem this patch
fixes.
Please base on the latest kernel version to fix.
Of course, but the question is how to fix it. Maybe Jason-JH.Lin
can help here.
In any case, please pick patch 1/2, it's independent of the second
patch and should still apply.
-michael