When adding the early latency==0 check back I neglected to
realize that we no longer have a way to return a failure
from the wm computation like we had in the past (since we
now calculate wms before ddb allocations). Also plane_en
being false doesn't actually indicate that the level is
invalid as it wil also happen when the plane is not
enabled.
skl_allocate_pipe_ddb() starts scanning from the maximum
watermark level and it stops as soon as it finds a level
that is deemed viable. The assumption being that if level
n+1 is valid then level n is valid as well. Thus if we
now disable any watermark level by zeroing its latency
the code will think that level to be actually valid
and won't confirm whether the actually enabled lower
watermark level(s) actually fit into the allotted ddb
space. This results in hilarious watermark values that
exceed the ddb allocation of the plane.
The way we must now indicate a failure is to assign an
unreasoanbly big value to min_ddb_alloc which will then
make skl_allocate_pipe_ddb() reject the entire level.
v2: Also do the same for the lines>31 case (Matt)
v3: Make 'blocks' u32 (Matt)
Cc: Matt Roper <matthew.d.roper@intel.com>
Cc: Stanislav Lisovskiy <stanislav.lisovskiy@intel.com>
Reviewed-by: Matt Roper <matthew.d.roper@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205155053.10081-1-ville.syrjala@linux.intel.com
clear_intel_crtc_state() uses the stack for saving a temporary copy of
certain bits of the inherited crtc_state before clearing the unwanted
bits. This pushes it over the stack limit for my little 32b Pineview,
so move the temporary allocation to the heap instead. As we now use a
zeroed struct, we can copy the whole extended state back to both
preserve what bits need to be preserved and zero the rest.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205092759.16018-1-chris@chris-wilson.co.uk
We generally omit register polling from the i915_reg_rw tracepoint.
Understandable since polling could generate a lot of noise in the
trace. The downside is that the trace is incomplete. As a compromise
let's trace the final register value observed while polling. That
should be generally sufficient to observe what the code should be
doing next.
I suppose in some cases it might make sense to also trace the initial
register value, and maybe the number of times we polled. But that
would require a separate tracepoint so let's leave it for the future.
The other users of _NOTRACE() are i915_pmu and i2c bitbanging,
which I decided to leave alone.
Next we should do something to claw back the tracepoints for
planes and whatnot which were switched to _FW() a while back.
I guess just new macros for raw_rw+trace. The question is
what to call it?
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190204211644.21967-1-ville.syrjala@linux.intel.com
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
When calling debugfs functions, they can now return error values if
something went wrong. If that happens, return a NULL as a *dentry to
the relay core instead of passing it an illegal pointer.
The relay core should be able to handle an illegal pointer, but add this
check to be safe.
Cc: Jani Nikula <jani.nikula@linux.intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Cc: David Airlie <airlied@linux.ie>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: intel-gfx@lists.freedesktop.org
Cc: dri-devel@lists.freedesktop.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190131131507.GA19807@kroah.com
First of all GMCH can be considered a feature by itself
since it is a chip present in some platforms that connects
the IA processor to memory and other components in PC.
Also with the introduction of display block at device info,
we got a redundant definition:
.display.has_gmch_display = 1,
So, let's clean up things a bit and use the standardized
way of has_feature on displays side.
No functional change and no manual interaction to generate
this patch.
It is only:
sed -si -e 's/has_gmch_display/has_gmch/g' \
-e 's/HAS_GMCH_DISPLAY/HAS_GMCH/g' drivers/gpu/drm/i915/*{c,h}
Cc: José Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190204222538.15842-1-rodrigo.vivi@intel.com
Looking forward, we need to break the struct_mutex dependency on
i915_gem_active. In the meantime, external use of i915_gem_active is
quite beguiling, little do new users suspect that it implies a barrier
as each request it tracks must be ordered wrt the previous one. As one
of many, it can be used to track activity across multiple timelines, a
shared fence, which fits our unordered request submission much better. We
need to steer external users away from the singular, exclusive fence
imposed by i915_gem_active to i915_active instead. As part of that
process, we move i915_gem_active out of i915_request.c into
i915_active.c to start separating the two concepts, and rename it to
i915_active_request (both to tie it to the concept of tracking just one
request, and to give it a longer, less appealing name).
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/20190205130005.2807-5-chris@chris-wilson.co.uk
Wrap the active tracking for a GPU references in a slabcache for faster
allocations, and hopefully better fragmentation reduction.
v3: Nothing device specific left, it's just a slabcache that we can
make global.
v4: Include i915_active.h and don't put the initfunc under DEBUG_GEM
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/20190205130005.2807-4-chris@chris-wilson.co.uk
As soon as we detect that the active tracker is idle and we prepare to
call the retire callback, release the storage for our tree of
per-timeline nodes. We expect these to be infrequently used and quick
to allocate, so there is little benefit in keeping the tree cached and
we would prefer to return the pages back to the system in a timely
fashion.
This also means that when we finalize the struct as a whole, we know as
the activity tracker must be idle, the tree has already been released.
Indeed we can reduce i915_active_fini() just to the assertions that there
is nothing to do.
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/20190205130005.2807-3-chris@chris-wilson.co.uk
We currently track GPU memory usage inside VMA, such that we never
release memory used by the GPU until after it has finished accessing it.
However, we may want to track other resources aside from VMA, or we may
want to split a VMA into multiple independent regions and track each
separately. For this purpose, generalise our request tracking (akin to
struct reservation_object) so that we can embed it into other objects.
v2: Tweak error handling during selftest setup.
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/20190205130005.2807-2-chris@chris-wilson.co.uk
Exercise the context image reconfiguration logic for idle and busy
contexts, with the resets thrown into the mix as well.
Free from the uAPI restrictions this test runs on all Gen9+ platforms
with slice power gating.
v2:
* Rename some helpers for clarity.
* Include subtest names in error logs.
* Remove unnecessary function export.
v3:
* Rebase for RUNTIME_INFO.
v4:
* Fix incomplete unexport from v2. (Chris Wilson)
v5:
* Rebased for runtime pm api changes.
v6:
* Rebased for i915_reset.c.
v7:
* Tidy checkpatch warnings.
* Consolidate error checking and logging a bit.
* Skip idle test phase if something failed before it.
v8:
(Chris Wilson)
* Fix i915_request_wait error handling.
* No need to PIN_HIGH the VMA.
* Remove pointless GEM_BUG_ON before pointer dereference.
v9:
* Avoid rq leak if rpcs query fails. (Chris)
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> # v6
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-5-tvrtko.ursulin@linux.intel.com
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
Timeline barrier allows serialization between different timelines.
After calling i915_timeline_set_barrier with a request, all following
submissions on this timeline will be set up as depending on this request,
or barrier. Once the barrier has been completed it automatically gets
cleared and things continue as normal.
This facility will be used by the upcoming context SSEU code.
v2:
* Assert barrier has been retired on timeline_fini. (Chris Wilson)
* Fix mock_timeline.
v3:
* Improved comment language. (Chris Wilson)
v4:
* Maintain ordering with previous barriers set on the timeline.
v5:
* Rebase.
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/20190205095032.22673-3-tvrtko.ursulin@linux.intel.com
If some of the contexts submitting workloads to the GPU have been
configured to shutdown slices/subslices, we might loose the NOA
configurations written in the NOA muxes.
One possible solution to this problem is to reprogram the NOA muxes
when we switch to a new context. We initially tried this in the
workaround batchbuffer but some concerns where raised about the cost
of reprogramming at every context switch. This solution is also not
without consequences from the userspace point of view. Reprogramming
of the muxes can only happen once the powergating configuration has
changed (which happens after context switch). This means for a window
of time during the recording, counters recorded by the OA unit might
be invalid. This requires userspace dealing with OA reports to discard
the invalid values.
Minimizing the reprogramming could be implemented by tracking of the
last programmed configuration somewhere in GGTT and use MI_PREDICATE
to discard some of the programming commands, but the command streamer
would still have to parse all the MI_LRI instructions in the
workaround batchbuffer.
Another solution, which this change implements, is to simply disregard
the user requested configuration for the period of time when i915/perf
is active.
On most platforms there are no issues with this apart from a performance
penality for some media workloads that benefit from running on a partially
powergated GPU. We already prevent RC6 from affecting the programming so
it doesn't sound completely unreasonable to hold on powergating for the
same reason.
On Icelake however there would a functional problem if the slices not-
containing the VME block were left enabled with a running media workload
which explicitly disabled them. To avoid a GPU hang in this case, on
Icelake we lock the enablement to only slices which contain VME blocks.
Downside is that it means degraded GPU performance when OA is active but
there is no known alternative solution for this.
v2: Leave RPCS programming in intel_lrc.c (Lionel)
v3: Update for s/union intel_sseu/struct intel_sseu/ (Lionel)
More to_intel_context() (Tvrtko)
s/dev_priv/i915/ (Tvrtko)
Tvrtko Ursulin:
v4:
* Rebase for make_rpcs changes.
v5:
* Apply OA restriction from make_rpcs directly.
v6:
* Rebase for context image setup changes.
v7:
* Move stream assignment before metric enable.
v8-9:
* Rebase.
v10:
* Squashed with ICL support patch.
Bspec: 21140
Co-developed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> # v9
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-2-tvrtko.ursulin@linux.intel.com
We want to expose the ability to reconfigure the slices, subslice and
eu per context and per engine. To facilitate that, store the current
configuration on the context for each engine, which is initially set
to the device default upon creation.
v2: record sseu configuration per context & engine (Chris)
v3: introduce the i915_gem_context_sseu to store powergating
programming, sseu_dev_info has grown quite a bit (Lionel)
v4: rename i915_gem_sseu into intel_sseu (Chris)
use to_intel_context() (Chris)
v5: More to_intel_context() (Tvrtko)
Switch intel_sseu from union to struct (Tvrtko)
Move context default sseu in existing loop (Chris)
v6: s/intel_sseu_from_device_sseu/intel_device_default_sseu/ (Tvrtko)
Tvrtko Ursulin:
v7:
* Pass intel_sseu by pointer instead of value to make_rpcs.
* Rebase for make_rpcs changes.
v8:
* Rebase for RPCS edit on pin.
v9:
* Rebase for context image setup changes.
v10:
* Rename dev_priv to i915. (Chris Wilson)
v11:
* Rebase.
v12:
* Rebase for IS_GEN changes.
v13:
* Rebase for RUNTIME_INFO.
v14:
* Rebase for intel_context_init.
v15:
* Rebase for drm-tip changes.
v16:
* Moved struct intel_sseu definition to i915_gem_context.h.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-1-tvrtko.ursulin@linux.intel.com
Limit the NEWCLIENT boost to only give its small priority boost to fresh
clients only that have no dependencies.
The idea for using NEWCLIENT boosting, commit b16c765122 ("drm/i915:
Priority boost for new clients"), is that short-lived streams are often
interactive and require lower latency -- and that by executing those
ahead of the long running hogs, the short-lived clients do little to
interfere with the system throughput by virtue of their short-lived
nature. However, we were only considering the client's own timeline for
determining whether or not it was a fresh stream. This allowed for
compositors to wake up before their vblank and bump all of its client
streams. However, in testing with media-bench this results in chaining
all cooperating contexts together preventing us from being able to
reorder contexts to reduce bubbles (pipeline stalls), overall increasing
latency, and reducing system throughput. The exact opposite of our
intent. The compromise of applying the NEWCLIENT boost to strictly fresh
clients (that do not wait upon anything else) should maintain the
"real-time response under load" characteristics of FQ_CODEL, without
locking together the long chains of dependencies across the system.
References: b16c765122 ("drm/i915: Priority boost for new clients")
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/20190204150101.30759-1-chris@chris-wilson.co.uk
When first enabling preemption, we hesitated from making it a free-for-all
where every higher priority client would force a preempt-to-idle cycle
and take over from all lower priority clients. We hesitated because we
were uncertain just how well preemption would work in practice, whether
the preemption latency itself would detract from the latency gains for
higher priority tasks and whether it would work at all. Since
introducing preemption, we have been enabling it for more common tasks,
even giving normal clients a small preemptive boost when they first
start (to aide fairness and improve interactivity). Now lets take one
step further and give permission for all normal (priority:0) clients to
preempt any idle (priority:<0) task so that users running long compute
jobs do not overly impact other jobs (i.e. their desktop) and the system
remains responsive under such idle loads.
References: f6322eddaf ("drm/i915/preemption: Allow preemption between submission ports")
References: b16c765122 ("drm/i915: Priority boost for new clients")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Michal Wajdeczko <michal.wajdeczko@intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: "Bloomfield, Jon" <jon.bloomfield@intel.com>
Cc: "Stead, Alan" <alan.stead@intel.com>
Reviewed-by: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190204084116.3013-1-chris@chris-wilson.co.uk
In order to enable the MMIO path stream ID protection provided by the
incarnation of host1x found in Tegra186 and later, the host1x must be
provided with the list of stream ID register offsets for each of its
clients. Some clients (such as VIC) have multiple stream ID registers
that are assumed to be contiguous. The host1x is programmed with the
base offset and a limit which provide the range of registers that the
host1x needs to monitor for writes.
Signed-off-by: Thierry Reding <treding@nvidia.com>
This new debugfs file represents the state of host1x bus devices,
specifying the list of subdevices and marking which ones have
successfully registered.
Signed-off-by: Thierry Reding <treding@nvidia.com>
In this usage, the two are completely equivalent, but the completion
documents better what is going on, and we generally try to avoid
semaphores these days.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Thierry Reding <treding@nvidia.com>
- Icelake display fixes (Ville, Imre)
- Workarounds fixes and reorg (Tvrtko, Talha)
- Enable fastboot by default on VLV and CHV (Hans)
- Add another PCI ID for Coffee Lake (Rodrigo)
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcVVKOAAoJEPpiX2QO6xPKzpEH/11faCaucfkejXnR2ff3H/Rc
EQILDB+SFwzKYaxd8pLHXJ7D8stmBGW4i086bic1JFTxIi/MtQv5rfOO87jqu1DU
3FFgCLuovzmheKVMuPxnSwGXn2ZI3RWPoDrH7OGaOtKuNAfoFTL9upZYsmBOyA+8
srraU1zHhhR3pawqqVpGrXCVToKSYQc/mh9Od1v491yoqMEhC6r2JaGiePZQldn9
J99ouBDOHMM1f45UX4+ORNQB951sQhJ4SW8e2bi2jKuc5WNmX3+tGLYdKemq3OYN
vi3a4xwSPkhbGWUSQtT7Cy6e2p43p/k7CwVl1iEESVB7HOqINwmxY/UIxm3ap1s=
=Q8JK
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2019-02-02' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Make background color and LUT more robust (Matt)
- Icelake display fixes (Ville, Imre)
- Workarounds fixes and reorg (Tvrtko, Talha)
- Enable fastboot by default on VLV and CHV (Hans)
- Add another PCI ID for Coffee Lake (Rodrigo)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190202082911.GA6615@intel.com
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Split out some part of drm_crtc_helper.h into drm_probe_helper.h
- DRIVER_* flags improvements
- New tasks on the TODO-list
- Improvements to the documentation
Driver Changes:
- Continual of drmP.h removal in multiple drivers
- Removal of FBINFO_(FLAG_)DEFAULT in multiple drivers
- sun4i: Addition of the A23 support, multiple fixes for the tiled
formats
- atmel-hlcdc: Fix of clipping and rotation properties
- qxl: various BO-related improvements, prime and generic fbdev emulation
support
- dw-hdmi: Support for HDMI2.0 2160p modes and YUV420 output
- New Sitronix ST7701 panel driver
- New Kingdisplay KD097D04 panel driver
- New LeMaker BL035-RGB-002 panel driver
- New PDA 91-00156-A0 panel driver
-----BEGIN PGP SIGNATURE-----
iHUEABYIAB0WIQRcEzekXsqa64kGDp7j7w1vZxhRxQUCXFRb/wAKCRDj7w1vZxhR
xXj2AQDFAkH0/tksJ+T6yrHZXQE7q/6fAWTlrDXLo7Nb1hhfswEA1AyaHmZJA0Ar
u7S+4Gfzs/gisw9Jr4bqQaerEpYJxQA=
=qumD
-----END PGP SIGNATURE-----
Merge tag 'drm-misc-next-2019-02-01' of git://anongit.freedesktop.org/drm/drm-misc into drm-next
drm-misc-next for 5.1:
UAPI Changes:
Cross-subsystem Changes:
Core Changes:
- Split out some part of drm_crtc_helper.h into drm_probe_helper.h
- DRIVER_* flags improvements
- New tasks on the TODO-list
- Improvements to the documentation
Driver Changes:
- Continual of drmP.h removal in multiple drivers
- Removal of FBINFO_(FLAG_)DEFAULT in multiple drivers
- sun4i: Addition of the A23 support, multiple fixes for the tiled
formats
- atmel-hlcdc: Fix of clipping and rotation properties
- qxl: various BO-related improvements, prime and generic fbdev emulation
support
- dw-hdmi: Support for HDMI2.0 2160p modes and YUV420 output
- New Sitronix ST7701 panel driver
- New Kingdisplay KD097D04 panel driver
- New LeMaker BL035-RGB-002 panel driver
- New PDA 91-00156-A0 panel driver
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Maxime Ripard <maxime.ripard@bootlin.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190201144749.t3abxvguhstu6bcl@flea
In order to support the HDMI2.0 YUV420 display modes, this patch
adds support for the YUV420 TMDS Clock divided by 2 and the controller
passthrough mode.
YUV420 Synopsys PHY support will need some specific configuration table
to support theses modes.
This patch is based on work from Zheng Yang <zhengyang@rock-chips.com> in
the Rockchip Linux 4.4 BSP at [1]
[1] https://github.com/rockchip-linux/kernel/tree/release-4.4
Cc: Zheng Yang <zhengyang@rock-chips.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1549022873-40549-5-git-send-email-narmstrong@baylibre.com
Now we support the TMDS Clock > 3.4GHz and support the SCDC Control
operation in the DW-HDMI Controller, we can enable support for the
HDMI2.0 3840x2160@60/50 RGB444 display modes.
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1549022873-40549-4-git-send-email-narmstrong@baylibre.com
Add support for SCDC Setup for TMDS Clock > 3.4GHz and enable TMDS
Scrambling when supported or mandatory.
This patch also adds an helper to setup the control bit to support
the high TMDS Bit Period/TMDS Clock-Period Ratio as required with
TMDS Clock > 3.4GHz for HDMI2.0 3840x2160@60/50 modes.
These changes were based on work done by Huicong Xu <xhc@rock-chips.com>
and Nickey Yang <nickey.yang@rock-chips.com> to support HDMI2.0 modes
on the Rockchip 4.4 BSP kernel at [1]
[1] https://github.com/rockchip-linux/kernel/tree/release-4.4
Cc: Nickey Yang <nickey.yang@rock-chips.com>
Cc: Huicong Xu <xhc@rock-chips.com>
Signed-off-by: Neil Armstrong <narmstrong@baylibre.com>
Tested-by: Heiko Stuebner <heiko@sntech.de>
Reviewed-by: Andrzej Hajda <a.hajda@samsung.com>
Signed-off-by: Andrzej Hajda <a.hajda@samsung.com>
Link: https://patchwork.freedesktop.org/patch/msgid/1549022873-40549-2-git-send-email-narmstrong@baylibre.com
- Fix ILK-IVB primary plane enable delays (Juha-Pekka)
- Differentiate between gtt->mutex and ppgtt->mutex (Chris)
- Prevent concurrent GGTT update and use on Braswell (Chris)
- Fix CNL macros for DDI vswing (Aditya)
- Fix static code analysis warning (RK)
- Only dump GPU state on set-wedged if interesting (Chris)
- Port F detection improvements (Imre)
- userptr mutex lock fixes (Chris)
- Fix on MST allocation by propagating error value at compute_config (Lyude)
- Serialise concurrent calls to set_wedge (Chris)
- Unify reset functionality into i915_reset.c (Chris)
- Switch to kernel fixed size types (Jani)
- Limit the for_each_set_bit to the valid range (Chris)
- Fix wakeref cooie handling (Tvrtko)
- IRQs handling improvements (Chris)
- Selftests improvements (Chris)
- Remove superfluous PANEL_POWER_OFF macro (Jani)
- Global seqno fix (Chris)
- DSI fixes (Hans)
- Refactor out intel_context_init() (Chris)
- Show all active engines on hangcheck (Chris)
- PSR2 fixes and improvements (Jose)
- Do a posting read after irq install on Ice Lake (Daniele)
- Add few more device IDs for Ice Lake (Rodrigo)
- Mark up priority boost on preemption (Chris)
- Add color management LUT validation helper (Matt)
- Split out intel_crt_present to platform specific setup (Jani)
- LVDS and TV clean up and improvements (Jani)
- Simplify CRT VBT check for per-VLV/DDI (Jani)
- De-inline intel_context_init() (Chris)
- Backlight fixes (Maarten)
- Enable fastset for non-boot modesets (Maarten)
- Make HW readout mark CRTC scaler as in use (Maarten)
-----BEGIN PGP SIGNATURE-----
iQEcBAABAgAGBQJcSk7xAAoJEPpiX2QO6xPKDUIH/0gzfkkFehRV76LTKTzdiFr5
4etRp4T7siGBN4E2MuhBrA5OBbzcXTlfjoO0nUZEwhC3HTJ/19eFZ5rjDCC4SuOt
5c4IDynWxyKfZS1gDcBNHeH68fD3Oeek93Wh69DFtze+sml5aPtD5wEDwlOihOpH
G/O5gBxH/91M4EXpF/IFUr6ZhdG4RVrBRV9PCjdo/wyji5zYVfnXFT2V1g2DDrX5
WK54aOlsPsb7lpyQTbf8F/jmxyen3Y3Y+hhWs3KmrE5SmK/0YF59Swj+z7lJgLoP
Y/wF+YJ9JWU1+E3zfz1NX97O4Prv8DHjbNh6tjNUoUAma/D91QYmUrOfuKSJO5Q=
=f3aM
-----END PGP SIGNATURE-----
Merge tag 'drm-intel-next-2019-01-24' of git://anongit.freedesktop.org/drm/drm-intel into drm-next
- Track all runtime-PM wakerefs and other rpm improvements (Chris)
- Fix ILK-IVB primary plane enable delays (Juha-Pekka)
- Differentiate between gtt->mutex and ppgtt->mutex (Chris)
- Prevent concurrent GGTT update and use on Braswell (Chris)
- Fix CNL macros for DDI vswing (Aditya)
- Fix static code analysis warning (RK)
- Only dump GPU state on set-wedged if interesting (Chris)
- Port F detection improvements (Imre)
- userptr mutex lock fixes (Chris)
- Fix on MST allocation by propagating error value at compute_config (Lyude)
- Serialise concurrent calls to set_wedge (Chris)
- Unify reset functionality into i915_reset.c (Chris)
- Switch to kernel fixed size types (Jani)
- Limit the for_each_set_bit to the valid range (Chris)
- Fix wakeref cooie handling (Tvrtko)
- IRQs handling improvements (Chris)
- Selftests improvements (Chris)
- Remove superfluous PANEL_POWER_OFF macro (Jani)
- Global seqno fix (Chris)
- DSI fixes (Hans)
- Refactor out intel_context_init() (Chris)
- Show all active engines on hangcheck (Chris)
- PSR2 fixes and improvements (Jose)
- Do a posting read after irq install on Ice Lake (Daniele)
- Add few more device IDs for Ice Lake (Rodrigo)
- Mark up priority boost on preemption (Chris)
- Add color management LUT validation helper (Matt)
- Split out intel_crt_present to platform specific setup (Jani)
- LVDS and TV clean up and improvements (Jani)
- Simplify CRT VBT check for per-VLV/DDI (Jani)
- De-inline intel_context_init() (Chris)
- Backlight fixes (Maarten)
- Enable fastset for non-boot modesets (Maarten)
- Make HW readout mark CRTC scaler as in use (Maarten)
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190128181000.GA5284@intel.com
New stuff for 5.1.
amdgpu:
- DC bandwidth formula updates
- Support for DCC on scanout surfaces
- Support for multiple IH rings on soc15 asics
- Fix xgmi locking
- Add sysfs interface to get pcie usage stats
- Simplify DC i2c/aux code
- Initial support for BACO on vega10/20
- New runtime SMU feature debug interface
- Expand existing sysfs power interfaces to new clock domains
- Handle kexec properly
- Simplify IH programming
- Rework doorbell handling across asics
- Drop old CI DPM implementation
- DC page flipping fixes
- Misc SR-IOV fixes
amdkfd:
- Simplify the interfaces between amdkfd and amdgpu
ttm:
- Add a callback to notify the driver when the lru changes
sched:
- Refactor mirror list handling
- Rework hw fence processing
Signed-off-by: Dave Airlie <airlied@redhat.com>
From: Alex Deucher <alexdeucher@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190125231517.26268-1-alexander.deucher@amd.com
Drivers shouldn't be using these values, add a TODO so someone removes
them.
Changes in v2:
- Add drm_display_mode.vrefresh removal (Ville)
- Add Sam's R-b and bonus points
Changes in v3:
- Add hsync removal todo item (Daniel)
- Change vrefresh wording to make removal less optional
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Suggested-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Reviewed-by: Sam Ravnborg <sam@ravnborg.org>
Bonus-points-awarded-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: Sean Paul <seanpaul@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129192637.73296-1-sean@poorly.run
While cross checking PCI IDs from Intel Media SDK
and kernel Dmitry noticed this gap. So we checked the
spec and this new ID had been recently added.
v2: Adding new H_GT1 entry to i915_pci.c (Jose)
Reported-by: Dmitry Rogozhkin<dmitry.v.rogozhkin@intel.com>
Cc: Dmitry Rogozhkin<dmitry.v.rogozhkin@intel.com>
Cc: José Roberto de Souza <jose.souza@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190201235049.27206-1-rodrigo.vivi@intel.com
We really want to have fastboot enabled by default to avoid an ugly
modeset during boot.
Currently we are enabling fastboot by default on gen9+ (Skylake and newer).
The intention is to enable it on older generations after it has seen more
testing on gen9+.
VLV and CHV devices are still being sold in stores today, as such it is
desirable to also enable fastboot by default on these now.
I've extensively tested fastboot=1 support on over 50 different
Bay- and Cherry-Trail devices. Testing DSI and eDP panels as well as
HDMI output (and even DP over Type-C on one device).
All 50 devices work fine with fastboot=1. On 2 devices their DSI panel
turns black as soon as the i915 driver loads when fastboot=0, so having
fastboot enabled is required for these 2 to work properly (for lack of
a better fix).
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Reviewed-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129142237.8684-1-hdegoede@redhat.com
Enables blend optimization for floating point RTs
This restores the workaround that was reverted in c358514ba8
("Revert "drm/i915/icl: WaEnableFloatBlendOptimization"").
The revert was due to the register write seemingly not sticking,
but the HW team has confirmed that this is because the
register is WO and that the workaround is indeed required.
Here the wa is added with a mask of 0 since the register is WO.
References: https://hsdes.intel.com/resource/1408134172
References: https://bugs.freedesktop.org/show_bug.cgi?id=107338
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Talha Nassar <talha.nassar@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/1548983324-15344-4-git-send-email-talha.nassar@intel.com
Top comment in intel_workarounds.c says common code should come first so
lets respect that. Also, by moving the common code together opportunities
to reduce duplication will become more obvious.
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Link: https://patchwork.freedesktop.org/patch/msgid/1548983324-15344-2-git-send-email-talha.nassar@intel.com
We can't safely probe Type C ports, whether they are a legacy or a
USB/Thunderbolt DP Alternate Type C port. This would require performing
the TypeC connect sequence - as described by the specification - but
that may have unwanted side-effects. These side-effects include at least
- without completeness - timeouts during AUX power well enabling and
subsequent PLL enabling errors.
To safely identify these ports we really need VBT, which has the proper
flag for this (ddi_vbt_port_info::supports_typec_usb, supports_tbt).
Based on the above disable Type C ports if we can't load VBT for some
reason.
v2:
- Notice that we disable TypeC ports completely and simplify accordingly
(Jose).
- Add code comment explaining why we disabled the ports. (Jani)
Cc: Jani Nikula <jani.nikula@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Cc: Jose Roberto de Souza <jose.souza@intel.com>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Rodrigo Vivi <rodrigo.vivi@intel.com>
Signed-off-by: Imre Deak <imre.deak@intel.com>
Reviewed-by: José Roberto de Souza <jose.souza@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190128114242.28666-1-imre.deak@intel.com
commit 5b0bd14dcc ("drm/i915/icl: keep track of unused pll while
looping") inadvertently (I presume) changed the code to pick the
last unused dpll rather than the first unused one like we did before.
While there should most likely be no harm in changing the order
let's change back just to avoid a change in the behaviour. At
least it might reduce the confusion when staring at logs (took
me a while to figure out why DPLL1 being picked over DPLL0
when the latter was most definitely available).
Cc: Lucas De Marchi <lucas.demarchi@intel.com>
Cc: Paulo Zanoni <paulo.r.zanoni@intel.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190130181359.20693-1-ville.syrjala@linux.intel.com
Reviewed-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Acked-by: Lucas De Marchi <lucas.demarchi@intel.com>
The code managing the dbuf slices is borked and needs some
real work to fix. In the meantime let's just stop using the
second slice.
v2: Drop the change to intel_enabled_dbuf_slices_num() (Mahesh)
Cc: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
Reviewed-by: Imre Deak <imre.deak@intel.com> #v1
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190130155110.12918-1-ville.syrjala@linux.intel.com
Reviewed-by: Mahesh Kumar <mahesh1.sh.kumar@gmail.com>
Implement VFIO EDID region for vgpu. Support EDID blob update and notify
guest on link state change via hotplug event.
v3: move struct edid_region to kvmgt.c <zhenyu>
v2: add EDID sanity check and size update <zhenyu>
Tested-by: Gerd Hoffmann <kraxel@redhat.com>
Reviewed-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Add function to emulate hotplug interrupt for SKL/KBL platforms
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
These functions will get default resolution according to vgpu type.
Signed-off-by: Hang Yuan <hang.yuan@linux.intel.com>
Signed-off-by: Zhenyu Wang <zhenyuw@linux.intel.com>
Use of the new DRM_COLOR_LUT_NON_DECREASING test was a bit over-zealous;
it doesn't actually need to be applied to the degamma on "bdw-style"
platforms. Likewise, we overlooked the fact that CHV should have that
test applied to the gamma LUT as well as the degamma LUT.
Rather than adding more complicated platform checking to
intel_color_check(), let's just store the appropriate set of LUT
validation flags for each platform in the intel_device_info structure.
v2:
- Shuffle around LUT size tests so that the hardware-specific tests
won't be applied to legacy gamma tables. (Ville)
- Add a debug message so that it will be easier to understand why an
atomic transaction involving incorrectly-sized LUT's got rejected
by the driver.
v3:
- Switch size_t's to int's. (Ville)
Fixes: 85e2d61e49 ("drm/i915: Validate userspace-provided color management LUT's (v4)")
References: https://lists.freedesktop.org/archives/intel-gfx/2019-January/187634.html
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190130181022.4291-1-matthew.d.roper@intel.com
We don't yet allow userspace to control the CRTC background color, but
we should manually program the color to black to ensure the BIOS didn't
leave us with some other color. We should also set the pipe gamma and
pipe CSC bits so that the background color goes through the same color
management transformations that a plane with black pixels would.
v2: Rename register to SKL_BOTTOM_COLOR to more closely follow
bspec naming. (Ville)
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Matt Roper <matthew.d.roper@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190130185122.10322-2-matthew.d.roper@intel.com
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Decode the NAK reply fields to make it easier to parse the logs.
v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day)
Use drm_dp_mst_req_type_str() more (DK)
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Reviewed-by: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190122200301.18633-2-ville.syrjala@linux.intel.com
