summaryrefslogtreecommitdiffstats
path: root/drivers/gpu/drm/i915
AgeCommit message (Collapse)AuthorFilesLines
2016-03-25Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds1-10/+5
Pull drm fixes from Dave Airlie: "Just a couple of dma-buf related fixes and some amdgpu fixes, along with a regression fix for radeon off but default feature, but makes my 30" monitor happy again" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: drm/radeon/mst: cleanup code indentation drm/radeon/mst: fix regression in lane/link handling. drm/amdgpu: add invalidate_page callback for userptrs drm/amdgpu: Revert "remove the userptr rmn->lock" drm/amdgpu: clean up path handling for powerplay drm/amd/powerplay: fix memory leak of tdp_table dma-buf/fence: fix fence_is_later v2 dma-buf: Update docs for SYNC ioctl drm: remove excess description dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access() drm/atmel-hlcdc: use helper to get crtc state drm/atomic: use helper to get crtc state
2016-03-24Merge tag 'topic/drm-misc-2016-03-22' of ↵Dave Airlie1-10/+5
git://anongit.freedesktop.org/drm-intel into drm-next Bunch of small fixupes all over. Plus a dma-buf patch that Sumit asked me to cherry-pick since that's the only one he had in his tree. There's a sparse issue outstanding in the color mgr stuff, but Lionel is still working on something that actually appeases sparse. * tag 'topic/drm-misc-2016-03-22' of git://anongit.freedesktop.org/drm-intel: dma-buf/fence: fix fence_is_later v2 dma-buf: Update docs for SYNC ioctl drm: remove excess description dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access() drm/atmel-hlcdc: use helper to get crtc state drm/atomic: use helper to get crtc state
2016-03-21Merge branch 'drm-next' of git://people.freedesktop.org/~airlied/linuxLinus Torvalds61-3337/+4636
Pull drm updates from Dave Airlie: "This is the main drm pull request for 4.6 kernel. Overall the coolest thing here for me is the nouveau maxwell signed firmware support from NVidia, it's taken a long while to extract this from them. I also wish the ARM vendors just designed one set of display IP, ARM display block proliferation is definitely increasing. Core: - drm_event cleanups - Internal API cleanup making mode_fixup optional. - Apple GMUX vga switcheroo support. - DP AUX testing interface Panel: - Refactoring of DSI core for use over more transports. New driver: - ARM hdlcd driver i915: - FBC/PSR (framebuffer compression, panel self refresh) enabled by default. - Ongoing atomic display support work - Ongoing runtime PM work - Pixel clock limit checks - VBT DSI description support - GEM fixes - GuC firmware scheduler enhancements amdkfd: - Deferred probing fixes to avoid make file or link ordering. amdgpu/radeon: - ACP support for i2s audio support. - Command Submission/GPU scheduler/GPUVM optimisations - Initial GPU reset support for amdgpu vmwgfx: - Support for DX10 gen mipmaps - Pageflipping and other fixes. exynos: - Exynos5420 SoC support for FIMD - Exynos5422 SoC support for MIPI-DSI nouveau: - GM20x secure boot support - adds acceleration for Maxwell GPUs. - GM200 support - GM20B clock driver support - Power sensors work etnaviv: - Correctness fixes for GPU cache flushing - Better support for i.MX6 systems. imx-drm: - VBlank IRQ support - Fence support - OF endpoint support msm: - HDMI support for 8996 (snapdragon 820) - Adreno 430 support - Timestamp queries support virtio-gpu: - Fixes for Android support. rockchip: - Add support for Innosilicion HDMI rcar-du: - Support for 4 crtcs - R8A7795 support - RCar Gen 3 support omapdrm: - HDMI interlace output support - dma-buf import support - Refactoring to remove a lot of legacy code. tilcdc: - Rewrite of pageflipping code - dma-buf support - pinctrl support vc4: - HDMI modesetting bug fixes - Significant 3D performance improvement. fsl-dcu (FreeScale): - Lots of fixes tegra: - Two small fixes sti: - Atomic support for planes - Improved HDMI support" * 'drm-next' of git://people.freedesktop.org/~airlied/linux: (1063 commits) drm/amdgpu: release_pages requires linux/pagemap.h drm/sti: restore mode_fixup callback drm/amdgpu/gfx7: add MTYPE definition drm/amdgpu: removing BO_VAs shouldn't be interruptible drm/amd/powerplay: show uvd/vce power gate enablement for tonga. drm/amd/powerplay: show uvd/vce power gate info for fiji drm/amdgpu: use sched fence if possible drm/amdgpu: move ib.fence to job.fence drm/amdgpu: give a fence param to ib_free drm/amdgpu: include the right version of gmc header files for iceland drm/radeon: fix indentation. drm/amd/powerplay: add uvd/vce dpm enabling flag to fix the performance issue for CZ drm/amdgpu: switch back to 32bit hw fences v2 drm/amdgpu: remove amdgpu_fence_is_signaled drm/amdgpu: drop the extra fence range check v2 drm/amdgpu: signal fences directly in amdgpu_fence_process drm/amdgpu: cleanup amdgpu_fence_wait_empty v2 drm/amdgpu: keep all fences in an RCU protected array v2 drm/amdgpu: add number of hardware submissions to amdgpu_fence_driver_init_ring drm/amdgpu: RCU protected amd_sched_fence_release ...
2016-03-20Merge branch 'mm-pkeys-for-linus' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 protection key support from Ingo Molnar: "This tree adds support for a new memory protection hardware feature that is available in upcoming Intel CPUs: 'protection keys' (pkeys). There's a background article at LWN.net: https://lwn.net/Articles/643797/ The gist is that protection keys allow the encoding of user-controllable permission masks in the pte. So instead of having a fixed protection mask in the pte (which needs a system call to change and works on a per page basis), the user can map a (handful of) protection mask variants and can change the masks runtime relatively cheaply, without having to change every single page in the affected virtual memory range. This allows the dynamic switching of the protection bits of large amounts of virtual memory, via user-space instructions. It also allows more precise control of MMU permission bits: for example the executable bit is separate from the read bit (see more about that below). This tree adds the MM infrastructure and low level x86 glue needed for that, plus it adds a high level API to make use of protection keys - if a user-space application calls: mmap(..., PROT_EXEC); or mprotect(ptr, sz, PROT_EXEC); (note PROT_EXEC-only, without PROT_READ/WRITE), the kernel will notice this special case, and will set a special protection key on this memory range. It also sets the appropriate bits in the Protection Keys User Rights (PKRU) register so that the memory becomes unreadable and unwritable. So using protection keys the kernel is able to implement 'true' PROT_EXEC on x86 CPUs: without protection keys PROT_EXEC implies PROT_READ as well. Unreadable executable mappings have security advantages: they cannot be read via information leaks to figure out ASLR details, nor can they be scanned for ROP gadgets - and they cannot be used by exploits for data purposes either. We know about no user-space code that relies on pure PROT_EXEC mappings today, but binary loaders could start making use of this new feature to map binaries and libraries in a more secure fashion. There is other pending pkeys work that offers more high level system call APIs to manage protection keys - but those are not part of this pull request. Right now there's a Kconfig that controls this feature (CONFIG_X86_INTEL_MEMORY_PROTECTION_KEYS) that is default enabled (like most x86 CPU feature enablement code that has no runtime overhead), but it's not user-configurable at the moment. If there's any serious problem with this then we can make it configurable and/or flip the default" * 'mm-pkeys-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (38 commits) x86/mm/pkeys: Fix mismerge of protection keys CPUID bits mm/pkeys: Fix siginfo ABI breakage caused by new u64 field x86/mm/pkeys: Fix access_error() denial of writes to write-only VMA mm/core, x86/mm/pkeys: Add execute-only protection keys support x86/mm/pkeys: Create an x86 arch_calc_vm_prot_bits() for VMA flags x86/mm/pkeys: Allow kernel to modify user pkey rights register x86/fpu: Allow setting of XSAVE state x86/mm: Factor out LDT init from context init mm/core, x86/mm/pkeys: Add arch_validate_pkey() mm/core, arch, powerpc: Pass a protection key in to calc_vm_flag_bits() x86/mm/pkeys: Actually enable Memory Protection Keys in the CPU x86/mm/pkeys: Add Kconfig prompt to existing config option x86/mm/pkeys: Dump pkey from VMA in /proc/pid/smaps x86/mm/pkeys: Dump PKRU with other kernel registers mm/core, x86/mm/pkeys: Differentiate instruction fetches x86/mm/pkeys: Optimize fault handling in access_error() mm/core: Do not enforce PKEY permissions on remote mm access um, pkeys: Add UML arch_*_access_permitted() methods mm/gup, x86/mm/pkeys: Check VMAs and PTEs for protection keys x86/mm/gup: Simplify get_user_pages() PTE bit handling ...
2016-03-19dma-buf, drm, ion: Propagate error code from dma_buf_start_cpu_access()Chris Wilson1-10/+5
Drivers, especially i915.ko, can fail during the initial migration of a dma-buf for CPU access. However, the error code from the driver was not being propagated back to ioctl and so userspace was blissfully ignorant of the failure. Rendering corruption ensues. Whilst fixing the ioctl to return the error code from dma_buf_start_cpu_access(), also do the same for dma_buf_end_cpu_access(). For most drivers, dma_buf_end_cpu_access() cannot fail. i915.ko however, as most drivers would, wants to avoid being uninterruptible (as would be required to guarrantee no failure when flushing the buffer to the device). As userspace already has to handle errors from the SYNC_IOCTL, take advantage of this to be able to restart the syscall across signals. This fixes a coherency issue for i915.ko as well as reducing the uninterruptible hold upon its BKL, the struct_mutex. Fixes commit c11e391da2a8fe973c3c2398452000bed505851e Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Thu Feb 11 20:04:51 2016 -0200 dma-buf: Add ioctls to allow userspace to flush Testcase: igt/gem_concurrent_blit/*dmabuf*interruptible Testcase: igt/prime_mmap_coherency/ioctl-errors Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Cc: Tiago Vignatti <tiago.vignatti@intel.com> Cc: Stéphane Marchesin <marcheu@chromium.org> Cc: David Herrmann <dh.herrmann@gmail.com> Cc: Sumit Semwal <sumit.semwal@linaro.org> Cc: Daniel Vetter <daniel.vetter@intel.com> CC: linux-media@vger.kernel.org Cc: dri-devel@lists.freedesktop.org Cc: linaro-mm-sig@lists.linaro.org Cc: intel-gfx@lists.freedesktop.org Cc: devel@driverdev.osuosl.org Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1458331359-2634-1-git-send-email-chris@chris-wilson.co.uk
2016-03-17Merge branch 'for-linus' of ↵Linus Torvalds1-5/+5
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial Pull trivial tree updates from Jiri Kosina. * 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial: drivers/rtc: broken link fix drm/i915 Fix typos in i915_gem_fence.c Docs: fix missing word in REPORTING-BUGS lib+mm: fix few spelling mistakes MAINTAINERS: add git URL for APM driver treewide: Fix typo in printk
2016-03-14drm/i915: Handle -EDEADLK in drm_atomic_commit from load-detect.Maarten Lankhorst1-1/+2
CI runs with DEBUG_WW_MUTEX_SLOWPATH, so -EDEADLK occurs a lot more. Handle the case where drm_atomic_commit fails with -EDEADLK correctly. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56D3FEF1.6070306@linux.intel.com Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> (cherry picked from commit 3ba86073edcbe2be53d9862d5a3098f0ebf8ae9a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-03-14Merge drm-fixes into drm-next.Dave Airlie6-7/+12
Nouveau wanted this to avoid some worse conflicts when I merge that.
2016-03-11drm/i915: Actually retry with bit-banging after GMBUS timeoutVille Syrjälä1-0/+6
After the GMBUS transfer times out, we set force_bit=1 and return -EAGAIN expecting the i2c core to call the .master_xfer hook again so that we will retry the same transfer via bit-banging. This is in case the gmbus hardware is somehow faulty. Unfortunately we left adapter->retries to 0, meaning the i2c core didn't actually do the retry. Let's tell the core we want one retry when we return -EAGAIN. Note that i2c-algo-bit also uses this retry count for some internal retries, so we'll end up increasing those a bit as well. Cc: Jani Nikula <jani.nikula@intel.com> Cc: drm-intel-fixes@lists.freedesktop.org Fixes: bffce907d640 ("drm/i915: abstract i2c bit banging fallback in gmbus xfer") Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1457366220-29409-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Jani Nikula <jani.nikula@intel.com> (cherry picked from commit 8b1f165a4a8f64c28cf42d10e1f4d3b451dedc51) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-03-08Merge tag 'drm-intel-next-2016-02-29' of ↵Dave Airlie42-610/+930
git://anongit.freedesktop.org/drm-intel into drm-next - fbc by default on hsw&bdw, thanks to great work by Paulo! - psr by default hsw,bdw,vlv&chv, thanks to great work by Rodrigo! - fixes to hw state readout vs. rpm issues (Imre) - dc3 fixes&improvements (Mika), this and above already cherr-pick to -fixes - first part of locking fixes from Tvrtko - proper atomic code for load detect (Maarten) - more rpm fixes from Ville - more atomic work from Maarten * tag 'drm-intel-next-2016-02-29' of git://anongit.freedesktop.org/drm-intel: (63 commits) drm/i915: Update DRIVER_DATE to 20160229 drm/i915: Execlists cannot pin a context without the object drm/i915: Reduce the pointer dance of i915_is_ggtt() drm/i915: Rename vma->*_list to *_link for consistency drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM) drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RS drm/i915/gen9: Set value of Indirect Context Offset based on gen version drm/i915: Remove update_sprite_watermarks. drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6. drm/i915: Unify power domain handling. drm/i915: Pass crtc state to modeset_get_crtc_power_domains. drm/i915: Add for_each_pipe_masked() drm/i915: Make sure pipe interrupts are processed before turning off power well on BDW+ drm/i915: synchronize_irq() before turning off disp2d power well on VLV/CHV drm/i915: Skip PIPESTAT reads from irq handler on VLV/CHV when power well is down drm/i915/gen9: Write dc state debugmask bits only once drm/i915/gen9: Extend dmc debug mask to include cores drm/i915/gen9: Verify and enforce dc6 state writes drm/i915/gen9: Check for DC state mismatch drm/i915/fbc: enable FBC by default on HSW and BDW ...
2016-03-07drm/i915: Fix bogus dig_port_map[] assignment for pre-HSWTakashi Iwai4-4/+3
The recent commit [0bdf5a05647a: drm/i915: Add reverse mapping between port and intel_encoder] introduced a reverse mapping to retrieve intel_dig_port object from the port number. The code assumed that the port vs intel_dig_port are 1:1 mapping. But in reality, this was a too naive assumption. As Martin reported about the missing HDMI audio on his SNB machine, pre-HSW chips may have multiple intel_dig_port objects corresponding to the same port. Since we assign the mapping statically at the init time and the multiple objects override the map, it may not match with the actually enabled output. This patch tries to address the regression above. The reverse mapping is provided basically only for the audio callbacks, so now we set / clear the mapping dynamically at enabling and disabling HDMI/DP audio, so that we can always track the latest and correct object corresponding to the given port. Fixes: 0bdf5a05647a ('drm/i915: Add reverse mapping between port and intel_encoder') Reported-and-tested-by: Martin Kepplinger <martink@posteo.de> Cc: drm-intel-fixes@lists.freedesktop.org Signed-off-by: Takashi Iwai <tiwai@suse.de> Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Tested-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456324522-21591-1-git-send-email-tiwai@suse.de (cherry picked from commit 9dfbffcf4ac0707097af9e6c1372192b9d03a357) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-03-02drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)Chris Wilson1-14/+12
commit 09731280028ce03e6a27e1998137f1775a2839f3 Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 17 14:17:42 2016 +0200 drm/i915: Add helper to get a display power ref if it was already enabled left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as intel_runtime_pm_get_if_in_use() would return true without incrementing the local bookkeeping required for the assertions. Fixes: 09731280028c ("drm/i915: Add helper to get a display power ref if it was already enabled") Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com> (cherry picked from commit 135dc79efbc119ea5fb34475996983159e6ca31c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-03-02drm/i915/skl: Fix power domain suspend sequenceImre Deak1-3/+3
During system suspend we need to first disable power wells then unitialize the display core. In case power well support is disabled we did this in the wrong order, so fix this up. Fixes: d314cd43 ("drm/i915: fix handling of the disable_power_well module option") CC: stable@vger.kernel.org CC: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456778945-5411-1-git-send-email-imre.deak@intel.com (cherry picked from commit 2622d79bd9d18fd04b650234e6a218c5f95cf308) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-03-01Merge tag 'drm-intel-next-2016-02-14' of ↵Dave Airlie43-1074/+1539
git://anongit.freedesktop.org/drm-intel into drm-next - lots and lots of fbc work from Paulo - max pixel clock checks from Mika Kahola - prep work for nv12 offset handling from Ville - piles of small fixes and refactorings all around * tag 'drm-intel-next-2016-02-14' of git://anongit.freedesktop.org/drm-intel: (113 commits) drm/i915: Update DRIVER_DATE to 20160214 drm/i915: edp resume/On time optimization. agp/intel-gtt: Only register fake agp driver for gen1 drm/i915: TV pixel clock check drm/i915: CRT pixel clock check drm/i915: SDVO pixel clock check drm/i915: DisplayPort-MST pixel clock check drm/i915: HDMI pixel clock check drm/i915: DisplayPort pixel clock check drm/i915: check that rpm ref is held when accessing ringbuf in stolen mem drm/i915: fix error path in intel_setup_gmbus() drm/i915: Stop depending upon CONFIG_AGP_INTEL agp/intel-gtt: Don't leak the scratch page drm/i915: Capture PCI revision and subsytem details in error state drm/i915: fix context/engine cleanup order drm/i915: Handle PipeC fused off on IVB/HSW/BDW drm/i915/skl: Fix typo in DPLL_CFGCR1 definition drm/i915: Skip DDI PLL selection for DSI drm/i915/skl: Explicitly check for eDP in skl_ddi_pll_select() drm/i915/skl: Don't skip mst encoders in skl_ddi_pll_select() ...
2016-02-29drm/i915: Update DRIVER_DATE to 20160229Daniel Vetter1-1/+1
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2016-02-26drm/i915: Execlists cannot pin a context without the objectChris Wilson1-4/+0
Given that the intel_lr_context_pin cannot succeed without the object, we cannot reach intel_lr_context_unpin() without first allocating that object - so we can remove the redundant test. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456485751-15213-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-02-26drm/i915: Reduce the pointer dance of i915_is_ggtt()Chris Wilson7-54/+33
The multiple levels of indirect do nothing but hinder the compiler and the pointer chasing turns to be quite painful but painless to fix. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by: Dave Gordon <david.s.gordon@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456484600-11477-1-git-send-email-tvrtko.ursulin@linux.intel.com
2016-02-26drm/i915: Rename vma->*_list to *_link for consistencyChris Wilson10-53/+52
Elsewhere we have adopted the convention of using '_link' to denote elements in the list (and '_list' for the actual list_head itself), and that the name should indicate which list the link belongs to (and preferrably not just where the link is being stored). s/vma_link/obj_link/ (we iterate over obj->vma_list) s/mm_list/vm_link/ (we iterate over vm->[in]active_list) Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
2016-02-26drm/i915: Balance assert_rpm_wakelock_held() for !IS_ENABLED(CONFIG_PM)Chris Wilson1-14/+12
commit 09731280028ce03e6a27e1998137f1775a2839f3 Author: Imre Deak <imre.deak@intel.com> Date: Wed Feb 17 14:17:42 2016 +0200 drm/i915: Add helper to get a display power ref if it was already enabled left the rpm wakelock assertions unbalanced if CONFIG_PM was disabled as intel_runtime_pm_get_if_in_use() would return true without incrementing the local bookkeeping required for the assertions. Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk> CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456434628-22574-1-git-send-email-chris@chris-wilson.co.uk Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-02-26drm/i915/lrc: Only set RS ctx enable in ctx control reg if there is a RSMichel Thierry1-1/+2
The driver should only set the "RS context enable" bit in the context image if we plan to use the resource streamer. Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456393738-35608-1-git-send-email-michel.thierry@intel.com
2016-02-26drm/i915/gen9: Set value of Indirect Context Offset based on gen versionMichel Thierry1-2/+24
The cache line offset for the Indirect CS context (0x21C8) varies from gen to gen. v2: Move it into a function (Arun), use MISSING_CASE (Chris) v3: Rebased (catched by ci bat) Cc: Arun Siluvery <arun.siluvery@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by: Arun Siluvery <arun.siluvery@linux.intel.com> Signed-off-by: Michel Thierry <michel.thierry@intel.com> Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1456223509-6454-1-git-send-email-michel.thierry@intel.com
2016-02-25drm/i915: Remove update_sprite_watermarks.Maarten Lankhorst2-5/+0
Commit 791a32be6eb2 ("drm/i915: Drop intel_update_sprite_watermarks") removes the use of this variable, but forgot to remove it. Reviewed-by: Matt Roper <matthew.d.roper@intel.com> Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-5-git-send-email-maarten.lankhorst@linux.intel.com
2016-02-25drm/i915: Kill off intel_crtc->atomic.wait_vblank, v6.Maarten Lankhorst3-25/+90
Currently we perform our own wait in post_plane_update, but the atomic core performs another one in wait_for_vblanks. This means that 2 vblanks are done when a fb is changed, which is a bit overkill. Merge them by creating a helper function that takes a crtc mask for the planes to wait on. The broadwell vblank workaround may look gone entirely but this is not the case. pipe_config->wm_changed is set to true when any plane is turned on, which forces a vblank wait. Changes since v1: - Removing the double vblank wait on broadwell moved to its own commit. Changes since v2: - Move out POWER_DOMAIN_MODESET handling to its own commit. Changes since v3: - Do not wait for vblank on legacy cursor updates. (Ville) - Move broadwell vblank workaround comment to page_flip_finished. (Ville) Changes since v4: - Compile fix, legacy_cursor_flip -> *_update. Changes since v5: - Kill brackets. - Add WARN_ON when wait_for_vblanks fails. - Remove extra newlines. - Split the checks whether vblank is needed to a separate function, with comments why a vblank is needed. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/56CD84DA.5030507@linux.intel.com Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
2016-02-25drm/i915: Unify power domain handling.Maarten Lankhorst1-45/+24
Right now there's separate power domain handling for update_pipe and modesets. Unify this and only grab POWER_DOMAIN_MODESET once. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-3-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
2016-02-25drm/i915: Pass crtc state to modeset_get_crtc_power_domains.Maarten Lankhorst1-12/+21
Use our newly created encoder_mask to iterate over the encoders. This makes it possible to get the crtc power domains from the crtc_state at any time, without any locks or having to look at the legacy state. Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455108583-29227-2-git-send-email-maarten.lankhorst@linux.intel.com Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
2016-02-22drm/i915: Add for_each_pipe_masked()Ville Syrjälä2-18/+12
for_each_pipe_masked() can be used to iterate over the pipes included in the user provided pipe mask. Removes a few lines of duplicated code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-2-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-02-22drm/i915: Make sure pipe interrupts are processed before turning off power ↵Ville Syrjälä3-0/+37
well on BDW+ Starting from BDW the DE_PIPE interrupts for pipe B and C belong to the relevant display power well. So we should make sure we've finished processing them before turning off the power well. The pipe interrupts shouldn't really happen at this point anymore since we've already shut down the planes/pipes/whatnot, but being a bit paranoid shouldn't hurt. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455907651-16397-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-02-22drm/i915: synchronize_irq() before turning off disp2d power well on VLV/CHVVille Syrjälä1-0/+3
After we've told the irq code we don't want to handle display irqs anymore, we must make sure any display irq handling already kicked off has finished before we actually turn off the power well. I wouldn't expect PIPESTAT based interrupts to occur anymore since vblanks/page flips/gmbus/etc should all be quiescent at this point. But at least hotplug interrupts could still occur. Hotplug interrupts may also kick off the workqueue based hotplug processing, but that code should take the required power domain references itself, so there shouldn't be any need to synchronize with the hotplug processing from the power well code. Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455900112-15387-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-02-22drm/i915: Skip PIPESTAT reads from irq handler on VLV/CHV when power well is ↵Ville Syrjälä1-0/+6
down PIPESTAT registers live in the display power well on VLV/CHV, so we shouldn't access them when things are powered down. Let's check whether the display interrupts are on or off before accessing the PIPESTAT registers. Another option would be to read the PIPESTAT registers only when the IIR register indicates that there's a pending pipe event. But that would mean we might miss even more underrun reports than we do now, because the underrun status bit lives in PIPESTAT but doesn't actually generate an interrupt. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93738 Cc: Chris Wilson <chris@chris-wilson.co.uk> Tested-by: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455825266-24686-1-git-send-email-ville.syrjala@linux.intel.com Reviewed-by: Imre Deak <imre.deak@intel.com>
2016-02-22drm/i915/gen9: Verify and enforce dc6 state writesMika Kuoppala1-2/+39
It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 779cb5d3ddd72950ec726f86e38f7575c7fbdd4c) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/gen9: Check for DC state mismatchPatrik Jakobsson3-0/+11
The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com (cherry picked from commit 832dba889e27487c3087149f1039acc3feb89003) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/skl: Ensure HW is powered during DDB HW state readoutImre Deak1-1/+6
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Spotted-by: Mika Kuoppala <mika.kuoppala@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93441 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455719489-3008-1-git-send-email-imre.deak@intel.com (cherry picked from commit 4d800030238878c1a98d1d3a37a3d673eea661ce) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/lvds: Ensure the HW is powered during HW state readoutImre Deak1-3/+11
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-13-git-send-email-imre.deak@intel.com (cherry picked from commit ecb2448218acf23c401434c26be256147833b221) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/hdmi: Ensure the HW is powered during HW state readoutImre Deak1-3/+11
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-12-git-send-email-imre.deak@intel.com (cherry picked from commit 5b0921748c0b1d0362bbfa802dc25a5c23de7e76) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/dsi: Ensure the HW is powered during HW state readoutImre Deak1-3/+10
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-11-git-send-email-imre.deak@intel.com (cherry picked from commit 3f3f42b887fbffc3353e44ef9f32456c19ae4280) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/dp: Ensure the HW is powered during HW state readoutImre Deak1-4/+14
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-10-git-send-email-imre.deak@intel.com (cherry picked from commit 6fa9a5ecf7a54450b255229ac1fc6df276cf0653) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915: Ensure the HW is powered when accessing the CRC HW blockImre Deak1-7/+21
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. While at it also add the missing reference around the HW access in i915_interrupt_info(). v2: - update the commit message mentioning that this also fixes the HW access in the interrupt info debugfs entry (Daniel) Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-9-git-send-email-imre.deak@intel.com (cherry picked from commit e129649b7a3e1d50d196e159492496777769437e) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/ddi: Ensure the HW is powered during HW state readoutImre Deak1-33/+79
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-8-git-send-email-imre.deak@intel.com (cherry picked from commit e27daab49718e3232318d8b539cb302521b4b724) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/crt: Ensure the HW is powered during HW state readoutImre Deak1-3/+10
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93439 CC: Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-7-git-send-email-imre.deak@intel.com (cherry picked from commit 1c8fdda1ea947ae8cf994969a1c285acc7089cb9) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915: Ensure the HW is powered during HW access in assert_pipeImre Deak1-4/+7
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-6-git-send-email-imre.deak@intel.com (cherry picked from commit 4feed0ebfa45879bc422c9a0bfa3cffec82ea60a) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915: Ensure the HW is powered when disabling VGAImre Deak1-1/+3
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-5-git-send-email-imre.deak@intel.com (cherry picked from commit 6392f8478e6f119467b1ad06e30e1f078e62efc1) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/ibx: Ensure the HW is powered during PLL HW readoutImre Deak1-1/+3
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-4-git-send-email-imre.deak@intel.com (cherry picked from commit 12fda3876d08519bdf6f0acc70dd35754b422ed5) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915: Ensure the HW is powered during display pipe HW readoutImre Deak1-19/+48
The assumption when adding the intel_display_power_is_enabled() checks was that if it returns success the power can't be turned off afterwards during the HW access, which is guaranteed by modeset locks. This isn't always true, so make sure we hold a dedicated reference for the time of the access. Signed-off-by: Imre Deak <imre.deak@intel.com> Revieved-by: Mika Kuoppala <mika.kuoppala@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455296121-4742-3-git-send-email-imre.deak@intel.com (cherry picked from commit 1729050eb4bbc192e54069e82069f2811313c1dd) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915: Add helper to get a display power ref if it was already enabledImre Deak2-9/+94
We have many places in the code where we check if a given display power domain is enabled and if so access registers backed by this power domain. We assumed that some modeset lock will prevent the power reference from vanishing in the middle of the HW access, but this assumption doesn't always hold. In such cases we get either the wakeref not held, or an unclaimed register access error message. To fix this in a future-proof way that's independent of other locks wrap any such access with a get_ref_if_enabled()/put_ref() pair. Kudos to Ville and Joonas for the ideas of this new interface. v2: - init the power_domains ptr when declaring it everywhere (Joonas) v3: - don't report the device to be powered if runtime PM is disabled CC: Mika Kuoppala <mika.kuoppala@intel.com> CC: Chris Wilson <chris@chris-wilson.co.uk> CC: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> CC: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455711462-7442-1-git-send-email-imre.deak@intel.com (cherry picked from commit 09731280028ce03e6a27e1998137f1775a2839f3) Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2016-02-22drm/i915/gen9: Write dc state debugmask bits only onceMika Kuoppala3-9/+8
DMC debugmask bits should stick so no need to write them everytime dc state is changed. v2: Write after firmware has been successfully loaded (Ville) Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-5-git-send-email-mika.kuoppala@intel.com
2016-02-22drm/i915/gen9: Extend dmc debug mask to include coresMika Kuoppala2-6/+11
Cores need to be included into the debug mask. We don't exactly know what it does but the spec says it must be enabled. So obey. v2: Cores should be only set for BXT (Imre, Art) Cc: Imre Deak <imre.deak@intel.com> Cc: Runyan, Arthur J <arthur.j.runyan@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455877564-5128-1-git-send-email-mika.kuoppala@intel.com
2016-02-22drm/i915/gen9: Verify and enforce dc6 state writesMika Kuoppala1-2/+39
It has been observed that sometimes disabling the dc6 fails and dc6 state pops back up, brief moment after disabling. This has to be dmc save/restore timing issue or other bug in the way dc states are handled. Try to work around this issue as we don't have firmware fix yet available. Verify that the value we wrote for the dmc sticks, and also enforce it by rewriting it, if it didn't. v2: Zero rereads on rewrite for extra paranoia (Imre) Testcase: kms_flip/basic-flip-vs-dpms References: https://bugs.freedesktop.org/show_bug.cgi?id=93768 Cc: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Imre Deak <imre.deak@intel.com> Signed-off-by: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by: Imre Deak <imre.deak@intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455811089-27884-1-git-send-email-mika.kuoppala@intel.com
2016-02-22drm/i915/gen9: Check for DC state mismatchPatrik Jakobsson3-0/+11
The DMC can incorrectly run off and allow DC states on it's own. We don't know the root-cause for this yet but this patch makes it more visible. Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com> Signed-off-by: Patrik Jakobsson <patrik.jakobsson@linux.intel.com> Signed-off-by: Imre Deak <imre.deak@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455808874-22089-2-git-send-email-mika.kuoppala@intel.com
2016-02-19drm/i915/fbc: enable FBC by default on HSW and BDWPaulo Zanoni1-1/+3
These platforms should be fine now. FBC can allow very significant power savings for screen-on idle systems, but it is worth mentioning that a lot of people won't get significant power savings by enabling this feature because they may have something else preventing the system from getting into the deepest sleep states. Examples may include a hungry wifi device or a max_performance SATA link power management policy. You can check your PC state residencies on the powertop "Idle stats" tab. I recommend trying to run "sudo powertop --auto-tune" and then seeing if the residencies improve. Oh, and in case you - the person reading this commit message - found this commit through git bisect, please do the following: - Check your dmesg and see if there are error messages mentioning underruns around the time your problem started happening. - Download intel-gpu-tools, compile it, and run: $ sudo ./tests/kms_frontbuffer_tracking --run-subtest '*fbc-*' 2>&1 | tee fbc.txt Then send us the fbc.txt file, especially if you get a failure. This will really maximize your chances of getting the bug fixed quickly. - Try to find a reliable way to reproduce the problem, and tell us. - Boot with drm.debug=0xe, reproduce the problem, then send us the dmesg file. v2: Don't enable by default on SKL. Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Link: http://patchwork.freedesktop.org/patch/msgid/1455655643-2535-1-git-send-email-paulo.r.zanoni@intel.com
2016-02-19drm/i915: drop unused i915.disable_vtd_wa module parameterJani Nikula2-5/+0
This is a manual revert of commit 7a10dfa638be26669f0987b6a21a65e6b39356b2 Author: Daniel Vetter <daniel.vetter@ffwll.ch> Date: Tue Apr 1 09:33:47 2014 +0200 drm/i915: Add debug module option for VTd validation as no users have appeared. Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch> Signed-off-by: Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/1455621493-6865-2-git-send-email-jani.nikula@intel.com
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-27 07:00:26 +0000