Re: [PATCH v3 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

2023-09-05 Thread AngeloGioacchino Del Regno
Il 05/09/23 09:58, Michael Walle ha scritto: At this point, I think that it would be sane to change this function to return a signed type, so that we can return -ENOENT if we couldn't find any DDP path (so, if we couldn't find any possible crtc). Fair enough, but should it be part of the fixes

Re: [PATCH v3 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

2023-09-05 Thread Michael Walle
At this point, I think that it would be sane to change this function to return a signed type, so that we can return -ENOENT if we couldn't find any DDP path (so, if we couldn't find any possible crtc). Fair enough, but should it be part of the fixes commit or a different one? -michael

Re: [PATCH v3 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

2023-09-05 Thread AngeloGioacchino Del Regno
Il 01/09/23 19:45, Michael Walle ha scritto: 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

[PATCH v3 2/2] drm/mediatek: dpi/dsi: fix possible_crtcs calculation

2023-09-01 Thread Michael Walle
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 availab