Messages in this thread | | | Subject | Re: [PATCH v3] drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with external bridge | From | AngeloGioacchino Del Regno <> | Date | Fri, 28 Jan 2022 10:13:32 +0100 |
| |
Il 27/01/22 16:46, AngeloGioacchino Del Regno ha scritto: > Il 27/01/22 16:21, Chun-Kuang Hu ha scritto: >> Hi, Angelo: >> >> AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> 於 >> 2022年1月27日 週四 下午10:36寫道: >>> >>> DRM bridge drivers are now attaching their DSI device at probe time, >>> which requires us to register our DSI host in order to let the bridge >>> to probe: this recently started producing an endless -EPROBE_DEFER >>> loop on some machines that are using external bridges, like the >>> parade-ps8640, found on the ACER Chromebook R13. >>> >>> Now that the DSI hosts/devices probe sequence is documented, we can >>> do adjustments to the mtk_dsi driver as to both fix now and make sure >>> to avoid this situation in the future: for this, following what is >>> documented in drm_bridge.c, move the mtk_dsi component_add() to the >>> mtk_dsi_ops.attach callback and delete it in the detach callback; >>> keeping in mind that we are registering a drm_bridge for our DSI, >>> which is only used/attached if the DSI Host is bound, it wouldn't >>> make sense to keep adding our bridge at probe time (as it would >>> be useless to have it if mtk_dsi_ops.attach() fails!), so also move >>> that one to the dsi host attach function (and remove it in detach). >>> >>> Fixes: 209264a85707 ("drm/bridge: Document the probe issue with MIPI-DSI bridges") >> >> The fixed tag should indicate the patch which cause the bug, but why a >> patch just adding document would cause bug? >> So no any patch cause bug? This patch just want to prevent a possible bug? >> > > I think you've missed my previous message on v2, so I will paste it here: > > unfortunately I couldn't find a valid commit for a Fixes tag. This > started being an issue at some point, when the DRM was changed to > adhere to the documented probe sequence: the MediaTek DSI driver was > not the only one that got broken/affected by these changes. > > If you have any advice on which commit should be tagged, I'm open for > any kind of suggestion. > > > I tried to check on other drivers which got fixed for the same behavior, > for example drm/msm, but none of them had a Fixes tag. > When the DRM got changed to adhere to this sequence, some drm/bridge > drivers were also changed; this has created some incompatibilities with > some drm drivers, including drm/msm and drm/mediatek. > > This commit is not fixing a latent bug that was introduced in drm/mediatek > but rather one that was induced by the new, fixed, probe flow that got > recently documented - and to which drivers should adhere; failing to adhere > to that will produce an endless -EPROBE_DEFER loop, due to other drivers > (as mentioned, for example drm/bridge drivers) having been changed to use > that probe sequence. > > > Regards, > Angelo >
I've been thinking about another solution to this issue.
Would it be fine if I send a v4 that removes the Fixes tag, but adds the following?
Cc: stable@kernel.org # v5.15+
>> Regards, >> Chun-Kuang. >> >>> Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com> >>> Reviewed-by: Andrzej Hajda <andrzej.hajda@intel.com> >>> Reviewed-by: Jagan Teki <jagan@amarulasolutions.com> >>> >>> --- >>> drivers/gpu/drm/mediatek/mtk_dsi.c | 167 +++++++++++++++-------------- >>> 1 file changed, 84 insertions(+), 83 deletions(-) >>>
-- AngeloGioacchino Del Regno Software Engineer
Collabora Ltd. Platinum Building, St John's Innovation Park, Cambridge CB4 0DS, UK Registered in England & Wales, no. 5513718
| |