Re: [REGRESSION] omapdrm/N900 display broken
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(&lcd->mutex); - lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_LOW); + lcd->reset_gpio = devm_gpiod_get(&spi->dev, "reset", GPIOD_OUT_HIGH); if (IS_ERR(lcd->reset_gpio)) { dev_err(&spi->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
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
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
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
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
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
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 ccbe5
Re: [REGRESSION] omapdrm/N900 display broken
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
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
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
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
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] [] (worker_th
Re: [REGRESSION] omapdrm/N900 display broken
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
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