summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/nouveau/nouveau_display.c
AgeCommit message (Collapse)AuthorFilesLines
2018-07-30BackMerge v4.18-rc7 into drm-nextDave Airlie1-2/+8
rmk requested this for armada and I think we've had a few conflicts build up. Signed-off-by: Dave Airlie <airlied@redhat.com>
2018-07-16drm/nouveau: Replace drm_gem_object_unreference_unlocked with put functionThomas Zimmermann1-4/+4
This patch unifies the naming of DRM functions for reference counting of struct drm_gem_object. The resulting code is more aligned with the rest of the Linux kernel interfaces. Signed-off-by: Thomas Zimmermann <tdz@users.sourceforge.net> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-16drm/nouveau: Avoid looping through fake MST connectorsLyude Paul1-2/+2
When MST and atomic were introduced to nouveau, another structure that could contain a drm_connector embedded within it was introduced; struct nv50_mstc. This meant that we no longer would be able to simply loop through our connector list and assume that nouveau_connector() would return a proper pointer for each connector, since the assertion that all connectors coming from nouveau have a full nouveau_connector struct became invalid. Unfortunately, none of the actual code that looped through connectors ever got updated, which means that we've been causing invalid memory accesses for quite a while now. An example that was caught by KASAN: [ 201.038698] ================================================================== [ 201.038792] BUG: KASAN: slab-out-of-bounds in nvif_notify_get+0x190/0x1a0 [nouveau] [ 201.038797] Read of size 4 at addr ffff88076738c650 by task kworker/0:3/718 [ 201.038800] [ 201.038822] CPU: 0 PID: 718 Comm: kworker/0:3 Tainted: G O 4.18.0-rc4Lyude-Test+ #1 [ 201.038825] Hardware name: LENOVO 20EQS64N0B/20EQS64N0B, BIOS N1EET78W (1.51 ) 05/18/2018 [ 201.038882] Workqueue: events nouveau_display_hpd_work [nouveau] [ 201.038887] Call Trace: [ 201.038894] dump_stack+0xa4/0xfd [ 201.038900] print_address_description+0x71/0x239 [ 201.038929] ? nvif_notify_get+0x190/0x1a0 [nouveau] [ 201.038935] kasan_report.cold.6+0x242/0x2fe [ 201.038942] __asan_report_load4_noabort+0x19/0x20 [ 201.038970] nvif_notify_get+0x190/0x1a0 [nouveau] [ 201.038998] ? nvif_notify_put+0x1f0/0x1f0 [nouveau] [ 201.039003] ? kmsg_dump_rewind_nolock+0xe4/0xe4 [ 201.039049] nouveau_display_init.cold.12+0x34/0x39 [nouveau] [ 201.039089] ? nouveau_user_framebuffer_create+0x120/0x120 [nouveau] [ 201.039133] nouveau_display_resume+0x5c0/0x810 [nouveau] [ 201.039173] ? nvkm_client_ioctl+0x20/0x20 [nouveau] [ 201.039215] nouveau_do_resume+0x19f/0x570 [nouveau] [ 201.039256] nouveau_pmops_runtime_resume+0xd8/0x2a0 [nouveau] [ 201.039264] pci_pm_runtime_resume+0x130/0x250 [ 201.039269] ? pci_restore_standard_config+0x70/0x70 [ 201.039275] __rpm_callback+0x1f2/0x5d0 [ 201.039279] ? rpm_resume+0x560/0x18a0 [ 201.039283] ? pci_restore_standard_config+0x70/0x70 [ 201.039287] ? pci_restore_standard_config+0x70/0x70 [ 201.039291] ? pci_restore_standard_config+0x70/0x70 [ 201.039296] rpm_callback+0x175/0x210 [ 201.039300] ? pci_restore_standard_config+0x70/0x70 [ 201.039305] rpm_resume+0xcc3/0x18a0 [ 201.039312] ? rpm_callback+0x210/0x210 [ 201.039317] ? __pm_runtime_resume+0x9e/0x100 [ 201.039322] ? kasan_check_write+0x14/0x20 [ 201.039326] ? do_raw_spin_lock+0xc2/0x1c0 [ 201.039333] __pm_runtime_resume+0xac/0x100 [ 201.039374] nouveau_display_hpd_work+0x67/0x1f0 [nouveau] [ 201.039380] process_one_work+0x7a0/0x14d0 [ 201.039388] ? cancel_delayed_work_sync+0x20/0x20 [ 201.039392] ? lock_acquire+0x113/0x310 [ 201.039398] ? kasan_check_write+0x14/0x20 [ 201.039402] ? do_raw_spin_lock+0xc2/0x1c0 [ 201.039409] worker_thread+0x86/0xb50 [ 201.039418] kthread+0x2e9/0x3a0 [ 201.039422] ? process_one_work+0x14d0/0x14d0 [ 201.039426] ? kthread_create_worker_on_cpu+0xc0/0xc0 [ 201.039431] ret_from_fork+0x3a/0x50 [ 201.039441] [ 201.039444] Allocated by task 79: [ 201.039449] save_stack+0x43/0xd0 [ 201.039452] kasan_kmalloc+0xc4/0xe0 [ 201.039456] kmem_cache_alloc_trace+0x10a/0x260 [ 201.039494] nv50_mstm_add_connector+0x9a/0x340 [nouveau] [ 201.039504] drm_dp_add_port+0xff5/0x1fc0 [drm_kms_helper] [ 201.039511] drm_dp_send_link_address+0x4a7/0x740 [drm_kms_helper] [ 201.039518] drm_dp_check_and_send_link_address+0x1a7/0x210 [drm_kms_helper] [ 201.039525] drm_dp_mst_link_probe_work+0x71/0xb0 [drm_kms_helper] [ 201.039529] process_one_work+0x7a0/0x14d0 [ 201.039533] worker_thread+0x86/0xb50 [ 201.039537] kthread+0x2e9/0x3a0 [ 201.039541] ret_from_fork+0x3a/0x50 [ 201.039543] [ 201.039546] Freed by task 0: [ 201.039549] (stack is not available) [ 201.039551] [ 201.039555] The buggy address belongs to the object at ffff88076738c1a8 which belongs to the cache kmalloc-2048 of size 2048 [ 201.039559] The buggy address is located 1192 bytes inside of 2048-byte region [ffff88076738c1a8, ffff88076738c9a8) [ 201.039563] The buggy address belongs to the page: [ 201.039567] page:ffffea001d9ce200 count:1 mapcount:0 mapping:ffff88084000d0c0 index:0x0 compound_mapcount: 0 [ 201.039573] flags: 0x8000000000008100(slab|head) [ 201.039578] raw: 8000000000008100 ffffea001da3be08 ffffea001da25a08 ffff88084000d0c0 [ 201.039582] raw: 0000000000000000 00000000000d000d 00000001ffffffff 0000000000000000 [ 201.039585] page dumped because: kasan: bad access detected [ 201.039588] [ 201.039591] Memory state around the buggy address: [ 201.039594] ffff88076738c500: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 201.039598] ffff88076738c580: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [ 201.039601] >ffff88076738c600: 00 00 00 00 00 00 00 00 00 00 fc fc fc fc fc fc [ 201.039604] ^ [ 201.039607] ffff88076738c680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 201.039611] ffff88076738c700: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc [ 201.039613] ================================================================== Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Cc: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-16drm/nouveau: Use drm_connector_list_iter_* for iterating connectorsLyude Paul1-2/+8
Every codepath in nouveau that loops through the connector list currently does so using the old method, which is prone to race conditions from MST connectors being created and destroyed. This has been causing a multitude of problems, including memory corruption from trying to access connectors that have already been freed! Signed-off-by: Lyude Paul <lyude@redhat.com> Cc: stable@vger.kernel.org Cc: Karol Herbst <karolherbst@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-05-18drm/nouveau/kms: move display class instantiation to libraryBen Skeggs1-28/+7
This function is useful outside of DRM code. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-04-27drm: Don't pass the index to drm_property_add_enum()Ville Syrjälä1-3/+1
drm_property_add_enum() can calculate the index itself just fine, so no point in having the caller pass it in. Cc: Patrik Jakobsson <patrik.r.jakobsson@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180316190420.26734-1-ville.syrjala@linux.intel.com Reviewed-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
2017-12-08drm/nouveau: Use drm_fb_helper_output_poll_changed()Noralf Trønnes1-1/+2
This driver can use drm_fb_helper_output_poll_changed() instead of its own nouveau_fbcon_output_poll_changed(). Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Noralf Trønnes <noralf@tronnes.org> Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20171205182504.41923-8-noralf@tronnes.org
2017-08-22drm/nouveau/kms/nv04-nv40: prevent undisplayable framebuffers from creationIlia Mirkin1-0/+21
Pre-nv50 YUV overlays have stringent requirements for working with the internal machinery. Instead of rejecting these at update_plane time, we should instead prevent the framebuffers from being created in the first place. Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-08-15Backmerge tag 'v4.13-rc5' into drm-nextDave Airlie1-5/+0
Linux 4.13-rc5 There's a really nasty nouveau collision, hopefully someone can take a look once I pushed this out.
2017-07-24drm/nouveau/kms: remove call to drm_crtc_vblank_off() during unload/suspendBen Skeggs1-5/+0
These on()/off() calls should be done as a result of modesetting actions, and as we shut down all heads already on unload/suspend, it's pointless to call off() again. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-06-27Merge remote-tracking branch 'airlied/drm-next' into drm-misc-nextSean Paul1-4/+2
Required for Daniel's drm_vblank_cleanup cleanup
2017-06-26drm/nouveau: Drop drm_vblank_cleanupDaniel Vetter1-2/+0
nouveau_display_vblank_fini is called in the load error path (where it doesn't matter) and module unload (where vblanks have been shut down correctly already through drm_vblank_off), we can drop it. Cc: Ben Skeggs <bskeggs@redhat.com> Cc: nouveau@lists.freedesktop.org Reviewed-by: Sean Paul <seanpaul@chromium.org> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170621082850.13224-8-daniel.vetter@ffwll.ch
2017-05-30Backmerge tag 'v4.12-rc3' into drm-nextDave Airlie1-4/+2
Linux 4.12-rc3 Daniel has requested this for some drm-intel-next work.
2017-05-17drm/nouveau: Fix drm poll_helper handlingPeter Ujfalusi1-4/+2
Commit cae9ff036eea effectively disabled the drm poll_helper by checking the wrong flag to see if the driver should enable the poll or not: mode_config.poll_enabled is only set to true by poll_init and it is not indicating if the poll is enabled or not. nouveau_display_create() will initialize the poll and going to disable it right away. After poll_init() the mode_config.poll_enabled will be true, but the poll itself is disabled. To avoid the race caused by calling the poll_enable() from different paths, this patch will enable the poll from one place, in the nouveau_display_hpd_work(). In case the pm_runtime is disabled we will enable the poll in nouveau_drm_load() once. Fixes: cae9ff036eea ("drm/nouveau: Don't enabling polling twice on runtime resume") Signed-off-by: Peter Ujfalusi <peter.ujfalusi@ti.com> Reviewed-by: Lyude <lyude@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-05-10drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutposDaniel Vetter1-31/+7
If we restrict this helper to only kms drivers (which is the case) we can look up the correct mode easily ourselves. But it's a bit tricky: - All legacy drivers look at crtc->hwmode. But that is updated already at the beginning of the modeset helper, which means when we disable a pipe. Hence the final timestamps might be a bit off. But since this is an existing bug I'm not going to change it, but just try to be bug-for-bug compatible with the current code. This only applies to radeon&amdgpu. - i915 tries to get it perfect by updating crtc->hwmode when the pipe is off (i.e. vblank->enabled = false). - All other atomic drivers look at crtc->state->adjusted_mode. Those that look at state->requested_mode simply don't adjust their mode, so it's the same. That has two problems: Accessing crtc->state from interrupt handling code is unsafe, and it's updated before we shut down the pipe. For nonblocking modesets it's even worse. For atomic drivers try to implement what i915 does. To do that we add a new hwmode field to the vblank structure, and update it from drm_calc_timestamping_constants(). For atomic drivers that's called from the right spot by the helper library already, so all fine. But for safety let's enforce that. For legacy driver this function is only called at the end (oh the fun), which is broken, so again let's not bother and just stay bug-for-bug compatible. The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos directly to implement ->get_vblank_timestamp in every driver, deleting a lot of code. v2: Completely new approach, trying to mimick the i915 solution. v3: Fixup kerneldoc. v4: Drop the WARN_ON to check that the vblank is off, atomic helpers currently unconditionally call this. Recomputing the same stuff should be harmless. v5: Fix typos and move misplaced hunks to the right patches (Neil). v6: Undo hunk movement (kbuild). Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-4-daniel.vetter@ffwll.ch
2017-05-10drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestampDaniel Vetter1-2/+3
It's overkill to have a flag parameter which is essentially used just as a boolean. This takes care of core + adjusting drivers. Adjusting the scanout position callback is a bit harder, since radeon also supplies it's own driver-private flags in there. v2: Fixup misplaced hunks (Neil). v3: kbuild says v1 was better ... Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-2-daniel.vetter@ffwll.ch
2017-05-10drm/vblank: Switch drm_driver->get_vblank_timestamp to return a boolDaniel Vetter1-2/+2
There's really no reason for anything more: - Calling this while the crtc vblank stuff isn't set up is a driver bug. Those places alrready DRM_ERROR. - Calling this when the crtc is off is either a driver bug (calling drm_crtc_handle_vblank at the wrong time) or a core bug (for anything else). Again, we DRM_ERROR. - EINVAL is checked at higher levels already, and if we'd use struct drm_crtc * instead of (dev, pipe) it would be real obvious that those are again core bugs. The only valid failure mode is crap hardware that couldn't sample a useful timestamp, to ask the core to just grab a not-so-accurate timestamp. Bool is perfectly fine for that. v2: Also fix up the one caller, I lost that in the shuffling (Jani). v3: Fixup commit message (Neil). Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Mario Kleiner <mario.kleiner@tuebingen.mpg.de> Cc: Eric Anholt <eric@anholt.net> Cc: Rob Clark <robdclark@gmail.com> Cc: linux-arm-msm@vger.kernel.org Cc: freedreno@lists.freedesktop.org Cc: Alex Deucher <alexander.deucher@amd.com> Cc: Christian König <christian.koenig@amd.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Neil Armstrong <narmstrong@baylibre.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170509140329.24114-1-daniel.vetter@ffwll.ch
2017-04-29drm/nouveau/kms: Increase max retries in scanout position queries.Mario Kleiner1-1/+1
So far we only allowed for 1 retry and just failed the query - and thereby high precision vblank timestamping - if we did not get a reasonable result, as such a failure wasn't considered all too horrible. There are a few NVidia gpu models out there which may need a bit more than 1 retry to get a successful query result under some conditions. Since Linux 4.4 the update code for vblank counter and timestamp in drm_update_vblank_count() changed so that the implementation assumes that high precision vblank timestamping of a kms driver either consistently succeeds or consistently fails for a given video mode and encoder/connector combo. Iow. switching from success to fail or vice versa on a modeset or connector change is ok, but spurious temporary failure for a given setup can confuse the core code and potentially cause bad miscounting of vblanks and confusion or hangs in userspace clients which rely on vblank stuff, e.g., desktop compositors. Therefore change the max retry count to a larger number - more than any gpu so far is known to need to succeed, but still low enough so that these queries which do also happen in vblank interrupt are still fast enough to be not disastrously long if something would go badly wrong with them. As such sporadic retries only happen seldom even on affected gpu's, this could mean a vblank irq could take a few dozen microseconds longer every few hours of uptime -- better than a desktop compositor randomly hanging every couple of hours or days of uptime in a hard to reproduce manner. Signed-off-by: Mario Kleiner <mario.kleiner.de@gmail.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-03-29drm: Add acquire ctx parameter to ->page_flip(_target)Daniel Vetter1-1/+2
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: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>t Link: http://patchwork.freedesktop.org/patch/msgid/20170322215058.8671-12-daniel.vetter@ffwll.ch
2017-03-27drm/atomic: Introduce drm_atomic_helper_shutdownDaniel Vetter1-2/+6
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: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20170321164149.31531-1-daniel.vetter@ffwll.ch
2017-02-28drm/atomic: Make disable_all helper fully disable the crtc.Maarten Lankhorst1-112/+1
It seems that nouveau requires this, so best to do this in the helper. This allows nouveau to use the atomic suspend helper. Cc: nouveau@lists.freedesktop.org Acked-by: Ben Skeggs <bskeggs@redhat.com> #irc Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1487685102-31991-2-git-send-email-maarten.lankhorst@linux.intel.com
2017-02-23Merge tag 'v4.10-rc8' into drm-nextDave Airlie1-1/+2
Linux 4.10-rc8 Backmerge Linus rc8 to fix some conflicts, but also to avoid pulling it in via a fixes pull from someone.
2017-02-17drm/nouveau: allocate device object for every clientBen Skeggs1-7/+7
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-02-17drm/nouveau: pass nvif_client to nouveau_gem_new() instead of drm_deviceBen Skeggs1-1/+2
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2017-01-27drm/nouveau: Don't enabling polling twice on runtime resumeLyude Paul1-1/+2
As it turns out, on cards that actually have CRTCs on them we're already calling drm_kms_helper_poll_enable(drm_dev) from nouveau_display_resume() before we call it in nouveau_pmops_runtime_resume(). This leads us to accidentally trying to enable polling twice, which results in a potential deadlock between the RPM locks and drm_dev->mode_config.mutex if we end up trying to enable polling the second time while output_poll_execute is running and holding the mode_config lock. As such, make sure we only enable polling in nouveau_pmops_runtime_resume() if we need to. This fixes hangs observed on the ThinkPad W541 Signed-off-by: Lyude <lyude@redhat.com> Cc: Hans de Goede <hdegoede@redhat.com> Cc: Kilian Singer <kilian.singer@quantumtechnology.info> Cc: Lukas Wunner <lukas@wunner.de> Cc: David Airlie <airlied@redhat.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-01-18drm: nouveau: use crtc helper drm_crtc_from_index()Shawn Guo1-15/+18
Use drm_crtc_from_index() to find drm_crtc for given index. Signed-off-by: Shawn Guo <shawn.guo@linaro.org> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Sean Paul <seanpaul@chromium.org> Link: http://patchwork.freedesktop.org/patch/msgid/1483961145-18453-5-git-send-email-shawnguo@kernel.org
2016-12-27drm: Wrap the check for atomic_commit implementationDhinakaran Pandiyan1-3/+3
This check is useful for drivers that do not have DRIVER_ATOMIC set but have atomic modesetting internally implemented. Wrap the check into a function since this is used in many places and as a bonus, the function name helps to document what the check is for. v2: Change return type to bool (Ville) Move the function drm_atomic.h (Daniel) Fixed comment marker for documentation Suggested-by: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> [danvet: Move back to drmP.h because include hell.] Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1482396643-32456-1-git-send-email-dhinakaran.pandiyan@intel.com
2016-12-15drm: Nuke fb->bits_per_pixelVille Syrjälä1-1/+1
Replace uses of fb->bits_per_pixel with fb->format->cpp[0]*8. Less duplicated information is a good thing. Note that I didn't put parens around the cpp*8 in the below cocci script, on account of not wanting spurious parens all over the place. Instead I did the unsafe way, and tried to look over the entire diff to spot if any dangerous expressions were produced. I didn't see any. There are some cases where previously the code did X*bpp/8, so the division happened after the multiplication. Those are now just X*cpp so the division effectively happens before the multiplication, but that is perfectly fine since bpp is always a multiple of 8. @@ struct drm_framebuffer *FB; expression E; @@ drm_helper_mode_fill_fb_struct(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ i9xx_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ ironlake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer *FB; expression E; @@ skylake_get_initial_plane_config(...) { ... - FB->bits_per_pixel = E; ... } @@ struct drm_framebuffer FB; expression E; @@ ( - E * FB.bits_per_pixel / 8 + E * FB.format->cpp[0] | - FB.bits_per_pixel / 8 + FB.format->cpp[0] | - E * FB.bits_per_pixel >> 3 + E * FB.format->cpp[0] | - FB.bits_per_pixel >> 3 + FB.format->cpp[0] | - (FB.bits_per_pixel + 7) / 8 + FB.format->cpp[0] | - FB.bits_per_pixel + FB.format->cpp[0] * 8 | - FB.format->cpp[0] * 8 != 8 + FB.format->cpp[0] != 1 ) @@ struct drm_framebuffer *FB; expression E; @@ ( - E * FB->bits_per_pixel / 8 + E * FB->format->cpp[0] | - FB->bits_per_pixel / 8 + FB->format->cpp[0] | - E * FB->bits_per_pixel >> 3 + E * FB->format->cpp[0] | - FB->bits_per_pixel >> 3 + FB->format->cpp[0] | - (FB->bits_per_pixel + 7) / 8 + FB->format->cpp[0] | - FB->bits_per_pixel + FB->format->cpp[0] * 8 | - FB->format->cpp[0] * 8 != 8 + FB->format->cpp[0] != 1 ) @@ struct drm_plane_state *state; expression E; @@ ( - E * state->fb->bits_per_pixel / 8 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel / 8 + state->fb->format->cpp[0] | - E * state->fb->bits_per_pixel >> 3 + E * state->fb->format->cpp[0] | - state->fb->bits_per_pixel >> 3 + state->fb->format->cpp[0] | - (state->fb->bits_per_pixel + 7) / 8 + state->fb->format->cpp[0] | - state->fb->bits_per_pixel + state->fb->format->cpp[0] * 8 | - state->fb->format->cpp[0] * 8 != 8 + state->fb->format->cpp[0] != 1 ) @@ @@ - (8 * 8) + 8 * 8 @@ struct drm_framebuffer FB; @@ - (FB.format->cpp[0]) + FB.format->cpp[0] @@ struct drm_framebuffer *FB; @@ - (FB->format->cpp[0]) + FB->format->cpp[0] @@ @@ struct drm_framebuffer { ... - int bits_per_pixel; ... }; v2: Clean up the 'cpp*8 != 8' and '(8 * 8)' cases (Laurent) v3: Adjusted the semantic patch a bit and regenerated due to code changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> (v1) Link: http://patchwork.freedesktop.org/patch/msgid/1481751140-18352-1-git-send-email-ville.syrjala@linux.intel.com
2016-12-15drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()Ville Syrjälä1-1/+1
Pass the drm_device to drm_helper_mode_fill_fb_struct() so that we can populate fb->dev early. Will make it easier to use the fb before we register it. @@ identifier fb, mode_cmd; @@ void drm_helper_mode_fill_fb_struct( + struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_mode_fb_cmd2 *mode_cmd ); @@ identifier fb, mode_cmd; @@ void drm_helper_mode_fill_fb_struct( + struct drm_device *dev, struct drm_framebuffer *fb, const struct drm_mode_fb_cmd2 *mode_cmd ) { ... } @@ function func; identifier dev; expression E1, E2; @@ func(struct drm_device *dev, ...) { ... drm_helper_mode_fill_fb_struct( + dev, E1, E2); ... } @@ expression E1, E2; @@ drm_helper_mode_fill_fb_struct( + dev, E1, E2); v2: Rerun spatch due to code changes Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by: Laurent Pinchart <laurent.pinchart@ideasonboard.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Link: http://patchwork.freedesktop.org/patch/msgid/1481748539-18283-1-git-send-email-ville.syrjala@linux.intel.com
2016-12-06Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-nextDave Airlie1-16/+16
- BIT_PERF_PTRS uses 32-bit pointers to its subtables, we were parsing them as 16-bit, causing various issues on newer boards. - Support for MXM on GM20x and up. - More display-related fixes. * 'linux-4.10' of git://github.com/skeggsb/linux: drm/nouveau/mxm: warn more loudly on unsupported DCB version drm/nouveau/mxm: handle DCB 4.1 modification drm/nouveau/bios/mxm: handle digital connector table 1.1 drm/nouveau: Queue hpd_work on (runtime) resume drm/nouveau: Rename acpi_work to hpd_work drm/nouveau/kms/nv50: Fix atomic pageflip events. drm/nouveau/fb/ram/gp100-: fix memory detection where FBP_NUM != FBPA_NUM drm/nouveau/bios/volt: pointers are 32-bit drm/nouveau/bios/vmap: pointers are 32-bit drm/nouveau/bios/timing: pointers are 32-bit drm/nouveau/bios/therm: pointers are 32-bit drm/nouveau/bios/perf: pointers are 32-bit drm/nouveau/bios/iccsense: pointers are 32-bit drm/nouveau/bios/fan: pointers are 32-bit drm/nouveau/bios/cstep: pointers are 32-bit drm/nouveau/bios/boost: pointers are 32-bit
2016-11-28drm/nouveau: Rename acpi_work to hpd_workHans de Goede1-16/+16
We need to call drm_helper_hpd_irq_event() on resume to properly detect monitor connection / disconnection on some laptops. For runtime-resume (which gets called on resume from normal suspend too) we must call drm_helper_hpd_irq_event() from a workqueue to avoid a deadlock. Rename acpi_work to hpd_work, and move it out of the #ifdef CONFIG_ACPI blocks to make it suitable for generic work. Signed-off-by: Hans de Goede <hdegoede@redhat.com> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17Merge branch 'linux-4.10' of git://github.com/skeggsb/linux into drm-nextDave Airlie1-1/+60
- GP102/GP104 devinit (suspend/resume, optimus) hang fix - GP102/GP104 hardware cursor fix - Fix for a regression on some non-MST monitors that was caused by the MST work - Workaround for certain laptops where ACPI sends display hotkey presses on a modeset, causing gnome-settings-daemon to go into a continuous loop * 'linux-4.10' of git://github.com/skeggsb/linux: drm/nouveau/disp/gp102: rename from gp104 drm/nouveau/ce/gp102: rename from gp104 drm/nouveau/fb/gp102: rename from gp104 drm/nouveau/disp/gp102: fix cursor/overlay immediate channel indices drm/nouveau/disp/nv50-: specify ctrl/user separately when constructing classes drm/nouveau/disp/nv50-: split chid into chid.ctrl and chid.user drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBE drm/nouveau/devinit/gm200: drop pmu reset sequence drm/nouveau/devinit/gm200: replace while loops with PTIMER-based timeout loops drm/nouveau/pmu/gp102: initial implementation drm/nouveau/pmu/gp100: initial implementation drm/nouveau/pmu: execute reset before running devinit drm/nouveau/pmu: move ucode handling into gt215 implementation drm/nouveau/core: initial support for GP102 drm/nouveau/device/pci: fix oops if no mmu subdev present drm/nouveau/kms/nv50: avoid touching DP_MSTM_CTRL if !DP_MST_CAP
2016-11-17drm/nouveau/disp/gp102: rename from gp104Ben Skeggs1-1/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-17drm/nouveau: Intercept ACPI_VIDEO_NOTIFY_PROBEHans de Goede1-0/+59
Various notebooks with nvidia GPUs generate an ACPI_VIDEO_NOTIFY_PROBE acpi-video event when an external device gets plugged in (and again on modesets on that connector), the default behavior in the acpi-video driver for this is to send a KEY_SWITCHVIDEOMODE evdev event, which causes e.g. gnome-settings-daemon to ask us to rescan the connectors (good), but also causes g-s-d to switch to mirror mode on a newly plugged monitor rather then using the monitor to extend the desktop (bad) as KEY_SWITCHVIDEOMODE is supposed to switch between extend the desktop vs mirror mode. More troublesome are the repeated ACPI_VIDEO_NOTIFY_PROBE events on changing the mode on the connector, which cause g-s-d to switch between mirror/extend mode, which causes a new ACPI_VIDEO_NOTIFY_PROBE event and we end up with an endless loop. This commit fixes this by adding an acpi notifier block handler to nouveau_display.c to intercept ACPI_VIDEO_NOTIFY_PROBE and: 1) Wake-up runtime suspended GPUs and call drm_helper_hpd_irq_event() on them, this is necessary in some cases for the GPU to detect connector hotplug events while runtime suspended 2) Return NOTIFY_BAD to stop acpi-video from emitting a bogus KEY_SWITCHVIDEOMODE key-press event There already is another acpi notifier block handler registered in drivers/gpu/drm/nouveau/nvkm/engine/device/acpi.c, but that is not suitable since that one gets unregistered on runtime suspend, and we also want to intercept ACPI_VIDEO_NOTIFY_PROBE when runtime suspended. Signed-off-by: Hans de Goede <hdegoede@redhat.com>
2016-11-15drm/nouveau: Use drm_crtc_vblank_off/onDaniel Vetter1-8/+4
With atomic nv50+ is already converted over to them, but the old display code is still using it. Found in a 2 year old patch I have lying around to un-export these old helpers! v2: Drop the hand-rolled versions from resume/suspend code. Now that crtc callbacks do this, we don't need a special case for s/r anymore. v3: Remove unused variables. v4: Don't remove drm_crtc_vblank_off from suspend paths, non-atomic nouveau still needs that. But still switch to drm_crtc_vblank_off since drm_vblank_off will disappear. Cc: Mario Kleiner <mario.kleiner.de@gmail.com> Cc: Ben Skeggs <bskeggs@redhat.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20161114114101.21731-1-daniel.vetter@ffwll.ch
2016-11-07drm/nouveau/kms/nv50: remove code to create ctxdma for every framebufferBen Skeggs1-16/+3
This is now handled by prepare_fb(). Legacy flips were the last user. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: remove code to support non-atomic page flipsBen Skeggs1-41/+21
Made completely unreachable (and broken) by atomic commits. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms/nv50: transition to atomic interfaces internallyBen Skeggs1-1/+1
This commit implements the atomic commit interfaces, and implements the legacy modeset and page flipping interfaces on top of them. There's two major changes in behavior from before: - We're now making use of interlocks between core and satellite EVO channels, which greatly improves our ability to keep their states synchronised. - DPMS is now implemented as a full modeset to either tear down the entire pipe (or bring it back up). This choice was made mostly to ease the initial implementation, but I'm also not sure what we gain by bring backing the old behaviour. We shall see. This does NOT currently expose the atomic ioctl by default, due to limited testing having been performed. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms: prepare to support suspend/resume of display state with atomicBen Skeggs1-0/+138
This is different from the equivilant functions in the atomic helpers in that we fully disable the pipe instead of just setting it to inactive. We do this (primarily) to ensure the framebuffer cleanup paths are hit, allowing buffers to be un-pinned from memory so they can be evicted to system memory and not lose their contents while suspended. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms: prepare to support vbl timestamp calculation with atomicBen Skeggs1-2/+6
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms: execute drm_mode_config_reset() after constructing displayBen Skeggs1-0/+2
This will ensure we have some kind of initial atomic state for all objects after initialisation. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/kms: move drm_crtc_force_disable_all() earlierBen Skeggs1-3/+5
nouveau_display_fini() is responsible for quiescing the hardware, so this is where such actions belong. More than that, nouveau_display_fini() switches off the receiving of sink irqs, which MST will require while shutting down an active head. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau/fbcon: refcount the drm_framebufferBen Skeggs1-28/+25
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-11-07drm/nouveau: mark symbols static where possibleBaoyou Xie1-1/+1
We get a few warnings when building kernel with W=1: drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:29:1: warning: no previous prototype for 'nvbios_fan_table' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/bios/fan.c:56:1: warning: no previous prototype for 'nvbios_fan_entry' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/clk/gt215.c:184:1: warning: no previous prototype for 'gt215_clk_info' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:99:1: warning: no previous prototype for 'gt215_link_train_calc' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:153:1: warning: no previous prototype for 'gt215_link_train' [-Wmissing-prototypes] drivers/gpu/drm/nouveau/nvkm/subdev/fb/ramgt215.c:271:1: warning: no previous prototype for 'gt215_link_train_init' [-Wmissing-prototypes] .... In fact, both functions are only used in the file in which they are declared and don't need a declaration, but can be made static. So this patch marks these functions with 'static'. Signed-off-by: Baoyou Xie <baoyou.xie@linaro.org> Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-15Merge tag 'topic/drm-misc-2016-07-14' of ↵Dave Airlie1-1/+2
git://anongit.freedesktop.org/drm-intel into drm-next I recovered dri-devel backlog from my vacation, more misc stuff: - of_put_node fixes from Peter Chen (not all yet) - more patches from Gustavo to use kms-native drm_crtc_vblank_* funcs - docs sphinxification from Lukas Wunner - bunch of fixes all over from Dan Carpenter - more follow up work from Chris register/unregister rework in various places - vgem dma-buf export (for writing testcases) - small things all over from tons of different people * tag 'topic/drm-misc-2016-07-14' of git://anongit.freedesktop.org/drm-intel: (52 commits) drm: Don't overwrite user ioctl arg unless requested dma-buf/sync_file: improve Kconfig description for Sync Files MAINTAINERS: add entry for the Sync File Framework drm: Resurrect atomic rmfb code drm/vgem: Use PAGE_KERNEL in place of x86-specific PAGE_KERNEL_IO qxl: silence uninitialized variable warning qxl: check for kmap failures vga_switcheroo: Sphinxify docs drm: Restore double clflush on the last partial cacheline gpu: drm: rockchip_drm_drv: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_vtg: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_hqvdp: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_vdo: add missing of_node_put after calling of_parse_phandle gpu: drm: sti_compositor: add missing of_node_put after calling of_parse_phandle drm/tilcdc: use drm_crtc_handle_vblank() drm/rcar-du: use drm_crtc_handle_vblank() drm/nouveau: use drm_crtc_handle_vblank() drm/atmel: use drm_crtc_handle_vblank() drm/armada: use drm_crtc_handle_vblank() drm: make drm_vblank_count_and_time() static ...
2016-07-14drm/nouveau/disp/gp104: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-14drm/nouveau/disp/gp100: initial supportBen Skeggs1-0/+1
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2016-07-12drm/nouveau: use drm_crtc_handle_vblank()Gustavo Padovan1-1/+1
Remove legacy usage of drm_handle_vblank() Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1467677092-5089-4-git-send-email-gustavo@padovan.org
2016-06-24drm/nouveau: Turn off CRTCs on driver unloadLukas Wunner1-0/+1
nouveau leaks a runtime pm ref if at least one CRTC is enabled on unload. The ref is taken by nouveau_crtc_set_config() and held as long as a CRTC is in use. nv04_display_destroy() should solve this by turning off all CRTCs, but (1) nv50_display_destroy() doesn't do the same and (2) it's broken since commit d6bf2f370703 ("drm/nouveau: run mode_config destructor before destroying internal display state") because the crtc structs are torn down by drm_mode_config_cleanup() before being turned off. Also, there's no locking. Move the code to turn off all CRTCs from nv04_display_destroy() to nouveau_display_destroy() so that it's called for both nv04 and nv50 and before drm_mode_config_cleanup(). Use drm_crtc_force_disable_all() helper to save on code and have proper locking. Cc: Ben Skeggs <bskeggs@redhat.com> Signed-off-by: Lukas Wunner <lukas@wunner.de> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/66daa161322444bbde05d83cb0210b90a66988a4.1465392124.git.lukas@wunner.de
2016-06-13drm/nouveau: replace legacy vblank helpersGustavo Padovan1-11/+11
Replace the legacy drm_send_vblank_event(), drm_arm_vblank_event() and drm_vblank_{get,put}() with the new helper functions. v2: add crtc to nouveau_page_flip_state (comment from Mario Kleiner) Signed-off-by: Gustavo Padovan <gustavo.padovan@collabora.co.uk> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1465308482-15104-1-git-send-email-gustavo@padovan.org
generated by cgit v1.2.3 (git 2.39.1) at 2024-07-16 19:03:53 +0000