Clean up the DP pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state(),
the port state asserts, and the VLV power sequencer code.
v2: Return PIPE_A for cpt/ppt when the port isn't selected by
any transcoder. Returning INVALID_PIPE explodes *somewhere*
on some machines (can't immediately see where though). This
now matches the old behaviour.
v3: Order the defines shift,mask,value (Jani)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-4-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
for_each_encoder_on_crtc() is legacy and shouldn't be used by atomic
drivers. Let's throw out intel_trans_dp_port_sel() and replace it
with intel_get_crtc_new_encoder() which looks the atomic state instead.
Since we now have to call intel_get_crtc_new_encoder() during the commit
phase we'll need to plumb in the top level atomic state. The
crtc_state->state pointers are no longer valid at that point.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180518152931.13104-3-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
nospec quite reasonably asserts that it will never be used with an index
larger than unsigned long (that being the largest possibly index into an
C array). However, our ubi uses the convention of u64 for any large
integer, running afoul of the assertion on 32b. Reduce our index to an
unsigned long, checking for type overflow first.
drivers/gpu/drm/i915/i915_query.c: In function 'i915_query_ioctl':
include/linux/compiler.h:339:38: error: call to '__compiletime_assert_119' declared with attribute error: BUILD_BUG_ON failed: sizeof(_s) > sizeof(long)
Reported-by: kbuild-all@01.org
Fixes: 84b510e22d ("drm/i915/query: Protect tainted function pointer lookup")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522121018.15199-1-chris@chris-wilson.co.uk
Replace dev_priv->vbt.edp.support with
dev_priv->vbt.int_lvds_support. We'll want to extend its
use beyond the LVDS vs. eDP case in the future.
v2: Nuke the edp.support from parse_edp() (Jani)
Only clear int_lvds_support for gen5+ to preserve
the current behaviour (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Ondrej Zary <linux@rainbow-software.org>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508140814.20105-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
As we handle the allocation failure of the page directory and tables by
propagating the failure back to userspace, allow it to fail if direct
reclaim is unable to satisfy the request (i.e. disable the oomkiller).
The premise being that if we are unable to allocate a single page for
the pagetable, we will not be able to handle the multitude of pages
required for the gfx operation and we should back off to allow the
system to recover.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106609
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180522083643.29601-1-chris@chris-wilson.co.uk
Smatch identifies i915_query_ioctl() as being a potential victim of
Spectre due to its use of a tainted user index into a function pointer
array. Use array_index_nospec() to defang the user index before using it
to lookup the function pointer.
Fixes: a446ae2c6e ("drm/i915: add query uAPI")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180521210530.26008-1-chris@chris-wilson.co.uk
This reverts commit dc911f5bd8.
Per the report, no matter what display mode you select with xrandr, the
i915 driver will always select the alternate fixed mode. For the
reporter this means that the display will always run at 40Hz which is
quite annoying. This may be due to the mode comparison.
But there are some other potential issues. The choice of alt_fixed_mode
seems dubious. It's the first non-preferred mode, but there are no
guarantees that the only difference would be refresh rate. Similarly,
there may be more than one preferred mode in the probed modes list, and
the commit changes the preferred mode selection to choose the last one
on the list instead of the first.
(Note that the probed modes list is the raw, unfiltered, unsorted list
of modes from drm_add_edid_modes(), not the pretty result after a
drm_helper_probe_single_connector_modes() call.)
Finally, we already have eerily similar code in place to find the
downclock mode for DRRS that seems like could be reused here.
Back to the drawing board.
Note: This is a hand-crafted revert due to conflicts. If it fails to
backport, please just try reverting the original commit directly.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105469
Reported-by: Rune Petersen <rune@megahurts.dk>
Reported-by: Mark Spencer <n7u4722r35@ynzlx.anonbox.net>
Fixes: dc911f5bd8 ("drm/i915/edp: Allow alternate fixed mode for eDP if available.")
Cc: Clint Taylor <clinton.a.taylor@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jim Bride <jim.bride@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: intel-gfx@lists.freedesktop.org
Cc: <stable@vger.kernel.org> # v4.14+
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516080110.22770-1-jani.nikula@intel.com
Since drm_framebuffer can now store GEM objects directly, place them
there rather than in our own subclass.
v2: Only hold a single reference per framebuffer, not per plane. (Ville)
v3: Drop NULL check in intel_fb_obj. (Ville)
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-2-daniels@collabora.com
We already have a macro to pull the GEM object from a FB, so use it
everywhere. We'll make use of this later to move the object storage.
Signed-off-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: intel-gfx@lists.freedesktop.org
Link: https://patchwork.freedesktop.org/patch/msgid/20180518143008.4120-1-daniels@collabora.com
When we do shadowing, workload's request might not be allocated yet,
so we still require shadow context's object. And when complete workload,
delay to zero workload's request pointer after used for update guest context.
v2: Move request alloc earlier as already try to track shadow status
depending on request state, which also facilitate to use request->hw_context
for target engine context reference.
Fixes: 1fc44d9b1a ("drm/i915: Store a pointer to intel_context in i915_request")
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.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/20180521081752.31056-1-zhenyuw@linux.intel.com
When testing reset, we wait for 1s on the main thread for the hang to
start. Meanwhile, we continue submitting requests on all the background
threads, and we may have more threads than cores and so potentially
starve the waiter from being woken within the timeout. As the hang
timeout and the active timeouts are the same, it is hard to distinguish
which caused the timeout. Bump the active thread timeouts to 5s,
compared to the 1s timeout for the hang, so that we preferentially
report the hang timing out, while hopefully ensuring that we do at least
wake up the hang thread first before declaring the background active
timeout.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517142442.16979-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
In order to support engine reset from irq (timer) context, we need to be
able to re-initialise the breadcrumbs. So we need to promote the plain
spin_lock_irq to a safe spin_lock_irqsave.
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/20180518090212.5349-3-chris@chris-wilson.co.uk
We want to be able to reset the GPU from inside a timer callback
(hardirq context). One step requires us to copy the default context
state over to the guilty context, which means we need to plan in advance
to have that object accessible from within an atomic context. The atomic
context prevents us from pinning the object or from peeking into the
shmemfs backing store (all may sleep), so we choose to pin the
default_state into memory when the engine becomes active. This
compromise allows us to swap out the default state when idle, when
required.
References: 5692251c25 ("drm/i915/lrc: Scrub the GPU state of the guilty hanging request")
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/20180518090212.5349-2-chris@chris-wilson.co.uk
To be useful later, enable intel_engine_dump() to be called from irq
context (i.e. using saving and restoring irq start rather than assuming
we enter with irqs enabled).
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/20180518090212.5349-1-chris@chris-wilson.co.uk
We rely on ksoftirqd to run in a timely fashion in order to drain the
execlists queue. Quite frequently, it does not. In some cases we may see
latencies of over 200ms triggering our idle timeouts and forcing us to
declare the driver wedged!
Thus we can speed up idle detection by bypassing ksoftirqd in these
cases and flush our tasklet to confirm if we are indeed still waiting
for the ELSP to drain.
v2: Put the execlists.first check back; it is required for handling
reset!
References: https://bugs.freedesktop.org/show_bug.cgi?id=106373
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: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180506171328.30034-1-chris@chris-wilson.co.uk
Almost all of the GEN7 checks in the DP code are actually looking for
IVB. HSW doesn't even take these codepaths, and VLV is excluded on
account of not having port A. So let's change the checks to IS_IVB to
make the code less confusing.
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-3-ville.syrjala@linux.intel.com
All DDI platforms support the full set of preemph settings for each
supported vswing, so let's use the same code for them. We'll also move
the code into intel_ddi.c so that it sits closer to the actual buf trans
tables.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-2-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Use intel_ddi_dp_voltage_max() for HSW/BDW too instead of letting these
fall through the if ladder in a weird way. This function will look at
the actual buf trans tables we have for HSW/BDW to determine the max
vswing level.
It looks to me like the current code leads HSW port A down the IVB port
A path, HSW port B+ and BDW fall through to the very end. Both cases do
result in the correct max vswing level 2, but it's very hard to see that
from the code.
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517170309.28630-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
As all backends implement the same pin_count mechanism and do a
dec-and-test as their first step, pull that into the common
intel_context_unpin(). This also pulls into the caller, eliminating the
indirect call in the usual steady state case. The intel_context_pin()
side is a little more complicated as it combines the lookup/alloc as
well as pinning the state, and so is left for a later date.
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/20180517212633.24934-4-chris@chris-wilson.co.uk
To ease the frequent and ugly pointer dance of
&request->gem_context->engine[request->engine->id] during request
submission, store that pointer as request->hw_context. One major
advantage that we will exploit later is that this decouples the logical
context state from the engine itself.
v2: Set mock_context->ops so we don't crash and burn in selftests.
Cleanups from Tvrtko.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Acked-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517212633.24934-3-chris@chris-wilson.co.uk
In the next patch, we want to store the intel_context pointer inside
i915_request, as it is frequently access via a convoluted dance when
submitting the request to hw. Having two context pointers inside
i915_request leads to confusion so first rename the existing
i915_gem_context pointer to i915_request.gem_context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517212633.24934-1-chris@chris-wilson.co.uk
The scheduler lock(gvt->sched_lock) is used to protect gvt
scheduler logic, including the gvt scheduler structure(gvt->scheduler
and per vgpu schedule data(vgpu->sched_data, vgpu->sched_ctl).
v9:
- Change commit author since the patches are improved a lot compared
with original version.
Original author: Pei Zhang <pei.zhang@intel.com>
- Rebase to latest gvt-staging.
v8:
- Correct coding wqstyle.
- Rebase to latest gvt-staging.
v7:
- Remove gtt_lock since already proteced by gvt_lock and vgpu_lock.
v6:
- Rebase to latest gvt-staging.
v5:
- Rebase to latest gvt-staging.
v4:
- Rebase to latest gvt-staging.
v3: update to latest code base
Signed-off-by: Pei Zhang <pei.zhang@intel.com>
Signed-off-by: Colin Xu <colin.xu@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
For all platforms that run haswell_crtc_enable, our spec tells us to
configure the transcoder clocks and do link training before it tells
us to set pipeconf and the other pipe/transcoder/plane registers.
Starting from Icelake, we get machine hangs if we try to touch the
pipe/transcoder registers without having the clocks configured and not
having some chicken bits set. So this patch changes
haswell_crtc_enable() to issue the calls at the appropriate order
mandated by the spec.
While setting the appropriate chicken bits would also work here, it's
better if we actually program the hardware the way it is intended to
be programmed. And the chicken bit also has some theoretical downsides
that may or may not affect us. Also, correctly programming the
hardware does not prevent us from setting the chicken bits in a later
patch in case we decide to.
v2: Don't forget link training (Ville).
Cc: Arthur J Runyan <arthur.j.runyan@intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502215851.30736-1-paulo.r.zanoni@intel.com
Stop reading some now deprecated interrupt registers in both
debugfs and error state. Instead, read the new equivalents in the
Gen11 interrupt repartitioning scheme.
Note that the equivalent to the PM ISR & IIR cannot be read without
affecting the current state of the system, so I've opted for leaving
them out. See gen11_reset_one_iir() for more info.
v2: else if !!! (Paulo)
v3: another else if (Vinay)
v4:
- Rebased
- Renamed patch
- Improved the ordering of GENs
- Improved the printing of per-GEN info
v5: Avoid maybe-unitialized & add comment explaining the lack
of PM ISR & IIR
Suggested-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
Reviewed-by: Vinay Belgaumkar <vinay.belgaumkar@intel.com>
[Paulo: fix commit message and coding style.]
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525989595-18220-1-git-send-email-oscar.mateo@intel.com
The command parser is feature complete, stable and required by
userspace. In commit 41736a8e33 ("drm/i915: Use the precomputed value
for whether to enable command parsing") I accidentally removed control
from the modparam, and as no one has complained, remove the left
over modparam completely!
References: 41736a8e33 ("drm/i915: Use the precomputed value for whether to enable command parsing")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517150727.10431-1-chris@chris-wilson.co.uk
Make sure that when we don't have any scheduler attributes for the
request, the string is terminated.
Fixes: 247870ac8e ("drm/i915: Build request info on stack before printk")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517152824.11619-1-chris@chris-wilson.co.uk
The HWACK bit more generically solves the problem of resubmitting ESLP
while the hardware is still processing the current ELSP write. We no
longer need to check port[0].count itself.
References: ba74cb10c7 ("drm/i915/execlists: Delay writing to ELSP until HW has processed the previous write")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180517115647.17205-1-chris@chris-wilson.co.uk
Parametrize the DVO pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514172423.9302-5-ville.syrjala@linux.intel.com
Parametrize the TV pipe select bits.
For consistency with the new way of doing things, let's read out the
pipe select bits even when the port is disable, even though we don't
need that behaviour for asserts in this case.
v2: Order the defines shift,mask,value (Jani)
Clear the stale pipe select bit in load detection (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514172423.9302-4-ville.syrjala@linux.intel.com
Clean up the SDVO pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514172423.9302-3-ville.syrjala@linux.intel.com
Clean up the LVDS pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Drop ruperfluous braces and whitesapce changes (Jani)
Combine masks in compute_is_dual_link_lvds() (Jani)
v3: Fix LVDS_PIPE_SEL_MASK_CPT
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514182827.28629-1-ville.syrjala@linux.intel.com
Clean up the ADPA pipe select bits. To make the whole situation a bit
less ugly we'll start to share the same code between .get_hw_state()
and the port state asserts.
v2: Order the defines shift,mask,value (Jani)
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180514172423.9302-1-ville.syrjala@linux.intel.com
Added encoding of drm content_type property from drm_connector_state
within AVI infoframe in order to properly handle external HDMI TV
content-type setting.
This requires also manipulationg ITC bit, as stated in
HDMI spec.
v2:
* Moved helper function which attaches content type property
to the drm core, as was suggested.
Removed redundant connector state initialization.
v3:
* Removed caps in drm_content_type_enum_list.
After some discussion it turned out that HDMI Spec 1.4
was wrongly assuming that IT Content(itc) bit doesn't affect
Content type states, however itc bit needs to be manupulated
as well. In order to not expose additional property for itc,
for sake of simplicity it was decided to bind those together
in same "content type" property.
v4:
* Added it_content checking in intel_digital_connector_atomic_check.
Fixed documentation for new content type enum.
v5:
* Moved patch revision's description to commit messages.
v6:
* Minor naming fix for the content type enumeration string.
v7:
* Fix parameter name for documentation and parameter alignment
in order not to get warning. Added Content Type description to
new HDMI connector properties section.
v8:
* Thrown away unneeded numbers from HDMI content-type property
description. Switch to strings desription instead of plain
definitions.
v9:
* Moved away hdmi specific content-type enum from
drm_connector_state. Content type property should probably not
be bound to any specific connector interface in
drm_connector_state.
Same probably should be done to hdmi_picture_aspect_ration enum
which is also contained in drm_connector_state. Added special
helper function to get derive hdmi specific relevant infoframe
fields.
v10:
* Added usage description to HDMI properties kernel doc.
v11:
* Created centralized function for filling HDMI AVI infoframe, based
on correspondent DRM property value.
Acked-by: Hans Verkuil <hans.verkuil@cisco.com>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180515135928.31092-3-stanislav.lisovskiy@intel.com
[vsyrjala: clean up checkpatch multiple blank lines warnings]
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Compute the offset of the end of the crc32 field using offsetofend()
rather than open-coding.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We cannot call kthread_park() from softirq context, so let's avoid it
entirely during the reset. We wanted to suspend the signaler so that it
would not mark a request as complete at the same time as we marked it as
being in error. Instead of parking the signaling, stop the engine from
advancing so that the GPU doesn't emit the breadcrumb for our chosen
"guilty" request.
v2: Refactor setting STOP_RING so that we don't have the same code thrice
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michałt Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-8-chris@chris-wilson.co.uk
Catch up with the inflight CSB events, after disabling the tasklet
before deciding which request was truly guilty of hanging the GPU.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-7-chris@chris-wilson.co.uk
Pull the CSB event processing into its own routine so that we can reuse
it during reset to flush any missed interrupts/events.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-6-chris@chris-wilson.co.uk
In the next patch, we will make the execlists reset prepare callback
take into account preemption by flushing the context-switch handler.
This is not applicable to the GuC submission backend, so split the two
into their own backend callbacks.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-5-chris@chris-wilson.co.uk
In preparation to more carefully handling incomplete preemption during
reset by execlists, we move the existing code wholesale to the backends
under a couple of new reset vfuncs.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Reviewed-by: Jeff McGee <jeff.mcgee@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-4-chris@chris-wilson.co.uk
As a complement to inject_preempt_context(), follow up with the function
to handle its completion. This will be useful should we wish to extend
the duties of the preempt-context for execlists.
v2: And do the same for the guc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Reviewed-by: Jeff McGee <jeff.mcgee@intel.com> #v1
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-3-chris@chris-wilson.co.uk
When setting up reset, we may need to recursively prepare an engine. In
which case we should only synchronously flush the tasklets on the outer
most call, the inner calls will then be inside an atomic section where
the tasklet will never be run (and so the sync will never complete).
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/20180516183355.10553-2-chris@chris-wilson.co.uk
The idea was to try and let the existing tasklet run to completion
before we began the reset, but it involves a racy check against anything
else that tries to run the tasklet. Rather than acknowledge and ignore
the race, let it be and don't try and be too clever.
The tasklet will resume execution after reset (after spinning a bit
during reset), but before we allow it to resume we will have cleared all
the pending state.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180516183355.10553-1-chris@chris-wilson.co.uk
When switching to the kernel context, we force the switch to occur after
all currently active requests (so that we know the GPU won't switch
immediately away and the kernel context remains current as we work). To
do so we have to inspect all the timelines and add a fence from the
active work to queue our switch afterwards. We can use the tracked set
of active rings to shrink our search for active timelines.
v2: Use a local to shrink the list_for_each_entry()
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/20180515143149.4795-1-chris@chris-wilson.co.uk
Guest OS driver uses PV info registers to deliver cursor hotspot info
to host. This patch is used to get cursor hotspot info from virtual
registers and deliver it to host userspace.
v4->v5:
- remove CI warning.
v3->v4:
- return UINT_MAX when x_hot/y_hot is invalid. (Zhenyu)
- correct version.
v2->v3:
- add validate_hotspot(). (Zhenyu)
v1->v2:
- name as cursor_x_hot/cursor_y_hot. (Zhenyu)
- use i915_reg_t definition instead of magic numbers. (Zhenyu)
Signed-off-by: Tina Zhang <tina.zhang@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Zhi Wang <zhi.a.wang@intel.com>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
UAPI Changes:
- Fix render node number regression from control node removal.
Driver Changes:
- Small header fix for virgl, used by qemu.
- Use vm_fault_t in qxl.
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAlr6l0MACgkQ/lWMcqZw
E8NFURAAkZ9TqzHRcn/3fMijuv/JslT0mW4CIFw3jm5diCXqrsKQ7TlQK8/q5uys
2vLgsTIKFzIp73ptUf11vyoKnvZA5SHHt55s2glrTDfKS9dkmgP+DcMab6qN31Y3
sPY54o0R/8lBd8YOZh8nfYbHngoeD4SHPIzZYETssklhip/CupMcHs2GtXlsO8nP
9ZNZyJHz0/GQUagUrFRgmVmq1ZF9t9Ap8fVBrkWUoQ02MogTFrPCj6F5AuBds9hR
ZRhGZLu3Ri1BdP06JraDTvbWZ8jQKF9yD4PuQVGAjkuz4LpRrNQCCKJQ+GMSXMTK
JmOB5Yty6/pN+WS+FeV7czbdS/bJDXLXzRh9dc0WOop4gCZPzmYC9HOBSZCZ8i1k
dcpGsJGcgzXgFSgZYISkkn50YUnbdjk44tonSK1qAWvNuo4SdZJFGoMoE3Mxf3/R
LMlfskWX3w8jzo7cWFkSvkh5Zt9MEaKJRKOGm4VUXidZSN/3/ZI1GbyRCZ8eeGxr
R6FK7GYHszBS+whWsA0NcX4KwS7qbktm5JGKpZCevIh9cscBVzQ3tbIugV0EgfAm
8VK1F9VU760pXoN+RRfdH61nZ2QTzmDGZwVtTz0ta5MlkW7YY4bvL5PNbUXYffaK
4EOk/RypONazqJ0B2ZUEHC47/8ETlfJ0bnYIqfR6O7bo7KPfWGQ=
=LG6G
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2018-05-15' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.18:
UAPI Changes:
- Fix render node number regression from control node removal.
Driver Changes:
- Small header fix for virgl, used by qemu.
- Use vm_fault_t in qxl.
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Tue 15 May 2018 06:16:03 PM AEST
# gpg: using RSA key FE558C72A67013C3
# gpg: Can't check signature: public key not found
Link: https://patchwork.freedesktop.org/patch/msgid/e63306b9-67a0-74ab-8883-08b3d9db72d2@mblankhorst.nl
- Add IPP v2 framework.
. it is a rewritten version of the Exynos mem-to-mem image processing
framework which supprts color space conversion, image up/down-scaling
and rotation. This new version replaces existing userspace API with
new easy-to-use and simple ones so we have already applied the use of
these API to real user, Tizen Platform[1], and also makes existing
Scaler, FIMC, GScaler and Rotator drivers to use IPP v2 core API.
And below are patch lists we have applied to a real user,
https://git.tizen.org/cgit/platform/adaptation/samsung_exynos/libtdm-exynos/log/?h=tizen&qt=grep&q=ipphttps://git.tizen.org/cgit/platform/adaptation/samsung_exynos/libtdm-exynos/commit/?h=tizen&id=b59be207365d10efd489e6f71c8a045b558c44fehttps://git.tizen.org/cgit/platform/kernel/linux-exynos/log/?h=tizen&qt=grep&q=ipp
TDM(Tizen Display Manager) is a Display HAL for Tizen platform.
Ps. Only real user using IPP API is Tizen.
[1] https://www.tizen.org/
- Two cleanups
. One is to just remove mode_set callback from MIPI-DSI driver
because drm_display_mode data is already available from crtc
atomic state.
. And other is to just use new return type, vm_fault_t
for page fault handler.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQIcBAABAgAGBQJa+Q9ZAAoJEFc4NIkMQxK4i3gQAJywYuOpyg1z8WeHDjizIh3D
CST10ftIrOnPozBf9TVJwgP3v+5i8md3ZJ6QuWIE1Zl/KZne5KEjsHxQcB/Ktlxd
bjZk5NtK/K5W4BWEASA1x2unrl1QEcyoOlXwNWWLbHjZidCqtuTgnuNcCdwqYWw8
e9Hid6w+qnQIyAQnJWv7Ue7IQXw79CNk4dlz5YIvILo2q23HUgHGW0qmz4OHiaF2
DiDUn/O/246WODagOJADXdjkb/BuksPATwHfyKcjU67wy0kCGnY2WQK7UC5piDi9
oKwFyzAKWnK10Wq9MElkFwyK6jrygLCmyglsuNs9hJ0HhDjGm15TI0MhQuQzx7H8
hL1IdgGIgW0CfFdrP6fDFZE7x6vEyW+gir0g0lVkV8Mq5XMaRs93RXDxGPKmSCg/
7oVcdy9nVMwLzVH9RmJrErQbtGFSIHmWyleg402NNqRMrBdmMKzlmHLSEvXRzp2/
6NThm1wG7yjh7w8hI2+nfGA4REgBp/rwyuL9JG2aO8cilAkv7jF30Z/B9k1YSaVm
qWy8H1Xo42dTyCzP0Ys9LXeyfjQ+DqFAa7HeM/9iHK8xE3Kl4fD3AuxtxR0IPqWX
gcs6CEHh69mnUrHvyNu74FbZY0Dptbfcl+nH9krmNDRwyqjl30zRDfswU9eIpOgS
/f01g2ztY9ht8EnKZkYU
=M74Y
-----END PGP SIGNATURE-----
Merge tag 'exynos-drm-next-for-v4.18' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next
- Add S5PV210 FIMD variant support.
- Add IPP v2 framework.
. it is a rewritten version of the Exynos mem-to-mem image processing
framework which supprts color space conversion, image up/down-scaling
and rotation. This new version replaces existing userspace API with
new easy-to-use and simple ones so we have already applied the use of
these API to real user, Tizen Platform[1], and also makes existing
Scaler, FIMC, GScaler and Rotator drivers to use IPP v2 core API.
And below are patch lists we have applied to a real user,
https://git.tizen.org/cgit/platform/adaptation/samsung_exynos/libtdm-exynos/log/?h=tizen&qt=grep&q=ipphttps://git.tizen.org/cgit/platform/adaptation/samsung_exynos/libtdm-exynos/commit/?h=tizen&id=b59be207365d10efd489e6f71c8a045b558c44fehttps://git.tizen.org/cgit/platform/kernel/linux-exynos/log/?h=tizen&qt=grep&q=ipp
TDM(Tizen Display Manager) is a Display HAL for Tizen platform.
Ps. Only real user using IPP API is Tizen.
[1] https://www.tizen.org/
- Two cleanups
. One is to just remove mode_set callback from MIPI-DSI driver
because drm_display_mode data is already available from crtc
atomic state.
. And other is to just use new return type, vm_fault_t
for page fault handler.
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Mon 14 May 2018 14:23:53 AEST
# gpg: using RSA key 573834890C4312B8
# gpg: Can't check signature: public key not found
Link: https://patchwork.freedesktop.org/patch/msgid/1526276453-29879-1-git-send-email-inki.dae@samsung.com
We assume that the CSB is written using the normal ringbuffer
coherency protocols, as outlined in kernel/events/ring_buffer.c:
* (HW) (DRIVER)
*
* if (LOAD ->data_tail) { LOAD ->data_head
* (A) smp_rmb() (C)
* STORE $data LOAD $data
* smp_wmb() (B) smp_mb() (D)
* STORE ->data_head STORE ->data_tail
* }
So we assume that the HW fulfils its ordering requirements (B), and so
we should use a complimentary rmb (C) to ensure that our read of its
WRITE pointer is completed before we start accessing the data.
The final mb (D) is implied by the uncached mmio we perform to inform
the HW of our READ pointer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105064
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
References: https://bugs.freedesktop.org/show_bug.cgi?id=106185
Fixes: 767a983ab2 ("drm/i915/execlists: Read the context-status HEAD from the HWSP")
References: 61bf9719fa ("drm/i915/cnl: Use mmio access to context status buffer")
Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511121147.31915-1-chris@chris-wilson.co.uk
(cherry picked from commit 77dfedb5be)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Operating on a zero sized GEM userptr object will lead to explosions.
Fixes: 5cc9ed4b9a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
Testcase: igt/gem_userptr_blits/input-checking
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/20180502195021.30900-1-matthew.auld@intel.com
(cherry picked from commit c11c7bfd21)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
When we process the outstanding requests upon banning a context, we need
to acquire both the engine and the client's timeline, nesting the locks.
This requires explicit markup as the two timelines are now of the same
class, since commit a89d1f921c ("drm/i915: Split i915_gem_timeline into
individual timelines").
Testcase: igt/gem_eio/banned
Fixes: a89d1f921c ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180512084957.9829-1-chris@chris-wilson.co.uk
The original switch to use CSB from the HWSP was plagued by the effect
of read ordering on VT-d; we would read the WRITE pointer from the HWSP
before it had completed writing the CSB contents. The mystery comes down
to the lack of rmb() for correct ordering with respect to the writes
from HW, and with that resolved we can remove the VT-d special casing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511121147.31915-3-chris@chris-wilson.co.uk
Tested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
This reverts commit 11474e9091.
There are issues which will block the host preemption before, instead of
disabling it use one workaround "setting max priority for gvt context"
to avoid the gvt context be preempted by the host. Now the issues have been
cleared, so revert this patch to enable host preemption.
v2:
- refine description(Zhenyu)
Signed-off-by: Weinan Li <weinan.z.li@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
the cmd_reg_handler() is called by cmds LRM, PIPE_CTRL, SRM...
for LRM, SRM, we cannot get write data in a simple way.
On other side, the force_to_nonpriv reigsters will only be written in LRI
in current drivers. so we don't want to bother the handler to handle those
memory access cmds, just leave a print message here.
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Return error will cause vm hang and enter failsafe mode.
However, we don't want that happen on detecting an wrong force_to_nonpriv
register write.
Therefore, we just omit the wrong write or patch it to default value.
v2: only return 0 on detecting lri write of registers outside whitelist,
but still return error on other error conditions. (zhenyu wang)
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Reviewed-by: Zhang Yulei <yulei.zhang@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Each ring has a NOPID register and currently they are regarded as default
value of force_to_nonpriv registers in guest drivers
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
The disable_warn_untrack never prevent gvt from printing untracked
mmio errors. We were disturbed by this error storm and the fix is
just adding them to the list with no essential new change.
This message is only useful for enabling new platform during
developing process. So lower the message level to debug and then
remove disable_warn_untrack.
Signed-off-by: Changbin Du <changbin.du@intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We write all 4K page entries, even when using 64K pages. In order to
verify that the HW isn't cheating by using the 4K PTE instead of the 64K
PTE, we want to remove all the surplus entries. If the HW skipped the
64K PTE, it will read/write into the scratch page instead - which we
detect as missing results during selftests.
v2: much improved commentary (Chris)
Signed-off-by: Matthew Auld <matthew.auld@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Changbin Du <changbin.du@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/20180511095140.25590-1-matthew.auld@intel.com
Before we unpin the buffer used for OA reports and return it to the
system, we need to be sure that the HW has finished writing into it.
For lack of a better idea, poll OACONTROL to check it is switched off.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106379
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Tested-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511135207.12880-1-chris@chris-wilson.co.uk
In the previous patch (to include a rmb() after readig the CSB WRITE
pointer from the HWSP) we believe we have fixed the underlying bug, and
so can re-enable using the HWSP on Cannolake.
This reverts commit 61bf9719fa ("drm/i915/cnl: Use mmio access to
context status buffer").
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
References: https://bugs.freedesktop.org/show_bug.cgi?id=106185
References: 61bf9719fa ("drm/i915/cnl: Use mmio access to context status buffer")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511121147.31915-2-chris@chris-wilson.co.uk
We assume that the CSB is written using the normal ringbuffer
coherency protocols, as outlined in kernel/events/ring_buffer.c:
* (HW) (DRIVER)
*
* if (LOAD ->data_tail) { LOAD ->data_head
* (A) smp_rmb() (C)
* STORE $data LOAD $data
* smp_wmb() (B) smp_mb() (D)
* STORE ->data_head STORE ->data_tail
* }
So we assume that the HW fulfils its ordering requirements (B), and so
we should use a complimentary rmb (C) to ensure that our read of its
WRITE pointer is completed before we start accessing the data.
The final mb (D) is implied by the uncached mmio we perform to inform
the HW of our READ pointer.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105064
References: https://bugs.freedesktop.org/show_bug.cgi?id=105888
References: https://bugs.freedesktop.org/show_bug.cgi?id=106185
Fixes: 767a983ab2 ("drm/i915/execlists: Read the context-status HEAD from the HWSP")
References: 61bf9719fa ("drm/i915/cnl: Use mmio access to context status buffer")
Suggested-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Rafael Antognolli <rafael.antognolli@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Timo Aaltonen <tjaalton@ubuntu.com>
Tested-by: Timo Aaltonen <tjaalton@ubuntu.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Acked-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180511121147.31915-1-chris@chris-wilson.co.uk
Avoids a hang during soft reset.
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
v4:
- Rebased
- C, not lisp (Chris)
- Which steppings affected by this are not clear.
For the moment, apply unconditionally as per the
BSpec (Mika)
- Add reference to another HSD also related
References: HSDES#1405476379
References: HSDES#2006612137
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-14-git-send-email-oscar.mateo@intel.com
Disable CGPSF unit clock gating to prevent an issue.
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
v4:
- Rebased
- C, not lisp (Chris)
- Remove unintentional whitespaces (Mika)
- Fixed in C0 (Mika)
References: HSDES#1406838659
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-13-git-send-email-oscar.mateo@intel.com
Disable I2M Write for performance reasons.
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
v4:
- Rebased
- C, not lisp (Chris)
- GEN7 chicken bit in the wrong side of the fence (Mika)
- Use two spaces to align bit macros
References: HSDES#1604302699
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-12-git-send-email-oscar.mateo@intel.com
Disable GWL clock gating to prevent an issue that might
cause hangs.
v2: Rebased on top of the WA refactoring
v3: Wa_2201832410 officially merged with Wa_1406680159
v4: Added References (Mika)
v5:
- Rebased
- C, not lisp (Chris)
- Add reference where WA is better explained (Rodrigo)
- Add reference to WA that got merged with this
References: HSDES#1406681710
References: HSDES#1406680159
References: HSDES#2201832410
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-11-git-send-email-oscar.mateo@intel.com
Disable MSC clock gating to prevent data corruption.
BSpec: 19257
v2: Rebased on top of the WA refactoring
v3: Added References (Mika)
v4:
- Rebased
- C, not lisp (Chris)
- A0 only (Mika)
References: HSDES#1405779004
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-10-git-send-email-oscar.mateo@intel.com
Revert to the legacy implementation to avoid a system hang.
v2: Correct the address for GAMW_ECO_DEV_RW_IA_REG
v3: Renamed to Wa_220166154
v4: Rebased on top of the WA refactoring
v5: Added References (Mika)
v6:
- Rebased
- C, not lisp (Chris)
References: HSDES#220166154
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-9-git-send-email-oscar.mateo@intel.com
This workarounds an issue with insufficient storage for the
CL2 and SF units.
v2: Renamed to Wa_1405766107
v3: Wrapped the commit message
v4: Rebased on top of the WA refactoring
v5: Added References (Mika)
v6:
- Rebased
- s/MACALLOC/MAXALLOC (Mika)
- C, not lisp (Chris)
References: HSDES#1405766107
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-8-git-send-email-oscar.mateo@intel.com
Avoids an undefined LLC behavior.
BSpec: 9613
v2: Renamed to Wa_1405733216
v3: Spaces around '<<' and fix surrounding code
v4: Rebased on top of the WA refactoring
v5: Added References (Mika)
v6:
- Rebased
- C, not lisp (Chris)
References: HSDES#1405733216
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-7-git-send-email-oscar.mateo@intel.com
Adjust default GAM TLB partitioning for performance reasons.
v2: Only touch the bits that we really need
v3: Rebased on top of the WA refactoring
v4:
- Added References (Mika)
- Rebased
v5:
- Rebased
- C, not lisp (Chris)
- Correct reference number (Mika)
References: HSDES#220160670
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-6-git-send-email-oscar.mateo@intel.com
Revert to an L3 non-hash model, for performance reasons.
v2:
- Place the WA name above the actual change
- Improve the register naming
v3:
- Rebased
- Renamed to Wa_1604223664
v4: Rebased on top of the WA refactoring
v5:
- Added References (Mika)
- Fixed wrong mask and value (Mika)
- Do not apply together with another WA for the same
register (not worth the hassle)
v6:
- Rebased
- C, not lisp (Chris)
References: HSDES#1604223664
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-5-git-send-email-oscar.mateo@intel.com
The default GAPZ arbitrer priority value at power-on has been found
to be incorrect.
v2: Now renamed to Wa_1405543622
v3: Rebased on top of the WA refactoring
v4: Added HSDES reference number (Mika)
v5:
- Rebased
- C, not lisp (Chris)
References: HSDES#1405543622
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-4-git-send-email-oscar.mateo@intel.com
Sampler Dynamic Frequency Rebalancing (DFR) aims to reduce Sampler
power by dynamically changing its clock frequency in low-throughput
conditions. This patches enables it by default on Gen11.
v2: Wrong operation to clear the bit (Praveen)
v3: Rebased on top of the WA refactoring
v4: Move to icl_init_clock_gating, since it's not a WA (Rodrigo)
v5: C, not lisp (Chris)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Praveen Paneri <praveen.paneri@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-3-git-send-email-oscar.mateo@intel.com
Inherit workarounds from previous platforms that are still valid for
Icelake.
v2: GEN7_ROW_CHICKEN2 is masked
v3:
- Since it has been fixed already in upstream, removed the TODO
comment about WA_SET_BIT for WaInPlaceDecompressionHang.
- Squashed with this patch:
drm/i915/icl: add icelake_init_clock_gating()
from Paulo Zanoni <paulo.r.zanoni@intel.com>
- Squashed with this patch:
drm/i915/icl: WaForceEnableNonCoherent
from Oscar Mateo <oscar.mateo@intel.com>
- WaPushConstantDereferenceHoldDisable is now Wa_1604370585 and
applies to B0 as well.
- WaPipeControlBefore3DStateSamplePattern WABB was being applied
to ICL incorrectly.
v4:
- Wrap the commit message
- s/dev_priv/p to please checkpatch
v5: Rebased on top of the WA refactoring
v6: Rebased on top of further whitelist registers refactoring (Michel)
v7: Added WaRsForcewakeAddDelayForAck
v8: s/ICL_HDC_CHICKEN0/ICL_HDC_MODE (Mika)
v9:
- C, not lisp (Chris)
- WaIncreaseDefaultTLBEntries is the same for GEN > 9_LP (Tvrtko)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525814984-20039-2-git-send-email-oscar.mateo@intel.com
This patch adds NV12 to list of supported formats for sprite plane.
v2: Rebased (me)
v3: Review comments by Ville addressed
- Removed skl_plane_formats_with_nv12 and added
NV12 case in existing skl_plane_formats
- Added the 10bpc RGB formats
v4: Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Removed 10bit RGB formats added previously with NV12 series
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
Addressed review comments from Clinton A Taylor
"Why are we adding 10 bit RGB formats with the NV12 series patches?
Trying to set XR30 or AB30 results in error returned even though
the modes are advertised for the planes"
- Previous version has 10bit RGB format removed from VLV formats
by mistake. Fixing that in this version.
Removed 10bit RGB formats added previously with NV12 series
for SKL.
v6: Addressed review comments by Ville
Restricting the NV12 to BXT and PIPE A and B
v7: Rebased (me)
v8: Rebased (me)
Restricting NV12 changes to BXT and KBL
Restricting NV12 changes for plane 0 (overlay)
v9: Rebased (me)
v10: Addressed review comments from Maarten.
Adding NV12 to skl_plane_formats itself.
v11: Addressed review comments from Shashank Sharma
v12: Addressed review comments from Shashank Sharma
Made the condition in intel_sprite_plane_create
simple and easy to read as suggested.
v13: Adding reviewed by tag from Shashank Sharma
Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v14: Addressed review comments from Ville
Added skl_planar_formats to include NV12
and a check skl_plane_has_planar in sprite create
Added NV12 format to skl_mod_supported. These were
review comments from Kristian Høgsberg <hoegsberg@gmail.com>
v15: Added reviewed by from Juha-Pekka Heikkila
v16: Rebased the series
v17: Added all tiling under mod supported for NV12
Credits to Megha Aggarwal
v18: Added RB by Maarten and Kristian
v19: Addressed review comments from Maarten
Made modification to skl_mod_supported
Credits-to: Megha Aggarwal <megha.aggarwal@intel.com>
Credits-to: Kristian Høgsberg <hoegsberg@gmail.com>
Reviewed-by: Kristian Høgsberg <hoegsberg@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526074397-10457-7-git-send-email-vidya.srinivas@intel.com
This patch adds NV12 to list of supported formats for
primary plane
v2: Rebased (Chandra Konduru)
v3: Rebased (me)
v4: Review comments by Ville addressed
Removed the skl_primary_formats_with_nv12 and
added NV12 case in existing skl_primary_formats
v5: Rebased (me)
v6: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v7: Review comments by Ville addressed
Restricting the NV12 for BXT and on PIPE A and B
Rebased (me)
v8: Rebased (me)
Modified restricting the NV12 support for both BXT and KBL.
v9: Rebased (me)
v10: Addressed review comments from Maarten.
Adding NV12 inside skl_primary_formats itself.
v11: Adding Reviewed By tag from Shashank Sharma
v12: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v13: Addressed review comments from Ville
Added skl_pri_planar_formats to include NV12
and skl_plane_has_planar function to check for
NV12 support on plane. Added NV12 format to
skl_mod_supported. These were review comments
from Kristian Høgsberg <hoegsberg@gmail.com>
v14: Added reviewed by from Juha-Pekka Heikkila
v15: Rebased the series
v16: Added all tiling support under mod supported
for NV12. Credits to Megha Aggarwal
v17: Added RB by Maarten and Kristian
v18: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826
v19: Addressed review comments from Maarten
Make changes to skl_mod_supported
Credits-to: Megha Aggarwal megha.aggarwal@intel.com
Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Kristian Høgsberg <hoegsberg@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526074397-10457-6-git-send-email-vidya.srinivas@intel.com
This patch adds NV12 as supported format
to intel_framebuffer_init and performs various checks.
v2:
-Fix an issue in checks added (Chandra Konduru)
v3: rebased (me)
v4: Review comments by Ville addressed
Added platform check for NV12 in intel_framebuffer_init
Removed offset checks for NV12 case
v5: Addressed review comments by Clinton A Taylor
This NV12 support only correctly works on SKL.
Plane color space conversion is different on GLK and later platforms
causing the colors to display incorrectly.
Ville's plane color space property patch series
in review will fix this issue.
- Restricted the NV12 case in intel_framebuffer_init to
SKL and BXT only.
v6: Rebased (me)
v7: Addressed review comments by Ville
Restricting the NV12 to BXT for now.
v8: Rebased (me)
Restricting the NV12 changes to BXT and KBL for now.
v9: Rebased (me)
v10: NV12 supported by all GEN >= 9.
Making this change in intel_framebuffer_init. This is
part of addressing Maarten's review comments.
Comment under v8 no longer applicable
v11: Addressed review comments from Shashank Sharma
v12: Adding Reviewed By from Shashank Sharma
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
v14: Addressed review comments from Maarten.
Add checks for fb width height for NV12 and fail the fb
creation if check fails. Added reviewed by from
Juha-Pekka Heikkila
v15: Rebased the series
v16: Setting the minimum value during fb creating to 16
as per Bspec for NV12. Earlier minimum was expected
to be > 16. Now changed it to >=16.
v17: Adding restriction to framebuffer_init - the fb
width and height should be a multiplier of 4
v18: Added RB from Maarten. Included Maarten's review comments
Dont allow CCS formats for fb creation of NV12
v19: Review comments from Maarten addressed -
Removing BROXTON support for NV12 due to WA826
Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526074397-10457-5-git-send-email-vidya.srinivas@intel.com
We skip src trunction/adjustments for
NV12 case and handle the sizes directly.
Without this, pipe fifo underruns are seen on APL/KBL.
v2: For NV12, making the src coordinates multiplier of 4
v3: Moving all the src coords handling code for NV12
to skl_check_nv12_surface
v4: Added RB from Mika
v5: Rebased the series. Removed checks of mult of 4 in
skl_update_scaler, Added NV12 condition in intel_check_sprite_plane
where src x/w is being checked for mult of 2 for yuv planes.
v6: Made changes to skl_check_nv12_surface as per WA#1106
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526074397-10457-4-git-send-email-vidya.srinivas@intel.com
Possible hang with NV12 plane surface formats.
WA: When the plane source pixel format is NV12,
the CHICKEN_PIPESL_* register bit 22 must be set to 1
and the render decompression must not be enabled
on any of the planes in that pipe.
v2: removed unnecessary POSTING_READ
v3: Added RB from Maarten
v4: Removed support for NV12 for BROXTON
Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526074397-10457-3-git-send-email-vidya.srinivas@intel.com
The workaround was applied only to the primary plane, but is required
on all planes. Iterate over all planes in the crtc atomic check to see
if the workaround is enabled, and only perform the actual toggling in
the pre/post plane update functions.
Changes since v1:
- Track active NV12 planes in a nv12_planes bitmask. (Ville)
v2: Removing BROXTON support for NV12 due to WA826
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1526074397-10457-2-git-send-email-vidya.srinivas@intel.com
Driver features data block has a boolean flag for PSR, use this to decide
whether PSR should be enabled on a platform. The module parameter can
still be used to override this.
Note: The feature currently remains disabled by default for all platforms
irrespective of what VBT says.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180509003524.3199-1-dhinakaran.pandiyan@intel.com
Prepare to allow the GuC submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.
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/20180508210318.10274-2-chris@chris-wilson.co.uk
Prepare to allow the execlists submission to be run from underneath a
hardirq timer context (and not just the current softirq context) as is
required for fast preemption resets and context switches.
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/20180508210318.10274-1-chris@chris-wilson.co.uk
In igt_flush_test() we try to switch back to the kernel context, but we
are only able to do so when we are called with struct_mutex held.
More of my CI fallout from lockdep being temporarily suppressed :(
Fixes: 4cdf65ce8c ("drm/i915/selftests: Return to kernel context after each test")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180509065926.19207-1-chris@chris-wilson.co.uk
Calling mock_engine() calls i915_timeline_init() and that requires
struct_mutex to be held as it adds itself to the global list of
timelines. This error was introduced by commit a89d1f921c ("drm/i915:
Split i915_gem_timeline into individual timelines") but the issue was
masked in CI by the earlier lockdep spam.
Fixes: a89d1f921c ("drm/i915: Split i915_gem_timeline into individual timelines")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508211056.17151-1-chris@chris-wilson.co.uk
The i915_flip* tracepoints are no longer in use since the removal of CS
flip in commit 8b5d27b911 ("drm/i915: Remove intel_flip_work
infrastructure")
References: 8b5d27b911 ("drm/i915: Remove intel_flip_work infrastructure")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508151552.31024-1-chris@chris-wilson.co.uk
During request submission, we call the engine->schedule() function so
that we may reorder the active requests as required for inheriting the
new request's priority. This may schedule several tasklets to run on the
local CPU, but we will need to schedule the tasklets again for the new
request. Delay all the local tasklets until the end, so that we only
have to process the queue just once.
v2: Beware PREEMPT_RCU, as then local_bh_disable() is then not a
superset of rcu_read_lock().
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-2-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
When called from process context tasklet_schedule() defers itself to
ksoftirqd. From experience this may cause unacceptable latencies of over
200ms in executing the submission tasklet, our goal is to reprioritise
the HW execution queue and trigger HW preemption immediately, so disable
bh over the call to schedule and force the tasklet to run afterwards if
scheduled.
v2: Keep rcu_read_lock() around for PREEMPT_RCU
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>
Link: https://patchwork.freedesktop.org/patch/msgid/20180507135731.10587-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
As we flush each test and wait for idle before the next, also switch
back to the kernel context. This helps limit the amount of collateral
damage a test may cause by resetting to the default state each time (and
also helps clean up temporaries used by the test).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508115312.12628-1-chris@chris-wilson.co.uk
Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.
Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.
This change increases the timeout of the `intel_enable_lvds` function
from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.
This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.
[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
code and properly cover the max hw timeout of ~4 seconds, and
drop the comment about the specific machine since this is not
a particulary surprising issue, nor specific to that one machine]
Signed-off-by: Florent Flament <contact@florentflament.com>
Cc: stable@vger.kernel.org
Cc: Pavel Petrovic <ppetrovic@acm.org>
Cc: Sérgio M. Basto <sergio@serjux.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
(cherry picked from commit 280b54ade5)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
scale the pipe contents. Let's preserve the pipe src size based
information in the user mode to make things consistent again.
This fixes a problem introduced by commit a2936e3d9a ("drm/i915:
Use drm_mode_get_hv_timing() to populate plane clip rectangle")
where the inconsistent state is now leading the plane clipping code
to report a failure on account the plane dst coordinates not matching
the user mode size. Previously we did the plane clipping based on
the pipe src size instead and thus never noticed the inconsistency.
The failure manifests as a WARN:
[ 0.762117] [drm:intel_dump_pipe_config [i915]] requested mode:
[ 0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa
...
[ 0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src size: 1024x768, pixel rate 72143
...
[ 0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane must cover entire CRTC
[ 0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0
[ 0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0
[ 0.764713] ------------[ cut here ]------------
[ 0.764714] Could not determine valid watermarks for inherited state
[ 0.764792] WARNING: CPU: 4 PID: 159 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 [i915]
...
Cc: FadeMind <fademind@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: FadeMind <fademind@gmail.com>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Tested-by: Dave Jones <davej@codemonkey.org.uk>
References: https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992
Fixes: a2936e3d9a ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426163015.14232-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: FadeMind <fademind@gmail.com>
(cherry picked from commit bd4cd03c81)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
On intel_dp_compute_config() we were calculating the needed vco
for eDP on gen9 and we stashing it in
intel_atomic_state.cdclk.logical.vco
However few moments later on intel_modeset_checks() we fully
replace entire intel_atomic_state.cdclk.logical with
dev_priv->cdclk.logical fully overwriting the logical desired
vco for eDP on gen9.
So, with wrong VCO value we end up with wrong desired cdclk, but
also it will raise a lot of WARNs: On gen9, when we read
CDCLK_CTL to verify if we configured properly the desired
frequency the CD Frequency Select bits [27:26] == 10b can mean
337.5 or 308.57 MHz depending on the VCO. So if we have wrong
VCO value stashed we will believe the frequency selection didn't
stick and start to raise WARNs of cdclk mismatch.
[ 42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 42.897269] cdclk state doesn't match!
[ 42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915]
[ 43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
v2: Move the entire eDP's vco logical adjustment to inside
the skl_modeset_calc_cdclk as suggested by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: bb0f4aab0e ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies")
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com
(cherry picked from commit 3297234a05)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Add some onion to populate_lr_context.
v2: prefer err_unpin_ctx
drop the fixes tag, worst case we just spew a warn before everything
is cleaned up and balance is restored
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>
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/20180301114639.510-1-matthew.auld@intel.com
igt_ctx_exec() expects that we retire all active requests/objects before
completing, so that when we clean up the files afterwards they are ready
to be freed. Before we do so, it is then prudent to ensure that we have
indeed retired the GPU activity, raising an error if it fails. If we do
not, we run the risk of triggering an assertion when freeing the object:
__i915_gem_free_objects:4793 GEM_BUG_ON(i915_gem_object_is_active(obj))
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/20180505091014.26126-2-chris@chris-wilson.co.uk
Operating on a zero sized GEM userptr object will lead to explosions.
Fixes: 5cc9ed4b9a ("drm/i915: Introduce mapping of user pages into video memory (userptr) ioctl")
Testcase: igt/gem_userptr_blits/input-checking
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/20180502195021.30900-1-matthew.auld@intel.com
When rescheduling a change of dependencies, they all need to be added to
the same priolist (at least the ones on the same engine!). Since we
likely want to move a batch of requests, keep the priolist around.
v2: Throw in an assert to catch trivial errors quickly.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-2-chris@chris-wilson.co.uk
lookup_priolist() no longer attaches the request into the priolist, it
just returns the priolist for the given priority instead. Drop the
unused parameter.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180508003046.2633-1-chris@chris-wilson.co.uk
Unsafe module parameters are just that, unsafe. If the user is foolish
enough to try them and the kernel breaks, they get to keep both pieces.
Don't ask them to file a bug report if they broke it themselves.
References: https://bugs.freedesktop.org/show_bug.cgi?id=106423
Fixes: d15d7538c6 ("drm/i915: Tune down init error message due to failure injection")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180506183147.2690-1-chris@chris-wilson.co.uk
This implements the "MG PLL Programming" sequence from our spec. The
biggest problem was that the spec assumes real numbers, so we had to
adjust some numbers and calculations due to the fact that the Kernel
prefers to deal with integers.
I recommend grabbing some coffee, a pen and paper before reviewing
this patch.
v2:
- Correctly identify DP encoders after upstream change.
- Small checkpatch issues.
- Rebase.
v3:
- Try to impove the comment on the tdc_targetcnt calculation based on
Manasi's feedback (Manasi).
- Rebase.
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-7-paulo.r.zanoni@intel.com
HDMI mode DPLL programming on ICL is the same as CNL, so just reuse
the CNL code.
v2:
- Properly detect HDMI crtcs.
- Rebase after changes to the cnl function (clock * 1000).
v3:
- Add a comment to clarify why we treat 38.4 as 19.2 (James).
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-5-paulo.r.zanoni@intel.com
This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be introduced as separate commits.
Special thanks to James Ausmus for investigating and fixing a bug with
the placement of icl_unmap_plls_to_ports() function.
v2:
- Rebase around dpll_lock changes.
v3:
- The spec now says what the timeouts should be.
- Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
the machine.
- Checkpatch found a white space problem.
- Small adjustments before upstreaming.
v4:
- Move the ICL checks out of the *map_plls_to_ports() functions
(James)
- Add extra encoder check (James)
- Call icl_unmap_plls_to_ports() later (James)
v5:
- Rebase after the pll struct changes.
v6:
- Properly make the unmap function based on encoders_post_disable()
with regarding to checks and iterators.
- Address checkpatch comment on "min = max = x()".
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180427231436.9353-1-paulo.r.zanoni@intel.com
Add documentation to gen9_set_dc_state() on what enabling a given DC
state means and at what point HW/DMC actually enters/exits these states.
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417113147.25120-1-imre.deak@intel.com
Fix `[drm:intel_enable_lvds] *ERROR* timed out waiting for panel to
power on` in kernel log at boot time.
Toshiba Satellite Z930 laptops needs between 1 and 2 seconds to power
on its screen during Intel i915 DRM initialization. This currently
results in a `[drm:intel_enable_lvds] *ERROR* timed out waiting for
panel to power on` message appearing in the kernel log during boot
time and when stopping the machine.
This change increases the timeout of the `intel_enable_lvds` function
from 1 to 5 seconds, letting enough time for the Satellite 930 LCD
screen to power on, and suppressing the error message from the kernel
log.
This patch has been successfully tested on Linux 4.14 running on a
Toshiba Satellite Z930.
[vsyrjala: bump the timeout from 2 to 5 seconds to match the DP
code and properly cover the max hw timeout of ~4 seconds, and
drop the comment about the specific machine since this is not
a particulary surprising issue, nor specific to that one machine]
Signed-off-by: Florent Flament <contact@florentflament.com>
Cc: stable@vger.kernel.org
Cc: Pavel Petrovic <ppetrovic@acm.org>
Cc: Sérgio M. Basto <sergio@serjux.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=103414
References: https://bugzilla.kernel.org/show_bug.cgi?id=57591
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419160700.19828-1-ville.syrjala@linux.intel.com
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
It is useful to see the priority as requests are coming in and completed
status as requests are coming out of the GPU.
To achieve this in a more readable way we need to abandon the common
request_hw tracepoint class.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180504115643.22437-1-tvrtko.ursulin@linux.intel.com
Following commit f773568b6f ("drm/i915: nuke the duplicated stolen
discovery"), the if-else-chain for determining the GTT size is redundant
with the !chv branches all being the same.
Reported-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
References: f773568b6f ("drm/i915: nuke the duplicated stolen discovery")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.auld@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503212956.3948-1-chris@chris-wilson.co.uk
We want to add more DRM selftests, and there's not much point in
having a Kconfig option for every single one of them, so make
a generic one.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-5-maarten.lankhorst@linux.intel.com
[mlankhorst: Fix i915/Kconfig.debug (ickle)]
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Acked-by: Daniel Vetter <daniel.vetter@ffwll.ch>
With the previous patch drm_atomic_helper_check_plane_state correctly
calculates clipping and the xf86-video-intel ddx is fixed to fall back
to GPU correctly when SetPlane fails, we can remove the hack where
we try to pan/zoom when out of min/max scaling range. This was already
poor behavior where the screen didn't show what was requested, and now
instead we reject it outright. This simplifies check_sprite_plane a lot.
Changes since v1:
- Set crtc_h to the height correctly.
- Reject < 3x3 rectangles instead of making them invisible for <gen9.
For gen9+ skl_update_scaler_plane will reject them.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-4-maarten.lankhorst@linux.intel.com
Acked-by: Jani Nikula <jani.nikula@intel.com>
Instead of relying on a scale which may increase rounding errors,
clip src by doing: src * (dst - clip) / dst and rounding the result
away from 1, so the new coordinates get closer to 1. We won't need
to fix up with a magic macro afterwards, because our scaling factor
will never go to the other side of 1.
Changes since v1:
- Adjust dst immediately, else drm_rect_width/height on dst gives bogus
results.
Change since v2:
- Get rid of macros and use 64-bits math.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
[mlankhorst: Add Villes comment, and rename newsrc to tmp. (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503112217.37292-3-maarten.lankhorst@linux.intel.com
Limit the arbitration (where preemption may occur) to inside the batch,
and prevent it from happening on the pipecontrols/flushes we use to
write the breadcrumb seqno. Once the user batch is complete, we have
nothing left to do but serialise and emit the breadcrumb; switching
contexts at this point is futile so don't.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180503195416.22498-1-chris@chris-wilson.co.uk
Don't pre-emptively retire the oldest request in our ring's list if it
is the only request. We keep various bits of state alive using the
active reference from the request and would rather transfer that state
over to a new request rather than the more involved process of retiring
and reacquiring 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/20180503195115.22309-2-chris@chris-wilson.co.uk
When userspace is passing around swapbuffers using DRI, we frequently
have to open and close the same object in the foreign address space.
This shows itself as the same object being rebound at roughly 30fps
(with a second object also being rebound at 30fps), which involves us
having to rewrite the page tables and maintain the drm_mm range manager
every time.
However, since the object still exists and it is only the local handle
that disappears, if we are lazy and do not unbind the VMA immediately
when the local user closes the object but defer it until the GPU is
idle, then we can reuse the same VMA binding. We still have to be
careful to mark the handle and lookup tables as closed to maintain the
uABI, just allowing the underlying VMA to be resurrected if the user is
able to access the same object from the same context again.
If the object itself is destroyed (neither userspace keeping a handle to
it), the VMA will be reaped immediately as usual.
In the future, this will be even more useful as instantiating a new VMA
for use on the GPU will become heavier. A nuisance indeed, so nip it in
the bud.
v2: s/__i915_vma_final_close/i915_vma_destroy/ etc.
v3: Leave a hint as to why we deferred the unbind on close.
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/20180503195115.22309-1-chris@chris-wilson.co.uk
In Icelake, there are more engines on which Memory Object Control
States need to be configured. Besides adding Icelake under Skylake
config, the patch makes sure MOCS register addresses for the new
engines are properly defined.
Additional patch might be need later, in case the specification will
propose different MOCS config values for Icelake than in previous
gens.
v2: Restricted comments to gen11, updated description, renamed
defines.
v3: Used proper engine indexes for gen11.
v4: Ensure patch is Icelake only.
v5: Style fixes (proposed by mwajdeczko)
v6 (from Paulo): fix checkpatch's COMMIT_LOG_LONG_LINE (Checkpatch).
BSpec: 19405
BSpec: 21140
Cc: Oscar Mateo Lozano <oscar.mateo@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Tomasz Lis <tomasz.lis@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502223142.3891-1-paulo.r.zanoni@intel.com
During state readout we first read out the pipe src size, store
that information in the user mode h/vdisplay, but later on we overwrite
that with the actual crtc timings. That makes our read out crtc state
inconsistent with itself when the BIOS has enabled the panel fitter to
scale the pipe contents. Let's preserve the pipe src size based
information in the user mode to make things consistent again.
This fixes a problem introduced by commit a2936e3d9a ("drm/i915:
Use drm_mode_get_hv_timing() to populate plane clip rectangle")
where the inconsistent state is now leading the plane clipping code
to report a failure on account the plane dst coordinates not matching
the user mode size. Previously we did the plane clipping based on
the pipe src size instead and thus never noticed the inconsistency.
The failure manifests as a WARN:
[ 0.762117] [drm:intel_dump_pipe_config [i915]] requested mode:
[ 0.762142] [drm:drm_mode_debug_printmodeline [drm]] Modeline 0:"1366x768" 60 72143 1366 1414 1446 1526 768 771 777 784 0x40 0xa
...
[ 0.762327] [drm:intel_dump_pipe_config [i915]] port clock: 72143, pipe src size: 1024x768, pixel rate 72143
...
[ 0.764666] [drm:drm_atomic_helper_check_plane_state [drm_kms_helper]] Plane must cover entire CRTC
[ 0.764690] [drm:drm_rect_debug_print [drm]] dst: 1024x768+0+0
[ 0.764711] [drm:drm_rect_debug_print [drm]] clip: 1366x768+0+0
[ 0.764713] ------------[ cut here ]------------
[ 0.764714] Could not determine valid watermarks for inherited state
[ 0.764792] WARNING: CPU: 4 PID: 159 at drivers/gpu/drm/i915/intel_display.c:14584 intel_modeset_init+0x3ce/0x19d0 [i915]
...
Cc: FadeMind <fademind@gmail.com>
Cc: Dave Jones <davej@codemonkey.org.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Reported-by: FadeMind <fademind@gmail.com>
Reported-by: Dave Jones <davej@codemonkey.org.uk>
Tested-by: Dave Jones <davej@codemonkey.org.uk>
References: https://lists.freedesktop.org/archives/intel-gfx/2018-April/163186.html
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105992
Fixes: a2936e3d9a ("drm/i915: Use drm_mode_get_hv_timing() to populate plane clip rectangle")
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426163015.14232-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Larry Finger <Larry.Finger@lwfinger.net>
Tested-by: FadeMind <fademind@gmail.com>
No functional changes, just a minor knit. Stumbled across the kernel doc for
schedule_timeout() which quotes "In all cases the return value is guaranteed
to be non-negative". Also, the return code of schedule_timeout() already checks
for negative values "return timeout < 0 ? 0 : timeout;" and returns 0
in such cases. Furthermore, the msec_to_jiffies returns an ungined long
value. So, let's do away with the redundant check for an atomic
pipe update.
v2: Commit message changes (Manasi).
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Tarun Vyas <tarun.vyas@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502233300.81220-1-tarun.vyas@intel.com
On intel_dp_compute_config() we were calculating the needed vco
for eDP on gen9 and we stashing it in
intel_atomic_state.cdclk.logical.vco
However few moments later on intel_modeset_checks() we fully
replace entire intel_atomic_state.cdclk.logical with
dev_priv->cdclk.logical fully overwriting the logical desired
vco for eDP on gen9.
So, with wrong VCO value we end up with wrong desired cdclk, but
also it will raise a lot of WARNs: On gen9, when we read
CDCLK_CTL to verify if we configured properly the desired
frequency the CD Frequency Select bits [27:26] == 10b can mean
337.5 or 308.57 MHz depending on the VCO. So if we have wrong
VCO value stashed we will believe the frequency selection didn't
stick and start to raise WARNs of cdclk mismatch.
[ 42.857519] [drm:intel_dump_cdclk_state [i915]] Changing CDCLK to 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 42.897269] cdclk state doesn't match!
[ 42.901052] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 42.938004] RIP: 0010:intel_set_cdclk+0x5d/0x110 [i915]
[ 43.155253] WARNING: CPU: 5 PID: 1116 at drivers/gpu/drm/i915/intel_cdclk.c:2084 intel_set_cdclk+0x5d/0x110 [i915]
[ 43.170277] [drm:intel_dump_cdclk_state [i915]] [hw state] 337500 kHz, VCO 8100000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
[ 43.182566] [drm:intel_dump_cdclk_state [i915]] [sw state] 308571 kHz, VCO 8640000 kHz, ref 24000 kHz, bypass 24000 kHz, voltage level 0
v2: Move the entire eDP's vco logical adjustment to inside
the skl_modeset_calc_cdclk as suggested by Ville.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Fixes: bb0f4aab0e ("drm/i915: Track full cdclk state for the logical and actual cdclk frequencies")
Cc: <stable@vger.kernel.org> # v4.12+
Link: https://patchwork.freedesktop.org/patch/msgid/20180502175255.5344-1-rodrigo.vivi@intel.com
As we unpark the engines and are about to begin a new cycle of activity,
mark the current status of the hangceck as idle so that we avoid
carrying over a stale timestamp/action into the next cycle.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502220313.6459-2-chris@chris-wilson.co.uk
If we try to suspend a wedged device following a GPU reset failure, we
will also fail to turn off the rc6 powerwells (on vlv), leading to a
*ERROR*. This is quite expected in this case, so the best we can do is
shake our heads and reduce the *ERROR* to a debug so CI stops
complaining.
Testcase: igt/gem_eio/in-flight-suspend #vlv
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105583
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Acked-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409094905.4516-1-chris@chris-wilson.co.uk
Move the tracepoint into the common execlists_context_schedule_out() and
call it from preemption completion as well. A small bit of refactoring
code should help with when tracing, or else we end up with requests
mysteriously disappearing and some being emitted to HW multiple times.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
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/20180502230202.6848-1-chris@chris-wilson.co.uk
We need to move to a more flexible timeline that doesn't assume one
fence context per engine, and so allow for a single timeline to be used
across a combination of engines. This means that preallocating a fence
context per engine is now a hindrance, and so we want to introduce the
singular timeline. From the code perspective, this has the notable
advantage of clearing up a lot of mirky semantics and some clumsy
pointer chasing.
By splitting the timeline up into a single entity rather than an array
of per-engine timelines, we can realise the goal of the previous patch
of tracking the timeline alongside the ring.
v2: Tweak wait_for_idle to stop the compiling thinking that ret may be
uninitialised.
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/20180502163839.3248-2-chris@chris-wilson.co.uk
In the future, we want to move a request between engines. To achieve
this, we first realise that we have two timelines in effect here. The
first runs through the GTT is required for ordering vma access, which is
tracked currently by engine. The second is implied by sequential
execution of commands inside the ringbuffer. This timeline is one that
maps to userspace's expectations when submitting requests (i.e. given the
same context, batch A is executed before batch B). As the rings's
timelines map to userspace and the GTT timeline an implementation
detail, move the timeline from the GTT into the ring itself (per-context
in logical-ring-contexts/execlists, or a global per-engine timeline for
the shared ringbuffers in legacy submission.
The two timelines are still assumed to be equivalent at the moment (no
migrating requests between engines yet) and so we can simply move from
one to the other without adding extra ordering.
v2: Reinforce that one isn't allowed to mix the engine execution
timeline with the client timeline from userspace (on the ring).
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/20180502163839.3248-1-chris@chris-wilson.co.uk
Replace 01.org URL with upstream linux-firmware repo URL.
We no longer release firmware to 01.org.
linux-firmware.git is the ultimate place to find
the i915 firmwares.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1525129168-529-1-git-send-email-anusha.srivatsa@intel.com
As our early doorbell is split between early allocation and a late setup
after we have a channel to the GuC, it may happen due to a lapse of
programmer judgement that we try to setup an invalid doorbell. Make use
of our has_doorbell() function to check the doorbell does exist for the
client before we try and tell the guc about it. In doing so, we prevent
the compiler from warning about the otherwise unused function in some
configurations.
Reported-by: Matthias Kaehlcke <mka@chromium.org>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180501075203.12458-1-chris@chris-wilson.co.uk
Commit 39bf4de89f ("drm/i915: Add -Wall -Wextra to our build, set
warnings to full") enabled extra warnings for i915 to spot possible
bugs in new code, and then disabled a subset of these warnings to keep
the current code building without warnings (with gcc). Enabling the
extra warnings also enabled some additional clang-only warnings, as a
result building i915 with clang currently is extremely noisy. For now
also disable the clang warnings sign-compare, sometimes-uninitialized,
unneeded-internal-declaration and initializer-overrides. If desired
they can be re-enabled after the code has been fixed.
Signed-off-by: Matthias Kaehlcke <mka@chromium.org>
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/20180501182440.70121-1-mka@chromium.org
Since the advent of execlists, the HW no longer executes from a single
statically assigned ring, but instead switches to a different ring for
each context (logical ringbuffer contexts as it is called). So a good way
to tally the executing context against what we have queued is by
comparing the RING_START register against our requests. Make it so.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180502104150.29874-1-chris@chris-wilson.co.uk
The old wait_on_atomic_t used a custom callback to perform the
schedule(), which used my return semantics of reporting an error code on
timeout. wait_var_event_timeout() uses the schedule() return semantics
of reporting the remaining jiffies (1 if it timed out with 0 jiffies
remaining!) and 0 on failure. This semantic mismatch lead to us falsely
claiming a time out occurred.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106085
Fixes: d224985a5e ("sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417170638.20550-1-chris@chris-wilson.co.uk
Use i915.dmc_firmware_path to override default firmware for the platform
and bypassing version checks.
v2: add missing param struct member declaration (David)
Tested-by: David Weinehall <david.weinehall@linux.intel.com>
Reviewed-by: David Weinehall <david.weinehall@linux.intel.com>
Cc: Anusha Srivatsa <anusha.srivatsa@intel.com>
Cc: David Weinehall <david.weinehall@linux.intel.com>
Acked-by: Anusha Srivatsa <anusha.srivatsa@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424122016.2416-1-jani.nikula@intel.com
Using plain jiffies in error state output makes the output
time differences relative to the current system time. This
is wrong as it makes output time differences dependent
of when the error state is printed rather than when it is
captured.
Store capture jiffies into error state and use it
when outputting the state to fix time differences output.
v2: use engine timestamp as epoch, output formatting (Chris)
v3: pass epoch to print_engine/request (Chris)
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180430075259.4476-1-mika.kuoppala@linux.intel.com
Due to the latency of the tasklet running from ksoftirqd, by the time we
process the execlist dequeue may be a long time behind the GPU. If the
request was completed when we ran reschedule, we will not have tweaked
its priority, but if it is still listed as being in-flight for dequeue
we will use it as a reference for the rest of the queue, including
requests from its own context which will now be at higher priority. This
can cause us to issue a preempt-to-idle request, even though the request
we want to preempt is already complete.
Reported-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180501122131.19435-1-chris@chris-wilson.co.uk
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
On clock recovery this function is called to find out
the max voltage swing level that we could go.
However gen 9 functions use the old buffer translation tables
to figure that out. ICL uses different set of tables for eDP
and DP for both Combo and MG PHY ports. This patch adds the hook
for ICL for getting this information from appropriate buf trans tables.
v5 (from Paulo):
* New rebase after changes to earlier patches.
v4:
* Rebase.
v3:
* Follow the coding conventions here
(https://cgit.freedesktop.org/drm-intel/tree/Documentation/process/codin
g-style.rst#n191) (Paulo)
v2:
* Rebase after patch that adds voltage check inside buf trans
function (Rodrigo)
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-9-paulo.r.zanoni@intel.com
This is an important part of the DDI initalization as well as
for changing the voltage during DisplayPort link training.
The Voltage swing seqeuence is similar to Cannonlake.
However it has different register definitions and hence
it makes sense to create a separate vswing sequence and
program functions for ICL to leave room for more changes
in case the Bspec changes later and deviates from CNL sequence.
v2:
Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
v3:
* Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
v4:
* Call it combo_vswing, use switch statement (Paulo)
v5 (from Paulo):
* Fix a typo.
* s/rate < 600000/rate <= 600000/.
* Don't remove blank lines that should be there.
v6:
* Rebased by Rodrigo on top of Cannonlake changes
where non vswing sequences are not aligned with iboost
anymore.
v7: Another rebase after an upstream rework.
v8 (from Paulo):
* Adjust the code to the upstream output type changes.
* Squash the patch that moved some functions up.
* Merge both get_combo_buf_trans functions in order to simplify the
code.
* Change the changelog format.
v9 (from Paulo):
* Use RTERM_SELECT instead of SCALING_MODE_SEL.
* Adjust the output type handling according to how the other platforms
do it now.
v10 (from Paulo):
* Fix comment left out from v9 changes (Rodrigo).
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: James Ausmus <james.ausmus@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-8-paulo.r.zanoni@intel.com
We don't need to track every ring for its lifetime as they are managed
by the contexts/engines. What we do want to track are the live rings so
that we can sporadically clean up requests if userspace falls behind. We
can simply restrict the gt->rings list to being only gt->live_rings.
v2: s/live/active/ for consistency with gt.active_requests
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180430131503.5375-4-chris@chris-wilson.co.uk
In the next patch, rings are the central timeline as requests may jump
between engines. Therefore in the future as we retire in order along the
engine timeline, we may retire out-of-order within a ring (as the ring now
occurs along multiple engines), leading to much hilarity in miscomputing
the position of ring->head.
As an added bonus, retiring along the ring reduces the penalty of having
one execlists client do cleanup for another (old legacy submission
shares a ring between all clients). The downside is that slow and
irregular (off the critical path) process of cleaning up stale requests
after userspace becomes a modicum less efficient.
In the long run, it will become apparent that the ordered
ring->request_list matches the ring->timeline, a fun challenge for the
future will be unifying the two lists to avoid duplication!
v2: We need both engine-order and ring-order processing to maintain our
knowledge of where individual rings have completed upto as well as
knowing what was last executing on any engine. And finally by decoupling
retiring the contexts on the engine and the timelines along the rings,
we do have to keep a reference to the context on each request
(previously it was guaranteed by the context being pinned).
v3: Not just a reference to the context, but we need to keep it pinned
as we manipulate the rings; i.e. we need a pin for both the manipulation
of the engine state during its retirements, and a separate pin for the
manipulation of the ring state.
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/20180430131503.5375-3-chris@chris-wilson.co.uk
Make life easier in upcoming patches by moving the context_pin and
context_unpin vfuncs into inline helpers.
v2: Fixup mock_engine to mark the context as pinned on use.
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/20180430131503.5375-2-chris@chris-wilson.co.uk
In commit 9b6586ae9f ("drm/i915: Keep a global seqno per-engine"), we
moved from a global inflight counter to per-engine counters in the
hope that will be easy to run concurrently in future. However, with the
advent of the desire to move requests between engines, we do need a
global counter to preserve the semantics that no engine wraps in the
middle of a submit. (Although this semantic is now only required for gen7
semaphore support, which only supports greater-then comparisons!)
v2: Keep a global counter of all requests ever submitted and force the
reset when it wraps.
References: 9b6586ae9f ("drm/i915: Keep a global seqno per-engine")
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/20180430131503.5375-1-chris@chris-wilson.co.uk
Previously, we just reset the ring register in the context image such
that we could skip over the broken batch and emit the closing
breadcrumb. However, on resume the context image and GPU state would be
reloaded, which may have been left in an inconsistent state by the
reset. The presumption was that at worst it would just cause another
reset and skip again until it recovered, however it seems just as likely
to cause an unrecoverable hang. Instead of risking loading an incomplete
context image, restore it back to the default state.
v2: Fix up off-by-one from including the ppHSWP in with the register
state.
v3: Use a ring local to compact a few lines.
v4: Beware setting the ring local before checking for a NULL request.
References: https://bugs.freedesktop.org/show_bug.cgi?id=105304
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com> #v2
Link: https://patchwork.freedesktop.org/patch/msgid/20180428111532.15819-1-chris@chris-wilson.co.uk
As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.
This removes the error message in the dmesg log:
i915 0000:00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
i915 0000:00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
i915 0000:00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
and now shows that the firmware has correctly loaded:
[drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411044213.383-1-ianwmorrison@gmail.com
(cherry picked from commit f6d3e06f07)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
UAPI Changes:
- Add support for a generic plane alpha property to sun4i, rcar-du and atmel-hclcdc. (Maxime)
Core Changes:
- Stop looking at legacy plane->fb and crtc members in atomic drivers. (Ville)
- mode_valid return type fixes. (Luc)
- Handle zpos normalization in the core. (Peter)
Driver Changes:
- Implement CTM, plane alpha and generic async cursor support in vc4. (Stefan)
- Various fixes for HPD and aux chan in drm_bridge/analogix_dp. (Lin, Zain, Douglas)
- Add support for MIPI DSI to sun4i. (Maxime)
-----BEGIN PGP SIGNATURE-----
iQIzBAABCgAdFiEEuXvWqAysSYEJGuVH/lWMcqZwE8MFAlrhqA0ACgkQ/lWMcqZw
E8PcQQ//ZfZE5SgklBEuqil4X30z0y/ikFy3rEPhJOYpCGYjwDpOXoHjbgeIqFYD
NWiYmeq8OfFBDQz8EkqalVJkqH10w2rcOJszM2t86FlSUWTmVxTqWjuVIIySkv67
UNJZo9+ppvwPahvO8aZqs90fJOGS2dqslgRa5v91S1IT+AZMZ7UNBlbhjCsmCPod
TKypdZ4rOzlI7E3NR2CVSngPgLbUvTLnGDx0xKCej3Pp4MSW2g4kDNzHOPY82uLZ
P2GyacmNN1yKTL9qfvqOoEWr8lu2bJuQ3mSzuYn6bBl8lHLPVEjdSMrtA3SGhM1v
4gTNRmnN1nCv+q3umLNSPLqKN6OHO1nstqbcTf753+g6gtJBGotCK2aWmTSKW8FC
DtezLQIaFVf+Vyhr2XIgHfuDetk+f6E1u0/01yqxpGDP2WpQCzadbgIqCdJviMZS
W9i/as2nJssg3ekoCbkA1leteAc088HPzFHVyqt4zKNTdCmUwtx/HdCoF2uXjsFV
fTj7+sFkLHMQWdR3WqKQHqnxoknD1mfBbR7SCjvNXfhjQPGZQZgdyoJXvOhuKAnO
cTygEZhCxlM1G0afStY18It/uZlNpxVz393nTiFtPp4RHmPO3jyIApTDPyqgXGCu
5L6MTBOrAntlOQ7kSWqrm9dbiv8ZDvPAhm7eer5txH7kQK2ywJo=
=9LYY
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2018-04-26' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for v4.18:
UAPI Changes:
- Add support for a generic plane alpha property to sun4i, rcar-du and atmel-hclcdc. (Maxime)
Core Changes:
- Stop looking at legacy plane->fb and crtc members in atomic drivers. (Ville)
- mode_valid return type fixes. (Luc)
- Handle zpos normalization in the core. (Peter)
Driver Changes:
- Implement CTM, plane alpha and generic async cursor support in vc4. (Stefan)
- Various fixes for HPD and aux chan in drm_bridge/analogix_dp. (Lin, Zain, Douglas)
- Add support for MIPI DSI to sun4i. (Maxime)
Signed-off-by: Dave Airlie <airlied@redhat.com>
# gpg: Signature made Thu 26 Apr 2018 08:21:01 PM AEST
# gpg: using RSA key FE558C72A67013C3
# gpg: Can't check signature: public key not found
Link: https://patchwork.freedesktop.org/patch/msgid/b33da7eb-efc9-ae6f-6f69-b7acd6df6797@mblankhorst.nl
There's a lot of code for the PLL enabling, so let's first only
introduce the register definitions in order to make patch reviewing a
little easier.
v2: Coding style (Jani).
v3: Preparation for upstreaming.
v4: Fix MG_CLKTOP2_CORECLKCTL1 address and random typos (James).
Cc: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-3-paulo.r.zanoni@intel.com
Gen11/ICL onward ddb entry start/end mask is increased from 10 bits to
11 bits. This patch make changes to use proper mask for ICL+ during
hardware ddb value readout.
Changes since V1:
- Use _MASK & _SHIFT macro (James)
Changes since V2:
- use kernel type u8 instead of uint8_t
Changes since V3:
- Rebase
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-4-mahesh1.kumar@intel.com
ICL has two slices of DBuf, each slice of size 1024 blocks.
We should not always enable slice-2. It should be enabled only if
display total required BW is > 12GBps OR more than 1 pipes are enabled.
Changes since V1:
- typecast total_data_rate to u64 before multiplication to solve any
possible overflow (Rodrigo)
- fix where skl_wm_get_hw_state was memsetting ddb, resulting
enabled_slices to become zero
- Fix the logic of calculating ddb_size
Changes since V2:
- If no-crtc is part of commit required_slices will have value "0",
don't try to disable DBuf slice.
Changes since V3:
- Create a generic helper to enable/disable slice
- don't return early if total_data_rate is 0, it may be cursor only
commit, or atomic modeset without any plane.
Changes since V4:
- Solve checkpatch warnings
- use kernel types u8/u64 instead of uint8_t/uint64_t
Changes since V5:
- Rebase
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-3-mahesh1.kumar@intel.com
This patch adds support to start tracking status of DBUF slices.
This is foundation to introduce support for enabling/disabling second
DBUF slice dynamically for ICL.
Changes Since V1:
- use kernel type u8 over uint8_t
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426142517.16643-2-mahesh1.kumar@intel.com
These fields have been deprecated and moved in ICL+. Stop setting the
bits.
They have moved to GAMMA_MODE and CSC_MODE, respectively. This patch
is just to stop incorrectly setting bits in PLANE_COLOR_CTL while
we're waiting for the new replacement functionality to be done.
v2: Drop useless comment, and change !(GEN >= 11) to (GEN < 11). (Ville)
v3: No changes
v4 (from Paulo): Rebase.
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: James Ausmus <james.ausmus@intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328215803.13835-2-paulo.r.zanoni@intel.com
As the Geminilake firmware is now merged to linux-firmware.git
use MODUE_FIRMWARE to load the firmware.
This removes the error message in the dmesg log:
i915 0000:00:02.0: Direct firmware load for
i915/glk_dmc_ver1_04.bin failed with error -2
i915 0000:00:02.0: Failed to load DMC firmware
i915/glk_dmc_ver1_04.bin. Disabling runtime power management.
i915 0000:00:02.0: DMC firmware homepage:
https://01.org/linuxgraphics/downloads/firmware
and now shows that the firmware has correctly loaded:
[drm] Finished loading DMC firmware i915/glk_dmc_ver1_04.bin (v1.4)
Signed-off-by: Ian W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411044213.383-1-ianwmorrison@gmail.com
This was my bad, spec says that the name of this bit is
'Y-coordinate valid' but the values for it is:
0: Include Y-coordinate valid eDP1.4a
1: Do not include Y-coordinate valid eDP 1.4
So not setting it.
BSpec: 7713
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-4-jose.souza@intel.com
IGT tests could be improved with sink status, knowing for sure that
hardware have activate or exit PSR.
v3:
Reading i915_edp_psr_status was causing PSR to exit but now with
'drm/i915/psr: Prevent PSR exit when a non-pipe related register is
written' it is fixed.
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-3-jose.souza@intel.com
This will be helpful to debug what hardware is actually tracking
and causing PSR to exit.
BSpec: 7721
v4:
- Using _MMIO_TRANS2() in PSR_EVENT
- Cleaning events before printing
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-2-jose.souza@intel.com
Any write in any display register was causing HW to exit PSR,
masking it to allow more power savings. Writes to pipe related
registers will still cause HW to exit PSR.
This is already masked for PSR2.
It also do not break the Display WA #0884, writes to CURSURFLIVE
are still causing hardware to exit PSR. This was tested in CNL machine
by triggering a write to CURSURFLIVE when a debugfs was read by user.
Bspec: 7721 and 8042
v4: Checked that it do not breaks WA #0884 and added this information
to the commit message.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180425212334.21109-1-jose.souza@intel.com
Even though we weren't injecting guilty requests to be reset, we could
still fall over the issue of resetting the same request too fast -- where
the GPU refuses to start again. (Although it is interesting to note that
reloading the driver is sufficient, suggesting that we could recover if
we delayed the setup after reset?) Continue to paper over the problem by
adding a small delay by waiting for the engine to idle between tests,
and ensure that the engines are idle before starting the idle tests.
v2: Replace single instance of 50 with a magic macro.
References: 028666793a ("drm/i915/selftests: Avoid repeatedly harming the same innocent context")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Michał Winiarski <michal.winiarski@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411120346.27618-1-chris@chris-wilson.co.uk
For now, there's just the one link config selection, optimizing for slow
and wide link. No functional changes.
Keep the debug logging in the caller, to avoid duplication later on if
alternative link confing selection gets added.
v2: Improved commit message
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/64848b76bf90d6ceecd7ec6b5add28531e0b1a41.1524730974.git.jani.nikula@intel.com
We call intel_dp_compute_rate() in intel_dp_compute_config() only to be
able to debug log the link_bw and rate_select parameters; we don't use
the parameters here for anything else. We call intel_dp_compute_rate()
again during link training where we actually need and use the
parameters.
Move the debug logging of link_bw and rate_select to
intel_dp_link_training_clock_recovery(), and clean up the extra
intel_dp_compute_rate() call and extra clutter from the already
overcrowded intel_dp_compute_config().
v2: Rewrote commit message (Rodrigo, Manasi)
Reviewed-by: Manasi Navare <manasi.d.navare@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/c5cf6a179e2d244eceb6bb80a792765d9efbee4f.1524730974.git.jani.nikula@intel.com
The majority of the engine state dumping is too voluminous to be useful
outside of a controlled setup, though a few do accompany severe errors.
Keep the debug dumps next to the errors, but hide the others behind a CI
compile flag. This becomes more useful when adding more dumps to latency
sensitive paths.
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/20180426103219.22181-1-chris@chris-wilson.co.uk
We can convert engine stats from a spinlock to seqlock to ensure interrupt
processing is never even a tiny bit delayed by parallel readers.
There is a smidgen bit more cost on the write lock side, and an extremely
unlikely chance that readers will have to retry a few times in face of
heavy interrupt load. But it should be extremely unlikely given how
lightweight read side section is compared to the interrupt processing
side, and also compared to the rest of the code paths which can lead into
it. Furthermore, writer is the ones doing the real, latency sensitive
work, while readers are only informative.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180426074716.7352-1-tvrtko.ursulin@linux.intel.com
Interrupt handling in Gen11 is quite different from previous platforms.
v2: Rebased (Michel)
v3: Rebased with wiggle
v4: Rebased, remove TODO warning correctly (Daniele)
v5: Rebased, made gen11_gtiir const while at it (Michel)
v6: Rebased
v7: Adapt to the style currently in upstream
Suggested-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1524605995-22324-1-git-send-email-oscar.mateo@intel.com
When filling the ring to align the emit pointer to the next cacheline,
use memset64() rather than open-coding it. As we know that we always
have an even number of dwords, we can replace the dword loop with the
qword equivalent.
v2: s/0/MI_NOOP<<32 | MI_NOOP/
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/20180425123718.16366-1-chris@chris-wilson.co.uk
If the initial fbdev configuration (intel_fbdev_initial_config()) runs
and there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened (but
internally the return is -EAGAIN). Because no framebuffer was
allocated, when a sink is connected intel_fbdev_output_poll_changed()
will not execute drm_fb_helper_hotplug_event() that would trigger
another try to do the initial fbdev configuration.
So here allowing drm_fb_helper_hotplug_event() to be executed when there
is no framebuffer allocated and fbdev was not set up yet.
This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if
intel_fbdev_initial_config() is executed before the first sink MST is
discovered it will cause this same issue.
This is a follow-up patch of
https://patchwork.freedesktop.org/patch/196089/
Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17
Tested-by: Ian Pilcher <arequipeno@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
(cherry picked from commit df9e652174)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.
We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.
v2: added bugzilla entry (Imre), added stable (Chris)
Reported-by: Imre Deak <imre.deak@intel.com>
References: https://lkml.org/lkml/2018/4/18/798 [1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
(cherry picked from commit 3085982c6b)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Instead of synchronously cancelling the timer and re-enabling it inside
the reset callbacks, keep the timer enabled and let it die on its next
wakeup if no longer required. This allows
intel_engine_reset_breadcrumbs() to be used from an atomic
(timer/softirq) context such as required for resetting an engine.
It also allows us to react better to the user poking around debugfs for
testing missed irqs.
v2: Tighten the order of del_timer_sync as the fake_irq timer
may trigger the hangcheck timer, and so we should cancel it first and
then cancel the hangcheck (Mika)
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: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424142945.6787-1-chris@chris-wilson.co.uk
There is a potential execution path in which variable err is
returned without being properly initialized previously.
Fix this by initializing variable err to 0.
Addresses-Coverity-ID: 1468362 ("Uninitialized scalar variable")
Fixes: f4ecfbfc32 ("drm/i915: Check whitelist registers across resets")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.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/20180424131545.GA4053@embeddedor.com
If the initial fbdev configuration (intel_fbdev_initial_config()) runs
and there still no sink connected it will cause
drm_fb_helper_initial_config() to return 0 as no error happened (but
internally the return is -EAGAIN). Because no framebuffer was
allocated, when a sink is connected intel_fbdev_output_poll_changed()
will not execute drm_fb_helper_hotplug_event() that would trigger
another try to do the initial fbdev configuration.
So here allowing drm_fb_helper_hotplug_event() to be executed when there
is no framebuffer allocated and fbdev was not set up yet.
This issue also happens when a MST DP sink is connected since boot, as
the MST topology is discovered in parallel if
intel_fbdev_initial_config() is executed before the first sink MST is
discovered it will cause this same issue.
This is a follow-up patch of
https://patchwork.freedesktop.org/patch/196089/
Changes from v1:
- not creating a dump framebuffer anymore, instead just allowing
drm_fb_helper_hotplug_event() to execute when fbdev is not setup yet.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104158
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=104425
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: stable@vger.kernel.org # v4.15+
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Tested-by: Paul Menzel <pmenzel@molgen.mpg.de>
Tested-by: frederik <frederik.schwan@linux.com> # 4.15.17
Tested-by: Ian Pilcher <arequipeno@gmail.com>
Acked-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418234158.9388-1-jose.souza@intel.com
If we have more than a few, possibly several thousand request in the
queue, don't show the central portion, just the first few and the last
being executed and/or queued. The first few should be enough to help
identify a problem in execution, and most often comparing the first/last
in the queue is enough to identify problems in the scheduling.
We may need some fine tuning to set MAX_REQUESTS_TO_SHOW for common
debug scenarios, but for the moment if we can avoiding spending more
than a few seconds dumping the GPU state that will avoid a nasty
livelock (where hangcheck spends so long dumping the state, it fires
again and starts to dump the state again in parallel, ad infinitum).
v2: Remember to print last not the stale rq iter after the loop.
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/20180424081600.27544-1-chris@chris-wilson.co.uk
printk unhelpfully inserts a '\n' between consecutive calls, and since
our drm_printf wrapper may be emitting info a seq_file instead,
KERN_CONT is not an option. To work with any drm_printf destination, we
need to build up the output into a temporary buf on the stack and then
feed the complete line in a single call to printk.
Fixes: b7268c5eed ("drm/i915: Pack params to engine->schedule() into a struct")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180424010839.22860-1-chris@chris-wilson.co.uk
We need to be careful to not let compiler evaluate
the expiration and the operation on it's terms.
Document and enforce that COND will be evaluated
before checking timeout expiration.
Suggested-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-2-mika.kuoppala@linux.intel.com
We use jiffies to determine when wait expires. However
Imre did find out that jiffies can and will do a >1
increments on certain situations [1]. When this happens
in a wait_for loop, we return timeout errorneously
much earlier than what the real wallclock would say.
We can't afford our waits to timeout prematurely.
Discard jiffies and change to ktime to detect timeouts.
v2: added bugzilla entry (Imre), added stable (Chris)
Reported-by: Imre Deak <imre.deak@intel.com>
References: https://lkml.org/lkml/2018/4/18/798 [1]
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Cc: Imre Deak <imre.deak@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: <stable@vger.kernel.org>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180423113754.28424-1-mika.kuoppala@linux.intel.com
The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.
I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.
Fixes: 53421c2fe9 ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
(cherry picked from commit b49be6622f)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
In GLK when the device boots with only 1366x768 panel without audio, HDA
codec doesn't come up. In this case, the CDCLK is less than twice the
BCLK. Even though audio isn't being enabled, having a too low CDCLK
leads to audio probe failing altogether.
Require CDCLK to be at least twice the BLCK regardless of audio. This is
a minimal fix to improve things. Unfortunately, this a) leads to too
high CDCLK being used when audio is not used, and b) is still not enough
to fix audio probe when no outputs are connected at probe time.
The proper fix would be to increase CDCLK dynamically from the audio
component hooks.
v2:
- Address comment (Jani)
- New design approach
v3: - Typo fix on top of v1
v4 by Jani: rewrite commit message, add comment in code
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Cc: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418103707.14645-1-jani.nikula@intel.com
(cherry picked from commit 2a5b95b448)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
In preparation to enabling -Wimplicit-fallthrough, mark switch cases
where we are expecting to fall through.
Addresses-Coverity-ID: 1466154 ("Missing break in switch")
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
The checks are misleading and not required [1].
[1] https://lkml.org/lkml/2018/3/19/1792
Addresses-Coverity-ID: 1466017
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
For perfomance purpose, scanning of non-privileged batch buffer is turned
off by default. But for debugging purpose, it can be turned on via debugfs.
After scanning, we submit the original non-privileged batch buffer into
hardware, so that the scanning is only a peeking window of guest submitted
commands and will not affect the execution results.
v4:
- refine debugfs print format&content (zhenyu wang)
- print engine id instread of engine name to prevent potential memory leak
in debugfs warning message. (zhenyu wang)
v3:
- change vgpu->scan_nonprivbb from type bool to u32, so it is able to
selectively turn on/off scanning of non-privileged batch buffer on engine
level. e.g.
if vgpu->scan_nonprivbb=3, then it will scan non-privileged batch buffer
on engine 0 and 1.
- in debugfs interface to set vgpu->scan_nonprivbb, print warning message
to warn user and explicitly tell state change in kernel log (zhenyu wang)
v2:
- rebase
- update comments for start_gma_offset (henry)
Signed-off-by: Zhao Yan <yan.y.zhao@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
When there is only one vGPU in GVT-g and it submits workloads
continuously, it will not be scheduled out, vgpu_update_timeslice
is not called and its sched_in_time is not updated in a long time,
which can be several seconds or longer.
Once GVT-g pauses to submit workload for this vGPU due to heavy
host CPU workload, this vGPU get scheduled out and
vgpu_update_timeslice is called, its left_ts will be subtract
by a big value from sched_out_time - sched_in_time.
When GVT-g is going to submit workload for this vGPU again,
it will not be scheduled in until gvt_balance_timeslice reaches
stage 0 and reset its left_ts, which introduces several
hunderand milliseconds latency.
This patch updates time slice in every ms to update sched_in_time
timely.
v2: revise commit message
v3: use more concise expr. (Zhenyu)
Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Min He <min.he@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
intel_gvt_schedule check timer through a counter and is supposed
to wake up to increase the counter every ms.
In a system with heavy workload, gvt_service_thread can not get
a chance to run right after wake up and will be delayed several
milliseconds. As a result, one hundred counter interval means
several hundred milliseconds in real time.
This patch use real time instead of counter to do timer check.
v2: remove static variable. (Zhenyu)
v3: correct expire_time update. (Zhenyu)
Signed-off-by: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Zhenyu Wang <zhenyuw@linux.intel.com>
Cc: Min He <min.he@intel.com>
Signed-off-by: Zhi Wang <zhi.a.wang@intel.com>
-----BEGIN PGP SIGNATURE-----
iQIcBAABAgAGBQJa3RQoAAoJEAx081l5xIa+lTAQAI65u2hfifTncFxAP/7F+jEJ
eDDHIl772Mf4Zfetc2h3atPpB6rtYY3IdONemJ1HdZfETX5qrjL33DwO0Ss2UCOp
bHRS02XebVkrCe+DRssGyj7mNqPKZcUf72wp5vEZU3Moiz1zGZajdlN5N7tJ5H/r
kR8mMGTw5ZQ4G+eP0TNbQD+6EValf7Twrk73aR4DbhH+mUI0BrVbf71kj4eeoqG/
XJRNBPViwIPl9rPT8HMxctF7Qg93qH2pYKFspSMBGaohnVHM15MUOrHeXMmmIICq
GtHBqmAq/jbKR5RLHcJCNhY6fkhWIYoCIFbveJLKf8rTtAC3lWRerGmL6aSMT6eC
rWP79rYXPDPOnl+JjnozZrpEnadfNDLI/dm7S/NKgTqiaM1pA1bV/uf2EMPE7cdb
KCZFCmTHiji7g38JRDct06bOGagIn4qtHloMfzxDAvVxfegqmtRjacJWkYh8/twu
2kB2lROq/+uBocKCpq43S8241gSH4VC7QzAnHcVJbieNYYsWv2t3AMLbIpGAFr26
CsUScUWrG4nIjgvZgIzQW8oCTgYhvenx9k3AwUOtAuaVs6Pr1J0smu9GO0KuY22l
vmTT7jN2t0PTDUb6vCeM5v7OK2gAhuyEpEr9RkkoDdbQINTCcmoJJ2Za9JoOIZP2
kUBedh7jQYvOVBNWoRgD
=SkQU
-----END PGP SIGNATURE-----
Merge tag 'drm-fixes-for-v4.17-rc2' of git://people.freedesktop.org/~airlied/linux
Pull drm fixes from Dave Airlie:
"Exynos, i915, vc4, amdgpu fixes.
i915:
- an oops fix
- two race fixes
- some gvt fixes
amdgpu:
- dark screen fix
- clk/voltage fix
- vega12 smu fix
vc4:
- memory leak fix
exynos just drops some code"
* tag 'drm-fixes-for-v4.17-rc2' of git://people.freedesktop.org/~airlied/linux: (23 commits)
drm/amd/powerplay: header file interface to SMU update
drm/amd/pp: Fix bug voltage can't be OD separately on VI
drm/amd/display: Don't program bypass on linear regamma LUT
drm/i915: Fix LSPCON TMDS output buffer enabling from low-power state
drm/i915/audio: Fix audio detection issue on GLK
drm/i915: Call i915_perf_fini() on init_hw error unwind
drm/i915/bios: filter out invalid DDC pins from VBT child devices
drm/i915/pmu: Inspect runtime PM state more carefully while estimating RC6
drm/i915: Do no use kfree() to free a kmem_cache_alloc() return value
drm/exynos: exynos_drm_fb -> drm_framebuffer
drm/exynos: Move dma_addr out of exynos_drm_fb
drm/exynos: Move GEM BOs to drm_framebuffer
drm: Fix HDCP downstream dev count read
drm/vc4: Fix memory leak during BO teardown
drm/i915/execlists: Clear user-active flag on preemption completion
drm/i915/gvt: Add drm_format_mod update
drm/i915/gvt: Disable primary/sprite/cursor plane at virtual display initialization
drm/i915/gvt: Delete redundant error message in fb_decode.c
drm/i915/gvt: Cancel dma map when resetting ggtt entries
drm/i915/gvt: Missed to cancel dma map for ggtt entries
...
Before this commit the WaSkipStolenMemoryFirstPage workaround code was
skipping the first 4k by passing 4096 as start of the address range passed
to drm_mm_init(). This means that calling drm_mm_reserve_node() to try and
reserve the firmware framebuffer so that we can inherit it would always
fail, as the firmware framebuffer starts at address 0.
Commit d435376104 ("drm/i915: skip the first 4k of stolen memory on
everything >= gen8") says in its commit message: "This is confirmed to fix
Skylake screen flickering issues (probably caused by the fact that we
initialized a ring in the first page of stolen, but I didn't 100% confirm
this theory)."
Which suggests that it is safe to use the first page for a linear
framebuffer as the firmware is doing (see note below).
This commit always passes 0 as start to drm_mm_init() and works around
WaSkipStolenMemoryFirstPage in i915_gem_stolen_insert_node_in_range()
by insuring the start address passed by to drm_mm_insert_node_in_range()
is always 4k or more. All entry points to i915_gem_stolen.c go through
i915_gem_stolen_insert_node_in_range(), so that any newly allocated
objects such as ring-buffers will not be allocated in the first 4k.
The one exception is i915_gem_object_create_stolen_for_preallocated()
which directly calls drm_mm_reserve_node() which now will be able to
use the first 4k.
This fixes the i915 driver no longer being able to inherit the firmware
framebuffer on gen8+, which fixes the video output changing from the
vendor logo to a black screen as soon as the i915 driver is loaded
(on systems without fbcon).
Some notes about the mapping of the BIOS framebuffer:
v1 led to some discussion if the assumption of the intel_display.c code
that the firmware framebuffer is a linear mapping of the stolen memory
starting at offset 0 is still correct, because that would mean that the
GOP does not implement the WaSkipStolenMemoryFirstPage workaround.
To verify this the following code was added at the end of
i915_gem_object_create_stolen_for_preallocated() :
pr_err("first ggtt entry before bind: 0x%016llx\n",
readq(dev_priv->ggtt.gsm));
ret = i915_vma_bind(vma,
HAS_LLC(dev_priv) ? I915_CACHE_LLC : I915_CACHE_NONE,
PIN_UPDATE);
pr_err("i915_vma_bind ret %d\n", ret);
pr_err("first ggtt entry after bind: 0x%016llx\n",
readq(dev_priv->ggtt.gsm));
Which prints the mapping of the first page, then does a vma_bind() to
force update the mapping with our linear view of the framebuffer and
then prints the mapping of the first page again.
On an Asrock B150M Pro4S/D3 mainboard with i5-6500 CPU this prints:
[ 1.651141] first ggtt entry before bind: 0x0000000078c00001
[ 1.651151] i915_vma_bind ret 0
[ 1.651152] first ggtt entry after bind: 0x0000000078c00083
And "sudo cat /proc/iomem | grep Stolen" gives:
78c00000-88bfffff : Graphics Stolen Memory
There are no visual changes with this patch (BIOS vendor logo still
stays in place when we inherit the BIOS framebuffer), so the vma_bind()
does not impact which memory is being scanned out.
The address of the first ggtt entry matches with the start of stolen
and the i915_vma_bind call only changes the first gtt entry's flags,
or-ing in _PAGE_RW (BIT(1)) and PPAT_CACHED (BIT(7)), which perfectly
matches what we would expect based on gen8_pte_encode()'s behavior.
So it seems that the GOP indeed does NOT implement the wa and the i915's
code assuming a linear mapping at the start of stolen for the BIOS fb
still holds true for gen8+.
I've also tested this on a Cherry Trail based device (a GPD Win)
with identical results (the flags are 0x1b after the vma_bind
on CHT, which matches with I915_CACHE_NONE).
Changed in v2: No code changes, extended the commit message with the
verification that the intel_display.c BIOS framebuffer mapping is still
correct.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180420095933.16442-1-hdegoede@redhat.com
Timestamps are useful for IGT tests that trigger PSR exit and/or wait for
PSR entry.
v2: Removed seqlock (Ville)
Removed erroneous warning in irq loop (Chris)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-4-dhinakaran.pandiyan@intel.com
Interrupts other than the one for AUX errors are required only for debug,
so unmask them via debugfs when the user requests debug.
User can make such a request with
echo 1 > <DEBUG_FS>/dri/0/i915_edp_psr_debug
There are no locks to serialize PSR debug enabling from
irq_postinstall() and debugfs for simplicity. As irq_postinstall() is
called only during module initialization/resume and IGT subtests
aren't expected to modify PSR debug at those times, we should be safe.
v2: Unroll loops (Ville)
Avoid resetting error mask bits.
v3: Unmask interrupts in postinstall() if debug was still enabled.
Avoid RMW (Ville)
v4: Avoid extra IMR write introduced in the previous version.(Jose)
Style changes, renames (Jose).
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405013717.24254-1-dhinakaran.pandiyan@intel.com
Plug in the bdw+ irq handling for PSR interrupts. bdw+ supports psr on
any transcoder in theory, though the we don't currenty enable PSR except
on the EDP transcoder.
v2: From DK
* Rebased on drm-tip
v3: Switched author to Ville based on IRC discussion.
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403212420.25007-2-dhinakaran.pandiyan@intel.com
The definitions for the error register should be valid on bdw/skl too,
but there we haven't even enabled DE_MISC handling yet.
Somewhat confusing the the moved register offset on bdw is only for
the _CTL/_AUX register, and that _IIR/IMR stayed where they have been
on bdw.
v2: Fixes from Ville.
v3: From DK
* Rebased on drm-tip
* Removed BDW IIR bit definition, looks like an unintentional change that
should be in the following patch.
v4: From DK
* Don't mask REG_WRITE.
References: bspec/11974 [SRD Interrupt Bit Definition DevHSW]
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405220023.9449-1-dhinakaran.pandiyan@intel.com
One is outright unused, other can be made static.
Drive-by cleanup while accidentally reading dc code.
Cc: Imre Deak <imre.deak@intel.com>
Acked-by: Imre Deak <imre.deak@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180417100225.12286-1-daniel.vetter@ffwll.ch
The DMC FW specific part of display WA#1183 is supposed to be enabled
whenever enabling DC5 or DC6, so move it to the DC6 enable function
from the DC6 disable function.
I noticed this after Daniel's patch to remove the unused
skl_disable_dc6() function.
Fixes: 53421c2fe9 ("drm/i915: Apply Display WA #1183 on skl, kbl, and cfl")
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: <stable@vger.kernel.org>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180419155109.29451-1-imre.deak@intel.com
Make the PIPE_CONF_CHECK macros a bit more robust by wrapping them
in do {} while(0). Avoids funky sirprises when you try put an 'else'
after a PIPE_CONF_CHECK invocation...
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180316183625.16316-1-ville.syrjala@linux.intel.com
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> #irc
Move the limit checks near the calculations for each field, and actually
log the values that exceed limits.
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/20180419085940.21505-1-jani.nikula@intel.com
In GLK when the device boots with only 1366x768 panel without audio, HDA
codec doesn't come up. In this case, the CDCLK is less than twice the
BCLK. Even though audio isn't being enabled, having a too low CDCLK
leads to audio probe failing altogether.
Require CDCLK to be at least twice the BLCK regardless of audio. This is
a minimal fix to improve things. Unfortunately, this a) leads to too
high CDCLK being used when audio is not used, and b) is still not enough
to fix audio probe when no outputs are connected at probe time.
The proper fix would be to increase CDCLK dynamically from the audio
component hooks.
v2:
- Address comment (Jani)
- New design approach
v3: - Typo fix on top of v1
v4 by Jani: rewrite commit message, add comment in code
Cc: stable@vger.kernel.org
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@gmail.com>
Cc: Wenkai Du <wenkai.du@intel.com>
Reviewed-by: Wenkai Du <wenkai.du@intel.com>
Tested-by: Wenkai Du <wenkai.du@intel.com>
Acked-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=102937
Signed-off-by: Abhay Kumar <abhay.kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418103707.14645-1-jani.nikula@intel.com
Today we only want to pass along the priority to engine->schedule(), but
in the future we want to have much more control over the various aspects
of the GPU during a context's execution, for example controlling the
frequency allowed. As we need an ever growing number of parameters for
scheduling, move those into a struct for convenience.
v2: Move the anonymous struct into its own function for legibility and
ye olde gcc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-3-chris@chris-wilson.co.uk
Having moved the priotree struct into i915_scheduler.h, identify it as
the scheduling element and rebrand into i915_sched. This becomes more
useful as we start attaching more information we require to propagate
through the scheduler.
v2: Use i915_sched_node for future distinctiveness
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-2-chris@chris-wilson.co.uk
Over time the priotree has grown from a sorted list to a more
complicated structure for propagating constraints along the dependency
chain to try and resolve priority inversion. Start to segregate this
information from the rest of the request/fence tracking.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180418184052.7129-1-chris@chris-wilson.co.uk
On Geminilake, sometimes audio card is not getting
detected after reboot. This is a spurious issue happening on
Geminilake. HW codec and HD audio controller link was going
out of sync for which there was a fix in i915 driver but
was not getting invoked for GLK. Extending this fix to GLK as well.
Tested by Du,Wenkai on GLK board.
Bspec: 21829
v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)
Cc: <stable@vger.kernel.org> # b651bd2a3a ("drm/i915/audio: Fix audio enumeration issue on BXT")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Abhay Kumar <abhay.Kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
(cherry picked from commit 8221229046)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
We have to cleanup after i915_perf_init(), even on the error path, as it
passes a pointer into the module to the sysfs core. If we fail to
unregister the sysctl table, we leave a dangling pointer which then may
explode anytime later.
Fixes: 9f9b2792b6 ("drm/i915/perf: reuse timestamp frequency from device info")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180414091233.32224-1-chris@chris-wilson.co.uk
(cherry picked from commit 9f172f6fbd)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state, and if not, the best we can do is return the last known
RC6 value.
Without this check we can calculate the estimated value based on un-
initialized or inappropriate internal state, which can result in over-
estimation, or in any case incorrect value being returned.
v2:
* Re-arrange the code a bit to avoid second unlock and return branch.
(Chris Wilson)
v3:
* Insert some strategic blank lines and improve commit msg.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 1fe699e301 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410112704.24462-1-tvrtko.ursulin@linux.intel.com
(cherry picked from commit 2924bdee21)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Along the eb_lookup_vmas() error path, the return value from
kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
kmem_cache_free() instead.
Fixes: d1b48c1e71 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Xidong Wang <wangxidong_97@163.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v4.14+
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/20180404093824.9313-1-chris@chris-wilson.co.uk
(cherry picked from commit 6be1187dbf)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
On Geminilake, sometimes audio card is not getting
detected after reboot. This is a spurious issue happening on
Geminilake. HW codec and HD audio controller link was going
out of sync for which there was a fix in i915 driver but
was not getting invoked for GLK. Extending this fix to GLK as well.
Tested by Du,Wenkai on GLK board.
Bspec: 21829
v2: Instead of checking GEN9_BC, BXT and GLK macros, use IS_GEN9 macro (Jani N)
Cc: <stable@vger.kernel.org> # b651bd2a3a ("drm/i915/audio: Fix audio enumeration issue on BXT")
Cc: <stable@vger.kernel.org>
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Abhay Kumar <abhay.Kumar@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523989338-29677-1-git-send-email-gaurav.k.singh@intel.com
Silence smatch over:
drivers/gpu/drm/i915/selftests/intel_workarounds.c:58 read_nonprivs() error: 'cs' dereferencing possible ERR_PTR()
by handling a potential (but unlikely) failure of intel_ring_begin.
Fixes: f4ecfbfc32 ("drm/i915: Check whitelist registers across resets")
Signed-off-by: Oscar Mateo <oscar.mateo@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/1523915821-30624-1-git-send-email-oscar.mateo@intel.com
kvmgt get msi eventfd_ctx at qemu vfio set irq eventfd, then
msi eventfd_ctx should be put at some point.
The first point is kvmgt handle qemu vfio_disable_irqindex()
call which has DATA_NONE and ACTION_TRIGGER in flags.
If qemu doesn't call vfio_disable_irqindex(), the second point
is vgpu release function.
v2: Don't inject msi interrupt into guest if eventfd_ctx is dereferenced
Signed-off-by: Xiong Zhang <xiong.y.zhang@intel.com>
Reviewed-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
We have to cleanup after i915_perf_init(), even on the error path, as it
passes a pointer into the module to the sysfs core. If we fail to
unregister the sysctl table, we leave a dangling pointer which then may
explode anytime later.
Fixes: 9f9b2792b6 ("drm/i915/perf: reuse timestamp frequency from device info")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Matthew Auld <matthew.auld@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180414091233.32224-1-chris@chris-wilson.co.uk
Add a selftest to ensure that we restore the whitelisted registers after
rewrite the registers everytime they might be scrubbed, e.g. module
load, reset and resume. For the other volatile workaround registers, we
export their presence via debugfs and check in igt/gem_workarounds.
However, we don't export the whitelist and rather than do so, let's test
them directly in the kernel.
The test we use is to read the registers back from the CS (this helps us
be sure that the registers will be valid for MI_LRI etc). In order to
generate the expected list, we split intel_whitelist_workarounds_emit
into two phases, the first to build the list and the second to apply.
Inside the test, we only build the list and then check that list against
the hw.
v2: Filter out pre-gen8 as they do not have RING_NONPRIV.
v3: Drop unused engine parameter, no plans to use it now or future.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180414122754.569-1-chris@chris-wilson.co.uk
It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter
where we are passing GT type and Core family values.
Let's stop/remove setup of this parameter and remove related
definitions.
v2: (this time without squashed HAX)
- New title and description
- Remove also GUC_CORE_FAMILY_* definitions (Michel)
v3:
- The removed define GUC_CTL_DEVICE_INFO has been restored (Michel)
- Updated description (Sagar)
v4: rebase
Signed-off-by: Piotr Piórkowski <piotr.piorkowski@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: John A Spotswood <john.a.spotswood@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Acked-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180413085245.57206-1-piotr.piorkowski@intel.com
There are different kind of workarounds (those that modify registers that
live in the context image, those that modify global registers, those that
whitelist registers, etc...) and they have different requirements in terms
of where they are applied and how. Also, by splitting them apart, it should
be easier to decide where a new workaround should go.
v2:
- Add multiple MISSING_CASE
- Rebased
v3:
- Rename mmio_workarounds to gt_workarounds (Chris, Mika)
- Create empty placeholders for BDW and CHV GT WAs
- Rebased
v4: Rebased
v5:
- Rebased
- FORCE_TO_NONPRIV register exists since BDW, so make a path
for it to achieve universality, even if empty (Chris)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: appease checkpatch]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1523376767-18480-2-git-send-email-oscar.mateo@intel.com
This has grown to be a sizable amount of code, so move it to
its own file before we try to refactor anything. For the moment,
we are leaving behind the WA BB code and the WAs that get applied
(incorrectly) in init_clock_gating, but we will deal with it later.
v2: Use intel_ prefix for code that deals with the hardware (Chris)
v3: Rebased
v4:
- Rebased
- New license header
v5:
- Rebased
- Added some organisational notes to the file (Chris)
v6: Include DOC section in the documentation build (Jani)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Jani Nikula <jani.nikula@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
[ickle: appease checkpatch, mostly]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1523376767-18480-1-git-send-email-oscar.mateo@intel.com
We can refine our current execlists->queue_priority if we inspect
ELSP[1] rather than the head of the unsubmitted queue. Currently, we use
the unsubmitted queue and say that if a subsequent request is more
important than the current queue, we will rerun the submission tasklet
to evaluate the need for preemption. However, we only want to preempt if
we need to jump ahead of a currently executing request in ELSP. The
second reason for running the submission tasklet is amalgamate requests
into the active context on ELSP[0] to avoid a stall when ELSP[0] drains.
(Though repeatedly amalgamating requests into the active context and
triggering many lite-restore is off question gain, the goal really is to
put a context into ELSP[1] to cover the interrupt.) So if instead of
looking at the head of the queue, we look at the context in ELSP[1] we
can answer both of the questions more accurately -- we don't need to
rerun the submission tasklet unless our new request is important enough
to feed into, at least, ELSP[1].
v2: Add some comments from the discussion with Tvrtko.
v3: More commentary to cross-reference queue_request()
References: f6322eddaf ("drm/i915/preemption: Allow preemption between submission ports")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180411103929.27374-1-chris@chris-wilson.co.uk
Apparently caused by a merge fail at some point. Due to the nature of
the duplicated block, the second one will have no effect, and there's no
need to backport.
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410091248.1454-1-jani.nikula@intel.com
While thinking about sporadic failures of perf_pmu/rc6-runtime-pm* tests
on some CI machines I have concluded that: a) the PMU readout of RC6 can
race against runtime PM transitions, and b) there are other reasons than
being runtime suspended which can cause intel_runtime_pm_get_if_in_use to
fail.
Therefore when estimating RC6 the code needs to assert we are indeed in
suspended state, and if not, the best we can do is return the last known
RC6 value.
Without this check we can calculate the estimated value based on un-
initialized or inappropriate internal state, which can result in over-
estimation, or in any case incorrect value being returned.
v2:
* Re-arrange the code a bit to avoid second unlock and return branch.
(Chris Wilson)
v3:
* Insert some strategic blank lines and improve commit msg.
(Chris Wilson)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Fixes: 1fe699e301 ("drm/i915/pmu: Fix sleep under atomic in RC6 readout")
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105010
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410112704.24462-1-tvrtko.ursulin@linux.intel.com
The error exit path when a duplicate is found does not kfree and cmd_entry
struct and hence there is a small memory leak. Fix this by kfree'ing it.
Detected by CoverityScan, CID#1370198 ("Resource Leak")
Fixes: be1da7070a ("drm/i915/gvt: vGPU command scanner")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
%phn is not a valid specifier, and the trailing 'n' is being eaten by
the format-specifier and defaulting to the ' ' separator. Avoid angering
smatch by using the unknown specifier, and use the default we expect.
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:616 ctb_read() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:669 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:679 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:693 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:707 ct_handle_response() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:727 ct_process_request() warn: '%ph' cannot be followed by 'n'
drivers/gpu/drm/i915/intel_guc_ct.c:803 ct_handle_request() warn: '%ph' cannot be followed by 'n'
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410111417.27563-1-chris@chris-wilson.co.uk
Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop
forcibly reloading the registers.
Ville suggested this many moons ago, I said at that time that sanitizing
was no harm and meant that our bookkeeping was kept consistent with the
HW. However, in a forthcoming series, we want to split rps/rc6 GT
powermanagement and one of the key simplifications is the control of
when we enable it. Performing a crude sanitize in the middle of
i915_gem_reset() is then a huge wart.
Suggested-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180410133354.13425-1-chris@chris-wilson.co.uk
Inside the psr work function, we want to wait for PSR to idle first and
wish to do so without blocking the normal modeset path, so we do so
without holding the PSR lock. However, we first have to find which pipe
PSR was enabled on, which requires chasing into the PSR struct and
requires locking to prevent intel_psr_disable() from concurrently
setting our pointer to NULL.
Fixes: 995d304774 ("drm/i915: VLV/CHV PSR Software timer mode")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Durgadoss R <durgadoss.r@intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: <stable@vger.kernel.org> # v4.0+
Reviewed-by: Jose Roberto de Souza <jose.souza@intel.com>
Acked-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405114915.29609-1-chris@chris-wilson.co.uk
On GLK sporadic timeouts occur during PHY0 enabling. Based on logs it looks
like they happen sometime after a system suspend/resume cycle, with the
same power well enabling succeeding both before and after the failed
one and no other problems observed. The current timeout in the code is
not actually specified by BSpec, so let's try to increase that until a
BSpec update.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105771
Signed-off-by: Imre Deak <imre.deak@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409122716.4055-1-imre.deak@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
All the references to get_existing_state can be converted to
get_new_state or get_old_state, which means that i915 is now
get_existing_state free.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180409124656.39886-3-maarten.lankhorst@linux.intel.com
[mlankhorst: Fix alignment in prepare_plane_fb. (Ville)]
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Include fence context and seqno in low level tracing so it is easier to
follow flows of individual requests when things go bad.
Also added tracing on the reset side of things.
v2:
Chris Wilson:
* Standardize global_seqno and seqno as global.
* Include current hws seqno in execlists_cancel_port_requests.
v3:
* Fix port printk format for all builds.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v2
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406123514.5809-1-tvrtko.ursulin@linux.intel.com
This patch updates scaler max limit support for NV12
v2: Rebased (me)
v3: Rebased (me)
v4: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v5: Addressed review comments from Ville and rebased
- calculation of max_scale to be made
less convoluted by splitting it up a bit
- Indentation errors to be fixed in the series
v6: Rebased (me)
Fixed review comments from Paauwe, Bob J
Previous version, where a split of calculation
was done, was wrong. Fixed that issue here.
v7: Rebased (me)
v8: Rebased (me)
v9: Rebased (me)
v10: Rebased (me)
v11: Addressed review comments from Shashank Sharma
Alignment issues fixed.
When call to skl_update_scaler is made, 0 was being
sent instead of pixel_format.
When crtc update scaler is called, we dont have the
fb to derive the pixel format. Added the function
parameter bool plane_scaler_check to account for this.
v12: Fixed failure in IGT debugfs_test.
fb is NULL in skl_update_scaler_plane
Due to this, accessing fb->format caused failure.
Patch checks fb before using.
v13: In the previous version there was a flaw.
In skl_update_scaler during plane_scaler_check
if the format was non-NV12, it would set need_scaling
to false. This could reset the previously set need_scaling
from a previous condition check. Patch fixes this.
Patch also adds minimum src height for YUV 420 formats
to 16 (as defined in BSpec) and adds for checking this
range.
v14: Addressed review comments from Maarten
Just add a check for NV12 min src height in
skl_update_scaler and retain the remaining checks
as is. Added Reviewed By from Juha-Pekka Heikkila.
v15: Rebased the series.
v16: Changed fb height restriction to be >= 16 as per
Bspec. Earlier it was > 16.
v17: Adding src width and height to be mult of 4 restriction
to avoid pipe fifo underruns for NV12.
Credits-to: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-15-git-send-email-vidya.srinivas@intel.com
This patch adds NV12 to format_is_yuv() function
for sprite planes.
v2:
-Use intel_ prefix for format_is_yuv (Ville)
v3: Rebased (me)
v4: Rebased and addressed review comments from Clinton A Taylor.
"static function in intel_sprite.c is not available
to the primary plane functions".
Changed commit message - function modified for
sprite planes.
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v6: Rebased (me)
v7: Rebased (me)
v8: Rebased (me)
v9: Rebased (me)
v10: Changed intel_format_is_yuv function from
static to non-static. We need to use it later from
other files for check.
v11: Rebased the patch. format_is_yuv has already
been renamed to intel_format_is_yuv in the color
patch series which is already merged. This function
which was previously static has already been made
non-static. So this patch after rebase just adds
NV12 to intel_format_is_yuv function.
v12: Added reviewed by from Juha-Pekka Heikkila
v13/v14/v15: Rebased the series
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-14-git-send-email-vidya.srinivas@intel.com
This patch sets appropriate scaler mode for NV12 format.
In this mode, skylake scaler does either chroma-upsampling or
chroma-upsampling and resolution scaling
v2: Review comments from Ville addressed
NV12 case to be checked first for setting
the scaler
v3: Rebased (me)
v4: Rebased (me)
v5: Missed the Tested-by/Reviewed-by in the previous series
Adding the same to commit message in this version.
v6: Rebased (me)
v7: Rebased (me)
v8: Rebased (me)
Restricting the NV12 change for scaler to BXT and KBL
in this series.
v9: Rebased (me)
v10: As of now, NV12 has been tested on Gen9 and Gen10. However,
code is applicable to all GEN >= 9. Hence making
that change to keep it generic.
Comments under v8 is not valid anymore.
v11: Addressed review comments by Shashank Sharma.
For Gen10+, the scaler mode to be set it planar or normal
(single bit). Changed the code to be applicable to all
Gen.
v12: Addressed review comments from Shashank Sharma
For Gen9 (apart from GLK) bits 28:29 to be programmed
in PS_CTRL for NV12. For GLK and Gen10+, bit 29 to be set
for all Planar.
v13: Addressed review comments from Juha-Pekka Heikkila
"NV12 not to be supported by SKL"
Adding Reviewed by tag from Shashank Shamr
v14: Added reviewed by from Juha-Pekka Heikkila
v15: Rebased the series
Tested-by: Clinton Taylor <clinton.a.taylor@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Clinton Taylor <clinton.a.taylor@intel.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-13-git-send-email-vidya.srinivas@intel.com
If the fb format is YUV, enable the plane CSC mode bits
for the conversion.
v2: Addressed review comments from Shashank Sharma
Alignment issue fixed in i915_reg.h
v3: Adding Reviewed By from Shashank Sharma
v4: Rebased the patch. As part of rebasing, re-using
the color series defines which are already merged.
plane_state->base.color_encoding might not be set for
NV12. For now, just using PLANE_COLOR_CSC_MODE_YUV709_TO_RGB709
in glk_plane_color_ctl if format is NV12.
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-12-git-send-email-vidya.srinivas@intel.com
Display WA 827 applies to GEN9 (excluede GLK) and CNL.
Switching the plane format from NV12 to RGB and leaving system idle
results in display underrun and corruption.
WA: Set the bit 15 & bit 19 to 1b in the CLKGATE_DIS_PSL
register for the pipe in which NV12 plane is enabled.
v2: Addressed review comments from Maarten and
Juha-Pekka Heikkila. Added reviewed by from
Juha-Pekka Heikkila.
v3: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Signed-off-by: Chandra Konduru <chandra.konduru@intel.com>
Signed-off-by: Nabendu Maiti <nabendu.bikash.maiti@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-11-git-send-email-vidya.srinivas@intel.com
This patch splits skl_compute_wm/ddb functions into two parts.
One adds all affected pipes after the commit to atomic_state structure
and second part does compute the DDB.
v2: Added reviewed by tag from Shashank Sharma
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
v5: Fixed checkpatch error. Changed *changed = true
to (*changed) = true;
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-10-git-send-email-vidya.srinivas@intel.com
Display Workaround #0826 (SKL:ALL BXT:ALL) & #1059(CNL:A)
Hardware sometimes fails to wake memory from pkg C states fetching the
last few lines of planar YUV 420 (NV12) planes. This causes
intermittent underflow and corruption.
WA: Disable package C states or do not enable latency levels 1 through 7
(WM1 - WM7) on NV12 planes.
v2: Addressed review comments by Maarten.
v3: Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-9-git-send-email-vidya.srinivas@intel.com
DDB allocation optimization algorithm requires/assumes ddb allocation for
any memory C-state level DDB value to be as high as level below the
current level. Render decompression requires level WM to be as high as
wm level-0. This patch fulfils both the requirements.
v2: Changed plane_num to plane_id in skl_compute_wm_levels
v3: Addressed review comments from Shashank Sharma
Changed the commit message "statement can be more clear,
"DDB value to be as high as level below " what is level below ?"
v4: Added reviewed by tag from Shashank Sharma
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-8-git-send-email-vidya.srinivas@intel.com
This patch passes skl_wm_level structure itself to watermark
computation function skl_compute_plane_wm function (instead
of its internal parameters). It reduces number of arguments
required to be passed.
v2: Addressed review comments by Shashank Sharma
v3: Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-7-git-send-email-vidya.srinivas@intel.com
NV12 requires WM calculation for UV plane as well.
UV plane WM should also fulfill all the WM related restrictions.
v2: Addressed review comments from Shashank Sharma.
v3: Addressed review comments from Shashank Sharma
Changed plane_num to plane_id in skl_compute_plane_wm_params
and skl_compute_plane_wm.
Adding reviewed by tag from Shashank Sharma
v4: Added reviewed by from Juha-Pekka Heikkila
v5: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-6-git-send-email-vidya.srinivas@intel.com
For YUV 420 Planar formats like NV12,
buffer allocation is done for Y and UV surfaces separately.
For NV12 plane formats, the UV buffer
allocation must be programmed in the Plane Buffer Config register
and the Y buffer allocation must be programmed in the
Plane NV12 Buffer Config register. Both register values
should be verified during verify_wm_state.
v2: Addressed review comments by Maarten.
v3: Addressed review comments by Shashank Sharma.
v4: Adding reviewed by tag from Shashank Sharma
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Shashank Sharma <shashank.sharma@intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-5-git-send-email-vidya.srinivas@intel.com
Add support of recognizing DRM_FORMAT_NV12 from plane_format
register value.
v2: Added reviewed by tag from Mika Kahola
v3: Added reviewed by from Juha-Pekka Heikkila
v4: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Mika Kahola <mika.kahola@intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-4-git-send-email-vidya.srinivas@intel.com
Current code calculates DDB for planar formats in such a way that we
store DDB of plane-0 in plane 1 & vice-versa.
In order to make this clean this patch refactors WM/DDB calculation for
NV12 planar formats.
v2: Addressed review comments by Maarten
v3: Rebased and addressed review comments by Maarten
v4: Fixed a compilation issue of string replacement is_nv12 to
is_planar
v5: Added reviewed by from Juha-Pekka Heikkila
v6: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Vidya Srinivas <vidya.srinivas@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-3-git-send-email-vidya.srinivas@intel.com
skl_wm_values struct contains values of pipe/plane DDB only.
so rename it for better readability of code. Similarly
skl_copy_wm_for_pipe copies DDB values.
s/skl_wm_values/skl_ddb_values
s/skl_copy_wm_for_pipe/skl_copy_ddb_for_pipe
Changes since V1:
- also change name of skl_copy_wm_for_pipe
v2: Added reviewed by from Juha-Pekka Heikkila
v3: Rebased the series
Reviewed-by: Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Signed-off-by: Mahesh Kumar <mahesh1.kumar@intel.com>
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523245273-30264-2-git-send-email-vidya.srinivas@intel.com
When doing a modeset where the sink is transitioning from D3 to D0 , it
would sometimes be possible for the initial power_up_phy() to start
timing out. This would only be observed in the last action before the
sink went into D3 mode was intel_dp_sink_dpms(DRM_MODE_DPMS_OFF). We
originally thought this might be an issue with us accidentally shutting
off the aux block when putting the sink into D3, but since the DP spec
mandates that sinks must wake up within 1ms while we have 100ms to
respond to an ESI irq, this didn't really add up. Turns out that the
problem is more subtle then that:
It turns out that the timeout is from us not enabling DPMS on the MST
hub before actually trying to initiate sideband communications. This
would cause the first sideband communication (power_up_phy()), to start
timing out because the sink wasn't ready to respond. Afterwards, we
would call intel_dp_sink_dpms(DRM_MODE_DPMS_ON) in
intel_ddi_pre_enable_dp(), which would actually result in waking up the
sink so that sideband requests would work again.
Since DPMS is what lets us actually bring the hub up into a state where
sideband communications become functional again, we just need to make
sure to enable DPMS on the display before attempting to perform sideband
communications.
Changes since v1:
- Remove comment above if (!intel_dp->is_mst) - vsryjala
- Move intel_dp_sink_dpms() for MST into intel_dp_post_disable_mst() to
keep enable/disable paths symmetrical
- Improve commit message - dhnkrn
Changes since v2:
- Only send DPMS off when we're disabling the last sink, and only send
DPMS on when we're enabling the first sink - dhnkrn
Changes since v3:
- Check against is_mst, not intel_dp->is_mst - dhnkrn/vsyrjala
Signed-off-by: Lyude Paul <lyude@redhat.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Tested-by: Laura Abbott <labbott@redhat.com>
Cc: stable@vger.kernel.org
Fixes: ad260ab32a ("drm/i915/dp: Write to SET_POWER dpcd to enable MST hub.")
Link: https://patchwork.freedesktop.org/patch/msgid/20180407011053.22437-1-lyude@redhat.com
-----BEGIN PGP SIGNATURE-----
iQJIBAABCgAyFiEEgMe7l+5h9hnxdsnuWYigwDrT+vwFAlrHeY8UHGJoZWxnYWFz
QGdvb2dsZS5jb20ACgkQWYigwDrT+vxhLRAAndV/0NDyWZU0eZNM6twri2SEFnF7
E4ar+YthxDxxJG4TLJbIA12jc5NgHZy4WuttDa6Jb99KreBXIHJFlNi/V/tme6zf
+yXUuxWae7wJzBiaay57VqLGSc80gt/LTgjLa1siwQqjTbO3wSXR6JJXNaE9FtQ4
/jL61t8bD1Peb5cWTpt9p0hrnKI0/pHwASdReyFS4F/HDKdvpof7BxE/OU3HSxxA
XKC2v6RjY4S93vkzvApDXQ+vhKquVRK7/ojyTXQUO/GIzcARprO7H4k62N4ar0x/
qbXLkR8IMkwA8ecsNmcL92ftb/cXoHfd+wdK8WpijqzF4kW4SdteVWbIhUzI0gbr
0gjDYIzjplvH3pZGv/qvx+8sFtAP95OdPjuAAW2qJ9TCVfmiS8naNFCvcxg87RhD
gjyQD3If1X7F8wy309lhq7VNyRexTHgIMgTXHyFvuZMzn/Qe1huL2XCwDcEAg/OX
AvU2iuSE5tWAh7gIUMF/aWi3uoeJUyyoru5ZR//gqdFfx9YxpSimO1UDXnpPi8SR
Iz/jzHJc0aWGYdQ9l6HiSbJF3P/QQcWYs9igt0A7BRGB05SPdWCh7sSO70FJa8ME
f4WID5/qEiaH26kiSRX4cUqpc8Amk8bT0DXw2OT57qy3JM0ZdV5ENQX11pSpr9hv
uLEf0DU7AEmdvzQ=
=T++R
-----END PGP SIGNATURE-----
Merge tag 'pci-v4.17-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci
Pull PCI updates from Bjorn Helgaas:
- move pci_uevent_ers() out of pci.h (Michael Ellerman)
- skip ASPM common clock warning if BIOS already configured it (Sinan
Kaya)
- fix ASPM Coverity warning about threshold_ns (Gustavo A. R. Silva)
- remove last user of pci_get_bus_and_slot() and the function itself
(Sinan Kaya)
- add decoding for 16 GT/s link speed (Jay Fang)
- add interfaces to get max link speed and width (Tal Gilboa)
- add pcie_bandwidth_capable() to compute max supported link bandwidth
(Tal Gilboa)
- add pcie_bandwidth_available() to compute bandwidth available to
device (Tal Gilboa)
- add pcie_print_link_status() to log link speed and whether it's
limited (Tal Gilboa)
- use PCI core interfaces to report when device performance may be
limited by its slot instead of doing it in each driver (Tal Gilboa)
- fix possible cpqphp NULL pointer dereference (Shawn Lin)
- rescan more of the hierarchy on ACPI hotplug to fix Thunderbolt/xHCI
hotplug (Mika Westerberg)
- add support for PCI I/O port space that's neither directly accessible
via CPU in/out instructions nor directly mapped into CPU physical
memory space. This is fairly intrusive and includes minor changes to
interfaces used for I/O space on most platforms (Zhichang Yuan, John
Garry)
- add support for HiSilicon Hip06/Hip07 LPC I/O space (Zhichang Yuan,
John Garry)
- use PCI_EXP_DEVCTL2_COMP_TIMEOUT in rapidio/tsi721 (Bjorn Helgaas)
- remove possible NULL pointer dereference in of_pci_bus_find_domain_nr()
(Shawn Lin)
- report quirk timings with dev_info (Bjorn Helgaas)
- report quirks that take longer than 10ms (Bjorn Helgaas)
- add and use Altera Vendor ID (Johannes Thumshirn)
- tidy Makefiles and comments (Bjorn Helgaas)
- don't set up INTx if MSI or MSI-X is enabled to align cris, frv,
ia64, and mn10300 with x86 (Bjorn Helgaas)
- move pcieport_if.h to drivers/pci/pcie/ to encapsulate it (Frederick
Lawler)
- merge pcieport_if.h into portdrv.h (Bjorn Helgaas)
- move workaround for BIOS PME issue from portdrv to PCI core (Bjorn
Helgaas)
- completely disable portdrv with "pcie_ports=compat" (Bjorn Helgaas)
- remove portdrv link order dependency (Bjorn Helgaas)
- remove support for unused VC portdrv service (Bjorn Helgaas)
- simplify portdrv feature permission checking (Bjorn Helgaas)
- remove "pcie_hp=nomsi" parameter (use "pci=nomsi" instead) (Bjorn
Helgaas)
- remove unnecessary "pcie_ports=auto" parameter (Bjorn Helgaas)
- use cached AER capability offset (Frederick Lawler)
- don't enable DPC if BIOS hasn't granted AER control (Mika Westerberg)
- rename pcie-dpc.c to dpc.c (Bjorn Helgaas)
- use generic pci_mmap_resource_range() instead of powerpc and xtensa
arch-specific versions (David Woodhouse)
- support arbitrary PCI host bridge offsets on sparc (Yinghai Lu)
- remove System and Video ROM reservations on sparc (Bjorn Helgaas)
- probe for device reset support during enumeration instead of runtime
(Bjorn Helgaas)
- add ACS quirk for Ampere (née APM) root ports (Feng Kan)
- add function 1 DMA alias quirk for Marvell 88SE9220 (Thomas
Vincent-Cross)
- protect device restore with device lock (Sinan Kaya)
- handle failure of FLR gracefully (Sinan Kaya)
- handle CRS (config retry status) after device resets (Sinan Kaya)
- skip various config reads for SR-IOV VFs as an optimization
(KarimAllah Ahmed)
- consolidate VPD code in vpd.c (Bjorn Helgaas)
- add Tegra dependency on PCI_MSI_IRQ_DOMAIN (Arnd Bergmann)
- add DT support for R-Car r8a7743 (Biju Das)
- fix a PCI_EJECT vs PCI_BUS_RELATIONS race condition in Hyper-V host
bridge driver that causes a general protection fault (Dexuan Cui)
- fix Hyper-V host bridge hang in MSI setup on 1-vCPU VMs with SR-IOV
(Dexuan Cui)
- fix Hyper-V host bridge hang when ejecting a VF before setting up MSI
(Dexuan Cui)
- make several structures static (Fengguang Wu)
- increase number of MSI IRQs supported by Synopsys DesignWare bridges
from 32 to 256 (Gustavo Pimentel)
- implemented multiplexed IRQ domain API and remove obsolete MSI IRQ
API from DesignWare drivers (Gustavo Pimentel)
- add Tegra power management support (Manikanta Maddireddy)
- add Tegra loadable module support (Manikanta Maddireddy)
- handle 64-bit BARs correctly in endpoint support (Niklas Cassel)
- support optional regulator for HiSilicon STB (Shawn Guo)
- use regulator bulk API for Qualcomm apq8064 (Srinivas Kandagatla)
- support power supplies for Qualcomm msm8996 (Srinivas Kandagatla)
* tag 'pci-v4.17-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/helgaas/pci: (123 commits)
MAINTAINERS: Add John Garry as maintainer for HiSilicon LPC driver
HISI LPC: Add ACPI support
ACPI / scan: Do not enumerate Indirect IO host children
ACPI / scan: Rename acpi_is_serial_bus_slave() for more general use
HISI LPC: Support the LPC host on Hip06/Hip07 with DT bindings
of: Add missing I/O range exception for indirect-IO devices
PCI: Apply the new generic I/O management on PCI IO hosts
PCI: Add fwnode handler as input param of pci_register_io_range()
PCI: Remove __weak tag from pci_register_io_range()
MAINTAINERS: Add missing /drivers/pci/cadence directory entry
fm10k: Report PCIe link properties with pcie_print_link_status()
net/mlx5e: Use pcie_bandwidth_available() to compute bandwidth
net/mlx5: Report PCIe link properties with pcie_print_link_status()
net/mlx4_core: Report PCIe link properties with pcie_print_link_status()
PCI: Add pcie_print_link_status() to log link speed and whether it's limited
PCI: Add pcie_bandwidth_available() to compute bandwidth available to device
misc: pci_endpoint_test: Handle 64-bit BARs properly
PCI: designware-ep: Make dw_pcie_ep_reset_bar() handle 64-bit BARs properly
PCI: endpoint: Make sure that BAR_5 does not have 64-bit flag set when clearing
PCI: endpoint: Make epc->ops->clear_bar()/pci_epc_clear_bar() take struct *epf_bar
...
Currently, we rely on inspecting the hangcheck state from within the
i915_reset() routines to determine which engines were guilty of the
hang. This is problematic for cases where we want to run
i915_handle_error() and call i915_reset() independently of hangcheck.
Instead of relying on the indirect parameter passing, turn it into an
explicit parameter providing the set of stalled engines which then are
treated as guilty until proven innocent.
While we are removing the implicit stalled parameter, also make the
reason into an explicit parameter to i915_reset(). We still need a
back-channel for i915_handle_error() to hand over the task to the locked
waiter, but let's keep that its own channel rather than incriminate
another.
This leaves stalled/seqno as being private to hangcheck, with no more
nefarious snooping by reset, be it whole-device or per-engine. \o/
The only real issue now is that this makes it crystal clear that we
don't actually do any testing of hangcheck per se in
drv_selftest/live_hangcheck, merely of resets!
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@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/20180406220354.18911-2-chris@chris-wilson.co.uk
If we are resetting just one engine, we know it has stalled. So we can
pass the stalled parameter directly to i915_gem_reset_engine(), which
alleviates the necessity to poke at the generic engine->hangcheck.stalled
magic variable, leaving that under control of hangcheck as its name
implies. Other than simplifying by removing the indirect parameter along
this path, this allows us to introduce new reset mechanisms that run
independently of hangcheck.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@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/20180406220354.18911-1-chris@chris-wilson.co.uk
We will want to park GEM before disengaging the drive^W^W^W unwedging.
Since we already do the work for idling, expose the guts as a new
function that we can then reuse.
v2: Just skip if already parked; makes it more forgiving to use by
future callers.
v3: Extract mark_busy, rename it to i915_gem_unpark and place it next to
i915_gem_park so that we can evaluate it for symmetry more easily.
Calling GEM from inside i915_request looks to be a bit of a layering
violation, for the moment I am imaging them as being notify_cb.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com> #v1
Reviewed-by: Michal Wajdeczko <michal.wajdeczko@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406155144.27791-1-chris@chris-wilson.co.uk
Tvrtko mentioned that wait_for_hang() was confusing as it does not
actually wait for the aforementioned hang, just until the request is
running and we are *ready* to inject a hang. A quick
s/wait_for_hang/wait_until_running/ removes that confusion without
having to rethink the naming scheme, immediately at least.
Suggested-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
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>
Cc: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406100950.19033-1-chris@chris-wilson.co.uk
AFAICT, once the new interrupt is in place, the rest should behave the
same as Gen10.
v2: Update ring frequencies (Sagar)
v3: Rebase.
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-5-mika.kuoppala@linux.intel.com
BSpec says:
"Second level interrupt events are stored in the GT INT DW. GT INT DW is
a double buffered structure. A snapshot of events is taken when SW reads
GT INT DW. From the time of read to the time of SW completely clearing
GT INT DW (to indicate end of service), all incoming interrupts are logged
in a secondary storage structure. this guarantees that the record of
interrupts SW is servicing will not change while under service".
We read GT INT DW in several places now:
- The IRQ handler (banks 0 and 1) where, hopefully, it is completely
cleared (operation now covered with the irq lock).
- The 'reset' interrupts functions for RPS and GuC logs, where we clear
the bit we are interested in and leave the others for the normal
interrupt handler.
- The 'enable' interrupts functions for RPS and GuC logs, as a measure
of precaution. Here we could relax a bit and don't check GT INT DW
at all or, if we do, at least we should clear the offending bit
(which is what this patch does).
Note that, if every bit is cleared on reading GT INT DW, the register
won't be locked. Also note that, according to the BSpec, GT INT DW
cannot be cleared without first servicing the Selector & Shared IIR
registers.
v2:
- Remove some code duplication (Tvrtko)
- Make sure GT_INTR_DW are protected by the irq spinlock, since it's a
global resource (Tvrtko)
v3: Optimize the spinlock (Tvrtko)
v4: Rebase.
v5:
- take spinlock on outer scope to please sparse (Mika)
- use raw_reg accessors (Mika)
v6: omit the continue in looping banks (Michel)
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com> (v4)
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406093237.14548-1-mika.kuoppala@linux.intel.com
Using the new hierarchical interrupt infrastructure.
v2: Rebase
v3: Rebase
v4: use class/instance handler (Mika)
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-3-mika.kuoppala@linux.intel.com
Interrupt identity register we already read from hardware
contains engine class and instance fields. Leverage
these fields to find correct engine to handle the interrupt.
v3: rebase on top of rps intr
use correct class / instance limits (Michel)
v4: split engine/other handling
v5: empty iir is not err (Daniele, Michel)
Suggested-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Michel Thierry <michel.thierry@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180406093145.14389-1-mika.kuoppala@linux.intel.com
The bits used to reset the different engines/domains have changed in
GEN11, this patch maps the reset engine mask bits with the new bits
in the reset control register.
v2: Use shift-left instead of BIT macro to match the file style (Paulo).
v3: Reuse gen8_reset_engines (Daniele).
v4: Do not call intel_uncore_forcewake_reset after reset, we may be
using the forcewake to read protected registers elsewhere and those
results may be clobbered by the concurrent dropping of forcewake.
bspec: 19212
Cc: Oscar Mateo <oscar.mateo@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Acked-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Signed-off-by: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Oscar Mateo <oscar.mateo@intel.com>
Signed-off-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405140052.10682-1-mika.kuoppala@linux.intel.com
Now that "DOC: User command execution" of i915_gem_execbuffer.c is included
in the i915.rst, it is benecifial (for new developers) to read what happens
at the bottom of the driver stack (in terms of bytes written to be read
by the GPU) when processing a user-space batchbuffer.
v5:
Typo correction of lacking double tick.
Signed-off-by: Kevin Rogovin <kevin.rogovin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
[Joonas: correcting the patch title]
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1523001957-6427-4-git-send-email-kevin.rogovin@intel.com
We don't handle resetting the kernel context very well, or presumably any
context executing its breadcrumb commands in the ring as opposed to the
batchbuffer and flush. If we trigger a device reset twice in quick
succession while the kernel context is executing, we may end up skipping
the breadcrumb. This is really only a problem for the selftest as
normally there is a large interlude between resets (hangcheck), or we
focus on resetting just one engine and so avoid repeatedly resetting
innocents.
Something to try would be a preempt-to-idle to quiesce the engine before
reset, so that innocent contexts would be spared the reset.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180330131801.18327-1-chris@chris-wilson.co.uk
On Apollolake, with stress test warm reboot, audio card was not getting
enumerated after reboot. This was a spurious issue happening on
Apollolake. HW codec and HD audio controller link was going out of sync
for which there was a fix in i915 driver but was not getting invoked for
BXT. Extending this fix to BXT as well.
Tested on apollolake chromebook by stress test warm reboot with 2500
iterations.
Bspec: 21829
Signed-off-by: Gaurav K Singh <gaurav.k.singh@intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1522946544-11524-1-git-send-email-gaurav.k.singh@intel.com
Pull trivial tree updates from Jiri Kosina.
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial:
kfifo: fix inaccurate comment
tools/thermal: tmon: fix for segfault
net: Spelling s/stucture/structure/
edd: don't spam log if no EDD information is present
Documentation: Fix early-microcode.txt references after file rename
tracing: Block comments should align the * on each line
treewide: Fix typos in printk
GenWQE: Fix a typo in two comments
treewide: Align function definition open/close braces
If we skip the intel_prepare_reset(), we should also skip the
intel_display_reset(). If we we use a flag set by intel_prepare_reset()
then we do not have to second guess based on external user controlled
state whether or not the prepare was called before deciding to finish
it after the reset. igt/gem_eio is one such example that may tweak
i915.reset faster than the code is expecting, leading to
[ 190.233528] =====================================
[ 190.233534] WARNING: bad unlock balance detected!
[ 190.233540] 4.16.0-rc7-g335ef9849310-drmtip_10+ #1 Tainted: G U
[ 190.233547] -------------------------------------
[ 190.233553] gem_eio/1348 is trying to release lock (crtc_ww_class_acquire) at:
[ 190.233569] [<ffffffff895c7810>] drm_modeset_acquire_fini+0x0/0x60
[ 190.233575] but there are no more locks to release!
[ 190.233580]
other info that might help us debug this:
[ 190.233588] 3 locks held by gem_eio/1348:
[ 190.233592] #0: (&f->f_pos_lock){+.+.}, at: [<00000000ab90c784>] __fdget_pos+0x3a/0x50
[ 190.233607] #1: (sb_writers#11){.+.+}, at: [<00000000e1529265>] vfs_write+0x188/0x1a0
[ 190.233622] #2: (&attr->mutex){+.+.}, at: [<0000000011f40afe>] simple_attr_write+0x36/0xd0
[ 190.233635]
stack backtrace:
[ 190.233644] CPU: 0 PID: 1348 Comm: gem_eio Tainted: G U 4.16.0-rc7-g335ef9849310-drmtip_10+ #1
[ 190.233655] Hardware name: Dell Inc. OptiPlex GX280 /0G8310, BIOS A04 02/09/2005
[ 190.233664] Call Trace:
[ 190.233674] dump_stack+0x67/0x95
[ 190.233682] ? drm_modeset_backoff+0x1b0/0x1b0
[ 190.233690] print_unlock_imbalance_bug+0xd2/0xe0
[ 190.233698] ? drm_modeset_backoff+0x1b0/0x1b0
[ 190.233704] lock_release+0x23e/0x300
[ 190.233712] drm_modeset_acquire_fini+0x16/0x60
[ 190.233835] intel_finish_reset+0x72/0x160 [i915]
[ 190.233894] i915_reset_device+0x1e9/0x240 [i915]
[ 190.233953] ? __intel_get_crtc_scanline+0x1c0/0x1c0 [i915]
[ 190.233962] ? work_on_cpu_safe+0x50/0x50
[ 190.234020] i915_handle_error+0x1f2/0x470 [i915]
[ 190.234031] ? __might_fault+0x39/0x90
[ 190.234037] ? __might_fault+0x39/0x90
[ 190.234099] i915_wedged_set+0x7f/0xc0 [i915]
[ 190.234107] simple_attr_write+0xb0/0xd0
[ 190.234117] full_proxy_write+0x51/0x80
[ 190.234125] __vfs_write+0x21/0x140
[ 190.234133] ? rcu_read_lock_sched_held+0x6f/0x80
[ 190.234140] ? rcu_sync_lockdep_assert+0x29/0x50
[ 190.234147] ? __sb_start_write+0x152/0x1f0
[ 190.234152] ? __sb_start_write+0x168/0x1f0
[ 190.234159] vfs_write+0xbd/0x1a0
[ 190.234166] SyS_write+0x40/0xa0
[ 190.234173] ? do_syscall_64+0x19/0x1b0
[ 190.234180] do_syscall_64+0x6b/0x1b0
[ 190.234188] entry_SYSCALL_64_after_hwframe+0x42/0xb7
[ 190.234196] RIP: 0033:0x7f84c1b392b7
[ 190.234201] RSP: 002b:00007f84b6755b00 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 190.234211] RAX: ffffffffffffffda RBX: 0000000000000046 RCX: 00007f84c1b392b7
[ 190.234218] RDX: 0000000000000002 RSI: 000055ec20abc8d6 RDI: 0000000000000046
[ 190.234225] RBP: 000055ec20abc8d6 R08: 0000000000000000 R09: 0000000000000000
[ 190.234231] R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000002
[ 190.234238] R13: 0000000000000000 R14: 00007f84b0000b20 R15: 000055ec20ce4eb8
Testcase: igt/gem_eio
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180405123714.3638-1-chris@chris-wilson.co.uk
Before adding a new feature to execlists submission, we should endeavour
to cover the baseline behaviour with selftests. So start the ball
rolling.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
CC: Michel Thierry <michel.thierry@intel.com>
Cc: Jeff McGee <jeff.mcgee@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180404093329.5383-1-chris@chris-wilson.co.uk
Along the eb_lookup_vmas() error path, the return value from
kmem_cache_alloc() was freed using kfree(). Fix it to use the proper
kmem_cache_free() instead.
Fixes: d1b48c1e71 ("drm/i915: Replace execbuf vma ht with an idr")
Signed-off-by: Xidong Wang <wangxidong_97@163.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: <stable@vger.kernel.org> # v4.14+
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/20180404093824.9313-1-chris@chris-wilson.co.uk
HDCP1.4 key can be loaded, only when Power well #1 is enabled and cdclk
is enabled. Using the I915 power well infrastruture, above requirement
is verified.
This patch enables the hdcp initialization for HSW, BDW, and BXT.
v2:
Choose the PW# based on the platform.
v3:
No Changes.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1522663834-24482-4-git-send-email-ramalingam.c@intel.com
In case of V prime mismatch, DP HDCP spec mandates the re-read of
Vprime atleast twice.
This patch needed for DP HDCP1.4 CTS Test: 1B-05.
v2:
Moved the V' validation into a function for retry. [Sean Paul]
v3:
Removed Inline keyword and DRM_DEBUG_KMS are used [Sean Paul]
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1522663834-24482-3-git-send-email-ramalingam.c@intel.com
As per DP spec when R0 mismatch is detected, HDCP source supported
re-read the R0 atleast twice.
And For HDMI and DP minimum wait required for the R0 availability is
100mSec. So this patch changes the wait time to 100mSec but retries
twice with the time interval of 100mSec for each attempt.
This patch is needed for DP HDCP1.4 CTS Test: 1A-06.
v2:
No Change
v3:
Comment on R0 retry is moved closer to the code[Seanpaul]
v4:
Removing unwanted noise introduced in v3.
Signed-off-by: Ramalingam C <ramalingam.c@intel.com>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1522669822-2508-1-git-send-email-ramalingam.c@intel.com
When cancelling the requests and clearing out the ports following a
successful preemption completion, also clear the active flag. I had
assumed that all preemptions would be followed by an immediate dequeue
(preserving the active user flag), but under rare circumstances we may
be triggering a preemption for the second port only for it to have
completed before the preemotion kicks in; leaving execlists->active set
even though the system is now idle.
We can clear the flag inside the common execlists_cancel_port_requests()
as the other users also expect the semantics of active being cleared.
Fixes: f6322eddaf ("drm/i915/preemption: Allow preemption between submission ports")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Michel Thierry <michel.thierry@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180324125829.27026-1-chris@chris-wilson.co.uk
(cherry picked from commit eed7ec52f2)
Signed-off-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Let's avoid having to delve down the pointer chain to see if the i915
device has support for preemption and store that on the engine, which
made the decision in the first place!
v2: Refactor common preemption policy between execlists/guc.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tomasz Lis <tomasz.lis@intel.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180403183537.5522-1-chris@chris-wilson.co.uk
We would like to start doing some bookkeeping at the beginning, between
contexts and at the end of execlists submission. We already mark the
beginning and end using EXECLISTS_ACTIVE_USER, to provide an indication
when the HW is idle. This give us a pair of sequence points we can then
expand on for further bookkeeping.
v2: Refactor guc submission to share the same begin/end.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Cc: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Francisco Jerez <currojerez@riseup.net>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180331130626.10712-1-chris@chris-wilson.co.uk
Pull wait_var_event updates from Ingo Molnar:
"This introduces the new wait_var_event() API, which is a more flexible
waiting primitive than wait_on_atomic_t().
All wait_on_atomic_t() users are migrated over to the new API and
wait_on_atomic_t() is removed. The migration fixes one bug and should
result in no functional changes for the other usecases"
* 'sched-wait-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
sched/wait: Improve __var_waitqueue() code generation
sched/wait: Remove the wait_on_atomic_t() API
sched/wait, arch/mips: Fix and convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/ocfs2: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/nfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/fscache: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/btrfs: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, fs/afs: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, drivers/media: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait, drivers/drm: Convert wait_on_atomic_t() usage to the new wait_var_event() API
sched/wait: Introduce wait_var_event()
Commit 'aee3bac0a3a8 ("drm/i915/psr: Tie PSR2 support to Y
coordinate requirement")' got merged to drm-intel-next-queued
but the variable was defined commit 'c5fe47327b06 ("drm: Add PSR
version 3 macro") who was merged through drm-misc.
So backmerging to get drm-intel-next-queued compiling back again.
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
In the 2 eDP1.4a pannels tested set or not set bit have no effect
but is better set it and comply with specification.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-9-jose.souza@intel.com
This value do not change overtime so better cache it than
fetch it every PSR enable.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-8-jose.souza@intel.com
Sink can support our PSR2 requirements but userspace can request
a resolution that PSR2 hardware do not support, in this case it
was overwritten the PSR2 sink support.
Adding another flag here, this way if requested resolution changed
to a value that PSR2 hardware can handle, PSR2 can be enabled.
Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180328223046.16125-6-jose.souza@intel.com
