- 14 Jun, 2018 14 commits
-
-
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 <imre.deak@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180613170710.15080-5-imre.deak@intel.com
-
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 <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:
Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614094103.18025-5-chris@chris-wilson.co.uk
-
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:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180614104709.2808-1-jani.nikula@intel.com
-
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 15 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:
Matthew Auld <matthew.william.auld@gmail.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180612120446.13901-1-chris@chris-wilson.co.uk
-
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:
-
Chris Wilson authored
When we update the gen6 ppgtt page directories, we do so by writing the new address into a reserved slot in the GGTT. It appears that when the GPU reads that entry from the gsm, it uses its small cache and that we need to invalidate that cache after writing. We don't see an issue currently as we prefill the ppgtt page directories on creation; and only create the single aliasing_ppgtt long before we start using the GGTT (and so before the cache may have a conflicting entry). Signed-off-by:
-
- 11 Jun, 2018 10 commits
-
-
Chris Wilson authored
On allocation error, do not jump to the unwind handler that tries to free the error pointer. Reported-by:
-
Chris Wilson authored
The HW only accepts offsets within ring->size, and fails peculiarly if the RING_HEAD or RING_TAIL is set to ring->size. Therefore whenever we set ring->head/ring->tail we want to make sure it is within value (using intel_ring_wrap()). v2: Double check execlists as well v3: Remove redundancy with assert_ring_tail_valid() v4: Just assert in intel_ring_reset() rather than be over-defensive. Signed-off-by:
-
Chris Wilson authored
The discovery with trying to enable full-ppgtt was that we were completely failing to the load both the mm and context following the reset. Although we were performing mmio to set the PP_DIR (per-process GTT) and CCID (context), these were taking no effect (the assumption was that this would trigger reload of the context and restore the page tables). It was not until we performed the LRI + MI_SET_CONTEXT in a following context switch would anything occur. Since we are then required to reset the context image and PP_DIR using CS commands, we place those commands into every batch. The hardware should recognise the no-ops and eliminate the expensive context loads, but we still have to pay the cost of using cross-powerwell register writes. In practice, this has no effect on actual context switch times, and only adds a few hundred nanoseconds to no-op switches. We can improve the latter by eliminating the w/a around known no-op switches, but there is an ulterior motive to keeping them. Always emitting the context switch at the beginning of the request (and relying on HW to skip unneeded switches) does have one key advantage. Should we implement request reordering on Haswell, we will not know in advance what the previous executing context was on the GPU and so we would not be able to elide the MI_SET_CONTEXT commands ourselves and always have to emit them. Having our hand forced now actually prepares us for later. Now since that context and mm follow the request, we no longer (and not for a long time since requests took over!) require a trace point to tell when we write the switch into the ring, since it is always. (This is even more important when you remember that simply writing into the ring bears no relation to the current mm.) v2: Sandybridge has to agree to use LRI as well. Testcase: igt/drv_selftests/live_hangcheck Signed-off-by:
-
Chris Wilson authored
An issue encountered with switching mm on gen7 is that the GPU likes to hang (with the VS unit busy) when told to force restore the current context. We can simply workaround this by substituting the MI_FORCE_RESTORE flag with a round-trip through the kernel_context, forcing the context to be saved and restored; thereby reloading the PP_DIR registers and updating the modified page directory! v2: Undo attempted optimisation in caller (Tvrtko) Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611104808.24295-1-chris@chris-wilson.co.uk
-
Imre Deak authored
While checking workarounds related to the CDCLK PLL, I noticed that the DMC firmware bits for WA#1183 are missing for SKL. After that I clarified with HW people that it's not needed on SKL, since it doesn't support eDP1.4 which would be the only thing requiring the problematic CDCLK clock rates. So in theory we shouldn't ever choose these frequencies, but add an assert in any case for catching such cases and for documentation. v2: - Move the check to skl_set_cdclk and warn whenever using the corresponding VCO freq. (Ville) v3: - Actually check for the platform. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Michel Thierry authored
Use the correct engine class shift value while storing the ctx hw id. Fixes the copy+paste error from commit 61d5676b ("drm/i915/perf: fix ctx_id read with GuC & ICL"). Apologies for not spotting this in the original review, the specific_ctx_id_mask is correct, only the specific_ctx_id had this problem. v2: Just use the upper 32 bits of lrc_desc (Chris) v3: If we use the lrc_desc, we must apply the ctx_id_mask too (Lionel) Fixes: 61d5676b ("drm/i915/perf: fix ctx_id read with GuC & ICL") Signed-off-by:
Michel Thierry <michel.thierry@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Matthew Auld <matthew.auld@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 Reviewed-by:
-
Michel Thierry authored
The upper 32 bits of the lrc_desc (bits 52-32 to be precise) are the context hw id in GEN8-10, so use them and have one less thing to maintain in the unlikely case we change the descriptor sw fields. v2: If we use the lrc_desc, we must apply the ctx_id_mask too (Lionel) Signed-off-by:
-
Chris Wilson authored
We special case the position of the batch within the GTT to prevent negative self-relocation deltas from underflowing. However, that restriction is being applied after a trial pin of the batch in its current position. Thus we are not rejecting an invalid location if the batch has been used before, leading to an assertion if we happen to need to rearrange the entire payload. In the worst case, this may cause a GPU hang on gen7 or perhaps missing state. References: https://bugs.freedesktop.org/show_bug.cgi?id=105720 Fixes: 2889caa9 ("drm/i915: Eliminate lots of iterations over the execobjects array") Signed-off-by:
-
Chris Wilson authored
As i915_gem_object_phys_attach() wants to play dirty and mess around with obj->mm.pages itself (replacing the shmemfs with a DMA allocation), refactor the gubbins so into i915_gem_object_unset_pages() that we don't have to duplicate all the secrets. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180611075532.26534-1-chris@chris-wilson.co.uk Link: https://patchwork.freedesktop.org/patch/msgid/152871104647.1718.8796913290418060204@jlahtine-desk.ger.corp.intel.com
-
Chris Wilson authored
Due to a silent conflict (silent because we are trying to fix the CI test that is meant to exercising these failures!) between commit 51e645b6 ("drm/i915: Mark the GPU as wedged without error on fault injection") and commit 8571a05a ("drm/i915: Use GEM suspend when aborting initialisation"), we failed to actually squash the error message after injecting the load failure. Rearrange the code to export i915_load_failure() for better logging of real errors (and quiet logging of injected errors). Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180609111058.2660-1-chris@chris-wilson.co.uk
-
