Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix coverage-vs-premult-vs-constant tests
Thank you very much Mark, for testing the patch and providing the "Tested-by"
tag.
Regards
Vidya
-Original Message-
From: Mark Yacoub
Sent: Saturday, June 5, 2021 12:12 AM
To: Srinivas, Vidya
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix
coverage-vs-premult-vs-constant tests
On Tue, Jun 1, 2021 at 7:54 AM Vidya Srinivas wrote:
>
> Few Gen11 systems show CRC mismatch. Make
> coverage-vs-premult-vs-constant code similar to constant_alpha_min or
> basic_alpha
>
Tested on ChromeOS on JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_plane_alpha_blend.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/tests/kms_plane_alpha_blend.c
> b/tests/kms_plane_alpha_blend.c index a37cb27c7d62..224d79bd1749
> 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t *data, enum
> pipe pipe, igt_plane_t
> igt_display_t *display = >display;
> igt_crc_t ref_crc = {}, crc = {};
>
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> -
> igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
> igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE,
> "Coverage");
> igt_plane_set_fb(plane, >argb_fb_cov_7e);
> igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer
Thank you very much Mark, for testing the patch and providing the "Tested-by"
tag.
Regards
Vidya
-Original Message-
From: Mark Yacoub
Sent: Saturday, June 5, 2021 12:13 AM
To: Srinivas, Vidya
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org;
Almahallawy, Khaled ; Lin, Charlton
Subject: Re: [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer
On Fri, May 28, 2021 at 12:41 AM Vidya Srinivas
wrote:
>
> Using (void *)-1 directly in read is aborting on chrome systems.
> Following message is seen.
>
> Starting subtest: invalid-buffer
> *** buffer overflow detected ***: terminated Received signal SIGABRT.
> Stack trace:
> Aborted (core dumped)
>
> Patch just adds a pointer variable and uses it in read.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/drm_read.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/drm_read.c b/tests/drm_read.c index
> ccf9d822fd8d..2fdec5be4078 100644
> --- a/tests/drm_read.c
> +++ b/tests/drm_read.c
> @@ -103,10 +103,11 @@ static void teardown(int fd) static void
> test_invalid_buffer(int in) {
> int fd = setup(in, 0);
> + void *add = (void *)-1;
>
> alarm(1);
>
> - igt_assert_eq(read(fd, (void *)-1, 4096), -1);
> + igt_assert_eq(read(fd, add, 4096), -1);
> igt_assert_eq(errno, EFAULT);
>
> teardown(fd);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
Thank you very much Mark, for testing the patch and providing the "Tested-by"
tag.
Regards
Vidya
-Original Message-
From: Mark Yacoub
Sent: Saturday, June 5, 2021 12:20 AM
To: Srinivas, Vidya
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org;
Almahallawy, Khaled ; Lin, Charlton
Subject: Re: [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before
collecting CRC
On Fri, May 28, 2021 at 12:36 AM Vidya Srinivas
wrote:
>
> Without wait for vblank, CRC mismatch is seen between big and small
> CRC on few Gen11 systems.
>
Tested on ChromeOS on JSL (Drawlat).
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_big_fb.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c index
> b35727a09bd0..f90363c3beb2 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data) static bool
> test_plane(data_t *data) {
> igt_plane_t *plane = data->plane;
> + igt_display_t *display = >display;
> struct igt_fb *small_fb = >small_fb;
> struct igt_fb *big_fb = >big_fb;
> int w = data->big_fb_width - small_fb->width; @@ -337,16
> +338,17 @@ static bool test_plane(data_t *data)
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>
> -
> + igt_wait_for_vblank(data->drm_fd,
> + display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, big_fb);
> igt_fb_set_position(big_fb, plane, x, y);
> igt_fb_set_size(big_fb, plane, small_fb->width,
> small_fb->height);
> +
> igt_plane_set_size(plane, data->width, data->height);
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> + igt_wait_for_vblank(data->drm_fd,
> + display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, NULL);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BUILD: failure for dma-buf: fix build due to missing export
This patch is intended for drm-misc, where the issue comes from. Lucas De Marchi On Sat, Jun 05, 2021 at 12:30:18AM +, Patchwork wrote: == Series Details == Series: dma-buf: fix build due to missing export URL : https://patchwork.freedesktop.org/series/91045/ State : failure == Summary == Applying: dma-buf: fix build due to missing export Using index info to reconstruct a base tree... M drivers/dma-buf/dma-resv.c Falling back to patching base and 3-way merge... Auto-merging drivers/dma-buf/dma-resv.c CONFLICT (content): Merge conflict in drivers/dma-buf/dma-resv.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 dma-buf: fix build due to missing export When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms
Thank you very much Mark, for testing the patch and providing the "Tested-by"
tag.
I shall incorporate you review comments and submit the patch.
Additionally, we have submitted the kernel alternative
https://patchwork.freedesktop.org/patch/436199/
Regards
Vidya
-Original Message-
From: Mark Yacoub
Sent: Saturday, June 5, 2021 12:24 AM
To: Srinivas, Vidya
Cc: Ville Syrjälä ;
igt-...@lists.freedesktop.org; intel-gfx@lists.freedesktop.org; Lin, Charlton
Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64
byte for Intel platforms
On Mon, May 31, 2021 at 10:47 AM Srinivas, Vidya
wrote:
>
> Hello Ville,
>
> Thank you very much.
> Before reaching our i915's i915_gem_dumb_create, it goes to
> vgem_gem_dumb_create for kms_prime.
>
> The pitch gets calculated there and it is not 64 byte aligned. Due to this,
> intel_framebuffer_init reports "pitch must be 64 byte aligned"
> and framebuffer creation fails. I tried submitting vgem patch where 64
> byte alignment can be done in vgem_gem_dumb_create and that also passes. But
> we did not get approval yet as few of them felt, vgem is generic and other
> platforms might fail if we do 64 byte alignment there.
>
> Kindly suggest. Thanks a lot.
>
> Regards
> Vidya
>
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, May 31, 2021 7:48 PM
> To: Srinivas, Vidya
> Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org;
> Lin, Charlton
> Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned
> pitch to 64 byte for Intel platforms
>
> On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> > For Intel platforms, pitch needs to be 64 byte aligned.
> > Kernel code vgem_gem_dumb_create which is platform generic code
> > doesnt do the alignment. This causes frame buffer creation to fail
> > on Intel platforms where the pitch is not 64 byte aligned.
> >
> > tests: test run on Intel platforms with panel resolution 1366x768
> >
Tested on ChromeOS on JSL (Drawlat).
Tested-by: Mark Yacoub
> > Signed-off-by: Vidya Srinivas
> > ---
> > tests/kms_prime.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> > 8cb2ca2a9dc3..fdc941fe8100 100644
> > --- a/tests/kms_prime.c
> > +++ b/tests/kms_prime.c
> > @@ -51,6 +51,8 @@ static struct {
> > { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x }, };
> >
> > +bool check_platform;
I think we can do a more precise name to indicate which platform.
Something like is_intel_device or is_i915 would be more appropriate.
alternatively, we can drop the boolean and just do the check when needed.
So it would look something like
+ is_i915_device(fd) ? ALIGN(scratch->width, 64) : scratch->width,
> > +
> > IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
> >
> > static bool has_prime_import(int fd) @@ -101,7 +103,7 @@ static
> > void prepare_scratch(int exporter_fd, struct dumb_bo *scratch,
> > scratch->bpp = 32;
> >
> > scratch->handle = kmstest_dumb_create(exporter_fd,
> > - scratch->width,
> > + check_platform? ALIGN(scratch->width, 64):
> > + scratch->width,
>
> The dumb_create ioctl already does this for us.
>
> > scratch->height,
> > scratch->bpp,
> > >pitch, @@ -262,6 +264,7 @@ igt_main
> >
> > /* ANY = anything that is not VGEM */
> > first_fd = __drm_open_driver_another(0, DRIVER_ANY |
> > DRIVER_VGEM);
> > + check_platform = is_i915_device(first_fd);
> > igt_require(first_fd >= 0);
> >
> > second_fd = __drm_open_driver_another(1, DRIVER_ANY |
> > DRIVER_VGEM);
> > --
> > 2.7.4
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
>
> --
> Ville Syrjälä
> Intel
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_color: Remove gamma code from degamma tests
Thank you very much Mark, for testing the patch and providing the "Tested-by"
tag.
Regards
Vidya
-Original Message-
From: Mark Yacoub
Sent: Friday, June 4, 2021 11:58 PM
To: Srinivas, Vidya
Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org;
Almahallawy, Khaled ; Lin, Charlton
; Latvala, Petri
Subject: Re: [PATCH i-g-t] tests/kms_color: Remove gamma code from degamma tests
On Thu, Jun 3, 2021 at 1:04 PM Vidya Srinivas wrote:
>
> CRC should be collected without degamma transformation and after
> drawing gradient with degamma LUT.
> This patch removes things which are not related to degamma and makes
> it similar to pipe gamma test.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_color.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/tests/kms_color.c b/tests/kms_color.c index
> 3a42532a5c27..2c9821cdecce 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -31,8 +31,7 @@ static void test_pipe_degamma(data_t *data, {
> igt_output_t *output;
> igt_display_t *display = >display;
> - gamma_lut_t *degamma_linear, *degamma_full;
> - gamma_lut_t *gamma_linear;
> + gamma_lut_t *degamma_full;
> color_t red_green_blue[] = {
> { 1.0, 0.0, 0.0 },
> { 0.0, 1.0, 0.0 },
> @@ -42,11 +41,8 @@ static void test_pipe_degamma(data_t *data,
> igt_require(igt_pipe_obj_has_prop(primary->pipe,
> IGT_CRTC_DEGAMMA_LUT));
> igt_require(igt_pipe_obj_has_prop(primary->pipe,
> IGT_CRTC_GAMMA_LUT));
>
> - degamma_linear = generate_table(data->degamma_lut_size, 1.0);
> degamma_full = generate_table_max(data->degamma_lut_size);
>
> - gamma_linear = generate_table(data->gamma_lut_size, 1.0);
> -
> for_each_valid_output_on_pipe(>display, primary->pipe->pipe,
> output) {
> drmModeModeInfo *mode;
> struct igt_fb fb_modeset, fb; @@ -75,8 +71,7 @@ static
> void test_pipe_degamma(data_t *data,
>
> igt_plane_set_fb(primary, _modeset);
> disable_ctm(primary->pipe);
> - disable_degamma(primary->pipe);
> - set_gamma(data, primary->pipe, gamma_linear);
> + set_degamma(data, primary->pipe, degamma_full);
> igt_display_commit(>display);
>
> /* Draw solid colors with no degamma transformation.
> */ @@ -92,7 +87,6 @@ static void test_pipe_degamma(data_t *data,
> */
> paint_gradient_rectangles(data, mode, red_green_blue, );
> igt_plane_set_fb(primary, );
> - set_degamma(data, primary->pipe, degamma_full);
> igt_display_commit(>display);
> igt_wait_for_vblank(data->drm_fd,
>
> display->pipes[primary->pipe->pipe].crtc_offset);
> @@ -105,13 +99,13 @@ static void test_pipe_degamma(data_t *data,
>
> igt_plane_set_fb(primary, NULL);
> igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit2(>display, data->display.is_atomic ?
> + COMMIT_ATOMIC
> + : COMMIT_LEGACY);
> igt_remove_fb(data->drm_fd, );
> igt_remove_fb(data->drm_fd, _modeset);
> }
>
> - free_lut(degamma_linear);
> free_lut(degamma_full);
> - free_lut(gamma_linear);
> }
>
> /*
> @@ -191,6 +185,8 @@ static void test_pipe_gamma(data_t *data,
>
> igt_plane_set_fb(primary, NULL);
> igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit2(>display, data->display.is_atomic ?
> + COMMIT_ATOMIC
> + : COMMIT_LEGACY);
> igt_remove_fb(data->drm_fd, );
> igt_remove_fb(data->drm_fd, _modeset);
> }
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_flip.c: Fix subtests flip-vs-suspend
Thank you so much Mark. This patch is not required. I have abandoned it. We needed to stop tlsdate daemon which was holding the RTC lock (initctl stop tlsdated). Apologies for the same. Regards Vidya -Original Message- From: Mark Yacoub Sent: Saturday, June 5, 2021 12:17 AM To: Srinivas, Vidya Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Almahallawy, Khaled ; Lin, Charlton Subject: Re: [PATCH i-g-t] [RFC] tests/kms_flip.c: Fix subtests flip-vs-suspend Tested it on ChromeOS and it runs well. But I think we should fix the root cause instead. On Fri, May 28, 2021 at 12:33 AM Vidya Srinivas wrote: > > Some Intel Gen11 systems are not able to do a RTC wake. > Instead change the default SUSPEND_TEST_NONE to SUSPEND_TEST_PLATFORM. > Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat) Tested-by: Mark Yacoub > Signed-off-by: Vidya Srinivas > --- > tests/kms_flip.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/kms_flip.c b/tests/kms_flip.c index > 8f736652be90..8afac88c9b15 100755 > --- a/tests/kms_flip.c > +++ b/tests/kms_flip.c > @@ -835,7 +835,8 @@ static bool run_test_step(struct test_output *o, > unsigned int *events) > > if (o->flags & TEST_SUSPEND) > igt_system_suspend_autoresume(SUSPEND_STATE_MEM, > - SUSPEND_TEST_NONE); > + is_i915_device(drm_fd)? > + > + SUSPEND_TEST_PLATFORM:SUSPEND_TEST_NONE); > > if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > > 0) > igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, > _reply) > -- > 2.7.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BUILD: failure for dma-buf: fix build due to missing export
== Series Details == Series: dma-buf: fix build due to missing export URL : https://patchwork.freedesktop.org/series/91045/ State : failure == Summary == Applying: dma-buf: fix build due to missing export Using index info to reconstruct a base tree... M drivers/dma-buf/dma-resv.c Falling back to patching base and 3-way merge... Auto-merging drivers/dma-buf/dma-resv.c CONFLICT (content): Merge conflict in drivers/dma-buf/dma-resv.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 dma-buf: fix build due to missing export When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-buf: fix build due to missing export
Commit 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit
v2")
turned dma_resv_reset_shared_max() into a function when
CONFIG_DEBUG_MUTEXES is set, but forgot to export it. That resulted in a
broken build:
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/vgem/vgem.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/amd/amdgpu/amdgpu.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/ttm/ttm.ko] undefined!
ERROR: modpost: "dma_resv_reset_shared_max" [drivers/gpu/drm/drm.ko]
undefined!
ERROR: modpost: "dma_resv_reset_shared_max"
[drivers/gpu/drm/drm_vram_helper.ko] undefined!
make[1]: *** [scripts/Makefile.modpost:150: modules-only.symvers] Error
1
Fixes: 0c6b522abc2a ("dma-buf: cleanup dma-resv shared fence debugging a bit
v2")
Cc: Christian König
Cc: Daniel Vetter
Cc: Sumit Semwal
Cc: "Christian König"
Cc: linux-me...@vger.kernel.org
Cc: dri-de...@lists.freedesktop.org
Cc: linaro-mm-...@lists.linaro.org
Signed-off-by: Lucas De Marchi
---
drivers/dma-buf/dma-resv.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/dma-buf/dma-resv.c b/drivers/dma-buf/dma-resv.c
index 3964df438505..6132ba631991 100644
--- a/drivers/dma-buf/dma-resv.c
+++ b/drivers/dma-buf/dma-resv.c
@@ -226,6 +226,7 @@ void dma_resv_reset_shared_max(struct dma_resv *obj)
fence->shared_max = fence->shared_count;
}
}
+EXPORT_SYMBOL(dma_resv_reset_shared_max);
#endif
/**
--
2.31.1
___
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/adl_p: Extend Wa_1606931601 for ADL-P
== Series Details == Series: drm/i915/adl_p: Extend Wa_1606931601 for ADL-P URL : https://patchwork.freedesktop.org/series/91042/ State : success == Summary == CI Bug Log - changes from CI_DRM_10171_full -> Patchwork_20288_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20288_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][1] ([i915#3002]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@legacy-engines-persistence: - shard-snb: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#1099]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-snb6/igt@gem_ctx_persiste...@legacy-engines-persistence.html * igt@gem_ctx_ringsize@active@bcs0: - shard-skl: [PASS][3] -> [INCOMPLETE][4] ([i915#3316]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-skl9/igt@gem_ctx_ringsize@act...@bcs0.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-skl3/igt@gem_ctx_ringsize@act...@bcs0.html * igt@gem_exec_fair@basic-none-share@rcs0: - shard-kbl: [PASS][5] -> [SKIP][6] ([fdo#109271]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-kbl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-kbl1/igt@gem_exec_fair@basic-none-sh...@rcs0.html * igt@gem_exec_fair@basic-none@vcs1: - shard-iclb: NOTRUN -> [FAIL][7] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-iclb1/igt@gem_exec_fair@basic-n...@vcs1.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][8] -> [FAIL][9] ([i915#2842]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-glk3/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#2190]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl2/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#307]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-skl3/igt@gem_mmap_...@big-copy-odd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-skl10/igt@gem_mmap_...@big-copy-odd.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][13] ([i915#2658]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl1/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][14] ([i915#3318]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl3/igt@gem_userptr_bl...@vma-merge.html * igt@i915_selftest@live@execlists: - shard-apl: NOTRUN -> [DMESG-FAIL][15] ([i915#3462]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl2/igt@i915_selftest@l...@execlists.html * igt@i915_selftest@live@hangcheck: - shard-tglb: [PASS][16] -> [INCOMPLETE][17] ([i915#750]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-tglb1/igt@i915_selftest@l...@hangcheck.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-tglb3/igt@i915_selftest@l...@hangcheck.html * igt@i915_suspend@forcewake: - shard-apl: NOTRUN -> [DMESG-WARN][18] ([i915#180]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl3/igt@i915_susp...@forcewake.html * igt@kms_big_fb@y-tiled-64bpp-rotate-270: - shard-kbl: NOTRUN -> [SKIP][19] ([fdo#109271]) +13 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-kbl2/igt@kms_big...@y-tiled-64bpp-rotate-270.html * igt@kms_ccs@pipe-c-missing-ccs-buffer: - shard-skl: NOTRUN -> [SKIP][20] ([fdo#109271] / [fdo#111304]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-skl2/igt@kms_...@pipe-c-missing-ccs-buffer.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][21] ([fdo#109271] / [fdo#111827]) +23 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/shard-apl2/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_chamelium@hdmi-hpd-storm-disable: - shard-skl: NOTRUN -> [SKIP][22] ([fdo#109271] / [fdo#111827]) +2 similar issues [22]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/adl_p: Extend Wa_1606931601 for ADL-P
== Series Details ==
Series: drm/i915/adl_p: Extend Wa_1606931601 for ADL-P
URL : https://patchwork.freedesktop.org/series/91042/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10171 -> Patchwork_20288
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/index.html
Known issues
Here are the changes found in Patchwork_20288 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-bsw-n3050: NOTRUN -> [INCOMPLETE][2] ([i915#3159])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [DMESG-WARN][3] ([i915#2868]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@runner@aborted:
- fi-kbl-x1275: [FAIL][5] ([i915#1436] / [i915#3363]) -> [FAIL][6]
([i915#1436] / [i915#2426] / [i915#3363])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-kbl-x1275/igt@run...@aborted.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-kbl-x1275/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][7] ([i915#2426] / [i915#3363] /
[k.org#202321]) -> [FAIL][8] ([i915#3363] / [k.org#202321])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-glk-dsi/igt@run...@aborted.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-glk-dsi/igt@run...@aborted.html
- fi-bsw-nick:[FAIL][9] ([fdo#109271] / [i915#1436]) -> [FAIL][10]
([fdo#109271] / [i915#1436] / [i915#2722])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-bsw-nick/igt@run...@aborted.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-bsw-nick/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][11] ([i915#3462]) -> [FAIL][12] ([i915#1602] /
[i915#2029])
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-bdw-5557u/igt@run...@aborted.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-bdw-5557u/igt@run...@aborted.html
- fi-kbl-soraka: [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363])
-> [FAIL][14] ([i915#1436] / [i915#3363])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-kbl-soraka/igt@run...@aborted.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-kbl-soraka/igt@run...@aborted.html
- fi-cfl-guc: [FAIL][15] ([i915#2426] / [i915#3363]) -> [FAIL][16]
([i915#3363])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-cfl-guc/igt@run...@aborted.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20288/fi-cfl-guc/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]: https://gitlab.freedesktop.org/drm/intel/issues/2029
[i915#2426]: https://gitlab.freedesktop.org/drm/intel/issues/2426
[i915#2722]: https://gitlab.freedesktop.org/drm/intel/issues/2722
[i915#2868]: https://gitlab.freedesktop.org/drm/intel/issues/2868
[i915#2932]: https://gitlab.freedesktop.org/drm/intel/issues/2932
[i915#2966]: https://gitlab.freedesktop.org/drm/intel/issues/2966
[i915#3159]: https://gitlab.freedesktop.org/drm/intel/issues/3159
[i915#3363]: https://gitlab.freedesktop.org/drm/intel/issues/3363
[i915#3462]: https://gitlab.freedesktop.org/drm/intel/issues/3462
[k.org#202321]: https://bugzilla.kernel.org/show_bug.cgi?id=202321
Participating hosts (43 -> 39)
--
Additional (1): fi-bsw-n3050
Missing(5): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-bsw-cyan fi-bdw-samus
Build changes
-
* Linux: CI_DRM_10171 -> Patchwork_20288
CI-20190529: 20190529
CI_DRM_10171: d297e8e1d96bf631f5d61085954244591896b447 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_6098: 1fbc1e7d602f96a7f4e2b95057eef994656b8e74 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_20288: 047418e7cadafc70dd2976d3e875c9da24af2ad4 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
047418e7cada drm/i915/adl_p: Extend Wa_1606931601
Re: [Intel-gfx] [PATCH 0/9] Enhance pipe color support for multi segmented luts
On 2021-06-01 6:41 a.m., Uma Shankar wrote: > Modern hardwares have multi segmented lut approach to prioritize > the darker regions of the spectrum. This series introduces a new > UAPI to define the lut ranges supported by the respective hardware. > > This also enables Pipe Color Management Support for Intel's XE_LPD hw. > Enable Support for Pipe Degamma with the increased lut samples > supported by hardware. This also adds support for newly introduced > Logarithmic Gamma for XE_LPD. Also added the gamma readout support. > > The Logarithmic gamma implementation on XE_LPD is non linear and adds 25 > segments with non linear lut samples in each segment. The expectation > is userspace will create the luts as per this distribution and pass > the final samples to driver to be programmed in hardware. > Is this design targetting Intel XE_LPD HW in particular or is it intended to be generic? If this is intended to be generic I think it would benefit from a lot more documentation. At this point it's difficult for me to see how to adapt this to AMD HW. It would take me a while to be comfortable to make a call on whether we can use it or not. And what about other vendors? I think we need to be cautious in directly exposing HW functionality through UAPI. The CM parts of AMD HW seem to be changing in some way each generation and it looks like the same is true for Intel. The trouble we have with adapting the old gamma/degamma properties to modern HW is some indication to me that this approach is somewhat problematic. It would be useful to understand and document the specific use-cases we want to provide to userspace implementers with this functionality. Do we want to support modern transfer functions such as PQ or HLG? If so, it might be beneficial to have an API to explicitly specify that, and then use LUT tables in drivers that are optimized for the implementing HW. Or is the use case tone mapping? If so, would a parametric definition of tone mapping be easier to manage? > +-+--+ > | x | 2 pow x segment|No of Entries > | | 0 | 1 | > | 0 | 1 | 1 | > | 1 | 2 | 2 | > | 2 | 4 | 2 | > | 3 | 8 | 2 | > | 4 | 16 | 2 | > | 5 | 32 | 4 | > | 6 | 64 | 4 | > | 7 | 128| 4 | > | 8 | 256| 8 | > | 9 | 512| 8 | > | 10 | 1024 | 8 | > | 11 | 2048 | 16 | > | 12 | 4096 | 16 | > | 13 | 8192 | 16 | > | 14 | 16384 | 32 | > | 15 | 32768 | 32 | > | 16 | 65536 | 64 | > | 17 | 131072 | 64 | > | 18 | 262144 | 64 | > | 19 | 524288 | 32 | > | 20 | 1048576| 32 | > | 21 | 2097152| 32 | > | 22 | 4194304| 32 | > | 23 | 8388608| 32 | > | 24 | 16777216 | 1 | > | | Total Entries | 511| > -+-++ > > Credits: Special mention and credits to Ville Syrjala for coming up > with a design for this feature and inputs. This series is based on > his original design. > > Note: Userspace support for this new UAPI will be done on Chrome and > plan is to get this supported on mutter as well. We will notify the > list once we have that ready for review. > Is this an RFC? If so it would be good to mark it as such. Harry > Uma Shankar (9): > drm: Add gamma mode property > drm/i915/xelpd: Define color lut range structure > drm/i915/xelpd: Add support for Logarithmic gamma mode > drm/i915/xelpd: Attach gamma mode property > drm: Add Client Cap for advance gamma mode > drm/i915/xelpd: logarithmic gamma enabled only with advance gamma mode > drm/i915/xelpd: Enable Pipe Degamma > drm/i915/xelpd: Add Pipe Color Lut caps to platform config > drm/i915/xelpd: Enable XE_LPD Gamma Lut readout > > drivers/gpu/drm/drm_atomic_uapi.c | 8 + > drivers/gpu/drm/drm_color_mgmt.c | 75 > drivers/gpu/drm/drm_ioctl.c| 5 + > drivers/gpu/drm/i915/display/intel_color.c | 454 - > drivers/gpu/drm/i915/i915_pci.c| 3 +- > drivers/gpu/drm/i915/i915_reg.h| 7 + > include/drm/drm_atomic.h | 1 + > include/drm/drm_color_mgmt.h | 8 + > include/drm/drm_crtc.h | 25 ++ > include/drm/drm_file.h | 8 + > include/uapi/drm/drm.h | 8 + > include/uapi/drm/drm_mode.h| 43 ++ > 12 files changed, 630 insertions(+), 15 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH] drm/i915/adl_p: Extend Wa_1606931601 for ADL-P
On Fri, Jun 04, 2021 at 03:14:25PM -0700, Nataraj Deshpande wrote:
> Helps to fixe skia test failures on adl_p platform.
>
> Cc: Matt Roper
> Cc: Lucas De Marchi
> Signed-off-by: Nataraj Deshpande
Reviewed-by: Matt Roper
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> index 62cb9ee5bfc3..38efc1e0ccfa 100644
> --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> @@ -1633,9 +1633,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine,
> struct i915_wa_list *wal)
> GEN7_DISABLE_SAMPLER_PREFETCH);
> }
>
> - if (IS_ALDERLAKE_S(i915) || IS_DG1(i915) ||
> + if (IS_ALDERLAKE_P(i915) || IS_ALDERLAKE_S(i915) || IS_DG1(i915) ||
> IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
> - /* Wa_1606931601:tgl,rkl,dg1,adl-s */
> + /* Wa_1606931601:tgl,rkl,dg1,adl-s,adl-p */
> wa_masked_en(wal, GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
>
> /*
> --
> 2.29.0
>
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/21] drm: Add Plane Degamma Mode property
On 2021-06-01 6:51 a.m., Uma Shankar wrote:
> Add Plane Degamma Mode as an enum property. Create a helper
> function for all plane color management features.
>
> This is an enum property with values as blob_id's and exposes
> the various gamma modes supported and the lut ranges. Getting
> the blob id in userspace, user can get the mode supported and
> also the range of gamma mode supported with number of lut
> coefficients. It can then set one of the modes using this
> enum property.
>
> Lut values will be sent through separate GAMMA_LUT blob property.
>
> Signed-off-by: Uma Shankar
> ---
> Documentation/gpu/drm-kms.rst | 90 ++
> drivers/gpu/drm/drm_atomic.c | 1 +
> drivers/gpu/drm/drm_atomic_state_helper.c | 2 +
> drivers/gpu/drm/drm_atomic_uapi.c | 4 +
> drivers/gpu/drm/drm_color_mgmt.c | 93 ++-
> include/drm/drm_mode_object.h | 2 +-
> include/drm/drm_plane.h | 23 ++
> 7 files changed, 212 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/drm-kms.rst b/Documentation/gpu/drm-kms.rst
> index 87e5023e3f55..752be545e7d7 100644
> --- a/Documentation/gpu/drm-kms.rst
> +++ b/Documentation/gpu/drm-kms.rst
> @@ -514,9 +514,99 @@ Damage Tracking Properties
> Color Management Properties
> ---
>
> +Below is how a typical hardware pipeline for color
> +will look like:
> +
> +.. kernel-render:: DOT
> + :alt: Display Color Pipeline
> + :caption: Display Color Pipeline Overview
> +
> + digraph "KMS" {
> + node [shape=box]
> +
> + subgraph cluster_static {
> + style=dashed
> + label="Display Color Hardware Blocks"
> +
> + node [bgcolor=grey style=filled]
> + "Plane Degamma A" -> "Plane CSC/CTM A"
> + "Plane CSC/CTM A" -> "Plane Gamma A"
> + "Pipe Blender" [color=lightblue,style=filled, width=5.25,
> height=0.75];
> + "Plane Gamma A" -> "Pipe Blender"
> + "Pipe Blender" -> "Pipe DeGamma"
> + "Pipe DeGamma" -> "Pipe CSC/CTM"
> + "Pipe CSC/CTM" -> "Pipe Gamma"
> + "Pipe Gamma" -> "Pipe Output"
> + }
> +
It might be worthwhile to also highlight the YCbCr coefficient matrix in the
pipeline,
between the FB and Plane degamma, i.e.
YCbCr coefficients > plane degamma > csc > ...
One problem with this view is that not all HW will support all (or any) of these
CM blocks on all planes. For example, on AMD HW cursors are very different from
other planes and don't really have full CM support.
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma B" -> "Plane CSC/CTM B"
> + "Plane CSC/CTM B" -> "Plane Gamma B"
> + "Plane Gamma B" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_static {
> + style=dashed
> +
> + node [shape=box]
> + "Plane Degamma C" -> "Plane CSC/CTM C"
> + "Plane CSC/CTM C" -> "Plane Gamma C"
> + "Plane Gamma C" -> "Pipe Blender"
> + }
> +
> + subgraph cluster_fb {
> + style=dashed
> + label="RAM"
> +
> + node [shape=box width=1.7 height=0.2]
> +
> + "FB 1" -> "Plane Degamma A"
> + "FB 2" -> "Plane Degamma B"
> + "FB 3" -> "Plane Degamma C"
> + }
> + }
> +
> +In real world usecases,
> +
> +1. Plane Degamma can be used to linearize a non linear gamma
> +encoded framebuffer. This is needed to do any linear math like
> +color space conversion. For ex, linearize frames encoded in SRGB
> +or by HDR curve.
> +
> +2. Later Plane CTM block can convert the content to some different
> +colorspace. For ex, SRGB to BT2020 etc.
> +
> +3. Plane Gamma block can be used later to re-apply the non-linear
> +curve. This can also be used to apply Tone Mapping for HDR usecases.
> +
This would mean you're blending in gamma space which is likely not what
most compositors expect. There are numerous articles that describe why
blending in gamma space is problematic, such as [1]
[1] https://ninedegreesbelow.com/photography/linear-gamma-blur-normal-blend.html
To blend in linear space this should be configured to do
Plane Degamma > Plane CTM > CRTC Gamma
I think it would also be good if we moved away from calling this gamma. It's
really only gamma for legacy SDR scenarios. For HDR cases I would never expect
these to use gamma and even though the sRGB transfer function is based on gamma
functions it's complicated [2].
[2] https://en.wikipedia.org/wiki/SRGB
A better way to describe these would be as "transfer function" and "inverse
transfer function." The space at various stages could then be described as
linear
or non-linear, specifically PQ, HLG, sRGB, BT709, or using another transfer
function.
Harry
> +All the layers or framebuffers need to be converted to same color
> +space and format before blending. The plane color hardware
[Intel-gfx] [PATCH] drm/i915/adl_p: Extend Wa_1606931601 for ADL-P
Helps to fixe skia test failures on adl_p platform.
Cc: Matt Roper
Cc: Lucas De Marchi
Signed-off-by: Nataraj Deshpande
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 62cb9ee5bfc3..38efc1e0ccfa 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1633,9 +1633,9 @@ rcs_engine_wa_init(struct intel_engine_cs *engine, struct
i915_wa_list *wal)
GEN7_DISABLE_SAMPLER_PREFETCH);
}
- if (IS_ALDERLAKE_S(i915) || IS_DG1(i915) ||
+ if (IS_ALDERLAKE_P(i915) || IS_ALDERLAKE_S(i915) || IS_DG1(i915) ||
IS_ROCKETLAKE(i915) || IS_TIGERLAKE(i915)) {
- /* Wa_1606931601:tgl,rkl,dg1,adl-s */
+ /* Wa_1606931601:tgl,rkl,dg1,adl-s,adl-p */
wa_masked_en(wal, GEN7_ROW_CHICKEN2, GEN12_DISABLE_EARLY_READ);
/*
--
2.29.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI] PR for new v62 GuC binaries
New binaries for all platforms. Cc: Matthew Brost Cc: John Harrison The following changes since commit f8462923ed8fc874f770b8c6dfad49d39b381f14: nvidia: fix symlinks for tu104/tu106 acr unload firmware (2021-05-18 11:03:08 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-firmware guc_v62 for you to fetch changes up to 5b20d5ead3692bf6cdf5b87dedc471391f5b9f1c: i915: Add GuC v62.0.0 for all platforms (2021-06-04 14:40:10 -0700) John Harrison (1): i915: Add GuC v62.0.0 for all platforms WHENCE | 30 ++ i915/adlp_guc_62.0.0.bin | Bin 0 -> 337280 bytes i915/bxt_guc_62.0.0.bin | Bin 0 -> 199616 bytes i915/cml_guc_62.0.0.bin | Bin 0 -> 200448 bytes i915/dg1_guc_62.0.0.bin | Bin 0 -> 315648 bytes i915/ehl_guc_62.0.0.bin | Bin 0 -> 327488 bytes i915/glk_guc_62.0.0.bin | Bin 0 -> 20 bytes i915/icl_guc_62.0.0.bin | Bin 0 -> 327488 bytes i915/kbl_guc_62.0.0.bin | Bin 0 -> 200448 bytes i915/skl_guc_62.0.0.bin | Bin 0 -> 199552 bytes i915/tgl_guc_62.0.0.bin | Bin 0 -> 326016 bytes 11 files changed, 30 insertions(+) create mode 100644 i915/adlp_guc_62.0.0.bin create mode 100644 i915/bxt_guc_62.0.0.bin create mode 100644 i915/cml_guc_62.0.0.bin create mode 100644 i915/dg1_guc_62.0.0.bin create mode 100644 i915/ehl_guc_62.0.0.bin create mode 100644 i915/glk_guc_62.0.0.bin create mode 100644 i915/icl_guc_62.0.0.bin create mode 100644 i915/kbl_guc_62.0.0.bin create mode 100644 i915/skl_guc_62.0.0.bin create mode 100644 i915/tgl_guc_62.0.0.bin ___ 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 + usb-type-c: Add support for out-of-band hotplug notification (rev4)
== Series Details == Series: drm + usb-type-c: Add support for out-of-band hotplug notification (rev4) URL : https://patchwork.freedesktop.org/series/89604/ State : success == Summary == CI Bug Log - changes from CI_DRM_10171_full -> Patchwork_20287_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20287_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-clear: - shard-skl: [PASS][1] -> [FAIL][2] ([i915#3160]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-skl8/igt@gem_cre...@create-clear.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-skl4/igt@gem_cre...@create-clear.html * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-apl6/igt@gem_cre...@create-massive.html * igt@gem_ctx_persistence@processes: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271] / [i915#1099]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-snb5/igt@gem_ctx_persiste...@processes.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2846]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk3/igt@gem_exec_f...@basic-deadline.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-glk6/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-flow@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-tglb3/igt@gem_exec_fair@basic-f...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-tglb7/igt@gem_exec_fair@basic-f...@rcs0.html * igt@gem_exec_fair@basic-none@vecs0: - shard-kbl: [PASS][9] -> [FAIL][10] ([i915#2842]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-kbl4/igt@gem_exec_fair@basic-n...@vecs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-kbl3/igt@gem_exec_fair@basic-n...@vecs0.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2842]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-glk4/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2851]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-tglb7/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-tglb2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][15] ([fdo#109271] / [i915#2190]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-apl8/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@cpuset-big-copy-odd: - shard-iclb: [PASS][16] -> [FAIL][17] ([i915#307]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-iclb3/igt@gem_mmap_...@cpuset-big-copy-odd.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-iclb7/igt@gem_mmap_...@cpuset-big-copy-odd.html - shard-glk: [PASS][18] -> [FAIL][19] ([i915#307]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk3/igt@gem_mmap_...@cpuset-big-copy-odd.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-glk6/igt@gem_mmap_...@cpuset-big-copy-odd.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][20] ([i915#2658]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-apl6/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@sync-overlap: - shard-glk: [PASS][21] -> [DMESG-WARN][22] ([i915#118] / [i915#95]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk9/igt@gem_userptr_bl...@sync-overlap.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-glk4/igt@gem_userptr_bl...@sync-overlap.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][23] ([i915#3318]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-apl2/igt@gem_userptr_bl...@vma-merge.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-kbl: NOTRUN -> [SKIP][24] ([fdo#109271] / [i915#1937]) [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/shard-kbl3/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_selftest@live@execlists: - shard-apl: NOTRUN -> [DMESG-FAIL][25] ([i915#3462])
[Intel-gfx] [drm-intel:drm-intel-gt-next 1/19] drivers/gpu/drm/i915/gt/uc/intel_uc.c:162:20: error: function 'guc_communication_enabled' is not needed and will not be emitted
tree: git://anongit.freedesktop.org/drm-intel drm-intel-gt-next
head: 84bdf4571d4dc36207bbc4b0fb2711723ee313d4
commit: 1fb12c5871521eab5fa428bf265841b1a3827a97 [1/19] drm/i915/guc: skip
disabling CTBs before sanitizing the GuC
config: x86_64-randconfig-r012-20210604 (attached as .config)
compiler: clang version 13.0.0 (https://github.com/llvm/llvm-project
5c0d1b2f902aa6a9cf47cc7e42c5b83bb2217cf9)
reproduce (this is a W=1 build):
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# install x86_64 cross compiling tool for clang build
# apt-get install binutils-x86-64-linux-gnu
git remote add drm-intel git://anongit.freedesktop.org/drm-intel
git fetch --no-tags drm-intel drm-intel-gt-next
git checkout 1fb12c5871521eab5fa428bf265841b1a3827a97
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/gt/uc/intel_uc.c:162:20: error: function
>> 'guc_communication_enabled' is not needed and will not be emitted
>> [-Werror,-Wunneeded-internal-declaration]
static inline bool guc_communication_enabled(struct intel_guc *guc)
^
1 error generated.
vim +/guc_communication_enabled +162 drivers/gpu/drm/i915/gt/uc/intel_uc.c
a9410a62506430 Daniele Ceraolo Spurio 2020-03-26 161
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 @162 static inline bool
guc_communication_enabled(struct intel_guc *guc)
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 163 {
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 164 return
intel_guc_ct_enabled(>ct);
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 165 }
8c69bd74a00baf Daniele Ceraolo Spurio 2019-12-16 166
:: The code at line 162 was first introduced by commit
:: 8c69bd74a00baff85f4ef46b9f79263a42e0d82c drm/i915/guc: Remove function
pointers for send/receive calls
:: TO: Daniele Ceraolo Spurio
:: CC: Daniele Ceraolo Spurio
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
Thanks for staying with me! Still hoping I can get back to using KMS/Wayland
combination with my setup.
I understand the current recommendation is to push the mode setting to the
wayland compositor per Ville here:
https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_337616
Alas, I am using Mutter (similar to issue #393) which (historically) doesn't
support mode setting (yet?).
There is mention of drm_dp_downstream_max_clock() in an i915 comment, which
looks like could be a reference to drm_dp_downstream_max_tmds_clock().
It seems there is a hard coded 165MHz max for DP_DWN_STRM_PORT_TYPE_TMDS or
(note the comment in the below code):
case DP_DS_PORT_TYPE_DVI:
if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
return 165000;
/* FIXME what to do about DVI dual link? */
return port_cap[1] * 2500;
Still wondering about the "one byte" format is for configuration, but I presume
it is setting DP_DETAILED_CAP_INFO_AVAILABLE to 0 which triggers this.
Is there a recommended approach to setting the port to support Dual-Link based
on EDID response (or is it too late by the time we get the EDID)?
Is there a recommended approach for a "disable filter", or "manual modeset"?
There are others who seem interested in overriding the filtering logic (e.g.
"do what I say even though it isn't clear it will work").
https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_829142
-Adam
-- Related --
I found these following a thread on the 165MHz clock limit in the context of DP
dual mode HDMI dongles with a patch experimenting with turning off the limit:
https://bugs.freedesktop.org/show_bug.cgi?id=112018#c2 (now
https://gitlab.freedesktop.org/drm/intel/-/issues/511) There is even a hack for
what appears to be a similar limitation
(using Dual mode DP): https://github.com/hansmi/fake-dp-dual-mode
Researching answers for previous questions:
"one byte" cap:
/*
* 0x80-0x8f describe downstream port capabilities, but there are two layouts
* based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not,
* each port's descriptor is one byte wide. If it was set, each port's is
* four bytes wide, starting with the one byte from the base info. As of
* DP interop v1.1a only VGA defines additional detail.
*/
And from a commit:
* Fixup logic for calculating the downstream port length to account for
the fact that downstream port caps can be either 1 byte or 4 bytes
long. We can actually skip fixing the max_clock/max_bpc helpers here
since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
DPCD = DisplayPort Configuration Data
DFP appears to be a structure to hold configuration data as part of
intel_attached_dp(connector):
/* Downstream facing port caps */
struct {
int min_tmds_clock, max_tmds_clock;
int max_dotclock;
u8 max_bpc;
bool ycbcr_444_to_420;
} dfp;
On Mon, May 31, 2021, at 10:28 AM, Adam Chasen wrote:
> Ville,
> Thanks for the additional detail!
>
> I looked up HPD and understand it is hot plug detection, but I didn't
> find much for "one byte caps format". I assume this is short hand for
> "capability format".
>
> Is the "one byte" format a limitation from the monitor, the dongle, the
> motherboard, or the chipset?
>
> What are some examples of other "capability formats"?
>
> Is there a recommended approach to setting the port to support
> Dual-Link based on EDID response (or is it too late by the time we get
> the EDID)?
>
> If there is no obvious automatic solution, do you have an example of a
> "manual override" (i.e. module argument) for another situation I can
> use as a guide?
>
> Still curious what DPCD DFP stands for.
>
> Thanks,
> Adam
>
> On Mon, May 31, 2021, at 10:15 AM, Ville Syrjälä wrote:
> > On Fri, May 28, 2021 at 02:15:46PM -0400, Adam Chasen wrote:
> > > Any further advice on tracing what is triggering what appears to be the
> > > limitation of the clock? My guess is it is imposing a DVI Single-Link
> > > speed (165000) limitation on the dual-link DVI adapter.
> > >
> > > > TMDS clock 25000-165000
> > >
> > > I am able to override in xorg with xrandr to 268500
> > >
> > > Per Ville's request:
> > > DPCD DFP: 0a
> > >
> > > What is the DPCD DFP?
> >
> > It indicates the port is DVI with HPD capability. But unfortunately it's
> > using the one byte caps format which doesn't let us differentiate
> > between single link and dual link DVI. So we take the more cautious
> > apporach and assume it's single link.
> >
> > >
> > > Thanks,
> > > Adam
> > >
> > > On Wed, May 12, 2021, at 5:07 PM, Adam Chasen wrote:
> > > > Ville,
> > > > DPCD DFP: 0a
> > > >
> > > > What is the DPCD DFP?
> > > >
> > > > Additional info, this is the first time there has been an issue with
> > > > this adapter not working (i.e. it must have been operating
[Intel-gfx] ✗ Fi.CI.IGT: failure for Pipe DMC Support (rev5)
== Series Details == Series: Pipe DMC Support (rev5) URL : https://patchwork.freedesktop.org/series/90445/ State : failure == Summary == CI Bug Log - changes from CI_DRM_10171_full -> Patchwork_20286_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_20286_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_20286_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_20286_full: ### IGT changes ### Possible regressions * igt@kms_big_fb@linear-16bpp-rotate-180: - shard-iclb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-iclb8/igt@kms_big...@linear-16bpp-rotate-180.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-iclb2/igt@kms_big...@linear-16bpp-rotate-180.html Known issues Here are the changes found in Patchwork_20286_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_create@create-massive: - shard-apl: NOTRUN -> [DMESG-WARN][3] ([i915#3002]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-apl6/igt@gem_cre...@create-massive.html * igt@gem_ctx_isolation@preservation-s3@vcs0: - shard-kbl: [PASS][4] -> [DMESG-WARN][5] ([i915#180]) +6 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-kbl3/igt@gem_ctx_isolation@preservation...@vcs0.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-kbl4/igt@gem_ctx_isolation@preservation...@vcs0.html * igt@gem_ctx_persistence@legacy-engines-persistence: - shard-snb: NOTRUN -> [SKIP][6] ([fdo#109271] / [i915#1099]) +1 similar issue [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-persistence.html * igt@gem_ctx_persistence@many-contexts: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2410]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-tglb6/igt@gem_ctx_persiste...@many-contexts.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-tglb7/igt@gem_ctx_persiste...@many-contexts.html * igt@gem_ctx_ringsize@active@bcs0: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#3316]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-skl9/igt@gem_ctx_ringsize@act...@bcs0.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-skl5/igt@gem_ctx_ringsize@act...@bcs0.html * igt@gem_exec_fair@basic-deadline: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#2846]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk3/igt@gem_exec_f...@basic-deadline.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-glk9/igt@gem_exec_f...@basic-deadline.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-tglb: [PASS][13] -> [FAIL][14] ([i915#2842]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-tglb7/igt@gem_exec_fair@basic-p...@rcs0.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-tglb6/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_exec_fair@basic-pace@vcs1: - shard-iclb: NOTRUN -> [FAIL][15] ([i915#2842]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-iclb4/igt@gem_exec_fair@basic-p...@vcs1.html * igt@gem_exec_reloc@basic-wide-active@vcs1: - shard-iclb: NOTRUN -> [FAIL][16] ([i915#2389]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-iclb4/igt@gem_exec_reloc@basic-wide-act...@vcs1.html * igt@gem_huc_copy@huc-copy: - shard-kbl: NOTRUN -> [SKIP][17] ([fdo#109271] / [i915#2190]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-kbl3/igt@gem_huc_c...@huc-copy.html * igt@gem_pwrite@basic-exhaustion: - shard-apl: NOTRUN -> [WARN][18] ([i915#2658]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-apl1/igt@gem_pwr...@basic-exhaustion.html * igt@gem_userptr_blits@vma-merge: - shard-apl: NOTRUN -> [FAIL][19] ([i915#3318]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-apl6/igt@gem_userptr_bl...@vma-merge.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][20] -> [FAIL][21] ([i915#454]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-iclb8/igt@i915_pm...@dc6-psr.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/shard-iclb6/igt@i915_pm...@dc6-psr.html * igt@i915_selftest@live@execlists: -
[Intel-gfx] ✓ Fi.CI.BAT: success for drm + usb-type-c: Add support for out-of-band hotplug notification (rev4)
== Series Details ==
Series: drm + usb-type-c: Add support for out-of-band hotplug notification
(rev4)
URL : https://patchwork.freedesktop.org/series/89604/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10171 -> Patchwork_20287
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/index.html
Known issues
Here are the changes found in Patchwork_20287 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_cs_nop@sync-fork-compute0:
- fi-snb-2600:NOTRUN -> [SKIP][1] ([fdo#109271]) +17 similar issues
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-snb-2600/igt@amdgpu/amd_cs_...@sync-fork-compute0.html
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][2] ([fdo#109271] / [i915#2190])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@execlists:
- fi-bxt-dsi: NOTRUN -> [DMESG-FAIL][3] ([i915#3462])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_busy@basic@modeset:
- fi-tgl-y: [PASS][4] -> [DMESG-WARN][5] ([i915#1982])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-tgl-y/igt@kms_busy@ba...@modeset.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-tgl-y/igt@kms_busy@ba...@modeset.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271] / [fdo#111827]) +8
similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271]) +10 similar issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][8] -> [FAIL][9] ([i915#49])
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-bxt-dsi: NOTRUN -> [SKIP][10] ([fdo#109271] / [i915#533])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@i915_selftest@live@gt_heartbeat:
- {fi-jsl-1}: [DMESG-WARN][11] ([i915#1222]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-jsl-1/igt@i915_selftest@live@gt_heartbeat.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-jsl-1/igt@i915_selftest@live@gt_heartbeat.html
* igt@i915_selftest@live@hangcheck:
- fi-snb-2600:[INCOMPLETE][13] ([i915#2782]) -> [PASS][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-snb-2600/igt@i915_selftest@l...@hangcheck.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [DMESG-WARN][15] ([i915#2868]) -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@i915_selftest@live@execlists:
- fi-bsw-nick:[INCOMPLETE][17] ([i915#2782] / [i915#2940] /
[i915#3462]) -> [DMESG-FAIL][18] ([i915#3462])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-bsw-nick/igt@i915_selftest@l...@execlists.html
- fi-icl-u2: [INCOMPLETE][19] ([i915#2782] / [i915#3462]) ->
[DMESG-FAIL][20] ([i915#3462])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@i915_selftest@l...@execlists.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-icl-u2/igt@i915_selftest@l...@execlists.html
* igt@runner@aborted:
- fi-icl-u2: [FAIL][21] ([i915#2782] / [i915#3363]) -> [FAIL][22]
([i915#2426] / [i915#2782] / [i915#3363])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@run...@aborted.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20287/fi-icl-u2/igt@run...@aborted.html
- fi-glk-dsi: [FAIL][23] ([i915#2426] / [i915#3363] /
[k.org#202321]) -> [FAIL][24] ([i915#3363] / [k.org#202321])
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm + usb-type-c: Add support for out-of-band hotplug notification (rev4)
== Series Details == Series: drm + usb-type-c: Add support for out-of-band hotplug notification (rev4) URL : https://patchwork.freedesktop.org/series/89604/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1 KB" +./drivers/gpu/drm/amd/amdgpu/../amdgpu/amdgv_sriovmsg.h:312:49: error: static assertion failed: "amd_sriov_msg_vf2pf_info must be 1
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Move engine->schedule to i915_sched_engine
On Fri, Jun 04, 2021 at 02:03:46PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > The schedule function should be in the schedule object.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
> > drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 8
> > drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
> > .../gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 16
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> > drivers/gpu/drm/i915/i915_request.c | 10 +-
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 8
> > 11 files changed, 31 insertions(+), 34 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > index 4b9856d5ba14..af1fbf8e2a9a 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> > @@ -104,8 +104,8 @@ static void fence_set_priority(struct dma_fence *fence,
> > engine = rq->engine;
> >
> > rcu_read_lock(); /* RCU serialisation for set-wedged protection */
> > - if (engine->schedule)
> > - engine->schedule(rq, attr);
> > + if (engine->sched_engine->schedule)
> > + engine->sched_engine->schedule(rq, attr);
> > rcu_read_unlock();
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 33d879137908..b480fcb1aad1 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -326,9 +326,6 @@ static int intel_engine_setup(struct intel_gt *gt, enum
> > intel_engine_id id)
> > if (engine->context_size)
> > DRIVER_CAPS(i915)->has_logical_contexts = true;
> >
> > - /* Nothing to do here, execute in order of dependencies */
> > - engine->schedule = NULL;
> > -
> > ewma__engine_latency_init(>latency);
> > seqcount_init(>stats.lock);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > index b99ac41695f3..b6a305e6a974 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> > @@ -121,7 +121,7 @@ static void heartbeat(struct work_struct *wrk)
> > * but all other contexts, including the kernel
> > * context are stuck waiting for the signal.
> > */
> > - } else if (engine->schedule &&
> > + } else if (engine->sched_engine->schedule &&
> >rq->sched.attr.priority < I915_PRIORITY_BARRIER)
> > {
> > /*
> > * Gradually raise the priority of the heartbeat to
> > @@ -136,7 +136,7 @@ static void heartbeat(struct work_struct *wrk)
> > attr.priority = I915_PRIORITY_BARRIER;
> >
> > local_bh_disable();
> > - engine->schedule(rq, );
> > + engine->sched_engine->schedule(rq, );
> > local_bh_enable();
> > } else {
> > if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index 7197b9fa5e35..f1b14aff5118 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > @@ -426,14 +426,6 @@ struct intel_engine_cs {
> > void(*bond_execute)(struct i915_request *rq,
> > struct dma_fence *signal);
> >
> > - /*
> > -* Call when the priority on a request has changed and it and its
> > -* dependencies may need rescheduling. Note the request itself may
> > -* not be ready to run!
> > -*/
> > - void(*schedule)(struct i915_request *request,
> > - const struct i915_sched_attr *attr);
> > -
> > void(*release)(struct intel_engine_cs *engine);
> >
> > struct intel_engine_execlists execlists;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > index 3cca7ea2d6ea..84142127ebd8 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> > @@ -108,7 +108,7 @@ static void set_scheduler_caps(struct drm_i915_private
Re: [Intel-gfx] [PATCH 8/9] drm/i915: Move submission tasklet to i915_sched_engine
On Fri, Jun 04, 2021 at 02:26:38PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > The submission tasklet operates on i915_sched_engine, thus it is the
> > correct place for it.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine.h| 14 ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +--
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 --
> > .../drm/i915/gt/intel_execlists_submission.c | 86 ++-
> > drivers/gpu/drm/i915/gt/mock_engine.c | 1 +
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 ++--
> > drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
> > drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +-
> > drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25 +++---
> > drivers/gpu/drm/i915/i915_scheduler.c | 1 +
> > drivers/gpu/drm/i915/i915_scheduler.h | 14 +++
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++
> > 13 files changed, 99 insertions(+), 93 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > index a8b2174b4395..988d9688ae4d 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > @@ -123,20 +123,6 @@ execlists_active(const struct intel_engine_execlists
> > *execlists)
> > return active;
> > }
> >
> > -static inline void
> > -execlists_active_lock_bh(struct intel_engine_execlists *execlists)
> > -{
> > - local_bh_disable(); /* prevent local softirq and lock recursion */
> > - tasklet_lock(>tasklet);
> > -}
> > -
> > -static inline void
> > -execlists_active_unlock_bh(struct intel_engine_execlists *execlists)
> > -{
> > - tasklet_unlock(>tasklet);
> > - local_bh_enable(); /* restore softirq, and kick ksoftirqd! */
> > -}
> > -
> > struct i915_request *
> > execlists_unwind_incomplete_requests(struct intel_engine_execlists
> > *execlists);
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index b480fcb1aad1..837d2132e31b 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -711,6 +711,7 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > err = -ENOMEM;
> > goto err_sched_engine;
> > }
> > + engine->sched_engine->engine = engine;
>
> This bothers me. If we're trying to separate things, why do we have a
> back pointer? Yes, I know it's because we need to access our engine
> back-end somehow. Makes me wonder if it should be some sort of a
> void* private data pointer instead of the engine. That's probably
> less safe but it seems more "right" in some sense? I don't know.
>
This was new moving from internal to upstream because of the new tasklet
API that has landed. Previously the tasklet function was setup with u64
data which we used to point to the engine. Now it uses a callback with
the tasklet structure as the argument and can only use a container_of to
resolve the object which in this case a i915_sched_engine. In execlists
we still need the engine object to do the submit, hence the back
pointer.
Longterm we really should have an execlists_submit_engine which
encapsulates the i915_sched_engine and everything we need for execlists
submission (and with DRM scheduler the i915_sched_engine encapsulates
the drm_gpu_scheduler object and common variables between execlists and
GuC).
I already have an object like this for the GuC, guc_submit_eninge,
albeit slightly out of order in patch series.
Agree void* private is better as for the GuC code we likely need this to
be a backpointer to the GuC structure until the aforementioned
guc_submit_engine lands.
Are you ok with landing this with a void* and taking a note this needs
to be reworked?
> Also, dumb question but what's a tasklet?
>
All submissions in the current i915 go through a tasklet. The GuC
submission that will initially land uses this too. Once the DRM
scheduler lands this will go away, at least for GuC submission. If this
is still around for execlists we likely stick this in
execlists_submit_engine object and forget about it.
Matt
> --Jason
>
> >
> > err = intel_engine_init_cmd_parser(engine);
> > if (err)
> > @@ -935,7 +936,6 @@ int intel_engines_init(struct intel_gt *gt)
> > void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> > {
> > GEM_BUG_ON(!list_empty(>sched_engine->requests));
> > - tasklet_kill(>execlists.tasklet); /* flush the callback */
> >
> > i915_sched_engine_put(engine->sched_engine);
> > intel_breadcrumbs_free(engine->breadcrumbs);
> > @@ -1221,7 +1221,7 @@ static bool ring_is_idle(struct intel_engine_cs
> > *engine)
> >
> > void
[Intel-gfx] [PATCH 8/8] usb: typec: altmodes/displayport: Notify drm subsys of hotplug events
Use the new drm_connector_oob_hotplug_event() functions to let drm/kms
drivers know about DisplayPort over Type-C hotplug events.
Reviewed-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
Changes in v3:
- Only call drm_connector_oob_hotplug_event() on hpd status bit change
- Adjust for drm_connector_oob_hotplug_event() no longer having a data
argument
Changes in v2:
- Add missing depends on DRM to TYPEC_DP_ALTMODE Kconfig entry
---
drivers/usb/typec/altmodes/Kconfig | 1 +
drivers/usb/typec/altmodes/displayport.c | 23 +++
2 files changed, 24 insertions(+)
diff --git a/drivers/usb/typec/altmodes/Kconfig
b/drivers/usb/typec/altmodes/Kconfig
index 60d375e9c3c7..1a6b5e872b0d 100644
--- a/drivers/usb/typec/altmodes/Kconfig
+++ b/drivers/usb/typec/altmodes/Kconfig
@@ -4,6 +4,7 @@ menu "USB Type-C Alternate Mode drivers"
config TYPEC_DP_ALTMODE
tristate "DisplayPort Alternate Mode driver"
+ depends on DRM
help
DisplayPort USB Type-C Alternate Mode allows DisplayPort
displays and adapters to be attached to the USB Type-C
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index aa669b9cf70e..c1d8c23baa39 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -11,8 +11,10 @@
#include
#include
#include
+#include
#include
#include
+#include
#include "displayport.h"
#define DP_HEADER(_dp, ver, cmd) (VDO((_dp)->alt->svid, 1, ver, cmd)
\
@@ -57,11 +59,13 @@ struct dp_altmode {
struct typec_displayport_data data;
enum dp_state state;
+ bool hpd;
struct mutex lock; /* device lock */
struct work_struct work;
struct typec_altmode *alt;
const struct typec_altmode *port;
+ struct fwnode_handle *connector_fwnode;
};
static int dp_altmode_notify(struct dp_altmode *dp)
@@ -125,6 +129,7 @@ static int dp_altmode_configure(struct dp_altmode *dp, u8
con)
static int dp_altmode_status_update(struct dp_altmode *dp)
{
bool configured = !!DP_CONF_GET_PIN_ASSIGN(dp->data.conf);
+ bool hpd = !!(dp->data.status & DP_STATUS_HPD_STATE);
u8 con = DP_STATUS_CONNECTION(dp->data.status);
int ret = 0;
@@ -137,6 +142,11 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
ret = dp_altmode_configure(dp, con);
if (!ret)
dp->state = DP_STATE_CONFIGURE;
+ } else {
+ if (dp->hpd != hpd) {
+ drm_connector_oob_hotplug_event(dp->connector_fwnode);
+ dp->hpd = hpd;
+ }
}
return ret;
@@ -512,6 +522,7 @@ static const struct attribute_group dp_altmode_group = {
int dp_altmode_probe(struct typec_altmode *alt)
{
const struct typec_altmode *port = typec_altmode_get_partner(alt);
+ struct fwnode_handle *fwnode;
struct dp_altmode *dp;
int ret;
@@ -540,6 +551,11 @@ int dp_altmode_probe(struct typec_altmode *alt)
alt->desc = "DisplayPort";
alt->ops = _altmode_ops;
+ fwnode = dev_fwnode(alt->dev.parent->parent); /* typec_port fwnode */
+ dp->connector_fwnode = fwnode_find_reference(fwnode, "displayport", 0);
+ if (IS_ERR(dp->connector_fwnode))
+ dp->connector_fwnode = NULL;
+
typec_altmode_set_drvdata(alt, dp);
dp->state = DP_STATE_ENTER;
@@ -555,6 +571,13 @@ void dp_altmode_remove(struct typec_altmode *alt)
sysfs_remove_group(>dev.kobj, _altmode_group);
cancel_work_sync(>work);
+
+ if (dp->connector_fwnode) {
+ if (dp->hpd)
+ drm_connector_oob_hotplug_event(dp->connector_fwnode);
+
+ fwnode_handle_put(dp->connector_fwnode);
+ }
}
EXPORT_SYMBOL_GPL(dp_altmode_remove);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 7/8] usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic
Make dp_altmode_notify() handle the dp->data.conf == 0 case too,
rather then having separate code-paths for this in various places
which call it.
Reviewed-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/usb/typec/altmodes/displayport.c | 35 +---
1 file changed, 13 insertions(+), 22 deletions(-)
diff --git a/drivers/usb/typec/altmodes/displayport.c
b/drivers/usb/typec/altmodes/displayport.c
index b7f094435b00..aa669b9cf70e 100644
--- a/drivers/usb/typec/altmodes/displayport.c
+++ b/drivers/usb/typec/altmodes/displayport.c
@@ -66,10 +66,17 @@ struct dp_altmode {
static int dp_altmode_notify(struct dp_altmode *dp)
{
- u8 state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+ unsigned long conf;
+ u8 state;
+
+ if (dp->data.conf) {
+ state = get_count_order(DP_CONF_GET_PIN_ASSIGN(dp->data.conf));
+ conf = TYPEC_MODAL_STATE(state);
+ } else {
+ conf = TYPEC_STATE_USB;
+ }
- return typec_altmode_notify(dp->alt, TYPEC_MODAL_STATE(state),
- >data);
+ return typec_altmode_notify(dp->alt, conf, >data);
}
static int dp_altmode_configure(struct dp_altmode *dp, u8 con)
@@ -137,21 +144,10 @@ static int dp_altmode_status_update(struct dp_altmode *dp)
static int dp_altmode_configured(struct dp_altmode *dp)
{
- int ret;
-
sysfs_notify(>alt->dev.kobj, "displayport", "configuration");
-
- if (!dp->data.conf)
- return typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
- >data);
-
- ret = dp_altmode_notify(dp);
- if (ret)
- return ret;
-
sysfs_notify(>alt->dev.kobj, "displayport", "pin_assignment");
- return 0;
+ return dp_altmode_notify(dp);
}
static int dp_altmode_configure_vdm(struct dp_altmode *dp, u32 conf)
@@ -172,13 +168,8 @@ static int dp_altmode_configure_vdm(struct dp_altmode *dp,
u32 conf)
}
ret = typec_altmode_vdm(dp->alt, header, , 2);
- if (ret) {
- if (DP_CONF_GET_PIN_ASSIGN(dp->data.conf))
- dp_altmode_notify(dp);
- else
- typec_altmode_notify(dp->alt, TYPEC_STATE_USB,
->data);
- }
+ if (ret)
+ dp_altmode_notify(dp);
return ret;
}
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/8] drm/i915/dp: Add support for out-of-bound hotplug events
On some Cherry Trail devices, DisplayPort over Type-C is supported through
a USB-PD microcontroller (e.g. a fusb302) + a mux to switch the superspeed
datalines between USB-3 and DP (e.g. a pi3usb30532). The kernel in this
case does the PD/alt-mode negotiation itself, rather then everything being
handled in firmware.
So the kernel itself picks an alt-mode, tells the Type-C "dongle" to switch
to DP mode and sets the mux accordingly. In this setup the HPD pin is not
connected, so the i915 driver needs to respond to a software event and scan
the DP port for changes manually.
This commit adds support for this. Together with the recent addition of
DP alt-mode support to the Type-C subsystem this makes DP over Type-C
work on these devices.
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_dp.c | 12
1 file changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 5c983044..5d6cf2657fa3 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4598,6 +4598,17 @@ static int intel_dp_connector_atomic_check(struct
drm_connector *conn,
return intel_modeset_synced_crtcs(state, conn);
}
+static void intel_dp_oob_hotplug_event(struct drm_connector *connector)
+{
+ struct intel_encoder *encoder =
intel_attached_encoder(to_intel_connector(connector));
+ struct drm_i915_private *i915 = to_i915(connector->dev);
+
+ spin_lock_irq(>irq_lock);
+ i915->hotplug.event_bits |= BIT(encoder->hpd_pin);
+ spin_unlock_irq(>irq_lock);
+ queue_delayed_work(system_wq, >hotplug.hotplug_work, 0);
+}
+
static const struct drm_connector_funcs intel_dp_connector_funcs = {
.force = intel_dp_force,
.fill_modes = drm_helper_probe_single_connector_modes,
@@ -4608,6 +4619,7 @@ static const struct drm_connector_funcs
intel_dp_connector_funcs = {
.destroy = intel_connector_destroy,
.atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
.atomic_duplicate_state = intel_digital_connector_duplicate_state,
+ .oob_hotplug_event = intel_dp_oob_hotplug_event,
};
static const struct drm_connector_helper_funcs intel_dp_connector_helper_funcs
= {
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/8] drm/i915: Associate ACPI connector nodes with connector entries (v2)
From: Heikki Krogerus
On Intel platforms we know that the ACPI connector device
node order will follow the order the driver (i915) decides.
The decision is made using the custom Intel ACPI OpRegion
(intel_opregion.c), though the driver does not actually know
that the values it sends to ACPI there are used for
associating a device node for the connectors, and assigning
address for them.
In reality that custom Intel ACPI OpRegion actually violates
ACPI specification (we supply dynamic information to objects
that are defined static, for example _ADR), however, it
makes assigning correct connector node for a connector entry
straightforward (it's one-on-one mapping).
Changes in v2 (Hans de goede):
- Take a reference on the fwnode which we assign to the connector,
for ACPI nodes this is a no-op but in the future we may see
software-fwnodes assigned to connectors which are ref-counted.
Signed-off-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/i915/display/intel_acpi.c| 46
drivers/gpu/drm/i915/display/intel_acpi.h| 3 ++
drivers/gpu/drm/i915/display/intel_display.c | 1 +
3 files changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
b/drivers/gpu/drm/i915/display/intel_acpi.c
index 833d0c1be4f1..37077b19cf58 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.c
+++ b/drivers/gpu/drm/i915/display/intel_acpi.c
@@ -263,3 +263,49 @@ void intel_acpi_device_id_update(struct drm_i915_private
*dev_priv)
}
drm_connector_list_iter_end(_iter);
}
+
+/* NOTE: The connector order must be final before this is called. */
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915)
+{
+ struct drm_connector_list_iter conn_iter;
+ struct drm_device *drm_dev = >drm;
+ struct fwnode_handle *fwnode = NULL;
+ struct drm_connector *connector;
+ struct acpi_device *adev;
+
+ drm_connector_list_iter_begin(drm_dev, _iter);
+ drm_for_each_connector_iter(connector, _iter) {
+ /* Always getting the next, even when the last was not used. */
+ fwnode = device_get_next_child_node(drm_dev->dev, fwnode);
+ if (!fwnode)
+ break;
+
+ switch (connector->connector_type) {
+ case DRM_MODE_CONNECTOR_LVDS:
+ case DRM_MODE_CONNECTOR_eDP:
+ case DRM_MODE_CONNECTOR_DSI:
+ /*
+* Integrated displays have a specific address 0x1f on
+* most Intel platforms, but not on all of them.
+*/
+ adev =
acpi_find_child_device(ACPI_COMPANION(drm_dev->dev),
+ 0x1f, 0);
+ if (adev) {
+ connector->fwnode =
+
fwnode_handle_get(acpi_fwnode_handle(adev));
+ break;
+ }
+ fallthrough;
+ default:
+ connector->fwnode = fwnode_handle_get(fwnode);
+ break;
+ }
+ }
+ drm_connector_list_iter_end(_iter);
+ /*
+* device_get_next_child_node() takes a reference on the fwnode, if
+* we stopped iterating because we are out of connectors we need to
+* put this, otherwise fwnode is NULL and the put is a no-op.
+*/
+ fwnode_handle_put(fwnode);
+}
diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
b/drivers/gpu/drm/i915/display/intel_acpi.h
index e8b068661d22..d2435691f4b5 100644
--- a/drivers/gpu/drm/i915/display/intel_acpi.h
+++ b/drivers/gpu/drm/i915/display/intel_acpi.h
@@ -12,11 +12,14 @@ struct drm_i915_private;
void intel_register_dsm_handler(void);
void intel_unregister_dsm_handler(void);
void intel_acpi_device_id_update(struct drm_i915_private *i915);
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915);
#else
static inline void intel_register_dsm_handler(void) { return; }
static inline void intel_unregister_dsm_handler(void) { return; }
static inline
void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
+static inline
+void intel_acpi_assign_connector_fwnodes(struct drm_i915_private *i915) {
return; }
#endif /* CONFIG_ACPI */
#endif /* __INTEL_ACPI_H__ */
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index caf0414e0b50..4133f657f6a0 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12381,6 +12381,7 @@ int intel_modeset_init_nogem(struct drm_i915_private
*i915)
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev, dev->mode_config.acquire_ctx);
+ intel_acpi_assign_connector_fwnodes(i915);
[Intel-gfx] [PATCH 4/8] drm/connector: Add support for out-of-band hotplug notification (v3)
Add a new drm_connector_oob_hotplug_event() function and
oob_hotplug_event drm_connector_funcs member.
On some hardware a hotplug event notification may come from outside the
display driver / device. An example of this is some USB Type-C setups
where the hardware muxes the DisplayPort data and aux-lines but does
not pass the altmode HPD status bit to the GPU's DP HPD pin.
In cases like this the new drm_connector_oob_hotplug_event() function can
be used to report these out-of-band events.
Changes in v2:
- Make drm_connector_oob_hotplug_event() take a fwnode as argument and
have it call drm_connector_find_by_fwnode() internally. This allows
making drm_connector_find_by_fwnode() a drm-internal function and
avoids code outside the drm subsystem potentially holding on the
a drm_connector reference for a longer period.
Changes in v3:
- Drop the data argument to the drm_connector_oob_hotplug_event
function since it is not used atm. This can be re-added later when
a use for it actually arises.
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 27 +++
include/drm/drm_connector.h | 9 +
2 files changed, 36 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 14644053a678..88ff7a011002 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -2592,6 +2592,33 @@ struct drm_connector
*drm_connector_find_by_fwnode(struct fwnode_handle *fwnode)
return found;
}
+/**
+ * drm_connector_oob_hotplug_event - Report out-of-band hotplug event to
connector
+ * @connector: connector to report the event on
+ *
+ * On some hardware a hotplug event notification may come from outside the
display
+ * driver / device. An example of this is some USB Type-C setups where the
hardware
+ * muxes the DisplayPort data and aux-lines but does not pass the altmode HPD
+ * status bit to the GPU's DP HPD pin.
+ *
+ * This function can be used to report these out-of-band events after obtaining
+ * a drm_connector reference through calling drm_connector_find_by_fwnode().
+ */
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode)
+{
+ struct drm_connector *connector;
+
+ connector = drm_connector_find_by_fwnode(connector_fwnode);
+ if (IS_ERR(connector))
+ return;
+
+ if (connector->funcs->oob_hotplug_event)
+ connector->funcs->oob_hotplug_event(connector);
+
+ drm_connector_put(connector);
+}
+EXPORT_SYMBOL(drm_connector_oob_hotplug_event);
+
/**
* DOC: Tile group
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index b4b08c7a538e..1d896a8e3fa7 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1079,6 +1079,14 @@ struct drm_connector_funcs {
*/
void (*atomic_print_state)(struct drm_printer *p,
const struct drm_connector_state *state);
+
+ /**
+* @oob_hotplug_event:
+*
+* This will get called when a hotplug-event for a drm-connector
+* has been received from a source outside the display driver / device.
+*/
+ void (*oob_hotplug_event)(struct drm_connector *connector);
};
/**
@@ -1661,6 +1669,7 @@ drm_connector_is_unregistered(struct drm_connector
*connector)
DRM_CONNECTOR_UNREGISTERED;
}
+void drm_connector_oob_hotplug_event(struct fwnode_handle *connector_fwnode);
const char *drm_get_connector_type_name(unsigned int connector_type);
const char *drm_get_connector_status_name(enum drm_connector_status status);
const char *drm_get_subpixel_order_name(enum subpixel_order order);
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/8] drm/connector: Add drm_connector_find_by_fwnode() function (v3)
Add a function to find a connector based on a fwnode.
This will be used by the new drm_connector_oob_hotplug_event()
function which is added by the next patch in this patch-set.
Changes in v2:
- Complete rewrite to use a global connector list in drm_connector.c
rather then using a class-dev-iter in drm_sysfs.c
Changes in v3:
- Add forward declaration for struct fwnode_handle to drm_crtc_internal.h
(fixes warning reported by kernel test robot )
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 50 +
drivers/gpu/drm/drm_crtc_internal.h | 2 ++
include/drm/drm_connector.h | 8 +
3 files changed, 60 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index eb3bd362c23f..14644053a678 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -65,6 +65,14 @@
* support can instead use e.g. drm_helper_hpd_irq_event().
*/
+/*
+ * Global connector list for drm_connector_find_by_fwnode().
+ * Note drm_connector_[un]register() first take connector->lock and then
+ * take the connector_list_lock.
+ */
+static DEFINE_MUTEX(connector_list_lock);
+static LIST_HEAD(connector_list);
+
struct drm_conn_prop_enum_list {
int type;
const char *name;
@@ -267,6 +275,7 @@ int drm_connector_init(struct drm_device *dev,
goto out_put_type_id;
}
+ INIT_LIST_HEAD(>global_connector_list_entry);
INIT_LIST_HEAD(>probed_modes);
INIT_LIST_HEAD(>modes);
mutex_init(>mutex);
@@ -534,6 +543,9 @@ int drm_connector_register(struct drm_connector *connector)
/* Let userspace know we have a new connector */
drm_sysfs_hotplug_event(connector->dev);
+ mutex_lock(_list_lock);
+ list_add_tail(>global_connector_list_entry, _list);
+ mutex_unlock(_list_lock);
goto unlock;
err_debugfs:
@@ -562,6 +574,10 @@ void drm_connector_unregister(struct drm_connector
*connector)
return;
}
+ mutex_lock(_list_lock);
+ list_del_init(>global_connector_list_entry);
+ mutex_unlock(_list_lock);
+
if (connector->funcs->early_unregister)
connector->funcs->early_unregister(connector);
@@ -2542,6 +2558,40 @@ int drm_mode_getconnector(struct drm_device *dev, void
*data,
return ret;
}
+/**
+ * drm_connector_find_by_fwnode - Find a connector based on the associated
fwnode
+ * @fwnode: fwnode for which to find the matching drm_connector
+ *
+ * This functions looks up a drm_connector based on its associated fwnode. When
+ * a connector is found a reference to the connector is returned. The caller
must
+ * call drm_connector_put() to release this reference when it is done with the
+ * connector.
+ *
+ * Returns: A reference to the found connector or an ERR_PTR().
+ */
+struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle
*fwnode)
+{
+ struct drm_connector *connector, *found = ERR_PTR(-ENODEV);
+
+ if (!fwnode)
+ return ERR_PTR(-ENODEV);
+
+ mutex_lock(_list_lock);
+
+ list_for_each_entry(connector, _list,
global_connector_list_entry) {
+ if (connector->fwnode == fwnode ||
+ (connector->fwnode && connector->fwnode->secondary ==
fwnode)) {
+ drm_connector_get(connector);
+ found = connector;
+ break;
+ }
+ }
+
+ mutex_unlock(_list_lock);
+
+ return found;
+}
+
/**
* DOC: Tile group
diff --git a/drivers/gpu/drm/drm_crtc_internal.h
b/drivers/gpu/drm/drm_crtc_internal.h
index 54d4cf1233e9..1e676a41d58b 100644
--- a/drivers/gpu/drm/drm_crtc_internal.h
+++ b/drivers/gpu/drm/drm_crtc_internal.h
@@ -57,6 +57,7 @@ struct drm_property;
struct edid;
struct kref;
struct work_struct;
+struct fwnode_handle;
/* drm_crtc.c */
int drm_mode_crtc_set_obj_prop(struct drm_mode_object *obj,
@@ -185,6 +186,7 @@ int drm_connector_set_obj_prop(struct drm_mode_object *obj,
int drm_connector_create_standard_properties(struct drm_device *dev);
const char *drm_get_connector_force_name(enum drm_connector_force force);
void drm_connector_free_work_fn(struct work_struct *work);
+struct drm_connector *drm_connector_find_by_fwnode(struct fwnode_handle
*fwnode);
/* IOCTL */
int drm_connector_property_set_ioctl(struct drm_device *dev,
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 56aae0d5e2f8..b4b08c7a538e 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1242,6 +1242,14 @@ struct drm_connector {
*/
struct list_head head;
+ /**
+* @global_connector_list_entry:
+*
+* Connector entry in the global connector-list, used by
+* drm_connector_find_by_fwnode().
+*/
+ struct list_head global_connector_list_entry;
+
[Intel-gfx] [PATCH 2/8] drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2)
Add a fwnode pointer to struct drm_connector and register an acpi_bus_type
for the connectors with the ACPI subsystem (when CONFIG_ACPI is enabled).
The adding of the fwnode pointer allows drivers to associate a fwnode
that represents a connector with that connector.
When the new fwnode pointer points to an ACPI-companion, then the new
acpi_bus_type will cause the ACPI subsys to bind the device instantiated
for the connector with the fwnode by calling acpi_bind_one(). This will
result in a firmware_node symlink under /sys/class/card#-/
which helps to verify that the fwnode-s and connectors are properly
matched.
Changes in v2:
- Make drm_connector_cleanup() call fwnode_handle_put() on
connector->fwnode and document this
Co-developed-by: Heikki Krogerus
Signed-off-by: Heikki Krogerus
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_connector.c | 2 ++
drivers/gpu/drm/drm_sysfs.c | 37 +
include/drm/drm_connector.h | 8 +++
3 files changed, 47 insertions(+)
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index da39e7ff6965..eb3bd362c23f 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -474,6 +474,8 @@ void drm_connector_cleanup(struct drm_connector *connector)
drm_mode_object_unregister(dev, >base);
kfree(connector->name);
connector->name = NULL;
+ fwnode_handle_put(connector->fwnode);
+ connector->fwnode = NULL;
spin_lock_irq(>mode_config.connector_list_lock);
list_del(>head);
dev->mode_config.num_connector--;
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index f9d92bbb1f98..bf9edce8e2d1 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -10,6 +10,7 @@
* Copyright (c) 2003-2004 IBM Corp.
*/
+#include
#include
#include
#include
@@ -56,6 +57,39 @@ static struct device_type drm_sysfs_device_connector = {
struct class *drm_class;
+#ifdef CONFIG_ACPI
+static bool drm_connector_acpi_bus_match(struct device *dev)
+{
+ return dev->type == _sysfs_device_connector;
+}
+
+static struct acpi_device *drm_connector_acpi_find_companion(struct device
*dev)
+{
+ struct drm_connector *connector = to_drm_connector(dev);
+
+ return to_acpi_device_node(connector->fwnode);
+}
+
+static struct acpi_bus_type drm_connector_acpi_bus = {
+ .name = "drm_connector",
+ .match = drm_connector_acpi_bus_match,
+ .find_companion = drm_connector_acpi_find_companion,
+};
+
+static void drm_sysfs_acpi_register(void)
+{
+ register_acpi_bus_type(_connector_acpi_bus);
+}
+
+static void drm_sysfs_acpi_unregister(void)
+{
+ unregister_acpi_bus_type(_connector_acpi_bus);
+}
+#else
+static void drm_sysfs_acpi_register(void) { }
+static void drm_sysfs_acpi_unregister(void) { }
+#endif
+
static char *drm_devnode(struct device *dev, umode_t *mode)
{
return kasprintf(GFP_KERNEL, "dri/%s", dev_name(dev));
@@ -89,6 +123,8 @@ int drm_sysfs_init(void)
}
drm_class->devnode = drm_devnode;
+
+ drm_sysfs_acpi_register();
return 0;
}
@@ -101,6 +137,7 @@ void drm_sysfs_destroy(void)
{
if (IS_ERR_OR_NULL(drm_class))
return;
+ drm_sysfs_acpi_unregister();
class_remove_file(drm_class, _attr_version.attr);
class_destroy(drm_class);
drm_class = NULL;
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 714d1a01c065..56aae0d5e2f8 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -1223,6 +1223,14 @@ struct drm_connector {
struct device *kdev;
/** @attr: sysfs attributes */
struct device_attribute *attr;
+ /**
+* @fwnode: associated fwnode supplied by platform firmware
+*
+* Drivers can set this to associate a fwnode with a connector, drivers
+* are expected to get a reference on the fwnode when setting this.
+* drm_connector_cleanup() will call fwnode_handle_put() on this.
+*/
+ struct fwnode_handle *fwnode;
/**
* @head:
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/8] drm/connector: Give connector sysfs devices there own device_type
Give connector sysfs devices there own device_type, this allows us to
check if a device passed to functions dealing with generic devices is
a drm_connector or not.
A check like this is necessary in the drm_connector_acpi_bus_match()
function added in the next patch in this series.
Tested-by: Heikki Krogerus
Signed-off-by: Hans de Goede
---
drivers/gpu/drm/drm_sysfs.c | 50 +++--
1 file changed, 37 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c
index 968a9560b4aa..f9d92bbb1f98 100644
--- a/drivers/gpu/drm/drm_sysfs.c
+++ b/drivers/gpu/drm/drm_sysfs.c
@@ -50,6 +50,10 @@ static struct device_type drm_sysfs_device_minor = {
.name = "drm_minor"
};
+static struct device_type drm_sysfs_device_connector = {
+ .name = "drm_connector",
+};
+
struct class *drm_class;
static char *drm_devnode(struct device *dev, umode_t *mode)
@@ -102,6 +106,11 @@ void drm_sysfs_destroy(void)
drm_class = NULL;
}
+static void drm_sysfs_release(struct device *dev)
+{
+ kfree(dev);
+}
+
/*
* Connector properties
*/
@@ -273,27 +282,47 @@ static const struct attribute_group
*connector_dev_groups[] = {
int drm_sysfs_connector_add(struct drm_connector *connector)
{
struct drm_device *dev = connector->dev;
+ struct device *kdev;
+ int r;
if (connector->kdev)
return 0;
- connector->kdev =
- device_create_with_groups(drm_class, dev->primary->kdev, 0,
- connector, connector_dev_groups,
- "card%d-%s", dev->primary->index,
- connector->name);
+ kdev = kzalloc(sizeof(*kdev), GFP_KERNEL);
+ if (!kdev)
+ return -ENOMEM;
+
+ device_initialize(kdev);
+ kdev->class = drm_class;
+ kdev->type = _sysfs_device_connector;
+ kdev->parent = dev->primary->kdev;
+ kdev->groups = connector_dev_groups;
+ kdev->release = drm_sysfs_release;
+ dev_set_drvdata(kdev, connector);
+
+ r = dev_set_name(kdev, "card%d-%s", dev->primary->index,
connector->name);
+ if (r)
+ goto err_free;
+
DRM_DEBUG("adding \"%s\" to sysfs\n",
connector->name);
- if (IS_ERR(connector->kdev)) {
- DRM_ERROR("failed to register connector device: %ld\n",
PTR_ERR(connector->kdev));
- return PTR_ERR(connector->kdev);
+ r = device_add(kdev);
+ if (r) {
+ DRM_ERROR("failed to register connector device: %d\n", r);
+ goto err_free;
}
+ connector->kdev = kdev;
+
if (connector->ddc)
return sysfs_create_link(>kdev->kobj,
>ddc->dev.kobj, "ddc");
return 0;
+
+err_free:
+ put_device(kdev);
+ return r;
}
void drm_sysfs_connector_remove(struct drm_connector *connector)
@@ -374,11 +403,6 @@ void drm_sysfs_connector_status_event(struct drm_connector
*connector,
}
EXPORT_SYMBOL(drm_sysfs_connector_status_event);
-static void drm_sysfs_release(struct device *dev)
-{
- kfree(dev);
-}
-
struct device *drm_sysfs_minor_alloc(struct drm_minor *minor)
{
const char *minor_str;
--
2.31.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/8] drm + usb-type-c: Add support for out-of-band hotplug notification (v4)
Here is v3 of my patchset making DP over Type-C work on devices where the Type-C controller does not drive the HPD pin on the GPU, but instead we need to forward HPD events from the Type-C controller to the DRM driver. Changes in v4: - Rebase on top of latest drm-tip - Add forward declaration for struct fwnode_handle to drm_crtc_internal.h (fixes warning reported by kernel test robot ) - Add Heikki's Reviewed-by to patch 7 & 8 - Add Heikki's Tested-by to the series Changes in v3: - Base on top of latest drm-tip, which should fix the CI being unable to apply (and thus to test) the patches - Make intel_acpi_assign_connector_fwnodes() take a ref on the fwnode it stores in connector->fwnode and have drm_connector_cleanup() put this reference - Drop data argument from drm_connector_oob_hotplug_event() - Make the Type-C DP altmode code only call drm_connector_oob_hotplug_event() when the HPD bit in the status vdo changes - Drop the platform/x86/intel_cht_int33fe: Correct "displayport" fwnode reference patch, this will be merged independently through the pdx86 tree Changes in v2: - Replace the bogus "drm/connector: Make the drm_sysfs connector->kdev device hold a reference to the connector" patch with: "drm/connector: Give connector sysfs devices there own device_type" the new patch is a dep for patch 2/9 see the patches - Stop using a class-dev-iter, instead at a global connector list to drm_connector.c and use that to find the connector by the fwnode, similar to how we already do this in drm_panel.c and drm_bridge.c - Make drm_connector_oob_hotplug_event() take a fwnode pointer as argument, rather then a drm_connector pointer and let it do the lookup itself. This allows making drm_connector_find_by_fwnode() a drm-internal function and avoids code outside the drm subsystem potentially holding on the a drm_connector reference for a longer period. This series not only touches drm subsys files but it also touches drivers/usb/typec/altmodes/typec_displayport.c, that file usually does not see a whole lot of changes. So I believe it would be best to just merge the entire series through drm-misc, Assuming we can get an ack from Greg for merging the typec_displayport.c changes this way. Regards, Hans Hans de Goede (7): drm/connector: Give connector sysfs devices there own device_type drm/connector: Add a fwnode pointer to drm_connector and register with ACPI (v2) drm/connector: Add drm_connector_find_by_fwnode() function (v3) drm/connector: Add support for out-of-band hotplug notification (v3) drm/i915/dp: Add support for out-of-bound hotplug events usb: typec: altmodes/displayport: Make dp_altmode_notify() more generic usb: typec: altmodes/displayport: Notify drm subsys of hotplug events Heikki Krogerus (1): drm/i915: Associate ACPI connector nodes with connector entries (v2) drivers/gpu/drm/drm_connector.c | 79 ++ drivers/gpu/drm/drm_crtc_internal.h | 2 + drivers/gpu/drm/drm_sysfs.c | 87 +--- drivers/gpu/drm/i915/display/intel_acpi.c| 46 +++ drivers/gpu/drm/i915/display/intel_acpi.h| 3 + drivers/gpu/drm/i915/display/intel_display.c | 1 + drivers/gpu/drm/i915/display/intel_dp.c | 12 +++ drivers/usb/typec/altmodes/Kconfig | 1 + drivers/usb/typec/altmodes/displayport.c | 58 - include/drm/drm_connector.h | 25 ++ 10 files changed, 279 insertions(+), 35 deletions(-) -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] [RFC PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler
On Sat, 5 Jun 2021 at 03:39, Daniel Vetter wrote: > > On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote: > > Add entry for i915 GuC submission / DRM scheduler integration plan. > > Follow up patch with details of new parallel submission uAPI to come. > > > > v2: > > (Daniel Vetter) > > - Expand explaination of why bonding isn't supported for GuC > > submission > > - CC some of the DRM scheduler maintainers > > - Add priority inheritance / boosting use case > > - Add reasoning for removing in order assumptions > > (Daniel Stone) > > - Add links to priority spec > > > > Cc: Christian König > > Cc: Luben Tuikov > > Cc: Alex Deucher > > Cc: Steven Price > > Cc: Jon Bloomfield > > Cc: Jason Ekstrand > > Cc: Dave Airlie > > Cc: Daniel Vetter > > Cc: Jason Ekstrand > > Cc: dri-de...@lists.freedesktop.org > > Signed-off-by: Matthew Brost > > You have a one-line hunk in the next patch that probably should be here. > With that moved. > > Reviewed-by: Daniel Vetter Acked-by: Dave Airlie And yes having the todos for GuC tracked would be good externally, so pressure can be applied for new fw releases with those features. Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Pipe DMC Support (rev5)
== Series Details == Series: Pipe DMC Support (rev5) URL : https://patchwork.freedesktop.org/series/90445/ State : success == Summary == CI Bug Log - changes from CI_DRM_10171 -> Patchwork_20286 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/index.html Known issues Here are the changes found in Patchwork_20286 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_gttfill@basic: - fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html * igt@gem_exec_suspend@basic-s3: - fi-bsw-n3050: NOTRUN -> [INCOMPLETE][2] ([i915#3159]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html * igt@gem_huc_copy@huc-copy: - fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html * igt@i915_selftest@live@execlists: - fi-bxt-dsi: NOTRUN -> [DMESG-FAIL][4] ([i915#3462]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html * igt@kms_chamelium@common-hpd-after-suspend: - fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html * igt@kms_force_connector_basic@force-load-detect: - fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +10 similar issues [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html * igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d: - fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html Possible fixes * igt@kms_chamelium@hdmi-hpd-fast: - fi-icl-u2: [DMESG-WARN][8] ([i915#2868]) -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html Warnings * igt@i915_selftest@live@execlists: - fi-cml-s: [DMESG-FAIL][10] ([i915#3462]) -> [INCOMPLETE][11] ([i915#3462]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-cml-s/igt@i915_selftest@l...@execlists.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-cml-s/igt@i915_selftest@l...@execlists.html * igt@runner@aborted: - fi-kbl-x1275: [FAIL][12] ([i915#1436] / [i915#3363]) -> [FAIL][13] ([i915#1436] / [i915#2426] / [i915#3363]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-kbl-x1275/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-kbl-x1275/igt@run...@aborted.html - fi-glk-dsi: [FAIL][14] ([i915#2426] / [i915#3363] / [k.org#202321]) -> [FAIL][15] ([i915#3363] / [k.org#202321]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-glk-dsi/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-glk-dsi/igt@run...@aborted.html - fi-kbl-r: [FAIL][16] ([i915#1436] / [i915#3363]) -> [FAIL][17] ([i915#1436] / [i915#2426] / [i915#3363]) [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-kbl-r/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-kbl-r/igt@run...@aborted.html - fi-kbl-7500u: [FAIL][18] ([i915#1436] / [i915#3363]) -> [FAIL][19] ([i915#1436] / [i915#2426] / [i915#3363]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-kbl-7500u/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-kbl-7500u/igt@run...@aborted.html - fi-cml-u2: [FAIL][20] ([i915#3363] / [i915#3462]) -> [FAIL][21] ([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462]) [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-cml-u2/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-cml-u2/igt@run...@aborted.html - fi-bxt-dsi: [FAIL][22] ([i915#2426] / [i915#3363]) -> [FAIL][23] ([i915#3363]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-bxt-dsi/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20286/fi-bxt-dsi/igt@run...@aborted.html - fi-cml-s: [FAIL][24] ([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462]) ->
Re: [Intel-gfx] [PATCH 8/9] drm/i915: Move submission tasklet to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> The submission tasklet operates on i915_sched_engine, thus it is the
> correct place for it.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h| 14 ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12 +--
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 5 --
> .../drm/i915/gt/intel_execlists_submission.c | 86 ++-
> drivers/gpu/drm/i915/gt/mock_engine.c | 1 +
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 16 ++--
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 2 +-
> drivers/gpu/drm/i915/gt/selftest_lrc.c| 6 +-
> drivers/gpu/drm/i915/gt/selftest_reset.c | 2 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 25 +++---
> drivers/gpu/drm/i915/i915_scheduler.c | 1 +
> drivers/gpu/drm/i915/i915_scheduler.h | 14 +++
> drivers/gpu/drm/i915/i915_scheduler_types.h | 8 ++
> 13 files changed, 99 insertions(+), 93 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index a8b2174b4395..988d9688ae4d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -123,20 +123,6 @@ execlists_active(const struct intel_engine_execlists
> *execlists)
> return active;
> }
>
> -static inline void
> -execlists_active_lock_bh(struct intel_engine_execlists *execlists)
> -{
> - local_bh_disable(); /* prevent local softirq and lock recursion */
> - tasklet_lock(>tasklet);
> -}
> -
> -static inline void
> -execlists_active_unlock_bh(struct intel_engine_execlists *execlists)
> -{
> - tasklet_unlock(>tasklet);
> - local_bh_enable(); /* restore softirq, and kick ksoftirqd! */
> -}
> -
> struct i915_request *
> execlists_unwind_incomplete_requests(struct intel_engine_execlists
> *execlists);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index b480fcb1aad1..837d2132e31b 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -711,6 +711,7 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> err = -ENOMEM;
> goto err_sched_engine;
> }
> + engine->sched_engine->engine = engine;
This bothers me. If we're trying to separate things, why do we have a
back pointer? Yes, I know it's because we need to access our engine
back-end somehow. Makes me wonder if it should be some sort of a
void* private data pointer instead of the engine. That's probably
less safe but it seems more "right" in some sense? I don't know.
Also, dumb question but what's a tasklet?
--Jason
>
> err = intel_engine_init_cmd_parser(engine);
> if (err)
> @@ -935,7 +936,6 @@ int intel_engines_init(struct intel_gt *gt)
> void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> {
> GEM_BUG_ON(!list_empty(>sched_engine->requests));
> - tasklet_kill(>execlists.tasklet); /* flush the callback */
>
> i915_sched_engine_put(engine->sched_engine);
> intel_breadcrumbs_free(engine->breadcrumbs);
> @@ -1221,7 +1221,7 @@ static bool ring_is_idle(struct intel_engine_cs *engine)
>
> void __intel_engine_flush_submission(struct intel_engine_cs *engine, bool
> sync)
> {
> - struct tasklet_struct *t = >execlists.tasklet;
> + struct tasklet_struct *t = >sched_engine->tasklet;
>
> if (!t->callback)
> return;
> @@ -1482,8 +1482,8 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
>
> drm_printf(m, "\tExeclist tasklet queued? %s (%s), preempt?
> %s, timeslice? %s\n",
>yesno(test_bit(TASKLET_STATE_SCHED,
> - >execlists.tasklet.state)),
> -
> enableddisabled(!atomic_read(>execlists.tasklet.count)),
> +
> >sched_engine->tasklet.state)),
> +
> enableddisabled(!atomic_read(>sched_engine->tasklet.count)),
>repr_timer(>execlists.preempt),
>repr_timer(>execlists.timer));
>
> @@ -1507,7 +1507,7 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
>idx, hws[idx * 2], hws[idx * 2 + 1]);
> }
>
> - execlists_active_lock_bh(execlists);
> + i915_sched_engine_active_lock_bh(engine->sched_engine);
> rcu_read_lock();
> for (port = execlists->active; (rq = *port); port++) {
> char hdr[160];
> @@ -1538,7 +1538,7 @@ static void intel_engine_print_registers(struct
> intel_engine_cs *engine,
> i915_request_show(m, rq, hdr, 0);
> }
> rcu_read_unlock();
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Add kick_backend function to i915_sched_engine
On Fri, Jun 04, 2021 at 02:09:46PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Rather than touching execlist specific structures in the generic
> > scheduling code, add a callback function in the backend.
>
> Seems reasonable but why does the function that's there today do
> nothing for the ringbuffer and current GuC back-ends? I'm sure
> there's some reason but it's not immediately obvious to me.
>
This code isn't used for ringbuffer submission and the current GuC
back-end is non-functional. The upcoming backend doesn't use these
structures nor does it is need to be kicked as it is always running if
requests are in the queue. So for the upcoming backend this function is
NULL.
Matt
> --Jason
>
>
> > Signed-off-by: Matthew Brost
> > ---
> > .../drm/i915/gt/intel_execlists_submission.c | 52
> > drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 4 ++
> > 3 files changed, 58 insertions(+), 60 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 23fd03815ad0..3fac17103837 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -3116,10 +3116,61 @@ static bool can_preempt(struct intel_engine_cs
> > *engine)
> > return engine->class != RENDER_CLASS;
> > }
> >
> > +static void kick_execlists(const struct i915_request *rq, int prio)
> > +{
> > + struct intel_engine_cs *engine = rq->engine;
> > + struct i915_sched_engine *sched_engine = engine->sched_engine;
> > + const struct i915_request *inflight;
> > +
> > + /*
> > +* We only need to kick the tasklet once for the high priority
> > +* new context we add into the queue.
> > +*/
> > + if (prio <= sched_engine->queue_priority_hint)
> > + return;
> > +
> > + rcu_read_lock();
> > +
> > + /* Nothing currently active? We're overdue for a submission! */
> > + inflight = execlists_active(>execlists);
> > + if (!inflight)
> > + goto unlock;
> > +
> > + /*
> > +* If we are already the currently executing context, don't
> > +* bother evaluating if we should preempt ourselves.
> > +*/
> > + if (inflight->context == rq->context)
> > + goto unlock;
> > +
> > + ENGINE_TRACE(engine,
> > +"bumping queue-priority-hint:%d for rq:%llx:%lld,
> > inflight:%llx:%lld prio %d\n",
> > +prio,
> > +rq->fence.context, rq->fence.seqno,
> > +inflight->fence.context, inflight->fence.seqno,
> > +inflight->sched.attr.priority);
> > +
> > + sched_engine->queue_priority_hint = prio;
> > +
> > + /*
> > +* Allow preemption of low -> normal -> high, but we do
> > +* not allow low priority tasks to preempt other low priority
> > +* tasks under the impression that latency for low priority
> > +* tasks does not matter (as much as background throughput),
> > +* so kiss.
> > +*/
> > + if (prio >= max(I915_PRIORITY_NORMAL, rq_prio(inflight)))
> > + tasklet_hi_schedule(>execlists.tasklet);
> > +
> > +unlock:
> > + rcu_read_unlock();
> > +}
> > +
> > static void execlists_set_default_submission(struct intel_engine_cs
> > *engine)
> > {
> > engine->submit_request = execlists_submit_request;
> > engine->sched_engine->schedule = i915_schedule;
> > + engine->sched_engine->kick_backend = kick_execlists;
> > engine->execlists.tasklet.callback = execlists_submission_tasklet;
> > }
> >
> > @@ -3702,6 +3753,7 @@ intel_execlists_create_virtual(struct intel_engine_cs
> > **siblings,
> > ve->base.request_alloc = execlists_request_alloc;
> >
> > ve->base.sched_engine->schedule = i915_schedule;
> > + ve->base.sched_engine->kick_backend = kick_execlists;
> > ve->base.submit_request = virtual_submit_request;
> > ve->base.bond_execute = virtual_bond_execute;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 4bc6969f6a97..035b88f2e4aa 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -157,65 +157,6 @@ sched_lock_engine(const struct i915_sched_node *node,
> > return locked;
> > }
> >
> > -static inline int rq_prio(const struct i915_request *rq)
> > -{
> > - return rq->sched.attr.priority;
> > -}
> > -
> > -static inline bool need_preempt(int prio, int active)
> > -{
> > - /*
> > -* Allow preemption of low -> normal -> high, but we do
> > -* not allow low priority tasks to preempt other low priority
> > -*
Re: [Intel-gfx] [PATCH 01/21] drm: Add Enhanced Gamma and color lut range attributes
On 2021-06-02 4:26 p.m., Shankar, Uma wrote:
>
>
>> -Original Message-
>> From: Pekka Paalanen
>> Sent: Wednesday, June 2, 2021 3:04 PM
>> To: Shankar, Uma
>> Cc: intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org; Modem,
>> Bhanuprakash
>> Subject: Re: [PATCH 01/21] drm: Add Enhanced Gamma and color lut range
>> attributes
>>
>> On Tue, 1 Jun 2021 16:21:58 +0530
>> Uma Shankar wrote:
>>
>>> Existing LUT precision structure is having only 16 bit precision. This
>>> is not enough for upcoming enhanced hardwares and advance usecases
>>> like HDR processing. Hence added a new structure with 32 bit precision
>>> values.
>>>
>>> This also defines a new structure to define color lut ranges, along
>>> with related macro definitions and enums. This will help describe
>>> multi segmented lut ranges in the hardware.
>>>
>>> Signed-off-by: Uma Shankar
>>> ---
>>> include/uapi/drm/drm_mode.h | 58
>>> +
>>> 1 file changed, 58 insertions(+)
>>>
>>> diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>>> index 9b6722d45f36..d0ce48d2e732 100644
>>> --- a/include/uapi/drm/drm_mode.h
>>> +++ b/include/uapi/drm/drm_mode.h
>>> @@ -819,6 +819,64 @@ struct hdr_output_metadata {
>>> };
>>> };
>>>
>>> +/*
>>> + * DRM_MODE_LUT_GAMMA|DRM_MODE_LUT_DEGAMMA is legal and means
>> the LUT
>>> + * can be used for either purpose, but not simultaneously. To expose
>>> + * modes that support gamma and degamma simultaneously the gamma mode
>>> + * must declare distinct DRM_MODE_LUT_GAMMA and
>> DRM_MODE_LUT_DEGAMMA
>>> + * ranges.
>>> + */
>>> +/* LUT is for gamma (after CTM) */
>>> +#define DRM_MODE_LUT_GAMMA BIT(0)
>>> +/* LUT is for degamma (before CTM) */ #define DRM_MODE_LUT_DEGAMMA
>>> +BIT(1)
>>> +/* linearly interpolate between the points */ #define
>>> +DRM_MODE_LUT_INTERPOLATE BIT(2)
>>> +/*
>>> + * the last value of the previous range is the
>>> + * first value of the current range.
>>> + */
>>> +#define DRM_MODE_LUT_REUSE_LAST BIT(3)
>>> +/* the curve must be non-decreasing */ #define
>>> +DRM_MODE_LUT_NON_DECREASING BIT(4)
>>> +/* the curve is reflected across origin for negative inputs */
>>> +#define DRM_MODE_LUT_REFLECT_NEGATIVE BIT(5)
>>> +/* the same curve (red) is used for blue and green channels as well
>>> +*/ #define DRM_MODE_LUT_SINGLE_CHANNEL BIT(6)
>>> +
>>> +struct drm_color_lut_range {
>>> + /* DRM_MODE_LUT_* */
>>> + __u32 flags;
>>> + /* number of points on the curve */
>>> + __u16 count;
>>> + /* input/output bits per component */
>>> + __u8 input_bpc, output_bpc;
>>> + /* input start/end values */
>>> + __s32 start, end;
>>> + /* output min/max values */
>>> + __s32 min, max;
>>> +};
>>> +
>>> +enum lut_type {
>>
>> Unprefixed type name in UAPI headers is probably not a good idea.
>
> Ok, will rename these.
>
>>> + LUT_TYPE_DEGAMMA = 0,
>>> + LUT_TYPE_GAMMA = 1,
>>> +};
>>
>> All the above stuff seems to be the same in your other patch series'
>> patch "[PATCH 1/9] drm: Add gamma mode property". Is this series replacing
>> the
>> series "[PATCH 0/9] Enhance pipe color support for multi segmented luts" or
>> what
>> does this mean?
>
> The concept and idea is similar and the range definition is also common. But
> this series
> focuses on plane color management while the other one is for pipe/crtc color
> features.
> Hence separated and floated them as unique series for review.
>
Might be better in this case to combine both patchsets. It wasn't entirely
clear to
me whether I could base one patchset on top of the other (doesn't look like it)
and
what base to apply them on. I had success applying the plane stuff on drm-next
and
the crtc stuff on drm-intel.
Harry
> Regards,
> Uma Shankar
>>
>> Thanks,
>> pq
>>
>>> +
>>> +/*
>>> + * Creating 64 bit palette entries for better data
>>> + * precision. This will be required for HDR and
>>> + * similar color processing usecases.
>>> + */
>>> +struct drm_color_lut_ext {
>>> + /*
>>> +* Data is U32.32 fixed point format.
>>> +*/
>>> + __u64 red;
>>> + __u64 green;
>>> + __u64 blue;
>>> + __u64 reserved;
>>> +};
>>> +
>>> #define DRM_MODE_PAGE_FLIP_EVENT 0x01 #define
>>> DRM_MODE_PAGE_FLIP_ASYNC 0x02 #define
>>> DRM_MODE_PAGE_FLIP_TARGET_ABSOLUTE 0x4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/9] drm/i915: Update i915_scheduler to operate on i915_sched_engine
On Fri, Jun 04, 2021 at 02:17:58PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Rather passing around an intel_engine_cs in the scheduling code, pass
> > around a i915_sched_engine.
>
>
>
> > Signed-off-by: Matthew Brost
> > ---
> > .../drm/i915/gt/intel_execlists_submission.c | 11 +++--
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
> > drivers/gpu/drm/i915/i915_scheduler.c | 46 +--
> > drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
> > 4 files changed, 32 insertions(+), 29 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 3fac17103837..7240c153be35 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -382,7 +382,8 @@ __unwind_incomplete_requests(struct intel_engine_cs
> > *engine)
> > GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
> > if (rq_prio(rq) != prio) {
> > prio = rq_prio(rq);
> > - pl = i915_sched_lookup_priolist(engine, prio);
> > + pl =
> > i915_sched_lookup_priolist(engine->sched_engine,
> > + prio);
> > }
> >
> > GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
> >
> > @@ -1096,7 +1097,8 @@ static void defer_active(struct intel_engine_cs
> > *engine)
> > if (!rq)
> > return;
> >
> > - defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
> > + defer_request(rq, i915_sched_lookup_priolist(engine->sched_engine,
> > +rq_prio(rq)));
> > }
> >
> > static bool
> > @@ -2083,7 +2085,7 @@ static void __execlists_unhold(struct i915_request
> > *rq)
> >
> > i915_request_clear_hold(rq);
> > list_move_tail(>sched.link,
> > - i915_sched_lookup_priolist(rq->engine,
> > +
> > i915_sched_lookup_priolist(rq->engine->sched_engine,
> > rq_prio(rq)));
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> >
> > @@ -2452,7 +2454,8 @@ static void queue_request(struct intel_engine_cs
> > *engine,
> > {
> > GEM_BUG_ON(!list_empty(>sched.link));
> > list_add_tail(>sched.link,
> > - i915_sched_lookup_priolist(engine, rq_prio(rq)));
> > + i915_sched_lookup_priolist(engine->sched_engine,
> > +rq_prio(rq)));
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 4c5bbec0775d..7ed21670ef14 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -529,7 +529,7 @@ static inline void queue_request(struct intel_engine_cs
> > *engine,
> > {
> > GEM_BUG_ON(!list_empty(>sched.link));
> > list_add_tail(>sched.link,
> > - i915_sched_lookup_priolist(engine, prio));
> > + i915_sched_lookup_priolist(engine->sched_engine,
> > prio));
> > set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> > b/drivers/gpu/drm/i915/i915_scheduler.c
> > index 035b88f2e4aa..3d36e4447b5d 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.c
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> > @@ -61,14 +61,13 @@ static void assert_priolists(struct i915_sched_engine *
> > const sched_engine)
> > }
> >
> > struct list_head *
> > -i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
> > +i915_sched_lookup_priolist(struct i915_sched_engine *sched_engine, int
> > prio)
> > {
> > - struct i915_sched_engine * const sched_engine =
> > engine->sched_engine;
> > struct i915_priolist *p;
> > struct rb_node **parent, *rb;
> > bool first = true;
> >
> > - lockdep_assert_held(>sched_engine->lock);
> > + lockdep_assert_held(_engine->lock);
> > assert_priolists(sched_engine);
> >
> > if (unlikely(sched_engine->no_priolist))
> > @@ -130,13 +129,13 @@ struct sched_cache {
> > struct list_head *priolist;
> > };
> >
> > -static struct intel_engine_cs *
> > -sched_lock_engine(const struct i915_sched_node *node,
> > - struct intel_engine_cs *locked,
> > +static struct i915_sched_engine *
> > +lock_sched_engine(struct i915_sched_node *node,
> > + struct i915_sched_engine *locked,
> > struct sched_cache *cache)
> > {
> > const
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Move active tracking to i915_sched_engine
On Fri, Jun 04, 2021 at 02:00:33PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Move active request tracking and its lock to i915_sched_engine. This
> > lock is also the submission lock so having it in the i915_sched_engine
> > is the correct place.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +++-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 --
> > .../drm/i915/gt/intel_execlists_submission.c | 98 ++-
> > .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +--
> > drivers/gpu/drm/i915/gt/mock_engine.c | 7 +-
> > drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++--
> > drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
> > drivers/gpu/drm/i915/i915_request.c | 32 +++---
> > drivers/gpu/drm/i915/i915_request.h | 2 +-
> > drivers/gpu/drm/i915/i915_scheduler.c | 30 --
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 9 ++
> > 13 files changed, 134 insertions(+), 135 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> > b/drivers/gpu/drm/i915/gt/intel_engine.h
> > index 8d9184920c51..a8b2174b4395 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> > @@ -257,8 +257,6 @@ intel_engine_find_active_request(struct intel_engine_cs
> > *engine);
> >
> > u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
> >
> > -void intel_engine_init_active(struct intel_engine_cs *engine,
> > - unsigned int subclass);
> > #define ENGINE_PHYSICAL0
> > #define ENGINE_MOCK1
> > #define ENGINE_VIRTUAL 2
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 85f2effe9dc6..33d879137908 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -719,7 +719,6 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > if (err)
> > goto err_cmd_parser;
> >
> > - intel_engine_init_active(engine, ENGINE_PHYSICAL);
> > intel_engine_init_execlists(engine);
> > intel_engine_init__pm(engine);
> > intel_engine_init_retire(engine);
> > @@ -778,11 +777,11 @@ static int measure_breadcrumb_dw(struct intel_context
> > *ce)
> > frame->rq.ring = >ring;
> >
> > mutex_lock(>timeline->mutex);
> > - spin_lock_irq(>active.lock);
> > + spin_lock_irq(>sched_engine->lock);
> >
> > dw = engine->emit_fini_breadcrumb(>rq, frame->cs) -
> > frame->cs;
> >
> > - spin_unlock_irq(>active.lock);
> > + spin_unlock_irq(>sched_engine->lock);
> > mutex_unlock(>timeline->mutex);
> >
> > GEM_BUG_ON(dw & 1); /* RING_TAIL must be qword aligned */
> > @@ -791,28 +790,6 @@ static int measure_breadcrumb_dw(struct intel_context
> > *ce)
> > return dw;
> > }
> >
> > -void
> > -intel_engine_init_active(struct intel_engine_cs *engine, unsigned int
> > subclass)
> > -{
> > - INIT_LIST_HEAD(>active.requests);
> > - INIT_LIST_HEAD(>active.hold);
> > -
> > - spin_lock_init(>active.lock);
> > - lockdep_set_subclass(>active.lock, subclass);
> > -
> > - /*
> > -* Due to an interesting quirk in lockdep's internal debug tracking,
> > -* after setting a subclass we must ensure the lock is used.
> > Otherwise,
> > -* nr_unused_locks is incremented once too often.
> > -*/
> > -#ifdef CONFIG_DEBUG_LOCK_ALLOC
> > - local_irq_disable();
> > - lock_map_acquire(>active.lock.dep_map);
> > - lock_map_release(>active.lock.dep_map);
> > - local_irq_enable();
> > -#endif
> > -}
> > -
> > static struct intel_context *
> > create_pinned_context(struct intel_engine_cs *engine,
> > unsigned int hwsp,
> > @@ -960,7 +937,7 @@ int intel_engines_init(struct intel_gt *gt)
> > */
> > void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> > {
> > - GEM_BUG_ON(!list_empty(>active.requests));
> > + GEM_BUG_ON(!list_empty(>sched_engine->requests));
> > tasklet_kill(>execlists.tasklet); /* flush the callback */
> >
> > i915_sched_engine_put(engine->sched_engine);
> > @@ -1353,7 +1330,7 @@ static struct intel_timeline *get_timeline(struct
> > i915_request *rq)
> > struct intel_timeline *tl;
> >
> > /*
> > -* Even though we are holding the engine->active.lock here, there
> > +* Even though we are holding the engine->sched_engine->lock here,
> > there
> > * is no control over the submission queue per-se and we are
> > * inspecting the active state at a random point in time, with an
> > * unknown queue. Play safe
Re: [Intel-gfx] [PATCH 7/9] drm/i915: Update i915_scheduler to operate on i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Rather passing around an intel_engine_cs in the scheduling code, pass
> around a i915_sched_engine.
> Signed-off-by: Matthew Brost
> ---
> .../drm/i915/gt/intel_execlists_submission.c | 11 +++--
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 2 +-
> drivers/gpu/drm/i915/i915_scheduler.c | 46 +--
> drivers/gpu/drm/i915/i915_scheduler.h | 2 +-
> 4 files changed, 32 insertions(+), 29 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 3fac17103837..7240c153be35 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -382,7 +382,8 @@ __unwind_incomplete_requests(struct intel_engine_cs
> *engine)
> GEM_BUG_ON(rq_prio(rq) == I915_PRIORITY_INVALID);
> if (rq_prio(rq) != prio) {
> prio = rq_prio(rq);
> - pl = i915_sched_lookup_priolist(engine, prio);
> + pl = i915_sched_lookup_priolist(engine->sched_engine,
> + prio);
> }
> GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
>
> @@ -1096,7 +1097,8 @@ static void defer_active(struct intel_engine_cs *engine)
> if (!rq)
> return;
>
> - defer_request(rq, i915_sched_lookup_priolist(engine, rq_prio(rq)));
> + defer_request(rq, i915_sched_lookup_priolist(engine->sched_engine,
> +rq_prio(rq)));
> }
>
> static bool
> @@ -2083,7 +2085,7 @@ static void __execlists_unhold(struct i915_request *rq)
>
> i915_request_clear_hold(rq);
> list_move_tail(>sched.link,
> - i915_sched_lookup_priolist(rq->engine,
> +
> i915_sched_lookup_priolist(rq->engine->sched_engine,
> rq_prio(rq)));
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
>
> @@ -2452,7 +2454,8 @@ static void queue_request(struct intel_engine_cs
> *engine,
> {
> GEM_BUG_ON(!list_empty(>sched.link));
> list_add_tail(>sched.link,
> - i915_sched_lookup_priolist(engine, rq_prio(rq)));
> + i915_sched_lookup_priolist(engine->sched_engine,
> +rq_prio(rq)));
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 4c5bbec0775d..7ed21670ef14 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -529,7 +529,7 @@ static inline void queue_request(struct intel_engine_cs
> *engine,
> {
> GEM_BUG_ON(!list_empty(>sched.link));
> list_add_tail(>sched.link,
> - i915_sched_lookup_priolist(engine, prio));
> + i915_sched_lookup_priolist(engine->sched_engine, prio));
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 035b88f2e4aa..3d36e4447b5d 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -61,14 +61,13 @@ static void assert_priolists(struct i915_sched_engine *
> const sched_engine)
> }
>
> struct list_head *
> -i915_sched_lookup_priolist(struct intel_engine_cs *engine, int prio)
> +i915_sched_lookup_priolist(struct i915_sched_engine *sched_engine, int prio)
> {
> - struct i915_sched_engine * const sched_engine = engine->sched_engine;
> struct i915_priolist *p;
> struct rb_node **parent, *rb;
> bool first = true;
>
> - lockdep_assert_held(>sched_engine->lock);
> + lockdep_assert_held(_engine->lock);
> assert_priolists(sched_engine);
>
> if (unlikely(sched_engine->no_priolist))
> @@ -130,13 +129,13 @@ struct sched_cache {
> struct list_head *priolist;
> };
>
> -static struct intel_engine_cs *
> -sched_lock_engine(const struct i915_sched_node *node,
> - struct intel_engine_cs *locked,
> +static struct i915_sched_engine *
> +lock_sched_engine(struct i915_sched_node *node,
> + struct i915_sched_engine *locked,
> struct sched_cache *cache)
> {
> const struct i915_request *rq = node_to_request(node);
> - struct intel_engine_cs *engine;
> + struct i915_sched_engine *sched_engine;
>
> GEM_BUG_ON(!locked);
>
> @@ -146,14 +145,14 @@ sched_lock_engine(const struct i915_sched_node *node,
> * engine lock. The simple ploy we use is to take the lock
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for Pipe DMC Support (rev5)
== Series Details == Series: Pipe DMC Support (rev5) URL : https://patchwork.freedesktop.org/series/90445/ State : warning == Summary == $ dim sparse --fast origin/drm-tip Sparse version: v0.6.2 Fast mode used, each commit won't be checked separately. - +drivers/gpu/drm/i915/display/intel_display.c:1893:21:expected struct i915_vma *[assigned] vma +drivers/gpu/drm/i915/display/intel_display.c:1893:21:got void [noderef] __iomem *[assigned] iomem +drivers/gpu/drm/i915/display/intel_display.c:1893:21: warning: incorrect type in assignment (different address spaces) +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:27:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:32:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:49:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_engine_stats.h:56:9: warning: trying to copy expression type 31 +drivers/gpu/drm/i915/gt/intel_reset.c:1396:5: warning: context imbalance in 'intel_gt_reset_trylock' - different lock contexts for basic block +drivers/gpu/drm/i915/gt/intel_ring_submission.c:1207:24: warning: Using plain integer as NULL pointer +drivers/gpu/drm/i915/i915_perf.c:1434:15: warning: memset with byte count of 16777216 +drivers/gpu/drm/i915/i915_perf.c:1488:15: warning: memset with byte count of 16777216 +./include/asm-generic/bitops/find.h:112:45: warning: shift count is negative (-262080) +./include/asm-generic/bitops/find.h:32:31: warning: shift count is negative (-262080) +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen11_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read64' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_read8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write16' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write32' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen12_fwtable_write8' - different lock contexts for basic block +./include/linux/spinlock.h:409:9: warning: context imbalance in 'gen6_read16' - different lock contexts for basic block
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Pipe DMC Support (rev5)
== Series Details == Series: Pipe DMC Support (rev5) URL : https://patchwork.freedesktop.org/series/90445/ State : warning == Summary == $ dim checkpatch origin/drm-tip fa1bf3879c91 drm/i915/dmc: Introduce DMC_FW_MAIN 2cdba84cf8be drm/i915/xelpd: Pipe A DMC plugging -:45: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #45: FILE: drivers/gpu/drm/i915/display/intel_display_debugfs.c:587: + intel_de_read(dev_priv, DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0))); -:60: WARNING:LONG_LINE: line length of 105 exceeds 100 columns #60: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:965: + DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)), -:160: WARNING:LONG_LINE: line length of 103 exceeds 100 columns #160: FILE: drivers/gpu/drm/i915/display/intel_dmc.c:394: + drm_notice(>drm, "Invalid firmware id: %d\n", fw_info[i].dmc_id); total: 0 errors, 3 warnings, 0 checks, 275 lines checked e5635428cc51 drm/i915/adl_p: Pipe B DMC Support 7c1b64175b3c drm/i915/adl_p: Load DMC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/9] drm/i915: Add kick_backend function to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Rather than touching execlist specific structures in the generic
> scheduling code, add a callback function in the backend.
Seems reasonable but why does the function that's there today do
nothing for the ringbuffer and current GuC back-ends? I'm sure
there's some reason but it's not immediately obvious to me.
--Jason
> Signed-off-by: Matthew Brost
> ---
> .../drm/i915/gt/intel_execlists_submission.c | 52
> drivers/gpu/drm/i915/i915_scheduler.c | 62 +--
> drivers/gpu/drm/i915/i915_scheduler_types.h | 4 ++
> 3 files changed, 58 insertions(+), 60 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 23fd03815ad0..3fac17103837 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -3116,10 +3116,61 @@ static bool can_preempt(struct intel_engine_cs
> *engine)
> return engine->class != RENDER_CLASS;
> }
>
> +static void kick_execlists(const struct i915_request *rq, int prio)
> +{
> + struct intel_engine_cs *engine = rq->engine;
> + struct i915_sched_engine *sched_engine = engine->sched_engine;
> + const struct i915_request *inflight;
> +
> + /*
> +* We only need to kick the tasklet once for the high priority
> +* new context we add into the queue.
> +*/
> + if (prio <= sched_engine->queue_priority_hint)
> + return;
> +
> + rcu_read_lock();
> +
> + /* Nothing currently active? We're overdue for a submission! */
> + inflight = execlists_active(>execlists);
> + if (!inflight)
> + goto unlock;
> +
> + /*
> +* If we are already the currently executing context, don't
> +* bother evaluating if we should preempt ourselves.
> +*/
> + if (inflight->context == rq->context)
> + goto unlock;
> +
> + ENGINE_TRACE(engine,
> +"bumping queue-priority-hint:%d for rq:%llx:%lld,
> inflight:%llx:%lld prio %d\n",
> +prio,
> +rq->fence.context, rq->fence.seqno,
> +inflight->fence.context, inflight->fence.seqno,
> +inflight->sched.attr.priority);
> +
> + sched_engine->queue_priority_hint = prio;
> +
> + /*
> +* Allow preemption of low -> normal -> high, but we do
> +* not allow low priority tasks to preempt other low priority
> +* tasks under the impression that latency for low priority
> +* tasks does not matter (as much as background throughput),
> +* so kiss.
> +*/
> + if (prio >= max(I915_PRIORITY_NORMAL, rq_prio(inflight)))
> + tasklet_hi_schedule(>execlists.tasklet);
> +
> +unlock:
> + rcu_read_unlock();
> +}
> +
> static void execlists_set_default_submission(struct intel_engine_cs *engine)
> {
> engine->submit_request = execlists_submit_request;
> engine->sched_engine->schedule = i915_schedule;
> + engine->sched_engine->kick_backend = kick_execlists;
> engine->execlists.tasklet.callback = execlists_submission_tasklet;
> }
>
> @@ -3702,6 +3753,7 @@ intel_execlists_create_virtual(struct intel_engine_cs
> **siblings,
> ve->base.request_alloc = execlists_request_alloc;
>
> ve->base.sched_engine->schedule = i915_schedule;
> + ve->base.sched_engine->kick_backend = kick_execlists;
> ve->base.submit_request = virtual_submit_request;
> ve->base.bond_execute = virtual_bond_execute;
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.c
> b/drivers/gpu/drm/i915/i915_scheduler.c
> index 4bc6969f6a97..035b88f2e4aa 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.c
> +++ b/drivers/gpu/drm/i915/i915_scheduler.c
> @@ -157,65 +157,6 @@ sched_lock_engine(const struct i915_sched_node *node,
> return locked;
> }
>
> -static inline int rq_prio(const struct i915_request *rq)
> -{
> - return rq->sched.attr.priority;
> -}
> -
> -static inline bool need_preempt(int prio, int active)
> -{
> - /*
> -* Allow preemption of low -> normal -> high, but we do
> -* not allow low priority tasks to preempt other low priority
> -* tasks under the impression that latency for low priority
> -* tasks does not matter (as much as background throughput),
> -* so kiss.
> -*/
> - return prio >= max(I915_PRIORITY_NORMAL, active);
> -}
> -
> -static void kick_submission(struct intel_engine_cs *engine,
> - const struct i915_request *rq,
> - int prio)
> -{
> - const struct i915_request *inflight;
> -
> - /*
> -* We only need to kick the tasklet once for the high priority
> -* new context we add into the queue.
> -
Re: [Intel-gfx] [PATCH 5/9] drm/i915: Move engine->schedule to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> The schedule function should be in the schedule object.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gem/i915_gem_wait.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 3 ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 4 ++--
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 8
> drivers/gpu/drm/i915/gt/intel_engine_user.c | 2 +-
> .../gpu/drm/i915/gt/intel_execlists_submission.c | 4 ++--
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 16
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 4 ++--
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> drivers/gpu/drm/i915/i915_request.c | 10 +-
> drivers/gpu/drm/i915/i915_scheduler_types.h | 8
> 11 files changed, 31 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> index 4b9856d5ba14..af1fbf8e2a9a 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_wait.c
> @@ -104,8 +104,8 @@ static void fence_set_priority(struct dma_fence *fence,
> engine = rq->engine;
>
> rcu_read_lock(); /* RCU serialisation for set-wedged protection */
> - if (engine->schedule)
> - engine->schedule(rq, attr);
> + if (engine->sched_engine->schedule)
> + engine->sched_engine->schedule(rq, attr);
> rcu_read_unlock();
> }
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 33d879137908..b480fcb1aad1 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -326,9 +326,6 @@ static int intel_engine_setup(struct intel_gt *gt, enum
> intel_engine_id id)
> if (engine->context_size)
> DRIVER_CAPS(i915)->has_logical_contexts = true;
>
> - /* Nothing to do here, execute in order of dependencies */
> - engine->schedule = NULL;
> -
> ewma__engine_latency_init(>latency);
> seqcount_init(>stats.lock);
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> index b99ac41695f3..b6a305e6a974 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c
> @@ -121,7 +121,7 @@ static void heartbeat(struct work_struct *wrk)
> * but all other contexts, including the kernel
> * context are stuck waiting for the signal.
> */
> - } else if (engine->schedule &&
> + } else if (engine->sched_engine->schedule &&
>rq->sched.attr.priority < I915_PRIORITY_BARRIER) {
> /*
> * Gradually raise the priority of the heartbeat to
> @@ -136,7 +136,7 @@ static void heartbeat(struct work_struct *wrk)
> attr.priority = I915_PRIORITY_BARRIER;
>
> local_bh_disable();
> - engine->schedule(rq, );
> + engine->sched_engine->schedule(rq, );
> local_bh_enable();
> } else {
> if (IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM))
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 7197b9fa5e35..f1b14aff5118 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -426,14 +426,6 @@ struct intel_engine_cs {
> void(*bond_execute)(struct i915_request *rq,
> struct dma_fence *signal);
>
> - /*
> -* Call when the priority on a request has changed and it and its
> -* dependencies may need rescheduling. Note the request itself may
> -* not be ready to run!
> -*/
> - void(*schedule)(struct i915_request *request,
> - const struct i915_sched_attr *attr);
> -
> void(*release)(struct intel_engine_cs *engine);
>
> struct intel_engine_execlists execlists;
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> index 3cca7ea2d6ea..84142127ebd8 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_user.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_user.c
> @@ -108,7 +108,7 @@ static void set_scheduler_caps(struct drm_i915_private
> *i915)
> for_each_uabi_engine(engine, i915) { /* all engines must agree! */
> int i;
>
> - if (engine->schedule)
> + if (engine->sched_engine->schedule)
> enabled |=
[Intel-gfx] [CI 4/4] drm/i915/adl_p: Load DMC
Load DMC v2.10 on ADLP. The release notes mention that
this version enables few power savings features.
Cc: Lucas De Marchi
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 09f65ad71f7e..52cedd5ea48e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -45,6 +45,10 @@
#define GEN12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
+#define ADLP_DMC_PATH "i915/adlp_dmc_ver2_10.bin"
+#define ADLP_DMC_VERSION_REQUIRED DMC_VERSION(2, 10)
+MODULE_FIRMWARE(ADLP_DMC_PATH);
+
#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01)
#define ADLS_DMC_VERSION_REQUIRED DMC_VERSION(2, 1)
MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -727,7 +731,11 @@ void intel_dmc_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_dmc_runtime_pm_get(dev_priv);
- if (IS_ALDERLAKE_S(dev_priv)) {
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ dmc->fw_path = ADLP_DMC_PATH;
+ dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
+ dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
+ } else if (IS_ALDERLAKE_S(dev_priv)) {
dmc->fw_path = ADLS_DMC_PATH;
dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 0/4] Pipe DMC Support
With all DMC cleanup patches merged, sending the rebased version of actual Pipe DMC bits. One change from previous verison is a fix of SKL regression. Corner cases for stepping-substepping combination was missing from fw_info_matches_stepping() helper. Luckily SKL was the only platform in CI that came under this category and DMC refused to load. This fix is tested on SKL. Anusha Srivatsa (4): drm/i915/dmc: Introduce DMC_FW_MAIN xdrm/i915/xelpd: Pipe A DMC plugging drm/i915/adl_p: Pipe B DMC Support drm/i915/adl_p: Load DMC .../drm/i915/display/intel_display_debugfs.c | 6 +- .../drm/i915/display/intel_display_power.c| 5 +- drivers/gpu/drm/i915/display/intel_dmc.c | 170 ++ drivers/gpu/drm/i915/display/intel_dmc.h | 23 ++- drivers/gpu/drm/i915/i915_reg.h | 2 +- 5 files changed, 127 insertions(+), 79 deletions(-) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915/xelpd: Pipe A DMC plugging
This patch adds Pipe A plumbing to the already
existing parsing and loading functions which is
taken care of in the prep patches. Adding MAX_DMC_FW
to keep track for both Main and Pipe A DMC while loading
the respective blobs.
Also adding present field in dmc_info.
s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
fw_info_matches_stepping() helper. CSR_PROGRAM() should now
take the starting address of the particular blob (Main or Pipe)
and not hardcode it.
v2: Add dmc_offset and start_mmioaddr fields for dmc_info struct.
v3: Add a missing corner cases of stepping-substepping combination in
fw_info_matches_stepping() helper.
Cc: Souza, Jose
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
.../drm/i915/display/intel_display_debugfs.c | 4 +-
.../drm/i915/display/intel_display_power.c| 5 +-
drivers/gpu/drm/i915/display/intel_dmc.c | 130 +++---
drivers/gpu/drm/i915/display/intel_dmc.h | 4 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
5 files changed, 89 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 88bb05d5c483..2a1c39a0e56e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "fw loaded: %s\n",
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
+ seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
+ seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
out:
seq_printf(m, "program base: 0x%08x\n",
- intel_de_read(dev_priv, DMC_PROGRAM(0)));
+ intel_de_read(dev_priv,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
seq_printf(m, "ssp base: 0x%08x\n",
intel_de_read(dev_priv, DMC_SSP_BASE));
seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv, DMC_HTP_SKL));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 3e1f6ec61514..b7d4993feca6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private
*dev_priv)
static void assert_dmc_loaded(struct drm_i915_private *dev_priv)
{
drm_WARN_ONCE(_priv->drm,
- !intel_de_read(dev_priv, DMC_PROGRAM(0)),
- "DMC program storage start is NULL\n");
+ !intel_de_read(dev_priv,
+
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+"DMC program storage start is NULL\n");
drm_WARN_ONCE(_priv->drm, !intel_de_read(dev_priv, DMC_SSP_BASE),
"DMC SSP Base Not fine\n");
drm_WARN_ONCE(_priv->drm, !intel_de_read(dev_priv, DMC_HTP_SKL),
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index b78cb44731fe..09f65ad71f7e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -317,8 +317,7 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = _priv->dmc;
- struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
- u32 i, fw_size;
+ u32 id, i;
if (!HAS_DMC(dev_priv)) {
drm_err(_priv->drm,
@@ -332,20 +331,25 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
preempt_disable();
- for (i = 0; i < fw_size; i++)
- intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- dmc_info->payload[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
+ intel_uncore_write_fw(_priv->uncore,
+
DMC_PROGRAM(dmc->dmc_info[id].start_mmioaddr, i),
+ dmc->dmc_info[id].payload[i]);
+ }
+ }
preempt_enable();
- for (i = 0; i < dmc_info->mmio_count; i++) {
- intel_de_write(dev_priv, dmc_info->mmioaddr[i],
- dmc_info->mmiodata[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0;
[Intel-gfx] [CI 3/4] drm/i915/adl_p: Pipe B DMC Support
ADLP requires us to load both Pipe A and Pipe B.
Plug Pipe B loading support.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 ++
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2a1c39a0e56e..db38891a9ef0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -546,6 +546,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "path: %s\n", dmc->fw_path);
seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
+ seq_printf(m, "Pipe B fw support: %s\n",
yesno(IS_ALDERLAKE_P(dev_priv)));
+ seq_printf(m, "Pipe B fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 007a284b0ef0..c3c00ff03869 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -19,6 +19,7 @@ struct drm_i915_private;
enum {
DMC_FW_MAIN = 0,
DMC_FW_PIPEA,
+ DMC_FW_PIPEB,
DMC_FW_MAX
};
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/4] drm/i915/dmc: Introduce DMC_FW_MAIN
This is a prep patch for Pipe DMC plugging.
Add dmc_info struct in intel_dmc to have all common fields
shared between all DMC's in the package.
Add DMC_FW_MAIN(dmc_id 0) to refer to the blob.
v2: Remove dmc_offset and start_mmioaddr from dmc_info struct (Jose)
Cc: Souza, Jose
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++-
drivers/gpu/drm/i915/display/intel_dmc.h | 18 +++---
2 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 97308da28059..b78cb44731fe 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -239,7 +239,7 @@ struct stepping_info {
bool intel_dmc_has_payload(struct drm_i915_private *i915)
{
- return i915->dmc.dmc_payload;
+ return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
}
static const struct stepping_info skl_stepping_info[] = {
@@ -316,7 +316,8 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
*/
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
- u32 *payload = dev_priv->dmc.dmc_payload;
+ struct intel_dmc *dmc = _priv->dmc;
+ struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
u32 i, fw_size;
if (!HAS_DMC(dev_priv)) {
@@ -325,26 +326,26 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- if (!intel_dmc_has_payload(dev_priv)) {
+ if (!dev_priv->dmc.dmc_info[DMC_FW_MAIN].payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
- fw_size = dev_priv->dmc.dmc_fw_size;
+ fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
preempt_disable();
for (i = 0; i < fw_size; i++)
intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- payload[i]);
+ dmc_info->payload[i]);
preempt_enable();
- for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
- intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
- dev_priv->dmc.mmiodata[i]);
+ for (i = 0; i < dmc_info->mmio_count; i++) {
+ intel_de_write(dev_priv, dmc_info->mmioaddr[i],
+ dmc_info->mmiodata[i]);
}
dev_priv->dmc.dc_state = 0;
@@ -401,13 +402,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
size_t rem_size)
{
struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+ struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
u8 *payload;
- BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+ BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
/*
* Check if we can access common fields, we will checkc again below
@@ -463,16 +465,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
}
for (i = 0; i < mmio_count; i++) {
- if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
- mmioaddr[i] > DMC_MMIO_END_RANGE) {
- drm_err(>drm, "DMC firmware has wrong mmio
address 0x%x\n",
- mmioaddr[i]);
- return 0;
- }
- dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
- dmc->mmiodata[i] = mmiodata[i];
+ dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
+ dmc_info->mmiodata[i] = mmiodata[i];
}
- dmc->mmio_count = mmio_count;
+ dmc_info->mmio_count = mmio_count;
rem_size -= header_len_bytes;
@@ -485,14 +481,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
drm_err(>drm, "DMC FW too big (%u bytes)\n",
payload_size);
return 0;
}
- dmc->dmc_fw_size = dmc_header->fw_size;
+ dmc_info->dmc_fw_size = dmc_header->fw_size;
- dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
- if (!dmc->dmc_payload)
+ dmc_info->payload = kmalloc(payload_size, GFP_KERNEL);
+ if (!dmc_info->payload)
return 0;
payload = (u8 *)(dmc_header) + header_len_bytes;
- memcpy(dmc->dmc_payload, payload, payload_size);
+ memcpy(dmc_info->payload, payload, payload_size);
return header_len_bytes + payload_size;
@@ -827,5 +823,5 @@ void intel_dmc_ucode_fini(struct drm_i915_private
Re: [Intel-gfx] [PATCH 4/9] drm/i915: Move active tracking to i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Move active request tracking and its lock to i915_sched_engine. This
> lock is also the submission lock so having it in the i915_sched_engine
> is the correct place.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h| 2 -
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 43 +++-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 --
> .../drm/i915/gt/intel_execlists_submission.c | 98 ++-
> .../gpu/drm/i915/gt/intel_ring_submission.c | 12 +--
> drivers/gpu/drm/i915/gt/mock_engine.c | 7 +-
> drivers/gpu/drm/i915/gt/selftest_execlists.c | 4 +-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 20 ++--
> drivers/gpu/drm/i915/i915_gpu_error.c | 4 +-
> drivers/gpu/drm/i915/i915_request.c | 32 +++---
> drivers/gpu/drm/i915/i915_request.h | 2 +-
> drivers/gpu/drm/i915/i915_scheduler.c | 30 --
> drivers/gpu/drm/i915/i915_scheduler_types.h | 9 ++
> 13 files changed, 134 insertions(+), 135 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index 8d9184920c51..a8b2174b4395 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -257,8 +257,6 @@ intel_engine_find_active_request(struct intel_engine_cs
> *engine);
>
> u32 intel_engine_context_size(struct intel_gt *gt, u8 class);
>
> -void intel_engine_init_active(struct intel_engine_cs *engine,
> - unsigned int subclass);
> #define ENGINE_PHYSICAL0
> #define ENGINE_MOCK1
> #define ENGINE_VIRTUAL 2
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 85f2effe9dc6..33d879137908 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -719,7 +719,6 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> if (err)
> goto err_cmd_parser;
>
> - intel_engine_init_active(engine, ENGINE_PHYSICAL);
> intel_engine_init_execlists(engine);
> intel_engine_init__pm(engine);
> intel_engine_init_retire(engine);
> @@ -778,11 +777,11 @@ static int measure_breadcrumb_dw(struct intel_context
> *ce)
> frame->rq.ring = >ring;
>
> mutex_lock(>timeline->mutex);
> - spin_lock_irq(>active.lock);
> + spin_lock_irq(>sched_engine->lock);
>
> dw = engine->emit_fini_breadcrumb(>rq, frame->cs) - frame->cs;
>
> - spin_unlock_irq(>active.lock);
> + spin_unlock_irq(>sched_engine->lock);
> mutex_unlock(>timeline->mutex);
>
> GEM_BUG_ON(dw & 1); /* RING_TAIL must be qword aligned */
> @@ -791,28 +790,6 @@ static int measure_breadcrumb_dw(struct intel_context
> *ce)
> return dw;
> }
>
> -void
> -intel_engine_init_active(struct intel_engine_cs *engine, unsigned int
> subclass)
> -{
> - INIT_LIST_HEAD(>active.requests);
> - INIT_LIST_HEAD(>active.hold);
> -
> - spin_lock_init(>active.lock);
> - lockdep_set_subclass(>active.lock, subclass);
> -
> - /*
> -* Due to an interesting quirk in lockdep's internal debug tracking,
> -* after setting a subclass we must ensure the lock is used.
> Otherwise,
> -* nr_unused_locks is incremented once too often.
> -*/
> -#ifdef CONFIG_DEBUG_LOCK_ALLOC
> - local_irq_disable();
> - lock_map_acquire(>active.lock.dep_map);
> - lock_map_release(>active.lock.dep_map);
> - local_irq_enable();
> -#endif
> -}
> -
> static struct intel_context *
> create_pinned_context(struct intel_engine_cs *engine,
> unsigned int hwsp,
> @@ -960,7 +937,7 @@ int intel_engines_init(struct intel_gt *gt)
> */
> void intel_engine_cleanup_common(struct intel_engine_cs *engine)
> {
> - GEM_BUG_ON(!list_empty(>active.requests));
> + GEM_BUG_ON(!list_empty(>sched_engine->requests));
> tasklet_kill(>execlists.tasklet); /* flush the callback */
>
> i915_sched_engine_put(engine->sched_engine);
> @@ -1353,7 +1330,7 @@ static struct intel_timeline *get_timeline(struct
> i915_request *rq)
> struct intel_timeline *tl;
>
> /*
> -* Even though we are holding the engine->active.lock here, there
> +* Even though we are holding the engine->sched_engine->lock here,
> there
> * is no control over the submission queue per-se and we are
> * inspecting the active state at a random point in time, with an
> * unknown queue. Play safe and make sure the timeline remains valid.
> @@ -1700,7 +1677,7 @@ void intel_engine_dump(struct intel_engine_cs *engine,
>
> drm_printf(m, "\tRequests:\n");
>
> - spin_lock_irqsave(>active.lock, flags);
> + spin_lock_irqsave(>sched_engine->lock, flags);
> rq =
[Intel-gfx] [CI 4/4] drm/i915/adl_p: Load DMC
Load DMC v2.06 on ADLP. The release notes mention that
this version enables few power savings features.
Cc: Lucas De Marchi
Cc: Clint Taylor
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 10 +-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 09f65ad71f7e..52cedd5ea48e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -45,6 +45,10 @@
#define GEN12_DMC_MAX_FW_SIZE ICL_DMC_MAX_FW_SIZE
+#define ADLP_DMC_PATH "i915/adlp_dmc_ver2_10.bin"
+#define ADLP_DMC_VERSION_REQUIRED DMC_VERSION(2, 10)
+MODULE_FIRMWARE(ADLP_DMC_PATH);
+
#define ADLS_DMC_PATH DMC_PATH(adls, 2, 01)
#define ADLS_DMC_VERSION_REQUIRED DMC_VERSION(2, 1)
MODULE_FIRMWARE(ADLS_DMC_PATH);
@@ -727,7 +731,11 @@ void intel_dmc_ucode_init(struct drm_i915_private
*dev_priv)
*/
intel_dmc_runtime_pm_get(dev_priv);
- if (IS_ALDERLAKE_S(dev_priv)) {
+ if (IS_ALDERLAKE_P(dev_priv)) {
+ dmc->fw_path = ADLP_DMC_PATH;
+ dmc->required_version = ADLP_DMC_VERSION_REQUIRED;
+ dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
+ } else if (IS_ALDERLAKE_S(dev_priv)) {
dmc->fw_path = ADLS_DMC_PATH;
dmc->required_version = ADLS_DMC_VERSION_REQUIRED;
dmc->max_fw_size = GEN12_DMC_MAX_FW_SIZE;
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 0/4] Pipe DMC Support
With all DMC cleanup patches merged, sending the rebased version of actual Pipe DMC bits. One change from previous verison is a fix of SKL regression. Corner cases for stepping-substepping combination was missing from fw_info_matches_stepping() helper. Luckily SKL was the only platform in CI that came under this category and DMC refused to load. This fix is tested on SKL. Anusha Srivatsa (4): drm/i915/dmc: Introduce DMC_FW_MAIN xdrm/i915/xelpd: Pipe A DMC plugging drm/i915/adl_p: Pipe B DMC Support drm/i915/adl_p: Load DMC .../drm/i915/display/intel_display_debugfs.c | 6 +- .../drm/i915/display/intel_display_power.c| 5 +- drivers/gpu/drm/i915/display/intel_dmc.c | 170 ++ drivers/gpu/drm/i915/display/intel_dmc.h | 23 ++- drivers/gpu/drm/i915/i915_reg.h | 2 +- 5 files changed, 127 insertions(+), 79 deletions(-) -- 2.25.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/4] drm/i915/adl_p: Pipe B DMC Support
ADLP requires us to load both Pipe A and Pipe B.
Plug Pipe B loading support.
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_display_debugfs.c | 2 ++
drivers/gpu/drm/i915/display/intel_dmc.h | 1 +
2 files changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 2a1c39a0e56e..db38891a9ef0 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -546,6 +546,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "path: %s\n", dmc->fw_path);
seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
+ seq_printf(m, "Pipe B fw support: %s\n",
yesno(IS_ALDERLAKE_P(dev_priv)));
+ seq_printf(m, "Pipe B fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEB].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.h
b/drivers/gpu/drm/i915/display/intel_dmc.h
index 007a284b0ef0..c3c00ff03869 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.h
+++ b/drivers/gpu/drm/i915/display/intel_dmc.h
@@ -19,6 +19,7 @@ struct drm_i915_private;
enum {
DMC_FW_MAIN = 0,
DMC_FW_PIPEA,
+ DMC_FW_PIPEB,
DMC_FW_MAX
};
--
2.25.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/4] drm/i915/xelpd: Pipe A DMC plugging
This patch adds Pipe A plumbing to the already
existing parsing and loading functions which is
taken care of in the prep patches. Adding MAX_DMC_FW
to keep track for both Main and Pipe A DMC while loading
the respective blobs.
Also adding present field in dmc_info.
s/find_dmc_fw_offset/csr_set_dmc_fw_offset. While at it add
fw_info_matches_stepping() helper. CSR_PROGRAM() should now
take the starting address of the particular blob (Main or Pipe)
and not hardcode it.
v2: Add dmc_offset and start_mmioaddr fields for dmc_info struct.
v3: Add a missing corner cases of stepping-substepping combination in
fw_info_matches_stepping() helper.
Cc: Souza, Jose
Cc: Lucas De Marchi
Signed-off-by: Anusha Srivatsa
---
.../drm/i915/display/intel_display_debugfs.c | 4 +-
.../drm/i915/display/intel_display_power.c| 5 +-
drivers/gpu/drm/i915/display/intel_dmc.c | 130 +++---
drivers/gpu/drm/i915/display/intel_dmc.h | 4 +
drivers/gpu/drm/i915/i915_reg.h | 2 +-
5 files changed, 89 insertions(+), 56 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 88bb05d5c483..2a1c39a0e56e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -544,6 +544,8 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "fw loaded: %s\n",
yesno(intel_dmc_has_payload(dev_priv)));
seq_printf(m, "path: %s\n", dmc->fw_path);
+ seq_printf(m, "Pipe A fw support: %s\n", yesno(INTEL_GEN(dev_priv) >=
12));
+ seq_printf(m, "Pipe A fw loaded: %s\n",
yesno(dmc->dmc_info[DMC_FW_PIPEA].payload));
if (!intel_dmc_has_payload(dev_priv))
goto out;
@@ -582,7 +584,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
out:
seq_printf(m, "program base: 0x%08x\n",
- intel_de_read(dev_priv, DMC_PROGRAM(0)));
+ intel_de_read(dev_priv,
DMC_PROGRAM(dmc->dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)));
seq_printf(m, "ssp base: 0x%08x\n",
intel_de_read(dev_priv, DMC_SSP_BASE));
seq_printf(m, "htp: 0x%08x\n", intel_de_read(dev_priv, DMC_HTP_SKL));
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 3e1f6ec61514..b7d4993feca6 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -961,8 +961,9 @@ static void bxt_disable_dc9(struct drm_i915_private
*dev_priv)
static void assert_dmc_loaded(struct drm_i915_private *dev_priv)
{
drm_WARN_ONCE(_priv->drm,
- !intel_de_read(dev_priv, DMC_PROGRAM(0)),
- "DMC program storage start is NULL\n");
+ !intel_de_read(dev_priv,
+
DMC_PROGRAM(dev_priv->dmc.dmc_info[DMC_FW_MAIN].start_mmioaddr, 0)),
+"DMC program storage start is NULL\n");
drm_WARN_ONCE(_priv->drm, !intel_de_read(dev_priv, DMC_SSP_BASE),
"DMC SSP Base Not fine\n");
drm_WARN_ONCE(_priv->drm, !intel_de_read(dev_priv, DMC_HTP_SKL),
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index b78cb44731fe..09f65ad71f7e 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -317,8 +317,7 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
struct intel_dmc *dmc = _priv->dmc;
- struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
- u32 i, fw_size;
+ u32 id, i;
if (!HAS_DMC(dev_priv)) {
drm_err(_priv->drm,
@@ -332,20 +331,25 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
preempt_disable();
- for (i = 0; i < fw_size; i++)
- intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- dmc_info->payload[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0; i < dmc->dmc_info[id].dmc_fw_size; i++) {
+ intel_uncore_write_fw(_priv->uncore,
+
DMC_PROGRAM(dmc->dmc_info[id].start_mmioaddr, i),
+ dmc->dmc_info[id].payload[i]);
+ }
+ }
preempt_enable();
- for (i = 0; i < dmc_info->mmio_count; i++) {
- intel_de_write(dev_priv, dmc_info->mmioaddr[i],
- dmc_info->mmiodata[i]);
+ for (id = 0; id < DMC_FW_MAX; id++) {
+ for (i = 0;
[Intel-gfx] [CI 1/4] drm/i915/dmc: Introduce DMC_FW_MAIN
This is a prep patch for Pipe DMC plugging.
Add dmc_info struct in intel_dmc to have all common fields
shared between all DMC's in the package.
Add DMC_FW_MAIN(dmc_id 0) to refer to the blob.
v2: Remove dmc_offset and start_mmioaddr from dmc_info struct (Jose)
Cc: Souza, Jose
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/display/intel_dmc.c | 44 +++-
drivers/gpu/drm/i915/display/intel_dmc.h | 18 +++---
2 files changed, 33 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dmc.c
b/drivers/gpu/drm/i915/display/intel_dmc.c
index 97308da28059..b78cb44731fe 100644
--- a/drivers/gpu/drm/i915/display/intel_dmc.c
+++ b/drivers/gpu/drm/i915/display/intel_dmc.c
@@ -239,7 +239,7 @@ struct stepping_info {
bool intel_dmc_has_payload(struct drm_i915_private *i915)
{
- return i915->dmc.dmc_payload;
+ return i915->dmc.dmc_info[DMC_FW_MAIN].payload;
}
static const struct stepping_info skl_stepping_info[] = {
@@ -316,7 +316,8 @@ static void gen9_set_dc_state_debugmask(struct
drm_i915_private *dev_priv)
*/
void intel_dmc_load_program(struct drm_i915_private *dev_priv)
{
- u32 *payload = dev_priv->dmc.dmc_payload;
+ struct intel_dmc *dmc = _priv->dmc;
+ struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
u32 i, fw_size;
if (!HAS_DMC(dev_priv)) {
@@ -325,26 +326,26 @@ void intel_dmc_load_program(struct drm_i915_private
*dev_priv)
return;
}
- if (!intel_dmc_has_payload(dev_priv)) {
+ if (!dev_priv->dmc.dmc_info[DMC_FW_MAIN].payload) {
drm_err(_priv->drm,
"Tried to program CSR with empty payload\n");
return;
}
- fw_size = dev_priv->dmc.dmc_fw_size;
+ fw_size = dmc_info->dmc_fw_size;
assert_rpm_wakelock_held(_priv->runtime_pm);
preempt_disable();
for (i = 0; i < fw_size; i++)
intel_uncore_write_fw(_priv->uncore, DMC_PROGRAM(i),
- payload[i]);
+ dmc_info->payload[i]);
preempt_enable();
- for (i = 0; i < dev_priv->dmc.mmio_count; i++) {
- intel_de_write(dev_priv, dev_priv->dmc.mmioaddr[i],
- dev_priv->dmc.mmiodata[i]);
+ for (i = 0; i < dmc_info->mmio_count; i++) {
+ intel_de_write(dev_priv, dmc_info->mmioaddr[i],
+ dmc_info->mmiodata[i]);
}
dev_priv->dmc.dc_state = 0;
@@ -401,13 +402,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
size_t rem_size)
{
struct drm_i915_private *i915 = container_of(dmc, typeof(*i915), dmc);
+ struct dmc_fw_info *dmc_info = >dmc_info[DMC_FW_MAIN];
unsigned int header_len_bytes, dmc_header_size, payload_size, i;
const u32 *mmioaddr, *mmiodata;
u32 mmio_count, mmio_count_max;
u8 *payload;
- BUILD_BUG_ON(ARRAY_SIZE(dmc->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
-ARRAY_SIZE(dmc->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
+ BUILD_BUG_ON(ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V3_MAX_MMIO_COUNT ||
+ARRAY_SIZE(dmc_info->mmioaddr) < DMC_V1_MAX_MMIO_COUNT);
/*
* Check if we can access common fields, we will checkc again below
@@ -463,16 +465,10 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
}
for (i = 0; i < mmio_count; i++) {
- if (mmioaddr[i] < DMC_MMIO_START_RANGE ||
- mmioaddr[i] > DMC_MMIO_END_RANGE) {
- drm_err(>drm, "DMC firmware has wrong mmio
address 0x%x\n",
- mmioaddr[i]);
- return 0;
- }
- dmc->mmioaddr[i] = _MMIO(mmioaddr[i]);
- dmc->mmiodata[i] = mmiodata[i];
+ dmc_info->mmioaddr[i] = _MMIO(mmioaddr[i]);
+ dmc_info->mmiodata[i] = mmiodata[i];
}
- dmc->mmio_count = mmio_count;
+ dmc_info->mmio_count = mmio_count;
rem_size -= header_len_bytes;
@@ -485,14 +481,14 @@ static u32 parse_dmc_fw_header(struct intel_dmc *dmc,
drm_err(>drm, "DMC FW too big (%u bytes)\n",
payload_size);
return 0;
}
- dmc->dmc_fw_size = dmc_header->fw_size;
+ dmc_info->dmc_fw_size = dmc_header->fw_size;
- dmc->dmc_payload = kmalloc(payload_size, GFP_KERNEL);
- if (!dmc->dmc_payload)
+ dmc_info->payload = kmalloc(payload_size, GFP_KERNEL);
+ if (!dmc_info->payload)
return 0;
payload = (u8 *)(dmc_header) + header_len_bytes;
- memcpy(dmc->dmc_payload, payload, payload_size);
+ memcpy(dmc_info->payload, payload, payload_size);
return header_len_bytes + payload_size;
@@ -827,5 +823,5 @@ void intel_dmc_ucode_fini(struct drm_i915_private
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Add i915_sched_engine_reset_on_empty function
On Fri, Jun 04, 2021 at 01:31:42PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Rather than touching schedule state in the generic PM code, reset the
> > priolist allocation when empty in the submission code. Add a wrapper
> > function to do this and update the backends to call it in the correct
> > place.
>
> Seems reasonable, I think. I'm by no means an expert but
>
> Reviewed-by: Jason Ekstrand
>
> anyway. My one suggestion would be to tweak the commit message to
> talk about the functional change rather than the helper. Something
> like
>
> drm/i915: Reset sched_engine.no_priolist immediately after dequeue
>
> Typically patches which say "add a helper function" don't come with a
> non-trivial functional change.
>
Agree.
Thanks - Matt
> --Jason
>
>
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 --
> > drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
> > drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 ++
> > drivers/gpu/drm/i915/i915_scheduler.h| 7 +++
> > 4 files changed, 10 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index b6a00dd72808..1f07ac4e0672 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -280,8 +280,6 @@ static int __engine_park(struct intel_wakeref *wf)
> > if (engine->park)
> > engine->park(engine);
> >
> > - engine->sched_engine->no_priolist = false;
> > -
> > /* While gt calls i915_vma_parked(), we have to break the lock
> > cycle */
> > intel_gt_pm_put_async(engine->gt);
> > return 0;
> > diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > index 2326a73af6d3..609753b5401a 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> > @@ -1553,6 +1553,7 @@ static void execlists_dequeue(struct intel_engine_cs
> > *engine)
> > * interrupt for secondary ports).
> > */
> > sched_engine->queue_priority_hint = queue_prio(sched_engine);
> > + i915_sched_engine_reset_on_empty(sched_engine);
> > spin_unlock(>active.lock);
> >
> > /*
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > index 5d00f2e3c1de..f4a6fbfaf82e 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> > @@ -263,6 +263,8 @@ static void guc_submission_tasklet(struct
> > tasklet_struct *t)
> >
> > __guc_dequeue(engine);
> >
> > + i915_sched_engine_reset_on_empty(engine->sched_engine);
> > +
> > spin_unlock_irqrestore(>active.lock, flags);
> > }
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
> > b/drivers/gpu/drm/i915/i915_scheduler.h
> > index 5bec7b3b8456..713c38c99de9 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler.h
> > +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> > @@ -72,6 +72,13 @@ i915_sched_engine_is_empty(struct i915_sched_engine
> > *sched_engine)
> > return RB_EMPTY_ROOT(_engine->queue.rb_root);
> > }
> >
> > +static inline void
> > +i915_sched_engine_reset_on_empty(struct i915_sched_engine *sched_engine)
> > +{
> > + if (i915_sched_engine_is_empty(sched_engine))
> > + sched_engine->no_priolist = false;
> > +}
> > +
> > void i915_request_show_with_schedule(struct drm_printer *m,
> > const struct i915_request *rq,
> > const char *prefix,
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to 64 byte for Intel platforms
On Mon, May 31, 2021 at 10:47 AM Srinivas, Vidya
wrote:
>
> Hello Ville,
>
> Thank you very much.
> Before reaching our i915's i915_gem_dumb_create, it goes to
> vgem_gem_dumb_create for kms_prime.
>
> The pitch gets calculated there and it is not 64 byte aligned. Due to this,
> intel_framebuffer_init reports "pitch must be 64 byte aligned"
> and framebuffer creation fails. I tried submitting vgem patch where 64 byte
> alignment can be done in vgem_gem_dumb_create and that also
> passes. But we did not get approval yet as few of them felt, vgem is generic
> and other platforms might fail if we do 64 byte alignment there.
>
> Kindly suggest. Thanks a lot.
>
> Regards
> Vidya
>
> -Original Message-
> From: Ville Syrjälä
> Sent: Monday, May 31, 2021 7:48 PM
> To: Srinivas, Vidya
> Cc: intel-gfx@lists.freedesktop.org; igt-...@lists.freedesktop.org; Lin,
> Charlton
> Subject: Re: [igt-dev] [PATCH i-g-t] [RFC] tests/kms_prime: Aligned pitch to
> 64 byte for Intel platforms
>
> On Fri, May 28, 2021 at 10:04:03AM +0530, Vidya Srinivas wrote:
> > For Intel platforms, pitch needs to be 64 byte aligned.
> > Kernel code vgem_gem_dumb_create which is platform generic code doesnt
> > do the alignment. This causes frame buffer creation to fail on Intel
> > platforms where the pitch is not 64 byte aligned.
> >
> > tests: test run on Intel platforms with panel resolution 1366x768
> >
Tested on ChromeOS on JSL (Drawlat).
Tested-by: Mark Yacoub
> > Signed-off-by: Vidya Srinivas
> > ---
> > tests/kms_prime.c | 5 -
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/tests/kms_prime.c b/tests/kms_prime.c index
> > 8cb2ca2a9dc3..fdc941fe8100 100644
> > --- a/tests/kms_prime.c
> > +++ b/tests/kms_prime.c
> > @@ -51,6 +51,8 @@ static struct {
> > { .r = 1.0, .g = 0.0, .b = 0.0, .color = 0x }, };
> >
> > +bool check_platform;
I think we can do a more precise name to indicate which platform.
Something like is_intel_device or is_i915 would be more appropriate.
alternatively, we can drop the boolean and just do the check when needed.
So it would look something like
+ is_i915_device(fd) ? ALIGN(scratch->width, 64) : scratch->width,
> > +
> > IGT_TEST_DESCRIPTION("Prime tests, focusing on KMS side");
> >
> > static bool has_prime_import(int fd)
> > @@ -101,7 +103,7 @@ static void prepare_scratch(int exporter_fd, struct
> > dumb_bo *scratch,
> > scratch->bpp = 32;
> >
> > scratch->handle = kmstest_dumb_create(exporter_fd,
> > - scratch->width,
> > + check_platform? ALIGN(scratch->width, 64):
> > scratch->width,
>
> The dumb_create ioctl already does this for us.
>
> > scratch->height,
> > scratch->bpp,
> > >pitch,
> > @@ -262,6 +264,7 @@ igt_main
> >
> > /* ANY = anything that is not VGEM */
> > first_fd = __drm_open_driver_another(0, DRIVER_ANY |
> > DRIVER_VGEM);
> > + check_platform = is_i915_device(first_fd);
> > igt_require(first_fd >= 0);
> >
> > second_fd = __drm_open_driver_another(1, DRIVER_ANY |
> > DRIVER_VGEM);
> > --
> > 2.7.4
> >
> > ___
> > igt-dev mailing list
> > igt-...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/igt-dev
>
> --
> Ville Syrjälä
> Intel
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_big_fb: Wait for vblank before collecting CRC
On Fri, May 28, 2021 at 12:36 AM Vidya Srinivas
wrote:
>
> Without wait for vblank, CRC mismatch is seen
> between big and small CRC on few Gen11 systems.
>
Tested on ChromeOS on JSL (Drawlat).
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_big_fb.c | 6 --
> 1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_big_fb.c b/tests/kms_big_fb.c
> index b35727a09bd0..f90363c3beb2 100644
> --- a/tests/kms_big_fb.c
> +++ b/tests/kms_big_fb.c
> @@ -254,6 +254,7 @@ static void unset_lut(data_t *data)
> static bool test_plane(data_t *data)
> {
> igt_plane_t *plane = data->plane;
> + igt_display_t *display = >display;
> struct igt_fb *small_fb = >small_fb;
> struct igt_fb *big_fb = >big_fb;
> int w = data->big_fb_width - small_fb->width;
> @@ -337,16 +338,17 @@ static bool test_plane(data_t *data)
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
>
> -
> + igt_wait_for_vblank(data->drm_fd,
> display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, big_fb);
> igt_fb_set_position(big_fb, plane, x, y);
> igt_fb_set_size(big_fb, plane, small_fb->width,
> small_fb->height);
> +
> igt_plane_set_size(plane, data->width, data->height);
> igt_display_commit2(>display, data->display.is_atomic ?
> COMMIT_ATOMIC : COMMIT_UNIVERSAL);
> -
> + igt_wait_for_vblank(data->drm_fd,
> display->pipes[data->pipe].crtc_offset);
> igt_pipe_crc_collect_crc(data->pipe_crc, _crc);
>
> igt_plane_set_fb(plane, NULL);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_dp_dsc: Avoid SIGSEGV when release DRM connector.
On Mon, May 31, 2021 at 11:34 AM Lee Shawn C wrote:
>
> Got SIGSEGV fault while running kms_dp_dsc test but did not
> connect DP DSC capable monitor on eDP/DP port. This test daemon
> should "SKIP" test without any problem. We found kms_dp_dsc
> can't get proper drmModeConnector and caused this SIGSEGV fault
> when release it. Make sure drmModeConnector is available before
> free it can avoid this issue.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat).
Tested-by: Mark Yacoub
> Signed-off-by: Lee Shawn C
> ---
> tests/kms_dp_dsc.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/tests/kms_dp_dsc.c b/tests/kms_dp_dsc.c
> index 2446fd82bba3..ea7c9f4f72ce 100644
> --- a/tests/kms_dp_dsc.c
> +++ b/tests/kms_dp_dsc.c
> @@ -262,7 +262,7 @@ igt_main
> data_t data = {};
> igt_output_t *output;
> drmModeRes *res;
> - drmModeConnector *connector;
> + drmModeConnector *connector = NULL;
> int i, test_conn_cnt, test_cnt;
> int tests[] = {DRM_MODE_CONNECTOR_eDP,
> DRM_MODE_CONNECTOR_DisplayPort};
>
> @@ -311,7 +311,8 @@ igt_main
> }
>
> igt_fixture {
> - drmModeFreeConnector(connector);
> + if (connector)
> + drmModeFreeConnector(connector);
> drmModeFreeResources(res);
> close(data.debugfs_fd);
> close(data.drm_fd);
> --
> 2.17.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_dp_dsc: Transmit correct DRM connector structure.
On Mon, May 31, 2021 at 11:36 PM Lee Shawn C wrote:
>
> 1. Pass one more parameter (current drmModeConnector) when
>call "run_test()". Use it to retrieve proper connector_type.
> 2. SIGSEGV fault would happen due to "igt_output" did not
>store properly in "data->output". Main funciton already
>pass "igt_output" pointer into "run_test()" function.
>Use this pointer instead of "data->output" to get display mode.
>
> Fixes: a1772be7dede ("tests/kms_dp_dsc: Bug fix for DP on Pipe A")
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Lee Shawn C
> ---
> tests/kms_dp_dsc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/tests/kms_dp_dsc.c b/tests/kms_dp_dsc.c
> index ea7c9f4f72ce..e434384da369 100644
> --- a/tests/kms_dp_dsc.c
> +++ b/tests/kms_dp_dsc.c
> @@ -224,11 +224,11 @@ static void update_display(data_t *data, enum
> dsc_test_type test_type)
> }
>
> static void run_test(data_t *data, igt_output_t *output,
> -enum dsc_test_type test_type)
> +drmModeConnector *connector, enum dsc_test_type
> test_type)
> {
> enum pipe pipe;
>
> - data->mode = igt_output_get_mode(data->output);
> + data->mode = igt_output_get_mode(output);
> igt_create_pattern_fb(data->drm_fd, data->mode->hdisplay,
> data->mode->vdisplay,
> DRM_FORMAT_XRGB,
> @@ -239,7 +239,7 @@ static void run_test(data_t *data, igt_output_t *output,
> if (is_i915_device(data->drm_fd)) {
> uint32_t devid = intel_get_drm_devid(data->drm_fd);
>
> - if (data->connector->connector_type ==
> DRM_MODE_CONNECTOR_DisplayPort &&
> + if (connector->connector_type ==
> DRM_MODE_CONNECTOR_DisplayPort &&
> data->pipe == PIPE_A && IS_GEN11(devid)) {
> igt_debug("DSC not supported on Pipe A on
> external DP in Gen11 platforms\n");
> continue;
> @@ -304,7 +304,7 @@ igt_main
> continue;
> }
> test_conn_cnt++;
> - run_test(, output,
> test_basic_dsc_enable);
> + run_test(, output, connector,
> test_basic_dsc_enable);
> }
> igt_skip_on(test_conn_cnt == 0);
> }
> --
> 2.17.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/kms_flip.c: Fix subtests flip-vs-suspend
Tested it on ChromeOS and it runs well. But I think we should fix the root cause instead. On Fri, May 28, 2021 at 12:33 AM Vidya Srinivas wrote: > > Some Intel Gen11 systems are not able to do a RTC wake. > Instead change the default SUSPEND_TEST_NONE to > SUSPEND_TEST_PLATFORM. > Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat) Tested-by: Mark Yacoub > Signed-off-by: Vidya Srinivas > --- > tests/kms_flip.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/tests/kms_flip.c b/tests/kms_flip.c > index 8f736652be90..8afac88c9b15 100755 > --- a/tests/kms_flip.c > +++ b/tests/kms_flip.c > @@ -835,7 +835,8 @@ static bool run_test_step(struct test_output *o, unsigned > int *events) > > if (o->flags & TEST_SUSPEND) > igt_system_suspend_autoresume(SUSPEND_STATE_MEM, > - SUSPEND_TEST_NONE); > + is_i915_device(drm_fd)? > + > SUSPEND_TEST_PLATFORM:SUSPEND_TEST_NONE); > > if (do_vblank && (o->flags & TEST_EINVAL) && o->vblank_state.count > > 0) > igt_assert(do_wait_for_vblank(o, o->pipe, target_seq, > _reply) > -- > 2.7.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] [RFC] tests/drm_read: Fix subtest invalid-buffer
On Fri, May 28, 2021 at 12:41 AM Vidya Srinivas
wrote:
>
> Using (void *)-1 directly in read is aborting on chrome systems.
> Following message is seen.
>
> Starting subtest: invalid-buffer
> *** buffer overflow detected ***: terminated
> Received signal SIGABRT.
> Stack trace:
> Aborted (core dumped)
>
> Patch just adds a pointer variable and uses it in read.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/drm_read.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/tests/drm_read.c b/tests/drm_read.c
> index ccf9d822fd8d..2fdec5be4078 100644
> --- a/tests/drm_read.c
> +++ b/tests/drm_read.c
> @@ -103,10 +103,11 @@ static void teardown(int fd)
> static void test_invalid_buffer(int in)
> {
> int fd = setup(in, 0);
> + void *add = (void *)-1;
>
> alarm(1);
>
> - igt_assert_eq(read(fd, (void *)-1, 4096), -1);
> + igt_assert_eq(read(fd, add, 4096), -1);
> igt_assert_eq(errno, EFAULT);
>
> teardown(fd);
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/20] drm/i915/guc: Relax CTB response timeout
On Fri, Jun 04, 2021 at 10:33:07AM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 10:16:23PM -0700, Matthew Brost wrote:
> > From: Michal Wajdeczko
> >
> > In upcoming patch we will allow more CTB requests to be sent in
> > parallel to the GuC for processing, so we shouldn't assume any more
> > that GuC will always reply without 10ms.
> >
> > Use bigger value from CONFIG_DRM_I915_GUC_CTB_TIMEOUT instead.
> >
> > v2: Add CONFIG_DRM_I915_GUC_CTB_TIMEOUT config option
> >
> > Signed-off-by: Michal Wajdeczko
> > Signed-off-by: Matthew Brost
> > Reviewed-by: Matthew Brost
>
> So this is a rant, but for upstream we really need to do better than
> internal:
>
> - The driver must work by default in the optimal configuration.
>
> - Any config change that we haven't validated _must_ taint the kernel
> (this is especially for module options, but also for config settings)
>
> - Config need a real reason beyond "was useful for bring-up".
>
> Our internal tree is an absolute disaster right now, with multi-line
> kernel configs (different on each platform) and bespoke kernel config or
> the driver just fails. We're the expert on our own hw, we should know how
> it works, not offload that to users essentially asking them "how shitty do
> you think Intel hw is in responding timely".
>
> Yes I know there's a lot of these there already, they don't make a lot of
> sense either.
>
> Except if there's a real reason for this (aside from us just offloading
> testing to our users instead of doing it ourselves properly) I think we
> should hardcode this, with a comment explaining why. Maybe with a switch
> between the PF/VF case once that's landed.
>
> > ---
> > drivers/gpu/drm/i915/Kconfig.profile | 10 ++
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c | 5 -
> > 2 files changed, 14 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/Kconfig.profile
> > b/drivers/gpu/drm/i915/Kconfig.profile
> > index 39328567c200..0d5475b5f28a 100644
> > --- a/drivers/gpu/drm/i915/Kconfig.profile
> > +++ b/drivers/gpu/drm/i915/Kconfig.profile
> > @@ -38,6 +38,16 @@ config DRM_I915_USERFAULT_AUTOSUSPEND
> > May be 0 to disable the extra delay and solely use the device level
> > runtime pm autosuspend delay tunable.
> >
> > +config DRM_I915_GUC_CTB_TIMEOUT
> > + int "How long to wait for the GuC to make forward progress on CTBs (ms)"
> > + default 1500 # milliseconds
> > + range 10 6
>
> Also range is definitely off, drm/scheduler will probably nuke you
> beforehand :-)
>
> That's kinda another issue I have with all these kconfig knobs: Maybe we
> need a knob for "relax with reset attempts, my workloads overload my gpus
> routinely", which then scales _all_ timeouts proportionally. But letting
> the user set them all, with silly combiniations like resetting the
> workload before heartbeat or stuff like that doesn't make much sense.
>
Yes, the code as is the user could do some wacky stuff that doesn't make
sense at all.
> Anyway, tiny patch so hopefully I can leave this one out for now until
> we've closed this.
No issue leaving this out as blocking CTBs are never really used anyways
until SRIOV aside from setup / debugging. That being said, we might
still want a higher hardcoded value in the meantime, perhaps around a
second. I can follow up on that if needed.
Matt
> -Daniel
>
> > + help
> > + Configures the default timeout waiting for GuC the to make forward
> > + progress on CTBs. e.g. Waiting for a response to a requeset.
> > +
> > + A range of 10 ms to 6 ms is allowed.
> > +
> > config DRM_I915_HEARTBEAT_INTERVAL
> > int "Interval between heartbeat pulses (ms)"
> > default 2500 # milliseconds
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > index 916c2b80c841..cf1fb09ef766 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ct.c
> > @@ -436,6 +436,7 @@ static int ct_write(struct intel_guc_ct *ct,
> > */
> > static int wait_for_ct_request_update(struct ct_request *req, u32 *status)
> > {
> > + long timeout;
> > int err;
> >
> > /*
> > @@ -443,10 +444,12 @@ static int wait_for_ct_request_update(struct
> > ct_request *req, u32 *status)
> > * up to that length of time, then switch to a slower sleep-wait loop.
> > * No GuC command should ever take longer than 10ms.
> > */
> > + timeout = CONFIG_DRM_I915_GUC_CTB_TIMEOUT;
> > +
> > #define done INTEL_GUC_MSG_IS_RESPONSE(READ_ONCE(req->status))
> > err = wait_for_us(done, 10);
> > if (err)
> > - err = wait_for(done, 10);
> > + err = wait_for(done, timeout);
> > #undef done
> >
> > if (unlikely(err))
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] [RFC] tests/kms_plane_alpha_blend: Fix coverage-vs-premult-vs-constant tests
On Tue, Jun 1, 2021 at 7:54 AM Vidya Srinivas wrote:
>
> Few Gen11 systems show CRC mismatch. Make coverage-vs-premult-vs-constant
> code similar to constant_alpha_min or basic_alpha
>
Tested on ChromeOS on JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_plane_alpha_blend.c | 4
> 1 file changed, 4 deletions(-)
>
> diff --git a/tests/kms_plane_alpha_blend.c b/tests/kms_plane_alpha_blend.c
> index a37cb27c7d62..224d79bd1749 100644
> --- a/tests/kms_plane_alpha_blend.c
> +++ b/tests/kms_plane_alpha_blend.c
> @@ -447,10 +447,6 @@ static void coverage_premult_constant(data_t *data, enum
> pipe pipe, igt_plane_t
> igt_display_t *display = >display;
> igt_crc_t ref_crc = {}, crc = {};
>
> - /* Set a background color on the primary fb for testing */
> - if (plane->type != DRM_PLANE_TYPE_PRIMARY)
> -
> igt_plane_set_fb(igt_pipe_get_plane_type(>pipes[pipe],
> DRM_PLANE_TYPE_PRIMARY), >gray_fb);
> -
> igt_plane_set_prop_enum(plane, IGT_PLANE_PIXEL_BLEND_MODE,
> "Coverage");
> igt_plane_set_fb(plane, >argb_fb_cov_7e);
> igt_display_commit2(display, COMMIT_ATOMIC);
> --
> 2.7.4
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/9] drm/i915: Add i915_sched_engine_reset_on_empty function
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Rather than touching schedule state in the generic PM code, reset the
> priolist allocation when empty in the submission code. Add a wrapper
> function to do this and update the backends to call it in the correct
> place.
Seems reasonable, I think. I'm by no means an expert but
Reviewed-by: Jason Ekstrand
anyway. My one suggestion would be to tweak the commit message to
talk about the functional change rather than the helper. Something
like
drm/i915: Reset sched_engine.no_priolist immediately after dequeue
Typically patches which say "add a helper function" don't come with a
non-trivial functional change.
--Jason
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_pm.c| 2 --
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 1 +
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 ++
> drivers/gpu/drm/i915/i915_scheduler.h| 7 +++
> 4 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index b6a00dd72808..1f07ac4e0672 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -280,8 +280,6 @@ static int __engine_park(struct intel_wakeref *wf)
> if (engine->park)
> engine->park(engine);
>
> - engine->sched_engine->no_priolist = false;
> -
> /* While gt calls i915_vma_parked(), we have to break the lock cycle
> */
> intel_gt_pm_put_async(engine->gt);
> return 0;
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index 2326a73af6d3..609753b5401a 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -1553,6 +1553,7 @@ static void execlists_dequeue(struct intel_engine_cs
> *engine)
> * interrupt for secondary ports).
> */
> sched_engine->queue_priority_hint = queue_prio(sched_engine);
> + i915_sched_engine_reset_on_empty(sched_engine);
> spin_unlock(>active.lock);
>
> /*
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index 5d00f2e3c1de..f4a6fbfaf82e 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -263,6 +263,8 @@ static void guc_submission_tasklet(struct tasklet_struct
> *t)
>
> __guc_dequeue(engine);
>
> + i915_sched_engine_reset_on_empty(engine->sched_engine);
> +
> spin_unlock_irqrestore(>active.lock, flags);
> }
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
> b/drivers/gpu/drm/i915/i915_scheduler.h
> index 5bec7b3b8456..713c38c99de9 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> @@ -72,6 +72,13 @@ i915_sched_engine_is_empty(struct i915_sched_engine
> *sched_engine)
> return RB_EMPTY_ROOT(_engine->queue.rb_root);
> }
>
> +static inline void
> +i915_sched_engine_reset_on_empty(struct i915_sched_engine *sched_engine)
> +{
> + if (i915_sched_engine_is_empty(sched_engine))
> + sched_engine->no_priolist = false;
> +}
> +
> void i915_request_show_with_schedule(struct drm_printer *m,
> const struct i915_request *rq,
> const char *prefix,
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t] tests/kms_color: Remove gamma code from degamma tests
On Thu, Jun 3, 2021 at 1:04 PM Vidya Srinivas wrote:
>
> CRC should be collected without degamma transformation
> and after drawing gradient with degamma LUT.
> This patch removes things which are not related to degamma
> and makes it similar to pipe gamma test.
>
Tested on ChromeOS on TGL (Delbin) and JSL (Drawlat)
Tested-by: Mark Yacoub
> Signed-off-by: Vidya Srinivas
> ---
> tests/kms_color.c | 16 ++--
> 1 file changed, 6 insertions(+), 10 deletions(-)
>
> diff --git a/tests/kms_color.c b/tests/kms_color.c
> index 3a42532a5c27..2c9821cdecce 100644
> --- a/tests/kms_color.c
> +++ b/tests/kms_color.c
> @@ -31,8 +31,7 @@ static void test_pipe_degamma(data_t *data,
> {
> igt_output_t *output;
> igt_display_t *display = >display;
> - gamma_lut_t *degamma_linear, *degamma_full;
> - gamma_lut_t *gamma_linear;
> + gamma_lut_t *degamma_full;
> color_t red_green_blue[] = {
> { 1.0, 0.0, 0.0 },
> { 0.0, 1.0, 0.0 },
> @@ -42,11 +41,8 @@ static void test_pipe_degamma(data_t *data,
> igt_require(igt_pipe_obj_has_prop(primary->pipe,
> IGT_CRTC_DEGAMMA_LUT));
> igt_require(igt_pipe_obj_has_prop(primary->pipe, IGT_CRTC_GAMMA_LUT));
>
> - degamma_linear = generate_table(data->degamma_lut_size, 1.0);
> degamma_full = generate_table_max(data->degamma_lut_size);
>
> - gamma_linear = generate_table(data->gamma_lut_size, 1.0);
> -
> for_each_valid_output_on_pipe(>display, primary->pipe->pipe,
> output) {
> drmModeModeInfo *mode;
> struct igt_fb fb_modeset, fb;
> @@ -75,8 +71,7 @@ static void test_pipe_degamma(data_t *data,
>
> igt_plane_set_fb(primary, _modeset);
> disable_ctm(primary->pipe);
> - disable_degamma(primary->pipe);
> - set_gamma(data, primary->pipe, gamma_linear);
> + set_degamma(data, primary->pipe, degamma_full);
> igt_display_commit(>display);
>
> /* Draw solid colors with no degamma transformation. */
> @@ -92,7 +87,6 @@ static void test_pipe_degamma(data_t *data,
> */
> paint_gradient_rectangles(data, mode, red_green_blue, );
> igt_plane_set_fb(primary, );
> - set_degamma(data, primary->pipe, degamma_full);
> igt_display_commit(>display);
> igt_wait_for_vblank(data->drm_fd,
>
> display->pipes[primary->pipe->pipe].crtc_offset);
> @@ -105,13 +99,13 @@ static void test_pipe_degamma(data_t *data,
>
> igt_plane_set_fb(primary, NULL);
> igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit2(>display, data->display.is_atomic ?
> + COMMIT_ATOMIC :
> COMMIT_LEGACY);
> igt_remove_fb(data->drm_fd, );
> igt_remove_fb(data->drm_fd, _modeset);
> }
>
> - free_lut(degamma_linear);
> free_lut(degamma_full);
> - free_lut(gamma_linear);
> }
>
> /*
> @@ -191,6 +185,8 @@ static void test_pipe_gamma(data_t *data,
>
> igt_plane_set_fb(primary, NULL);
> igt_output_set_pipe(output, PIPE_NONE);
> + igt_display_commit2(>display, data->display.is_atomic ?
> + COMMIT_ATOMIC :
> COMMIT_LEGACY);
> igt_remove_fb(data->drm_fd, );
> igt_remove_fb(data->drm_fd, _modeset);
> }
> --
> 2.7.4
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/20] drm/i915/guc: Use guc_class instead of engine_class in fw interface
On Fri, Jun 04, 2021 at 10:44:31AM +0200, Daniel Vetter wrote:
> On Wed, Jun 02, 2021 at 10:16:30PM -0700, Matthew Brost wrote:
> > From: Daniele Ceraolo Spurio
> >
> > GuC has its own defines for the engine classes. They're currently
> > mapping 1:1 to the defines used by the driver, but there is no guarantee
> > this will continue in the future. Given that we've been caught off-guard
> > in the past by similar divergences, we can prepare for the changes by
> > introducing helper functions to convert from engine class to GuC class and
> > back again.
> >
> > Signed-off-by: Daniele Ceraolo Spurio
> > Signed-off-by: Matthew Brost
> > Reviewed-by: Matthew Brost
> > Cc: John Harrison
> > Cc: Michal Wajdeczko
>
> Applied all up to this, except the Kconfig one.
>
Thanks, that one isn't really a blocker to next post which will update
the GuC firmware to the latest and greatest version.
Let me look at the issue with that patch now.
Matt
> Thanks, Daniel
>
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++--
> > drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c | 20 +---
> > drivers/gpu/drm/i915/gt/uc/intel_guc_fwif.h | 26 +
> > 3 files changed, 42 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 3f9a811eb02b..69281b5aba51 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -265,6 +265,7 @@ static int intel_engine_setup(struct intel_gt *gt, enum
> > intel_engine_id id)
> > const struct engine_info *info = _engines[id];
> > struct drm_i915_private *i915 = gt->i915;
> > struct intel_engine_cs *engine;
> > + u8 guc_class;
> >
> > BUILD_BUG_ON(MAX_ENGINE_CLASS >= BIT(GEN11_ENGINE_CLASS_WIDTH));
> > BUILD_BUG_ON(MAX_ENGINE_INSTANCE >= BIT(GEN11_ENGINE_INSTANCE_WIDTH));
> > @@ -293,9 +294,10 @@ static int intel_engine_setup(struct intel_gt *gt,
> > enum intel_engine_id id)
> > engine->i915 = i915;
> > engine->gt = gt;
> > engine->uncore = gt->uncore;
> > - engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
> > engine->hw_id = info->hw_id;
> > - engine->guc_id = MAKE_GUC_ID(info->class, info->instance);
> > + guc_class = engine_class_to_guc_class(info->class);
> > + engine->guc_id = MAKE_GUC_ID(guc_class, info->instance);
> > + engine->mmio_base = __engine_mmio_base(i915, info->mmio_bases);
> >
> > engine->irq_handler = nop_irq_handler;
> >
> > diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > index 17526717368c..efdce309b6f1 100644
> > --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_ads.c
> > @@ -6,6 +6,7 @@
> > #include "gt/intel_gt.h"
> > #include "gt/intel_lrc.h"
> > #include "intel_guc_ads.h"
> > +#include "intel_guc_fwif.h"
> > #include "intel_uc.h"
> > #include "i915_drv.h"
> >
> > @@ -104,7 +105,7 @@ static void guc_mapping_table_init(struct intel_gt *gt,
> > GUC_MAX_INSTANCES_PER_CLASS;
> >
> > for_each_engine(engine, gt, id) {
> > - u8 guc_class = engine->class;
> > + u8 guc_class = engine_class_to_guc_class(engine->class);
> >
> > system_info->mapping_table[guc_class][engine->instance] =
> > engine->instance;
> > @@ -124,7 +125,7 @@ static void __guc_ads_init(struct intel_guc *guc)
> > struct __guc_ads_blob *blob = guc->ads_blob;
> > const u32 skipped_size = LRC_PPHWSP_SZ * PAGE_SIZE + LR_HW_CONTEXT_SIZE;
> > u32 base;
> > - u8 engine_class;
> > + u8 engine_class, guc_class;
> >
> > /* GuC scheduling policies */
> > guc_policies_init(>policies);
> > @@ -140,22 +141,25 @@ static void __guc_ads_init(struct intel_guc *guc)
> > for (engine_class = 0; engine_class <= MAX_ENGINE_CLASS;
> > ++engine_class) {
> > if (engine_class == OTHER_CLASS)
> > continue;
> > +
> > + guc_class = engine_class_to_guc_class(engine_class);
> > +
> > /*
> > * TODO: Set context pointer to default state to allow
> > * GuC to re-init guilty contexts after internal reset.
> > */
> > - blob->ads.golden_context_lrca[engine_class] = 0;
> > - blob->ads.eng_state_size[engine_class] =
> > + blob->ads.golden_context_lrca[guc_class] = 0;
> > + blob->ads.eng_state_size[guc_class] =
> > intel_engine_context_size(guc_to_gt(guc),
> > engine_class) -
> > skipped_size;
> > }
> >
> > /* System info */
> > - blob->system_info.engine_enabled_masks[RENDER_CLASS] = 1;
> > - blob->system_info.engine_enabled_masks[COPY_ENGINE_CLASS] = 1;
> > - blob->system_info.engine_enabled_masks[VIDEO_DECODE_CLASS]
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 4, 2021 at 12:59 PM Matthew Brost wrote:
>
> On Fri, Jun 04, 2021 at 12:51:43PM -0500, Jason Ekstrand wrote:
> > On Fri, Jun 4, 2021 at 12:42 PM Matthew Brost
> > wrote:
> > >
> > > On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> > > > On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost
> > > > wrote:
> > > > >
> > > > > Introduce i915_sched_engine object which is lower level data structure
> > > > > that i915_scheduler / generic code can operate on without touching
> > > > > execlist specific structures. This allows additional submission
> > > > > backends
> > > > > to be added without breaking the layering.
> > > > >
> > > > > This is a bit of detour to integrating the i915 with the DRM scheduler
> > > > > but this object will still exist when the DRM scheduler lands in the
> > > > > i915. It will however look a bit different. It will encapsulate the
> > > > > drm_gpu_scheduler object plus and common variables (to the backends)
> > > > > related to scheduling. Regardless this is a step in the right
> > > > > direction.
> > > > >
> > > > > This patch starts the aforementioned transition by moving the the
> > > > > priolist into the i915_sched_engine object.
> > > > >
> > > > > Signed-off-by: Matthew Brost
> > > > > ---
> > > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > > > > .../drm/i915/gt/intel_execlists_submission.c | 81
> > > > > +++
> > > > > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > > > > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > > > > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > > > > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > > > > 9 files changed, 169 insertions(+), 90 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > index 3f9a811eb02b..d0f3814440f6 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct
> > > > > intel_engine_cs *engine)
> > > > > memset(execlists->pending, 0, sizeof(execlists->pending));
> > > > > execlists->active =
> > > > > memset(execlists->inflight, 0,
> > > > > sizeof(execlists->inflight));
> > > > > -
> > > > > - execlists->queue_priority_hint = INT_MIN;
> > > > > - execlists->queue = RB_ROOT_CACHED;
> > > > > }
> > > > >
> > > > > static void cleanup_status_page(struct intel_engine_cs *engine)
> > > > > @@ -712,6 +709,12 @@ static int engine_setup_common(struct
> > > > > intel_engine_cs *engine)
> > > > > goto err_status;
> > > > > }
> > > > >
> > > > > + engine->sched_engine =
> > > > > i915_sched_engine_create(ENGINE_PHYSICAL);
> > > > > + if (!engine->sched_engine) {
> > > > > + err = -ENOMEM;
> > > > > + goto err_sched_engine;
> > > > > + }
> > > > > +
> > > > > err = intel_engine_init_cmd_parser(engine);
> > > > > if (err)
> > > > > goto err_cmd_parser;
> > > > > @@ -735,6 +738,8 @@ static int engine_setup_common(struct
> > > > > intel_engine_cs *engine)
> > > > > return 0;
> > > > >
> > > > > err_cmd_parser:
> > > > > + i915_sched_engine_put(engine->sched_engine);
> > > > > +err_sched_engine:
> > > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > > > err_status:
> > > > > cleanup_status_page(engine);
> > > > > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct
> > > > > intel_engine_cs *engine)
> > > > > GEM_BUG_ON(!list_empty(>active.requests));
> > > > > tasklet_kill(>execlists.tasklet); /* flush the
> > > > > callback */
> > > > >
> > > > > + i915_sched_engine_put(engine->sched_engine);
> > > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > > >
> > > > > intel_engine_fini_retire(engine);
> > > > > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct
> > > > > intel_engine_cs *engine)
> > > > > intel_engine_flush_submission(engine);
> > > > >
> > > > > /* ELSP is empty, but there are ready requests? E.g. after
> > > > > reset */
> > > > > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > > > > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > > > > return false;
> > > > >
> > > > > /* Ring stopped? */
> > > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > > index 47f4397095e5..b6a00dd72808 100644
> > > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > > +++
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: apply WaEnableVGAAccessThroughIOPort as needed
== Series Details == Series: drm/i915: apply WaEnableVGAAccessThroughIOPort as needed URL : https://patchwork.freedesktop.org/series/91017/ State : success == Summary == CI Bug Log - changes from CI_DRM_10171_full -> Patchwork_20284_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_20284_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_persistence@legacy-engines-persistence: - shard-snb: NOTRUN -> [SKIP][1] ([fdo#109271] / [i915#1099]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-snb5/igt@gem_ctx_persiste...@legacy-engines-persistence.html * igt@gem_ctx_ringsize@active@bcs0: - shard-skl: [PASS][2] -> [INCOMPLETE][3] ([i915#3316]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-skl9/igt@gem_ctx_ringsize@act...@bcs0.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-skl5/igt@gem_ctx_ringsize@act...@bcs0.html * igt@gem_ctx_shared@q-in-order: - shard-snb: NOTRUN -> [SKIP][4] ([fdo#109271]) +191 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-snb2/igt@gem_ctx_sha...@q-in-order.html * igt@gem_exec_fair@basic-pace-share@rcs0: - shard-glk: [PASS][5] -> [FAIL][6] ([i915#2842]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk9/igt@gem_exec_fair@basic-pace-sh...@rcs0.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-glk5/igt@gem_exec_fair@basic-pace-sh...@rcs0.html * igt@gem_exec_fair@basic-pace@rcs0: - shard-tglb: [PASS][7] -> [FAIL][8] ([i915#2842]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-tglb7/igt@gem_exec_fair@basic-p...@rcs0.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-tglb2/igt@gem_exec_fair@basic-p...@rcs0.html * igt@gem_huc_copy@huc-copy: - shard-apl: NOTRUN -> [SKIP][9] ([fdo#109271] / [i915#2190]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-apl1/igt@gem_huc_c...@huc-copy.html * igt@gem_mmap_gtt@big-copy-odd: - shard-glk: [PASS][10] -> [FAIL][11] ([i915#307]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-glk2/igt@gem_mmap_...@big-copy-odd.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-glk6/igt@gem_mmap_...@big-copy-odd.html * igt@i915_pm_lpsp@kms-lpsp@kms-lpsp-dp: - shard-kbl: NOTRUN -> [SKIP][12] ([fdo#109271] / [i915#1937]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-kbl3/igt@i915_pm_lpsp@kms-l...@kms-lpsp-dp.html * igt@i915_selftest@live@execlists: - shard-apl: NOTRUN -> [DMESG-FAIL][13] ([i915#3462]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-apl1/igt@i915_selftest@l...@execlists.html * igt@kms_ccs@pipe-c-missing-ccs-buffer: - shard-skl: NOTRUN -> [SKIP][14] ([fdo#109271] / [fdo#111304]) [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-skl4/igt@kms_...@pipe-c-missing-ccs-buffer.html * igt@kms_chamelium@hdmi-crc-multiple: - shard-kbl: NOTRUN -> [SKIP][15] ([fdo#109271] / [fdo#111827]) +3 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-kbl2/igt@kms_chamel...@hdmi-crc-multiple.html * igt@kms_chamelium@hdmi-edid-change-during-suspend: - shard-apl: NOTRUN -> [SKIP][16] ([fdo#109271] / [fdo#111827]) +14 similar issues [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-apl1/igt@kms_chamel...@hdmi-edid-change-during-suspend.html * igt@kms_chamelium@hdmi-hpd-storm-disable: - shard-skl: NOTRUN -> [SKIP][17] ([fdo#109271] / [fdo#111827]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-skl4/igt@kms_chamel...@hdmi-hpd-storm-disable.html * igt@kms_chamelium@hdmi-mode-timings: - shard-snb: NOTRUN -> [SKIP][18] ([fdo#109271] / [fdo#111827]) +11 similar issues [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-snb2/igt@kms_chamel...@hdmi-mode-timings.html * igt@kms_color@pipe-a-ctm-0-75: - shard-skl: [PASS][19] -> [DMESG-WARN][20] ([i915#1982]) +1 similar issue [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/shard-skl5/igt@kms_co...@pipe-a-ctm-0-75.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-skl10/igt@kms_co...@pipe-a-ctm-0-75.html * igt@kms_content_protection@atomic-dpms: - shard-apl: NOTRUN -> [TIMEOUT][21] ([i915#1319]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/shard-apl1/igt@kms_content_protect...@atomic-dpms.html - shard-kbl: NOTRUN ->
Re: [Intel-gfx] [RFC PATCH 64/97] drm/i915/guc: Reset implementation for new GuC interface
On Fri, Jun 04, 2021 at 10:16:14AM +0200, Daniel Vetter wrote:
> On Fri, Jun 4, 2021 at 5:25 AM Matthew Brost wrote:
> >
> > On Wed, Jun 02, 2021 at 03:33:43PM +0100, Tvrtko Ursulin wrote:
> > >
> > > On 06/05/2021 20:14, Matthew Brost wrote:
> > > > Reset implementation for new GuC interface. This is the legacy reset
> > > > implementation which is called when the i915 owns the engine hang check.
> > > > Future patches will offload the engine hang check to GuC but we will
> > > > continue to maintain this legacy path as a fallback and this code path
> > > > is also required if the GuC dies.
> > > >
> > > > With the new GuC interface it is not possible to reset individual
> > > > engines - it is only possible to reset the GPU entirely. This patch
> > > > forces an entire chip reset if any engine hangs.
> > > >
> > > > Cc: John Harrison
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_context.c | 3 +
> > > > drivers/gpu/drm/i915/gt/intel_context_types.h | 7 +
> > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 6 +
> > > > .../drm/i915/gt/intel_execlists_submission.c | 40 ++
> > > > drivers/gpu/drm/i915/gt/intel_gt_pm.c | 6 +-
> > > > drivers/gpu/drm/i915/gt/intel_reset.c | 18 +-
> > > > .../gpu/drm/i915/gt/intel_ring_submission.c | 22 +
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 31 +
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc.c| 16 +-
> > > > drivers/gpu/drm/i915/gt/uc/intel_guc.h| 8 +-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 580 ++
> > > > drivers/gpu/drm/i915/gt/uc/intel_uc.c | 34 +-
> > > > drivers/gpu/drm/i915/gt/uc/intel_uc.h | 3 +
> > > > drivers/gpu/drm/i915/i915_request.c | 41 +-
> > > > drivers/gpu/drm/i915/i915_request.h | 2 +
> > > > 15 files changed, 643 insertions(+), 174 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > index b24a1b7a3f88..2f01437056a8 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context.c
> > > > @@ -392,6 +392,9 @@ intel_context_init(struct intel_context *ce, struct
> > > > intel_engine_cs *engine)
> > > > spin_lock_init(>guc_state.lock);
> > > > INIT_LIST_HEAD(>guc_state.fences);
> > > > + spin_lock_init(>guc_active.lock);
> > > > + INIT_LIST_HEAD(>guc_active.requests);
> > > > +
> > > > ce->guc_id = GUC_INVALID_LRC_ID;
> > > > INIT_LIST_HEAD(>guc_id_link);
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > index 6945963a31ba..b63c8cf7823b 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_context_types.h
> > > > @@ -165,6 +165,13 @@ struct intel_context {
> > > > struct list_head fences;
> > > > } guc_state;
> > > > + struct {
> > > > + /** lock: protects everything in guc_active */
> > > > + spinlock_t lock;
> > > > + /** requests: active requests on this context */
> > > > + struct list_head requests;
> > > > + } guc_active;
> > >
> > > More accounting, yeah, this is more of that where GuC gives with one hand
> > > and takes away with the other. :(
> > >
> >
> > Yep but we probably can drop this once we switch to the DRM scheduler.
> > The drm_gpu_scheduler has a list of jobs and if don't mind searching the
> > whole thing on a reset that will probably work too. I think the only
> > reason we have a per context list is because of feedback I received a
> > a while go saying resets are per context with GuC so keep a list on the
> > context and engine list didn't really fit either. I'll make a to circle
> > back to this when we hook into the DRM scheduler.
>
> Please add a FIXME or similar to the kerneldoc comment for stuff like
> this. We have a lot of things to recheck once the big picture is
> sorted, and it's easy to forget them.
>
Sure, will do in next rev. But I think a lot things like this will come
naturally when we switch over to the DRM scheduler. I didn't quite get
to deleting this list the in my PoC but could clearly see this was no
longer needed and actually have a TODO in the code to delete this.
Matt
> Similar for anything else where we have opens about how to structure
> things once it's cut over.
> -Daniel
>
> >
> > > > +
> > > > /* GuC scheduling state that does not require a lock. */
> > > > atomic_t guc_sched_state_no_lock;
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > index f7b6eed586ce..b84562b2708b 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > > > @@ -432,6 +432,12 @@ struct
Re: [Intel-gfx] [RFC PATCH 2/2] drm/doc/rfc: i915 new parallel submission uAPI plan
On Wed, May 26, 2021 at 04:33:57PM -0700, Matthew Brost wrote:
> Add entry for i915 new parallel submission uAPI plan.
>
> v2:
> (Daniel Vetter):
> - Expand logical order explaination
> - Add dummy header
> - Only allow N BBs in execbuf IOCTL
> - Configure parallel submission per slot not per gem context
> v3:
> (Marcin Ślusarz):
> - Lot's of typos / bad english fixed
> (Tvrtko Ursulin):
> - Consistent pseudo code, clean up wording in descriptions
>
> Cc: Tvrtko Ursulin
> Cc: Tony Ye
> CC: Carl Zhang
> Cc: Daniel Vetter
> Cc: Jason Ekstrand
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/rfc/i915_parallel_execbuf.h | 145 ++
> Documentation/gpu/rfc/i915_scheduler.rst | 55 ++-
> 2 files changed, 198 insertions(+), 2 deletions(-)
> create mode 100644 Documentation/gpu/rfc/i915_parallel_execbuf.h
>
> diff --git a/Documentation/gpu/rfc/i915_parallel_execbuf.h
> b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> new file mode 100644
> index ..20de206e3ab4
> --- /dev/null
> +++ b/Documentation/gpu/rfc/i915_parallel_execbuf.h
> @@ -0,0 +1,145 @@
> +#define I915_CONTEXT_ENGINES_EXT_PARALLEL_SUBMIT 2 /* see
> i915_context_engines_parallel_submit */
> +
> +/*
> + * i915_context_engines_parallel_submit:
So the idea is to make these kerneldoc and pull them into the rfc section.
Then when we merge, move them to the real uapi section, like what Matt has
done for lmem.
> + *
> + * Setup a slot in the context engine map to allow multiple BBs to be
> submitted
> + * in a single execbuf IOCTL. Those BBs will then be scheduled to run on the
> GPU
> + * in parallel. Multiple hardware contexts are created internally in the i915
> + * run these BBs. Once a slot is configured for N BBs only N BBs can be
> + * submitted in each execbuf IOCTL and this is implicit behavior e.g. The
> user
> + * doesn't tell the execbuf IOCTL there are N BBs, the execbuf IOCTL know how
> + * many BBs there are based on the slots configuration. The N BBs are the
> last N
> + * buffer objects for first N if I915_EXEC_BATCH_FIRST is set.
s/for/or/
> + *
> + * There are two currently defined ways to control the placement of the
> + * hardware contexts on physical engines: default behavior (no flags) and
> + * I915_PARALLEL_IMPLICIT_BONDS (a flag). More flags may be added the in the
> + * future as new hardware / use cases arise. Details of how to use this
> + * interface above the flags field in this structure.
> + *
> + * Returns -EINVAL if hardware context placement configuration is invalid or
> if
> + * the placement configuration isn't supported on the platform / submission
> + * interface.
> + * Returns -ENODEV if extension isn't supported on the platform / submission
> + * inteface.
> + */
> +struct i915_context_engines_parallel_submit {
> + struct i915_user_extension base;
> +
> + __u16 engine_index; /* slot for parallel engine */
Kernel doc here for the inline comments too.
> + __u16 width;/* number of contexts per parallel engine */
> + __u16 num_siblings; /* number of siblings per context */
> + __u16 mbz16;
> +/*
> + * Default placement behavior (currently unsupported):
> + *
> + * Allow BBs to be placed on any available engine instance. In this case each
> + * context's engine mask indicates where that context can be placed. It is
> + * implied in this mode that all contexts have mutual exclusive placement.
> + * e.g. If one context is running CSX[0] no other contexts can run on
> CSX[0]).
> + *
> + * Example 1 pseudo code:
> + * CSX,Y[N] = generic engine class X or Y, logical instance N
> + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> + * set_engines(INVALID)
> + * set_parallel(engine_index=0, width=2, num_siblings=2,
> + * engines=CSX[0],CSX[1],CSY[0],CSY[1])
> + *
> + * Results in the following valid placements:
> + * CSX[0], CSY[0]
> + * CSX[0], CSY[1]
> + * CSX[1], CSY[0]
> + * CSX[1], CSY[1]
> + *
> + * This can also be thought of as 2 virtual engines described by 2-D array in
> + * the engines the field:
> + * VE[0] = CSX[0], CSX[1]
> + * VE[1] = CSY[0], CSY[1]
> + *
> + * Example 2 pseudo code:
> + * CSX[Y] = generic engine of same class X, logical instance N
> + * INVALID = I915_ENGINE_CLASS_INVALID, I915_ENGINE_CLASS_INVALID_NONE
> + * set_engines(INVALID)
> + * set_parallel(engine_index=0, width=2, num_siblings=3,
> + * engines=CSX[0],CSX[1],CSX[2],CSX[0],CSX[1],CSX[2])
> + *
> + * Results in the following valid placements:
> + * CSX[0], CSX[1]
> + * CSX[0], CSX[2]
> + * CSX[1], CSX[0]
> + * CSX[1], CSX[2]
> + * CSX[2], CSX[0]
> + * CSX[2], CSX[1]
> + *
> + * This can also be thought of as 2 virtual engines described by 2-D array in
> + * the engines the field:
> + * VE[0] = CSX[0], CSX[1], CSX[2]
> + * VE[1] = CSX[0], CSX[1], CSX[2]
> +
> + * This enables a use case where all engines are created equally, we don't
> care
> + * where they are scheduled, we
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 04, 2021 at 12:51:43PM -0500, Jason Ekstrand wrote:
> On Fri, Jun 4, 2021 at 12:42 PM Matthew Brost wrote:
> >
> > On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> > > On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost
> > > wrote:
> > > >
> > > > Introduce i915_sched_engine object which is lower level data structure
> > > > that i915_scheduler / generic code can operate on without touching
> > > > execlist specific structures. This allows additional submission backends
> > > > to be added without breaking the layering.
> > > >
> > > > This is a bit of detour to integrating the i915 with the DRM scheduler
> > > > but this object will still exist when the DRM scheduler lands in the
> > > > i915. It will however look a bit different. It will encapsulate the
> > > > drm_gpu_scheduler object plus and common variables (to the backends)
> > > > related to scheduling. Regardless this is a step in the right direction.
> > > >
> > > > This patch starts the aforementioned transition by moving the the
> > > > priolist into the i915_sched_engine object.
> > > >
> > > > Signed-off-by: Matthew Brost
> > > > ---
> > > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > > > .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> > > > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > > > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > > > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > > > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > > > 9 files changed, 169 insertions(+), 90 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > index 3f9a811eb02b..d0f3814440f6 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct
> > > > intel_engine_cs *engine)
> > > > memset(execlists->pending, 0, sizeof(execlists->pending));
> > > > execlists->active =
> > > > memset(execlists->inflight, 0,
> > > > sizeof(execlists->inflight));
> > > > -
> > > > - execlists->queue_priority_hint = INT_MIN;
> > > > - execlists->queue = RB_ROOT_CACHED;
> > > > }
> > > >
> > > > static void cleanup_status_page(struct intel_engine_cs *engine)
> > > > @@ -712,6 +709,12 @@ static int engine_setup_common(struct
> > > > intel_engine_cs *engine)
> > > > goto err_status;
> > > > }
> > > >
> > > > + engine->sched_engine =
> > > > i915_sched_engine_create(ENGINE_PHYSICAL);
> > > > + if (!engine->sched_engine) {
> > > > + err = -ENOMEM;
> > > > + goto err_sched_engine;
> > > > + }
> > > > +
> > > > err = intel_engine_init_cmd_parser(engine);
> > > > if (err)
> > > > goto err_cmd_parser;
> > > > @@ -735,6 +738,8 @@ static int engine_setup_common(struct
> > > > intel_engine_cs *engine)
> > > > return 0;
> > > >
> > > > err_cmd_parser:
> > > > + i915_sched_engine_put(engine->sched_engine);
> > > > +err_sched_engine:
> > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > > err_status:
> > > > cleanup_status_page(engine);
> > > > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct
> > > > intel_engine_cs *engine)
> > > > GEM_BUG_ON(!list_empty(>active.requests));
> > > > tasklet_kill(>execlists.tasklet); /* flush the callback
> > > > */
> > > >
> > > > + i915_sched_engine_put(engine->sched_engine);
> > > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > >
> > > > intel_engine_fini_retire(engine);
> > > > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > > > *engine)
> > > > intel_engine_flush_submission(engine);
> > > >
> > > > /* ELSP is empty, but there are ready requests? E.g. after
> > > > reset */
> > > > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > > > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > > > return false;
> > > >
> > > > /* Ring stopped? */
> > > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > index 47f4397095e5..b6a00dd72808 100644
> > > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > > @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> > > > intel_breadcrumbs_park(engine->breadcrumbs);
> > > >
> > > > /* Must be reset upon idling, or we may miss the busy wakeup. */
> > > > -
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 4, 2021 at 12:42 PM Matthew Brost wrote:
>
> On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> > On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost
> > wrote:
> > >
> > > Introduce i915_sched_engine object which is lower level data structure
> > > that i915_scheduler / generic code can operate on without touching
> > > execlist specific structures. This allows additional submission backends
> > > to be added without breaking the layering.
> > >
> > > This is a bit of detour to integrating the i915 with the DRM scheduler
> > > but this object will still exist when the DRM scheduler lands in the
> > > i915. It will however look a bit different. It will encapsulate the
> > > drm_gpu_scheduler object plus and common variables (to the backends)
> > > related to scheduling. Regardless this is a step in the right direction.
> > >
> > > This patch starts the aforementioned transition by moving the the
> > > priolist into the i915_sched_engine object.
> > >
> > > Signed-off-by: Matthew Brost
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > > .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> > > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > > 9 files changed, 169 insertions(+), 90 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > index 3f9a811eb02b..d0f3814440f6 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct
> > > intel_engine_cs *engine)
> > > memset(execlists->pending, 0, sizeof(execlists->pending));
> > > execlists->active =
> > > memset(execlists->inflight, 0,
> > > sizeof(execlists->inflight));
> > > -
> > > - execlists->queue_priority_hint = INT_MIN;
> > > - execlists->queue = RB_ROOT_CACHED;
> > > }
> > >
> > > static void cleanup_status_page(struct intel_engine_cs *engine)
> > > @@ -712,6 +709,12 @@ static int engine_setup_common(struct
> > > intel_engine_cs *engine)
> > > goto err_status;
> > > }
> > >
> > > + engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
> > > + if (!engine->sched_engine) {
> > > + err = -ENOMEM;
> > > + goto err_sched_engine;
> > > + }
> > > +
> > > err = intel_engine_init_cmd_parser(engine);
> > > if (err)
> > > goto err_cmd_parser;
> > > @@ -735,6 +738,8 @@ static int engine_setup_common(struct intel_engine_cs
> > > *engine)
> > > return 0;
> > >
> > > err_cmd_parser:
> > > + i915_sched_engine_put(engine->sched_engine);
> > > +err_sched_engine:
> > > intel_breadcrumbs_free(engine->breadcrumbs);
> > > err_status:
> > > cleanup_status_page(engine);
> > > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct
> > > intel_engine_cs *engine)
> > > GEM_BUG_ON(!list_empty(>active.requests));
> > > tasklet_kill(>execlists.tasklet); /* flush the callback */
> > >
> > > + i915_sched_engine_put(engine->sched_engine);
> > > intel_breadcrumbs_free(engine->breadcrumbs);
> > >
> > > intel_engine_fini_retire(engine);
> > > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > > *engine)
> > > intel_engine_flush_submission(engine);
> > >
> > > /* ELSP is empty, but there are ready requests? E.g. after reset
> > > */
> > > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > > return false;
> > >
> > > /* Ring stopped? */
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > index 47f4397095e5..b6a00dd72808 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > > @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> > > intel_breadcrumbs_park(engine->breadcrumbs);
> > >
> > > /* Must be reset upon idling, or we may miss the busy wakeup. */
> > > - GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
> > > + GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
> > >
> > > if (engine->park)
> > > engine->park(engine);
> > >
> > > - engine->execlists.no_priolist = false;
> > > +
Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add i915_sched_engine_is_empty function
Reviewed-by: Jason Ekstrand
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Add wrapper function around RB tree to determine if i915_sched_engine is
> empty.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c| 2 +-
> drivers/gpu/drm/i915/gt/intel_execlists_submission.c | 6 +++---
> drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c| 2 +-
> drivers/gpu/drm/i915/i915_scheduler.h| 6 ++
> 4 files changed, 11 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index d0f3814440f6..85f2effe9dc6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -1287,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> *engine)
> intel_engine_flush_submission(engine);
>
> /* ELSP is empty, but there are ready requests? E.g. after reset */
> - if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> + if (!i915_sched_engine_is_empty(engine->sched_engine))
> return false;
>
> /* Ring stopped? */
> diff --git a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> index d1dc1db3e378..2326a73af6d3 100644
> --- a/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> +++ b/drivers/gpu/drm/i915/gt/intel_execlists_submission.c
> @@ -384,7 +384,7 @@ __unwind_incomplete_requests(struct intel_engine_cs
> *engine)
> prio = rq_prio(rq);
> pl = i915_sched_lookup_priolist(engine, prio);
> }
> -
> GEM_BUG_ON(RB_EMPTY_ROOT(>sched_engine->queue.rb_root));
> + GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
>
> list_move(>sched.link, pl);
> set_bit(I915_FENCE_FLAG_PQUEUE, >fence.flags);
> @@ -1139,7 +1139,7 @@ static bool needs_timeslice(const struct
> intel_engine_cs *engine,
> }
>
> /* Otherwise, ELSP[0] is by itself, but may be waiting in the queue */
> - if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root)) {
> + if (!i915_sched_engine_is_empty(engine->sched_engine)) {
> ENGINE_TRACE(engine, "timeslice required for queue\n");
> return true;
> }
> @@ -2487,7 +2487,7 @@ static void execlists_submit_request(struct
> i915_request *request)
> } else {
> queue_request(engine, request);
>
> -
> GEM_BUG_ON(RB_EMPTY_ROOT(>sched_engine->queue.rb_root));
> + GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
> GEM_BUG_ON(list_empty(>sched.link));
>
> if (submit_queue(engine, request))
> diff --git a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> index d42dea79ee64..5d00f2e3c1de 100644
> --- a/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> +++ b/drivers/gpu/drm/i915/gt/uc/intel_guc_submission.c
> @@ -541,7 +541,7 @@ static void guc_submit_request(struct i915_request *rq)
>
> queue_request(engine, rq, rq_prio(rq));
>
> - GEM_BUG_ON(RB_EMPTY_ROOT(>sched_engine->queue.rb_root));
> + GEM_BUG_ON(i915_sched_engine_is_empty(engine->sched_engine));
> GEM_BUG_ON(list_empty(>sched.link));
>
> tasklet_hi_schedule(>execlists.tasklet);
> diff --git a/drivers/gpu/drm/i915/i915_scheduler.h
> b/drivers/gpu/drm/i915/i915_scheduler.h
> index 91a04e34cac5..5bec7b3b8456 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler.h
> @@ -66,6 +66,12 @@ i915_sched_engine_put(struct i915_sched_engine
> *sched_engine)
> kref_put(_engine->ref, i915_sched_engine_free);
> }
>
> +static inline bool
> +i915_sched_engine_is_empty(struct i915_sched_engine *sched_engine)
> +{
> + return RB_EMPTY_ROOT(_engine->queue.rb_root);
> +}
> +
> void i915_request_show_with_schedule(struct drm_printer *m,
> const struct i915_request *rq,
> const char *prefix,
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 00/15] Restricted DMA
Hi Claire, On Thu, May 27, 2021 at 08:58:30PM +0800, Claire Chang wrote: > This series implements mitigations for lack of DMA access control on > systems without an IOMMU, which could result in the DMA accessing the > system memory at unexpected times and/or unexpected addresses, possibly > leading to data leakage or corruption. > > For example, we plan to use the PCI-e bus for Wi-Fi and that PCI-e bus is > not behind an IOMMU. As PCI-e, by design, gives the device full access to > system memory, a vulnerability in the Wi-Fi firmware could easily escalate > to a full system exploit (remote wifi exploits: [1a], [1b] that shows a > full chain of exploits; [2], [3]). > > To mitigate the security concerns, we introduce restricted DMA. Restricted > DMA utilizes the existing swiotlb to bounce streaming DMA in and out of a > specially allocated region and does memory allocation from the same region. > The feature on its own provides a basic level of protection against the DMA > overwriting buffer contents at unexpected times. However, to protect > against general data leakage and system memory corruption, the system needs > to provide a way to restrict the DMA to a predefined memory region (this is > usually done at firmware level, e.g. MPU in ATF on some ARM platforms [4]). > > [1a] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_4.html > [1b] > https://googleprojectzero.blogspot.com/2017/04/over-air-exploiting-broadcoms-wi-fi_11.html > [2] https://blade.tencent.com/en/advisories/qualpwn/ > [3] > https://www.bleepingcomputer.com/news/security/vulnerabilities-found-in-highly-popular-firmware-for-wifi-chips/ > [4] > https://github.com/ARM-software/arm-trusted-firmware/blob/master/plat/mediatek/mt8183/drivers/emi_mpu/emi_mpu.c#L132 > > v8: > - Fix reserved-memory.txt and add the reg property in example. > - Fix sizeof for of_property_count_elems_of_size in > drivers/of/address.c#of_dma_set_restricted_buffer. > - Apply Will's suggestion to try the OF node having DMA configuration in > drivers/of/address.c#of_dma_set_restricted_buffer. > - Fix typo in the comment of > drivers/of/address.c#of_dma_set_restricted_buffer. > - Add error message for PageHighMem in > kernel/dma/swiotlb.c#rmem_swiotlb_device_init and move it to > rmem_swiotlb_setup. > - Fix the message string in rmem_swiotlb_setup. Thanks for the v8. It works for me out of the box on arm64 under KVM, so: Tested-by: Will Deacon Note that something seems to have gone wrong with the mail threading, so the last 5 patches ended up as a separate thread for me. Probably worth posting again with all the patches in one place, if you can. Cheers, Will ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Fri, Jun 04, 2021 at 12:38:22PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Introduce i915_sched_engine object which is lower level data structure
> > that i915_scheduler / generic code can operate on without touching
> > execlist specific structures. This allows additional submission backends
> > to be added without breaking the layering.
> >
> > This is a bit of detour to integrating the i915 with the DRM scheduler
> > but this object will still exist when the DRM scheduler lands in the
> > i915. It will however look a bit different. It will encapsulate the
> > drm_gpu_scheduler object plus and common variables (to the backends)
> > related to scheduling. Regardless this is a step in the right direction.
> >
> > This patch starts the aforementioned transition by moving the the
> > priolist into the i915_sched_engine object.
> >
> > Signed-off-by: Matthew Brost
> > ---
> > drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> > drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> > drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> > .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> > drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> > .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> > drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> > drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> > 9 files changed, 169 insertions(+), 90 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > index 3f9a811eb02b..d0f3814440f6 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> > @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
> > *engine)
> > memset(execlists->pending, 0, sizeof(execlists->pending));
> > execlists->active =
> > memset(execlists->inflight, 0, sizeof(execlists->inflight));
> > -
> > - execlists->queue_priority_hint = INT_MIN;
> > - execlists->queue = RB_ROOT_CACHED;
> > }
> >
> > static void cleanup_status_page(struct intel_engine_cs *engine)
> > @@ -712,6 +709,12 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > goto err_status;
> > }
> >
> > + engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
> > + if (!engine->sched_engine) {
> > + err = -ENOMEM;
> > + goto err_sched_engine;
> > + }
> > +
> > err = intel_engine_init_cmd_parser(engine);
> > if (err)
> > goto err_cmd_parser;
> > @@ -735,6 +738,8 @@ static int engine_setup_common(struct intel_engine_cs
> > *engine)
> > return 0;
> >
> > err_cmd_parser:
> > + i915_sched_engine_put(engine->sched_engine);
> > +err_sched_engine:
> > intel_breadcrumbs_free(engine->breadcrumbs);
> > err_status:
> > cleanup_status_page(engine);
> > @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
> > *engine)
> > GEM_BUG_ON(!list_empty(>active.requests));
> > tasklet_kill(>execlists.tasklet); /* flush the callback */
> >
> > + i915_sched_engine_put(engine->sched_engine);
> > intel_breadcrumbs_free(engine->breadcrumbs);
> >
> > intel_engine_fini_retire(engine);
> > @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> > *engine)
> > intel_engine_flush_submission(engine);
> >
> > /* ELSP is empty, but there are ready requests? E.g. after reset */
> > - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> > + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> > return false;
> >
> > /* Ring stopped? */
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > index 47f4397095e5..b6a00dd72808 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> > @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> > intel_breadcrumbs_park(engine->breadcrumbs);
> >
> > /* Must be reset upon idling, or we may miss the busy wakeup. */
> > - GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
> > + GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
> >
> > if (engine->park)
> > engine->park(engine);
> >
> > - engine->execlists.no_priolist = false;
> > + engine->sched_engine->no_priolist = false;
> >
> > /* While gt calls i915_vma_parked(), we have to break the lock
> > cycle */
> > intel_gt_pm_put_async(engine->gt);
> > diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> > index
Re: [Intel-gfx] [RFC PATCH 1/2] drm/doc/rfc: i915 GuC submission / DRM scheduler
On Wed, May 26, 2021 at 04:33:56PM -0700, Matthew Brost wrote: > Add entry for i915 GuC submission / DRM scheduler integration plan. > Follow up patch with details of new parallel submission uAPI to come. > > v2: > (Daniel Vetter) > - Expand explaination of why bonding isn't supported for GuC > submission > - CC some of the DRM scheduler maintainers > - Add priority inheritance / boosting use case > - Add reasoning for removing in order assumptions > (Daniel Stone) > - Add links to priority spec > > Cc: Christian König > Cc: Luben Tuikov > Cc: Alex Deucher > Cc: Steven Price > Cc: Jon Bloomfield > Cc: Jason Ekstrand > Cc: Dave Airlie > Cc: Daniel Vetter > Cc: Jason Ekstrand > Cc: dri-de...@lists.freedesktop.org > Signed-off-by: Matthew Brost You have a one-line hunk in the next patch that probably should be here. With that moved. Reviewed-by: Daniel Vetter Also did you get an ack from Carl on these? -Daniel > --- > Documentation/gpu/rfc/i915_scheduler.rst | 85 > Documentation/gpu/rfc/index.rst | 4 ++ > 2 files changed, 89 insertions(+) > create mode 100644 Documentation/gpu/rfc/i915_scheduler.rst > > diff --git a/Documentation/gpu/rfc/i915_scheduler.rst > b/Documentation/gpu/rfc/i915_scheduler.rst > new file mode 100644 > index ..7faa46cde088 > --- /dev/null > +++ b/Documentation/gpu/rfc/i915_scheduler.rst > @@ -0,0 +1,85 @@ > += > +I915 GuC Submission/DRM Scheduler Section > += > + > +Upstream plan > += > +For upstream the overall plan for landing GuC submission and integrating the > +i915 with the DRM scheduler is: > + > +* Merge basic GuC submission > + * Basic submission support for all gen11+ platforms > + * Not enabled by default on any current platforms but can be enabled via > + modparam enable_guc > + * Lots of rework will need to be done to integrate with DRM scheduler so > + no need to nit pick everything in the code, it just should be > + functional, no major coding style / layering errors, and not regress > + execlists > + * Update IGTs / selftests as needed to work with GuC submission > + * Enable CI on supported platforms for a baseline > + * Rework / get CI heathly for GuC submission in place as needed > +* Merge new parallel submission uAPI > + * Bonding uAPI completely incompatible with GuC submission, plus it has > + severe design issues in general, which is why we want to retire it no > + matter what > + * New uAPI adds I915_CONTEXT_ENGINES_EXT_PARALLEL context setup step > + which configures a slot with N contexts > + * After I915_CONTEXT_ENGINES_EXT_PARALLEL a user can submit N batches to > + a slot in a single execbuf IOCTL and the batches run on the GPU in > + paralllel > + * Initially only for GuC submission but execlists can be supported if > + needed > +* Convert the i915 to use the DRM scheduler > + * GuC submission backend fully integrated with DRM scheduler > + * All request queues removed from backend (e.g. all backpressure > + handled in DRM scheduler) > + * Resets / cancels hook in DRM scheduler > + * Watchdog hooks into DRM scheduler > + * Lots of complexity of the GuC backend can be pulled out once > + integrated with DRM scheduler (e.g. state machine gets > + simplier, locking gets simplier, etc...) > + * Execlist backend will do the minimum required to hook in the DRM > + scheduler so it can live next to the fully integrated GuC backend > + * Legacy interface > + * Features like timeslicing / preemption / virtual engines would > + be difficult to integrate with the DRM scheduler and these > + features are not required for GuC submission as the GuC does > + these things for us > + * ROI low on fully integrating into DRM scheduler > + * Fully integrating would add lots of complexity to DRM > + scheduler > + * Port i915 priority inheritance / boosting feature in DRM scheduler > + * Used for i915 page flip, may be useful to other DRM drivers as > + well > + * Will be an optional feature in the DRM scheduler > + * Remove in-order completion assumptions from DRM scheduler > + * Even when using the DRM scheduler the backends will handle > + preemption, timeslicing, etc... so it is possible for jobs to > + finish out of order > + * Pull out i915 priority levels and use DRM priority levels > + * Optimize DRM scheduler as needed > + > +New uAPI for basic GuC submission > += > +No major changes are required to the uAPI for basic GuC submission. The only > +change is a new
Re: [Intel-gfx] [PATCH 1/9] drm/i915: Move priolist to new i915_sched_engine object
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Introduce i915_sched_engine object which is lower level data structure
> that i915_scheduler / generic code can operate on without touching
> execlist specific structures. This allows additional submission backends
> to be added without breaking the layering.
>
> This is a bit of detour to integrating the i915 with the DRM scheduler
> but this object will still exist when the DRM scheduler lands in the
> i915. It will however look a bit different. It will encapsulate the
> drm_gpu_scheduler object plus and common variables (to the backends)
> related to scheduling. Regardless this is a step in the right direction.
>
> This patch starts the aforementioned transition by moving the the
> priolist into the i915_sched_engine object.
>
> Signed-off-by: Matthew Brost
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 14 +++-
> drivers/gpu/drm/i915/gt/intel_engine_pm.c | 4 +-
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 30 +--
> .../drm/i915/gt/intel_execlists_submission.c | 81 +++
> drivers/gpu/drm/i915/gt/mock_engine.c | 9 ++-
> .../gpu/drm/i915/gt/uc/intel_guc_submission.c | 19 ++---
> drivers/gpu/drm/i915/i915_scheduler.c | 51 +---
> drivers/gpu/drm/i915/i915_scheduler.h | 18 +
> drivers/gpu/drm/i915/i915_scheduler_types.h | 33
> 9 files changed, 169 insertions(+), 90 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index 3f9a811eb02b..d0f3814440f6 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -583,9 +583,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
> *engine)
> memset(execlists->pending, 0, sizeof(execlists->pending));
> execlists->active =
> memset(execlists->inflight, 0, sizeof(execlists->inflight));
> -
> - execlists->queue_priority_hint = INT_MIN;
> - execlists->queue = RB_ROOT_CACHED;
> }
>
> static void cleanup_status_page(struct intel_engine_cs *engine)
> @@ -712,6 +709,12 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> goto err_status;
> }
>
> + engine->sched_engine = i915_sched_engine_create(ENGINE_PHYSICAL);
> + if (!engine->sched_engine) {
> + err = -ENOMEM;
> + goto err_sched_engine;
> + }
> +
> err = intel_engine_init_cmd_parser(engine);
> if (err)
> goto err_cmd_parser;
> @@ -735,6 +738,8 @@ static int engine_setup_common(struct intel_engine_cs
> *engine)
> return 0;
>
> err_cmd_parser:
> + i915_sched_engine_put(engine->sched_engine);
> +err_sched_engine:
> intel_breadcrumbs_free(engine->breadcrumbs);
> err_status:
> cleanup_status_page(engine);
> @@ -958,6 +963,7 @@ void intel_engine_cleanup_common(struct intel_engine_cs
> *engine)
> GEM_BUG_ON(!list_empty(>active.requests));
> tasklet_kill(>execlists.tasklet); /* flush the callback */
>
> + i915_sched_engine_put(engine->sched_engine);
> intel_breadcrumbs_free(engine->breadcrumbs);
>
> intel_engine_fini_retire(engine);
> @@ -1281,7 +1287,7 @@ bool intel_engine_is_idle(struct intel_engine_cs
> *engine)
> intel_engine_flush_submission(engine);
>
> /* ELSP is empty, but there are ready requests? E.g. after reset */
> - if (!RB_EMPTY_ROOT(>execlists.queue.rb_root))
> + if (!RB_EMPTY_ROOT(>sched_engine->queue.rb_root))
> return false;
>
> /* Ring stopped? */
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> index 47f4397095e5..b6a00dd72808 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
> @@ -275,12 +275,12 @@ static int __engine_park(struct intel_wakeref *wf)
> intel_breadcrumbs_park(engine->breadcrumbs);
>
> /* Must be reset upon idling, or we may miss the busy wakeup. */
> - GEM_BUG_ON(engine->execlists.queue_priority_hint != INT_MIN);
> + GEM_BUG_ON(engine->sched_engine->queue_priority_hint != INT_MIN);
>
> if (engine->park)
> engine->park(engine);
>
> - engine->execlists.no_priolist = false;
> + engine->sched_engine->no_priolist = false;
>
> /* While gt calls i915_vma_parked(), we have to break the lock cycle
> */
> intel_gt_pm_put_async(engine->gt);
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> index 9ef349cd5cea..86b41ddec373 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_types.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_types.h
> @@ -59,6 +59,7 @@ struct drm_i915_reg_table;
> struct i915_gem_context;
> struct i915_request;
> struct i915_sched_attr;
> +struct i915_sched_engine;
>
Re: [Intel-gfx] [PATCH 9/9] drm/i915/doc: Add kernel doc for i915_sched_engine
On Fri, Jun 04, 2021 at 12:20:36PM -0500, Jason Ekstrand wrote:
> On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
> >
> > Signed-off-by: Matthew Brost
> > ---
> > Documentation/gpu/i915.rst | 6
> > drivers/gpu/drm/i915/i915_scheduler_types.h | 37 ++---
> > 2 files changed, 38 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> > index 42ce0196930a..8f4f5471a05b 100644
> > --- a/Documentation/gpu/i915.rst
> > +++ b/Documentation/gpu/i915.rst
> > @@ -425,6 +425,12 @@ User Batchbuffer Execution
> > .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> > :doc: User command execution
> >
> > +Scheduling
> > +--
> > +.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h
> > + :functions: i915_sched_engine
> > +
> > +
> > Logical Rings, Logical Ring Contexts and Execlists
> > --
> >
> > diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
> > b/drivers/gpu/drm/i915/i915_scheduler_types.h
> > index 9d79514450de..e3da7517853f 100644
> > --- a/drivers/gpu/drm/i915/i915_scheduler_types.h
> > +++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
> > @@ -91,7 +91,21 @@ struct i915_dependency {
> > &(rq__)->sched.signalers_list, \
> > signal_link)
> >
> > +/**
> > + * sturct i915_sched_engine - scheduler engine
> > + *
> > + * A schedule engine represents a submission queue with different priority
> > + * bands. It contains all the common state (relative to the backend) to
> > queue,
> > + * track, and submit a request.
> > + *
> > + * This object at the moment is quite i915 specific but will transition
> > into a
> > + * container for the drm_gpu_scheduler plus a few other variables once the
> > i915
> > + * is integrated with the DRM scheduler.
> > + */
>
> Why is this its own patch? The above comment would be nice to have in
> patch 1/9 and the kref could be documented there too.
>
I thought it make the review easier? Either way, can squash this patch into the
previous 8 as needed in next rev.
Matt
> > struct i915_sched_engine {
> > + /**
> > +* @ref: reference count of schedule engine object
> > +*/
> > struct kref ref;
> >
> > /**
> > @@ -100,11 +114,18 @@ struct i915_sched_engine {
> > */
> > spinlock_t lock;
> >
> > + /**
> > +* @requests: list of requests inflight on this schedule engine
> > +*/
> > struct list_head requests;
> > - struct list_head hold; /* ready requests, but on hold */
> >
> > /**
> > -* @tasklet: softirq tasklet for bottom handler
> > +* @hold: list of requests on hold.
> > +*/
> > + struct list_head hold;
> > +
> > + /**
> > +* @tasklet: softirq tasklet for submission
> > */
> > struct tasklet_struct tasklet;
> >
> > @@ -137,14 +158,20 @@ struct i915_sched_engine {
> > */
> > bool no_priolist;
> >
> > - /* Back pointer to engine */
> > + /**
> > +* @engine: back pointer to engine
> > +*/
> > struct intel_engine_cs *engine;
> >
> > - /* Kick backend */
> > + /**
> > +* @kick_backed: kick back after a request's priority has changed
> > +*/
> > void(*kick_backend)(const struct i915_request *rq,
> > int prio);
> >
> > - /*
> > + /**
> > +* @schedule: schedule function to adjust priority of request
> > +*
> > * Call when the priority on a request has changed and it and its
> > * dependencies may need rescheduling. Note the request itself may
> > * not be ready to run!
> > --
> > 2.28.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property
On Fri, Jun 04, 2021 at 07:17:23PM +0200, Werner Sembach wrote:
> This commits implements the "active bpc" drm property for the Intel GPU
> driver.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 13 +
> drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
> drivers/gpu/drm/i915/display/intel_hdmi.c| 4 +++-
> 4 files changed, 25 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 64e9107d70f7..f7898d9d7438 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> struct drm_i915_private *dev_priv = to_i915(dev);
> struct intel_crtc_state *new_crtc_state, *old_crtc_state;
> struct intel_crtc *crtc;
> + struct drm_connector *connector;
> + struct drm_connector_state *new_conn_state;
> u64 put_domains[I915_MAX_PIPES] = {};
> intel_wakeref_t wakeref = 0;
> int i;
> @@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct
> intel_atomic_state *state)
> }
> intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
>
> + /* Extract information from crtc to communicate it to userspace as
> connector properties */
> + for_each_new_connector_in_state(>base, connector,
> new_conn_state, i) {
> + struct drm_crtc *crtc = new_conn_state->crtc;
> + if (crtc) {
> + new_crtc_state =
> to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));
intel_atomic_get_new_crtc_state()
> + new_conn_state->active_bpc = new_crtc_state->pipe_bpp /
> 3;
> + }
> + else
> + new_conn_state->active_bpc = 0;
> + }
This also seems too late. I think the whole thing should be
done somewhere around the normal swap_state() stuff.
> +
> /*
>* Defer the cleanup of the old state to a separate worker to not
>* impede the current task (userspace for blocking modesets) that
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 642c60f3d9b1..67826ba976ed 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
> struct drm_connector *connect
> intel_attach_force_audio_property(connector);
>
> intel_attach_broadcast_rgb_property(connector);
> - if (HAS_GMCH(dev_priv))
> + if (HAS_GMCH(dev_priv)) {
> drm_connector_attach_max_bpc_property(connector, 6, 10);
> - else if (DISPLAY_VER(dev_priv) >= 5)
> + drm_connector_attach_active_bpc_property(connector, 6, 10);
> + }
> + else if (DISPLAY_VER(dev_priv) >= 5) {
> drm_connector_attach_max_bpc_property(connector, 6, 12);
> + drm_connector_attach_active_bpc_property(connector, 6, 12);
> + }
>
> /* Register HDMI colorspace for case of lspcon */
> if (intel_bios_is_lspcon_present(dev_priv, port)) {
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 2daa3f67791e..5a1869dc2210 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -844,8 +844,10 @@ static struct drm_connector
> *intel_dp_add_mst_connector(struct drm_dp_mst_topolo
>*/
> connector->max_bpc_property =
> intel_dp->attached_connector->base.max_bpc_property;
> - if (connector->max_bpc_property)
> + if (connector->max_bpc_property) {
> drm_connector_attach_max_bpc_property(connector, 6, 12);
> + drm_connector_attach_active_bpc_property(connector, 6, 12);
> + }
>
> return connector;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
> b/drivers/gpu/drm/i915/display/intel_hdmi.c
> index d69f0a6dc26d..8af78b27b6ce 100644
> --- a/drivers/gpu/drm/i915/display/intel_hdmi.c
> +++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
> @@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi
> *intel_hdmi, struct drm_connector *c
> drm_object_attach_property(>base,
>
> connector->dev->mode_config.hdr_output_metadata_property, 0);
>
> - if (!HAS_GMCH(dev_priv))
> + if (!HAS_GMCH(dev_priv)) {
> drm_connector_attach_max_bpc_property(connector, 8, 12);
> + drm_connector_attach_active_bpc_property(connector, 8, 12);
> + }
> }
>
> /*
> --
> 2.25.1
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
On Fri, Jun 04, 2021 at 07:17:21PM +0200, Werner Sembach wrote:
> Add a new general drm property "active bpc" which can be used by graphic
> drivers
> to report the applied bit depth per pixel back to userspace.
>
> While "max bpc" can be used to change the color depth, there was no way to
> check
> which one actually got used. While in theory the driver chooses the
> best/highest
> color depth within the max bpc setting a user might not be fully aware what
> his
> hardware is or isn't capable off. This is meant as a quick way to double check
> the setup.
>
> In the future, automatic color calibration for screens might also depend on
> this
> information available.
>
> Signed-off-by: Werner Sembach
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 ++
> drivers/gpu/drm/drm_connector.c | 40 +++
> include/drm/drm_connector.h | 15
> 3 files changed, 57 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 268bb69c2e2f..7ae4e40936b5 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector
> *connector,
> *val = 0;
> } else if (property == connector->max_bpc_property) {
> *val = state->max_requested_bpc;
> + } else if (property == connector->active_bpc_property) {
> + *val = state->active_bpc;
> } else if (connector->funcs->atomic_get_property) {
> return connector->funcs->atomic_get_property(connector,
> state, property, val);
> diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
> index 7631f76e7f34..5f42a5be5822 100644
> --- a/drivers/gpu/drm/drm_connector.c
> +++ b/drivers/gpu/drm/drm_connector.c
> @@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list
> dp_colorspaces[] = {
> * drm_connector_attach_max_bpc_property() to create and attach the
> * property to the connector during initialization.
> *
> + * active bpc:
> + * This read-only range property is used by userspace check the bit depth
> + * actually applied by the GPU driver after evaluation all hardware
> + * capabilities and max bpc. Drivers to use the function
> + * drm_connector_attach_active_bpc_property() to create and attach the
> + * property to the connector during initialization.
> + *
> * Connectors also have one standardized atomic property:
> *
> * CRTC_ID:
> @@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct
> drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
>
> +/**
> + * drm_connector_attach_active_bpc_property - attach "active bpc" property
> + * @connector: connector to attach active bpc property on.
> + * @min: The minimum bit depth supported by the connector.
> + * @max: The maximum bit depth supported by the connector.
> + *
> + * This is used to check the applied bit depth on a connector.
> + *
> + * Returns:
> + * Zero on success, negative errno on failure.
> + */
> +int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
> + int min, int max)
> +{
> + struct drm_device *dev = connector->dev;
> + struct drm_property *prop;
> +
> + prop = connector->active_bpc_property;
> + if (!prop) {
> + prop = drm_property_create_range(dev, 0, "active bpc", min,
> max);
Should be immutable.
Also wondering what the semantics of this should be when eg. DSC
is active?
> + if (!prop)
> + return -ENOMEM;
> +
> + connector->active_bpc_property = prop;
> + }
> +
> + drm_object_attach_property(>base, prop, 0);
> + connector->state->active_bpc = 0;
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
> +
> /**
> * drm_connector_set_vrr_capable_property - sets the variable refresh rate
> * capable property for a connector
> diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
> index 1922b278ffad..c58cba2b6afe 100644
> --- a/include/drm/drm_connector.h
> +++ b/include/drm/drm_connector.h
> @@ -781,6 +781,13 @@ struct drm_connector_state {
>*/
> u8 max_bpc;
>
> + /**
> + * @active_bpc: Read only property set by the GPU driver to the actually
> + * applied bit depth of the pixels after evaluating all hardware
> + * limitations.
> + */
> + u8 active_bpc;
> +
> /**
>* @hdr_output_metadata:
>* DRM blob property for HDR output metadata
> @@ -1380,6 +1387,12 @@ struct drm_connector {
>*/
> struct drm_property *max_bpc_property;
>
> + /**
> + * @active_bpc_property: Default connector property for the active bpc
> + * to be driven out of the connector.
> + */
> + struct drm_property *active_bpc_property;
> +
>
[Intel-gfx] ✗ Fi.CI.BUILD: failure for Add "activ bpc" drm property and use it in AMD and Intel driver
== Series Details == Series: Add "activ bpc" drm property and use it in AMD and Intel driver URL : https://patchwork.freedesktop.org/series/91026/ State : failure == Summary == Applying: drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc Applying: drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_atomic_uapi.c M drivers/gpu/drm/drm_connector.c M include/drm/drm_connector.h Falling back to patching base and 3-way merge... Auto-merging include/drm/drm_connector.h Auto-merging drivers/gpu/drm/drm_connector.c CONFLICT (content): Merge conflict in drivers/gpu/drm/drm_connector.c Auto-merging drivers/gpu/drm/drm_atomic_uapi.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0002 drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 9/9] drm/i915/doc: Add kernel doc for i915_sched_engine
On Thu, Jun 3, 2021 at 4:09 PM Matthew Brost wrote:
>
> Signed-off-by: Matthew Brost
> ---
> Documentation/gpu/i915.rst | 6
> drivers/gpu/drm/i915/i915_scheduler_types.h | 37 ++---
> 2 files changed, 38 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst
> index 42ce0196930a..8f4f5471a05b 100644
> --- a/Documentation/gpu/i915.rst
> +++ b/Documentation/gpu/i915.rst
> @@ -425,6 +425,12 @@ User Batchbuffer Execution
> .. kernel-doc:: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
> :doc: User command execution
>
> +Scheduling
> +--
> +.. kernel-doc:: drivers/gpu/drm/i915/i915_scheduler_types.h
> + :functions: i915_sched_engine
> +
> +
> Logical Rings, Logical Ring Contexts and Execlists
> --
>
> diff --git a/drivers/gpu/drm/i915/i915_scheduler_types.h
> b/drivers/gpu/drm/i915/i915_scheduler_types.h
> index 9d79514450de..e3da7517853f 100644
> --- a/drivers/gpu/drm/i915/i915_scheduler_types.h
> +++ b/drivers/gpu/drm/i915/i915_scheduler_types.h
> @@ -91,7 +91,21 @@ struct i915_dependency {
> &(rq__)->sched.signalers_list, \
> signal_link)
>
> +/**
> + * sturct i915_sched_engine - scheduler engine
> + *
> + * A schedule engine represents a submission queue with different priority
> + * bands. It contains all the common state (relative to the backend) to
> queue,
> + * track, and submit a request.
> + *
> + * This object at the moment is quite i915 specific but will transition into
> a
> + * container for the drm_gpu_scheduler plus a few other variables once the
> i915
> + * is integrated with the DRM scheduler.
> + */
Why is this its own patch? The above comment would be nice to have in
patch 1/9 and the kref could be documented there too.
> struct i915_sched_engine {
> + /**
> +* @ref: reference count of schedule engine object
> +*/
> struct kref ref;
>
> /**
> @@ -100,11 +114,18 @@ struct i915_sched_engine {
> */
> spinlock_t lock;
>
> + /**
> +* @requests: list of requests inflight on this schedule engine
> +*/
> struct list_head requests;
> - struct list_head hold; /* ready requests, but on hold */
>
> /**
> -* @tasklet: softirq tasklet for bottom handler
> +* @hold: list of requests on hold.
> +*/
> + struct list_head hold;
> +
> + /**
> +* @tasklet: softirq tasklet for submission
> */
> struct tasklet_struct tasklet;
>
> @@ -137,14 +158,20 @@ struct i915_sched_engine {
> */
> bool no_priolist;
>
> - /* Back pointer to engine */
> + /**
> +* @engine: back pointer to engine
> +*/
> struct intel_engine_cs *engine;
>
> - /* Kick backend */
> + /**
> +* @kick_backed: kick back after a request's priority has changed
> +*/
> void(*kick_backend)(const struct i915_request *rq,
> int prio);
>
> - /*
> + /**
> +* @schedule: schedule function to adjust priority of request
> +*
> * Call when the priority on a request has changed and it and its
> * dependencies may need rescheduling. Note the request itself may
> * not be ready to run!
> --
> 2.28.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/uAPI: Add "active bpc" as feedback channel for "max bpc" drm property
Add a new general drm property "active bpc" which can be used by graphic drivers
to report the applied bit depth per pixel back to userspace.
While "max bpc" can be used to change the color depth, there was no way to check
which one actually got used. While in theory the driver chooses the best/highest
color depth within the max bpc setting a user might not be fully aware what his
hardware is or isn't capable off. This is meant as a quick way to double check
the setup.
In the future, automatic color calibration for screens might also depend on this
information available.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 ++
drivers/gpu/drm/drm_connector.c | 40 +++
include/drm/drm_connector.h | 15
3 files changed, 57 insertions(+)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 268bb69c2e2f..7ae4e40936b5 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -873,6 +873,8 @@ drm_atomic_connector_get_property(struct drm_connector
*connector,
*val = 0;
} else if (property == connector->max_bpc_property) {
*val = state->max_requested_bpc;
+ } else if (property == connector->active_bpc_property) {
+ *val = state->active_bpc;
} else if (connector->funcs->atomic_get_property) {
return connector->funcs->atomic_get_property(connector,
state, property, val);
diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 7631f76e7f34..5f42a5be5822 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -1195,6 +1195,13 @@ static const struct drm_prop_enum_list dp_colorspaces[]
= {
* drm_connector_attach_max_bpc_property() to create and attach the
* property to the connector during initialization.
*
+ * active bpc:
+ * This read-only range property is used by userspace check the bit depth
+ * actually applied by the GPU driver after evaluation all hardware
+ * capabilities and max bpc. Drivers to use the function
+ * drm_connector_attach_active_bpc_property() to create and attach the
+ * property to the connector during initialization.
+ *
* Connectors also have one standardized atomic property:
*
* CRTC_ID:
@@ -2150,6 +2157,39 @@ int drm_connector_attach_max_bpc_property(struct
drm_connector *connector,
}
EXPORT_SYMBOL(drm_connector_attach_max_bpc_property);
+/**
+ * drm_connector_attach_active_bpc_property - attach "active bpc" property
+ * @connector: connector to attach active bpc property on.
+ * @min: The minimum bit depth supported by the connector.
+ * @max: The maximum bit depth supported by the connector.
+ *
+ * This is used to check the applied bit depth on a connector.
+ *
+ * Returns:
+ * Zero on success, negative errno on failure.
+ */
+int drm_connector_attach_active_bpc_property(struct drm_connector *connector,
+ int min, int max)
+{
+ struct drm_device *dev = connector->dev;
+ struct drm_property *prop;
+
+ prop = connector->active_bpc_property;
+ if (!prop) {
+ prop = drm_property_create_range(dev, 0, "active bpc", min,
max);
+ if (!prop)
+ return -ENOMEM;
+
+ connector->active_bpc_property = prop;
+ }
+
+ drm_object_attach_property(>base, prop, 0);
+ connector->state->active_bpc = 0;
+
+ return 0;
+}
+EXPORT_SYMBOL(drm_connector_attach_active_bpc_property);
+
/**
* drm_connector_set_vrr_capable_property - sets the variable refresh rate
* capable property for a connector
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 1922b278ffad..c58cba2b6afe 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -781,6 +781,13 @@ struct drm_connector_state {
*/
u8 max_bpc;
+ /**
+* @active_bpc: Read only property set by the GPU driver to the actually
+* applied bit depth of the pixels after evaluating all hardware
+* limitations.
+*/
+ u8 active_bpc;
+
/**
* @hdr_output_metadata:
* DRM blob property for HDR output metadata
@@ -1380,6 +1387,12 @@ struct drm_connector {
*/
struct drm_property *max_bpc_property;
+ /**
+* @active_bpc_property: Default connector property for the active bpc
+* to be driven out of the connector.
+*/
+ struct drm_property *active_bpc_property;
+
#define DRM_CONNECTOR_POLL_HPD (1 << 0)
#define DRM_CONNECTOR_POLL_CONNECT (1 << 1)
#define DRM_CONNECTOR_POLL_DISCONNECT (1 << 2)
@@ -1698,6 +1711,8 @@ int drm_connector_set_panel_orientation_with_quirk(
int width, int height);
int drm_connector_attach_max_bpc_property(struct drm_connector *connector,
[Intel-gfx] [PATCH 4/4] drm/i915/display: Add handling for new "active bpc" property
This commits implements the "active bpc" drm property for the Intel GPU driver.
Signed-off-by: Werner Sembach
---
drivers/gpu/drm/i915/display/intel_display.c | 13 +
drivers/gpu/drm/i915/display/intel_dp.c | 8 ++--
drivers/gpu/drm/i915/display/intel_dp_mst.c | 4 +++-
drivers/gpu/drm/i915/display/intel_hdmi.c| 4 +++-
4 files changed, 25 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 64e9107d70f7..f7898d9d7438 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -10164,6 +10164,8 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc_state *new_crtc_state, *old_crtc_state;
struct intel_crtc *crtc;
+ struct drm_connector *connector;
+ struct drm_connector_state *new_conn_state;
u64 put_domains[I915_MAX_PIPES] = {};
intel_wakeref_t wakeref = 0;
int i;
@@ -10324,6 +10326,17 @@ static void intel_atomic_commit_tail(struct
intel_atomic_state *state)
}
intel_runtime_pm_put(_priv->runtime_pm, state->wakeref);
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(>base, connector,
new_conn_state, i) {
+ struct drm_crtc *crtc = new_conn_state->crtc;
+ if (crtc) {
+ new_crtc_state =
to_intel_crtc_state(drm_atomic_get_new_crtc_state(>base, crtc));
+ new_conn_state->active_bpc = new_crtc_state->pipe_bpp /
3;
+ }
+ else
+ new_conn_state->active_bpc = 0;
+ }
+
/*
* Defer the cleanup of the old state to a separate worker to not
* impede the current task (userspace for blocking modesets) that
diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
b/drivers/gpu/drm/i915/display/intel_dp.c
index 642c60f3d9b1..67826ba976ed 100644
--- a/drivers/gpu/drm/i915/display/intel_dp.c
+++ b/drivers/gpu/drm/i915/display/intel_dp.c
@@ -4671,10 +4671,14 @@ intel_dp_add_properties(struct intel_dp *intel_dp,
struct drm_connector *connect
intel_attach_force_audio_property(connector);
intel_attach_broadcast_rgb_property(connector);
- if (HAS_GMCH(dev_priv))
+ if (HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 6, 10);
- else if (DISPLAY_VER(dev_priv) >= 5)
+ drm_connector_attach_active_bpc_property(connector, 6, 10);
+ }
+ else if (DISPLAY_VER(dev_priv) >= 5) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_bpc_property(connector, 6, 12);
+ }
/* Register HDMI colorspace for case of lspcon */
if (intel_bios_is_lspcon_present(dev_priv, port)) {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 2daa3f67791e..5a1869dc2210 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -844,8 +844,10 @@ static struct drm_connector
*intel_dp_add_mst_connector(struct drm_dp_mst_topolo
*/
connector->max_bpc_property =
intel_dp->attached_connector->base.max_bpc_property;
- if (connector->max_bpc_property)
+ if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 6, 12);
+ drm_connector_attach_active_bpc_property(connector, 6, 12);
+ }
return connector;
diff --git a/drivers/gpu/drm/i915/display/intel_hdmi.c
b/drivers/gpu/drm/i915/display/intel_hdmi.c
index d69f0a6dc26d..8af78b27b6ce 100644
--- a/drivers/gpu/drm/i915/display/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/display/intel_hdmi.c
@@ -2463,8 +2463,10 @@ intel_hdmi_add_properties(struct intel_hdmi *intel_hdmi,
struct drm_connector *c
drm_object_attach_property(>base,
connector->dev->mode_config.hdr_output_metadata_property, 0);
- if (!HAS_GMCH(dev_priv))
+ if (!HAS_GMCH(dev_priv)) {
drm_connector_attach_max_bpc_property(connector, 8, 12);
+ drm_connector_attach_active_bpc_property(connector, 8, 12);
+ }
}
/*
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/4] drm/amd/display: Add handling for new "active bpc" property
This commits implements the "active bpc" drm property for the AMD GPU driver.
Signed-off-by: Werner Sembach
---
.../gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 18 +-
.../display/amdgpu_dm/amdgpu_dm_mst_types.c| 4 +++-
2 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
index 6e82889271d5..52a057c585b1 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c
@@ -7519,8 +7519,10 @@ void amdgpu_dm_connector_init_helper(struct
amdgpu_display_manager *dm,
adev->mode_info.underscan_vborder_property,
0);
- if (!aconnector->mst_port)
+ if (!aconnector->mst_port) {
drm_connector_attach_max_bpc_property(>base, 8, 16);
+ drm_connector_attach_active_bpc_property(>base, 8,
16);
+ }
/* This defaults to the max in the range, but we want 8bpc for non-edp.
*/
aconnector->base.state->max_bpc = (connector_type ==
DRM_MODE_CONNECTOR_eDP) ? 16 : 8;
@@ -8890,6 +8892,20 @@ static void amdgpu_dm_atomic_commit_tail(struct
drm_atomic_state *state)
mutex_unlock(>dc_lock);
}
+ /* Extract information from crtc to communicate it to userspace as
connector properties */
+ for_each_new_connector_in_state(state, connector, new_con_state, i) {
+ struct drm_crtc *crtc = new_con_state->crtc;
+ if (crtc) {
+ new_crtc_state = drm_atomic_get_new_crtc_state(state,
crtc);
+ dm_new_crtc_state = to_dm_crtc_state(new_crtc_state);
+ if (dm_new_crtc_state->stream)
+ new_con_state->active_bpc =
convert_dc_color_depth_into_bpc(
+
dm_new_crtc_state->stream->timing.display_color_depth);
+ }
+ else
+ new_con_state->active_bpc = 0;
+ }
+
/* Count number of newly disabled CRTCs for dropping PM refs later. */
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state,
new_crtc_state, i) {
diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
index 9b221db526dc..2a8dc6b2c6c7 100644
--- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
+++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_mst_types.c
@@ -397,8 +397,10 @@ dm_dp_add_mst_connector(struct drm_dp_mst_topology_mgr
*mgr,
}
connector->max_bpc_property = master->base.max_bpc_property;
- if (connector->max_bpc_property)
+ if (connector->max_bpc_property) {
drm_connector_attach_max_bpc_property(connector, 8, 16);
+ drm_connector_attach_active_bpc_property(>base, 8,
16);
+ }
connector->vrr_capable_property = master->base.vrr_capable_property;
if (connector->vrr_capable_property)
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/4] drm/amd/display: Add missing cases convert_dc_color_depth_into_bpc
convert_dc_color_depth_into_bpc() that converts the enum dc_color_depth to an integer had the casses for COLOR_DEPTH_999 and COLOR_DEPTH_11 missing. Signed-off-by: Werner Sembach --- drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c | 4 1 file changed, 4 insertions(+) diff --git a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c index 389eff96fcf6..6e82889271d5 100644 --- a/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c +++ b/drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c @@ -6515,6 +6515,10 @@ static int convert_dc_color_depth_into_bpc (enum dc_color_depth display_color_de return 14; case COLOR_DEPTH_161616: return 16; + case COLOR_DEPTH_999: + return 9; + case COLOR_DEPTH_11: + return 11; default: break; } -- 2.25.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Add "activ bpc" drm property and use it in AMD and Intel driver
I started work on my proposal for better color handling in Linux display drivers: https://lkml.org/lkml/2021/5/12/764 Since the first read-only property is now implemented for amdgpu and i915 I wanted to collect some feedback, since the other two read-only properties will be quite similar, I hope. I have already commited the first patch in this series independently as it fixes a function already in use. The actuall update of the values is implemented in patch three and four in the atomic_commit_tail() function of amdgpu and i915 respectifly. It does get updated more often than needed with the current approach, but without harm since just the same value is written again. A check if the update is required would be the same amount of computation. Let me know if you know a better place to put the update than attomic_commit_tail(). ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Tracing a "drm_mode_prune_invalid"
On Fri, Jun 04, 2021 at 12:57:25PM -0400, Adam Chasen wrote:
> Thanks for staying with me! Still hoping I can get back to using KMS/Wayland
> combination with my setup.
>
> I understand the current recommendation is to push the mode setting to the
> wayland compositor per Ville here:
> https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_337616
>
> Alas, I am using Mutter (similar to issue #393) which (historically) doesn't
> support mode setting (yet?).
>
> There is mention of drm_dp_downstream_max_clock() in an i915 comment, which
> looks like could be a reference to drm_dp_downstream_max_tmds_clock().
>
> It seems there is a hard coded 165MHz max for DP_DWN_STRM_PORT_TYPE_TMDS or
> (note the comment in the below code):
>
> case DP_DS_PORT_TYPE_DVI:
> if ((dpcd[DP_DOWNSTREAMPORT_PRESENT] &
> DP_DETAILED_CAP_INFO_AVAILABLE) == 0)
> return 165000;
> /* FIXME what to do about DVI dual link? */
> return port_cap[1] * 2500;
>
> Still wondering about the "one byte" format is for configuration, but I
> presume it is setting DP_DETAILED_CAP_INFO_AVAILABLE to 0 which triggers this.
>
> Is there a recommended approach to setting the port to support Dual-Link
> based on EDID response (or is it too late by the time we get the EDID)?
EDID can't help us since it would only tell us whether the display
supports dual-link or not. The dongle may still be single link only.
>
> Is there a recommended approach for a "disable filter", or "manual modeset"?
> There are others who seem interested in overriding the filtering logic (e.g.
> "do what I say even though it isn't clear it will work").
> https://gitlab.freedesktop.org/drm/intel/-/issues/393#note_829142
Userspace is free to force any it wants. But I guess mutter+wayland
doesn't support that for some reason.
I've occasionally pondered about adding some kind of connector property
for this, but not sure wht it should look like. And it would still
require userspace support to set it. Another idea would be to extend the
video= cmdline with some kind of knob that lets you override these
limits. But again it's a bit hard to come up with a decent solution since
there are various different clock limits involved (TMDS clock for HDMI
vs. link rate for DP, dotclock for everyting). And just saying "ignore
all limits" is not a very flexible solution since there may be some
limit you do want to enforce, just not as low as what we would
auto-detect.
>
> -Adam
>
> -- Related --
>
> I found these following a thread on the 165MHz clock limit in the context of
> DP dual mode HDMI dongles with a patch experimenting with turning off the
> limit: https://bugs.freedesktop.org/show_bug.cgi?id=112018#c2 (now
> https://gitlab.freedesktop.org/drm/intel/-/issues/511) There is even a hack
> for what appears to be a similar limitation
> (using Dual mode DP): https://github.com/hansmi/fake-dp-dual-mode
>
> Researching answers for previous questions:
>
> "one byte" cap:
> /*
> * 0x80-0x8f describe downstream port capabilities, but there are two layouts
> * based on whether DP_DETAILED_CAP_INFO_AVAILABLE was set. If it was not,
> * each port's descriptor is one byte wide. If it was set, each port's is
> * four bytes wide, starting with the one byte from the base info. As of
> * DP interop v1.1a only VGA defines additional detail.
> */
>
> And from a commit:
> * Fixup logic for calculating the downstream port length to account for
> the fact that downstream port caps can be either 1 byte or 4 bytes
> long. We can actually skip fixing the max_clock/max_bpc helpers here
> since they all check for DP_DETAILED_CAP_INFO_AVAILABLE anyway.
>
> DPCD = DisplayPort Configuration Data
> DFP appears to be a structure to hold configuration data as part of
> intel_attached_dp(connector):
> /* Downstream facing port caps */
> struct {
> int min_tmds_clock, max_tmds_clock;
> int max_dotclock;
> u8 max_bpc;
> bool ycbcr_444_to_420;
> } dfp;
>
> On Mon, May 31, 2021, at 10:28 AM, Adam Chasen wrote:
> > Ville,
> > Thanks for the additional detail!
> >
> > I looked up HPD and understand it is hot plug detection, but I didn't
> > find much for "one byte caps format". I assume this is short hand for
> > "capability format".
> >
> > Is the "one byte" format a limitation from the monitor, the dongle, the
> > motherboard, or the chipset?
> >
> > What are some examples of other "capability formats"?
> >
> > Is there a recommended approach to setting the port to support
> > Dual-Link based on EDID response (or is it too late by the time we get
> > the EDID)?
> >
> > If there is no obvious automatic solution, do you have an example of a
> > "manual override" (i.e. module argument) for another situation I can
> > use as a guide?
> >
> > Still curious what DPCD DFP stands for.
> >
> > Thanks,
> > Adam
> >
> > On Mon,
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: apply WaEnableVGAAccessThroughIOPort as needed
== Series Details ==
Series: drm/i915: apply WaEnableVGAAccessThroughIOPort as needed
URL : https://patchwork.freedesktop.org/series/91017/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_10171 -> Patchwork_20284
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/index.html
Known issues
Here are the changes found in Patchwork_20284 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_gttfill@basic:
- fi-bsw-n3050: NOTRUN -> [SKIP][1] ([fdo#109271])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bsw-n3050/igt@gem_exec_gttf...@basic.html
* igt@gem_exec_suspend@basic-s3:
- fi-bsw-n3050: NOTRUN -> [INCOMPLETE][2] ([i915#3159])
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bsw-n3050/igt@gem_exec_susp...@basic-s3.html
* igt@gem_huc_copy@huc-copy:
- fi-bxt-dsi: NOTRUN -> [SKIP][3] ([fdo#109271] / [i915#2190])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bxt-dsi/igt@gem_huc_c...@huc-copy.html
* igt@i915_selftest@live@execlists:
- fi-bxt-dsi: NOTRUN -> [DMESG-FAIL][4] ([i915#3462])
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bxt-dsi/igt@i915_selftest@l...@execlists.html
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-bxt-dsi: NOTRUN -> [SKIP][5] ([fdo#109271] / [fdo#111827]) +8
similar issues
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bxt-dsi/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_force_connector_basic@force-load-detect:
- fi-bxt-dsi: NOTRUN -> [SKIP][6] ([fdo#109271]) +10 similar issues
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bxt-dsi/igt@kms_force_connector_ba...@force-load-detect.html
* igt@kms_pipe_crc_basic@compare-crc-sanitycheck-pipe-d:
- fi-bxt-dsi: NOTRUN -> [SKIP][7] ([fdo#109271] / [i915#533])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bxt-dsi/igt@kms_pipe_crc_ba...@compare-crc-sanitycheck-pipe-d.html
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [DMESG-WARN][8] ([i915#2868]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@runner@aborted:
- fi-glk-dsi: [FAIL][10] ([i915#2426] / [i915#3363] /
[k.org#202321]) -> [FAIL][11] ([i915#3363] / [k.org#202321])
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-glk-dsi/igt@run...@aborted.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-glk-dsi/igt@run...@aborted.html
- fi-kbl-r: [FAIL][12] ([i915#1436] / [i915#3363]) -> [FAIL][13]
([i915#1436] / [i915#2426] / [i915#3363])
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-kbl-r/igt@run...@aborted.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-kbl-r/igt@run...@aborted.html
- fi-bdw-5557u: [FAIL][14] ([i915#3462]) -> [FAIL][15] ([i915#1602] /
[i915#2029])
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-bdw-5557u/igt@run...@aborted.html
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bdw-5557u/igt@run...@aborted.html
- fi-cml-u2: [FAIL][16] ([i915#3363] / [i915#3462]) -> [FAIL][17]
([i915#2082] / [i915#2426] / [i915#3363] / [i915#3462])
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-cml-u2/igt@run...@aborted.html
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-cml-u2/igt@run...@aborted.html
- fi-bxt-dsi: [FAIL][18] ([i915#2426] / [i915#3363]) -> [FAIL][19]
([i915#3363])
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-bxt-dsi/igt@run...@aborted.html
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-bxt-dsi/igt@run...@aborted.html
- fi-cml-s: [FAIL][20] ([i915#2082] / [i915#2426] / [i915#3363] /
[i915#3462]) -> [FAIL][21] ([i915#3363] / [i915#3462])
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_10171/fi-cml-s/igt@run...@aborted.html
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_20284/fi-cml-s/igt@run...@aborted.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#111827]: https://bugs.freedesktop.org/show_bug.cgi?id=111827
[i915#1436]: https://gitlab.freedesktop.org/drm/intel/issues/1436
[i915#1602]: https://gitlab.freedesktop.org/drm/intel/issues/1602
[i915#2029]:
Re: [Intel-gfx] [PATCH v4] drm/i915: Invoke another _DSM to enable MUX on HP Workstation laptops
On Thu, May 20, 2021 at 2:58 PM Kai-Heng Feng
wrote:
>
> On HP Fury G7 Workstations, graphics output is re-routed from Intel GFX
> to discrete GFX after S3. This is not desirable, because userspace will
> treat connected display as a new one, losing display settings.
>
> The expected behavior is to let discrete GFX drives all external
> displays.
>
> The platform in question uses ACPI method \_SB.PCI0.HGME to enable MUX.
> The method is inside the another _DSM, so add the _DSM and call it
> accordingly.
>
> I also tested some MUX-less and iGPU only laptops with that _DSM, no
> regression was found.
>
> v4:
> - Rebase.
> - Change the DSM name to avoid confusion.
> - Move the function call to intel_opregion.
>
> v3:
> - Remove BXT from names.
> - Change the parameter type.
> - Fold the function into intel_modeset_init_hw().
>
> v2:
> - Forward declare struct pci_dev.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/3113
> References:
> https://lore.kernel.org/intel-gfx/1460040732-31417-4-git-send-email-animesh.ma...@intel.com/
> Signed-off-by: Kai-Heng Feng
A gentle ping...
> ---
> drivers/gpu/drm/i915/display/intel_acpi.c | 19 +++
> drivers/gpu/drm/i915/display/intel_acpi.h | 3 +++
> drivers/gpu/drm/i915/display/intel_opregion.c | 3 +++
> 3 files changed, 25 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.c
> b/drivers/gpu/drm/i915/display/intel_acpi.c
> index 833d0c1be4f1..7cfe91fc05f2 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.c
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.c
> @@ -19,6 +19,12 @@ static const guid_t intel_dsm_guid =
> GUID_INIT(0x7ed873d3, 0xc2d0, 0x4e4f,
> 0xa8, 0x54, 0x0f, 0x13, 0x17, 0xb0, 0x1c, 0x2c);
>
> +#define INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED 0 /* No args */
> +
> +static const guid_t intel_dsm_guid2 =
> + GUID_INIT(0x3e5b41c6, 0xeb1d, 0x4260,
> + 0x9d, 0x15, 0xc7, 0x1f, 0xba, 0xda, 0xe4, 0x14);
> +
> static char *intel_dsm_port_name(u8 id)
> {
> switch (id) {
> @@ -176,6 +182,19 @@ void intel_unregister_dsm_handler(void)
> {
> }
>
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> +{
> + struct pci_dev *pdev = to_pci_dev(i915->drm.dev);
> + acpi_handle dhandle;
> +
> + dhandle = ACPI_HANDLE(>dev);
> + if (!dhandle)
> + return;
> +
> + acpi_evaluate_dsm(dhandle, _dsm_guid2, INTEL_DSM_REVISION_ID,
> + INTEL_DSM_FN_GET_BIOS_DATA_FUNCS_SUPPORTED, NULL);
> +}
> +
> /*
> * ACPI Specification, Revision 5.0, Appendix B.3.2 _DOD (Enumerate All
> Devices
> * Attached to the Display Adapter).
> diff --git a/drivers/gpu/drm/i915/display/intel_acpi.h
> b/drivers/gpu/drm/i915/display/intel_acpi.h
> index e8b068661d22..9f197401c313 100644
> --- a/drivers/gpu/drm/i915/display/intel_acpi.h
> +++ b/drivers/gpu/drm/i915/display/intel_acpi.h
> @@ -11,11 +11,14 @@ struct drm_i915_private;
> #ifdef CONFIG_ACPI
> void intel_register_dsm_handler(void);
> void intel_unregister_dsm_handler(void);
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915);
> void intel_acpi_device_id_update(struct drm_i915_private *i915);
> #else
> static inline void intel_register_dsm_handler(void) { return; }
> static inline void intel_unregister_dsm_handler(void) { return; }
> static inline
> +void intel_dsm_get_bios_data_funcs_supported(struct drm_i915_private *i915)
> { return; }
> +static inline
> void intel_acpi_device_id_update(struct drm_i915_private *i915) { return; }
> #endif /* CONFIG_ACPI */
>
> diff --git a/drivers/gpu/drm/i915/display/intel_opregion.c
> b/drivers/gpu/drm/i915/display/intel_opregion.c
> index dfd724e506b5..3855fba70980 100644
> --- a/drivers/gpu/drm/i915/display/intel_opregion.c
> +++ b/drivers/gpu/drm/i915/display/intel_opregion.c
> @@ -1078,6 +1078,9 @@ void intel_opregion_resume(struct drm_i915_private
> *i915)
> opregion->asle->ardy = ASLE_ARDY_READY;
> }
>
> + /* Some platforms abuse the _DSM to enable MUX */
> + intel_dsm_get_bios_data_funcs_supported(i915);
> +
> intel_opregion_notify_adapter(i915, PCI_D0);
> }
>
> --
> 2.31.1
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: only disable default vga device
On Fri, 4 Jun 2021 at 15:08, Ville Syrjälä wrote: > > On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote: > > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote: > > > > > > Hi Ville, > > > > > > On Tue, 18 May 2021 at 12:17, Ville Syrjälä > > > wrote: > > > > > > > > On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote: > > > > > Hi Ville, > > > > > > > > > > On Mon, 17 May 2021 at 18:24, Ville Syrjälä > > > > > wrote: > > > > > > > > > > > > On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote: > > > > > > > From: Vivek Das Mohapatra > > > > > > > > > > > > > > This patch is to do with seamless handover, eg when the sequence > > > > > > > is > > > > > > > bootloader → plymouth → desktop. > > > > > > > > > > > > > > It switches the vga arbiter from the "other" GPU to the default > > > > > > > one > > > > > > > (intel in this case), so the driver can issue some io(). > > > > > > > > > > > > I don't understand what this commit message is trying to say. > > > > > > > > > > > Bunch of context is lost due to the patch age, so I'm not 100% sure of > > > > > the actual hardware setup where this occurs. > > > > > Does the following make sense? > > > > > > > > > > Currently on dual GPU systems, we do not get seamless handover as the > > > > > output flickers during the transition bootloader -> plymouth -> > > > > > desktop. > > > > > This happens as a result of switching (via the VGA arbiter) from the > > > > > "other" GPU back to the default i915 one and issuing io() commands. > > > > > > > > Hmm. Does this work? > > > > > > > > --- a/drivers/gpu/drm/i915/display/intel_vga.c > > > > +++ b/drivers/gpu/drm/i915/display/intel_vga.c > > > > @@ -29,6 +29,9 @@ void intel_vga_disable(struct drm_i915_private > > > > *dev_priv) > > > > i915_reg_t vga_reg = intel_vga_cntrl_reg(dev_priv); > > > > u8 sr1; > > > > > > > > + if (intel_de_read(dev_priv, vga_reg) & VGA_DISP_DISABLE) > > > > + return; > > > > + > > > > /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ > > > > vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > > > > outb(SR01, VGA_SR_INDEX); > > > > > > > Was able to replicate the issue somewhat and the above does help quite a > > > lot. > > > Feel free to add my: > > > Reviewed-by: Emil Velikov > > > Tested-by: Emil Velikov > > > > > Humble poke. > > > > Cannot see this patch in the drm-misc or drm-intel trees. Is there > > anything I do to help move it forward? > > Can you just respin the patch with this? > I've used your suggestion and redone the commit message completely. Hope it's far less cryptic now. Patch is on the ML - realised I didn't CC you, just as it went out. https://lore.kernel.org/dri-devel/20210604154905.660142-1-emil.l.veli...@gmail.com/T/#u Thanks -Emil ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: apply WaEnableVGAAccessThroughIOPort as needed
From: Emil Velikov Currently as the workaround is applied the screen flickers. As a result we do not achieve seamless boot experience. Avoiding the issue in the common use-case might be hard, although we can resolve it for dual GPU setups - when the "other" GPU is primary and/or outputs are connected to it. With this I was able to get seamless experience on my Intel/Nvidia box, running systemd-boot and sddm/Xorg. Note that the i915 driver is within initrd while the Nvidia one is not. Without this patch, the splash presented by systemd-boot (UEFI BGRT) is torn down as the code-path kicks in, leaving the monitor blank until the login manager starts. Same issue were reported with plymouth/grub, although personally I wasn't able to get them to behave on my setup. Suggested-by: Ville Syrjälä Signed-off-by: Emil Velikov --- Supersedes https://lore.kernel.org/dri-devel/20210516171432.1734268-1-emil.l.veli...@gmail.com/ Ville, others, Patch is based against drm-intel/drm-intel-next and will apply cleanly against drm-intel/drm-intel-fixes. If possible, can one of the i915 maintainers apply it to the latter? Thanks Emil --- drivers/gpu/drm/i915/display/intel_vga.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_vga.c b/drivers/gpu/drm/i915/display/intel_vga.c index be333699c515..7beef1206097 100644 --- a/drivers/gpu/drm/i915/display/intel_vga.c +++ b/drivers/gpu/drm/i915/display/intel_vga.c @@ -29,6 +29,9 @@ void intel_vga_disable(struct drm_i915_private *dev_priv) i915_reg_t vga_reg = intel_vga_cntrl_reg(dev_priv); u8 sr1; + if (intel_de_read(dev_priv, vga_reg) & VGA_DISP_DISABLE) + return; + /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); outb(SR01, VGA_SR_INDEX); -- 2.31.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize the mbus_offset to fix static analysis issue
On Fri, Jun 04, 2021 at 06:22:49PM +0300, Mika Kuoppala wrote:
> Rodrigo Vivi writes:
>
> > On Thu, Jun 03, 2021 at 03:07:54PM -0700, Manasi Navare wrote:
> >> Static analysis identified an issue in skl_crtc_allocate_ddb where
> >> mbus_offset may be used uninitialized.
> >> This patch fixes it.
> >
> > I'm sorry, but I really cannot see what this tool is seeing...
> > I even tried to look to our internal branch to see if it was an issue
> > there.
> > But I'm failing to see how it is possible...
>
> It is in the goto out; path.
indeed... thanks
what a huge "out" block.
For me it looks like another function and not just an "out".
Could we get a refactor here?
I'm afraid that setting mbus_offset = 0 silence the static analysis tool,
but this might not be right for this "out" section. Because offset gets
totally ignored.
The condition to call the goto out is not that clear on why we want
one or another path, so a refactor there to make things more clear is
probably the best.
> -Mika
>
> >
> >>
> >> Fixes: 835c176cb1c4 ("drm/i915: Introduce MBUS relative dbuf offsets")
> >> Cc: Ville Syrjälä
> >> Signed-off-by: Manasi Navare
> >> ---
> >> drivers/gpu/drm/i915/intel_pm.c | 2 +-
> >> 1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> >> b/drivers/gpu/drm/i915/intel_pm.c
> >> index 00f3dead20ad..a385b8b7414f 100644
> >> --- a/drivers/gpu/drm/i915/intel_pm.c
> >> +++ b/drivers/gpu/drm/i915/intel_pm.c
> >> @@ -4163,7 +4163,7 @@ skl_crtc_allocate_ddb(struct intel_atomic_state
> >> *state, struct intel_crtc *crtc)
> >>struct intel_crtc_state *crtc_state;
> >>struct skl_ddb_entry ddb_slices;
> >>enum pipe pipe = crtc->pipe;
> >> - unsigned int mbus_offset;
> >> + unsigned int mbus_offset = 0;
> >>u32 ddb_range_size;
> >>u32 dbuf_slice_mask;
> >>u32 start, end;
> >> --
> >> 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@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize the mbus_offset to fix static analysis issue
Rodrigo Vivi writes:
> On Thu, Jun 03, 2021 at 03:07:54PM -0700, Manasi Navare wrote:
>> Static analysis identified an issue in skl_crtc_allocate_ddb where
>> mbus_offset may be used uninitialized.
>> This patch fixes it.
>
> I'm sorry, but I really cannot see what this tool is seeing...
> I even tried to look to our internal branch to see if it was an issue
> there.
> But I'm failing to see how it is possible...
It is in the goto out; path.
-Mika
>
>>
>> Fixes: 835c176cb1c4 ("drm/i915: Introduce MBUS relative dbuf offsets")
>> Cc: Ville Syrjälä
>> Signed-off-by: Manasi Navare
>> ---
>> drivers/gpu/drm/i915/intel_pm.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 00f3dead20ad..a385b8b7414f 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -4163,7 +4163,7 @@ skl_crtc_allocate_ddb(struct intel_atomic_state
>> *state, struct intel_crtc *crtc)
>> struct intel_crtc_state *crtc_state;
>> struct skl_ddb_entry ddb_slices;
>> enum pipe pipe = crtc->pipe;
>> -unsigned int mbus_offset;
>> +unsigned int mbus_offset = 0;
>> u32 ddb_range_size;
>> u32 dbuf_slice_mask;
>> u32 start, end;
>> --
>> 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@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
Am 04.06.21 um 16:11 schrieb Thomas Hellström: On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote: Am 04.06.21 um 16:03 schrieb Thomas Hellström: On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: Am 04.06.21 um 11:12 schrieb Daniel Vetter: On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote: On 6/4/21 9:51 AM, Christian König wrote: Am 03.06.21 um 09:36 schrieb Daniel Vetter: On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström wrote: On 6/2/21 8:40 PM, Daniel Vetter wrote: On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): On 6/2/21 10:32 AM, Christian König wrote: Uff I'm just waiting for feedback from Philip to merge a large patch set for TTM through drm-misc-next. I'm pretty sure we will run into merge conflicts if you try to push your changes through the Intel tree. Christian. OK, so what would be the best approach here?, Adding the TTM patches to drm-misc-next when your set has landed? I think I will send out out my set to Matthew once more for review, then push the common TTM stuff to drm-misc-next as much as possible. Then you should be able to land your stuff to drm-misc-next and rebase on the end result. Just need to note to David that drm-misc-next should be merged to drm-next before the Intel patches depending on that stuff land as well. Other option (because the backmerges tend to be slow) is a topic branch, and we just eat/resolve the conflicts in both drm- misc- next and drm-intel-gt-next in the merge commit. If it's not too bad (I haven't looked at what exactly we need for the i915 side from ttm in detail). But also often figuring out the topic branch logistics takes longer than just merging to drm-misc-next as the patches get ready. -Daniel Daniel: So the thing we need to get into TTM is the iterator-based move_memcpy which is more adaptable than the current one and needed to support non-linear lmem buffers, some bug-fixes and minor changes to be able to keep our short-term-pinning while on the LRU. A necessary evil. Christian: it looks like you have landed some TTM changes already, in particular the >mem -> bo->resource change which is the main conflict I think. Yes, I thought that pushing this with Matthew rb should solve at least a bit of the conflict. Is the 10 patches self-allocation series the main remaining part? Yes, exactly. I only need Matthew's, Daniel's or your ok and I'm good to go as well That will probably cause some conflicts with already pushed i915 TTM setup code, but otherwise will not conflict with the rest of the TTM code I think, which should make it possible to bring in our TTM changes after conflict resolution with what you've already pushed. The memcpy code is pretty self-contained. I think in that case topic branch on top of drm-next (once the ttm bits we conflict with are there) is probably best, and then pull that into drm-misc-next and drm-intel-gt-next. Merge window freeze is also approach, so without topic branch we'd be stuck until like - rc2 when drm-next reopens. I guess Maarten can do the topic branch logistics in drm-misc.git for this. That approach sounds good to me as well. The amdgpu branch had some merge conflicts as well, but nothing we couldn't fix. OK, so this is going to be a little tricky, I guess. From what I can tell, the memcpy TTM stuff is resolved locally and can be merged to drm-misc-next immediately. It might have a very minor conflict with your 10 patches I think, if any. Your 10 patches will conflict slightly with current drm- intel-gt- next I think. Remaining intel patches will conflict only with current drm- misc- next. So We could have pull order - drm-misc-next up to bot not including your 10 patches, - drm-intel-gt-next - drm-misc-next from your 10 paches and onwards, - Intel's ttm enablement topic branch. If it's just slight conflicts then I wouldn't bother with careful merge order. Because if we do this we can get around to the i915 ttm topic branch only when we're back to -rc2. I've just pushed the remaining 10 patches to drm-misc-next and ran into minor merge conflicts in drm-tip. I'm working on this, but I'm not very familiar with drm-tip handling. Christian. Np, I'll hold off until Monday. Ok I've fixed up drm-tip for amdgpu, but there are also merge conflicts for i915. Can you handle those? Doesn't looks to hard, but I would prefer not to touch code I can't test. Christian. Hi, Christian, Unfortunately I can't (not until monday at least as I'm off for the weekend). But I did warn you twice about those. Ok in this case I will just fix them up as best as I can. Thanks, Christian. /Thomas /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
Am 04.06.21 um 16:03 schrieb Thomas Hellström: On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: Am 04.06.21 um 11:12 schrieb Daniel Vetter: On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström wrote: On 6/4/21 9:51 AM, Christian König wrote: Am 03.06.21 um 09:36 schrieb Daniel Vetter: On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström wrote: On 6/2/21 8:40 PM, Daniel Vetter wrote: On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian König wrote: Am 02.06.21 um 11:16 schrieb Thomas Hellström (Intel): On 6/2/21 10:32 AM, Christian König wrote: Uff I'm just waiting for feedback from Philip to merge a large patch set for TTM through drm-misc-next. I'm pretty sure we will run into merge conflicts if you try to push your changes through the Intel tree. Christian. OK, so what would be the best approach here?, Adding the TTM patches to drm-misc-next when your set has landed? I think I will send out out my set to Matthew once more for review, then push the common TTM stuff to drm-misc-next as much as possible. Then you should be able to land your stuff to drm-misc-next and rebase on the end result. Just need to note to David that drm-misc-next should be merged to drm-next before the Intel patches depending on that stuff land as well. Other option (because the backmerges tend to be slow) is a topic branch, and we just eat/resolve the conflicts in both drm-misc- next and drm-intel-gt-next in the merge commit. If it's not too bad (I haven't looked at what exactly we need for the i915 side from ttm in detail). But also often figuring out the topic branch logistics takes longer than just merging to drm-misc-next as the patches get ready. -Daniel Daniel: So the thing we need to get into TTM is the iterator-based move_memcpy which is more adaptable than the current one and needed to support non-linear lmem buffers, some bug-fixes and minor changes to be able to keep our short-term-pinning while on the LRU. A necessary evil. Christian: it looks like you have landed some TTM changes already, in particular the >mem -> bo->resource change which is the main conflict I think. Yes, I thought that pushing this with Matthew rb should solve at least a bit of the conflict. Is the 10 patches self-allocation series the main remaining part? Yes, exactly. I only need Matthew's, Daniel's or your ok and I'm good to go as well That will probably cause some conflicts with already pushed i915 TTM setup code, but otherwise will not conflict with the rest of the TTM code I think, which should make it possible to bring in our TTM changes after conflict resolution with what you've already pushed. The memcpy code is pretty self-contained. I think in that case topic branch on top of drm-next (once the ttm bits we conflict with are there) is probably best, and then pull that into drm-misc-next and drm-intel-gt-next. Merge window freeze is also approach, so without topic branch we'd be stuck until like - rc2 when drm-next reopens. I guess Maarten can do the topic branch logistics in drm-misc.git for this. That approach sounds good to me as well. The amdgpu branch had some merge conflicts as well, but nothing we couldn't fix. OK, so this is going to be a little tricky, I guess. From what I can tell, the memcpy TTM stuff is resolved locally and can be merged to drm-misc-next immediately. It might have a very minor conflict with your 10 patches I think, if any. Your 10 patches will conflict slightly with current drm-intel-gt- next I think. Remaining intel patches will conflict only with current drm-misc- next. So We could have pull order - drm-misc-next up to bot not including your 10 patches, - drm-intel-gt-next - drm-misc-next from your 10 paches and onwards, - Intel's ttm enablement topic branch. If it's just slight conflicts then I wouldn't bother with careful merge order. Because if we do this we can get around to the i915 ttm topic branch only when we're back to -rc2. I've just pushed the remaining 10 patches to drm-misc-next and ran into minor merge conflicts in drm-tip. I'm working on this, but I'm not very familiar with drm-tip handling. Christian. Np, I'll hold off until Monday. Ok I've fixed up drm-tip for amdgpu, but there are also merge conflicts for i915. Can you handle those? Doesn't looks to hard, but I would prefer not to touch code I can't test. Christian. /Thomas ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Merging TTM branches through the Intel tree?
On Fri, 2021-06-04 at 16:06 +0200, Christian König wrote: > Am 04.06.21 um 16:03 schrieb Thomas Hellström: > > On Fri, 2021-06-04 at 15:38 +0200, Christian König wrote: > > > Am 04.06.21 um 11:12 schrieb Daniel Vetter: > > > > On Fri, Jun 04, 2021 at 11:01:40AM +0200, Thomas Hellström > > > > wrote: > > > > > On 6/4/21 9:51 AM, Christian König wrote: > > > > > > Am 03.06.21 um 09:36 schrieb Daniel Vetter: > > > > > > > On Thu, Jun 3, 2021 at 8:50 AM Thomas Hellström > > > > > > > wrote: > > > > > > > > On 6/2/21 8:40 PM, Daniel Vetter wrote: > > > > > > > > > On Wed, Jun 02, 2021 at 11:48:41AM +0200, Christian > > > > > > > > > König > > > > > > > > > wrote: > > > > > > > > > > Am 02.06.21 um 11:16 schrieb Thomas Hellström > > > > > > > > > > (Intel): > > > > > > > > > > > On 6/2/21 10:32 AM, Christian König wrote: > > > > > > > > > > > > Uff I'm just waiting for feedback from Philip > > > > > > > > > > > > to > > > > > > > > > > > > merge a large patch > > > > > > > > > > > > set for TTM through drm-misc-next. > > > > > > > > > > > > > > > > > > > > > > > > I'm pretty sure we will run into merge > > > > > > > > > > > > conflicts if > > > > > > > > > > > > you try to push > > > > > > > > > > > > your changes through the Intel tree. > > > > > > > > > > > > > > > > > > > > > > > > Christian. > > > > > > > > > > > OK, so what would be the best approach here?, > > > > > > > > > > > Adding > > > > > > > > > > > the TTM patches to > > > > > > > > > > > drm-misc-next when your set has landed? > > > > > > > > > > I think I will send out out my set to Matthew once > > > > > > > > > > more > > > > > > > > > > for review, then > > > > > > > > > > push the common TTM stuff to drm-misc-next as much > > > > > > > > > > as > > > > > > > > > > possible. > > > > > > > > > > > > > > > > > > > > Then you should be able to land your stuff to > > > > > > > > > > drm-misc-next and rebase on > > > > > > > > > > the end result. > > > > > > > > > > > > > > > > > > > > Just need to note to David that drm-misc-next > > > > > > > > > > should be > > > > > > > > > > merged to drm-next > > > > > > > > > > before the Intel patches depending on that stuff > > > > > > > > > > land > > > > > > > > > > as well. > > > > > > > > > Other option (because the backmerges tend to be slow) > > > > > > > > > is > > > > > > > > > a > > > > > > > > > topic branch, > > > > > > > > > and we just eat/resolve the conflicts in both drm- > > > > > > > > > misc- > > > > > > > > > next and > > > > > > > > > drm-intel-gt-next in the merge commit. If it's not > > > > > > > > > too > > > > > > > > > bad (I haven't > > > > > > > > > looked at what exactly we need for the i915 side from > > > > > > > > > ttm > > > > > > > > > in detail). > > > > > > > > > > > > > > > > > > But also often figuring out the topic branch > > > > > > > > > logistics > > > > > > > > > takes > > > > > > > > > longer than > > > > > > > > > just merging to drm-misc-next as the patches get > > > > > > > > > ready. > > > > > > > > > -Daniel > > > > > > > > Daniel: So the thing we need to get into TTM is the > > > > > > > > iterator-based > > > > > > > > move_memcpy which is more adaptable than the current > > > > > > > > one > > > > > > > > and needed to > > > > > > > > support non-linear lmem buffers, some bug-fixes and > > > > > > > > minor > > > > > > > > changes to be > > > > > > > > able to keep our short-term-pinning while on the LRU. A > > > > > > > > necessary evil. > > > > > > > > > > > > > > > > Christian: it looks like you have landed some TTM > > > > > > > > changes > > > > > > > > already, in > > > > > > > > particular the >mem -> bo->resource change which is > > > > > > > > the > > > > > > > > main > > > > > > > > conflict I think. > > > > > > Yes, I thought that pushing this with Matthew rb should > > > > > > solve > > > > > > at least a > > > > > > bit of the conflict. > > > > > > > > > > > > > > Is the 10 patches self-allocation series the main > > > > > > > > remaining part? > > > > > > Yes, exactly. I only need Matthew's, Daniel's or your ok > > > > > > and > > > > > > I'm good to > > > > > > go as well > > > > > > > > > > > > > > That will probably cause some conflicts with already > > > > > > > > pushed i915 TTM setup code, but otherwise will not > > > > > > > > conflict > > > > > > > > with the > > > > > > > > rest of the TTM code I think, which should make it > > > > > > > > possible > > > > > > > > to bring in > > > > > > > > our TTM changes after conflict resolution with what > > > > > > > > you've > > > > > > > > already > > > > > > > > pushed. The memcpy code is pretty self-contained. > > > > > > > I think in that case topic branch on top of drm-next > > > > > > > (once > > > > > > > the ttm > > > > > > > bits we conflict with are there) is probably best, and > > > > > > > then > > > > > > > pull that > > > > > > > into drm-misc-next and drm-intel-gt-next. Merge window > > > > > > > freeze > > > > > > > is also > > > > > > > approach, so without topic
Re: [Intel-gfx] [PATCH] drm/i915: only disable default vga device
On Fri, Jun 04, 2021 at 02:47:16PM +0100, Emil Velikov wrote: > On Wed, 26 May 2021 at 17:21, Emil Velikov wrote: > > > > Hi Ville, > > > > On Tue, 18 May 2021 at 12:17, Ville Syrjälä > > wrote: > > > > > > On Tue, May 18, 2021 at 12:09:56PM +0100, Emil Velikov wrote: > > > > Hi Ville, > > > > > > > > On Mon, 17 May 2021 at 18:24, Ville Syrjälä > > > > wrote: > > > > > > > > > > On Sun, May 16, 2021 at 06:14:32PM +0100, Emil Velikov wrote: > > > > > > From: Vivek Das Mohapatra > > > > > > > > > > > > This patch is to do with seamless handover, eg when the sequence is > > > > > > bootloader → plymouth → desktop. > > > > > > > > > > > > It switches the vga arbiter from the "other" GPU to the default one > > > > > > (intel in this case), so the driver can issue some io(). > > > > > > > > > > I don't understand what this commit message is trying to say. > > > > > > > > > Bunch of context is lost due to the patch age, so I'm not 100% sure of > > > > the actual hardware setup where this occurs. > > > > Does the following make sense? > > > > > > > > Currently on dual GPU systems, we do not get seamless handover as the > > > > output flickers during the transition bootloader -> plymouth -> > > > > desktop. > > > > This happens as a result of switching (via the VGA arbiter) from the > > > > "other" GPU back to the default i915 one and issuing io() commands. > > > > > > Hmm. Does this work? > > > > > > --- a/drivers/gpu/drm/i915/display/intel_vga.c > > > +++ b/drivers/gpu/drm/i915/display/intel_vga.c > > > @@ -29,6 +29,9 @@ void intel_vga_disable(struct drm_i915_private > > > *dev_priv) > > > i915_reg_t vga_reg = intel_vga_cntrl_reg(dev_priv); > > > u8 sr1; > > > > > > + if (intel_de_read(dev_priv, vga_reg) & VGA_DISP_DISABLE) > > > + return; > > > + > > > /* WaEnableVGAAccessThroughIOPort:ctg,elk,ilk,snb,ivb,vlv,hsw */ > > > vga_get_uninterruptible(pdev, VGA_RSRC_LEGACY_IO); > > > outb(SR01, VGA_SR_INDEX); > > > > > Was able to replicate the issue somewhat and the above does help quite a > > lot. > > Feel free to add my: > > Reviewed-by: Emil Velikov > > Tested-by: Emil Velikov > > > Humble poke. > > Cannot see this patch in the drm-misc or drm-intel trees. Is there > anything I do to help move it forward? Can you just respin the patch with this? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
