[Intel-gfx] [PATCH 2/2] drm/i915: FB backing gem obj should reside in LMEM
If Local memory is supported by hardware, we want framebuffer backing
gem objects from local memory.
pin_to_display is failed, if the backing obj is not from LMEM.
This is developed on top of LMEM Basics
https://patchwork.freedesktop.org/series/67350/
v2:
memory regions are correctly assigned to obj->memory_regions [tvrtko]
migration failure is reported as debug log [Tvrtko]
v3:
Migration is dropped. only error is reported [Daniel]
mem region check is move to pin_to_display [Chris]
cc: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/gem/i915_gem_domain.c | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
index 55c3ab59e3aa..c74d0796b142 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_domain.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_domain.c
@@ -419,11 +419,19 @@ i915_gem_object_pin_to_display_plane(struct
drm_i915_gem_object *obj,
const struct i915_ggtt_view *view,
unsigned int flags)
{
+ struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct i915_vma *vma;
int ret;
assert_object_held(obj);
+ /* GEM Obj for frame buffer is expected to be in LMEM. */
+ if (HAS_LMEM(dev_priv))
+ if (obj->mm.region->type != INTEL_LMEM) {
+ DRM_DEBUG_KMS("OBJ is not from LMEM\n");
+ return ERR_PTR(-EINVAL);
+ }
+
/*
* The display engine is not coherent with the LLC cache on gen6. As
* a result, we make sure that the pinning that is about to occur is
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Create dumb buffer from LMEM
When LMEM is supported, dumb buffer preferred to be created from LMEM.
This is developed on top of LMEM Basics
https://patchwork.freedesktop.org/series/67350/
v2:
Parameters are reshuffled. [Chris]
Signed-off-by: Ramalingam C
cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 82daaab022d8..48afc676fa8c 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -44,6 +44,7 @@
#include "gem/i915_gem_clflush.h"
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_ioctls.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
@@ -157,6 +158,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
static int
i915_gem_create(struct drm_file *file,
struct drm_i915_private *dev_priv,
+ enum intel_region_id mem_region,
u64 *size_p,
u32 *handle_p)
{
@@ -170,7 +172,12 @@ i915_gem_create(struct drm_file *file,
return -EINVAL;
/* Allocate the new object */
- obj = i915_gem_object_create_shmem(dev_priv, size);
+ if (mem_region == INTEL_MEMORY_LMEM)
+ obj = i915_gem_object_create_lmem(dev_priv, size, 0);
+ else if (mem_region == INTEL_MEMORY_STOLEN)
+ obj = i915_gem_object_create_stolen(dev_priv, size);
+ else
+ obj = i915_gem_object_create_shmem(dev_priv, size);
if (IS_ERR(obj))
return PTR_ERR(obj);
@@ -190,6 +197,7 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
+ enum intel_region_id mem_region = INTEL_MEMORY_UKNOWN;
int cpp = DIV_ROUND_UP(args->bpp, 8);
u32 format;
@@ -216,7 +224,11 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->pitch, 4096);
args->size = args->pitch * args->height;
- return i915_gem_create(file, to_i915(dev),
+
+ if (HAS_LMEM(to_i915(dev)))
+ mem_region = INTEL_MEMORY_LMEM;
+
+ return i915_gem_create(file, to_i915(dev), mem_region,
>size, >handle);
}
@@ -235,7 +247,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
i915_gem_flush_free_objects(dev_priv);
- return i915_gem_create(file, dev_priv,
+ return i915_gem_create(file, dev_priv, INTEL_MEMORY_UKNOWN,
>size, >handle);
}
--
2.20.1
___
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/tgl: Magic interrupt shadow to relieve some random lockups
== Series Details == Series: drm/i915/tgl: Magic interrupt shadow to relieve some random lockups URL : https://patchwork.freedesktop.org/series/67416/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6976_full -> Patchwork_14592_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14592_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14592_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_14592_full: ### IGT changes ### Possible regressions * igt@gem_ctx_isolation@rcs0-s3: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb1/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-iclb1/igt@gem_ctx_isolat...@rcs0-s3.html Known issues Here are the changes found in Patchwork_14592_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-apl7/igt@gem_ctx_isolat...@bcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-apl7/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +3 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb3/igt@gem_exec_as...@concurrent-writes-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-sliding: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb2/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-iclb7/igt@kms_cursor_...@pipe-a-cursor-64x64-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103232]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-skl7/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#105363]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-glk1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#103191]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/shard-skl7/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]:
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_crtc_background_color: overhaul to match upstream ABI (v5.1)
On 30/09/2019 19:13, Matt Roper wrote:
> CRTC background color kernel patches were written about 2.5 years ago
> and floated on the upstream mailing list, but since no opensource
> userspace materialized, we never actually merged them. However the
> corresponding IGT test did get merged and has basically been dead code
> ever since.
>
> A couple years later we finally have an open source userspace
> (ChromeOS), so lets update the IGT test to match the ABI that's actually
> going upstream and to remove some of the cruft from the original test
> that wouldn't actually work.
>
> It's worth noting that CRC's don't seem to work properly on Intel gen9.
> The bspec does tell us that we must have one plane enabled before taking
> a pipe-level ("dmux") CRC, so this test is violating that by disabling
> all planes; it's quite possible that this is the source of the CRC
> mismatch. If running on an Intel platform, you may want to run in
> interactive mode ("--interactive-debug=bgcolor --skip-crc-compare") to
> ensure that the colors being generated actually do match visually since
> the CRC's can't be trusted.
Hmm, landing a feature without automating testing for it is a bit too
much to ask IMO.
I have two proposals to make it happen:
- Could we add a workaround for the affected intel platforms? If the
problem really is because no planes are enabled, then surely a
fully-transparent plane would be a sufficient workaround.
- If CRCs really cannot be used for this, then we should use the
chamelium for it. The idea would be to detect if the connector is
connected to a chamelium, and if so use chamelium's CRC.
How does this sound?
Martin
>
> v2:
> - Swap red and blue ordering in property value to reflect change
>in v2 of kernel series.
>
> v3:
> - Minor updates to proposed uapi helpers (s/rgba/argb/).
>
> v4:
> - General restructuring into pipe/color subtests.
> - Use RGB2101010 framebuffers for comparison so that we match the bits
>of precision that Intel hardware background color accepts
>
> v5:
> - Re-enable CRC comparisons; just because these don't work on Intel
>doesn't mean we shouldn't use them on other vendors' platforms
>(Daniel).
> - Use DRIVER_ANY rather than DRIVER_INTEL. (Heiko Stuebner)
>
> v5.1:
> - Update commit message body discussion of CRC issues.
>
> Cc: igt-...@lists.freedesktop.org
> Cc: Daniel Vetter
> Cc: Heiko Stuebner
> Signed-off-by: Matt Roper
> ---
> lib/igt_kms.c | 2 +-
> tests/kms_crtc_background_color.c | 263 ++
> 2 files changed, 127 insertions(+), 138 deletions(-)
>
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index e9b80b9b..9a7f0e23 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -391,7 +391,7 @@ const char * const
> igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
> };
>
> const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
> - [IGT_CRTC_BACKGROUND] = "background_color",
> + [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
> [IGT_CRTC_CTM] = "CTM",
> [IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
> [IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
> diff --git a/tests/kms_crtc_background_color.c
> b/tests/kms_crtc_background_color.c
> index 3df3401f..58cdd7a9 100644
> --- a/tests/kms_crtc_background_color.c
> +++ b/tests/kms_crtc_background_color.c
> @@ -25,164 +25,153 @@
> #include "igt.h"
> #include
>
> -
> IGT_TEST_DESCRIPTION("Test crtc background color feature");
>
> +/*
> + * Paints a desired color into a full-screen primary plane and then compares
> + * that CRC with turning off all planes and setting the CRTC background to
> the
> + * same color.
> + *
> + * At least on current Intel platforms, the CRC tests appear to always fail,
> + * even though the resulting pipe output seems to be the same. The bspec
> tells
> + * us that we must have at least one plane turned on when taking a pipe-level
> + * CRC, so the fact that we're violating that may explain the failures. If
> + * your platform gives failures for all tests, you may want to run with
> + * --interactive-debug=bgcolor --skip-crc-compare to visually inspect that
> the
> + * background color matches the equivalent solid plane.
> + */
> +
> typedef struct {
> - int gfx_fd;
> igt_display_t display;
> - struct igt_fb fb;
> - igt_crc_t ref_crc;
> + int gfx_fd;
> + igt_output_t *output;
> igt_pipe_crc_t *pipe_crc;
> + drmModeModeInfo *mode;
> } data_t;
>
> -#define BLACK 0x00 /* BGR 8bpc */
> -#define CYAN 0x00 /* BGR 8bpc */
> -#define PURPLE 0xFF00FF /* BGR 8bpc */
> -#define WHITE 0xFF /* BGR 8bpc */
> -
> -#define BLACK640x /* BGR 16bpc */
> -#define CYAN64 0x /* BGR 16bpc */
> -#define PURPLE64 0x /* BGR 16bpc */
> -#define YELLOW64 0x /* BGR 16bpc */
> -#define WHITE640x /* BGR
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Fix g4x sprite scaling stride check with GTT remapping
== Series Details == Series: drm/i915: Fix g4x sprite scaling stride check with GTT remapping URL : https://patchwork.freedesktop.org/series/67415/ State : success == Summary == CI Bug Log - changes from CI_DRM_6976_full -> Patchwork_14591_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14591_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-self-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb8/igt@gem_exec_sched...@preempt-self-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-iclb2/igt@gem_exec_sched...@preempt-self-bsd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][3] -> [SKIP][4] ([fdo#109271]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-snb1/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@kms_big_fb@x-tiled-32bpp-rotate-180: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#105604] / [fdo#105763]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-kbl4/igt@kms_big...@x-tiled-32bpp-rotate-180.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-kbl6/igt@kms_big...@x-tiled-32bpp-rotate-180.html * igt@kms_cursor_crc@pipe-a-cursor-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#110741]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-skl9/igt@kms_cursor_...@pipe-a-cursor-suspend.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#103232]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103191]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-skl2/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-iclb6/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-hsw: [PASS][19] -> [FAIL][20] ([fdo#99912]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-hsw6/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-hsw4/igt@kms_setm...@basic.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_6976/shard-apl6/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-apl8/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@perf@polling: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#110728]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@p...@polling.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/shard-skl2/igt@p...@polling.html * igt@prime_busy@after-bsd2: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109276]) +10
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/tc: Implement the TC cold exit sequence
== Series Details ==
Series: drm/i915/tc: Implement the TC cold exit sequence
URL : https://patchwork.freedesktop.org/series/67426/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6979 -> Patchwork_14595
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14595 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14595, 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_14595/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14595:
### IGT changes ###
Possible regressions
* igt@runner@aborted:
- fi-bsw-n3050: NOTRUN -> [FAIL][1]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/fi-bsw-n3050/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_sync@basic-store-all:
- {fi-tgl-u2}:NOTRUN -> [FAIL][2]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/fi-tgl-u2/igt@gem_s...@basic-store-all.html
* igt@i915_selftest@live_requests:
- {fi-tgl-u2}:NOTRUN -> [DMESG-FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/fi-tgl-u2/igt@i915_selftest@live_requests.html
Known issues
Here are the changes found in Patchwork_14595 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bsw-n3050: [PASS][4] -> [INCOMPLETE][5] ([fdo#105876])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- {fi-tgl-u2}:[DMESG-WARN][6] ([fdo#111600]) -> [PASS][7]
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
* igt@gem_sync@basic-each:
- {fi-tgl-u2}:[INCOMPLETE][8] ([fdo#111647]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/fi-tgl-u2/igt@gem_s...@basic-each.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/fi-tgl-u2/igt@gem_s...@basic-each.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (15 -> 43)
--
Additional (28): fi-kbl-soraka fi-bdw-gvtdvm fi-icl-u2 fi-apl-guc
fi-snb-2520m fi-icl-u3 fi-skl-lmem fi-blb-e6850 fi-icl-guc fi-byt-n2820
fi-skl-6600u fi-hsw-4770r fi-bxt-dsi fi-cml-s fi-glk-dsi fi-bwr-2160 fi-ilk-650
fi-kbl-7500u fi-gdg-551 fi-elk-e7500 fi-skl-6700k2 fi-hsw-peppy fi-cfl-guc
fi-whl-u fi-kbl-x1275 fi-cfl-8109u fi-skl-iommu fi-kbl-8809g
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6979 -> Patchwork_14595
CI-20190529: 20190529
CI_DRM_6979: 46637a3b58ef5e2c0fb6e53b7c50bba8f5de3455 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14595: a6ecce8d8ab2cdeff30b89cc0a8289dc8c414145 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a6ecce8d8ab2 drm/i915/tc: Implement the TC cold exit sequence
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14595/index.html
___
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: Refuse modes with hdisplay==4096 on pre-HSW DP (rev2)
== Series Details == Series: series starting with [1/2] drm/i915: Refuse modes with hdisplay==4096 on pre-HSW DP (rev2) URL : https://patchwork.freedesktop.org/series/63892/ State : success == Summary == CI Bug Log - changes from CI_DRM_6976_full -> Patchwork_14590_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14590_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_read@short-buffer-wakeup: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-apl4/igt@drm_r...@short-buffer-wakeup.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-apl2/igt@drm_r...@short-buffer-wakeup.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb8/igt@gem_exec_sched...@reorder-wide-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_exec_suspend@basic-s3: - shard-kbl: [PASS][5] -> [FAIL][6] ([fdo#103375]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-kbl6/igt@gem_exec_susp...@basic-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-kbl7/igt@gem_exec_susp...@basic-s3.html * igt@gem_workarounds@suspend-resume: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-apl4/igt@gem_workarou...@suspend-resume.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-apl3/igt@gem_workarou...@suspend-resume.html * igt@kms_busy@extended-modeset-hang-oldfb-with-reset-render-b: - shard-snb: [PASS][9] -> [SKIP][10] ([fdo#109271] / [fdo#109278]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-snb6/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-b.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-snb4/igt@kms_b...@extended-modeset-hang-oldfb-with-reset-render-b.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103232]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-skl3/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html * igt@kms_cursor_legacy@short-flip-after-cursor-atomic-transitions-varying-size: - shard-snb: [PASS][13] -> [SKIP][14] ([fdo#109271]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-snb6/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-snb4/igt@kms_cursor_leg...@short-flip-after-cursor-atomic-transitions-varying-size.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][15] -> [INCOMPLETE][16] ([fdo#103540]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-hsw7/igt@kms_f...@flip-vs-suspend-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#103191]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-skl3/igt@kms_pipe_crc_ba...@nonblocking-crc-pipe-b-frame-sequence.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/shard-skl3/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][23] -> [FAIL][24] ([fdo#108341]) [23]:
[Intel-gfx] [PATCH] drm/i915/tc: Implement the TC cold exit sequence
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
BSpec: 21750
BSpsc: 49294
Cc: Imre Deak
Cc: Lucas De Marchi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_tc.c | 34 -
drivers/gpu/drm/i915/i915_reg.h | 1 +
2 files changed, 29 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 7773169b7331..09b78027bdd5 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -7,6 +7,7 @@
#include "intel_display.h"
#include "intel_display_types.h"
#include "intel_dp_mst.h"
+#include "intel_sideband.h"
#include "intel_tc.h"
static const char *tc_port_mode_name(enum tc_port_mode mode)
@@ -169,6 +170,22 @@ static void tc_port_fixup_legacy_flag(struct
intel_digital_port *dig_port,
dig_port->tc_legacy_port = !dig_port->tc_legacy_port;
}
+static int tc_cold_exit_request(struct drm_i915_private *dev_priv)
+{
+ int ret;
+
+ do {
+ ret = sandybridge_pcode_write_timeout(dev_priv,
+ ICL_PCODE_EXIT_TCCOLD, 0,
+ 250, 1);
+
+ } while (ret == -EAGAIN);
+
+ DRM_DEBUG_KMS("tccold exit %s\n", ret == 0 ? "succeeded" : "failed");
+
+ return ret;
+}
+
static u32 tc_port_live_status_mask(struct intel_digital_port *dig_port)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -177,13 +194,21 @@ static u32 tc_port_live_status_mask(struct
intel_digital_port *dig_port)
u32 mask = 0;
u32 val;
+ if (intel_uncore_read(uncore, SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port))
+ mask |= BIT(TC_PORT_LEGACY);
+
val = intel_uncore_read(uncore,
PORT_TX_DFLEXDPSP(dig_port->tc_phy_fia));
if (val == 0x) {
- DRM_DEBUG_KMS("Port %s: PHY in TCCOLD, nothing connected\n",
- dig_port->tc_port_name);
- return mask;
+ if (mask)
+ tc_cold_exit_request(i915);
+
+ if (val == 0x) {
+ DRM_DEBUG_KMS("Port %s: PHY in TCCOLD, nothing
connected\n",
+ dig_port->tc_port_name);
+ return mask;
+ }
}
if (val & TC_LIVE_STATE_TBT(dig_port->tc_phy_fia_idx))
@@ -191,9 +216,6 @@ static u32 tc_port_live_status_mask(struct
intel_digital_port *dig_port)
if (val & TC_LIVE_STATE_TC(dig_port->tc_phy_fia_idx))
mask |= BIT(TC_PORT_DP_ALT);
- if (intel_uncore_read(uncore, SDEISR) & SDE_TC_HOTPLUG_ICP(tc_port))
- mask |= BIT(TC_PORT_LEGACY);
-
/* The sink can be connected only in a single mode. */
if (!WARN_ON(hweight32(mask) > 1))
tc_port_fixup_legacy_flag(dig_port, mask);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 058aa5ca8b73..35c3724b7fef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8860,6 +8860,7 @@ enum {
#define ICL_PCODE_MEM_SS_READ_QGV_POINT_INFO(point)(((point) <<
16) | (0x1 << 8))
#define GEN6_PCODE_READ_D_COMP 0x10
#define GEN6_PCODE_WRITE_D_COMP 0x11
+#define ICL_PCODE_EXIT_TCCOLD0x12
#define HSW_PCODE_DE_WRITE_FREQ_REQ 0x17
#define DISPLAY_IPS_CONTROL 0x19
/* See also IPS_CTL */
--
2.23.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 DC3CO Support for TGL (rev13)
== Series Details == Series: DC3CO Support for TGL (rev13) URL : https://patchwork.freedesktop.org/series/64923/ State : success == Summary == CI Bug Log - changes from CI_DRM_6976_full -> Patchwork_14589_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14589_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-kbl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103665]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-kbl6/igt@gem_ctx_isolat...@vecs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-kbl2/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_exec_create@forked: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-apl8/igt@gem_exec_cre...@forked.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-apl4/igt@gem_exec_cre...@forked.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +6 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb8/igt@gem_exec_sched...@reorder-wide-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-snb: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-snb5/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +5 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-apl3/igt@i915_susp...@sysfs-reader.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-apl7/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-b-cursor-128x128-onscreen: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103232]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-128x128-onscreen.html * igt@kms_flip@dpms-vs-vblank-race-interruptible: - shard-apl: [PASS][13] -> [FAIL][14] ([fdo#111609]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-apl7/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-apl7/igt@kms_f...@dpms-vs-vblank-race-interruptible.html - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#111609]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-glk6/igt@kms_f...@dpms-vs-vblank-race-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-glk1/igt@kms_f...@dpms-vs-vblank-race-interruptible.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#105363]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-glk9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-glk3/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +5 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-gtt.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc: - shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([fdo#106978] / [fdo#107713]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-wc.html *
[Intel-gfx] ✓ Fi.CI.BAT: success for CRTC background color (rev8)
== Series Details ==
Series: CRTC background color (rev8)
URL : https://patchwork.freedesktop.org/series/50834/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6979 -> Patchwork_14594
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14594:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_execlists:
- {fi-tgl-u2}:NOTRUN -> [DMESG-FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/fi-tgl-u2/igt@i915_selftest@live_execlists.html
Known issues
Here are the changes found in Patchwork_14594 that come from known issues:
### IGT changes ###
Possible fixes
* igt@gem_sync@basic-each:
- {fi-tgl-u2}:[INCOMPLETE][2] ([fdo#111647]) -> [PASS][3]
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6979/fi-tgl-u2/igt@gem_s...@basic-each.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/fi-tgl-u2/igt@gem_s...@basic-each.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (15 -> 42)
--
Additional (27): fi-kbl-soraka fi-bdw-gvtdvm fi-icl-u2 fi-apl-guc
fi-snb-2520m fi-icl-u3 fi-skl-lmem fi-blb-e6850 fi-byt-n2820 fi-skl-6600u
fi-hsw-4770r fi-bxt-dsi fi-cml-s fi-byt-j1900 fi-glk-dsi fi-bwr-2160 fi-ilk-650
fi-gdg-551 fi-elk-e7500 fi-skl-6700k2 fi-hsw-peppy fi-cfl-guc fi-whl-u
fi-kbl-x1275 fi-cfl-8109u fi-skl-iommu fi-kbl-8809g
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6979 -> Patchwork_14594
CI-20190529: 20190529
CI_DRM_6979: 46637a3b58ef5e2c0fb6e53b7c50bba8f5de3455 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14594: 52e2c82f7a757bbea9b03da959bd2d3192966458 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
52e2c82f7a75 drm/i915: Add background color hardware readout and state check
fbe4bbbe8aec drm/i915/gen9+: Add support for pipe background color
ce8779b97946 drm: Add CRTC background color property
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14594/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v8, 2/4] drm/panel: set display info in panel attach
On Sat, Sep 28, 2019 at 10:23 PM james qian wang (Arm Technology
China) wrote:
>
> On Wed, Sep 25, 2019 at 03:58:31PM -0700, Derek Basehore wrote:
> > Devicetree systems can set panel orientation via a panel binding, but
> > there's no way, as is, to propagate this setting to the connector,
> > where the property need to be added.
> > To address this, this patch sets orientation, as well as other fixed
> > values for the panel, in the drm_panel_attach function. These values
> > are stored from probe in the drm_panel struct.
> >
> > Signed-off-by: Derek Basehore
> > Reviewed-by: Sam Ravnborg
> > ---
> > drivers/gpu/drm/drm_panel.c | 28 +
> > include/drm/drm_panel.h | 50 +
> > 2 files changed, 78 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_panel.c b/drivers/gpu/drm/drm_panel.c
> > index 0909b53b74e6..1cd2b56c9fe6 100644
> > --- a/drivers/gpu/drm/drm_panel.c
> > +++ b/drivers/gpu/drm/drm_panel.c
> > @@ -104,11 +104,23 @@ EXPORT_SYMBOL(drm_panel_remove);
> > */
> > int drm_panel_attach(struct drm_panel *panel, struct drm_connector
> > *connector)
> > {
> > + struct drm_display_info *info;
> > +
> > if (panel->connector)
> > return -EBUSY;
> >
> > panel->connector = connector;
> > panel->drm = connector->dev;
> > + info = >display_info;
> > + info->width_mm = panel->width_mm;
> > + info->height_mm = panel->height_mm;
> > + info->bpc = panel->bpc;
> > + info->panel_orientation = panel->orientation;
> > + info->bus_flags = panel->bus_flags;
> > + if (panel->bus_formats)
> > + drm_display_info_set_bus_formats(>display_info,
> > + panel->bus_formats,
> > + panel->num_bus_formats);
> >
> > return 0;
> > }
> > @@ -126,6 +138,22 @@ EXPORT_SYMBOL(drm_panel_attach);
> > */
> > void drm_panel_detach(struct drm_panel *panel)
> > {
> > + struct drm_display_info *info;
> > +
> > + if (!panel->connector)
> > + goto out;
> > +
> > + info = >connector->display_info;
> > + info->width_mm = 0;
> > + info->height_mm = 0;
> > + info->bpc = 0;
> > + info->panel_orientation = DRM_MODE_PANEL_ORIENTATION_UNKNOWN;
> > + info->bus_flags = 0;
> > + kfree(info->bus_formats);
> > + info->bus_formats = NULL;
> > + info->num_bus_formats = 0;
> > +
> > +out:
> > panel->connector = NULL;
> > panel->drm = NULL;
> > }
> > diff --git a/include/drm/drm_panel.h b/include/drm/drm_panel.h
> > index d16158deacdc..f3587a54b8ac 100644
> > --- a/include/drm/drm_panel.h
> > +++ b/include/drm/drm_panel.h
> > @@ -141,6 +141,56 @@ struct drm_panel {
> >*/
> > const struct drm_panel_funcs *funcs;
> >
>
> All these new added members seems dupliated with drm_display_info,
> So I think, can we add a new drm_plane_funcs func:
>
> int (*set_display_info)(struct drm_panel *panel,
> struct drm_display_info *info);
I don't disagree personally, since I originally wrote it this way, but
2 maintainers, Daniel Vetter and Thierry Reding, requested that it be
changed. Unless that decision is reversed, I won't be changing this.
>
> Then in drm_panel_attach(), via this interface the specific panel
> driver can directly set connector->display_info. like
>
>...
>if (panel->funcs && panel->funcs->set_display_info)
> panel->funcs->unprepare(panel, connector->display_info);
>...
>
> Thanks
> James
>
> > + /**
> > + * @width_mm:
> > + *
> > + * Physical width in mm.
> > + */
> > + unsigned int width_mm;
> > +
> > + /**
> > + * @height_mm:
> > + *
> > + * Physical height in mm.
> > + */
> > + unsigned int height_mm;
> > +
> > + /**
> > + * @bpc:
> > + *
> > + * Maximum bits per color channel. Used by HDMI and DP outputs.
> > + */
> > + unsigned int bpc;
> > +
> > + /**
> > + * @orientation
> > + *
> > + * Installation orientation of the panel with respect to the chassis.
> > + */
> > + int orientation;
> > +
> > + /**
> > + * @bus_formats
> > + *
> > + * Pixel data format on the wire.
> > + */
> > + const u32 *bus_formats;
> > +
> > + /**
> > + * @num_bus_formats:
> > + *
> > + * Number of elements pointed to by @bus_formats
> > + */
> > + unsigned int num_bus_formats;
> > +
> > + /**
> > + * @bus_flags:
> > + *
> > + * Additional information (like pixel signal polarity) for the pixel
> > + * data on the bus.
> > + */
> > + u32 bus_flags;
> > +
> > /**
> >* @list:
> >*
Thanks for the review
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] tests/kms_crtc_background_color: overhaul to match upstream ABI (v5.1)
CRTC background color kernel patches were written about 2.5 years ago
and floated on the upstream mailing list, but since no opensource
userspace materialized, we never actually merged them. However the
corresponding IGT test did get merged and has basically been dead code
ever since.
A couple years later we finally have an open source userspace
(ChromeOS), so lets update the IGT test to match the ABI that's actually
going upstream and to remove some of the cruft from the original test
that wouldn't actually work.
It's worth noting that CRC's don't seem to work properly on Intel gen9.
The bspec does tell us that we must have one plane enabled before taking
a pipe-level ("dmux") CRC, so this test is violating that by disabling
all planes; it's quite possible that this is the source of the CRC
mismatch. If running on an Intel platform, you may want to run in
interactive mode ("--interactive-debug=bgcolor --skip-crc-compare") to
ensure that the colors being generated actually do match visually since
the CRC's can't be trusted.
v2:
- Swap red and blue ordering in property value to reflect change
in v2 of kernel series.
v3:
- Minor updates to proposed uapi helpers (s/rgba/argb/).
v4:
- General restructuring into pipe/color subtests.
- Use RGB2101010 framebuffers for comparison so that we match the bits
of precision that Intel hardware background color accepts
v5:
- Re-enable CRC comparisons; just because these don't work on Intel
doesn't mean we shouldn't use them on other vendors' platforms
(Daniel).
- Use DRIVER_ANY rather than DRIVER_INTEL. (Heiko Stuebner)
v5.1:
- Update commit message body discussion of CRC issues.
Cc: igt-...@lists.freedesktop.org
Cc: Daniel Vetter
Cc: Heiko Stuebner
Signed-off-by: Matt Roper
---
lib/igt_kms.c | 2 +-
tests/kms_crtc_background_color.c | 263 ++
2 files changed, 127 insertions(+), 138 deletions(-)
diff --git a/lib/igt_kms.c b/lib/igt_kms.c
index e9b80b9b..9a7f0e23 100644
--- a/lib/igt_kms.c
+++ b/lib/igt_kms.c
@@ -391,7 +391,7 @@ const char * const
igt_plane_prop_names[IGT_NUM_PLANE_PROPS] = {
};
const char * const igt_crtc_prop_names[IGT_NUM_CRTC_PROPS] = {
- [IGT_CRTC_BACKGROUND] = "background_color",
+ [IGT_CRTC_BACKGROUND] = "BACKGROUND_COLOR",
[IGT_CRTC_CTM] = "CTM",
[IGT_CRTC_GAMMA_LUT] = "GAMMA_LUT",
[IGT_CRTC_GAMMA_LUT_SIZE] = "GAMMA_LUT_SIZE",
diff --git a/tests/kms_crtc_background_color.c
b/tests/kms_crtc_background_color.c
index 3df3401f..58cdd7a9 100644
--- a/tests/kms_crtc_background_color.c
+++ b/tests/kms_crtc_background_color.c
@@ -25,164 +25,153 @@
#include "igt.h"
#include
-
IGT_TEST_DESCRIPTION("Test crtc background color feature");
+/*
+ * Paints a desired color into a full-screen primary plane and then compares
+ * that CRC with turning off all planes and setting the CRTC background to the
+ * same color.
+ *
+ * At least on current Intel platforms, the CRC tests appear to always fail,
+ * even though the resulting pipe output seems to be the same. The bspec tells
+ * us that we must have at least one plane turned on when taking a pipe-level
+ * CRC, so the fact that we're violating that may explain the failures. If
+ * your platform gives failures for all tests, you may want to run with
+ * --interactive-debug=bgcolor --skip-crc-compare to visually inspect that the
+ * background color matches the equivalent solid plane.
+ */
+
typedef struct {
- int gfx_fd;
igt_display_t display;
- struct igt_fb fb;
- igt_crc_t ref_crc;
+ int gfx_fd;
+ igt_output_t *output;
igt_pipe_crc_t *pipe_crc;
+ drmModeModeInfo *mode;
} data_t;
-#define BLACK 0x00 /* BGR 8bpc */
-#define CYAN 0x00 /* BGR 8bpc */
-#define PURPLE 0xFF00FF /* BGR 8bpc */
-#define WHITE 0xFF /* BGR 8bpc */
-
-#define BLACK640x /* BGR 16bpc */
-#define CYAN64 0x /* BGR 16bpc */
-#define PURPLE64 0x /* BGR 16bpc */
-#define YELLOW64 0x /* BGR 16bpc */
-#define WHITE640x /* BGR 16bpc */
-#define RED64 0x /* BGR 16bpc */
-#define GREEN640x /* BGR 16bpc */
-#define BLUE64 0x /* BGR 16bpc */
-
-static void
-paint_background(data_t *data, struct igt_fb *fb, drmModeModeInfo *mode,
- uint32_t background, double alpha)
+/*
+ * Local copy of kernel uapi
+ */
+static inline __u64
+local_argb(__u8 bpc, __u16 alpha, __u16 red, __u16 green, __u16 blue)
{
- cairo_t *cr;
- int w, h;
- double r, g, b;
-
- w = mode->hdisplay;
- h = mode->vdisplay;
-
- cr = igt_get_cairo_ctx(data->gfx_fd, >fb);
+ int msb_shift = 16 - bpc;
- /* Paint with background color */
- r = (double) (background & 0xFF) / 255.0;
- g = (double) ((background
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for CRTC background color (rev8)
== Series Details ==
Series: CRTC background color (rev8)
URL : https://patchwork.freedesktop.org/series/50834/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
ce8779b97946 drm: Add CRTC background color property
-:255: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'shift' - possible
side-effects?
#255: FILE: include/uapi/drm/drm_mode.h:1049:
+#define DRM_ARGB_COMP(c, shift, numbits) \
+ (__u16)(((c) & 0xull << (shift)) >> ((shift) + 16 - (numbits)))
total: 0 errors, 0 warnings, 1 checks, 151 lines checked
fbe4bbbe8aec drm/i915/gen9+: Add support for pipe background color
52e2c82f7a75 drm/i915: Add background color hardware readout and state check
-:66: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'name' - possible
side-effects?
#66: FILE: drivers/gpu/drm/i915/display/intel_display.c:12656:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_mismatch(fastset, __stringify(name), \
+"(expected 0x%016llx, found 0x%016llx)\n",
\
+current_config->name & mask, \
+pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
-:66: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'name' may be better as
'(name)' to avoid precedence issues
#66: FILE: drivers/gpu/drm/i915/display/intel_display.c:12656:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_mismatch(fastset, __stringify(name), \
+"(expected 0x%016llx, found 0x%016llx)\n",
\
+current_config->name & mask, \
+pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
-:66: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'mask' - possible
side-effects?
#66: FILE: drivers/gpu/drm/i915/display/intel_display.c:12656:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_mismatch(fastset, __stringify(name), \
+"(expected 0x%016llx, found 0x%016llx)\n",
\
+current_config->name & mask, \
+pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
-:66: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'mask' may be better as
'(mask)' to avoid precedence issues
#66: FILE: drivers/gpu/drm/i915/display/intel_display.c:12656:
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_mismatch(fastset, __stringify(name), \
+"(expected 0x%016llx, found 0x%016llx)\n",
\
+current_config->name & mask, \
+pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
total: 0 errors, 0 warnings, 4 checks, 62 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for drm/i915/tgl: Add sysfs interface to control class-of-service (rev3)
== Series Details == Series: drm/i915/tgl: Add sysfs interface to control class-of-service (rev3) URL : https://patchwork.freedesktop.org/series/65769/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC drivers/gpu/drm/i915/gt/intel_mocs.h.s In file included from :0:0: ./drivers/gpu/drm/i915/gt/intel_mocs.h:62:45: error: ‘struct intel_context’ declared inside parameter list will not be visible outside of this definition or declaration [-Werror] void intel_mocs_init_reg_state(const struct intel_context *ce); ^ cc1: all warnings being treated as errors scripts/Makefile.build:293: recipe for target 'drivers/gpu/drm/i915/gt/intel_mocs.h.s' failed make[5]: *** [drivers/gpu/drm/i915/gt/intel_mocs.h.s] Error 1 scripts/Makefile.build:509: recipe for target 'drivers/gpu/drm/i915/gt' failed make[4]: *** [drivers/gpu/drm/i915/gt] Error 2 scripts/Makefile.build:509: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:509: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:509: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1670: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 0/3] CRTC background color
The previous version of this series was posted in February here: https://lists.freedesktop.org/archives/dri-devel/2019-February/208068.html Right before we merged this in February Maarten noticed that we should be setting up the initial property state in a CRTC reset function (which didn't exist yet) instead of when the property was attached. Maarten landed the CRTC reset functionality a week or two later, but I was busy with travel and other work at the time, so revisiting and rebasing this background color series fell through the cracks and I'm just getting back to it now. Userspace consumer is chromeos; these are the links the ChromeOS folks gave me back in February: https://chromium-review.googlesource.com/c/chromium/src/+/1278858 https://chromium-review.googlesource.com/c/chromiumos/platform/drm-tests/+/1241436 IGT is still the same as posted in February: https://lists.freedesktop.org/archives/igt-dev/2019-February/009637.html Cc: Maarten Lankhorst Matt Roper (3): drm: Add CRTC background color property drm/i915/gen9+: Add support for pipe background color drm/i915: Add background color hardware readout and state check drivers/gpu/drm/drm_atomic_state_helper.c| 4 +- drivers/gpu/drm/drm_atomic_uapi.c| 4 ++ drivers/gpu/drm/drm_blend.c | 35 +-- drivers/gpu/drm/drm_mode_config.c| 6 +++ drivers/gpu/drm/i915/display/intel_color.c | 11 +++-- drivers/gpu/drm/i915/display/intel_display.c | 45 drivers/gpu/drm/i915/i915_debugfs.c | 9 include/drm/drm_blend.h | 1 + include/drm/drm_crtc.h | 12 ++ include/drm/drm_mode_config.h| 5 +++ include/uapi/drm/drm_mode.h | 28 11 files changed, 153 insertions(+), 7 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v7 1/3] drm: Add CRTC background color property
Some display controllers can be programmed to present non-black colors
for pixels not covered by any plane (or pixels covered by the
transparent regions of higher planes). Compositors that want a UI with
a solid color background can potentially save memory bandwidth by
setting the CRTC background property and using smaller planes to display
the rest of the content.
To avoid confusion between different ways of encoding RGB data, we
define a standard 64-bit format that should be used for this property's
value. Helper functions and macros are provided to generate and dissect
values in this standard format with varying component precision values.
v2:
- Swap internal representation's blue and red bits to make it easier
to read if printed out. (Ville)
- Document bgcolor property in drm_blend.c. (Sean Paul)
- s/background_color/bgcolor/ for consistency between property name and
value storage field. (Sean Paul)
- Add a convenience function to attach property to a given crtc.
v3:
- Restructure ARGB component extraction macros to be easier to
understand and enclose the parameters in () to avoid calculations
if expressions are passed. (Sean Paul)
- s/rgba/argb/ in helper function/macro names. Even though the idea is
to not worry about the internal representation of the u64, it can
still be confusing to look at code that uses 'rgba' terminology, but
stores values with argb ordering. (Ville)
v4:
- Drop the bgcolor_changed flag. (Ville, Brian Starkey)
- Clarify in kerneldoc that background color is expected to undergo the
same pipe-level degamma/csc/gamma transformations that planes do.
(Brian Starkey)
- Update kerneldoc to indicate non-opaque colors are allowed, but are
generally only useful in special cases such as when writeback
connectors are used (Brian Starkey / Eric Anholt)
v5:
- Set crtc->state->bgcolor to solid black inside
drm_crtc_add_bgcolor_property() in case drivers don't do this
themselves. (Ville)
- Add kerneldoc to drm_crtc_add_bgcolor_property() function.
v7:
- Don't update CRTC state at attach time; instead set the default value
in __drm_atomic_helper_crtc_reset. (Maarten)
Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Cc: Sean Paul
Cc: Brian Starkey
Cc: Eric Anholt
Cc: Stéphane Marchesin
Cc: Daniel Vetter
Cc: Maarten Lankhorst
Cc: Jean-Jacques Hiblot
Signed-off-by: Matt Roper
Reviewed-by: Sean Paul # v2
Reviewed-by: Brian Starkey # v4
---
drivers/gpu/drm/drm_atomic_state_helper.c | 4 ++-
drivers/gpu/drm/drm_atomic_uapi.c | 4 +++
drivers/gpu/drm/drm_blend.c | 35 +--
drivers/gpu/drm/drm_mode_config.c | 6
include/drm/drm_blend.h | 1 +
include/drm/drm_crtc.h| 12
include/drm/drm_mode_config.h | 5
include/uapi/drm/drm_mode.h | 28 ++
8 files changed, 91 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_state_helper.c
b/drivers/gpu/drm/drm_atomic_state_helper.c
index d0a937fb0c56..b8cc12579024 100644
--- a/drivers/gpu/drm/drm_atomic_state_helper.c
+++ b/drivers/gpu/drm/drm_atomic_state_helper.c
@@ -73,8 +73,10 @@ void
__drm_atomic_helper_crtc_reset(struct drm_crtc *crtc,
struct drm_crtc_state *crtc_state)
{
- if (crtc_state)
+ if (crtc_state) {
crtc_state->crtc = crtc;
+ crtc_state->bgcolor = drm_argb(16, 0x, 0, 0, 0);
+ }
crtc->state = crtc_state;
}
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 7a26bfb5329c..038e6a38ae5f 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -469,6 +469,8 @@ static int drm_atomic_crtc_set_property(struct drm_crtc
*crtc,
return -EFAULT;
set_out_fence_for_crtc(state->state, crtc, fence_ptr);
+ } else if (property == config->bgcolor_property) {
+ state->bgcolor = val;
} else if (crtc->funcs->atomic_set_property) {
return crtc->funcs->atomic_set_property(crtc, state, property,
val);
} else {
@@ -503,6 +505,8 @@ drm_atomic_crtc_get_property(struct drm_crtc *crtc,
*val = (state->gamma_lut) ? state->gamma_lut->base.id : 0;
else if (property == config->prop_out_fence_ptr)
*val = 0;
+ else if (property == config->bgcolor_property)
+ *val = state->bgcolor;
else if (crtc->funcs->atomic_get_property)
return crtc->funcs->atomic_get_property(crtc, state, property,
val);
else
diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index d02709dd2d4a..f71af04101e5 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -183,9 +183,22 @@
* plane
[Intel-gfx] [PATCH v7 2/3] drm/i915/gen9+: Add support for pipe background color
Gen9+ platforms allow CRTC's to be programmed with a background/canvas
color below the programmable planes. Let's expose this for use by
compositors.
v2:
- Split out bgcolor sanitization and programming of csc/gamma bits to a
separate patch that we can land before the ABI changes are ready to
go in. (Ville)
- Change a temporary variable name to be more consistent with
other similar functions. (Ville)
- Change register name to SKL_CANVAS for consistency with the
CHV_CANVAS register.
v3:
- Switch register name back to SKL_BOTTOM_COLOR. (Ville)
- Use non-_FW register write. (Ville)
- Minor parameter rename for consistency. (Ville)
v4:
- Removed use of bgcolor_changed flag.
v5:
- s/uint64_t/u64/
v6:
- Rebase onto latest drm-tip (bgcolor writing now moves to the new
color_commit function added by Ville's series)
v7:
- Rebase
Cc: dri-de...@lists.freedesktop.org
Cc: wei.c...@intel.com
Cc: harish.krupo@intel.com
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_color.c | 11 ---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/i915_debugfs.c | 9 +
3 files changed, 30 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_color.c
b/drivers/gpu/drm/i915/display/intel_color.c
index 9ab34902663e..f93153ffc843 100644
--- a/drivers/gpu/drm/i915/display/intel_color.c
+++ b/drivers/gpu/drm/i915/display/intel_color.c
@@ -481,12 +481,17 @@ static void skl_color_commit(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);
enum pipe pipe = crtc->pipe;
+ u64 propval = crtc_state->base.bgcolor;
u32 val = 0;
+ /* Hardware is programmed with 10 bits of precision */
+ val = DRM_ARGB_RED(propval, 10) << 20
+ | DRM_ARGB_GREEN(propval, 10) << 10
+ | DRM_ARGB_BLUE(propval, 10);
+
/*
-* We don't (yet) allow userspace to control the pipe background color,
-* so force it to black, but apply pipe gamma and CSC appropriately
-* so that its handling will match how we program our planes.
+* Apply pipe gamma and CSC appropriately so that its handling will
+* match how we program our planes.
*/
if (crtc_state->gamma_enable)
val |= SKL_BOTTOM_COLOR_GAMMA_ENABLE;
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index bbe088b9d057..78e64c62f34f 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -11833,8 +11833,12 @@ static int intel_crtc_atomic_check(struct drm_crtc
*_crtc,
{
struct intel_crtc *crtc = to_intel_crtc(_crtc);
struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+ struct intel_atomic_state *state =
+ to_intel_atomic_state(_crtc_state->state);
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(_crtc_state);
+ struct intel_crtc_state *old_crtc_state =
+ intel_atomic_get_old_crtc_state(state, crtc);
int ret;
bool mode_changed = needs_modeset(crtc_state);
@@ -11864,6 +11868,9 @@ static int intel_crtc_atomic_check(struct drm_crtc
*_crtc,
return ret;
}
+ if (crtc_state->base.bgcolor != old_crtc_state->base.bgcolor)
+ crtc_state->base.color_mgmt_changed = true;
+
ret = 0;
if (dev_priv->display.compute_pipe_wm) {
ret = dev_priv->display.compute_pipe_wm(crtc_state);
@@ -15210,6 +15217,9 @@ static int intel_crtc_init(struct drm_i915_private
*dev_priv, enum pipe pipe)
WARN_ON(drm_crtc_index(_crtc->base) != intel_crtc->pipe);
+ if (INTEL_GEN(dev_priv) >= 9)
+ drm_crtc_add_bgcolor_property(_crtc->base);
+
return 0;
fail:
@@ -16495,6 +16505,9 @@ static void intel_sanitize_crtc(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state =
to_intel_crtc_state(crtc->base.state);
enum transcoder cpu_transcoder = crtc_state->cpu_transcoder;
+ /* Always force bgcolor to solid black */
+ crtc_state->base.bgcolor = drm_argb(16, 0x, 0, 0, 0);
+
/* Clear any frame start delays used for debugging left by the BIOS */
if (crtc->active && !transcoder_is_dsi(cpu_transcoder)) {
i915_reg_t reg = PIPECONF(cpu_transcoder);
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index fec9fb7cc384..ccb08b759b89 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2773,6 +2773,15 @@ static int i915_display_info(struct seq_file *m, void
*unused)
intel_plane_info(m, crtc);
}
[Intel-gfx] [PATCH v7 3/3] drm/i915: Add background color hardware readout and state check
We should support readout and verification of crtc background color as
we do with other pipe state. Note that our hardware holds less bits of
precision than the CRTC state allows, so we need to take care to only
verify the most significant bits of the color after performing readout.
At boot time the pipe color is already sanitized to full black as
required by ABI, so the new readout here won't break that requirement.
Suggested-by: Ville Syrjälä
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 32
1 file changed, 32 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 78e64c62f34f..516e2927566a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10453,6 +10453,7 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
intel_wakeref_t wakerefs[POWER_DOMAIN_NUM], wf;
enum intel_display_power_domain power_domain;
u64 power_domain_mask;
+ u32 bgcolor;
bool active;
intel_crtc_init_scalers(crtc, pipe_config);
@@ -10565,6 +10566,15 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->pixel_multiplier = 1;
}
+ if (INTEL_GEN(dev_priv) >= 9) {
+ bgcolor = I915_READ(SKL_BOTTOM_COLOR(crtc->pipe));
+ pipe_config->base.bgcolor =
+ drm_argb(10, 0x,
+bgcolor >> 20 & 0x3FF,
+bgcolor >> 10 & 0x3FF,
+bgcolor & 0x3FF);
+ }
+
out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put(dev_priv,
@@ -12245,6 +12255,10 @@ static void intel_dump_pipe_config(const struct
intel_crtc_state *pipe_config,
if (plane->pipe == crtc->pipe)
intel_dump_plane_state(plane_state);
}
+
+ if (INTEL_GEN(dev_priv) >= 9)
+ DRM_DEBUG_KMS("background color: %llx\n",
+ pipe_config->base.bgcolor);
}
static bool check_digital_port_conflicts(struct intel_atomic_state *state)
@@ -12639,6 +12653,16 @@ intel_pipe_config_compare(const struct
intel_crtc_state *current_config,
} \
} while (0)
+#define PIPE_CONF_CHECK_LLX_MASKED(name, mask) do { \
+ if ((current_config->name & mask) != (pipe_config->name & mask)) { \
+ pipe_config_mismatch(fastset, __stringify(name), \
+"(expected 0x%016llx, found 0x%016llx)\n",
\
+current_config->name & mask, \
+pipe_config->name & mask); \
+ ret = false; \
+ } \
+} while (0)
+
#define PIPE_CONF_CHECK_I(name) do { \
if (current_config->name != pipe_config->name) { \
pipe_config_mismatch(fastset, __stringify(name), \
@@ -12945,6 +12969,14 @@ intel_pipe_config_compare(const struct
intel_crtc_state *current_config,
PIPE_CONF_CHECK_INFOFRAME(hdmi);
PIPE_CONF_CHECK_INFOFRAME(drm);
+ /*
+* Hardware only holds top 10 bits of each color component; ignore
+* bottom six bits (and all of alpha) when comparing against readout.
+*/
+ if (INTEL_GEN(dev_priv) >= 9)
+ PIPE_CONF_CHECK_LLX_MASKED(base.bgcolor, 0xFFC0FFC0FFC0);
+
+#undef PIPE_CONF_CHECK_LLX_MASKED
#undef PIPE_CONF_CHECK_X
#undef PIPE_CONF_CHECK_I
#undef PIPE_CONF_CHECK_BOOL
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/ehl: Add sysfs interface to control class-of-service
To provide shared last-level-cache isolation to cpu workloads running
concurrently with gpu workloads, the gpu allocation of cache lines needs
to be restricted to certain ways. Currently GPU hardware supports four
class-of-service(CLOS) levels and there is an associated way-mask for
each CLOS. Each LLC MOCS register has a field to select the clos level.
So in-order to globally set the gpu to a clos level, driver needs
to program entire MOCS table.
Hardware supports reading supported way-mask configuration for GPU using
a bios pcode interface. This interface has two files--llc_clos_modes and
llc_clos. The file llc_clos_modes is read only file and will list the
available way masks. The file llc_clos is read/write and will show the
currently active way mask and writing a new way mask will update the
active way mask of the gpu.
Note of Caution: Restricting cache ways using this mechanism presents a
larger attack surface for side-channel attacks.
Example usage:
> cat /sys/class/drm/card0/llc_clos_modes
0xfff 0xfc0 0xc00 0x800
>cat /sys/class/drm/card0/llc_clos
0xfff
Update to new clos
echo "0x800" > /sys/class/drm/card0/llc_clos
v2: Updated the interface to use two sysfs files(Joonas)
- Gen12 PCode interface is not ready yet to read the way mask.
So removed TGL support and added support for Gen11.
- Updating MOCS in Gen 11 also require changing the context image of
existing contexts.
Referred to gen8_configure_all_contexts() as suggested by Chris.
Signed-off-by: Prathap Kumar Valsan
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 7 +
drivers/gpu/drm/i915/gt/intel_lrc_reg.h | 1 +
drivers/gpu/drm/i915/gt/intel_mocs.c| 215 +++-
drivers/gpu/drm/i915/gt/intel_mocs.h| 3 +
drivers/gpu/drm/i915/i915_drv.h | 8 +
drivers/gpu/drm/i915/i915_reg.h | 1 +
drivers/gpu/drm/i915/i915_sysfs.c | 100 +++
7 files changed, 334 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ab725a6ca0ac..82cbf9b97a55 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2114,6 +2114,13 @@ __execlists_update_reg_state(const struct intel_context
*ce,
intel_sseu_make_rpcs(engine->i915, >sseu);
i915_oa_init_reg_state(ce, engine);
+ /*
+* Gen11 supports update of LLC class-of-service via
+* sysfs interface. Also update the context register state
+* of the new contexts.
+*/
+ if (IS_GEN(engine->i915, 11))
+ intel_mocs_init_reg_state(ce);
}
}
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
index 06ab0276e10e..f07a6262217c 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
+++ b/drivers/gpu/drm/i915/gt/intel_lrc_reg.h
@@ -28,6 +28,7 @@
#define CTX_R_PWR_CLK_STATE(0x42 + 1)
#define GEN9_CTX_RING_MI_MODE 0x54
+#define GEN11_CTX_GFX_MOCS_BASE0x4F2
/* GEN12+ Reg State Context */
#define GEN12_CTX_BB_PER_CTX_PTR (0x12 + 1)
diff --git a/drivers/gpu/drm/i915/gt/intel_mocs.c
b/drivers/gpu/drm/i915/gt/intel_mocs.c
index 728704bbbe18..5eb805b6ee23 100644
--- a/drivers/gpu/drm/i915/gt/intel_mocs.c
+++ b/drivers/gpu/drm/i915/gt/intel_mocs.c
@@ -26,6 +26,9 @@
#include "intel_gt.h"
#include "intel_mocs.h"
#include "intel_lrc.h"
+#include "intel_lrc_reg.h"
+#include "intel_sideband.h"
+#include "gem/i915_gem_context.h"
/* structures required */
struct drm_i915_mocs_entry {
@@ -40,6 +43,7 @@ struct drm_i915_mocs_table {
const struct drm_i915_mocs_entry *table;
};
+#define ctx_mocsN(N) (GEN11_CTX_GFX_MOCS_BASE + 2 * (N) + 1)
/* Defines for the tables (XXX_MOCS_0 - XXX_MOCS_63) */
#define _LE_CACHEABILITY(value)((value) << 0)
#define _LE_TGT_CACHE(value) ((value) << 2)
@@ -51,6 +55,7 @@ struct drm_i915_mocs_table {
#define LE_SCF(value) ((value) << 14)
#define LE_COS(value) ((value) << 15)
#define LE_SSE(value) ((value) << 17)
+#define LE_COS_MASKGENMASK(16, 15)
/* Defines for the tables (LNCFMOCS0 - LNCFMOCS31) - two entries per word */
#define L3_ESC(value) ((value) << 0)
@@ -377,6 +382,7 @@ void intel_mocs_init_engine(struct intel_engine_cs *engine)
struct intel_gt *gt = engine->gt;
struct intel_uncore *uncore = gt->uncore;
struct drm_i915_mocs_table table;
+ unsigned int active_clos;
unsigned int index;
u32 unused_value;
@@ -390,11 +396,16 @@ void intel_mocs_init_engine(struct intel_engine_cs
*engine)
if (!get_mocs_settings(gt, ))
return;
+ active_clos = engine->i915->clos.active_clos;
/* Set unused values to PTE */
unused_value = table.table[I915_MOCS_PTE].control_value;
+ unused_value &=
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On Fri, 27 Sep 2019 16:25:13 +
Parav Pandit wrote:
> Hi Alex,
>
>
> > -Original Message-
> > From: Alex Williamson
> > Sent: Tuesday, September 24, 2019 6:07 PM
> > To: Jason Wang
> > Cc: k...@vger.kernel.org; linux-s...@vger.kernel.org; linux-
> > ker...@vger.kernel.org; dri-de...@lists.freedesktop.org; intel-
> > g...@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org;
> > kwankh...@nvidia.com; m...@redhat.com; tiwei@intel.com;
> > virtualizat...@lists.linux-foundation.org; net...@vger.kernel.org;
> > coh...@redhat.com; maxime.coque...@redhat.com;
> > cunming.li...@intel.com; zhihong.w...@intel.com;
> > rob.mil...@broadcom.com; xiao.w.w...@intel.com;
> > haotian.w...@sifive.com; zhen...@linux.intel.com; zhi.a.w...@intel.com;
> > jani.nik...@linux.intel.com; joonas.lahti...@linux.intel.com;
> > rodrigo.v...@intel.com; airl...@linux.ie; dan...@ffwll.ch;
> > far...@linux.ibm.com; pa...@linux.ibm.com; seb...@linux.ibm.com;
> > ober...@linux.ibm.com; heiko.carst...@de.ibm.com; g...@linux.ibm.com;
> > borntrae...@de.ibm.com; akrow...@linux.ibm.com; fre...@linux.ibm.com;
> > lingshan@intel.com; Ido Shamay ;
> > epere...@redhat.com; l...@redhat.com; Parav Pandit
> > ; christophe.de.dinec...@gmail.com;
> > kevin.t...@intel.com
> > Subject: Re: [PATCH V2 6/8] mdev: introduce virtio device and its device ops
> >
> > On Tue, 24 Sep 2019 21:53:30 +0800
> > Jason Wang wrote:
> >
> > > This patch implements basic support for mdev driver that supports
> > > virtio transport for kernel virtio driver.
> > >
> > > Signed-off-by: Jason Wang
> > > ---
> > > include/linux/mdev.h| 2 +
> > > include/linux/virtio_mdev.h | 145
> > >
> > > 2 files changed, 147 insertions(+)
> > > create mode 100644 include/linux/virtio_mdev.h
> > >
> > > diff --git a/include/linux/mdev.h b/include/linux/mdev.h index
> > > 3414307311f1..73ac27b3b868 100644
> > > --- a/include/linux/mdev.h
> > > +++ b/include/linux/mdev.h
> > > @@ -126,6 +126,8 @@ struct mdev_device *mdev_from_dev(struct device
> > > *dev);
> > >
> > > enum {
> > > MDEV_ID_VFIO = 1,
> > > + MDEV_ID_VIRTIO = 2,
> > > + MDEV_ID_VHOST = 3,
> >
> > MDEV_ID_VHOST isn't used yet here. Also, given the strong interdependence
> > between the class_id and the ops structure, we might wand to define them in
> > the same place. Thanks,
> >
>
> When mlx5_core creates mdevs (parent->ops->create() and it wants to
> bind to mlx5 mdev driver (which does mdev_register_driver()), mlx5
> core driver will publish MDEV_ID_MLX5_NET defined in central place as
> include/linux/mdev.h without any ops structure. Because such ops are
> not relevant. It uses usual, standard ops probe() remove() on the
> mdev (similar to a regular PCI device). So for VHOST case ops may be
> closely related to ID, but not for other type of ID.
>
> Just want to make sure, that scope of ID covers this case.
AIUI, these device-ops are primarily meant to have 1:N multiplexing of
the mdev bus driver. One mdev bus driver supports N vendor drivers via
a common "protocol" defined by this structure. vfio-mdev supports
GVT-g, GRID, and several sample drivers. I think Jason and Tiwei are
attempting something similar if we have multiple vendors that may
provide virtio/vhost parent drivers. If you have a 1:1 model with
mlx5 where you're not trying to abstract a common channel between the
mdev bus driver and the mdev vendor driver, then I suppose you might
not use the device-ops capabilities of the mdev-core. Did I interpret
the question correctly? I think that's probably fine, mdev-core
shouldn't have any dependencies on the device-ops and we shouldn't
really be dictating the bus/vendor link through mdev. Thanks,
Alex
___
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/tgl: Magic interrupt shadow to relieve some random lockups
== Series Details ==
Series: drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
URL : https://patchwork.freedesktop.org/series/67416/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6976 -> Patchwork_14592
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/index.html
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14592:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_execlists:
- {fi-tgl-u2}:NOTRUN -> [DMESG-FAIL][1] +1 similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-tgl-u2/igt@i915_selftest@live_execlists.html
Known issues
Here are the changes found in Patchwork_14592 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][2] -> [INCOMPLETE][3] ([fdo#107718])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
* igt@i915_getparams_basic@basic-eu-total:
- fi-icl-u3: [PASS][4] -> [DMESG-WARN][5] ([fdo#107724])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@i915_getparams_ba...@basic-eu-total.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-icl-u3/igt@i915_getparams_ba...@basic-eu-total.html
* igt@kms_frontbuffer_tracking@basic:
- fi-hsw-peppy: [PASS][6] -> [DMESG-WARN][7] ([fdo#102614])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* {igt@i915_selftest@live_gt_timelines}:
- {fi-tgl-u2}:[INCOMPLETE][8] ([fdo#111831]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: [DMESG-WARN][10] ([fdo#107724]) -> [PASS][11] +4
similar issues
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@kms_f...@basic-flip-vs-dpms.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-icl-u3/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][12] ([fdo#103167]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/fi-icl-u3/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#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#105763]: https://bugs.freedesktop.org/show_bug.cgi?id=105763
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111831]: https://bugs.freedesktop.org/show_bug.cgi?id=111831
Participating hosts (53 -> 46)
--
Missing(7): 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_6976 -> Patchwork_14592
CI-20190529: 20190529
CI_DRM_6976: c698979e8207a4eb568b533f05b9d4580fd5d007 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14592: 781c7510e4dfb0f6815cee70e31b0888dd1cfe22 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
781c7510e4df drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14592/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/guc: Update H2G enable logging action definition
On 9/28/19 3:36 AM, Patchwork wrote: == Series Details == Series: drm/i915/guc: Update H2G enable logging action definition URL : https://patchwork.freedesktop.org/series/67351/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6970_full -> Patchwork_14570_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14570_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14570_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_14570_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@system-suspend-execbuf: - shard-iclb: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-iclb8/igt@i915_pm_...@system-suspend-execbuf.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-iclb1/igt@i915_pm_...@system-suspend-execbuf.html Dmesg warnings are for thunderbolt and do not look to be related to this patch. It looks to be related to fdo#111764. I think patch should be safe to merge. New tests - New tests have been introduced between CI_DRM_6970_full and Patchwork_14570_full: ### New Piglit tests (7) ### * spec@arb_gpu_shader5@texturegather@vs-rgba-2-float-2darray: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegather@vs-rgba-3-float-2darray: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffset@vs-rgba-0-float-2darray: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-0-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-1-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-2-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s * spec@arb_gpu_shader5@texturegatheroffsets@vs-rgba-3-float-2d: - Statuses : 1 incomplete(s) - Exec time: [0.0] s Known issues Here are the changes found in Patchwork_14570_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +3 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-iclb7/igt@gem_exec_as...@concurrent-writes-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +17 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_pm_rpm@cursor-dpms: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108840]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-iclb7/igt@i915_pm_...@cursor-dpms.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-iclb7/igt@i915_pm_...@cursor-dpms.html * igt@kms_busy@basic-modeset-a: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-iclb4/igt@kms_b...@basic-modeset-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-iclb1/igt@kms_b...@basic-modeset-a.html * igt@kms_cursor_legacy@cursor-vs-flip-varying-size: - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-apl7/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-apl1/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6970/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14570/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@plain-flip-fb-recreate-interruptible: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#100368]) [15]:
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
== Series Details == Series: drm/i915/tgl: Magic interrupt shadow to relieve some random lockups URL : https://patchwork.freedesktop.org/series/67416/ State : warning == Summary == $ dim checkpatch origin/drm-tip 781c7510e4df drm/i915/tgl: Magic interrupt shadow to relieve some random lockups -:43: CHECK:USLEEP_RANGE: usleep_range is preferred over udelay; see Documentation/timers/timers-howto.rst #43: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1205: + udelay(250); total: 0 errors, 0 warnings, 1 checks, 28 lines checked ___ 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: Fix g4x sprite scaling stride check with GTT remapping
== Series Details ==
Series: drm/i915: Fix g4x sprite scaling stride check with GTT remapping
URL : https://patchwork.freedesktop.org/series/67415/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6976 -> Patchwork_14591
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/index.html
Known issues
Here are the changes found in Patchwork_14591 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_close_race@basic-threads:
- fi-icl-u3: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@gem_close_r...@basic-threads.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/fi-icl-u3/igt@gem_close_r...@basic-threads.html
Possible fixes
* {igt@i915_selftest@live_gt_timelines}:
- {fi-tgl-u2}:[INCOMPLETE][3] ([fdo#111831]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111045] / [fdo#111096]) -> [FAIL][8]
([fdo#111407])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/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#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[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
[fdo#111831]: https://bugs.freedesktop.org/show_bug.cgi?id=111831
Participating hosts (53 -> 46)
--
Missing(7): 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_6976 -> Patchwork_14591
CI-20190529: 20190529
CI_DRM_6976: c698979e8207a4eb568b533f05b9d4580fd5d007 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14591: 8485ce705a6f71645351cb39b55ff5d2b148b7f9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8485ce705a6f drm/i915: Fix g4x sprite scaling stride check with GTT remapping
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14591/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
Could anyone please review the patch below & let me know if any other ideas
please?
https://patchwork.freedesktop.org/patch/332806/?series=66837=3
Thanks,
> -Original Message-
> From: S, Srinivasan
> Sent: Wednesday, September 25, 2019 8:33 PM
> To: 'Ville Syrjälä'
> Cc: Navare, Manasi D ; 'intel-
> g...@lists.freedesktop.org' ; 'dri-
> de...@lists.freedesktop.org'
> Subject: RE: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC
> cable
>
> Hi Ville,
>
> I have revised the patch from DRM_ERROR to DRM_DEBUG, could you please
> review?
>
> https://patchwork.freedesktop.org/patch/332806/?series=66837=3
>
> Thanks,
>
> -Original Message-
> From: S, Srinivasan
> Sent: Thursday, September 19, 2019 7:22 PM
> To: 'Ville Syrjälä'
> Cc: Navare, Manasi D ; 'intel-
> g...@lists.freedesktop.org' ; 'dri-
> de...@lists.freedesktop.org'
> Subject: RE: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC
> cable
>
> Then it's better that, could we change it to DRM_DEBUG_KMS("failed to update
> payload %d\n", ret); instead of DRM_ERROR("failed to update payload %d\n",
> ret);, without any connector status check, would that be fine?
>
> Regards,
> -Original Message-
> From: Ville Syrjälä
> Sent: Thursday, September 19, 2019 5:34 PM
> To: S, Srinivasan
> Cc: Navare, Manasi D ; intel-
> g...@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC
> cable
>
> On Thu, Sep 19, 2019 at 07:23:30AM +, S, Srinivasan wrote:
> > Would the following be appropriate fix?
> >
> > if (connector || connector->base.status ==
> > connector_status_connected)
> {
> > ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> > if (ret) {
> > DRM_ERROR("failed to update payload %d\n", ret);
> > }
> > }
>
> The whole connector->status check is racy. IMO don't do it.
>
> >
> > Regards,
> > -Original Message-
> > From: dri-devel On Behalf Of
> > Manasi Navare
> > Sent: Wednesday, September 18, 2019 11:55 PM
> > To: Ville Syrjälä
> > Cc: S, Srinivasan ;
> > intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> > Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging
> > TypeC cable
> >
> > On Wed, Sep 18, 2019 at 09:11:36PM +0300, Ville Syrjälä wrote:
> > > On Wed, Sep 18, 2019 at 10:50:39AM -0700, Manasi Navare wrote:
> > > > On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com
> wrote:
> > > > > From: Srinivasan S
> > > > >
> > > > > This patch avoids DP MST payload error message in dmesg, as it
> > > > > is trying to read the payload from the disconnected DP MST device.
> > > > > After the unplug the connector status is disconnected and we
> > > > > should not be looking for the payload and hence remove the error and
> throw the warning.
> > > > >
> > > > > This details can be found in:
> > > > > https://bugs.freedesktop.org/show_bug.cgi?id=111632
> > > >
> > > > Please add this link as Bugzilla:
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=111632 after the Sign
> > > > off statement
> > > >
> > > > >
> > > > > Signed-off-by: Srinivasan S
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++-
> > > > > 1 file changed, 6 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 eeeb3f933aa4..5b2278fdf675 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > > @@ -215,7 +215,12 @@ static void intel_mst_disable_dp(struct
> > > > > intel_encoder *encoder,
> > > > >
> > > > > ret = drm_dp_update_payload_part1(_dp->mst_mgr);
> > > > > if (ret) {
> > > > > - DRM_ERROR("failed to update payload %d\n", ret);
> > > > > + if (!connector ||
> > > > > + connector->base.status !=
> connector_status_connected) {
> > > > > + DRM_WARN("DP MST disconnect\n");
> > > >
> > > > May be adding this check before calling drm_dp_update_payload_part1() is
> a better idea?
> > > > If the connector is disconnected, why update payload?
> > > >
> > > > Jani, Ville, thoughts?
> > >
> > > Or just convert it to a debug?
> >
> > Sure that will work, but do we really want to update the payload if the
> connector status is disconnected.
> > So shouldnt checking that before calling the function be a better fix?
> >
> > Manasi
> >
> > >
> > > >
> > > > Regards
> > > > Manasi
> > > >
> > > > > + } else {
> > > > > + DRM_ERROR("failed to update payload %d\n",
> ret);
> > > > > + }
> > > > > }
> > > > > if (old_crtc_state->has_audio)
> > > > > intel_audio_codec_disable(encoder,
> > > > > --
> > > > > 2.7.4
> > > > >
> > >
> > > --
> > > Ville
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Exercise context switching in parallell (rev4)
== Series Details == Series: drm/i915/selftests: Exercise context switching in parallell (rev4) URL : https://patchwork.freedesktop.org/series/67395/ State : success == Summary == CI Bug Log - changes from CI_DRM_6973_full -> Patchwork_14587_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14587_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +7 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-apl4/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108] / [fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl3/igt@i915_pm_...@system-suspend-execbuf.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-skl8/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#105767]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.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_6973/shard-skl6/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-skl7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html - shard-apl: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-apl8/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-hsw5/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb3/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/shard-skl7/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]:
[Intel-gfx] [CI] drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
My current theory is that this masks interrupt delivery to the local CPU
during a critical phase. Purely papering over the symptoms with a delay
plucked out of thin air from testing on tgl1-gem, refined slightly by
just waiting for the next ack (though technically the next CS event may
not be the corresponding event for this submit, but an intermediate
completion).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Andi Shyti
Acked-by: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 22 ++
1 file changed, 22 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fa385218ce92..6b995017571d 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1186,6 +1186,28 @@ static void execlists_submit_ports(struct
intel_engine_cs *engine)
/* we need to manually load the submit queue */
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
+
+ /*
+* Now this is evil magic.
+*
+* Adding the same udelay() to process_csb before we clear
+* execlists->pending (that is after we receive the HW ack for this
+* submit and before we can submit again) does not relieve the symptoms
+* (machine lockup). So is the active difference here the wait under
+* the irq-off spinlock? That gives more credance to the theory that
+* the issue is interrupt delivery. Also note that we still rely on
+* disabling RPS, again that seems like an issue with simultaneous
+* GT interrupts being delivered to the same CPU.
+*/
+ if (IS_TIGERLAKE(engine->i915)) {
+ u64 start = local_clock();
+
+ udelay(250);
+
+ while (READ_ONCE(*execlists->pending) && /* wait for ack */
+ (local_clock() - start) >> 22 == 0) /* ~4ms timeout */
+ cpu_relax();
+ }
}
static bool ctx_single_port_submission(const struct intel_context *ce)
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/6] drm/i915/display/icl: HW state readout for transcoder port sync config
On Thu, Sep 26, 2019 at 05:11:10PM -0700, Manasi Navare wrote:
After the state is committed, we readout the HW registers and compare
the HW state with the SW state that we just committed.
For Transcdoer port sync, we add master_transcoder and the
salves bitmask to the crtc_state, hence we need to read those during
the HW state readout to avoid pipe state mismatch.
v6:
* Go through both parts of HW readout (Maarten)
* Add a WARN if the same trans configured as
master and slave (Ville, Maarten)
v5:
* Add return INVALID in defaut case (Maarten)
v4:
* Get power domains in master loop for get_config (Ville)
v3:
* Add TRANSCODER_D (Maarten)
* v3 Reviewed-by: Maarten Lankhorst
v2:
* Add Transcoder_D and MISSING_CASE (Maarten)
Cc: Ville Syrjälä
Cc: Maarten Lankhorst
Cc: Matt Roper
Cc: Jani Nikula
Signed-off-by: Manasi Navare
Reviewed-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 69
1 file changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index af6b8f10f132..6e4af6ded6f0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10510,6 +10510,72 @@ static void haswell_get_ddi_port_state(struct
intel_crtc *crtc,
}
}
+static enum transcoder transcoder_master(struct drm_i915_private *dev_priv,
+enum transcoder cpu_transcoder)
I find this function name misleading since there's no indication it's
actually reading the HW.
Maybe even inline this in the only caller? Or would a `_readout` suffix
make sense?
+{
+ u32 trans_port_sync, master_select;
+
+ trans_port_sync = I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
+
+ if ((trans_port_sync & PORT_SYNC_MODE_ENABLE) == 0)
+ return INVALID_TRANSCODER;
+
+ master_select = trans_port_sync &
+ PORT_SYNC_MODE_MASTER_SELECT_MASK;
+ switch (master_select) {
+ case 1:
+ return TRANSCODER_A;
+ case 2:
+ return TRANSCODER_B;
+ case 3:
+ return TRANSCODER_C;
+ case 4:
+ return TRANSCODER_D;
+ default:
+ MISSING_CASE(master_select);
+ return INVALID_TRANSCODER;
+ }
+}
+
+static void icelake_get_trans_port_sync_config(struct intel_crtc *crtc,
+ struct intel_crtc_state
*pipe_config)
+{
+ struct drm_device *dev = crtc->base.dev;
+ struct drm_i915_private *dev_priv = to_i915(dev);
+ u32 transcoders;
+ enum transcoder cpu_transcoder;
+
+ pipe_config->master_transcoder = transcoder_master(dev_priv,
+
pipe_config->cpu_transcoder);
+ if (pipe_config->master_transcoder != INVALID_TRANSCODER)
+ pipe_config->sync_mode_slaves_mask = 0;
+
+ transcoders = BIT(TRANSCODER_A) |
+ BIT(TRANSCODER_B) |
+ BIT(TRANSCODER_C) |
+ BIT(TRANSCODER_D);
+ for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
+ enum intel_display_power_domain power_domain;
+ intel_wakeref_t trans_wakeref;
+
+ power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
+ trans_wakeref = intel_display_power_get_if_enabled(dev_priv,
+
power_domain);
+
+ if (!trans_wakeref)
+ continue;
+
+ if (transcoder_master(dev_priv, cpu_transcoder) ==
+ pipe_config->cpu_transcoder)
+ pipe_config->sync_mode_slaves_mask |=
BIT(cpu_transcoder);
+
+ intel_display_power_put(dev_priv, power_domain, trans_wakeref);
+ }
+
+ WARN_ON(pipe_config->master_transcoder != INVALID_TRANSCODER &&
+ pipe_config->sync_mode_slaves_mask);
+}
+
static bool haswell_get_pipe_config(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config)
{
@@ -10629,6 +10695,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
*crtc,
pipe_config->pixel_multiplier = 1;
}
+ if (INTEL_GEN(dev_priv) >= 11)
+ icelake_get_trans_port_sync_config(crtc, pipe_config);
Three letters prefix for functions is much more common, so I'd stick
with that. For Ice Lake for example there's only icelake_get_ddi_pll()
as opposed to tons of icl_*() functions.
+
out:
for_each_power_domain(power_domain, power_domain_mask)
intel_display_power_put(dev_priv,
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Refuse modes with hdisplay==4096 on pre-HSW DP (rev2)
== Series Details ==
Series: series starting with [1/2] drm/i915: Refuse modes with hdisplay==4096
on pre-HSW DP (rev2)
URL : https://patchwork.freedesktop.org/series/63892/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6976 -> Patchwork_14590
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/index.html
Known issues
Here are the changes found in Patchwork_14590 that come from known issues:
### IGT changes ###
Issues hit
* igt@core_auth@basic-auth:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@core_a...@basic-auth.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/fi-icl-u3/igt@core_a...@basic-auth.html
* igt@gem_ctx_create@basic-files:
- fi-icl-u3: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] /
[fdo#109100])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/fi-icl-u3/igt@gem_ctx_cre...@basic-files.html
Possible fixes
* {igt@i915_selftest@live_gt_timelines}:
- {fi-tgl-u2}:[INCOMPLETE][5] ([fdo#111831]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111045] / [fdo#111096]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.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#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[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#111831]: https://bugs.freedesktop.org/show_bug.cgi?id=111831
Participating hosts (53 -> 45)
--
Missing(8): fi-ilk-m540 fi-bxt-dsi 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_6976 -> Patchwork_14590
CI-20190529: 20190529
CI_DRM_6976: c698979e8207a4eb568b533f05b9d4580fd5d007 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14590: 4f5696761d4b5fdaa2e80e29403eaf8020c48b91 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
4f5696761d4b drm/i915: Check some transcoder timing minimum limits
4ace124ba15f drm/i915: Refuse modes with hdisplay==4096 on pre-HSW DP
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14590/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for DC3CO Support for TGL (rev13)
== Series Details ==
Series: DC3CO Support for TGL (rev13)
URL : https://patchwork.freedesktop.org/series/64923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6976 -> Patchwork_14589
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/index.html
Known issues
Here are the changes found in Patchwork_14589 that come from known issues:
### IGT changes ###
Issues hit
* igt@prime_vgem@basic-fence-flip:
- 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_6976/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/fi-icl-u3/igt@prime_v...@basic-fence-flip.html
Possible fixes
* {igt@i915_selftest@live_gt_timelines}:
- {fi-tgl-u2}:[INCOMPLETE][3] ([fdo#111831]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/fi-tgl-u2/igt@i915_selftest@live_gt_timelines.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][5] ([fdo#111045] / [fdo#111096]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_flip@basic-flip-vs-dpms:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +4
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@kms_f...@basic-flip-vs-dpms.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/fi-icl-u3/igt@kms_f...@basic-flip-vs-dpms.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u3: [FAIL][9] ([fdo#103167]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6976/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.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#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111831]: https://bugs.freedesktop.org/show_bug.cgi?id=111831
Participating hosts (53 -> 46)
--
Missing(7): 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_6976 -> Patchwork_14589
CI-20190529: 20190529
CI_DRM_6976: c698979e8207a4eb568b533f05b9d4580fd5d007 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5208: c0131b4f132acf287d9d05b0f5078003d3159e1c @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14589: 545caadae45b04ab37b64076d167ddb4058a920e @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
545caadae45b drm/i915/tgl: Add DC3CO counter in i915_dmc_info
e94eda9ae56d drm/i915/tgl: Switch between dc3co and dc5 based on display
idleness
507c90fb4404 drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
f7b7735ce04d drm/i915/tgl: Enable DC3CO state in "DC Off" power well
c0d55331aa20 drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
2885248fbdcb drm/i915/tgl: Add DC3CO required register and bits
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14589/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
== Series Details == Series: lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers URL : https://patchwork.freedesktop.org/series/67405/ State : success == Summary == CI Bug Log - changes from CI_DRM_6973_full -> Patchwork_14586_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14586_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]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb8/igt@gem_exec_as...@concurrent-writes-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-iclb1/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_exec_schedule@deep-vebox: - shard-iclb: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb6/igt@gem_exec_sched...@deep-vebox.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-iclb7/igt@gem_exec_sched...@deep-vebox.html * igt@gem_pread@snoop: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl5/igt@gem_pr...@snoop.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-apl8/igt@gem_pr...@snoop.html * igt@i915_pm_rc6_residency@rc6-accuracy: - shard-kbl: [PASS][7] -> [SKIP][8] ([fdo#109271]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-kbl1/igt@i915_pm_rc6_reside...@rc6-accuracy.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-kbl2/igt@i915_pm_rc6_reside...@rc6-accuracy.html * igt@i915_pm_rpm@modeset-stress-extra-wait: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([fdo#105763] / [fdo#106538]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-glk4/igt@i915_pm_...@modeset-stress-extra-wait.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl3/igt@i915_susp...@fence-restore-tiled2untiled.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-apl7/igt@i915_susp...@fence-restore-tiled2untiled.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#105767]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#105363]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-glk5/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +4 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-skl9/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [24]:
[Intel-gfx] DDC on Thinkpad x220
Hi! Thinkpad X220 should be new enough machine to talk DDC to the monitors, right? And my monitor has DDC enable/disable in the menu, so it should support it, too... But I don't have /dev/i2c* and did not figure out how to talk to the monitor. Is the support there in the kernel? What do I need to enable it? lspci says: 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) Thanks, Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html signature.asc Description: Digital signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Make is_signed_type() simpler
== Series Details == Series: Make is_signed_type() simpler URL : https://patchwork.freedesktop.org/series/67413/ State : failure == Summary == CALLscripts/checksyscalls.sh CALLscripts/atomic/check-atomics.sh DESCEND objtool CHK include/generated/compile.h CC [M] drivers/gpu/drm/i915/gvt/trace_points.o In file included from ./include/trace/define_trace.h:102:0, from drivers/gpu/drm/i915/gvt/trace.h:383, from drivers/gpu/drm/i915/gvt/trace_points.c:33: ./drivers/gpu/drm/i915/gvt/./trace.h: In function ‘trace_event_define_fields_spt_alloc’: ./include/linux/trace_events.h:549:40: error: ordered comparison of pointer with integer zero [-Werror=extra] #define is_signed_type(type) ((type)-1 < 0) ^ ./include/trace/trace_events.h:455:2: note: in definition of macro ‘DECLARE_EVENT_CLASS’ tstruct; \ ^~~ ./include/trace/trace_events.h:77:9: note: in expansion of macro ‘PARAMS’ PARAMS(tstruct), \ ^~ ./drivers/gpu/drm/i915/gvt/./trace.h:42:1: note: in expansion of macro ‘TRACE_EVENT’ TRACE_EVENT(spt_alloc, ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h:48:2: note: in expansion of macro ‘TP_STRUCT__entry’ TP_STRUCT__entry( ^~~~ ./include/trace/trace_events.h:401:6: note: in expansion of macro ‘is_signed_type’ is_signed_type(type), filter_type); \ ^~ ./include/trace/trace_events.h:415:29: note: in expansion of macro ‘__field_ext’ #define __field(type, item) __field_ext(type, item, FILTER_OTHER) ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h:50:3: note: in expansion of macro ‘__field’ __field(void *, spt) ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h: In function ‘trace_event_define_fields_spt_free’: ./include/linux/trace_events.h:549:40: error: ordered comparison of pointer with integer zero [-Werror=extra] #define is_signed_type(type) ((type)-1 < 0) ^ ./include/trace/trace_events.h:455:2: note: in definition of macro ‘DECLARE_EVENT_CLASS’ tstruct; \ ^~~ ./include/trace/trace_events.h:77:9: note: in expansion of macro ‘PARAMS’ PARAMS(tstruct), \ ^~ ./drivers/gpu/drm/i915/gvt/./trace.h:72:1: note: in expansion of macro ‘TRACE_EVENT’ TRACE_EVENT(spt_free, ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h:77:2: note: in expansion of macro ‘TP_STRUCT__entry’ TP_STRUCT__entry( ^~~~ ./include/trace/trace_events.h:401:6: note: in expansion of macro ‘is_signed_type’ is_signed_type(type), filter_type); \ ^~ ./include/trace/trace_events.h:415:29: note: in expansion of macro ‘__field_ext’ #define __field(type, item) __field_ext(type, item, FILTER_OTHER) ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h:79:3: note: in expansion of macro ‘__field’ __field(void *, spt) ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h: In function ‘trace_event_define_fields_gvt_command’: ./include/linux/trace_events.h:549:40: error: ordered comparison of pointer with integer zero [-Werror=extra] #define is_signed_type(type) ((type)-1 < 0) ^ ./include/trace/trace_events.h:455:2: note: in definition of macro ‘DECLARE_EVENT_CLASS’ tstruct; \ ^~~ ./include/trace/trace_events.h:77:9: note: in expansion of macro ‘PARAMS’ PARAMS(tstruct), \ ^~ ./drivers/gpu/drm/i915/gvt/./trace.h:228:1: note: in expansion of macro ‘TRACE_EVENT’ TRACE_EVENT(gvt_command, ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h:236:2: note: in expansion of macro ‘TP_STRUCT__entry’ TP_STRUCT__entry( ^~~~ ./include/trace/trace_events.h:401:6: note: in expansion of macro ‘is_signed_type’ is_signed_type(type), filter_type); \ ^~ ./include/trace/trace_events.h:415:29: note: in expansion of macro ‘__field_ext’ #define __field(type, item) __field_ext(type, item, FILTER_OTHER) ^~~ ./drivers/gpu/drm/i915/gvt/./trace.h:243:3: note: in expansion of macro ‘__field’ __field(void*, workload) ^~~ cc1: all warnings being treated as errors scripts/Makefile.build:280: recipe for target 'drivers/gpu/drm/i915/gvt/trace_points.o' failed make[4]: *** [drivers/gpu/drm/i915/gvt/trace_points.o] Error 1 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm/i915' failed make[3]: *** [drivers/gpu/drm/i915] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu/drm' failed make[2]: *** [drivers/gpu/drm] Error 2 scripts/Makefile.build:497: recipe for target 'drivers/gpu' failed make[1]: *** [drivers/gpu] Error 2 Makefile:1087: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
On Sun, Sep 22, 2019 at 10:08:02AM -0700, Manasi Navare wrote: In case of tiled displays when the two tiles are sent across two CRTCs over two separate DP SST connectors, we need a mechanism to synchronize the two CRTCs and their corresponding transcoders. So use the master-slave mode where there is one master corresponding to last horizontal and vertical tile that needs to be genlocked with all other slave tiles. This patch identifies saves the master transcoder in all the slave CRTC states. This is needed to select the master CRTC/transcoder while configuring transcoder port sync for the corresponding slaves. v4: * Rebase v3: * Use master_tramscoder instead of master_crtc for valid HW state readouts (Ville) v2: * Move this to intel_mode_set_pipe_config(Jani N, Ville) * Use slave_bitmask to save associated slaves in master crtc state (Ville) Cc: Daniel Vetter Cc: Ville Syrjälä Cc: Maarten Lankhorst Cc: Matt Roper Signed-off-by: Manasi Navare Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/display/intel_display.c | 123 ++ drivers/gpu/drm/i915/display/intel_display.h | 3 + .../drm/i915/display/intel_display_types.h| 6 + 3 files changed, 132 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index c05ba6af6226..4ff375d5852d 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -521,6 +521,24 @@ needs_modeset(const struct intel_crtc_state *state) return drm_atomic_crtc_needs_modeset(>base); } +bool +is_trans_port_sync_mode(struct drm_i915_private *dev_priv, + const struct intel_crtc_state *state) on TGL we now also need a master transcoder for DP-MST. I'm wondering if we couldn't reuse the same mechanism so we would dissociate a little bit the port_sync_mode from saving or searching for a master transcoder in crtc_state. @@ -12369,6 +12478,15 @@ intel_modeset_pipe_config(struct intel_crtc_state *pipe_config) drm_mode_set_crtcinfo(_config->base.adjusted_mode, CRTC_STEREO_DOUBLE); + /* Set the crtc_state defaults for trans_port_sync */ + pipe_config->master_transcoder = INVALID_TRANSCODER; could we get away with the INVALID_TRANSCODER by simply making pipe_config->master_transcoder = pipe_config->cpu_transcoder? then we can always make sure it's assigned to something valid and use it in the cases it makes sense (port sync mode and dp-mst). Lucas De Marchi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Make is_signed_type() simpler
>-Original Message-
>From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of
>Alexey Dobriyan
>Sent: Sunday, September 29, 2019 4:06 PM
>To: a...@linux-foundation.org
>Cc: intel-gfx@lists.freedesktop.org; li...@rasmusvillemoes.dk; linux-
>ker...@vger.kernel.org; rost...@goodmis.org; mi...@redhat.com
>Subject: [Intel-gfx] [PATCH] Make is_signed_type() simpler
>
>* Simply compare -1 with 0,
>* Drop unnecessary parenthesis sets
>
>New macro leaves pointer as "unsigned type" but gives a warning,
>which should be fine because asking whether a pointer is signed is
>strange question.
>
>I'm not sure what's going on in the i915 driver, it is shipping kernel
>pointers to userspace.
>
>Signed-off-by: Alexey Dobriyan
>---
>
> drivers/gpu/drm/i915/i915_trace.h | 86 +++--
>-
> include/linux/overflow.h |2
> include/linux/trace_events.h |2
> tools/include/linux/overflow.h|2
> 4 files changed, 46 insertions(+), 46 deletions(-)
>
>--- a/drivers/gpu/drm/i915/i915_trace.h
>+++ b/drivers/gpu/drm/i915/i915_trace.h
>@@ -419,16 +419,16 @@ TRACE_EVENT(i915_gem_object_create,
> TP_ARGS(obj),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>+ __field(unsigned long, obj)
>__field(u64, size)
>),
>
> TP_fast_assign(
>- __entry->obj = obj;
>+ __entry->obj = (unsigned long)obj;
> __entry->size = obj->base.size;
> ),
>
>- TP_printk("obj=%p, size=0x%llx", __entry->obj, __entry->size)
>+ TP_printk("obj=%p, size=0x%llx", (void *)__entry->obj, __entry-
Looking up the printk format specifiers, I see:
%p
Pointers printed without a specifier extension (i.e unadorned %p) are
hashed to give a unique identifier without leaking kernel addresses to user
space.
This would seem to me that we this code is correct. Am I misreading this?
Mike
>>size)
> );
>
> TRACE_EVENT(i915_gem_shrink,
>@@ -456,25 +456,25 @@ TRACE_EVENT(i915_vma_bind,
> TP_ARGS(vma, flags),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>- __field(struct i915_address_space *, vm)
>+ __field(unsigned long, obj)
>+ __field(unsigned long, vm)
>__field(u64, offset)
>__field(u64, size)
>__field(unsigned, flags)
>),
>
> TP_fast_assign(
>- __entry->obj = vma->obj;
>- __entry->vm = vma->vm;
>+ __entry->obj = (unsigned long)vma->obj;
>+ __entry->vm = (unsigned long)vma->vm;
> __entry->offset = vma->node.start;
> __entry->size = vma->node.size;
> __entry->flags = flags;
> ),
>
> TP_printk("obj=%p, offset=0x%016llx size=0x%llx%s vm=%p",
>-__entry->obj, __entry->offset, __entry->size,
>+(void *)__entry->obj, __entry->offset, __entry->size,
> __entry->flags & PIN_MAPPABLE ? ", mappable" : "",
>-__entry->vm)
>+(void *)__entry->vm)
> );
>
> TRACE_EVENT(i915_vma_unbind,
>@@ -482,21 +482,21 @@ TRACE_EVENT(i915_vma_unbind,
> TP_ARGS(vma),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>- __field(struct i915_address_space *, vm)
>+ __field(unsigned long, obj)
>+ __field(unsigned long, vm)
>__field(u64, offset)
>__field(u64, size)
>),
>
> TP_fast_assign(
>- __entry->obj = vma->obj;
>- __entry->vm = vma->vm;
>+ __entry->obj = (unsigned long)vma->obj;
>+ __entry->vm = (unsigned long)vma->vm;
> __entry->offset = vma->node.start;
> __entry->size = vma->node.size;
> ),
>
> TP_printk("obj=%p, offset=0x%016llx size=0x%llx vm=%p",
>-__entry->obj, __entry->offset, __entry->size, __entry-
>>vm)
>+(void *)__entry->obj, __entry->offset, __entry->size,
>(void *)__entry->vm)
> );
>
> TRACE_EVENT(i915_gem_object_pwrite,
>@@ -504,19 +504,19 @@ TRACE_EVENT(i915_gem_object_pwrite,
> TP_ARGS(obj, offset, len),
>
> TP_STRUCT__entry(
>- __field(struct drm_i915_gem_object *, obj)
>+
[Intel-gfx] [PATCH] drm/i915: Fix g4x sprite scaling stride check with GTT remapping
From: Ville Syrjälä
I forgot to update the g4x sprite scaling stride check when GTT
remapping was introduced. The stride of the original framebuffer
is irrelevant when remapping is used and instead we want to check
the stride of the remapped view.
Also drop the duplicate width_bytes check. We already check that
a few lines earlier.
Fixes: df79cf441910 ("drm/i915: Store the final plane stride in plane_state")
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_sprite.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c
b/drivers/gpu/drm/i915/display/intel_sprite.c
index 3d56db32291b..633fa8069348 100644
--- a/drivers/gpu/drm/i915/display/intel_sprite.c
+++ b/drivers/gpu/drm/i915/display/intel_sprite.c
@@ -1513,12 +1513,13 @@ g4x_sprite_check_scaling(struct intel_crtc_state
*crtc_state,
const struct drm_framebuffer *fb = plane_state->base.fb;
const struct drm_rect *src = _state->base.src;
const struct drm_rect *dst = _state->base.dst;
int src_x, src_w, src_h, crtc_w, crtc_h;
const struct drm_display_mode *adjusted_mode =
_state->base.adjusted_mode;
+ unsigned int stride = plane_state->color_plane[0].stride;
unsigned int cpp = fb->format->cpp[0];
unsigned int width_bytes;
int min_width, min_height;
crtc_w = drm_rect_width(dst);
crtc_h = drm_rect_height(dst);
@@ -1554,15 +1555,15 @@ g4x_sprite_check_scaling(struct intel_crtc_state
*crtc_state,
if (width_bytes > 4096) {
DRM_DEBUG_KMS("Fetch width (%d) exceeds hardware max with
scaling (%u)\n",
width_bytes, 4096);
return -EINVAL;
}
- if (width_bytes > 4096 || fb->pitches[0] > 4096) {
+ if (stride > 4096) {
DRM_DEBUG_KMS("Stride (%u) exceeds hardware max with scaling
(%u)\n",
- fb->pitches[0], 4096);
+ stride, 4096);
return -EINVAL;
}
return 0;
}
--
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/4] drm/rect: Add drm_rect_translate_to()
== Series Details ==
Series: series starting with [1/4] drm/rect: Add drm_rect_translate_to()
URL : https://patchwork.freedesktop.org/series/67402/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973_full -> Patchwork_14584_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_14584_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@i915_pm_dc@dc5-psr}:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl7/igt@i915_pm...@dc5-psr.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-skl8/igt@i915_pm...@dc5-psr.html
Known issues
Here are the changes found in Patchwork_14584_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_isolation@rcs0-s3:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +5
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html
* igt@gem_exec_schedule@preempt-queue-bsd1:
- shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +21 similar
issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@gem_exec_sched...@preempt-queue-bsd1.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-iclb7/igt@gem_exec_sched...@preempt-queue-bsd1.html
* igt@gem_exec_schedule@reorder-wide-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +3 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html
* igt@i915_suspend@debugfs-reader:
- shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108] /
[fdo#107773] / [fdo#111867])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl6/igt@i915_susp...@debugfs-reader.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-skl10/igt@i915_susp...@debugfs-reader.html
* igt@kms_flip@basic-flip-vs-modeset:
- shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#103313] /
[fdo#105345])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-kbl1/igt@kms_f...@basic-flip-vs-modeset.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-kbl2/igt@kms_f...@basic-flip-vs-modeset.html
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: [PASS][13] -> [DMESG-WARN][14] ([fdo#103313])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-kbl7/igt@kms_f...@flip-vs-suspend.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-kbl2/igt@kms_f...@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render:
- shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +1 similar
issue
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html
* igt@kms_frontbuffer_tracking@psr-suspend:
- shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108] /
[fdo#106978])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl9/igt@kms_frontbuffer_track...@psr-suspend.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-skl6/igt@kms_frontbuffer_track...@psr-suspend.html
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min:
- shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html
* igt@kms_psr@psr2_cursor_render:
- shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +2 similar
issues
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_psr@psr2_cursor_render.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/shard-iclb8/igt@kms_psr@psr2_cursor_render.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][23] -> [FAIL][24] ([fdo#99912])
[23]:
[Intel-gfx] [PATCH v10 2/6] drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently. [Animesh]
v2: Using a switch statement for cleaner code. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 29 +++
drivers/gpu/drm/i915/i915_params.c| 3 +-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index f1186bc23542..0b685c517bcb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -711,7 +711,11 @@ static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
u32 mask;
mask = DC_STATE_EN_UPTO_DC5;
- if (INTEL_GEN(dev_priv) >= 11)
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6
+ | DC_STATE_EN_DC9;
+ else if (IS_GEN(dev_priv, 11))
mask |= DC_STATE_EN_UPTO_DC6 | DC_STATE_EN_DC9;
else if (IS_GEN9_LP(dev_priv))
mask |= DC_STATE_EN_DC9;
@@ -3940,14 +3944,17 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int requested_dc;
int max_dc;
- if (INTEL_GEN(dev_priv) >= 11) {
- max_dc = 2;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
* suspend/resume, so allow it unconditionally.
*/
mask = DC_STATE_EN_DC9;
+ } else if (IS_GEN(dev_priv, 11)) {
+ max_dc = 2;
+ mask = DC_STATE_EN_DC9;
} else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv)) {
max_dc = 2;
mask = 0;
@@ -3966,7 +3973,7 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = enable_dc;
} else if (enable_dc == -1) {
requested_dc = max_dc;
- } else if (enable_dc > max_dc && enable_dc <= 2) {
+ } else if (enable_dc > max_dc && enable_dc <= 4) {
DRM_DEBUG_KMS("Adjusting requested max DC state (%d->%d)\n",
enable_dc, max_dc);
requested_dc = max_dc;
@@ -3975,10 +3982,20 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = max_dc;
}
- if (requested_dc > 1)
+ switch (requested_dc) {
+ case 4:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6;
+ break;
+ case 3:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC5;
+ break;
+ case 2:
mask |= DC_STATE_EN_UPTO_DC6;
- if (requested_dc > 0)
+ break;
+ case 1:
mask |= DC_STATE_EN_UPTO_DC5;
+ break;
+ }
DRM_DEBUG_KMS("Allowed DC state mask %02x\n", mask);
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..4f1806f65040 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,8 @@ i915_param_named(modeset, int, 0400,
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
- "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
+ "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
+ "3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
i915_param_named_unsafe(enable_fbc, int, 0600,
"Enable frame buffer compression for power savings "
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 6/6] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
Adding DC3CO counter in i915_dmc_info debugfs will be
useful for DC3CO validation.
DMC firmware uses DMC_DEBUG3 register as DC3CO counter
register on TGL, as per B.Specs DMC_DEBUG3 is general
purpose register.
v1: comment modification for DMC_DBUG3.
using GEN >= 12 check instead of IS_TIGERLAKE()
to print DMC_DEBUG3 counter value.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_debugfs.c | 7 +++
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b5b449a88cf1..fcccfd4507bd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2410,6 +2410,13 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
if (INTEL_GEN(dev_priv) >= 12) {
dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
+ /*
+* NOTE: DMC_DEBUG3 is a general purpose reg.
+* According to B.Specs:49196 DMC f/w reuses DC5/6 counter
+* reg for DC3CO debugging and validation,
+* but TGL DMC f/w is using DMC_DEBUG3 reg for DC3CO counter.
+*/
+ seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
} else {
dc5_reg = IS_BROXTON(dev_priv) ? BXT_CSR_DC3_DC5_COUNT :
SKL_CSR_DC3_DC5_COUNT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3ee9720af207..af810f6ed652 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7263,6 +7263,8 @@ enum {
#define TGL_DMC_DEBUG_DC5_COUNT_MMIO(0x101084)
#define TGL_DMC_DEBUG_DC6_COUNT_MMIO(0x101088)
+#define DMC_DEBUG3 _MMIO(0x101090)
+
/* interrupts */
#define DE_MASTER_IRQ_CONTROL (1 << 31)
#define DE_SPRITEB_FLIP_DONE(1 << 29)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 4/6] drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
DC3CO enabling B.Specs sequence requires to enable end configure
exit scanlines to TRANS_EXITLINE register, programming this register
has to be part of modeset sequence as this can't be change when
transcoder or port is enabled.
When system boots with only eDP panel there may not be real
modeset as BIOS has already programmed the necessary registers,
therefore it needs to force a modeset to enable and configure
DC3CO exitline.
v1: Computing dc3co_exitline crtc state from a DP encoder
compute config. [Imre]
Enabling and disabling DC3CO PSR2 transcoder exitline from
encoder pre_enable and post_disable hooks. [Imre]
Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
v2: Code refactoring for symmetry and to avoid exported function. [Imre]
Removing IS_TIGERLAKE check from compute_config, adding PIPE_A
restriction and clearing dc3co_exitline state if crtc is not active
or it is not PSR2 capable in dc3co exitline compute_config. [Imre]
Using IS_TGL check and dc3co exitline get_config
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 104 +-
drivers/gpu/drm/i915/display/intel_display.c | 1 +
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
4 files changed, 105 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index aa470c70a198..d779a33c70db 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -45,6 +45,7 @@
#include "intel_lspcon.h"
#include "intel_panel.h"
#include "intel_psr.h"
+#include "intel_sprite.h"
#include "intel_tc.h"
#include "intel_vdsc.h"
@@ -3200,6 +3201,97 @@ static void intel_ddi_disable_fec_state(struct
intel_encoder *encoder,
POSTING_READ(intel_dp->regs.dp_tp_ctl);
}
+static u32 intel_get_frame_time_us(const struct intel_crtc_state *cstate)
+{
+ if (!cstate || !cstate->base.active)
+ return 0;
+
+ return DIV_ROUND_UP(1000 * 1000,
+ drm_mode_vrefresh(>base.adjusted_mode));
+}
+
+static void
+tgl_clear_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+ u32 val;
+
+ if (!cstate->dc3co_exitline)
+ return;
+
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+static void
+tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ u32 val, exit_scanlines;
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+
+ if (!cstate->dc3co_exitline)
+ return;
+
+ exit_scanlines = cstate->dc3co_exitline;
+ exit_scanlines <<= EXITLINE_SHIFT;
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ val |= exit_scanlines;
+ val |= EXITLINE_ENABLE;
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+static void tgl_dc3co_exitline_compute_config(struct intel_encoder *encoder,
+ struct intel_crtc_state *cstate)
+{
+ u32 exit_scanlines;
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+ u32 crtc_vdisplay = cstate->base.adjusted_mode.crtc_vdisplay;
+
+ dev_priv->psr.dc3co_frame_time_us = 0;
+ cstate->dc3co_exitline = 0;
+
+ if (!(dev_priv->csr.allowed_dc_mask & DC_STATE_EN_DC3CO))
+ return;
+
+ /* B.Specs:49196 DC3CO only works with pipeA and DDIA.*/
+ if (to_intel_crtc(cstate->base.crtc)->pipe != PIPE_A ||
+ encoder->port != PORT_A)
+ return;
+
+ if (!cstate->has_psr2 || !cstate->base.active)
+ return;
+
+ /*
+* DC3CO Exit time 200us B.Spec 49196
+* PSR2 transcoder Early Exit scanlines = ROUNDUP(200 / line time) + 1
+*/
+ exit_scanlines =
+ intel_usecs_to_scanlines(>base.adjusted_mode, 200) + 1;
+
+ if (WARN_ON(exit_scanlines > crtc_vdisplay))
+ return;
+
+ cstate->dc3co_exitline = crtc_vdisplay - exit_scanlines;
+ DRM_DEBUG_KMS("DC3CO exit scanlines %d\n", cstate->dc3co_exitline);
+ dev_priv->psr.dc3co_frame_time_us = intel_get_frame_time_us(cstate);
+}
+
+static void tgl_dc3co_exitline_get_config(struct intel_crtc_state *crtc_state)
+{
+ u32 val;
+ struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
+
+ if (INTEL_GEN(dev_priv) < 12)
+ return;
+
+ val = I915_READ(EXITLINE(crtc_state->cpu_transcoder));
+
+ if (val & EXITLINE_ENABLE)
+ crtc_state->dc3co_exitline = val &
[Intel-gfx] [PATCH v10 5/6] drm/i915/tgl: Switch between dc3co and dc5 based on display idleness
DC3CO is useful power state, when DMC detects PSR2 idle frame
while an active video playback, playing 30fps video on 60hz panel
is the classic example of this use case.
B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
It will be worthy to enable DC3CO after completion of each pageflip
and switch back to DC5 when display is idle because driver doesn't
differentiate between video playback and a normal pageflip.
We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
targeted for VPB use case. We are not interested here for frontbuffer
invalidates calls because that triggers PSR2 exit, which will
explicitly disable DC3CO.
DC5 and DC6 saves more power, but can't be entered during video
playback because there are not enough idle frames in a row to meet
most PSR2 panel deep sleep entry requirement typically 4 frames.
As PSR2 existing implementation is using minimum 6 idle frames for
deep sleep, it is safer to enable DC5/6 after 6 idle frames
(By scheduling a delayed work of 6 idle frames, once DC3CO has been
enabled after a pageflip).
After manually waiting for 6 idle frames DC5/6 will be enabled and
PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
6 idle frames.
In future when we will enable S/W PSR2 tracking, we can change the
PSR2 required deep sleep idle frames to 1 so DMC can trigger the
DC5/6 immediately after S/W manual waiting of 6 idle frames get
complete.
v2: calculated s/w state to switch over dc3co when there is an
update. [Imre]
Used cancel_delayed_work_sync() in order to avoid any race
with already scheduled delayed work. [Imre]
v3: Cancel_delayed_work_sync() may blocked the commit work.
hence dropping it, dc5_idle_thread() checks the valid wakeref before
putting the reference count, which avoids any chances of dropping
a zero wakeref. [Imre (IRC)]
v4: Used frontbuffer flush mechanism. [Imre]
v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
Used cancel_delayed_work_sync() in encoder disable path. [Imre]
Used mod_delayed_work() instead of cancelling and scheduling a
delayed work. [Imre]
Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
sleep. [Imre]
Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
v6: Used dc3co_exitline check instead of TGL and dc3co allowed_dc_mask
checks, used delayed_work_pending with the psr lock and removed the
psr2_deep_slp_disabled flag. [Imre]
v7: Code refactoring moved the most of functional code to inte_psr.c [Imre]
Using frontbuffer_bits on psr.pipe check instead of
busy_frontbuffer_bits. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 45
.../drm/i915/display/intel_display_power.h| 2 +
drivers/gpu/drm/i915/display/intel_psr.c | 109 +-
drivers/gpu/drm/i915/i915_drv.h | 2 +
4 files changed, 157 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 67ba92dd8366..9fddebfda169 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -886,6 +886,51 @@ lookup_power_well(struct drm_i915_private *dev_priv,
return _priv->power_domains.power_wells[0];
}
+/**
+ * intel_display_power_set_target_dc_state - Set target dc state.
+ * @dev_priv: i915 device
+ * @state: state which needs to be set as target_dc_state.
+ *
+ * This function set the "DC off" power well target_dc_state,
+ * based upon this target_dc_stste, "DC off" power well will
+ * enable desired DC state.
+ */
+void intel_display_power_set_target_dc_state(struct drm_i915_private *dev_priv,
+u32 state)
+{
+ struct i915_power_well *power_well;
+ bool dc_off_enabled;
+ struct i915_power_domains *power_domains = _priv->power_domains;
+
+ mutex_lock(_domains->lock);
+ power_well = lookup_power_well(dev_priv, SKL_DISP_DC_OFF);
+
+ if (WARN_ON(!power_well))
+ goto unlock;
+
+ state = sanitize_target_dc_state(dev_priv, state);
+
+ if (state == dev_priv->csr.target_dc_state)
+ goto unlock;
+
+ dc_off_enabled = power_well->desc->ops->is_enabled(dev_priv,
+ power_well);
+ /*
+* If DC off power well is disabled, need to enable and disable the
+* DC off power well to effect target DC state.
+*/
+ if (!dc_off_enabled)
+ power_well->desc->ops->enable(dev_priv, power_well);
+
+ dev_priv->csr.target_dc_state = state;
+
+ if (!dc_off_enabled)
+ power_well->desc->ops->disable(dev_priv,
[Intel-gfx] [PATCH v10 3/6] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
Add target_dc_state and used by set_target_dc_state API
in order to enable DC3CO state with existing DC states.
target_dc_state will enable/disable the desired DC state in
DC_STATE_EN reg when "DC Off" power well gets disable/enable.
v2: commit log improvement.
v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
to a appropriate place haswell_crtc_enable(). [Imre]
Changed the DC3CO power well enabled call back logic as
recommended in review comments. [Imre]
v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
v5: using udelay() instead of waiting for DC3CO exit status.
v6: Fixed minor unwanted change.
v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask
in "DC off" power well callback. [Imre]
Adding "DC off" power well id to older platforms. [Imre]
Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre]
v9: Used switch case for target DC state in
gen9_dc_off_power_well_disable(), checking DC3CO state against
allowed DC mask, using WARN_ON() in
tgl_set_target_dc_state(). [Imre]
v10: Code refactoring and using sanitize_target_dc_state(). [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 80 ---
.../drm/i915/display/intel_display_power.h| 1 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 73 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0b685c517bcb..67ba92dd8366 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -785,6 +785,52 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+static u32
+sanitize_target_dc_state(struct drm_i915_private *dev_priv,
+u32 target_dc_state)
+{
+ u32 states[] = {
+ DC_STATE_EN_UPTO_DC6,
+ DC_STATE_EN_UPTO_DC5,
+ DC_STATE_EN_DC3CO,
+ DC_STATE_DISABLE,
+ };
+ int i;
+
+ for (i = 0; i < ARRAY_SIZE(states) - 1; i++) {
+ if (target_dc_state != states[i])
+ continue;
+
+ if (dev_priv->csr.allowed_dc_mask & target_dc_state)
+ break;
+
+ target_dc_state = states[i + 1];
+ }
+
+ return target_dc_state;
+}
+
+static void tgl_enable_dc3co(struct drm_i915_private *dev_priv)
+{
+ DRM_DEBUG_KMS("Enabling DC3CO\n");
+ gen9_set_dc_state(dev_priv, DC_STATE_EN_DC3CO);
+}
+
+static void tgl_disable_dc3co(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ DRM_DEBUG_KMS("Disabling DC3CO\n");
+ val = I915_READ(DC_STATE_EN);
+ val &= ~DC_STATE_DC3CO_STATUS;
+ I915_WRITE(DC_STATE_EN, val);
+ gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+ /*
+* Delay of 200us DC3CO Exit time B.Spec 49196
+*/
+ usleep_range(200, 210);
+}
+
static void bxt_enable_dc9(struct drm_i915_private *dev_priv)
{
assert_can_enable_dc9(dev_priv);
@@ -952,7 +998,8 @@ static void bxt_verify_ddi_phy_power_wells(struct
drm_i915_private *dev_priv)
static bool gen9_dc_off_power_well_enabled(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
+ return ((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC3CO) == 0 &&
+ (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0);
}
static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
@@ -968,6 +1015,11 @@ static void gen9_disable_dc_states(struct
drm_i915_private *dev_priv)
{
struct intel_cdclk_state cdclk_state = {};
+ if (dev_priv->csr.target_dc_state == DC_STATE_EN_DC3CO) {
+ tgl_disable_dc3co(dev_priv);
+ return;
+ }
+
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
dev_priv->display.get_cdclk(dev_priv, _state);
@@ -1000,10 +1052,17 @@ static void gen9_dc_off_power_well_disable(struct
drm_i915_private *dev_priv,
if (!dev_priv->csr.dmc_payload)
return;
- if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC6)
+ switch (dev_priv->csr.target_dc_state) {
+ case DC_STATE_EN_DC3CO:
+ tgl_enable_dc3co(dev_priv);
+ break;
+ case DC_STATE_EN_UPTO_DC6:
skl_enable_dc6(dev_priv);
- else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
+ break;
+ case DC_STATE_EN_UPTO_DC5:
[Intel-gfx] [PATCH v10 1/6] drm/i915/tgl: Add DC3CO required register and bits
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
DC3CO enable bit will be used by driver to make DC3CO
ready for DMC f/w and status bit will be used as DC3CO
entry status.
2. Transcoder EXITLINE register and its bit fields and mask.
Transcoder EXITLINE enable bit represents PSR2 idle frame
reset should be applied at exit line and exitlines mask
represent required number of scanlines at which DC3CO
exit happens.
B.Specs:49196
v1: Use of REG_BIT and using extra space for EXITLINE_ macro
definition. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e752de9470bd..3ee9720af207 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4140,6 +4140,7 @@ enum {
#define _VTOTAL_A 0x6000c
#define _VBLANK_A 0x60010
#define _VSYNC_A 0x60014
+#define _EXITLINE_A0x60018
#define _PIPEASRC 0x6001c
#define _BCLRPAT_A 0x60020
#define _VSYNCSHIFT_A 0x60028
@@ -4186,11 +4187,16 @@ enum {
#define VTOTAL(trans) _MMIO_TRANS2(trans, _VTOTAL_A)
#define VBLANK(trans) _MMIO_TRANS2(trans, _VBLANK_A)
#define VSYNC(trans) _MMIO_TRANS2(trans, _VSYNC_A)
+#define EXITLINE(trans)_MMIO_TRANS2(trans, _EXITLINE_A)
#define BCLRPAT(trans) _MMIO_TRANS2(trans, _BCLRPAT_A)
#define VSYNCSHIFT(trans) _MMIO_TRANS2(trans, _VSYNCSHIFT_A)
#define PIPESRC(trans) _MMIO_TRANS2(trans, _PIPEASRC)
#define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
+#define EXITLINE_ENABLE REG_BIT(31)
+#define EXITLINE_MASKREG_GENMASK(12, 0)
+#define EXITLINE_SHIFT 0
+
/*
* HSW+ eDP PSR registers
*
@@ -10292,6 +10298,8 @@ enum skl_power_gate {
/* GEN9 DC */
#define DC_STATE_EN_MMIO(0x45504)
#define DC_STATE_DISABLE 0
+#define DC_STATE_EN_DC3CO REG_BIT(30)
+#define DC_STATE_DC3CO_STATUS REG_BIT(29)
#define DC_STATE_EN_UPTO_DC5 (1 << 0)
#define DC_STATE_EN_DC9 (1 << 3)
#define DC_STATE_EN_UPTO_DC6 (2 << 0)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v10 0/6] DC3CO Support for TGL
This v10 revision has most of the chages related to dc3co series code refactoring and fixes for few review comment provided by imre. Anshuman Gupta (6): drm/i915/tgl: Add DC3CO required register and bits drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask drm/i915/tgl: Enable DC3CO state in "DC Off" power well drm/i915/tgl: Do modeset to enable and configure DC3CO exitline drm/i915/tgl: Switch between dc3co and dc5 based on display idleness drm/i915/tgl: Add DC3CO counter in i915_dmc_info drivers/gpu/drm/i915/display/intel_ddi.c | 104 +++- drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_power.c| 154 -- .../drm/i915/display/intel_display_power.h| 3 + .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_psr.c | 109 - drivers/gpu/drm/i915/i915_debugfs.c | 7 + drivers/gpu/drm/i915/i915_drv.h | 4 + drivers/gpu/drm/i915/i915_params.c| 3 +- drivers/gpu/drm/i915/i915_reg.h | 10 ++ 10 files changed, 377 insertions(+), 19 deletions(-) -- 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 RFT drm/i915/tgl: Re-enable rps
== Series Details == Series: RFT drm/i915/tgl: Re-enable rps URL : https://patchwork.freedesktop.org/series/67398/ State : success == Summary == CI Bug Log - changes from CI_DRM_6973_full -> Patchwork_14583_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14583_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_partial_pwrite_pread@writes-after-reads-display: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl1/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-apl6/igt@gem_partial_pwrite_pr...@writes-after-reads-display.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108686]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl3/igt@gem_tiled_swapp...@non-threaded.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-apl1/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_selftest@mock_fence: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb8/igt@i915_selftest@mock_fence.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-iclb7/igt@i915_selftest@mock_fence.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#109507]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl6/igt@kms_f...@flip-vs-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-skl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +5 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][13] -> [INCOMPLETE][14] ([fdo#104108]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-skl9/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-skl4/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-iclb8/igt@kms_psr@psr2_cursor_render.html * igt@kms_rotation_crc@sprite-rotation-270: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([fdo#106107]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl7/igt@kms_rotation_...@sprite-rotation-270.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-skl10/igt@kms_rotation_...@sprite-rotation-270.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl1/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-apl1/igt@kms_setm...@basic.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-apl: [PASS][23] -> [DMESG-WARN][24] ([fdo#108566]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl8/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/shard-apl2/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html *
Re: [Intel-gfx] [PATCH v4] drm/i915/selftests: Exercise context switching in parallel
On 30/09/2019 15:49, Chris Wilson wrote:
We currently test context switching on each engine as a basic stress
test (just verifying that nothing explodes if we execute 2 requests from
different contexts sequentially). What we have not tested is what
happens if we try and do so on all available engines simultaneously,
putting our SW and the HW under the maximal stress.
v2: Clone the set of engines from the first context into the secondary
contexts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 225 ++
1 file changed, 225 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index dc25bcc3e372..81a83c34404c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -156,6 +156,230 @@ static int live_nop_switch(void *arg)
return err;
}
+struct parallel_switch {
+ struct task_struct *tsk;
+ struct intel_context *ce[2];
+};
+
+static int __live_parallel_switch1(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq = NULL;
+ int err, n;
+
+ for (n = 0; n < ARRAY_SIZE(arg->ce); n++) {
+ i915_request_put(rq);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[n]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+ }
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ return err;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int __live_parallel_switchN(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+ int n;
+
+ count = 0;
+ do {
+ for (n = 0; n < ARRAY_SIZE(arg->ce); n++) {
+ struct i915_request *rq;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[n]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+ }
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int live_parallel_switch(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
+ __live_parallel_switch1,
+ __live_parallel_switchN,
+ NULL,
+ };
+ struct parallel_switch *data = NULL;
+ struct i915_gem_engines *engines;
+ struct i915_gem_engines_iter it;
+ int (* const *fn)(void *arg);
+ struct i915_gem_context *ctx;
+ struct intel_context *ce;
+ struct drm_file *file;
+ int n, m, count;
+ int err = 0;
+
+ /*
+* Check we can process switches on all engines simultaneously.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+
+ ctx = live_context(i915, file);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out_locked;
+ }
+
+ engines = i915_gem_context_lock_engines(ctx);
+ count = engines->num_engines;
+
+ data = kcalloc(count, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ i915_gem_context_unlock_engines(ctx);
+ err = -ENOMEM;
+ goto out_locked;
+ }
+
+ m = 0; /* Use the first context as our template for the engines */
+ for_each_gem_engine(ce, engines, it) {
+ err = intel_context_pin(ce);
+ if (err) {
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Exercise context switching in parallell (rev4)
== Series Details ==
Series: drm/i915/selftests: Exercise context switching in parallell (rev4)
URL : https://patchwork.freedesktop.org/series/67395/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14587
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/index.html
Known issues
Here are the changes found in Patchwork_14587 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_6973/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_mmap_gtt@basic-read-write-distinct:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_mmap_...@basic-read-write-distinct.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/fi-icl-u3/igt@gem_mmap_...@basic-read-write-distinct.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/fi-icl-u3/igt@gem_m...@basic-small-bo.html
* igt@i915_selftest@live_gem_contexts:
- fi-bxt-dsi: [INCOMPLETE][9] ([fdo#103927]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111736]: https://bugs.freedesktop.org/show_bug.cgi?id=111736
Participating hosts (53 -> 45)
--
Additional (1): fi-cml-h
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-skl-guc
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6973 -> Patchwork_14587
CI-20190529: 20190529
CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14587: d759ff0773524d9e4accb50023b488f0a9c63ed4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d759ff077352 drm/i915/selftests: Exercise context switching in parallel
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14587/index.html
___
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/selftests: Exercise context switching in parallell (rev2)
== Series Details == Series: drm/i915/selftests: Exercise context switching in parallell (rev2) URL : https://patchwork.freedesktop.org/series/67395/ State : success == Summary == CI Bug Log - changes from CI_DRM_6973_full -> Patchwork_14582_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14582_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_6973/shard-apl5/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb6/igt@gem_exec_sched...@reorder-wide-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-iclb4/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#103313]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-kbl4/igt@gem_soft...@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-kbl2/igt@gem_soft...@noreloc-s3.html * igt@i915_selftest@live_execlists: - shard-skl: [PASS][7] -> [DMESG-FAIL][8] ([fdo#08]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl9/igt@i915_selftest@live_execlists.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-skl5/igt@i915_selftest@live_execlists.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_6973/shard-iclb8/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-iclb8/igt@i915_selftest@live_hangcheck.html * igt@kms_atomic_transition@2x-modeset-transitions: - shard-hsw: [PASS][11] -> [SKIP][12] ([fdo#109271]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-hsw6/igt@kms_atomic_transit...@2x-modeset-transitions.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-hsw5/igt@kms_atomic_transit...@2x-modeset-transitions.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#105767]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +6 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-iclb1/igt@kms_frontbuffer_track...@fbc-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#108145]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-iclb1/igt@kms_psr@psr2_cursor_render.html * igt@kms_setmode@basic: - shard-apl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl1/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-apl7/igt@kms_setm...@basic.html - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/shard-skl3/igt@kms_setm...@basic.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109276]) +15 similar issues [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@prime_b...@hang-bsd2.html
Re: [Intel-gfx] [PATCH v3 4/6] drm/i915/display/icl: Enable master-slaves in trans port sync
On Sun, Sep 22, 2019 at 10:08:05AM -0700, Manasi Navare wrote:
> As per the display enable sequence, we need to follow the enable sequence
> for slaves first with DP_TP_CTL set to Idle and configure the transcoder
> port sync register to select the corersponding master, then follow the
> enable sequence for master leaving DP_TP_CTL to idle.
> At this point the transcoder port sync mode is configured and enabled
> and the Vblanks of both ports are synchronized so then set DP_TP_CTL
> for the slave and master to Normal and do post crtc enable updates.
>
> v6:
> * Modeset implies active_changed, remove one condition (Maarten)
> v5:
> * Fix checkpatch warning (Manasi)
> v4:
> * Reuse skl_commit_modeset_enables() hook (Maarten)
> * Obtain slave crtc and states from master (Maarten)
> v3:
> * Rebase on drm-tip (Manasi)
> v2:
> * Create a icl_update_crtcs hook (Maarten, Danvet)
> * This sequence only for CRTCs in trans port sync mode (Maarten)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Signed-off-by: Manasi Navare
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 3 +-
> drivers/gpu/drm/i915/display/intel_display.c | 141 ++-
> drivers/gpu/drm/i915/display/intel_display.h | 2 +
> 3 files changed, 142 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 3e6394139964..62e9f5602b6b 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3347,7 +3347,8 @@ static void hsw_ddi_pre_enable_dp(struct intel_encoder
> *encoder,
> true);
> intel_dp_sink_set_fec_ready(intel_dp, crtc_state);
> intel_dp_start_link_train(intel_dp);
> - if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> + if ((port != PORT_A || INTEL_GEN(dev_priv) >= 9) &&
> + !is_trans_port_sync_mode(dev_priv, crtc_state))
> intel_dp_stop_link_train(intel_dp);
>
> intel_ddi_enable_fec(encoder, crtc_state);
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 711987eb4e9e..10425a789b5e 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -13928,6 +13928,30 @@ static void intel_update_crtc(struct intel_crtc
> *crtc,
> intel_finish_crtc_commit(state, crtc);
> }
>
> +static struct intel_crtc *intel_get_slave_crtc(struct drm_i915_private
> *dev_priv,
'dev_priv' can be derived from the crtc state.
> +struct intel_crtc_state
> *new_crtc_state)
const
> +{
cpu_transcoder = ffs(slaves) - 1;
return get_crtc((enum pipe)cpu_transcoder);
or something.
Maybe toss in a WARN_ON(!is_power_of_2(slaves)).
> + if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_A))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_A);
> + else if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_B))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_B);
> + else if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_C))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_C);
> + else if (new_crtc_state->sync_mode_slaves_mask &
> + BIT(TRANSCODER_D))
> + return intel_get_crtc_for_pipe(dev_priv,
> +PIPE_D);
> + /* should never happen */
> + WARN_ON(1);
> + return NULL;
> +}
> +
> static void intel_old_crtc_state_disables(struct intel_atomic_state *state,
> struct intel_crtc_state
> *old_crtc_state,
> struct intel_crtc_state
> *new_crtc_state,
> @@ -14006,6 +14030,104 @@ static void intel_commit_modeset_enables(struct
> intel_atomic_state *state)
> }
> }
>
> +static void intel_crtc_enable_trans_port_sync(struct intel_crtc *crtc,
> + struct intel_atomic_state *state,
> + struct intel_crtc_state
> *new_crtc_state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> +
> + update_scanline_offset(new_crtc_state);
> + dev_priv->display.crtc_enable(new_crtc_state, state);
> + intel_crtc_enable_pipe_crc(crtc);
> +}
> +
> +static void intel_set_dp_tp_ctl_normal(struct intel_crtc *crtc,
> +struct intel_atomic_state *state)
> +{
> + struct drm_connector_state *conn_state;
> + struct drm_connector *conn;
> + struct intel_dp *intel_dp;
> + int i;
> +
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Exercise context switching in parallell (rev4)
== Series Details ==
Series: drm/i915/selftests: Exercise context switching in parallell (rev4)
URL : https://patchwork.freedesktop.org/series/67395/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d759ff077352 drm/i915/selftests: Exercise context switching in parallel
-:36: WARNING:LINE_SPACING: Missing a blank line after declarations
#36: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:168:
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
-:77: WARNING:LINE_SPACING: Missing a blank line after declarations
#77: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:209:
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
-:107: WARNING:LINE_SPACING: Missing a blank line after declarations
#107: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:239:
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
-:115: WARNING:LINE_SPACING: Missing a blank line after declarations
#115: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:247:
+ struct i915_gem_engines_iter it;
+ int (* const *fn)(void *arg);
-:201: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!data[n].ce[0]"
#201: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:333:
+ if (data[n].ce[0] == NULL)
total: 0 errors, 4 warnings, 1 checks, 237 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
== Series Details ==
Series: lib/string-choice: add yesno(), onoff(), enableddisabled(), plural()
helpers
URL : https://patchwork.freedesktop.org/series/67405/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14586
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/index.html
Known issues
Here are the changes found in Patchwork_14586 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-blb-e6850/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/fi-blb-e6850/igt@i915_module_l...@reload.html
* igt@i915_module_load@reload-no-display:
- fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) +2
similar issues
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/fi-icl-u3/igt@i915_module_l...@reload-no-display.html
* igt@i915_selftest@live_hangcheck:
- fi-bsw-kefka: [PASS][5] -> [INCOMPLETE][6] ([fdo#105876])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/fi-bsw-kefka/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#111045] / [fdo#111096])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/fi-icl-u3/igt@gem_m...@basic-small-bo.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111867]: https://bugs.freedesktop.org/show_bug.cgi?id=111867
Participating hosts (53 -> 45)
--
Additional (1): fi-cml-h
Missing(9): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-skl-6770hq
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6973 -> Patchwork_14586
CI-20190529: 20190529
CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14586: 776ae2f2dd012e0dd0fc1ae9831f082e6eabfbb3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
776ae2f2dd01 lib/string-choice: add yesno(), onoff(), enableddisabled(),
plural() helpers
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14586/index.html
___
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/selftests: Exercise context switching in parallell (rev3)
== Series Details == Series: drm/i915/selftests: Exercise context switching in parallell (rev3) URL : https://patchwork.freedesktop.org/series/67395/ State : success == Summary == CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14585 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/index.html Known issues Here are the changes found in Patchwork_14585 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-blb-e6850/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_selftest@live_sanitycheck: - 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_6973/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/fi-icl-u3/igt@i915_selftest@live_sanitycheck.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_mmap@basic-small-bo: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/fi-icl-u3/igt@gem_m...@basic-small-bo.html * igt@i915_selftest@live_gem_contexts: - fi-bxt-dsi: [INCOMPLETE][9] ([fdo#103927]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html [fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407 Participating hosts (53 -> 45) -- Additional (1): fi-cml-h Missing(9): fi-ilk-m540 fi-hsw-4200u fi-tgl-u2 fi-skl-6770hq fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_6973 -> Patchwork_14585 CI-20190529: 20190529 CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_14585: b6e359fa23f7dc9c62fac7fc6948d7813ca91232 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == b6e359fa23f7 drm/i915/selftests: Exercise context switching in parallel == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14585/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
== Series Details == Series: lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers URL : https://patchwork.freedesktop.org/series/67405/ State : warning == Summary == $ dim checkpatch origin/drm-tip 776ae2f2dd01 lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers -:165: WARNING:FILE_PATH_CHANGES: added, moved or deleted file(s), does MAINTAINERS need updating? #165: new file mode 100644 total: 0 errors, 1 warnings, 0 checks, 145 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4] drm/i915/selftests: Exercise context switching in parallel
We currently test context switching on each engine as a basic stress
test (just verifying that nothing explodes if we execute 2 requests from
different contexts sequentially). What we have not tested is what
happens if we try and do so on all available engines simultaneously,
putting our SW and the HW under the maximal stress.
v2: Clone the set of engines from the first context into the secondary
contexts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 225 ++
1 file changed, 225 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index dc25bcc3e372..81a83c34404c 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -156,6 +156,230 @@ static int live_nop_switch(void *arg)
return err;
}
+struct parallel_switch {
+ struct task_struct *tsk;
+ struct intel_context *ce[2];
+};
+
+static int __live_parallel_switch1(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq = NULL;
+ int err, n;
+
+ for (n = 0; n < ARRAY_SIZE(arg->ce); n++) {
+ i915_request_put(rq);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[n]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+ }
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ return err;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int __live_parallel_switchN(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+ int n;
+
+ count = 0;
+ do {
+ for (n = 0; n < ARRAY_SIZE(arg->ce); n++) {
+ struct i915_request *rq;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[n]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+ }
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int live_parallel_switch(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
+ __live_parallel_switch1,
+ __live_parallel_switchN,
+ NULL,
+ };
+ struct parallel_switch *data = NULL;
+ struct i915_gem_engines *engines;
+ struct i915_gem_engines_iter it;
+ int (* const *fn)(void *arg);
+ struct i915_gem_context *ctx;
+ struct intel_context *ce;
+ struct drm_file *file;
+ int n, m, count;
+ int err = 0;
+
+ /*
+* Check we can process switches on all engines simultaneously.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+
+ ctx = live_context(i915, file);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out_locked;
+ }
+
+ engines = i915_gem_context_lock_engines(ctx);
+ count = engines->num_engines;
+
+ data = kcalloc(count, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ i915_gem_context_unlock_engines(ctx);
+ err = -ENOMEM;
+ goto out_locked;
+ }
+
+ m = 0; /* Use the first context as our template for the engines */
+ for_each_gem_engine(ce, engines, it) {
+ err = intel_context_pin(ce);
+ if (err) {
+ i915_gem_context_unlock_engines(ctx);
+ goto
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/rect: Add drm_rect_translate_to()
== Series Details ==
Series: series starting with [1/4] drm/rect: Add drm_rect_translate_to()
URL : https://patchwork.freedesktop.org/series/67402/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14584
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/index.html
Known issues
Here are the changes found in Patchwork_14584 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_flink_basic@bad-flink:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +2
similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/fi-icl-u3/igt@gem_flink_ba...@bad-flink.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/fi-icl-u3/igt@gem_m...@basic-small-bo.html
* igt@i915_selftest@live_gem_contexts:
- fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (53 -> 46)
--
Additional (1): fi-cml-h
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6973 -> Patchwork_14584
CI-20190529: 20190529
CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14584: f3a20d7ec37c67f5d9fb73941b12621cdaa2aff0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f3a20d7ec37c drm/i915: Use drm_rect_init()
104847f6b61a drm/i915: Use drm_rect_translate_to()
321630731752 drm/rect: Add drm_rect_init()
54e6f0f6b1ee drm/rect: Add drm_rect_translate_to()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14584/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [PATCH v2] lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
On 30/09/2019 16.18, Jani Nikula wrote:
> The kernel has plenty of ternary operators to choose between constant
> strings, such as condition ? "yes" : "no", as well as value == 1 ? "" :
> "s":
>
>
> ---
>
> v2: add string-choice.[ch] to not clutter kernel.h and to actually save
> space on string constants.
>
> +EXPORT_SYMBOL(enableddisabled);
> +
> +const char *plural(long v)
> +{
> + return v == 1 ? "" : "s";
> +}
> +EXPORT_SYMBOL(plural);
>
Say what? I'll bet you a beer that this is a net loss: You're adding
hundreds of bytes of export symbol overhead, plus forcing gcc to emit
actual calls at the call sites, with all the register saving/restoring
that implies.
Please just do this as static inlines. As I said, the linker is
perfectly capable of merging string literals across translation units
(but of course not between vmlinux and modules), so any built-in code
that uses those helpers (or open-codes them, doesn't matter) will
automatically share those literals.
Rasmus
Re: [Intel-gfx] [CI] RFT drm/i915/tgl: Re-enable rps
Quoting Chris Wilson (2019-09-30 13:39:29)
> ---
> drivers/gpu/drm/i915/i915_pci.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ea53dfe2fba0..cd1fbd71dc31 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -807,7 +807,6 @@ static const struct intel_device_info
> intel_tigerlake_12_info = {
> .display.has_modular_fia = 1,
> .engine_mask =
> BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
> - .has_rps = false, /* XXX disabled for debugging */
Seems the report is a little delayed. Long story short, fi-tgl-u2 died
in gem_sync as before. Underlying cause is still unresolved, although
rps is likely a correlation rather than causal link.
-Chris
___
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/selftests: Exercise context switching in parallell (rev3)
== Series Details ==
Series: drm/i915/selftests: Exercise context switching in parallell (rev3)
URL : https://patchwork.freedesktop.org/series/67395/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b6e359fa23f7 drm/i915/selftests: Exercise context switching in parallel
-:36: WARNING:LINE_SPACING: Missing a blank line after declarations
#36: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:168:
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
-:83: WARNING:LINE_SPACING: Missing a blank line after declarations
#83: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:215:
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
-:120: WARNING:LINE_SPACING: Missing a blank line after declarations
#120: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:252:
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
-:127: WARNING:LINE_SPACING: Missing a blank line after declarations
#127: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:259:
+ struct i915_gem_engines_iter it;
+ int (* const *fn)(void *arg);
-:214: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!data[n].ce[0]"
#214: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:346:
+ if (data[n].ce[0] == NULL)
total: 0 errors, 4 warnings, 1 checks, 250 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 3/6] drm/i915/display/icl: HW state readout for transcoder port sync config
On Thu, Sep 26, 2019 at 05:11:10PM -0700, Manasi Navare wrote:
> After the state is committed, we readout the HW registers and compare
> the HW state with the SW state that we just committed.
> For Transcdoer port sync, we add master_transcoder and the
> salves bitmask to the crtc_state, hence we need to read those during
> the HW state readout to avoid pipe state mismatch.
>
> v6:
> * Go through both parts of HW readout (Maarten)
> * Add a WARN if the same trans configured as
> master and slave (Ville, Maarten)
> v5:
> * Add return INVALID in defaut case (Maarten)
> v4:
> * Get power domains in master loop for get_config (Ville)
> v3:
> * Add TRANSCODER_D (Maarten)
> * v3 Reviewed-by: Maarten Lankhorst
> v2:
> * Add Transcoder_D and MISSING_CASE (Maarten)
>
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 69
> 1 file changed, 69 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index af6b8f10f132..6e4af6ded6f0 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10510,6 +10510,72 @@ static void haswell_get_ddi_port_state(struct
> intel_crtc *crtc,
> }
> }
>
> +static enum transcoder transcoder_master(struct drm_i915_private *dev_priv,
> + enum transcoder cpu_transcoder)
> +{
> + u32 trans_port_sync, master_select;
> +
> + trans_port_sync = I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
> +
> + if ((trans_port_sync & PORT_SYNC_MODE_ENABLE) == 0)
> + return INVALID_TRANSCODER;
> +
> + master_select = trans_port_sync &
> + PORT_SYNC_MODE_MASTER_SELECT_MASK;
> + switch (master_select) {
> + case 1:
> + return TRANSCODER_A;
> + case 2:
> + return TRANSCODER_B;
> + case 3:
> + return TRANSCODER_C;
> + case 4:
> + return TRANSCODER_D;
Missing EDP. Also A-D are just master_select-1
> + default:
> + MISSING_CASE(master_select);
> + return INVALID_TRANSCODER;
> + }
> +}
> +
> +static void icelake_get_trans_port_sync_config(struct intel_crtc *crtc,
> +struct intel_crtc_state
> *pipe_config)
s/pipe_config/crtc_state/
'crtc' argument can be derived so doesn't need to be passed in.
> +{
> + struct drm_device *dev = crtc->base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + u32 transcoders;
> + enum transcoder cpu_transcoder;
> +
> + pipe_config->master_transcoder = transcoder_master(dev_priv,
> +
> pipe_config->cpu_transcoder);
> + if (pipe_config->master_transcoder != INVALID_TRANSCODER)
> + pipe_config->sync_mode_slaves_mask = 0;
Zeroing seems redundant.
> +
> + transcoders = BIT(TRANSCODER_A) |
> + BIT(TRANSCODER_B) |
> + BIT(TRANSCODER_C) |
> + BIT(TRANSCODER_D);
> + for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders) {
> + enum intel_display_power_domain power_domain;
> + intel_wakeref_t trans_wakeref;
> +
> + power_domain = POWER_DOMAIN_TRANSCODER(cpu_transcoder);
> + trans_wakeref = intel_display_power_get_if_enabled(dev_priv,
> +
> power_domain);
> +
> + if (!trans_wakeref)
> + continue;
> +
> + if (transcoder_master(dev_priv, cpu_transcoder) ==
> + pipe_config->cpu_transcoder)
> + pipe_config->sync_mode_slaves_mask |=
> BIT(cpu_transcoder);
> +
> + intel_display_power_put(dev_priv, power_domain, trans_wakeref);
> + }
> +
> + WARN_ON(pipe_config->master_transcoder != INVALID_TRANSCODER &&
> + pipe_config->sync_mode_slaves_mask);
> +}
> +
> static bool haswell_get_pipe_config(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config)
> {
> @@ -10629,6 +10695,9 @@ static bool haswell_get_pipe_config(struct intel_crtc
> *crtc,
> pipe_config->pixel_multiplier = 1;
> }
>
> + if (INTEL_GEN(dev_priv) >= 11)
> + icelake_get_trans_port_sync_config(crtc, pipe_config);
> +
> out:
> for_each_power_domain(power_domain, power_domain_mask)
> intel_display_power_put(dev_priv,
> --
> 2.19.1
--
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 v3 2/6] drm/i915/display/icl: Enable TRANSCODER PORT SYNC for tiled displays across separate ports
On Sun, Sep 22, 2019 at 10:08:03AM -0700, Manasi Navare wrote:
> In case of tiled displays where different tiles are displayed across
> different ports, we need to synchronize the transcoders involved.
> This patch implements the transcoder port sync feature for
> synchronizing one master transcoder with one or more slave
> transcoders. This is only enbaled in slave transcoder
> and the master transcoder is unaware that it is operating
> in this mode.
> This has been tested with tiled display connected to ICL.
>
> v5:
> * Add TRANSCODER_D case and MISSING_CASE (Maarten)
> v4:
> Rebase
> v3:
> * Check of DP_MST moved to atomic_check (Maarten)
> v2:
> * Do not use RMW, just write to the register in commit (Jani N)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 46
> 1 file changed, 46 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 4ff375d5852d..1ae5eafe2892 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -4426,6 +4426,49 @@ static void icl_set_pipe_chicken(struct intel_crtc
> *crtc)
> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> }
>
> +static void icl_enable_trans_port_sync(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);
> + u32 trans_ddi_func_ctl2_val;
> + u8 master_select;
> +
> + /*
> + * Configure the master select and enable Transcoder Port Sync for
> + * Slave CRTCs transcoder.
> + */
> + if (crtc_state->master_transcoder == INVALID_TRANSCODER)
> + return;
> +
> + switch (crtc_state->master_transcoder) {
> + case TRANSCODER_A:
> + master_select = 1;
> + break;
> + case TRANSCODER_B:
> + master_select = 2;
> + break;
> + case TRANSCODER_C:
> + master_select = 3;
> + break;
> + case TRANSCODER_D:
> + master_select = 4;
> + break;
That's all just master_transcoder+1.
> + case TRANSCODER_EDP:
EDP transcoder can be master. The MISSING_CASE is wrong for EDP.
> + default:
> + MISSING_CASE(crtc_state->master_transcoder);
> + master_select = 0;
> + }
> + /* Set the master select bits for Tranascoder Port Sync */
> + trans_ddi_func_ctl2_val = (PORT_SYNC_MODE_MASTER_SELECT(master_select) &
> +PORT_SYNC_MODE_MASTER_SELECT_MASK) <<
> + PORT_SYNC_MODE_MASTER_SELECT_SHIFT;
> + /* Enable Transcoder Port Sync */
> + trans_ddi_func_ctl2_val |= PORT_SYNC_MODE_ENABLE;
> +
> + I915_WRITE(TRANS_DDI_FUNC_CTL2(crtc_state->cpu_transcoder),
> +trans_ddi_func_ctl2_val);
> +}
> +
> static void intel_update_pipe_config(const struct intel_crtc_state
> *old_crtc_state,
>const struct intel_crtc_state
> *new_crtc_state)
> {
> @@ -6494,6 +6537,9 @@ static void haswell_crtc_enable(struct intel_crtc_state
> *pipe_config,
> if (!transcoder_is_dsi(cpu_transcoder))
> intel_set_pipe_timings(pipe_config);
>
> + if (INTEL_GEN(dev_priv) >= 11)
> + icl_enable_trans_port_sync(pipe_config);
> +
> intel_set_pipe_src_size(pipe_config);
>
> if (cpu_transcoder != TRANSCODER_EDP &&
> --
> 2.19.1
--
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 v3] drm/i915/selftests: Exercise context switching in parallel
Quoting Chris Wilson (2019-09-30 15:15:22)
> We currently test context switching on each engine as a basic stress
> test (just verifying that nothing explodes if we execute 2 requests from
> different contexts sequentially). What we have not tested is what
> happens if we try and do so on all available engines simultaneously,
> putting our SW and the HW under the maximal stress.
>
> v2: Clone the set of engines from the first context into the secondary
> contexts.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Tvrtko Ursulin
> ---
> +static int live_parallel_switch(void *arg)
> +{
> + struct drm_i915_private *i915 = arg;
> + static int (* const func[])(void *arg) = {
> + __live_parallel_switch1,
> + __live_parallel_switchN,
> + NULL,
> + };
> + struct i915_gem_engines *engines;
> + struct i915_gem_engines_iter it;
> + int (* const *fn)(void *arg);
> + struct parallel_switch *data;
> + struct i915_gem_context *ctx;
> + struct intel_context *ce;
> + struct drm_file *file;
> + int n, m, count;
> + int err = 0;
> +
> + /*
> +* Check we can process switches on all engines simultaneously.
> +*/
> +
> + if (!DRIVER_CAPS(i915)->has_logical_contexts)
> + return 0;
> +
> + file = mock_file(i915);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + mutex_lock(>drm.struct_mutex);
> +
> + ctx = live_context(i915, file);
> + if (IS_ERR(ctx)) {
> + err = PTR_ERR(ctx);
> + goto out_locked;
This needs data = NULL to be safe.
...
> + mutex_lock(>drm.struct_mutex);
> +out_locked:
> + for (n = 0; n < count; n++) {
> + for (m = 0; m < ARRAY_SIZE(data->ce); m++) {
> + if (!data[n].ce[m])
> + continue;
> +
> + intel_context_unpin(data[n].ce[m]);
> + intel_context_put(data[n].ce[m]);
> + }
> + }
> + mutex_unlock(>drm.struct_mutex);
> + kfree(data);
> + mock_file_free(i915, file);
> + return err;
> +}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[PATCH v2] lib/string-choice: add yesno(), onoff(), enableddisabled(), plural() helpers
The kernel has plenty of ternary operators to choose between constant
strings, such as condition ? "yes" : "no", as well as value == 1 ? "" :
"s":
$ git grep '? "yes" : "no"' | wc -l
258
$ git grep '? "on" : "off"' | wc -l
204
$ git grep '? "enabled" : "disabled"' | wc -l
196
$ git grep '? "" : "s"' | wc -l
25
Additionally, there are some occurences of the same in reverse order,
split to multiple lines, or otherwise not caught by the simple grep.
Add helpers to return the constant strings. Remove existing equivalent
and conflicting functions in i915, cxgb4, and USB core. Further
conversion can be done incrementally.
While the main goal here is to abstract recurring patterns, and slightly
clean up the code base by not open coding the ternary operators, there
are also some space savings to be had via better string constant
pooling.
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: intel-gfx@lists.freedesktop.org
Cc: Vishal Kulkarni
Cc: net...@vger.kernel.org
Cc: Greg Kroah-Hartman
Cc: linux-...@vger.kernel.org
Cc: Andrew Morton
Cc: linux-ker...@vger.kernel.org
Cc: Julia Lawall
Cc: Rasmus Villemoes
Reviewed-by: Greg Kroah-Hartman # v1
Signed-off-by: Jani Nikula
---
v2: add string-choice.[ch] to not clutter kernel.h and to actually save
space on string constants.
Example of further cleanup possibilities are at [1], to be done
incrementally afterwards.
[1] http://lore.kernel.org/r/20190903133731.2094-2-jani.nik...@intel.com
---
drivers/gpu/drm/i915/i915_utils.h | 16 +-
.../ethernet/chelsio/cxgb4/cxgb4_debugfs.c| 12 +--
drivers/usb/core/config.c | 6 +---
drivers/usb/core/generic.c| 6 +---
include/linux/kernel.h| 1 +
include/linux/string-choice.h | 16 ++
lib/Makefile | 2 +-
lib/string-choice.c | 31 +++
8 files changed, 53 insertions(+), 37 deletions(-)
create mode 100644 include/linux/string-choice.h
create mode 100644 lib/string-choice.c
diff --git a/drivers/gpu/drm/i915/i915_utils.h
b/drivers/gpu/drm/i915/i915_utils.h
index 562f756da421..794f02a90efe 100644
--- a/drivers/gpu/drm/i915/i915_utils.h
+++ b/drivers/gpu/drm/i915/i915_utils.h
@@ -28,6 +28,7 @@
#include
#include
#include
+#include
#include
#include
@@ -395,21 +396,6 @@ wait_remaining_ms_from_jiffies(unsigned long
timestamp_jiffies, int to_wait_ms)
#define MBps(x) KBps(1000 * (x))
#define GBps(x) ((u64)1000 * MBps((x)))
-static inline const char *yesno(bool v)
-{
- return v ? "yes" : "no";
-}
-
-static inline const char *onoff(bool v)
-{
- return v ? "on" : "off";
-}
-
-static inline const char *enableddisabled(bool v)
-{
- return v ? "enabled" : "disabled";
-}
-
static inline void add_taint_for_CI(unsigned int taint)
{
/*
diff --git a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
index ae6a47dd7dc9..d9123dae1d00 100644
--- a/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
+++ b/drivers/net/ethernet/chelsio/cxgb4/cxgb4_debugfs.c
@@ -35,6 +35,7 @@
#include
#include
#include
+#include
#include
#include
@@ -2023,17 +2024,6 @@ static const struct file_operations rss_debugfs_fops = {
/* RSS Configuration.
*/
-/* Small utility function to return the strings "yes" or "no" if the supplied
- * argument is non-zero.
- */
-static const char *yesno(int x)
-{
- static const char *yes = "yes";
- static const char *no = "no";
-
- return x ? yes : no;
-}
-
static int rss_config_show(struct seq_file *seq, void *v)
{
struct adapter *adapter = seq->private;
diff --git a/drivers/usb/core/config.c b/drivers/usb/core/config.c
index 151a74a54386..52cee9067eb4 100644
--- a/drivers/usb/core/config.c
+++ b/drivers/usb/core/config.c
@@ -10,6 +10,7 @@
#include
#include
#include
+#include
#include
#include "usb.h"
@@ -19,11 +20,6 @@
#define USB_MAXCONFIG 8 /* Arbitrary limit */
-static inline const char *plural(int n)
-{
- return (n == 1 ? "" : "s");
-}
-
static int find_next_descriptor(unsigned char *buffer, int size,
int dt1, int dt2, int *num_skipped)
{
diff --git a/drivers/usb/core/generic.c b/drivers/usb/core/generic.c
index 38f8b3e31762..a784a09794d6 100644
--- a/drivers/usb/core/generic.c
+++ b/drivers/usb/core/generic.c
@@ -21,14 +21,10 @@
#include
#include
+#include
#include
#include "usb.h"
-static inline const char *plural(int n)
-{
- return (n == 1 ? "" : "s");
-}
-
static int is_rndis(struct usb_interface_descriptor *desc)
{
return desc->bInterfaceClass == USB_CLASS_COMM
diff --git a/include/linux/kernel.h b/include/linux/kernel.h
index d83d403dac2e..91ace0e6ec1d 100644
--- a/include/linux/kernel.h
+++ b/include/linux/kernel.h
@@ -1029,4 +1029,5 @@ static inline void ftrace_dump(enum ftrace_dump_mode
oops_dump_mode) { }
[Intel-gfx] [PATCH v3] drm/i915/selftests: Exercise context switching in parallel
We currently test context switching on each engine as a basic stress
test (just verifying that nothing explodes if we execute 2 requests from
different contexts sequentially). What we have not tested is what
happens if we try and do so on all available engines simultaneously,
putting our SW and the HW under the maximal stress.
v2: Clone the set of engines from the first context into the secondary
contexts.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
.../drm/i915/gem/selftests/i915_gem_context.c | 238 ++
1 file changed, 238 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index dc25bcc3e372..c221ed53620f 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -156,6 +156,243 @@ static int live_nop_switch(void *arg)
return err;
}
+struct parallel_switch {
+ struct task_struct *tsk;
+ struct intel_context *ce[2];
+};
+
+static int __live_parallel_switch1(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+ int err;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ return err;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int __live_parallel_switchN(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int live_parallel_switch(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
+ __live_parallel_switch1,
+ __live_parallel_switchN,
+ NULL,
+ };
+ struct i915_gem_engines *engines;
+ struct i915_gem_engines_iter it;
+ int (* const *fn)(void *arg);
+ struct parallel_switch *data;
+ struct i915_gem_context *ctx;
+ struct intel_context *ce;
+ struct drm_file *file;
+ int n, m, count;
+ int err = 0;
+
+ /*
+* Check we can process switches on all engines simultaneously.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(>drm.struct_mutex);
+
+ ctx = live_context(i915, file);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out_locked;
+ }
+
+ engines = i915_gem_context_lock_engines(ctx);
+ count = engines->num_engines;
+
+ data = kcalloc(count, sizeof(*data), GFP_KERNEL);
+ if (!data) {
+ i915_gem_context_unlock_engines(ctx);
+ err = -ENOMEM;
+ goto
Re: [Intel-gfx] [PATCH v3 1/6] drm/i915/display/icl: Save Master transcoder in slave's crtc_state for Transcoder Port Sync
On Sun, Sep 22, 2019 at 10:08:02AM -0700, Manasi Navare wrote:
> In case of tiled displays when the two tiles are sent across two CRTCs
> over two separate DP SST connectors, we need a mechanism to synchronize
> the two CRTCs and their corresponding transcoders.
> So use the master-slave mode where there is one master corresponding
> to last horizontal and vertical tile that needs to be genlocked with
> all other slave tiles.
> This patch identifies saves the master transcoder in all the slave
> CRTC states. This is needed to select the master CRTC/transcoder
> while configuring transcoder port sync for the corresponding slaves.
>
> v4:
> * Rebase
> v3:
> * Use master_tramscoder instead of master_crtc for valid
> HW state readouts (Ville)
> v2:
> * Move this to intel_mode_set_pipe_config(Jani N, Ville)
> * Use slave_bitmask to save associated slaves in master crtc state (Ville)
>
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
> Cc: Maarten Lankhorst
> Cc: Matt Roper
> Signed-off-by: Manasi Navare
> Reviewed-by: Maarten Lankhorst
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 123 ++
> drivers/gpu/drm/i915/display/intel_display.h | 3 +
> .../drm/i915/display/intel_display_types.h| 6 +
> 3 files changed, 132 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c05ba6af6226..4ff375d5852d 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -521,6 +521,24 @@ needs_modeset(const struct intel_crtc_state *state)
> return drm_atomic_crtc_needs_modeset(>base);
> }
>
> +bool
> +is_trans_port_sync_mode(struct drm_i915_private *dev_priv,
Redundant function parameter. Can be derived if needed.
> + const struct intel_crtc_state *state)
'crtc_state'
> +{
> + return (INTEL_GEN(dev_priv) >= 11 &&
I don't think we need a gen check at all. The state should not have
master/slaves set if the feature is not supported.
> + (state->master_transcoder != INVALID_TRANSCODER ||
> + state->sync_mode_slaves_mask));
> +}
> +
> +static bool
> +is_trans_port_sync_master(struct drm_i915_private *dev_priv,
> + const struct intel_crtc_state *state)
> +{
> + return (INTEL_GEN(dev_priv) >= 11 &&
> + (state->master_transcoder == INVALID_TRANSCODER &&
> + state->sync_mode_slaves_mask));
> +}
> +
> /*
> * Platform specific helpers to calculate the port PLL loopback- (clock.m),
> * and post-divider (clock.p) values, pre- (clock.vco) and post-divided fast
> @@ -11773,6 +11791,91 @@ static bool c8_planes_changed(const struct
> intel_crtc_state *new_crtc_state)
> return !old_crtc_state->c8_planes != !new_crtc_state->c8_planes;
> }
>
> +static int icl_add_sync_mode_crtcs(struct drm_crtc *crtc,
intel_ types all over please.
Also don't need all three funciton arguments. Either just
crtc_state or state+crtc will do.
> +struct intel_crtc_state *crtc_state,
> +struct drm_atomic_state *state)
> +{
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> + struct drm_connector *master_connector, *connector;
> + struct drm_connector_state *connector_state;
> + struct drm_connector_list_iter conn_iter;
> + struct drm_crtc *master_crtc = NULL;
> + struct drm_crtc_state *master_crtc_state;
> + struct intel_crtc_state *master_pipe_config;
> + int i, tile_group_id;
> +
> + if (INTEL_GEN(dev_priv) < 11)
> + return 0;
> +
> + /*
> + * In case of tiled displays there could be one or more slaves but
> there is
> + * only one master. Lets make the CRTC used by the connector
> corresponding
> + * to the last horizonal and last vertical tile a master/genlock CRTC.
> + * All the other CRTCs corresponding to other tiles of the same Tile
> group
> + * are the slave CRTCs and hold a pointer to their genlock CRTC.
> + */
> + for_each_new_connector_in_state(state, connector, connector_state, i) {
> + if (connector_state->crtc != crtc)
> + continue;
> + if (!connector->has_tile)
> + continue;
> + if (crtc_state->base.mode.hdisplay != connector->tile_h_size ||
> + crtc_state->base.mode.vdisplay != connector->tile_v_size)
> + return 0;
> + if (connector->tile_h_loc == connector->num_h_tile - 1 &&
> + connector->tile_v_loc == connector->num_v_tile - 1)
> + continue;
> + crtc_state->sync_mode_slaves_mask = 0;
> + tile_group_id = connector->tile_group->id;
> + drm_connector_list_iter_begin(_priv->drm, _iter);
> + drm_for_each_connector_iter(master_connector, _iter) {
> +
Re: [Intel-gfx] [PATCH 11/23] drm/i915: Try to make bigjoiner work in atomic check.
Op 26-09-2019 om 05:48 schreef Matt Roper:
> On Fri, Sep 20, 2019 at 01:42:23PM +0200, Maarten Lankhorst wrote:
>> When the clock is higher than the dotclock, try with 2 pipes enabled.
>> If we can enable 2, then we will go into big joiner mode, and steal
>> the adjacent crtc.
>>
>> This only links the crtc's in software, no hardware or plane
>> programming is done yet. Blobs are also copied from the master's
>> crtc_state, so it doesn't depend at commit time on the other
>> crtc_state.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/display/intel_atomic.c | 15 +-
>> drivers/gpu/drm/i915/display/intel_atomic.h | 3 +-
>> drivers/gpu/drm/i915/display/intel_display.c | 197 +-
>> .../drm/i915/display/intel_display_types.h| 11 +-
>> drivers/gpu/drm/i915/display/intel_dp.c | 25 ++-
>> 5 files changed, 228 insertions(+), 23 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.c
>> b/drivers/gpu/drm/i915/display/intel_atomic.c
>> index c50e0b218bd6..0db04064c86e 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic.c
>> @@ -228,25 +228,26 @@ 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)
>> +void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
>> + const struct intel_crtc_state *from_crtc_state)
>> {
>> intel_crtc_put_color_blobs(crtc_state);
>>
>> -if (crtc_state->uapi.degamma_lut)
>> +if (from_crtc_state->uapi.degamma_lut)
>> crtc_state->hw.degamma_lut =
>> -drm_property_blob_get(crtc_state->uapi.degamma_lut);
>> +
>> drm_property_blob_get(from_crtc_state->uapi.degamma_lut);
>> else
>> crtc_state->hw.degamma_lut = NULL;
>>
>> -if (crtc_state->uapi.gamma_lut)
>> +if (from_crtc_state->uapi.gamma_lut)
>> crtc_state->hw.gamma_lut =
>> -drm_property_blob_get(crtc_state->uapi.gamma_lut);
>> +drm_property_blob_get(from_crtc_state->uapi.gamma_lut);
>> else
>> crtc_state->hw.gamma_lut = NULL;
>>
>> -if (crtc_state->uapi.ctm)
>> +if (from_crtc_state->uapi.ctm)
>> crtc_state->hw.ctm =
>> -drm_property_blob_get(crtc_state->uapi.ctm);
>> +drm_property_blob_get(from_crtc_state->uapi.ctm);
>> else
>> crtc_state->hw.ctm = NULL;
>> }
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic.h
>> b/drivers/gpu/drm/i915/display/intel_atomic.h
>> index 42be91e0772a..8da84d64aa04 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic.h
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic.h
>> @@ -36,7 +36,8 @@ 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);
>> +void intel_crtc_copy_color_blobs(struct intel_crtc_state *crtc_state,
>> + const struct intel_crtc_state
>> *from_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 ba52a70840fd..143d531c4c81 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -7434,7 +7434,7 @@ static int intel_crtc_compute_config(struct intel_crtc
>> *crtc,
>> struct intel_crtc_state *pipe_config)
>> {
>> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> -const struct drm_display_mode *adjusted_mode =
>> _config->hw.adjusted_mode;
>> +struct drm_display_mode *adjusted_mode = _config->hw.adjusted_mode;
>> int clock_limit = dev_priv->max_dotclk_freq;
>>
>> if (INTEL_GEN(dev_priv) < 4) {
>> @@ -7451,6 +7451,25 @@ static int intel_crtc_compute_config(struct
>> intel_crtc *crtc,
>> }
>> }
>>
>> +/*
>> + * copy hw mode to transcoder mode.
>> + * This matters mostly for big joiner, which splits the mode in half.
>> + */
>> +pipe_config->hw.transcoder_mode = pipe_config->hw.adjusted_mode;
>> +if (pipe_config->bigjoiner) {
>> +/* Make sure the crtc config is halved horizontally */
>> +adjusted_mode->crtc_clock /= 2;
>> +adjusted_mode->crtc_hdisplay /= 2;
>> +adjusted_mode->crtc_hblank_start /= 2;
>> +adjusted_mode->crtc_hblank_end /=
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise context switching in parallel
Quoting Tvrtko Ursulin (2019-09-30 14:47:26)
>
> On 30/09/2019 12:31, Chris Wilson wrote:
> > +static int live_parallel_switch(void *arg)
> > +{
> > + struct drm_i915_private *i915 = arg;
> > + static int (* const func[])(void *arg) = {
> > + __live_parallel_switch1,
> > + __live_parallel_switchN,
> > + NULL,
> > + };
> > + struct i915_gem_context *ctx[2];
> > + struct parallel_switch *data;
> > + int (* const *fn)(void *arg);
> > + struct drm_file *file;
> > + int err = 0;
> > + int n;
> > +
> > + /*
> > + * Check we can process switches on all engines simultaneously.
> > + */
> > +
> > + if (!DRIVER_CAPS(i915)->has_logical_contexts)
> > + return 0;
> > +
> > + file = mock_file(i915);
> > + if (IS_ERR(file))
> > + return PTR_ERR(file);
> > +
> > + data = kcalloc(I915_NUM_ENGINES, sizeof(*data), GFP_KERNEL);
>
> There is a little bit of mixing up I915_NUM_ENGINES and gem engines
> (which contains the num_engines field) in this function.
>
> I think it would be better to limit to one - so maybe get the count from
> gem engines? It can't change during selftest so don't have to have them
> locked for the whole time.
>
> > + if (!data)
>
> mock_file_free
>
> > + return -ENOMEM;
> > +
> > + for (n = 0; n < ARRAY_SIZE(ctx); n++) {
> > + struct i915_gem_engines_iter it;
> > + struct intel_context *ce;
> > +
> > + mutex_lock(>drm.struct_mutex);
> > + ctx[n] = live_context(i915, file);
> > + if (IS_ERR(ctx[n])) {
> > + err = PTR_ERR(ctx[n]);
> > + goto out_locked;
> > + }
> > +
> > + for_each_gem_engine(ce,
> > + i915_gem_context_lock_engines(ctx[n]),
> > it) {
> > + err = intel_context_pin(ce);
> > + if (err) {
> > + i915_gem_context_unlock_engines(ctx[n]);
> > + goto out_locked;
> > + }
> > + data[ce->engine->legacy_idx].ce[n] = ce;
>
> IMHO a bit confusing to use legacy_idx - makes it sound like there is
> some significance to the legacy part so why not just use engine->id?
Default engine list with legacy_idx is nice and linear, with a cap of
I915_NUM_ENGINES.
Ok, I have a weirder plan...
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise context switching in parallel
On 30/09/2019 12:31, Chris Wilson wrote:
We currently test context switching on each engine as a basic stress
test (just verifying that nothing explodes if we execute 2 requests from
different contexts sequentially). What we have not tested is what
happens if we try and do so on all available engines simultaneously,
putting our SW and the HW under the maximal stress.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Keep struct_mutex the outer lock while it still exists
---
.../drm/i915/gem/selftests/i915_gem_context.c | 203 ++
1 file changed, 203 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index dc25bcc3e372..8325c7329dc7 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -156,6 +156,208 @@ static int live_nop_switch(void *arg)
return err;
}
+struct parallel_switch {
+ struct task_struct *tsk;
+ struct intel_context *ce[2];
+};
+
+static int __live_parallel_switch1(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+ int err;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
unlock-lock! :) I guess in anticipation of removing it all.
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ return err;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int __live_parallel_switchN(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int live_parallel_switch(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
+ __live_parallel_switch1,
+ __live_parallel_switchN,
+ NULL,
+ };
+ struct i915_gem_context *ctx[2];
+ struct parallel_switch *data;
+ int (* const *fn)(void *arg);
+ struct drm_file *file;
+ int err = 0;
+ int n;
+
+ /*
+* Check we can process switches on all engines simultaneously.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ data = kcalloc(I915_NUM_ENGINES, sizeof(*data), GFP_KERNEL);
There is a little bit of mixing up I915_NUM_ENGINES and gem engines
(which contains the num_engines field) in this function.
I think it would be better to limit to one - so maybe get the count from
gem engines? It can't change during selftest so don't have to have them
locked for the whole time.
+ if (!data)
mock_file_free
+ return -ENOMEM;
+
+ for (n = 0; n < ARRAY_SIZE(ctx); n++) {
+ struct
[Intel-gfx] [PATCH 2/4] drm/rect: Add drm_rect_init()
From: Ville Syrjälä
Add a helper to initialize a rectangle from x/y/w/h information.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 17 +
1 file changed, 17 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index fc7c14627ee2..cd0106135b6a 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -69,6 +69,23 @@ struct drm_rect {
(r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
(r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
+/**
+ * drm_rect_init - initialize the rectangle from x/y/w/h
+ * @r: rectangle
+ * @x: x coordinate
+ * @y: y coordinate
+ * @width: width
+ * @height: height
+ */
+static inline void drm_rect_init(struct drm_rect *r, int x, int y,
+int width, int height)
+{
+ r->x1 = x;
+ r->y1 = y;
+ r->x2 = x + width;
+ r->y2 = y + height;
+}
+
/**
* drm_rect_adjust_size - adjust the size of the rectangle
* @r: rectangle to be adjusted
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] drm/i915: Use drm_rect_init()
From: Ville Syrjälä Use the new drm_rect_init() helper where appropriate. Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/display/intel_display.c | 10 ++ drivers/gpu/drm/i915/display/intel_sprite.c | 6 ++ 2 files changed, 4 insertions(+), 12 deletions(-) diff --git a/drivers/gpu/drm/i915/display/intel_display.c b/drivers/gpu/drm/i915/display/intel_display.c index 7e031b76694a..3ddd8a940bfa 100644 --- a/drivers/gpu/drm/i915/display/intel_display.c +++ b/drivers/gpu/drm/i915/display/intel_display.c @@ -2738,10 +2738,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv, size++; /* rotate the x/y offsets to match the GTT view */ - r.x1 = x; - r.y1 = y; - r.x2 = x + width; - r.y2 = y + height; + drm_rect_init(, x, y, width, height); drm_rect_rotate(, rot_info->plane[i].width * tile_width, rot_info->plane[i].height * tile_height, @@ -2863,10 +2860,7 @@ intel_plane_remap_gtt(struct intel_plane_state *plane_state) struct drm_rect r; /* rotate the x/y offsets to match the GTT view */ - r.x1 = x; - r.y1 = y; - r.x2 = x + width; - r.y2 = y + height; + drm_rect_init(, x, y, width, height); drm_rect_rotate(, info->plane[i].width * tile_width, info->plane[i].height * tile_height, diff --git a/drivers/gpu/drm/i915/display/intel_sprite.c b/drivers/gpu/drm/i915/display/intel_sprite.c index 3d56db32291b..8d5854d54045 100644 --- a/drivers/gpu/drm/i915/display/intel_sprite.c +++ b/drivers/gpu/drm/i915/display/intel_sprite.c @@ -287,10 +287,8 @@ int intel_plane_check_src_coordinates(struct intel_plane_state *plane_state) src_y = src->y1 >> 16; src_h = drm_rect_height(src) >> 16; - src->x1 = src_x << 16; - src->x2 = (src_x + src_w) << 16; - src->y1 = src_y << 16; - src->y2 = (src_y + src_h) << 16; + drm_rect_init(src, src_x << 16, src_y << 16, + src_w << 16, src_h << 16); if (!fb->format->is_yuv) return 0; -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/i915: Use drm_rect_translate_to()
From: Ville Syrjälä
Use the newly introduced drm_rect_translate_to() instead
of hand rolling it.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_display.c | 10 --
1 file changed, 4 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index f1328c08f4ad..7e031b76694a 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -3485,9 +3485,8 @@ static int skl_check_main_surface(struct
intel_plane_state *plane_state)
* Put the final coordinates back so that the src
* coordinate checks will see the right values.
*/
- drm_rect_translate(_state->base.src,
- (x << 16) - plane_state->base.src.x1,
- (y << 16) - plane_state->base.src.y1);
+ drm_rect_translate_to(_state->base.src,
+ x << 16, y << 16);
return 0;
}
@@ -3709,9 +3708,8 @@ int i9xx_check_plane_surface(struct intel_plane_state
*plane_state)
* Put the final coordinates back so that the src
* coordinate checks will see the right values.
*/
- drm_rect_translate(_state->base.src,
- (src_x << 16) - plane_state->base.src.x1,
- (src_y << 16) - plane_state->base.src.y1);
+ drm_rect_translate_to(_state->base.src,
+ src_x << 16, src_y << 16);
/* HSW/BDW do this automagically in hardware */
if (!IS_HASWELL(dev_priv) && !IS_BROADWELL(dev_priv)) {
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/rect: Add drm_rect_translate_to()
From: Ville Syrjälä
Add a helper to translate a rectangle to an absolute position.
Signed-off-by: Ville Syrjälä
---
include/drm/drm_rect.h | 14 ++
1 file changed, 14 insertions(+)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 6195820aa5c5..fc7c14627ee2 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -106,6 +106,20 @@ static inline void drm_rect_translate(struct drm_rect *r,
int dx, int dy)
r->y2 += dy;
}
+/**
+ * drm_rect_translate_to - translate the rectangle to an absolute position
+ * @r: rectangle to be tranlated
+ * @x: horizontal position
+ * @y: vertical position
+ *
+ * Move rectangle @r to @x in the horizontal direction,
+ * and to @y in the vertical direction.
+ */
+static inline void drm_rect_translate_to(struct drm_rect *r, int x, int y)
+{
+ drm_rect_translate(r, x - r->x1, y - r->y1);
+}
+
/**
* drm_rect_downscale - downscale a rectangle
* @r: rectangle to be downscaled
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] i915/gem_mmap_gtt: Reduce RSS for fault-concurrent
The intent of exercising parallel page fault is not necessarily to
exercise parallel swap-in (we can safely rely on that being well tested
and is orthogonal to page faulting), but to make sure that our object
and GGTT locking is exercised. We can safely reduce our RSS without loss
of coverage. Furthermore, by using varying sizes we can exercise
different code paths within page faulting, rather than all being
serviced as partial mmaps. Instead of allocating 32 surfaces, each of
16MiB, we allocate 32 surfaces in incremental 512KiB sizes; halving the
memory requirement.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111864
Signed-off-by: Chris Wilson
---
tests/i915/gem_mmap_gtt.c | 40 +++
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index 91da5a37b..6ebbdd8c7 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -57,30 +57,36 @@ set_domain_gtt(int fd, uint32_t handle)
}
static void *
-mmap_bo(int fd, uint32_t handle)
+mmap_bo(int fd, uint32_t handle, uint64_t size)
{
void *ptr;
- ptr = gem_mmap__gtt(fd, handle, OBJECT_SIZE, PROT_READ | PROT_WRITE);
+ ptr = gem_mmap__gtt(fd, handle, size, PROT_READ | PROT_WRITE);
return ptr;
}
static void *
-create_pointer(int fd)
+create_pointer_size(int fd, uint64_t size)
{
uint32_t handle;
void *ptr;
- handle = gem_create(fd, OBJECT_SIZE);
+ handle = gem_create(fd, size);
- ptr = mmap_bo(fd, handle);
+ ptr = mmap_bo(fd, handle, size);
gem_close(fd, handle);
return ptr;
}
+static void *
+create_pointer(int fd)
+{
+ return create_pointer_size(fd, OBJECT_SIZE);
+}
+
static void
test_access(int fd)
{
@@ -468,7 +474,7 @@ test_write_gtt(int fd)
dst = gem_create(fd, OBJECT_SIZE);
/* prefault object into gtt */
- dst_gtt = mmap_bo(fd, dst);
+ dst_gtt = mmap_bo(fd, dst, OBJECT_SIZE);
set_domain_gtt(fd, dst);
memset(dst_gtt, 0, OBJECT_SIZE);
munmap(dst_gtt, OBJECT_SIZE);
@@ -958,10 +964,16 @@ thread_fault_concurrent(void *closure)
int n;
for (n = 0; n < 32; n++) {
+ unsigned int id = (n + t->id) % 32;
+ uint32_t sz = *t->ptr[id] - 1;
+ int idx = rand() % sz + 1;
+
if (n & 1)
- *t->ptr[(n + t->id) % 32] = val;
+ t->ptr[id][idx] = val;
else
- val = *t->ptr[(n + t->id) % 32];
+ val = t->ptr[id][idx];
+
+ val++;
}
return NULL;
@@ -975,7 +987,10 @@ test_fault_concurrent(int fd)
int n;
for (n = 0; n < 32; n++) {
- ptr[n] = create_pointer(fd);
+ uint32_t sz = (n + 1) << 19; /* 512KiB increments */
+
+ ptr[n] = create_pointer_size(fd, sz);
+ *ptr[n] = sz / sizeof(uint32_t); /* num_elems for convenience */
}
for (n = 0; n < 64; n++) {
@@ -984,12 +999,13 @@ test_fault_concurrent(int fd)
pthread_create([n].thread, NULL,
thread_fault_concurrent, [n]);
}
+ sleep(2);
+
for (n = 0; n < 64; n++)
pthread_join(thread[n].thread, NULL);
- for (n = 0; n < 32; n++) {
- munmap(ptr[n], OBJECT_SIZE);
- }
+ for (n = 0; n < 32; n++)
+ munmap(ptr[n], *ptr[n] * sizeof(uint32_t));
}
static void
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for RFT drm/i915/tgl: Re-enable rps
== Series Details ==
Series: RFT drm/i915/tgl: Re-enable rps
URL : https://patchwork.freedesktop.org/series/67398/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14583
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/index.html
Known issues
Here are the changes found in Patchwork_14583 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111045] / [fdo#111096])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/fi-icl-u3/igt@gem_m...@basic-small-bo.html
* igt@i915_selftest@live_gem_contexts:
- fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/fi-bxt-dsi/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (53 -> 46)
--
Additional (1): fi-cml-h
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6973 -> Patchwork_14583
CI-20190529: 20190529
CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14583: ac469e3ebe6fc2fa1401371766402dd532eb19dc @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ac469e3ebe6f RFT drm/i915/tgl: Re-enable rps
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14583/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for RFT drm/i915/tgl: Re-enable rps
== Series Details == Series: RFT drm/i915/tgl: Re-enable rps URL : https://patchwork.freedesktop.org/series/67398/ State : warning == Summary == $ dim checkpatch origin/drm-tip ac469e3ebe6f RFT drm/i915/tgl: Re-enable rps -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:18: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 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
[Intel-gfx] [CI] RFT drm/i915/tgl: Re-enable rps
---
drivers/gpu/drm/i915/i915_pci.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index ea53dfe2fba0..cd1fbd71dc31 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -807,7 +807,6 @@ static const struct intel_device_info
intel_tigerlake_12_info = {
.display.has_modular_fia = 1,
.engine_mask =
BIT(RCS0) | BIT(BCS0) | BIT(VECS0) | BIT(VCS0) | BIT(VCS2),
- .has_rps = false, /* XXX disabled for debugging */
};
#undef GEN
--
2.23.0
___
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/selftests: Exercise context switching in parallell (rev2)
== Series Details ==
Series: drm/i915/selftests: Exercise context switching in parallell (rev2)
URL : https://patchwork.freedesktop.org/series/67395/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14582
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/index.html
Known issues
Here are the changes found in Patchwork_14582 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
* igt@i915_selftest@live_hangcheck:
- fi-bsw-n3050: [PASS][3] -> [INCOMPLETE][4] ([fdo#105876])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/fi-bsw-n3050/igt@i915_selftest@live_hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][5] -> [FAIL][6] ([fdo#111407])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
* igt@kms_pipe_crc_basic@hang-read-crc-pipe-a:
- fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/fi-icl-u3/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html
Possible fixes
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] +1
similar issue
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/fi-icl-u3/igt@gem_m...@basic-small-bo.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105876]: https://bugs.freedesktop.org/show_bug.cgi?id=105876
[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#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111867]: https://bugs.freedesktop.org/show_bug.cgi?id=111867
Participating hosts (53 -> 45)
--
Additional (1): fi-cml-h
Missing(9): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-skl-6770hq
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6973 -> Patchwork_14582
CI-20190529: 20190529
CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14582: b214c64b2862a064deb1795b395fff8aa95557a9 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
b214c64b2862 drm/i915/selftests: Exercise context switching in parallel
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14582/index.html
___
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/tgl: Magic udelay to relieve the random lockups with multiple engines (rev2)
== Series Details == Series: drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines (rev2) URL : https://patchwork.freedesktop.org/series/67365/ State : success == Summary == CI Bug Log - changes from CI_DRM_6973_full -> Patchwork_14581_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14581_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-snb: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-snb5/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-snb5/igt@gem_...@unwedge-stress.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb1/igt@gem_exec_sched...@independent-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-iclb7/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl6/igt@gem_workarou...@suspend-resume-context.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-apl7/igt@gem_workarou...@suspend-resume-context.html * igt@i915_pm_rpm@modeset-stress-extra-wait: - shard-glk: [PASS][7] -> [DMESG-WARN][8] ([fdo#105763] / [fdo#106538]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-glk4/igt@i915_pm_...@modeset-stress-extra-wait.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-glk8/igt@i915_pm_...@modeset-stress-extra-wait.html * igt@kms_busy@extended-modeset-hang-oldfb-render-a: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb8/igt@kms_b...@extended-modeset-hang-oldfb-render-a.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-iclb7/igt@kms_b...@extended-modeset-hang-oldfb-render-a.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-hsw6/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-hsw1/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-atomic.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +6 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-indfb-draw-pwrite.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_psr@psr2_cursor_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-iclb2/igt@kms_psr@psr2_cursor_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-iclb6/igt@kms_psr@psr2_cursor_render.html * igt@kms_setmode@basic: - shard-apl: [PASS][19] -> [FAIL][20] ([fdo#99912]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-apl1/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-apl5/igt@kms_setm...@basic.html - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl2/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-skl7/igt@kms_setm...@basic.html * igt@perf@polling: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#110728]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/shard-skl3/igt@p...@polling.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/shard-skl7/igt@p...@polling.html Possible fixes * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [SKIP][25] ([fdo#111325]) -> [PASS][26] +6 similar issues [25]:
Re: [Intel-gfx] [PATCH v2] drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
Quoting Mika Kuoppala (2019-09-30 13:02:49)
> Chris Wilson writes:
>
> > My current theory is that this masks interrupt delivery to the local CPU
> > during a critical phase. Purely papering over the symptoms with a delay
> > plucked out of thin air from testing on tgl1-gem, refined slightly by
> > just waiting for the next ack (though technically the next CS event may
> > not be the corresponding event for this submit, but an intermediate
> > completion).
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Andi Shyti
> > ---
> > drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> > 1 file changed, 9 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > index ab725a6ca0ac..35410d647b52 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> > @@ -1155,6 +1155,7 @@ assert_pending_valid(const struct
> > intel_engine_execlists *execlists,
> > static void execlists_submit_ports(struct intel_engine_cs *engine)
> > {
> > struct intel_engine_execlists *execlists = >execlists;
> > + unsigned int tail = READ_ONCE(*execlists->csb_write);
> > unsigned int n;
> >
> > GEM_BUG_ON(!assert_pending_valid(execlists, "submit"));
> > @@ -1186,6 +1187,14 @@ static void execlists_submit_ports(struct
> > intel_engine_cs *engine)
> > /* we need to manually load the submit queue */
> > if (execlists->ctrl_reg)
> > writel(EL_CTRL_LOAD, execlists->ctrl_reg);
> > +
>
> I don't doubt we forget this but a comment would still be
> good that we limit the intr generation for reasons still
> unknown.
>
> > + if (IS_TIGERLAKE(engine->i915)) {
> > + u64 start = local_clock();
> > + do
> > + cpu_relax();
> > + while (tail == READ_ONCE(*execlists->csb_write) &&
> > +(local_clock() - start) >> 20 == 0);
>
> 1ms..well, if it works :O
>
> Need to track this closely and pls consider limiting this to current revid
> just so that we would notice the diff immediately when we get updates.
>
> Acked-by: Mika Kuoppala
Yeah, this one I'm not so keen to put in drm-intel-next-queued itself.
It's clear that we are not pruning features to achieve a stable base,
but now into the hax territory.
If possible, we'll get a topic/tgl-snafu branch where we can soak test
such hax on CI. But failing that, I'll try soaking it in core-for-CI --
once that is rebased on to v5.4-rc1.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
Chris Wilson writes:
> My current theory is that this masks interrupt delivery to the local CPU
> during a critical phase. Purely papering over the symptoms with a delay
> plucked out of thin air from testing on tgl1-gem, refined slightly by
> just waiting for the next ack (though technically the next CS event may
> not be the corresponding event for this submit, but an intermediate
> completion).
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Andi Shyti
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
> 1 file changed, 9 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers/gpu/drm/i915/gt/intel_lrc.c
> index ab725a6ca0ac..35410d647b52 100644
> --- a/drivers/gpu/drm/i915/gt/intel_lrc.c
> +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
> @@ -1155,6 +1155,7 @@ assert_pending_valid(const struct
> intel_engine_execlists *execlists,
> static void execlists_submit_ports(struct intel_engine_cs *engine)
> {
> struct intel_engine_execlists *execlists = >execlists;
> + unsigned int tail = READ_ONCE(*execlists->csb_write);
> unsigned int n;
>
> GEM_BUG_ON(!assert_pending_valid(execlists, "submit"));
> @@ -1186,6 +1187,14 @@ static void execlists_submit_ports(struct
> intel_engine_cs *engine)
> /* we need to manually load the submit queue */
> if (execlists->ctrl_reg)
> writel(EL_CTRL_LOAD, execlists->ctrl_reg);
> +
I don't doubt we forget this but a comment would still be
good that we limit the intr generation for reasons still
unknown.
> + if (IS_TIGERLAKE(engine->i915)) {
> + u64 start = local_clock();
> + do
> + cpu_relax();
> + while (tail == READ_ONCE(*execlists->csb_write) &&
> +(local_clock() - start) >> 20 == 0);
1ms..well, if it works :O
Need to track this closely and pls consider limiting this to current revid
just so that we would notice the diff immediately when we get updates.
Acked-by: Mika Kuoppala
> + }
> }
>
> static bool ctx_single_port_submission(const struct intel_context *ce)
> --
> 2.23.0
___
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/selftests: Exercise context switching in parallell (rev2)
== Series Details ==
Series: drm/i915/selftests: Exercise context switching in parallell (rev2)
URL : https://patchwork.freedesktop.org/series/67395/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b214c64b2862 drm/i915/selftests: Exercise context switching in parallel
-:32: WARNING:LINE_SPACING: Missing a blank line after declarations
#32: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:168:
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
-:79: WARNING:LINE_SPACING: Missing a blank line after declarations
#79: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:215:
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
-:116: WARNING:LINE_SPACING: Missing a blank line after declarations
#116: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:252:
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
-:123: WARNING:LINE_SPACING: Missing a blank line after declarations
#123: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:259:
+ struct parallel_switch *data;
+ int (* const *fn)(void *arg);
-:178: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!data[n].ce[0]"
#178: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:314:
+ if (data[n].ce[0] == NULL || data[n].ce[1] == NULL)
-:178: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written
"!data[n].ce[1]"
#178: FILE: drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c:314:
+ if (data[n].ce[0] == NULL || data[n].ce[1] == NULL)
total: 0 errors, 4 warnings, 2 checks, 215 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v9 7/7] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
On Fri, Sep 27, 2019 at 10:27:44PM +0530, Anshuman Gupta wrote:
> On 2019-09-27 at 19:38:49 +0300, Imre Deak wrote:
> > On Thu, Sep 26, 2019 at 08:26:21PM +0530, Anshuman Gupta wrote:
> > > Adding DC3CO counter in i915_dmc_info debugfs will be
> > > useful for DC3CO validation.
> > > DMC firmware uses DMC_DEBUG3 register as DC3CO counter
> > > register on TGL, as per B.Specs DMC_DEBUG3 is general
> > > purpose register.
> > >
> > > Cc: Jani Nikula
> > > Cc: Imre Deak
> > > Cc: Animesh Manna
> > > Signed-off-by: Anshuman Gupta
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
> > > drivers/gpu/drm/i915/i915_reg.h | 2 ++
> > > 2 files changed, 8 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index b5b449a88cf1..8a16bbd31212 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2407,6 +2407,12 @@ static int i915_dmc_info(struct seq_file *m, void
> > > *unused)
> > > seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
> > > CSR_VERSION_MINOR(csr->version));
> > >
> > > + /*
> > > + * TGL DMC f/w uses DMC_DEBUG3 register for DC3CO counter.
> > > + */
> >
> > The above is obvious from the code itself, so we don't need a comment
> > for it. Please also consider removing all other comments in the patchset
> > that state only what is obvious from the code.
> DMC_DEBUG3 is a DMC general purpose register, B.Specs doesn't specify
> it as DC3CO counter unlike DC5 and DC6, that is why i have added
> this comment. Shall i remove this comment considering DMC_DEBUG3
> as general purpose register?
Imo that's an issue in bspec, can you file a ticket there? The comment
could explain what the problem is, the above is already obvious from the
code. Something like:
"NOTE: DMC_DEBUG3 is a general purpose reg, its specification is yet to
be finalized in Bspec for the DC3co counter use."
> >
> > > + if (IS_TIGERLAKE(dev_priv))
> >
> > The above should match the check in get_allowed_dc_mask().
> IS_TIGERLAKE is being checked for the same reason as TGL
> DMC is using DMC_DEBUG3 for DC3CO counter. It may not be true
> for other Gen12 platfrom.
Should we enable then DC3co, if we won't be able to debug it?
In any case DMC_DEBUG3 exists for all GEN12 platforms, so I think we can
safely read it.
> Thanks,
> Anshuman Gupta.
> >
> > > + seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
> > > +
> > > if (INTEL_GEN(dev_priv) >= 12) {
> > > dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
> > > dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h
> > > index 3ee9720af207..af810f6ed652 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7263,6 +7263,8 @@ enum {
> > > #define TGL_DMC_DEBUG_DC5_COUNT _MMIO(0x101084)
> > > #define TGL_DMC_DEBUG_DC6_COUNT _MMIO(0x101088)
> > >
> > > +#define DMC_DEBUG3 _MMIO(0x101090)
> > > +
> > > /* interrupts */
> > > #define DE_MASTER_IRQ_CONTROL (1 << 31)
> > > #define DE_SPRITEB_FLIP_DONE(1 << 29)
> > > --
> > > 2.21.0
> > >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise context switching in parallel
We currently test context switching on each engine as a basic stress
test (just verifying that nothing explodes if we execute 2 requests from
different contexts sequentially). What we have not tested is what
happens if we try and do so on all available engines simultaneously,
putting our SW and the HW under the maximal stress.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
Keep struct_mutex the outer lock while it still exists
---
.../drm/i915/gem/selftests/i915_gem_context.c | 203 ++
1 file changed, 203 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index dc25bcc3e372..8325c7329dc7 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -156,6 +156,208 @@ static int live_nop_switch(void *arg)
return err;
}
+struct parallel_switch {
+ struct task_struct *tsk;
+ struct intel_context *ce[2];
+};
+
+static int __live_parallel_switch1(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+ int err;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ return err;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int __live_parallel_switchN(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int live_parallel_switch(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
+ __live_parallel_switch1,
+ __live_parallel_switchN,
+ NULL,
+ };
+ struct i915_gem_context *ctx[2];
+ struct parallel_switch *data;
+ int (* const *fn)(void *arg);
+ struct drm_file *file;
+ int err = 0;
+ int n;
+
+ /*
+* Check we can process switches on all engines simultaneously.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ data = kcalloc(I915_NUM_ENGINES, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ for (n = 0; n < ARRAY_SIZE(ctx); n++) {
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ mutex_lock(>drm.struct_mutex);
+ ctx[n] = live_context(i915, file);
+ if (IS_ERR(ctx[n])) {
+ err = PTR_ERR(ctx[n]);
+ goto out_locked;
+ }
+
+ for_each_gem_engine(ce,
+ i915_gem_context_lock_engines(ctx[n]), it) {
+
Re: [Intel-gfx] [PATCH v2] drm/i915/userptr: Never allow userptr into the mappable GGTT
Quoting Tvrtko Ursulin (2019-09-30 11:33:22) > > On 28/09/2019 09:25, Chris Wilson wrote: > > Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to > > invalidate userptr objects which also happen to be pulled into GGTT > > mmaps. That is when we unbind the userptr object (on mmu invalidation), > > we revoke all CPU mmaps, which may then recurse into mmu invalidation. > > On the same object? Invalidate on userptr built from some mmap_gtt area, > or standard userptr object mmapped via gtt? Or one userptr object built > from a mmap_gtt of another userptr object? Yup, think of the multiple partial mmaps we have on the same object. If we invalidate the mmap_offset, we may hit the same object again in mmu-invalidate. As far as my understanding goes, there is nothing in the munmap/invalidate that prevents this. Although, having the same pages mapped into different process is not unusual, so you would think we are not alone in having device pages in multiple mappings? There might be something more at play here, but Daniel's lockdep patch is straightforward: no recursion allowed in mmu-invalidate. > Will anything change here after the struct mutex removal series? AFAIR > you remove struct mutex from userptr invalidation there. No. This, aiui, is purely an issue where we trigger an mmu-invalidate from inside the mmu_invalidate_range_start. [snip] > I remember in the distant past we discussed whether or not to allow > this. It is indeed a quite perverse setup so I am okay with disallowing it. > > Reviewed-by: Tvrtko Ursulin > > Regards, > > Tvrtko > > P.S. I expect there will be some IGTs to be adjusted as well. Yup. This was to start the ball rolling as come rc1 we will have some fire-fighting to do. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Exercise context switching in parallell
We currently test context switching on each engine as a basic stress
test (just verifying that nothing explodes if we execute 2 requests from
different contexts sequentially). What we have not tested is what
happens if we try and do so on all available engines simultaneously,
putting our SW and the HW under the maximal stress.
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
---
.../drm/i915/gem/selftests/i915_gem_context.c | 205 ++
1 file changed, 205 insertions(+)
diff --git a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
index dc25bcc3e372..33acc33bc778 100644
--- a/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c
@@ -156,6 +156,210 @@ static int live_nop_switch(void *arg)
return err;
}
+struct parallel_switch {
+ struct task_struct *tsk;
+ struct intel_context *ce[2];
+};
+
+static int __live_parallel_switch1(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+ int err;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ err = 0;
+ if (i915_request_wait(rq, 0, HZ / 5) < 0)
+ err = -ETIME;
+ i915_request_put(rq);
+ if (err)
+ return err;
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (sync)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int __live_parallel_switchN(void *data)
+{
+ struct parallel_switch *arg = data;
+ struct drm_i915_private *i915 = arg->ce[0]->engine->i915;
+ IGT_TIMEOUT(end_time);
+ unsigned long count;
+
+ count = 0;
+ do {
+ struct i915_request *rq;
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[0]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ mutex_lock(>drm.struct_mutex);
+ rq = i915_request_create(arg->ce[1]);
+ if (IS_ERR(rq)) {
+ mutex_unlock(>drm.struct_mutex);
+ return PTR_ERR(rq);
+ }
+
+ i915_request_add(rq);
+ mutex_unlock(>drm.struct_mutex);
+
+ count++;
+ } while (!__igt_timeout(end_time, NULL));
+
+ pr_info("%s: %lu switches (many)\n", arg->ce[0]->engine->name, count);
+ return 0;
+}
+
+static int live_parallel_switch(void *arg)
+{
+ struct drm_i915_private *i915 = arg;
+ static int (* const func[])(void *arg) = {
+ __live_parallel_switch1,
+ __live_parallel_switchN,
+ NULL,
+ };
+ struct i915_gem_context *ctx[2];
+ struct parallel_switch *data;
+ int (* const *fn)(void *arg);
+ struct drm_file *file;
+ int err = 0;
+ int n;
+
+ /*
+* Check we can process switches on all engines simultaneously.
+*/
+
+ if (!DRIVER_CAPS(i915)->has_logical_contexts)
+ return 0;
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ data = kcalloc(I915_NUM_ENGINES, sizeof(*data), GFP_KERNEL);
+ if (!data)
+ return -ENOMEM;
+
+ for (n = 0; n < ARRAY_SIZE(ctx); n++) {
+ struct i915_gem_engines_iter it;
+ struct intel_context *ce;
+
+ mutex_lock(>drm.struct_mutex);
+ ctx[n] = live_context(i915, file);
+ mutex_unlock(>drm.struct_mutex);
+ if (IS_ERR(ctx[n])) {
+ err = PTR_ERR(ctx[n]);
+ goto out;
+ }
+
+ for_each_gem_engine(ce,
+ i915_gem_context_lock_engines(ctx[n]), it) {
+
Re: [Intel-gfx] [PATCH 10/22] drm/i915/selftests: add write-dword test for LMEM
Quoting Matthew Auld (2019-09-30 10:58:15)
> On 27/09/2019 21:42, Chris Wilson wrote:
> > Quoting Matthew Auld (2019-09-27 18:33:57)
> >> + i = 0;
> >> + engines = i915_gem_context_lock_engines(ctx);
> >> + do {
> >> + u32 rng = prandom_u32_state();
> >> + u32 dword = offset_in_page(rng) / 4;
> >> +
> >> + ce = engines->engines[order[i] % engines->num_engines];
> >> + i = (i + 1) % (count * count);
> >> + if (!ce || !intel_engine_can_store_dword(ce->engine))
> >> + continue;
> >> +
> >> + err = igt_gpu_write_dw(ce, vma, dword, rng);
> >> + if (err)
> >> + break;
> >
> > Do you have a test that does
> > dword,
> > 64B or cacheline,
> > page
> > random width of the above
> > before doing the read back of a random dword from those?
>
> Are you thinking write_dw + increment(dword, qword, cl, ..), or actually
> doing the fill: write_dw, write_qw, write_block?
Here, I think stride is most interesting to hit various caching/transfer
artifacts between the CPU and lmem (and possibly with writes to lmem).
I think write_dw et al better stress the GPU write side and the
instruction stream.
> Or maybe both? I have been playing around with the write_dw + increment
> for hugepages.c.
Maybe both :) Never say no to more patterns! (Just be cautious of time
budget and use the cycles wisely to maximise coverage of your mental
model of the HW.) Once we get past the obvious coherency glitches in the
driver, it gets far more subtle. It's easy enough to filter out the noise
but deducing a pattern from gaps in the testing is much harder :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] i915/gem_ctx_isolation: Check nonpriv values are kept across switch
On Fri, Sep 27, 2019 at 02:28:34PM +0100, Chris Wilson wrote: > Verify that the values we store in our nonpriv context image registers > are restored after a switch. > > v2: Use explicit ordering to ensure we force the context switch back and > forth in between the register writes and their read. > > Signed-off-by: Chris Wilson > Cc: Michał Winiarski Reviewed-by: Michał Winiarski -Michał > --- > tests/i915/gem_ctx_isolation.c | 31 +++ > 1 file changed, 31 insertions(+) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_mmap_gtt: Reduce RSS for fault-concurrent
The intent of exercising parallel page fault is not necessarily to
exercise parallel swap-in (we can safely rely on that being well tested
and is orthogonal to page faulting), but to make sure that our object
and GGTT locking is exercised. We can safely reduce our RSS without loss
of coverage. Furthermore, by using varying sizes we can exercise
different code paths within page faulting, rather than all being
serviced as partial mmaps. Instead of allocating 32 surfaces, each of
16MiB, we allocate 32 surfaces in incremental 512KiB sizes; halving the
memory requirement.
References: https://bugs.freedesktop.org/show_bug.cgi?id=111864
Signed-off-by: Chris Wilson
---
tests/i915/gem_mmap_gtt.c | 30 ++
1 file changed, 22 insertions(+), 8 deletions(-)
diff --git a/tests/i915/gem_mmap_gtt.c b/tests/i915/gem_mmap_gtt.c
index 91da5a37b..0f85e 100644
--- a/tests/i915/gem_mmap_gtt.c
+++ b/tests/i915/gem_mmap_gtt.c
@@ -67,12 +67,12 @@ mmap_bo(int fd, uint32_t handle)
}
static void *
-create_pointer(int fd)
+create_pointer_size(int fd, uint64_t size)
{
uint32_t handle;
void *ptr;
- handle = gem_create(fd, OBJECT_SIZE);
+ handle = gem_create(fd, size);
ptr = mmap_bo(fd, handle);
@@ -81,6 +81,12 @@ create_pointer(int fd)
return ptr;
}
+static void *
+create_pointer(int fd)
+{
+ return create_pointer_size(fd, OBJECT_SIZE);
+}
+
static void
test_access(int fd)
{
@@ -958,10 +964,16 @@ thread_fault_concurrent(void *closure)
int n;
for (n = 0; n < 32; n++) {
+ unsigned int id = (n + t->id) % 32;
+ uint32_t sz = *t->ptr[id] - 1;
+ int idx = rand() % sz + 1;
+
if (n & 1)
- *t->ptr[(n + t->id) % 32] = val;
+ t->ptr[id][idx] = val;
else
- val = *t->ptr[(n + t->id) % 32];
+ val = t->ptr[id][idx];
+
+ val++;
}
return NULL;
@@ -975,7 +987,10 @@ test_fault_concurrent(int fd)
int n;
for (n = 0; n < 32; n++) {
- ptr[n] = create_pointer(fd);
+ uint32_t sz = n << 19; /* 512KiB increments */
+
+ ptr[n] = create_pointer_size(fd, sz);
+ *ptr[n] = sz / sizeof(uint32_t); /* num_elems for convenience */
}
for (n = 0; n < 64; n++) {
@@ -987,9 +1002,8 @@ test_fault_concurrent(int fd)
for (n = 0; n < 64; n++)
pthread_join(thread[n].thread, NULL);
- for (n = 0; n < 32; n++) {
- munmap(ptr[n], OBJECT_SIZE);
- }
+ for (n = 0; n < 32; n++)
+ munmap(ptr[n], *ptr[n] * sizeof(uint32_t));
}
static void
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/userptr: Never allow userptr into the mappable GGTT
On 28/09/2019 09:25, Chris Wilson wrote:
Daniel Vetter uncovered a nasty cycle in using the mmu-notifiers to
invalidate userptr objects which also happen to be pulled into GGTT
mmaps. That is when we unbind the userptr object (on mmu invalidation),
we revoke all CPU mmaps, which may then recurse into mmu invalidation.
On the same object? Invalidate on userptr built from some mmap_gtt area,
or standard userptr object mmapped via gtt? Or one userptr object built
from a mmap_gtt of another userptr object?
Will anything change here after the struct mutex removal series? AFAIR
you remove struct mutex from userptr invalidation there.
We looked for ways of breaking the cycle, but the revocation on
invalidation is required and cannot be avoided. The only solution we
could see was to not allow such GGTT bindings of userptr objects in the
first place. In practice, no one really wants to use a GGTT mmapping of
a CPU pointer...
Just before Daniel's explosive lockdep patches land in rc1, we got a
genuine blip from CI:
<4>[ 246.793958] ==
<4>[ 246.793972] WARNING: possible circular locking dependency detected
<4>[ 246.793989] 5.3.0-gbd6c56f50d15-drmtip_372+ #1 Tainted: G U
<4>[ 246.794003] --
<4>[ 246.794017] kswapd0/145 is trying to acquire lock:
<4>[ 246.794030] 3f565be6 (>struct_mutex/1){+.+.}, at:
userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[ 246.794250]
but task is already holding lock:
<4>[ 246.794263] 1799cef9 (_vma->rwsem){}, at:
page_lock_anon_vma_read+0xe6/0x2a0
<4>[ 246.794291]
which lock already depends on the new lock.
<4>[ 246.794307]
the existing dependency chain (in reverse order) is:
<4>[ 246.794322]
-> #3 (_vma->rwsem){}:
<4>[ 246.794344]down_write+0x33/0x70
<4>[ 246.794357]__vma_adjust+0x3d9/0x7b0
<4>[ 246.794370]__split_vma+0x16a/0x180
<4>[ 246.794385]mprotect_fixup+0x2a5/0x320
<4>[ 246.794399]do_mprotect_pkey+0x208/0x2e0
<4>[ 246.794413]__x64_sys_mprotect+0x16/0x20
<4>[ 246.794429]do_syscall_64+0x55/0x1c0
<4>[ 246.794443]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794456]
-> #2 (>i_mmap_rwsem){}:
<4>[ 246.794478]down_write+0x33/0x70
<4>[ 246.794493]unmap_mapping_pages+0x48/0x130
<4>[ 246.794519]i915_vma_revoke_mmap+0x81/0x1b0 [i915]
<4>[ 246.794519]i915_vma_unbind+0x11d/0x4a0 [i915]
<4>[ 246.794519]i915_vma_destroy+0x31/0x300 [i915]
<4>[ 246.794519]__i915_gem_free_objects+0xb8/0x4b0 [i915]
<4>[ 246.794519]drm_file_free.part.0+0x1e6/0x290
<4>[ 246.794519]drm_release+0xa6/0xe0
<4>[ 246.794519]__fput+0xc2/0x250
<4>[ 246.794519]task_work_run+0x82/0xb0
<4>[ 246.794519]do_exit+0x35b/0xdb0
<4>[ 246.794519]do_group_exit+0x34/0xb0
<4>[ 246.794519]__x64_sys_exit_group+0xf/0x10
<4>[ 246.794519]do_syscall_64+0x55/0x1c0
<4>[ 246.794519]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794519]
-> #1 (>mutex){+.+.}:
<4>[ 246.794519]i915_gem_shrinker_taints_mutex+0x6d/0xe0 [i915]
<4>[ 246.794519]i915_address_space_init+0x9f/0x160 [i915]
<4>[ 246.794519]i915_ggtt_init_hw+0x55/0x170 [i915]
<4>[ 246.794519]i915_driver_probe+0xc9f/0x1620 [i915]
<4>[ 246.794519]i915_pci_probe+0x43/0x1b0 [i915]
<4>[ 246.794519]pci_device_probe+0x9e/0x120
<4>[ 246.794519]really_probe+0xea/0x3d0
<4>[ 246.794519]driver_probe_device+0x10b/0x120
<4>[ 246.794519]device_driver_attach+0x4a/0x50
<4>[ 246.794519]__driver_attach+0x97/0x130
<4>[ 246.794519]bus_for_each_dev+0x74/0xc0
<4>[ 246.794519]bus_add_driver+0x13f/0x210
<4>[ 246.794519]driver_register+0x56/0xe0
<4>[ 246.794519]do_one_initcall+0x58/0x300
<4>[ 246.794519]do_init_module+0x56/0x1f6
<4>[ 246.794519]load_module+0x25bd/0x2a40
<4>[ 246.794519]__se_sys_finit_module+0xd3/0xf0
<4>[ 246.794519]do_syscall_64+0x55/0x1c0
<4>[ 246.794519]entry_SYSCALL_64_after_hwframe+0x49/0xbe
<4>[ 246.794519]
-> #0 (>struct_mutex/1){+.+.}:
<4>[ 246.794519]__lock_acquire+0x15d8/0x1e90
<4>[ 246.794519]lock_acquire+0xa6/0x1c0
<4>[ 246.794519]__mutex_lock+0x9d/0x9b0
<4>[ 246.794519]userptr_mn_invalidate_range_start+0x18f/0x220 [i915]
<4>[ 246.794519]__mmu_notifier_invalidate_range_start+0x85/0x110
<4>[ 246.794519]try_to_unmap_one+0x76b/0x860
<4>[ 246.794519]rmap_walk_anon+0x104/0x280
<4>[ 246.794519]try_to_unmap+0xc0/0xf0
<4>[ 246.794519]shrink_page_list+0x561/0xc10
<4>[ 246.794519]shrink_inactive_list+0x220/0x440
<4>[ 246.794519]
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines (rev2)
== Series Details ==
Series: drm/i915/tgl: Magic udelay to relieve the random lockups with multiple
engines (rev2)
URL : https://patchwork.freedesktop.org/series/67365/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6973 -> Patchwork_14581
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/index.html
Known issues
Here are the changes found in Patchwork_14581 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/fi-bxt-dsi/igt@gem_ctx_cre...@basic-files.html
* igt@gem_ctx_switch@legacy-render:
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927] /
[fdo#111381])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/fi-apl-guc/igt@gem_ctx_swi...@legacy-render.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_6973/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_mmap_gtt@basic-write:
- fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) +2
similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_mmap_...@basic-write.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/fi-icl-u3/igt@gem_mmap_...@basic-write.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][9] -> [FAIL][10] ([fdo#111045] / [fdo#111096])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_mmap@basic-small-bo:
- fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +1
similar issue
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6973/fi-icl-u3/igt@gem_m...@basic-small-bo.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/fi-icl-u3/igt@gem_m...@basic-small-bo.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
[fdo#110387]: https://bugs.freedesktop.org/show_bug.cgi?id=110387
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111831]: https://bugs.freedesktop.org/show_bug.cgi?id=111831
Participating hosts (53 -> 46)
--
Additional (1): fi-cml-h
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-skl-6770hq fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6973 -> Patchwork_14581
CI-20190529: 20190529
CI_DRM_6973: 7462c58bba0fb6e85bd380591c3fd86e298c0f95 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5206: 5a6c68568def840cd720f18fc66f529a89f84675 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14581: ffe0e0f4ce510d58f1c20d6901bf2c1c5eccb189 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
ffe0e0f4ce51 drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14581/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Initialise breadcrumb lists on the virtual engine
On 29/09/2019 09:33, Chris Wilson wrote:
With deferring the breadcrumb signalling to the virtual engine (thanks
preempt-to-busy) we need to make sure the lists and irq-worker are ready
to send a signal.
Fixes: cb2377a919bb ("drm/i915: Fixup preempt-to-busy vs reset of a virtual
request")
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index 45fe87a59796..ded618bca587 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -4177,6 +4177,7 @@ intel_execlists_create_virtual(struct i915_gem_context
*ctx,
snprintf(ve->base.name, sizeof(ve->base.name), "virtual");
intel_engine_init_active(>base, ENGINE_VIRTUAL);
+ intel_engine_init_breadcrumbs(>base);
intel_engine_init_execlists(>base);
__intel_gt_set_wedged -> nop_submit_request? But how does the commit
from fixes come into play? That one was about not looking at the engine
timeline when we detect virtual request is hanging as far as I remember.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/22] drm/i915/selftests: add write-dword test for LMEM
On 27/09/2019 21:42, Chris Wilson wrote:
Quoting Matthew Auld (2019-09-27 18:33:57)
+ i = 0;
+ engines = i915_gem_context_lock_engines(ctx);
+ do {
+ u32 rng = prandom_u32_state();
+ u32 dword = offset_in_page(rng) / 4;
+
+ ce = engines->engines[order[i] % engines->num_engines];
+ i = (i + 1) % (count * count);
+ if (!ce || !intel_engine_can_store_dword(ce->engine))
+ continue;
+
+ err = igt_gpu_write_dw(ce, vma, dword, rng);
+ if (err)
+ break;
Do you have a test that does
dword,
64B or cacheline,
page
random width of the above
before doing the read back of a random dword from those?
Are you thinking write_dw + increment(dword, qword, cl, ..), or actually
doing the fill: write_dw, write_qw, write_block?
Or maybe both? I have been playing around with the write_dw + increment
for hugepages.c.
Think nasty cache artifacts, PCI transfers, and timing.
-Chris
___
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/tgl: Magic udelay to relieve the random lockups with multiple engines (rev2)
== Series Details == Series: drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines (rev2) URL : https://patchwork.freedesktop.org/series/67365/ State : warning == Summary == $ dim checkpatch origin/drm-tip ffe0e0f4ce51 drm/i915/tgl: Magic interrupt shadow to relieve some random lockups -:37: WARNING:LINE_SPACING: Missing a blank line after declarations #37: FILE: drivers/gpu/drm/i915/gt/intel_lrc.c:1193: + u64 start = local_clock(); + do 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
[Intel-gfx] [PATCH v2] drm/i915/tgl: Magic interrupt shadow to relieve some random lockups
My current theory is that this masks interrupt delivery to the local CPU
during a critical phase. Purely papering over the symptoms with a delay
plucked out of thin air from testing on tgl1-gem, refined slightly by
just waiting for the next ack (though technically the next CS event may
not be the corresponding event for this submit, but an intermediate
completion).
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Andi Shyti
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ab725a6ca0ac..35410d647b52 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -1155,6 +1155,7 @@ assert_pending_valid(const struct intel_engine_execlists
*execlists,
static void execlists_submit_ports(struct intel_engine_cs *engine)
{
struct intel_engine_execlists *execlists = >execlists;
+ unsigned int tail = READ_ONCE(*execlists->csb_write);
unsigned int n;
GEM_BUG_ON(!assert_pending_valid(execlists, "submit"));
@@ -1186,6 +1187,14 @@ static void execlists_submit_ports(struct
intel_engine_cs *engine)
/* we need to manually load the submit queue */
if (execlists->ctrl_reg)
writel(EL_CTRL_LOAD, execlists->ctrl_reg);
+
+ if (IS_TIGERLAKE(engine->i915)) {
+ u64 start = local_clock();
+ do
+ cpu_relax();
+ while (tail == READ_ONCE(*execlists->csb_write) &&
+ (local_clock() - start) >> 20 == 0);
+ }
}
static bool ctx_single_port_submission(const struct intel_context *ce)
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/tgl: Magic udelay to relieve the random lockups with multiple engines
Quoting Andi Shyti (2019-09-29 21:25:54) > Hi Chris, > > > --- a/drivers/gpu/drm/i915/gt/intel_lrc.c > > +++ b/drivers/gpu/drm/i915/gt/intel_lrc.c > > @@ -1186,6 +1186,21 @@ static void execlists_submit_ports(struct > > intel_engine_cs *engine) > > /* we need to manually load the submit queue */ > > if (execlists->ctrl_reg) > > writel(EL_CTRL_LOAD, execlists->ctrl_reg); > > + > > + /* > > + * Now this is evil magic. > > + * > > + * Adding the same udelay() to process_csb before we clear > > + * execlists->pending (that is after we receive the HW ack for this > > + * submit and before we can submit again) does not relieve the > > symptoms > > + * (machine lockup). So is the active difference here the wait under > > + * the irq-off spinlock? That gives more credance to the theory that > > + * the issue is interrupt delivery. Also note that we still rely on > > + * disabling RPS, again that seems like an issue with simultaneous > > + * GT interrupts being delivered to the same CPU. > > + */ > > + if (IS_TIGERLAKE(engine->i915)) > > + udelay(250); > > you want a delay of 250us. Two questions: > > 1. why 250? Magic. Purely first random number. > 2. is there any good reason for using 'udelay' for sleeping 250us >(that is quite a long time) and not 'usleep'? We are inside interrupt context. That this trick worked much better inside interrupt context than out makes me suspect interrupt delivery so much more. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH -next] treewide: remove unused argument in lock_release()
On Thu, Sep 19, 2019 at 12:09:40PM -0400, Qian Cai wrote:
> Since the commit b4adfe8e05f1 ("locking/lockdep: Remove unused argument
> in __lock_release"), @nested is no longer used in lock_release(), so
> remove it from all lock_release() calls and friends.
Right; I never did this cleanup for not wanting the churn, but as long
as it applies I'll take it.
> Signed-off-by: Qian Cai
> ---
> drivers/gpu/drm/drm_connector.c | 2 +-
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 6 +++---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
> drivers/gpu/drm/i915/i915_request.c | 2 +-
> drivers/tty/tty_ldsem.c | 8
> fs/dcache.c | 2 +-
> fs/jbd2/transaction.c | 4 ++--
> fs/kernfs/dir.c | 4 ++--
> fs/ocfs2/dlmglue.c| 2 +-
> include/linux/jbd2.h | 2 +-
> include/linux/lockdep.h | 21 ++---
> include/linux/percpu-rwsem.h | 4 ++--
> include/linux/rcupdate.h | 2 +-
> include/linux/rwlock_api_smp.h| 16
> include/linux/seqlock.h | 4 ++--
> include/linux/spinlock_api_smp.h | 8
> include/linux/ww_mutex.h | 2 +-
> include/net/sock.h| 2 +-
> kernel/bpf/stackmap.c | 2 +-
> kernel/cpu.c | 2 +-
> kernel/locking/lockdep.c | 3 +--
> kernel/locking/mutex.c| 4 ++--
> kernel/locking/rtmutex.c | 6 +++---
> kernel/locking/rwsem.c| 10 +-
> kernel/printk/printk.c| 10 +-
> kernel/sched/core.c | 2 +-
> lib/locking-selftest.c| 24
> mm/memcontrol.c | 2 +-
> net/core/sock.c | 2 +-
> tools/lib/lockdep/include/liblockdep/common.h | 3 +--
> tools/lib/lockdep/include/liblockdep/mutex.h | 2 +-
> tools/lib/lockdep/include/liblockdep/rwlock.h | 2 +-
> tools/lib/lockdep/preload.c | 16
> 33 files changed, 90 insertions(+), 93 deletions(-)
Thanks!
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Make is_signed_type() simpler
On 29/09/2019 23.09, Alexey Dobriyan wrote: > On Sun, Sep 29, 2019 at 10:21:48PM +0200, Rasmus Villemoes wrote: >> On 29/09/2019 22.06, Alexey Dobriyan wrote: >>> * Simply compare -1 with 0, >>> * Drop unnecessary parenthesis sets >>> >>> -#define is_signed_type(type) (((type)(-1)) < (type)1) >>> +#define is_signed_type(type) ((type)-1 < 0) >> >> NAK. I wrote it that way to avoid -Wtautological-compare when type is >> unsigned. > > Was is W=1? > > godbolt doesn't show it with just -Wall > > https://godbolt.org/z/kCA7mm > > And the warning which found i915 case is -Wextra not -Wtautological-compare. > Yeah, it's usually disabled/not enabled in the kernel. I did most of the prototyping/testing in userspace with my default Cflags, and decided to keep it this way in case somebody copy-pastes it to a code base that does enable -Wtautological-compare. I see it's been copy-pasted to tools/, who knows what they do. IMO, "it may be copy-pasted" would not be valid reason for a transform the other way, but I really don't see a reason for changing it now. Especially since it seems to require some tree-wide adaptation. Rasmus ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
