DSI panel not working on -next

DSI panel not working on -next

[Alexandre Courbot]

Hi Thierry,

I noticed that the DSI panel of SHIELD (tegra114-roth) was not brought 
up on -next. I have bisected the following commit as introducing that 
behavior:

commit f4c5cf88fbd50e4779042268947b2e2f90c20484
Author: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
Date:   Thu Dec 18 15:29:14 2014 +0100

     gpu: host1x: Provide a proper struct bus_type


With and without this patch, the DSI panel is probed, but the stack 
trace in the probe() function is different:


Working case:
[    2.045189] [<c02f4cc8>] (panel_simple_probe) from [<c02f4e6c>] 
(panel_simple_dsi_probe+0x2c/0x64)
[    2.054159] [<c02f4e6c>] (panel_simple_dsi_probe) from [<c0303618>] 
(driver_probe_device+0x108/0x23c)
[    2.063413] [<c0303618>] (driver_probe_device) from [<c0301c84>] 
(bus_for_each_drv+0x64/0x98)
[    2.072027] [<c0301c84>] (bus_for_each_drv) from [<c03034e0>] 
(device_attach+0x74/0x88)
[    2.080126] [<c03034e0>] (device_attach) from [<c0302bcc>] 
(bus_probe_device+0x84/0xa8)
[    2.088227] [<c0302bcc>] (bus_probe_device) from [<c0300fac>] 
(device_add+0x398/0x520)
[    2.096248] [<c0300fac>] (device_add) from [<c02e35cc>] 
(mipi_dsi_host_register+0xb8/0x198)
[    2.104698] [<c02e35cc>] (mipi_dsi_host_register) from [<c02f0ad4>] 
(tegra_dsi_probe+0x2dc/0x4d4)
[    2.113611] [<c02f0ad4>] (tegra_dsi_probe) from [<c0304d74>] 
(platform_drv_probe+0x44/0xa4)
[    2.122031] [<c0304d74>] (platform_drv_probe) from [<c0303618>] 
(driver_probe_device+0x108/0x23c)
[    2.130991] [<c0303618>] (driver_probe_device) from [<c0301c84>] 
(bus_for_each_drv+0x64/0x98)
[    2.139608] [<c0301c84>] (bus_for_each_drv) from [<c03034e0>] 
(device_attach+0x74/0x88)
[    2.147706] [<c03034e0>] (device_attach) from [<c0302bcc>] 
(bus_probe_device+0x84/0xa8)
[    2.155806] [<c0302bcc>] (bus_probe_device) from [<c0302fec>] 
(deferred_probe_work_func+0x64/0x94)
[    2.164863] [<c0302fec>] (deferred_probe_work_func) from [<c0038c5c>] 
(process_one_work+0x120/0x330)
[    2.174033] [<c0038c5c>] (process_one_work) from [<c00394cc>] 
(worker_thread+0x4c/0x474)
[    2.182193] [<c00394cc>] (worker_thread) from [<c003d548>] 
(kthread+0xdc/0xf4)
[    2.189505] [<c003d548>] (kthread) from [<c000e8c0>] 
(ret_from_fork+0x14/0x34)


Failure case:
[    1.540582] [<c03067f0>] (panel_simple_probe) from [<c0306994>] 
(panel_simple_dsi_probe+0x2c/0x64)
[    1.549731] [<c0306994>] (panel_simple_dsi_probe) from [<c030ced8>] 
(driver_probe_device+0x108/0x23c)
[    1.559145] [<c030ced8>] (driver_probe_device) from [<c030d0dc>] 
(__driver_attach+0x8c/0x90)
[    1.567763] [<c030d0dc>] (__driver_attach) from [<c030b498>] 
(bus_for_each_dev+0x6c/0xa0)
[    1.576122] [<c030b498>] (bus_for_each_dev) from [<c030c700>] 
(bus_add_driver+0x148/0x1f0)
[    1.584565] [<c030c700>] (bus_add_driver) from [<c030d6e0>] 
(driver_register+0x78/0xf8)
[    1.592723] [<c030d6e0>] (driver_register) from [<c09792c8>] 
(panel_simple_init+0x28/0x34)
[    1.601160] [<c09792c8>] (panel_simple_init) from [<c0008b30>] 
(do_one_initcall+0x8c/0x1d4)
[    1.609697] [<c0008b30>] (do_one_initcall) from [<c095ddc8>] 
(kernel_init_freeable+0x144/0x1e4)
[    1.618577] [<c095ddc8>] (kernel_init_freeable) from [<c0675da8>] 
(kernel_init+0x8/0xe8)
[    1.626850] [<c0675da8>] (kernel_init) from [<c000e8c0>] 
(ret_from_fork+0x14/0x34)


