Re: [REGRESSION] omapdrm/N900 display broken

2020-11-27 Thread Ivaylo Dimitrov

Hi,

On 27.11.20 г. 19:30 ч., Tomi Valkeinen wrote:

On 27/11/2020 17:37, Ivaylo Dimitrov wrote:


With 5.9.11 and the patch on top, n900 boots fine, albeit display remains 
blank, could be related to
brightness, we're still investigating.


Ok. A DSS regdump for a working version and the latest one would be good too. 
There's a omapdss
debugfs dir, with dss, dispc and clk files which are of interest here.



It turned out to be a long standing bug in the panel driver, with the 
bellow fix it works fine:



diff --git a/drivers/gpu/drm/panel/panel-sony-acx565akm.c 
b/drivers/gpu/drm/panel/panel-sony-acx565akm.c

index fc6a7e451abe..304267f7849a
--- a/drivers/gpu/drm/panel/panel-sony-acx565akm.c
+++ b/drivers/gpu/drm/panel/panel-sony-acx565akm.c
@@ -629,7 +629,7 @@ static int acx565akm_probe(struct spi_device *spi)
lcd->spi = spi;
mutex_init(>mutex);

-   lcd->reset_gpio = devm_gpiod_get(>dev, "reset", GPIOD_OUT_LOW);
+   lcd->reset_gpio = devm_gpiod_get(>dev, "reset", 
GPIOD_OUT_HIGH);

