- 14 Jun, 2018 25 commits
-
-
Chris Wilson authored
We can stop asserting using WARN_ON as given sufficient CI coverage, we can rely on using GEM_BUG_ON() to catch problems before merging. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.william.auld@gmail.com> Reviewed-by:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614184218.1606-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
As the most frequent PTE encoding is for the scratch page, cache it upon creation. Signed-off-by:
-
Chris Wilson authored
As we cannot reliably change used page tables while the context is active, the earliest opportunity we have to recover excess pages is when the context becomes idle. So whenever we unbind the context (it must be idle, and indeed being evicted) free the unused ptes. Signed-off-by:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614134315.5900-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
As we were only supporting aliasing_ppgtt on gen7 for some time, we saved a few checks by preallocating the page directories on creation. However, since we need 2MiB of page directories for each ppgtt, to support arbitrary numbers of user contexts, we need to be more prudent in our allocations, and defer the page allocation until it is used. We don't recover unused pages yet as we found that doing so on the fly (i.e. altering TLB entries) would confuse the GPU. Signed-off-by:
-
Chris Wilson authored
Hangcheck is our back up in case the GPU or the driver gets stuck. It detects when the GPU is not making any progress and issues a GPU reset. However, if the driver is failing to make any progress, we can get ourselves into a situation where we continually try resetting the GPU to no avail. Employ a second timeout such that if we continue to see the same seqno (the stalled engine has made no progress at all) over the course of several hangchecks, declare the driver wedged and attempt to start afresh. Signed-off-by:
Mika Kuoppala <mika.kuoppala@intel.com>
-
Chris Wilson authored
In the unlikely case where we have failed to keep submitting to the GPU, we end up with the ELSP queue empty but a pending queue of requests. Here, we skip the per-engine reset as there is no guilty request, but in doing so we also skip the engine restart leaving ourselves with a permanently hung engine. A quick way to recover is by moving the tasklet kick to execlists_reset_finish() (from init_hw). We still emit the error on hanging, so the error is not lost but we should be able to recover. Signed-off-by:
-
Chris Wilson authored
With an old (4.7.3 on 32bit) gcc, it emits a warning for In file included from drivers/gpu/drm/i915/i915_request.c:1425:0: drivers/gpu/drm/i915/selftests/i915_request.c: In function ‘live_nop_request’: drivers/gpu/drm/i915/selftests/i915_request.c:380:21: error: ‘request’ may be used uninitialized in this function [-Werror=maybe-uninitialized] Silence it by just setting it to NULL on initialisation. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614124923.18071-1-chris@chris-wilson.co.uk
-
Ville Syrjälä authored
While Bspec doesn't list a specific sequence for turning off the DP port on g4x we are getting an underrun if the port is disabled in the .disable() hook. Looks like the pipe stops when the port stops, and by that time the plane disable may not have completed yet. Also the plane(s) seem to end up in some wonky state when this happens as they also signal another underrun immediately after we turn them back on during the next enable sequence. We could add a vblank wait in .disable() to avoid wedging the planes, but I assume we're still tripping up the pipe in some way. So it seems better to me to just follow the ILK+ sequence and turn off the DP port in .post_disable() instead. This sequence doesn't seem to suffer from this problem. Could be it was always the intended sequence for DP and the gen4 bspec was just never updated to include it. Originally we used the bad sequence even on ilk+, but I changed that in commit 08aff3fe ("drm/i915: Move DP port disable to post_disable for pch platforms") as it was causing issues on those platforms as well. I left out g4x then only because I didn't have the hardware to test it. Now that I do it's fairly clear that the ilk+ sequence is also the right choice for g4x. v2: Fix whitespace fail (Jani) Mention the ilk+ commit (Jani) Cc: stable@vger.kernel.org Signed-off-by:
Jani Nikula <jani.nikula@intel.com>
-
Ville Syrjälä authored
Looks like interlaced DP output doesn't work on g4x either. Not all that surprising considering we already established that interlaced DP output is busted on VLV/CHV. Cc: stable@vger.kernel.org Signed-off-by:
-
Ville Syrjälä authored
On i965/g4x IIR is edge triggered. So in order for IIR to notice that there is still a pending interrupt we have to force and edge in ISR. For the ISR/IIR pipe event bits we can do that by temporarily clearing all the PIPESTAT enable bits when we ack the status bits. This will force the ISR pipe event bit low, and it can then go back high when we restore the PIPESTAT enable bits. This avoids the following race: 1. stat = read(PIPESTAT) 2. an enabled PIPESTAT status bit goes high 3. write(PIPESTAT, enable|stat); 4. write(IIR, PIPE_EVENT) The end result is IIR==0 and ISR!=0. This can lead to nasty vblank wait/flip_done timeouts if another interrupt source doesn't trick us into looking at the PIPESTAT status bits despite the IIR PIPE_EVENT bit being low. Before i965 IIR was level triggered so this problem can't actually happen there. And curiously VLV/CHV went back to the level triggered scheme as well. But for simplicity we'll use the same i965/g4x compatible code for all platforms. Cc: stable@vger.kernel.org Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106033 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105225 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106030Signed-off-by:
-
Imre Deak authored
Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
On ICL for setting the HDMI infoframe the pipe clock needs to be enabled, otherwise accessing the VIDEO_DIP_CTL register will hang the machine. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
The only requirement by BSpec for setting the HDMI infoframes is on DDI platforms to do that before enabling the HDMI transcoder function, see VIDEO_DIP_CTL bit 16. Accordingly check for the transcoder function disabled state instead of the port's disabled state on DDI platforms. This is needed by the next patch as it will set the infoframe during crtc disabling where the port is still enabled. Suggested-by:
-
Imre Deak authored
On ICL the pipe clock needs to be enabled before setting the HDMI infoframe, but these steps are in the reverse order atm. Move the pipe clock enabling to the encoders, so reordering of the two steps can be done in a clean way. No functional change. v2: - Rebased on drm-tip. Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
crtc->config points to the old crtc state at the point display.crtc_disable() is called, so use the more descriptive pointer instead. v2: - Convert one remaining instance of the ptr in the function. (Ville) Cc: Vandita Kulkarni <vandita.kulkarni@intel.com> Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Rodrigo Vivi authored
The immediate enabling was actually not an issue for the HW perspective for core platforms that have HW tracking. HW will wait few identical idle frames before transitioning to actual psr active anyways. Now that we removed VLV/CHV out of the picture completely we can safely remove any delays. Note that this patch also remove the delayed activation on HSW and BDW introduced by commit 'd0ac896a ("drm/i915: Delay first PSR activation.")'. This was introduced to fix a blank screen on VLV/CHV and also masked some frozen screens on other core platforms. Probably the same that we are now properly hunting and fixing. v2:(DK): Remove unnecessary WARN_ONs and make some other VLV | CHV more readable. v3: Do it regardless the timer rework. v4: (DK/CI): Add VLV || CHV check on cancel work at psr_disable. v5: Kill remaining items and fully rework activation functions. v6: Rebase on top of VLV/CHV clean-up and keep the reactivation on a regular non-delayed work to avoid extra delays on exit calls and allow us to add few more safety checks before real activation. Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Signed-off-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Reviewed-by:
Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613192600.3955-1-rodrigo.vivi@intel.com
-
Chris Wilson authored
In order to be able to evict the gen6 ppgtt, we have to unpin it at some point. We can simply use our context activity tracking to know when the ppgtt is no longer in use by hardware, and so only keep it pinned while being used a request. For the kernel_context (and thus aliasing_ppgtt), it remains pinned at all times, as the kernel_context itself is pinned at all times. Signed-off-by:
-
Chris Wilson authored
For debugging context issues, knowing what context the GPU is loading/using is helpful. Signed-off-by:
-
Chris Wilson authored
Currently we use %08x for the row offset, and %08x for the binary contents of the buffer. This makes it very easily to confuse the two, so switch to using [%04x] for the start-of-row offset. Signed-off-by:
-
Chris Wilson authored
Sometimes we need to see what instructions we emitted for a request to try and gather a glimmer of insight into what the GPU is doing when it stops responding. v2: Move ring dumping into its own routine Signed-off-by:
-
Jani Nikula authored
Pass a local acpi_handle around instead of having a static dsm priv structure. If we need it later, we can always move it to dev_priv, and the change at hand will make that easier as well. Care is taken to preserve old behaviour, particularly using the last non-NULL acpi handle, whether it makes sense or not. Reviewed-by:
-
Chris Wilson authored
This should be a no-op in terms of our control flow, we move the sanitization (GPU reset) from the bottom of the early resume phase to the top of the next. However, following hibernation debug, the power code skips the early resume phase, but as we are about to completely restore the GTT mappings, we first need to stop the GPU using them i.e. perform a GPU reset (i915_gem_sanitize()). Testcase: igt/gem_exec_suspend/basic-S4-devices Signed-off-by:
-
Jani Nikula authored
Get rid of the silly static variable. Reviewed-by:
-
Jani Nikula authored
No reason not to be const. Reviewed-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
-
Chris Wilson authored
For symmetry, simplicity and ensuring the request is always truly idle upon its completion, always emit the closing flush prior to emitting the request breadcrumb. Previously, we would only emit the flush if we had started a user batch, but this just leaves all the other paths open to speculation (do they affect the GPU caches or not?) With mm switching, a key requirement is that the GPU is flushed and invalidated before hand, so for absolute safety, we want that closing flush be mandatory. Signed-off-by:
-
- 13 Jun, 2018 1 commit
-
-
Ville Syrjälä authored
When encountering a connector with the scaling mode property both intel and modesetting ddxs sometimes add tons of DBLSCAN modes to the output's mode list. The idea presumably being that since the output will be going through the panel fitter anyway we can pretend to use any kind of mode. Sadly that means we can't reject user modes with the DBLSCAN flag until we know whether we're going to be using the panel's native mode or the user mode directly. Doing otherwise means X clients using xf86vidmode/xrandr will get a protocol error (and often self terminate as a result) when the kernel refuses to use the requested mode with the DBLSCAN flag. To undo the regression we'll move the DBLSCAN checks into the connector->mode_valid() and encoder->compute_config() hooks. Cc: stable@vger.kernel.org Cc: Vito Caputo <vcaputo@pengaru.com> Reported-by:
Vito Caputo <vcaputo@pengaru.com> Fixes: e995ca0b ("drm/i915: Provide a device level .mode_valid() hook") References: https://lkml.org/lkml/2018/5/21/715Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=106804Tested-by:
Arkadiusz Miskiewicz <arekm@maven.pl>
-
- 12 Jun, 2018 14 commits
-
-
James Ausmus authored
Add support for DP_AUX_E. Here we also introduce the bits for the AUX power well E, however ICL power well support is still not enabled yet, so the power well is not used. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Dhinakaran Pandiyan <dhinakaran.pandiyan@intel.com> Reviewed-by:
Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by:
James Ausmus <james.ausmus@intel.com> Signed-off-by:
-
Mahesh Kumar authored
ICP has GPIO pin 1/2 mapped to combo-phy ports & GPIO pins 9/10/11/12 mapped to tc ports[1-4]. This patch defines GPIOCTL registers for GPIO pins 9-12 & uses them in GPIO pin mapping table. Cc: Anusha Srivatsa <anusha.srivatsa@intel.com> Cc: Madhav Chauhan <madhav.chauhan@intel.com> Cc: Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
Lucas De Marchi <lucas.demarchi@intel.com> Signed-off-by:
Mahesh Kumar <mahesh1.kumar@intel.com> Signed-off-by:
-
Manasi Navare authored
This patch adds a proper HDMI DDI entry level for vswing programming sequences on ICL. Spec doesn't specify any default for HDMI tables, so let's pick the last entry as the default for now to stay consistent with older platform like CNL. Cc: Rakshmi Bhatia <rakshmi.bhatia@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Chris Wilson authored
Currently all page directories are bound at creation using an unevictable node in the GGTT. This severely limits us as we cannot remove any inactive ppgtt for new contexts, or under aperture pressure. To fix this we need to make the page directory into a first class and unbindable vma. Hence, the creation of a custom vma to wrap the page directory as opposed to a GEM object. In this patch, we leave the page directories pinned upon creation. Signed-off-by:
-
Piotr Piorkowski authored
At this moment we can define GuC logs sizes only using pages. But GuC also allows use for this values expressed in megabytes. Lets add support for define guc_log_size in megabytes when we debug of GuC. v2: - change buffers size to more friendly (Michał Wajdeczko) - merge statements in guc_ctl_log_params_flags() (Michał Wajdeczko) v3: - fix ifdef (rename DRM_I915_DEBUG_GUC to CONFIG_DRM_I915_DEBUG_GUC) (Michał Wajdeczko) - use SZ_* macros to define buffers sizes (Michał Wajdeczko) Signed-off-by:
Piotr Piórkowski <piotr.piorkowski@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
-
Piotr Piorkowski authored
At this moment, we have defined GuC logs sizes in intel_guc_fwif.h, but as these values are related directly to the GuC logs, and not to API of GuC parameters, we should move these defines to intel_guc_log.h. v2: - change buffers size to more friendly (Michał Wajdeczko) - remove GUC_LOG_SIZE define (Michał Wajdeczko) v3: - use SZ_* macros to define buffers sizes (Michał Wajdeczko) Signed-off-by:
-
Piotr Piorkowski authored
At the moment, the preparation of GUC_CTL_CTXINFO is disordered. Lets move all GUC_CTL_CTXINFO related operations to one place. v2: - move 'ctxnum' and 'base' declarations to USES_GUC_SUBMISSION case (Michał Wajdeczko) Signed-off-by:
-
Piotr Piorkowski authored
At the moment, the preparation of GUC_CTL_LOG_PARAMS is disordered. Additionally, in struct intel_guc_log we have an unnecessary field 'flags' which we use only to assign value to GuC parameter. Lets move all GUC_CTL_LOG_PARAMS related operations to one place, and lets remove field 'flags' from struct intel_guc_log. Signed-off-by:
-
Piotr Piorkowski authored
At the moment, the preparation of GUC_CTL_FEATURE is disordered. Lets move all GUC_CTL_FEATURE related operations to one place. Signed-off-by:
-
Piotr Piorkowski authored
At the moment, the preparation of GUC_CTL_DEBUG is disordered. Lets move all GUC_CTL_DEBUG related operations to one place. v2: - move 'ads' declaration to USES_GUC_SUBMISSION case (Michał Wajdeczko) Signed-off-by:
-
Piotr Piórkowski authored
Currently we are using modparam as placeholder for GuC log level. Stop doing this and keep runtime GuC level in intel_guc_log struct. v2: - rename functions intel_guc_log_level_[get|set] to intel_guc_log_[get|set]_level (Michał Wajdeczko) - remove GEM_BUG_ON from intel_guc_log_get_level() (Michał Wajdeczko) Signed-off-by:
-
Chris Wilson authored
Pull the empty stubs together into the top level gen6_ppgtt_create, and tear each one down on error in proper onion order (rather than use Joonas' pet hate of calling the cleanup function in indeterminable state). Signed-off-by:
-
Chris Wilson authored
The legacy gen6 ppgtt needs a little more hand holding than gen8+, and so requires a larger structure. As I intend to make this slightly more complicated in the future, separate the gen6 from the core gen8 hw struct by subclassing. This patch moves the gen6 only features out to gen6_hw_ppgtt and pipes the new type everywhere that needs it. Signed-off-by:
-
Chris Wilson authored
After triggering the mm switch with a load of PD_DIR, which may be deferred unto the MI_SET_CONTEXT on rcs, serialise the next commands with that load by posting a read of PD_DIR (or else those subsequent commands may access the stale page tables). Signed-off-by:
-