i.e. with f4c5cf88fbd, the panel is not probed from tegra_dsi_probe() 
anymore, which means DSI remains without a valid connector:

[    1.378513] [drm] Initialized drm 1.1.0 20060810
[    1.384564] 54300000.dsi supply avdd-dsi-csi not found, using dummy 
regulator
[    1.396394] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[    1.403021] [drm] No driver support for vblank timestamp query.
[    1.409080] drm drm: No connectors reported connected with modes
[    1.415128] [drm] Cannot find any crtc or sizes - going 1024x768


Are you aware of this? Does it affect other DSI panels? Does SHIELD's DT 
need an update of some sort?

Cheers,
Alex.

Re: DSI panel not working on -next

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 1806 bytes --]

On Fri, Feb 13, 2015 at 03:29:09PM +0900, Alexandre Courbot wrote:
> Hi Thierry,
> 
> I noticed that the DSI panel of SHIELD (tegra114-roth) was not brought up on
> -next. I have bisected the following commit as introducing that behavior:
> 
> commit f4c5cf88fbd50e4779042268947b2e2f90c20484
> Author: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> Date:   Thu Dec 18 15:29:14 2014 +0100
> 
>     gpu: host1x: Provide a proper struct bus_type
> 
> 
> With and without this patch, the DSI panel is probed, but the stack trace in
> the probe() function is different:

This shouldn't make much of a difference, really, since we're attaching
to the panel only during mipi_dsi_host_register() anyway. And the panel
device can't exist earlier than that because mipi_dsi_host_register()
will instantiate it. Still...

> i.e. with f4c5cf88fbd, the panel is not probed from tegra_dsi_probe()
> anymore, which means DSI remains without a valid connector:
> 
> [    1.378513] [drm] Initialized drm 1.1.0 20060810
> [    1.384564] 54300000.dsi supply avdd-dsi-csi not found, using dummy
> regulator
> [    1.396394] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [    1.403021] [drm] No driver support for vblank timestamp query.
> [    1.409080] drm drm: No connectors reported connected with modes
> [    1.415128] [drm] Cannot find any crtc or sizes - going 1024x768

... the failing log here does indicate that there is no panel, so I'll
need to investigate why that's happening.

> Are you aware of this? Does it affect other DSI panels? Does SHIELD's DT
> need an update of some sort?

I'm almost certain that I've tested this on at least Dalmore and I don't
see any differences that could be causing this. I'll look into it.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: DSI panel not working on -next

[Alexandre Courbot]

On 02/13/2015 06:55 PM, Thierry Reding wrote:
> On Fri, Feb 13, 2015 at 03:29:09PM +0900, Alexandre Courbot wrote:
>> Hi Thierry,
>>
>> I noticed that the DSI panel of SHIELD (tegra114-roth) was not brought up on
>> -next. I have bisected the following commit as introducing that behavior:
>>
>> commit f4c5cf88fbd50e4779042268947b2e2f90c20484
>> Author: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
>> Date:   Thu Dec 18 15:29:14 2014 +0100
>>
>>      gpu: host1x: Provide a proper struct bus_type
>>
>>
>> With and without this patch, the DSI panel is probed, but the stack trace in
>> the probe() function is different:
>
> This shouldn't make much of a difference, really, since we're attaching
> to the panel only during mipi_dsi_host_register() anyway. And the panel
> device can't exist earlier than that because mipi_dsi_host_register()
> will instantiate it. Still...
>
>> i.e. with f4c5cf88fbd, the panel is not probed from tegra_dsi_probe()
>> anymore, which means DSI remains without a valid connector:
>>
>> [    1.378513] [drm] Initialized drm 1.1.0 20060810
>> [    1.384564] 54300000.dsi supply avdd-dsi-csi not found, using dummy
>> regulator
>> [    1.396394] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>> [    1.403021] [drm] No driver support for vblank timestamp query.
>> [    1.409080] drm drm: No connectors reported connected with modes
>> [    1.415128] [drm] Cannot find any crtc or sizes - going 1024x768
>
> ... the failing log here does indicate that there is no panel, so I'll
> need to investigate why that's happening.
>
>> Are you aware of this? Does it affect other DSI panels? Does SHIELD's DT
>> need an update of some sort?
>
> I'm almost certain that I've tested this on at least Dalmore and I don't
> see any differences that could be causing this. I'll look into it.