if (IS_ERR(lcd->reset_gpio)) {
dev_err(>dev, "failed to get reset GPIO\n");
return PTR_ERR(lcd->reset_gpio);

Proper patch will follow.

Thanks,
Ivo


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-27 Thread Tomi Valkeinen
On 27/11/2020 17:37, Ivaylo Dimitrov wrote:

> With 5.9.11 and the patch on top, n900 boots fine, albeit display remains 
> blank, could be related to
> brightness, we're still investigating.

Ok. A DSS regdump for a working version and the latest one would be good too. 
There's a omapdss
debugfs dir, with dss, dispc and clk files which are of interest here.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-27 Thread Ivaylo Dimitrov

Hi,

On 27.11.20 г. 15:10 ч., Ivaylo Dimitrov wrote:



On 27.11.20 г. 13:45 ч., Tomi Valkeinen wrote:

On 27/11/2020 01:17, Ivaylo Dimitrov wrote:

Hi Tomi,

On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:

Hi Aaro, Ivaylo,

On 24/11/2020 23:03, Ivaylo Dimitrov wrote:

Is there any progress on the issue? I tried 5.9.1 and still nothing 
displayed.


Can you test the attached patch?



With this patch I don't see oops that Aaro reported, so:

Tested-by: Ivaylo Dimitrov 

Seems to fix the particular issue, however, now we get another oops. 
As this is not upstream kernel

but one with PVR related patches, I will try again with vanilla 5.9.

Just in case oops rings any bells (the line in question is
https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801) 



Do the PVR patches touch omapdrm? The call stack looks like normal 
boot time probing stuff, not

something happening later (possibly from PVR).



pvr driver is not even enabled in that particular config, however, I see 
"HACK: drm/omap: Add omapdrm plugin API" patch in the tree that touches 
omap-gem.c, I don't really want to just create some noise for problems 
that are created by out-of-tree patches. And yeah, it looks like a 
normal boot time probing stuff. As soon as I have some spare time 
(hopefully later today) I will try vanilla 5.9.x with 
omap2plus_defconfig and will report.




With 5.9.11 and the patch on top, n900 boots fine, albeit display 
remains blank, could be related to brightness, we're still investigating.


Thanks and regards,
Ivo


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-27 Thread Ivaylo Dimitrov




On 27.11.20 г. 13:45 ч., Tomi Valkeinen wrote:

On 27/11/2020 01:17, Ivaylo Dimitrov wrote:

Hi Tomi,

On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:

Hi Aaro, Ivaylo,

On 24/11/2020 23:03, Ivaylo Dimitrov wrote:


Is there any progress on the issue? I tried 5.9.1 and still nothing displayed.


Can you test the attached patch?



With this patch I don't see oops that Aaro reported, so:

Tested-by: Ivaylo Dimitrov 

Seems to fix the particular issue, however, now we get another oops. As this is 
not upstream kernel
but one with PVR related patches, I will try again with vanilla 5.9.

Just in case oops rings any bells (the line in question is
https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801)


Do the PVR patches touch omapdrm? The call stack looks like normal boot time 
probing stuff, not
something happening later (possibly from PVR).



pvr driver is not even enabled in that particular config, however, I see 
"HACK: drm/omap: Add omapdrm plugin API" patch in the tree that touches 
omap-gem.c, I don't really want to just create some noise for problems 
that are created by out-of-tree patches. And yeah, it looks like a 
normal boot time probing stuff. As soon as I have some spare time 
(hopefully later today) I will try vanilla 5.9.x with 
omap2plus_defconfig and will report.


Ivo


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-27 Thread Tomi Valkeinen
On 27/11/2020 01:17, Ivaylo Dimitrov wrote:
> Hi Tomi,
> 
> On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:
>> Hi Aaro, Ivaylo,
>>
>> On 24/11/2020 23:03, Ivaylo Dimitrov wrote:
>>
>>> Is there any progress on the issue? I tried 5.9.1 and still nothing 
>>> displayed.
>>
>> Can you test the attached patch?
>>
> 
> With this patch I don't see oops that Aaro reported, so:
> 
> Tested-by: Ivaylo Dimitrov 
> 
> Seems to fix the particular issue, however, now we get another oops. As this 
> is not upstream kernel
> but one with PVR related patches, I will try again with vanilla 5.9.
> 
> Just in case oops rings any bells (the line in question is
> https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801)

Do the PVR patches touch omapdrm? The call stack looks like normal boot time 
probing stuff, not
something happening later (possibly from PVR).

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-27 Thread Tomi Valkeinen
On 25/11/2020 11:07, Daniel Vetter wrote:

>> Laurent, does this ring any bells? The WARN comes in 
>> drm_atomic_bridge_chain_enable() when
>> drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge.
>>
>> I'm not sure why the bridge state would not be there.
> 
> Lack of state on first modeset usually means your
> drm_mode_config_reset didn't create one. Or whatever it is you're
> using. I didn't look whether you're wiring this up correctly or not.
> We might even want to add a ->reset function to
> drm_private_state_funcs to make this work for everyone.

The bridge driver set atomic_enable and atomic_disable, but no other atomic 
funcs. It was supposed
to set the legacy enable & disable.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-26 Thread Ivaylo Dimitrov

Hi Tomi,

On 26.11.20 г. 16:11 ч., Tomi Valkeinen wrote:

Hi Aaro, Ivaylo,

On 24/11/2020 23:03, Ivaylo Dimitrov wrote:


Is there any progress on the issue? I tried 5.9.1 and still nothing displayed.


Can you test the attached patch?



With this patch I don't see oops that Aaro reported, so:

Tested-by: Ivaylo Dimitrov 

Seems to fix the particular issue, however, now we get another oops. As 
this is not upstream kernel but one with PVR related patches, I will try 
again with vanilla 5.9.


Just in case oops rings any bells (the line in question is 
https://github.com/maemo-leste/droid4-linux/blob/maemo-5.9/drivers/gpu/drm/omapdrm/omap_gem.c#L801)


[   17.494506] Unable to handle kernel NULL pointer dereference at 
virtual address 

[   17.502807] pgd = c59ec13e
[   17.505523] [] *pgd=
[   17.509277] Internal error: Oops: 5 [#1] THUMB2
[   17.513824] Modules linked in: joydev hsi_char wl1251_spi wl1251 
omap3_rom_rng rng_core ir_rx51 leds_gpio led_class rc_core 
snd_soc_rx51(+) isp1704_charger pwm_omap_dmtimer gpio_keys mac80211 
cpufreq_dt snd_soc_omap_mcbsp snd_soc_ti_sdma cfg80211 omap3_isp 
videobuf2_dma_contig videobuf2_memops libarc4 videobuf2_v4l2 omap_sham 
videobuf2_common omap2430 tsc2005 panel_sony_acx565akm tsc200x_core 
snd_soc_tlv320aic3x snd_soc_tpa6130a2 omap_mailbox snd_soc_core 
hci_nokia snd_pcm_dmaengine si4713 bq2415x_charger phy_twl4030_usb 
snd_pcm snd_timer bq27xxx_battery_i2c bq27xxx_battery snd tsl2563 
musb_hdrc soundcore udc_core hci_uart btbcm ohci_platform ohci_hcd 
ehci_hcd twl4030_pwrbutton st_accel_i2c st_sensors_i2c st_accel pwm_twl 
st_sensors twl4030_madc pwm_twl_led industrialio_triggered_buffer 
kfifo_buf evdev twl4030_vibra ff_memless bluetooth et8ek8 industrialio 
ad5820 v4l2_fwnode ecdh_generic usbcore ecc libaes usb_common videodev 
lis3lv02d_i2c omap_ssi lis3lv02d hsi mc
[   17.599914] CPU: 0 PID: 10 Comm: kworker/0:1 Tainted: G U 
   5.9.0-02838-g91f16872ecee #5

[   17.609161] Hardware name: Nokia RX-51 board
[   17.613464] Workqueue: events deferred_probe_work_func
[   17.618652] PC is at omap_gem_dma_sync_buffer 
(/home/user/git/linux-omap/drivers/gpu/drm/omapdrm/omap_gem.c:801)
[   17.623901] LR is at omap_framebuffer_pin 
(/home/user/git/linux-omap/drivers/gpu/drm/omapdrm/omap_fb.c:237 
(discriminator 2))

[   17.628814] pc : lr : psr: 800b0033
[   17.635101] sp : ce1cf978  ip : cbad5040  fp : 
[   17.640350] r10: 0001  r9 :   r8 : ccbe5000
[   17.645599] r7 : 0177  r6 :   r5 :   r4 : cba8b000
[   17.652160] r3 :   r2 :   r1 : 0001  r0 : cba8b000
[   17.658721] Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  ISA Thumb 
Segment none

[   17.666046] Control: 50c5387d  Table: 8cb3c019  DAC: 0051
[   17.671813] Process kworker/0:1 (pid: 10, stack limit = 0x4150a91a)
[   17.678131] Stack: (0xce1cf978 to 0xce1d)
[   17.682495] f960: 
  8e90 cba8b000
[   17.690734] f980:  c04410e7 cba8b000 cbc75000  
cbc75080  cbc750a0
[   17.698944] f9a0: 0001 cbc7507c cbbb5538 c0440ad9 ccc3ffc0 
0002  
[   17.707183] f9c0: 0001  ccbe5160 c0411be9 c0413509 
ccc3ffc0  ccbe5000
[   17.715393] f9e0:  c041355b c041350d ccc3ffc0 ce1cfa0c 
ccbe5000 cbdfa100 c042e9c9
[   17.723602] fa00:  c0a04048 0001 ce0bba80 0004 
0007  
[   17.731842] fa20: cb816858 ccc15a20  be70958a  
ccbe5000 cbdfa118 cd742600
[   17.740051] fa40: cbdfa100 c0aed344 0064 001e 0001 
c042ea7b cbc750c0 c0aef518
[   17.748291] fa60: cbdfa1a8 ccbe5054 ccbe5054 cbdfa100 ccbe5000 
cd742600 cbdfa1a8 c0aed344
[   17.756500] fa80: 0064 c042eb31 cbdfa1a8 cbdfa100  
c0416199 ccba8400 
[   17.764739] faa0: ccba8400 cd742600  c04161f1 ce08e000 
c03cad8f c0a04048 c01c92bd
[   17.772949] fac0: 0064 001e 0020   
ce08e000 c0aefc30 
[   17.781188] fae0:  c0641e80  c0aefb34 ce08e000 
c03f627b  
[   17.789398] fb00:  0001  c03f7875 c0a04048 
c0a6de84 c0768eab 003e
[   17.797637] fb20: 0001 c0aef63c c0a6de84  c0aef634 
c0641e80  003e
[   17.805847] fb40:  0001 c0aefc34 c03f7b09 c0a6de84 
c076ebc5 0001 ce1cfba4
[   17.814056] fb60: ccba8618 c0aed21c c0a69bf4 c0aed220 c0a04850 
c0a04048 ccba8410 ccba8618
[   17.822296] fb80: 01e0 c03c9239 ccba8400  c0aed214 
c03c4cc9 c0768b17 
[   17.830505] fba0:    0320 01e0 
  
[   17.838745] fbc0:      
 0020 be70958a
[   17.846954] fbe0: cbdfa100 c0a7208c ccba8400  ccbe5000 
 cbdfa1a8 c0415ec7
[   17.855194] fc00: cbdfa118 0001 ccfc598c   
0320 01e0 0320
[   17.863403] fc20: 01e0 0020 0018 be70958a c0a7208c 
cbdfa100 

Re: [REGRESSION] omapdrm/N900 display broken

2020-11-26 Thread Tomi Valkeinen
Hi Aaro, Ivaylo,

On 24/11/2020 23:03, Ivaylo Dimitrov wrote:

> Is there any progress on the issue? I tried 5.9.1 and still nothing displayed.

Can you test the attached patch?

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
>From 97c55032ac5c44885b0ec219467699af0b6153c1 Mon Sep 17 00:00:00 2001
From: Tomi Valkeinen 
Date: Thu, 26 Nov 2020 16:04:24 +0200
Subject: [PATCH] drm/omap: sdi: fix bridge enable/disable

When the SDI output was converted to DRM bridge, the atomic versions of
enable and disable funcs were used. This was not intended, as that would
require implementing other atomic funcs too. This leads to:

WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 drm_atomic_helper_commit_modeset_enables+0x134/0x268

and display not working.

Fix this by using the legacy enable/disable funcs.

Signed-off-by: Tomi Valkeinen 
Reported-by: Aaro Koskinen 
Fixes: 8bef8a6d5da81b909a190822b96805a47348146f ("drm/omap: sdi: Register a drm_bridge")
Cc: sta...@vger.kernel.org #v5.7+
---
 drivers/gpu/drm/omapdrm/dss/sdi.c | 10 --
 1 file changed, 4 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/omapdrm/dss/sdi.c b/drivers/gpu/drm/omapdrm/dss/sdi.c
index 033fd30074b0..282e4c837cd9 100644
--- a/drivers/gpu/drm/omapdrm/dss/sdi.c
+++ b/drivers/gpu/drm/omapdrm/dss/sdi.c
@@ -195,8 +195,7 @@ static void sdi_bridge_mode_set(struct drm_bridge *bridge,
 	sdi->pixelclock = adjusted_mode->clock * 1000;
 }
 
-static void sdi_bridge_enable(struct drm_bridge *bridge,
-			  struct drm_bridge_state *bridge_state)
+static void sdi_bridge_enable(struct drm_bridge *bridge)
 {
 	struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
 	struct dispc_clock_info dispc_cinfo;
@@ -259,8 +258,7 @@ static void sdi_bridge_enable(struct drm_bridge *bridge,
 	regulator_disable(sdi->vdds_sdi_reg);
 }
 
-static void sdi_bridge_disable(struct drm_bridge *bridge,
-			   struct drm_bridge_state *bridge_state)
+static void sdi_bridge_disable(struct drm_bridge *bridge)
 {
 	struct sdi_device *sdi = drm_bridge_to_sdi(bridge);
 
@@ -278,8 +276,8 @@ static const struct drm_bridge_funcs sdi_bridge_funcs = {
 	.mode_valid = sdi_bridge_mode_valid,
 	.mode_fixup = sdi_bridge_mode_fixup,
 	.mode_set = sdi_bridge_mode_set,
-	.atomic_enable = sdi_bridge_enable,
-	.atomic_disable = sdi_bridge_disable,
+	.enable = sdi_bridge_enable,
+	.disable = sdi_bridge_disable,
 };
 
 static void sdi_bridge_init(struct sdi_device *sdi)
-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki



Re: [REGRESSION] omapdrm/N900 display broken

2020-11-25 Thread Daniel Vetter
On Tue, Aug 25, 2020 at 3:16 PM Tomi Valkeinen  wrote:
>
> Hi Laurent,
>
> On 23/08/2020 19:26, Aaro Koskinen wrote:
> > Hi,
> >
> > On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:
> >> On 04/08/2020 15:13, Tomi Valkeinen wrote:
> >
> >>> Can you try to pinpoint a bit where the hang happens? Maybe add
> >>> DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock
> >>> that's in deadlock.
> >>
> >> Also, one data point would be to disable venc, e.g. set venc status to
> >> "disabled" in dts.
> >
> > Disabling venc makes no difference.
> >
> > The hang happens in drm_fb_helper_initial_config(). I followed the
> > "HANG DEBUGGING" tips in the function comment text and enabled
> > fb.lockless_register_fb=1 to get more (serial) console output.
> >
> > Now I get this:
> >
> > [6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using 
> > dummy regulator
> > [6.566375] DSS: OMAP DSS rev 2.0
> > [6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
> > dispc_component_ops)
> > [6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support
> > [6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> > [6.626617] [ cut here ]
> > [6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 
> > drm_atomic_helper_commit_modeset_enables+0x134/0x268
> > [6.643768] Modules linked in:
> > [6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U
> > 5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2
> > [6.658966] Hardware name: Nokia RX-51 board
> > [6.663635] Workqueue: events deferred_probe_work_func
> > [6.669097] [] (unwind_backtrace) from [] 
> > (show_stack+0x10/0x14)
> > [6.677429] [] (show_stack) from [] 
> > (__warn+0xbc/0xd4)
> > [6.684844] [] (__warn) from [] 
> > (warn_slowpath_fmt+0x60/0xb8)
> > [6.692901] [] (warn_slowpath_fmt) from [] 
> > (drm_atomic_helper_commit_modeset_enables+0x134/0x268)
> > [6.704254] [] (drm_atomic_helper_commit_modeset_enables) from 
> > [] (omap_atomic_commit_tail+0xb4/0xc0)
> > [6.715972] [] (omap_atomic_commit_tail) from [] 
> > (commit_tail+0x9c/0x1a8)
> > [6.725128] [] (commit_tail) from [] 
> > (drm_atomic_helper_commit+0x134/0x158)
> > [6.734466] [] (drm_atomic_helper_commit) from [] 
> > (drm_client_modeset_commit_atomic+0x16c/0x208)
> > [6.745727] [] (drm_client_modeset_commit_atomic) from 
> > [] (drm_client_modeset_commit_locked+0x58/0x184)
> > [6.757629] [] (drm_client_modeset_commit_locked) from 
> > [] (drm_client_modeset_commit+0x24/0x40)
> > [6.768798] [] (drm_client_modeset_commit) from [] 
> > (__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8)
> > [6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) 
> > from [] (drm_fb_helper_set_par+0x38/0x64)
> > [6.792785] [] (drm_fb_helper_set_par) from [] 
> > (fbcon_init+0x3d4/0x568)
> > [6.801757] [] (fbcon_init) from [] 
> > (visual_init+0xb8/0xfc)
> > [6.809631] [] (visual_init) from [] 
> > (do_bind_con_driver+0x1e0/0x3bc)
> > [6.818267] [] (do_bind_con_driver) from [] 
> > (do_take_over_console+0x138/0x1d8)
> > [6.827880] [] (do_take_over_console) from [] 
> > (do_fbcon_takeover+0x74/0xd4)
> > [6.837219] [] (do_fbcon_takeover) from [] 
> > (register_framebuffer+0x204/0x2d8)
> > [6.846740] [] (register_framebuffer) from [] 
> > (__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554)
> > [6.858459] [] (__drm_fb_helper_initial_config_and_unlock) 
> > from [] (omap_fbdev_init+0x84/0xbc)
> > [6.869537] [] (omap_fbdev_init) from [] 
> > (pdev_probe+0x580/0x7d8)
> > [6.877807] [] (pdev_probe) from [] 
> > (platform_drv_probe+0x48/0x98)
>
> Laurent, does this ring any bells? The WARN comes in 
> drm_atomic_bridge_chain_enable() when
> drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge.
>
> I'm not sure why the bridge state would not be there.

Lack of state on first modeset usually means your
drm_mode_config_reset didn't create one. Or whatever it is you're
using. I didn't look whether you're wiring this up correctly or not.
We might even want to add a ->reset function to
drm_private_state_funcs to make this work for everyone.
-Daniel

> Aaro, you can probably debug easier if you disable 
> CONFIG_FRAMEBUFFER_CONSOLE, or even
> CONFIG_DRM_FBDEV_EMULATION.
>
>  Tomi
>
> --
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch


Re: [REGRESSION] omapdrm/N900 display broken

2020-11-24 Thread Ivaylo Dimitrov

Hi,

On 25.08.20 г. 16:16 ч., Tomi Valkeinen wrote:

Hi Laurent,

On 23/08/2020 19:26, Aaro Koskinen wrote:

Hi,

On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:

On 04/08/2020 15:13, Tomi Valkeinen wrote:



Can you try to pinpoint a bit where the hang happens? Maybe add
DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock
that's in deadlock.


Also, one data point would be to disable venc, e.g. set venc status to
"disabled" in dts.


Disabling venc makes no difference.

The hang happens in drm_fb_helper_initial_config(). I followed the
"HANG DEBUGGING" tips in the function comment text and enabled
fb.lockless_register_fb=1 to get more (serial) console output.

Now I get this:

[6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using 
dummy regulator
[6.566375] DSS: OMAP DSS rev 2.0
[6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
dispc_component_ops)
[6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support
[6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[6.626617] [ cut here ]
[6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 
drm_atomic_helper_commit_modeset_enables+0x134/0x268
[6.643768] Modules linked in:
[6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U
5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2
[6.658966] Hardware name: Nokia RX-51 board
[6.663635] Workqueue: events deferred_probe_work_func
[6.669097] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[6.677429] [] (show_stack) from [] (__warn+0xbc/0xd4)
[6.684844] [] (__warn) from [] 
(warn_slowpath_fmt+0x60/0xb8)
[6.692901] [] (warn_slowpath_fmt) from [] 
(drm_atomic_helper_commit_modeset_enables+0x134/0x268)
[6.704254] [] (drm_atomic_helper_commit_modeset_enables) from 
[] (omap_atomic_commit_tail+0xb4/0xc0)
[6.715972] [] (omap_atomic_commit_tail) from [] 
(commit_tail+0x9c/0x1a8)
[6.725128] [] (commit_tail) from [] 
(drm_atomic_helper_commit+0x134/0x158)
[6.734466] [] (drm_atomic_helper_commit) from [] 
(drm_client_modeset_commit_atomic+0x16c/0x208)
[6.745727] [] (drm_client_modeset_commit_atomic) from 
[] (drm_client_modeset_commit_locked+0x58/0x184)
[6.757629] [] (drm_client_modeset_commit_locked) from 
[] (drm_client_modeset_commit+0x24/0x40)
[6.768798] [] (drm_client_modeset_commit) from [] 
(__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8)
[6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) from 
[] (drm_fb_helper_set_par+0x38/0x64)
[6.792785] [] (drm_fb_helper_set_par) from [] 
(fbcon_init+0x3d4/0x568)
[6.801757] [] (fbcon_init) from [] 
(visual_init+0xb8/0xfc)
[6.809631] [] (visual_init) from [] 
(do_bind_con_driver+0x1e0/0x3bc)
[6.818267] [] (do_bind_con_driver) from [] 
(do_take_over_console+0x138/0x1d8)
[6.827880] [] (do_take_over_console) from [] 
(do_fbcon_takeover+0x74/0xd4)
[6.837219] [] (do_fbcon_takeover) from [] 
(register_framebuffer+0x204/0x2d8)
[6.846740] [] (register_framebuffer) from [] 
(__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554)
[6.858459] [] (__drm_fb_helper_initial_config_and_unlock) from 
[] (omap_fbdev_init+0x84/0xbc)
[6.869537] [] (omap_fbdev_init) from [] 
(pdev_probe+0x580/0x7d8)
[6.877807] [] (pdev_probe) from [] 
(platform_drv_probe+0x48/0x98)


Laurent, does this ring any bells? The WARN comes in 
drm_atomic_bridge_chain_enable() when
drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge.

I'm not sure why the bridge state would not be there.

Aaro, you can probably debug easier if you disable CONFIG_FRAMEBUFFER_CONSOLE, 
or even
CONFIG_DRM_FBDEV_EMULATION.

  Tomi



Is there any progress on the issue? I tried 5.9.1 and still nothing 
displayed.


Regards,
Ivo


Re: [REGRESSION] omapdrm/N900 display broken

2020-08-25 Thread Tomi Valkeinen
Hi Laurent,

On 23/08/2020 19:26, Aaro Koskinen wrote:
> Hi,
> 
> On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:
>> On 04/08/2020 15:13, Tomi Valkeinen wrote:
> 
>>> Can you try to pinpoint a bit where the hang happens? Maybe add
>>> DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock
>>> that's in deadlock.
>>
>> Also, one data point would be to disable venc, e.g. set venc status to
>> "disabled" in dts.
> 
> Disabling venc makes no difference.
> 
> The hang happens in drm_fb_helper_initial_config(). I followed the
> "HANG DEBUGGING" tips in the function comment text and enabled
> fb.lockless_register_fb=1 to get more (serial) console output.
> 
> Now I get this:
> 
> [6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using 
> dummy regulator
> [6.566375] DSS: OMAP DSS rev 2.0
> [6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
> dispc_component_ops)
> [6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support
> [6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> [6.626617] [ cut here ]
> [6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 
> drm_atomic_helper_commit_modeset_enables+0x134/0x268
> [6.643768] Modules linked in:
> [6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U
> 5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2
> [6.658966] Hardware name: Nokia RX-51 board
> [6.663635] Workqueue: events deferred_probe_work_func
> [6.669097] [] (unwind_backtrace) from [] 
> (show_stack+0x10/0x14)
> [6.677429] [] (show_stack) from [] (__warn+0xbc/0xd4)
> [6.684844] [] (__warn) from [] 
> (warn_slowpath_fmt+0x60/0xb8)
> [6.692901] [] (warn_slowpath_fmt) from [] 
> (drm_atomic_helper_commit_modeset_enables+0x134/0x268)
> [6.704254] [] (drm_atomic_helper_commit_modeset_enables) from 
> [] (omap_atomic_commit_tail+0xb4/0xc0)
> [6.715972] [] (omap_atomic_commit_tail) from [] 
> (commit_tail+0x9c/0x1a8)
> [6.725128] [] (commit_tail) from [] 
> (drm_atomic_helper_commit+0x134/0x158)
> [6.734466] [] (drm_atomic_helper_commit) from [] 
> (drm_client_modeset_commit_atomic+0x16c/0x208)
> [6.745727] [] (drm_client_modeset_commit_atomic) from 
> [] (drm_client_modeset_commit_locked+0x58/0x184)
> [6.757629] [] (drm_client_modeset_commit_locked) from 
> [] (drm_client_modeset_commit+0x24/0x40)
> [6.768798] [] (drm_client_modeset_commit) from [] 
> (__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8)
> [6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) 
> from [] (drm_fb_helper_set_par+0x38/0x64)
> [6.792785] [] (drm_fb_helper_set_par) from [] 
> (fbcon_init+0x3d4/0x568)
> [6.801757] [] (fbcon_init) from [] 
> (visual_init+0xb8/0xfc)
> [6.809631] [] (visual_init) from [] 
> (do_bind_con_driver+0x1e0/0x3bc)
> [6.818267] [] (do_bind_con_driver) from [] 
> (do_take_over_console+0x138/0x1d8)
> [6.827880] [] (do_take_over_console) from [] 
> (do_fbcon_takeover+0x74/0xd4)
> [6.837219] [] (do_fbcon_takeover) from [] 
> (register_framebuffer+0x204/0x2d8)
> [6.846740] [] (register_framebuffer) from [] 
> (__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554)
> [6.858459] [] (__drm_fb_helper_initial_config_and_unlock) from 
> [] (omap_fbdev_init+0x84/0xbc)
> [6.869537] [] (omap_fbdev_init) from [] 
> (pdev_probe+0x580/0x7d8)
> [6.877807] [] (pdev_probe) from [] 
> (platform_drv_probe+0x48/0x98)

Laurent, does this ring any bells? The WARN comes in 
drm_atomic_bridge_chain_enable() when
drm_atomic_get_old_bridge_state() returns null for (presumably) sdi bridge.

I'm not sure why the bridge state would not be there.

Aaro, you can probably debug easier if you disable CONFIG_FRAMEBUFFER_CONSOLE, 
or even
CONFIG_DRM_FBDEV_EMULATION.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [REGRESSION] omapdrm/N900 display broken

2020-08-23 Thread Aaro Koskinen
Hi,

On Tue, Aug 04, 2020 at 03:39:37PM +0300, Tomi Valkeinen wrote:
> On 04/08/2020 15:13, Tomi Valkeinen wrote:

> > Can you try to pinpoint a bit where the hang happens? Maybe add
> > DRM/omapdrm debug prints, or perhaps sysrq works and it shows a lock
> > that's in deadlock.
> 
> Also, one data point would be to disable venc, e.g. set venc status to
> "disabled" in dts.

Disabling venc makes no difference.

The hang happens in drm_fb_helper_initial_config(). I followed the
"HANG DEBUGGING" tips in the function comment text and enabled
fb.lockless_register_fb=1 to get more (serial) console output.

Now I get this:

[6.514739] omapdss_dss 4805.dss: supply vdda_video not found, using 
dummy regulator
[6.566375] DSS: OMAP DSS rev 2.0
[6.571807] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
dispc_component_ops)
[6.580749] omapdrm omapdrm.0: DMM not available, disable DMM support
[6.587982] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[6.626617] [ cut here ]
[6.631774] WARNING: CPU: 0 PID: 18 at drivers/gpu/drm/drm_bridge.c:708 
drm_atomic_helper_commit_modeset_enables+0x134/0x268
[6.643768] Modules linked in:
[6.647033] CPU: 0 PID: 18 Comm: kworker/0:1 Tainted: G U
5.8.0-omap3-los_16068+-4-g2e7d4a7efefd-dirty #2
[6.658966] Hardware name: Nokia RX-51 board
[6.663635] Workqueue: events deferred_probe_work_func
[6.669097] [] (unwind_backtrace) from [] 
(show_stack+0x10/0x14)
[6.677429] [] (show_stack) from [] (__warn+0xbc/0xd4)
[6.684844] [] (__warn) from [] 
(warn_slowpath_fmt+0x60/0xb8)
[6.692901] [] (warn_slowpath_fmt) from [] 
(drm_atomic_helper_commit_modeset_enables+0x134/0x268)
[6.704254] [] (drm_atomic_helper_commit_modeset_enables) from 
[] (omap_atomic_commit_tail+0xb4/0xc0)
[6.715972] [] (omap_atomic_commit_tail) from [] 
(commit_tail+0x9c/0x1a8)
[6.725128] [] (commit_tail) from [] 
(drm_atomic_helper_commit+0x134/0x158)
[6.734466] [] (drm_atomic_helper_commit) from [] 
(drm_client_modeset_commit_atomic+0x16c/0x208)
[6.745727] [] (drm_client_modeset_commit_atomic) from 
[] (drm_client_modeset_commit_locked+0x58/0x184)
[6.757629] [] (drm_client_modeset_commit_locked) from 
[] (drm_client_modeset_commit+0x24/0x40)
[6.768798] [] (drm_client_modeset_commit) from [] 
(__drm_fb_helper_restore_fbdev_mode_unlocked+0xa0/0xc8)
[6.780975] [] (__drm_fb_helper_restore_fbdev_mode_unlocked) from 
[] (drm_fb_helper_set_par+0x38/0x64)
[6.792785] [] (drm_fb_helper_set_par) from [] 
(fbcon_init+0x3d4/0x568)
[6.801757] [] (fbcon_init) from [] 
(visual_init+0xb8/0xfc)
[6.809631] [] (visual_init) from [] 
(do_bind_con_driver+0x1e0/0x3bc)
[6.818267] [] (do_bind_con_driver) from [] 
(do_take_over_console+0x138/0x1d8)
[6.827880] [] (do_take_over_console) from [] 
(do_fbcon_takeover+0x74/0xd4)
[6.837219] [] (do_fbcon_takeover) from [] 
(register_framebuffer+0x204/0x2d8)
[6.846740] [] (register_framebuffer) from [] 
(__drm_fb_helper_initial_config_and_unlock+0x3a4/0x554)
[6.858459] [] (__drm_fb_helper_initial_config_and_unlock) from 
[] (omap_fbdev_init+0x84/0xbc)
[6.869537] [] (omap_fbdev_init) from [] 
(pdev_probe+0x580/0x7d8)
[6.877807] [] (pdev_probe) from [] 
(platform_drv_probe+0x48/0x98)
[6.886291] [] (platform_drv_probe) from [] 
(really_probe+0x1e0/0x344)
[6.895172] [] (really_probe) from [] 
(driver_probe_device+0x5c/0xb4)
[6.903961] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x80/0xc4)
[6.913085] [] (bus_for_each_drv) from [] 
(__device_attach+0xd0/0x13c)
[6.921966] [] (__device_attach) from [] 
(bus_probe_device+0x84/0x8c)
[6.930725] [] (bus_probe_device) from [] 
(device_add+0x3f0/0x740)
[6.939086] [] (device_add) from [] 
(platform_device_add+0x110/0x204)
[6.947845] [] (platform_device_add) from [] 
(platform_device_register_full+0xcc/0x110)
[6.958282] [] (platform_device_register_full) from [] 
(dss_bind+0x80/0xa8)
[6.967620] [] (dss_bind) from [] 
(try_to_bring_up_master+0x160/0x1a8)
[6.976501] [] (try_to_bring_up_master) from [] 
(component_master_add_with_match+0xc4/0xf8)
[6.987304] [] (component_master_add_with_match) from [] 
(dss_probe+0x494/0x55c)
[6.997100] [] (dss_probe) from [] 
(platform_drv_probe+0x48/0x98)
[7.005523] [] (platform_drv_probe) from [] 
(really_probe+0x1e0/0x344)
[7.014404] [] (really_probe) from [] 
(driver_probe_device+0x5c/0xb4)
[7.023193] [] (driver_probe_device) from [] 
(bus_for_each_drv+0x80/0xc4)
[7.032348] [] (bus_for_each_drv) from [] 
(__device_attach+0xd0/0x13c)
[7.041198] [] (__device_attach) from [] 
(bus_probe_device+0x84/0x8c)
[7.049987] [] (bus_probe_device) from [] 
(deferred_probe_work_func+0x64/0x90)
[7.059570] [] (deferred_probe_work_func) from [] 
(process_one_work+0x1d4/0x440)
[7.069213] [] (process_one_work) from [] 
(worker_thread+0x260/0x590)
[7.078002] [] 

Re: [REGRESSION] omapdrm/N900 display broken

2020-08-04 Thread Tomi Valkeinen
On 04/08/2020 15:13, Tomi Valkeinen wrote:
> On 28/07/2020 21:14, Aaro Koskinen wrote:
>> Hi,
>>
>> Looks like N900 display support has broken after v5.6.
>>
>> When using v5.7, or the current mainline (v5.8-rc7), the boot hangs at:
>>
>> [6.269500] omapdss_dss 4805.dss: 4805.dss supply vdda_video not 
>> found, using dummy regulator
>> [6.321685] DSS: OMAP DSS rev 2.0
>> [6.328002] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
>> dispc_component_ops)
>> [6.336364] omapdss_dss 4805.dss: bound 48050c00.encoder (ops 
>> venc_component_ops)
>> [6.345153] omapdrm omapdrm.0: DMM not available, disable DMM support
>> [6.352447] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
>>
>> with a blank display.
>>
>> I tried to bisect this, and the first commit that breaks the display is:
>>
>> 2f004792adadcf017fde50339b432a26039fff0c is the first bad commit
>> commit 2f004792adadcf017fde50339b432a26039fff0c
>> Author: Laurent Pinchart 
>> Date:   Wed Feb 26 13:24:57 2020 +0200
>>
>> drm/omap: venc: Register a drm_bridge
>>
>> This commit does not yet hang the kernel, but the display is blank and
>> the probe fails:
>>
>> [6.290100] omapdss_dss 4805.dss: 4805.dss supply vdda_video not 
>> foun
>> d, using dummy regulator
>> [6.342346] DSS: OMAP DSS rev 2.0
>> [6.348663] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
>> dispc_component_ops)
>> [6.357025] omapdss_dss 4805.dss: bound 48050c00.encoder (ops 
>> venc_component_ops)
>> [6.365814] omapdrm omapdrm.0: DMM not available, disable DMM support
>> [6.372863] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22
>> [6.414611] omapdrm: probe of omapdrm.0 failed with error -22
> 
> Afaics, this is caused by the patch doing
> 
>   if (!venc->output.next_bridge)
> 
> instead of
> 
>   if (venc->output.next_bridge)
> 
> Fixing that removes the error on beagle xm, but for some reason I don't see 
> TV-out as a DRM output
> (but HDMI output works).
> 
>> The hang seems to start with this commit:
>>
>> commit 8bef8a6d5da81b909a190822b96805a47348146f (HEAD -> master)
>> Author: Laurent Pinchart 
>> Date:   Wed Feb 26 13:25:10 2020 +0200
>>
>> drm/omap: sdi: Register a drm_bridge
>>
>> Confusingly, some of the commits between these two commits do provide a
>> working display, e.g. 13d2d52f59c0c79398d9c9e2ea3d661a0e5b6bbc ("drm/omap:
>> sdi: Sort includes alphabetically") works...
> 
> The venc issue is fixed in "Switch the HDMI and VENC outputs to drm_bridge", 
> which is a few commits
> after the "venc: Register a drm_bridge".
> 
> So I'm guessing SDI works until "sdi: Register a drm_bridge", but as omapdrm 
> doesn't probe, you get
> no displays.
> 
> Can you try to pinpoint a bit where the hang happens? Maybe add DRM/omapdrm 
> debug prints, or perhaps
> sysrq works and it shows a lock that's in deadlock.

Also, one data point would be to disable venc, e.g. set venc status to 
"disabled" in dts.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [REGRESSION] omapdrm/N900 display broken

2020-08-04 Thread Tomi Valkeinen
On 28/07/2020 21:14, Aaro Koskinen wrote:
> Hi,
> 
> Looks like N900 display support has broken after v5.6.
> 
> When using v5.7, or the current mainline (v5.8-rc7), the boot hangs at:
> 
> [6.269500] omapdss_dss 4805.dss: 4805.dss supply vdda_video not 
> found, using dummy regulator
> [6.321685] DSS: OMAP DSS rev 2.0
> [6.328002] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
> dispc_component_ops)
> [6.336364] omapdss_dss 4805.dss: bound 48050c00.encoder (ops 
> venc_component_ops)
> [6.345153] omapdrm omapdrm.0: DMM not available, disable DMM support
> [6.352447] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
> 
> with a blank display.
> 
> I tried to bisect this, and the first commit that breaks the display is:
> 
> 2f004792adadcf017fde50339b432a26039fff0c is the first bad commit
> commit 2f004792adadcf017fde50339b432a26039fff0c
> Author: Laurent Pinchart 
> Date:   Wed Feb 26 13:24:57 2020 +0200
> 
> drm/omap: venc: Register a drm_bridge
> 
> This commit does not yet hang the kernel, but the display is blank and
> the probe fails:
> 
> [6.290100] omapdss_dss 4805.dss: 4805.dss supply vdda_video not 
> foun
> d, using dummy regulator
> [6.342346] DSS: OMAP DSS rev 2.0
> [6.348663] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
> dispc_component_ops)
> [6.357025] omapdss_dss 4805.dss: bound 48050c00.encoder (ops 
> venc_component_ops)
> [6.365814] omapdrm omapdrm.0: DMM not available, disable DMM support
> [6.372863] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22
> [6.414611] omapdrm: probe of omapdrm.0 failed with error -22

Afaics, this is caused by the patch doing

if (!venc->output.next_bridge)

instead of

if (venc->output.next_bridge)

Fixing that removes the error on beagle xm, but for some reason I don't see 
TV-out as a DRM output
(but HDMI output works).

> The hang seems to start with this commit:
> 
> commit 8bef8a6d5da81b909a190822b96805a47348146f (HEAD -> master)
> Author: Laurent Pinchart 
> Date:   Wed Feb 26 13:25:10 2020 +0200
> 
> drm/omap: sdi: Register a drm_bridge
> 
> Confusingly, some of the commits between these two commits do provide a
> working display, e.g. 13d2d52f59c0c79398d9c9e2ea3d661a0e5b6bbc ("drm/omap:
> sdi: Sort includes alphabetically") works...

The venc issue is fixed in "Switch the HDMI and VENC outputs to drm_bridge", 
which is a few commits
after the "venc: Register a drm_bridge".

So I'm guessing SDI works until "sdi: Register a drm_bridge", but as omapdrm 
doesn't probe, you get
no displays.

Can you try to pinpoint a bit where the hang happens? Maybe add DRM/omapdrm 
debug prints, or perhaps
sysrq works and it shows a lock that's in deadlock.

 Tomi

-- 
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


[REGRESSION] omapdrm/N900 display broken

2020-07-28 Thread Aaro Koskinen
Hi,

Looks like N900 display support has broken after v5.6.

When using v5.7, or the current mainline (v5.8-rc7), the boot hangs at:

[6.269500] omapdss_dss 4805.dss: 4805.dss supply vdda_video not 
found, using dummy regulator
[6.321685] DSS: OMAP DSS rev 2.0
[6.328002] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
dispc_component_ops)
[6.336364] omapdss_dss 4805.dss: bound 48050c00.encoder (ops 
venc_component_ops)
[6.345153] omapdrm omapdrm.0: DMM not available, disable DMM support
[6.352447] [drm] Supports vblank timestamp caching Rev 2 (21.10.2013).

with a blank display.

I tried to bisect this, and the first commit that breaks the display is:

2f004792adadcf017fde50339b432a26039fff0c is the first bad commit
commit 2f004792adadcf017fde50339b432a26039fff0c
Author: Laurent Pinchart 
Date:   Wed Feb 26 13:24:57 2020 +0200

drm/omap: venc: Register a drm_bridge

This commit does not yet hang the kernel, but the display is blank and
the probe fails:

[6.290100] omapdss_dss 4805.dss: 4805.dss supply vdda_video not foun
d, using dummy regulator
[6.342346] DSS: OMAP DSS rev 2.0
[6.348663] omapdss_dss 4805.dss: bound 48050400.dispc (ops 
dispc_component_ops)
[6.357025] omapdss_dss 4805.dss: bound 48050c00.encoder (ops 
venc_component_ops)
[6.365814] omapdrm omapdrm.0: DMM not available, disable DMM support
[6.372863] omapdrm omapdrm.0: omap_modeset_init failed: ret=-22
[6.414611] omapdrm: probe of omapdrm.0 failed with error -22

The hang seems to start with this commit:

commit 8bef8a6d5da81b909a190822b96805a47348146f (HEAD -> master)
Author: Laurent Pinchart 
Date:   Wed Feb 26 13:25:10 2020 +0200

drm/omap: sdi: Register a drm_bridge

Confusingly, some of the commits between these two commits do provide a
working display, e.g. 13d2d52f59c0c79398d9c9e2ea3d661a0e5b6bbc ("drm/omap:
sdi: Sort includes alphabetically") works...

Used kernel .config is below.

A.

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 5.7.0 Kernel Configuration
#

#
# Compiler: arm-linux-gnueabi-gcc (GCC) 8.4.0
#
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=80400
CONFIG_LD_VERSION=23200
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y

#
# General setup
#
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION="-omap3"
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_CROSS_MEMORY_ATTACH is not set
# CONFIG_USELIB is not set
# CONFIG_AUDIT is not set
CONFIG_HAVE_ARCH_AUDITSYSCALL=y

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_GENERIC_IRQ_SHOW_LEVEL=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
CONFIG_HANDLE_DOMAIN_IRQ=y
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
# CONFIG_GENERIC_IRQ_DEBUGFS is not set
# end of IRQ subsystem

CONFIG_GENERIC_IRQ_MULTI_HANDLER=y
CONFIG_GENERIC_CLOCKEVENTS=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# end of Timers subsystem

CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
# CONFIG_IRQ_TIME_ACCOUNTING is not set
CONFIG_BSD_PROCESS_ACCT=y
# CONFIG_BSD_PROCESS_ACCT_V3 is not set
# CONFIG_TASKSTATS is not set
# CONFIG_PSI is not set
# end of CPU/Task time and stats accounting

#
# RCU Subsystem
#
CONFIG_TINY_RCU=y
# CONFIG_RCU_EXPERT is not set
CONFIG_SRCU=y
CONFIG_TINY_SRCU=y
# end of RCU Subsystem

CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_IKHEADERS is not set
CONFIG_LOG_BUF_SHIFT=20
CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13
CONFIG_GENERIC_SCHED_CLOCK=y

#
# Scheduler features
#
# end of Scheduler features

# CONFIG_CGROUPS is not set
# CONFIG_NAMESPACES is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
# CONFIG_RELAY is not set
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_RD_GZIP is not set
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
CONFIG_RD_XZ=y
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
# CONFIG_BOOT_CONFIG is not set
CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE=y
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_HAVE_UID16=y
CONFIG_BPF=y
CONFIG_EXPERT=y
CONFIG_UID16=y
CONFIG_MULTIUSER=y
# CONFIG_SGETMASK_SYSCALL