Re: -EPROBE_DEFER and failed DSI panel probe

[Eric Anholt <eric@anholt.net>]

[-- Attachment #1.1: Type: text/plain, Size: 4659 bytes --]

Daniel Vetter <daniel@ffwll.ch> writes:

> On Mon, Nov 20, 2017 at 08:53:05AM +0100, Andrzej Hajda wrote:
>> On 18.11.2017 02:16, Eric Anholt wrote:
>> > Andrzej Hajda <a.hajda@samsung.com> writes:
>> >
>> >> 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.
>> > Yeah, the second thing.  I would like to use a single DT to describe a
>> > platform where the panel may or may not be present, so the panel driver
>> > (panel-raspberrypi-touchscreen.c) will throw an error from the I2C part
>> > of the probe or not instead of creating the DSI device and attaching the
>> > panel.
>> >
>> >> 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.
>> > This is basically what I had before all the review reworks, and the
>> > regression from this state is keeping me from merging the current driver
>> > downstream.
>> >
>> > This option is unfortunate because we'll have forced *some* output on at
>> > boot time, and then when the panel driver shows up later we don't resize
>> > the fbcon to the panel's size.
>> 
>> This issue can be solved using deffered fbdev registration, ie fbdev is
>> registered after some  connector(or specific one, up to you) becomes
>> connected.
>
> Just jumping on on this part here: Deferred fbdev probe is merged now,
> which means as long as really nothing is connected, fbdev won't force
> anything.
>
> The exception is still analog outputs where we report "unknown", in that
> case fbdev still tries to light that up right away, just in case. Not sure
> that applies to the rpi with the tv-out.

Yeah, TV-out reports unknown for us as well.

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

[-- Attachment #2: Type: text/plain, Size: 160 bytes --]

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