[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for DSB enablement. (rev2)
== Series Details == Series: DSB enablement. (rev2) URL : https://patchwork.freedesktop.org/series/63013/ State : warning == Summary == $ dim checkpatch origin/drm-tip e65049952809 drm/i915/dsb: feature flag added for display state buffer. ff9965b61f73 drm/i915/dsb: DSB context creation. -:43: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #43: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 121 lines checked 5e026ff7ced1 drm/i915/dsb: single register write function for DSB. c2a803f1f6c9 drm/i915/dsb: Added enum for reg write capability. c432f5814713 drm/i915/dsb: Indexed register write function for DSB. 363815055070 drm/i915/dsb: Update i915_write to call dsb-write. -:51: ERROR:COMPLEX_MACRO: Macros with complex values should be enclosed in parentheses #51: FILE: drivers/gpu/drm/i915/i915_drv.h:2419: +#define I915_WRITE(reg__, val__) \ + (reg__.cap) ? intel_dsb_reg_write(dev_priv->dsb, (reg__), (val__)) : \ + __I915_REG_OP(write, dev_priv, (reg__), (val__)) -:51: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'reg__' - possible side-effects? #51: FILE: drivers/gpu/drm/i915/i915_drv.h:2419: +#define I915_WRITE(reg__, val__) \ + (reg__.cap) ? intel_dsb_reg_write(dev_priv->dsb, (reg__), (val__)) : \ + __I915_REG_OP(write, dev_priv, (reg__), (val__)) -:51: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'val__' - possible side-effects? #51: FILE: drivers/gpu/drm/i915/i915_drv.h:2419: +#define I915_WRITE(reg__, val__) \ + (reg__.cap) ? intel_dsb_reg_write(dev_priv->dsb, (reg__), (val__)) : \ + __I915_REG_OP(write, dev_priv, (reg__), (val__)) total: 1 errors, 0 warnings, 2 checks, 26 lines checked 6a23be979f1b drm/i915/dsb: Register definition of DSB registers. 20dcb2d6beeb drm/i915/dsb: Check DSB engine status. 58c392a91a63 drm/i915/dsb: functions to enable/disable DSB engine. 4a715966094e drm/i915/dsb: function to trigger workload execution of DSB. 0607b6bd8f57 drm/i915/dsb: function to destroy DSB context. 16d2ad5f1cf2 drm/i915/dsb: Early prepare of dsb context. cb19df1870f3 drm/i915/dsb: Cleanup of DSB context. d88ece297e3e drm/i915/dsb: Documentation for DSB. 5ff614b2aa70 drm/i915/dsb: Enable gamma lut programming using DSB. -:72: WARNING:LONG_LINE: line over 100 characters #72: FILE: drivers/gpu/drm/i915/i915_reg.h:10255: +#define PREC_PAL_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_GC_MAX_A, _PAL_PREC_GC_MAX_B) + (i) * 4, \ -:74: WARNING:LONG_LINE: line over 100 characters #74: FILE: drivers/gpu/drm/i915/i915_reg.h:10257: +#define PREC_PAL_EXT_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_EXT_GC_MAX_A, _PAL_PREC_EXT_GC_MAX_B) + (i) * 4, \ -:76: WARNING:LONG_LINE: line over 100 characters #76: FILE: drivers/gpu/drm/i915/i915_reg.h:10259: +#define PREC_PAL_EXT2_GC_MAX(pipe, i) _MMIO(_PIPE(pipe, _PAL_PREC_EXT2_GC_MAX_A, _PAL_PREC_EXT2_GC_MAX_B) + (i) * 4, \ total: 0 errors, 3 warnings, 0 checks, 67 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for DSB enablement. (rev2)
== Series Details == Series: DSB enablement. (rev2) URL : https://patchwork.freedesktop.org/series/63013/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915/dsb: feature flag added for display state buffer. Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for DSB enablement. (rev2)
== Series Details == Series: DSB enablement. (rev2) URL : https://patchwork.freedesktop.org/series/63013/ State : success == Summary == CI Bug Log - changes from CI_DRM_6750 -> Patchwork_14117 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/ Known issues Here are the changes found in Patchwork_14117 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s3: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html * igt@kms_busy@basic-flip-c: - fi-kbl-7500u: [PASS][3] -> [SKIP][4] ([fdo#109271] / [fdo#109278]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-kbl-7500u/igt@kms_b...@basic-flip-c.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-cml-u2: [PASS][5] -> [DMESG-WARN][6] ([fdo#102505]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-cml-u2/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([fdo#102614]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@i915_selftest@live_reset: - fi-icl-u2: [INCOMPLETE][9] ([fdo#107713]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-icl-u2/igt@i915_selftest@live_reset.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-icl-u2/igt@i915_selftest@live_reset.html Warnings * igt@kms_chamelium@dp-hpd-fast: - fi-icl-u2: [FAIL][11] ([fdo#111407]) -> [DMESG-FAIL][12] ([fdo#110595]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-icl-u2/igt@kms_chamel...@dp-hpd-fast.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][13] ([fdo#111096]) -> [FAIL][14] ([fdo#111407]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14117/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505 [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278 [fdo#110595]: https://bugs.freedesktop.org/show_bug.cgi?id=110595 [fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (50 -> 42) -- Additional (3): fi-skl-guc fi-apl-guc fi-pnv-d510 Missing(11): fi-kbl-soraka fi-icl-u4 fi-bxt-dsi fi-ilk-m540 fi-hsw-4200u fi-glk-dsi fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6750 -> Patchwork_14117 CI-20190529: 20190529 CI_DRM_6750: ba37f74dbdc1e78e70a5a2e5f4ce8d762d06eaa7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5146: 357dbe1869d88a2f08bcee4eebceff4ee9014424 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14117: 5ff614b2aa70d503bf4c9e280927dc5bd3fb9e07 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 5ff614b2aa70 drm/i915/dsb: Enable gamma lut programming using DSB. d88ece297e3e drm/i915/dsb: Documentation for DSB. cb19df1870f3 drm/i915/dsb: Cleanup of DSB context. 16d2ad5f1cf2 drm/i915/dsb: Early prepare of dsb context. 0607b6bd8f57 drm/i915/dsb: function to destroy DSB context. 4a715966094e drm/i915/dsb: function to trigger workload execution of DSB. 58c392a91a63 drm/i915/dsb: functions to enable/disable DSB engine. 20dcb2d6beeb drm/i915/dsb: Check DSB engine status. 6a23be979f1b drm/i915/dsb: Register definition of DSB registers. 363815055070 drm/i915/dsb: Update i915_write to call dsb-write. c432f5814713 drm/i915/dsb: Indexed register write f
Re: [Intel-gfx] [PATCH 33/39] drm/i915/perf: add a parameter to control the size of OA buffer
I think this patch needs to be landed after
https://patchwork.freedesktop.org/patch/319815/?series=60916&rev=10
As recommended by Joonas.
It should also bump the revision number of the perf API so that the
application can detect this feature is available.
Thanks,
-Lionel
On 16/08/2019 10:04, Lucas De Marchi wrote:
From: Lionel Landwerlin
The way our hardware is designed doesn't seem to let us use the
MI_RECORD_PERF_COUNT command without setting up a circular buffer.
In the case where the user didn't request OA reports to be available
through the i915 perf stream, we can set the OA buffer to the minimum
size to avoid consuming memory which won't be used by the driver.
Cc: Joonas Lahtinen
Cc: Matthew Auld
Signed-off-by: Lionel Landwerlin
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_perf.c | 98 +---
drivers/gpu/drm/i915/i915_reg.h | 2 +
include/uapi/drm/i915_drm.h | 7 +++
3 files changed, 74 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2c9f46e12622..9386d9c82930 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -216,13 +216,7 @@
#include "oa/i915_oa_cnl.h"
#include "oa/i915_oa_icl.h"
-/* HW requires this to be a power of two, between 128k and 16M, though driver
- * is currently generally designed assuming the largest 16M size is used such
- * that the overflow cases are unlikely in normal operation.
- */
-#define OA_BUFFER_SIZE SZ_16M
-
-#define OA_TAKEN(tail, head) ((tail - head) & (OA_BUFFER_SIZE - 1))
+#define OA_TAKEN(tail, head) (((tail) - (head)) &
(stream->oa_buffer.vma->size - 1))
/**
* DOC: OA Tail Pointer Race
@@ -347,6 +341,7 @@ static const struct i915_oa_format
gen8_plus_oa_formats[I915_OA_FORMAT_MAX] = {
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
* @oa_period_exponent: The OA unit sampling period is derived from this
+ * @oa_buffer_size_exponent: The OA buffer size is derived from this
*
* As read_properties_unlocked() enumerates and validates the properties given
* to open a stream of metrics the configuration is built up in the structure
@@ -363,6 +358,7 @@ struct perf_open_properties {
int oa_format;
bool oa_periodic;
int oa_period_exponent;
+ u32 oa_buffer_size_exponent;
};
static enum hrtimer_restart oa_poll_check_timer_cb(struct hrtimer *hrtimer);
@@ -531,7 +527,7 @@ static bool oa_buffer_check_unlocked(struct
i915_perf_stream *stream)
* could put the tail out of bounds...
*/
if (hw_tail >= gtt_offset &&
- hw_tail < (gtt_offset + OA_BUFFER_SIZE)) {
+ hw_tail < (gtt_offset + stream->oa_buffer.vma->size)) {
stream->oa_buffer.tails[!aged_idx].offset =
aging_tail = hw_tail;
stream->oa_buffer.aging_timestamp = now;
@@ -659,7 +655,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
int report_size = stream->oa_buffer.format_size;
u8 *oa_buf_base = stream->oa_buffer.vaddr;
u32 gtt_offset = i915_ggtt_offset(stream->oa_buffer.vma);
- u32 mask = (OA_BUFFER_SIZE - 1);
+ u32 mask = (stream->oa_buffer.vma->size - 1);
size_t start_offset = *offset;
unsigned long flags;
unsigned int aged_tail_idx;
@@ -699,8 +695,8 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* only be incremented by multiples of the report size (notably also
* all a power of two).
*/
- if (WARN_ONCE(head > OA_BUFFER_SIZE || head % report_size ||
- tail > OA_BUFFER_SIZE || tail % report_size,
+ if (WARN_ONCE(head > stream->oa_buffer.vma->size || head % report_size
||
+ tail > stream->oa_buffer.vma->size || tail % report_size,
"Inconsistent OA buffer pointers: head = %u, tail = %u\n",
head, tail))
return -EIO;
@@ -723,7 +719,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* here would imply a driver bug that would result
* in an overrun.
*/
- if (WARN_ON((OA_BUFFER_SIZE - head) < report_size)) {
+ if (WARN_ON((stream->oa_buffer.vma->size - head) <
report_size)) {
DRM_ERROR("Spurious OA head ptr: non-integral report
offset\n");
break;
}
@@ -881,11 +877,6 @@ static int gen8_oa_read(struct i915_perf_stream *stream,
* automatically triggered reports in this condition and so we
* have to assume that old reports are now being trampled
* over.
-*
-* Considering how we don't currently give userspace cont
[Intel-gfx] [drm-intel:for-linux-next 3/3] drivers/gpu/drm/i915/i915_gem_gtt.c:3317:3: error: implicit declaration of function 'wbinvd_on_all_cpus'; did you mean 'wrmsr_on_cpus'?
tree: git://anongit.freedesktop.org/drm-intel for-linux-next head: 64b95df91f44837f961321a6c555409885ca59c4 commit: 64b95df91f44837f961321a6c555409885ca59c4 [3/3] drm/i915: Assume exclusive access to objects inside resume config: x86_64-randconfig-f002-201933 (attached as .config) compiler: gcc-7 (Debian 7.4.0-10) 7.4.0 reproduce: git checkout 64b95df91f44837f961321a6c555409885ca59c4 # save the attached .config to linux build tree make ARCH=x86_64 If you fix the issue, kindly add following tag Reported-by: kbuild test robot All errors (new ones prefixed by >>): drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'ggtt_restore_mappings': >> drivers/gpu/drm/i915/i915_gem_gtt.c:3317: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 Cyclomatic Complexity 5 include/linux/compiler.h:__read_once_size Cyclomatic Complexity 5 include/linux/compiler.h:__write_once_size Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_read Cyclomatic Complexity 1 include/linux/kasan-checks.h:kasan_check_write Cyclomatic Complexity 1 arch/x86/include/asm/bitops.h:fls64 Cyclomatic Complexity 1 include/linux/log2.h:__ilog2_u64 Cyclomatic Complexity 1 include/linux/list.h:INIT_LIST_HEAD Cyclomatic Complexity 1 include/linux/list.h:__list_del Cyclomatic Complexity 1 include/linux/math64.h:div64_u64_rem Cyclomatic Complexity 1 arch/x86/include/asm/current.h:get_current Cyclomatic Complexity 1 include/asm-generic/getorder.h:__get_order Cyclomatic Complexity 2 arch/x86/include/asm/jump_label.h:arch_static_branch Cyclomatic Complexity 1 include/linux/jump_label.h:static_key_false Cyclomatic Complexity 1 arch/x86/include/asm/string_64.h:memset32 Cyclomatic Complexity 1 arch/x86/include/asm/string_64.h:memset64 Cyclomatic Complexity 1 include/linux/string.h:memset_p Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_read Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_set Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_add Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_sub Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_inc Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_dec_and_test Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_add_return Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_sub_return Cyclomatic Complexity 1 arch/x86/include/asm/atomic.h:arch_atomic_fetch_add Cyclomatic Complexity 2 arch/x86/include/asm/atomic.h:arch_atomic_try_cmpxchg Cyclomatic Complexity 1 arch/x86/include/asm/atomic64_64.h:arch_atomic64_read Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_read Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_set Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_add Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_fetch_add Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_sub Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_sub_return Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_inc Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_try_cmpxchg Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic_dec_and_test Cyclomatic Complexity 1 include/asm-generic/atomic-instrumented.h:atomic64_read Cyclomatic Complexity 1 include/linux/atomic-fallback.h:atomic_fetch_inc Cyclomatic Complexity 1 include/asm-generic/atomic-long.h:atomic_long_read Cyclomatic Complexity 1 include/linux/err.h:ERR_PTR Cyclomatic Complexity 1 include/linux/err.h:PTR_ERR Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_save_fl Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_restore_fl Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:native_irq_disable Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_save_flags Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_restore Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_disable Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_local_irq_save Cyclomatic Complexity 1 arch/x86/include/asm/irqflags.h:arch_irqs_disabled_flags Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_add Cyclomatic Complexity 5 arch/x86/include/asm/preempt.h:__preempt_count_sub Cyclomatic Complexity 1 include/linux/spinlock.h:spinlock_check Cyclo
Re: [Intel-gfx] [PATCH v2 21/40] drm/i915/tgl: Enable VD HCP/MFX sub-pipe power gating
Reviewed-by: Tony Ye
Regards, --Tony
On 8/21/2019 4:54 AM, Lucas De Marchi wrote:
On Sat, Aug 17, 2019 at 02:38:43AM -0700, Lucas De Marchi wrote:
From: Michel Thierry
HCP/MFX power gating is disabled by default, turn it on for the vd units
available. User space will also issue a MI_FORCE_WAKEUP properly to
wake up proper subwell.
During driver load, init_clock_gating happens after
device_info_init_mmio
read the vdbox disable fuse register, so only present vd units will have
these enabled.
BSpec: 14214
HSDES: 1209977827
Cc: Tony Ye
Signed-off-by: Michel Thierry
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_reg.h | 4
drivers/gpu/drm/i915/intel_pm.c | 17 -
2 files changed, 20 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h
b/drivers/gpu/drm/i915/i915_reg.h
index a55f15eb6175..c1b779c40fa8 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8621,6 +8621,10 @@ enum {
#define GEN9_PWRGT_MEDIA_STATUS_MASK (1 << 0)
#define GEN9_PWRGT_RENDER_STATUS_MASK (1 << 1)
+#define POWERGATE_ENABLE _MMIO(0xa210)
+#define VDN_HCP_POWERGATE_ENABLE(n) BIT(((n) * 2) + 3)
+#define VDN_MFX_POWERGATE_ENABLE(n) BIT(((n) * 2) + 4)
+
#define GTFIFODBG _MMIO(0x12)
#define GT_FIFO_SBDEDICATE_FREE_ENTRY_CHV (0x1f << 20)
#define GT_FIFO_FREE_ENTRIES_CHV (0x7f << 13)
diff --git a/drivers/gpu/drm/i915/intel_pm.c
b/drivers/gpu/drm/i915/intel_pm.c
index 75ee027abb80..604c53793726 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -9078,6 +9078,21 @@ static void icl_init_clock_gating(struct
drm_i915_private *dev_priv)
_MASKED_BIT_ENABLE(GEN11_ENABLE_32_PLANE_MODE));
}
+static void tgl_init_clock_gating(struct drm_i915_private *dev_priv)
+{
+ u32 vd_pg_enable = 0;
+ unsigned int i;
+
+ /* This is not a WA. Enable VD HCP & MFX_ENC powergate */
+ for (i = 0; i < I915_MAX_VCS; i++) {
+ if (HAS_ENGINE(dev_priv, _VCS(i)))
+ vd_pg_enable |= VDN_HCP_POWERGATE_ENABLE(i) |
+ VDN_MFX_POWERGATE_ENABLE(i);
+ }
missing blank line here. Probably my fault while rebasing.
Reviewed-by: Lucas De Marchi
Lucas De Marchi
+ I915_WRITE(POWERGATE_ENABLE,
+ I915_READ(POWERGATE_ENABLE) | vd_pg_enable);
+}
+
static void cnp_init_clock_gating(struct drm_i915_private *dev_priv)
{
if (!HAS_PCH_CNP(dev_priv))
@@ -9598,7 +9613,7 @@ static void nop_init_clock_gating(struct
drm_i915_private *dev_priv)
void intel_init_clock_gating_hooks(struct drm_i915_private *dev_priv)
{
if (IS_GEN(dev_priv, 12))
- dev_priv->display.init_clock_gating = nop_init_clock_gating;
+ dev_priv->display.init_clock_gating = tgl_init_clock_gating;
else if (IS_GEN(dev_priv, 11))
dev_priv->display.init_clock_gating = icl_init_clock_gating;
else if (IS_CANNONLAKE(dev_priv))
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/5] drm/i915/dp: stylistic cleanup around hdcp2_msg_data
== Series Details == Series: series starting with [1/5] drm/i915/dp: stylistic cleanup around hdcp2_msg_data URL : https://patchwork.freedesktop.org/series/65481/ State : success == Summary == CI Bug Log - changes from CI_DRM_6749_full -> Patchwork_14103_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14103_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb7/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_capture@capture-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb7/igt@gem_exec_capt...@capture-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-iclb2/igt@gem_exec_capt...@capture-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb1/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-iclb3/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108686]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-apl1/igt@gem_tiled_swapp...@non-threaded.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108] / [fdo#107807]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-skl9/igt@i915_pm_...@system-suspend-execbuf.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-skl7/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-hsw2/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_frontbuffer_tracking@fbc-badstride: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb5/igt@kms_frontbuffer_track...@fbc-badstride.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-iclb8/igt@kms_frontbuffer_track...@fbc-badstride.html * igt@kms_frontbuffer_tracking@psr-1p-offscren-pri-indfb-draw-blt: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#103167]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-skl8/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-skl6/igt@kms_frontbuffer_track...@psr-1p-offscren-pri-indfb-draw-blt.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-skl8/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@kms_psr@suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#108972]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-skl9/igt@kms_...@suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-skl6/igt@kms_...@suspend.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-apl5/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-apl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html Possible fixes * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [SKIP][23] ([fdo#111325]) -> [PASS][24] +4 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14103/shard-iclb8/igt@gem_exec_as.
Re: [Intel-gfx] [PATCH 4/4] mm, notifier: Catch sleeping/blocking for !blockable
On Wed, Aug 21, 2019 at 9:33 AM Jason Gunthorpe wrote:
>
> On Tue, Aug 20, 2019 at 05:18:10PM +0200, Daniel Vetter wrote:
> > > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> > > > index 538d3bb87f9b..856636d06ee0 100644
> > > > +++ b/mm/mmu_notifier.c
> > > > @@ -181,7 +181,13 @@ int __mmu_notifier_invalidate_range_start(struct
> > > > mmu_notifier_range *range)
> > > > id = srcu_read_lock(&srcu);
> > > > hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list,
> > > > hlist) {
> > > > if (mn->ops->invalidate_range_start) {
> > > > - int _ret = mn->ops->invalidate_range_start(mn, range);
> > > > + int _ret;
> > > > +
> > > > + if (!mmu_notifier_range_blockable(range))
> > > > + non_block_start();
> > > > + _ret = mn->ops->invalidate_range_start(mn, range);
> > > > + if (!mmu_notifier_range_blockable(range))
> > > > + non_block_end();
> > >
> > > If someone Acks all the sched changes then I can pick this for
> > > hmm.git, but I still think the existing pre-emption debugging is fine
> > > for this use case.
> >
> > Ok, I'll ping Peter Z. for an ack, iirc he was involved.
> >
> > > Also, same comment as for the lockdep map, this needs to apply to the
> > > non-blocking range_end also.
> >
> > Hm, I thought the page table locks we're holding there already prevent any
> > sleeping, so would be redundant?
>
> AFAIK no. All callers of invalidate_range_start/end pairs do so a few
> lines apart and don't change their locking in between - thus since
> start can block so can end.
>
> Would love to know if that is not true??
Yeah I reviewed them, I think I mixed up a discussion I had a while
ago with Jerome. It's a bit tricky to follow in the code since in some
places ->invalidate_range and ->invalidate_range_end seem to be called
from the same place, in others not at all.
> Similarly I've also been idly wondering if we should add a
> 'might_sleep()' to invalidate_rangestart/end() to make this constraint
> clear & tested to the mm side?
Hm, sounds like a useful idea. Since in general you wont test with mmu
notifiers, but they could happen, and then they will block for at
least some mutex usually. I'll throw that as an idea on top for the
next round.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Include asm/smp.h
We need asm/smp.h for wbinvd_on_all_cpus() Reported-by: kbuild-...@01.org Signed-off-by: Chris Wilson Cc: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index c9a4690bf8b1..14eef8f8d16a 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -32,6 +32,7 @@ #include #include +#include #include -- 2.23.0.rc1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gtt: Include asm/smp.h
== Series Details == Series: drm/i915/gtt: Include asm/smp.h URL : https://patchwork.freedesktop.org/series/65532/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8b9d243b31ad drm/i915/gtt: Include asm/smp.h -:20: WARNING:INCLUDE_LINUX: Use #include instead of #20: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:35: +#include total: 0 errors, 1 warnings, 0 checks, 7 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gtt: Include asm/smp.h
Quoting Patchwork (2019-08-21 11:01:05)
> == Series Details ==
>
> Series: drm/i915/gtt: Include asm/smp.h
> URL : https://patchwork.freedesktop.org/series/65532/
> State : warning
>
> == Summary ==
>
> $ dim checkpatch origin/drm-tip
> 8b9d243b31ad drm/i915/gtt: Include asm/smp.h
> -:20: WARNING:INCLUDE_LINUX: Use #include instead of
Sorry, checkpatch but you are wrong. If we did that, it would not
include asm/smp.h for !CONFIG_SMP and we would not have the
wbinvd_on_all_cpus() { wbinv() } stub.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gtt: Include asm/smp.h
On 21/08/2019 10:39, Chris Wilson wrote: We need asm/smp.h for wbinvd_on_all_cpus() Reported-by: kbuild-...@01.org Signed-off-by: Chris Wilson Cc: Matthew Auld Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Do not create a new max_bpc prop for MST connectors
== Series Details == Series: drm/i915: Do not create a new max_bpc prop for MST connectors URL : https://patchwork.freedesktop.org/series/65493/ State : success == Summary == CI Bug Log - changes from CI_DRM_6749_full -> Patchwork_14108_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14108_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_flush@basic-wb-pro-default: - shard-snb: [PASS][1] -> [INCOMPLETE][2] ([fdo#105411]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-snb4/igt@gem_exec_fl...@basic-wb-pro-default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-snb6/igt@gem_exec_fl...@basic-wb-pro-default.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +18 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb1/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-iclb7/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb5/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_persistent_relocs@forked-interruptible: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb5/igt@gem_persistent_rel...@forked-interruptible.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-iclb7/igt@gem_persistent_rel...@forked-interruptible.html * igt@i915_selftest@live_hangcheck: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / [fdo#108569]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb5/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-iclb4/igt@i915_selftest@live_hangcheck.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-apl3/igt@i915_susp...@sysfs-reader.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-apl5/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#105767]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#103060]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-glk1/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-glk1/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#104108]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-skl8/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-skl8/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-b.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-iclb8/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-iclb1/igt@kms_psr@no_drrs.html * igt@perf@blocking: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#110728]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6749/shard-skl4/igt@p...@blocking.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14108/shard-skl4/igt@p...@blocking.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][25] -> [SKIP][26] ([fdo#109271]) [25]: https:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gtt: Include asm/smp.h
== Series Details ==
Series: drm/i915/gtt: Include asm/smp.h
URL : https://patchwork.freedesktop.org/series/65532/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6752 -> Patchwork_14118
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14118/
Known issues
Here are the changes found in Patchwork_14118 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6752/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14118/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
Participating hosts (56 -> 47)
--
Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6752 -> Patchwork_14118
CI-20190529: 20190529
CI_DRM_6752: 127b3299354a78fac5c2a450e78950ee258c0355 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5146: 357dbe1869d88a2f08bcee4eebceff4ee9014424 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14118: 8b9d243b31adabfe5abe6a868a3cf0cbd79e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8b9d243b31ad drm/i915/gtt: Include asm/smp.h
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14118/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/dp: stylistic cleanup around hdcp2_msg_data
On Tue, 20 Aug 2019, Ramalingam C wrote:
> On 2019-08-20 at 16:40:15 +0300, Jani Nikula wrote:
>> Split struct declaration and array definition. Fix indents and
>> whitespace. No functional changes.
>>
>
> Reviewed-by: Ramalingam C
Thanks, pushed the lot.
BR,
Jani.
>
> -Ram
>> Cc: Ramalingam C
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_dp.c | 70 +
>> 1 file changed, 36 insertions(+), 34 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 5c45a3bb102d..001d520660a9 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -5812,47 +5812,49 @@ struct hdcp2_dp_errata_stream_type {
>> u8 stream_type;
>> } __packed;
>>
>> -static struct hdcp2_dp_msg_data {
>> +struct hdcp2_dp_msg_data {
>> u8 msg_id;
>> u32 offset;
>> bool msg_detectable;
>> u32 timeout;
>> u32 timeout2; /* Added for non_paired situation */
>> -} hdcp2_msg_data[] = {
>> -{HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0},
>> -{HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
>> -false, HDCP_2_2_CERT_TIMEOUT_MS, 0},
>> -{HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
>> -false, 0, 0},
>> -{HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
>> -false, 0, 0},
>> -{HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
>> -true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
>> -HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS},
>> -{HDCP_2_2_AKE_SEND_PAIRING_INFO,
>> -DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
>> -HDCP_2_2_PAIRING_TIMEOUT_MS, 0},
>> -{HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0},
>> -{HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
>> -false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0},
>> -{HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
>> -0, 0},
>> -{HDCP_2_2_REP_SEND_RECVID_LIST,
>> -DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
>> -HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0},
>> -{HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
>> -0, 0},
>> -{HDCP_2_2_REP_STREAM_MANAGE,
>> -DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
>> -0, 0},
>> -{HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
>> -false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0},
>> +};
>> +
>> +static struct hdcp2_dp_msg_data hdcp2_msg_data[] = {
>> +{ HDCP_2_2_AKE_INIT, DP_HDCP_2_2_AKE_INIT_OFFSET, false, 0, 0 },
>> +{ HDCP_2_2_AKE_SEND_CERT, DP_HDCP_2_2_AKE_SEND_CERT_OFFSET,
>> + false, HDCP_2_2_CERT_TIMEOUT_MS, 0 },
>> +{ HDCP_2_2_AKE_NO_STORED_KM, DP_HDCP_2_2_AKE_NO_STORED_KM_OFFSET,
>> + false, 0, 0 },
>> +{ HDCP_2_2_AKE_STORED_KM, DP_HDCP_2_2_AKE_STORED_KM_OFFSET,
>> + false, 0, 0 },
>> +{ HDCP_2_2_AKE_SEND_HPRIME, DP_HDCP_2_2_AKE_SEND_HPRIME_OFFSET,
>> + true, HDCP_2_2_HPRIME_PAIRED_TIMEOUT_MS,
>> + HDCP_2_2_HPRIME_NO_PAIRED_TIMEOUT_MS },
>> +{ HDCP_2_2_AKE_SEND_PAIRING_INFO,
>> + DP_HDCP_2_2_AKE_SEND_PAIRING_INFO_OFFSET, true,
>> + HDCP_2_2_PAIRING_TIMEOUT_MS, 0 },
>> +{ HDCP_2_2_LC_INIT, DP_HDCP_2_2_LC_INIT_OFFSET, false, 0, 0 },
>> +{ HDCP_2_2_LC_SEND_LPRIME, DP_HDCP_2_2_LC_SEND_LPRIME_OFFSET,
>> + false, HDCP_2_2_DP_LPRIME_TIMEOUT_MS, 0 },
>> +{ HDCP_2_2_SKE_SEND_EKS, DP_HDCP_2_2_SKE_SEND_EKS_OFFSET, false,
>> + 0, 0 },
>> +{ HDCP_2_2_REP_SEND_RECVID_LIST,
>> + DP_HDCP_2_2_REP_SEND_RECVID_LIST_OFFSET, true,
>> + HDCP_2_2_RECVID_LIST_TIMEOUT_MS, 0 },
>> +{ HDCP_2_2_REP_SEND_ACK, DP_HDCP_2_2_REP_SEND_ACK_OFFSET, false,
>> + 0, 0 },
>> +{ HDCP_2_2_REP_STREAM_MANAGE,
>> + DP_HDCP_2_2_REP_STREAM_MANAGE_OFFSET, false,
>> + 0, 0 },
>> +{ HDCP_2_2_REP_STREAM_READY, DP_HDCP_2_2_REP_STREAM_READY_OFFSET,
>> + false, HDCP_2_2_STREAM_READY_TIMEOUT_MS, 0 },
>> /* local define to shovel this through the write_2_2 interface */
>> #define HDCP_2_2_ERRATA_DP_STREAM_TYPE 50
>> -{HDCP_2_2_ERRATA_DP_STREAM_TYPE,
>> -DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
>> -0, 0},
>> -};
>> +{ HDCP_2_2_ERRATA_DP_STREAM_TYPE,
>> + DP_HDCP_2_2_REG_STREAM_TYPE_OFFSET, false,
>> + 0, 0 },
>> +};
>>
>> static inline
>> int intel_dp_hdcp2_read_rx_status(struct intel_digital_port *intel_dig_
Re: [Intel-gfx] [PATCH] drm/i915: Serialise the fill BLT with the vma pinning
On 20/08/2019 14:52, Chris Wilson wrote:
Make sure that we wait for the vma to be pinned prior to telling the GPU
to fill the pages through that vma.
However, since our async operations fight over obj->resv->excl_fence we
must manually order them. This makes it much more fragile, and gives an
outside observer the chance to see the intermediate fences. To be
discussed!
Signed-off-by: Chris Wilson
Cc: Matthew Auld
---
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 46 ++-
1 file changed, 35 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index 3502071e1391..bbbc10499099 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -71,10 +71,30 @@ static struct i915_sleeve *create_sleeve(struct
i915_address_space *vm,
goto err_free;
}
+ /*
+* XXX fix scheduling with get_pages & clear workers
+*
+* The complication is that we end up overwriting the same
+* obj->resv->excl_fence for each stage of the operation. That fence
+* should be set on scheduling the work, and only signaled upon
+* completion of the entire workqueue.
+*
+* Within the workqueue, we use the fence to schedule each individual
+* task. Each individual task knows to use obj->resv->fence.
+*
+* To an outsider, they must wait until the end and so the
+* obj->resv->fence must be the composite.
+*
+* Ideas?
+*/
I don't have any good ideas...
Are we meant to somehow have a "shadow" resv obj that we use for our
intermediate pipelined ops, such that we don't leak anything?
Reviewed-by: Matthew Auld
+ err = i915_vma_pin(vma, 0, 0, PIN_USER);
+ if (unlikely(err))
+ goto err_free;
+
vma->private = sleeve;
vma->ops = &proxy_vma_ops;
- sleeve->vma = vma;
+ sleeve->vma = i915_vma_get(vma);
sleeve->pages = pages;
sleeve->page_sizes = *page_sizes;
@@ -87,6 +107,13 @@ static struct i915_sleeve *create_sleeve(struct i915_address_space *vm,
static void destroy_sleeve(struct i915_sleeve *sleeve)
{
+ struct i915_vma *vma = sleeve->vma;
+
+ if (vma) {
+ i915_vma_unpin(vma);
+ i915_vma_put(vma);
+ }
+
kfree(sleeve);
}
@@ -155,8 +182,8 @@ static void clear_pages_dma_fence_cb(struct dma_fence *fence,
static void clear_pages_worker(struct work_struct *work)
{
struct clear_pages_work *w = container_of(work, typeof(*w), work);
- struct drm_i915_gem_object *obj = w->sleeve->vma->obj;
- struct i915_vma *vma = w->sleeve->vma;
+ struct i915_vma *vma = fetch_and_zero(&w->sleeve->vma);
+ struct drm_i915_gem_object *obj = vma->obj;
struct i915_request *rq;
struct i915_vma *batch;
int err = w->dma.error;
@@ -166,20 +193,16 @@ static void clear_pages_worker(struct work_struct *work)
if (obj->cache_dirty) {
if (i915_gem_object_has_struct_page(obj))
- drm_clflush_sg(w->sleeve->pages);
+ drm_clflush_sg(vma->pages);
obj->cache_dirty = false;
}
obj->read_domains = I915_GEM_GPU_DOMAINS;
obj->write_domain = 0;
- err = i915_vma_pin(vma, 0, 0, PIN_USER);
- if (unlikely(err))
- goto out_signal;
-
batch = intel_emit_vma_fill_blt(w->ce, vma, w->value);
if (IS_ERR(batch)) {
err = PTR_ERR(batch);
- goto out_unpin;
+ goto out_signal;
}
rq = intel_context_create_request(w->ce);
@@ -224,14 +247,15 @@ static void clear_pages_worker(struct work_struct *work)
i915_request_add(rq);
out_batch:
intel_emit_vma_release(w->ce, batch);
-out_unpin:
- i915_vma_unpin(vma);
out_signal:
if (unlikely(err)) {
dma_fence_set_error(&w->dma, err);
dma_fence_signal(&w->dma);
dma_fence_put(&w->dma);
}
+
+ i915_vma_unpin(vma);
+ i915_vma_put(vma);
}
static int __i915_sw_fence_call
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Serialise the fill BLT with the vma pinning
Quoting Matthew Auld (2019-08-21 12:00:07)
> On 20/08/2019 14:52, Chris Wilson wrote:
> > Make sure that we wait for the vma to be pinned prior to telling the GPU
> > to fill the pages through that vma.
> >
> > However, since our async operations fight over obj->resv->excl_fence we
> > must manually order them. This makes it much more fragile, and gives an
> > outside observer the chance to see the intermediate fences. To be
> > discussed!
> >
> > Signed-off-by: Chris Wilson
> > Cc: Matthew Auld
> > ---
> > .../gpu/drm/i915/gem/i915_gem_client_blt.c| 46 ++-
> > 1 file changed, 35 insertions(+), 11 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > index 3502071e1391..bbbc10499099 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
> > @@ -71,10 +71,30 @@ static struct i915_sleeve *create_sleeve(struct
> > i915_address_space *vm,
> > goto err_free;
> > }
> >
> > + /*
> > + * XXX fix scheduling with get_pages & clear workers
> > + *
> > + * The complication is that we end up overwriting the same
> > + * obj->resv->excl_fence for each stage of the operation. That fence
> > + * should be set on scheduling the work, and only signaled upon
> > + * completion of the entire workqueue.
> > + *
> > + * Within the workqueue, we use the fence to schedule each individual
> > + * task. Each individual task knows to use obj->resv->fence.
> > + *
> > + * To an outsider, they must wait until the end and so the
> > + * obj->resv->fence must be the composite.
> > + *
> > + * Ideas?
> > + */
>
> I don't have any good ideas...
>
> Are we meant to somehow have a "shadow" resv obj that we use for our
> intermediate pipelined ops, such that we don't leak anything?
A sketch I haven't put any code to is a struct chain_fence {
struct dma_fence base;
struct dma_fence *prev;
struct dma_fence_cb cb;
/* if only dma_chain_fence wan't already taken, maybe
dma_composite_fence */
}; that we insert as dma_resv_add_excl_fence() and then
pass to all the async operations that then chain to. It means more work
in making sure we have the fence available at all times, all the way
down the chain, but it should work (now and in the future)... Give or
take various factors to make sure we don't wait on the same fence while
building it (eviction and shrinking).
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 17/40] drm: Add for_each_oldnew_intel_crtc_in_state_reverse()
On Sat, 2019-08-17 at 02:38 -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> Same as for_each_oldnew_intel_crtc_in_state() but iterates in reverse
> order.
>
> v2: Fix additional blank line
>
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index fd3043e77b50..b63fb7a4599e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -419,6 +419,15 @@ enum phy_fia {
>((connector) =
> to_intel_connector((__state)->base.connectors[__i].ptr), \
>(new_connector_state) =
> to_intel_digital_connector_state((__state)-
> >base.connectors[__i].new_state), 1))
>
> +#define for_each_oldnew_intel_crtc_in_state_reverse(__state, crtc,
> old_crtc_state, new_crtc_state, __i) \
> + for ((__i) = (__state)->base.dev->mode_config.num_crtc - 1; \
Maybe aligning these two 'for' loops on top of each other similarly to
to other. Now, it seems the lower one is off by one.
Otherwise, this is
Reviewed-by: Mika Kahola
> + (__i) >= 0 && \
> + ((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \
> + (old_crtc_state) = to_intel_crtc_state((__state)-
> >base.crtcs[__i].old_state), \
> + (new_crtc_state) = to_intel_crtc_state((__state)-
> >base.crtcs[__i].new_state), 1); \
> + (__i)--) \
> + for_each_if(crtc)
> +
> void intel_link_compute_m_n(u16 bpp, int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 18/40] drm/i915: Disable pipes in reverse order
On Sat, 2019-08-17 at 02:38 -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> Disable CRTC/pipes in reverse order because some features (MST in
> TGL+) requires master and slave relationship between pipes, so it
> should always pick the lowest pipe as master as it will be enabled
> first and disable in the reverse order so the master will be the last
> one to be disabled.
>
> Cc: Rodrigo Vivi
> Cc: Ville Syrjälä
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index b51d1ceb8739..ddb8436e2208 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13908,7 +13908,15 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> if (state->modeset)
> wakeref = intel_display_power_get(dev_priv,
> POWER_DOMAIN_MODESET);
>
> - for_each_oldnew_intel_crtc_in_state(state, crtc,
> old_crtc_state, new_crtc_state, i) {
> + /*
> + * Disable CRTC/pipes in reverse order because some
> features(MST in
> + * TGL+) requires master and slave relationship between pipes,
> so it
> + * should always pick the lowest pipe as master as it will be
> enabled
> + * first and disable in the reverse order so the master will be
> the
> + * last one to be disabled.
> + */
> + for_each_oldnew_intel_crtc_in_state_reverse(state, crtc,
> old_crtc_state,
> + new_crtc_state, i)
> {
> if (needs_modeset(new_crtc_state) ||
> new_crtc_state->update_pipe) {
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/6] drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
On Tue, 20 Aug 2019 at 15:28, Chris Wilson wrote: > > When under severe stress for GTT mappable space, the LRU eviction model > falls off a cliff. We spend all our time scanning the much large > non-mappable vma searching for something within the mappable zone we can > evict. Turn this on its head by only using the full vma if it is already > pinned in the mappable zone or there is sufficient *free* space to > accommodate it(prioritizing speedy reuse). If there is not, immediately > fall back to using small chunks (tilerow for GTT mmap, single pages for > pwrite/relocation) and using random eviction before doing a full search. > > Testcase: igt/gem_concurrent_blt > References: https://bugs.freedesktop.org/show_bug.cgi?id=110848 > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Only track bound elements of the GTT
On Tue, 20 Aug 2019 at 15:28, Chris Wilson wrote: > > The premise here is to simply avoiding having to acquire the vm->mutex > inside vma create/destroy to update the vm->unbound_lists, to avoid some > nasty lock recursions later. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/2] drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
When under severe stress for GTT mappable space, the LRU eviction model
falls off a cliff. We spend all our time scanning the much larger
non-mappable area searching for something within the mappable zone we can
evict. Turn this on its head by only using the full vma for the object if
it is already pinned in the mappable zone or there is sufficient *free*
space to accommodate it (prioritizing speedy reuse). If there is not,
immediately fall back to using small chunks (tilerow for GTT mmap, single
pages for pwrite/relocation) and using random eviction before doing a full
search.
Testcase: igt/gem_concurrent_blt
References: https://bugs.freedesktop.org/show_bug.cgi?id=110848
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 8
drivers/gpu/drm/i915/i915_gem.c| 8
drivers/gpu/drm/i915/i915_gem_evict.c | 8
drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-
drivers/gpu/drm/i915/i915_gem_gtt.h| 6 +++---
6 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f30258eebbd2..2dca2962c73a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1035,8 +1035,8 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONBLOCK |
- PIN_NONFAULT);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (IS_ERR(vma)) {
memset(&cache->node, 0, sizeof(cache->node));
err = drm_mm_insert_node_in_range
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 48c2cbe9b278..dba5dd779149 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -264,15 +264,15 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
/* Now pin it into the GTT as needed */
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONBLOCK |
- PIN_NONFAULT);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOSEARCH);
if (IS_ERR(vma)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
unsigned int flags;
- flags = PIN_MAPPABLE;
+ flags = PIN_MAPPABLE | PIN_NOSEARCH;
if (view.type == I915_GGTT_VIEW_NORMAL)
flags |= PIN_NONBLOCK; /* avoid warnings for pinned */
@@ -282,7 +282,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
*/
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
- if (IS_ERR(vma) && !view.type) {
+ if (IS_ERR(vma)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 22021da28239..68976689d569 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -345,8 +345,8 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONFAULT |
- PIN_NONBLOCK);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (!IS_ERR(vma)) {
node.start = i915_ggtt_offset(vma);
node.allocated = false;
@@ -559,8 +559,8 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONFAULT |
- PIN_NONBLOCK);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (!IS_ERR(vma)) {
node.start = i915_ggtt_offset(vma);
node.allocated = false;
diff --git a/dri
[Intel-gfx] [CI 2/2] drm/i915: Only track bound elements of the GTT
The premise here is to simply avoiding having to acquire the vm->mutex
inside vma create/destroy to update the vm->unbound_lists, to avoid some
nasty lock recursions later.
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_stolen.c| 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 23 ---
drivers/gpu/drm/i915/i915_gem_gtt.h | 5
drivers/gpu/drm/i915/i915_vma.c | 12 ++
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 +-
5 files changed, 8 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
index aa533b4ab5f5..2e1bfd5e4adf 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_stolen.c
@@ -689,7 +689,7 @@ i915_gem_object_create_stolen_for_preallocated(struct
drm_i915_private *dev_priv
__i915_vma_set_map_and_fenceable(vma);
mutex_lock(&ggtt->vm.mutex);
- list_move_tail(&vma->vm_link, &ggtt->vm.bound_list);
+ list_add_tail(&vma->vm_link, &ggtt->vm.bound_list);
mutex_unlock(&ggtt->vm.mutex);
GEM_BUG_ON(i915_gem_object_is_shrinkable(obj));
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b06d1d9054ba..9332d6387e74 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -498,19 +498,12 @@ static void i915_address_space_fini(struct
i915_address_space *vm)
static void ppgtt_destroy_vma(struct i915_address_space *vm)
{
- struct list_head *phases[] = {
- &vm->bound_list,
- &vm->unbound_list,
- NULL,
- }, **phase;
+ struct i915_vma *vma, *vn;
mutex_lock(&vm->i915->drm.struct_mutex);
- for (phase = phases; *phase; phase++) {
- struct i915_vma *vma, *vn;
-
- list_for_each_entry_safe(vma, vn, *phase, vm_link)
- i915_vma_destroy(vma);
- }
+ list_for_each_entry_safe(vma, vn, &vm->bound_list, vm_link)
+ i915_vma_destroy(vma);
+ GEM_BUG_ON(!list_empty(&vm->bound_list));
mutex_unlock(&vm->i915->drm.struct_mutex);
}
@@ -521,9 +514,6 @@ static void __i915_vm_release(struct work_struct *work)
ppgtt_destroy_vma(vm);
- GEM_BUG_ON(!list_empty(&vm->bound_list));
- GEM_BUG_ON(!list_empty(&vm->unbound_list));
-
vm->cleanup(vm);
i915_address_space_fini(vm);
@@ -562,7 +552,6 @@ static void i915_address_space_init(struct
i915_address_space *vm, int subclass)
stash_init(&vm->free_pages);
- INIT_LIST_HEAD(&vm->unbound_list);
INIT_LIST_HEAD(&vm->bound_list);
}
@@ -1883,10 +1872,6 @@ static struct i915_vma *pd_vma_create(struct gen6_ppgtt
*ppgtt, int size)
INIT_LIST_HEAD(&vma->obj_link);
INIT_LIST_HEAD(&vma->closed_link);
- mutex_lock(&vma->vm->mutex);
- list_add(&vma->vm_link, &vma->vm->unbound_list);
- mutex_unlock(&vma->vm->mutex);
-
return vma;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index b97a47fc7a68..61bbbfb964b1 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -320,11 +320,6 @@ struct i915_address_space {
*/
struct list_head bound_list;
- /**
-* List of vma that are not unbound.
-*/
- struct list_head unbound_list;
-
struct pagestash free_pages;
/* Global GTT */
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 79f9d1fb7611..0e6d3ef9a691 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -218,10 +218,6 @@ vma_create(struct drm_i915_gem_object *obj,
spin_unlock(&obj->vma.lock);
- mutex_lock(&vm->mutex);
- list_add(&vma->vm_link, &vm->unbound_list);
- mutex_unlock(&vm->mutex);
-
return vma;
err_vma:
@@ -659,7 +655,7 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64
alignment, u64 flags)
GEM_BUG_ON(!i915_gem_valid_gtt_space(vma, cache_level));
mutex_lock(&vma->vm->mutex);
- list_move_tail(&vma->vm_link, &vma->vm->bound_list);
+ list_add_tail(&vma->vm_link, &vma->vm->bound_list);
mutex_unlock(&vma->vm->mutex);
if (vma->obj) {
@@ -687,7 +683,7 @@ i915_vma_remove(struct i915_vma *vma)
mutex_lock(&vma->vm->mutex);
drm_mm_remove_node(&vma->node);
- list_move_tail(&vma->vm_link, &vma->vm->unbound_list);
+ list_del(&vma->vm_link);
mutex_unlock(&vma->vm->mutex);
/*
@@ -800,10 +796,6 @@ static void __i915_vma_destroy(struct i915_vma *vma)
GEM_BUG_ON(vma->node.allocated);
GEM_BUG_ON(vma->fence);
- mutex_lock(&vma->vm->mutex);
- list_del(&vma->vm_link);
- mutex_unlock(&vma->vm->mutex);
-
Re: [Intel-gfx] Linux Kernel 5.2.8 (uvc or i915?)
On Fri, 16 Aug 2019, Nathaniel Russell wrote: > Here is the file you requested with the debug information Please attach it to the bug you've hopefully created. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Nouveau] [PATCH v6 08/17] drm/ttm: use gem vma_node
On Wed, Aug 21, 2019 at 04:33:58PM +1000, Ben Skeggs wrote: > On Wed, 14 Aug 2019 at 20:14, Gerd Hoffmann wrote: > > > > Hi, > > > > > > Changing the order doesn't look hard. Patch attached (untested, have no > > > > test hardware). But maybe I missed some detail ... > > > > > > I came up with something very similar by splitting up nouveau_bo_new() > > > into allocation and initialization steps, so that when necessary the GEM > > > object can be initialized in between. I think that's slightly more > > > flexible and easier to understand than a boolean flag. > > > > Yes, that should work too. > > > > Acked-by: Gerd Hoffmann > Acked-by: Ben Skeggs Thanks guys, applied to drm-misc-next. Thierry signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: disable set/get_tiling ioctl on gen12+ (rev2)
== Series Details == Series: drm/i915: disable set/get_tiling ioctl on gen12+ (rev2) URL : https://patchwork.freedesktop.org/series/65495/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6750_full -> Patchwork_14110_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14110_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14110_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14110_full: ### IGT changes ### Possible regressions * igt@i915_selftest@live_gtt: - shard-glk: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-glk1/igt@i915_selftest@live_gtt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-glk5/igt@i915_selftest@live_gtt.html Known issues Here are the changes found in Patchwork_14110_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +4 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl9/igt@gem_soft...@noreloc-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-skl1/igt@gem_soft...@noreloc-s3.html * igt@kms_cursor_legacy@long-nonblocking-modeset-vs-cursor-atomic: - shard-skl: [PASS][9] -> [DMESG-WARN][10] ([fdo#105541]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl4/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-skl6/igt@kms_cursor_leg...@long-nonblocking-modeset-vs-cursor-atomic.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103166]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-y.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-iclb5/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109642] / [fdo#111068]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr2...@frontbuffer.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-iclb7/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][15] -> [SKIP][16] ([fdo#109441]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-iclb8/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl3/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-apl7/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][19] -> [SKIP][20] ([fdo#109271]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-kbl4/igt@perf_...@rc6.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-kbl7/igt@perf_...@rc6.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109276]) +24 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb4/igt@prime_b...@hang-bsd2.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14110/shard-iclb3/igt@prime_b...@hang-bsd2.html Possible fixes * igt@gem_eio@reset-stress: - shard-skl: [FAIL][23] ([fdo#109661]) -> [PASS][24] [23]: https://intel-gfx-ci.0
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
== Series Details ==
Series: series starting with [CI,1/2] drm/i915: Replace PIN_NONFAULT with calls
to PIN_NOEVICT
URL : https://patchwork.freedesktop.org/series/65537/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6753 -> Patchwork_14119
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14119 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14119, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14119:
### IGT changes ###
Possible regressions
* igt@i915_selftest@live_gem_contexts:
- fi-byt-j1900: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-byt-j1900/igt@i915_selftest@live_gem_contexts.html
- fi-ivb-3770:[PASS][3] -> [DMESG-WARN][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-ivb-3770/igt@i915_selftest@live_gem_contexts.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-ivb-3770/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-4770:[PASS][5] -> [DMESG-WARN][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-hsw-4770/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-hsw-peppy/igt@i915_selftest@live_gem_contexts.html
- fi-hsw-4770r: [PASS][9] -> [DMESG-WARN][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-hsw-4770r/igt@i915_selftest@live_gem_contexts.html
- fi-byt-n2820: [PASS][11] -> [DMESG-WARN][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-byt-n2820/igt@i915_selftest@live_gem_contexts.html
Known issues
Here are the changes found in Patchwork_14119 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][13] -> [INCOMPLETE][14] ([fdo#107718])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][15] -> [DMESG-WARN][16] ([fdo#102614])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_close_race@basic-process:
- fi-icl-u3: [DMESG-WARN][17] ([fdo#107724]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-icl-u3/igt@gem_close_r...@basic-process.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-icl-u3/igt@gem_close_r...@basic-process.html
* igt@gem_ctx_create@basic-files:
- {fi-icl-dsi}: [INCOMPLETE][19] ([fdo#107713] / [fdo#109100]) ->
[PASS][20]
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-icl-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@gem_mmap_gtt@basic-small-bo-tiledy:
- fi-ilk-650: [FAIL][21] ([fdo#108803]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-ilk-650/igt@gem_mmap_...@basic-small-bo-tiledy.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-ilk-650/igt@gem_mmap_...@basic-small-bo-tiledy.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [DMESG-FAIL][23] ([fdo#08]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6753/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14119/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_ch
[Intel-gfx] [CI] drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
When under severe stress for GTT mappable space, the LRU eviction model
falls off a cliff. We spend all our time scanning the much larger
non-mappable area searching for something within the mappable zone we can
evict. Turn this on its head by only using the full vma for the object if
it is already pinned in the mappable zone or there is sufficient *free*
space to accommodate it (prioritizing speedy reuse). If there is not,
immediately fall back to using small chunks (tilerow for GTT mmap, single
pages for pwrite/relocation) and using random eviction before doing a full
search.
Testcase: igt/gem_concurrent_blt
References: https://bugs.freedesktop.org/show_bug.cgi?id=110848
Signed-off-by: Chris Wilson
Reviewed-by: Matthew Auld
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 4 ++--
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 8
drivers/gpu/drm/i915/i915_gem.c| 8
drivers/gpu/drm/i915/i915_gem_evict.c | 8
drivers/gpu/drm/i915/i915_gem_gtt.c| 6 +-
drivers/gpu/drm/i915/i915_gem_gtt.h| 6 +++---
6 files changed, 18 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f30258eebbd2..2dca2962c73a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1035,8 +1035,8 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONBLOCK |
- PIN_NONFAULT);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (IS_ERR(vma)) {
memset(&cache->node, 0, sizeof(cache->node));
err = drm_mm_insert_node_in_range
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 48c2cbe9b278..dba5dd779149 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -264,15 +264,15 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
/* Now pin it into the GTT as needed */
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONBLOCK |
- PIN_NONFAULT);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOSEARCH);
if (IS_ERR(vma)) {
/* Use a partial view if it is bigger than available space */
struct i915_ggtt_view view =
compute_partial_view(obj, page_offset, MIN_CHUNK_PAGES);
unsigned int flags;
- flags = PIN_MAPPABLE;
+ flags = PIN_MAPPABLE | PIN_NOSEARCH;
if (view.type == I915_GGTT_VIEW_NORMAL)
flags |= PIN_NONBLOCK; /* avoid warnings for pinned */
@@ -282,7 +282,7 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
*/
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
- if (IS_ERR(vma) && !view.type) {
+ if (IS_ERR(vma)) {
flags = PIN_MAPPABLE;
view.type = I915_GGTT_VIEW_PARTIAL;
vma = i915_gem_object_ggtt_pin(obj, &view, 0, 0, flags);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 22021da28239..68976689d569 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -345,8 +345,8 @@ i915_gem_gtt_pread(struct drm_i915_gem_object *obj,
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONFAULT |
- PIN_NONBLOCK);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (!IS_ERR(vma)) {
node.start = i915_ggtt_offset(vma);
node.allocated = false;
@@ -559,8 +559,8 @@ i915_gem_gtt_pwrite_fast(struct drm_i915_gem_object *obj,
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
- PIN_NONFAULT |
- PIN_NONBLOCK);
+ PIN_NONBLOCK /* NOWARN */ |
+ PIN_NOEVICT);
if (!IS_ERR(vma)) {
node.start = i915_ggtt_offset(vma);
node.allocated = false;
diff --git a/dri
Re: [Intel-gfx] [PATCH v2 33/40] drm/i915/tgl/perf: use the same oa ctx_id format as icl
On 17/08/2019 11:38, Lucas De Marchi wrote:
From: Michel Thierry
Compared to Icelake, Tigerlake's MAX_CONTEXT_HW_ID is smaller by one, but
since we just use the upper 32 bits of the lrc_desc, it's guaranteed OA
will use the correct one.
Cc: Lionel Landwerlin
Signed-off-by: Michel Thierry
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_perf.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e42b86827d6b..2c9f46e12622 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1299,7 +1299,8 @@ static int oa_get_render_ctx_id(struct i915_perf_stream
*stream)
}
break;
- case 11: {
+ case 11:
+ case 12: {
stream->specific_ctx_id_mask =
((1U << GEN11_SW_CTX_ID_WIDTH) - 1) <<
(GEN11_SW_CTX_ID_SHIFT - 32) |
((1U << GEN11_ENGINE_INSTANCE_WIDTH) - 1) <<
(GEN11_ENGINE_INSTANCE_SHIFT - 32) |
This looks correct, I just have one question I don't remember the answer
to :
With GuC on Gen11+ we get the same value as when i915 builds up the
upper 32bits of the LRC descriptor using the hw_id?
Thanks,
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev3)
== Series Details ==
Series: drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT (rev3)
URL : https://patchwork.freedesktop.org/series/65222/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6754 -> Patchwork_14120
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/
Known issues
Here are the changes found in Patchwork_14120 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_basic@bad-close:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-icl-u3/igt@gem_ba...@bad-close.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-icl-u3/igt@gem_ba...@bad-close.html
* igt@i915_pm_rpm@module-reload:
- fi-skl-6770hq: [PASS][3] -> [FAIL][4] ([fdo#108511])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-skl-6770hq/igt@i915_pm_...@module-reload.html
* igt@i915_selftest@live_execlists:
- fi-skl-gvtdvm: [PASS][5] -> [DMESG-FAIL][6] ([fdo#08])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-skl-gvtdvm/igt@i915_selftest@live_execlists.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][7] -> [DMESG-WARN][8] ([fdo#102614])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@gem_sync@basic-store-each:
- fi-cfl-8109u: [INCOMPLETE][9] ([fdo#111427]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-cfl-8109u/igt@gem_s...@basic-store-each.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-cfl-8109u/igt@gem_s...@basic-store-each.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-icl-u3/igt@i915_module_l...@reload.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-icl-u3/igt@i915_module_l...@reload.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][13] ([fdo#111407]) -> [FAIL][14] ([fdo#111096])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#08]: https://bugs.freedesktop.org/show_bug.cgi?id=08
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111427]: https://bugs.freedesktop.org/show_bug.cgi?id=111427
Participating hosts (56 -> 46)
--
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-bxt-dsi fi-cml-s fi-hsw-4200u
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6754 -> Patchwork_14120
CI-20190529: 20190529
CI_DRM_6754: f4168ecba1e5c41cbf25d7b5db0c685ee7470d60 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5146: 357dbe1869d88a2f08bcee4eebceff4ee9014424 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14120: 0324887c7dc916cedcaf49e9496e79ec5427a8ea @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0324887c7dc9 drm/i915: Replace PIN_NONFAULT with calls to PIN_NOEVICT
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14120/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 0/2] drm/i915: timeline semaphore support
Hi all, Just a rebase and a change added then reversed that puts us right back to v3. Cheers, Lionel Landwerlin (2): drm/i915: introduce a mechanism to extend execbuf2 drm/i915: add syncobj timeline support .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 346 +++--- drivers/gpu/drm/i915/i915_drv.c | 3 +- drivers/gpu/drm/i915/i915_getparam.c | 1 + include/uapi/drm/i915_drm.h | 65 +++- 4 files changed, 354 insertions(+), 61 deletions(-) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 1/2] drm/i915: introduce a mechanism to extend execbuf2
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 ++-
include/uapi/drm/i915_drm.h | 26 +++--
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index f30258eebbd2..8d1946556bc0 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -25,6 +25,7 @@
#include "i915_gem_context.h"
#include "i915_gem_ioctls.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
enum {
FORCE_CPU_RELOC = 1,
@@ -271,6 +272,10 @@ struct i915_execbuffer {
*/
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
+
+ struct {
+ u64 flags; /** Available extensions parameters */
+ } extensions;
};
#define exec_entry(EB, VMA) (&(EB)->exec[(VMA)->exec_flags - (EB)->flags])
@@ -1915,7 +1920,8 @@ static bool i915_gem_check_execbuffer(struct
drm_i915_gem_execbuffer2 *exec)
return false;
/* Kernel clipping was a DRI1 misfeature */
- if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+ if (!(exec->flags & (I915_EXEC_FENCE_ARRAY |
+I915_EXEC_USE_EXTENSIONS))) {
if (exec->num_cliprects || exec->cliprects_ptr)
return false;
}
@@ -2417,6 +2423,33 @@ signal_fence_array(struct i915_execbuffer *eb,
}
}
+static const i915_user_extension_fn execbuf_extensions[] = {
+};
+
+static int
+parse_execbuf2_extensions(struct drm_i915_gem_execbuffer2 *args,
+ struct i915_execbuffer *eb)
+{
+ eb->extensions.flags = 0;
+
+ if (!(args->flags & I915_EXEC_USE_EXTENSIONS))
+ return 0;
+
+ /* The execbuf2 extension mechanism reuses cliprects_ptr. So we cannot
+* have another flag also using it at the same time.
+*/
+ if (eb->args->flags & I915_EXEC_FENCE_ARRAY)
+ return -EINVAL;
+
+ if (args->num_cliprects != 0)
+ return -EINVAL;
+
+ return i915_user_extensions(u64_to_user_ptr(args->cliprects_ptr),
+ execbuf_extensions,
+ ARRAY_SIZE(execbuf_extensions),
+ eb);
+}
+
static int
i915_gem_do_execbuffer(struct drm_device *dev,
struct drm_file *file,
@@ -2463,6 +2496,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_IS_PINNED)
eb.batch_flags |= I915_DISPATCH_PINNED;
+ err = parse_execbuf2_extensions(args, &eb);
+ if (err)
+ return err;
+
if (args->flags & I915_EXEC_FENCE_IN) {
in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
if (!in_fence)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 469dc512cca3..0a99c26730e1 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1007,6 +1007,10 @@ struct drm_i915_gem_exec_fence {
__u32 flags;
};
+enum drm_i915_gem_execbuffer_ext {
+ DRM_I915_GEM_EXECBUFFER_EXT_MAX /* non-ABI */
+};
+
struct drm_i915_gem_execbuffer2 {
/**
* List of gem_exec_object2 structs
@@ -1023,8 +1027,15 @@ struct drm_i915_gem_execbuffer2 {
__u32 num_cliprects;
/**
* This is a struct drm_clip_rect *cliprects if I915_EXEC_FENCE_ARRAY
-* is not set. If I915_EXEC_FENCE_ARRAY is set, then this is a
-* struct drm_i915_gem_exec_fence *fences.
+* & I915_EXEC_USE_EXTENSIONS are not set.
+*
+* If I915_EXEC_FENCE_ARRAY is set, then this is a pointer to an array
+* of struct drm_i915_gem_exec_fence and num_cliprects is the length
+* of the array.
+*
+* If I915_EXEC_USE_EXTENSIONS is set, then this is a pointer to a
+* single struct drm_i915_gem_base_execbuffer_ext and num_cliprects is
+* 0.
*/
__u64 cliprects_ptr;
#define I915_EXEC_RING_MASK (0x3f)
@@ -1142,7 +1153,16 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_FENCE_SUBMIT (1 << 20)
-#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SUBMIT << 1))
+/*
+ * Setting I915_EXEC_USE_EXTENSIONS implies that
+ * drm_i915_gem_execbuffer2.cliprects_ptr is treated as a pointer to an linked
+ * list of i915_user_extension. Each i915_user_extension node is the base of a
+ * larger structure. The list of supported structures are listed in the
+ * drm_i915_gem_execbuffer_ext enum.
+ */
+#defi
[Intel-gfx] [PATCH v4 2/2] drm/i915: add syncobj timeline support
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
Signed-off-by: Lionel Landwerlin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 307 ++
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 39 +++
4 files changed, 293 insertions(+), 57 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 8d1946556bc0..6d5a234f9f9b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -214,6 +214,13 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
+struct i915_eb_fences {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -275,6 +282,7 @@ struct i915_execbuffer {
struct {
u64 flags; /** Available extensions parameters */
+ struct drm_i915_gem_execbuffer_ext_timeline_fences
timeline_fences;
} extensions;
};
@@ -2295,67 +2303,217 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
{
- while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ while (n--) {
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ dma_fence_put(fences[n].dma_fence);
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
-static struct drm_syncobj **
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+static struct i915_eb_fences *
+get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
{
- const unsigned long nfences = args->num_cliprects;
+ struct drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences =
+ &eb->extensions.timeline_fences;
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fences *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return ERR_PTR(-EINVAL);
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return ERR_PTR(-EFAULT);
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return ERR_PTR(-EFAULT);
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return ERR_PTR(-ENOMEM);
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence user_fence;
+ struct drm_syncobj *syncobj;
+ struct dma_fence *fence = NULL;
+ u64 point;
+
+ if (__copy_from_user(&user_fence, user_fences++,
sizeof(user_fence))) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ if (user_fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+ err = -EINVAL;
+ goto err;
+ }
+
+ if (__get_user(point, user_values++)) {
+ err = -EFAULT;
+ goto err;
+ }
+
+
Re: [Intel-gfx] [PATCH v2 16/40] drm/i915: Add for_each_new_intel_connector_in_state()
On Sat, 2019-08-17 at 02:38 -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> The same macro as for_each_new_connector_in_state() but it uses
> intel/i915 types instead of the drm ones.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Mika Kahola
> ---
> drivers/gpu/drm/i915/display/intel_display.h | 8
> 1 file changed, 8 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> b/drivers/gpu/drm/i915/display/intel_display.h
> index e57e6969051d..fd3043e77b50 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.h
> +++ b/drivers/gpu/drm/i915/display/intel_display.h
> @@ -411,6 +411,14 @@ enum phy_fia {
>(__i)++) \
> for_each_if(crtc)
>
> +#define for_each_new_intel_connector_in_state(__state, connector,
> new_connector_state, __i) \
> + for ((__i) = 0; \
> + (__i) < (__state)->base.num_connector; \
> + (__i)++) \
> + for_each_if ((__state)->base.connectors[__i].ptr && \
> + ((connector) =
> to_intel_connector((__state)->base.connectors[__i].ptr), \
> + (new_connector_state) =
> to_intel_digital_connector_state((__state)-
> >base.connectors[__i].new_state), 1))
> +
> void intel_link_compute_m_n(u16 bpp, int nlanes,
> int pixel_clock, int link_clock,
> struct intel_link_m_n *m_n,
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v8,1/3] drm/i915/psr: Make PSR registers relative to transcoders
== Series Details == Series: series starting with [v8,1/3] drm/i915/psr: Make PSR registers relative to transcoders URL : https://patchwork.freedesktop.org/series/65507/ State : success == Summary == CI Bug Log - changes from CI_DRM_6750_full -> Patchwork_14112_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14112_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_pm_rpm@basic-pci-d3-state: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl1/igt@i915_pm_...@basic-pci-d3-state.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-apl2/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][9] -> [FAIL][10] ([fdo#105767]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-hsw7/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-hsw8/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#105363]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-skl8/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_frontbuffer_tracking@fbc-1p-rte: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167] / [fdo#110378]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-rte.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-rte.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl5/igt@kms_frontbuffer_track...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-skl8/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14112/shard-skl7/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr2
Re: [Intel-gfx] [PATCH v2 17/40] drm: Add for_each_oldnew_intel_crtc_in_state_reverse()
On Wed, 2019-08-21 at 11:22 +, Kahola, Mika wrote:
> On Sat, 2019-08-17 at 02:38 -0700, Lucas De Marchi wrote:
> > From: José Roberto de Souza
> >
> > Same as for_each_oldnew_intel_crtc_in_state() but iterates in
> > reverse
> > order.
> >
> > v2: Fix additional blank line
> >
> > Cc: Rodrigo Vivi
> > Cc: Ville Syrjälä
> > Signed-off-by: José Roberto de Souza
> > Signed-off-by: Lucas De Marchi
> > ---
> > drivers/gpu/drm/i915/display/intel_display.h | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.h
> > b/drivers/gpu/drm/i915/display/intel_display.h
> > index fd3043e77b50..b63fb7a4599e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.h
> > +++ b/drivers/gpu/drm/i915/display/intel_display.h
> > @@ -419,6 +419,15 @@ enum phy_fia {
> > ((connector) =
> > to_intel_connector((__state)->base.connectors[__i].ptr), \
> > (new_connector_state) =
> > to_intel_digital_connector_state((__state)-
> > > base.connectors[__i].new_state), 1))
> >
> >
> > +#define for_each_oldnew_intel_crtc_in_state_reverse(__state, crtc,
> > old_crtc_state, new_crtc_state, __i) \
> > + for ((__i) = (__state)->base.dev->mode_config.num_crtc - 1; \
>
> Maybe aligning these two 'for' loops on top of each other similarly
> to
> to other. Now, it seems the lower one is off by one.
Please forget this comment. The patch DOES align cleanly.
>
> Otherwise, this is
>
> Reviewed-by: Mika Kahola
>
> > +(__i) >= 0 && \
> > +((crtc) = to_intel_crtc((__state)->base.crtcs[__i].ptr), \
> > + (old_crtc_state) = to_intel_crtc_state((__state)-
> > > base.crtcs[__i].old_state), \
> >
> > + (new_crtc_state) = to_intel_crtc_state((__state)-
> > > base.crtcs[__i].new_state), 1); \
> >
> > +(__i)--) \
> > + for_each_if(crtc)
> > +
> > void intel_link_compute_m_n(u16 bpp, int nlanes,
> > int pixel_clock, int link_clock,
> > struct intel_link_m_n *m_n,
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/10] drm/i915/dp: Fix dsc bpp calculations.
There was a integer wraparound when mode_clock became too high,
and we didn't correct for the FEC overhead factor when dividing,
also the calculations would break at HBR3.
As a result our calculated bpp was way too high, and the link width
bpp limitation never came into effect.
Print out the resulting bpp calcululations as a sanity check, just
in case we ever have to debug it later on again.
Signed-off-by: Maarten Lankhorst
Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice
Count for DSC")
Cc: # v5.0+
Cc: Manasi Navare
---
drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
drivers/gpu/drm/i915/display/intel_dp.h | 4 ++--
2 files changed, 11 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 921ad0a2f7ba..614a25911f07 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4323,10 +4323,10 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp, u8
*sink_irq_vector)
DP_DPRX_ESI_LEN;
}
-u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count,
- int mode_clock, int mode_hdisplay)
+u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u8 lane_count,
+ u32 mode_clock, u32 mode_hdisplay)
{
- u16 bits_per_pixel, max_bpp_small_joiner_ram;
+ u32 bits_per_pixel, max_bpp_small_joiner_ram;
int i;
/*
@@ -4335,13 +4335,14 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8
lane_count,
* FECOverhead = 2.4%, for SST -> TimeSlotsPerMTP is 1,
* for MST -> TimeSlotsPerMTP has to be calculated
*/
- bits_per_pixel = (link_clock * lane_count * 8 *
- DP_DSC_FEC_OVERHEAD_FACTOR) /
- mode_clock;
+ bits_per_pixel = div_u64((u64)link_clock * lane_count * 8 *
+DP_DSC_FEC_OVERHEAD_FACTOR, 1000ULL *
mode_clock);
+ DRM_DEBUG_KMS("Max link bpp: %u\n", bits_per_pixel);
/* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
max_bpp_small_joiner_ram = DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER /
mode_hdisplay;
+ DRM_DEBUG_KMS("Max small joiner bpp: %u\n", max_bpp_small_joiner_ram);
/*
* Greatest allowed DSC BPP = MIN (output BPP from avaialble Link BW
@@ -4351,7 +4352,8 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8
lane_count,
/* Error out if the max bpp is less than smallest allowed valid bpp */
if (bits_per_pixel < valid_dsc_bpp[0]) {
- DRM_DEBUG_KMS("Unsupported BPP %d\n", bits_per_pixel);
+ DRM_DEBUG_KMS("Unsupported BPP %u, min %u\n",
+ bits_per_pixel, valid_dsc_bpp[0]);
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
b/drivers/gpu/drm/i915/display/intel_dp.h
index 657bbb1f5ed0..007d1981a33b 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.h
+++ b/drivers/gpu/drm/i915/display/intel_dp.h
@@ -102,8 +102,8 @@ bool intel_dp_source_supports_hbr2(struct intel_dp
*intel_dp);
bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
bool
intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
-u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count,
- int mode_clock, int mode_hdisplay);
+u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u8 lane_count,
+ u32 mode_clock, u32 mode_hdisplay);
u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, int mode_clock,
int mode_hdisplay);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/10] drm/i915: Handle a few more cases for hw/sw split
We are still looking at drm_crtc_state in a few places, convert those
to use intel_crtc_state instead. Look at uapi/hw where appropriate.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 22 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 2 +-
drivers/gpu/drm/i915/display/intel_psr.c | 4 ++--
3 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c6d7e32ae70a..31be767bca32 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11754,10 +11754,10 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
bool mode_changed = needs_modeset(pipe_config);
if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv) &&
- mode_changed && !crtc_state->active)
+ mode_changed && !pipe_config->hw.active)
pipe_config->update_wm_post = true;
- if (mode_changed && crtc_state->enable &&
+ if (mode_changed && pipe_config->hw.enable &&
dev_priv->display.crtc_compute_clock &&
!WARN_ON(pipe_config->shared_dpll)) {
ret = dev_priv->display.crtc_compute_clock(intel_crtc,
@@ -11771,10 +11771,10 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
* when C8 planes are getting enabled/disabled.
*/
if (c8_planes_changed(pipe_config))
- crtc_state->color_mgmt_changed = true;
+ pipe_config->uapi.color_mgmt_changed = true;
if (mode_changed || pipe_config->update_pipe ||
- crtc_state->color_mgmt_changed) {
+ pipe_config->uapi.color_mgmt_changed) {
ret = intel_color_check(pipe_config);
if (ret)
return ret;
@@ -16051,8 +16051,8 @@ static int intel_initial_commit(struct drm_device *dev)
{
struct drm_atomic_state *state = NULL;
struct drm_modeset_acquire_ctx ctx;
- struct drm_crtc *crtc;
- struct drm_crtc_state *crtc_state;
+ struct intel_crtc *crtc;
+ struct intel_crtc_state *crtc_state;
int ret = 0;
state = drm_atomic_state_alloc(dev);
@@ -16064,15 +16064,15 @@ static int intel_initial_commit(struct drm_device
*dev)
retry:
state->acquire_ctx = &ctx;
- drm_for_each_crtc(crtc, dev) {
- crtc_state = drm_atomic_get_crtc_state(state, crtc);
+ for_each_intel_crtc(dev, crtc) {
+ crtc_state = intel_atomic_get_crtc_state(state, crtc);
if (IS_ERR(crtc_state)) {
ret = PTR_ERR(crtc_state);
goto out;
}
- if (crtc_state->active) {
- ret = drm_atomic_add_affected_planes(state, crtc);
+ if (crtc_state->hw.active) {
+ ret = drm_atomic_add_affected_planes(state,
&crtc->base);
if (ret)
goto out;
@@ -16082,7 +16082,7 @@ static int intel_initial_commit(struct drm_device *dev)
* having a proper LUT loaded. Remove once we
* have readout for pipe gamma enable.
*/
- crtc_state->color_mgmt_changed = true;
+ crtc_state->uapi.color_mgmt_changed = true;
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 50c480a3e663..78496d047086 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -179,7 +179,7 @@ intel_dp_mst_atomic_check(struct drm_connector *connector,
if (!crtc_state ||
!drm_atomic_crtc_needs_modeset(crtc_state) ||
- crtc_state->enable)
+ to_intel_crtc_state(crtc_state)->hw.enable)
return 0;
}
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index 3207f48ffd54..bc775b1cf4cf 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -1025,9 +1025,9 @@ static int intel_psr_fastset_force(struct
drm_i915_private *dev_priv)
intel_crtc_state = to_intel_crtc_state(crtc_state);
- if (crtc_state->active && intel_crtc_state->has_psr) {
+ if (intel_crtc_state->hw.active && intel_crtc_state->has_psr) {
/* Mark mode as changed to trigger a pipe->update() */
- crtc_state->mode_changed = true;
+ intel_crtc_state->uapi.mode_changed = true;
break;
}
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http
[Intel-gfx] [PATCH 00/10] drm/i915: Bigjoiner preparations.
Some of the patches that support the big joiner configuration, without actually enabling anything bigjoiner specific yet. Big Joiner requires us to enable an additional pipe, which drives the same port. The master pipe drives the left half of the display, the slave the right half. This is handled by splitting crtc_state into a uapi and hw state. The uapi state is the state from drm, while the hw state contains the actual state of the hardware. Maarten Lankhorst (10): drm/i915/dp: Fix dsc bpp calculations. drm/i915: Prepare to split crtc state in uapi and hw state drm/i915: Handle a few more cases for hw/sw split drm/i915: Complete sw/hw split drm/i915: Kill off is_planar_yuv_format drm/i915: Get rid of crtc_state->fb_changed drm/i915: Remove begin/finish_crtc_commit. drm/i915: Do not add all planes when checking scalers on glk+ drm/i915: Add debugfs entries for reading out DPCD DSC and FEC. drm/i915: Move FEC enable timeout wait to enable_ddi_dp drivers/gpu/drm/i915/display/icl_dsi.c| 18 +- drivers/gpu/drm/i915/display/intel_atomic.c | 66 +- drivers/gpu/drm/i915/display/intel_atomic.h | 2 + .../gpu/drm/i915/display/intel_atomic_plane.c | 8 +- drivers/gpu/drm/i915/display/intel_audio.c| 12 +- drivers/gpu/drm/i915/display/intel_bw.c | 4 +- drivers/gpu/drm/i915/display/intel_cdclk.c| 8 +- drivers/gpu/drm/i915/display/intel_color.c| 150 ++-- drivers/gpu/drm/i915/display/intel_crt.c | 24 +- drivers/gpu/drm/i915/display/intel_ddi.c | 39 +- drivers/gpu/drm/i915/display/intel_display.c | 724 +- drivers/gpu/drm/i915/display/intel_display.h | 4 +- .../drm/i915/display/intel_display_types.h| 31 +- drivers/gpu/drm/i915/display/intel_dp.c | 58 +- drivers/gpu/drm/i915/display/intel_dp.h | 4 +- drivers/gpu/drm/i915/display/intel_dp_mst.c | 8 +- drivers/gpu/drm/i915/display/intel_dpio_phy.c | 14 +- drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 20 +- drivers/gpu/drm/i915/display/intel_dvo.c | 14 +- drivers/gpu/drm/i915/display/intel_fbc.c | 2 +- drivers/gpu/drm/i915/display/intel_hdmi.c | 62 +- drivers/gpu/drm/i915/display/intel_lspcon.c | 4 +- drivers/gpu/drm/i915/display/intel_lvds.c | 12 +- drivers/gpu/drm/i915/display/intel_panel.c| 14 +- drivers/gpu/drm/i915/display/intel_pipe_crc.c | 6 +- drivers/gpu/drm/i915/display/intel_psr.c | 14 +- drivers/gpu/drm/i915/display/intel_sdvo.c | 22 +- drivers/gpu/drm/i915/display/intel_sprite.c | 44 +- drivers/gpu/drm/i915/display/intel_sprite.h | 1 - drivers/gpu/drm/i915/display/intel_tv.c | 8 +- drivers/gpu/drm/i915/display/intel_vdsc.c | 12 +- drivers/gpu/drm/i915/display/vlv_dsi.c| 20 +- drivers/gpu/drm/i915/i915_debugfs.c | 16 +- drivers/gpu/drm/i915/intel_pm.c | 192 +++-- 34 files changed, 858 insertions(+), 779 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/10] drm/i915: Get rid of crtc_state->fb_changed
We had this as an optimization to not do a plane update, but we killed
it off because there are so many reasons we may have to do a plane
update or fastset that it's best to just assume everything changed.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c| 1 -
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/display/intel_display_types.h | 1 -
3 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 094f3f5917e0..d267dd39475d 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -208,7 +208,6 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
crtc_state->disable_cxsr = false;
crtc_state->update_wm_pre = false;
crtc_state->update_wm_post = false;
- crtc_state->fb_changed = false;
crtc_state->fifo_changed = false;
crtc_state->wm.need_postvbl_update = false;
crtc_state->fb_bits = 0;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index fa77212d937d..b87bfc0706d6 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11491,7 +11491,6 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
bool was_crtc_enabled = old_crtc_state->hw.active;
bool is_crtc_enabled = crtc_state->hw.active;
bool turn_off, turn_on, visible, was_visible;
- struct drm_framebuffer *fb = plane_state->base.fb;
int ret;
if (INTEL_GEN(dev_priv) >= 9 && plane->id != PLANE_CURSOR) {
@@ -11525,18 +11524,11 @@ int intel_plane_atomic_calc_changes(const struct
intel_crtc_state *old_crtc_stat
if (!was_visible && !visible)
return 0;
- if (fb != old_plane_state->base.fb)
- crtc_state->fb_changed = true;
-
turn_off = was_visible && (!visible || mode_changed);
turn_on = visible && (!was_visible || mode_changed);
- DRM_DEBUG_ATOMIC("[CRTC:%d:%s] has [PLANE:%d:%s] with fb %i\n",
+ DRM_DEBUG_ATOMIC("[CRTC:%d:%s] with [PLANE:%d:%s] visible %i -> %i, off
%i, on %i, ms %i\n",
crtc->base.base.id, crtc->base.name,
-plane->base.base.id, plane->base.name,
-fb ? fb->base.id : -1);
-
- DRM_DEBUG_ATOMIC("[PLANE:%d:%s] visible %i -> %i, off %i, on %i, ms
%i\n",
plane->base.base.id, plane->base.name,
was_visible, visible,
turn_off, turn_on, mode_changed);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 71f73d5bfa91..bc2e792c2049 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -785,7 +785,6 @@ struct intel_crtc_state {
bool update_pipe; /* can a fast modeset be performed? */
bool disable_cxsr;
bool update_wm_pre, update_wm_post; /* watermarks are updated */
- bool fb_changed; /* fb on any of the planes is changed */
bool fifo_changed; /* FIFO split is changed */
/* Pipe source size (ie. panel fitter input size)
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/10] drm/i915: Kill off is_planar_yuv_format
Instead of relying on the fourcc, use the drm fourcc helper
drm_format_info_is_yuv_semiplanar().
Signed-off-by: Maarten Lankhorst
---
.../gpu/drm/i915/display/intel_atomic_plane.c | 2 +-
drivers/gpu/drm/i915/display/intel_display.c | 10 +-
drivers/gpu/drm/i915/display/intel_display.h | 4 +++-
drivers/gpu/drm/i915/display/intel_sprite.c | 19 +++
drivers/gpu/drm/i915/display/intel_sprite.h | 1 -
drivers/gpu/drm/i915/intel_pm.c | 12 +---
6 files changed, 17 insertions(+), 31 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
index 68bfb467f195..eb785f142651 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
@@ -164,7 +164,7 @@ int intel_plane_atomic_check_with_state(const struct
intel_crtc_state *old_crtc_
new_crtc_state->active_planes |= BIT(plane->id);
if (new_plane_state->base.visible &&
- is_planar_yuv_format(new_plane_state->base.fb->format->format))
+ drm_format_info_is_yuv_semiplanar(new_plane_state->base.fb->format))
new_crtc_state->nv12_planes |= BIT(plane->id);
if (new_plane_state->base.visible &&
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f504b6f3c5f4..fa77212d937d 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3529,7 +3529,7 @@ int skl_check_plane_surface(struct intel_plane_state
*plane_state)
* Handle the AUX surface first since
* the main surface setup depends on it.
*/
- if (is_planar_yuv_format(fb->format->format)) {
+ if (drm_format_info_is_yuv_semiplanar(fb->format)) {
ret = skl_check_nv12_aux_surface(plane_state);
if (ret)
return ret;
@@ -5447,7 +5447,7 @@ skl_update_scaler(struct intel_crtc_state *crtc_state,
bool force_detach,
return 0;
}
- if (format && is_planar_yuv_format(format->format) &&
+ if (format && drm_format_info_is_yuv_semiplanar(format) &&
(src_h < SKL_MIN_YUV_420_SRC_H || src_w < SKL_MIN_YUV_420_SRC_W)) {
DRM_DEBUG_KMS("Planar YUV: src dimensions not met\n");
return -EINVAL;
@@ -5524,7 +5524,7 @@ static int skl_update_scaler_plane(struct
intel_crtc_state *crtc_state,
/* Pre-gen11 and SDR planes always need a scaler for planar formats. */
if (!icl_is_hdr_plane(dev_priv, intel_plane->id) &&
- fb && is_planar_yuv_format(fb->format->format))
+ fb && drm_format_info_is_yuv_semiplanar(fb->format))
need_scaler = true;
ret = skl_update_scaler(crtc_state, force_detach,
@@ -14500,7 +14500,7 @@ intel_cleanup_plane_fb(struct drm_plane *plane,
int
skl_max_scale(const struct intel_crtc_state *crtc_state,
- u32 pixel_format)
+ const struct drm_format_info *pixel_format)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->uapi.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
@@ -14525,7 +14525,7 @@ skl_max_scale(const struct intel_crtc_state *crtc_state,
*or
*cdclk/crtc_clock
*/
- mult = is_planar_yuv_format(pixel_format) ? 2 : 3;
+ mult = drm_format_info_is_yuv_semiplanar(pixel_format) ? 2 : 3;
tmpclk1 = (1 << 16) * mult - 1;
tmpclk2 = (1 << 8) * ((max_dotclk << 8) / crtc_clock);
max_scale = min(tmpclk1, tmpclk2);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index e57e6969051d..3e3a3bca13f5 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -34,6 +34,7 @@ struct drm_connector;
struct drm_device;
struct drm_encoder;
struct drm_file;
+struct drm_format_info;
struct drm_framebuffer;
struct drm_i915_error_state_buf;
struct drm_i915_gem_object;
@@ -521,7 +522,8 @@ void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
u16 skl_scaler_calc_phase(int sub, int scale, bool chroma_center);
int skl_update_scaler_crtc(struct intel_crtc_state *crtc_state);
int skl_max_scale(const struct intel_crtc_state *crtc_state,
- u32 pixel_format);
+ const struct drm_format_info *format);
+
u32 glk_plane_color_ctl(const struct intel_crtc_state *crtc_state,
const struct intel_plane_state *plane_state);
u32 glk_plane_color_ctl_crtc(const struct intel_crtc_state *crtc_state);
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 242fafd132cc..72e18435bb36 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -48,19 +48,6 @@
[Intel-gfx] [PATCH 08/10] drm/i915: Do not add all planes when checking scalers on glk+
We cannot switch between HQ and normal mode on GLK+, so only
add planes on platforms where it makes sense.
We could probably restrict it even more to only add when scaler
users toggles between 1 and 2, but lets just leave it for now.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index d267dd39475d..c442e9762ce7 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -418,6 +418,11 @@ int intel_atomic_setup_scalers(struct drm_i915_private
*dev_priv,
*/
if (!plane) {
struct drm_plane_state *state;
+
+ /* No need to reprogram, we're not changing
scaling mode */
+ if (INTEL_GEN(dev_priv) >= 10 ||
IS_GEMINILAKE(dev_priv))
+ continue;
+
plane = drm_plane_from_index(&dev_priv->drm, i);
state = drm_atomic_get_plane_state(drm_state,
plane);
if (IS_ERR(state)) {
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/10] drm/i915: Complete sw/hw split
Now that we separated everything into uapi and hw, it's
time to make the split definitive. Remove the union and
make a copy of the hw state on modeset and fastset.
Color blobs are copied in crtc atomic_check(), right
before color management is checked.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_atomic.c | 44 +++
drivers/gpu/drm/i915/display/intel_atomic.h | 2 +
drivers/gpu/drm/i915/display/intel_display.c | 39 +---
.../drm/i915/display/intel_display_types.h| 8 ++--
4 files changed, 85 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
b/drivers/gpu/drm/i915/display/intel_atomic.c
index 53152f754785..094f3f5917e0 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.c
+++ b/drivers/gpu/drm/i915/display/intel_atomic.c
@@ -195,6 +195,14 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
__drm_atomic_helper_crtc_duplicate_state(crtc, &crtc_state->uapi);
+ /* copy color blobs */
+ if (crtc_state->hw.degamma_lut)
+ drm_property_blob_get(crtc_state->hw.degamma_lut);
+ if (crtc_state->hw.ctm)
+ drm_property_blob_get(crtc_state->hw.ctm);
+ if (crtc_state->hw.gamma_lut)
+ drm_property_blob_get(crtc_state->hw.gamma_lut);
+
crtc_state->update_pipe = false;
crtc_state->disable_lp_wm = false;
crtc_state->disable_cxsr = false;
@@ -209,6 +217,41 @@ intel_crtc_duplicate_state(struct drm_crtc *crtc)
return &crtc_state->uapi;
}
+static void intel_crtc_put_color_blobs(struct intel_crtc_state *crtc_state)
+{
+ drm_property_blob_put(crtc_state->hw.degamma_lut);
+ drm_property_blob_put(crtc_state->hw.gamma_lut);
+ drm_property_blob_put(crtc_state->hw.ctm);
+}
+
+void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state)
+{
+ intel_crtc_put_color_blobs(crtc_state);
+}
+
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state)
+{
+ intel_crtc_put_color_blobs(crtc_state);
+
+ if (crtc_state->uapi.degamma_lut)
+ crtc_state->hw.degamma_lut =
+ drm_property_blob_get(crtc_state->uapi.degamma_lut);
+ else
+ crtc_state->hw.degamma_lut = NULL;
+
+ if (crtc_state->uapi.gamma_lut)
+ crtc_state->hw.gamma_lut =
+ drm_property_blob_get(crtc_state->uapi.gamma_lut);
+ else
+ crtc_state->hw.gamma_lut = NULL;
+
+ if (crtc_state->uapi.ctm)
+ crtc_state->hw.ctm =
+ drm_property_blob_get(crtc_state->uapi.ctm);
+ else
+ crtc_state->hw.ctm = NULL;
+}
+
/**
* intel_crtc_destroy_state - destroy crtc state
* @crtc: drm crtc
@@ -224,6 +267,7 @@ intel_crtc_destroy_state(struct drm_crtc *crtc,
struct intel_crtc_state *crtc_state = to_intel_crtc_state(state);
__drm_atomic_helper_crtc_destroy_state(&crtc_state->uapi);
+ intel_crtc_free_hw_state(crtc_state);
kfree(crtc_state);
}
diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
b/drivers/gpu/drm/i915/display/intel_atomic.h
index 58065d3161a3..42be91e0772a 100644
--- a/drivers/gpu/drm/i915/display/intel_atomic.h
+++ b/drivers/gpu/drm/i915/display/intel_atomic.h
@@ -35,6 +35,8 @@ intel_digital_connector_duplicate_state(struct drm_connector
*connector);
struct drm_crtc_state *intel_crtc_duplicate_state(struct drm_crtc *crtc);
void intel_crtc_destroy_state(struct drm_crtc *crtc,
struct drm_crtc_state *state);
+void intel_crtc_free_hw_state(struct intel_crtc_state *crtc_state);
+void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state);
struct drm_atomic_state *intel_atomic_state_alloc(struct drm_device *dev);
void intel_atomic_state_clear(struct drm_atomic_state *state);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 31be767bca32..f504b6f3c5f4 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -114,6 +114,7 @@ static const u64 cursor_format_modifiers[] = {
DRM_FORMAT_MOD_INVALID
};
+static void copy_uapi_to_hw_state(struct intel_crtc_state *crtc_state);
static void i9xx_crtc_clock_get(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
static void ironlake_pch_clock_get(struct intel_crtc *crtc,
@@ -7067,6 +7068,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc
*crtc,
crtc->enabled = false;
crtc->state->connector_mask = 0;
crtc->state->encoder_mask = 0;
+ copy_uapi_to_hw_state(to_intel_crtc_state(crtc->state));
for_each_encoder_on_crtc(crtc->dev, crtc, encoder)
encoder->base.crtc = NULL;
@@ -11775,6 +11777,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*crtc,
if (mode_changed || pipe_config->upd
[Intel-gfx] [PATCH 10/10] drm/i915: Move FEC enable timeout wait to enable_ddi_dp
Even without bigjoiner I get a timeout when enabling FEC, the length of the
timeout
doesn't matter, still happens with 10s timeout.
It seems that DP-MST waits for ACT in enable_dp() so we
could postpone it in normal bringup in a similar way, just to be sure.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_ddi.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index 81205b75da78..a88348464ffd 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3138,10 +3138,6 @@ static void intel_ddi_enable_fec(struct intel_encoder
*encoder,
val = I915_READ(DP_TP_CTL(port));
val |= DP_TP_CTL_FEC_ENABLE;
I915_WRITE(DP_TP_CTL(port), val);
-
- if (intel_de_wait_for_set(dev_priv, DP_TP_STATUS(port),
- DP_TP_STATUS_FEC_ENABLE_LIVE, 1))
- DRM_ERROR("Timed out waiting for FEC Enable Status\n");
}
static void intel_ddi_disable_fec_state(struct intel_encoder *encoder,
@@ -3473,6 +3469,11 @@ static void intel_enable_ddi_dp(struct intel_encoder
*encoder,
if (port == PORT_A && INTEL_GEN(dev_priv) < 9)
intel_dp_stop_link_train(intel_dp);
+ if (crtc_state->fec_enable &&
+ intel_de_wait_for_set(dev_priv, DP_TP_STATUS(port),
+ DP_TP_STATUS_FEC_ENABLE_LIVE, 1))
+ DRM_ERROR("Timed out waiting for FEC Enable Status\n");
+
intel_edp_backlight_on(crtc_state, conn_state);
intel_psr_enable(intel_dp, crtc_state);
intel_dp_ycbcr_420_enable(intel_dp, crtc_state);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/10] drm/i915: Remove begin/finish_crtc_commit.
This can all be done from the intel_update_crtc function. Split out the
pipe update into a separate function, just like is done for the planes.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 124 ---
1 file changed, 52 insertions(+), 72 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b87bfc0706d6..c2624b5f4f05 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
-static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
intel_crtc *);
-static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
intel_crtc *);
static void intel_crtc_init_scalers(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state);
static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
@@ -13725,13 +13723,54 @@ u32 intel_crtc_get_vblank_counter(struct intel_crtc
*crtc)
return crtc->base.funcs->get_vblank_counter(&crtc->base);
}
+void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (!IS_GEN(dev_priv, 2))
+ intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
true);
+
+ if (crtc_state->has_pch_encoder) {
+ enum pipe pch_transcoder =
+ intel_crtc_pch_transcoder(crtc);
+
+ intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
true);
+ }
+}
+
+static void commit_pipe_config(struct intel_atomic_state *state,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ bool modeset = needs_modeset(new_crtc_state);
+
+ if (!modeset) {
+ if (new_crtc_state->uapi.color_mgmt_changed ||
+ new_crtc_state->update_pipe)
+ intel_color_commit(new_crtc_state);
+
+ if (new_crtc_state->update_pipe)
+ intel_update_pipe_config(old_crtc_state,
new_crtc_state);
+ else if (INTEL_GEN(dev_priv) >= 9)
+ skl_detach_scalers(new_crtc_state);
+
+ if (INTEL_GEN(dev_priv) >= 9 || IS_BROADWELL(dev_priv))
+ bdw_set_pipemisc(new_crtc_state);
+ }
+
+ if (dev_priv->display.atomic_update_watermarks)
+ dev_priv->display.atomic_update_watermarks(state,
+ new_crtc_state);
+}
+
static void intel_update_crtc(struct intel_crtc *crtc,
struct intel_atomic_state *state,
struct intel_crtc_state *old_crtc_state,
struct intel_crtc_state *new_crtc_state)
{
- struct drm_device *dev = state->base.dev;
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
bool modeset = needs_modeset(new_crtc_state);
struct intel_plane_state *new_plane_state =
intel_atomic_get_new_plane_state(state,
@@ -13755,14 +13794,21 @@ static void intel_update_crtc(struct intel_crtc *crtc,
else if (new_plane_state)
intel_fbc_enable(crtc, new_crtc_state, new_plane_state);
- intel_begin_crtc_commit(state, crtc);
+ /* Perform vblank evasion around commit operation */
+ intel_pipe_update_start(new_crtc_state);
+
+ commit_pipe_config(state, old_crtc_state, new_crtc_state);
if (INTEL_GEN(dev_priv) >= 9)
skl_update_planes_on_crtc(state, crtc);
else
i9xx_update_planes_on_crtc(state, crtc);
- intel_finish_crtc_commit(state, crtc);
+ intel_pipe_update_end(new_crtc_state);
+
+ if (new_crtc_state->update_pipe && !modeset &&
+ old_crtc_state->hw.mode.private_flags & I915_MODE_FLAG_INHERITED)
+ intel_crtc_arm_fifo_underrun(crtc, new_crtc_state);
}
static void intel_update_crtcs(struct intel_atomic_state *state)
@@ -14525,72 +14571,6 @@ skl_max_scale(const struct intel_crtc_state
*crtc_state,
return max_scale;
}
-static void intel_begin_crtc_commit(struct intel_atomic_state *state,
- struct intel_crtc *crtc)
-{
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- struct intel_crtc_state *old_crtc_state
[Intel-gfx] [PATCH 09/10] drm/i915: Add debugfs entries for reading out DPCD DSC and FEC.
Dump the DSC and FEC in i915_dpcd as well. This is useful when
debugging the link caps.
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/i915_debugfs.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 610bc9b5d740..c2f15de07427 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4396,8 +4396,10 @@ struct dpcd_block {
static const struct dpcd_block i915_dpcd_debug[] = {
{ .offset = DP_DPCD_REV, .size = DP_RECEIVER_CAP_SIZE },
+ { .offset = DP_DSC_SUPPORT, .end = DP_DSC_BITS_PER_PIXEL_INC },
{ .offset = DP_PSR_SUPPORT, .end = DP_PSR_CAPS },
{ .offset = DP_DOWNSTREAM_PORT_0, .size = 16 },
+ { .offset = DP_FEC_CAPABILITY },
{ .offset = DP_LINK_BW_SET, .end = DP_EDP_CONFIGURATION_SET },
{ .offset = DP_SINK_COUNT, .end = DP_ADJUST_REQUEST_LANE2_3 },
{ .offset = DP_SET_POWER },
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: timeline semaphore support (rev4)
== Series Details == Series: drm/i915: timeline semaphore support (rev4) URL : https://patchwork.freedesktop.org/series/61032/ State : warning == Summary == $ dim checkpatch origin/drm-tip 41f8e78e82c4 drm/i915: introduce a mechanism to extend execbuf2 -:141: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #141: FILE: include/uapi/drm/i915_drm.h:1165: +#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_USE_EXTENSIONS<<1)) ^ total: 0 errors, 0 warnings, 1 checks, 113 lines checked 069b5af0d919 drm/i915: add syncobj timeline support -:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #25: https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html -:379: WARNING:TYPO_SPELLING: 'transfered' may be misspelled - perhaps 'transferred'? #379: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2591: +* The chain's ownership is transfered to the -:410: ERROR:CODE_INDENT: code indent should use tabs where possible #410: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2622: +[DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES] = parse_timeline_fences,$ -:410: WARNING:LEADING_SPACE: please, no spaces at the start of a line #410: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:2622: +[DRM_I915_GEM_EXECBUFFER_EXT_TIMELINE_FENCES] = parse_timeline_fences,$ total: 1 errors, 3 warnings, 0 checks, 541 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: disable set/get_tiling ioctl on gen12+
On Tue, Aug 20, 2019 at 01:57:44PM -0700, Daniele Ceraolo Spurio wrote:
>
>
> On 8/20/19 12:54 PM, Daniel Vetter wrote:
> > The cpu (de)tiler hw is gone, this stopped being useful. Plus it never
> > supported any of the fancy new tiling formats, which means userspace
> > also stopped using the magic side-channel this provides.
> >
> > This would totally break a lot of the igts, but they're already broken
> > for the same reasons as userspace on gen12 would be.
> >
> > v2: Look at ggtt->num_fences instead, that also avoids the need for a
> > comment (Chris). This also means that gen12 support really needs to
> > make sure num_fences is set to 0. There is a patch for that, but it
> > checks for HAS_MAPPABLE_APERTURE, which I'm not sure is the right
> > thing really. Adding relevant people.
> >
>
> We'd obviously need to make that setting for all gen12+, because TGL
> does have mappable aperture.
>
> Apart from the tiling ioctl, the only place I see where we set tiling is
> intel_alloc_initial_plane_obj(), can the users of that object handle the
> lack of fences gracefully?
Gen4+ display engine has its own tiling controls and doesn't care about
fences. So we should be able to leave the obj tiling set to NONE.
Hmm. Actually I think we should reject tiled framebuffers in the BIOS
fb takeover because fbdev needs a linear view for the memory. No can
do without the fence.
> When I wrote the num_fences=0 patch I was
> expecting display to be unavailable, so I didn't really look at that
> part of the code.
>
> It'd also be nice to be more explicit with fencing since we seem to
> often call i915_vma_pin_iomap, which implicitly applies a fence if
> needed, on objects that can't be tiled or have had a fence assigned a
> few lines before. This is more a nice to have tough, possibly together
> with a split of the "mappable" and "fenceable" attributes of the vma.
>
> Daniele
>
> > Cc: Daniele Ceraolo Spurio
> > Cc: Stuart Summers
> > Cc: Matthew Auld
> > Cc: Kenneth Graunke
> > Cc: Jason Ekstrand
> > Cc: Chris Wilson
> > Cc: Lucas De Marchi
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 7 +++
> > 1 file changed, 7 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > index ca0c2f451742..e5d1ae8d4dba 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > @@ -313,10 +313,14 @@ int
> > i915_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
> > struct drm_file *file)
> > {
> > + struct drm_i915_private *dev_priv = to_i915(dev);
> > struct drm_i915_gem_set_tiling *args = data;
> > struct drm_i915_gem_object *obj;
> > int err;
> >
> > + if (!dev_priv->ggtt.num_fences)
> > + return -EOPNOTSUPP;
> > +
> > obj = i915_gem_object_lookup(file, args->handle);
> > if (!obj)
> > return -ENOENT;
> > @@ -402,6 +406,9 @@ i915_gem_get_tiling_ioctl(struct drm_device *dev, void
> > *data,
> > struct drm_i915_gem_object *obj;
> > int err = -ENOENT;
> >
> > + if (!dev_priv->ggtt.num_fences)
> > + return -EOPNOTSUPP;
> > +
> > rcu_read_lock();
> > obj = i915_gem_object_lookup_rcu(file, args->handle);
> > if (obj) {
> >
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> > On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >> With nouveau fixed all ttm-using drives have the correct nesting of
> >> mmap_sem vs dma_resv, and we can just lock the buffer.
> >>
> >> Assuming I didn't screw up anything with my audit of course.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: Christian Koenig
> >> Cc: Huang Rui
> >> Cc: Gerd Hoffmann
> >> Cc: "VMware Graphics"
> >> Cc: Thomas Hellstrom
> >> ---
> >> drivers/gpu/drm/ttm/ttm_bo.c| 34 -
> >> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +
> >> include/drm/ttm/ttm_bo_api.h| 1 -
> >> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> >> index 20ff56f27aa4..a952dd624b06 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> >> *bdev)
> >> ;
> >> }
> >> EXPORT_SYMBOL(ttm_bo_swapout_all);
> >> -
> >> -/**
> >> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object
> >> to become
> >> - * unreserved
> >> - *
> >> - * @bo: Pointer to buffer
> >> - */
> >> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> >> -{
> >> -int ret;
> >> -
> >> -/*
> >> - * In the absense of a wait_unlocked API,
> >> - * Use the bo::wu_mutex to avoid triggering livelocks due to
> >> - * concurrent use of this function. Note that this use of
> >> - * bo::wu_mutex can go away if we change locking order to
> >> - * mmap_sem -> bo::reserve.
> >> - */
> >> -ret = mutex_lock_interruptible(&bo->wu_mutex);
> >> -if (unlikely(ret != 0))
> >> -return -ERESTARTSYS;
> >> -if (!dma_resv_is_locked(bo->base.resv))
> >> -goto out_unlock;
> >> -ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
> >> -if (ret == -EINTR)
> >> -ret = -ERESTARTSYS;
> >> -if (unlikely(ret != 0))
> >> -goto out_unlock;
> >> -dma_resv_unlock(bo->base.resv);
> >> -
> >> -out_unlock:
> >> -mutex_unlock(&bo->wu_mutex);
> >> -return ret;
> >> -}
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> index 76eedb963693..505e1787aeea 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> >> vm_fault *vmf)
> >> &bdev->man[bo->mem.mem_type];
> >> struct vm_area_struct cvma;
> >> -/*
> >> - * Work around locking order reversal in fault / nopfn
> >> - * between mmap_sem and bo_reserve: Perform a trylock operation
> >> - * for reserve, and if it fails, retry the fault after waiting
> >> - * for the buffer to become unreserved.
> >> - */
> >> -if (unlikely(!dma_resv_trylock(bo->base.resv))) {
> >> -if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> >> -if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> >> -ttm_bo_get(bo);
> >> - up_read(&vmf->vma->vm_mm->mmap_sem);
> >> -(void) ttm_bo_wait_unreserved(bo);
> >> -ttm_bo_put(bo);
> >> -}
> >> -
> >> -return VM_FAULT_RETRY;
> >> -}
> >> -
> >> -/*
> >> - * If we'd want to change locking order to
> >> - * mmap_sem -> bo::reserve, we'd use a blocking reserve here
> >> - * instead of retrying the fault...
> >> - */
> >
> > I think you should justify why the above code is removed, since the
> > comments actually outlines what to do if we change locking order.
> >
> > The code that's removed above is not for adjusting locking orders but
> > to decrease the mm latency by releasing the mmap_sem while waiting for
> > bo reserve which in turn might be waiting for GPU. At a minimum we
> > should have a separate patch with justification.
> >
> > Note that the caller here ensures locking progress by adjusting the
> > RETRY flags after a retry.
That would be patches 1&2 in this series.
> And this last sentence also means we still can remove the wu-mutex when
> the locking order is changed, since the chance of livelock is goes away.
> IIRC only a single RETRY spin is allowed by the mm core.
Christian already noticed that one too, I simply forgot, it's fixed in
v2 I have here.
-Daniel
> /Thomas
>
> >
> > /Thomas
> >
> >
> >> -return VM_FAULT_NOPAGE;
> >> -}
> >> +dma_resv_lock(bo->base.resv, NULL);
> >> /*
> >>* Refuse to fault imported pages. This should be handled
> >> diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
> >> index 43c4929a2171..6b50e624e3e2 100644
> >> --- a/include/drm/ttm/ttm_bo_api.h
> >> +++ b/include/drm/ttm/ttm_bo_api.h
> >> @@ -765,7 +765,6 @@ ssize_t ttm_bo_io(struct ttm_bo_devi
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware) wrote: > > On 8/20/19 4:53 PM, Daniel Vetter wrote: > > With nouveau fixed all ttm-using drives have the correct nesting of > > mmap_sem vs dma_resv, and we can just lock the buffer. > > > > Assuming I didn't screw up anything with my audit of course. > > > > Signed-off-by: Daniel Vetter > > Cc: Christian Koenig > > Cc: Huang Rui > > Cc: Gerd Hoffmann > > Cc: "VMware Graphics" > > Cc: Thomas Hellstrom > > --- > > drivers/gpu/drm/ttm/ttm_bo.c| 34 - > > drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 + > > include/drm/ttm/ttm_bo_api.h| 1 - > > 3 files changed, 1 insertion(+), 60 deletions(-) > > > > > > + dma_resv_lock(bo->base.resv, NULL); > > interruptible, or at least killable. (IIRC think killable is the right > choice in fault code, even if TTM initially implemented interruptible to > get reasonable Xorg "silken mouse" latency). I think interruptible is fine. I chickend out of that for v1 because I always mix up the return code for _lock_interruptibl() :-) I'll add that for the next version too. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/dp/dsc: Add Support for all BPCs supported by TGL (rev5)
== Series Details == Series: drm/dp/dsc: Add Support for all BPCs supported by TGL (rev5) URL : https://patchwork.freedesktop.org/series/63526/ State : success == Summary == CI Bug Log - changes from CI_DRM_6750_full -> Patchwork_14113_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14113_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +6 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb4/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@fifo-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +12 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@gem_exec_sched...@fifo-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb3/igt@gem_exec_sched...@fifo-bsd1.html * igt@gem_pwrite@big-cpu-random: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl4/igt@gem_pwr...@big-cpu-random.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-apl8/igt@gem_pwr...@big-cpu-random.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([fdo#108686]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-glk3/igt@gem_tiled_swapp...@non-threaded.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-glk6/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_userptr_blits@create-destroy-sync: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#109100]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb5/igt@gem_userptr_bl...@create-destroy-sync.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb7/igt@gem_userptr_bl...@create-destroy-sync.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108] / [fdo#107807]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl6/igt@i915_pm_...@system-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-skl9/igt@i915_pm_...@system-suspend.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-skl10/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@kms_frontbuffer_track...@fbc-stridechange.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb5/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr2...@frontbuffer.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb3/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb4/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-iclb4/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][25] -> [SKIP][26] ([fdo#109271]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-kbl4/igt@perf_...@rc6.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14113/shard-kbl7/igt@perf_...@rc6.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: timeline semaphore support (rev4)
== Series Details ==
Series: drm/i915: timeline semaphore support (rev4)
URL : https://patchwork.freedesktop.org/series/61032/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6754 -> Patchwork_14121
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14121/
Known issues
Here are the changes found in Patchwork_14121 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_reloc@basic-cpu-gtt-noreloc:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-icl-u3/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14121/fi-icl-u3/igt@gem_exec_re...@basic-cpu-gtt-noreloc.html
Possible fixes
* igt@gem_sync@basic-store-each:
- fi-cfl-8109u: [INCOMPLETE][3] ([fdo#111427]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-cfl-8109u/igt@gem_s...@basic-store-each.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14121/fi-cfl-8109u/igt@gem_s...@basic-store-each.html
* igt@i915_module_load@reload:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6754/fi-icl-u3/igt@i915_module_l...@reload.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14121/fi-icl-u3/igt@i915_module_l...@reload.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111427]: https://bugs.freedesktop.org/show_bug.cgi?id=111427
Participating hosts (56 -> 48)
--
Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6754 -> Patchwork_14121
CI-20190529: 20190529
CI_DRM_6754: f4168ecba1e5c41cbf25d7b5db0c685ee7470d60 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5146: 357dbe1869d88a2f08bcee4eebceff4ee9014424 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14121: 069b5af0d9195805d4ee0c0e5b9a8ec8cb84da0e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
069b5af0d919 drm/i915: add syncobj timeline support
41f8e78e82c4 drm/i915: introduce a mechanism to extend execbuf2
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14121/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/execlists: Set priority hint prior to submission
Since we now run process_csb() outside of the engine->active.lock, we
can process a CS-event immediately upon our ELSP write. As we currently
inspect the pending queue *after* the ELSP write, there is an
opportunity for a CS-event to update the pending queue before we can
read it, making ourselves chases an invalid pointer.
Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off
spinlock")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 44780e7fafec..d42584439f51 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1335,9 +1335,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (submit) {
*port = execlists_schedule_in(last, port - execlists->pending);
memset(port + 1, 0, (last_port - port) * sizeof(*port));
- execlists_submit_ports(engine);
execlists->switch_priority_hint =
switch_prio(engine, *execlists->pending);
+ execlists_submit_ports(engine);
} else {
ring_set_paused(engine, 0);
}
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/execlists: Set priority hint prior to submission
Quoting Chris Wilson (2019-08-21 15:23:36)
> Since we now run process_csb() outside of the engine->active.lock, we
> can process a CS-event immediately upon our ELSP write. As we currently
> inspect the pending queue *after* the ELSP write, there is an
> opportunity for a CS-event to update the pending queue before we can
> read it, making ourselves chases an invalid pointer.
>
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=111427
> Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the
> irq-off spinlock")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 44780e7fafec..d42584439f51 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1335,9 +1335,9 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> if (submit) {
> *port = execlists_schedule_in(last, port -
> execlists->pending);
> memset(port + 1, 0, (last_port - port) * sizeof(*port));
> - execlists_submit_ports(engine);
> execlists->switch_priority_hint =
> switch_prio(engine, *execlists->pending);
> + execlists_submit_ports(engine);
> } else {
> ring_set_paused(engine, 0);
> }
> --
> 2.23.0.rc1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 37/40] drm/framebuffer/tgl: Format modifier for Intel Gen-12 render compression
On Sat, 2019-08-17 at 02:38 -0700, Lucas De Marchi wrote:
> From: Dhinakaran Pandiyan
>
> Gen-12 has a new compression format, add a new modifier for userspace
> to
> indicate that.
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Signed-off-by: Dhinakaran Pandiyan
> Signed-off-by: Lucas De Marchi
> ---
> include/uapi/drm/drm_fourcc.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/include/uapi/drm/drm_fourcc.h
> b/include/uapi/drm/drm_fourcc.h
> index 3feeaa3f987a..fb7270bf9670 100644
> --- a/include/uapi/drm/drm_fourcc.h
> +++ b/include/uapi/drm/drm_fourcc.h
> @@ -410,6 +410,16 @@ extern "C" {
> #define I915_FORMAT_MOD_Y_TILED_CCS fourcc_mod_code(INTEL, 4)
> #define I915_FORMAT_MOD_Yf_TILED_CCS fourcc_mod_code(INTEL, 5)
>
> +/*
> + * Intel color control surfaces (CCS) for Gen-12 render compression.
> + *
> + * The main surface is Y-tiled and is at plane index 0 whereas CCS
> is linear and
> + * at index 1. A CCS cache line corresponds to an area of 4x1 tiles
> in the main
> + * surface. The main surface pitch is required to be a multiple of 4
> tile
> + * widths.
> + */
> +#define I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS fourcc_mod_code(INTEL,
> 6)
> +
> /*
> * Tiled, NV12MT, grouped in 64 (pixels) x 32 (lines) -sized
> macroblocks
> *
Reviewed-by: Stanislav Lisovskiy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 40/40] drm/i915/tgl: Gen-12 media compression
On Sat, 2019-08-17 at 02:39 -0700, Lucas De Marchi wrote:
> From: Dhinakaran Pandiyan
>
> Gen-12 display can decompress surfaces compressed by the media
> engine.
> Detect the modifier corresponding to media compression to enable
> decompression for YUV and ARGB packed formats. A new modifier is
> added
> so that the driver can distinguish between media and render
> compressed
> buffers. Unlike render decompression, plane 6 and plane 7 do not
> support
> media decompression.
>
> v2: Fix checkpatch warnings on code style (Lucas)
>
> Bspec: 29695
>
> Cc: Ville Syrjälä
> Signed-off-by: Dhinakaran Pandiyan
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 23 +-
> --
> drivers/gpu/drm/i915/display/intel_sprite.c | 20 +
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 3 files changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 190adbffe055..18ff4631f873 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -1913,6 +1913,7 @@ intel_tile_width_bytes(const struct
> drm_framebuffer *fb, int color_plane)
> return 128;
> /* fall through */
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> if (color_plane == 1)
> return cpp;
> /* fall through */
> @@ -2050,6 +2051,7 @@ static unsigned int intel_surf_alignment(const
> struct drm_framebuffer *fb,
> return 256 * 1024;
> return 0;
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> return 4 * 4 * 1024;
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> @@ -2248,8 +2250,15 @@ static u32 intel_adjust_tile_offset(int *x,
> int *y,
>
> static bool is_surface_linear(u64 modifier, int color_plane)
> {
> - return modifier == DRM_FORMAT_MOD_LINEAR ||
> -(modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS &&
> color_plane == 1);
> + switch (modifier) {
> + case DRM_FORMAT_MOD_LINEAR:
> + return true;
> + case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> + return color_plane == 1;
> + default:
> + return false;
> + }
> }
>
> static u32 intel_adjust_aligned_offset(int *x, int *y,
> @@ -2437,6 +2446,7 @@ static unsigned int
> intel_fb_modifier_to_tiling(u64 fb_modifier)
> case I915_FORMAT_MOD_Y_TILED:
> case I915_FORMAT_MOD_Y_TILED_CCS:
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> return I915_TILING_Y;
> default:
> return I915_TILING_NONE;
> @@ -2510,6 +2520,7 @@ intel_get_format_info(const struct
> drm_mode_fb_cmd2 *cmd)
> ARRAY_SIZE(skl_ccs_formats),
> cmd->pixel_format);
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> return lookup_format_info(gen12_ccs_formats,
> ARRAY_SIZE(gen12_ccs_formats)
> ,
> cmd->pixel_format);
> @@ -2521,6 +2532,7 @@ intel_get_format_info(const struct
> drm_mode_fb_cmd2 *cmd)
> bool is_ccs_modifier(u64 modifier)
> {
> return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
> +modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
> modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
> modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
> }
> @@ -4093,6 +4105,8 @@ static u32 skl_plane_ctl_tiling(u64
> fb_modifier)
> /* fall through */
> case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
> return PLANE_CTL_TILED_Y |
> PLANE_CTL_RENDER_DECOMPRESSION_ENABLE;
> + case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
> + return PLANE_CTL_TILED_Y |
> PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE;
> case I915_FORMAT_MOD_Yf_TILED:
> return PLANE_CTL_TILED_YF;
> case I915_FORMAT_MOD_Yf_TILED_CCS:
> @@ -9870,6 +9884,8 @@ skylake_get_initial_plane_config(struct
> intel_crtc *crtc,
> fb->modifier = INTEL_GEN(dev_priv) >= 12 ?
> I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS :
> I915_FORMAT_MOD_Y_TILED_CCS;
> + else if (val & PLANE_CTL_MEDIA_DECOMPRESSION_ENABLE)
> + fb->modifier =
> I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS;
> else
> fb->modifier = I915_FORMAT_MOD_Y_TILED;
> break;
> @@ -15740,7 +15756,8 @@ static int intel_framebuffer_init(struct
> intel_framebuffe
Re: [Intel-gfx] [PATCH v2 39/40] drm/framebuffer/tgl: Format modifier for Intel Gen-12 media compression
On Sat, 2019-08-17 at 02:39 -0700, Lucas De Marchi wrote: > From: Dhinakaran Pandiyan > > Gen-12 display can decompress surfaces compressed by the media > engine, add > a new modifier as the driver needs to know the surface was compressed > by > the media or render engine. > > Cc: Ville Syrjälä > Signed-off-by: Dhinakaran Pandiyan > Signed-off-by: Lucas De Marchi > --- > include/uapi/drm/drm_fourcc.h | 10 ++ > 1 file changed, 10 insertions(+) > > Reviewed-by: Stanislav Lisovskiy ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Bigjoiner preparations.
== Series Details == Series: drm/i915: Bigjoiner preparations. URL : https://patchwork.freedesktop.org/series/65543/ State : warning == Summary == $ dim checkpatch origin/drm-tip bb9674943922 drm/i915/dp: Fix dsc bpp calculations. 0e2d405f7bbf drm/i915: Prepare to split crtc state in uapi and hw state -:11: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #11: - crtc, *_changed flags, event, commit, state, mode_blob, (plane/connector/encoder)_mask. -:1976: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #1976: FILE: drivers/gpu/drm/i915/display/intel_display.c:11171: + crtc_state->uapi.active = crtc_state->uapi.enable = true; -:2646: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #2646: FILE: drivers/gpu/drm/i915/display/intel_display.c:16658: + crtc_state->hw.active = crtc_state->hw.enable = -:3798: ERROR:CODE_INDENT: code indent should use tabs where possible #3798: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:224: +^I^I^I^I new_crtc_state->uapi.event);$ -:3798: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #3798: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:224: + drm_crtc_arm_vblank_event(&crtc->base, + new_crtc_state->uapi.event); total: 1 errors, 1 warnings, 3 checks, 4194 lines checked 15321f86c2b3 drm/i915: Handle a few more cases for hw/sw split 4c4ad0feadf2 drm/i915: Complete sw/hw split 8bc9c0b2e0a0 drm/i915: Kill off is_planar_yuv_format 782d5f4e19cc drm/i915: Get rid of crtc_state->fb_changed 2c4f08fcf5ee drm/i915: Remove begin/finish_crtc_commit. bb6ec153c77c drm/i915: Do not add all planes when checking scalers on glk+ c3e067461453 drm/i915: Add debugfs entries for reading out DPCD DSC and FEC. 1f51e8536ef9 drm/i915: Move FEC enable timeout wait to enable_ddi_dp -:6: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #6: Even without bigjoiner I get a timeout when enabling FEC, the length of the timeout total: 0 errors, 1 warnings, 0 checks, 21 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 28/40] drm/i915/tgl: add GEN12_MAX_CONTEXT_HW_ID
On Sat, 2019-08-17 at 02:38 -0700, Lucas De Marchi wrote:
> From: Daniele Ceraolo Spurio
>
> Like Gen11, Gen12 has 11 available bits for the ctx id field.
> However,
> the last value (0x7FF) is reserved to indicate engine idle, so we
> need to reduce the maximum number of contexts by 1 compared to Gen11.
>
> Cc: Chris Wilson
> Signed-off-by: Daniele Ceraolo Spurio <
> daniele.ceraolospu...@intel.com>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/gem/i915_gem_context.c | 4 +++-
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> 2 files changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> index cd1fd2e5423a..1cdfe05514c3 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
> @@ -173,7 +173,9 @@ static inline int new_hw_id(struct
> drm_i915_private *i915, gfp_t gfp)
>
> lockdep_assert_held(&i915->contexts.mutex);
>
> - if (INTEL_GEN(i915) >= 11)
> + if (INTEL_GEN(i915) >= 12)
> + max = GEN12_MAX_CONTEXT_HW_ID;
> + else if (INTEL_GEN(i915) >= 11)
> max = GEN11_MAX_CONTEXT_HW_ID;
> else if (USES_GUC_SUBMISSION(i915))
> /*
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index d6c8efcba612..c9b1b94a620f 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1605,6 +1605,8 @@ struct drm_i915_private {
> #define MAX_CONTEXT_HW_ID (1<<21) /* exclusive */
> #define MAX_GUC_CONTEXT_HW_ID (1 << 20) /* exclusive */
> #define GEN11_MAX_CONTEXT_HW_ID (1<<11) /* exclusive */
> +/* in Gen12 ID 0x7FF is reserved to indicate idle */
> +#define GEN12_MAX_CONTEXT_HW_ID (GEN11_MAX_CONTEXT_HW_ID - 1)
> struct list_head hw_id_list;
> } contexts;
>
Reviewed-by: Stanislav Lisovskiy
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
On Wed, Aug 21, 2019 at 4:30 PM Thomas Hellström (VMware) wrote: > > On 8/21/19 4:10 PM, Daniel Vetter wrote: > > On Wed, Aug 21, 2019 at 3:16 PM Thomas Hellström (VMware) > > wrote: > >> On 8/20/19 4:53 PM, Daniel Vetter wrote: > >>> With nouveau fixed all ttm-using drives have the correct nesting of > >>> mmap_sem vs dma_resv, and we can just lock the buffer. > >>> > >>> Assuming I didn't screw up anything with my audit of course. > >>> > >>> Signed-off-by: Daniel Vetter > >>> Cc: Christian Koenig > >>> Cc: Huang Rui > >>> Cc: Gerd Hoffmann > >>> Cc: "VMware Graphics" > >>> Cc: Thomas Hellstrom > >>> --- > >>>drivers/gpu/drm/ttm/ttm_bo.c| 34 - > >>>drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 + > >>>include/drm/ttm/ttm_bo_api.h| 1 - > >>>3 files changed, 1 insertion(+), 60 deletions(-) > >>> > >>> > >>> + dma_resv_lock(bo->base.resv, NULL); > >> interruptible, or at least killable. (IIRC think killable is the right > >> choice in fault code, even if TTM initially implemented interruptible to > >> get reasonable Xorg "silken mouse" latency). > > I think interruptible is fine. I chickend out of that for v1 because I > > always mix up the return code for _lock_interruptibl() :-) > > :). IIRC I think the in-kernel users of fault() were unhappy with > interruptible. (GUP?), but I guess it's better to use a bulk change at > some point if necessary. We've been using interruptible since forever, returning VM_FAULT_NOPAGE to get the signal handled and re-run. Seems to not have pissed off anyone thus far. I think if we do this I'll do it as a follow-up. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> >>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
>
> Assuming I didn't screw up anything with my audit of course.
>
> Signed-off-by: Daniel Vetter
> Cc: Christian Koenig
> Cc: Huang Rui
> Cc: Gerd Hoffmann
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 34 -
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +
> include/drm/ttm/ttm_bo_api.h| 1 -
> 3 files changed, 1 insertion(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
> index 20ff56f27aa4..a952dd624b06 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> *bdev)
> ;
> }
> EXPORT_SYMBOL(ttm_bo_swapout_all);
> -
> -/**
> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object
> to become
> - * unreserved
> - *
> - * @bo: Pointer to buffer
> - */
> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> -{
> -int ret;
> -
> -/*
> - * In the absense of a wait_unlocked API,
> - * Use the bo::wu_mutex to avoid triggering livelocks due to
> - * concurrent use of this function. Note that this use of
> - * bo::wu_mutex can go away if we change locking order to
> - * mmap_sem -> bo::reserve.
> - */
> -ret = mutex_lock_interruptible(&bo->wu_mutex);
> -if (unlikely(ret != 0))
> -return -ERESTARTSYS;
> -if (!dma_resv_is_locked(bo->base.resv))
> -goto out_unlock;
> -ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
> -if (ret == -EINTR)
> -ret = -ERESTARTSYS;
> -if (unlikely(ret != 0))
> -goto out_unlock;
> -dma_resv_unlock(bo->base.resv);
> -
> -out_unlock:
> -mutex_unlock(&bo->wu_mutex);
> -return ret;
> -}
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 76eedb963693..505e1787aeea 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> vm_fault *vmf)
> &bdev->man[bo->mem.mem_type];
> struct vm_area_struct cvma;
> -/*
> - * Work around locking order reversal in fault / nopfn
> - * between mmap_sem and bo_reserve: Perform a trylock operation
> - * for reserve, and if it fails, retry the fault after waiting
> - * for the buffer to become unreserved.
> - */
> -if (unlikely(!dma_resv_trylock(bo->base.resv))) {
> -if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> -if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> -ttm_bo_get(bo);
> - up_read(&vmf->vma->vm_mm->mmap_sem);
> -(void) ttm_bo_wait_unreserved(bo);
> -ttm_bo_put(bo);
> -}
> -
> -return VM_FAULT_RETRY;
> -}
> -
> -/*
> - * If we'd want to change locking order to
> - * mmap_sem -> bo::reserve, we'd use a blocking reserve here
> - * instead of retrying the fault...
> - */
> >>> I think you should justify why the above code is removed, since the
> >>> comments actually outlines what to do if we change locking order.
> >>>
> >>> The code that's removed above is not for adjusting locking orders but
> >>> to decrease the mm latency by releasing the mmap_sem while waiting for
> >>> bo reserve which in turn might be waiting for GPU. At a minimum we
> >>> should have a separate patch with justification.
> >>>
> >>> Note that the caller here ensures locking progress by adjusting the
> >>> RETRY flags after a retry.
> > That would be patches 1&2 in this series.
> >
> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
> patch should look along the lines of (based on an older tree) to
> implement the new locking-order mmap_sem->reservation,
Only nouveau was breaking was doing copy_*_user or get_user_pages
while holding dma_resv locks, no one else. So nothing else needed to
be changed. But patch 1 contains the full audit. I might have missed
something.
> but to keep the mm latency op
Re: [Intel-gfx] [PATCH v2 06/40] drm/i915: Add transcoder restriction to PSR2
On Sat, Aug 17, 2019 at 02:38:28AM -0700, Lucas De Marchi wrote:
> From: José Roberto de Souza
>
> According to PSR2_CTL definition in BSpec there is only one instance of
> PSR2_CTL. Platforms gen < 12 with EDP transcoder only support PSR2 on
> TRANSCODER_EDP while on TGL PSR2 is only supported by TRANSCODER_A.
>
> Since BDW PSR is allowed on any port, but we need to restrict by transcoder.
>
> BSpec: 7713
> BSpec: 20584
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 16
> 1 file changed, 16 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index 77232f6bca17..4353270bd65c 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -534,6 +534,16 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> I915_WRITE(EDP_PSR2_CTL(dev_priv->psr.transcoder), val);
> }
>
> +static bool
> +_psr2_supported_in_trans(struct drm_i915_private *dev_priv,
> + enum transcoder trans)
I think a more customary name would be something like
transcoder_has_psr2() or transcoder_supports_psr2().
> +{
> + if (INTEL_GEN(dev_priv) >= 12)
> + return trans == TRANSCODER_A;
> + else
> + return trans == TRANSCODER_EDP;
> +}
> +
> static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
> struct intel_crtc_state *crtc_state)
> {
> @@ -545,6 +555,12 @@ static bool intel_psr2_config_valid(struct intel_dp
> *intel_dp,
> if (!dev_priv->psr.sink_psr2_support)
> return false;
>
> + if (!_psr2_supported_in_trans(dev_priv, crtc_state->cpu_transcoder)) {
> + DRM_DEBUG_KMS("PSR2 not supported in transcoder %s\n",
> + transcoder_name(crtc_state->cpu_transcoder));
> + return false;
> + }
> +
> /*
>* DSC and PSR2 cannot be enabled simultaneously. If a requested
>* resolution requires DSC to be enabled, priority is given to DSC
> --
> 2.21.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Bigjoiner preparations.
== Series Details ==
Series: drm/i915: Bigjoiner preparations.
URL : https://patchwork.freedesktop.org/series/65543/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6755 -> Patchwork_14122
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14122 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14122, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14122:
### IGT changes ###
Possible regressions
* igt@gem_exec_suspend@basic-s3:
- fi-kbl-r: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-kbl-r/igt@gem_exec_susp...@basic-s3.html
- fi-whl-u: [PASS][3] -> [INCOMPLETE][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-whl-u/igt@gem_exec_susp...@basic-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-whl-u/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_execlists:
- fi-icl-u2: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u2/igt@i915_selftest@live_execlists.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-icl-u2/igt@i915_selftest@live_execlists.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_execlists:
- {fi-icl-dsi}: [PASS][7] -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-dsi/igt@i915_selftest@live_execlists.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-icl-dsi/igt@i915_selftest@live_execlists.html
Known issues
Here are the changes found in Patchwork_14122 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s3:
- fi-skl-6770hq: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-6770hq/igt@gem_exec_susp...@basic-s3.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-skl-6770hq/igt@gem_exec_susp...@basic-s3.html
- fi-skl-6260u: [PASS][11] -> [INCOMPLETE][12] ([fdo#104108])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-skl-6260u/igt@gem_exec_susp...@basic-s3.html
- fi-kbl-7567u: [PASS][13] -> [INCOMPLETE][14] ([fdo#103665])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-kbl-7567u/igt@gem_exec_susp...@basic-s3.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-kbl-7567u/igt@gem_exec_susp...@basic-s3.html
- fi-apl-guc: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927] /
[fdo#108743])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-apl-guc/igt@gem_exec_susp...@basic-s3.html
- fi-skl-6600u: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-skl-6600u/igt@gem_exec_susp...@basic-s3.html
* igt@gem_tiled_pread_basic:
- fi-icl-u3: [PASS][19] -> [DMESG-WARN][20] ([fdo#107724])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u3/igt@gem_tiled_pread_basic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-icl-u3/igt@gem_tiled_pread_basic.html
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][21] -> [INCOMPLETE][22] ([fdo#107718])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-blb-e6850/igt@i915_module_l...@reload.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-blb-e6850/igt@i915_module_l...@reload.html
Possible fixes
* igt@gem_linear_blits@basic:
- fi-icl-u3: [DMESG-WARN][23] ([fdo#107724]) -> [PASS][24]
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u3/igt@gem_linear_bl...@basic.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14122/fi-icl-u3/igt@gem_linear_bl...@basic.html
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][25] ([fdo#111045])
Re: [Intel-gfx] linux-next: Tree for Aug 21 (gpu/drm/i915/)
On 8/21/19 1:49 AM, Stephen Rothwell wrote: > Hi all, > > Changes since 20190820: > on x86_64: ../drivers/gpu/drm/i915/i915_gem_gtt.c: In function ‘ggtt_restore_mappings’: ../drivers/gpu/drm/i915/i915_gem_gtt.c::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 Full randconfig file is attached. -- ~Randy # # Automatically generated file; DO NOT EDIT. # Linux/x86_64 5.3.0-rc5 Kernel Configuration # # # Compiler: gcc (SUSE Linux) 7.4.0 # CONFIG_CC_IS_GCC=y CONFIG_GCC_VERSION=70400 CONFIG_CLANG_VERSION=0 CONFIG_CC_CAN_LINK=y CONFIG_CC_HAS_ASM_GOTO=y CONFIG_CC_HAS_WARN_MAYBE_UNINITIALIZED=y CONFIG_CC_DISABLE_WARN_MAYBE_UNINITIALIZED=y CONFIG_CONSTRUCTORS=y CONFIG_IRQ_WORK=y CONFIG_BUILDTIME_EXTABLE_SORT=y CONFIG_THREAD_INFO_IN_TASK=y # # General setup # CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # CONFIG_COMPILE_TEST is not set # CONFIG_HEADER_TEST is not set CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_BUILD_SALT="" CONFIG_HAVE_KERNEL_GZIP=y CONFIG_HAVE_KERNEL_BZIP2=y CONFIG_HAVE_KERNEL_LZMA=y CONFIG_HAVE_KERNEL_XZ=y CONFIG_HAVE_KERNEL_LZO=y CONFIG_HAVE_KERNEL_LZ4=y # CONFIG_KERNEL_GZIP is not set CONFIG_KERNEL_BZIP2=y # CONFIG_KERNEL_LZMA is not set # CONFIG_KERNEL_XZ is not set # CONFIG_KERNEL_LZO is not set # CONFIG_KERNEL_LZ4 is not set CONFIG_DEFAULT_HOSTNAME="(none)" CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_CROSS_MEMORY_ATTACH is not set CONFIG_USELIB=y # CONFIG_AUDIT is not set CONFIG_HAVE_ARCH_AUDITSYSCALL=y # # IRQ subsystem # CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_IRQ_SHOW=y CONFIG_GENERIC_IRQ_CHIP=y CONFIG_IRQ_DOMAIN=y CONFIG_IRQ_SIM=y CONFIG_IRQ_DOMAIN_HIERARCHY=y CONFIG_GENERIC_IRQ_MATRIX_ALLOCATOR=y CONFIG_GENERIC_IRQ_RESERVATION_MODE=y CONFIG_IRQ_FORCED_THREADING=y CONFIG_SPARSE_IRQ=y # CONFIG_GENERIC_IRQ_DEBUGFS is not set # end of IRQ subsystem CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_ARCH_CLOCKSOURCE_DATA=y CONFIG_ARCH_CLOCKSOURCE_INIT=y CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y CONFIG_GENERIC_TIME_VSYSCALL=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y CONFIG_GENERIC_CMOS_UPDATE=y # # Timers subsystem # CONFIG_TICK_ONESHOT=y CONFIG_HZ_PERIODIC=y # CONFIG_NO_HZ_IDLE is not set CONFIG_CONTEXT_TRACKING=y # CONFIG_CONTEXT_TRACKING_FORCE is not set # CONFIG_NO_HZ is not set CONFIG_HIGH_RES_TIMERS=y # end of Timers subsystem CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # # CPU/Task time and stats accounting # CONFIG_VIRT_CPU_ACCOUNTING=y # CONFIG_TICK_CPU_ACCOUNTING is not set CONFIG_VIRT_CPU_ACCOUNTING_GEN=y # CONFIG_IRQ_TIME_ACCOUNTING is not set # CONFIG_BSD_PROCESS_ACCT is not set CONFIG_TASKSTATS=y CONFIG_TASK_DELAY_ACCT=y # CONFIG_TASK_XACCT is not set # CONFIG_PSI is not set # end of CPU/Task time and stats accounting # # RCU Subsystem # CONFIG_TINY_RCU=y CONFIG_RCU_EXPERT=y CONFIG_SRCU=y CONFIG_TINY_SRCU=y # end of RCU Subsystem # CONFIG_IKCONFIG is not set # CONFIG_IKHEADERS is not set CONFIG_LOG_BUF_SHIFT=17 CONFIG_PRINTK_SAFE_LOG_BUF_SHIFT=13 CONFIG_HAVE_UNSTABLE_SCHED_CLOCK=y # # Scheduler features # # end of Scheduler features CONFIG_ARCH_SUPPORTS_NUMA_BALANCING=y CONFIG_ARCH_WANT_BATCHED_UNMAP_TLB_FLUSH=y CONFIG_ARCH_SUPPORTS_INT128=y # CONFIG_CGROUPS is not set CONFIG_NAMESPACES=y # CONFIG_UTS_NS is not set # CONFIG_USER_NS is not set CONFIG_PID_NS=y # CONFIG_NET_NS is not set CONFIG_CHECKPOINT_RESTORE=y # CONFIG_SCHED_AUTOGROUP is not set # CONFIG_SYSFS_DEPRECATED is not set CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_RD_GZIP is not set CONFIG_RD_BZIP2=y # CONFIG_RD_LZMA is not set CONFIG_RD_XZ=y # CONFIG_RD_LZO is not set # CONFIG_RD_LZ4 is not set # CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y CONFIG_SYSCTL_EXCEPTION_TRACE=y CONFIG_HAVE_PCSPKR_PLATFORM=y CONFIG_BPF=y # CONFIG_EXPERT is not set CONFIG_MULTIUSER=y CONFIG_SGETMASK_SYSCALL=y CONFIG_SYSFS_SYSCALL=y CONFIG_FHANDLE=y CONFIG_POSIX_TIMERS=y CONFIG_PRINTK=y CONFIG_PRINTK_NMI=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_PCSPKR_PLATFORM=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_FUTEX_PI=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_AIO=y CONFIG_IO_URING=y CONFIG_ADVISE_SYSCALLS=y CONFIG_MEMBARRIER=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_BASE_RELATIVE=y # CONFIG_BPF_SYSCALL is not set # CONFIG_USERFAULTFD is not set CONFIG_ARCH_HAS_MEMBARRIER_SYNC_CORE=y CONFIG_RSEQ=y # CONFIG_EMBEDDED is not set CONFIG_HAVE_PERF_EVENTS=y # # Kernel Performance Events And Counters # CONFIG_PERF_EVENTS=y # end of Kernel Performance Events And Counters CONFIG_VM_EVENT_COUNTERS=y # CONFIG_COMPAT_BRK is not set CONFIG_SLAB=y # CONFIG_SLUB is not set CONFIG_SLAB_MERGE_DEFAULT=y # CONFIG_SLAB_FRE
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
Am 21.08.19 um 16:47 schrieb Daniel Vetter: > On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware) > wrote: >> On 8/21/19 4:09 PM, Daniel Vetter wrote: >>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware) >>> wrote: On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote: > On 8/20/19 4:53 PM, Daniel Vetter wrote: > [SNIP] >> but to keep the mm latency optimization using the RETRY functionality: > Still no idea why this is needed? All the comments here and the code > and history seem like they've been about the mmap_sem vs dma_resv > inversion between driver ioctls and fault handling here. Once that's > officially fixed there's no reason to play games here and retry loops > - previously that was necessary because the old ttm_bo_vm_fault had a > busy spin and that's definitely not nice. If it's needed I think it > should be a second patch on top, to keep this all clear. I had to > audit an enormous amount of code, I'd like to make sure I didn't miss > anything before we start to make this super fancy again. Further > patches on top is obviously all fine with me. I think this is just an optimization to not hold the mmap_sem while waiting for the dma_resv lock. I agree that it shouldn't be necessary, but maybe it's a good idea for performance. I'm also OK with removing it, cause I'm not sure if it's worth it. But Thomas noted correctly that we should probably do it in a separate patch so that when somebody points out "Hey my system is slower now!" he's able to bisect to the change. Christian. > -Daniel > >> Thanks, >> Thomas >> ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 4:47 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> >>> wrote:
> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> > On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >> With nouveau fixed all ttm-using drives have the correct nesting of
> >> mmap_sem vs dma_resv, and we can just lock the buffer.
> >>
> >> Assuming I didn't screw up anything with my audit of course.
> >>
> >> Signed-off-by: Daniel Vetter
> >> Cc: Christian Koenig
> >> Cc: Huang Rui
> >> Cc: Gerd Hoffmann
> >> Cc: "VMware Graphics"
> >> Cc: Thomas Hellstrom
> >> ---
> >> drivers/gpu/drm/ttm/ttm_bo.c| 34
> >> -
> >> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +
> >> include/drm/ttm/ttm_bo_api.h| 1 -
> >> 3 files changed, 1 insertion(+), 60 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> >> b/drivers/gpu/drm/ttm/ttm_bo.c
> >> index 20ff56f27aa4..a952dd624b06 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> >> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> >> *bdev)
> >> ;
> >> }
> >> EXPORT_SYMBOL(ttm_bo_swapout_all);
> >> -
> >> -/**
> >> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object
> >> to become
> >> - * unreserved
> >> - *
> >> - * @bo: Pointer to buffer
> >> - */
> >> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> >> -{
> >> -int ret;
> >> -
> >> -/*
> >> - * In the absense of a wait_unlocked API,
> >> - * Use the bo::wu_mutex to avoid triggering livelocks due to
> >> - * concurrent use of this function. Note that this use of
> >> - * bo::wu_mutex can go away if we change locking order to
> >> - * mmap_sem -> bo::reserve.
> >> - */
> >> -ret = mutex_lock_interruptible(&bo->wu_mutex);
> >> -if (unlikely(ret != 0))
> >> -return -ERESTARTSYS;
> >> -if (!dma_resv_is_locked(bo->base.resv))
> >> -goto out_unlock;
> >> -ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
> >> -if (ret == -EINTR)
> >> -ret = -ERESTARTSYS;
> >> -if (unlikely(ret != 0))
> >> -goto out_unlock;
> >> -dma_resv_unlock(bo->base.resv);
> >> -
> >> -out_unlock:
> >> -mutex_unlock(&bo->wu_mutex);
> >> -return ret;
> >> -}
> >> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> index 76eedb963693..505e1787aeea 100644
> >> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> >> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> >> vm_fault *vmf)
> >> &bdev->man[bo->mem.mem_type];
> >> struct vm_area_struct cvma;
> >> -/*
> >> - * Work around locking order reversal in fault / nopfn
> >> - * between mmap_sem and bo_reserve: Perform a trylock operation
> >> - * for reserve, and if it fails, retry the fault after waiting
> >> - * for the buffer to become unreserved.
> >> - */
> >> -if (unlikely(!dma_resv_trylock(bo->base.resv))) {
> >> -if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> >> -if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> >> -ttm_bo_get(bo);
> >> - up_read(&vmf->vma->vm_mm->mmap_sem);
> >> -(void) ttm_bo_wait_unreserved(bo);
> >> -ttm_bo_put(bo);
> >> -}
> >> -
> >> -return VM_FAULT_RETRY;
> >> -}
> >> -
> >> -/*
> >> - * If we'd want to change locking order to
> >> - * mmap_sem -> bo::reserve, we'd use a blocking reserve here
> >> - * instead of retrying the fault...
> >> - */
> > I think you should justify why the above code is removed, since the
> > comments actually outlines what to do if we change locking order.
> >
> > The code that's removed above is not for adjusting locking orders but
> > to decrease the mm latency by releasing the mmap_sem while waiting for
> > bo reserve which in turn might be waiting for GPU. At a minimum we
> > should have a separate patch with justification.
> >
> > Note that the caller here ensures locking progress by adjusting the
> > RETRY flags after a retry.
> >>> That would be patches 1&2 in this series.
> >>>
> >> Hmm? Those seem to touch only dma-buf and nouveau not ttm? I mean this
>
[Intel-gfx] ✓ Fi.CI.IGT: success for Refactor to expand subslice mask (rev 2)
== Series Details == Series: Refactor to expand subslice mask (rev 2) URL : https://patchwork.freedesktop.org/series/65509/ State : success == Summary == CI Bug Log - changes from CI_DRM_6750_full -> Patchwork_14114_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14114_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@preempt-hang-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@gem_exec_sched...@preempt-hang-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb1/igt@gem_exec_sched...@preempt-hang-bsd.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl5/igt@i915_susp...@fence-restore-tiled2untiled.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-apl2/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions-varying-size: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#102670]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl10/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-skl3/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions-varying-size.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-skl10/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-glk4/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +5 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-skl1/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@kms_plane_low...@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb7/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109642] / [fdo#111068]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr2...@frontbuffer.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb8/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb8/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109276]) +15 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb4/igt@prime_b...@hang-bsd2.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14114/shard-iclb7/igt@p
Re: [Intel-gfx] [PATCH] drm/i915: disable set/get_tiling ioctl on gen12+
On Wed, Aug 21, 2019 at 3:55 PM Ville Syrjälä
wrote:
>
> On Tue, Aug 20, 2019 at 01:57:44PM -0700, Daniele Ceraolo Spurio wrote:
> >
> >
> > On 8/20/19 12:54 PM, Daniel Vetter wrote:
> > > The cpu (de)tiler hw is gone, this stopped being useful. Plus it never
> > > supported any of the fancy new tiling formats, which means userspace
> > > also stopped using the magic side-channel this provides.
> > >
> > > This would totally break a lot of the igts, but they're already broken
> > > for the same reasons as userspace on gen12 would be.
> > >
> > > v2: Look at ggtt->num_fences instead, that also avoids the need for a
> > > comment (Chris). This also means that gen12 support really needs to
> > > make sure num_fences is set to 0. There is a patch for that, but it
> > > checks for HAS_MAPPABLE_APERTURE, which I'm not sure is the right
> > > thing really. Adding relevant people.
> > >
> >
> > We'd obviously need to make that setting for all gen12+, because TGL
> > does have mappable aperture.
> >
> > Apart from the tiling ioctl, the only place I see where we set tiling is
> > intel_alloc_initial_plane_obj(), can the users of that object handle the
> > lack of fences gracefully?
>
> Gen4+ display engine has its own tiling controls and doesn't care about
> fences. So we should be able to leave the obj tiling set to NONE.
>
> Hmm. Actually I think we should reject tiled framebuffers in the BIOS
> fb takeover because fbdev needs a linear view for the memory. No can
> do without the fence.
Yeah I think this is just more fallout from "no more fences in the hw".
-Daniel
>
> > When I wrote the num_fences=0 patch I was
> > expecting display to be unavailable, so I didn't really look at that
> > part of the code.
> >
> > It'd also be nice to be more explicit with fencing since we seem to
> > often call i915_vma_pin_iomap, which implicitly applies a fence if
> > needed, on objects that can't be tiled or have had a fence assigned a
> > few lines before. This is more a nice to have tough, possibly together
> > with a split of the "mappable" and "fenceable" attributes of the vma.
> >
> > Daniele
> >
> > > Cc: Daniele Ceraolo Spurio
> > > Cc: Stuart Summers
> > > Cc: Matthew Auld
> > > Cc: Kenneth Graunke
> > > Cc: Jason Ekstrand
> > > Cc: Chris Wilson
> > > Cc: Lucas De Marchi
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > drivers/gpu/drm/i915/gem/i915_gem_tiling.c | 7 +++
> > > 1 file changed, 7 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > > b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > > index ca0c2f451742..e5d1ae8d4dba 100644
> > > --- a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
> > > @@ -313,10 +313,14 @@ int
> > > i915_gem_set_tiling_ioctl(struct drm_device *dev, void *data,
> > > struct drm_file *file)
> > > {
> > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > struct drm_i915_gem_set_tiling *args = data;
> > > struct drm_i915_gem_object *obj;
> > > int err;
> > >
> > > + if (!dev_priv->ggtt.num_fences)
> > > + return -EOPNOTSUPP;
> > > +
> > > obj = i915_gem_object_lookup(file, args->handle);
> > > if (!obj)
> > > return -ENOENT;
> > > @@ -402,6 +406,9 @@ i915_gem_get_tiling_ioctl(struct drm_device *dev,
> > > void *data,
> > > struct drm_i915_gem_object *obj;
> > > int err = -ENOENT;
> > >
> > > + if (!dev_priv->ggtt.num_fences)
> > > + return -EOPNOTSUPP;
> > > +
> > > rcu_read_lock();
> > > obj = i915_gem_object_lookup_rcu(file, args->handle);
> > > if (obj) {
> > >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Ville Syrjälä
> Intel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/ttm: remove ttm_bo_wait_unreserved
On Wed, Aug 21, 2019 at 5:19 PM Thomas Hellström (VMware)
wrote:
> On 8/21/19 5:14 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 5:03 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 4:47 PM, Daniel Vetter wrote:
> >>> On Wed, Aug 21, 2019 at 4:27 PM Thomas Hellström (VMware)
> >>> wrote:
> On 8/21/19 4:09 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 2:47 PM Thomas Hellström (VMware)
> > wrote:
> >> On 8/21/19 2:40 PM, Thomas Hellström (VMware) wrote:
> >>> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> With nouveau fixed all ttm-using drives have the correct nesting of
> mmap_sem vs dma_resv, and we can just lock the buffer.
>
> Assuming I didn't screw up anything with my audit of course.
>
> Signed-off-by: Daniel Vetter
> Cc: Christian Koenig
> Cc: Huang Rui
> Cc: Gerd Hoffmann
> Cc: "VMware Graphics"
> Cc: Thomas Hellstrom
> ---
> drivers/gpu/drm/ttm/ttm_bo.c| 34
> -
> drivers/gpu/drm/ttm/ttm_bo_vm.c | 26 +
> include/drm/ttm/ttm_bo_api.h| 1 -
> 3 files changed, 1 insertion(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/ttm/ttm_bo.c
> b/drivers/gpu/drm/ttm/ttm_bo.c
> index 20ff56f27aa4..a952dd624b06 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo.c
> @@ -1954,37 +1954,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device
> *bdev)
> ;
> }
> EXPORT_SYMBOL(ttm_bo_swapout_all);
> -
> -/**
> - * ttm_bo_wait_unreserved - interruptible wait for a buffer object
> to become
> - * unreserved
> - *
> - * @bo: Pointer to buffer
> - */
> -int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
> -{
> -int ret;
> -
> -/*
> - * In the absense of a wait_unlocked API,
> - * Use the bo::wu_mutex to avoid triggering livelocks due to
> - * concurrent use of this function. Note that this use of
> - * bo::wu_mutex can go away if we change locking order to
> - * mmap_sem -> bo::reserve.
> - */
> -ret = mutex_lock_interruptible(&bo->wu_mutex);
> -if (unlikely(ret != 0))
> -return -ERESTARTSYS;
> -if (!dma_resv_is_locked(bo->base.resv))
> -goto out_unlock;
> -ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
> -if (ret == -EINTR)
> -ret = -ERESTARTSYS;
> -if (unlikely(ret != 0))
> -goto out_unlock;
> -dma_resv_unlock(bo->base.resv);
> -
> -out_unlock:
> -mutex_unlock(&bo->wu_mutex);
> -return ret;
> -}
> diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> index 76eedb963693..505e1787aeea 100644
> --- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
> +++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
> @@ -125,31 +125,7 @@ static vm_fault_t ttm_bo_vm_fault(struct
> vm_fault *vmf)
> &bdev->man[bo->mem.mem_type];
> struct vm_area_struct cvma;
> -/*
> - * Work around locking order reversal in fault / nopfn
> - * between mmap_sem and bo_reserve: Perform a trylock operation
> - * for reserve, and if it fails, retry the fault after waiting
> - * for the buffer to become unreserved.
> - */
> -if (unlikely(!dma_resv_trylock(bo->base.resv))) {
> -if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
> -if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
> -ttm_bo_get(bo);
> - up_read(&vmf->vma->vm_mm->mmap_sem);
> -(void) ttm_bo_wait_unreserved(bo);
> -ttm_bo_put(bo);
> -}
> -
> -return VM_FAULT_RETRY;
> -}
> -
> -/*
> - * If we'd want to change locking order to
> - * mmap_sem -> bo::reserve, we'd use a blocking reserve here
> - * instead of retrying the fault...
> - */
> >>> I think you should justify why the above code is removed, since the
> >>> comments actually outlines what to do if we change locking order.
> >>>
> >>> The code that's removed above is not for adjusting locking orders but
> >>> to decrease the mm latency by releasing the mmap_sem while waiting for
> >>> bo reserve which in turn migh
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/execlists: Set priority hint prior to submission
== Series Details ==
Series: drm/i915/execlists: Set priority hint prior to submission
URL : https://patchwork.freedesktop.org/series/65550/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6755 -> Patchwork_14123
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/
Known issues
Here are the changes found in Patchwork_14123 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_exec_reloc@basic-gtt-cpu-noreloc:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +1
similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u3/igt@gem_exec_re...@basic-gtt-cpu-noreloc.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-icl-u3/igt@gem_exec_re...@basic-gtt-cpu-noreloc.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@i915_selftest@live_hangcheck:
- fi-skl-6260u: [PASS][7] -> [INCOMPLETE][8] ([fdo#108744])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-6260u/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-skl-6260u/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@gem_ctx_switch@legacy-render:
- fi-cfl-8109u: [INCOMPLETE][9] -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-cfl-8109u/igt@gem_ctx_swi...@legacy-render.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-cfl-8109u/igt@gem_ctx_swi...@legacy-render.html
* igt@gem_linear_blits@basic:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u3/igt@gem_linear_bl...@basic.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-icl-u3/igt@gem_linear_bl...@basic.html
* igt@i915_selftest@live_execlists:
- {fi-icl-guc}: [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-guc/igt@i915_selftest@live_execlists.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-icl-guc/igt@i915_selftest@live_execlists.html
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][15] ([fdo#111045]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u4}:[FAIL][17] ([fdo#103167]) -> [PASS][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14123/fi-icl-u4/igt@kms_frontbuffer_track...@basic.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (57 -> 47)
--
Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy
fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6755 -> Patchwork_14123
CI-20190529: 20190529
CI_DRM_6755: 8ef0018b4afe55bff6f538b2125a72250a8bf67f @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5146: 357dbe1869d88a2f08bcee4eebceff4ee9014424 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14123: 02a8e285f9a4c5718a05641ab754fde0b3
[Intel-gfx] [PATCH] drm/ttm: remove ttm_bo_wait_unreserved
With nouveau fixed all ttm-using drives have the correct nesting of
mmap_sem vs dma_resv, and we can just lock the buffer.
Assuming I didn't screw up anything with my audit of course.
v2:
- Dont forget wu_mutex (Christian König)
- Keep the mmap_sem-less wait optimization (Thomas)
- Use _lock_interruptible to be good citizens (Thomas)
Reviewed-by: Christian König
Signed-off-by: Daniel Vetter
Cc: Christian Koenig
Cc: Huang Rui
Cc: Gerd Hoffmann
Cc: "VMware Graphics"
Cc: Thomas Hellstrom
---
drivers/gpu/drm/ttm/ttm_bo.c | 36 ---
drivers/gpu/drm/ttm/ttm_bo_util.c | 1 -
drivers/gpu/drm/ttm/ttm_bo_vm.c | 18 +---
include/drm/ttm/ttm_bo_api.h | 4
4 files changed, 5 insertions(+), 54 deletions(-)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 20ff56f27aa4..d1ce5d315d5b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -162,7 +162,6 @@ static void ttm_bo_release_list(struct kref *list_kref)
dma_fence_put(bo->moving);
if (!ttm_bo_uses_embedded_gem_object(bo))
dma_resv_fini(&bo->base._resv);
- mutex_destroy(&bo->wu_mutex);
bo->destroy(bo);
ttm_mem_global_free(bdev->glob->mem_glob, acc_size);
}
@@ -1319,7 +1318,6 @@ int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
INIT_LIST_HEAD(&bo->ddestroy);
INIT_LIST_HEAD(&bo->swap);
INIT_LIST_HEAD(&bo->io_reserve_lru);
- mutex_init(&bo->wu_mutex);
bo->bdev = bdev;
bo->type = type;
bo->num_pages = num_pages;
@@ -1954,37 +1952,3 @@ void ttm_bo_swapout_all(struct ttm_bo_device *bdev)
;
}
EXPORT_SYMBOL(ttm_bo_swapout_all);
-
-/**
- * ttm_bo_wait_unreserved - interruptible wait for a buffer object to become
- * unreserved
- *
- * @bo: Pointer to buffer
- */
-int ttm_bo_wait_unreserved(struct ttm_buffer_object *bo)
-{
- int ret;
-
- /*
-* In the absense of a wait_unlocked API,
-* Use the bo::wu_mutex to avoid triggering livelocks due to
-* concurrent use of this function. Note that this use of
-* bo::wu_mutex can go away if we change locking order to
-* mmap_sem -> bo::reserve.
-*/
- ret = mutex_lock_interruptible(&bo->wu_mutex);
- if (unlikely(ret != 0))
- return -ERESTARTSYS;
- if (!dma_resv_is_locked(bo->base.resv))
- goto out_unlock;
- ret = dma_resv_lock_interruptible(bo->base.resv, NULL);
- if (ret == -EINTR)
- ret = -ERESTARTSYS;
- if (unlikely(ret != 0))
- goto out_unlock;
- dma_resv_unlock(bo->base.resv);
-
-out_unlock:
- mutex_unlock(&bo->wu_mutex);
- return ret;
-}
diff --git a/drivers/gpu/drm/ttm/ttm_bo_util.c
b/drivers/gpu/drm/ttm/ttm_bo_util.c
index fe81c565e7ef..82ea26a49959 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_util.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_util.c
@@ -508,7 +508,6 @@ static int ttm_buffer_object_transfer(struct
ttm_buffer_object *bo,
INIT_LIST_HEAD(&fbo->base.lru);
INIT_LIST_HEAD(&fbo->base.swap);
INIT_LIST_HEAD(&fbo->base.io_reserve_lru);
- mutex_init(&fbo->base.wu_mutex);
fbo->base.moving = NULL;
drm_vma_node_reset(&fbo->base.base.vma_node);
atomic_set(&fbo->base.cpu_writers, 0);
diff --git a/drivers/gpu/drm/ttm/ttm_bo_vm.c b/drivers/gpu/drm/ttm/ttm_bo_vm.c
index 76eedb963693..a61a35e57d1c 100644
--- a/drivers/gpu/drm/ttm/ttm_bo_vm.c
+++ b/drivers/gpu/drm/ttm/ttm_bo_vm.c
@@ -125,30 +125,22 @@ static vm_fault_t ttm_bo_vm_fault(struct vm_fault *vmf)
&bdev->man[bo->mem.mem_type];
struct vm_area_struct cvma;
- /*
-* Work around locking order reversal in fault / nopfn
-* between mmap_sem and bo_reserve: Perform a trylock operation
-* for reserve, and if it fails, retry the fault after waiting
-* for the buffer to become unreserved.
-*/
if (unlikely(!dma_resv_trylock(bo->base.resv))) {
if (vmf->flags & FAULT_FLAG_ALLOW_RETRY) {
if (!(vmf->flags & FAULT_FLAG_RETRY_NOWAIT)) {
ttm_bo_get(bo);
up_read(&vmf->vma->vm_mm->mmap_sem);
- (void) ttm_bo_wait_unreserved(bo);
+ if (!dma_resv_lock_interruptible(bo->base.resv,
+NULL))
+ dma_resv_unlock(bo->base.resv);
ttm_bo_put(bo);
}
return VM_FAULT_RETRY;
}
- /*
-* If we'd want to change locking order to
-* mmap_sem -> bo::reserve, we'd use a blocking reserve here
-* instead of retrying the fault...
-*/
- return V
Re: [Intel-gfx] [PATCH 4/4] mm, notifier: Catch sleeping/blocking for !blockable
On Tue, Aug 20, 2019 at 05:18:10PM +0200, Daniel Vetter wrote:
> On Tue, Aug 20, 2019 at 10:34:18AM -0300, Jason Gunthorpe wrote:
> > On Tue, Aug 20, 2019 at 10:19:02AM +0200, Daniel Vetter wrote:
> > > We need to make sure implementations don't cheat and don't have a
> > > possible schedule/blocking point deeply burried where review can't
> > > catch it.
> > >
> > > I'm not sure whether this is the best way to make sure all the
> > > might_sleep() callsites trigger, and it's a bit ugly in the code flow.
> > > But it gets the job done.
> > >
> > > Inspired by an i915 patch series which did exactly that, because the
> > > rules haven't been entirely clear to us.
> > >
> > > v2: Use the shiny new non_block_start/end annotations instead of
> > > abusing preempt_disable/enable.
> > >
> > > v3: Rebase on top of Glisse's arg rework.
> > >
> > > v4: Rebase on top of more Glisse rework.
> > >
> > > Cc: Jason Gunthorpe
> > > Cc: Andrew Morton
> > > Cc: Michal Hocko
> > > Cc: David Rientjes
> > > Cc: "Christian König"
> > > Cc: Daniel Vetter
> > > Cc: "Jérôme Glisse"
> > > Cc: linux...@kvack.org
> > > Reviewed-by: Christian König
> > > Reviewed-by: Jérôme Glisse
> > > Signed-off-by: Daniel Vetter
> > > mm/mmu_notifier.c | 8 +++-
> > > 1 file changed, 7 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> > > index 538d3bb87f9b..856636d06ee0 100644
> > > +++ b/mm/mmu_notifier.c
> > > @@ -181,7 +181,13 @@ int __mmu_notifier_invalidate_range_start(struct
> > > mmu_notifier_range *range)
> > > id = srcu_read_lock(&srcu);
> > > hlist_for_each_entry_rcu(mn, &range->mm->mmu_notifier_mm->list, hlist) {
> > > if (mn->ops->invalidate_range_start) {
> > > - int _ret = mn->ops->invalidate_range_start(mn, range);
> > > + int _ret;
> > > +
> > > + if (!mmu_notifier_range_blockable(range))
> > > + non_block_start();
> > > + _ret = mn->ops->invalidate_range_start(mn, range);
> > > + if (!mmu_notifier_range_blockable(range))
> > > + non_block_end();
> >
> > If someone Acks all the sched changes then I can pick this for
> > hmm.git, but I still think the existing pre-emption debugging is fine
> > for this use case.
>
> Ok, I'll ping Peter Z. for an ack, iirc he was involved.
>
> > Also, same comment as for the lockdep map, this needs to apply to the
> > non-blocking range_end also.
>
> Hm, I thought the page table locks we're holding there already prevent any
> sleeping, so would be redundant? But reading through code I think that's
> not guaranteed, so yeah makes sense to add it for invalidate_range_end
> too. I'll respin once I have the ack/nack from scheduler people.
So I started to look into this, and I'm a bit confused. There's no
_nonblock version of this, so does this means blocking is never allowed,
or always allowed?
From a quick look through implementations I've only seen spinlocks, and
one up_read. So I guess I should wrape this callback in some unconditional
non_block_start/end, but I'm not sure.
Thanks, Daniel
> > Anyhow, since this series has conflicts with hmm.git it would be best
> > to flow through the whole thing through that tree. If there are no
> > remarks on the first two patches I'll grab them in a few days.
>
> Thanks, Daniel
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
On Tue, Aug 20, 2019 at 02:56:36PM +, Koenig, Christian wrote:
> Am 20.08.19 um 16:53 schrieb Daniel Vetter:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >really no business holding struct_mutex while doing copy_*_user. But
> >I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >copying from/to userspace happens all in v3d_lookup_bos which is
> >outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >- vmw_execbuf_process: First this does some copies in
> > vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> > Then comes the usual ttm reserve/validate sequence, then actual
> > submission/fencing, then unreserving, and finally some more
> > copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> > details, but looks all safe.
> >- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> > seen, seems to only create a fence and copy it out.
> >- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> > found there.
> >Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >copying from userspace before even looking up objects through their
> >handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >qxl_process_single_command. There's a lovely comment before the
> >__copy_from_user_inatomic that the slowpath should be copied from
> >i915, but I guess that never happened. Try not to be unlucky and get
> >your CS data evicted between when it's written and the kernel tries
> >to read it. The only other copy_from_user is for relocs, but those
> >are done before qxl_release_reserve_list(), which seems to be the
> >only thing reserving buffers (in the ttm/dma_resv sense) in that
> >code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >everywhere and needs to be fixed up.
> >
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: Chris Wilson
> > Cc: Thomas Zimmermann
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Eric Anholt
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: Ben Skeggs
> > Cc: "VMware Graphics"
> > Cc: Thomas Hellstrom
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Christian König
Does this r-b just apply to radeon/amdgpu or for the full audit?
-Daniel
>
> > ---
> > drivers/dma-buf/dma-resv.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 42a8f3f11681..3edca10d3faf 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> >
> > #include
> > #include
> > +#include
> >
> > /**
> >* DOC: Reservation Object Overview
> > @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> > &reservation_seqcount_class);
> > RCU_INIT_POINTER(obj->fence, NULL);
> > RCU_INIT_POINTER(obj->fence_excl, NULL);
> > +
> > + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > + if (current->mm)
> > + down_read(¤t->mm->mmap_sem);
> > + ww_mutex_lock(&obj->lock, NULL);
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + fs_reclaim_release(GFP_KERNEL);
> > + ww_mutex_unlock(&obj->lock);
> > + if (current->mm)
> > + up_read(¤t->mm->mmap_sem);
> > + }
> > }
> > EXPORT_SYMBOL(dma_resv_init);
> >
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/5] drm/i915: Track ggtt fence reservations under its own mutex
We can reduce the locking for fence registers from the dev->struct_mutex
to a local mutex. We could introduce a mutex for the sole purpose of
tracking the fence acquisition, except there is a little bit of overlap
with the fault tracking, so use the i915_ggtt.mutex as it covers both.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 7 ++
drivers/gpu/drm/i915/gvt/aperture_gm.c | 10 +-
drivers/gpu/drm/i915/i915_debugfs.c | 5 +-
drivers/gpu/drm/i915/i915_gem_fence_reg.c| 108 ---
drivers/gpu/drm/i915/i915_gem_fence_reg.h| 2 +-
drivers/gpu/drm/i915/i915_vma.h | 4 +-
6 files changed, 87 insertions(+), 49 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
index 298c4d191439..a0098fc35921 100644
--- a/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/selftest_hangcheck.c
@@ -1157,7 +1157,14 @@ static int evict_fence(void *data)
goto out_unlock;
}
+ err = i915_vma_pin(arg->vma, 0, 0, PIN_GLOBAL | PIN_MAPPABLE);
+ if (err) {
+ pr_err("Unable to pin vma for Y-tiled fence; err:%d\n", err);
+ goto out_unlock;
+ }
+
err = i915_vma_pin_fence(arg->vma);
+ i915_vma_unpin(arg->vma);
if (err) {
pr_err("Unable to pin Y-tiled fence; err:%d\n", err);
goto out_unlock;
diff --git a/drivers/gpu/drm/i915/gvt/aperture_gm.c
b/drivers/gpu/drm/i915/gvt/aperture_gm.c
index c3d19d88da40..5ff2437b2998 100644
--- a/drivers/gpu/drm/i915/gvt/aperture_gm.c
+++ b/drivers/gpu/drm/i915/gvt/aperture_gm.c
@@ -172,14 +172,14 @@ static void free_vgpu_fence(struct intel_vgpu *vgpu)
intel_runtime_pm_get(&dev_priv->runtime_pm);
- mutex_lock(&dev_priv->drm.struct_mutex);
+ mutex_lock(&dev_priv->ggtt.vm.mutex);
_clear_vgpu_fence(vgpu);
for (i = 0; i < vgpu_fence_sz(vgpu); i++) {
reg = vgpu->fence.regs[i];
i915_unreserve_fence(reg);
vgpu->fence.regs[i] = NULL;
}
- mutex_unlock(&dev_priv->drm.struct_mutex);
+ mutex_unlock(&dev_priv->ggtt.vm.mutex);
intel_runtime_pm_put_unchecked(&dev_priv->runtime_pm);
}
@@ -195,7 +195,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
intel_runtime_pm_get(rpm);
/* Request fences from host */
- mutex_lock(&dev_priv->drm.struct_mutex);
+ mutex_lock(&dev_priv->ggtt.vm.mutex);
for (i = 0; i < vgpu_fence_sz(vgpu); i++) {
reg = i915_reserve_fence(dev_priv);
@@ -207,7 +207,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
_clear_vgpu_fence(vgpu);
- mutex_unlock(&dev_priv->drm.struct_mutex);
+ mutex_unlock(&dev_priv->ggtt.vm.mutex);
intel_runtime_pm_put_unchecked(rpm);
return 0;
out_free_fence:
@@ -220,7 +220,7 @@ static int alloc_vgpu_fence(struct intel_vgpu *vgpu)
i915_unreserve_fence(reg);
vgpu->fence.regs[i] = NULL;
}
- mutex_unlock(&dev_priv->drm.struct_mutex);
+ mutex_unlock(&dev_priv->ggtt.vm.mutex);
intel_runtime_pm_put_unchecked(rpm);
return -ENOSPC;
}
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b39226d7f8d2..f5d6702ec7df 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -652,10 +652,11 @@ static int i915_gem_fence_regs_info(struct seq_file *m,
void *data)
rcu_read_lock();
for (i = 0; i < i915->ggtt.num_fences; i++) {
- struct i915_vma *vma = i915->ggtt.fence_regs[i].vma;
+ struct i915_fence_reg *reg = &i915->ggtt.fence_regs[i];
+ struct i915_vma *vma = reg->vma;
seq_printf(m, "Fence %d, pin count = %d, object = ",
- i, i915->ggtt.fence_regs[i].pin_count);
+ i, atomic_read(®->pin_count));
if (!vma)
seq_puts(m, "unused");
else
diff --git a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
index c9654f1a468f..6a33a0bb97a9 100644
--- a/drivers/gpu/drm/i915/i915_gem_fence_reg.c
+++ b/drivers/gpu/drm/i915/i915_gem_fence_reg.c
@@ -299,15 +299,24 @@ static int fence_update(struct i915_fence_reg *fence,
*/
int i915_vma_put_fence(struct i915_vma *vma)
{
+ struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
struct i915_fence_reg *fence = vma->fence;
+ int err;
if (!fence)
return 0;
- if (fence->pin_count)
+ if (atomic_read(&fence->pin_count))
return -EBUSY;
- return fence_update(fence, NULL);
+ err = mutex_lock_interruptible(&ggtt->vm.mutex);
+ if (err)
+ return err;
+
+ err =
[Intel-gfx] [PATCH 2/5] drm/i915/gtt: Add some range asserts
These should have been validated in the upper layers, but for sanity's
sake, repeat them.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +++-
1 file changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b06d1d9054ba..0b81e0b64393 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -965,8 +965,10 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
const struct i915_page_scratch * const scratch = &vm->scratch[lvl];
unsigned int idx, len;
+ GEM_BUG_ON(end > vm->total >> GEN8_PTE_SHIFT);
+
len = gen8_pd_range(start, end, lvl--, &idx);
- DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d}\n",
+ DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d
}\n",
__func__, vm, lvl + 1, start, end,
idx, len, atomic_read(px_used(pd)));
GEM_BUG_ON(!len || len >= atomic_read(px_used(pd)));
@@ -992,7 +994,7 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
const vm,
u64 *vaddr;
count = gen8_pt_count(start, end);
- DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d,
len:%d, used:%d} removing pte\n",
+ DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d,
len:%d, used:%d } removing pte\n",
__func__, vm, lvl, start, end,
gen8_pd_index(start, 0), count,
atomic_read(&pt->used));
@@ -1020,6 +1022,7 @@ static void gen8_ppgtt_clear(struct i915_address_space
*vm,
{
GEM_BUG_ON(!IS_ALIGNED(start, BIT_ULL(GEN8_PTE_SHIFT)));
GEM_BUG_ON(!IS_ALIGNED(length, BIT_ULL(GEN8_PTE_SHIFT)));
+ GEM_BUG_ON(range_overflows(start, length, vm->total));
start >>= GEN8_PTE_SHIFT;
length >>= GEN8_PTE_SHIFT;
@@ -1031,15 +1034,17 @@ static void gen8_ppgtt_clear(struct i915_address_space
*vm,
static int __gen8_ppgtt_alloc(struct i915_address_space * const vm,
struct i915_page_directory * const pd,
- u64 * const start, u64 end, int lvl)
+ u64 * const start, const u64 end, int lvl)
{
const struct i915_page_scratch * const scratch = &vm->scratch[lvl];
struct i915_page_table *alloc = NULL;
unsigned int idx, len;
int ret = 0;
+ GEM_BUG_ON(end > vm->total >> GEN8_PTE_SHIFT);
+
len = gen8_pd_range(*start, end, lvl--, &idx);
- DBG("%s(%p):{lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d}\n",
+ DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d
}\n",
__func__, vm, lvl + 1, *start, end,
idx, len, atomic_read(px_used(pd)));
GEM_BUG_ON(!len || (idx + len - 1) >> gen8_pd_shift(1));
@@ -1105,7 +1110,7 @@ static int __gen8_ppgtt_alloc(struct i915_address_space *
const vm,
} else {
unsigned int count = gen8_pt_count(*start, end);
- DBG("%s(%p):{lvl:%d, start:%llx, end:%llx, idx:%d,
len:%d, used:%d} inserting pte\n",
+ DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d,
len:%d, used:%d } inserting pte\n",
__func__, vm, lvl, *start, end,
gen8_pd_index(*start, 0), count,
atomic_read(&pt->used));
@@ -1131,6 +1136,7 @@ static int gen8_ppgtt_alloc(struct i915_address_space *vm,
GEM_BUG_ON(!IS_ALIGNED(start, BIT_ULL(GEN8_PTE_SHIFT)));
GEM_BUG_ON(!IS_ALIGNED(length, BIT_ULL(GEN8_PTE_SHIFT)));
+ GEM_BUG_ON(range_overflows(start, length, vm->total));
start >>= GEN8_PTE_SHIFT;
length >>= GEN8_PTE_SHIFT;
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915/execlists: Set priority hint prior to submission
Since we now run process_csb() outside of the engine->active.lock, we
can process a CS-event immediately upon our ELSP write. As we currently
inspect the pending queue *after* the ELSP write, there is an
opportunity for a CS-event to update the pending queue before we can
read it, making ourselves chases an invalid pointer.
Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the irq-off
spinlock")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 44780e7fafec..d42584439f51 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1335,9 +1335,9 @@ static void execlists_dequeue(struct intel_engine_cs
*engine)
if (submit) {
*port = execlists_schedule_in(last, port - execlists->pending);
memset(port + 1, 0, (last_port - port) * sizeof(*port));
- execlists_submit_ports(engine);
execlists->switch_priority_hint =
switch_prio(engine, *execlists->pending);
+ execlists_submit_ports(engine);
} else {
ring_set_paused(engine, 0);
}
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Replace i915_vma_put_fence()
Avoid calling i915_vma_put_fence() by using our alternate paths that
bind a secondary vma avoiding the original fenced vma. For the few
instances where we need to release the fence (i.e. on binding when the
GGTT range becomes invalid), replace the put_fence with a revoke_fence.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/display/intel_overlay.c | 4 ---
drivers/gpu/drm/i915/gem/i915_gem_domain.c| 16 ++---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 9 ++---
drivers/gpu/drm/i915/i915_gem.c | 36 ---
drivers/gpu/drm/i915/i915_gem_fence_reg.c | 16 +++--
drivers/gpu/drm/i915/i915_vma.c | 4 ++-
drivers/gpu/drm/i915/i915_vma.h | 4 +--
7 files changed, 38 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index eca41c4a5aa6..29edfc343716 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -770,10 +770,6 @@ static int intel_overlay_do_put_image(struct intel_overlay
*overlay,
}
intel_frontbuffer_flush(new_bo->frontbuffer, ORIGIN_DIRTYFB);
- ret = i915_vma_put_fence(vma);
- if (ret)
- goto out_unpin;
-
if (!overlay->active) {
u32 oconfig;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index a1afc2690e9e..60134c5aefa7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -221,6 +221,8 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
* state and so involves less work.
*/
if (atomic_read(&obj->bind_count)) {
+ struct drm_i915_private *i915 = to_i915(obj->base.dev);
+
/* Before we change the PTE, the GPU must not be accessing it.
* If we wait upon the object, we know that all the bound
* VMA are no longer active.
@@ -232,8 +234,7 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
if (ret)
return ret;
- if (!HAS_LLC(to_i915(obj->base.dev)) &&
- cache_level != I915_CACHE_NONE) {
+ if (!HAS_LLC(i915) && cache_level != I915_CACHE_NONE) {
/* Access to snoopable pages through the GTT is
* incoherent and on some machines causes a hard
* lockup. Relinquish the CPU mmaping to force
@@ -241,6 +242,10 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
* then double check if the GTT mapping is still
* valid for that pointer access.
*/
+ ret = mutex_lock_interruptible(&i915->ggtt.vm.mutex);
+ if (ret)
+ return ret;
+
i915_gem_object_release_mmap(obj);
/* As we no longer need a fence for GTT access,
@@ -251,10 +256,13 @@ int i915_gem_object_set_cache_level(struct
drm_i915_gem_object *obj,
* supposed to be linear.
*/
for_each_ggtt_vma(vma, obj) {
- ret = i915_vma_put_fence(vma);
+ ret = i915_vma_revoke_fence(vma);
if (ret)
- return ret;
+ break;
}
+ mutex_unlock(&i915->ggtt.vm.mutex);
+ if (ret)
+ return ret;
} else {
/* We either have incoherent backing store and
* so no GTT access or the architecture is fully
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 2dca2962c73a..b5f6937369ea 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1024,6 +1024,9 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
struct i915_vma *vma;
int err;
+ if (i915_gem_object_is_tiled(obj))
+ return ERR_PTR(-EINVAL);
+
if (use_cpu_reloc(cache, obj))
return NULL;
@@ -1047,12 +1050,6 @@ static void *reloc_iomap(struct drm_i915_gem_object *obj,
if (err) /* no inactive aperture space, use cpu reloc */
return NULL;
} else {
- err = i915_vma_put_fence(vma);
- if (err) {
- i915_vma_unpin(vma);
- return ERR_PTR(err);
-
[Intel-gfx] [PATCH 4/5] drm/i915: Pull obj->userfault tracking under the ggtt->mutex
Since we want to revoke the ggtt vma from only under the ggtt->mutex, we
need to move protection of the userfault tracking from the struct_mutex
to the ggtt->mutex.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 10 +++---
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c | 4 +++-
3 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index dba5dd779149..595539a09e38 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -306,14 +306,17 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
if (ret)
goto err_fence;
- /* Mark as being mmapped into userspace for later revocation */
assert_rpm_wakelock_held(rpm);
+
+ /* Mark as being mmapped into userspace for later revocation */
+ mutex_lock(&i915->ggtt.vm.mutex);
if (!i915_vma_set_userfault(vma) && !obj->userfault_count++)
list_add(&obj->userfault_link, &i915->ggtt.userfault_list);
+ mutex_unlock(&i915->ggtt.vm.mutex);
+
if (CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND)
intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
- GEM_BUG_ON(!obj->userfault_count);
i915_vma_set_ggtt_write(vma);
@@ -408,8 +411,8 @@ void i915_gem_object_release_mmap(struct
drm_i915_gem_object *obj)
* requirement that operations to the GGTT be made holding the RPM
* wakeref.
*/
- lockdep_assert_held(&i915->drm.struct_mutex);
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
+ mutex_lock(&i915->ggtt.vm.mutex);
if (!obj->userfault_count)
goto out;
@@ -426,6 +429,7 @@ void i915_gem_object_release_mmap(struct
drm_i915_gem_object *obj)
wmb();
out:
+ mutex_unlock(&i915->ggtt.vm.mutex);
intel_runtime_pm_put(&i915->runtime_pm, wakeref);
}
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index f5d6702ec7df..b0f51591f2e4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -94,7 +94,7 @@ static char get_tiling_flag(struct drm_i915_gem_object *obj)
static char get_global_flag(struct drm_i915_gem_object *obj)
{
- return obj->userfault_count ? 'g' : ' ';
+ return READ_ONCE(obj->userfault_count) ? 'g' : ' ';
}
static char get_pin_mapped_flag(struct drm_i915_gem_object *obj)
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 79f9d1fb7611..9840cb2f70b9 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -864,7 +864,7 @@ void i915_vma_revoke_mmap(struct i915_vma *vma)
struct drm_vma_offset_node *node = &vma->obj->base.vma_node;
u64 vma_offset;
- lockdep_assert_held(&vma->vm->i915->drm.struct_mutex);
+ lockdep_assert_held(&vma->vm->mutex);
if (!i915_vma_has_userfault(vma))
return;
@@ -987,7 +987,9 @@ int i915_vma_unbind(struct i915_vma *vma)
return ret;
/* Force a pagefault for domain tracking on next user access */
+ mutex_lock(&vma->vm->mutex);
i915_vma_revoke_mmap(vma);
+ mutex_unlock(&vma->vm->mutex);
__i915_vma_iounmap(vma);
vma->flags &= ~I915_VMA_CAN_FENCE;
--
2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/execlists: Set priority hint prior to submission
Chris Wilson writes:
> Since we now run process_csb() outside of the engine->active.lock, we
> can process a CS-event immediately upon our ELSP write. As we currently
> inspect the pending queue *after* the ELSP write, there is an
> opportunity for a CS-event to update the pending queue before we can
> read it, making ourselves chases an invalid pointer.
>
> Fixes: df403069029d ("drm/i915/execlists: Lift process_csb() out of the
> irq-off spinlock")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index 44780e7fafec..d42584439f51 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1335,9 +1335,9 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> if (submit) {
> *port = execlists_schedule_in(last, port - execlists->pending);
> memset(port + 1, 0, (last_port - port) * sizeof(*port));
> - execlists_submit_ports(engine);
> execlists->switch_priority_hint =
> switch_prio(engine, *execlists->pending);
> + execlists_submit_ports(engine);
> } else {
> ring_set_paused(engine, 0);
> }
> --
> 2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFC/T: dma_resv vs. mmap_sem (rev2)
== Series Details == Series: RFC/T: dma_resv vs. mmap_sem (rev2) URL : https://patchwork.freedesktop.org/series/65488/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3166313498da dma_resv: prime lockdep annotations -:65: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" ' might be better as 'VMware Graphics ' #65: Cc: "VMware Graphics" -:99: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 24 lines checked 7c35577035f8 drm/nouveau: slowpath for pushbuf ioctl -:153: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 1 warnings, 0 checks, 122 lines checked e00626825d81 drm/ttm: remove ttm_bo_wait_unreserved -:24: WARNING:BAD_SIGN_OFF: email address '"VMware Graphics" ' might be better as 'VMware Graphics ' #24: Cc: "VMware Graphics" -:165: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Daniel Vetter ' total: 0 errors, 2 warnings, 0 checks, 81 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/gtt: Add some range asserts
Chris Wilson writes:
> These should have been validated in the upper layers, but for sanity's
> sake, repeat them.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +++-
> 1 file changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index b06d1d9054ba..0b81e0b64393 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -965,8 +965,10 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space
> * const vm,
> const struct i915_page_scratch * const scratch = &vm->scratch[lvl];
> unsigned int idx, len;
>
> + GEM_BUG_ON(end > vm->total >> GEN8_PTE_SHIFT);
I am having thoughts to clean all underlying handling to
use page indexes consistently...
Reviewed-by: Mika Kuoppala
> +
> len = gen8_pd_range(start, end, lvl--, &idx);
> - DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d}\n",
> + DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d
> }\n",
> __func__, vm, lvl + 1, start, end,
> idx, len, atomic_read(px_used(pd)));
> GEM_BUG_ON(!len || len >= atomic_read(px_used(pd)));
> @@ -992,7 +994,7 @@ static u64 __gen8_ppgtt_clear(struct i915_address_space *
> const vm,
> u64 *vaddr;
>
> count = gen8_pt_count(start, end);
> - DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d,
> len:%d, used:%d} removing pte\n",
> + DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d,
> len:%d, used:%d } removing pte\n",
> __func__, vm, lvl, start, end,
> gen8_pd_index(start, 0), count,
> atomic_read(&pt->used));
> @@ -1020,6 +1022,7 @@ static void gen8_ppgtt_clear(struct i915_address_space
> *vm,
> {
> GEM_BUG_ON(!IS_ALIGNED(start, BIT_ULL(GEN8_PTE_SHIFT)));
> GEM_BUG_ON(!IS_ALIGNED(length, BIT_ULL(GEN8_PTE_SHIFT)));
> + GEM_BUG_ON(range_overflows(start, length, vm->total));
>
> start >>= GEN8_PTE_SHIFT;
> length >>= GEN8_PTE_SHIFT;
> @@ -1031,15 +1034,17 @@ static void gen8_ppgtt_clear(struct
> i915_address_space *vm,
>
> static int __gen8_ppgtt_alloc(struct i915_address_space * const vm,
> struct i915_page_directory * const pd,
> - u64 * const start, u64 end, int lvl)
> + u64 * const start, const u64 end, int lvl)
> {
> const struct i915_page_scratch * const scratch = &vm->scratch[lvl];
> struct i915_page_table *alloc = NULL;
> unsigned int idx, len;
> int ret = 0;
>
> + GEM_BUG_ON(end > vm->total >> GEN8_PTE_SHIFT);
> +
> len = gen8_pd_range(*start, end, lvl--, &idx);
> - DBG("%s(%p):{lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d}\n",
> + DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d, len:%d, used:%d
> }\n",
> __func__, vm, lvl + 1, *start, end,
> idx, len, atomic_read(px_used(pd)));
> GEM_BUG_ON(!len || (idx + len - 1) >> gen8_pd_shift(1));
> @@ -1105,7 +1110,7 @@ static int __gen8_ppgtt_alloc(struct i915_address_space
> * const vm,
> } else {
> unsigned int count = gen8_pt_count(*start, end);
>
> - DBG("%s(%p):{lvl:%d, start:%llx, end:%llx, idx:%d,
> len:%d, used:%d} inserting pte\n",
> + DBG("%s(%p):{ lvl:%d, start:%llx, end:%llx, idx:%d,
> len:%d, used:%d } inserting pte\n",
> __func__, vm, lvl, *start, end,
> gen8_pd_index(*start, 0), count,
> atomic_read(&pt->used));
> @@ -1131,6 +1136,7 @@ static int gen8_ppgtt_alloc(struct i915_address_space
> *vm,
>
> GEM_BUG_ON(!IS_ALIGNED(start, BIT_ULL(GEN8_PTE_SHIFT)));
> GEM_BUG_ON(!IS_ALIGNED(length, BIT_ULL(GEN8_PTE_SHIFT)));
> + GEM_BUG_ON(range_overflows(start, length, vm->total));
>
> start >>= GEN8_PTE_SHIFT;
> length >>= GEN8_PTE_SHIFT;
> --
> 2.23.0.rc1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> > Full audit of everyone:
> >
> > - i915, radeon, amdgpu should be clean per their maintainers.
> >
> > - vram helpers should be fine, they don't do command submission, so
> >really no business holding struct_mutex while doing copy_*_user. But
> >I haven't checked them all.
> >
> > - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >looks clean.
> >
> > - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >copying from/to userspace happens all in v3d_lookup_bos which is
> >outside of the critical section.
> >
> > - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >- vmw_execbuf_process: First this does some copies in
> > vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> > Then comes the usual ttm reserve/validate sequence, then actual
> > submission/fencing, then unreserving, and finally some more
> > copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> > details, but looks all safe.
> >- vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> > seen, seems to only create a fence and copy it out.
> >- a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> > found there.
> >Summary: vmwgfx seems to be fine too.
> >
> > - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >copying from userspace before even looking up objects through their
> >handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >
> > - qxl only has qxl_execbuffer_ioctl, which calls into
> >qxl_process_single_command. There's a lovely comment before the
> >__copy_from_user_inatomic that the slowpath should be copied from
> >i915, but I guess that never happened. Try not to be unlucky and get
> >your CS data evicted between when it's written and the kernel tries
> >to read it. The only other copy_from_user is for relocs, but those
> >are done before qxl_release_reserve_list(), which seems to be the
> >only thing reserving buffers (in the ttm/dma_resv sense) in that
> >code. So looks safe.
> >
> > - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >everywhere and needs to be fixed up.
> >
> > Cc: Alex Deucher
> > Cc: Christian König
> > Cc: Chris Wilson
> > Cc: Thomas Zimmermann
> > Cc: Rob Herring
> > Cc: Tomeu Vizoso
> > Cc: Eric Anholt
> > Cc: Dave Airlie
> > Cc: Gerd Hoffmann
> > Cc: Ben Skeggs
> > Cc: "VMware Graphics"
> > Cc: Thomas Hellstrom
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/dma-buf/dma-resv.c | 12
> > 1 file changed, 12 insertions(+)
> >
> > diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> > index 42a8f3f11681..3edca10d3faf 100644
> > --- a/drivers/dma-buf/dma-resv.c
> > +++ b/drivers/dma-buf/dma-resv.c
> > @@ -34,6 +34,7 @@
> > #include
> > #include
> > +#include
> > /**
> >* DOC: Reservation Object Overview
> > @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> > &reservation_seqcount_class);
> > RCU_INIT_POINTER(obj->fence, NULL);
> > RCU_INIT_POINTER(obj->fence_excl, NULL);
> > +
> > + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> > + if (current->mm)
> > + down_read(¤t->mm->mmap_sem);
> > + ww_mutex_lock(&obj->lock, NULL);
> > + fs_reclaim_acquire(GFP_KERNEL);
> > + fs_reclaim_release(GFP_KERNEL);
> > + ww_mutex_unlock(&obj->lock);
> > + if (current->mm)
> > + up_read(¤t->mm->mmap_sem);
> > + }
> > }
> > EXPORT_SYMBOL(dma_resv_init);
>
> I assume if this would have been easily done and maintainable using only
> lockdep annotation instead of actually acquiring the locks, that would have
> been done?
There's might_lock(), plus a pile of macros, but they don't map obviuosly,
so pretty good chances I accidentally end up with the wrong type of
annotation. Easier to just take the locks quickly, and stuff that all into
a lockdep-only section to avoid overhead.
> Otherwise LGTM.
>
> Reviewed-by: Thomas Hellström
>
> Will test this and let you know if it trips on vmwgfx, but it really
> shouldn't.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for RFC/T: dma_resv vs. mmap_sem (rev2)
== Series Details == Series: RFC/T: dma_resv vs. mmap_sem (rev2) URL : https://patchwork.freedesktop.org/series/65488/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6755 -> Patchwork_14124 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14124 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14124, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14124: ### IGT changes ### Possible regressions * igt@gem_exec_reloc@basic-gtt: - fi-hsw-4770:[PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-hsw-4770/igt@gem_exec_re...@basic-gtt.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-hsw-4770/igt@gem_exec_re...@basic-gtt.html - fi-byt-j1900: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-byt-j1900/igt@gem_exec_re...@basic-gtt.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-byt-j1900/igt@gem_exec_re...@basic-gtt.html - fi-blb-e6850: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-blb-e6850/igt@gem_exec_re...@basic-gtt.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-blb-e6850/igt@gem_exec_re...@basic-gtt.html - fi-skl-6260u: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-6260u/igt@gem_exec_re...@basic-gtt.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-skl-6260u/igt@gem_exec_re...@basic-gtt.html - fi-cml-u2: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-cml-u2/igt@gem_exec_re...@basic-gtt.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-cml-u2/igt@gem_exec_re...@basic-gtt.html - fi-ivb-3770:[PASS][11] -> [DMESG-WARN][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-ivb-3770/igt@gem_exec_re...@basic-gtt.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-ivb-3770/igt@gem_exec_re...@basic-gtt.html - fi-skl-6600u: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-6600u/igt@gem_exec_re...@basic-gtt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-skl-6600u/igt@gem_exec_re...@basic-gtt.html - fi-kbl-x1275: [PASS][15] -> [DMESG-WARN][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-kbl-x1275/igt@gem_exec_re...@basic-gtt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-kbl-x1275/igt@gem_exec_re...@basic-gtt.html - fi-apl-guc: [PASS][17] -> [DMESG-WARN][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-apl-guc/igt@gem_exec_re...@basic-gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-apl-guc/igt@gem_exec_re...@basic-gtt.html - fi-glk-dsi: [PASS][19] -> [DMESG-WARN][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-glk-dsi/igt@gem_exec_re...@basic-gtt.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-glk-dsi/igt@gem_exec_re...@basic-gtt.html - fi-kbl-guc: [PASS][21] -> [DMESG-WARN][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-kbl-guc/igt@gem_exec_re...@basic-gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-kbl-guc/igt@gem_exec_re...@basic-gtt.html - fi-gdg-551: [PASS][23] -> [DMESG-WARN][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-gdg-551/igt@gem_exec_re...@basic-gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-gdg-551/igt@gem_exec_re...@basic-gtt.html - fi-kbl-7500u: [PASS][25] -> [DMESG-WARN][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-kbl-7500u/igt@gem_exec_re...@basic-gtt.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-kbl-7500u/igt@gem_exec_re...@basic-gtt.html - fi-whl-u: [PASS][27] -> [DMESG-WARN][28] [27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-whl-u/igt@gem_exec_re...@basic-gtt.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14124/fi-whl-u/igt@gem_exec_re...@basic-gtt.html - fi-skl-iommu: [PASS][29] -> [DMESG-WARN][30] [29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6755/fi-skl-iommu/igt@gem_exec_re...@basic-gtt.html [30]: https://intel-gfx-ci.01.org/tree
Re: [Intel-gfx] [PATCH 2/5] drm/i915/gtt: Add some range asserts
Quoting Mika Kuoppala (2019-08-21 17:24:05) > Chris Wilson writes: > > > These should have been validated in the upper layers, but for sanity's > > sake, repeat them. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_gem_gtt.c | 16 +++- > > 1 file changed, 11 insertions(+), 5 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c > > b/drivers/gpu/drm/i915/i915_gem_gtt.c > > index b06d1d9054ba..0b81e0b64393 100644 > > --- a/drivers/gpu/drm/i915/i915_gem_gtt.c > > +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c > > @@ -965,8 +965,10 @@ static u64 __gen8_ppgtt_clear(struct > > i915_address_space * const vm, > > const struct i915_page_scratch * const scratch = &vm->scratch[lvl]; > > unsigned int idx, len; > > > > + GEM_BUG_ON(end > vm->total >> GEN8_PTE_SHIFT); > > I am having thoughts to clean all underlying handling to > use page indexes consistently... I would agree, pfn throughout does make a certain sense for the page directory trees. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest (rev2) URL : https://patchwork.freedesktop.org/series/65450/ State : success == Summary == CI Bug Log - changes from CI_DRM_6750_full -> Patchwork_14115_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14115_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +3 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@preempt-queue-chain-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +13 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb4/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-iclb5/igt@gem_exec_sched...@preempt-queue-chain-bsd2.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][5] -> [DMESG-WARN][6] ([fdo#108686]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-glk3/igt@gem_tiled_swapp...@non-threaded.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-glk1/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_pm_backlight@fade_with_suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl4/igt@i915_pm_backlight@fade_with_suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-skl8/igt@i915_pm_backlight@fade_with_suspend.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl5/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-skl3/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl3/igt@kms_f...@flip-vs-suspend-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-apl6/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-offscren-pri-shrfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-offscren-pri-shrfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@kms_vblank@pipe-c-ts-continuation-modeset-hang: - shard-glk: [PASS][19] -> [INCOMPLETE][20] ([fdo#103359] / [k.org#198133]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-glk5/igt@kms_vbl...@pipe-c-ts-continuation-modeset-hang.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-glk3/igt@kms_vbl...@pipe-c-ts-continuation-modeset-hang.html * igt@perf_pmu@busy-start-bcs0: - shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([fdo#107713]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@perf_...@busy-start-bcs0.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14115/shard-iclb4/igt@perf_...@busy-start-bcs0.html Possible fixes * igt@gem_ctx_shared@exec-shared-gtt-bsd2: - shard-iclb: [SKIP][23] ([fdo#109276]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb3/igt@gem_ctx_sha...@exec-shared-gtt-bsd2.html [24]: htt
Re: [Intel-gfx] [PATCH v4 2/2] drm/i915: add syncobj timeline support
On Wed, Aug 21, 2019 at 8:12 AM Lionel Landwerlin <
lionel.g.landwer...@intel.com> wrote:
> Introduces a new parameters to execbuf so that we can specify syncobj
> handles as well as timeline points.
>
> v2: Reuse i915_user_extension_fn
>
> v3: Check that the chained extension is only present once (Chris)
>
> v4: Check that dma_fence_chain_find_seqno returns a non NULL fence (Lionel)
>
> v5: Use BIT_ULL (Chris)
>
> v6: Fix issue with already signaled timeline points,
> dma_fence_chain_find_seqno() setting fence to NULL (Chris)
>
> v7: Report ENOENT with invalid syncobj handle (Lionel)
>
> v8: Check for out of order timeline point insertion (Chris)
>
> v9: After explanations on
>
> https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
> drop the ordering check from v8 (Lionel)
>
> Signed-off-by: Lionel Landwerlin
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 307 ++
> drivers/gpu/drm/i915/i915_drv.c | 3 +-
> drivers/gpu/drm/i915/i915_getparam.c | 1 +
> include/uapi/drm/i915_drm.h | 39 +++
> 4 files changed, 293 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> index 8d1946556bc0..6d5a234f9f9b 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> @@ -214,6 +214,13 @@ enum {
> * the batchbuffer in trusted mode, otherwise the ioctl is rejected.
> */
>
> +struct i915_eb_fences {
> + struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
> + struct dma_fence *dma_fence;
> + u64 value;
> + struct dma_fence_chain *chain_fence;
> +};
> +
> struct i915_execbuffer {
> struct drm_i915_private *i915; /** i915 backpointer */
> struct drm_file *file; /** per-file lookup tables and limits */
> @@ -275,6 +282,7 @@ struct i915_execbuffer {
>
> struct {
> u64 flags; /** Available extensions parameters */
> + struct drm_i915_gem_execbuffer_ext_timeline_fences
> timeline_fences;
> } extensions;
> };
>
> @@ -2295,67 +2303,217 @@ eb_pin_engine(struct i915_execbuffer *eb,
> }
>
> static void
> -__free_fence_array(struct drm_syncobj **fences, unsigned int n)
> +__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
> {
> - while (n--)
> - drm_syncobj_put(ptr_mask_bits(fences[n], 2));
> + while (n--) {
> + drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
> + dma_fence_put(fences[n].dma_fence);
> + kfree(fences[n].chain_fence);
> + }
> kvfree(fences);
> }
>
> -static struct drm_syncobj **
> -get_fence_array(struct drm_i915_gem_execbuffer2 *args,
> - struct drm_file *file)
> +static struct i915_eb_fences *
> +get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
> {
> - const unsigned long nfences = args->num_cliprects;
> + struct drm_i915_gem_execbuffer_ext_timeline_fences
> *timeline_fences =
> + &eb->extensions.timeline_fences;
> + struct drm_i915_gem_exec_fence __user *user_fences;
> + struct i915_eb_fences *fences;
> + u64 __user *user_values;
> + u64 num_fences, num_user_fences = timeline_fences->fence_count;
> + unsigned long n;
> + int err;
> +
> + /* Check multiplication overflow for access_ok() and
> kvmalloc_array() */
> + BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
> + if (num_user_fences > min_t(unsigned long,
> + ULONG_MAX / sizeof(*user_fences),
> + SIZE_MAX / sizeof(*fences)))
> + return ERR_PTR(-EINVAL);
> +
> + user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
> + if (!access_ok(user_fences, num_user_fences *
> sizeof(*user_fences)))
> + return ERR_PTR(-EFAULT);
> +
> + user_values = u64_to_user_ptr(timeline_fences->values_ptr);
> + if (!access_ok(user_values, num_user_fences *
> sizeof(*user_values)))
> + return ERR_PTR(-EFAULT);
> +
> + fences = kvmalloc_array(num_user_fences, sizeof(*fences),
> + __GFP_NOWARN | GFP_KERNEL);
> + if (!fences)
> + return ERR_PTR(-ENOMEM);
> +
> + BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
> +~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
> +
> + for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++)
> {
> + struct drm_i915_gem_exec_fence user_fence;
> + struct drm_syncobj *syncobj;
> + struct dma_fence *fence = NULL;
> + u64 point;
> +
> + if (__copy_from_user(&user_fence, user_fences++,
> sizeof(user_fence))) {
> + err = -EFAULT;
> + goto err;
> +
Re: [Intel-gfx] [PATCH 01/10] drm/i915/dp: Fix dsc bpp calculations.
On Wed, Aug 21, 2019 at 03:32:12PM +0200, Maarten Lankhorst wrote:
> There was a integer wraparound when mode_clock became too high,
> and we didn't correct for the FEC overhead factor when dividing,
> also the calculations would break at HBR3.
But the mode_clock is obtained from the adusted_mode->crtc_clock which is
defined as an int in drm_mode_config struct, does that need to change also?
>
> As a result our calculated bpp was way too high, and the link width
> bpp limitation never came into effect.
>
> Print out the resulting bpp calcululations as a sanity check, just
> in case we ever have to debug it later on again.
>
> Signed-off-by: Maarten Lankhorst
> Fixes: d9218c8f6cf4 ("drm/i915/dp: Add helpers for Compressed BPP and Slice
> Count for DSC")
> Cc: # v5.0+
> Cc: Manasi Navare
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 16 +---
> drivers/gpu/drm/i915/display/intel_dp.h | 4 ++--
> 2 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 921ad0a2f7ba..614a25911f07 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4323,10 +4323,10 @@ intel_dp_get_sink_irq_esi(struct intel_dp *intel_dp,
> u8 *sink_irq_vector)
> DP_DPRX_ESI_LEN;
> }
>
> -u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count,
> - int mode_clock, int mode_hdisplay)
> +u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u8 lane_count,
> + u32 mode_clock, u32 mode_hdisplay)
> {
> - u16 bits_per_pixel, max_bpp_small_joiner_ram;
> + u32 bits_per_pixel, max_bpp_small_joiner_ram;
But bits_per_pixel is a 16 bit value for DSC PPS, why does this need to be u32?
> int i;
>
> /*
> @@ -4335,13 +4335,14 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8
> lane_count,
>* FECOverhead = 2.4%, for SST -> TimeSlotsPerMTP is 1,
>* for MST -> TimeSlotsPerMTP has to be calculated
>*/
> - bits_per_pixel = (link_clock * lane_count * 8 *
> - DP_DSC_FEC_OVERHEAD_FACTOR) /
> - mode_clock;
> + bits_per_pixel = div_u64((u64)link_clock * lane_count * 8 *
> + DP_DSC_FEC_OVERHEAD_FACTOR, 1000ULL *
> mode_clock);
Thanks for catching this, this had the 1000 in the denominator in my original
patches :https://patchwork.freedesktop.org/series/47514/#rev3
And then the nex rev lost it somehow, so thanks for catching this
Manasi
> + DRM_DEBUG_KMS("Max link bpp: %u\n", bits_per_pixel);
>
> /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
> max_bpp_small_joiner_ram = DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER /
> mode_hdisplay;
> + DRM_DEBUG_KMS("Max small joiner bpp: %u\n", max_bpp_small_joiner_ram);
>
> /*
>* Greatest allowed DSC BPP = MIN (output BPP from avaialble Link BW
> @@ -4351,7 +4352,8 @@ u16 intel_dp_dsc_get_output_bpp(int link_clock, u8
> lane_count,
>
> /* Error out if the max bpp is less than smallest allowed valid bpp */
> if (bits_per_pixel < valid_dsc_bpp[0]) {
> - DRM_DEBUG_KMS("Unsupported BPP %d\n", bits_per_pixel);
> + DRM_DEBUG_KMS("Unsupported BPP %u, min %u\n",
> + bits_per_pixel, valid_dsc_bpp[0]);
> return 0;
> }
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.h
> b/drivers/gpu/drm/i915/display/intel_dp.h
> index 657bbb1f5ed0..007d1981a33b 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.h
> +++ b/drivers/gpu/drm/i915/display/intel_dp.h
> @@ -102,8 +102,8 @@ bool intel_dp_source_supports_hbr2(struct intel_dp
> *intel_dp);
> bool intel_dp_source_supports_hbr3(struct intel_dp *intel_dp);
> bool
> intel_dp_get_link_status(struct intel_dp *intel_dp, u8 *link_status);
> -u16 intel_dp_dsc_get_output_bpp(int link_clock, u8 lane_count,
> - int mode_clock, int mode_hdisplay);
> +u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u8 lane_count,
> + u32 mode_clock, u32 mode_hdisplay);
> u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp, int mode_clock,
> int mode_hdisplay);
>
> --
> 2.20.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Don't deballoon unused ggtt drm_mm_node in linux guest
Quoting Zhenyu Wang (2019-08-21 04:35:56)
> On 2019.08.20 13:46:17 +0800, Xiong Zhang wrote:
> > The following call trace may exist in linux guest dmesg when guest i915
> > driver is unloaded.
> > [ 90.776610] [drm:vgt_deballoon_space.isra.0 [i915]] deballoon space:
> > range [0x0 - 0x0] 0 KiB.
> > [ 90.776621] BUG: unable to handle kernel NULL pointer dereference at
> > 00c0
> > [ 90.776691] IP: drm_mm_remove_node+0x4d/0x320 [drm]
> > [ 90.776718] PGD 80012c7d0067 P4D 80012c7d0067 PUD 138e4c067 PMD 0
> > [ 90.777091] task: 9adab60f2f00 task.stack: af39c0fe
> > [ 90.777142] RIP: 0010:drm_mm_remove_node+0x4d/0x320 [drm]
> > [ 90.777573] Call Trace:
> > [ 90.777653] intel_vgt_deballoon+0x4c/0x60 [i915]
> > [ 90.29] i915_ggtt_cleanup_hw+0x121/0x190 [i915]
> > [ 90.92] i915_driver_unload+0x145/0x180 [i915]
> > [ 90.777856] i915_pci_remove+0x15/0x20 [i915]
> > [ 90.777890] pci_device_remove+0x3b/0xc0
> > [ 90.777916] device_release_driver_internal+0x157/0x220
> > [ 90.777945] driver_detach+0x39/0x70
> > [ 90.777967] bus_remove_driver+0x51/0xd0
> > [ 90.777990] pci_unregister_driver+0x23/0x90
> > [ 90.778019] SyS_delete_module+0x1da/0x240
> > [ 90.778045] entry_SYSCALL_64_fastpath+0x24/0x87
> > [ 90.778072] RIP: 0033:0x7f34312af067
> > [ 90.778092] RSP: 002b:7ffdea3da0d8 EFLAGS: 0206
> > [ 90.778297] RIP: drm_mm_remove_node+0x4d/0x320 [drm] RSP:
> > af39c0fe3dc0
> > [ 90.778344] ---[ end trace f4b1bc8305fc59dd ]---
> >
> > Four drm_mm_node are used to reserve guest ggtt space, but some of them
> > may be skipped and not initialised due to space constraints in
> > intel_vgt_balloon(). If drm_mm_remove_node() is called with
> > uninitialized drm_mm_node, the above call trace occurs.
> >
> > This patch check drm_mm_node's validity before calling
> > drm_mm_remove_node().
> >
> > Fixes: ff8f797557c7("drm/i915: return the correct usable aperture size
> > under gvt environment")
> > Cc: sta...@vger.kernel.org
> > Signed-off-by: Xiong Zhang
> > ---
> > drivers/gpu/drm/i915/i915_vgpu.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> > b/drivers/gpu/drm/i915/i915_vgpu.c
> > index bf2b837..d2fd66f 100644
> > --- a/drivers/gpu/drm/i915/i915_vgpu.c
> > +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> > @@ -119,6 +119,9 @@ static struct _balloon_info_ bl_info;
> > static void vgt_deballoon_space(struct i915_ggtt *ggtt,
> > struct drm_mm_node *node)
> > {
> > + if (!node->allocated)
> > + return;
> > +
> > DRM_DEBUG_DRIVER("deballoon space: range [0x%llx - 0x%llx] %llu
> > KiB.\n",
> >node->start,
> >node->start + node->size,
>
> Searching shows this is pretty old one and also with r-b from Chris,
> but be ignored that nobody picked this up..
>
> I think I hit this once too and tried to fix it another way,
> but this looks simpler to me.
>
> Acked-by: Zhenyu Wang
Better late than never, I guess. Thanks for the patch and checking it
over, pushed.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/5] drm/i915: Use enum pipe instead of crtc index to track active pipes
From: Ville Syrjälä
We may need to eliminate the crtc->index == pipe assumptions from
the code to support arbitrary pipes being fused off. Start that by
switching some bitmasks over to using pipe instead of the crtc index.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_cdclk.c| 12 +--
drivers/gpu/drm/i915/display/intel_display.c | 20 +--
.../drm/i915/display/intel_display_types.h| 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/intel_pm.c | 20 +--
5 files changed, 29 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d0bc42e5039c..939088c7d814 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -2369,7 +2369,7 @@ static int vlv_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.logical.voltage_level =
vlv_calc_voltage_level(dev_priv, cdclk);
- if (!state->active_crtcs) {
+ if (!state->active_pipes) {
cdclk = vlv_calc_cdclk(dev_priv, state->cdclk.force_min_cdclk);
state->cdclk.actual.cdclk = cdclk;
@@ -2400,7 +2400,7 @@ static int bdw_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.logical.voltage_level =
bdw_calc_voltage_level(cdclk);
- if (!state->active_crtcs) {
+ if (!state->active_pipes) {
cdclk = bdw_calc_cdclk(state->cdclk.force_min_cdclk);
state->cdclk.actual.cdclk = cdclk;
@@ -2470,7 +2470,7 @@ static int skl_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.logical.voltage_level =
skl_calc_voltage_level(cdclk);
- if (!state->active_crtcs) {
+ if (!state->active_pipes) {
cdclk = skl_calc_cdclk(state->cdclk.force_min_cdclk, vco);
state->cdclk.actual.vco = vco;
@@ -2506,7 +2506,7 @@ static int bxt_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.logical.voltage_level =
bxt_calc_voltage_level(cdclk);
- if (!state->active_crtcs) {
+ if (!state->active_pipes) {
if (IS_GEMINILAKE(dev_priv)) {
cdclk = glk_calc_cdclk(state->cdclk.force_min_cdclk);
vco = glk_de_pll_vco(dev_priv, cdclk);
@@ -2544,7 +2544,7 @@ static int cnl_modeset_calc_cdclk(struct
intel_atomic_state *state)
max(cnl_calc_voltage_level(cdclk),
cnl_compute_min_voltage_level(state));
- if (!state->active_crtcs) {
+ if (!state->active_pipes) {
cdclk = cnl_calc_cdclk(state->cdclk.force_min_cdclk);
vco = cnl_cdclk_pll_vco(dev_priv, cdclk);
@@ -2578,7 +2578,7 @@ static int icl_modeset_calc_cdclk(struct
intel_atomic_state *state)
max(icl_calc_voltage_level(dev_priv, cdclk),
cnl_compute_min_voltage_level(state));
- if (!state->active_crtcs) {
+ if (!state->active_pipes) {
cdclk = icl_calc_cdclk(state->cdclk.force_min_cdclk, ref);
vco = icl_calc_cdclk_pll_vco(dev_priv, cdclk);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b51d1ceb8739..7b74df03a1ef 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7080,7 +7080,7 @@ static void intel_crtc_disable_noatomic(struct drm_crtc
*crtc,
intel_display_power_put_unchecked(dev_priv, domain);
intel_crtc->enabled_power_domains = 0;
- dev_priv->active_crtcs &= ~(1 << intel_crtc->pipe);
+ dev_priv->active_pipes &= ~BIT(intel_crtc->pipe);
dev_priv->min_cdclk[intel_crtc->pipe] = 0;
dev_priv->min_voltage_level[intel_crtc->pipe] = 0;
@@ -13452,7 +13452,7 @@ static int intel_modeset_checks(struct
intel_atomic_state *state)
state->cdclk.force_min_cdclk = dev_priv->cdclk.force_min_cdclk;
state->modeset = true;
- state->active_crtcs = dev_priv->active_crtcs;
+ state->active_pipes = dev_priv->active_pipes;
state->cdclk.logical = dev_priv->cdclk.logical;
state->cdclk.actual = dev_priv->cdclk.actual;
state->cdclk.pipe = INVALID_PIPE;
@@ -13460,12 +13460,12 @@ static int intel_modeset_checks(struct
intel_atomic_state *state)
for_each_oldnew_intel_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
if (new_crtc_state->base.active)
- state->active_crtcs |= 1 << i;
+ state->active_pipes |= BIT(crtc->pipe);
else
- state->active_crtcs &= ~(1 << i);
+ state->active_pipes &= ~BIT(crtc->pipe);
[Intel-gfx] [PATCH 3/5] drm/i915: Use enum pipe consistently
From: Ville Syrjälä
Replace all "int pipe"s with "enum pipe pipe"s to make it clear
what we're dealing with.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 42 +--
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_dvo.c | 2 +-
drivers/gpu/drm/i915/display/intel_lvds.c | 2 +-
drivers/gpu/drm/i915/display/vlv_dsi.c| 2 +-
drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
drivers/gpu/drm/i915/i915_irq.c | 11 ++---
drivers/gpu/drm/i915/intel_pm.c | 2 +-
8 files changed, 33 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 7b74df03a1ef..ea2915dde6ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -490,7 +490,7 @@ static const struct intel_limit intel_limits_bxt = {
/* WA Display #0827: Gen9:all */
static void
-skl_wa_827(struct drm_i915_private *dev_priv, int pipe, bool enable)
+skl_wa_827(struct drm_i915_private *dev_priv, enum pipe pipe, bool enable)
{
if (enable)
I915_WRITE(CLKGATE_DIS_PSL(pipe),
@@ -4421,7 +4421,7 @@ static void intel_fdi_normal_train(struct intel_crtc
*crtc)
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 temp;
@@ -4464,7 +4464,7 @@ static void ironlake_fdi_link_train(struct intel_crtc
*crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 temp, tries;
@@ -4565,7 +4565,7 @@ static void gen6_fdi_link_train(struct intel_crtc *crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 temp, i, retry;
@@ -4698,7 +4698,7 @@ static void ivb_manual_fdi_link_train(struct intel_crtc
*crtc,
{
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
i915_reg_t reg;
u32 temp, i, j;
@@ -4816,7 +4816,7 @@ static void ironlake_fdi_pll_enable(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(intel_crtc->base.dev);
- int pipe = intel_crtc->pipe;
+ enum pipe pipe = intel_crtc->pipe;
i915_reg_t reg;
u32 temp;
@@ -4853,7 +4853,7 @@ static void ironlake_fdi_pll_disable(struct intel_crtc
*intel_crtc)
{
struct drm_device *dev = intel_crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = intel_crtc->pipe;
+ enum pipe pipe = intel_crtc->pipe;
i915_reg_t reg;
u32 temp;
@@ -4884,7 +4884,7 @@ static void ironlake_fdi_disable(struct drm_crtc *crtc)
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
- int pipe = intel_crtc->pipe;
+ enum pipe pipe = intel_crtc->pipe;
i915_reg_t reg;
u32 temp;
@@ -5199,7 +5199,7 @@ static void ironlake_pch_enable(const struct
intel_atomic_state *state,
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
u32 temp;
assert_pch_transcoder_disabled(dev_priv, pipe);
@@ -5294,7 +5294,7 @@ static void lpt_pch_enable(const struct
intel_atomic_state *state,
lpt_enable_pch_transcoder(dev_priv, cpu_transcoder);
}
-static void cpt_verify_modeset(struct drm_device *dev, int pipe)
+static void cpt_verify_modeset(struct drm_device *dev, enum pipe pipe)
{
struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t dslreg = PIPEDSL(pipe);
@@ -5633,7 +5633,7 @@ static void ironlake_pfit_enable(const struct
intel_crtc_state *crtc_state)
{
struct intel_crtc *crtc = to_intel_crtc(crtc_state->base.crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
- int pipe = crtc->pipe;
+ enum pipe pipe = crtc->pipe;
if (crtc_state->pch_pfit.enabled) {
/* Force use of hard-coded filter coefficients
@@ -5746,7 +5746,7 @@ intel_post_enable_primary(struct drm_crtc *crtc,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_
[Intel-gfx] [PATCH 4/5] drm/i915: s/num_active_crtcs/num_active_pipes/
From: Ville Syrjälä
Set a good example and talk about pipes rather than crtcs.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d6bf5b64dd32..e86503023daf 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1490,7 +1490,7 @@ static void g4x_merge_wm(struct drm_i915_private
*dev_priv,
struct g4x_wm_values *wm)
{
struct intel_crtc *crtc;
- int num_active_crtcs = 0;
+ int num_active_pipes = 0;
wm->cxsr = true;
wm->hpll_en = true;
@@ -1509,10 +1509,10 @@ static void g4x_merge_wm(struct drm_i915_private
*dev_priv,
if (!wm_state->fbc_en)
wm->fbc_en = false;
- num_active_crtcs++;
+ num_active_pipes++;
}
- if (num_active_crtcs != 1) {
+ if (num_active_pipes != 1) {
wm->cxsr = false;
wm->hpll_en = false;
wm->fbc_en = false;
@@ -2098,7 +2098,7 @@ static void vlv_merge_wm(struct drm_i915_private
*dev_priv,
struct vlv_wm_values *wm)
{
struct intel_crtc *crtc;
- int num_active_crtcs = 0;
+ int num_active_pipes = 0;
wm->level = dev_priv->wm.max_level;
wm->cxsr = true;
@@ -2112,14 +2112,14 @@ static void vlv_merge_wm(struct drm_i915_private
*dev_priv,
if (!wm_state->cxsr)
wm->cxsr = false;
- num_active_crtcs++;
+ num_active_pipes++;
wm->level = min_t(int, wm->level, wm_state->num_levels - 1);
}
- if (num_active_crtcs != 1)
+ if (num_active_pipes != 1)
wm->cxsr = false;
- if (num_active_crtcs > 1)
+ if (num_active_pipes > 1)
wm->level = VLV_WM_LEVEL_PM2;
for_each_intel_crtc(&dev_priv->drm, crtc) {
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/5] drm/i915: Use hweight8() for 8bit masks
From: Ville Syrjälä
Use hweight8() instead of hweight32() for 8bit masks. Doesn't actually
matter for us since the arch code will go for hweight32() anyway, but
maybe we stil want to do this for documentation purposes?
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_pm.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index e86503023daf..b6089545c8fa 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -1327,8 +1327,8 @@ static int g4x_compute_pipe_wm(struct intel_crtc_state
*crtc_state)
struct intel_atomic_state *state =
to_intel_atomic_state(crtc_state->base.state);
struct g4x_wm_state *wm_state = &crtc_state->wm.g4x.optimal;
- int num_active_planes = hweight32(crtc_state->active_planes &
- ~BIT(PLANE_CURSOR));
+ int num_active_planes = hweight8(crtc_state->active_planes &
+~BIT(PLANE_CURSOR));
const struct g4x_pipe_wm *raw;
const struct intel_plane_state *old_plane_state;
const struct intel_plane_state *new_plane_state;
@@ -1659,7 +1659,7 @@ static int vlv_compute_fifo(struct intel_crtc_state
*crtc_state)
&crtc_state->wm.vlv.raw[VLV_WM_LEVEL_PM2];
struct vlv_fifo_state *fifo_state = &crtc_state->wm.vlv.fifo_state;
unsigned int active_planes = crtc_state->active_planes &
~BIT(PLANE_CURSOR);
- int num_active_planes = hweight32(active_planes);
+ int num_active_planes = hweight8(active_planes);
const int fifo_size = 511;
int fifo_extra, fifo_left = fifo_size;
int sprite0_fifo_extra = 0;
@@ -1848,8 +1848,8 @@ static int vlv_compute_pipe_wm(struct intel_crtc_state
*crtc_state)
struct vlv_wm_state *wm_state = &crtc_state->wm.vlv.optimal;
const struct vlv_fifo_state *fifo_state =
&crtc_state->wm.vlv.fifo_state;
- int num_active_planes = hweight32(crtc_state->active_planes &
- ~BIT(PLANE_CURSOR));
+ int num_active_planes = hweight8(crtc_state->active_planes &
+~BIT(PLANE_CURSOR));
bool needs_modeset = drm_atomic_crtc_needs_modeset(&crtc_state->base);
const struct intel_plane_state *old_plane_state;
const struct intel_plane_state *new_plane_state;
@@ -3761,14 +3761,14 @@ bool intel_can_enable_sagv(struct intel_atomic_state
*state)
/*
* If there are no active CRTCs, no additional checks need be performed
*/
- if (hweight32(state->active_pipes) == 0)
+ if (hweight8(state->active_pipes) == 0)
return true;
/*
* SKL+ workaround: bspec recommends we disable SAGV when we have
* more then one pipe enabled
*/
- if (hweight32(state->active_pipes) > 1)
+ if (hweight8(state->active_pipes) > 1)
return false;
/* Since we're now guaranteed to only have one active CRTC... */
@@ -3867,14 +3867,14 @@ skl_ddb_get_pipe_allocation_limits(struct
drm_i915_private *dev_priv,
if (WARN_ON(!state) || !crtc_state->base.active) {
alloc->start = 0;
alloc->end = 0;
- *num_active = hweight32(dev_priv->active_pipes);
+ *num_active = hweight8(dev_priv->active_pipes);
return;
}
if (intel_state->active_pipe_changes)
- *num_active = hweight32(intel_state->active_pipes);
+ *num_active = hweight8(intel_state->active_pipes);
else
- *num_active = hweight32(dev_priv->active_pipes);
+ *num_active = hweight8(dev_priv->active_pipes);
ddb_size = intel_get_ddb_size(dev_priv, crtc_state, total_data_rate,
*num_active, ddb);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/5] drm/i915: Unconfuse pipe vs. crtc->index in i915_get_crtc_scanoutpos()
From: Ville Syrjälä
The "pipe" argument passed in by the vblank code is in fact the crtc
index. Don't assume that is the same as the pipe.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_irq.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 37e3dd3c1a9d..fe6a87a00527 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -942,14 +942,14 @@ static int __intel_get_crtc_scanline(struct intel_crtc
*crtc)
return (position + crtc->scanline_offset) % vtotal;
}
-bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int pipe,
+bool i915_get_crtc_scanoutpos(struct drm_device *dev, unsigned int index,
bool in_vblank_irq, int *vpos, int *hpos,
ktime_t *stime, ktime_t *etime,
const struct drm_display_mode *mode)
{
struct drm_i915_private *dev_priv = to_i915(dev);
- struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
- pipe);
+ struct intel_crtc *crtc = to_intel_crtc(drm_crtc_from_index(dev,
index));
+ enum pipe pipe = crtc->pipe;
int position;
int vbl_start, vbl_end, hsync_start, htotal, vtotal;
unsigned long irqflags;
@@ -992,7 +992,7 @@ bool i915_get_crtc_scanoutpos(struct drm_device *dev,
unsigned int pipe,
/* No obvious pixelcount register. Only query vertical
* scanout position from Display scan line register.
*/
- position = __intel_get_crtc_scanline(intel_crtc);
+ position = __intel_get_crtc_scanline(crtc);
} else {
/* Have access to pixelcount since start of frame.
* We can split this into vertical and horizontal
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Do not create a new max_bpc prop for MST connectors
On 2019-08-20 12:16 p.m., Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We're not allowed to create new properties after device registration
> so for MST connectors we need to either create the max_bpc property
> earlier, or we reuse one we already have. Let's do the latter apporach
> since the corresponding SST connector already has the prop and its
> min/max are correct also for the MST connector.
>
> The problem was highlighted by commit 4f5368b5541a ("drm/kms:
> Catch mode_object lifetime errors") which results in the following
> spew:
> [ 1330.878941] WARNING: CPU: 2 PID: 1554 at
> drivers/gpu/drm/drm_mode_object.c:45 __drm_mode_object_add+0xa0/0xb0 [drm]
> ...
> [ 1330.879008] Call Trace:
> [ 1330.879023] drm_property_create+0xba/0x180 [drm]
> [ 1330.879036] drm_property_create_range+0x15/0x30 [drm]
> [ 1330.879048] drm_connector_attach_max_bpc_property+0x62/0x80 [drm]
> [ 1330.879086] intel_dp_add_mst_connector+0x11f/0x140 [i915]
> [ 1330.879094] drm_dp_add_port.isra.20+0x20b/0x440 [drm_kms_helper]
> ...
>
> Cc: sta...@vger.kernel.org
> Cc: Lyude Paul
> Cc: sunpeng...@amd.com
> Cc: Daniel Vetter
> Cc: Sean Paul
> Fixes: 5ca0ef8a56b8 ("drm/i915: Add max_bpc property for DP MST")
> Signed-off-by: Ville Syrjälä
Thanks for following up, I had forgotten about this issue.
Reviewed-by: Leo Li
> ---
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 83faa246e361..9748581c1d62 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -536,7 +536,15 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>
> intel_attach_force_audio_property(connector);
> intel_attach_broadcast_rgb_property(connector);
> - drm_connector_attach_max_bpc_property(connector, 6, 12);
> +
> + /*
> + * Reuse the prop from the SST connector because we're
> + * not allowed to create new props after device registration.
> + */
> + connector->max_bpc_property =
> + intel_dp->attached_connector->base.max_bpc_property;
> + if (connector->max_bpc_property)
> + drm_connector_attach_max_bpc_property(connector, 6, 12);
>
> return connector;
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gtt: Relax assertion for pt_used
== Series Details == Series: drm/i915/gtt: Relax assertion for pt_used URL : https://patchwork.freedesktop.org/series/65518/ State : success == Summary == CI Bug Log - changes from CI_DRM_6750_full -> Patchwork_14116_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14116_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-hang-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb8/igt@gem_exec_sched...@preempt-hang-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-iclb4/igt@gem_exec_sched...@preempt-hang-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-apl8/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#103313]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-64x64-onscreen: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-apl5/igt@kms_cursor_...@pipe-c-cursor-64x64-onscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-64x64-onscreen.html * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-render: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-render.html * igt@kms_frontbuffer_tracking@psr-suspend: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108] / [fdo#106978]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl10/igt@kms_frontbuffer_track...@psr-suspend.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-skl6/igt@kms_frontbuffer_track...@psr-suspend.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-skl4/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109642] / [fdo#111068]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr2...@frontbuffer.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-iclb4/igt@kms_psr2...@frontbuffer.html * igt@kms_psr@psr2_cursor_mmap_cpu: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-iclb7/igt@kms_psr@psr2_cursor_mmap_cpu.html * igt@perf_pmu@rc6: - shard-kbl: [PASS][21] -> [SKIP][22] ([fdo#109271]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-kbl4/igt@perf_...@rc6.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-kbl7/igt@perf_...@rc6.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109276]) +14 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6750/shard-iclb4/igt@prime_b...@hang-bsd2.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14116/shard-iclb8/igt@prime_b...@hang-bsd2.html Possible fixes * igt@gem_eio@reset-stress: - s
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/5] drm/i915/execlists: Set priority hint prior to submission
== Series Details == Series: series starting with [1/5] drm/i915/execlists: Set priority hint prior to submission URL : https://patchwork.freedesktop.org/series/65553/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6757 -> Patchwork_14125 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14125 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14125, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/ Known issues Here are the changes found in Patchwork_14125 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6757/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@kms_frontbuffer_tracking@basic: - fi-bsw-n3050: [PASS][3] -> [FAIL][4] ([fdo#103167]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6757/fi-bsw-n3050/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/fi-bsw-n3050/igt@kms_frontbuffer_track...@basic.html - fi-bsw-kefka: [PASS][5] -> [FAIL][6] ([fdo#103167]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6757/fi-bsw-kefka/igt@kms_frontbuffer_track...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/fi-bsw-kefka/igt@kms_frontbuffer_track...@basic.html - fi-byt-n2820: [PASS][7] -> [FAIL][8] ([fdo#103167]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6757/fi-byt-n2820/igt@kms_frontbuffer_track...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/fi-byt-n2820/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_ctx_switch@legacy-render: - fi-apl-guc: [INCOMPLETE][9] ([fdo#103927]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6757/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 Participating hosts (56 -> 20) -- ERROR: It appears as if the changes made in Patchwork_14125 prevented too many machines from booting. Missing(36): fi-kbl-soraka fi-skl-6770hq fi-bdw-gvtdvm fi-icl-u2 fi-snb-2520m fi-icl-u3 fi-pnv-d510 fi-icl-y fi-skl-lmem fi-icl-guc fi-skl-6600u fi-cml-u2 fi-icl-u4 fi-bxt-dsi fi-tgl-u fi-byt-j1900 fi-glk-dsi fi-bwr-2160 fi-ilk-650 fi-kbl-7500u fi-hsw-4770 fi-gdg-551 fi-kbl-r fi-ilk-m540 fi-skl-gvtdvm fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-cfl-guc fi-kbl-guc fi-whl-u fi-kbl-x1275 fi-cfl-8109u fi-kbl-8809g fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6757 -> Patchwork_14125 CI-20190529: 20190529 CI_DRM_6757: be31a083b02b1b37be1a8c67bab6d0b57422d3b7 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5146: 357dbe1869d88a2f08bcee4eebceff4ee9014424 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14125: 394eca9840e4303b7b149082a5b746a8d60b0862 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 394eca9840e4 drm/i915: Replace i915_vma_put_fence() 332e6e957e98 drm/i915: Pull obj->userfault tracking under the ggtt->mutex f9abd7a99ab6 drm/i915: Track ggtt fence reservations under its own mutex == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14125/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 02/15] drm/i915/dsb: DSB context creation.
Quoting Animesh Manna (2019-08-21 07:32:22)
> The function will internally get the gem buffer from global GTT
> which is mapped in cpu domain to feed the data + opcode for DSB engine.
>
> Cc: Imre Deak
> Cc: Michel Thierry
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/Makefile | 1 +
> .../drm/i915/display/intel_display_types.h| 4 ++
> drivers/gpu/drm/i915/display/intel_dsb.c | 66 +++
> drivers/gpu/drm/i915/display/intel_dsb.h | 31 +
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> 5 files changed, 103 insertions(+)
> create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.c
> create mode 100644 drivers/gpu/drm/i915/display/intel_dsb.h
>
> diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
> index 45add812048b..5232b2607822 100644
> --- a/drivers/gpu/drm/i915/Makefile
> +++ b/drivers/gpu/drm/i915/Makefile
> @@ -171,6 +171,7 @@ i915-y += \
> display/intel_display_power.o \
> display/intel_dpio_phy.o \
> display/intel_dpll_mgr.o \
> + display/intel_dsb.o \
> display/intel_fbc.o \
> display/intel_fifo_underrun.o \
> display/intel_frontbuffer.o \
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 449abaea619f..e62450a72dc2 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -1026,6 +1026,10 @@ struct intel_crtc {
>
> /* scalers available on this crtc */
> int num_scalers;
> +
> + /* per pipe DSB related info */
> + struct intel_dsb dsb[MAX_DSB_PER_PIPE];
> + int dsb_in_use;
> };
>
> struct intel_plane {
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> new file mode 100644
> index ..6cde3af30643
> --- /dev/null
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -0,0 +1,66 @@
> +// SPDX-License-Identifier: MIT
> +/*
> + * Copyright © 2019 Intel Corporation
> + *
> + */
> +
> +#include "../i915_drv.h"
> +#include "intel_display_types.h"
> +
> +#define DSB_BUF_SIZE(2 * PAGE_SIZE)
> +
> +struct intel_dsb *
> +intel_dsb_get(struct intel_crtc *crtc)
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *i915 = to_i915(dev);
> + struct drm_i915_gem_object *obj;
> + struct i915_vma *vma;
> + struct intel_dsb *dsb;
> + intel_wakeref_t wakeref;
> + int i;
> +
> + WARN_ON(crtc->dsb_in_use >= MAX_DSB_PER_PIPE);
> +
> + for (i = 0; i < MAX_DSB_PER_PIPE; i++) {
> + if (!crtc->dsb[i].cmd_buf) {
> + dsb = &crtc->dsb[i];
> + dsb->id = i;
> + }
> + }
That seems out of place.
> +
> + dsb = &crtc->dsb[crtc->dsb_in_use];
What lock guards dsb_in_use?
> + dsb->crtc = crtc;
> + if (!HAS_DSB(i915))
> + return dsb;
> +
> + wakeref = intel_runtime_pm_get(&i915->runtime_pm);
> + mutex_lock(&i915->drm.struct_mutex);
> +
> + obj = i915_gem_object_create_shmem(i915, DSB_BUF_SIZE);
_internal not shmem, you never need to swap.
> + if (IS_ERR(obj))
> + goto err;
> +
> + vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0, PIN_MAPPABLE);
Only this (currently) still requires struct_mutex
Does it have to mappable? Is that the HW constraint?
> + if (IS_ERR(vma)) {
> + DRM_DEBUG_KMS("Vma creation failed.\n");
> + i915_gem_object_put(obj);
> + goto err;
> + }
> +
> + dsb->cmd_buf = i915_gem_object_pin_map(vma->obj, I915_MAP_WC);
Are you sure you WC? You spend more time reading it back than writing.
> + if (IS_ERR(dsb->cmd_buf)) {
> + DRM_DEBUG_KMS("Command buffer creation failed.\n");
> + dsb->cmd_buf = NULL;
> + goto err;
> + }
> + crtc->dsb_in_use++;
> + dsb->cmd_buf_head = (uintptr_t)i915_ggtt_offset(vma);
Pardon? Do not even pretend an offset into the global virtual address of
the GPU is a CPU pointer. Just don't bother, you store the vma, so you
already have the offset stored.
> + dsb->vma = vma;
> +
> + memset(dsb->cmd_buf, 0, DSB_BUF_SIZE);
That's overkill.
> +err:
> + mutex_unlock(&i915->drm.struct_mutex);
> + intel_runtime_pm_put(&i915->runtime_pm, wakeref);
So what did you do here that required a wakeref?
> + return dsb;
> +}
Include the complimentary teardown routine. That should be part of the
API you are presenting.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] dma_resv: prime lockdep annotations
On Wed, Aug 21, 2019 at 7:06 PM Thomas Hellström (VMware)
wrote:
>
> On 8/21/19 6:34 PM, Daniel Vetter wrote:
> > On Wed, Aug 21, 2019 at 05:54:27PM +0200, Thomas Hellström (VMware) wrote:
> >> On 8/20/19 4:53 PM, Daniel Vetter wrote:
> >>> Full audit of everyone:
> >>>
> >>> - i915, radeon, amdgpu should be clean per their maintainers.
> >>>
> >>> - vram helpers should be fine, they don't do command submission, so
> >>> really no business holding struct_mutex while doing copy_*_user. But
> >>> I haven't checked them all.
> >>>
> >>> - panfrost seems to dma_resv_lock only in panfrost_job_push, which
> >>> looks clean.
> >>>
> >>> - v3d holds dma_resv locks in the tail of its v3d_submit_cl_ioctl(),
> >>> copying from/to userspace happens all in v3d_lookup_bos which is
> >>> outside of the critical section.
> >>>
> >>> - vmwgfx has a bunch of ioctls that do their own copy_*_user:
> >>> - vmw_execbuf_process: First this does some copies in
> >>> vmw_execbuf_cmdbuf() and also in the vmw_execbuf_process() itself.
> >>> Then comes the usual ttm reserve/validate sequence, then actual
> >>> submission/fencing, then unreserving, and finally some more
> >>> copy_to_user in vmw_execbuf_copy_fence_user. Glossing over tons of
> >>> details, but looks all safe.
> >>> - vmw_fence_event_ioctl: No ttm_reserve/dma_resv_lock anywhere to be
> >>> seen, seems to only create a fence and copy it out.
> >>> - a pile of smaller ioctl in vmwgfx_ioctl.c, no reservations to be
> >>> found there.
> >>> Summary: vmwgfx seems to be fine too.
> >>>
> >>> - virtio: There's virtio_gpu_execbuffer_ioctl, which does all the
> >>> copying from userspace before even looking up objects through their
> >>> handles, so safe. Plus the getparam/getcaps ioctl, also both safe.
> >>>
> >>> - qxl only has qxl_execbuffer_ioctl, which calls into
> >>> qxl_process_single_command. There's a lovely comment before the
> >>> __copy_from_user_inatomic that the slowpath should be copied from
> >>> i915, but I guess that never happened. Try not to be unlucky and get
> >>> your CS data evicted between when it's written and the kernel tries
> >>> to read it. The only other copy_from_user is for relocs, but those
> >>> are done before qxl_release_reserve_list(), which seems to be the
> >>> only thing reserving buffers (in the ttm/dma_resv sense) in that
> >>> code. So looks safe.
> >>>
> >>> - A debugfs file in nouveau_debugfs_pstate_set() and the usif ioctl in
> >>> usif_ioctl() look safe. nouveau_gem_ioctl_pushbuf() otoh breaks this
> >>> everywhere and needs to be fixed up.
> >>>
> >>> Cc: Alex Deucher
> >>> Cc: Christian König
> >>> Cc: Chris Wilson
> >>> Cc: Thomas Zimmermann
> >>> Cc: Rob Herring
> >>> Cc: Tomeu Vizoso
> >>> Cc: Eric Anholt
> >>> Cc: Dave Airlie
> >>> Cc: Gerd Hoffmann
> >>> Cc: Ben Skeggs
> >>> Cc: "VMware Graphics"
> >>> Cc: Thomas Hellstrom
> >>> Signed-off-by: Daniel Vetter
> >>> ---
> >>>drivers/dma-buf/dma-resv.c | 12
> >>>1 file changed, 12 insertions(+)
> >>>
> >>> diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
> >>> index 42a8f3f11681..3edca10d3faf 100644
> >>> --- a/drivers/dma-buf/dma-resv.c
> >>> +++ b/drivers/dma-buf/dma-resv.c
> >>> @@ -34,6 +34,7 @@
> >>>#include
> >>>#include
> >>> +#include
> >>>/**
> >>> * DOC: Reservation Object Overview
> >>> @@ -107,6 +108,17 @@ void dma_resv_init(struct dma_resv *obj)
> >>> &reservation_seqcount_class);
> >>> RCU_INIT_POINTER(obj->fence, NULL);
> >>> RCU_INIT_POINTER(obj->fence_excl, NULL);
> >>> +
> >>> + if (IS_ENABLED(CONFIG_LOCKDEP)) {
> >>> + if (current->mm)
> >>> + down_read(¤t->mm->mmap_sem);
> >>> + ww_mutex_lock(&obj->lock, NULL);
> >>> + fs_reclaim_acquire(GFP_KERNEL);
> >>> + fs_reclaim_release(GFP_KERNEL);
> >>> + ww_mutex_unlock(&obj->lock);
> >>> + if (current->mm)
> >>> + up_read(¤t->mm->mmap_sem);
> >>> + }
> >>>}
> >>>EXPORT_SYMBOL(dma_resv_init);
> >> I assume if this would have been easily done and maintainable using only
> >> lockdep annotation instead of actually acquiring the locks, that would have
> >> been done?
> > There's might_lock(), plus a pile of macros, but they don't map obviuosly,
> > so pretty good chances I accidentally end up with the wrong type of
> > annotation. Easier to just take the locks quickly, and stuff that all into
> > a lockdep-only section to avoid overhead.
> >
> >> Otherwise LGTM.
> >>
> >> Reviewed-by: Thomas Hellström
> >>
> >> Will test this and let you know if it trips on vmwgfx, but it really
> >> shouldn't.
> > Thanks, Daniel
>
> One thing that strikes me is that this puts restrictions on where you
> can actually initialize a dma_resv, even if locking orders are otherwise
> obeyed. But that might no
Re: [Intel-gfx] [PATCH v2 05/15] drm/i915/dsb: Indexed register write function for DSB.
Quoting Animesh Manna (2019-08-21 07:32:25)
> DSB can program large set of data through indexed register write
> (opcode 0x9) in one shot. Will be using for bulk register programming
> e.g. gamma lut programming, HDR meta data programming.
>
> Cc: Shashank Sharma
> Cc: Imre Deak
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 42
> drivers/gpu/drm/i915/display/intel_dsb.h | 6
> 2 files changed, 48 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 8a9d082b1601..4fe8cac6246a 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -22,6 +22,7 @@
> #define DSB_OPCODE_INDEXED_WRITE 0x9
> #define DSB_OPCODE_POLL0xA
> #define DSB_BYTE_EN(0xf << 20)
> +#define DSB_REG_VALUE_MASK 0xf
>
> struct intel_dsb *
> intel_dsb_get(struct intel_crtc *crtc)
> @@ -79,6 +80,42 @@ intel_dsb_get(struct intel_crtc *crtc)
> return dsb;
> }
>
> +static void intel_dsb_indexed_reg_write(struct intel_dsb *dsb, i915_reg_t
> reg,
> + u32 val)
> +{
> + u32 *buf = dsb->cmd_buf;
> + u32 reg_val;
> +
> + reg_val = buf[dsb->ins_start_offset + 1] & DSB_REG_VALUE_MASK;
Uncached read.
> + if (reg_val != i915_mmio_reg_offset(reg)) {
> + /* Every instruction should be 8 byte aligned. */
> + if (dsb->free_pos & 0x1)
> + dsb->free_pos++;
dsb->free_pos = ALIGN(dsb->free_pos, 2);
> +
> + /* Update the size. */
> + dsb->ins_start_offset = dsb->free_pos;
> + buf[dsb->free_pos++] = 1;
> +
> + /* Update the opcode and reg. */
> + buf[dsb->free_pos++] = (DSB_OPCODE_INDEXED_WRITE <<
> + DSB_OPCODE_SHIFT) |
> + i915_mmio_reg_offset(reg);
> +
> + /* Update the value. */
> + buf[dsb->free_pos++] = val;
> + } else {
> + /* Update the new value. */
> + buf[dsb->free_pos++] = val;
> +
> + /* Update the size. */
> + buf[dsb->ins_start_offset]++;
Uncached read and write. So far this is working out to be _more_
expensive than mmio.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 06/15] drm/i915/dsb: Update i915_write to call dsb-write.
Quoting Animesh Manna (2019-08-21 07:32:26)
> Existing mmio-reg-write need intel_uncore handle which is part
> of dev_priv structure and the same design is followed by
> adding dsb handle in dev_priv for programming registers through DSB.
>
> I915_WRITE is modified to check for register capability and call
> dsb-reg-write based on its capability.
>
> No changes in I915_READ definition as DSB do not have support to
> read any register.
>
> Cc: Jani Nikula
> Cc: Rodrigo Vivi
> Signed-off-by: Animesh Manna
> ---
> drivers/gpu/drm/i915/display/intel_dsb.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 6 +-
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dsb.c
> b/drivers/gpu/drm/i915/display/intel_dsb.c
> index 4fe8cac6246a..6f1999140085 100644
> --- a/drivers/gpu/drm/i915/display/intel_dsb.c
> +++ b/drivers/gpu/drm/i915/display/intel_dsb.c
> @@ -123,7 +123,7 @@ void intel_dsb_reg_write(struct intel_dsb *dsb,
> i915_reg_t reg, u32 val)
> u32 *buf = dsb->cmd_buf;
>
> if (!buf) {
> - I915_WRITE(reg, val);
> + intel_uncore_write(&(dev_priv)->uncore, reg, val);
> return;
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 643fd6d6fd73..7aed957362c9 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1753,6 +1753,8 @@ struct drm_i915_private {
> /* Mutex to protect the above hdcp component related values. */
> struct mutex hdcp_comp_mutex;
>
> + struct intel_dsb *dsb;
> +
> /*
> * NOTE: This is the dri1/ums dungeon, don't add stuff here. Your
> patch
> * will be rejected. Instead look for a better place.
> @@ -2414,7 +2416,9 @@ int i915_reg_read_ioctl(struct drm_device *dev, void
> *data,
> intel_uncore_##op__(&(dev_priv__)->uncore, __VA_ARGS__)
>
> #define I915_READ(reg__)__I915_REG_OP(read, dev_priv, (reg__))
> -#define I915_WRITE(reg__, val__) __I915_REG_OP(write, dev_priv, (reg__),
> (val__))
> +#define I915_WRITE(reg__, val__) \
> + (reg__.cap) ? intel_dsb_reg_write(dev_priv->dsb, (reg__), (val__)) : \
> + __I915_REG_OP(write, dev_priv, (reg__), (val__))
Jani, over to you.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
