- 29 Mar, 2017 20 commits
-
-
Chris Wilson authored
Move the repeated (a - b) <= (1 << 23) to its own function. v2: Catch the '1<<23' inside drm_handle_vblank() as well Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Michel Dänzer <michel@daenzer.net> Link: http://patchwork.freedesktop.org/patch/msgid/20170322100650.26082-1-chris@chris-wilson.co.ukReviewed-by:
Michel Dänzer <michel.daenzer@amd.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Chris Wilson authored
Since we cannot enable the vblank if !dev->irq_enabled, we assert that checking for both !vblank->enabled and !dev->irq_enabled is tautological and only need the former. The only time it may differ is when racing with drm_irq_uninstall(), but that will then disable the vblank and wakeup the waiters. Signed-off-by:
-
Chris Wilson authored
Order the update to vblank->enabled after the timestamp is primed so that a concurrent unlocked reader will only see the vblank->enabled with the current timestamp. v2: vblank->enable is guarded by dev->vbl_lock not dev->vblank_time_lock, update the READ_ONCE accordingly. Do not add a READ_ONCE(vblank->enabled) inside the interrupt handler to avoid missing an interrupt whilst racing with enable_vblank() Signed-off-by:
-
Chris Wilson authored
We want to provide the vblank irq shadow for pageflip events as well as vblank queries. Such events are completed within the vblank interrupt handler, and so the current check for disabling the irq will disable it from with the same interrupt as the last pageflip event. If we move the decision on whether to disable the irq (based on there no being no remaining vblank events, i.e. vblank->refcount == 0) to before we signal the events, we will only disable the irq on the interrupt after the last event was signaled. In the normal course of events, this will keep the vblank irq enabled for the entire flip sequence whereas before it would flip-flop around every interrupt. v2: Move the disable_fn() call outside of the vblank_event_lock. Signed-off-by:
-
Daniel Vetter authored
Another one bites the dust. Again let's not forget to remove the temporary hidden acquire_ctx assignment, now that we pass this all around explicitly it can go away again. Reviewed-by:
Harry Wentland <harry.wentland@amd.com> Signed-off-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-20-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
Surprisingly a lot of legacy drivers roll their own, for runtime pm and because vmwgfx. Also make nouveau's set_config static while at it. Cc: Sinclair Yeh <syeh@vmware.com> Cc: Thomas Hellstrom <thellstrom@vmware.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
-
Daniel Vetter authored
Just the groundwork to have something to feed into ->set_config. Again we need a temporary hack to still fill out the legacy ctx in mode_config.acquire_ctx. Reviewed-by:
-
Daniel Vetter authored
This is another case where we really can't reconstruct a acquire ctx in any useful fashion because all the callers are legacy drivers. So like drm_plane_force_disable simply restrict it to non-atomic drivers so that it's clear we're ok with passing a NULL ctx. Reviewed-by:
Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-17-daniel.vetter@ffwll.ch
-
Daniel Vetter authored
No need to grab both plane and crtc locks at the same time, we can do them one after the other. If userspace races it'll get what it deserves either way. This removes another user of drm_modeset_lock_crtc. There's only one left. v2: Make sure all access to primary->state is properly protected (Harry). Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Daniel Vetter authored
Yay, we can now properly retry in case of deadlocks or whatever! Also don't forget to remove the transitional crtc->acquire_ctx assignment again. Reviewed-by:
-
Daniel Vetter authored
Again just going through the motions, no functional changes in here. Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Reviewed-by:
-
Daniel Vetter authored
Again just prep work. Reviewed-by:
-
Daniel Vetter authored
We can now properly retry at the top level, yay! v2: Also remove the temporary acquire_ctx hack again, no longer needed! Reviewed-by:
-
Daniel Vetter authored
Nouveau had a few direct calls to ->disable_plane, I replaced those with drm_plane_force_disable. Same story for shmob. Otherwise no code changes. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by:
-
Daniel Vetter authored
This way I can explain why it'll be fine to pass a NULL acquire ctx here in the next patch. Reviewed-by:
-
Daniel Vetter authored
Just rolling it out, no code change here. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: Russell King <linux@armlinux.org.uk> Cc: Rob Clark <robdclark@gmail.com> Cc: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Cc: Eric Anholt <eric@anholt.net> Reviewed-by:
-
Daniel Vetter authored
This is just prep work to get an acquire ctx into every place where we call ->update_plane or ->disable_plane. v2: Keep the hidden acquire_ctx pointers valid while transitioning. Reviewed-by:
-
Daniel Vetter authored
Mostly because I want the links from the newly-added @state functions to work. But I think explaining when they're useful and that the implicit one is deprecated is good either way. Slightly repetitive unfortunately. Cc: Harry Wentland <harry.wentland@amd.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Reviewed-by:
Alex Deucher <alexander.deucher@amd.com> Reviewed-by:
-
Daniel Vetter authored
The rules are getting real hard, better to dump my brain into text a bit. This is by far not complete, but I think I reasonable start at least. Some of the older kms structures would need a full doc review anyway ... Cc: Harry Wentland <harry.wentland@amd.com> Reviewed-by:
-
Daniel Vetter authored
They're properly documented in drm_connector.c now, and this csv file is a horrible mess. Better to remove it. Reviewed-by:
-
- 28 Mar, 2017 1 commit
-
-
Shashank Sharma authored
This patch adds description about 'scdc' variable in drm_hdmi_info structure, to fix this warning during doc-build. "drm_connector.h:140: warning: No description found for parameter 'scdc'" V2: Rebase V3: Added extra * V4: Removed merged conflict V5: Removed extra line at start of structure (Daniel) V6: Make description single line (Daniel) Cc: Daniel Vetter <daniel@ffwll.ch> Signed-off-by:
Shashank Sharma <shashank.sharma@intel.com> Signed-off-by:
-
- 27 Mar, 2017 5 commits
-
-
Daniel Vetter authored
Yes the help text is unhelpful, but atomic drivers should never use this. Just grab the lock without context or anything. Also an aside: Checking ->active like this doesn't protect against nonblocking commits, this is rather bogus. Cc: Thierry Reding <thierry.reding@gmail.com> Acked-by:
Thierry Reding <thierry.reding@gmail.com> Signed-off-by:
-
Gabriel Krisman Bertazi authored
If fbdev registration fails for whatever reason, the error path of bochs_fbdev_init() will call bochs_fbdev_fini(), but since an fbdev initialization error is not fatal to the probe function, a subsequent device removal will try to call bochs_fbdev_fini() again, hitting the Oops below. This was detected by 0-day with a failing framebuffer registration and CONFIG_DEBUG_TEST_DRIVER_REMOVE=y. This reproduces the scenario I mentioned above at insmod time, because the test attempts to remove the device right after probing. root@debian:~# insmod bochs-drm.ko [ 17.609635] [drm] Found bochs VGA, ID 0xb0c0. [ 17.612974] [drm] Framebuffer size 16384 kB @ 0xfa000000, mmio @ 0xfebf2000. [ 17.613938] [TTM] Zone kernel: Available graphics memory: 1022244 kiB [ 17.614701] [TTM] Initializing pool allocator [ 17.615427] [TTM] Initializing DMA pool allocator [ 17.619143] fbcon: bochsdrmfb (fb0) is primary device [ 17.619428] Console: switching to colour frame buffer device 128x48 [ 17.621047] bochs-drm 0000:00:02.0: fb0: bochsdrmfb frame buffer device [ 17.641111] [drm] Initialized bochs-drm 1.0.0 20130925 for 0000:00:02.0 on minor 0 [ 17.642380] general protection fault: 0000 [#1] SMP [ 17.642985] Modules linked in: bochs_drm(+) [ 17.643259] CPU: 4 PID: 3279 Comm: insmod Tainted: G W 4.11.0-rc1+ #119 [ 17.643259] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.9.3-20161025_171302-gandalf 04/01/2014 [ 17.643259] task: ffff88007af35e00 task.stack: ffffc90000d84000 [ 17.643259] RIP: 0010:drm_fb_helper_fini+0x8e/0x110 [ 17.643259] RSP: 0018:ffffc90000d87ad0 EFLAGS: 00010202 [ 17.643259] RAX: dead000000000200 RBX: ffff8800790d5770 RCX: 0000000000000000 [ 17.652101] RDX: dead000000000100 RSI: 000000007fffffff RDI: ffffffff81eaf820 [ 17.652101] RBP: ffffc90000d87ae0 R08: 0000000000000000 R09: ffff88007271d918 [ 17.652101] R10: ffffc90000d87a88 R11: 0000000000000000 R12: 0000000000000000 [ 17.652101] R13: ffff8800790d56d0 R14: 0000000000000000 R15: 0000000000000000 [ 17.652101] FS: 00007f9285995700(0000) GS:ffff88007cf00000(0000) knlGS:0000000000000000 [ 17.652101] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 17.652101] CR2: 0000564f1cf9f1e8 CR3: 0000000079686000 CR4: 00000000000006e0 [ 17.652101] Call Trace: [ 17.652101] bochs_fbdev_fini+0x24/0x90 [bochs_drm] [ 17.652101] bochs_unload+0x16/0x50 [bochs_drm] [ 17.652101] drm_dev_unregister+0x37/0xd0 [ 17.652101] drm_put_dev+0x31/0x60 [ 17.652101] bochs_pci_remove+0x10/0x20 [bochs_drm] [ 17.652101] pci_device_remove+0x34/0xb0 [ 17.652101] driver_probe_device+0xd0/0x370 [ 17.652101] __driver_attach+0x96/0xa0 [ 17.652101] ? driver_probe_device+0x370/0x370 [ 17.652101] bus_for_each_dev+0x5b/0x90 [ 17.652101] driver_attach+0x19/0x20 [ 17.652101] bus_add_driver+0x11c/0x220 [ 17.652101] driver_register+0x5b/0xd0 [ 17.652101] ? 0xffffffffa0006000 [ 17.652101] __pci_register_driver+0x47/0x50 [ 17.652101] drm_pci_init+0xe1/0xf0 [ 17.652101] ? 0xffffffffa0006000 [ 17.652101] bochs_init+0x3c/0x1000 [bochs_drm] [ 17.652101] do_one_initcall+0x3e/0x180 [ 17.652101] ? kmem_cache_alloc_trace+0x33/0x150 [ 17.652101] do_init_module+0x5a/0x1eb [ 17.652101] load_module+0x1ea0/0x2650 [ 17.652101] ? __symbol_put+0x40/0x40 [ 17.652101] ? kernel_read_file+0x19e/0x1c0 [ 17.652101] ? kernel_read_file_from_fd+0x44/0x70 [ 17.652101] SYSC_finit_module+0xba/0xc0 [ 17.652101] SyS_finit_module+0x9/0x10 [ 17.652101] entry_SYSCALL_64_fastpath+0x1a/0xa9 [ 17.652101] RIP: 0033:0x7f92854da119 [ 17.652101] RSP: 002b:00007ffcd0390498 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 17.652101] RAX: ffffffffffffffda RBX: 00007f928578eb58 RCX: 00007f92854da119 [ 17.652101] RDX: 0000000000000000 RSI: 0000564f1c8bd638 RDI: 0000000000000003 [ 17.652101] RBP: 000000000000270e R08: 0000000000000000 R09: 00007f9285790ea0 [ 17.652101] R10: 0000000000000003 R11: 0000000000000246 R12: 00007f928578eb58 [ 17.652101] R13: 0000000000001020 R14: 0000564f1cf9e1c0 R15: 00007f928578eb00 [ 17.652101] Code: c7 20 f8 ea 81 e8 b3 3e 50 00 48 8b 83 d0 00 00 00 48 8d 93 d0 00 00 00 48 39 c2 74 46 48 8b 83 d8 00 00 00 48 8b 93 d0 00 00 00 <48> 89 42 08 48 89 10 48 b8 00 01 00 00 0000 ad de 48 89 83 d0 [ 17.652101] RIP: drm_fb_helper_fini+0x8e/0x110 RSP: ffffc90000d87ad0 [ 17.653331] ---[ end trace 542fd75a2e60a6a4 ]--- Signed-off-by:
Gabriel Krisman Bertazi <krisman@collabora.co.uk> Link: http://patchwork.freedesktop.org/patch/msgid/20170324045444.11912-1-krisman@collabora.co.ukSigned-off-by:
Gerd Hoffmann <kraxel@redhat.com>
-
Daniel Vetter authored
The trouble here is that it does multiple atomic commits under one drm_modeset_lock_all, which breaks the behind-the-scenes acquire context magic that function pulls off. It's much better to have one overall atomic commit. That we still have multiple atomic commits prevents us from adding some pretty useful debug checks to the atomic machinery. Hence it is really a bad idea to call the legacy drm_crtc_force_disable_all() function. There's 2 atomic drivers using this still, nouveau and tinydrm. To fix this, introduce a new drm_atomic_helper_shutdown() by extracting the code from i915. While at it improve kernel-doc and catch future offenders by sprinkling a WARN_ON into the legacy function. We should probably move those into the legacy modeset helpers, too ... v2: Make it compile on arm drivers too (Noralf). v3: Correct kerneldoc to point at _disable_all(). Reviewed-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by:
Noralf Trønnes <noralf@tronnes.org> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Noralf Trønnes <noralf@tronnes.org> Cc: Ben Skeggs <bskeggs@redhat.com> Tested-by:
Tomi Valkeinen <tomi.valkeinen@ti.com> Signed-off-by:
-
Noralf Trønnes authored
drm_driver.fops can't be shared since the owner then becomes tinydrm.ko. Move the fops declaration to the driver. v2: Use DEFINE_DRM_GEM_CMA_FOPS Reported-by:
-
Romain Perier authored
Currently, the irq handler that monitors changes for HPD and RX_SENSE relies on the status of the bridge for updating the status of the HPD. The update is done only when the bridge is enabled. However, on Rockchip platforms we have found use cases where it could be a problem. When HDMI is being used, turning off/on the screen or unplugging/re-plugging the cable, the following simplified code path will happen: - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is on hdmi->disabled is false, then the handler will update the rxsense flag accordingly. - dw_hdmi_update_power() will be invoked with the mode DRM_FORCE_UNSPECIFIED and rxsense == 1, so dw_hdmi_poweroff() will be called and the PHY will be desactivated (its pixel clocks and TMDS) [...] - dw_hdmi_bridge_disable() will be invoked, the bridge will be marked as disabled. - dw_hdmi_irq() will be triggered by an HPD event, as the bridge is currently disabled the HPD status won't be updated, so hdmi->rxsense won't be changed. Even if the data part of the PHY is disabled, this information coming from the HDMI Transmitter is correct and should be saved. [...] - dw_hdmi_bridge_enable() will be invoked, the bridge will be marked as enabled. - dw_hdmi_update_power() will be called. When hdmi->force is equal to DRM_FORCE_UNSPECIFIED the function will rely on hdmi->rxsense. If this field has not been updated by the irq handler, it will be false and DRM_FORCE_ON won't be put to hdmi->force. Consequently, most of the time dw_hdmi_poweron() won't be called in this use case, TMDS won't be re-enabled the PHY won't be re-initialized, resulting in a "Signal not found". This commit fixes the issue by removing the check for "!hdmi->disabled". As already explained, even if the PHY is partially disabled, information coming from HDMI Transmitter about HPD should be saved for a later use. Signed-off-by:
Romain Perier <romain.perier@collabora.com> Signed-off-by:
Archit Taneja <architt@codeaurora.org> Link: https://patchwork.freedesktop.org/patch/143602/
-
- 25 Mar, 2017 4 commits
-
-
Daniel Vetter authored
The core code doesn't care at all about this, it's entirely dead. Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Reviewed-by:
-
Daniel Vetter authored
Discussed with Noralf on the list a bit. An open question is tinydrm vs. drm_panel, but until we have a clear idea what's really needed in that space, I think it's best to just move forward with what we have. Cc: Noralf Trønnes <noralf@tronnes.org> Acked-by:
-
Daniel Vetter authored
To match the drm_ioctl.c we already have. v2: Remove spurious space (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
Again this is an internal helper, not the official way to lock a crtc. Cc: Jyri Sarha <jsarha@ti.com> Cc: Tomi Valkeinen <tomi.valkeinen@ti.com> Reviewed-by:
Jyri Sarha <jsarha@ti.com> Signed-off-by:
-
- 24 Mar, 2017 9 commits
-
-
Chris Zhong authored
For the RK3399, the grf_switch_reg name should be RK3399_GRF_SOC_CON20, not RK3399_GRF_SOC_CON19. Signed-off-by:
Chris Zhong <zyw@rock-chips.com> Reviewed-by:
Brian Norris <briannorris@chromium.org> Reviewed-by:
Sean Paul <seanpaul@chromium.org> Signed-off-by:
-
Chris Zhong authored
For RK3399, the grf clk should be enabled before writing grf registers, otherwise the register value can not be changed. Signed-off-by:
-
Chris Zhong authored
For RK3399, the grf clock should be controlled by dw-mipi-dsi driver, add the description for this clock. Acked-by: Rob Herring <robh@kernel.org Signed-off-by:
-
Chris Zhong authored
For RK3399, the phy_cfg_clk is a required clock, if phy_cfg_clk is disabled, MIPI phy can not work. Let's return a error if there is no phy_cfg_clk in dts property, when the pdata match RK3399. Signed-off-by:
-
Jeffy Chen authored
Currently we are adding all components from the dts, if one of their drivers been disabled, we would not be able to bring up others. Refactor component match logic, follow exynos drm. Signed-off-by:
Jeffy Chen <jeffy.chen@rock-chips.com> Reviewed-by:
Andrzej Hajda <a.hajda@samsung.com> Acked-by:
Mark Yao <mark.yao@rock-chips.com> Tested-by:
Heiko Stuebner <heiko@sntech.de> Signed-off-by:
-
Daniel Vetter authored
I've decided to not document drm_debugfs_remove_files, it's on the way out. The biggest part is a huge todo.rst entry with what all should be improved. v2: Nits from Gabriel. Cc: Gabriel Krisman Bertazi <krisman@collabora.co.uk> Reviewed-by:
-
Daniel Vetter authored
This was missed in Tomeu's patch. Also remove the kerneldoc for the internal function, we don't document that in general. While at it word-smith the docs slightly for more clarity. Cc: Tomeu Vizoso <tomeu.vizoso@collabora.com> Reviewed-by:
Tomeu Vizoso <tomeu.vizoso@collabora.com> Signed-off-by:
-
Daniel Vetter authored
Doc polish will follow in the next patch. v2: Put the include guard #endif at the end (Ville). Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Daniel Vetter authored
It's the default storage class for functions, entirely redundant. And a lot of these headers are a bit inconsistent due to organically grown. Reviewed-by:
-
- 23 Mar, 2017 1 commit
-
-
Jani Nikula authored
Fix sparse warning: drivers/gpu/drm/drm_scdc_helper.c:138:6: warning: symbol 'drm_scdc_get_scrambling_status' was not declared. Should it be static? Fixes: 62c58af3 ("drm/edid: detect SCDC support in HF-VSDB") Cc: Shashank Sharma <shashank.sharma@intel.com> Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1490193218-24806-1-git-send-email-jani.nikula@intel.com
-