Thanks - please don't hesitate to ask me to run some more tests (or just 
to try and fix it by myself) if this can save you time.

Re: DSI panel not working on -next

[Thierry Reding]

[-- Attachment #1: Type: text/plain, Size: 4214 bytes --]

On Fri, Feb 13, 2015 at 07:18:11PM +0900, Alexandre Courbot wrote:
> On 02/13/2015 06:55 PM, Thierry Reding wrote:
> >On Fri, Feb 13, 2015 at 03:29:09PM +0900, Alexandre Courbot wrote:
> >>Hi Thierry,
> >>
> >>I noticed that the DSI panel of SHIELD (tegra114-roth) was not brought up on
> >>-next. I have bisected the following commit as introducing that behavior:
> >>
> >>commit f4c5cf88fbd50e4779042268947b2e2f90c20484
> >>Author: Thierry Reding <treding-DDmLM1+adcrQT0dZR+AlfA@public.gmane.org>
> >>Date:   Thu Dec 18 15:29:14 2014 +0100
> >>
> >>     gpu: host1x: Provide a proper struct bus_type
> >>
> >>
> >>With and without this patch, the DSI panel is probed, but the stack trace in
> >>the probe() function is different:
> >
> >This shouldn't make much of a difference, really, since we're attaching
> >to the panel only during mipi_dsi_host_register() anyway. And the panel
> >device can't exist earlier than that because mipi_dsi_host_register()
> >will instantiate it. Still...
> >
> >>i.e. with f4c5cf88fbd, the panel is not probed from tegra_dsi_probe()
> >>anymore, which means DSI remains without a valid connector:
> >>
> >>[    1.378513] [drm] Initialized drm 1.1.0 20060810
> >>[    1.384564] 54300000.dsi supply avdd-dsi-csi not found, using dummy
> >>regulator
> >>[    1.396394] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> >>[    1.403021] [drm] No driver support for vblank timestamp query.
> >>[    1.409080] drm drm: No connectors reported connected with modes
> >>[    1.415128] [drm] Cannot find any crtc or sizes - going 1024x768
> >
> >... the failing log here does indicate that there is no panel, so I'll
> >need to investigate why that's happening.
> >
> >>Are you aware of this? Does it affect other DSI panels? Does SHIELD's DT
> >>need an update of some sort?
> >
> >I'm almost certain that I've tested this on at least Dalmore and I don't
> >see any differences that could be causing this. I'll look into it.
> 
> Thanks - please don't hesitate to ask me to run some more tests (or just to
> try and fix it by myself) if this can save you time.

Let me try to summarize what we discussed on IRC earlier. The root cause
here is that the panel is probed as part of the mipi_dsi_host_register()
call. In some cases the panel driver may defer probe itself, therefore
causing the DSI output to end up with no attached panel. The KMS fbdev
emulation will then assume a default resolution of 1024x768.

The panel will at some point successfully probe and attach to the host,
which should cause things to work normally for anything that's able to
set a mode by itself. So running modetest or weston should still work,
even if fbcon doesn't.

I see three possible solutions:

  - Defer in the DSI output's ->probe() if after registering the host
    there is no panel attached. That should delay the initialization of
    fbdev until a panel is detected.

    This is somewhat ugly, but I think it would be the easiest fix for
    the regression until a proper solution is implemented.

  - Modify the driver to cope with "hot-pluggable" panels. This isn't
    really going to fix the regression because the outcome will be the
    same. In fact, for DSI panels are already hot-pluggable.

  - Implement a mechanism to tear down and setup from scratch the fbdev
    when the first output is added. So at driver load time the fbdev
    code would skip fbdev initialization if no connected output was
    detected. Once any of the outputs is connected, the native mode of
    that output can be used to create fbdev. That should be enough to
    fix the problem for panels that defer probe, but I think an even
    more generic solution would be to go a step further and completely
    tear down fbdev when the last connected output goes away and then
    create it again when any of the outputs is connected again.

    I'm told that it's very difficult to resize fbcon, but I know that
    at least with the Tegra driver it is properly torn down and set up
    again during a driver unload/load cycle, so it must be possible to
    do this more granularly for fbdev only.

Thierry

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]