- 14 Jan, 2020 2 commits
-
-
Chris Wilson authored
The rc6 residency starts ticking from 0 from BIOS POST, but the kernel starts measuring the time from its boot. If we start measuruing I915_PMU_RC6_RESIDENCY while the GT is idle, we start our sampling from 0 and then upon first activity (park/unpark) add in all the rc6 residency since boot. After the first park with the sampler engaged, the sleep/active counters are aligned. v2: With a wakeref to be sure Closes: https://gitlab.freedesktop.org/drm/intel/issues/973 Fixes: df6a4205 ("drm/i915/pmu: Ensure monotonic rc6") 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/20200114105648.2172026-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
Signed-off-by:Jani Nikula <jani.nikula@intel.com>
-
- 13 Jan, 2020 8 commits
-
-
Chris Wilson authored
Currently, we reset the timer after a pre-eemption event. This has the side-effect that the timeslice runs into the second context after the first is completed after a normal promotion event, causing the second context to be swapped out early and switched for a third context. To be more fair, we want to reset the clock after promotion as well. Signed-off-by:
-
Zhang Xiaoxu authored
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there is an error when compile the kernel: drivers/gpu/drm/i915/gt/intel_reset.c: In function intel_gt_handle_error: drivers/gpu/drm/i915/gt/intel_reset.c:1233:3: error: too few arguments to function i915_capture_error_state i915_capture_error_state(gt->i915); ^~~~~~~~~~~~~~~~~~~~~~~~ In file included from ./drivers/gpu/drm/i915/i915_drv.h:97:0, from ./drivers/gpu/drm/i915/display/intel_display_types.h:46, from drivers/gpu/drm/i915/gt/intel_reset.c:10: ./drivers/gpu/drm/i915/i915_gpu_error.h:267:20: note: declared here static inline void i915_capture_error_state(struct drm_i915_private *dev_priv, Fixes: 742379c0 ("drm/i915: Start chopping up the GPU error capture") Reported-by:Hulk Robot <hulkci@huawei.com> Signed-off-by:
Zhang Xiaoxu <zhangxiaoxu5@huawei.com> Reviewed-by:
-
Zhang Xiaoxu authored
If 'CONFIG_DRM_I915_CAPTURE_ERROR' not configured, there are some errors like: drivers/gpu/drm/i915/i915_irq.o: In function `i915_vma_capture_finish': ./drivers/gpu/drm/i915/i915_gpu_error.h:312: multiple definition of `i915_vma_capture_finish' drivers/gpu/drm/i915/i915_drv.o: ./drivers/gpu/drm/i915/i915_gpu_error.h:312: first defined here So, add 'static inline' on the defineation of the 'i915_vma_capture_finish' Fixes: d713e3ab("drm/i915: Correct typo in i915_vma_compress_finish stub") Reported-by:
-
Ville Syrjälä authored
Just use the passed in encoder instead of digging it out via the legacy drm_connector->encoder pointer (which we'll want to stop using). Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191204180549.1267-5-ville.syrjala@linux.intel.comReviewed-by:
Ramalingam C <ramalingam.c@intel.com>
-
Ville Syrjälä authored
Lots of enc_to_foo(&encoder->base) around. Simplify by passing in the intel_encoder instead. @find@ identifier F =~ "^enc_to_.*"; identifier E; @@ F(struct drm_encoder *E) { ... } @@ identifier find.F; identifier find.E; @@ F( - struct drm_encoder *E + struct intel_encoder *encoder ) { <... - E + &encoder->base ...> } @@ identifier find.F; expression E; @@ - F(E) + F(to_intel_encoder(E)) @@ expression E; @@ - to_intel_encoder(&E->base) + E Signed-off-by:Juha-Pekka Heikkila <juhapekka.heikkila@gmail.com>
-
Ville Syrjälä authored
Life is usually easier when we pass around intel_ types instead of drm_ types. In this case it might not be, but I think being consistent is a good thing anyway. Also some of this might get cleaned up a bit more later as we keep propagating the intel_ types further. @find@ identifier F =~ "^intel_attached_.*"; identifier C; @@ F(struct drm_connector *C) { ... } @@ identifier find.F; identifier find.C; @@ F( - struct drm_connector *C + struct intel_connector *connector ) { <... - C + &connector->base ...> } @@ identifier find.F; expression C; @@ - F(C) + F(to_intel_connector(C)) @@ expression C; @@ - to_intel_connector(&C->base) + C Signed-off-by:Mika Kahola <mika.kahola@intel.com>
-
Stanislav Lisovskiy authored
There seems to be some undocumented bandwidth bottleneck/dependency which scales with CDCLK, causing FIFO underruns when CDCLK is too low, even when it's correct from BSpec point of view. Currently for TGL platforms we calculate min_cdclk initially based on pixel_rate divided by 2, accounting for also plane requirements, however in some cases the lowest possible CDCLK doesn't work and causing the underruns. We've found experimentally that raising cdclk to at least pixel_rate (rather than pixel_rate/2) eliminates these underruns, so let's use this as a temporary workaround until the hardware team can suggest a more precise remedy. Explicitly stating here that this seems to be currently rather a Hack, than final solution. v2: Use clamp operation instead of min(Matt Roper) v3: - Fixed commit message(Matt Roper) - Now using pixel_rate instead of max_cdclk(Jani Nikula) - Switched to max from clamp(Ville Syrjälä) Hopefully this hybrid satisfies everyone :) Reviewed-by:Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Stanislav Lisovskiy <stanislav.lisovskiy@intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/402Signed-off-by:
-
Tvrtko Ursulin authored
We use PCI device path in the registered PMU name in order to distinguish between multiple GPUs. But since tools/perf reserves a special meaning to dash and colon characters we need to transliterate them to something else. We choose an underscore. v2: * Use strreplace. (Chris) * Dashes are not good either. (Chris) Signed-off-by:
Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com> Fixes: 05488673 ("drm/i915/pmu: Support multiple GPUs") Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Andi Kleen <ak@linux.intel.com> Reviewed-by:
-
- 11 Jan, 2020 5 commits
-
-
Chris Wilson authored
A copy and paste error in setting up the !CONFIG_DRM_I915_CAPTURE_ERROR stubs left a conflicting duplicate declaration. Reported-by:
kbuild test robot <lkp@intel.com> Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200111083007.1619228-1-chris@chris-wilson.co.uk
-
Michal Wajdeczko authored
uC sanitization is only meaningful if we are running with uC present or enabled. Make this function part of the uc_ops. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Reviewed-by:
-
Michal Wajdeczko authored
uC preparation and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by:
-
Michal Wajdeczko authored
Firmware fetching and cleanup steps are only meaningful if we are running with uC enabled. Make these functions part of the uc_ops. Signed-off-by:
-
Michal Wajdeczko authored
Instead of spreading multiple conditionals across the uC code to find out current mode of uC operation, start using predefined set of function pointers that reflect that mode. Begin with pair of init_hw/fini_hw functions that are responsible for uC hardware initialization and cleanup. v2: drop ops_none, use macro to generate ops helpers v3: reuse __uc_check_hw to avoid redundant comment v4: forward declare ops struct vs functions Signed-off-by:
-
- 10 Jan, 2020 14 commits
-
-
Chris Wilson authored
We need to hold the runtime-pm wakeref to update the global PTEs (as they exist behind a PCI BAR). However, some systems invoke ACPI during runtime resume and so require allocations, which is verboten inside the vm->mutex. Ergo, we must not use intel_runtime_pm_get() inside the mutex, but lift the call outside. Closes: https://gitlab.freedesktop.org/drm/intel/issues/958Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200110144418.1415639-1-chris@chris-wilson.co.uk
-
Vivek Kasireddy authored
Parsing the i2c element is mainly done to transfer the payload from the MIPI sequence block to the relevant slave device. In some cases, the commands that are part of the payload can be used to turn on the backlight. This patch is actually a refactored version of this old patch: https://lists.freedesktop.org/archives/intel-gfx/2014-December/056897.html In addition to the refactoring, the original patch is augmented by looking up the i2c bus from ACPI NS instead of relying on the bus number provided in the VBT. This patch was tested on Aava Mobile's Inari 10 tablet. It enabled turning on the backlight by transferring the payload to the device. v2: - Add DRM_DEV_ERROR for invalid adapter and failed transfer and also drop the DRM_DEBUG that existed originally. (Hans) - Add two gotos instead of one to clean things up properly. v3: - Identify the device on which this patch was tested in the commit message (Ville) Cc: Hans de Goede <hdegoede@redhat.com> Cc: Nabendu Maiti <nabendu.bikash.maiti@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Hans de Goede <hdegoede@redhat.com> Signed-off-by:
Vivek Kasireddy <vivek.kasireddy@intel.com> Signed-off-by:
-
Chris Wilson authored
The list of requests from after the hang tells little about the hang itself, only how busy userspace was after the fact. As it pertains nothing to the HW state, drop it from the error state. Signed-off-by:
-
Chris Wilson authored
The shadow ring regs (ring->head, ring->tail) are meaningless in the post-mortem dump as they do not related to anything on HW. Remove them from the coredump. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200110123059.1348712-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
While this is technically the batch as executed by the HW (in part at least), it is confusing, and only used for a minority of gen. Signed-off-by:
-
Chris Wilson authored
In the near future, we will want to start a GPU error capture from a new context, from inside the softirq region of a forced preemption. To do so requires us to break up the monolithic error capture to provide new entry points with finer control; in particular focusing on one engine/gt, and being able to compose an error state from little pieces of HW capture. Signed-off-by:
-
Chris Wilson authored
As we use the active state to keep the vma alive while we are reading its contents during GPU error capture, we need to mark the ring->vma as active during execution if we want to include the rinbuffer in the error state. Reported-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: b1e3177b ("drm/i915: Coordinate i915_active with its own mutex") Signed-off-by:
-
Chris Wilson authored
As we use the active state to keep the vma alive while we are reading its contents during GPU error capture, we need to mark the context->state vma as active during execution if we want to include it in the error state. Reported-by:
-
Chris Wilson authored
Currently we first to try to unbind the VMA (and lazily rebind on next use) as an optimisation during restore_ggtt_mappings. Ideally, the only objects in the GGTT upon resume are the pinned kernel objects which can't be unbound and need to be restored. As the unbind interferes with the plan to mark those objects as active for error capture, forgo the optimisation. Signed-off-by:
-
Wambui Karuga authored
Convert to the use of new struct drm_device based logging macros to replace the use of the printk based macros in i915/intel_uncore.c Signed-off-by:
Wambui Karuga <wambui.karugax@gmail.com> Signed-off-by:
-
Wambui Karuga authored
Replace the use of printk based debugging macros with the struct drm_device based logging macros in i915/intel_sideband.c. Signed-off-by:
-
Wambui Karuga authored
Replace instances of printk based logging macros with the new struct drm_device logging macros in i915/intel_region_lmem.c. Signed-off-by:
-
Wambui Karuga authored
This converts various instances of the struct device and printk based logging macros with the new struct drm_device based logging macros in i915/intel_pm.c Signed-off-by:
-
Wambui Karuga authored
Convert the use of the DRM_DEBUG_KMS() logging macro to the new struct drm_device based drm_dbg_kms() logging macro in i915/intel_pch.c. Signed-off-by:
-
- 09 Jan, 2020 11 commits
-
-
Chen Zhou authored
Fix build error: drivers/gpu/drm/i915/gt/intel_ggtt.c: In function ggtt_restore_mappings: drivers/gpu/drm/i915/gt/intel_ggtt.c:1239:3: error: implicit declaration of function wbinvd_on_all_cpus; did you mean wrmsr_on_cpus? [-Werror=implicit-function-declaration] wbinvd_on_all_cpus(); ^~~~~~~~~~~~~~~~~~ wrmsr_on_cpus Reported-by:Chen Zhou <chenzhou10@huawei.com> Reviewed-by:
-
Ville Syrjälä authored
I missed a few assert_pipe_disabled() cases when changing it to take enum transcoder instead of enum pipe, making sparse unhappy. Convert the leftovers. Reported-by:
-
Ville Syrjälä authored
When moving the pipe disable & co. function calls from haswell_crtc_disable() into the encoder .post_disable() hooks I neglected to account for the MST vs. DDI interactions properly. This now leads us to call these functions two times for the last MST stream (once from the MST code and a second time from the DDI code). The calls from the DDI code should only be done for SST and not MST. Add the proper check for that. This results in an MCE on ICL. My vague theory is that we turn off the transcoder clock from the MST code and then we proceed to touch something in the DDI code which still depends on that clock causing the hardware to become upset. Though I can't really explain why Stan's hack of omitting the pipe disable in the MST code would avoid the MCE since we should still be turning off the transcoder clock. But maybe there's something magic in the hw that keeps the clock on as long as the pipe is on. Or maybe the clock isn't the problem and we now touch something in the DDI disable code that really does need the pipe to be still enabled. v2: Rebase to latest drm-tip Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Reported-by:
José Roberto de Souza <jose.souza@intel.com>
-
Jani Nikula authored
Sync with drm-next to get the new logging macros, among other things. Signed-off-by: -
Ma Feng authored
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_crt.c:1066:1-28: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:928:2-29: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_crt.c:443:2-29: WARNING: Assignment of 0/1 to bool variable Reported-by:
Ma Feng <mafeng.ma@huawei.com> Signed-off-by:
-
Ma Feng authored
Fixes coccicheck warning: drivers/gpu/drm/i915/display/intel_dp.c:4950:1-33: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/display/intel_dp.c:4906:1-33: WARNING: Assignment of 0/1 to bool variable Reported-by:
-
Ma Feng authored
Fixes coccicheck warning: drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3078:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable drivers/gpu/drm/i915/i915_debugfs.c:3080:4-36: WARNING: Assignment of 0/1 to bool variable Reported-by:
-
Chris Wilson authored
Now that we have moved the runtime-pm management out of intel_context_acctive_acquire, and that itself out of ce->ops->pin(), no explicit runtime pm wakeref is required in intel_context_pin(). Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200109085717.873326-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
While this is encroaching on midlayer territory, having already made the state allocation a previous step in pinning, we can now pull the common intel_context_active_acquire() into intel_context_pin() itself. This is a prelude to make the activation a separate step inside pinning, outside of the ce->pin_mutex Signed-off-by:
-
Chris Wilson authored
Allow for knowledgeable users to preallocate the context state, and to separate the allocation step from the pinning step during intel_context_pin() Signed-off-by:
-
Chris Wilson authored
Since we now allow the intel_context_unpin() to run unserialised, we risk our operations under the intel_context_lock_pinned() being run as the context is unpinned (and thus invalidating our state). We can atomically acquire the pin, testing to see if it is pinned in the process, thus ensuring that the state remains consistent during the course of the whole operation. Fixes: 84135022 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") Signed-off-by:
-
