-EPROBE_DEFER and failed DSI panel probe

-EPROBE_DEFER and failed DSI panel probe

[Eric Anholt]

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

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?

[-- 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

Re: -EPROBE_DEFER and failed DSI panel probe

[Andrzej Hajda]

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.
Another (maybe better) solution is to look for panel after
mipi_dsi_host_register, but before component_add, and fail if the panel
is not present.

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.


Regards
Andrzej



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


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

Re: -EPROBE_DEFER and failed DSI panel probe

[Eric Anholt]

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

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.

[-- 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

Re: -EPROBE_DEFER and failed DSI panel probe

[Andrzej Hajda]

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

Re: -EPROBE_DEFER and failed DSI panel probe

[Eric Anholt]

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

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.

> 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.

Restating to see if I understand: Defer all of VC4, including its MIPI
host registration, until we see the panel driver loaded (how would one
do that?).  Then once we get reprobed with the MIPI driver present
(would that even happen?), register our MIPI bus and continue on to
component bind.  In component bind, don't defer if we don't find the
panel, because we know the panel driver had a chance to probe and attach
right away when our bus showed up.

> 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.

If the I2C driver's probe fails, what ends up freeing the panel or DSI
host driver that the I2C driver allocated when the module is unloaded?

[-- 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

Re: -EPROBE_DEFER and failed DSI panel probe

[Andrzej Hajda]

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.


>
>> 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.
> Restating to see if I understand: Defer all of VC4, including its MIPI
> host registration, until we see the panel driver loaded (how would one
> do that?). 
>  Then once we get reprobed with the MIPI driver present
> (would that even happen?), register our MIPI bus and continue on to
> component bind.  In component bind, don't defer if we don't find the
> panel, because we know the panel driver had a chance to probe and attach
> right away when our bus showed up.

Yes this is the rough idea. I have assumed you have panel on DSI bus,
but from your response it seems you have panel controlled via i2c bus
and having DSI data bus.
I am not sure if there is generic code for looking for a driver with
given compatible, I guess you should use bus_for_each_drv, for every bus
you want to support - hacky, ugly, complicated.

>
>> 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.
> If the I2C driver's probe fails, what ends up freeing the panel or DSI
> host driver that the I2C driver allocated when the module is unloaded?

The idea was to register panel, only if the panel physically exists, but
to use (or rather abuse), mipi_dsi bus attach/detach callbacks to inform
the host about panel registration trials.
But as I said it looks for me as too big abuse to both panel and host.

So finally I would stay with my 1st idea - connector's HPD.

Regards

Andrzej


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

Re: -EPROBE_DEFER and failed DSI panel probe

[Daniel Vetter]

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.

I guess it'd be lovely if we could re-plug the fbdev emulation when a new
connector shows up (at least if it's of type panel maybe), so to avoid the
dreaded "my fbcon is totally wrong" problem. I think with all the fbdev
rework and drm connector hotplug support this should be doable.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -EPROBE_DEFER and failed DSI panel probe

[Eric Anholt]

[-- 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

Re: -EPROBE_DEFER and failed DSI panel probe

[Boris Brezillon]

+Thierry and Archit for the drm_panel/panel_bridge bits.

Hi all,

I'm resurrecting this thread because Eric asked me to find a solution
to this problem :-).

On Mon, 20 Nov 2017 08:53:05 +0100
Andrzej Hajda <a.hajda@samsung.com> 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.

Well, that's not surprising since I2C is not an hotplug-friendly bus.
So, if you declare a device in the DT, and this device is not accessible
(returns I2C errors), that means there's no device at all, and there's
no reason for the I2C core to retry later.

> >>>>>
> >>>>> 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.

We could have a fake/dummy panel object that is registered to the
panel list when we know the device will never be available (because
it's simply not connected to the control bus). This way, instead of
-EPROBE_DEFER, the drm_panel layer could return -ENODEV. But still,
this alone won't solve your problem, because, AFAICT, the way the VC4
dev registration work is: "bind all components of the display pipeline,
and if there's one missing, do not register the DRM device". So, you'd
have to change that for: "only wait for mandatory elements", and then
declare the DSI panel as optional (don't know how to encode that in
the DT).

> >>>  
> >>>> 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.
> 
> 
> >  
> >> 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.  
> > Restating to see if I understand: Defer all of VC4, including its MIPI
> > host registration, until we see the panel driver loaded (how would one
> > do that?). 
> >  Then once we get reprobed with the MIPI driver present
> > (would that even happen?), register our MIPI bus and continue on to
> > component bind.  In component bind, don't defer if we don't find the
> > panel, because we know the panel driver had a chance to probe and attach
> > right away when our bus showed up.  
> 
> Yes this is the rough idea. I have assumed you have panel on DSI bus,
> but from your response it seems you have panel controlled via i2c bus
> and having DSI data bus.
> I am not sure if there is generic code for looking for a driver with
> given compatible, I guess you should use bus_for_each_drv, for every bus
> you want to support - hacky, ugly, complicated.
> 
> >  
> >> 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.  
> > If the I2C driver's probe fails, what ends up freeing the panel or DSI
> > host driver that the I2C driver allocated when the module is unloaded?  
> 
> The idea was to register panel, only if the panel physically exists, but
> to use (or rather abuse), mipi_dsi bus attach/detach callbacks to inform
> the host about panel registration trials.
> But as I said it looks for me as too big abuse to both panel and host.
> 
> So finally I would stay with my 1st idea - connector's HPD.

I went for this option and hacked the drm_panel and bridge/panel.c code
[1] to have the panel layer report whether the panel is connected or
not and let the panel_bridge layer propagate the state through its
connector implementation. It works, but I'm not sure Thierry and Archit
will like it :-).

Regards,

Boris

[1]http://code.bulix.org/iepwz6-275366
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: -EPROBE_DEFER and failed DSI panel probe

[Rob Herring]

On Wed, Nov 15, 2017 at 2:26 PM, Eric Anholt <eric@anholt.net> 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?

You can modify the live DT marking the panel disabled (updating/adding
the status property) in the rpi_touchscreen probe. Then you would need
to get the status property re-read on the panel node which I'm not
sure would happen currently. Getting this latter part working would be
useful also for cases were applying a DT overlay enables/disables a
panel.

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