[v4,04/15] drm/bridge: tc358764: add drm_panel_bridge support

Thu Sep 3 06:20:03 UTC 2020

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 at ravnborg.org>
>>> Cc: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>>> Cc: kbuild test robot <lkp at intel.com>
>>> Cc: Andrzej Hajda <a.hajda at samsung.com>
>>> Cc: Neil Armstrong <narmstrong at baylibre.com>
>>> Cc: Jonas Karlman <jonas at kwiboo.se>
>>> Cc: Jernej Skrabec <jernej.skrabec at siol.net>
>>> Reviewed-by: Laurent Pinchart <laurent.pinchart at ideasonboard.com>
>> 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 at lists.freedesktop.org
> https://protect2.fireeye.com/url?k=4965500c-14b1ec64-4964db43-0cc47a3356b2-f40ef8e76ffb9eeb&q=1&u=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Fdri-devel
>