- 23 Oct, 2019 6 commits
-
-
Robert M. Fosha authored
GuC enable logging H2G action definition changed some time ago from 0xE000 to 0x40. All current GuC FW blobs use this definition, so fix the action definition in driver to match. Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Robert M. Fosha <robert.m.fosha@intel.com> Reviewed-by:
Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Signed-off-by:
-
Robert M. Fosha authored
Creating and opening the GuC log relay file enables and starts the relay potentially before the caller is ready to consume logs. Change the behavior so that relay starts only on an explicit call to the write function (with a value of '1'). Other values flush the log relay as before. v2: Style changes and fix typos. Add guc_log_relay_stop() function. (Daniele) Cc: Matthew Brost <matthew.brost@intel.com> Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com> Cc: Michal Wajdeczko <michal.wajdeczko@intel.com> Signed-off-by:
Matthew Brost <matthew.brost@intel.com> Signed-off-by:
-
Imre Deak authored
Atm we don't detect a PCH with PCI ID 0xA3C1 which showed up now on a CML platform. We don't have the official assignment of the PCH PCI IDs, but this looks like a CNP which was already used on CML platforms. Let's add the new ID->PCH type mapping accordingly. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112051Reported-and-tested-by:
Cyrus <cyrus.lien@canonical.com> Cc: Cyrus <cyrus.lien@canonical.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022095155.30991-1-imre.deak@intel.com
-
Jani Nikula authored
DSC isn't DP specific, so remove the dp_ prefix from the crtc state member name. Also moving the member under the dsc sub-struct gives us enough context to allow shortening the name to just config. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022133414.8293-2-jani.nikula@intel.com
-
Jani Nikula authored
Reduce verbosity in code by renaming dsc_params member of crtc state to simply dsc. There is enough context for this to be clear. No functional changes. Cc: Manasi Navare <manasi.d.navare@intel.com> Reviewed-by:
-
Chris Wilson authored
A lock once taken must be released again. Fixes: c31c9e82 ("drm/i915/selftests: Teach switch_to_context() to use the context") Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Matthew Auld <matthew.auld@intel.com> Reviewed-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022223316.12662-1-chris@chris-wilson.co.uk
-
- 22 Oct, 2019 20 commits
-
-
Chris Wilson authored
If retirement is running on another thread, we may inspect the status of the i915_active before its retirement callback is complete. As we expect it to be running synchronously, we can wait for any callback to complete by acquiring the i915_active.mutex. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022112111.9317-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Forcewake is the speciality of the GT, so it is natural to run the intel_uncore_forcewake tests over the GT. So pass intel_gt as the parameter to our selftests. Signed-off-by:
-
Chris Wilson authored
The context details which engines to use, so use the ctx->engines[] to generate the requests to cause the context switch. Signed-off-by:
-
Chris Wilson authored
Again we wish to operate on the engines, which are owned by the intel_gt. As such it is easier, and much more consistent, to pass the intel_gt parameter. v2: Unexport i915_gem_load_power_context() Signed-off-by:
-
Chris Wilson authored
Separate each object class into a separate lock type to avoid lockdep cross-contamination between paths (i.e. userptr!). Signed-off-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022144501.26486-1-chris@chris-wilson.co.uk
-
James Ausmus authored
Even the AML devices that behave like CFLs can be paired with an SPT PCH. Allow this to happen without blowing up dmesg. BSpec: 33665 Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=112013 Cc: Quanxian Wang <quanxian.wang@intel.com> Cc: Rodrigo Vivi <rodrigo.vivi@intel.com> Signed-off-by:
James Ausmus <james.ausmus@intel.com> Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
Matt Roper <matthew.d.roper@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191017194203.9645-1-james.ausmus@intel.com
-
Chris Wilson authored
The actual conditions are that we know the GPU is not accessing the context, and we hold a pin on the context image to allow CPU access. We used a fake lock on ce->pin_mutex so that we could try and use lockdep to assert that access is serialised, but the various different hardirq/softirq contexts where we need to *fake* holding the pin_mutex are causing more trouble. Still it would be nice if we did have a way to reassure ourselves that the direct update to the context image is serialised with GPU execution. In the meantime, stop lockdep complaining about false irq inversions. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111923Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191022122845.25038-1-chris@chris-wilson.co.uk
-
Chris Wilson authored
Loop over all engines, issuing a request for the object on each in order to make sure we leave no stone unturned when creating an active ref. The purpose is to make sure that we can reap a zombie object (one that is only alive due to an active reference on the GPU) no matter where that active reference emanates from. Signed-off-by:
-
Tvrtko Ursulin authored
Contexts are not testing physical engines so it makes sense to use the uabi iterator. Signed-off-by:
-
Tvrtko Ursulin authored
Frees up two call sites from passing i915 to for_each_engine. Signed-off-by:
-
Tvrtko Ursulin authored
Just freeing up two more call sites from passing in i915 to for_each_engine. Signed-off-by:
-
Tvrtko Ursulin authored
Convert the test code to work directly on what it needs rather than going through the top-level i915. This enables another natural usage for for_each_engine(.., gt, ..). Signed-off-by:
-
Tvrtko Ursulin authored
Just compartmentalizes code a bit more. Signed-off-by:
-
Tvrtko Ursulin authored
Engines belong to the GT so make it indicative in the API. Signed-off-by:
-
Tvrtko Ursulin authored
Engines belong to the GT so make it indicative in the API. Signed-off-by:
-
Tvrtko Ursulin authored
Engines belong to the GT so make it indicative in the API. Signed-off-by:
-
Tvrtko Ursulin authored
Engines belong to the GT so make it indicative in the API. Signed-off-by:
-
Tvrtko Ursulin authored
Engines belong to the GT so make it indicative in the API. Signed-off-by:
-
Tvrtko Ursulin authored
Engines belong to the GT so make it indicative in the API. Signed-off-by:
-
Chris Wilson authored
Add the backpointer to ppgtt and i915->gt so that we can traverse across the device hierarchy. Reported-by:
-
- 21 Oct, 2019 8 commits
-
-
Chris Wilson authored
With the last user, i915_vma_parked(), retired, there are no more users of the per-gt pm notifications and we can remove the unused infrastructure. Signed-off-by:
-
Chris Wilson authored
Currently even though i915_vma_parked() operates on a per-gt struct, it is called from a global pm notify. This oddity was only because the long term plan is to decouple the vma cache from the pm notification, but right now the oddity stands out like a sore thumb! Suggested-by:
-
Chris Wilson authored
To flush idle barriers, and even inflight requests, we want to send a preemptive 'pulse' along an engine. We use a no-op request along the pinned kernel_context at high priority so that it should run or else kick off the stuck requests. We can use this to ensure idle barriers are immediately flushed, as part of a context cancellation mechanism, or as part of a heartbeat mechanism to detect and reset a stuck GPU. Signed-off-by:
-
Chris Wilson authored
i915_active must track over any engine, so expand the selftest to iterate over all uabi engines. Signed-off-by:
-
Ville Syrjälä authored
On ILK+ the documented min hdisplay is 64, min hblank is 32, and min vblank is 5. On earlier platforms min hblank is also 32, and min vblank is 3. Make sure the mode satisfies those limits. There are further limits for HDMI and pfit use cases, but we'll check for those in a more specific location. Signed-off-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20190718144340.1114-2-ville.syrjala@linux.intel.comReviewed-by:
-
Chris Wilson authored
If we change the priority of the active context, then it has no impact on the decision of whether to preempt the active context -- we don't preempt the context with itself. In this situation, we elide the tasklet rescheduling and should *not* be marking up the queue_priority_hint as that may mask a later submission where we decide we don't have to kick the tasklet as a higher priority submission is pending (spoiler alert, it was not). Signed-off-by:
-
Joonas Lahtinen authored
Signed-off-by:Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
-
Chris Wilson authored
Use the local vgpu_lock while preparing workloads to avoid taking the obsolete i915->drm.struct_mutex Signed-off-by:
Zhenyu Wang <zhenyuw@linux.intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20191016183902.13614-1-chris@chris-wilson.co.uk
-
- 20 Oct, 2019 2 commits
-
-
Andi Shyti authored
Although the ring management is much smaller compared to the other GT power management functions, continue the theme of extracting it out of the huge intel_pm.c for maintenance. Based on a patch by Chris Wilson. Signed-off-by:
-
Lionel Landwerlin authored
The current logic just reapplies the same configuration already stored into stream->oa_config instead of the newly selected one. Signed-off-by:
Lionel Landwerlin <lionel.g.landwerlin@intel.com> Fixes: 7831e9a9 ("drm/i915/perf: Allow dynamic reconfiguration of the OA stream") Cc: Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
-
- 19 Oct, 2019 4 commits
-
-
Lucas De Marchi authored
s/?/:/ so it gets correctly colored by dmesg. Signed-off-by:
Lucas De Marchi <lucas.demarchi@intel.com> Reviewed-by:
-
Lucas De Marchi authored
This way it's easier to figure out what didn't match when we have multiple pipes enabled. v2: pass drm_crtc and use the more common [CRTC:%d:%s] format (Ville) v3: use struct intel_crtc type to pass crtc around (Ville) Signed-off-by: -
Lucas De Marchi authored
The new line is already added by pipe_config_mismatch(), so the callers shouldn't add it. Signed-off-by:
-
Lucas De Marchi authored
Both Ice Lake and Elkhart Lake (gen 11) support MST on all external connections except DDI A. Tiger Lake (gen 12) supports on all external connections. Move the check to happen inside intel_dp_mst_encoder_init() and add specific platform checks. v2: Replace != with == checks for ports on gen < 11 (Ville) Signed-off-by:
-
