- 23 Jun, 2020 4 commits
-
-
Imre Deak authored
It's not clear if the DP_TP_STATUS flags other than the ACT sent flag have some side-effect, so don't clear those; we don't depend on the state of these flags anyway. Suggested-by:
Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Imre Deak <imre.deak@intel.com> Reviewed-by:
-
Imre Deak authored
During transcoder enabling we'll configure the transcoder in MST mode and enable the VC payload allocation, which will start the ACT sequence. Before waiting for the ACT sequence completion, we need to clear the ACT sent flag, but based on the above we can do this right before enabling the transcoder. For clarity, move the flag clearing closer to where we wait for it. While at it also factor out some common code. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
During the initial probing of an MST sink, MST core will determine the sink's link bandwidth based on its own version of the sink link rate/lane count caps it reads from the DPCD. At a later point (after probing and 1 or more modesets) i915 may limit the link parameters wrt. the original source/sink common caps above due to link training failures during a modeset and the resulting link training fallback logic. Based on the above a modeset following another modeset with a link training error will compute the i915 HW specific and DP protocol timing parameters (data/link M/N and MST TU values) taking into account only the unlimited source/sink common caps, but not taking into account the fallback limits. This will also let DRM core oversubscribe the actual link bandwidth during the MST payload allocation. Prevent the above problem by disabling the link training fallback on MST links for now, until the MST probe time initialization and the MST compute config logic can deal with changing link parameters. The misconfigured timings lead at least to a 'Timed out waiting for DP idle patterns' error. v2: (Ville) - Print link training error message on the MST path too. - Clarify the problem in the commit log. Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: Manasi Navare <manasi.d.navare@intel.com> Signed-off-by:
-
Imre Deak authored
MST encoders must use the master MST transcoder's DP_TP_STATUS and DP_TP_CONTROL registers. Atm, during the HW readout of an MST encoder connected to a slave transcoder we reset these register addresses in intel_dp::regs.dp_tp_* to the slave transcoder's DP_TP_* register addresses incorrectly; fix this. One example where the above overwite happens is the encoder HW state validation after enabling multiple streams; see intel_dp_mst_enc_get_config(). After that during disabling any stream we'll get a 'Timed out waiting for ACT sent when disabling' error, due to reading from the incorrect DP_TP_STATUS register. This change replaces https://patchwork.freedesktop.org/patch/369577/?series=78193&rev=1 which just papered over the problem. v2: - Correct the failure scenario in the commit log. (José) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Cc: José Roberto de Souza <jose.souza@intel.com> Signed-off-by:
José Roberto de Souza <jose.souza@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200616211146.23027-1-imre.deak@intel.com
-
- 22 Jun, 2020 1 commit
-
-
Jani Nikula authored
Start using device specific parameters instead of module parameters for most things. The module parameters become the immutable initial values for i915 parameters. The device specific parameters in i915->params start life as a copy of i915_modparams. Any later changes are only reflected in the debugfs. The stragglers are: * i915.force_probe and i915.modeset. Needed before dev_priv is available. This is fine because the parameters are read-only and never modified. * i915.verbose_state_checks. Passing dev_priv to I915_STATE_WARN and I915_STATE_WARN_ON would result in massive and ugly churn. This is handled by not exposing the parameter via debugfs, and leaving the parameter writable in sysfs. This may be fixed up in follow-up work. * i915.inject_probe_failure. Only makes sense in terms of the module, not the device. This is handled by not exposing the parameter via debugfs. v2: Fix uc i915 lookup code (Michał Winiarski) Cc: Juha-Pekka Heikkilä <juha-pekka.heikkila@intel.com> Cc: Venkata Sandeep Dhanalakota <venkata.s.dhanalakota@intel.com> Cc: Michał Winiarski <michal.winiarski@intel.com> Reviewed-by:
Rodrigo Vivi <rodrigo.vivi@intel.com> Acked-by:
Michał Winiarski <michal.winiarski@intel.com> Signed-off-by:
Jani Nikula <jani.nikula@intel.com> Link: http://patchwork.freedesktop.org/patch/msgid/20200618150402.14022-1-jani.nikula@intel.com
-
- 20 Jun, 2020 2 commits
-
-
Chris Wilson authored
We only emit the renderstate once now during module load, it is no longer a concern that we are delaying context creation and so do not need to so eagerly optimise. Since the last time we have looked at the renderstate, we have a pin_map / flush_map facility that supports simple single mappings, replacing the open-coded kmap_atomic() and prepare_write. As it should be a single page, of which we only write a small portion, we stick to a simple WB [kmap] and use clflush on !llc platforms, rather than creating a temporary WC vmapping for the single page. Signed-off-by:
Chris Wilson <chris@chris-wilson.co.uk> Reviewed-by:
Matthew Auld <matthew.auld@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200619234543.17499-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since gvt calls pin_map for the shadow batch buffer, this makes the action of prepare_write [+pin_pages] redundant. We can write into the obj->mm.mapping directory and the flush_map routine knows when it has to flush the cpu cache afterwards. Signed-off-by:
-
- 19 Jun, 2020 3 commits
-
-
Chris Wilson authored
Since we always enable the busy-stats, the culmulative runtime should be accurate, and might be useful for diagnosing issues with the engine. Signed-off-by:
-
Chris Wilson authored
Smatch warns that we may iterate over an empty array of gt->engines[]. One hopes that this is impossible, but nevertheless we can simply appease smatch by initialising the timestamp to zero before we starting probing the busy-time from the engines. Signed-off-by:
-
Gustavo A. R. Silva authored
Make use of the struct_size() helper instead of an open-coded version in order to avoid any potential type mistakes. This code was detected with the help of Coccinelle and, audited and fixed manually. Signed-off-by:
Gustavo A. R. Silva <gustavoars@kernel.org> Reviewed-by:
-
- 18 Jun, 2020 2 commits
-
-
Chris Wilson authored
Return the monotonic timestamp (ktime_get()) at the time of sampling the busy-time. This is used in preference to taking ktime_get() separately before or after the read seqlock as there can be some large variance in reported timestamps. For selftests trying to ascertain that we are reporting accurate to within a few microseconds, even a small delay leads to the test failing. Signed-off-by:
Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617130916.15261-2-chris@chris-wilson.co.uk
-
Chris Wilson authored
A couple of very simple tests to ensure that the basic properties of per-engine busyness accounting [0% and 100% busy] are faithful. Signed-off-by:
Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200617130916.15261-1-chris@chris-wilson.co.uk
-
- 17 Jun, 2020 2 commits
-
-
Colin Ian King authored
There is a spelling mistake in a pr_err message. Fix it. Signed-off-by:
Colin Ian King <colin.king@canonical.com> Reviewed-by:
-
Chris Wilson authored
Like live_unlite_ring, but instead of simply looking at the impact of intel_ring_direction(), check that preemption more generally works with different depths of queued requests in the ring. Signed-off-by:
-
- 16 Jun, 2020 5 commits
-
-
Chris Wilson authored
Rather than mixing [012] and (A1, A2, B2) for the request indices, use the enums throughout. Signed-off-by:
-
Chris Wilson authored
Not too long ago, we realised we had issues with a rolling back a context so far for a preemption request we considered the resubmit not to be a rollback but a forward roll. This means we would issue a lite restore instead of forcing a full restore, continuing execution of the old requests rather than causing a preemption. Add a selftest to exercise such a far rollback, such that if we were to skip the full restore, we would execute invalid instructions in the ring and hang. Note that while I was able to confirm that this causes us to do a lite-restore preemption rollback (with commit e36ba817 ("drm/i915/gt: Incrementally check for rewinding") disabled), it did not trick the HW into rolling past the old RING_TAIL. Myybe on other HW. References: e36ba817 ("drm/i915/gt: Incrementally check for rewinding") Signed-off-by:
-
Tvrtko Ursulin authored
One i915_request_await_object is enough and we keep the one under the object lock so it is final. At the same time move async clflushing setup under the same locked section and consolidate common code into a helper function. v2: * Emit initial breadcrumbs after aways are set up. (Chris) Signed-off-by:
Michael J. Ruhl <michael.j.ruhl@intel.com> Signed-off-by:
-
Chris Wilson authored
Since these inline routines only return the desired pointer from the i915_request(after checking the preconditions for acquiring said pointer), they can be const. Signed-off-by:
-
Gustavo A. R. Silva authored
Fix inconsistent IS_ERR and PTR_ERR in live_timeslice_nopreempt(). The proper pointer to be passed as argument to PTR_ERR() is ce. This bug was detected with the help of Coccinelle. Fixes: b72f02d7 ("drm/i915/gt: Prevent timeslicing into unpreemptable requests") Signed-off-by:
-
- 15 Jun, 2020 6 commits
-
-
Chris Wilson authored
If the tasklet is not being used, don't try and flush it. Fixes: 59489387 ("drm/i915/gt: Add a safety submission flush in the heartbeat") Signed-off-by:
-
Rodrigo Vivi authored
Alexandre Oliva has recently removed these files from Linux Libre with concerns that the sources weren't available. The sources are available on IGT repository, and only open source tools are used to generate the {ivb,hsw}_clear_kernel.c files. However, the remaining concern from Alexandre Oliva was around GPL license and the source not been present when distributing the code. So, it looks like 2 alternatives are possible, the use of linux-firmware.git repository to store the blob or making sure that the source is also present in our tree. Since the goal is to limit the i915 firmware to only the micro-controller blobs let's make sure that we do include the asm sources here in our tree. Btw, I tried to have some diligence here and make sure that the asms that these commits are adding are truly the source for the mentioned files: igt$ ./scripts/generate_clear_kernel.sh -g ivb \ -m ~/mesa/build/src/intel/tools/i965_asm Output file not specified - using default file "ivb-cb_assembled" Generating gen7 CB Kernel assembled file "ivb_clear_kernel.c" for i915 driver... igt$ diff ~/i915/drm-tip/drivers/gpu/drm/i915/gt/ivb_clear_kernel.c \ ivb_clear_kernel.c < * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:29:32 AM UTC > * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:00:54 AM PDT 61c61 < }; > }; \ No newline at end of file igt$ ./scripts/generate_clear_kernel.sh -g hsw \ -m ~/mesa/build/src/intel/tools/i965_asm Output file not specified - using default file "hsw-cb_assembled" Generating gen7.5 CB Kernel assembled file "hsw_clear_kernel.c" for i915 driver... igt$ diff ~/i915/drm-tip/drivers/gpu/drm/i915/gt/hsw_clear_kernel.c \ hsw_clear_kernel.c 5c5 < * Generated by: IGT Gpu Tools on Fri 21 Feb 2020 05:30:13 AM UTC > * Generated by: IGT Gpu Tools on Mon 08 Jun 2020 10:01:42 AM PDT 61c61 < }; > }; \ No newline at end of file Used IGT and Mesa master repositories from Fri Jun 5 2020) IGT: 53e8c878a6fb ("tests/kms_chamelium: Force reprobe after replugging the connector") Mesa: 5d13c7477eb1 ("radv: set keep_statistic_info with RADV_DEBUG=shaderstats") Mesa built with: meson build -D platforms=drm,x11 -D dri-drivers=i965 \ -D gallium-drivers=iris -D prefix=/usr \ -D libdir=/usr/lib64/ -Dtools=intel \ -Dkulkan-drivers=intel && ninja -C build v2: Header clean-up and include build instructions in a readme (Chris) Modified commit message to respect check-patch Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003374.html Reference: http://www.fsfla.org/pipermail/linux-libre/2020-June/003375.html Fixes: 47f8253d ("drm/i915/gen7: Clear all EU/L3 residual contexts") Cc: <stable@vger.kernel.org> # v5.7+ Cc: Alexandre Oliva <lxoliva@fsfla.org> Cc: Prathap Kumar Valsan <prathap.kumar.valsan@intel.com> Cc: Akeem G Abodunrin <akeem.g.abodunrin@intel.com> Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com> Cc: Chris Wilson <chris@chris-wilson.co.uk> Cc: Jani Nikula <jani.nikula@intel.com> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com> Signed-off-by:Jon Bloomfield <jon.bloomfield@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200610201807.191440-1-rodrigo.vivi@intel.com
-
Chris Wilson authored
Just in case everything fails (like for example "missed interrupt syndrome" on Sandybridge), always flush the submission tasklet from the heartbeat. This papers over such issues, but will still appear as a second long glitch, and prevents us from detecting it unless we happen to be performing a timed test. v2: We rely on flush_submission() synchronizing with the tasklet on another CPU. Signed-off-by:
-
Chris Wilson authored
If the engine dies after a reset, and so we fail to submit a request but need to be interrupted by the CI runner, dump the engine state. Signed-off-by:
-
Chris Wilson authored
Since the heartbeat may cause a preemption event, disable it over the preemption suppression tests. Signed-off-by:
-
Imre Deak authored
Atm, hotplug interrupts on TypeC ports are left enabled after detecting an interrupt storm, fix this. Reported-by:
Kunal Joshi <kunal1.joshi@intel.com> References: https://gitlab.freedesktop.org/drm/intel/-/issues/351 Bugzilla: https://gitlab.freedesktop.org/drm/intel/-/issues/1964 Cc: Kunal Joshi <kunal1.joshi@intel.com> Cc: stable@vger.kernel.org Signed-off-by:
-
- 13 Jun, 2020 3 commits
-
-
Chris Wilson authored
gen3 does not fully flush MI stores to memory on MI_FLUSH, such that a subsequent read from e.g. the sampler can bypass the store and read the stale value from memory. This is a serious issue when we are using MI stores to rewrite the batches for relocation, as it means that the batch is reading from random user/kernel memory. While it is particularly sensitive [and detectable] for relocations, reading stale data at any time is a worry. Having started with a small number of delaying stores and doubling until no more incoherency was seen over a few hours (with and without background memory pressure), 32 was the magic number. Note that it definitely doesn't fix the issue, merely adds a long delay between requests, sufficient to mostly hide the problem, enough to raise the mtbf to several hours. This is merely a stop gap. v2: Follow more closer with the gen5 w/a and include some post-invalidate flushes as well. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2018 References: a889580c ("drm/i915: Flush GPU relocs harder for gen3") Signed-off-by:
-
Chris Wilson authored
Reduce the smoke depth by trimming the number of contexts, repetitions and wait times. This is in preparation for a less greedy scheduler that tries to be fair across contexts, resulting in a great many more context switches. A thousand context switches may be 50-100ms, causing us to timeout as the HW is not fast enough to complete the deep smoketests. Signed-off-by:
Andi Shyti <andi.shyti@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200607222108.14401-5-chris@chris-wilson.co.uk
-
Chris Wilson authored
Since the process_csb() does not require us to hold the engine->active.lock, we can move the opportunistic flush before direction submission to outside of the lock. Signed-off-by:
-
- 12 Jun, 2020 2 commits
-
-
Chris Wilson authored
If we find ourselves trying to reuse a misplaced but active vma, we currently try to discard it to avoid having to wait to unbind it (upsetting the current user fo the vma). An alternative to marking it as a dicarded vma and keeping it in both the obj->vma.list and obj->vma.tree, is to simply remove it from the lookup rbtree. While it remains in the list of vma, it will be unbound under eviction pressure and freed along with the object. We will never reuse it again for new instances. As before, with no pruning, the list may continually grow, but eventually we will have the most constrained version of the ggtt view that meets all requirements -- so the list of vma should not grow without bound. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2012 Fixes: 9bdcaa5e ("drm/i915: Discard a misplaced GGTT vma") Signed-off-by:
-
Vandita Kulkarni authored
For all ddi, encoder->type holds output type as ddi, assigning it to individual o/p types is no more valid. Fixes: 362bfb99 ("drm/i915/tgl: Add DKL PHY vswing table for HDMI") v2: Rebase, no functional change. Signed-off-by:
Vandita Kulkarni <vandita.kulkarni@intel.com> Reviewed-by:
Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
- 11 Jun, 2020 10 commits
-
-
Chris Wilson authored
Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by:
-
Chris Wilson authored
Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by:
-
Chris Wilson authored
Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by:
-
Chris Wilson authored
Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by:
-
Chris Wilson authored
Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. Signed-off-by:
-
Chris Wilson authored
Rescue the GT workarounds from being buried inside init_clock_gating so that we remember to apply them after a GT reset, and that they are included in our verification that the workarounds are applied. v2: Leave HSW_SCRATCH to set an explicit value, not or in our disable bit. Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011Signed-off-by:
-
Chris Wilson authored
With the removal of the internal wait-priority boosting, we can also remove the selftest to ensure that those waits were being suppressed from causing preemptions. Signed-off-by:
-
Imre Deak authored
Currently MST on a port can get enabled/disabled from the hotplug work and get disabled from the short pulse work in a racy way. Fix this by relying on the MST state checking in the hotplug work and just schedule a hotplug work from the short pulse handler if some problem happened during the MST interrupt handling. This removes the explicit MST disabling in case of an AUX failure, but if AUX fails, then probably the detection will also fail during the scheduled hotplug work and it's not guaranteed that we'll see intermittent errors anyway. While at it also simplify the error checking of the MST interrupt handler. v2: - Convert intel_dp_check_mst_status() to return bool. (Ville) - Change the intel_dp->is_mst check to an assert, since after this patch the condition can't change after we checked it previously. - Document the return value from intel_dp_check_mst_status(). v3: - Remove the intel_dp->is_mst check from intel_dp_check_mst_status(). There is no point in checking the same condition twice, even though there is a chance that the hotplug work running concurrently changes it. Cc: José Roberto de Souza <jose.souza@intel.com> Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
-
Imre Deak authored
DSC is not supported on DP MST streams so just don't add this entry for MST connectors. This also fixes an OOPS, caused by the encoder->digport cast, which is not valid for MST encoders. v2: - Check encoder, which is unset for an MST connector, before it gets enabled. v3: - Just don't add this debugfs file for MST connectors. (Ville) Cc: Ville Syrjälä <ville.syrjala@linux.intel.com> Signed-off-by:
Manasi Navare <manasi.d.navare@intel.com> Link: https://patchwork.freedesktop.org/patch/msgid/20200609184140.4937-1-imre.deak@intel.com
-
Imre Deak authored
According to BSpec the Data Island Packet should be disabled after disabling the transcoder, but before the transcoder clock select is set to none. On an ICL RVP, daisy-chained MST config not following this leads to a hang with the following MCE when disabling the output: [ 870.948739] mce: [Hardware Error]: CPU 0: Machine Check Exception: 5 Bank 6: ba00000011000402 [ 871.019212] mce: [Hardware Error]: RIP !INEXACT! 10:<ffffffff81aca652> {poll_idle+0x92/0xb0} [ 871.019212] mce: [Hardware Error]: TSC 135a261fe61 [ 871.019212] mce: [Hardware Error]: PROCESSOR 0:706e5 TIME 1591739604 SOCKET 0 APIC 0 microcode 20 [ 871.019212] mce: [Hardware Error]: Run the above through 'mcelog --ascii' [ 871.019212] mce: [Hardware Error]: Machine check: Processor context corrupt [ 871.019212] Kernel panic - not syncing: Fatal machine check [ 871.019212] Kernel Offset: disabled Bspec: 4287 Fixes: fa37a213 ("drm/i915: Stop sending DP SDPs on ddi disable") Cc: Gwan-gyeong Mun <gwan-gyeong.mun@intel.com> Cc: Uma Shankar <uma.shankar@intel.com> Signed-off-by:
-
