- 16 Jan, 2020 2 commits
-
-
Chris Wilson authored
Remove the double space that crept into the fmt stringification. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200116125749.2786743-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
We need to allow concurrent intel_context_unpin, which means avoiding doing destructive operations like intel_ring_reset(). This was already fixed for intel_ring_unpin() in commit 0725d9a3 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint"), but I overlooked that execlists_context_unpin() also made the same mistake. Reported-by:
Matthew Brost <matthew.brost@intel.com> Fixes: 84135022 ("drm/i915/gt: Drop mutex serialisation between context pin/unpin") References: 0725d9a3 ("drm/i915/gt: Make intel_ring_unpin() safe for concurrent pint") Signed-off-by:
-
- 15 Jan, 2020 7 commits
-
-
Radhakrishna Sripada authored
Workaround database indicates we should disable VRH clockgating in pre-production hardware. V2: - Use REG_BIT macro - Update reference in commit message(Matt) Bspec: 52890 Bspec: 49424 Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
Radhakrishna Sripada <radhakrishna.sripada@intel.com> Signed-off-by:
-
Ville Syrjälä authored
Add tracepoints which let us know when fbc activates/deactivates/nukes. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191213133453.22152-5-ville.syrjala@linux.intel.comReviewed-by:
Imre Deak <imre.deak@intel.com>
-
Ville Syrjälä authored
fbc_supported() is just a pointless wrapper for HAS_FBC(). Get rid of it. In places where we're operating on a specific plane we can replace this with a plane->has_fbc check to avoid doing anything for crtcs that don't even support fbc. Signed-off-by:
-
Ville Syrjälä authored
Instead of dealing with the presence/absence of the primary plane in the higher level pre/post plane update code let's move all that into the fbc code itself. Now the higher level code doesn't have to think about FBC details anymore. Signed-off-by:
-
Chris Wilson authored
In converting over to using set_bit()/test_bit(), when manually inspecting the rq->fence.flags, we need to use BIT(). Fixes: e1c31fb5 ("drm/i915: Merge i915_request.flags with i915_request.fence.flags") Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200115122509.2673075-1-chris@chris-wilson.co.uk
-
Jani Nikula authored
It's not uncommon for us to switch param types between bools and ints, often having otherwise bool semantics but -1 value for platform default. Allow bool values (such as YyNn) for ints. Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/c945ac7b08e0eb0827cf647609885f4abdb84f1d.1575560168.git.jani.nikula@intel.com
-
Jani Nikula authored
Add a debugfs subdirectory i915_params with all the i915 module parameters. This is a first step, with lots of boilerplate, and not much benefit yet. This will result in a new device specific debugfs directory at /sys/kernel/debug/dri/<N>/i915_params duplicating the module specific sysfs directory at /sys/module/i915/parameters/. Going forward, all users of the parameters should use the debugfs, with the module parameters being phased out. Add debugfs permissions to I915_PARAMS_FOR_EACH(). This duplicates the mode with module parameter sysfs, but the goal is to make the module parameters read-only initial values for device specific parameters. 0 mode will bypass debugfs creation. Use it for verbose_state_checks which will need special attention in follow-up work. Reviewed-by:
-
- 14 Jan, 2020 13 commits
-
-
Matt Roper authored
I don't think we've ever hit these new error codes, but they're documented in the gen11 pcode document, so we might as well add them to the handler. Signed-off-by:
José Roberto de Souza <jose.souza@intel.com>
-
José Roberto de Souza authored
Renaming to match the BSpec and struct name. BSpec: 20150 Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
José Roberto de Souza authored
TGL has now a table for RBR and HBR and another table for HBR2 over combo phys. The HBR2 one has some small changes comparing to the ICL one, so adding two new tables and adding a function to return TGL combo phy tables. v2: - reordered the tgl_combo_phy_ddi_translations_dp_hbr2 to reduce diff (Matt) - removed definition of rates, kept using raw number(Jani and Ville) - changed code to use icl_get_combo_buf_trans() for non-DP as those are equal between TGL and ICL(Matt) BSpec: 49291 Cc: Lucas De Marchi <lucas.demarchi@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
Chris Wilson authored
Add a i915_vma to the mock_engine/mock_ring so that the core code can always assume the presence of ring->vma. Fixes: 8ccfc20a ("drm/i915/gt: Mark ring->vma as active while pinned") Signed-off-by:
-
Ville Syrjälä authored
intel_prepare_plane_fb() will always pin plane_state->hw.fb whenever it is present. We copy that from the master plane to the slave plane, but we fail to copy the corresponding ggtt view. Thus when it comes time to pin the slave plane's fb we use some stale ggtt view left over from the last time the plane was used as a non-slave plane. If that previous use involved 90/270 degree rotation or remapping we'll try to shuffle the pages of the new fb around accordingingly. However the new fb may be backed by a bo with less pages than what the ggtt view rotation/remapped info requires, and so we we trip a GEM_BUG(). Steps to reproduce on icl: 1. plane 1: whatever plane 6: largish !NV12 fb + 90 degree rotation 2. plane 1: smallish NV12 fb plane 6: make invisible so it gets slaved to plane 1 3. GEM_BUG() Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Closes: https://gitlab.freedesktop.org/drm/intel/issues/951 Fixes: 1f594b20 ("drm/i915: Remove special case slave handling during hw programming, v3.") Signed-off-by:
-
Chris Wilson authored
Take and hold a reference to each of the vma (and their objects) as we process them with the cmdparser. This stops them being freed during the work if the GEM execbuf is interrupted and the request we expected to keep the objects alive is incomplete. Fixes: 686c7c35 ("drm/i915/gem: Asynchronous cmdparser") Closes: https://gitlab.freedesktop.org/drm/intel/issues/970Signed-off-by:
-
Michal Wajdeczko authored
While we have function that returns "next fence" that can be used by new CT request, we internally store value of the last used fence. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Michal Wajdeczko authored
Update GuC CTB action helpers to benefit from new CT_ERROR macro. Signed-off-by:
-
Michal Wajdeczko authored
We should start using dev variants of error logging and to simplify that introduce helper macro that will do any necessary conversions to obtain pointer to device struct. Signed-off-by:
-
Michal Wajdeczko authored
We need CT message size in bytes so just use that in helper var. Signed-off-by:
-
Chris Wilson authored
On suspend, the rc6 residency counters (stored in HW registers) will be lost and cleared. However, we keep track of the rc6 residency to provide a continuous 64b sampling, and if we see the HW value go backwards, we assume it overflowed and add on 32b/40b -- an interesting artifact when sampling across suspend. Signed-off-by:
-
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:
-
Jani Nikula authored
Signed-off-by:
-
- 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:
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: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 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 5 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:
-
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:
-
