summaryrefslogtreecommitdiff
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2017-09-04Merge tag 'drm-for-v4.14' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds120-33201/+5917
Pull drm updates from Dave Airlie: "This is the main drm pull request for 4.14 merge window. I'm sending this early, as my continuing journey into fatherhood is occurring really soon now, I'm going to be mostly useless for the next couple of weeks, though I may be able to read email, I doubt I'll be doing much patch applications or git sending. If anything urgent pops up I've asked Daniel/Jani/Alex/Sean to try and direct stuff towards you. Outside drm changes: Some rcar-du updates that touch the V4L tree, all acks should be in place. It adds one export to the radix tree code for new i915 use case. There are some minor AGP cleanups (don't see that too often). Changes to the vbox driver in staging to avoid breaking compilation. Summary: core: - Atomic helper fixes - Atomic UAPI fixes - Add YCBCR 4:2:0 support - Drop set_busid hook - Refactor fb_helper locking - Remove a bunch of internal APIs - Add a bunch of better default handlers - Format modifier/blob plane property added - More internal header refactoring - Make more internal API names consistent - Enhanced syncobj APIs (wait/signal/reset/create signalled) bridge: - Add Synopsys Designware MIPI DSI host bridge driver tiny: - Add Pervasive Displays RePaper displays - Add support for LEGO MINDSTORMS EV3 LCD i915: - Lots of GEN10/CNL support patches - drm syncobj support - Skylake+ watermark refactoring - GVT vGPU 48-bit ppgtt support - GVT performance improvements - NOA change ioctl - CCS (color compression) scanout support - GPU reset improvements amdgpu: - Initial hugepage support - BO migration logic rework - Vega10 improvements - Powerplay fixes - Stop reprogramming the MC - Fixes for ACP audio on stoney - SR-IOV fixes/improvements - Command submission overhead improvements amdkfd: - Non-dGPU upstreaming patches - Scratch VA ioctl - Image tiling modes - Update PM4 headers for new firmware - Drop all BUG_ONs. nouveau: - GP108 modesetting support. - Disable MSI on big endian. vmwgfx: - Add fence fd support. msm: - Runtime PM improvements exynos: - NV12MT support - Refactor KMS drivers imx-drm: - Lock scanout channel to improve memory bw - Cleanups etnaviv: - GEM object population fixes tegra: - Prep work for Tegra186 support - PRIME mmap support sunxi: - HDMI support improvements - HDMI CEC support omapdrm: - HDMI hotplug IRQ support - Big driver cleanup - OMAP5 DSI support rcar-du: - vblank fixes - VSP1 updates arcgpu: - Minor fixes stm: - Add STM32 DSI controller driver dw_hdmi: - Add support for Rockchip RK3399 - HDMI CEC support atmel-hlcdc: - Add 8-bit color support vc4: - Atomic fixes - New ioctl to attach a label to a buffer object - HDMI CEC support - Allow userspace to dictate rendering order on submit ioctl" * tag 'drm-for-v4.14' of git://people.freedesktop.org/~airlied/linux: (1074 commits) drm/syncobj: Add a signal ioctl (v3) drm/syncobj: Add a reset ioctl (v3) drm/syncobj: Add a syncobj_array_find helper drm/syncobj: Allow wait for submit and signal behavior (v5) drm/syncobj: Add a CREATE_SIGNALED flag drm/syncobj: Add a callback mechanism for replace_fence (v3) drm/syncobj: add sync obj wait interface. (v8) i915: Use drm_syncobj_fence_get drm/syncobj: Add a race-free drm_syncobj_fence_get helper (v2) drm/syncobj: Rename fence_get to find_fence drm: kirin: Add mode_valid logic to avoid mode clocks we can't generate drm/vmwgfx: Bump the version for fence FD support drm/vmwgfx: Add export fence to file descriptor support drm/vmwgfx: Add support for imported Fence File Descriptor drm/vmwgfx: Prepare to support fence fd drm/vmwgfx: Fix incorrect command header offset at restart drm/vmwgfx: Support the NOP_ERROR command drm/vmwgfx: Restart command buffers after errors drm/vmwgfx: Move irq bottom half processing to threads drm/vmwgfx: Don't use drm_irq_[un]install ...
2017-08-28i915: Use drm_syncobj_fence_getJason Ekstrand1-3/+1
Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Signed-off-by: Dave Airlie <airlied@redhat.com>
2017-08-23Merge tag 'gvt-fixes-2017-08-23' of https://github.com/01org/gvt-linux into ↵Jani Nikula1-1/+1
drm-intel-fixes gvt-fixes-2017-08-23 - Fix possible null ptr reference in error path (Fred) Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170823075352.nlo7hp3bplnb5ilx@zhen-hp.sh.intel.com
2017-08-23drm/i915/gvt: Fix the kernel null pointer errorfred gao1-1/+1
once error happens in shadow_indirect_ctx function, the variable wa_ctx->indirect_ctx.obj is not initialized but accessed, so the kernel null point panic occurs. Fixes: 894cf7d15634 ("drm/i915/gvt: i915_gem_object_create() returns an error pointer") Cc: stable@vger.kernel.org # v4.8+ Signed-off-by: fred gao <fred.gao@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-22Merge tag 'drm-intel-next-2017-08-18' of ↵Dave Airlie115-32707/+4617
git://anongit.freedesktop.org/git/drm-intel into drm-next Final pile of features for 4.14 - New ioctl to change NOA configurations, plus prep (Lionel) - CCS (color compression) scanout support, based on the fancy new modifier additions (Ville&Ben) - Document i915 register macro style (Jani) - Many more gen10/cnl patches (Rodrigo, Pualo, ...) - More gpu reset vs. modeset duct-tape to restore the old way. - prep work for cnl: hpd_pin reorg (Rodrigo), support for more power wells (Imre), i2c pin reorg (Anusha) - drm_syncobj support (Jason Ekstrand) - forcewake vs gpu reset fix (Chris) - execbuf speedup for the no-relocs fastpath, anv/vk low-overhead ftw (Chris) - switch to idr/radixtree instead of the resizing ht for execbuf id->vma lookups (Chris) gvt: - MMIO save/restore optimization (Changbin) - Split workload scan vs. dispatch for more parallel exec (Ping) - vGPU full 48bit ppgtt support (Joonas, Tina) - vGPU hw id expose for perf (Zhenyu) Bunch of work all over to make the igt CI runs more complete/stable. Watch https://intel-gfx-ci.01.org/tree/drm-tip/shards-all.html for progress in getting this ready. Next week we're going into production mode (i.e. will send results to intel-gfx) on hsw, more platforms to come. Also, a new maintainer tram, I'm stepping out. Huge thanks to Jani for being an awesome co-maintainer the past few years, and all the best for Jani, Joonas&Rodrigo as the new maintainers! * tag 'drm-intel-next-2017-08-18' of git://anongit.freedesktop.org/git/drm-intel: (179 commits) drm/i915: Update DRIVER_DATE to 20170818 drm/i915/bxt: use NULL for GPIO connection ID drm/i915: Mark the GT as busy before idling the previous request drm/i915: Trivial grammar fix s/opt of/opt out of/ in comment drm/i915: Replace execbuf vma ht with an idr drm/i915: Simplify eb_lookup_vmas() drm/i915: Convert execbuf to use struct-of-array packing for critical fields drm/i915: Check context status before looking up our obj/vma drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcs drm/i915: Stop touching forcewake following a gen6+ engine reset MAINTAINERS: drm/i915 has a new maintainer team drm/i915: Split pin mapping into per platform functions drm/i915/opregion: let user specify override VBT via firmware load drm/i915/cnl: Reuse skl_wm_get_hw_state on Cannonlake. drm/i915/gen10: implement gen 10 watermarks calculations drm/i915/cnl: Fix LSPCON support. drm/i915/vbt: ignore extraneous child devices for a port drm/i915/cnl: Setup PAT Index. drm/i915/edp: Allow alternate fixed mode for eDP if available. drm/i915: Add support for drm syncobjs ...
2017-08-21drm/i915: Clear lost context-switch interrupts across resetChris Wilson1-1/+22
During a global reset, we disable the irq. As we disable the irq, the hardware may be raising a GT interrupt that we then ignore, leaving it pending in the GTIIR. After the reset, we then re-enable the irq, triggering the pending interrupt. However, that interrupt was for the stale state from before the reset, and the contents of the CSB buffer are now invalid. v2: Add a comment to make it clear that the double clear is purely my paranoia. Reported-by: "Dong, Chuanxiao" <chuanxiao.dong@intel.com> Fixes: 821ed7df6e2a ("drm/i915: Update reset path to fix incomplete requests") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: "Dong, Chuanxiao" <chuanxiao.dong@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Winiarski <michal.winiarski@intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170807121919.30165-1-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/20170818090509.5363-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com> (cherry picked from commit 64f09f00caf0a7cb40a8c0b85789bacba0f51d9e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-21drm/i915/bxt: use NULL for GPIO connection IDAndy Shevchenko1-1/+1
The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element support") enables GPIO support for Broxton based platforms. While using that API we might get into troubles in the future, because we can't rely on label name in the driver since vendor firmware might provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in which case the request will fail). To avoid inconsistency and potential issues we have two options: a) generate GPIO ACPI mapping table and supply it via acpi_dev_add_driver_gpios(), or b) just pass NULL as connection ID. The b) approach is much simpler and would work since the driver relies on GPIO indices only. Moreover, the _CRS fallback mechanism, when requesting GPIO, has been made stricter, and supplying non-NULL connection ID when neither _DSD, nor GPIO ACPI mapping is present, is making request fail. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921 Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817105541.63914-1-andriy.shevchenko@linux.intel.com (cherry picked from commit cd55a1fbd21a820b7dd85a208b3170aa0b06adfa) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-18drm/i915: Update DRIVER_DATE to 20170818Daniel Vetter1-2/+2
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2017-08-18drm/i915/bxt: use NULL for GPIO connection IDAndy Shevchenko1-1/+1
The commit 213e08ad60ba ("drm/i915/bxt: add bxt dsi gpio element support") enables GPIO support for Broxton based platforms. While using that API we might get into troubles in the future, because we can't rely on label name in the driver since vendor firmware might provide any GPIO pin there, e.g. "reset", and even mark it in _DSD (in which case the request will fail). To avoid inconsistency and potential issues we have two options: a) generate GPIO ACPI mapping table and supply it via acpi_dev_add_driver_gpios(), or b) just pass NULL as connection ID. The b) approach is much simpler and would work since the driver relies on GPIO indices only. Moreover, the _CRS fallback mechanism, when requesting GPIO, has been made stricter, and supplying non-NULL connection ID when neither _DSD, nor GPIO ACPI mapping is present, is making request fail. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101921 Fixes: f10e4bf6632b ("gpio: acpi: Even more tighten up ACPI GPIO lookups") Cc: Mika Kahola <mika.kahola@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Tested-by: Mika Kahola <mika.kahola@intel.com> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817105541.63914-1-andriy.shevchenko@linux.intel.com
2017-08-18drm/i915: Mark the GT as busy before idling the previous requestChris Wilson1-43/+45
In a synchronous setup, we may retire the last request before we complete allocating the next request. As the last request is retired, we queue a timer to mark the device as idle, and promptly have to execute ad cancel that timer once we complete allocating the request and need to keep the device awake. If we rearrange the mark_busy() to occur before we retire the previous request, we can skip this ping-pong. v2: Joonas pointed out that unreserve_seqno() was now doing more than doing seqno handling and should be renamed to reflect its wider purpose. That also highlighted the new asymmetry with reserve_seqno(), so fixup that and rename both to [un]reserve_engine(). Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817144719.10968-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-08-18drm/i915: Trivial grammar fix s/opt of/opt out of/ in commentChris Wilson1-1/+1
The word out was dropped from the sentence across the line break, put it back. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-6-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-08-18drm/i915: Replace execbuf vma ht with an idrChris Wilson10-208/+114
This was the competing idea long ago, but it was only with the rewrite of the idr as an radixtree and using the radixtree directly ourselves, along with the realisation that we can store the vma directly in the radixtree and only need a list for the reverse mapping, that made the patch performant enough to displace using a hashtable. Though the vma ht is fast and doesn't require any extra allocation (as we can embed the node inside the vma), it does require a thread for resizing and serialization and will have the occasional slow lookup. That is hairy enough to investigate alternatives and favour them if equivalent in peak performance. One advantage of allocating an indirection entry is that we can support a single shared bo between many clients, something that was done on a first-come first-serve basis for shared GGTT vma previously. To offset the extra allocations, we create yet another kmem_cache for them. 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/20170816085210.4199-5-chris@chris-wilson.co.uk
2017-08-18drm/i915: Simplify eb_lookup_vmas()Chris Wilson1-86/+36
Since the introduction of being able to perform a lockless lookup of an object (i915_gem_object_get_rcu() in fbbd37b36fa5 ("drm/i915: Move object release to a freelist + worker") we no longer need to split the object/vma lookup into 3 phases and so combine them into a much simpler single loop. 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/20170816085210.4199-4-chris@chris-wilson.co.uk
2017-08-18drm/i915: Convert execbuf to use struct-of-array packing for critical fieldsChris Wilson3-151/+156
When userspace is doing most of the work, avoiding relocs (using NO_RELOC) and opting out of implicit synchronisation (using ASYNC), we still spend a lot of time processing the arrays in execbuf, even though we now should have nothing to do most of the time. One issue that becomes readily apparent in profiling anv is that iterating over the large execobj[] is unfriendly to the loop prefetchers of the CPU and it much prefers iterating over a pair of arrays rather than one big array. v2: Clear vma[] on construction to handle errors during vma lookup 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/20170816085210.4199-3-chris@chris-wilson.co.uk
2017-08-18drm/i915: Check context status before looking up our obj/vmaChris Wilson1-7/+6
Since we keep the context around across the slow lookup where we may drop the struct_mutex, we should double check that the context is still valid upon reacquisition. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-2-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
2017-08-18drm/i915: Don't use MI_STORE_DWORD_IMM on Sandybridge/vcsChris Wilson7-15/+40
MI_STORE_DWORD_IMM just doesn't work on the video decode engine under Sandybridge, so refrain from using it. Then switch the selftests over to using the now common test prior to using MI_STORE_DWORD_IMM. Fixes: 7dd4f6729f92 ("drm/i915: Async GPU relocation processing") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.13-rc1+ Link: https://patchwork.freedesktop.org/patch/msgid/20170816085210.4199-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2017-08-18drm/i915: Stop touching forcewake following a gen6+ engine resetChris Wilson1-6/+1
Forcewake is not affected by the engine reset on gen6+. Indeed the reason why we added intel_uncore_forcewake_reset() to gen6_reset_engines() was to keep the bookkeeping intact because the reset did not touch the forcewake bit (yet we cancelled the forcewake consumers)! This was done in commit 521198a2e7095: Author: Mika Kuoppala <mika.kuoppala@linux.intel.com> Date: Fri Aug 23 16:52:30 2013 +0300 drm/i915: sanitize forcewake registers on reset In reset we try to restore the forcewake state to pre reset state, using forcewake_count. The reset doesn't seem to clear the forcewake bits so we get warn on forcewake ack register not clearing. That futzing of the forcewake bookkeeping was dropped in commit 0294ae7b44bb ("drm/i915: Consolidate forcewake resetting to a single function"), but it did not make the realisation that the remaining intel_uncore_forcewake_reset() was redundant. The new danger with using intel_uncore_forcewake_reset() with per-engine resets is that the driver and hw are still in an active state as we perform the reset. We may be using the forcewake to read protected registers elsewhere and those results may be clobbered by the concurrent dropping of forcewake. Reported-by: Michel Thierry <michel.thierry@intel.com> Fixes: 142bc7d99bcf ("drm/i915: Modify error handler for per engine hang recovery") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817173229.20324-1-chris@chris-wilson.co.uk Reviewed-by: Michel Thierry <michel.thierry@intel.com> Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
2017-08-18drm/i915: Split pin mapping into per platform functionsAnusha Srivatsa1-22/+91
Cleanup the code. Map the pins in accordance to individual platforms rather than according to ports. Create separate functions for platforms. v2: - Add missing condition for CoffeeLake. Make platform specific functions static. Add function i915_ddc_pin_mapping(). v3: - Rename functions to x_port_to_ddc_pin() which directly indicates the purpose. Correct default return values on CNP and BXT. Rename i915_port_to_ to g4x_port_to since that was the first platform to run this. Correct code style. (Paulo) Sugested-by Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Clinton Taylor <clinton.a.taylor@intel.com> Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com> Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1502927114-24012-1-git-send-email-anusha.srivatsa@intel.com
2017-08-17drm/i915/opregion: let user specify override VBT via firmware loadJani Nikula4-0/+51
Sometimes it would be most enlightening to debug systems by replacing the VBT to be used. For example, in the referenced bug the BIOS provides different VBT depending on the boot mode (UEFI vs. legacy). It would be interesting to try the failing boot mode with the VBT from the working boot, and see if that makes a difference. Add a module parameter to load the VBT using the firmware loader, not unlike the EDID firmware mechanism. As a starting point for experimenting, one can pick up the BIOS provided VBT from /sys/kernel/debug/dri/0/i915_opregion/i915_vbt. v2: clarify firmware load return value check (Bob) v3: kfree the loaded firmware blob References: https://bugs.freedesktop.org/show_bug.cgi?id=97822#c83 Reviewed-by: Bob Paauwe <bob.j.paauwe@intel.com> Acked-by: Daniel Vetter <daniel@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170817115209.25912-1-jani.nikula@intel.com
2017-08-16drm/i915/cnl: Fix LSPCON support.Rodrigo Vivi1-2/+2
When LSPCON support was extended to CNL one part was missed on lspcon_init. So, instead of adding check per platform on lspcon_init let's use HAS_LSPCON that is already there for that purpose. Fixes: ff15947e0f02 ("drm/i915/cnl: LSPCON support is gen9+") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170816030403.11368-1-rodrigo.vivi@intel.com (cherry picked from commit acf58d4e965d40fc014252292b0911b4c9fe6697) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-16drm/i915/vbt: ignore extraneous child devices for a portJani Nikula1-6/+9
Ever since we've parsed VBT child devices, starting from 6acab15a7b0d ("drm/i915: use the HDMI DDI buffer translations from VBT"), we've ignored the child device information if more than one child device references the same port. The rationale for this seems lost in time. Since commit 311a20949f04 ("drm/i915: don't init DP or HDMI when not supported by DDI port") we started using this information more to skip HDMI/DP init if the port wasn't there per VBT child devices. However, at the same time it added port defaults without further explanation. Thus, if the child device info was skipped due to multiple child devices referencing the same port, the device info would be retrieved from the somewhat arbitrary defaults. Finally, when commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") stopped initializing the defaults whenever VBT is present, thus trusting the VBT more, we stopped initializing ports which were referenced by more than one child device. Apparently at least Asus UX305UA, UX305U, and UX306U laptops have VBT child device blocks which cause this behaviour. Arguably they were shipped with a broken VBT. Relax the rules for multiple references to the same port, and use the first child device info to reference a port. Retain the logic to debug log about this, though. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101745 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196233 Fixes: bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") Tested-by: Oliver Weißbarth <mail@oweissbarth.de> Reported-by: Oliver Weißbarth <mail@oweissbarth.de> Reported-by: Didier G <didierg-divers@orange.fr> Reported-by: Giles Anderson <agander@gmail.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170811113907.6716-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit b5273d72750555a673040070bfb23c454a7cd3ef) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-16drm/i915: Initialize 'data' in intel_dsi_dcs_backlight.cBalasubramaniam, Hari Chand1-1/+1
variable 'data' may be used uninitialized in this function. thus, 'function dcs_get_backlight' will return unwanted value/fail. Thus, adding NULL initialized to 'data' variable will solve the return failure happening. v2: Change commit message to reflect upstream with proper message Fixes: 90198355b83c ("drm/i915/dsi: Add DCS control for Panel PWM") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Yetunde Adebisi <yetundex.adebisi@intel.com> Cc: Deepak M <m.deepak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Balasubramaniam, Hari Chand <hari.chand.balasubramaniam@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1502762746-191826-1-git-send-email-hari.chand.balasubramaniam@intel.com (cherry picked from commit d59814a5b4852442e1d03c569a4542f8b08356a7) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-16drm/i915/cnl: Reuse skl_wm_get_hw_state on Cannonlake.Rodrigo Vivi1-1/+1
Otherwise it reuses the ilk that has a completely different wm. Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170809205248.11917-6-rodrigo.vivi@intel.com
2017-08-16drm/i915/gen10: implement gen 10 watermarks calculationsPaulo Zanoni1-4/+13
They're slightly different than the gen 9 calculations. v2: Remove TODO comment. Code matches recent spec. v3: Rebase on top of latest skl code using new fp16.16 and fixing a logic issue. Auto rebase bot has apparently made some bad decisions that changed the logic of the code. (Noticed by Manesh, updated by Rodrigo). Cc: Mahesh Kumar <mahesh1.kumar@intel.com> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Mahesh Kumar <mahesh1.kumar@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170811233825.32083-1-rodrigo.vivi@intel.com
2017-08-16drm/i915/cnl: Fix LSPCON support.Rodrigo Vivi1-2/+2
When LSPCON support was extended to CNL one part was missed on lspcon_init. So, instead of adding check per platform on lspcon_init let's use HAS_LSPCON that is already there for that purpose. Fixes: ff15947e0f02 ("drm/i915/cnl: LSPCON support is gen9+") Cc: Shashank Sharma <shashank.sharma@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Reviewed-by: Shashank Sharma <shashank.sharma@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170816030403.11368-1-rodrigo.vivi@intel.com
2017-08-16drm/i915/vbt: ignore extraneous child devices for a portJani Nikula1-6/+9
Ever since we've parsed VBT child devices, starting from 6acab15a7b0d ("drm/i915: use the HDMI DDI buffer translations from VBT"), we've ignored the child device information if more than one child device references the same port. The rationale for this seems lost in time. Since commit 311a20949f04 ("drm/i915: don't init DP or HDMI when not supported by DDI port") we started using this information more to skip HDMI/DP init if the port wasn't there per VBT child devices. However, at the same time it added port defaults without further explanation. Thus, if the child device info was skipped due to multiple child devices referencing the same port, the device info would be retrieved from the somewhat arbitrary defaults. Finally, when commit bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") stopped initializing the defaults whenever VBT is present, thus trusting the VBT more, we stopped initializing ports which were referenced by more than one child device. Apparently at least Asus UX305UA, UX305U, and UX306U laptops have VBT child device blocks which cause this behaviour. Arguably they were shipped with a broken VBT. Relax the rules for multiple references to the same port, and use the first child device info to reference a port. Retain the logic to debug log about this, though. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101745 Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=196233 Fixes: bb1d132935c2 ("drm/i915/vbt: split out defaults that are set when there is no VBT") Tested-by: Oliver Weißbarth <mail@oweissbarth.de> Reported-by: Oliver Weißbarth <mail@oweissbarth.de> Reported-by: Didier G <didierg-divers@orange.fr> Reported-by: Giles Anderson <agander@gmail.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: <stable@vger.kernel.org> # v4.12+ Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170811113907.6716-1-jani.nikula@intel.com Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-16drm/i915/cnl: Setup PAT Index.Rodrigo Vivi2-2/+25
Different from previous platforms, on CNL+ there's separated registers for separated indexes. v2: Remove comments regarding uncertainty around the table. v3: Remove extra line (by Ben) Cc: Clint Taylor <clinton.a.taylor@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Ben Widawsky <benjamin.widawsky@intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170815232539.3562-1-rodrigo.vivi@intel.com
2017-08-16drm/i915/edp: Allow alternate fixed mode for eDP if available.Jim Bride6-8/+45
Some fixed resolution panels actually support more than one mode, with the only thing different being the refresh rate. Having this alternate mode available to us is desirable, because it allows us to test PSR on panels whose setup time at the preferred mode is too long. With this patch we allow the use of the alternate mode if it's available and it was specifically requested. v2 and v3: Rebase v4: * Fix up some leaky mode stuff (Chris) * Rebase v5: * Fix a NULL pointer derefrence (David Weinehall) v6: * Whitespace / spelling / checkpatch clean-up; no functional change. (David) * Rebase Cc: David Weinehall <david.weinehall@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: David Weinehall <david.weinehall@linux.intel.com> Signed-off-by: Jim Bride <jim.bride@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1502308133-26892-1-git-send-email-jim.bride@linux.intel.com
2017-08-15drm/i915: Add support for drm syncobjsJason Ekstrand2-6/+149
This commit adds support for waiting on or signaling DRM syncobjs as part of execbuf. It does so by hijacking the currently unused cliprects pointer to instead point to an array of i915_gem_exec_fence structs which containe a DRM syncobj and a flags parameter which specifies whether to wait on it or to signal it. This implementation theoretically allows for both flags to be set in which case it waits on the dma_fence that was in the syncobj and then immediately replaces it with the dma_fence from the current execbuf. v2: - Rebase on new syncobj API v3: - Pull everything out into helpers - Do all allocation in gem_execbuffer2 - Pack the flags in the bottom 2 bits of the drm_syncobj* v4: - Prevent a potential race on syncobj->fence Testcase: igt/gem_exec_fence/syncobj* Signed-off-by: Jason Ekstrand <jason@jlekstrand.net> Link: https://patchwork.freedesktop.org/patch/msgid/1499289202-25441-1-git-send-email-jason.ekstrand@intel.com Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170815145733.4562-1-chris@chris-wilson.co.uk
2017-08-15drm/i915: Handle full s64 precision for wait-ioctlChris Wilson2-1/+10
The wait-ioctl is optionally supplied a timeout with nanosecond precision in a s64 field. We use nsecs_to_jiffies64() to convert that into the jiffies consumed by the scheduler, but internally nsecs_to_jiffies64() does not guard against overflow (as it's purpose is for use by the scheduler and not drivers!). So we must guard against the overflow ourselves, and in the process note that we may then return much earlier than the timeout selected by the user, so don't report ETIME unless we do hit the timeout. (Woe betold us though if the user waits for a year (32bit) and the request is still not complete!) v2: Refine overflow detection (to not include an overffow itself) Reported-by: Jason Ekstrand <jason.ekstrand@intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170811105731.9482-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-08-15drm/i915: Split obj->cache_coherent to track r/wChris Wilson11-32/+96
Another month, another story in the cache coherency saga. This time, we come to the realisation that i915_gem_object_is_coherent() has been reporting whether we can read from the target without requiring a cache invalidate; but we were using it in places for testing whether we could write into the object without requiring a cache flush. So split the tracking into two, one to decide before reads, one after writes. See commit e27ab73d17ef ("drm/i915: Mark CPU cache as dirty on every transition for CPU writes") for the previous entry in this saga. v2: Be verbose v3: Remove unused function (i915_gem_object_is_coherent) v4: Fix inverted coherency check prior to execbuf (from v2) v5: Add comment for nasty code where we are optimising on gcc's behalf. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101109 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101555 Testcase: igt/kms_mmap_write_crc Testcase: igt/kms_pwrite_crc Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Dongwon Kim <dongwon.kim@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Tested-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Acked-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170811111116.10373-1-chris@chris-wilson.co.uk Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
2017-08-15drm/i915/hsw+: Add support for multiple power well regsImre Deak4-33/+68
Future platforms increase the number of power wells which require additional control registers. A convenient way to select the correct register is to use the high bits of the power well ID as index. This patch only prepares for this, while upcoming platform enabling patches will add the actual new power well IDs and corresponding power well control registers. Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Animesh Manna <animesh.manna@intel.com> Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Animesh Manna <animesh.manna@intel.com> Reviewed-by: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-2-imre.deak@intel.com
2017-08-15drm/i915: Work around GCC anonymous union initialization bugImre Deak1-24/+54
GCC 4.4 can't cope with anonymous union initializers which seems to be a bug in that version (see the Reference) and is fixed since GCC version 4.6. A workaround which is also used elsewhere in the kernel for the same purpose is to wrap the initialization in curly braces, so do the same here. Fixes: b5565a2efc12 ("drm/i915/bxt, glk: Give a proper name to the power well struct phy field") Reference: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10676 Reported-by: Fengguang Wu <fengguang.wu@intel.com> Cc: Arkadiusz Hiler <arkadiusz.hiler@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20170814151530.24154-1-imre.deak@intel.com
2017-08-15Merge tag 'gvt-next-2017-08-15' of https://github.com/01org/gvt-linux into ↵Daniel Vetter18-133/+297
drm-intel-next-queued gvt-next-2017-08-15 gvt update for 4.14 - MMIO save/restore optimization (Changbin) - Split workload scan vs. dispatch for more parallel exec (Ping) - vGPU full 48bit ppgtt support (Joonas, Tina) - vGPU hw id expose for perf (Zhenyu) - other misc cleanup and fixes Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170815023940.skhjfcsyrao7axqi@zhen-hp.sh.intel.com
2017-08-15drm/i915: Initialize 'data' in intel_dsi_dcs_backlight.cBalasubramaniam, Hari Chand1-1/+1
variable 'data' may be used uninitialized in this function. thus, 'function dcs_get_backlight' will return unwanted value/fail. Thus, adding NULL initialized to 'data' variable will solve the return failure happening. v2: Change commit message to reflect upstream with proper message Fixes: 90198355b83c ("drm/i915/dsi: Add DCS control for Panel PWM") Cc: Jani Nikula <jani.nikula@intel.com> Cc: Daniel Vetter <daniel.vetter@intel.com> Cc: Yetunde Adebisi <yetundex.adebisi@intel.com> Cc: Deepak M <m.deepak@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Signed-off-by: Balasubramaniam, Hari Chand <hari.chand.balasubramaniam@intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1502762746-191826-1-git-send-email-hari.chand.balasubramaniam@intel.com
2017-08-15drm/i915/dp: Validate the compliance test link parametersManasi Navare1-17/+17
Validate the compliance test link parameters when the compliance test dpcd registers are read. Also validate them in compute_config before using them since the max values might have been reduced due to link training fallback. If either the link rate or lane count is invalid, we still bail from using the test parameters since the combination would not work and instead use the fallback values. v2: * Added commit message to explain why we still bail when either of of the params is invalid (Ville Syrjala) * Add reason for validating in the comment (Jani Nikula) * Also check if index >= 0 after validating (Jani Nikula) Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@intel.com> Tested-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1496954463-18038-2-git-send-email-manasi.d.navare@intel.com
2017-08-15drm/i915/dp: Generalize intel_dp_link_params function to accept arguments to ↵Manasi Navare1-6/+8
be validated This function now takes the link rate and lane ocunt to be validated as an argument so that this can be used for validating even the compliance test link parameters. Signed-off-by: Manasi Navare <manasi.d.navare@intel.com> Cc: Ville Syrjala <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@linux.intel.com> Reviewed-by: Jani Nikula <jani.nikula@linux.intel.com> Tested-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/1496954463-18038-1-git-send-email-manasi.d.navare@intel.com
2017-08-15Backmerge tag 'v4.13-rc5' into drm-nextDave Airlie20-120/+154
Linux 4.13-rc5 There's a really nasty nouveau collision, hopefully someone can take a look once I pushed this out.
2017-08-15drm/i915/gvt: Fix guest i915 full ppgtt blocking issueTina Zhang2-17/+29
Guest i915 full ppgtt functionality was blocking by an issue, which would lead to gpu hardware hang. Guest i915 driver may update the ppgtt table just before this workload is going to be submitted to the hardware by device model. This case wasn't handled well by device model before, due to the small time window between removing old ppgtt entry and adding the new one. Errors occur when the workload is executed by hardware during that small time window. This patch is to remove this time window by adding the new ppgtt entry first and then remove the old one. Changes in v2: - Move VGT_CAPS_FULL_PPGTT introduction to patch 2/4. (Joonas) Changes since v2: - Divide the whole patch set into two separate patch series, with one patch in i915 side to check guest i915 full ppgtt capability and enable it when this capability is supported by the device model, and the other one in gvt side which fixs the blocking issue and enables the device model to provide the capability to guest. And this patch focuses on gvt side. (Joonas) - Change the title from "reorder the shadow ppgtt update process by adding entry first" to "Fix guest i915 full ppgtt blocking issue". (Tina) Changes since v3: - Rebase to the latest branch. Changes since v4: - Tested by Tina Zhang. Changes since v5: - Rebase to the latest branch. v6: - Update full 48bit ppgtt definition Cc: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-15drm/i915: Enable guest i915 full ppgtt functionalityTina Zhang5-3/+20
Enable the guest i915 full ppgtt functionality when host can provide this capability. vgt_caps is introduced to guest i915 driver to get the vgpu capabilities from the device model. VGT_CPAS_FULL_PPGTT is one of the capabilities type to let guest i915 dirver know that the guest i915 full ppgtt is supported by device model. Notice that the minor version of pvinfo isn't bumped because of this vgt_caps introduction, due to older guest would be broken by simply increasing the pvinfo version. Although the pvinfo minor version doesn't increase, the compatibility won't be blocked. The compatibility is ensured by checking the value of caps field in pvinfo. Zero means no full ppgtt support and BIT(2) means this feature is provided. Changes since v1: - Use u32 instead of uint32_t (Joonas) - Move VGT_CAPS_FULL_PPGTT introduction to this patch and use #define instead of enum (Joonas) - Rewrite the vgpu full ppgtt capability checking logic. (Joonas) - Some coding style refine. (Joonas) Changes since v2: - Divide the whole patch set into two separate patch series, with one patch in i915 side to check guest i915 full ppgtt capability and enable it when this capability is supported by the device model, and the other one in gvt side which fixs the blocking issue and enables the device model to provide the capability to guest. And this patch focuses on guest i915 side. (Joonas) - Change the title from "introduce vgt_caps to pvinfo" to "Enable guest i915 full ppgtt functionality". (Tina) Change since v3: - Add some comments about pvinfo caps and version. (Joonas) Change since v4: - Tested by Tina Zhang. Change since v5: - Add limitation about supporting 32bit full ppgtt. Change since v6: - Change the fallback to 48bit full ppgtt if i915.ppgtt_enable=2. (Zhenyu) Change in v9: - Remove the fixme comment due to no plan for 32bit full ppgtt support. (Zhenyu) - Reorder the patch-set to fix compiling issue with git-bisect. (Zhenyu) - Add print log when forcing guest 48bit full ppgtt. (Zhenyu) v10: - Update against Joonas's has_full_ppgtt and has_full_48bit_ppgtt disconnect change. (Zhenyu) Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> # in v2 Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Tina Zhang <tina.zhang@intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-15drm/i915: Disconnect 32 and 48 bit ppGTT supportJoonas Lahtinen1-4/+9
Configurations like virtualized environments may support only 48 bit ppGTT without supporting 32 bit ppGTT. Support this by disconnecting the relationship of the two feature bits. Cc: Tina Zhang <tina.zhang@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Zhi Wang <zhi.a.wang@intel.com> Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
2017-08-14drm/i915: Avoid the gpu reset vs. modeset deadlockDaniel Vetter1-0/+7
... using the biggest hammer we have. This is essentially a weaponized version of the timeout-based wedging Chris added in commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 22 11:56:25 2017 +0100 drm/i915: Break modeset deadlocks on reset Because defense-in-depth is good it's good to still have both. Also note that with the locking change we can now restrict this a lot (old gpus and special testing only), so this doesn't kill the TDR benefits on at least anything remotely modern. And futuremore with a few tricks it should be possible to make a much more educated guess about whether an atomic commit is stuck waiting on the gpu (atomic_t counting the pending i915_sw_fence used by the atomic modeset code should do it), so we can improve this. But for now just start with something that is guaranteed to recover faster, for much better CI througput. This defacto reverts TDR on these platforms, but there's not really a single commit to specify as the sole offender. v2: Add a debug message to explain what's going on. We can't DRM_ERROR because that spams CI. And the timeout based fallback still prints a DRM_ERROR, in case something goes wrong. v3: Fix comment layout (Michel) Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion") Fixes: 221fe7994554 ("drm/i915: Perform a direct reset of the GPU from the waiter") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-1-daniel.vetter@ffwll.ch (cherry picked from commit 97154ec242c14f646a3ab3b4da8f838d197f300d) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-14drm/i915: Suppress switch_mm emission between the same aliasing_ppgttChris Wilson1-7/+8
When switching between contexts using the aliasing_ppgtt, the VM is shared. We don't need to reload the PD registers unless they are dirty. Martin Peres reported an issue that looks like corruption between Haswell context switches, bisecting to commit f9326be5f1d3 ("drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use"). Switching between the same mm (the aliasing_ppgtt is used for all contexts in this case) should be a nop, but appears to trigger some side-effects in the context switch. However, as we know the switch is redundant in this case, we can skip it and continue to ignore the issue until somebody feels strong enough to investigate full-ppgtt on gen7 again! Except.. Martin was using full-ppgtt which is not supported as it doesn't work correctly yet. So whilst the bisect did yield valuable information about the failures, the fix should not have any user impact under default settings, with the exception of a slightly lower throughput on xcs as the VM would always be reloaded. v2: Also remember to set the legacy_active_context following the switch on xcs (commit e8a9c58fcd9a ("drm/i915: Unify active context tracking between legacy/execlists/guc")) Fixes: f9326be5f1d3 ("drm/i915: Rearrange switch_context to load the aliasing ppgtt on first use") Fixes: e8a9c58fcd9a ("drm/i915: Unify active context tracking between legacy/execlists/guc") Reported-by: Martin Peres <martin.peres@linux.intel.com> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Martin Peres <martin.peres@linux.intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170812152724.6883-1-chris@chris-wilson.co.uk (cherry picked from commit 12124bea5b82dc1e917304aed703c27292270051) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-14drm/i915: Return correct EDP voltage swing table for 0.85VMatthias Kaehlcke1-1/+1
For 0.85V cnl_get_buf_trans_edp() returns the DP table, instead of EDP. Use the correct table. The error was pointed out by this clang warning: drivers/gpu/drm/i915/intel_ddi.c:392:39: warning: variable 'cnl_ddi_translations_edp_0_85V' is not needed and will not be emitted [-Wunneeded-internal-declaration] static const struct cnl_ddi_buf_trans cnl_ddi_translations_edp_0_85V[] = { Fixes: cf54ca8bc567 ("drm/i915/cnl: Implement voltage swing sequence.") Signed-off-by: Matthias Kaehlcke <mka@chromium.org> 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/20170717195854.192139-1-mka@chromium.org (cherry picked from commit 50946c89850db13bd672c664aec6cf4551f71fe9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-14drm/i915/cnl: Add slice and subslice information to debugfs.Rodrigo Vivi1-1/+1
A missing part to EU slice power gating is the debugfs interface. This patch actually should have been squashed to the initial EU slice power gating one. v2: Initial patch was merged without this part. Fixes: c7ae7e9ab207 ("drm/i915/cnl: Configure EU slice power gating.") Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170809200702.11236-1-rodrigo.vivi@intel.com (cherry picked from commit 7ea1adf30f82a4c0910524ac06f8f1f26281bb23) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-14drm/i915: Perform an invalidate prior to executing golden renderstateChris Wilson1-0/+4
As we may have just bound the renderstate into the GGTT for execution, we need to ensure that the GTT TLB are also flushed. On snb-gt2, this would cause a random GPU hang at the start of a new context (e.g. boot) and on snb-gt1, it was causing the renderstate batch to take ~10s. It was the GPU hang that revealed the truth, as the CS gleefully executed beyond the end of the golden renderstate batch, a good indicator for a GTT TLB miss. Fixes: 20fe17aa52dc ("drm/i915: Remove redundant TLB invalidate on switching contexts") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: stable@vger.kernel.org Link: https://patchwork.freedesktop.org/patch/msgid/20170808131904.1385-1-chris@chris-wilson.co.uk Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: <drm-intel-fixes@lists.freedesktop.org> # v4.12-rc1+ (cherry picked from commit 802673d66f8a6ded5d2689d597853c7bb3a70163) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-14drm/i915: remove unused function declarationLionel Landwerlin1-1/+0
This function is not part of the driver anymore. Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 90f4fcd56bda ("drm/i915: Remove forced stop ring on suspend/unload") Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20170804140348.24971-1-lionel.g.landwerlin@intel.com (cherry picked from commit fe29133df37ac31de9e657ad91bcf74cdfe8c4cd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2017-08-14drm/i915: More surgically unbreak the modeset vs reset deadlockDaniel Vetter4-10/+52
There's no reason to entirely wedge the gpu, for the minimal deadlock bugfix we only need to unbreak/decouple the atomic commit from the gpu reset. The simplest way to fix that is by replacing the unconditional fence wait a the top of commit_tail by a wait which completes either when the fences are done (normal case, or when a reset doesn't need to touch the display state). Or when the gpu reset needs to force-unblock all pending modeset states. The lesser source of deadlocks is when we try to pin a new framebuffer and run into a stall. There's a bunch of places this can happen, like eviction, changing the caching mode, acquiring a fence on older platforms. And we can't just break the depency loop and keep going, the only way would be to break out and restart. But the problem with that approach is that we must stall for the reset to complete before we grab any locks, and with the atomic infrastructure that's a bit tricky. The only place is the ioctl code, and we don't want to insert code into e.g. the BUSY ioctl. Hence for that problem just create a critical section, and if any code is in there, wedge the GPU. For the steady-state this should never be a problem. Note that in both cases TDR itself keeps working, so from a userspace pov this trickery isn't observable. Users themselvs might spot a short glitch while the rendering is catching up again, but that's still better than pre-TDR where we've thrown away all the rendering, including innocent batches. Also, this fixes the regression TDR introduced of making gpu resets deadlock-prone when we do need to touch the display. One thing I noticed is that gpu_error.flags seems to use both our own wait-queue in gpu_error.wait_queue, and the generic wait_on_bit facilities. Not entirely sure why this inconsistency exists, I just picked one style. A possible future avenue could be to insert the gpu reset in-between ongoing modeset changes, which would avoid the momentary glitch. But that's a lot more work to implement in the atomic commit machinery, and given that we only need this for pre-g4x hw, of questionable utility just for the sake of polishing gpu reset even more on those old boxes. It might be useful for other features though. v2: Rebase onto 4.13 with a s/wait_queue_t/struct wait_queue_entry/. v3: Really emabarrassing fixup, I checked the wrong bit and broke the unbreak/wakeup logic. v4: Also handle deadlocks in pin_to_display. v5: Review from Michel: - Fixup the BUILD_BUG_ON - Don't forget about the overlay Cc: Michel Thierry <michel.thierry@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Cc: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-3-daniel.vetter@ffwll.ch Reviewed-by: Michel Thierry <michel.thierry@intel.com>
2017-08-14drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commitDaniel Vetter1-8/+8
Blocking in a worker is ok, that's what the unbound_wq is for. And it unifies the paths between the blocking and nonblocking commit, giving me just one path where I have to implement the deadlock avoidance trickery in the next patch. I first tried to implement the following patch without this rework, but force-completing i915_sw_fence creates some serious challenges around properly cleaning things up. So wasn't a feasible short-term approach. Another approach would be to simple keep track of all pending atomic commit work items and manually queue them from the reset code. With the caveat that double-queue in case we race with the i915_sw_fence must be avoided. Given all that, taking the cost of a double schedule in atomic for the short-term fix is the best approach, but can be changed in the future of course. v2: Amend commit message (Chris). v3: Add comment explaining why we do nothing in the sw_fence complete callback (Michel). Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-2-daniel.vetter@ffwll.ch
2017-08-14drm/i915: Avoid the gpu reset vs. modeset deadlockDaniel Vetter1-0/+7
... using the biggest hammer we have. This is essentially a weaponized version of the timeout-based wedging Chris added in commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 Author: Chris Wilson <chris@chris-wilson.co.uk> Date: Thu Jun 22 11:56:25 2017 +0100 drm/i915: Break modeset deadlocks on reset Because defense-in-depth is good it's good to still have both. Also note that with the locking change we can now restrict this a lot (old gpus and special testing only), so this doesn't kill the TDR benefits on at least anything remotely modern. And futuremore with a few tricks it should be possible to make a much more educated guess about whether an atomic commit is stuck waiting on the gpu (atomic_t counting the pending i915_sw_fence used by the atomic modeset code should do it), so we can improve this. But for now just start with something that is guaranteed to recover faster, for much better CI througput. This defacto reverts TDR on these platforms, but there's not really a single commit to specify as the sole offender. v2: Add a debug message to explain what's going on. We can't DRM_ERROR because that spams CI. And the timeout based fallback still prints a DRM_ERROR, in case something goes wrong. v3: Fix comment layout (Michel) Fixes: 4680816be336 ("drm/i915: Wait first for submission, before waiting for request completion") Fixes: 221fe7994554 ("drm/i915: Perform a direct reset of the GPU from the waiter") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Cc: Michel Thierry <michel.thierry@intel.com> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v2) Reviewed-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20170808080828.23650-1-daniel.vetter@ffwll.ch
generated by cgit v1.2.3 (git 2.39.0) at 2024-11-25 02:45:22 +0300