- 27 Jun, 2019 2 commits
-
-
Jani Nikula authored
With the subdirectories we lost the ability to build individual files on the command line, for example: $ make drivers/gpu/drm/i915/display/intel_display.o This was due to the top level directory missing from header search path. Add the header search paths to subdir Makefiles. Note that none of the other options in the top level i915 Makefile are taken into account when building individual files. Usually this is not a concern. Reported-by:
Imre Deak <imre.deak@intel.com> Reported-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Chris Wilson <chris@chris-wilson.co.uk> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626143618.21800-2-jani.nikula@intel.com
-
Jani Nikula authored
Per commit 43068cb7 ("drm: prefix header search paths with $(srctree)/") this is what we should be doing. Follow suit. Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 26 Jun, 2019 19 commits
-
-
Michal Wajdeczko authored
OA files look to be auto-generated so we can keep them all in dedicated subdirectory. Signed-off-by:
Michal Wajdeczko <michal.wajdeczko@intel.com> Cc: Lionel Landwerlin <lionel.g.landwerlin@intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Acked-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Acked-by:
Umesh Nerlige Ramappa <umesh.nerlige.ramappa@intel.com> Signed-off-by:
-
José Roberto de Souza authored
EHL has it own voltage level requirement depending on cd clock. BSpec: 21809 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
Matt Roper <matthew.d.roper@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626014053.30541-3-jose.souza@intel.com
-
José Roberto de Souza authored
EHL do not support 648 and 652.8 MHz. v2: - Limiting maximum CD clock by max_cdclk_freq instead of remove it from icl_calc_cdclk()(Ville and Jani) BSpec: 20598 Cc: Clint Taylor <Clinton.A.Taylor@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> Reviewed-by:
-
José Roberto de Souza authored
Now 180, 172.8 and 192 MHz are supported. 180 and 172.8 MHz CD clocks will only be used when audio is not enabled as state by BSpec and implemented in intel_crtc_compute_min_cdclk(), CD clock must be at least twice of Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48 MHz but we are not reading it. v3: - making icl clock arrays static (Ville) BSpec: 20598 BSpec: 15729 Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Reviewed-by:
-
Chris Wilson authored
Since the reset path wants to recover the engines itself, it only wants to reinitialise the hardware using i915_gem_init_hw(). Pull the call to intel_engines_resume() to the module init/resume path so we can avoid it during reset. Fixes: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Imre Deak <imre.deak@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190626154549.10066-3-chris@chris-wilson.co.uk
-
Chris Wilson authored
If we issue a reset to a currently idle engine, leave it idle afterwards. This is useful to excise a linkage between reset and the shrinker. When waking the engine, we need to pin the default context image which we use for overwriting a guilty context -- if the engine is idle we do not need this pinned image! However, this pinning means that waking the engine acquires the FS_RECLAIM, and so may trigger the shrinker. The shrinker itself may need to wait upon the GPU to unbind and object and so may require services of reset; ergo we should avoid the engine wake up path. The danger in skipping the recovery for idle engines is that we leave the engine with no context defined, which may interfere with the operation of the power context on some older platforms. In practice, we should only be resetting an active GPU but it something to look out for on Ironlake (if memory serves). Fixes: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
-
Chris Wilson authored
For use in the next patch, we want to acquire a wakeref without having to wake the device up -- i.e. only acquire the engine wakeref if the engine is already active. Signed-off-by:
-
Ville Syrjälä authored
Move the .get_vblank_timestamp() and .get_scanout_position() initialization to happen at compile time. No point in delaying it since we always assign the same functions. Signed-off-by:
-
Ville Syrjälä authored
Stop using the irq vfuncs under drm_driver. That's not going to fly in a mixed gen environment since the structure is shared between all the devices. v2: Allow intel_irq_uninstall() to be called twice due to intel_modeset_cleanup() calling it as well. Toss in a FIXME to remind us that this is not great. Signed-off-by: -
Ville Syrjälä authored
Switch from the driver-wide vblank vfuncs to the per-crtc ones so that we don't have so many platform specific vfuncs in the driver struct. We still need to do something about the rest fo the irq vfuncs... v2: s/INTEL_GEN>=3/IS_GEN3/ Signed-off-by:
-
Ville Syrjälä authored
Gen2 doesn't have a frame counter and apparently we no longer provide a fake .get_vblank_counter() hook for it. That means all tracepoints calling that hook will oops. Update the tracepoints to use intel_crtc_get_vblank_counter() which will gracefully fall back to using the software counter. This is actually a better approach since we now get (hopefully accurate) frame numbers in the traces. This also gets rid of the raw driver->get_vblank_counter() calls, which we need to do in order to switch to the per-crtc vblank vfuncs. v2: Deal with new tracepoints v3: Use a distinct variable name for the internal crtc iterator (Chris) Cc: Shawn Guo <shawn.guo@linaro.org> Cc: Daniel Vetter <daniel.vetter@ffwll.ch> Fixes: 967dd484 ("drm: remove drm_vblank_no_hw_counter assignment from driver code") Signed-off-by:
-
Chris Wilson authored
We require that the intel_gpu_reset() was atomic, not the whole of i915_reset() which is guarded by a mutex. However, we do require that i915_reset_engine() is atomic for use from within the submission tasklet. Signed-off-by:
-
Chris Wilson authored
We no longer need to manually acquire a wakeref for request emission, so drop the redundant wakerefs, letting us test our wakeref handling more precisely. References: 79ffac85 ("drm/i915: Invert the GEM wakeref hierarchy") Signed-off-by:
-
Chris Wilson authored
In order for the reset count to be accurate across our selftest, we need to prevent the background retire worker from modifying our expected state. To preserve the intent of symmetry, we apply this to both i915_reset and i915_reset_engine, even though it strictly only affects i915_reset_engine currently. Signed-off-by:
-
Lee Shawn C authored
If LFP backlight type setting from VBT was "VESA eDP AUX Interface". Driver should check panel capability and try to initialize aux backlight. No matter i915_modparams.enable_dpcd_backlight was enabled or not. v2: access dev_priv->vbt.backlight.type directly and remove unused function. v3: 1. Modify i915.enable_dpcd_backlight type from bool to int and give default value as 0 (disable). 2. Add a judgement to check LFP backlight type was aux interface or not. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Jose Roberto de Souza <jose.souza@intel.com> Cc: Cooper Chiou <cooper.chiou@intel.com> Signed-off-by:Lee Shawn C <shawn.c.lee@intel.com> Signed-off-by:
-
Mika Kahola authored
We are missing PCI device ID for SKU ICLLP U GT 1.5F (0x8A54) as per BSPec. BSpec: 19092 Signed-off-by:
Mika Kahola <mika.kahola@intel.com> Reviewed-by:
Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
Maarten Lankhorst <maarten.lankhorst@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190617082413.22549-1-mika.kahola@intel.com
-
Chris Wilson authored
Add the context pin/unpin events to the trace for post-mortem debugging. Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190625194859.28005-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Always initialise the refcount, even for the embedded timelines inside mock devices. Signed-off-by:
-
Chris Wilson authored
We no longer allocate a contiguous set of timeline ids for all engines upon creation, so we no longer should assume that the timelines are densely allocated within a context. Hopefully, the set of fences used within a workload are still dense enough for us to take advantage of the compressed radix tree used for the syncmap. Signed-off-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190625233349.32371-1-chris@chris-wilson.co.uk
-
- 25 Jun, 2019 9 commits
-
-
Chris Wilson authored
As we wait upon the request, we should be sure to hold our own reference for our checks. Signed-off-by:
-
Chris Wilson authored
Our general rule is to use is/has as the verb for boolean functions, rename intel_wakeref_active to intel_wakeref_is_active so the question being asked is clear. Signed-off-by:
-
Chris Wilson authored
Switch from passing the i915 container to newly named struct intel_gt. Signed-off-by:
-
Robert M. Fosha authored
Detect GuC firmware load failure due to an exception during execution in GuC firmware. Output the GuC EIP where exception occurred to dmesg for GuC debug information. v2: correct typos, change debug message and error code returned for GuC exception (Michal) Signed-off-by:
Robert M. Fosha <robert.m.fosha@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Reviewed-by:
-
Chris Wilson authored
As this engine owns the lock around rq->sched.link (for those waiters submitted to this engine), we can use that link as an element in a local list. We can thus replace the recursive algorithm with an iterative walk over the ordered list of waiters. Signed-off-by:
-
José Roberto de Souza authored
EHL can have up to one VECS(video enhancement) engine, so add it to the device_info. BSpec: 29152 Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Cc: Bob Paauwe <bob.j.paauwe@intel.com> Cc: Matt Roper <matthew.d.roper@intel.com> Cc: Clint Taylor <Clinton.A.Taylor@intel.com> Signed-off-by:
-
Matt Roper authored
There's one additional ID that we should treat as Mule Creek Canyon. Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
-
Lionel Landwerlin authored
We got the wrong offsets (could they have changed?). New values were computed off an error state by looking up the register offset in the context image as written by the HW. Signed-off-by:
Kenneth Graunke <kenneth@whitecape.org> Link: https://patchwork.freedesktop.org/patch/msgid/20190610081914.25428-1-lionel.g.landwerlin@intel.com
-
Kenneth Graunke authored
The Demand Prefetch workaround (binding table prefetching) only applies to Icelake A0/B0. But the Sampler Prefetch workaround needs to be applied to all Gen11 steppings, according to a programming note in the SARCHKMD documentation. Using the Intel Gallium driver, I have seen intermittent failures in the dEQP-GLES31.functional.copy_image.non_compressed.* tests. After applying this workaround, the tests reliably pass. v2: Remove the overlap with a pre-production w/a BSpec: 9663 Signed-off-by:
-
- 24 Jun, 2019 2 commits
-
-
Chris Wilson authored
Update the domains for the write via the GPU so that we do not shortcircuit any set-domain clflush afterwards. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110978 Fixes: b2dbf8d9 ("drm/i915/blt: Remove recursive vma->lock") Signed-off-by:
-
Chris Wilson authored
In the unlikely case (thank you CI!), we may find ourselves wanting to issue a preemption but having no runnable requests left. In this case, we set the semaphore before computing the preemption and so must unset it before forgetting (or else we leave the machine busywaiting until the next request comes along and so likely hang). v2: Replace readback with only a wmb after asserting the semaphore Signed-off-by:
-
- 21 Jun, 2019 8 commits
-
-
Chris Wilson authored
As we have already plugged the w->dma into the reservation_object, and have set ourselves up to automatically signal the request and w->dma on completion, we do not need to export the rq->fence directly and just use the w->dma fence. This avoids having to take the reservation_lock inside the worker which cross-release lockdep would complain about. :) Signed-off-by:
-
Chris Wilson authored
Avoid pulling in i915_gem.h just so that we can use a conditional BUG_ON for debugging. Signed-off-by:
-
Chris Wilson authored
If we introduce a callback for i915_active that is only called the first time we use the i915_active and is symmetrically paired with the i915_active.retire callback, we can replace the open-coded and non-atomic implementations -- which will be very fragile (i.e. broken) upon removing the struct_mutex serialisation. Signed-off-by:
-
Chris Wilson authored
Remove the accumulated optimisations that we have for i915_vma_retire and reduce it to the bare essential of tracking the active object reference. This allows us to only use atomic operations, and so will be able to avoid the struct_mutex requirement. The principal loss here is the shrinker MRU bumping, so now if we have to shrink, we will do so in much more random order and more likely to try and shrink recently used objects. That is a nuisance, but shrinking active objects is a second step we try to avoid and will always be a system-wide performance issue. The other loss is here is in the automatic pruning of the reservation_object when idling. This is not as large an issue as upon reservation_object introduction as now adding new fences into the object replaces already signaled fences, keeping the array compact. But we do lose the auto-expiration of stale fences and unused arrays. That may be a noticeable problem for which we need to re-implement autopruning. Signed-off-by:
-
Chris Wilson authored
Provide runtime asserts and tracking of i915_active via debugobjects. For example, this should allow us to check that the i915_active is only active when we expect it to be and is never freed too early. One consequence is that, for simplicity, we no longer allow i915_active to be on-stack which only affected the selftests. Signed-off-by:
-
Chris Wilson authored
i915_gem_wait_for_idle() and i915_retire_requests() introduce a dependency on the timeline->mutex. This is problematic as we want to later perform allocations underneath i915_active.mutex, forming a link between the shrinker, the timeline and active mutexes. Nip this cycle in the bud by removing the acquisition of the timeline mutex (i.e. retiring) from inside the shrinker. Signed-off-by:
-
Daniele Ceraolo Spurio authored
There is a very small chance of triggering a log flush event when enabling or disabling CT buffers. Events triggered while CT buffers are disabled are logged in the SCRATCH_15 register using the same bits used in the CT message payload. Since our communication channel with GuC is turned off, we can save the message and handle it after we turn it back on. GuC should be idle and not generate more events in the meantime because we're not talking to it. v2: clear the mmio register on stop_communication as well (Chris) Signed-off-by:
-
Daniele Ceraolo Spurio authored
Make sure we always have CT buffers enabled when the interrupts are enabled, so we can always handle interrupts from GuC. Also move the setting of the guc->send and guc->handler functions to the GuC communication control functions for consistency. The reorder also fixes the onion unwinding of intel_uc_init_hw, because guc_enable_communication would've left interrupts enabled when failing to enable CTB. v2: always retunr the result of ctch_enable() in intel_guc_ct_enable() (Michal) Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110943Signed-off-by:Matthew Brost <matthew.brost@intel.com> Reviewed-by:
-
