OSDN Git Service
Chris Wilson [Thu, 27 Feb 2020 08:57:18 +0000 (08:57 +0000)]
drm/i915/selftests: Be a little more lenient for reset workers
Give the reset worker a kick before losing help when waiting for hang
recovery, as the CPU scheduler is a little unreliable.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-15-chris@chris-wilson.co.uk
Ville Syrjälä [Tue, 28 Jan 2020 15:51:52 +0000 (17:51 +0200)]
drm/i915: Add glk to intel_detect_preproduction_hw()
Detect GLK pre-production steppings. Not 100% of A2 being pre-prod
since the spec is a bit of a mess but feels more or less correct.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200128155152.21977-4-ville.syrjala@linux.intel.com
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Chris Wilson [Fri, 28 Feb 2020 08:23:24 +0000 (08:23 +0000)]
drm/i915/selftests: Wait for the context switch
As we require a context switch to ensure that the current context is
switched out and saved to memory, perform an explicit switch to the
kernel context and wait for it.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1336
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200228082330.2411941-18-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:06 +0000 (08:57 +0000)]
drm/i915/perf: Manually acquire engine-wakeref around use of kernel_context
The engine->kernel_context is a special case for request emission. Since
it is used as the barrier within the engine's wakeref, we must acquire the
wakeref before submitting a request to the kernel_context.
Reported-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-3-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:05 +0000 (08:57 +0000)]
drm/i915/perf: Mark up the racy use of perf->exclusive_stream
Inside the general i915_oa_init_reg_state() we avoid using the
perf->mutex. However, we rely on perf->exclusive_stream being valid to
access at that point, and for that we have to control the race with
disabling perf. This relies on the disabling being a heavy barrier that
inspects all active contexts, after marking the perf->exclusive_stream
as not available. This should ensure that there are no more concurrent
accesses to the perf->exclusive_stream as we destroy it.
Mark up the races around the perf->exclusive_stream so that they stand
out much more. (And hopefully we will be running kcsan to start
validating that the only races we have are carefully controlled.)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-2-chris@chris-wilson.co.uk
Anshuman Gupta [Wed, 26 Feb 2020 16:35:17 +0000 (22:05 +0530)]
drm/i915: Fix wrongly populated plane possible_crtcs bit mask
As a disabled pipe in pipe_mask is not having a valid intel crtc,
driver wrongly populates the possible_crtcs mask while initializing
the plane for a CRTC. Fixing up the plane possible_crtcs mask.
changes since RFC:
- Simplify the possible_crtcs initialization. [Ville]
v2:
- Removed the unnecessary stack garbage possible_crtcs to
drm_universal_plane_init. [Ville]
v3:
- Combine the intel_crtc assignment and declaration. [Ville]
v4:
- Fix possible_crtcs abused bits from
intel_{primary,curosr,sprite}_plane_create(). [Ville]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226163517.31234-1-anshuman.gupta@intel.com
Chris Wilson [Thu, 27 Feb 2020 08:57:14 +0000 (08:57 +0000)]
drm/i915: Protect i915_request_await_start from early waits
We need to be extremely careful inside i915_request_await_start() as it
needs to walk the list of requests in the foreign timeline with very
little protection. As we hold our own timeline mutex, we can not nest
inside the signaler's timeline mutex, so all that remains is our RCU
protection. However, to be safe we need to tell the compiler that we may
be traversing the list only under RCU protection, and furthermore we
need to start declaring requests as elements of the timeline from their
construction.
Fixes:
9ddc8ec027a3 ("drm/i915: Eliminate the trylock for awaiting an earlier request")
Fixes:
6a79d848403d ("drm/i915: Lock signaler timeline while navigating")
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/20200227085723.1961649-11-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:16 +0000 (08:57 +0000)]
drm/i915/selftests: Check recovery from corrupted LRC
Check that we can recover if the LRC is totally corrupted. Based on a
very simple theory that anything that can be adjusted via the context
(i.e. on behalf of the user), should be under the purview of the
per-engine-reset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-13-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:15 +0000 (08:57 +0000)]
drm/i915/selftests: Verify LRC isolation
Record the LRC registers before/after a preemption event to ensure that
the first context sees nothing from the second client; at least in the
normal per-context register state.
References: https://gitlab.freedesktop.org/drm/intel/issues/1233
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-12-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:13 +0000 (08:57 +0000)]
drm/i915/gt: Pull marking vm as closed underneath the vm->mutex
Pull the final atomic_dec of vm->open (marking the vm as closed)
underneath the same vm->mutex as used to close it. This is required to
correctly serialise with attempting to reuse the vma as the vm is closed
by a second thread.
References:
00de702c6c6f ("drm/i915: Check that the vma hasn't been closed before we insert it")
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/20200227085723.1961649-10-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 20:47:27 +0000 (20:47 +0000)]
drm/i915/gt: Check engine-is-awake on reset later
As we drop the engine-pm on retiring, that may happen while there are
still CS events in the buffer. As such we cannot assert the engine is
still active on reset, until we know that the current request is still
in flight.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1338
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227204727.2009346-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:11 +0000 (08:57 +0000)]
drm/i915/selftests: Disable heartbeat around manual pulse tests
Still chasing the mystery of the stray idle flush, let's ensure that the
heartbeat does not run at the same time as our test and confuse us.
References: https://gitlab.freedesktop.org/drm/intel/issues/541
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-8-chris@chris-wilson.co.uk
Chris Wilson [Thu, 27 Feb 2020 08:57:04 +0000 (08:57 +0000)]
drm/i915: Skip barriers inside waits
Attaching to the i915_active barrier is a two stage process, and a flush
is only effective when the barrier is activation. Thus it is possible
for us to see a barrier, and attempt to flush, only for our flush to
have no effect. As such, before attempting to activate signaling on the
fence we need to double check it is a fence!
Fixes:
d13a31770077 ("drm/i915: Flush idle barriers when waiting")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1333
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200227085723.1961649-1-chris@chris-wilson.co.uk
Daniele Ceraolo Spurio [Wed, 26 Feb 2020 18:56:57 +0000 (10:56 -0800)]
drm/i915/ggtt: do not set bits 1-11 in gen12 ptes
On TGL, bits 2-4 in the GGTT PTE are not ignored anymore and are
instead used for some extra VT-d capabilities. We don't (yet?) have
support for those capabilities, but, given that we shared the pte_encode
function betweed GGTT and PPGTT, we still set those bits to the PPGTT
PPAT values. The DMA engine gets very confused when those bits are
set while the iommu is enabled, leading to errors. E.g. when loading
the GuC we get:
[ 9.796218] DMAR: DRHD: handling fault status reg 2
[ 9.796235] DMAR: [DMA Write] Request device [00:02.0] PASID
ffffffff fault addr 0 [fault reason 02] Present bit in context entry is clear
[ 9.899215] [drm:intel_guc_fw_upload [i915]] *ERROR* GuC firmware signature verification failed
To fix this, just have dedicated gen8_pte_encode function per type of
gtt. Also, explicitly set vm->pte_encode for gen8_ppgtt, even if we
don't use it, to make sure we don't accidentally assign it to the GGTT
one, like we do for gen6_ppgtt, in case we need it in the future.
Reported-by: "Sodhi, Vunny" <vunny.sodhi@intel.com>
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226185657.26445-1-daniele.ceraolospurio@intel.com
Lucas De Marchi [Mon, 24 Feb 2020 19:12:58 +0000 (11:12 -0800)]
drm/i915/tgl: Add Wa_1608008084
Wa_1608008084 is an additional WA that applies to writes on FF_MODE2
register. We can't read it back either from CPU or GPU. Since the other
bits should be 0, recommendation to handle Wa_1604555607 is to actually
just write the timer value.
Do a write only and don't try to read it, neither before or after
the WA is applied.
Fixes:
ff690b2111ba ("drm/i915/tgl: Implement Wa_1604555607")
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224191258.15668-1-lucas.demarchi@intel.com
Ville Syrjälä [Wed, 26 Feb 2020 16:30:54 +0000 (18:30 +0200)]
drm/i915: Set up PIPE_MISC truncate bit on tgl+
Looks like the pipe rounding mode bit has moved from PIPE_CHICKEN to
PIPE_MISC on tgl. Frob the new location.
Bspec does still document the old bits as well, so I left the code
for them as is until we get clarification from the hw folks on
whether the old bits still do something useful.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226163054.9509-1-ville.syrjala@linux.intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Lucas De Marchi [Fri, 8 Mar 2019 23:23:21 +0000 (15:23 -0800)]
drm/i915: remove ICP_PP_CONTROL
This register was placed in the middle of the PP_STATUS definition
instead of together with the PP_CONTROL where it should. Since it's not
used and there are no current plans to use it, just remove the
definition.
v2: remove the define rather than moving it.
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190308232321.30168-1-lucas.demarchi@intel.com
Jani Nikula [Tue, 25 Feb 2020 11:15:09 +0000 (13:15 +0200)]
drm/i915/drv: use intel_uncore_write() for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace the sole remaining I915_WRITE() in i915_drv.c with
intel_uncore_write(), although it might be better to keep the entire
file void of direct register access.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225111509.21879-3-jani.nikula@intel.com
Jani Nikula [Tue, 25 Feb 2020 11:15:08 +0000 (13:15 +0200)]
drm/i915/dram: use intel_uncore_*() functions for register access
The implicit "dev_priv" local variable use has been a long-standing pain
point in the register access macros I915_READ(), I915_WRITE(),
POSTING_READ(), I915_READ_FW(), and I915_WRITE_FW().
Replace them with the corresponding uncore register accessors
intel_uncore_read(), intel_uncore_write(), intel_uncore_posting_read(),
intel_uncore_read_fw(), and intel_uncore_write_fw().
Rename dev_priv to i915 while at it.
No functional changes.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225111509.21879-2-jani.nikula@intel.com
Jani Nikula [Tue, 25 Feb 2020 11:15:07 +0000 (13:15 +0200)]
drm/i915: split out intel_dram.[ch] from i915_drv.c
The DRAM related routines are pretty isolated from the rest of the
i915_drv.c, split it out to a separate file. Put the eDRAM stuff in the
same bag, and rename the visible functions to have intel_dram_
prefix. Do some benign whitespace fixes and dev_priv -> i915 conversions
while at it.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225111509.21879-1-jani.nikula@intel.com
Jani Nikula [Tue, 25 Feb 2020 13:31:31 +0000 (15:31 +0200)]
drm/i915: significantly reduce the use of <drm/i915_drm.h>
The #include has been splattered all over the place, but there are
precious few places, all .c files, that actually need it.
v2: remove leftover double newlines
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225133131.3301-1-jani.nikula@intel.com
Matt Atwood [Mon, 24 Feb 2020 22:36:51 +0000 (14:36 -0800)]
drm/i915/tgl: Add Wa_1606054188:tgl
On Tiger Lake we do not support source keying in the pixel formats P010,
P012, P016.
v2: Move WA to end of function. Create helper function for format
check. Less verbose debugging messaging.
v3: whitespace
v4(MattR):
- Actually return EINVAL to reject this combination.
- Pass format parameter as u32.
- Make test TGL-specific for now.
- Switch to per-device logging.
- Shorten/simplify comment.
Bspec: 52890
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Atwood <matthew.s.atwood@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224223651.3801646-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Matt Roper [Thu, 20 Feb 2020 23:18:43 +0000 (15:18 -0800)]
drm/i915/tgl: Allow DC5/DC6 entry while PG2 is active
On gen12, we no longer need to disable DC5/DC6 when when PG2 is in use
(which translates to cases where we're using VDSC on pipe A).
Bspec: 49193
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220231843.3127468-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Rodrigo Vivi [Wed, 26 Feb 2020 22:58:14 +0000 (14:58 -0800)]
Merge tag 'gvt-next-2020-02-26' of https://github.com/intel/gvt-linux into drm-intel-next-queued
gvt-next-2020-02-26
- Enable VFIO edid for all platform (Zhenyu)
- Code cleanup for attr group and unused vblank complete (Zhenyu, Julian)
- Make gvt oblivious of kvmgt data structures (Julian)
- Make WARN* drm specific (Pankaj)
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
From: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200226103840.GD10413@zhen-hp.sh.intel.com
Anshuman Gupta [Mon, 24 Feb 2020 12:40:04 +0000 (18:10 +0530)]
drm/i915: Fix broken num_entries in skl_ddb_allocation_overlaps
skl_ddb_allocation_overlaps() num_entries hass been passed as
INTEL_NUM_PIPES, it should be I915_MAX_PIPES.
v2:
- Rebased.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-8-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 24 Feb 2020 12:40:03 +0000 (18:10 +0530)]
drm/i915: Add WARN_ON in intel_get_crtc_for_pipe()
Add a WARN_ON for a disabled pipe in pipe_mask at
intel_get_crtc_for_pipe() function.
v2:
- Use drm_WARN_ON instead of WARN_ON.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-7-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 24 Feb 2020 12:40:02 +0000 (18:10 +0530)]
drm/i915: Get first crtc instead of PIPE_A crtc
intel_plane_fb_max_stride should return the max stride of
primary plane for first available pipe in intel device info
pipe_mask.
Similarly glk_force_audio_cdclk() should also use the first
available CRTC instead of pipe 'A' crtc to force the cdclk
changes.
changes since RFC:
- Introduced a helper to get first intel_crtc intel_get_first_crtc. [Ville]
v1:
- Used intel_get_first_crtc() instead of PIPE_A crtc in
glk_force_audio_cdclk(). [Ville]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-6-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 24 Feb 2020 12:40:00 +0000 (18:10 +0530)]
drm/i915: Fix broken transcoder err state
Skip the transcoder whose pipe is disabled while
initializing transcoder error state in 3 non-contiguous
display pipe system.
v2:
- Don't skip EDP_TRANSCODER error state. [Ville]
- Use a helper has_transcoder(). [Ville]
v3:
- Removed DSI transcoder case from has_transcoder(),
and few other cosmetic changes. [Ville]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-4-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 24 Feb 2020 12:39:59 +0000 (18:09 +0530)]
drm/i915: Remove (pipe == crtc->index) assumption
we can't have (pipe == crtc->index) assumption in
driver in order to support 3 non-contiguous
display pipe system.
FIXME: Remove the WARN_ON(drm_crtc_index(&crtc->base) != crtc->pipe)
when we will fix all such assumption.
changes since RFC:
- Added again removed (pipe == crtc->index) WARN_ON.
- Pass drm_crtc_index instead of intel pipe in order to
call drm_handle_vblank().
v2:
- Used drm_crtc_handle_vblank()/drm_crtc_wait_one_vblank()
instead of drm_handle_vblank/drm_wait_one_vblank(). [Jani]
- Introduced intel_handle_vblank() helper to avoid sprinkle
of intel_crtc across irq_handlers. [Ville]
v3:
- Moved intel_handle_vblank() from header to i915_irq.c. [Ville]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-3-anshuman.gupta@intel.com
Anshuman Gupta [Mon, 24 Feb 2020 12:39:58 +0000 (18:09 +0530)]
drm/i915: Iterate over pipes and skip the disabled one
It should not be assumed that a disabled display pipe will be
always last the pipe.
for_each_pipe() should iterate over I915_MAX_PIPES and check
for the disabled pipe and skip that pipe so that it should not
initialize the intel crtc for any disabled pipes.
Due to changes in for_each_pipe() macro, it requires to handle
the below compilation error.
"suggest explicit braces to avoid ambiguous ‘else’
[-Werror=dangling-else]"
v2:
- Cosmetic changes, removed unwanted parentheses. [Ville]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Anshuman Gupta <anshuman.gupta@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224124004.26712-2-anshuman.gupta@intel.com
Jani Nikula [Mon, 24 Feb 2020 12:08:28 +0000 (14:08 +0200)]
drm/i915: split intel_modeset_init() to pre/post irq install
Split inte_modeset_init() to parts before and after irq install, to
facilitate further cleanup. The error paths are a mess, otherwise no
functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224120828.22105-1-jani.nikula@intel.com
Jani Nikula [Mon, 24 Feb 2020 11:33:12 +0000 (13:33 +0200)]
drm/i915: stop assigning drm->dev_private pointer
We no longer need or use it as we subclass struct drm_device in our
struct drm_i915_private, and can always use to_i915() to get at
i915. Stop assigning the pointer to catch anyone trying to add new users
for ->dev_private.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Dale B Stimson <dale.b.stimson@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224113312.13674-1-jani.nikula@intel.com
Chris Wilson [Tue, 25 Feb 2020 19:22:06 +0000 (19:22 +0000)]
drm/i915/gem: Honour O_NONBLOCK before throttling execbuf submissions
Check the user's flags on the struct file before deciding whether or not
to stall before submitting a request. This allows us to reasonably
cheaply honour O_NONBLOCK without checking at more critical phases
during request submission.
Suggested-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Steve Carbonari <steven.carbonari@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225192206.1107336-3-chris@chris-wilson.co.uk
Chris Wilson [Tue, 25 Feb 2020 19:22:05 +0000 (19:22 +0000)]
drm/i915: Allow userspace to specify ringsize on construction
No good reason why we must always use a static ringsize, so let
userspace select one during construction.
Link: https://github.com/intel/compute-runtime/pull/261
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Steve Carbonari <steven.carbonari@intel.com>
Reviewed-by: Janusz Krzysztofik <janusz.krzysztofik@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225192206.1107336-2-chris@chris-wilson.co.uk
Chris Wilson [Tue, 25 Feb 2020 19:22:04 +0000 (19:22 +0000)]
drm/i915: Flush idle barriers when waiting
If we do find ourselves with an idle barrier inside our active while
waiting, attempt to flush it by emitting a pulse using the kernel
context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Steve Carbonari <steven.carbonari@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225192206.1107336-1-chris@chris-wilson.co.uk
Rodrigo Vivi [Tue, 25 Feb 2020 18:41:22 +0000 (10:41 -0800)]
drm/i915: Update DRIVER_DATE to
20200225
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Tue, 25 Feb 2020 17:29:58 +0000 (09:29 -0800)]
Merge drm/drm-next into drm-intel-next-queued
Some DSI and VBT pending patches from Hans will apply
cleanly and with less ugly conflicts if they are rebuilt
on top of other patches that recently landed on drm-next.
Reference: https://patchwork.freedesktop.org/series/70952/
Cc: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com
Chris Wilson [Tue, 25 Feb 2020 08:22:23 +0000 (08:22 +0000)]
drm/i915: Drop assertion that active->fence is unchanged
We cannot assert the fence is not yet changed as the next thread may
change it prior to acquiring our lock.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225082233.274530-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 25 Feb 2020 08:22:26 +0000 (08:22 +0000)]
drm/i915/gem: Cleanup shadow batch after I915_EXEC_SECURE
Tidy up after a call to eb_parse() if a later bind fails.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1312
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200225082233.274530-4-chris@chris-wilson.co.uk
Tina Zhang [Tue, 25 Feb 2020 05:35:26 +0000 (13:35 +0800)]
drm/i915/gvt: Fix drm_WARN issue where vgpu ptr is unavailable
When vgpu ptr is unavailable, the drm_WARN* can hang the whole system
due to the drm pointer is NULL. This patch fixes this issue by using
WARN directly which won't care about the drm pointer.
Fixes:
12d5861973c70 ("drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available")
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200225053527.8336-1-tina.zhang@intel.com
Rodrigo Vivi [Tue, 25 Feb 2020 01:45:39 +0000 (17:45 -0800)]
drm/i915: Update DRIVER_DATE to
20200224
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Rodrigo Vivi [Tue, 25 Feb 2020 01:32:20 +0000 (17:32 -0800)]
drm/i915: Update DRIVER_DATE to
20200224
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Chris Wilson [Mon, 24 Feb 2020 10:11:20 +0000 (10:11 +0000)]
drm/i915/gtt: Downgrade gen7 (ivb, byt, hsw) back to aliasing-ppgtt
Full-ppgtt on gen7 is proving to be highly unstable and not robust.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/694
Fixes:
3cd6e8860ecd ("drm/i915/gen7: Re-enable full-ppgtt for ivb & hsw")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Dave Airlie <airlied@redhat.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200224101120.4024481-1-chris@chris-wilson.co.uk
José Roberto de Souza [Fri, 21 Feb 2020 21:26:35 +0000 (13:26 -0800)]
drm/i915/psr: Force PSR probe only after full initialization
Commit
60c6a14b489b ("drm/i915/display: Force the state compute phase
once to enable PSR") was forcing the state compute too earlier
causing errors because not everything was initialized, so here
moving to the end of i915_driver_modeset_probe() when the display is
all initialized.
Also fixing the place where it disarm the force probe as during the
atomic check phase errors could happen like the ones due locking and
it would cause PSR to never be enabled if that happens.
Leaving the disarm to the atomic commit phase, intel_psr_enable() or
intel_psr_update() will be called even if the current state do not
allow PSR to be enabled.
v2: Check if intel_dp is null in intel_psr_force_mode_changed_set()
v3: Check intel_dp before get dev_priv
v4:
- renamed intel_psr_force_mode_changed_set() to
intel_psr_set_force_mode_changed()
- removed the set parameter from intel_psr_set_force_mode_changed()
- not calling intel_psr_set_force_mode_changed() from
intel_psr_enable/update(), directly setting it after the same checks
that intel_psr_set_force_mode_changed() does
- moved intel_psr_set_force_mode_changed() arm call to
i915_driver_modeset_probe() as it is a better for a PSR call, all the
functions calls happening between the old and the new function call
will cause issue
Fixes:
60c6a14b489b ("drm/i915/display: Force the state compute phase once to enable PSR")
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1151
Tested-by: Ross Zwisler <zwisler@google.com>
Reported-by: Ross Zwisler <zwisler@google.com>
Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Anshuman Gupta <anshuman.gupta@intel.com>
Reviewed-by: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221212635.11614-1-jose.souza@intel.com
Ville Syrjälä [Fri, 21 Feb 2020 15:43:10 +0000 (17:43 +0200)]
drm/i915: Correctly terminate connector iteration
One should use drm_connector_list_iter_end() rather than
drm_connector_list_iter_begin() to terminate the connector
iteration.
Cc: Manasi Navare <manasi.d.navare@intel.com>
Cc: Uma Shankar <uma.shankar@intel.com>
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1278
Fixes:
e24bcd34c1dd ("drm/i915/dp: Add all tiled and port sync conns to modeset")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221154310.14858-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Jani Nikula [Fri, 21 Feb 2020 10:54:14 +0000 (12:54 +0200)]
drm/i915: fix header test with GCOV
$(CC) with $(CFLAGS_GCOV) assumes the output filename with .gcno suffix
appended is writable. This is not the case when the output filename is
/dev/null:
HDRTEST drivers/gpu/drm/i915/display/intel_frontbuffer.h
/dev/null:1:0: error: cannot open /dev/null.gcno
HDRTEST drivers/gpu/drm/i915/display/intel_ddi.h
/dev/null:1:0: error: cannot open /dev/null.gcno
make[5]: *** [../drivers/gpu/drm/i915/Makefile:307:
drivers/gpu/drm/i915/display/intel_ddi.hdrtest] Error 1
make[5]: *** Waiting for unfinished jobs....
make[5]: *** [../drivers/gpu/drm/i915/Makefile:307:
drivers/gpu/drm/i915/display/intel_frontbuffer.hdrtest] Error 1
Filter out $(CFLAGS_GVOC) from the header test $(c_flags) as they don't
make sense here anyway.
References: http://lore.kernel.org/r/
d8112767-4089-4c58-d7d3-
2ce03139858a@infradead.org
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Fixes:
c6d4a099a240 ("drm/i915: reimplement header test feature")
Cc: Masahiro Yamada <masahiroy@kernel.org>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221105414.14358-1-jani.nikula@intel.com
Chris Wilson [Sun, 23 Feb 2020 17:37:46 +0000 (17:37 +0000)]
drm/i915/display: Fix inverted WARN_ON
Restore the previous WARN_ON(cond) so that we don't complain about poor
old Cherryview.
Fixes:
eb020ca3d43f ("drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200223173959.3885742-1-chris@chris-wilson.co.uk
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:07 +0000 (22:25 +0530)]
drm/i915/gvt: Make WARN* drm specific where vgpu ptr is available
Drm specific drm_WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device struct pointer is readily
available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@@
identifier func, T;
@@
func(struct intel_vgpu *T,...) {
+struct drm_i915_private *i915 = T->gvt->dev_priv;
<+...
(
-WARN(
+drm_WARN(&i915->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&i915->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&i915->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&i915->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-9-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:06 +0000 (22:25 +0530)]
drm/i915/gvt: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-8-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:05 +0000 (22:25 +0530)]
drm/i915/display/hdcp: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-7-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:04 +0000 (22:25 +0530)]
drm/i915/display/dp: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-6-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:03 +0000 (22:25 +0530)]
drm/i915/display/power: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-5-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:02 +0000 (22:25 +0530)]
drm/i915/display/display: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-4-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:01 +0000 (22:25 +0530)]
drm/i915/display/ddi: Make WARN* drm specific where drm_device ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_device or drm_i915_private struct
pointer is readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_device *T = ...;
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule2@
identifier func, T;
@@
func(struct drm_device *T,...) {
<...
(
-WARN(
+drm_WARN(T,
...)
|
-WARN_ON(
+drm_WARN_ON(T,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(T,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(T,
...)
)
...>
}
@rule3@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule4@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-3-pankaj.laxminarayan.bharadiya@intel.com
Pankaj Bharadiya [Thu, 20 Feb 2020 16:55:00 +0000 (22:25 +0530)]
drm/i915/display/cdclk: Make WARN* drm specific where drm_priv ptr is available
drm specific WARN* calls include device information in the
backtrace, so we know what device the warnings originate from.
Covert all the calls of WARN* with device specific drm_WARN*
variants in functions where drm_i915_private struct pointer is
readily available.
The conversion was done automatically with below coccinelle semantic
patch. checkpatch errors/warnings are fixed manually.
@rule1@
identifier func, T;
@@
func(...) {
...
struct drm_i915_private *T = ...;
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
@rule2@
identifier func, T;
@@
func(struct drm_i915_private *T,...) {
<+...
(
-WARN(
+drm_WARN(&T->drm,
...)
|
-WARN_ON(
+drm_WARN_ON(&T->drm,
...)
|
-WARN_ONCE(
+drm_WARN_ONCE(&T->drm,
...)
|
-WARN_ON_ONCE(
+drm_WARN_ON_ONCE(&T->drm,
...)
)
...+>
}
Signed-off-by: Pankaj Bharadiya <pankaj.laxminarayan.bharadiya@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220165507.16823-2-pankaj.laxminarayan.bharadiya@intel.com
Kees Cook [Fri, 21 Feb 2020 00:05:17 +0000 (16:05 -0800)]
drm/i915: Distribute switch variables for initialization
Variables declared in a switch statement before any case statements
cannot be automatically initialized with compiler instrumentation (as
they are not part of any execution flow). With GCC's proposed automatic
stack variable initialization feature, this triggers a warning (and they
don't get initialized). Clang's automatic stack variable initialization
(via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
doesn't initialize such variables[1]. Note that these warnings (or silent
skipping) happen before the dead-store elimination optimization phase,
so even when the automatic initializations are later elided in favor of
direct initializations, the warnings remain.
To avoid these problems, move such variables into the "case" where
they're used or lift them up into the main function body.
drivers/gpu/drm/i915/display/intel_display.c: In function ‘check_digital_port_conflicts’:
drivers/gpu/drm/i915/display/intel_display.c:12963:17: warning: statement will never be executed [-Wswitch-unreachable]
12963 | unsigned int port_mask;
| ^~~~~~~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_get_fifo_size’:
drivers/gpu/drm/i915/intel_pm.c:474:7: warning: statement will never be executed [-Wswitch-unreachable]
474 | u32 dsparb, dsparb2, dsparb3;
| ^~~~~~
drivers/gpu/drm/i915/intel_pm.c: In function ‘vlv_atomic_update_fifo’:
drivers/gpu/drm/i915/intel_pm.c:1997:7: warning: statement will never be executed [-Wswitch-unreachable]
1997 | u32 dsparb, dsparb2, dsparb3;
| ^~~~~~
[1] https://bugs.llvm.org/show_bug.cgi?id=44916
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/202002201602.92CADF7D@keescook
Jani Nikula [Wed, 19 Feb 2020 15:45:42 +0000 (17:45 +0200)]
drm/i915: make dbuf configurations const
Ensure const data goes to rodata.
Fixes:
ff2cd8635e41 ("drm/i915: Correctly map DBUF slices to pipes")
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219154542.19574-1-jani.nikula@intel.com
Jani Nikula [Wed, 19 Feb 2020 13:37:56 +0000 (15:37 +0200)]
drm/i915: split i915_driver_modeset_probe() to pre/post irq install
Pair the irq install and uninstall in the same layer. There are no
functional changes in the happy day scenario. The cleanup paths are
currently a mess though.
Note that modeset probe pre-irq + post-irq install are matched by
modeset driver remove pre-irq + post-irq uninstall, together, but not
independently. They are not symmetric pairs.
v2: don't add a new probe failure point here
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219133756.13224-1-jani.nikula@intel.com
Colin Ian King [Sat, 22 Feb 2020 13:47:55 +0000 (13:47 +0000)]
drm/i915/gt: remove redundant assignment to variable dw
Variable dw is being initialized with a value that is never read,
it is assigned a new value later on. The assignment is redundant
and can be removed.
Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200222134755.134209-1-colin.king@canonical.com
Chris Wilson [Fri, 21 Feb 2020 23:51:35 +0000 (23:51 +0000)]
drm/i915/gt: Push the GPU cancellation to the backend
Upon unregistering the user interface, we mark the GPU as wedged to
ensure we push no new work to the GPU, and to flush all current work
from the GPU. Move this call to the GT backend.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221235135.2883006-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 21 Feb 2020 22:18:18 +0000 (22:18 +0000)]
drm/i915: Avoid recursing onto active vma from the shrinker
We mark the vma as active while binding it in order to protect outselves
from being shrunk under mempressure. This only works if we are strict in
not attempting to shrink active objects.
<6> [472.618968] Workqueue: events_unbound fence_work [i915]
<4> [472.618970] Call Trace:
<4> [472.618974] ? __schedule+0x2e5/0x810
<4> [472.618978] schedule+0x37/0xe0
<4> [472.618982] schedule_preempt_disabled+0xf/0x20
<4> [472.618984] __mutex_lock+0x281/0x9c0
<4> [472.618987] ? mark_held_locks+0x49/0x70
<4> [472.618989] ? _raw_spin_unlock_irqrestore+0x47/0x60
<4> [472.619038] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619084] ? i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619122] i915_vma_unbind+0xae/0x110 [i915]
<4> [472.619165] i915_gem_object_unbind+0x1dc/0x400 [i915]
<4> [472.619208] i915_gem_shrink+0x328/0x660 [i915]
<4> [472.619250] ? i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619282] i915_gem_shrink_all+0x38/0x60 [i915]
<4> [472.619325] vm_alloc_page.constprop.25+0x1aa/0x240 [i915]
<4> [472.619330] ? rcu_read_lock_sched_held+0x4d/0x80
<4> [472.619363] ? __alloc_pd+0xb/0x30 [i915]
<4> [472.619366] ? module_assert_mutex_or_preempt+0xf/0x30
<4> [472.619368] ? __module_address+0x23/0xe0
<4> [472.619371] ? is_module_address+0x26/0x40
<4> [472.619374] ? static_obj+0x34/0x50
<4> [472.619376] ? lockdep_init_map+0x4d/0x1e0
<4> [472.619407] setup_page_dma+0xd/0x90 [i915]
<4> [472.619437] alloc_pd+0x29/0x50 [i915]
<4> [472.619470] __gen8_ppgtt_alloc+0x443/0x6b0 [i915]
<4> [472.619503] gen8_ppgtt_alloc+0xd7/0x300 [i915]
<4> [472.619535] ppgtt_bind_vma+0x2a/0xe0 [i915]
<4> [472.619577] __vma_bind+0x26/0x40 [i915]
<4> [472.619611] fence_work+0x1c/0x90 [i915]
<4> [472.619617] process_one_work+0x26a/0x620
Fixes:
2850748ef876 ("drm/i915: Pull i915_vma_pin under the vm->mutex")
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/20200221221818.2861432-1-chris@chris-wilson.co.uk
Matt Roper [Wed, 19 Feb 2020 21:56:55 +0000 (13:56 -0800)]
drm/i915/tgl: Add Wa_22010178259:tgl
We need to explicitly set the TLB Request Timer initial value in the
BW_BUDDY registers to 0x8 rather than relying on the hardware default.
v2: Apply missing REG_FIELD_PREP to ensure 0x8 is placed in the correct
bits during the rmw. (Jose)
Bspec: 52890
Bspec: 50044
Fixes:
3fa01d642fa7 ("drm/i915/tgl: Program BW_BUDDY registers during display init")
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219215655.2923650-1-matthew.d.roper@intel.com
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Chris Wilson [Fri, 21 Feb 2020 12:19:40 +0000 (12:19 +0000)]
drm/i915: Check that the vma hasn't been closed before we insert it
As there is a delay before we pin a vma, there is an opportunity for
another thread to have closed the vm and its vma (including us).
Check as soon as we acquire the vm->mutex and know the vm/vma is stable.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/1291
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221121940.2741563-1-chris@chris-wilson.co.uk
Chris Wilson [Fri, 21 Feb 2020 10:09:53 +0000 (10:09 +0000)]
drm/i915/gem: Break up long lists of object reclaim
Call cond_resched() between each freed object in case we have a really,
really long list, and we don't want to block normal processes.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200221100953.2587176-1-chris@chris-wilson.co.uk
Michał Winiarski [Wed, 19 Feb 2020 16:18:22 +0000 (17:18 +0100)]
drm/i915/pmu: Avoid using globals for PMU events
Attempting to bind / unbind module from devices where we have both
integrated and discreete GPU handled by i915, will cause us to try and
double free the global state, hitting null ptr deref in free_event_attributes.
Let's move it to i915_pmu.
Fixes:
05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219161822.24592-2-michal.winiarski@intel.com
Michał Winiarski [Wed, 19 Feb 2020 16:18:21 +0000 (17:18 +0100)]
drm/i915/pmu: Avoid using globals for CPU hotplug state
Attempting to bind / unbind module from devices where we have both
integrated and discreete GPU handled by i915 can lead to leaks and
warnings from cpuhp:
Error: Removing state XXX which has instances left.
Let's move the state to i915_pmu.
Fixes:
05488673a4d4 ("drm/i915/pmu: Support multiple GPUs")
Signed-off-by: Michał Winiarski <michal.winiarski@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219161822.24592-1-michal.winiarski@intel.com
Wambui Karuga [Tue, 18 Feb 2020 17:39:36 +0000 (20:39 +0300)]
drm/i915/perf: conversion to struct drm_device based logging macros.
Manual conversion of instances of printk based drm logging macros to the
struct drm_device based logging macros in i915/i915_perf.c.
Also involves extraction of the struct drm_i915_private device from
various intel types for use in the macros.
Instances of the DRM_DEBUG printk macro were not converted due to the
lack of an analogous struct drm_device based logging macro.
v2: remove instances of DRM_DEBUG that were converted.
References: https://lists.freedesktop.org/archives/dri-devel/2020-January/253381.html
Signed-off-by: Wambui Karuga <wambui.karugax@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218173936.19664-1-wambui.karugax@gmail.com
Matt Roper [Tue, 4 Feb 2020 01:10:32 +0000 (17:10 -0800)]
drm/i915/tgl: Program MBUS_ABOX{1,2}_CTL during display init
On gen11 we only needed to program MBus credits into MBUS_ABOX_CTL
during display initialization, but on gen12 we're now supposed to
program the same values into MBUS_ABOX1_CTL and MBUS_ABOX2_CTL as well.
v2:
- Program registers with rmw to preserve contents of unrelated bits.
- Switch to the new display uncore helpers.
Bspec: 49213
Bspec: 50096
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-2-matthew.d.roper@intel.com
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Matt Roper [Tue, 4 Feb 2020 01:10:31 +0000 (17:10 -0800)]
drm/i915: Program MBUS with rmw during initialization
It wasn't terribly clear from the bspec's wording, but after discussion
with the hardware folks, it turns out that we need to preserve the
pre-existing contents of the MBUS ABOX control register when
initializing a few specific bits.
Bspec: 49213
Bspec: 50096
Fixes:
4cb4585e5a7f ("drm/i915/icl: initialize MBus during display init")
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200204011032.582737-1-matthew.d.roper@intel.com
Reviewed-by: Matt Atwood <matthew.s.atwood@intel.com>
Ville Syrjälä [Wed, 12 Feb 2020 16:17:32 +0000 (18:17 +0200)]
drm/i915: Use intel_de_write_fw() for skl+ scaler registers
We have to write quite a few registers when programming the
pipe scaler. Let's use intel_de_write_fw() for these to reduce
the lockdep overhead a bit. All plane registers (including plane
scaler) already do this.
We already had a few accidental intel_de_write_fw() in there.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 12 Feb 2020 16:17:31 +0000 (18:17 +0200)]
drm/i915: Parametrize PFIT_PIPE
Make the PFIT_PIPE stuff less ugly via parametrization.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200212161738.28141-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 5 Feb 2020 18:35:43 +0000 (20:35 +0200)]
drm/i915: Mark all HPD capabled connectors as such
Currently we only set the DRM_CONNECTOR_POLL_{DISCONNECT,CONNECT}
bits in intel_connector->polled (the base setting), leading to
some confusing looking code to reset drm_connector->polled
(the actual setting) to DRM_CONNECTOR_POLL_HPD. Let's set
intel_connector->polled = DRM_CONNECTOR_POLL_HPD for all hpd
capable connectors, and then we don't need so many special
cases in the hotplug code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Wed, 5 Feb 2020 18:35:42 +0000 (20:35 +0200)]
drm/i915/hpd: Replace the loop-within-loop with two independent loops
No point in looping over all connectors for each hpd pin. Just loop
over each connector first and deal with each one's hpd pin. Then
loop over all the hpd pins to mark them as enabled again.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200205183546.9291-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Ville Syrjälä [Thu, 7 Nov 2019 15:17:17 +0000 (17:17 +0200)]
drm/i915: Add i9xx_lut_8()
We have a nice little helper to compute a single LUT entry
for everything except the 8bpc legacy gamma mode. Let's
complete the set.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191107151725.10507-5-ville.syrjala@linux.intel.com
Reviewed-by: Emil Velikov <emil.velikov@collabora.com>
Dave Airlie [Thu, 20 Feb 2020 05:21:02 +0000 (15:21 +1000)]
Merge tag 'drm-misc-next-2020-02-10' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.7:
UAPI Changes:
- lima: Add support for heap buffers
Cross-subsystem Changes:
Core Changes:
- Implement mode_config mode_valid for memory constrained drivers
- Bus format negociation between bridges
- Consolidate fake vblank events for drivers without vblank interrupts
- drm/bufs: dma_alloc related cleanups
- drm/dp_mst: Various fixes
- drm/print: New drm_device based print helpers
- Thomas is a drm-misc maintainer now!
Driver Changes:
- DPMS cleanups for atomic drivers
- Removal of owner field in SPI tinydrm drivers
- Removal of explicit dependency on DT for tinydrm drivers
- Conversion to YAML schemas for DT bindings
- tidss: New driver
- virtio: various reworks and fixes
- Our usual dozen or so new panels or bridges
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime@cerno.tech>
Link: https://patchwork.freedesktop.org/patch/msgid/20200210093421.xu4sofldm6wm6xq6@gilmour.lan
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:26 +0000 (14:33 -0800)]
drm/i915/uc: consolidate firmware cleanup
We are quite trigger happy in cleaning up the firmware blobs, as we do
so from several error/fini paths in GuC/HuC/uC code. We do have the
__uc_cleanup_firmwares cleanup function, which unwinds
__uc_fetch_firmwares and is already called both from the error path of
gem_init and from gem_driver_release, so let's stop cleaning up from
all the other paths.
The fact that we're not cleaning the firmware immediately means that
we can't consider firmware availability as an indication of
initialization success. A "LOADABLE" status has been added to
indicate that the initialization was successful, to be used to
selectively load HuC only if HuC init has completed (HuC init failure
is not considered a fatal error).
v2: s/ready_to_load/loadable (Michal), only run guc/huc_fini if the
fw is in loadable state
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1
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/20200218223327.11058-9-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:25 +0000 (14:33 -0800)]
drm/i915/uc: Abort early on uc_init failure
Now that we can differentiate wants vs uses GuC/HuC, intel_uc_init is
restricted to running only if we have successfully fetched the required
blob(s) and are committed to using the microcontroller(s).
The only remaining thing that can go wrong in uc_init is the allocation
of GuC/HuC related objects; if we get such a failure better to bail out
immediately instead of wedging later, like we do for e.g.
intel_engines_init, since without objects we can't use the HW, including
not being able to attempt the firmware load.
While at it, remove the unneeded fw_cleanup call (this is handled
outside of gt_init) and add a probe failure injection point for testing.
Also, update the logs for <g/h>uc_init failures to probe_failure() since
they will cause the driver load to fail.
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-8-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:24 +0000 (14:33 -0800)]
drm/i915/guc: Apply new uC status tracking to GuC submission as well
To be able to differentiate the before and after of our commitment to
GuC submission, which will be used in follow-up patches to early set-up
the submission structures.
v2: move functions to guc_submission.h (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@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/20200218223327.11058-7-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:23 +0000 (14:33 -0800)]
drm/i915/uc: Improve tracking of uC init status
To be able to setup GuC submission functions during engine init we need
to commit to using GuC as soon as possible.
Currently, the only thing that can stop us from using the
microcontrollers once we've fetched the blobs is a fundamental
error (e.g. OOM); given that if we hit such an error we can't really
fall-back to anything, we can "officialize" the FW fetching completion
as the moment at which we're committing to using GuC.
To better differentiate this case, the uses_guc check, which indicates
that GuC is supported and was selected in modparam, is renamed to
wants_guc and a new uses_guc is introduced to represent the case were
we're committed to using the GuC. Note that uses_guc does still not imply
that the blob is actually loaded on the HW (is_running is the check for
that). Also, since we need to have attempted the fetch for the result
of uses_guc to be meaningful, we need to make sure we've moved away
from INTEL_UC_FIRMWARE_SELECTED.
All the GuC changes have been mirrored on the HuC for coherency.
v2: split fetch return changes and new macros to their own patches,
support HuC only if GuC is wanted, improve "used" state
description (Michal)
v3: s/wants_huc/uses_huc in uc_init_wopcm
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Fernando Pacheco <fernando.pacheco@intel.com> #v1
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/20200218223327.11058-6-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:22 +0000 (14:33 -0800)]
drm/i915/uc: autogenerate uC checker functions
We want to map uC-level checks to GuC/HuC-level ones. The mapping from
the uC state to the GuC/HuC one follows the same pattern for all the
functions:
uc_xxx_guc() -> guc_is_yyy()
So we can easily use a macro to autogenerate the functions via macros by
passing in the 2 mapped states.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-5-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:21 +0000 (14:33 -0800)]
drm/i915/uc: Update the FW status on injected fetch error
In a follow up patch we will rely on the fact that the status always
moves away from "SELECTED" after the fetch is attempted to decide what
to do with the GuC.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-4-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:20 +0000 (14:33 -0800)]
drm/i915/guc: Kill USES_GUC_SUBMISSION macro
use intel_uc_uses_guc_submission() directly instead, to be consistent in
the way we check what we want to do with the GuC.
v2: do not go through ctx->vm->gt, use i915->gt instead
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com> #v1
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-3-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:19 +0000 (14:33 -0800)]
drm/i915/guc: Kill USES_GUC macro
use intel_uc_uses_guc() directly instead, to be consistent in the way we
check what we want to do with the GuC.
v2: split guc_log_info changes to their own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-2-daniele.ceraolospurio@intel.com
Daniele Ceraolo Spurio [Tue, 18 Feb 2020 22:33:18 +0000 (14:33 -0800)]
drm/i915/debugfs: Pass guc_log struct to i915_guc_log_info
The log struct is the only thing the function needs (apart from
the seq_file), so we can pass just that instead of the whole dev_priv.
v2: Split this change to its own patch (Michal)
Signed-off-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: John Harrison <John.C.Harrison@Intel.com>
Cc: Matthew Brost <matthew.brost@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218223327.11058-1-daniele.ceraolospurio@intel.com
Chris Wilson [Thu, 20 Feb 2020 12:36:07 +0000 (12:36 +0000)]
drm/i915: Double check bumping after the spinlock
In preparation for making GEM execbuf parallel, we need to be prepared
to handle very early declaration of dependencies -- even before our
signaler has itself been submitted.
References:
a79ca656b648 ("drm/i915: Push the wakeref->count deferral to the backend")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220123608.1666271-1-chris@chris-wilson.co.uk
Chris Wilson [Thu, 20 Feb 2020 07:50:20 +0000 (07:50 +0000)]
drm/i915/gt: Protect signaler walk with RCU
While we know that the waiters cannot disappear as we walk our list
(only that they might be added), the same cannot be said for our
signalers as they may be completed by the HW and retired as we process
this request. Ergo we need to use rcu to protect the list iteration and
remember to mark up the list_del_rcu.
v2: Mark the deps as safe-for-rcu
Fixes:
793c22617367 ("drm/i915/gt: Protect execlists_hold/unhold from new waiters")
Fixes:
32ff621fd744 ("drm/i915/gt: Allow temporary suspension of inflight requests")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220075025.1539375-1-chris@chris-wilson.co.uk
Matthew Auld [Thu, 20 Feb 2020 10:57:07 +0000 (10:57 +0000)]
drm/i915: remove the other slab_dependencies
The real one can be found in i915_scheduler.c.
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20200220105707.344522-1-matthew.auld@intel.com
Julian Stecklina [Mon, 17 Feb 2020 16:38:58 +0000 (17:38 +0100)]
drm/i915/gvt: make gvt oblivious of kvmgt data structures
Instead of defining KVMGT per-device state in struct intel_vgpu
directly, add an indirection. This makes the GVT code oblivious of
what state KVMGT needs to keep.
The intention here is to eventually make it possible to build
hypervisor backends for the mediator, without having to touch the
mediator itself. This is a first step.
v2:
- rebased onto gvt-staging (no conflicts)
Signed-off-by: Julian Stecklina <julian.stecklina@cyberus-technology.de>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20200217163858.26496-1-julian.stecklina@cyberus-technology.de
Manasi Navare [Fri, 14 Feb 2020 11:41:26 +0000 (03:41 -0800)]
drm/i915/dp: Add all tiled and port sync conns to modeset
If one of the synced crtcs needs a full modeset, we need
to make sure all the synced crtcs are forced a full
modeset.
v3:
* Remove ~BIT(cpu_trans) which is a nop (Ville)
* use get_new_crtc_state and remove error check (Ville)
v2:
* Add tiles based on cpu_trans check (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-3-manasi.d.navare@intel.com
Manasi Navare [Fri, 14 Feb 2020 11:41:25 +0000 (03:41 -0800)]
drm/i915/dp: Compute port sync crtc states post compute_config()
This patch pushes out the computation of master and slave
transcoders in crtc states after encoder's compute_config hook.
This ensures that the assigned master slave crtcs have exact same
mode and timings which is a requirement for Port sync mode
to be enabled.
v3:
* Make crtc_state const, remove crtc state NULL init (Ville)
v2:
* Correct indentation
* Rename to intel_ddi_port_sync_transcoders (Ville)
* remove unwanted debug (Ville)
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-2-manasi.d.navare@intel.com
Ville Syrjälä [Fri, 14 Feb 2020 11:41:24 +0000 (03:41 -0800)]
drm/i915: Introduce encoder->compute_config_late()
Add an optional secondary encoder state compute hook. This gets
called after the normak .compute_config() has been called for
all the encoders in the state. Thus in the new hook we can rely
on all derived state populated by .compute_config() to be already
set up. Should be useful for MST and port sync master/slave
transcoder selection.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214114126.13192-1-manasi.d.navare@intel.com
Zhenyu Wang [Thu, 20 Feb 2020 08:23:37 +0000 (16:23 +0800)]
Merge drm-intel-next-queued into gvt-next
Backmerge to pull in
https://patchwork.freedesktop.org/patch/353621/?series=73544&rev=1
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Chris Wilson [Wed, 19 Feb 2020 13:01:19 +0000 (13:01 +0000)]
drm/i915/gt: Do not attempt to reprogram IA/ring frequencies for dgfx
For dgfx, we do not need to reconfigure the IA/ring frequencies of the
main processors as they are distinct devices.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Andi Shyti <andi.shyti@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Andi Shyti <andi.shyti@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219130119.1457693-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 19 Feb 2020 12:34:18 +0000 (12:34 +0000)]
drm/i915/selftests: Mark GPR checking more hostile
Currently, we check that a new context has a clear set of general
purpose registers. Add a little bit of hostility by preempting our new
context and re-poisoning the GPR to ensure that there is no context
leakage from preemption.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219123418.1447428-1-chris@chris-wilson.co.uk
Chris Wilson [Wed, 19 Feb 2020 11:20:03 +0000 (11:20 +0000)]
drm/i915/selftest: Analyse timestamp behaviour across context switches
Check that the CTX_TIMESTAMP is monotonic across context save/restore
and upon preemption.
References: https://gitlab.freedesktop.org/drm/intel/issues/1233
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ramalingam C <ramalingam.c@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200219112004.1412791-1-chris@chris-wilson.co.uk
Chris Wilson [Sun, 16 Feb 2020 16:34:45 +0000 (16:34 +0000)]
drm/i915: Read rawclk_freq earlier
Read the rawclk_freq during runtime info probing, prior to its first use
in computing the CS timestamp frequency. Then store it in the runtime
info, and include it in the debug printouts.
Closes: https://gitlab.freedesktop.org/drm/intel/issues/834
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200216163445.555786-1-chris@chris-wilson.co.uk
Chris Wilson [Tue, 18 Feb 2020 16:21:48 +0000 (16:21 +0000)]
drm/i915/gt: Refactor l3cc/mocs availability
On dgfx, we only use l3cc and not mocs, but we share the table
containing both register definitions with Tigerlake. This confuses our
selftest that verifies that both sets of registers do contain the values
in our tables after various events (idling, reset, activity etc).
When constructing the table of register definitions, also include the
flags for which registers are valid so that information is computed
centrally and available to all callers.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Brian Welty <brian.welty@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200218162150.1300405-10-chris@chris-wilson.co.uk
Jani Nikula [Fri, 14 Feb 2020 13:50:58 +0000 (15:50 +0200)]
drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstall
Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214135058.7580-2-jani.nikula@intel.com
Jani Nikula [Fri, 14 Feb 2020 13:50:57 +0000 (15:50 +0200)]
drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall. Move
irq_unintall() closer to the layer it belongs.
The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200214135058.7580-1-jani.nikula@intel.com
Jani Nikula [Mon, 17 Feb 2020 18:42:19 +0000 (20:42 +0200)]
drm/i915/gem: use spinlock_t instead of struct spinlock
spinlock_t is one case where the typedef is to be preferred over struct
spinlock.
Fixes:
42fb60de3129 ("drm/i915/gem: Don't leak non-persistent requests on changing engines")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200217184219.15325-1-jani.nikula@intel.com