- 21 Mar, 2018 10 commits
-
-
Dhinakaran Pandiyan authored
HSW and BDW have SRD_AUX_{CTL, STATUS} registers that the driver needs to setup for the HW to use whenever exiting PSR. SKL+ hardware use hardcoded values for the same and do not need any registers to be setup. So, use drm_dp_dpcd_writeb() for a one-time write during PSR enable and setup the PSR aux registers on HSW and BDW for later use by HW. We also end up writing to reserved bits in SRD_AUX_CTL by reusing intel_dp->get_aux_send_ctl() for HSW and BDW, fix this. Since the AUX register setup is source side programming, move the call to enable_source() from enable_sink(). Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@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/20180313034646.3721-2-dhinakaran.pandiyan@intel.com
-
Dhinakaran Pandiyan authored
Non-functional change useful for the following patch. Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Chris Wilson authored
We were relying on the uncached reads when processing the CSB to provide ourselves with the serialisation with the interrupt handler (so we could detect new interrupts in the middle of processing the old one). However, in commit 767a983a ("drm/i915/execlists: Read the context-status HEAD from the HWSP") those uncached reads were eliminated (on one path at least) and along with them our serialisation. The result is that we would very rarely miss notification of a new interrupt and leave a context-switch unprocessed, hanging the GPU. Fixes: 767a983a ("drm/i915/execlists: Read the context-status HEAD from the HWSP") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Michel Thierry <michel.thierry@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Reviewed-by:
Michel Thierry <michel.thierry@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180321091027.21034-1-chris@chris-wilson.co.uk
-
Michal Wajdeczko authored
There is no need to mix parameter types in public CT functions as we can always accept intel_guc_ct. v2: fix 'Return' doc, s/dev_priv/i915 (Sagar) Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
We already try to keep all GuC log related code in separate file, handling flush event should be placed there too. This will also allow future code reuse. v2: rebased Signed-off-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
While today we are modifying GuC enabled msg mask only in GuC log, this code should be defined as generic GuC to allow future code reuse. Signed-off-by:
-
Michal Wajdeczko authored
Usually we use shift/mask macros for bit field definitions. Union guc_log_control was not following that pattern. Additional bonus: add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-25 (-25) Function old new delta intel_guc_log_level_set 388 363 -25 v2: prevent out-of-range verbosity (MichalWi) Signed-off-by:
-
Michal Wajdeczko authored
We should avoid using guc_log prefix for functions that don't operate on GuC log, but rather request action from the GuC. Better to use guc_action prefix. v2: rebase + naming compromise v3: rebase Signed-off-by:
-
Michal Wajdeczko authored
We try to keep all HuC related code in dedicated file. There is no need to peek HuC register directly during handling getparam ioctl. Signed-off-by:
-
Kelvin Gardiner authored
This patch adds support to detect ICL, slice, subslice and EU fuse settings. Add addresses for ICL 11 slice, subslice and EU fuses registers. These register addresses are the same as previous platforms but the format and / or the meaning of the information is different. Therefore Gen11 defines for these registers are added. Bspec: 9731 Bspec: 20643 Bspec: 20673 v2: Update fusing information storage after introducing the new query uAPI (Lionel) v3 (Oscar): - The maximum number of slices in ICL 11 is 1 - The subslice disable fuse can potentially store information in all bits - GEN_MAX_SUBSLICES has to be increased to 8 - Don't trust the slice enabled fuse outside the max number of expected slices - Indentation fix and some reordering and renaming of local variables v4: Use single space after Cc tag Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Signed-off-by:Kelvin Gardiner <kelvin.gardiner@intel.com> Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Signed-off-by:
Oscar Mateo <oscar.mateo@intel.com> Reviewed-by:
-
- 20 Mar, 2018 7 commits
-
-
Chris Wilson authored
Not all callers want the GPU error to handled in the same way, so expose a control parameter. In the first instance, some callers do not want the heavyweight error capture so add a bit to request the state to be captured and saved. v2: Pass msg down to i915_reset/i915_reset_engine so that we include the reason for the reset in the dev_notice(), superseding the earlier option to not print that notice. v3: Stash the reason inside the i915->gpu_error to handover to the direct reset from the blocking waiter. Signed-off-by:
-
Chris Wilson authored
If the GPU is stuck waiting for an event or for a semaphore, we need to reset the GPU in order to recover. We have to tell the reset routine which engines we want reset, but we were still using the old interface and declaring it as "not-fatal". Fixes: 14b730fc ("drm/i915/tdr: Prepare error handler to accept mask of hung engines") Signed-off-by:
-
Michał Winiarski authored
When changing the default values for guc_log_level, we accidentally left the log enabled on non-guc platforms. Let's fix that. v2: Define the levels used and remove (now obsolete) comments (Chris) v3: Use "IS" rather than "TO" for booleans (Chris) Fixes: 9605d1ce ("drm/i915/guc: Default to non-verbose GuC logging") Reported-by:
-
Kelvin Gardiner authored
ICL 11 has a greater number of maximum subslices. This patch reflects this. v2: GEN11 updates to MCR_SELECTOR (Oscar) v3: Copypasta error in the new defines (Lionel) Bspec: 21139 BSpec: 21108 Signed-off-by:
-
Oscar Mateo authored
Icelake 11 has one vebox and two vdboxes (0 and 2). Bspec: 21140 v2: Split out in two (Daniele) Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Oscar Mateo authored
In Gen11, the Video Decode engines (aka VDBOX, aka VCS, aka BSD) and the Video Enhancement engines (aka VEBOX, aka VECS) could be fused off. Also, each VDBOX and VEBOX has its own power well, which only exist if the related engine exists in the HW. Unfortunately, we have a Catch-22 situation going on: we need the blitter forcewake to read the register with the fuse info, but we cannot initialize the forcewake domains without knowin about the engines present in the HW. We workaround this problem by allowing the initialization of all forcewake domains and then pruning the fused off ones, as per the fuse information. Bspec: 20680 v2: We were shifting incorrectly for vebox disable (Vinay) v3: Assert mmio is ready and warn if we have attempted to initialize forcewake for fused-off engines (Paulo) v4: - Use INTEL_GEN in new code (Tvrtko) - Shorter local variable (Tvrtko, Michal) - Keep "if (!...) continue" style (Tvrtko) - No unnecessary BUG_ON (Tvrtko) - WARN_ON and cleanup if wrong mask (Tvrtko, Michal) - Use I915_READ_FW (Michal) - Use I915_MAX_VCS/VECS macros (Michal) v5: Rebased by Rodrigo fixing conflicts on top of: "drm/i915: Simplify intel_engines_init" v6: Fix v5. Remove info->num_rings. (by Oscar) v7: Rebase (Rodrigo). v8: - s/intel_device_info_fused_off_engines/ intel_device_info_init_mmio (Chris) - Make vdbox_disable & vebox_disable local variables (Chris) v9: - Move function declaration to intel_device_info.h (Michal) - Missing indent in bit fields definitions (Michal) - When RC6 is enabled by BIOS, the fuse register cannot be read until the blitter powerwell is awake. Shuffle where the fuse is read, prune the forcewake domains after the fact and change the commit message accordingly (Vinay, Sagar, Chris). v10: - Improved commit message (Sagar) - New line in header file (Sagar) - Specify the message in fw_domain_reset applies to ICL+ (Sagar) Cc: Paulo Zanoni <paulo.r.zanoni@intel.com> Cc: Vinay Belgaumkar <vinay.belgaumkar@intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Sagar Arun Kamble <sagar.a.kamble@intel.com> Signed-off-by: -
Daniel Vetter authored
select in Kconfig isn't recursive, we need to select the stuff our selects select, too. Fix that. Signed-off-by:
Daniel Vetter <daniel.vetter@intel.com> Reviewed-by:
Daniel Vetter <daniel.vetter@ffwll.ch> Link: https://patchwork.freedesktop.org/patch/msgid/20180320125009.2305-1-daniel.vetter@ffwll.ch
-
- 19 Mar, 2018 15 commits
-
-
Chris Wilson authored
For the convenience of userspace passing in an arbitrary reset mask, remove unknown engines from the set of engines that are to be reset. This means that we always follow a per-engine reset with a full-device reset when userspace writes -1 into debugfs/i915_wedged. Reported-by:
-
Chris Wilson authored
As the ringbuffer may exist inside stolen memory, our access to it may be via the GTT iomap. This implies we may only have WC access for which the conventional memset() substitution of rep stos performs very badly, so switch to the rep mov[dq] variants when available. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180319123528.28249-1-chris@chris-wilson.co.uk
-
Michał Winiarski authored
We're using those functions in selftests, and the callers are expected to do the error handling anyways. Let's demote all GuC actions and doorbell creation to DEBUG_DRIVER. Signed-off-by:
-
Michał Winiarski authored
Now that we've decoupled logging from relay, GuC log level is only controlling the GuC behavior - there shouldn't be any impact on i915 behaviour. We're only going to see a single extra interrupt when log will get half full. That, and the fact that we're seeing igt/gem_exec_nop/basic-series failing with non-verbose logging being disabled. v2: Bring back the "auto" guc_log_level, now that we fixed the log Signed-off-by:
-
Michał Winiarski authored
While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled 1 Non-verbose log 2-5 Verbose log v2: Adjust naming after rebase. v3: Fixed the log_level logic error introduced on rebase. Signed-off-by:
-
Michał Winiarski authored
If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter and tidy the debugfs formatting. v2: Correct stats accounting (Sagar) v3: Corrected one more error in stats accounting, move relay_enabled (Sagar) Signed-off-by:
-
Michał Winiarski authored
While some of the content in this file is related to GuC submission only, that's not the case with log related statistics. Signed-off-by:
-
Michał Winiarski authored
Runtime is not a very good name. Let's also move counting relay overflows inside relay struct. v2: Rename things rather than remove the struct (Chris) Signed-off-by:
-
Michał Winiarski authored
We only need those fast memcpy_wc when we're using relay to read continuous GuC log. Let's prevent the user from creating a relay if we know we won't be able to keep up with GuC. v2: Adjust the return value (Michał) Signed-off-by:
-
Michał Winiarski authored
Those two concepts are really separate. Since GuC is writing data into its own buffer and we even provide a way for userspace to read directly from it using i915_guc_log_dump debugfs, there's no real reason to tie log level with relay creation. Let's create a separate debugfs, giving userspace a way to create a relay on demand, when it wants to read a continuous log rather than a snapshot. v2: Don't touch guc_log_level on relay creation error, adjust locking after rebase, s/dev_priv/i915, pass guc to file->private_data (Sagar) Use struct_mutex rather than runtime.lock for set_log_level v3: Tidy ordering of definitions (Sagar) Signed-off-by: -
Michał Winiarski authored
Having both guc_flush_logs and guc_log_flush functions is confusing. While we could just rename things, guc_flush_logs implementation is quite simple. Let's get rid of it and move its content to unregister. v2: s/dev_priv/i915 (Sagar) Signed-off-by:
-
Michał Winiarski authored
We have all the information we need at relay_open call time. Since there's no reason to split the process into relay_open and relay_late_setup_files, let's remove the extra code. v2: Remove obsoleted comments (Sagar) v3: There was one obsolete comment left (Sagar) Signed-off-by:
-
Michał Winiarski authored
Currently, we're treating relay and mapping of GuC log as a separate concepts. We're also using inconsistent locking, sometimes using relay_lock, sometimes using struct mutex. Let's correct that. Anything touching the runtime is now serialized using runtime.lock, while we're still using struct mutex as inner lock for mapping. We're still racy in setting the log level - but we'll take care of that in the following patches. v2: Tidy locking (Sagar) v3: Remove obsoleted comment (Sagar) Signed-off-by:
-
Michał Winiarski authored
The GuC log contains a separate space used for crash dump. We even get a separate notification for it. While we're not handling crash differently yet, it makes sense to decouple the two right now to simplify the following patches. v2: Move guc_log_flush_irq_disable up to avoid movement in following patches (Sagar). v3: s/guc_log_flush_irq_*/guc_flush_log_msg_*, rebase after mass rename Signed-off-by: -
Dhinakaran Pandiyan authored
If bios sets up an MST output and hardware state readout code sees this is an SST configuration, when disabling the encoder we end up calling ->post_disable_dp() hook instead of the MST version. Consequently, we write to the DP_SET_POWER dpcd to set it D3 state. Further along when we try enable the encoder in MST mode, POWER_UP_PHY transaction fails to power up the MST hub. This results in continuous link training failures which keep the system busy delaying boot. We could identify bios MST boot discrepancy and handle it accordingly but a simple way to solve this is to write to the DP_SET_POWER dpcd for MST too. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105470 Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Reviewed-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Reported-by:
Laura Abbott <labbott@redhat.com> Cc: stable@vger.kernel.org Fixes: 5ea2355a ("drm/i915/mst: Use MST sideband message transactions for dpms control") Tested-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20180314054825.1718-1-dhinakaran.pandiyan@intel.com
-
- 16 Mar, 2018 8 commits
-
-
Ville Syrjälä authored
AFAIK CHV was supposed to have HBR2 originally, but in the end the feature was dropped. We still have some code leftovers from those early days. Eliminate them. The extra bit for the training pattern seems to be dead in the hardware. I can set it (in fact I can set almost any reserved bit in the registers) but it doesn't seem to interfere with the operation of the hardware. Either that or I'm very lucky that my displays complete link training with the incorrect pattern being sent out. Signed-off-by:
-
Andy Shevchenko authored
...instead of open coding file operations followed by custom ->open() callbacks per each attribute. Reviewed-by:
Andy Shevchenko <andriy.shevchenko@linux.intel.com> Signed-off-by:
-
Ville Syrjälä authored
We don't use the enum i9xx_plane_id namespace on SKL+ anymore, so do not initialize the related plane_to_crtc_mapping[] table either. Actually the only remaining user of that table is the pre-g4x watermark code, but no harm in initializing the table on all pre-SKL platforms. Signed-off-by:
-
Chris Wilson authored
On Valleyview, the HW deduces the base of the reserved portion of stolen memory as being (top - size) and the address field within GEN6_STOLEN_RESERVED is set to 0. Add yet another GEN6_STOLEN_RESERVED reader to cope with the subtly different path required for vlv. v2: Avoid using reserved_base = reserved_size = 0 as the invalid condition as that typically falls outside of the stolen region, provoking a consistency error. Signed-off-by:
-
Chris Wilson authored
In the next patch, we will introduce a new vlv_get_stolen_reserved, so before we do, make sure checkpatch is happy with the surrounding code. Sneak in some debug output while we are here. Signed-off-by:
-
Chris Wilson authored
i915_gem_stolen is an allocator for the reserved portion of memory ("stolen" from the system by the BIOS). It is not tied to KMS but central to the driver, so prefer DRM_DEBUG_DRIVER. Signed-off-by: -
Chris Wilson authored
If we fail to reset the GPU, we declare the machine wedged. However, the GPU may well still be running in the background with an in-flight request. So despite our efforts in cleaning up the request queue and faking the breadcrumb in the HWSP, the GPU may eventually write the in-flght seqno there breaking all of our assumptions and throwing the driver into a deep turmoil, wedging beyond wedged. To avoid this we ideally want to reset the GPU. Since that has already failed, make sure the rings have the stop bit set instead. This is part of the normal GPU reset sequence, but that is actually disabled by igt/gem_eio to force the wedged state. If we assume the worst, we must poke at the bit again before we give up. v2: Move the intel_gpu_reset() from set-wedged in the reset error path into i915_gem_set_wedged() itself. Even if the reset fails (e.g. if it is disabled by gem_eio), it still tries to make sure the engines are stopped. For i915_gem_set_wedged() callers from outside of i915_reset(), this should make sure the GPU is disabled while the driver is marked as being wedged. Testcase: igt/gem_eio Signed-off-by:
-
Chris Wilson authored
We still have an odd race with wedging/unwedging as shown by igt/gem_eio that defies expectations. Add some more trace_printks to try and visualize the flow over the precipice. Signed-off-by:
-
