Hi All,
The below patch in Linux-next 20221123 is causing regression on Renesas {RZ/G2M, R-Car Gen-3}
Platforms.
Steps to reproduce:
Use the arm64 defconfig to build the kernel and then boot the board.
Is there any patch to fix the problem? I am happy to test.
Logs:-
[ 23.762999] Console: switching to colour frame buffer device 240x67
[ 23.763128] ------------[ cut here ]------------
[ 23.763133] WARNING: CPU: 3 PID: 278 at drivers/video/fbdev/core/fb_defio.c:340 fb_deferred_io_schedule_flush+0x38/0x40
[ 23.763164] Modules linked in: cfg80211(+) rcar_du_drm(+) rcar_mipi_dsi rcar_cmm rcar_lvds snd_soc_hdmi_codec vsp1 dw_hdmi_cec dw_hdmi_i2s_audio rcar_fdp1 v4l2_mem2mem videobuf2_vmalloc rcar_dw_hdmi videobuf2_dma_contig dw_hdmi videobuf2_memops hci_uart videobuf2_v4l2 cec videobuf2_common crct10dif_ce btqca drm_display_helper snd_soc_audio_graph_card drm_dma_helper videodev snd_soc_simple_card_utils btbcm wlcore_sdio mc rcar_fcp display_connector bluetooth rcar_can drm_kms_helper ecdh_generic renesas_usb3 ecc snd_soc_rcar drm rfkill can_dev pwm_rcar usb_dmac renesas_usbhs phy_rcar_gen3_usb3 ipv6
[ 23.763314] CPU: 3 PID: 278 Comm: systemd-udevd Not tainted 6.1.0-rc6-next-20221123-10432-g736b6d81d93c #314
[ 23.763323] Hardware name: HopeRun HiHope RZ/G2M with sub board (DT)
[ 23.763329] pstate: 80000005 (Nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 23.763337] pc : fb_deferred_io_schedule_flush+0x38/0x40
[ 23.763344] lr : drm_fb_helper_sys_imageblit+0xa8/0xc4 [drm_kms_helper]
[ 23.763474] sp : ffff80000ac5b3c0
[ 23.763478] x29: ffff80000ac5b3c0 x28: 00000000ffffffff x27: 0000000000000010
[ 23.763489] x26: ffff0005c1356000 x25: ffff0005c3a80800 x24: ffff0005c02528cc
[ 23.763499] x23: 0000000000000000 x22: 0000000000000180 x21: 0000000000000008
[ 23.763509] x20: 0000000000000010 x19: ffff0005c0252800 x18: 0000000000000001
[ 23.763519] x17: 0000000000000004 x16: 0000000000000000 x15: 0000000000000000
[ 23.763529] x14: 0000000000000020 x13: 0000000000000000 x12: 0000000000000020
[ 23.763539] x11: 00000000ffffffff x10: 0000000000000001 x9 : 0000000000000001
[ 23.763549] x8 : ffff0005c1356010 x7 : 0000000000000008 x6 : 0000000000000000
[ 23.763559] x5 : 0000000000000190 x4 : 0000000000000180 x3 : 0000000000000008
[ 23.763569] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0005c3a80800
[ 23.763580] Call trace:
[ 23.763585] fb_deferred_io_schedule_flush+0x38/0x40
[ 23.763594] drm_fbdev_fb_imageblit+0x38/0x70 [drm_kms_helper]
[ 23.763671] soft_cursor+0x15c/0x200
[ 23.763680] bit_cursor+0x3ac/0x500
[ 23.763687] fbcon_cursor+0xec/0x11c
[ 23.763694] hide_cursor+0x3c/0xc0
[ 23.763708] redraw_screen+0x128/0x240
[ 23.763717] do_bind_con_driver.isra.0+0x2c8/0x39c
[ 23.763726] do_take_over_console+0x140/0x200
[ 23.763736] do_fbcon_takeover+0x6c/0xe4
[ 23.763742] fbcon_fb_registered+0x1e4/0x1f0
[ 23.763749] register_framebuffer+0x214/0x310
[ 23.763761] __drm_fb_helper_initial_config_and_unlock+0x33c/0x534 [drm_kms_helper]
[ 23.763837] drm_fb_helper_initial_config+0x4c/0x60 [drm_kms_helper]
[ 23.763912] drm_fbdev_client_hotplug+0xc4/0x150 [drm_kms_helper]
[ 23.763987] drm_fbdev_generic_setup+0x90/0x154 [drm_kms_helper]
[ 23.764061] rcar_du_probe+0x154/0x184 [rcar_du_drm]
[ 23.764103] platform_probe+0x68/0xe0
[ 23.764115] really_probe+0xbc/0x2e0
[ 23.764122] __driver_probe_device+0x78/0xe0
[ 23.764129] driver_probe_device+0xd8/0x15c
[ 23.764136] __driver_attach+0x94/0x19c
[ 23.764143] bus_for_each_dev+0x70/0xd0
[ 23.764149] driver_attach+0x24/0x30
[ 23.764155] bus_add_driver+0x154/0x20c
[ 23.764161] driver_register+0x78/0x130
[ 23.764168] __platform_driver_register+0x28/0x34
[ 23.764176] rcar_du_platform_driver_init+0x20/0x1000 [rcar_du_drm]
Cheers,
Biju
> Subject: [PATCH v2 5/6] drm/fb-helper: Schedule deferred-I/O worker after
> writing to framebuffer
> Schedule the deferred-I/O worker instead of the damage worker after
> writing to the fbdev framebuffer. The deferred-I/O worker then performs
> the dirty-fb update. The fbdev emulation will initialize deferred I/O
> for all drivers that require damage updates. It is therefore a valid
> assumption that the deferred-I/O worker is present.
> It would be possible to perform the damage handling directly from within
> the write operation. But doing this could increase the overhead of the
> write or interfere with a concurrently scheduled deferred-I/O worker.
> Instead, scheduling the deferred-I/O worker with its regular delay of
> 50 ms removes load off the write operation and allows the deferred-I/O
> worker to handle multiple write operations that arrived during the delay
> time window.
> v2:
> * keep drm_fb_helper_damage() (Daniel)
> * use fb_deferred_io_schedule_flush() (Daniel)
> * clarify comments (Daniel)
> Signed-off-by: Thomas Zimmermann <tzimmermann@xxxxxxx>
> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx>
