- 15 Nov, 2019 3 commits
-
-
Jani Nikula authored
Backmerge to get dfce9025 ("Backmerge i915 security patches from commit 'ea0b163b' into drm-next") and thus 100d46bd ("Merge Intel Gen8/Gen9 graphics fixes from Jon Bloomfield."). Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
git://people.freedesktop.org/~thomash/linuxDave Airlie authored
Two minor cleanups / fixes for -next. Signed-off-by:
Dave Airlie <airlied@redhat.com> From: =?UTF-8?q?Thomas=20Hellstr=C3=B6m=20=28VMware=29?= Link: https://patchwork.freedesktop.org/patch/msgid/20191114131703.8607-1-thomas_os@shipmail.org
-
Dave Airlie authored
Merge tag 'drm-intel-next-fixes-2019-11-14' of git://anongit.freedesktop.org/drm/drm-intel into drm-next - PMU "Frequency" is reported as accumulated cycles - Avoid OOPS in dumb_create IOCTL when no CRTCs - Mitigation for userptr put_pages deadlock with trylock_page - Fix to avoid freeing heartbeat request too early - Fix LRC coherency issue - Fix Bugzilla #112212: Avoid screen corruption on MST - Error path fix to unlock context on failed context VM SETPARAM - Always consider holding preemption a privileged op in perf/OA - Preload LUTs if the hw isn't currently using them to avoid color flash on VLV/CHV - Protect context while grabbing its name for the request - Don't resize aliasing ppGTT size - Smaller fixes picked by tooling Signed-off-by:
-
- 14 Nov, 2019 15 commits
-
-
Daniele Ceraolo Spurio authored
With the new interrupt re-partitioning in Gen11, GuC controls by itself the interrupts it receives, so steering bits and registers have been defeatured. Being this the case, when the GuC is in control of submissions we won't know what to do with the ctx switch interrupt in the driver, so disable it. v2 (Daniele): replace the gen9 paths instead of keeping gen9 and gen11 functions since we won't support guc submission on any pre-gen11 platform. Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: John Harrison <John.C.Harrison@Intel.com> Cc: Matthew Brost <matthew.brost@intel.com> Reviewed-by:
John Harrison <John.C.Harrison@Intel.com> Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Link: https://patchwork.freedesktop.org/patch/msgid/20191105225321.26642-1-daniele.ceraolospurio@intel.com
-
Imre Deak authored
The workaround to disable coarse power gating is still needed on SKL GT3/GT4 machines and since the RC6 context corruption was discovered by the hardware team also on all GEN9 machines. Restore applying the workaround. Fixes: c1132367 ("drm/i915: Extract GT render sleep (rc6) management") Testcase: igt/intel_gt_pm_late_selftests/live_rc6_ctx Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Andi Shyti <andi.shyti@intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Ville Syrjälä authored
HDMI_PICTURE_ASPECT_NONE is zero and the connector state is kzalloc()'d so no need to initialize conn_state->picture_aspect_ratio with it. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190620142639.17518-6-ville.syrjala@linux.intel.comReviewed-by:
Uma Shankar <uma.shankar@intel.com>
-
Ville Syrjälä authored
HDMI_PICTURE_ASPECT_NONE means "Automatic" so when the user has that selected we should keep whatever aspect ratio the mode already has. Also no point in checking for connector->is_hdmi in the SDVO code since we only attach the property to HDMI connectors. Cc: Ilia Mirkin <imirkin@alum.mit.edu> Signed-off-by:
-
Chris Wilson authored
As we want to be able to run inside atomic context for retiring the i915_active, and we are no longer allowed to abuse mutex_trylock, split the tree management portion of i915_active.mutex into an irq-safe spinlock. References: a0855d24 ("locking/mutex: Complain upon mutex API misuse in IRQ contexts") References: https://bugs.freedesktop.org/show_bug.cgi?id=111626 Fixes: 274cbf20 ("drm/i915: Push the i915_active.retire into a worker") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191114172535.1116-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Probe the mocs registers for new contexts and across GPU resets. Similar to intel_workarounds, we have tables of what register values we expect to see, so verify that user contexts are affected by them. In the future, we should add tests similar to intel_sseu to cover dynamic reconfigurations. Signed-off-by:
Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-4-chris@chris-wilson.co.uk
-
Chris Wilson authored
We repeatedly (and more so in future) use the same looping construct over the mocs definition table to setup the register state. Refactor the loop construct into a reusable macro. add/remove: 2/1 grow/shrink: 1/2 up/down: 113/-330 (-217) Function old new delta intel_mocs_init_engine.cold - 71 +71 offset - 28 +28 __func__ 17273 17287 +14 intel_mocs_init 143 113 -30 mocs_register.isra 91 - -91 intel_mocs_init_engine 503 294 -209 Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112223600.30993-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we always run new platforms through CI, we only need the debug code compiled in during CI runs. Signed-off-by:
-
Chris Wilson authored
Be consistent in our mocs setup on Tigerlake and set the unused control value to follow the PTE entry as we previously have done. The unused values are beyond the defines of the ABI, the consistency simplifies our checking. Signed-off-by:
-
Chris Wilson authored
fbdev uses the physical address of our framebuffer for its fb_mmap() routine. While we need to adapt this address for the new io BAR, we have to fix v5.4 first! The simplest fix is to restore the smem back to v5.3 and we will then probably have to implement our fbops->fb_mmap() callback to handle local memory. Reported-by:
Neil MacLeod <freedesktop@nmacleod.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112256 Fixes: 5f889b9a ("drm/i915: Disregard drm_mode_config.fb_base") Signed-off-by:
-
YueHaibing authored
drivers/gpu/drm/vmwgfx/vmwgfx_surface.c:339:22: warning: variable srf set but not used [-Wunused-but-set-variable] 'srf' is never used, so can be removed. Signed-off-by:
YueHaibing <yuehaibing@huawei.com> Reviewed-by:
Thomas Hellstrom <thellstrom@vmware.com>
-
Thomas Hellstrom authored
Drivers like vmwgfx may want to test whether the dma page pool is present or not. Since it's activated by default by TTM if compiled-in, define a hidden configuration option that the driver can test for. Cc: Christian König <christian.koenig@amd.com> Signed-off-by:
Christian König <christian.koenig@amd.com>
-
Lionel Landwerlin authored
I'm observing incoherence metric values, changing from run to run. It appears the patches introducing noa wait & reconfiguration from command stream switched places in the series multiple times during the review. This lead to the dependency of one onto the order to go missing... Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 15d0ace1 ("drm/i915/perf: execute OA configuration from command stream") Reviewed-by:
-
Dave Airlie authored
This backmerges the branch that ended up in Linus' tree. It removes all the changes for the rc6 patches from Linus' tree in favour of a patch that is based on a large refactor that occured. Otherwise it all looks good. Signed-off-by: -
Imre Deak authored
In some circumstances the RC6 context can get corrupted. We can detect this and take the required action, that is disable RC6 and runtime PM. The HW recovers from the corrupted state after a system suspend/resume cycle, so detect the recovery and re-enable RC6 and runtime PM. v2: rebase (Mika) v3: - Move intel_suspend_gt_powersave() to the end of the GEM suspend sequence. - Add commit message. v4: - Rebased on intel_uncore_forcewake_put(i915->uncore, ...) API change. v5: - Rebased on latest upstream gt_pm refactoring. v6: - s/i915_rc6_/intel_rc6_/ - Don't return a value from i915_rc6_ctx_wa_check(). v7: - Rebased on latest gt rc6 refactoring. Signed-off-by:
-
- 13 Nov, 2019 19 commits
-
-
Radhakrishna Sripada authored
Extend disabling SAMPLER_STATE prefetch workaround to gen12. v2: Limit the WA to TGL A0 and update the WA no(Chris) BSpec: 52890 Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Reviewed-by:
-
Dave Airlie authored
This is a pretty simple improvement that allows to find encoder as the one and only (ARC PGU doesn't support more than one) endpoint instead of using non-standard "encoder-slave" property. Signed-off-by:
-
Bruce Chang authored
io_mapping_map_atomic/kmap_atomic are occasionally taken in error capture (if there is no aperture preallocated for the use of error capture), but the error capture and compression routines are now run in normal context: <3> [113.316247] BUG: sleeping function called from invalid context at mm/page_alloc.c:4653 <3> [113.318190] in_atomic(): 1, irqs_disabled(): 0, pid: 678, name: debugfs_test <4> [113.319900] no locks held by debugfs_test/678. <3> [113.321002] Preemption disabled at: <4> [113.321130] [<ffffffffa02506d4>] i915_error_object_create+0x494/0x610 [i915] <4> [113.327259] Call Trace: <4> [113.327871] dump_stack+0x67/0x9b <4> [113.328683] ___might_sleep+0x167/0x250 <4> [113.329618] __alloc_pages_nodemask+0x26b/0x1110 <4> [113.334614] pool_alloc.constprop.19+0x14/0x60 [i915] <4> [113.335951] compress_page+0x7c/0x100 [i915] <4> [113.337110] i915_error_object_create+0x4bd/0x610 [i915] <4> [113.338515] i915_capture_gpu_state+0x384/0x1680 [i915] However, it is not a good idea to run the slow compression inside atomic context, so we choose not to. Fixes: 895d8ebe ("drm/i915: error capture with no ggtt slot") Signed-off-by:
Bruce Chang <yu.bruce.chang@intel.com> Reviewed-by:
Brian Welty <brian.welty@intel.com> Reviewed-by:
-
Dave Airlie authored
Merge tag 'drm-misc-next-fixes-2019-11-13' of git://anongit.freedesktop.org/drm/drm-misc into drm-next - Fix memory leak in gpu debugfs node's release (Johan) Cc: Johan Hovold <johan@kernel.org> Signed-off-by:
-
git://people.freedesktop.org/~agd5f/linuxDave Airlie authored
drm-next-5.5-2019-11-08: amdgpu: - Enable VCN dynamic powergating on RV/RV2 - Fixes for Navi14 - Misc Navi fixes - Fix MSI-X tear down - Misc Arturus fixes - Fix xgmi powerstate handling - Documenation fixes scheduler: - Fix static code checker warning - Fix possible thread reactivation while thread is stopped - Avoid cleanup if thread is parked radeon: - SI dpm fix ported from amdgpu Signed-off-by:
-
Lucas De Marchi authored
Tiger Lake supports HDMI on port A. For other platforms we ignore what the VBT says regarding HDMI to workaround broken VBTs, see commit 2ba7d7e0 ("drm/i915/bios: ignore HDMI on port A"). Make this apply gen12+ so they inherit the TGL behavior. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113021935.41547-1-lucas.demarchi@intel.com
-
José Roberto de Souza authored
This register was being enabled after enable TRANS_DDI_FUNC_CTL and PIPECONF/TRANS_CONF while BSpec states that it should be set when enabling TRANS_DDI_FUNC_CTL. BSpec: 49190 BSpec: 22243 Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191107214559.77087-3-jose.souza@intel.com
-
José Roberto de Souza authored
Adding pipe D support to DSI transcoder. Not adding it for EDP transcoder code paths as only TGL has 4 pipes and it do not have a EDP transcoder. Reviewed-by:
-
José Roberto de Souza authored
TRANS_DDI_MST_TRANSPORT_SELECT is 2 bits wide not 3, it was taking one bit from EDP/DSI Input Select. Fixes: b3545e08 ("drm/i915/tgl: add support to one DP-MST stream") Cc: Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
-
Johan Hovold authored
If a process is interrupted while accessing the "gpu" debugfs file and the drm device struct_mutex is contended, release() could return early and fail to free related resources. Note that the return value from release() is ignored. Fixes: 4f776f45 ("drm/msm/gpu: Convert the GPU show function to use the GPU state") Cc: stable <stable@vger.kernel.org> # 4.18 Cc: Jordan Crouse <jcrouse@codeaurora.org> Cc: Rob Clark <robdclark@gmail.com> Reviewed-by:
Rob Clark <robdclark@gmail.com> Signed-off-by:
Johan Hovold <johan@kernel.org> Signed-off-by:
Sean Paul <seanpaul@chromium.org> Link: https://patchwork.freedesktop.org/patch/msgid/20191010131333.23635-2-johan@kernel.org
-
Dave Airlie authored
We have the i915 security fixes to backmerge, but first let's clear the decks for other drivers to avoid a bigger mess. Signed-off-by: -
Lucas De Marchi authored
When we call intel_bios_is_valid_vbt(), size may not actually be the size of the VBT, but rather the size of the blob the VBT is contained in. For example, when mapping the PCI oprom, size will be the entire oprom size. We don't want to read beyond what is reported to be the VBT. So make sure we vbt->vbt_size makes sense and use that for the latter checks. v2: check for vbt_size after checking for vbt signature and give it a more meaningful error message (from Jani) Signed-off-by:
-
Lucas De Marchi authored
oprom is actually a better name to use when using pci_map_rom(). "bios" is way too generic and confusing. Signed-off-by:
-
Chris Wilson authored
Still the saga of the hsw live_blt incoherency continues. While it did seem that the invalidate before the breadcrumb had improved the mtbf, nevertheless live_blt still failed. Mika's next idea was to pull the invalidate-stall into the breadcrumb write itself. References: 860afa08 ("drm/i915/gt: Flush gen7 even harder") References: https://bugs.freedesktop.org/show_bug.cgi?id=112147 Testcase: igt/i915_selftest/live_blt Signed-off-by:
-
Matt Roper authored
The bspec was just updated with a minor correction to entry 61 (it shouldn't have had the SCF bit set). v2: - Add a MOCS_ENTRY_UNUSED() and use it to declare the explicitly-reserved MOCS entries. (Lucas) - Move the warning suppression from the Makefile to a #pragma that only affects the TGL table. (Lucas) v3: - Entries 16 and 17 are identical to ICL now, so no need to explicitly adjust them (or mess with compiler warning overrides). Bspec: 45101 Fixes: 2ddf9921 ("drm/i915/tgl: Define MOCS entries for Tigerlake") Cc: Tomasz Lis <tomasz.lis@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Francisco Jerez <francisco.jerez.plata@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Signed-off-by:
Francisco Jerez <currojerez@riseup.net> Reviewed-by:
Tomasz Lis <tomasz.lis@intel.com>
-
Matt Roper authored
This reverts commit f4071997. These extra EHL entries won't behave as expected without a bit more work on the kernel side so let's drop them until that kernel work has had a chance to land. Userspace trying to use these new entries won't get the advantage of the new functionality these entries are meant to provide, but at least it won't misbehave. When we do add these back in the future, we'll probably want to explicitly use separate tables for ICL and EHL so that userspace software that mistakenly uses these entries (which are undefined on ICL) sees the same behavior it sees with all the other undefined entries. Cc: Francisco Jerez <francisco.jerez.plata@intel.com> Cc: Jon Bloomfield <jon.bloomfield@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: <stable@vger.kernel.org> # v5.3+ Fixes: f4071997 ("drm/i915/ehl: Update MOCS table for EHL") Signed-off-by:
-
Gwan-gyeong Mun authored
The setting of MSA is done by the DDI .pre_enable() hook. And when we are using MST, the MSA is only set to first mst stream by calling of DDI .pre_eanble() hook. It raies issues to non-first mst streams. Wrong MSA or missed MSA packets might show scrambled screen or wrong screen. This splits a setting of MSA to MST and SST cases. And In the MST case it will call a setting of MSA after an allocating of Virtual Channel from MST encoder pre_enable callback. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112212 Fixes: 0c06fa15 ("drm/i915/dp: Add support of BT.2020 Colorimetry to DP MSA") Fixes: d4a415dc ("drm/i915: Fix MST oops due to MSA changes") Signed-off-by:
Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191106212636.502471-1-gwan-gyeong.mun@intel.comReviewed-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191113125241.20547-1-ville.syrjala@linux.intel.com
-
Imre Deak authored
According to internal documents I found for CMP PCHs the PCI ID 0xA3C1 belongs to a CMP-V chipset. Based on the same docs the programming of the PCH is compatible with that of KBP. Fix up my previous wrong assumption accordingly using the SPT programming which in turn is the basis for KBP. The original bug reporter verified that this is the correct PCH identification (the only way we'll program valid DDC pin-pair values to the GMBUS register) and the Windows team uses the same identification (that is using the KBP programming model for this PCH). I filed the necessary Bspec update requests (BSpec/33734). Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051 Fixes: 37c92dc3 ("drm/i915: Add new CNL PCH ID seen on a CML platform") Reported-and-tested-by:
Cyrus <cyrus.lien@canonical.com> Cc: Cyrus <cyrus.lien@canonical.com> Cc: Timo Aaltonen <tjaalton@ubuntu.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Chris Wilson authored
The gem_ctx_persistence/smoketest was detecting an odd coherency issue inside the LRC context image; that the address of the ring buffer did not match our associated struct intel_ring. As we set the address into the context image when we pin the ring buffer into place before the context is active, that leaves the question of where did it get overwritten. Either the HW context save occurred after our pin which would imply that our idle barriers are broken, or we overwrote the context image ourselves. It is only in reset_active() where we dabble inside the context image outside of a serialised path from schedule-out; but we could equally perform the operation inside schedule-in which is then fully serialised with the context pin -- and remains serialised by the engine pulse with kill_context(). (The only downside, aside from doing more work inside the engine->active.lock, was the plan to merge all the reset paths into doing their context scrubbing on schedule-out needs more thought.) Fixes: d12acee8 ("drm/i915/execlists: Cancel banned contexts on schedule-out") Testcase: igt/gem_ctx_persistence/smoketest Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191111133205.11590-3-chris@chris-wilson.co.uk (cherry picked from commit 31b61f0e) Signed-off-by:
-
- 12 Nov, 2019 3 commits
-
-
Lucas De Marchi authored
The warning should be just a warning. Where it is currently is wrong since we already registered the connector on drm, meaning it dies later on a NULL pointer deref if the VBT-overriding we have is removed. Move the warning up. Signed-off-by:
-
Chris Wilson authored
live_blt is still failing on hsw, showing the hallmark of incoherency. Since we are fairly certain that the interrupt is after the seqno is visible, the other possibility is that the seqno is before the writes to memory are flushed. Throw in an TLB invalidate before the breadcrumb as we are reasonably confident that forces a CS stall. References: f9228f76 ("drm/i915/gt: Try an extra flush on the Haswell blitter") References: https://bugs.freedesktop.org/show_bug.cgi?id=112147 Testcase: igt/i915_selftest/live_blt Signed-off-by:
-
Chris Wilson authored
drivers/gpu/drm/i915/gem/selftests/i915_gem_object_blt.c:453 igt_threaded_blt() error: uninitialized symbol 'file'. Fixes: 34485832 ("drm/i915/selftests: Exercise parallel blit operations on a single ctx") Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191112163643.3527-1-chris@chris-wilson.co.uk
-
