summaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2018-07-25drm/i915/icl: program MG_DP_MODEPaulo Zanoni4-0/+84
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: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-5-paulo.r.zanoni@intel.com
2018-07-25drm/i915/icl: Update FIA supported lane count for hpd.Animesh Manna2-1/+35
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Animesh Manna <animesh.manna@intel.com> [Paulo: significant rewrite of the patch.] Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-4-paulo.r.zanoni@intel.com
2018-07-25drm/i915/icl: store the port type for TC portsPaulo Zanoni3-2/+46
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725002813.6938-3-paulo.r.zanoni@intel.com
2018-07-25drm/i915/icl: implement icl_digital_port_connected()Paulo Zanoni2-1/+62
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180725195927.12059-1-paulo.r.zanoni@intel.com
2018-07-25drm/i915/dp: Improve clock recovery loop limit commentNathan Ciobanu1-4/+6
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: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Reviewed-by: Marc Herbert <marc.herbert@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1532471612-30001-1-git-send-email-nathan.d.ciobanu@linux.intel.com
2018-07-25drm/i915: Skip repeated calls to i915_gem_set_wedged()Chris Wilson1-2/+3
If we already wedged, i915_gem_set_wedged() becomes a complicated no-op. References: https://bugs.freedesktop.org/show_bug.cgi?id=107343 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180723145335.24579-1-chris@chris-wilson.co.uk
2018-07-25drm/i915/icl: Implement voltage swing programming sequence for MG PHY DDIManasi Navare1-6/+129
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: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530225344-20373-2-git-send-email-manasi.d.navare@intel.com
2018-07-25drm/i915/icl: Add remaining registers and bitfields for MG PHY DDIManasi Navare1-113/+157
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 (c92f47b5ec977a "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: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531510993-6606-1-git-send-email-manasi.d.navare@intel.com
2018-07-24drm/i915: Show stack (by WARN) for hitting forcewake errorsChris Wilson1-4/+14
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: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720111102.11549-1-chris@chris-wilson.co.uk
2018-07-24drm/i915: Pull unpin map into vma releaseChris Wilson10-40/+24
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180721125037.20127-1-chris@chris-wilson.co.uk
2018-07-24drm/i915/dp: Refactor max_vswing_tries variableNathan Ciobanu1-4/+4
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 <nathan.d.ciobanu@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720214413.29506-2-rodrigo.vivi@intel.com
2018-07-24drm/i915/dp: Limit link training clock recovery loopNathan Ciobanu1-2/+15
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: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720214413.29506-1-rodrigo.vivi@intel.com
2018-07-24drm/i915/kvmgt: Fix compilation errorMichał Winiarski1-6/+0
gvt_pin_guest_page extracted some of the gvt_dma_map_page functionality: commit 79e542f5af79 ("drm/i915/kvmgt: Support setting dma map for huge pages") And yet, part of it was reintroduced in: commit 39b4cbadb9a9 ("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: Michał Winiarski <michal.winiarski@intel.com> Cc: Changbin Du <changbin.du@intel.com> Cc: Zhenyu Wang <zhenyuw@linux.intel.com> Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180712155330.32055-1-michal.winiarski@intel.com
2018-07-23Merge drm/drm-next into drm-intel-next-queuedRodrigo Vivi13380-633720/+537063
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: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-21drm/i915/dsc: Add missing _MMIO() from PPS registersAnusha Srivatsa1-38/+38
This patch fixes the commit - <2efbb2f099fb> ("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: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1532122962-9068-1-git-send-email-anusha.srivatsa@intel.com
2018-07-20drm/i915: Fix psr sink status report.Rodrigo Vivi1-2/+11
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: 5b7b30864d1d ("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 <rodrigo.vivi@intel.com> Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720003155.16290-1-rodrigo.vivi@intel.com
2018-07-20drm/i915: Remove unused "ret" variable.Rodrigo Vivi1-3/+2
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: <nathan.d.ciobanu@linux.intel.com> Reviewed-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719234217.7855-1-rodrigo.vivi@intel.com
2018-07-20drm/i915: Only force GGTT coherency w/a on required chipsetsChris Wilson5-0/+41
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=100587 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Tomasz Lis <tomasz.lis@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720101910.11153-1-chris@chris-wilson.co.uk
2018-07-20drm/i915: Suppress assertion for i915_ggtt_disable_gucChris Wilson1-0/+4
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: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Acked-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180720095144.5885-1-chris@chris-wilson.co.uk
2018-07-20Merge branch 'drm-next-4.19' of git://people.freedesktop.org/~agd5f/linux ↵Dave Airlie189-2272/+3650
into drm-next 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
2018-07-20Merge tag 'drm-intel-next-2018-07-19' of ↵Dave Airlie60-1009/+2158
git://anongit.freedesktop.org/drm/drm-intel into drm-next 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: Dave Airlie <airlied@redhat.com> # gpg: Signature made Fri 20 Jul 2018 01:51:45 AM AEST # gpg: using RSA key FA625F640EEB13CA # gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>" # gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>" # gpg: WARNING: This key is not certified with a trusted signature! # gpg: There is no indication that the signature belongs to the owner. # Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA # Conflicts: # drivers/gpu/drm/i915/intel_lrc.c Link: https://patchwork.freedesktop.org/patch/msgid/20180719171257.GA12199@intel.com
2018-07-20Merge tag 'drm-misc-next-2018-07-18' of ↵Dave Airlie167-1375/+2442
git://anongit.freedesktop.org/drm/drm-misc into drm-next 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: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180718200826.GA20165@juma
2018-07-20Merge branch 'linux-4.19' of git://github.com/skeggsb/linux into drm-nextDave Airlie27-64/+167
misc fixes and cleanups for next. Signed-off-by: Dave Airlie <airlied@redhat.com> Link: https://patchwork.freedesktop.org/patch/msgid/CACAvsv55CfRonQ0bo2XiitkCiWTjKwhsP=+ZFhoa-BaJ72Ryew@mail.gmail.com
2018-07-20drm/i915/icl: compute the TBT PLL registersPaulo Zanoni1-1/+21
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: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180711215909.23945-2-paulo.r.zanoni@intel.com
2018-07-19drm/i915: Fix assert_plane() warning on bootup with external displayAzhar Shaikh1-2/+59
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: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1530902250-44583-1-git-send-email-azhar.shaikh@intel.com
2018-07-19drm/amdgpu: clean up UVD instance handling v2Christian König2-67/+64
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>
2018-07-19drm/amdgpu: remove superflous UVD encode entityChristian König3-27/+0
Not sure what that was every used for, but now it is completely unused. 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>
2018-07-19drm/amdgpu/display: Replace CONFIG_DRM_AMD_DC_DCN1_0 with CONFIG_X86Michel Dänzer26-64/+56
Allowing CONFIG_DRM_AMD_DC_DCN1_0 to be disabled on X86 was an opportunity for display with Raven Ridge accidentally not working. Reviewed-by: Harry Wentland <harry.wentland@amd.com> Signed-off-by: Michel Dänzer <michel.daenzer@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/amd/powerplay: fixed uninitialized valueEvan Quan1-1/+1
The 'result' is not initialized correctly. It causes the API return an error code even on success. Signed-off-by: Evan Quan <evan.quan@amd.com> Acked-by: Huang Rui <ray.huang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com> Cc: stable@vger.kernel.org
2018-07-19drm/amdgpu/powerplay: use irq source defines for smu7 sourcesAlex Deucher1-3/+4
Use the newly added irq source defines rather than magic numbers for smu7 thermal interrupts. Rewiewed-by: Chunming Zhou <david1.zhou@amd.com> Reviewed-by: Rex Zhu <rezhu@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/i915/gtt: Full ppgtt everywhere, no excusesChris Wilson1-6/+0
We believe we have all the kinks worked out, even for the early Valleyview devices, for whom we currently disable all ppgtt. References: 62942ed7279d ("drm/i915/vlv: disable PPGTT on early revs v3") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717095751.1034-2-chris@chris-wilson.co.uk
2018-07-19drm/i915/gtt: Enable full-ppgtt by default everywhereChris Wilson1-6/+4
We should we have all the kinks worked out and full-ppgtt now works reliably on gen7 (Ivybridge, Valleyview/Baytrail and Haswell). If we can let userspace have full control over their own ppgtt, it makes softpinning far more effective, in turn making GPU dispatch far more efficient by virtue of better mm segregation. On the other hand, switching over to a different GTT for every client does incur noticeable overhead, but only for very lightweight tasks. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Jason Ekstrand <jason.ekstrand@intel.com> Cc: Kenneth Graunke <kenneth@whitecape.org> Acked-by: Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20180717095751.1034-1-chris@chris-wilson.co.uk
2018-07-19drm/i915: Update DRIVER_DATE to 20180719Rodrigo Vivi1-2/+2
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-19drm/i915: Remove intel_panel_detect()Ville Syrjälä4-26/+0
With neither LVDS or eDP no longer using intel_panel_detect() we can kill it, and the accompanying modparam. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-3-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-19drm/i915: Assume eDP is always connectedVille Syrjälä1-9/+2
We never registered any kind of lid notifier for eDP, so looking at the lid status is pretty much bonkers. Let's just consider eDP always connected instead. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-2-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-19drm/i915: Nuke the LVDS lid notifierVille Syrjälä3-152/+2
We broke the LVDS notifier resume thing in (presumably) commit e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as we no longer duplicate the current state in the LVDS notifier and thus we never resume it properly either. Instead of trying to fix it again let's just kill off the lid notifier entirely. None of the machines tested thus far have apparently needed it. Originally the lid notifier was added to work around cases where the VBIOS was clobbering some of the hardware state behind the driver's back, mostly on Thinkpads. We now have a few report of Thinkpads working just fine without the notifier. So maybe it was misdiagnosed originally, or something else has changed (ACPI video stuff perhaps?). If we do end up finding a machine where the VBIOS is still causing problems I would suggest that we first try setting various bits in the VBIOS scratch registers. There are several to choose from that may instruct the VBIOS to steer clear. With the notifier gone we'll also stop looking at the panel status in ->detect(). v2: Nuke enum modeset_restore (Rodrigo) Cc: stable@vger.kernel.org Cc: Wolfgang Draxinger <wdraxinger.maillist@draxit.de> Cc: Vito Caputo <vcaputo@pengaru.com> Cc: kitsunyan <kitsunyan@airmail.cc> Cc: Joonas Saarinen <jza@saunalahti.fi> Tested-by: Vito Caputo <vcaputo@pengaru.com> # Thinkapd X61s Tested-by: kitsunyan <kitsunyan@airmail.cc> # ThinkPad X200 Tested-by: Joonas Saarinen <jza@saunalahti.fi> # Fujitsu Siemens U9210 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902 References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html References: https://bugs.freedesktop.org/show_bug.cgi?id=21230 Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
2018-07-19drm/i915/execlists: Move the assertion we have the rpm wakeref downChris Wilson1-14/+11
There's a race between idling the engine and finishing off the last tasklet (as we may kick the tasklets after declaring an individual engine idle). However, since we do not need to access the device until we try to submit to the ELSP register (processing the CSB just requires normal CPU access to the HWSP, and when idle we should not need to submit!) we can defer the assertion unto that point. The assertion is still useful as it does verify that we do hold the longterm GT wakeref taken from request allocation until request completion. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274 Fixes: 9512f985c32d ("drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719075029.28643-1-chris@chris-wilson.co.uk
2018-07-19drm/i915: Handle recursive shrinker for vma->last_active allocationChris Wilson1-0/+8
If we call into the shrinker for direct relcaim inside kmalloc, it will retire the requests. If we retire the vma->last_active while processing a new i915_vma_move_to_active() we can upset the delicate bookkeeping required for the cache. After the possible invocation of the shrinker, we need to double check the vma->last_active is still valid. Fixes: 8b293eb53a7d ("drm/i915: Track the last-active inside the i915_vma") Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105600#c39 Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180719072206.16015-1-chris@chris-wilson.co.uk
2018-07-19drm/i915/guc: Keep guc submission permanently engagedChris Wilson3-16/+31
We make a decision at module load whether to use the GuC backend or not, but lose that setup across set-wedge. Currently, the guc doesn't override the engine->set_default_submission hook letting execlists sneak back in temporarily on unwedging leading to an unbalanced park/unpark. v2: Remove comment about switching back temporarily to execlists on guc_submission_disable(). We currently only call disable on shutdown, and plan to also call disable before suspend and reset, in which case we will either restore guc submission or mark the driver as wedged, making the reset back to execlists pointless. v3: Move reset.prepare across Fixes: 63572937cebf ("drm/i915/execlists: Flush pending preemption events during reset") Testcase: igt/drv_module_reload/basic-reload-inject Testcase: igt/gem_eio Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by: Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180717202932.1423-1-chris@chris-wilson.co.uk
2018-07-19drm/nouveau/kms/nv50-: allocate push buffers in vidmem on pascalBen Skeggs1-2/+27
Workaround for issues seen on systems with large amounts of RAM, caused by display not supporting the same physical address limits as the other parts of the GPU. Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
2018-07-19i915/dp/dsc: Add Rate Control Range Parameter RegistersAnusha Srivatsa1-0/+104
RC model has these parameters that correspond with each of 15 ranges of RC buffer threshold value in the RC model. The three elements are range_min_qp, range_max_qp and range_bpg_offset. Add the Rate Control range values for eDP/MIPI and DP case. The actual values are calculated usung a helper function. This patch adds the shifts to registers where the value will be written during atomic commit. v2: - Use _MMIO_PIPE() instead of _MMIO(_PICK()) (Manasi) - Combine shifts (Manasi) Cc: Jose Souza <jose.souza@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-4-git-send-email-anusha.srivatsa@intel.com
2018-07-19i915/dp/dsc: Add Rate Control Buffer Threshold RegistersAnusha Srivatsa1-0/+51
Add register defines and shifts that control the RC buffer threshold between encoder and decoder for eDP/MIPI and DP cases. The actual values are calculated usung a helper function. This patch adds the shifts to registers where the value will be written during atomic commit. v2: - Use _MMIO_PIPE() instead of _MMIO_(_PICK()) (Manasi) - Combine shifts (Manasi) Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-3-git-send-email-anusha.srivatsa@intel.com
2018-07-19i915/dp/dsc: Add DSC PPS register definitionsAnusha Srivatsa1-0/+255
Display Stream Compression(DSC) has a set of Picture Parameter Set(PPS) components that the encoder must communicate to the decoder. This patch adds register definitions to the PPS parameters for eDP/MIPI case and Display Port. v2: - Use _MMIO_PIPE instead of _MMIO(_PICK()). (Manasi) - Use DSC constants as arguments. (Manasi) Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.srivatsa@intel.com
2018-07-19drm/i915/icl: Add VIDEO_DIP registersAnusha Srivatsa1-0/+23
The Picture Parameter Set metadata for DSC has to be sent to the panel through secondary data packets. Add the error correction registers, data registers and control registers for the same. The control registers for transcoders A and B are already defined and will be reused for Icelake purpose. This patch adds Control register for EDP and transcoder C apart from adding the PPS data and error registers. v2: reuse MMIO_TRANS2 for _PPS_DATA and _PPS_ECC. The _MMIO_TRANS2(pipe, reg) macro definition takes care of the eDp case Cc: Jani Nikula <jani.nikula@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-1-git-send-email-anusha.srivatsa@intel.com
2018-07-19drm/amdgpu/pm: Remove VLA usageKees Cook1-58/+42
In the quest to remove all stack VLA usage from the kernel[1], this uses the maximum sane buffer size and removes copy/paste code. [1] https://lkml.kernel.org/r/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com Reviewed-by: Rex Zhu <rezhu@amd.com> Signed-off-by: Kees Cook <keescook@chromium.org> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/amdgpu: simplify the bo reference on amdgpu_bo_updateHuang Rui1-4/+3
BO ptr already be initialized at definition, we needn't use the complicated reference. v2: fix typo at subject line Signed-off-by: Huang Rui <ray.huang@amd.com> Reviewed-by: Christian König <christian.koenig@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/amdgpu: remove internal/unused kernel module parametersSonny Jiang2-15/+0
Remove internal/unused kernel module parameters Signed-off-by: Sonny Jiang <sonny.jiang@amd.com> Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/amdgpu: change ring priority after pushing the job (v2)Christian König2-3/+11
Pushing a job can change the ring assignment of an entity. v2: squash in: "drm/amdgpu: fix job priority handling" (Christian) Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/amdgpu: allow for more flexible priority handlingChristian König1-1/+2
Allow to call amdgpu_ring_priority_get() after pushing the ring to the scheduler. Signed-off-by: Christian König <christian.koenig@amd.com> Reviewed-by: Chunming Zhou <david1.zhou@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
2018-07-19drm/amdgpu/gfx9: Update golden settings for vg10.Feifei Xu1-1/+12
Add some UTCL registers' golden settings. Signed-off-by: Feifei Xu <Feifei.Xu@amd.com> Tested-by: Kevin Wang <Kevin1.Wang@amd.com> Signed-off-by: Alex Deucher <alexander.deucher@amd.com>