Re: -EPROBE_DEFER and failed DSI panel probe

[Andrzej Hajda <a.hajda@samsung.com>]

On 16.11.2017 21:27, Eric Anholt wrote:
> Andrzej Hajda <a.hajda@samsung.com> writes:
>
>> On 15.11.2017 21:26, Eric Anholt wrote:
>>> I'm happy to have the DSI panel finally working on VC4 (just waiting on
>>> https://lists.freedesktop.org/archives/dri-devel/2017-October/156407.html),
>>> but now I've got another problem to solve.  It would be great if I could
>>> include the DSI panel in our upstream DT, so that it automatically
>>> worked when you plugged one in.  However, right now we return
>>> -EPROBE_DEFER during bind unless the panel has actually shown up.  This
>>> means that if you don't have the panel actually connected, you get this
>>> sequence at startup:
>>>
>>> [   10.719929] [drm] Initialized
>>> [   10.829510] vc4_hdmi 3f902000.hdmi: vc4-hdmi-hifi <-> 3f902000.hdmi mapping ok
>>> [   10.844043] vc4-drm soc:gpu: bound 3f902000.hdmi (ops vc4_hdmi_ops [vc4])
>>> [   10.848626] vc4-drm soc:gpu: bound 3f806000.vec (ops vc4_vec_ops [vc4])
>>> [   10.850214] vc4-drm soc:gpu: failed to bind 3f700000.dsi (ops vc4_dsi_ops [vc4]): -517
>>> [   10.856559] vc4-drm soc:gpu: master bind failed: -517
>>>
>>> [...]
>>>
>>> [   10.967718] rpi_touchscreen 3-0045: Atmel I2C read failed: -6
>>>
>>> Once the panel driver fails to probe, we never get asked to re-bind vc4,
>>> and drm_of_find_panel_or_bridge looks like it would just give us
>>> -EPROBE_DEFER again since the panel still wasn't registered.
>>>
>>> Does anyone have any suggestions for handling this?
>> I guess you should call component_add only when all required resources
>> are present(including panel), I suppose moving it to vc4_dsi_host_attach
>> should help.
> How can I decide when the panel driver has tried to probe and failed,
> versus not tried to probe yet?  find_panel_or_bridge gives me
> -EPROBE_DEFER either way.
>
>> On the other side I am curious why EPROBE_DEFER from bind does not fail
>> probing of some component (the last one probed), with proper error
>> propagation it should cause defer_probing of one of the components or
>> master, and probe/bind should be retried after panel's probe.
> The panel probe failed, though, so there's no trigger to re-probe other
> drivers.

OK, I misunderstood your problem. And after 2nd read I am not sure what
do you want to achieve exactly?

Do you want to 'hotplug' DSI panel? Or just make it working with and
without the panel. In 2nd case other paths (HDMI) should still work, I
guess.

Lets assume that you are interested in the latter case. There could be
multiple solutions more or less hacky:

1. Use connector's HPD infrastructure to signal presence of the panel,
ie. in mipi_dsi::host_(attach|detach) callback you grab the panel and
change connector status to connected|disconnected and calls
drm_kms_helper_hotplug_event, it is done this way in exynos_dsi_host_attach.

2. Check for presence of the panel's driver before registering the bus,
if not present defer probing (but I am not sure if driver's registration
will trigger deferred probing, should be checked).

This way if the panel's driver is present during mipi bus registration
and after that panel should be bound to the drivers, otherwise  it means
probe failed. This solutions requires discovering panels compatible in
DSI driver. Quite complicated and very hacky.

3. In panel's probe attach the panel to the bus before hardware probe
and detach it if the physical panel is not present. This way dsi host
callbacks will be called and can be used to discover failed probes.


Regards

Andrzej

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel