Re: [PATCH] drm/omap: dsi: Fix deferred probe warnings

[Tomi Valkeinen <tomi.valkeinen@ideasonboard.com>]

On 13/09/2023 10:37, Tony Lindgren wrote:
> * Laurent Pinchart <laurent.pinchart@ideasonboard.com> [230412 11:59]:
>> On Wed, Apr 12, 2023 at 11:55:34AM +0300, Tomi Valkeinen wrote:
>>> On 12/04/2023 11:50, Laurent Pinchart wrote:
>>>> Hi Tony,
>>>>
>>>> Thank you for the patch.
>>>>
>>>> On Wed, Apr 12, 2023 at 10:39:53AM +0300, Tony Lindgren wrote:
>>>>> We may not have dsi->dsidev initialized during probe, and that can
>>>>> lead into various dsi related warnings as omap_dsi_host_detach() gets
>>>>> called with dsi->dsidev set to NULL.
>>>>>
>>>>> The warnings can be "Fixed dependency cycle(s)" followed by a
>>>>> WARNING: CPU: 0 PID: 787 at drivers/gpu/drm/omapdrm/dss/dsi.c:4414.
>>>>
>>>> How can this happen ? I assume .detach() can't be called without a
>>>> priori successful call to .attach(), that that sets dsi->dsidev.
>>>
>>> I had a quick look, and the driver calls mipi_dsi_host_register() in
>>> probe, and mipi_dsi_host_unregister() in remove.
>>>
>>> mipi_dsi_host_unregister() always calls mipi_dsi_detach(), but I don't
>>> think mipi_dsi_host_register() always calls attach, which happens later
>>> when the peripheral probes.
>>
>> Is this something that should be addressed in the DRM MIPI DSI helpers,
>> to only detach after an attach ?
> 
> Tomi, any comments on detach after attach?

I sent a comment to the patch.

As Laurent said, I think this really should be fixed in the framework 
side. Calling detach in drivers without attach feels just plain wrong.

However, I don't see any harm in the patch (but perhaps some changes 
needed as per my comments), and it will fix the issue for omapdrm, until 
someone has the time and energy to look at a real fix.

  Tomi