Hi, I am using drm_simple_kms_helper and writing a new driver. The code is here: https://git.kernel.org/pub/scm/linux/kernel/git/linusw/linux-stericsson.git/log/?h=ux500-mcde It's starting to look acceptable, but I just don't wanna post the driver until I get a clean probe. This is using a command mode-only DSI panel, which naturally will not start generating any vblank interrups all by itself: you tell it explicitly to scan out a frame. However I have set it up to scan out frames continously and generate interrupts continously at each completed frame if struct drm_simple_display_pipe_funcs .enable_vblank() is called, and stop it if .disable_vblank() is called. This works mostly: graphics come out on the display and are then continously updated. Some interrupts come out too: 77: 569 0 GIC-0 80 Level mcde As expected with framebuffer emulation, there is some vblank use when setting it up, then it turns vblanks off again and just count on the display being continously streamed out. But I get a snag when starting up: mcde a0350000.mcde: mcde_display_enable_vblank ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1 at ../drivers/gpu/drm/drm_atomic_helper.c:1424 drm_atomic_helper_wait_for_vblanks.part.1+0x29c/0x2a0 [CRTC:34:crtc-0] vblank wait timed out Modules linked in: CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.0.0-rc1-00005-ga1691ef3e833-dirty #487 Hardware name: ST-Ericsson Ux5x0 platform (Device Tree Support) (unwind_backtrace) from [<c010ba88>] (show_stack+0x10/0x14) (show_stack) from [<c0709020>] (dump_stack+0x88/0x9c) (dump_stack) from [<c011cd48>] (__warn+0xdc/0xf4) (__warn) from [<c011cda8>] (warn_slowpath_fmt+0x48/0x6c) (warn_slowpath_fmt) from [<c03eab04>] (drm_atomic_helper_wait_for_vblanks.part.1+0x29c/0x2a0) (drm_atomic_helper_wait_for_vblanks.part.1) from [<c03ec3fc>] (drm_atomic_helper_commit_tail+0x5c/0x6c) (drm_atomic_helper_commit_tail) from [<c03ec474>] (commit_tail+0x68/0x6c) (commit_tail) from [<c03ec53c>] (drm_atomic_helper_commit+0xbc/0x128) (drm_atomic_helper_commit) from [<c03ef23c>] (restore_fbdev_mode_atomic+0x1c8/0x1d8) (restore_fbdev_mode_atomic) from [<c03f2c6c>] (drm_fb_helper_restore_fbdev_mode_unlocked+0x54/0xa0) (drm_fb_helper_restore_fbdev_mode_unlocked) from [<c03f2ce8>] (drm_fb_helper_set_par+0x30/0x54) (drm_fb_helper_set_par) from [<c0393ec8>] (fbcon_init+0x464/0x574) (fbcon_init) from [<c03cd4e8>] (visual_init+0xbc/0x104) (visual_init) from [<c03cf344>] (do_bind_con_driver+0x1e0/0x3f4) (do_bind_con_driver) from [<c03cf854>] (do_take_over_console+0x84/0x1dc) (do_take_over_console) from [<c039404c>] (do_fbcon_takeover+0x74/0xcc) (do_fbcon_takeover) from [<c013b200>] (notifier_call_chain+0x48/0x84) (notifier_call_chain) from [<c013b9e8>] (blocking_notifier_call_chain+0x44/0x5c) (blocking_notifier_call_chain) from [<c038d54c>] (register_framebuffer+0x228/0x310) (register_framebuffer) from [<c03f2730>] (__drm_fb_helper_initial_config_and_unlock+0x234/0x460) (__drm_fb_helper_initial_config_and_unlock) from [<c03f2a10>] (drm_fb_helper_fbdev_setup+0xb4/0x1e8) (drm_fb_helper_fbdev_setup) from [<c03f30a0>] (drm_fbdev_cma_init+0x8c/0xbc) (drm_fbdev_cma_init) from [<c03f30d8>] (drm_fb_cma_fbdev_init+0x8/0x14) (drm_fb_cma_fbdev_init) from [<c041e478>] (mcde_drm_bind+0xec/0x114) (mcde_drm_bind) from [<c04215e0>] (try_to_bring_up_master+0x140/0x17c) (try_to_bring_up_master) from [<c0421820>] (component_master_add_with_match+0xc8/0xfc) (component_master_add_with_match) from [<c041ea80>] (mcde_probe+0x544/0x58c) (mcde_probe) from [<c0428c44>] (platform_drv_probe+0x48/0x98) (platform_drv_probe) from [<c04270f0>] (really_probe+0x228/0x2d0) (really_probe) from [<c04272fc>] (driver_probe_device+0x60/0x164) (driver_probe_device) from [<c04274d0>] (__driver_attach+0xd0/0xd4) (__driver_attach) from [<c04253e8>] (bus_for_each_dev+0x74/0xb4) (bus_for_each_dev) from [<c0426544>] (bus_add_driver+0x188/0x20c) (bus_add_driver) from [<c0427e08>] (driver_register+0x7c/0x114) (driver_register) from [<c010271c>] (do_one_initcall+0x54/0x194) (do_one_initcall) from [<c0b00e38>] (kernel_init_freeable+0x148/0x1e4) (kernel_init_freeable) from [<c071ee14>] (kernel_init+0x8/0x10c) (kernel_init) from [<c01010e8>] (ret_from_fork+0x14/0x2c) I *think* this is because of a catch 22: the FB emulation want to send the first frame out, so it starts the vblank and wait for the first blank before sending the first new fresh framebuffer update by calling .update(). But since this DSI command mode panel is not going to give any IRQs and thus no vblanks before the first frame is sent, it waits in vain. Video mode DSI panels does not have this characteristic and it seems all other panels we handle are video mode. After the timeout and sending the first frame anyways, of course the vblank starts working. So it seems to me that the FB helper does not really deal very well with this kind of displays that do not support vblank interrupts until you send the first frame. The crtcs state no_vblank should according to documentation be used to overcome these situations. At least sometimes. I could not get that to help at all, but it seems unclear whether any of the helper-based drivers actually use that. My driver will deal with arming the vblank event on the first update (drm_crtc_vblank_get(crtc) == 0)) and sending vblank events in response to updates when the CRTC is not active as is custom. This is just exactly what all other drivers do. Has somebody else seen the same problem or is it just me? Yours, Linus Walleij _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
