Hi Sam, On 30.08.2020 22:42, Sam Ravnborg wrote: > Hi Marek. > > On Thu, Aug 27, 2020 at 01:39:06PM +0200, Marek Szyprowski wrote: >> Hi Sam, >> >> On 26.07.2020 22:33, Sam Ravnborg wrote: >>> Prepare the tc358764 bridge driver for use in a chained setup by >>> replacing direct use of drm_panel with drm_panel_bridge support. >>> >>> The bridge panel will use the connector type reported by the panel, >>> where the connector for this driver hardcodes DRM_MODE_CONNECTOR_LVDS. >>> >>> The tc358764 did not any additional info the the connector so the >>> connector creation is passed to the bridge panel driver. >>> >>> v3: >>> - Merge with patch to make connector creation optional to avoid >>> creating two connectors (Laurent) >>> - Pass connector creation to bridge panel, as this bridge driver >>> did not add any extra info to the connector. >>> - Set bridge.type to DRM_MODE_CONNECTOR_LVDS. >>> >>> v2: >>> - Use PTR_ERR_OR_ZERO() (kbuild test robot) >>> >>> Signed-off-by: Sam Ravnborg <sam@xxxxxxxxxxxx> >>> Cc: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> >>> Cc: kbuild test robot <lkp@xxxxxxxxx> >>> Cc: Andrzej Hajda <a.hajda@xxxxxxxxxxx> >>> Cc: Neil Armstrong <narmstrong@xxxxxxxxxxxx> >>> Cc: Jonas Karlman <jonas@xxxxxxxxx> >>> Cc: Jernej Skrabec <jernej.skrabec@xxxxxxxx> >>> Reviewed-by: Laurent Pinchart <laurent.pinchart@xxxxxxxxxxxxxxxx> >> I've noticed that this patch has been merged recently to linux-next. >> Sadly it causes regression on Samsung Exynos5250-based Arndale board. > Thanks for reporting this! > > I did not find time to focus on this bug this weekend. It is on my todo > list for the coming weekend. > > Anything you could do to narrow down this a bit to help finding the root > cause? > > Ideas: > - Trying to find out what part of the connector that cuases troubles > - Posting the full kernel boot log, to help identifying something. > Bonus if we get a working and non-working log - so we can compare. > - Migrate exonys to the new model > That would not fix the bug, so that would be a natural step 2 > - Identify the exact code-patch in the exonys driver that is used. > drm_bridge_attach() is called in several places > - And likely much more that I just forgot dmesg WARN suggest there is no connector registered and it can be true. I guess drm_panel_bridge does not support dynamic connector registration, so if the bridge appears after drm dev is created it will not be properly registered. I will try look closer at the patch but I guess the above can be the main reason. Regards Andrzej > > Any help would be appreciated - I did not find the culprint from first > glance. I may still be obvious but I just failed to spot it. > > Sam > >> It can be observed by the following warning during boot: >> >> ------------[ cut here ]------------ >> WARNING: CPU: 1 PID: 1 at drivers/gpu/drm/drm_atomic_state_helper.c:494 >> drm_atomic_helper_connector_duplicate_state+0x60/0x68 >> Modules linked in: >> CPU: 1 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc2-00501-g1644127f83bc >> #1526 >> Hardware name: Samsung Exynos (Flattened Device Tree) >> [<c011184c>] (unwind_backtrace) from [<c010d250>] (show_stack+0x10/0x14) >> [<c010d250>] (show_stack) from [<c0517ce4>] (dump_stack+0xbc/0xe8) >> [<c0517ce4>] (dump_stack) from [<c01270a8>] (__warn+0xf0/0x108) >> [<c01270a8>] (__warn) from [<c0127170>] (warn_slowpath_fmt+0xb0/0xb8) >> [<c0127170>] (warn_slowpath_fmt) from [<c05e81f0>] >> (drm_atomic_helper_connector_duplicate_state+0x60/0x68) >> [<c05e81f0>] (drm_atomic_helper_connector_duplicate_state) from >> [<c06014b8>] (drm_atomic_get_connector_state+0xfc/0x184) >> [<c06014b8>] (drm_atomic_get_connector_state) from [<c0602238>] >> (__drm_atomic_helper_set_config+0x2a0/0x368) >> [<c0602238>] (__drm_atomic_helper_set_config) from [<c06183b8>] >> (drm_client_modeset_commit_atomic+0x180/0x284) >> [<c06183b8>] (drm_client_modeset_commit_atomic) from [<c061859c>] >> (drm_client_modeset_commit_locked+0x64/0x1cc) >> [<c061859c>] (drm_client_modeset_commit_locked) from [<c0618728>] >> (drm_client_modeset_commit+0x24/0x40) >> [<c0618728>] (drm_client_modeset_commit) from [<c05eb6b4>] >> (drm_fb_helper_restore_fbdev_mode_unlocked+0x50/0x94) >> [<c05eb6b4>] (drm_fb_helper_restore_fbdev_mode_unlocked) from >> [<c05eb728>] (drm_fb_helper_set_par+0x30/0x5c) >> [<c05eb728>] (drm_fb_helper_set_par) from [<c055dedc>] >> (fbcon_init+0x5c8/0x65c) >> [<c055dedc>] (fbcon_init) from [<c05a8530>] (visual_init+0xc0/0x108) >> [<c05a8530>] (visual_init) from [<c05aaca4>] >> (do_bind_con_driver+0x180/0x39c) >> [<c05aaca4>] (do_bind_con_driver) from [<c05ab244>] >> (do_take_over_console+0x140/0x1cc) >> [<c05ab244>] (do_take_over_console) from [<c055ac04>] >> (do_fbcon_takeover+0x84/0xe0) >> [<c055ac04>] (do_fbcon_takeover) from [<c0553820>] >> (register_framebuffer+0x1cc/0x2dc) >> [<c0553820>] (register_framebuffer) from [<c05eb19c>] >> (__drm_fb_helper_initial_config_and_unlock+0x3f0/0x5e8) >> [<c05eb19c>] (__drm_fb_helper_initial_config_and_unlock) from >> [<c05d941c>] (drm_kms_helper_hotplug_event+0x24/0x30) >> [<c05d941c>] (drm_kms_helper_hotplug_event) from [<c0628f74>] >> (exynos_dsi_host_attach+0x184/0x2d8) >> [<c0628f74>] (exynos_dsi_host_attach) from [<c0634120>] >> (tc358764_probe+0x13c/0x1ac) >> [<c0634120>] (tc358764_probe) from [<c064cce4>] (really_probe+0x200/0x48c) >> [<c064cce4>] (really_probe) from [<c064d0d8>] >> (driver_probe_device+0x78/0x1fc) >> [<c064d0d8>] (driver_probe_device) from [<c064d4c0>] >> (device_driver_attach+0x58/0x60) >> [<c064d4c0>] (device_driver_attach) from [<c064d5a4>] >> (__driver_attach+0xdc/0x174) >> [<c064d5a4>] (__driver_attach) from [<c064aaf0>] >> (bus_for_each_dev+0x68/0xb4) >> [<c064aaf0>] (bus_for_each_dev) from [<c064be24>] >> (bus_add_driver+0x158/0x214) >> [<c064be24>] (bus_add_driver) from [<c064e478>] (driver_register+0x78/0x110) >> [<c064e478>] (driver_register) from [<c0102378>] >> (do_one_initcall+0x8c/0x424) >> [<c0102378>] (do_one_initcall) from [<c1001158>] >> (kernel_init_freeable+0x190/0x204) >> [<c1001158>] (kernel_init_freeable) from [<c0ab835c>] >> (kernel_init+0x8/0x118) >> [<c0ab835c>] (kernel_init) from [<c0100114>] (ret_from_fork+0x14/0x20) >> Exception stack(0xee8ddfb0 to 0xee8ddff8) >> dfa0: 00000000 00000000 00000000 >> 00000000 >> dfc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 >> 00000000 >> dfe0: 00000000 00000000 00000000 00000000 00000013 00000000 >> irq event stamp: 171647 >> hardirqs last enabled at (171653): [<c019ec00>] vprintk_emit+0x2ac/0x2ec >> hardirqs last disabled at (171658): [<c019eab8>] vprintk_emit+0x164/0x2ec >> softirqs last enabled at (171486): [<c010174c>] __do_softirq+0x50c/0x608 >> softirqs last disabled at (171473): [<c0130340>] irq_exit+0x168/0x16c >> ---[ end trace 33117a16f066466a ]--- >> >> Then calling modetest end with segmentation fault. I'm not able to check >> currently if there is anything on the display because of having only >> remote access to the board. If this is important I will try to ask >> someone to help checking at the board's display at the office. >> >> Best regards >> -- >> Marek Szyprowski, PhD >> Samsung R&D Institute Poland > _______________________________________________ > dri-devel mailing list > dri-devel@xxxxxxxxxxxxxxxxxxxxx > https://protect2.fireeye.com/url?k=4965500c-14b1ec64-4964db43-0cc47a3356b2-f40ef8e76ffb9eeb&q=1&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel > _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
