Hi,
Am 19.11.2018 um 15:18 schrieb Sebastian Reichel sre@kernel.org:
Hi,
On Mon, Nov 19, 2018 at 02:55:35PM +0100, H. Nikolaus Schaller wrote:
Am 19.11.2018 um 14:11 schrieb Sebastian Reichel sre@kernel.org: On Mon, Nov 19, 2018 at 02:38:38PM +0200, Tomi Valkeinen wrote:
On 19/11/18 14:29, H. Nikolaus Schaller wrote:
My series:
patch 1: Simple cleanup patch 2-4: General DSI fixes for the kernel changes in 4.20-rc1. I think they are also relevant for DSI video mode panels. patch 5-6: Only relevant for DSI command mode. It's not really DSI specific and should not make a difference on any outputs not setting OMAP_DSS_DISPLAY_CAP_MANUAL_UPDATE.
-- Sebastian
but the video mode panel doesn't call enable(). It did up to 4.19.0 and stopped in 4.20-rc1.
Ok.
So how can I debug the panel->enable()? Where should it be called from dss core? Then I could check the conditions to call enable().
This is called in omap_encoder_enable(). For debugging I suggest to add "drm.debug=0xf" kernel argument. "drm/omap: don't check dispc timings for DSI" fixes a similar problem for panel-dsi-cm.
I have checked that and it looks all reasonable and I did enable the same on the 4.19 kernel and they are basically the same (some not obviously significant diffs in sequence or connector numbers).
The main difference is that after
[ 10.811910] [drm:omap_fbdev_create [omapdrm]] allocated 720x1280 fb
there is no more drm activity on 4.20-rc3 but on 4.19 there is. And there, the panel enable() is called.
Another diff is
4.20: [drm:pdev_probe [omapdrm]] registered 4 planes, 2 crtcs, 2 encoders and 2 connectors 4.19: [drm:pdev_probe [omapdrm]] registered 4 planes, 2 crtcs/encoders/connectors
but I am not sure if this is just a cosmetic change or if encoders/connectors are missing.
So I have no more ideas how to find out why the panel is not becoming enabled.
BR and thanks, Nikolaus