[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAD=FV=VfCWFViDE1a5-_KtH0Pfo2EnCJeo2k8MaWuRHhmMPMMA@mail.gmail.com>
Date: Fri, 29 Aug 2025 09:40:30 -0700
From: Doug Anderson <dianders@...omium.org>
To: John Ripple <john.ripple@...sight.com>
Cc: andrzej.hajda@...el.com, neil.armstrong@...aro.org, rfoss@...nel.org,
maarten.lankhorst@...ux.intel.com, mripard@...nel.org, tzimmermann@...e.de,
airlied@...il.com, simona@...ll.ch, Laurent.pinchart@...asonboard.com,
jonas@...boo.se, jernej.skrabec@...il.com, dri-devel@...ts.freedesktop.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: break probe dependency loop
Hi,
On Wed, Aug 20, 2025 at 8:24 AM John Ripple <john.ripple@...sight.com> wrote:
>
> The commit c3b75d4734cb ("drm/bridge: sn65dsi86: Register and attach our
> DSI device at probe") was intended to prevent probe ordering issues and
> created the ti_sn_attach_host function.
>
> In practice, I found the following when using the nwl-dsi driver:
> - ti_sn_bridge_probe happens and it adds the i2c bridge. Then
> ti_sn_attach_host runs (in the ti_sn_bridge_probe function) and fails to
> find the dsi host which then returns to ti_sn_bridge_probe and removes
> the i2c bridge because of the failure.
> - The nwl_dsi_probe then runs and adds dsi host to the host list and then
> looks for the i2c bridge, which is now gone, so it fails. This loop
> continues for the entire boot sequence.
Which i2c bridge are you talking about? You mean the one created by
i2c_add_adapter() in drm_dp_aux_register()? I guess I'm confused about
why the DSI probe routine would even be looking for that adapter.
In any case, I don't _think_ your patch is valid. Specifically, if you
notice ti_sn_attach_host() can return "-EPROBE_DEFER". That's a valid
error code to return from a probe routine but I don't think it's a
valid error code to return from a bridge attach function, is it?
Powered by blists - more mailing lists