[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20250902162246.4143785-1-john.ripple@keysight.com>
Date: Tue, 2 Sep 2025 10:22:46 -0600
From: John Ripple <john.ripple@...sight.com>
To: dianders@...omium.org
Cc: Laurent.pinchart@...asonboard.com, airlied@...il.com,
andrzej.hajda@...el.com, dri-devel@...ts.freedesktop.org,
jernej.skrabec@...il.com, john.ripple@...sight.com, jonas@...boo.se,
linux-kernel@...r.kernel.org, maarten.lankhorst@...ux.intel.com,
mripard@...nel.org, neil.armstrong@...aro.org, rfoss@...nel.org,
simona@...ll.ch, tzimmermann@...e.de
Subject: Re: [PATCH 2/2] drm/bridge: ti-sn65dsi86: break probe dependency loop
Hi,
>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.
The i2c bridge I was seeing was created by the drm_bridge_add() function
in the ti_sn_bridge_probe() function. Without moving the ti_sn_attach_host()
function out of the ti_sn_bridge_probe() function I kept getting stuck in a
loop during boot where the bridge would never come up. It's possible this
could be a unique interaction with the hardware I'm using and the nwl-dsi
driver.
>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?
What error code would you suggest?
Powered by blists - more mailing lists