Re: [PATCH v3] drm/mediatek: mtk_dsi: Avoid EPROBE_DEFER loop with external bridge

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxx> 於
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@xxxxxxxxxx # v5.15+

Regards,
Chun-Kuang.

Signed-off-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@xxxxxxxxxxxxx>
Reviewed-by: Andrzej Hajda <andrzej.hajda@xxxxxxxxx>
Reviewed-by: Jagan Teki <jagan@xxxxxxxxxxxxxxxxxxxx>

---
  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



[Index of Archives]     [Linux DRI Users]     [Linux Intel Graphics]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Linux Kernel]     [Linux SCSI]     [XFree86]
  Powered by Linux