The short pulse handler checks if channel equalization is okay and
goes onto retrain a link if there are active MST links. This retraining
path is not meant for new MST connections, but due to a bug elsewhere, if
active_mst_links is < 0 the boolean check for active_mst_links passes and
we proceed to retrain a new link. This results in a sequence of failed link
training attempts, most likely due to the hardware not setup for link
training at that point i.e., missing the DDI pre_enable sequence.
[ 80.301272] [drm:intel_dp_check_mst_status] channel EQ not ok, retraining
[ 80.301312] [drm:intel_ddi_prepare_link_retrain] *ERROR* Timeout waiting for DDI BUF C idle bit
The above error gives us a hint something went wrong before link
training started.
Check for a positive value of active_mst_links and throw in a warning for
invalid active_mst_links as debug aid.
Cc: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Tested-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180718171943.3246-1-dhinakaran.pandiyan@intel.com
On GLK NUC platforms the HDMI retiming buffer needs additional disabled
time to correctly sync to a faster incoming signal.
When measured on a scope the highspeed lines of the HDMI clock turn off
for ~400uS during a normal resolution change. The HDMI retimer on the
GLK NUC appears to require at least a full frame of quiet time before a
new faster clock can be correctly sync'd. Wait 100ms due to msleep
inaccuracies while waiting for a completed frame. Add a quirk to the
driver for GLK boards that use ITE66317 HDMI retimers.
V2: Add more devices to the quirk list
V3: Delay increased to 100ms, check to confirm crtc type is HDMI.
V4: crtc type check extended to include _DDI and whitespace fixes
v5: Fix white spaces, remove the macro for delay. Revert the crtc type
check introduced in v4.
Cc: Imre Deak <imre.deak@intel.com>
Cc: <stable@vger.kernel.org> # v4.14+
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105887
Signed-off-by: Clint Taylor <clinton.a.taylor@intel.com>
Tested-by: Daniel Scheller <d.scheller.oss@gmail.com>
Signed-off-by: Radhakrishna Sripada <radhakrishna.sripada@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180710200205.1478-1-radhakrishna.sripada@intel.com
(cherry picked from commit 90c3e21987)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
This sequence is used to setup voltage swing before enabling MG PHY DDI
as well as for changing the voltage during DisplayPort Link training.
For ICL, there are two types of DDIs. This sequence needs to be used
for MG PHY DDI which is ports C-F.
v6 (From Manasi):
* Add programming for MG_CLKHUB and MG_TX_DCC as per the
spec updates
v5 (from Paulo):
* Checkpatch.
v4 (from Paulo):
* Fix bogus error message
* Fix copy+paste bugs (missing s/TX1/TX2/ after copy+paste)
* Use the new mask names
* Stay under 80 columns
* Add some blank lines
v3:
* Clear the regs before writing (Paulo)
v2:
* Rename to MG PHY in the function def (Jani Nikula)
* Rebase on top of new revision of other patches in series
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1530225344-20373-2-git-send-email-manasi.d.navare@intel.com
This patch adds the remaining register definitions and bit fields
required for MG PHy DDI buffer initializations and voltage
swing programming for MG PHy DDI ports.
While at it this patch also fixes the naming for previously defined
MG PHY registers in original commit id (c92f47b5ec "drm/i915/icl:
Add register defs for voltage swing sequences for MG PHY DDI").
Since the MG PHY registers are first defined in ICL platform, there
is no need for _ICL prefix.
v4 (from Paulo): add two white spaces to CRI_CALCINIT too.
v3:
* Fix register names, add spaces for MASK defines, correct the order
of #defines (Paulo)
v2:
* Change the MG_TX_DRVCTL registers names to match the spec (Anusha)
Cc: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531510993-6606-1-git-send-email-manasi.d.navare@intel.com
On Sandybridge, we need a workaround to wait for the CPU thread to wake
up before we are sure that we have enabled the GT power well. However,
we do see the errors being reported and failed reads returning spurious
results. To try and capture more details as it fails, promote the error
into a WARN so we grab the stacktrace, and to try and reduce the
frequency of error increase the timeout from 500us to 5ms.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180720111102.11549-1-chris@chris-wilson.co.uk
Limit the link training clock recovery loop to 10 attempts at
LANEx_CR_DONE per DP 1.4 spec section 3.5.1.2.2 and 80 attempts for
pre-DP 1.4 (4 voltage levels x 4 preemphasis levels x
x 5 identical voltages tries). Some faulty USB-C MST hubs can
cause us to get stuck in this loop indefinitely requesting something
like:
voltage swing: 0, pre-emphasis level: 2
voltage swing: 1, pre-emphasis level: 2
voltage swing: 0, pre-emphasis level: 3
over and over so max_vswing would never be reached,
drm_dp_clock_recovery_ok() would never return true and voltage_tries
would always get reset to 1. The driver sends those values to the hub
but the hub keeps requesting new values every time.
Changes in v2:
- updated commit message (DK, Manasi)
- defined DP_DP14_MAX_CR_TRIES (Marc)
- made the loop iterate for max 10 times (Rodrigo, Marc)
Changes in v3:
- changed error message to use DP_DP14_MAX_CR_TRIES
Changes in v4:
- Updated the title to reflect the change
- Updated the commit message
- Added 80 attempts for pre-DP 1.4 devices
Changes in v5:
- Removed DP_DP14_MAX_CR_TRIES from drm
v6: Updated comment to match kernel style (Rodrigo)
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Marc Herbert <marc.herbert@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Nathan Ciobanu <nathan.d.ciobanu@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180720214413.29506-1-rodrigo.vivi@intel.com
We need a backmerge to get DP_DPCD_REV_14 before we push other
i915 changes to dinq that could break compilation.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Not all chipsets have an internal buffer delaying the visibility of
writes via the GGTT being visible by other physical paths, but we use a
very heavy workaround for all. We only need to apply that workarounds to
the chipsets we know suffer from the delay and the resulting coherency
issue.
Similarly, the same inconsistent coherency fouls up our ABI promise that
a write into a mmap_gtt is immediately visible to others. Since the HW
has made that a lie, let userspace know when that contract is broken.
(Not that userspace would want to use mmap_gtt on those chipsets for
other performance reasons...)
Testcase: igt/drv_selftest/live_coherency
Testcase: igt/gem_mmap_gtt/coherency
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100587
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tomasz Lis <tomasz.lis@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180720101910.11153-1-chris@chris-wilson.co.uk
On GEM side:
- GuC related fixes (Chris, Michal)
- GTT read-only pages support (Jon, Chris)
- More selftests fixes (Chris)
- More GPU reset improvements (Chris)
- Flush caches after GGTT writes (Chris)
- Handle recursive shrinker for vma->last_active allocation (Chris)
- Other execlists fixes (Chris)
On Display side:
- GLK HDMI fix (Clint)
- Rework and cleanup around HPD pin (Ville)
- Preparation work for Display Stream Compression support coming on ICL (Anusha)
- Nuke LVDS lid notification (Ville)
- Assume eDP is always connected (Ville)
- Kill intel panel detection (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Fri 20 Jul 2018 01:51:45 AM AEST
# gpg: using RSA key FA625F640EEB13CA
# gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>"
# gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA
# Conflicts:
# drivers/gpu/drm/i915/intel_lrc.c
Link: https://patchwork.freedesktop.org/patch/msgid/20180719171257.GA12199@intel.com
drm-misc-next for 4.19:
Core Changes:
- add support for DisplayPort CEC-Tunneling-over-AUX (Hans Verkuil)
- more doc updates (Daniel Vetter)
- fourcc: Add is_yuv field to drm_format_info (Ayan Kumar Halder)
- dma-buf: correctly place BUG_ON (Michel Dänzer)
Driver Changes:
- more vkms support(Rodrigo Siqueira)
- many fixes and small improments to all drivers
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180718200826.GA20165@juma
On KBL, WHL RVPs, booting up with an external display connected, triggers
below warning, when the BiOS brings up the external display too.
This warning is not seen during hotplug.
[ 3.615226] ------------[ cut here ]------------
[ 3.619829] plane 1A assertion failure (expected on, current off)
[ 3.632039] WARNING: CPU: 2 PID: 354 at drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
[ 3.633920] iwlwifi 0000:00:14.3: loaded firmware version 38.c0e03d94.0 op_mode iwlmvm
[ 3.647157] Modules linked in: iwlwifi cfg80211 btusb btrtl btbcm btintel bluetooth ecdh_generic
[ 3.647163] CPU: 2 PID: 354 Comm: frecon Not tainted 4.17.0-rc7-50176-g655af12d39c2 #3
[ 3.647165] Hardware name: Intel Corporation CoffeeLake Client Platform/WhiskeyLake U DDR4 ERB, BIOS CNLSFWR1.R00.X140.B00.1804040304 04/04/2018
[ 3.684509] RIP: 0010:assert_plane+0x71/0xbb
[ 3.764451] Call Trace:
[ 3.766888] intel_atomic_commit_tail+0xa97/0xb77
[ 3.771569] intel_atomic_commit+0x26a/0x279
[ 3.771572] drm_atomic_helper_set_config+0x5c/0x76
[ 3.780670] __drm_mode_set_config_internal+0x66/0x109
[ 3.780672] drm_mode_setcrtc+0x4c9/0x5cc
[ 3.780674] ? drm_mode_getcrtc+0x162/0x162
[ 3.789774] ? drm_mode_getcrtc+0x162/0x162
[ 3.798108] drm_ioctl_kernel+0x8d/0xe4
[ 3.801926] drm_ioctl+0x27d/0x368
[ 3.805311] ? drm_mode_getcrtc+0x162/0x162
[ 3.805314] ? selinux_file_ioctl+0x14e/0x199
[ 3.805317] vfs_ioctl+0x21/0x2f
[ 3.813812] do_vfs_ioctl+0x491/0x4b4
[ 3.813813] ? security_file_ioctl+0x37/0x4b
[ 3.813816] ksys_ioctl+0x55/0x75
[ 3.820672] __x64_sys_ioctl+0x1a/0x1e
[ 3.820674] do_syscall_64+0x51/0x5f
[ 3.820678] entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 3.828221] RIP: 0033:0x7b5e04953967
[ 3.835504] RSP: 002b:00007fff2eafb6f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
[ 3.835505] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007b5e04953967
[ 3.835505] RDX: 00007fff2eafb730 RSI: 00000000c06864a2 RDI: 000000000000000f
[ 3.835506] RBP: 00007fff2eafb720 R08: 0000000000000000 R09: 0000000000000000
[ 3.835507] R10: 0000000000000070 R11: 0000000000000246 R12: 000000000000000f
[ 3.879988] R13: 000056bc9dd7d210 R14: 00007fff2eafb730 R15: 00000000c06864a2
[ 3.887081] Code: 48 c7 c7 06 71 a5 be 84 c0 48 c7 c2 06 fd a3 be 48 89 f9 48 0f 44 ca 84 db 48 0f 45 d7 48 c7 c7 df d3 a4 be 31 c0 e8 af a0 c0 ff <0f> 0b eb 2b 48 c7 c7 06 fd a3 be 84 c0 48 c7 c2 06 71 a5 be 48
[ 3.905845] WARNING: CPU: 2 PID: 354 at drivers/gpu/drm/i915/intel_display.c:1294 assert_plane+0x71/0xbb
[ 3.920964] ---[ end trace dac692f4ac46391a ]---
The warning is seen when mode_setcrtc() is called for pipeB
during bootup and before we get a mode_setcrtc() for pipeA,
while doing update_crtcs() in intel_atomic_commit_tail().
Now since, plane1A is still active after commit, update_crtcs()
is done for pipeA and eventually update_plane() for plane1A.
intel_plane_state->ctl for plane1A is not updated since set_modecrtc() is
called for pipeB. So intel_plane_state->ctl for plane 1A will be 0x0.
So doing an update_plane() for plane1A, will result in clearing
PLANE_CTL_ENABLE bit, and hence the warning.
To fix this warning, force all active planes to recompute their states
in probe.
Changes in v8:
- Actually add Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Changes in v7:
- Move call to intel_initial_commit() after sanitize_watermarks()
Otherwise the plane update will still consult potentially bogus
watermarks we read out from the hardware. (Ville)
- Carry Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
from v6
Changes in v6:
- Handle EDEADLK for drm_atomic_get_crtc_state() and
drm_atomic_add_affected_planes()
- Remove optimization of calling intel_initial_commit()
only when there is more than one active pipe in probe.
- Avoid using intel_ types.
Changes in v5:
- Drop drm_modeset_lock_all_ctx() since locks will be taken later.
Changes in v4:
- Handle locking in intel_initial_commit()
- Move the for loop inside intel_initial_commit() so that
drm_atomic_commit() is called only once
- Call intel_initial_commit() only for more than one active crtc on boot.
- Save the return value of intel_initial_commit() and print a message in
case of an error
Changes in v3:
- Add comments
Changes in v2:
- Force all planes to recompute their states.(Ville Syrjälä)
- Update the commit message
Signed-off-by: Azhar Shaikh <azhar.shaikh@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1530902250-44583-1-git-send-email-azhar.shaikh@intel.com
There's a race between idling the engine and finishing off the last
tasklet (as we may kick the tasklets after declaring an individual
engine idle). However, since we do not need to access the device until
we try to submit to the ELSP register (processing the CSB just requires
normal CPU access to the HWSP, and when idle we should not need to
submit!) we can defer the assertion unto that point. The assertion is
still useful as it does verify that we do hold the longterm GT wakeref
taken from request allocation until request completion.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
Fixes: 9512f985c3 ("drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719075029.28643-1-chris@chris-wilson.co.uk
We make a decision at module load whether to use the GuC backend or not,
but lose that setup across set-wedge. Currently, the guc doesn't
override the engine->set_default_submission hook letting execlists sneak
back in temporarily on unwedging leading to an unbalanced park/unpark.
v2: Remove comment about switching back temporarily to execlists on
guc_submission_disable(). We currently only call disable on shutdown,
and plan to also call disable before suspend and reset, in which case we
will either restore guc submission or mark the driver as wedged, making
the reset back to execlists pointless.
v3: Move reset.prepare across
Fixes: 63572937ce ("drm/i915/execlists: Flush pending preemption events during reset")
Testcase: igt/drv_module_reload/basic-reload-inject
Testcase: igt/gem_eio
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717202932.1423-1-chris@chris-wilson.co.uk
It was originally introduced following the VESA spec in order to validate PSR.
However we found so many issues around sink_crc that instead of helping PSR
development it only brought another layer of trouble to the table.
So, sink_crc has been a black whole for us in question of time, effort and hope.
First of the problems is that HW statement is clear: "Do not attempt to use
aux communication with PSR enabled". So the main reason behind sink_crc is
already compromised.
For a while we had hope on the aux-mutex could workaround this problem on SKL+
platforms, but that mutex was not reliable, not tested,
and we shouldn't use according to HW engineers.
Also, nor source, nor sink designed and implemented the sink_crc to be used like
we are trying to use here.
Well, the sink side of things is also apparently not prepared for this
case. Each panel that we tried seemed to have a different behavior with same
code and same source.
So, for all the time we lost on trying to ducktape all these different issues
I believe it is now time to move PSR to a more reliable validation.
Maybe not a perfect one as we dreamed for this sink_crc, but at least more
reliable.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705192528.30515-1-rodrigo.vivi@intel.com
Higlights here goes to many PSR fixes and improvements; to the Ice lake work with
power well support and begin of DSI support addition. Also there were many improvements
on execlists and interrupts for minimal latency on command submission; and many fixes
on selftests, mostly caught by our CI.
General driver:
- Clean-up on aux irq (Lucas)
- Mark expected switch fall-through for dealing with static analysis tools (Gustavo)
Gem:
- Different fixes for GuC (Chris, Anusha, Michal)
- Avoid self-relocation BIAS if no relocation (Chris)
- Improve debugging cases in on EINVAL return and vma allocation (Chris)
- Fixes and improvements on context destroying and freeing (Chris)
- Wait for engines to idle before retiring (Chris)
- Many improvements on execlists and interrupts for minimal latency on command submission (Chris)
- Many fixes in selftests, specially on cases highlighted on CI (Chris)
- Other fixes and improvements around GGTT (Chris)
- Prevent background reaping of active objects (Chris)
Display:
- Parallel modeset cleanup to fix driver reset (Chris)
- Get AUX power domain for DP main link (Imre)
- Clean-up on PSR unused func pointers (Rodrigo)
- Many PSR/PSR2 fixes and improvements (DK, Jose, Tarun)
- Add a PSR1 live status (Vathsala)
- Replace old drm_*_{un/reference} with put,get functions (Thomas)
- FBC fixes (Maarten)
- Abstract and document the usage of picking macros (Jani)
- Remove unnecessary check for unsupported modifiers for NV12. (DK)
- Interrupt fixes for display (Ville)
- Clean up on sdvo code (Ville)
- Clean up on current DSI code (Jani)
- Remove support for legacy debugfs crc interface (Maarten)
- Simplify get_encoder_power_domains (Imre)
Icelake:
- MG PLL fixes (Imre)
- Add hw workaround for alpha blending (Vandita)
- Add power well support (Imre)
- Add Interrupt Support (Anusha)
- Start to add support for DSI on Ice Lake (Madhav)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Tue 10 Jul 2018 08:41:37 AM AEST
# gpg: using RSA key FA625F640EEB13CA
# gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>"
# gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA
Link: https://patchwork.freedesktop.org/patch/msgid/20180710234349.GA16562@intel.com
This is the final step for more generic support of DRM audio
component. The generic audio component code is now moved to its own
file, and the symbols are renamed from snd_hac_i915_* to
snd_hdac_acomp_*, respectively. The generic code is enabled via the
new kconfig, CONFIG_SND_HDA_COMPONENT, while CONFIG_SND_HDA_I915 is
kept as the super-class.
Along with the split, three new callbacks are added to audio_ops:
pin2port is for providing the conversion between the pin number and
the widget id, and master_bind/master_unbin are called at binding /
unbinding the master component, respectively. All these are optional,
but used in i915 implementation and also other later implementations.
A note about the new snd_hdac_acomp_init() function: there is a slight
difference between this and the old snd_hdac_i915_init(). The latter
(still) synchronizes with the master component binding, i.e. it
assures that the relevant DRM component gets bound when it returns, or
gives a negative error. Meanwhile the new function doesn't
synchronize but just leaves as is. It's the responsibility by the
caller's side to synchronize, or the caller may accept the
asynchronous binding on the fly.
v1->v2: Fix missing NULL check in master_bind/unbind
Signed-off-by: Takashi Iwai <tiwai@suse.de>
For allowing other drivers to use the DRM audio component, rename the
i915_audio_component_* with drm_audio_component_*, and split the
generic part into drm_audio_component.h. The i915 specific stuff
remains in struct i915_audio_component, which contains
drm_audio_component as the base.
The license of drm_audio_component.h is kept to MIT as same as the the
original i915_component.h.
This is a preliminary change for further development, and no
functional changes by this patch itself, merely code-split and
renames.
v1->v2: Use SPDX for drm_audio_component.h, fix remaining i915
argument in drm_audio_component.h
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
Our I915g (early gen3, the oldest machine we have in the farm) is still
reporting occasional incoherency performing the following operations:
1) write through GGTT (indirect write into memory)
2) write through either CPU or WC (direct write into memory)
3) read from GGTT (indirect read)
Instead of reporting the value from (2), the read from GGTT reports the
earlier value written via the GGTT. We have made sure that the writes are
flushed from the CPU (commit 3a32497f0d ("drm/i915/selftests: Provide
full mb() around clflush") and commit add00e6d89 ("drm/i915: Flush the
WCB following a WC write")), but still see the error, just less
frequently. The only remaining cache that might be affected here is a
chipset cache, so flush that as well.
Testcase: igt/drv_selftest/live_coherency #gdg
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717092655.28417-1-chris@chris-wilson.co.uk
On reset/wedging, we cancel all pending replies from the HW and we also
want to cancel an outstanding preemption event. Since we use the same
function to cancel the pending replies for reset and for a preemption
event, we can simply clear the active tracking for all.
v2: Keep execlists_user_end() markup for wedging
v3: Move assignment to inline to hide the bare assignment.
Fixes: 60a9432454 ("drm/i915/execlists: Drop clear_gtiir() on GPU reset")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180716125424.5715-1-chris@chris-wilson.co.uk
