- 27 Jul, 2018 4 commits
-
-
Jakub Bartmiński authored
There seems to be no reason for doing extra work on WOPCM partitioning in the case GuC is not used, as the partitioning will not be used by the intel_wopcm_init_hw function anyway. Signed-off-by:
Jakub Bartmiński <jakub.bartminski@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
-
Jakub Bartmiński authored
It would appear that the calculated GuC pin bias was larger than it should be, as the GuC address space does NOT contain the "HW contexts RSVD" part of the WOPCM. Thus, the GuC pin bias is simply the GuC WOPCM size. v5: Clarify the diagram to better represent the GuC address space. Since we now don't use guc.base for the pin bias there's no need to validate it. It also has already been verified in WOPCM init. Bspec: 1180 Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Chris Wilson authored
As GEN8_LR_CONTEXT_ALIGN is I915_GTT_MIN_ALIGNMENT is it functionally equivalent to 0, and we will not be able to reduce the min-alignment for the GTT, so passing 0 is and will remain equivalent. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180727092947.1953-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Using PAGE_SIZE for virtual offset alignment is superfluous as it is equal to the minimum gtt alignment and so equivalent to 0. It is also the wrong value to use as we stopped using physical page constructs for the virtual GTT, i.e. it would be preferrable to use I915_GTT_PAGE_SIZE and in these cases merely imply I915_GTT_MIN_ALIGNMENT. Signed-off-by:
-
- 26 Jul, 2018 9 commits
-
-
Chris Wilson authored
On older HW, gen2/3, fence registers are used for detiling GPU commands and as such changing those registers requires serialisation with the requests on the GPU. Anything running on the GPU is subject to a hang, and so we must be able to recover cleanly in the middle of a stuck wait on a fence register. We can simulate using the fence on the GPU simply by marking the fence as active on the request for this vma, the interface being common to all gen, thus broadening the test. Signed-off-by:
-
Chris Wilson authored
To test eviction from a ppgtt, we just want a ppgtt i.e. something other than the Global GTT which is shared and used by the kernel for HW features like fencing and scanout. However, we also need it to pass !i915_is_ggtt() and the simplest way is to emulate a full user context rather than the internal kernel context that is used for the GGTT. Signed-off-by:
-
Chris Wilson authored
If we issue a device level GPU reset on the older gen, it will disable key components of the GMCH and the display engine. The purpose of wedging is to simply prevent further GEM usage without disabling KMS, so we need to be careful when we do issue the reset on wedging. Signed-off-by:
-
Chris Wilson authored
If we fail during GEM initialisation, we scrub the HW state by performing a device level GPU resuet. However, we want to leave the system in a usable state (with functioning KMS but no GEM) so after scrubbing the HW state, we need to restore some sane defaults and re-enable the low-level common parts of the GPU (such as the GMCH). v2: Restore GTT entries. Signed-off-by:
-
Chris Wilson authored
Prevent [ 397.873143] general protection fault: 0000 [#1] PREEMPT SMP PTI [ 397.873154] CPU: 4 PID: 4799 Comm: drv_module_relo Tainted: G U 4.18.0-rc6-CI-CI_DRM_4534+ #1 [ 397.873162] Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.10 12/28/2017 [ 397.873175] RIP: 0010:__lock_acquire+0xf6/0x1b50 [ 397.873179] Code: 85 c0 4c 8b 9d 40 ff ff ff 8b 8d 38 ff ff ff 44 8b 8d 30 ff ff ff 4c 8b 85 28 ff ff ff 44 8b 95 24 ff ff ff 0f 84 54 03 00 00 <f0> ff 80 38 01 00 00 8b 15 45 8c 59 02 45 8b bc 24 70 08 00 00 85 [ 397.873240] RSP: 0018:ffffc90000497b40 EFLAGS: 00010002 [ 397.873246] RAX: 6b6b6b6b6b6b6b6b RBX: 0000000000000001 RCX: 0000000000000000 [ 397.873252] RDX: 0000000000000046 RSI: 0000000000000000 RDI: 0000000000000000 [ 397.873258] RBP: ffffc90000497c20 R08: ffffffff810a25e9 R09: 0000000000000000 [ 397.873264] R10: 0000000000000000 R11: ffff880255c63c28 R12: ffff8801093b2840 [ 397.873270] R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000246 [ 397.873277] FS: 00007faf88d71980(0000) GS:ffff880266300000(0000) knlGS:0000000000000000 [ 397.873284] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 [ 397.873289] CR2: 000055d866c9ca10 CR3: 000000025472e006 CR4: 00000000003606e0 [ 397.873295] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 [ 397.873301] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 [ 397.873308] Call Trace: [ 397.873318] ? lock_acquire+0xa6/0x210 [ 397.873323] lock_acquire+0xa6/0x210 [ 397.873331] ? drain_workqueue+0x19/0x180 [ 397.873339] __mutex_lock+0x89/0x980 [ 397.873346] ? drain_workqueue+0x19/0x180 [ 397.873352] ? _raw_spin_unlock_irqrestore+0x4c/0x60 [ 397.873359] ? trace_hardirqs_on_caller+0xe0/0x1b0 [ 397.873365] ? drain_workqueue+0x19/0x180 [ 397.873373] ? debug_object_active_state+0x127/0x150 [ 397.873381] ? drain_workqueue+0x19/0x180 [ 397.873387] drain_workqueue+0x19/0x180 [ 397.873395] destroy_workqueue+0x12/0x1f0 [ 397.873476] intel_guc_fini_misc+0x36/0x90 [i915] [ 397.873540] i915_gem_fini+0x91/0x100 [i915] [ 397.873588] i915_driver_unload+0xd2/0x110 [i915] [ 397.873638] i915_pci_remove+0x19/0x30 [i915] [ 397.873646] pci_device_remove+0x36/0xb0 [ 397.873653] device_release_driver_internal+0x185/0x250 [ 397.873660] driver_detach+0x35/0x70 [ 397.873668] bus_remove_driver+0x53/0xd0 [ 397.873675] pci_unregister_driver+0x25/0xa0 [ 397.873683] __se_sys_delete_module+0x162/0x210 [ 397.873691] ? do_syscall_64+0xd/0x190 [ 397.873697] do_syscall_64+0x55/0x190 [ 397.873704] entry_SYSCALL_64_after_hwframe+0x49/0xbe [ 397.873710] RIP: 0033:0x7faf884231b7 [ 397.873714] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48 [ 397.873775] RSP: 002b:00007ffda4e98cf8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0 [ 397.873784] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faf884231b7 [ 397.873790] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 000055fbb18f1bd8 [ 397.873796] RBP: 000055fbb18f1b70 R08: 000055fbb18f1bdc R09: 00007ffda4e98d38 [ 397.873802] R10: 00007ffda4e97cf4 R11: 0000000000000206 R12: 000055fbb0d32470 [ 397.873808] R13: 00007ffda4e992e0 R14: 0000000000000000 R15: 0000000000000000 v2: It's use-after-free; not a NULL pointer. Testcase: igt/drv_module_reload/basic-reload-inject Signed-off-by:
-
Chris Wilson authored
For that little bit of defense against a tired programmer. Signed-off-by:
-
Chris Wilson authored
i915_gem_tile_height() asserts that the object is tiled, but inside the error printer for the selftest we computed the row size regardless of tiling, tripping over the assert. Signed-off-by:
-
Dhinakaran Pandiyan authored
We are too late in the enabling sequence to back out cleanly, not updating state tracking variables, like intel_dp->active_mst_links in this instance, results in incorrect behaviour further along. v2: Fixed int v/s bool comparison Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107281Signed-off-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Tested-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180718171943.3246-2-dhinakaran.pandiyan@intel.com
-
Dhinakaran Pandiyan authored
The short pulse handler checks if channel equalization is okay and goes onto retrain a link if there are active MST links. This retraining path is not meant for new MST connections, but due to a bug elsewhere, if active_mst_links is < 0 the boolean check for active_mst_links passes and we proceed to retrain a new link. This results in a sequence of failed link training attempts, most likely due to the hardware not setup for link training at that point i.e., missing the DDI pre_enable sequence. [ 80.301272] [drm:intel_dp_check_mst_status] channel EQ not ok, retraining [ 80.301312] [drm:intel_ddi_prepare_link_retrain] *ERROR* Timeout waiting for DDI BUF C idle bit The above error gives us a hint something went wrong before link training started. Check for a positive value of active_mst_links and throw in a warning for invalid active_mst_links as debug aid. Cc: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
-
- 25 Jul, 2018 7 commits
-
-
Paulo Zanoni authored
The Gen11 TypeC PHY DDI Buffer chapter, PHY Clock Gating Programming section says that PHY clock gating should be disabled before starting voltage swing programming, then enabled after any link training is complete. v2: Simple rebase. Cc: Animesh Manna <animesh.manna@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Signed-off-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-6-paulo.r.zanoni@intel.com
-
Paulo Zanoni authored
Programming this register is part of the Enable Sequence for DisplayPort on ICL. Do as the spec says. v2: Simple rebase. Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> (v1) Signed-off-by:
-
Animesh Manna authored
In ICL, Flexible IO Adapter (FIA) muxes data and clocks of USB 3.1, tbt and display controller. In DP alt mode FIA configure the number of lanes and will be used apart from DPCD read to calculate max available lanes for DP enablement. v2 (from Paulo): Simple rebase. Reviewed-by: Anusha Srivatsa <anusha.srivatsa@intel.com> (v1). Reviewed-by:
Animesh Manna <animesh.manna@intel.com> [Paulo: significant rewrite of the patch.] Signed-off-by:
-
Paulo Zanoni authored
The type is detected based on the live status bits. Once detected, it's not supposed to be changed, so we have some sanity checks for that. v2: Rebase. Cc: Animesh Manna <animesh.manna@intel.com> Reviewed-by:
-
Paulo Zanoni authored
Do like the other functions and check for the status bits. The "Hot Plug Detection" page from our documentation says we can't just use the ISR bits on the CPU side (North Display, which has the TC and TBT modes), so use the correct register: DFLEXDPSP, TC Live State field. v2: Rebase. v3: - Simplify true/false assignment (Rodrigo). - Reorganize is_gen if ladder (Rodrigo). - Don't use the ISR for TC/TBT CPU bits. v4: - Improve commit message wording (Lucas). v5: - COMMIT_LOG_LONG_LINE (Checkpatch). Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by: Lucas De Marchi <lucas.demarchi@intel.com> (v3). Signed-off-by:
-
Nathan Ciobanu authored
Clarifies the clock recovery loop limit comment that 80 max_cr_tries for pre-DP1.4 devices was chosen as a very tolerant upper bound. Assumptions made: - DP1.4 syncs should be smarter so they won't need more than 10 tries - pre-DP1.4 syncs should be compliant enough to not need that many tries (80) but we should tolerate any that may trigger this corner case Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Marc Herbert <marc.herbert@intel.com> Suggested-by:
Marc Herbert <marc.herbert@intel.com> Signed-off-by:
-
Chris Wilson authored
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op. References: https://bugs.freedesktop.org/show_bug.cgi?id=107343Signed-off-by:
-
- 24 Jul, 2018 4 commits
-
-
Manasi Navare authored
This sequence is used to setup voltage swing before enabling MG PHY DDI as well as for changing the voltage during DisplayPort Link training. For ICL, there are two types of DDIs. This sequence needs to be used for MG PHY DDI which is ports C-F. v6 (From Manasi): * Add programming for MG_CLKHUB and MG_TX_DCC as per the spec updates v5 (from Paulo): * Checkpatch. v4 (from Paulo): * Fix bogus error message * Fix copy+paste bugs (missing s/TX1/TX2/ after copy+paste) * Use the new mask names * Stay under 80 columns * Add some blank lines v3: * Clear the regs before writing (Paulo) v2: * Rename to MG PHY in the function def (Jani Nikula) * Rebase on top of new revision of other patches in series Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Manasi Navare authored
This patch adds the remaining register definitions and bit fields required for MG PHy DDI buffer initializations and voltage swing programming for MG PHy DDI ports. While at it this patch also fixes the naming for previously defined MG PHY registers in original commit id (c92f47b5 "drm/i915/icl: Add register defs for voltage swing sequences for MG PHY DDI"). Since the MG PHY registers are first defined in ICL platform, there is no need for _ICL prefix. v4 (from Paulo): add two white spaces to CRI_CALCINIT too. v3: * Fix register names, add spaces for MASK defines, correct the order of #defines (Paulo) v2: * Change the MG_TX_DRVCTL registers names to match the spec (Anusha) Cc: James Ausmus <james.ausmus@intel.com> Reviewed-by:
-
Chris Wilson authored
On Sandybridge, we need a workaround to wait for the CPU thread to wake up before we are sure that we have enabled the GT power well. However, we do see the errors being reported and failed reads returning spurious results. To try and capture more details as it fails, promote the error into a WARN so we grab the stacktrace, and to try and reduce the frequency of error increase the timeout from 500us to 5ms. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720111102.11549-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
A reasonably common operation is to pin the map of the vma alongside the vma itself for the lifetime of the vma, and so release both pins at the same time as destroying the vma. It is common enough to pull into the release function, making that central function more attractive to a couple of other callsites. The continual ulterior motive is to sweep over errors on module load aborting... Testcase: igt/drv_module_reload/basic-reload-inject Signed-off-by:
-
- 23 Jul, 2018 4 commits
-
-
Nathan Ciobanu authored
Changes the type and renames the max_vswing_tries variable which was declared as an integer but used as a boolean making it easy to be confused with a counter. Changes in v2: - updated the title and commit message - left the loop exit point in place v3: fix typo in title v4: renamed max_vswing to max_vswing_reached (Ville) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Marc Herbert <marc.herbert@intel.com> Signed-off-by: -
Nathan Ciobanu authored
Limit the link training clock recovery loop to 10 attempts at LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x x 5 identical voltages tries). Some faulty USB-C MST hubs can cause us to get stuck in this loop indefinitely requesting something like: voltage swing: 0, pre-emphasis level: 2 voltage swing: 1, pre-emphasis level: 2 voltage swing: 0, pre-emphasis level: 3 over and over so max_vswing would never be reached, drm_dp_clock_recovery_ok() would never return true and voltage_tries would always get reset to 1. The driver sends those values to the hub but the hub keeps requesting new values every time. Changes in v2: - updated commit message (DK, Manasi) - defined DP_DP14_MAX_CR_TRIES (Marc) - made the loop iterate for max 10 times (Rodrigo, Marc) Changes in v3: - changed error message to use DP_DP14_MAX_CR_TRIES Changes in v4: - Updated the title to reflect the change - Updated the commit message - Added 80 attempts for pre-DP 1.4 devices Changes in v5: - Removed DP_DP14_MAX_CR_TRIES from drm v6: Updated comment to match kernel style (Rodrigo) Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Marc Herbert <marc.herbert@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: -
Michał Winiarski authored
gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality: commit 79e542f5 ("drm/i915/kvmgt: Support setting dma map for huge pages") And yet, part of it was reintroduced in: commit 39b4cbad ("drm/i915/kvmgt: Check the pfn got from vfio_pin_pages") Causing kvmgt part to no longer build. Let's remove it. Reported-by:
Tomasz Lis <tomasz.lis@intel.com> Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
We need a backmerge to get DP_DPCD_REV_14 before we push other i915 changes to dinq that could break compilation. Signed-off-by:
-
- 20 Jul, 2018 9 commits
-
-
Anusha Srivatsa authored
This patch fixes the commit - <2efbb2f0> ("i915/dp/dsc: Add DSC PPS register definitions"), which did not have _MMIO() for DSCA and DSCC. v2: Fix typos. (manasi) v3: Change the commit message (Rodrigo) Cc: Rodrigi Vivi <rodrigo.vivi@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Rodrigo Vivi authored
First of all don't try to read dpcd if PSR is not even supported. But also, if read failed return -EIO instead of reporting via a backchannel. v2: fix dev_priv: At this level m->private is the connector. (CI/DK) don't convert dpcd read errors to EIO. (DK) Fixes: 5b7b3086 ("drm/i915/psr: Split sink status into a separate debugfs node") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by: -
Rodrigo Vivi authored
Just a small clean-up with no functional change, only removing a variable that is never actually used. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
-
Chris Wilson authored
Not all chipsets have an internal buffer delaying the visibility of writes via the GGTT being visible by other physical paths, but we use a very heavy workaround for all. We only need to apply that workarounds to the chipsets we know suffer from the delay and the resulting coherency issue. Similarly, the same inconsistent coherency fouls up our ABI promise that a write into a mmap_gtt is immediately visible to others. Since the HW has made that a lie, let userspace know when that contract is broken. (Not that userspace would want to use mmap_gtt on those chipsets for other performance reasons...) Testcase: igt/drv_selftest/live_coherency Testcase: igt/gem_mmap_gtt/coherency Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100587Signed-off-by:
-
Chris Wilson authored
Another step in the drv_module_reload fault-injection saga, is that we try to disable the guc twice. Probably. It's a little unclear exactly what is going on in the unload sequence that catches us out, so for the time being suppress the assertion to get the test re-enabled. Testcase: igt/drv_module_reload/basic-reload-inject Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
More features for 4.19: - Map processes to vmids for debugging GPUVM faults - Raven gfxoff fixes - Initial gfxoff support for vega12 - Use defines for interrupt sources rather than magic numbers - DC aux fixes - Finish DC logging TODO - Add more DC debugfs interfaces for conformance testing - Add CRC support for DCN - Scheduler rework in preparation for load balancing - Unify common smu9 code - Clean up UVD instancing support - ttm cleanups - Misc fixes and cleanups Signed-off-by:
Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719194001.3488-1-alexander.deucher@amd.com
-
git://anongit.freedesktop.org/drm/drm-intelDave Airlie authored
On GEM side: - GuC related fixes (Chris, Michal) - GTT read-only pages support (Jon, Chris) - More selftests fixes (Chris) - More GPU reset improvements (Chris) - Flush caches after GGTT writes (Chris) - Handle recursive shrinker for vma->last_active allocation (Chris) - Other execlists fixes (Chris) On Display side: - GLK HDMI fix (Clint) - Rework and cleanup around HPD pin (Ville) - Preparation work for Display Stream Compression support coming on ICL (Anusha) - Nuke LVDS lid notification (Ville) - Assume eDP is always connected (Ville) - Kill intel panel detection (Ville) Signed-off-by:
-
git://anongit.freedesktop.org/drm/drm-miscDave Airlie authored
drm-misc-next for 4.19: Core Changes: - add support for DisplayPort CEC-Tunneling-over-AUX (Hans Verkuil) - more doc updates (Daniel Vetter) - fourcc: Add is_yuv field to drm_format_info (Ayan Kumar Halder) - dma-buf: correctly place BUG_ON (Michel Dänzer) Driver Changes: - more vkms support(Rodrigo Siqueira) - many fixes and small improments to all drivers Signed-off-by:
-
git://github.com/skeggsb/linuxDave Airlie authored
misc fixes and cleanups for next. Signed-off-by:
-
- 19 Jul, 2018 3 commits
-
-
Paulo Zanoni authored
Use the hardcoded tables provided by our spec. v2: - SSC stays disabled. - Use intel_port_is_tc(). Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by:
-
Azhar Shaikh authored
On KBL, WHL RVPs, booting up with an external display connected, triggers below warning, when the BiOS brings up the external display too. This warning is not seen during hotplug. [ 3.615226] ------------[ cut here ]------------ [ 3.619829] plane 1A assertion failure (expected on, current off) [ 3.632039] WARNING: CPU: 2 PID: 354 at drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb [ 3.633920] iwlwifi 0000:00:14.3: loaded firmware version 38.c0e03d94.0 op_mode iwlmvm [ 3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm btintel bluetooth ecdh_generic [ 3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7-50176-g655af12d39c2 #3 [ 3.647165] Hardware name: Intel Corporation CoffeeLake Client Platform/WhiskeyLake U DDR4 ERB, BIOS CNLSFWR1.R00.X140.B00.1804040304 04/04/2018 [ 3.684509] RIP: 0010:assert_plane+0x71/0xbb [ 3.764451] Call Trace: [ 3.766888] intel_atomic_commit_tail+0xa97/0xb77 [ 3.771569] intel_atomic_commit+0x26a/0x279 [ 3.771572] drm_atomic_helper_set_config+0x5c/0x76 [ 3.780670] __drm_mode_set_config_internal+0x66/0x109 [ 3.780672] drm_mode_setcrtc+0x4c9/0x5cc [ 3.780674] ? drm_mode_getcrtc+0x162/0x162 [ 3.789774] ? drm_mode_getcrtc+0x162/0x162 [ 3.798108] drm_ioctl_kernel+0x8d/0xe4 [ 3.801926] drm_ioctl+0x27d/0x368 [ 3.805311] ? drm_mode_getcrtc+0x162/0x162 [ 3.805314] ? selinux_file_ioctl+0x14e/0x199 [ 3.805317] vfs_ioctl+0x21/0x2f [ 3.813812] do_vfs_ioctl+0x491/0x4b4 [ 3.813813] ? security_file_ioctl+0x37/0x4b [ 3.813816] ksys_ioctl+0x55/0x75 [ 3.820672] __x64_sys_ioctl+0x1a/0x1e [ 3.820674] do_syscall_64+0x51/0x5f [ 3.820678] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 3.828221] RIP: 0033:0x7b5e04953967 [ 3.835504] RSP: 002b:00007fff2eafb6f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010 [ 3.835505] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007b5e04953967 [ 3.835505] RDX: 00007fff2eafb730 RSI: 00000000c06864a2 RDI: 000000000000000f [ 3.835506] RBP: 00007fff2eafb720 R08: 0000000000000000 R09: 0000000000000000 [ 3.835507] R10: 0000000000000070 R11: 0000000000000246 R12: 000000000000000f [ 3.879988] R13: 000056bc9dd7d210 R14: 00007fff2eafb730 R15: 00000000c06864a2 [ 3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 89 f9 48 0f 44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff <0f> 0b eb 2b 48 c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48 [ 3.905845] WARNING: CPU: 2 PID: 354 at drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb [ 3.920964] ---[ end trace dac692f4ac46391a ]--- The warning is seen when mode_setcrtc() is called for pipeB during bootup and before we get a mode_setcrtc() for pipeA, while doing update_crtcs() in intel_atomic_commit_tail(). Now since, plane1A is still active after commit, update_crtcs() is done for pipeA and eventually update_plane() for plane1A. intel_plane_state->ctl for plane1A is not updated since set_modecrtc() is called for pipeB. So intel_plane_state->ctl for plane 1A will be 0x0. So doing an update_plane() for plane1A, will result in clearing PLANE_CTL_ENABLE bit, and hence the warning. To fix this warning, force all active planes to recompute their states in probe. Changes in v8: - Actually add Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Changes in v7: - Move call to intel_initial_commit() after sanitize_watermarks() Otherwise the plane update will still consult potentially bogus watermarks we read out from the hardware. (Ville) - Carry Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> from v6 Changes in v6: - Handle EDEADLK for drm_atomic_get_crtc_state() and drm_atomic_add_affected_planes() - Remove optimization of calling intel_initial_commit() only when there is more than one active pipe in probe. - Avoid using intel_ types. Changes in v5: - Drop drm_modeset_lock_all_ctx() since locks will be taken later. Changes in v4: - Handle locking in intel_initial_commit() - Move the for loop inside intel_initial_commit() so that drm_atomic_commit() is called only once - Call intel_initial_commit() only for more than one active crtc on boot. - Save the return value of intel_initial_commit() and print a message in case of an error Changes in v3: - Add comments Changes in v2: - Force all planes to recompute their states.(Ville Syrjälä) - Update the commit message Signed-off-by:
Azhar Shaikh <azhar.shaikh@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Christian König authored
The whole handle, filp and entity handling is superfluous here. We should have reviewed that more thoughtfully. It looks like somebody just made the code instance aware without knowing the background. v2: fix one more missed case in amdgpu_uvd_suspend Reviewed-by:
Leo Liu <leo.liu@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com> Acked-by:
Chunming Zhou <david1.zhou@amd.com> Signed-off-by:
Alex Deucher <alexander.deucher@amd.com>
-
