Age | Commit message (Collapse) | Author | Files | Lines |
|
The i915 DRM driver very cleverly used ascii85 encoding for their
GPU state file. Move the encode functions to a general header file to
support other drivers that might be interested in the same
functionality.
v4: Make the return value const char * as suggested by Chris Wilson
v3: Fix error_puts -> err_puts pointed out by the 01.org bot
v2: Update API to be cleaner for the caller as suggested by Chris Wilson
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jordan Crouse <jcrouse@codeaurora.org>
Signed-off-by: Rob Clark <robdclark@gmail.com>
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-next
On GEM side:
- GuC related fixes (Chris, Michal)
- GTT read-only pages support (Jon, Chris)
- More selftests fixes (Chris)
- More GPU reset improvements (Chris)
- Flush caches after GGTT writes (Chris)
- Handle recursive shrinker for vma->last_active allocation (Chris)
- Other execlists fixes (Chris)
On Display side:
- GLK HDMI fix (Clint)
- Rework and cleanup around HPD pin (Ville)
- Preparation work for Display Stream Compression support coming on ICL (Anusha)
- Nuke LVDS lid notification (Ville)
- Assume eDP is always connected (Ville)
- Kill intel panel detection (Ville)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Fri 20 Jul 2018 01:51:45 AM AEST
# gpg: using RSA key FA625F640EEB13CA
# gpg: Good signature from "Rodrigo Vivi <rodrigo.vivi@intel.com>"
# gpg: aka "Rodrigo Vivi <rodrigo.vivi@gmail.com>"
# gpg: WARNING: This key is not certified with a trusted signature!
# gpg: There is no indication that the signature belongs to the owner.
# Primary key fingerprint: 6D20 7068 EEDD 6509 1C2C E2A3 FA62 5F64 0EEB 13CA
# Conflicts:
# drivers/gpu/drm/i915/intel_lrc.c
Link: https://patchwork.freedesktop.org/patch/msgid/20180719171257.GA12199@intel.com
|
|
git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 4.19:
Core Changes:
- add support for DisplayPort CEC-Tunneling-over-AUX (Hans Verkuil)
- more doc updates (Daniel Vetter)
- fourcc: Add is_yuv field to drm_format_info (Ayan Kumar Halder)
- dma-buf: correctly place BUG_ON (Michel Dänzer)
Driver Changes:
- more vkms support(Rodrigo Siqueira)
- many fixes and small improments to all drivers
Signed-off-by: Dave Airlie <airlied@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180718200826.GA20165@juma
|
|
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
With neither LVDS or eDP no longer using intel_panel_detect() we can
kill it, and the accompanying modparam.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-3-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
We never registered any kind of lid notifier for eDP, so looking at the
lid status is pretty much bonkers. Let's just consider eDP always
connected instead.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-2-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
We broke the LVDS notifier resume thing in (presumably) commit
e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.") as
we no longer duplicate the current state in the LVDS notifier and
thus we never resume it properly either.
Instead of trying to fix it again let's just kill off the lid
notifier entirely. None of the machines tested thus far have
apparently needed it. Originally the lid notifier was added to
work around cases where the VBIOS was clobbering some of the
hardware state behind the driver's back, mostly on Thinkpads.
We now have a few report of Thinkpads working just fine without
the notifier. So maybe it was misdiagnosed originally, or
something else has changed (ACPI video stuff perhaps?).
If we do end up finding a machine where the VBIOS is still causing
problems I would suggest that we first try setting various bits in
the VBIOS scratch registers. There are several to choose from that
may instruct the VBIOS to steer clear.
With the notifier gone we'll also stop looking at the panel status
in ->detect().
v2: Nuke enum modeset_restore (Rodrigo)
Cc: stable@vger.kernel.org
Cc: Wolfgang Draxinger <wdraxinger.maillist@draxit.de>
Cc: Vito Caputo <vcaputo@pengaru.com>
Cc: kitsunyan <kitsunyan@airmail.cc>
Cc: Joonas Saarinen <jza@saunalahti.fi>
Tested-by: Vito Caputo <vcaputo@pengaru.com> # Thinkapd X61s
Tested-by: kitsunyan <kitsunyan@airmail.cc> # ThinkPad X200
Tested-by: Joonas Saarinen <jza@saunalahti.fi> # Fujitsu Siemens U9210
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105902
References: https://lists.freedesktop.org/archives/intel-gfx/2018-June/169315.html
References: https://bugs.freedesktop.org/show_bug.cgi?id=21230
Fixes: e2c8b8701e2d ("drm/i915: Use atomic helpers for suspend, v2.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717174216.22252-1-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
There's a race between idling the engine and finishing off the last
tasklet (as we may kick the tasklets after declaring an individual
engine idle). However, since we do not need to access the device until
we try to submit to the ELSP register (processing the CSB just requires
normal CPU access to the HWSP, and when idle we should not need to
submit!) we can defer the assertion unto that point. The assertion is
still useful as it does verify that we do hold the longterm GT wakeref
taken from request allocation until request completion.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107274
Fixes: 9512f985c32d ("drm/i915/execlists: Direct submission of new requests (avoid tasklet/ksoftirqd)")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719075029.28643-1-chris@chris-wilson.co.uk
|
|
If we call into the shrinker for direct relcaim inside kmalloc, it will
retire the requests. If we retire the vma->last_active while processing a
new i915_vma_move_to_active() we can upset the delicate bookkeeping
required for the cache. After the possible invocation of the shrinker, we
need to double check the vma->last_active is still valid.
Fixes: 8b293eb53a7d ("drm/i915: Track the last-active inside the i915_vma")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105600#c39
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180719072206.16015-1-chris@chris-wilson.co.uk
|
|
We make a decision at module load whether to use the GuC backend or not,
but lose that setup across set-wedge. Currently, the guc doesn't
override the engine->set_default_submission hook letting execlists sneak
back in temporarily on unwedging leading to an unbalanced park/unpark.
v2: Remove comment about switching back temporarily to execlists on
guc_submission_disable(). We currently only call disable on shutdown,
and plan to also call disable before suspend and reset, in which case we
will either restore guc submission or mark the driver as wedged, making
the reset back to execlists pointless.
v3: Move reset.prepare across
Fixes: 63572937cebf ("drm/i915/execlists: Flush pending preemption events during reset")
Testcase: igt/drv_module_reload/basic-reload-inject
Testcase: igt/gem_eio
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717202932.1423-1-chris@chris-wilson.co.uk
|
|
RC model has these parameters that correspond with each of
15 ranges of RC buffer threshold value in the RC model.
The three elements are range_min_qp, range_max_qp and
range_bpg_offset.
Add the Rate Control range values for eDP/MIPI and DP case.
The actual values are calculated usung a helper function.
This patch adds the shifts to registers where the value will
be written during atomic commit.
v2:
- Use _MMIO_PIPE() instead of _MMIO(_PICK()) (Manasi)
- Combine shifts (Manasi)
Cc: Jose Souza <jose.souza@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-4-git-send-email-anusha.srivatsa@intel.com
|
|
Add register defines and shifts that control the RC buffer threshold
between encoder and decoder for eDP/MIPI and DP cases.
The actual values are calculated usung a helper function.
This patch adds the shifts to registers where the value will
be written during atomic commit.
v2:
- Use _MMIO_PIPE() instead of _MMIO_(_PICK()) (Manasi)
- Combine shifts (Manasi)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-3-git-send-email-anusha.srivatsa@intel.com
|
|
Display Stream Compression(DSC) has a set of Picture
Parameter Set(PPS) components that the encoder must
communicate to the decoder.
This patch adds register definitions to
the PPS parameters for eDP/MIPI case and Display Port.
v2:
- Use _MMIO_PIPE instead of _MMIO(_PICK()). (Manasi)
- Use DSC constants as arguments. (Manasi)
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-2-git-send-email-anusha.srivatsa@intel.com
|
|
The Picture Parameter Set metadata for DSC has to be sent
to the panel through secondary data packets. Add the error
correction registers, data registers and control registers
for the same.
The control registers for transcoders A and B are already
defined and will be reused for Icelake purpose. This patch adds
Control register for EDP and transcoder C apart from adding the
PPS data and error registers.
v2: reuse MMIO_TRANS2 for _PPS_DATA and _PPS_ECC.
The _MMIO_TRANS2(pipe, reg) macro definition takes care of the eDp case
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ville Syrjala <ville.syrjala@linux.intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531861861-10950-1-git-send-email-anusha.srivatsa@intel.com
|
|
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
|
|
git://anongit.freedesktop.org/drm/drm-intel into drm-next
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
|
|
drm_format_info table has a field 'is_yuv' to denote if the format
is yuv or not. The driver is expected to use this instead of
having a function for the same purpose.
Signed-off-by: Ayan Kumar halder <ayan.halder@arm.com>
Reviewed-by: Ville Syrjala <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1531847626-22248-2-git-send-email-ayan.halder@arm.com
|
|
If the driver is wedged, we skip idling the GPU. However, we may still
have a few requests still not retired following the wedging (since they
will be waiting for a background worker trying to acquire struct_mutex).
As we hold the struct_mutex, always do a quick request retirement in
order to flush the wedged path.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107257
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/20180717084121.28185-1-chris@chris-wilson.co.uk
|
|
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 3a32497f0dbe ("drm/i915/selftests: Provide
full mb() around clflush") and commit add00e6d896f ("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
|
|
In the huge pages tests, we may have lots of objects being trapped on
the freelist as we hold the struct_mutex allowing the free worker no
opportunity to recover the backing store. We also have stricter
requirements and the desire for large contiguous pages, further
increasing the allocation pressure. To reduce the chance of running out
of memory, we could either drop the mutex and flush the free worker, or
we could release the backing store directly. We do the latter in this
patch for simplicity.
References: https://bugs.freedesktop.org/show_bug.cgi?id=107254
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180717082334.18774-1-chris@chris-wilson.co.uk
|
|
We must be able to reset the GPU while we are waiting on it to perform
an eviction (unbinding an active vma). So attach a spinning request to a
target vma and try and it evict it from a thread to see if that blocks
indefinitely.
v2: Add a wait for the thread to start just in case that takes more than
10ms...
v3: complete() not completion_done() to signal the completion.
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/20180716134009.13143-1-chris@chris-wilson.co.uk
|
|
Inject a failure into preemption completion to pretend as if the HW
didn't successfully handle preemption and we are forced to do a reset in
the middle.
v2: Wait for preemption, to force testing with the missed preemption.
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/20180716132154.12539-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: 60a943245413 ("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
|
|
If we declare the driver wedged before the GPU truly is, then we may see
the GPU complete some CS events following our cancellation. This leaves
us quite confused as we deleted all the bookkeeping and thus complain
about the inconsistent state.
We can just ignore the remaining events and let the GPU idle by not
feeding it, and so avoid trying to racily overwrite shared state. We
rely on there being a full GPU reset before unwedging, giving us the
opportunity to reset the shared state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107188
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/20180716080332.32283-4-chris@chris-wilson.co.uk
|
|
On an aborted module load, we unwind and free our device private - but
we left a dangling pointer to our privates inside the pci_device. After
the attempted aborted unload, we may still get a call to i915_pci_remove()
when the module is removed, potentially chasing stale data.
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/20180716080332.32283-5-chris@chris-wilson.co.uk
|
|
Give in, since CI continues to incorrectly insist that KERN_NOTICE is a
warning and flags the timeout message as unwanted spam. At first, the
intention was to use the message to indicate which tests might warrant
an extended run, but virtually all tests require a timeout so it is
simply not as interesting as first thought.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103667
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/20180716080332.32283-6-chris@chris-wilson.co.uk
|
|
We're seeing "RPM wakelock ref not held during HW access" warning
otherwise. Since IRQs are synced for runtime suspend we can just disable
the wakeref asserts.
Reported-by: Marta Löfstedt <marta.lofstedt@intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105710
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180714173703.7894-1-chris@chris-wilson.co.uk
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
With the new CSB processing code, we are not vulnerable to delayed
delivery of a pre-reset interrupt as we use the CSB status pointers in
the HWSP to decide if we need to parse any CSB events and no longer need
to wait for the first post-reset interrupt to be assured that the CSB
mmio registers are valid.
The new icl code to clear registers has a nasty lock inversion:
[ 57.409776] ======================================================
[ 57.409779] WARNING: possible circular locking dependency detected
[ 57.409783] 4.18.0-rc4-CI-CI_DII_1137+ #1 Tainted: G U W
[ 57.409785] ------------------------------------------------------
[ 57.409788] swapper/6/0 is trying to acquire lock:
[ 57.409790] 000000004f304ee5 (&engine->timeline.lock/1){-.-.}, at: execlists_submit_request+0x2b/0x1a0 [i915]
[ 57.409841]
but task is already holding lock:
[ 57.409844] 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915]
[ 57.409869]
which lock already depends on the new lock.
[ 57.409872]
the existing dependency chain (in reverse order) is:
[ 57.409876]
-> #2 (&(&rq->lock)->rlock#2){-.-.}:
[ 57.409900] notify_ring+0x2b2/0x480 [i915]
[ 57.409922] gen8_cs_irq_handler+0x39/0xa0 [i915]
[ 57.409943] gen11_irq_handler+0x2f0/0x420 [i915]
[ 57.409949] __handle_irq_event_percpu+0x42/0x370
[ 57.409952] handle_irq_event_percpu+0x2b/0x70
[ 57.409956] handle_irq_event+0x2f/0x50
[ 57.409959] handle_edge_irq+0xe7/0x190
[ 57.409964] handle_irq+0x67/0x160
[ 57.409967] do_IRQ+0x5e/0x120
[ 57.409971] ret_from_intr+0x0/0x1d
[ 57.409974] _raw_spin_unlock_irqrestore+0x4e/0x60
[ 57.409979] tasklet_action_common.isra.5+0x47/0xb0
[ 57.409982] __do_softirq+0xd9/0x505
[ 57.409985] irq_exit+0xa9/0xc0
[ 57.409988] do_IRQ+0x9a/0x120
[ 57.409991] ret_from_intr+0x0/0x1d
[ 57.409995] cpuidle_enter_state+0xac/0x360
[ 57.409999] do_idle+0x1f3/0x250
[ 57.410004] cpu_startup_entry+0x6a/0x70
[ 57.410010] start_secondary+0x19d/0x1f0
[ 57.410015] secondary_startup_64+0xa5/0xb0
[ 57.410018]
-> #1 (&(&dev_priv->irq_lock)->rlock){-.-.}:
[ 57.410081] clear_gtiir+0x30/0x200 [i915]
[ 57.410116] execlists_reset+0x6e/0x2b0 [i915]
[ 57.410140] i915_reset_engine+0x111/0x190 [i915]
[ 57.410165] i915_handle_error+0x11a/0x4a0 [i915]
[ 57.410198] i915_hangcheck_elapsed+0x378/0x530 [i915]
[ 57.410204] process_one_work+0x248/0x6c0
[ 57.410207] worker_thread+0x37/0x380
[ 57.410211] kthread+0x119/0x130
[ 57.410215] ret_from_fork+0x3a/0x50
[ 57.410217]
-> #0 (&engine->timeline.lock/1){-.-.}:
[ 57.410224] _raw_spin_lock_irqsave+0x33/0x50
[ 57.410256] execlists_submit_request+0x2b/0x1a0 [i915]
[ 57.410289] submit_notify+0x8d/0x124 [i915]
[ 57.410314] __i915_sw_fence_complete+0x81/0x250 [i915]
[ 57.410339] dma_i915_sw_fence_wake+0xd/0x20 [i915]
[ 57.410344] dma_fence_signal_locked+0x79/0x200
[ 57.410368] notify_ring+0x2ba/0x480 [i915]
[ 57.410392] gen8_cs_irq_handler+0x39/0xa0 [i915]
[ 57.410416] gen11_irq_handler+0x2f0/0x420 [i915]
[ 57.410421] __handle_irq_event_percpu+0x42/0x370
[ 57.410425] handle_irq_event_percpu+0x2b/0x70
[ 57.410428] handle_irq_event+0x2f/0x50
[ 57.410432] handle_edge_irq+0xe7/0x190
[ 57.410436] handle_irq+0x67/0x160
[ 57.410439] do_IRQ+0x5e/0x120
[ 57.410445] ret_from_intr+0x0/0x1d
[ 57.410449] cpuidle_enter_state+0xac/0x360
[ 57.410453] do_idle+0x1f3/0x250
[ 57.410456] cpu_startup_entry+0x6a/0x70
[ 57.410460] start_secondary+0x19d/0x1f0
[ 57.410464] secondary_startup_64+0xa5/0xb0
[ 57.410466]
other info that might help us debug this:
[ 57.410471] Chain exists of:
&engine->timeline.lock/1 --> &(&dev_priv->irq_lock)->rlock --> &(&rq->lock)->rlock#2
[ 57.410481] Possible unsafe locking scenario:
[ 57.410485] CPU0 CPU1
[ 57.410487] ---- ----
[ 57.410490] lock(&(&rq->lock)->rlock#2);
[ 57.410494] lock(&(&dev_priv->irq_lock)->rlock);
[ 57.410498] lock(&(&rq->lock)->rlock#2);
[ 57.410503] lock(&engine->timeline.lock/1);
[ 57.410506]
*** DEADLOCK ***
[ 57.410511] 4 locks held by swapper/6/0:
[ 57.410514] #0: 0000000074575789 (&(&dev_priv->irq_lock)->rlock){-.-.}, at: gen11_irq_handler+0x8a/0x420 [i915]
[ 57.410542] #1: 000000009b29b30e (rcu_read_lock){....}, at: notify_ring+0x1a/0x480 [i915]
[ 57.410573] #2: 00000000aad89594 (&(&rq->lock)->rlock#2){-.-.}, at: notify_ring+0x2b2/0x480 [i915]
[ 57.410601] #3: 000000009b29b30e (rcu_read_lock){....}, at: submit_notify+0x35/0x124 [i915]
[ 57.410635]
stack backtrace:
[ 57.410640] CPU: 6 PID: 0 Comm: swapper/6 Tainted: G U W 4.18.0-rc4-CI-CI_DII_1137+ #1
[ 57.410644] Hardware name: Intel Corporation Ice Lake Client Platform/IceLake U DDR4 SODIMM PD RVP, BIOS ICLSFWR1.R00.2222.A01.1805300339 05/30/2018
[ 57.410650] Call Trace:
[ 57.410652] <IRQ>
[ 57.410657] dump_stack+0x67/0x9b
[ 57.410662] print_circular_bug.isra.16+0x1c8/0x2b0
[ 57.410666] __lock_acquire+0x1897/0x1b50
[ 57.410671] ? lock_acquire+0xa6/0x210
[ 57.410674] lock_acquire+0xa6/0x210
[ 57.410706] ? execlists_submit_request+0x2b/0x1a0 [i915]
[ 57.410711] _raw_spin_lock_irqsave+0x33/0x50
[ 57.410741] ? execlists_submit_request+0x2b/0x1a0 [i915]
[ 57.410769] execlists_submit_request+0x2b/0x1a0 [i915]
[ 57.410774] ? _raw_spin_unlock_irqrestore+0x39/0x60
[ 57.410804] submit_notify+0x8d/0x124 [i915]
[ 57.410828] __i915_sw_fence_complete+0x81/0x250 [i915]
[ 57.410854] dma_i915_sw_fence_wake+0xd/0x20 [i915]
[ 57.410858] dma_fence_signal_locked+0x79/0x200
[ 57.410882] notify_ring+0x2ba/0x480 [i915]
[ 57.410907] gen8_cs_irq_handler+0x39/0xa0 [i915]
[ 57.410933] gen11_irq_handler+0x2f0/0x420 [i915]
[ 57.410938] __handle_irq_event_percpu+0x42/0x370
[ 57.410943] handle_irq_event_percpu+0x2b/0x70
[ 57.410947] handle_irq_event+0x2f/0x50
[ 57.410951] handle_edge_irq+0xe7/0x190
[ 57.410955] handle_irq+0x67/0x160
[ 57.410958] do_IRQ+0x5e/0x120
[ 57.410962] common_interrupt+0xf/0xf
[ 57.410965] </IRQ>
[ 57.410969] RIP: 0010:cpuidle_enter_state+0xac/0x360
[ 57.410972] Code: 44 00 00 31 ff e8 84 93 91 ff 45 84 f6 74 12 9c 58 f6 c4 02 0f 85 31 02 00 00 31 ff e8 7d 30 98 ff e8 e8 0e 94 ff fb 4c 29 fb <48> ba cf f7 53 e3 a5 9b c4 20 48 89 d8 48 c1 fb 3f 48 f7 ea b8 ff
[ 57.411015] RSP: 0018:ffffc90000133e90 EFLAGS: 00000216 ORIG_RAX: ffffffffffffffdd
[ 57.411023] RAX: ffff8804ae748040 RBX: 000000000002a97d RCX: 0000000000000000
[ 57.411029] RDX: 0000000000000046 RSI: ffffffff82141263 RDI: ffffffff820f05a7
[ 57.411035] RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
[ 57.411041] R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff8229f078
[ 57.411045] R13: ffff8804ab2adfa8 R14: 0000000000000000 R15: 0000000d5de092e3
[ 57.411052] do_idle+0x1f3/0x250
[ 57.411055] cpu_startup_entry+0x6a/0x70
[ 57.411059] start_secondary+0x19d/0x1f0
[ 57.411064] secondary_startup_64+0xa5/0xb0
The easiest remedy is to remove the defunct code.
Fixes: ff047a87cfac ("drm/i915/icl: Correctly clear lost ctx-switch interrupts across reset for Gen11")
References: fd8526e50902 ("drm/i915/execlists: Trust the CSB")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-3-chris@chris-wilson.co.uk
|
|
Inside intel_engine_is_idle(), we flush the tasklet to ensure that is
being run in a timely fashion (ksoftirqd has taught us to expect the
worst). However, if we are in the middle of reset, the HW may not yet be
ready to execute the submission tasklet and so we must respect the
disable flag.
Fixes: dd0cf235d81f ("drm/i915: Speed up idle detection by kicking the tasklets")
Testcase: igt/drv_selftest/live_hangcheck
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-2-chris@chris-wilson.co.uk
|
|
Knowing the boundary of each subtest can be instrumental in digesting
the voluminous trace output and finding the critical piece of
information.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180713203529.1973-1-chris@chris-wilson.co.uk
|
|
Hopefully the final hack to get guc fault-injection happy before we can
clean it up again, starting from a known good baseline...
[ 383.017530] BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
[ 383.017556] Oops: 0000 [#1] PREEMPT SMP PTI
[ 383.017566] CPU: 7 PID: 4725 Comm: drv_module_relo Tainted: G U 4.18.0-rc4-CI-CI_DRM_4485+ #1
[ 383.017581] Hardware name: Micro-Star International Co., Ltd. MS-7B54/Z370M MORTAR (MS-7B54), BIOS 1.10 12/28/2017
[ 383.017664] RIP: 0010:guc_stage_desc_pool_destroy+0x17/0xe0 [i915]
[ 383.017674] Code: 59 a0 c6 05 02 59 18 00 01 e8 5e 01 c3 e0 eb b1 0f 1f 00 53 48 89 fb 48 81 c7 90 02 00 00 e8 60 64 45 e1 48 8b 83 80 02 00 00 <48> 8b 80 a0 00 00 00 48 8b 90 68 02 00 00 48 83 ea 01 48 81 fa ff
[ 383.017771] RSP: 0018:ffffc900004bbdd0 EFLAGS: 00010282
[ 383.017782] RAX: 0000000000000000 RBX: ffff88012ff41300 RCX: 0000000000000000
[ 383.017794] RDX: 0000000000000000 RSI: ffffc900004bbd80 RDI: 0000000000000000
[ 383.017805] RBP: ffff88012ff40000 R08: 00000000d876ee11 R09: 0000000000000000
[ 383.017817] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012ff47770
[ 383.017828] R13: ffff88012ff40068 R14: ffff880264392ef8 R15: ffffffffa0639950
[ 383.017840] FS: 00007fb9c18c8980(0000) GS:ffff8802663c0000(0000) knlGS:0000000000000000
[ 383.017853] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 383.017864] CR2: 00000000000000a0 CR3: 00000001df6cc003 CR4: 00000000003606e0
[ 383.017875] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 383.017887] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 383.017898] Call Trace:
[ 383.017962] intel_uc_fini+0x34/0xd0 [i915]
[ 383.018020] i915_gem_fini+0x5c/0x100 [i915]
[ 383.018093] i915_driver_unload+0xd2/0x110 [i915]
[ 383.018150] i915_pci_remove+0x10/0x20 [i915]
[ 383.018165] pci_device_remove+0x36/0xb0
[ 383.018179] device_release_driver_internal+0x185/0x250
[ 383.018193] driver_detach+0x35/0x70
[ 383.018205] bus_remove_driver+0x53/0xd0
[ 383.018217] pci_unregister_driver+0x25/0xa0
[ 383.018232] __se_sys_delete_module+0x162/0x210
[ 383.018245] ? do_syscall_64+0xd/0x190
[ 383.018257] do_syscall_64+0x55/0x190
[ 383.018270] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 383.018282] RIP: 0033:0x7fb9c0f7c1b7
[ 383.018290] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
[ 383.018408] RSP: 002b:00007fffa01c2aa8 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 383.018425] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fb9c0f7c1b7
[ 383.018440] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000560b96856d48
[ 383.018454] RBP: 0000560b96856ce0 R08: 0000560b96856d4c R09: 00007fffa01c2ae8
[ 383.018468] R10: 00007fffa01c1aa4 R11: 0000000000000206 R12: 0000560b954f7470
Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180713172658.14070-1-chris@chris-wilson.co.uk
|
|
Since there's very few callers of these I've decided to do them all in
one patch. With this the unecessarily long drm_mode_connector_ prefix
is gone from the codebase! The only exception being struct
drm_mode_connector_set_property, which is part of the uapi so can't be
renamed.
Again done with sed+some manual fixups for indent issues.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-8-daniel.vetter@ffwll.ch
|
|
Again to align with the usual prefix of just drm_connector_. Again
done with sed + manual fixup for indent issues.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-7-daniel.vetter@ffwll.ch
|
|
Just makes it longer, and for most things in drm_connector.[hc] we
just use the drm_connector_ prefix. Done with sed + a bit of manual
fixup for the indenting.
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180709084016.23750-6-daniel.vetter@ffwll.ch
|
|
We're printing out which pins got a hotplug, so why not also print
out which pins detected the long pulse as opposed to a short pulse.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-9-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
|
|
We're doing a pointless translation from hpd_pin to port simply for
passing the thing to long_pulse_detect(). Let's pass the hpd_pin
directly instead.
This removes the assumption that the hpd_pin and port always
match. The only other place where we make that assumption anymore
is intel_hpd_pin_default() and that's fine as it's what determines
the relationship between the two. If we ever get hardware where
the hpd pins are wired in more interesting ways it should be
trivial to handle from now on.
This should also fix the IS_CNL_WITH_PORT_F() case as that mapped
pin E back to port F and passed that to
spt_port_hotplug2_long_detect() which would always return false
for port F. Now that we pass in pin E directly it'll actually
do the right thing.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Fixes: cf53902f48c3 ("drm/i915/cnl: Add HPD support for Port F.")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-7-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Use the enum hpd_pin type when talking about HPD pins, and rename the
variable from a very nondescript 'i' to 'pin', a name we already
use in other parts of the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-6-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Instead of looping over ports and hpd_pins, let's loop over
the encoders when doing hotplug processing. And instead of
depending on dev_priv->irq_port[] to tell us whether the
encoder has the ->hpd_pulse() hook or not, we can just
check for that directly. So we can just nuke irq_port[] entirely.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-5-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Rather than looping over all the ports and picking the encoder based on
the port, let's just loop over all the encoders instead. Gets rid of
some irq_port[] usage, which is a bit of an eye sore.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-4-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Add intel_encoder_is_dig_port() to match intel_encoder_is_dp().
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-3-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
Add a convenience macro for iterating DP encoders.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180705164357.28512-2-ville.syrjala@linux.intel.com
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
|
|
On gen8 and onwards, we can mark GPU accesses through the ppGTT as being
read-only, that is cause any GPU write onto that page to be discarded
(not triggering a fault). This is all that we need to finally support
the read-only flag for userptr!
v2: Check default address space for read only support as a proxy for the
user context/ppgtt.
Testcase: igt/gem_userptr_blits/readonly*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712191430.9269-1-chris@chris-wilson.co.uk
|
|
If the user created a read-only object, they should not be allowed to
circumvent the write protection using the pwrite ioctl.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-5-chris@chris-wilson.co.uk
|
|
If the user has created a read-only object, they should not be allowed
to circumvent the write protection by using a GGTT mmapping. Deny it.
Also most machines do not support read-only GGTT PTEs, so again we have
to reject attempted writes. Fortunately, this is known a priori, so we
can at least reject in the call to create the mmap (with a sanity check
in the fault handler).
v2: Check the vma->vm_flags during mmap() to allow readonly access.
v3: Remove VM_MAYWRITE to curtail mprotect()
Testcase: igt/gem_userptr_blits/readonly_mmap*
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: David Herrmann <dh.herrmann@gmail.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com> #v1
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-4-chris@chris-wilson.co.uk
|
|
GVT is not propagating the PTE bits, and is always setting the
read-write bit, thus breaking read-only support.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-3-chris@chris-wilson.co.uk
|
|
Hook up the flags to allow read-only ppGTT mappings for gen8+
v2: Include a selftest to check that writes to a readonly PTE are
dropped
v3: Don't duplicate cpu_check() as we can just reuse it, and even worse
don't wholesale copy the theory-of-operation comment from igt_ctx_exec
without changing it to explain the intention behind the new test!
v4: Joonas really likes magic mystery values
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-2-chris@chris-wilson.co.uk
|
|
We can set a bit inside the ppGTT PTE to indicate a page is read-only;
writes from the GPU will be discarded. We can use this to protect pages
and in particular support read-only userptr mappings (necessary for
importing PROT_READ vma).
Signed-off-by: Jon Bloomfield <jon.bloomfield@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712185315.3288-1-chris@chris-wilson.co.uk
|
|
Implement support for this DisplayPort feature.
Signed-off-by: Hans Verkuil <hans.verkuil@cisco.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/20180711132909.25409-4-hverkuil@xs4all.nl
|
|
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
|
|
After aborting a module load, we may try and disable guc before we have
finished setting it. Long term plan is to ensure perfect onion unwind,
but in the short term we want to fix the oops to re-enable
drv_module_reload.
[ 317.401239] BUG: unable to handle kernel NULL pointer dereference at 0000000000000030
[ 317.401279] Oops: 0000 [#1] PREEMPT SMP PTI
[ 317.401294] CPU: 5 PID: 4275 Comm: drv_module_relo Tainted: G U 4.18.0-rc4-CI-CI_DRM_4476+ #1
[ 317.401317] Hardware name: System manufacturer System Product Name/Z170M-PLUS, BIOS 3610 03/29/2018
[ 317.401440] RIP: 0010:unreserve_doorbell+0x0/0x80 [i915]
[ 317.401454] Code: bb e0 48 8b 35 21 4d 18 00 49 c7 c0 a8 e5 62 a0 b9 cc 00 00 00 48 c7 c2 d8 41 5f a0 48 c7 c7 c9 f6 53 a0 e8 a2 3d c2 e0 0f 0b <0f> b7 47 30 66 3d 00 01 74 20 48 8b 57 18 48 0f a3 82 40 05 00 00
[ 317.401602] RSP: 0018:ffffc900003d3da0 EFLAGS: 00010246
[ 317.401619] RAX: ffffffff8223b300 RBX: 0000000000000000 RCX: 0000000000000000
[ 317.401636] RDX: 0000001fffffffc0 RSI: ffff880219f115f0 RDI: 0000000000000000
[ 317.401654] RBP: ffff880219f11838 R08: 0000000000000000 R09: 0000000000000000
[ 317.401671] R10: 0000000000000000 R11: 0000000000000000 R12: ffff880219f11300
[ 317.401689] R13: ffff880219f17770 R14: ffff88022c1daef8 R15: ffffffffa06ae950
[ 317.401707] FS: 00007febf77a9980(0000) GS:ffff880236d40000(0000) knlGS:0000000000000000
[ 317.401727] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 317.401743] CR2: 0000000000000030 CR3: 0000000222072003 CR4: 00000000003606e0
[ 317.401761] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 317.401779] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 317.401796] Call Trace:
[ 317.401894] guc_client_free+0x9/0x130 [i915]
[ 317.401993] intel_guc_submission_fini+0x50/0x90 [i915]
[ 317.402092] intel_uc_fini+0x34/0xd0 [i915]
[ 317.402179] i915_gem_fini+0x5c/0x100 [i915]
[ 317.402249] i915_driver_unload+0xd2/0x110 [i915]
[ 317.402321] i915_pci_remove+0x10/0x20 [i915]
[ 317.402341] pci_device_remove+0x36/0xb0
[ 317.402357] device_release_driver_internal+0x185/0x250
[ 317.402374] driver_detach+0x35/0x70
[ 317.402390] bus_remove_driver+0x53/0xd0
[ 317.402404] pci_unregister_driver+0x25/0xa0
[ 317.402423] __se_sys_delete_module+0x162/0x210
[ 317.402439] ? do_syscall_64+0xd/0x190
[ 317.402454] do_syscall_64+0x55/0x190
[ 317.402470] entry_SYSCALL_64_after_hwframe+0x49/0xbe
[ 317.402485] RIP: 0033:0x7febf6e5d1b7
[ 317.402496] Code: 73 01 c3 48 8b 0d d1 8c 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 b8 b0 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d a1 8c 2c 00 f7 d8 64 89 01 48
[ 317.402646] RSP: 002b:00007fffb5e72798 EFLAGS: 00000206 ORIG_RAX: 00000000000000b0
[ 317.402667] RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007febf6e5d1b7
[ 317.402686] RDX: 0000000000000000 RSI: 0000000000000800 RDI: 0000562da1addd98
[ 317.402703] RBP: 0000562da1addd30 R08: 0000562da1addd9c R09: 00007fffb5e727d8
[ 317.402721] R10: 00007fffb5e71794 R11: 0000000000000206 R12: 0000562da0ff6470
Testcase: igt/drv_module_reload/basic-reload-inject
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180712202027.19801-1-chris@chris-wilson.co.uk
|