[Intel-gfx] [PATCH] drm/i915: Flush the tasklet when checking for idle
In order to reduce latency when checking for idle we kick the tasklet directly. Sometimes this is not enough as it is queued on another cpu and so to improve the accuracy of this idle-check (and so to reduce latency overall by avoiding another pass, or worse declaring a timeout!) wait for the tasklet to complete. References: https://bugs.freedesktop.org/show_bug.cgi?id=107916 Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Mika Kuoppala Cc: Michel Thierry --- drivers/gpu/drm/i915/intel_engine_cs.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c b/drivers/gpu/drm/i915/intel_engine_cs.c index 10cd051ba29e..217ed3ee1cab 100644 --- a/drivers/gpu/drm/i915/intel_engine_cs.c +++ b/drivers/gpu/drm/i915/intel_engine_cs.c @@ -990,6 +990,9 @@ bool intel_engine_is_idle(struct intel_engine_cs *engine) } local_bh_enable(); + /* Otherwise flush the tasklet if it was on another cpu */ + tasklet_unlock_wait(t); + if (READ_ONCE(engine->execlists.active)) return false; } -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Flush the tasklet when checking for idle
== Series Details == Series: drm/i915: Flush the tasklet when checking for idle URL : https://patchwork.freedesktop.org/series/49616/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10165 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49616/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10165 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#107139, fdo#105128) -> PASS igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 43) == Missing(8): fi-hsw-4770r fi-cnl-u fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-u == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10165 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10165: 64f4c703c24fec02eddf453ed9039c3ebe417963 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 64f4c703c24f drm/i915: Flush the tasklet when checking for idle == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10165/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for i915/oa: Simplify updating contexts
On 12/09/2018 17:58, Patchwork wrote: == Series Details == Series: i915/oa: Simplify updating contexts URL : https://patchwork.freedesktop.org/series/49569/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813 -> Patchwork_10158 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49569/revisions/1/mbox/ == Known issues == Here are the changes found in Patchwork_10158 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-bdw-samus: PASS -> INCOMPLETE (fdo#107773) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) Possible fixes igt@drv_selftest@live_hangcheck: fi-cfl-guc: DMESG-FAIL (fdo#107710) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: fi-bxt-dsi: INCOMPLETE (fdo#103927) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107710 https://bugs.freedesktop.org/show_bug.cgi?id=107710 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107773 https://bugs.freedesktop.org/show_bug.cgi?id=107773 == Participating hosts (51 -> 45) == Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-glk-j4005 == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10158 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10158: 2a916e5572e4e76f7a31d748b15b417b280e8123 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 2a916e5572e4 i915/oa: Simplify updating contexts Pushed, thanks for the brainstorming and reviews! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915/oa: Simplify updating contexts
On 12/09/2018 16:50, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-12 16:29:30) /* * The OA register config is setup through the context image. This image * might be written to by the GPU on context switch (in particular on @@ -1833,7 +1727,7 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv, * the GPU from any submitted work. */ ret = i915_gem_wait_for_idle(dev_priv, -wait_flags, +I915_WAIT_LOCKED, MAX_SCHEDULE_TIMEOUT); Wait until idle includes a wait for the gpu to switch off. At least it does for execlists, not so clear for ringbuffer as there is no explicit idle-event. However, that shouldn't matter as the kernel context doesn't exist for legacy ringbuffer anyway ;) But the reload will be forced on the next actual use. And on top this is only called on Gen8+! if (ret) return ret; @@ -1859,7 +1753,17 @@ static int gen8_configure_all_contexts(struct drm_i915_private *dev_priv, i915_gem_object_unpin_map(ce->state->obj); } - return ret; + /* +* Apply the configuration by doing one context restore of the edited +* context image. +*/ + rq = i915_request_alloc(engine, dev_priv->kernel_context); By feeding a request, you ensure the reconfig is loaded again. +1 for having it turn off when idle (and not instrument the kernel context at all)! Still I follow your logic that this should leave the oa config in exactly the same state as before the patch, so Reviewed-by: Chris Wilson Thanks, yeah, I am not sure excluding kernel context is possible. If I understand the comments in i915_perf.c, and how much Lionel explained to me, when on we want it on all the time so sampling timers are always on regardless of context switches. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915/oa: Simplify updating contexts
Quoting Tvrtko Ursulin (2018-09-13 09:54:15) > > On 12/09/2018 16:50, Chris Wilson wrote: > > By feeding a request, you ensure the reconfig is loaded again. +1 for > > having it turn off when idle (and not instrument the kernel context at > > all)! > > > > Still I follow your logic that this should leave the oa config in > > exactly the same state as before the patch, so > > Reviewed-by: Chris Wilson > > Thanks, yeah, I am not sure excluding kernel context is possible. If I > understand the comments in i915_perf.c, and how much Lionel explained to > me, when on we want it on all the time so sampling timers are always on > regardless of context switches. I was just thinking along the lines of not having the sampling active when we are idle... But doesn't it actually break our powersaving model entirely if the GT remains active after we drop our wakeref for it? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] i915/oa: Simplify updating contexts
Quoting Chris Wilson (2018-09-13 09:58:59) > Quoting Tvrtko Ursulin (2018-09-13 09:54:15) > > > > On 12/09/2018 16:50, Chris Wilson wrote: > > > By feeding a request, you ensure the reconfig is loaded again. +1 for > > > having it turn off when idle (and not instrument the kernel context at > > > all)! > > > > > > Still I follow your logic that this should leave the oa config in > > > exactly the same state as before the patch, so > > > Reviewed-by: Chris Wilson > > > > Thanks, yeah, I am not sure excluding kernel context is possible. If I > > understand the comments in i915_perf.c, and how much Lionel explained to > > me, when on we want it on all the time so sampling timers are always on > > regardless of context switches. > > I was just thinking along the lines of not having the sampling active > when we are idle... But doesn't it actually break our powersaving model > entirely if the GT remains active after we drop our wakeref for it? Ah, oa being the brute tries to keep the device awake. But iirc it only takes the forcewake and not a rpm wakeref. By the argument above, it needs both. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Flush the tasklet when checking for idle
== Series Details == Series: drm/i915: Flush the tasklet when checking for idle URL : https://patchwork.freedesktop.org/series/49616/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4813_full -> Patchwork_10165_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10165_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_flip@flip-vs-expired-vblank: shard-glk: PASS -> FAIL (fdo#102887, fdo#105363) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4813 -> Patchwork_10165 CI_DRM_4813: 3c13515b12339366b414637b69227a4e3cbe21ae @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10165: 64f4c703c24fec02eddf453ed9039c3ebe417963 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10165/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Remove fb pitch limit for no display
If there is not a display (and so no CRTCs) then there is no upper limit
to the framebuffer pitch imposed by the CRTC.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 3be5fa0acee8..7db14086fb02 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14403,9 +14403,9 @@ static const struct drm_framebuffer_funcs
intel_fb_funcs = {
.dirty = intel_user_framebuffer_dirty,
};
-static
-u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
-uint64_t fb_modifier, uint32_t pixel_format)
+static u32
+intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
+uint64_t fb_modifier, uint32_t pixel_format)
{
struct intel_crtc *crtc;
struct intel_plane *plane;
@@ -14415,6 +14415,9 @@ u32 intel_fb_pitch_limit(struct drm_i915_private
*dev_priv,
* the highest stride limits of them all.
*/
crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
+ if (!crtc)
+ return U32_MAX;
+
plane = to_intel_plane(crtc->base.primary);
return plane->max_stride(plane, pixel_format, fb_modifier,
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATH i-g-t v12 2/2] tests: add slice power programming test
On 12/09/2018 12:53, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2018-09-11 15:42:10)
+ last_with_engines = -1;
+ for (class = 0; class < ~0; class++) {
+ for (instance = 0; instance < ~0; instance++) {
+ int ret;
+
+ sseu.class = class;
+ sseu.instance = instance;
+
+ ret = __gem_context_set_param(fd, &arg);
+
+ if (has_engine(fd, class, instance)) {
+ if (engine_supports_sseu(fd, class, instance))
Meh, . I just don't like having hardcoded db on this side of the
ABI. The ABI imo is to ask the kernel if the device/engine is supported,
and should not allow for assumptions.
Done.
+static void
+test_dynamic(int fd, unsigned int flags)
+{
+ uint64_t pg_slice_mask = mask_minus_one(__slice_mask__);
+ unsigned int pg_slice_count = __slice_count__ - 1;
+ struct drm_i915_gem_context_param_sseu sseu = { };
+ struct drm_i915_gem_context_param arg =
+ { .param = I915_CONTEXT_PARAM_SSEU,
+ .ctx_id = gem_context_create(fd),
+ .size = sizeof(sseu),
+ .value = to_user_pointer(&sseu) };
+ igt_spin_t *spin = NULL;
+
+ gem_context_get_param(fd, &arg);
+
+ /* First set the default mask */
+ if (flags & TEST_BUSY)
+ spin = __spin_sync(fd, arg.ctx_id, I915_EXEC_RENDER);
+
+ sseu.slice_mask = __slice_mask__;
+ gem_context_set_param(fd, &arg);
I would also suggest a reset test here. Both reset when idle, and by
hangcheck/forced-reset of the spinner & active context.
And across suspend.
Reset & suspsend after set param but before execbuf? Or after execbuf
and then re-read rpcs?
+ igt_assert_eq(read_slice_count_busy(fd, arg.ctx_id, 0, spin),
+ __slice_count__);
+ igt_assert_eq(read_slice_count(fd, 0, 0), __slice_count__);
In the read_slice I would suggest having a
igt_assert(gem_bo_busy(spin->handle));
Done.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATH i-g-t v12 2/2] tests: add slice power programming test
Quoting Tvrtko Ursulin (2018-09-13 11:38:47) > > On 12/09/2018 12:53, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-09-11 15:42:10) > > I would also suggest a reset test here. Both reset when idle, and by > > hangcheck/forced-reset of the spinner & active context. > > > > And across suspend. > > Reset & suspsend after set param but before execbuf? Or after execbuf > and then re-read rpcs? My concern is making sure that after the reset/suspend the adjusted sseu is still in effect. For reset, I think the hardest case is if the spinning batch (causing us to use the MI_STORE_DATA_IMM path) itself hangs. An idle/reset is only borderline interesting. For that it's just the question of whether resetting the gpu breaks everything -- but we reset the gpu frequently enough (on load, on resume) that there's no getting away from it :) Argh, there's another dilemma here... The wedged driver. In that case, it should still work as although we may lose the request to set the sseu in flight, if we ever use the gpu again, we will repin the context and so reset the sseu. For suspend, I can see an argument for both idle/suspend and active/suspend to check that the settings are preserved across the suspend. In the first case, the path we take will apply them afterwards, in the latter case, we will apply the settings again on resume. So maybe there isn't much point to the second case. However, it does all presume that we do remember to repin the context (so probably worth exercising). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove fb pitch limit for no display
On Thu, Sep 13, 2018 at 11:39:23AM +0100, Chris Wilson wrote:
> If there is not a display (and so no CRTCs) then there is no upper limit
> to the framebuffer pitch imposed by the CRTC.
Should we still allow you to create framebuffers in that case?
If yes then my plan to also query the planes which pixel formats/modifiers
to accept in addfb is going to hit hard times.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_display.c | 9 ++---
> 1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3be5fa0acee8..7db14086fb02 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14403,9 +14403,9 @@ static const struct drm_framebuffer_funcs
> intel_fb_funcs = {
> .dirty = intel_user_framebuffer_dirty,
> };
>
> -static
> -u32 intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
> - uint64_t fb_modifier, uint32_t pixel_format)
> +static u32
> +intel_fb_pitch_limit(struct drm_i915_private *dev_priv,
> + uint64_t fb_modifier, uint32_t pixel_format)
> {
> struct intel_crtc *crtc;
> struct intel_plane *plane;
> @@ -14415,6 +14415,9 @@ u32 intel_fb_pitch_limit(struct drm_i915_private
> *dev_priv,
>* the highest stride limits of them all.
>*/
> crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
> + if (!crtc)
> + return U32_MAX;
> +
> plane = to_intel_plane(crtc->base.primary);
>
> return plane->max_stride(plane, pixel_format, fb_modifier,
> --
> 2.19.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove fb pitch limit for no display
Quoting Ville Syrjälä (2018-09-13 11:56:56) > On Thu, Sep 13, 2018 at 11:39:23AM +0100, Chris Wilson wrote: > > If there is not a display (and so no CRTCs) then there is no upper limit > > to the framebuffer pitch imposed by the CRTC. > > Should we still allow you to create framebuffers in that case? Up to you, imho is that fb are just bo with a bit of description. I didn't see much harm in creating an fb even if it was never going to be attached to any pipe. I don't have a solid usecase, just feels like it reduces the impact on the API. Hmm, however if we if (num_pipes == 0) driver_features &= ~DRIVER_MODESET; we will kill the unusable API at the ioctl boundary. > If yes then my plan to also query the planes which pixel formats/modifiers > to accept in addfb is going to hit hard times. Spreading an ugly if !plane around :( -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Wait for the previous RCU grace period, not request completion
On 12/09/2018 17:40, Chris Wilson wrote:
Under mempressure, our goal is to allow ourselves sufficient time to
reclaim the RCU protected slabs without overly penalizing our clients.
Currently, we use a 1 jiffie wait if the client is still active as a
means of throttling the allocations, but we can instead wait for the end
of the RCU grace period of the clients previous allocation.
Why did you opt for three patches changing the same code and just squash
to last?
Regards,
Tvrtko
Suggested-by: Daniel Vetter
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Cc: Daniel Vetter
---
drivers/gpu/drm/i915/i915_request.c | 14 ++
drivers/gpu/drm/i915/i915_request.h | 8
2 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 72bcb4ca0c45..a492385b2089 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -732,17 +732,13 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq = kmem_cache_alloc(i915->requests,
GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
if (unlikely(!rq)) {
+ i915_retire_requests(i915);
+
/* Ratelimit ourselves to prevent oom from malicious clients */
rq = i915_gem_active_raw(&ce->ring->timeline->last_request,
&i915->drm.struct_mutex);
- if (rq && i915_request_wait(rq,
- I915_WAIT_LOCKED |
- I915_WAIT_INTERRUPTIBLE,
- 1) == -EINTR) {
- ret = -EINTR;
- goto err_unreserve;
- }
- i915_retire_requests(i915);
+ if (rq)
+ cond_synchronize_rcu(rq->rcustate);
/*
* We've forced the client to stall and catch up with whatever
@@ -762,6 +758,8 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
}
}
+ rq->rcustate = get_state_synchronize_rcu();
+
INIT_LIST_HEAD(&rq->active_list);
rq->i915 = i915;
rq->engine = engine;
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index 9898301ab7ef..7fa94b024968 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -100,6 +100,14 @@ struct i915_request {
struct i915_timeline *timeline;
struct intel_signal_node signaling;
+ /*
+* The rcu epoch of when this request was allocated. Used to judiciously
+* apply backpressure on future allocations to ensure that under
+* mempressure there is sufficient RCU ticks for us to reclaim our
+* RCU protected slabs.
+*/
+ unsigned long rcustate;
+
/*
* Fences for the various phases in the request's lifetime.
*
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove fb pitch limit for no display
== Series Details ==
Series: drm/i915: Remove fb pitch limit for no display
URL : https://patchwork.freedesktop.org/series/49625/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4816 -> Patchwork_10166 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49625/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10166 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_psr@primary_mmap_gtt:
{fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3
Possible fixes
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
== Participating hosts (49 -> 46) ==
Additional (2): fi-cnl-u fi-icl-u
Missing(5): fi-ctg-p8600 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-hsw-4200u
== Build changes ==
* Linux: CI_DRM_4816 -> Patchwork_10166
CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10166: 1b805e4c8215a284269e9cfcf3b0bf7921f37539 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
1b805e4c8215 drm/i915: Remove fb pitch limit for no display
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10166/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Wait for the previous RCU grace period, not request completion
Quoting Tvrtko Ursulin (2018-09-13 12:16:42) > > On 12/09/2018 17:40, Chris Wilson wrote: > > Under mempressure, our goal is to allow ourselves sufficient time to > > reclaim the RCU protected slabs without overly penalizing our clients. > > Currently, we use a 1 jiffie wait if the client is still active as a > > means of throttling the allocations, but we can instead wait for the end > > of the RCU grace period of the clients previous allocation. > > Why did you opt for three patches changing the same code and just squash > to last? 1 introduced a timeout, 2 limited it to the single timeline, 3 changed what we are waiting on entirely. Each of those are big jumps, and only (1) is required to fix the bug. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Wait for the previous RCU grace period, not request completion
On 13/09/2018 12:18, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-09-13 12:16:42) On 12/09/2018 17:40, Chris Wilson wrote: Under mempressure, our goal is to allow ourselves sufficient time to reclaim the RCU protected slabs without overly penalizing our clients. Currently, we use a 1 jiffie wait if the client is still active as a means of throttling the allocations, but we can instead wait for the end of the RCU grace period of the clients previous allocation. Why did you opt for three patches changing the same code and just squash to last? 1 introduced a timeout, 2 limited it to the single timeline, 3 changed what we are waiting on entirely. Each of those are big jumps, and only (1) is required to fix the bug. I completely understand that, just question why we want to review all the intermediate solutions only to end up with superior one in terms of both logic, design and simplicity. Because as said before, I don't really approve of patch 1 that much, even if it fixes a bug. Two is already superior, but three is right to the point of what problem you want to solve. (Even if I haven't looked into the exact RCU API yet, but it looks believable.) Anyway, I'll let the other guys comment, maybe it is just me who is too picky. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Wait for the previous RCU grace period, not request completion
Quoting Tvrtko Ursulin (2018-09-13 12:29:46) > > On 13/09/2018 12:18, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-09-13 12:16:42) > >> > >> On 12/09/2018 17:40, Chris Wilson wrote: > >>> Under mempressure, our goal is to allow ourselves sufficient time to > >>> reclaim the RCU protected slabs without overly penalizing our clients. > >>> Currently, we use a 1 jiffie wait if the client is still active as a > >>> means of throttling the allocations, but we can instead wait for the end > >>> of the RCU grace period of the clients previous allocation. > >> > >> Why did you opt for three patches changing the same code and just squash > >> to last? > > > > 1 introduced a timeout, 2 limited it to the single timeline, 3 changed > > what we are waiting on entirely. Each of those are big jumps, and only > > (1) is required to fix the bug. > > I completely understand that, just question why we want to review all > the intermediate solutions only to end up with superior one in terms of > both logic, design and simplicity. Depends on viewpoint. > Because as said before, I don't really approve of patch 1 that much, > even if it fixes a bug. > > Two is already superior, but three is right to the point of what problem > you want to solve. (Even if I haven't looked into the exact RCU API yet, > but it looks believable.) 2 mixes global/local without any clue as to whether local is a good idea. I think that switch deserves argument (because what good is pretending to only check the local client when there's a massive global bottleneck in the following lines). The switch over to using waiting a single grace period itself is also dubious, because there is even less to link that back to gpu behaviour and that I feel may be more crucial than the handwaving in (1) gives credit for. And then there are the shivers that come from having a big global barrier in something that needs to learn to be lean and scalable. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove fb pitch limit for no display
On Thu, Sep 13, 2018 at 12:05:49PM +0100, Chris Wilson wrote: > Quoting Ville Syrjälä (2018-09-13 11:56:56) > > On Thu, Sep 13, 2018 at 11:39:23AM +0100, Chris Wilson wrote: > > > If there is not a display (and so no CRTCs) then there is no upper limit > > > to the framebuffer pitch imposed by the CRTC. > > > > Should we still allow you to create framebuffers in that case? > > Up to you, imho is that fb are just bo with a bit of description. I > didn't see much harm in creating an fb even if it was never going to be > attached to any pipe. I don't have a solid usecase, just feels like it > reduces the impact on the API. To me it feels a bit like giving userspace false hope that they can actually do something with the fb later. > > Hmm, however if we > if (num_pipes == 0) driver_features &= ~DRIVER_MODESET; > we will kill the unusable API at the ioctl boundary. That seems a bit wrong. We'd really want to device_features for something like that. Not sure how many things we have in the driver struct that really ought to be under the device. > > > If yes then my plan to also query the planes which pixel formats/modifiers > > to accept in addfb is going to hit hard times. > > Spreading an ugly if !plane around :( Should just be for_each_plane() and I guess if none are there the addfb would get rejected as the format wouldn't match anything. But I haven't actually figured out how to do this in the best way. Another option would be to cache the union of all format/modifier combos of all planes somewhere and check against that (should be slightly more efficient as we wouldn't check the same thing many times). And in that case I guess we could always add some kind of fallback of say just XRGB for the num_pipes==0 case, should we think there is some benefit to allowing it. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Remove fb pitch limit for no display
Quoting Ville Syrjälä (2018-09-13 13:26:48) > On Thu, Sep 13, 2018 at 12:05:49PM +0100, Chris Wilson wrote: > > Quoting Ville Syrjälä (2018-09-13 11:56:56) > > > On Thu, Sep 13, 2018 at 11:39:23AM +0100, Chris Wilson wrote: > > > > If there is not a display (and so no CRTCs) then there is no upper limit > > > > to the framebuffer pitch imposed by the CRTC. > > > > > > Should we still allow you to create framebuffers in that case? > > > > Up to you, imho is that fb are just bo with a bit of description. I > > didn't see much harm in creating an fb even if it was never going to be > > attached to any pipe. I don't have a solid usecase, just feels like it > > reduces the impact on the API. > > To me it feels a bit like giving userspace false hope that they > can actually do something with the fb later. > > > > > Hmm, however if we > > if (num_pipes == 0) driver_features &= ~DRIVER_MODESET; > > we will kill the unusable API at the ioctl boundary. > > That seems a bit wrong. We'd really want to device_features for > something like that. Not sure how many things we have in the driver > struct that really ought to be under the device. Hah, yes it is one level too deep. I think the current set of driver_features is more or less device_features? That seems like an easy job though -- though some may point out that this smells of midlayer ;) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC PATCH] drm/i915: split GVT as separated module
On Thu, 13 Sep 2018, Zhenyu Wang wrote: > Joonas requested if we could move GVT into separated module. > Then obvious requirement is to export i915 functions that GVT > currently use. So this one blindly trys to export all of them > for people to review. Some of them are already only for GVT now. > But more others might need more thinking on what may better fit. > > With separated module, this also changes how GVT module loads with > i915. Initial attempt was to request loading GVT module when i915 > init, but as for dependence issue that couldn't work. Then I think we > should just enable GVT when user request to load it. So removed GVT > init from i915, also 'enable_gvt' parameter and call GVT init function > when module load. But for GVT init, we still need struct > drm_i915_private for target device, so this just hacks it to > export..Maybe we can add some interface to get that from i915? Some get/put interface indeed seems much better than exporting it directly. Some other comments inline. > Another problem for separated module is that GVT wants a clean > initial MMIO snapshot for vGPU default state. Now in upstream we > will take that snapshot during GVT init. For separated module, we > might need i915 to dump it for GVT then GVT could get it when init. > This part of change for i915 and GVT is not included in this patch yet. > > Cc: Joonas Lahtinen > Signed-off-by: Zhenyu Wang > --- > drivers/gpu/drm/i915/Kconfig | 2 +- > drivers/gpu/drm/i915/Makefile | 3 - > drivers/gpu/drm/i915/gvt/Makefile | 3 +- > drivers/gpu/drm/i915/gvt/gvt.c| 40 +- > drivers/gpu/drm/i915/gvt/gvt.h| 3 + > drivers/gpu/drm/i915/i915_drv.c | 17 +-- > drivers/gpu/drm/i915/i915_drv.h | 6 +- > drivers/gpu/drm/i915/i915_gem.c | 11 ++ > drivers/gpu/drm/i915/i915_gem_context.c | 2 + > drivers/gpu/drm/i915/i915_gem_dmabuf.c| 1 + > drivers/gpu/drm/i915/i915_gem_fence_reg.c | 2 + > drivers/gpu/drm/i915/i915_gem_gtt.c | 1 + > drivers/gpu/drm/i915/i915_params.c| 3 - > drivers/gpu/drm/i915/i915_params.h| 3 +- > drivers/gpu/drm/i915/i915_request.c | 3 + > drivers/gpu/drm/i915/i915_vma.c | 2 + > drivers/gpu/drm/i915/intel_gvt.c | 143 -- > drivers/gpu/drm/i915/intel_gvt.h | 50 > drivers/gpu/drm/i915/intel_ringbuffer.c | 1 + > drivers/gpu/drm/i915/intel_runtime_pm.c | 2 + > drivers/gpu/drm/i915/intel_uncore.c | 3 + > 21 files changed, 82 insertions(+), 219 deletions(-) > delete mode 100644 drivers/gpu/drm/i915/intel_gvt.c > delete mode 100644 drivers/gpu/drm/i915/intel_gvt.h > > diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig > index 33a458b7f1fc..a05261cabf53 100644 > --- a/drivers/gpu/drm/i915/Kconfig > +++ b/drivers/gpu/drm/i915/Kconfig > @@ -96,7 +96,7 @@ config DRM_I915_USERPTR > If in doubt, say "Y". > > config DRM_I915_GVT > -bool "Enable Intel GVT-g graphics virtualization host support" > +tristate "Enable Intel GVT-g graphics virtualization host support" > depends on DRM_I915 > depends on 64BIT > default n > diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile > index 5794f102f9b8..b3acd431c35e 100644 > --- a/drivers/gpu/drm/i915/Makefile > +++ b/drivers/gpu/drm/i915/Makefile > @@ -182,10 +182,7 @@ i915-y += i915_perf.o \ > i915_oa_cnl.o \ > i915_oa_icl.o > > -ifeq ($(CONFIG_DRM_I915_GVT),y) > -i915-y += intel_gvt.o > include $(src)/gvt/Makefile > -endif I think this should happen via obj-$(CONFIG_DRM_I915_GVT) += gvt/ Contrast with drivers/gpu/drm/Makefile and drivers/gpu/drm/i915/Makefile. Adapt the gvt/Makefile accordingly, instead of basing them on Makefile includes. > > # LPE Audio for VLV and CHT > i915-y += intel_lpe_audio.o > diff --git a/drivers/gpu/drm/i915/gvt/Makefile > b/drivers/gpu/drm/i915/gvt/Makefile > index b016dc753db9..a2e1de745d63 100644 > --- a/drivers/gpu/drm/i915/gvt/Makefile > +++ b/drivers/gpu/drm/i915/gvt/Makefile > @@ -6,5 +6,6 @@ GVT_SOURCE := gvt.o aperture_gm.o handlers.o vgpu.o > trace_points.o firmware.o \ > fb_decoder.o dmabuf.o page_track.o > > ccflags-y+= -I$(src) -I$(src)/$(GVT_DIR) > -i915-y += $(addprefix $(GVT_DIR)/, > $(GVT_SOURCE)) > +i915_gvt-y := $(addprefix $(GVT_DIR)/, > $(GVT_SOURCE)) > +obj-$(CONFIG_DRM_I915_GVT) += i915_gvt.o > obj-$(CONFIG_DRM_I915_GVT_KVMGT) += $(GVT_DIR)/kvmgt.o > diff --git a/drivers/gpu/drm/i915/gvt/gvt.c b/drivers/gpu/drm/i915/gvt/gvt.c > index 6ef5a7fc70df..2a6bbc89e20f 100644 > --- a/drivers/gpu/drm/i915/gvt/gvt.c > +++ b/drivers/gpu/drm/i915/gvt/gvt.c > @@ -30,10 +30,11 @@ > * > */ > > +#include > #include > #include > #include > - > +#include > #
[Intel-gfx] [PATCH i-g-t] igt/prime_vgem: Skip flip if no display
We try flipping a vgem surface onto a i915 scanout. However, if there is no display we want to disable the kms interface, including the addfb ioctl. On such systems the call to kms_addfb will naturally fail and the test cannot be run. Signed-off-by: Chris Wilson --- tests/prime_vgem.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/tests/prime_vgem.c b/tests/prime_vgem.c index 993a35894..952fb017a 100644 --- a/tests/prime_vgem.c +++ b/tests/prime_vgem.c @@ -764,10 +764,13 @@ static void test_flip(int i915, int vgem, unsigned hang) igt_assert(handle[i]); close(fd); - do_or_die(__kms_addfb(i915, handle[i], - bo[i].width, bo[i].height, bo[i].pitch, - DRM_FORMAT_XRGB, I915_TILING_NONE, NULL, - LOCAL_DRM_MODE_FB_MODIFIERS, &fb_id[i])); + /* May skip if i915 has no displays */ + igt_require(__kms_addfb(i915, handle[i], + bo[i].width, bo[i].height, bo[i].pitch, + DRM_FORMAT_XRGB, + I915_TILING_NONE, NULL, + LOCAL_DRM_MODE_FB_MODIFIERS, + &fb_id[i]) == 0); igt_assert(fb_id[i]); } -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next
Hi Dave, Coming to you from stormy North Carolina! It looks like Florence will wrap right around us, so hopefully no drm-misc service interruptions will occur in the next week :-) Quite a lot of activity this week, both in volume and UAPI. Two of the line items in UAPI section are functionality changes rather than new ioctls/declarations. So we'll keep a close eye out for regression reports. That's it, that's all. Please pull. drm-misc-next-2018-09-13: drm-misc-next for 4.20: UAPI Changes: - Add host endian variants for the most common formats (Gerd) - Fail ADDFB2 for big-endian drivers that don't advertise BE quirk (Gerd) - clear smem_start in fbdev for drm drivers to avoid leaking fb addr (Daniel) Cross-subsystem Changes: Core Changes: - fix drm_mode_addfb() on big endian machines (Gerd) - add timeline point to syncobj find+replace (Chunming) - more drmP.h removal effort (Daniel) - split uapi portions of drm_atomic.c into drm_atomic_uapi.c (Daniel) Driver Changes: - bochs: Convert open-coded portions to use helpers (Peter) - vkms: Add cursor support (Haneen) - udmabuf: Lots of fixups (mostly cosmetic afaict) (Gerd) - qxl: Convert to use fbdev helper (Peter) Cc: Gerd Hoffmann Cc: Chunming Zhou Cc: Daniel Vetter Cc: Peter Wu Cc: Haneen Mohammed Cheers, Sean The following changes since commit 3ee22b769fd761c98eeaceab49153c3eb7612821: drm/rockchip: rgb: add stub functions when rgb encoder is disabled (2018-09-05 15:43:14 -0400) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-2018-09-13 for you to fetch changes up to 169cc4c7a14e988985c8833ddec2f3e897de2c28: drm: bridge: document bridge attach/detach imbalance (2018-09-13 11:28:12 +0200) drm-misc-next for 4.20: UAPI Changes: - Add host endian variants for the most common formats (Gerd) - Fail ADDFB2 for big-endian drivers that don't advertise BE quirk (Gerd) - clear smem_start in fbdev for drm drivers to avoid leaking fb addr (Daniel) Cross-subsystem Changes: Core Changes: - fix drm_mode_addfb() on big endian machines (Gerd) - add timeline point to syncobj find+replace (Chunming) - more drmP.h removal effort (Daniel) - split uapi portions of drm_atomic.c into drm_atomic_uapi.c (Daniel) Driver Changes: - bochs: Convert open-coded portions to use helpers (Peter) - vkms: Add cursor support (Haneen) - udmabuf: Lots of fixups (mostly cosmetic afaict) (Gerd) - qxl: Convert to use fbdev helper (Peter) Cc: Gerd Hoffmann Cc: Chunming Zhou Cc: Daniel Vetter Cc: Peter Wu Cc: Haneen Mohammed Alexandru Gheorghe (1): drm: Clarify DRM_MODE_REFLECT_X/Y documentation Chen-Yu Tsai (2): drm/sun4i: tcon: Pass drm_encoder * into sun4i_tcon0_mode_set_cpu drm/sun4i: tcon: Rename Dithering related register macros Chris Wilson (1): drm: Reject unknown legacy bpp and depth for drm_mode_addfb ioctl Chunming Zhou (4): drm: fix syncobj null_fence_enable_signaling drm: rename null fence to stub fence in syncobj v2 drm: expand drm_syncobj_find_fence to support timeline point v2 drm: expand replace_fence to support timeline point v2 Daniel Vetter (11): drm: Add drm/drm_util.h header file drm: Drop drmP.h from drm_connector.c drm: drop drmP.h include from drm_plane.c drm: drop drmP.h include from drm_crtc.c drm/atomic: trim driver interface/docs drm: Update todo.rst drm: extract drm_atomic_uapi.c fbdev: Drop FBINFO_CAN_FORCE_OUTPUT flag vt: Remove vc_panic_force_write fbdev: Add FBINFO_HIDE_SMEM_START flag drm/fb: Stop leaking physical address Gerd Hoffmann (17): drm: replace DRIVER_PREFER_XBGR_30BPP driver flag with mode_config quirk drm: byteorder: add DRM_FORMAT_HOST_* drm: do not mask out DRM_FORMAT_BIG_ENDIAN drm: fix drm_mode_addfb() on big endian machines. drm: refuse ADDFB2 ioctl for broken bigendian drivers udmabuf: sort headers, drop uapi/ path prefix udmabuf: improve map_udmabuf error handling udmabuf: use pgoff_t for pagecount udmabuf: constify udmabuf_ops udmabuf: constify udmabuf_create args udmabuf: add MEMFD_CREATE dependency udmabuf: rework limits udmabuf: improve udmabuf_create error handling udmabuf: use EBADFD in case we didn't got a memfd udmabuf: use ENOTTY for invalid ioctls udmabuf: drop WARN_ON() check. udmabuf: use sizeof(variable) instead of sizeof(type) Haneen Mohammed (4): drm/vkms: Add cursor plane support drm/vkms: Compute CRC with Cursor Plane drm/vkms: Enable/Disable cursor support with module option drm/vkms: Add kerneldoc entry Jonathan Liu (1): drm/sun4i: tcon: Add dithering support for RGB565/RGB666 LCD panels Marc Zyngier (2): drm/rockchip: Allow driver to be shutdown on reboo
[Intel-gfx] [PATCH 1/4] drm/i915: Mark up a couple of KMS debug messages as such
For finding the panel fitter and PLL for a particular modeset is a part
of that modeset and should be included with the reset of the
DRM_DEBUG_KMS.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/intel_display.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 7fbc006be44a..3be5fa0acee8 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -6155,8 +6155,8 @@ static void i9xx_pfit_disable(struct intel_crtc *crtc)
assert_pipe_disabled(dev_priv, crtc->pipe);
- DRM_DEBUG_DRIVER("disabling pfit, current: 0x%08x\n",
-I915_READ(PFIT_CONTROL));
+ DRM_DEBUG_KMS("disabling pfit, current: 0x%08x\n",
+ I915_READ(PFIT_CONTROL));
I915_WRITE(PFIT_CONTROL, 0);
}
@@ -8678,8 +8678,8 @@ static int ironlake_crtc_compute_clock(struct intel_crtc
*crtc,
ironlake_compute_dpll(crtc, crtc_state, NULL);
if (!intel_get_shared_dpll(crtc, crtc_state, NULL)) {
- DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
-pipe_name(crtc->pipe));
+ DRM_DEBUG_KMS("failed to find PLL for pipe %c\n",
+ pipe_name(crtc->pipe));
return -EINVAL;
}
@@ -9246,8 +9246,8 @@ static int haswell_crtc_compute_clock(struct intel_crtc
*crtc,
intel_get_crtc_new_encoder(state, crtc_state);
if (!intel_get_shared_dpll(crtc, crtc_state, encoder)) {
- DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
-pipe_name(crtc->pipe));
+ DRM_DEBUG_KMS("failed to find PLL for pipe %c\n",
+ pipe_name(crtc->pipe));
return -EINVAL;
}
}
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 4/4] HAX: force i915.disable_display=1
--- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index 6c4d4a21474b..3d9fa6bb8f2b 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -63,7 +63,7 @@ struct drm_printer; param(bool, load_detect_test, false) \ param(bool, force_reset_modeset_test, false) \ param(bool, error_capture, true) \ - param(bool, disable_display, false) \ + param(bool, disable_display, true) \ param(bool, verbose_state_checks, true) \ param(bool, nuclear_pageflip, false) \ param(bool, enable_dp_mst, true) \ -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/4] drm/i915/fbdev: Use i915/drm_i915_private consistently
Convert the interface (except for the drm core callback) to accept
drm_i915_private as that is our native type of the majority of
operations.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c| 10 +--
drivers/gpu/drm/i915/intel_drv.h | 28 +++
drivers/gpu/drm/i915/intel_fbdev.c | 117 ++---
3 files changed, 77 insertions(+), 78 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 5dd7fc582e6f..a74de4428c79 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -692,7 +692,7 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (INTEL_INFO(dev_priv)->num_pipes == 0)
return 0;
- ret = intel_fbdev_init(dev);
+ ret = intel_fbdev_init(dev_priv);
if (ret)
goto cleanup_gem;
@@ -1260,7 +1260,7 @@ static void i915_driver_register(struct drm_i915_private
*dev_priv)
* irqs are fully enabled. We do it last so that the async config
* cannot run before the connectors are registered.
*/
- intel_fbdev_initial_config_async(dev);
+ intel_fbdev_initial_config_async(dev_priv);
/*
* We need to coordinate the hotplugs with the asynchronous fbdev
@@ -1527,7 +1527,7 @@ static int i915_driver_open(struct drm_device *dev,
struct drm_file *file)
*/
static void i915_driver_lastclose(struct drm_device *dev)
{
- intel_fbdev_restore_mode(dev);
+ intel_fbdev_restore_mode(to_i915(dev));
vga_switcheroo_process_delayed_switch();
}
@@ -1623,7 +1623,7 @@ static int i915_drm_suspend(struct drm_device *dev)
intel_opregion_unregister(dev_priv);
- intel_fbdev_set_suspend(dev, FBINFO_STATE_SUSPENDED, true);
+ intel_fbdev_set_suspend(dev_priv, FBINFO_STATE_SUSPENDED, true);
dev_priv->suspend_count++;
@@ -1784,7 +1784,7 @@ static int i915_drm_resume(struct drm_device *dev)
intel_opregion_register(dev_priv);
- intel_fbdev_set_suspend(dev, FBINFO_STATE_RUNNING, false);
+ intel_fbdev_set_suspend(dev_priv, FBINFO_STATE_RUNNING, false);
intel_opregion_notify_adapter(dev_priv, PCI_D0);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bf1c38728a59..daa2fc007d02 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1779,32 +1779,34 @@ bool intel_encoder_hotplug(struct intel_encoder
*encoder,
/* legacy fbdev emulation in intel_fbdev.c */
#ifdef CONFIG_DRM_FBDEV_EMULATION
-extern int intel_fbdev_init(struct drm_device *dev);
-extern void intel_fbdev_initial_config_async(struct drm_device *dev);
-extern void intel_fbdev_unregister(struct drm_i915_private *dev_priv);
-extern void intel_fbdev_fini(struct drm_i915_private *dev_priv);
-extern void intel_fbdev_set_suspend(struct drm_device *dev, int state, bool
synchronous);
-extern void intel_fbdev_output_poll_changed(struct drm_device *dev);
-extern void intel_fbdev_restore_mode(struct drm_device *dev);
+int intel_fbdev_init(struct drm_i915_private *i915);
+void intel_fbdev_initial_config_async(struct drm_i915_private *i915);
+void intel_fbdev_unregister(struct drm_i915_private *i915);
+void intel_fbdev_fini(struct drm_i915_private *i915);
+void intel_fbdev_set_suspend(struct drm_i915_private *i915,
+int state, bool synchronous);
+void intel_fbdev_restore_mode(struct drm_i915_private *i915);
+void intel_fbdev_output_poll_changed(struct drm_device *dev);
#else
-static inline int intel_fbdev_init(struct drm_device *dev)
+static inline int intel_fbdev_init(struct drm_i915_private *i915)
{
return 0;
}
-static inline void intel_fbdev_initial_config_async(struct drm_device *dev)
+static inline void intel_fbdev_initial_config_async(struct drm_i915_private
*i915)
{
}
-static inline void intel_fbdev_unregister(struct drm_i915_private *dev_priv)
+static inline void intel_fbdev_unregister(struct drm_i915_private *i915)
{
}
-static inline void intel_fbdev_fini(struct drm_i915_private *dev_priv)
+static inline void intel_fbdev_fini(struct drm_i915_private *i915)
{
}
-static inline void intel_fbdev_set_suspend(struct drm_device *dev, int state,
bool synchronous)
+static inline void intel_fbdev_set_suspend(struct drm_i915_private *i915,
+ int state, bool synchronous)
{
}
@@ -1812,7 +1814,7 @@ static inline void intel_fbdev_output_poll_changed(struct
drm_device *dev)
{
}
-static inline void intel_fbdev_restore_mode(struct drm_device *dev)
+static inline void intel_fbdev_restore_mode(struct drm_i915_private *i915)
{
}
#endif
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index f99332972b7a..84ebd8102215 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -54,11 +54,14 @@ static void intel_fbdev_invalidate(struct
[Intel-gfx] [PATCH 3/4] drm/i915: Disable displays at the user's request
If the user passes i915.disable_display=1 we want to disable all the
displays and associated HW like the powerwells on their behalf. Instead
of short circuiting the HW probe, let it run and setup all the
bookkeeping for the known HW. Afterwards, instead of taking over the
BIOS fb and installing the fbcon, we shutdown all the outputs and
teardown the bookkeeping, leaving us with no attached outputs or crtcs,
and all the HW powered down.
Open: wq flushes should be required but seem to deadlock the modprobe
under CI.
Signed-off-by: Chris Wilson
Cc: Imre Deak
Cc: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.c | 52 +---
drivers/gpu/drm/i915/intel_device_info.c | 9 ++--
drivers/gpu/drm/i915/intel_fbdev.c | 2 +-
3 files changed, 42 insertions(+), 21 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a74de4428c79..f34a1f5b99e5 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -689,22 +689,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
intel_setup_overlay(dev_priv);
- if (INTEL_INFO(dev_priv)->num_pipes == 0)
- return 0;
-
- ret = intel_fbdev_init(dev_priv);
- if (ret)
- goto cleanup_gem;
-
- /* Only enable hotplug handling once the fbdev is fully set up. */
- intel_hpd_init(dev_priv);
-
return 0;
-cleanup_gem:
- if (i915_gem_suspend(dev_priv))
- DRM_ERROR("failed to idle hardware; continuing to unload!\n");
- i915_gem_fini(dev_priv);
cleanup_modeset:
intel_modeset_cleanup(dev);
cleanup_irq:
@@ -1366,6 +1352,17 @@ static void i915_driver_destroy(struct drm_i915_private
*i915)
pci_set_drvdata(pdev, NULL);
}
+static void disable_display(struct drm_i915_private *i915)
+{
+ drm_atomic_helper_shutdown(&i915->drm);
+
+#if 0 /* XXX flushes deadlock under modprobe??? */
+ flush_workqueue(i915->modeset_wq);
+ flush_work(&i915->atomic_helper.free_work);
+ flush_scheduled_work();
+#endif
+}
+
/**
* i915_driver_load - setup chip and create an initial config
* @pdev: PCI device
@@ -1426,6 +1423,33 @@ int i915_driver_load(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_hw;
+ /*
+* After completing our HW probe; tear it all down again (at the
+* user's request)!
+*
+* Along side the CRTCs and connectors, there is a medley of
+* auxiliary HW which control various powerwells and interact with
+* other state (such as the BIOS framebuffer occupying a portion
+* of reserved memory). If the user tells us to run without any
+* displays enabled, we still need to register all the display and
+* auxiliary HW in order to safely disable them.
+*/
+ if (i915_modparams.disable_display) {
+ DRM_INFO("Display disabled (module parameter)\n");
+ disable_display(dev_priv);
+ mkwrite_device_info(dev_priv)->num_pipes = 0;
+ }
+
+ if (INTEL_INFO(dev_priv)->num_pipes == 0) {
+ dev_priv->psr.sink_support = false;
+ drm_mode_config_cleanup(&dev_priv->drm);
+ driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC);
+ }
+
+ /* Only enable hotplug handling once the fbdev is fully set up. */
+ if (intel_fbdev_init(dev_priv) == 0)
+ intel_hpd_init(dev_priv);
+
i915_driver_register(dev_priv);
intel_init_ipc(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_device_info.c
b/drivers/gpu/drm/i915/intel_device_info.c
index 0ef0c6448d53..e50ea5b2576b 100644
--- a/drivers/gpu/drm/i915/intel_device_info.c
+++ b/drivers/gpu/drm/i915/intel_device_info.c
@@ -776,12 +776,9 @@ void intel_device_info_runtime_init(struct
intel_device_info *info)
info->num_sprites[pipe] = 1;
}
- if (i915_modparams.disable_display) {
- DRM_INFO("Display disabled (module parameter)\n");
- info->num_pipes = 0;
- } else if (info->num_pipes > 0 &&
- (IS_GEN7(dev_priv) || IS_GEN8(dev_priv)) &&
- HAS_PCH_SPLIT(dev_priv)) {
+ if (info->num_pipes > 0 &&
+ (IS_GEN7(dev_priv) || IS_GEN8(dev_priv)) &&
+ HAS_PCH_SPLIT(dev_priv)) {
u32 fuse_strap = I915_READ(FUSE_STRAP);
u32 sfuse_strap = I915_READ(SFUSE_STRAP);
diff --git a/drivers/gpu/drm/i915/intel_fbdev.c
b/drivers/gpu/drm/i915/intel_fbdev.c
index 84ebd8102215..9dd50c5ec558 100644
--- a/drivers/gpu/drm/i915/intel_fbdev.c
+++ b/drivers/gpu/drm/i915/intel_fbdev.c
@@ -668,7 +668,7 @@ int intel_fbdev_init(struct drm_i915_private *i915)
struct intel_fbdev *ifbdev;
int ret;
- if (WARN_ON(INTEL_INFO(i915)->num_pipes == 0))
+ if (INTEL_INFO(i915)->num_pipes == 0
[Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
From: Ville Syrjälä
We wish to control certain driver_features flags on a per-device basis
while still sharing a single drm_driver instance across all the
devices. To that end introduce device.driver_features. By default
it will be set to ~0 to not impose any limits beyond
driver.driver_features. Drivers can then clear specific flags
in the per-device bitmask to limit the capabilities of the device.
An alternative approach would be to copy the driver_features from
the driver into the device in drm_dev_init(), however that would
require verifying that no driver is currently changing
driver.driver_features after drm_dev_init(). Hence the ~0 apporach
was easier.
Ideally we'd also make drm_driver const but there is plenty of code
left that wants to mutate it (eg. various vfunc assignments). We'll
need to fix all that up before we can make it const.
And while at it fix up the type of the feature flag passed to
drm_core_check_feature().
v2: Streamline the && vs. & (Chris)
s/int/u32/ in drm_core_check_feature() args
Cc: Chris Wilson
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_drv.c | 3 +++
include/drm/drm_device.h | 10 ++
include/drm/drm_drv.h | 8
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
index ea4941da9b27..36e8e9cbec52 100644
--- a/drivers/gpu/drm/drm_drv.c
+++ b/drivers/gpu/drm/drm_drv.c
@@ -506,6 +506,9 @@ int drm_dev_init(struct drm_device *dev,
dev->dev = parent;
dev->driver = driver;
+ /* no per-device feature limits by default */
+ dev->driver_features = ~0u;
+
INIT_LIST_HEAD(&dev->filelist);
INIT_LIST_HEAD(&dev->filelist_internal);
INIT_LIST_HEAD(&dev->clientlist);
diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
index f9c6e0e3aec7..42411b3ea0c8 100644
--- a/include/drm/drm_device.h
+++ b/include/drm/drm_device.h
@@ -45,6 +45,16 @@ struct drm_device {
/* currently active master for this device. Protected by master_mutex */
struct drm_master *master;
+ /**
+* @driver_features: per-device driver features
+*
+* Drivers can clear specific flags here to disallow
+* certain features on a per-device basis while still
+* sharing a single &struct drm_driver instance across
+* all devices.
+*/
+ u32 driver_features;
+
/**
* @unplugged:
*
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index 23b9678137a6..8830e3de3a86 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -653,14 +653,14 @@ static inline bool drm_dev_is_unplugged(struct drm_device
*dev)
* @dev: DRM device to check
* @feature: feature flag
*
- * This checks @dev for driver features, see &drm_driver.driver_features and
the
- * various DRIVER_\* flags.
+ * This checks @dev for driver features, see &drm_driver.driver_features,
+ * &drm_device.driver_features, and the various DRIVER_\* flags.
*
* Returns true if the @feature is supported, false otherwise.
*/
-static inline bool drm_core_check_feature(struct drm_device *dev, int feature)
+static inline bool drm_core_check_feature(struct drm_device *dev, u32 feature)
{
- return dev->driver->driver_features & feature;
+ return dev->driver->driver_features & dev->driver_features & feature;
}
/**
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Clear DRIVER_ATOMIC on a per-device basis
From: Ville Syrjälä Currently we're clearing DRIVER_ATOMIC in driver.driver_features for older platforms. This will not work correctly should we ever have a system with and old and new GPU in it. While that is not possible currently let's make the code more correct and use the per-device driver_features instead. Cc: Chris Wilson Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/i915/i915_drv.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 5dd7fc582e6f..2ddf8538cb47 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1384,14 +1384,14 @@ int i915_driver_load(struct pci_dev *pdev, const struct pci_device_id *ent) struct drm_i915_private *dev_priv; int ret; - /* Enable nuclear pageflip on ILK+ */ - if (!i915_modparams.nuclear_pageflip && match_info->gen < 5) - driver.driver_features &= ~DRIVER_ATOMIC; - dev_priv = i915_driver_create(pdev, ent); if (!dev_priv) return -ENOMEM; + /* Disable nuclear pageflip by default on pre-ILK */ + if (!i915_modparams.nuclear_pageflip && match_info->gen < 5) + dev_priv->drm.driver_features &= ~DRIVER_ATOMIC; + ret = pci_enable_device(pdev); if (ret) goto out_fini; -- 2.16.4 ___ 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: Remove fb pitch limit for no display
== Series Details == Series: drm/i915: Remove fb pitch limit for no display URL : https://patchwork.freedesktop.org/series/49625/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4816_full -> Patchwork_10166_full = == Summary - WARNING == Minor unknown changes coming with Patchwork_10166_full need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10166_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_10166_full: === IGT changes === Warnings igt@kms_draw_crc@draw-method-xrgb-mmap-gtt-xtiled: shard-snb: PASS -> SKIP +5 == Known issues == Here are the changes found in Patchwork_10166_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_cursor_legacy@cursor-vs-flip-toggle: shard-hsw: PASS -> FAIL (fdo#103355) igt@kms_flip@dpms-vs-vblank-race-interruptible: shard-kbl: PASS -> FAIL (fdo#103060) igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-indfb-pgflip-blt: shard-glk: PASS -> DMESG-FAIL (fdo#106538) igt@kms_plane_scaling@pipe-b-scaler-with-rotation: shard-glk: PASS -> DMESG-WARN (fdo#105763, fdo#106538) +1 igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS igt@kms_color@pipe-c-ctm-max: shard-kbl: DMESG-WARN (fdo#103558, fdo#105602) -> PASS +34 igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_setmode@basic: shard-hsw: FAIL (fdo#99912) -> PASS fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103355 https://bugs.freedesktop.org/show_bug.cgi?id=103355 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105763 https://bugs.freedesktop.org/show_bug.cgi?id=105763 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106538 https://bugs.freedesktop.org/show_bug.cgi?id=106538 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4816 -> Patchwork_10166 CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10166: 1b805e4c8215a284269e9cfcf3b0bf7921f37539 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10166/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Disable displays at the user's request
Quoting Chris Wilson (2018-09-13 14:16:28)
> + /*
> +* After completing our HW probe; tear it all down again (at the
> +* user's request)!
> +*
> +* Along side the CRTCs and connectors, there is a medley of
> +* auxiliary HW which control various powerwells and interact with
> +* other state (such as the BIOS framebuffer occupying a portion
> +* of reserved memory). If the user tells us to run without any
> +* displays enabled, we still need to register all the display and
> +* auxiliary HW in order to safely disable them.
> +*/
> + if (i915_modparams.disable_display) {
> + DRM_INFO("Display disabled (module parameter)\n");
> + disable_display(dev_priv);
> + mkwrite_device_info(dev_priv)->num_pipes = 0;
> + }
> +
> + if (INTEL_INFO(dev_priv)->num_pipes == 0) {
> + dev_priv->psr.sink_support = false;
> + drm_mode_config_cleanup(&dev_priv->drm);
> + driver.driver_features &= ~(DRIVER_MODESET | DRIVER_ATOMIC);
Removing the feature seems like a good idea on surface (as we then don't
have to worry about hitting internals that expect crtcs and planes and
such), however more work required in declaring igt requirements than
simply having no pipes :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 2/2] lib: Skip drmModeReources()
An alternative to requiring the display is to mark the attached display as empty (no available CRTC, no outputs) and let the tests skip if they required any output. This allows the binary to open the display once in its global fixture, even if it doesn't use the display in every subtest and so avoid skipping the subtests that didn't require the display. Signed-off-by: Chris Wilson --- lib/igt_kms.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 0e6f91475..b38d64415 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1857,7 +1857,8 @@ void igt_display_init(igt_display_t *display, int drm_fd) display->drm_fd = drm_fd; resources = drmModeGetResources(display->drm_fd); - igt_require(resources); + if (!resources) + goto out; /* * We cache the number of pipes, that number is a physical limit of the @@ -2005,6 +2006,7 @@ void igt_display_init(igt_display_t *display, int drm_fd) igt_display_reset(display); igt_kms_disallow_hotplug(drm_fd); +out: LOG_UNINDENT(display); } -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] lib: Require drmModeResources()
If modesetting is not supported, the drmModeGetResources() call will fail with -EINVAL (or -ENOTSUPP). As no displays are connected, skip. Signed-off-by: Chris Wilson --- lib/igt_kms.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lib/igt_kms.c b/lib/igt_kms.c index 3e0a07b98..0e6f91475 100644 --- a/lib/igt_kms.c +++ b/lib/igt_kms.c @@ -1857,7 +1857,7 @@ void igt_display_init(igt_display_t *display, int drm_fd) display->drm_fd = drm_fd; resources = drmModeGetResources(display->drm_fd); - igt_assert(resources); + igt_require(resources); /* * We cache the number of pipes, that number is a physical limit of the -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
Quoting Ville Syrjala (2018-09-13 14:16:21) > From: Ville Syrjälä > > We wish to control certain driver_features flags on a per-device basis > while still sharing a single drm_driver instance across all the > devices. To that end introduce device.driver_features. By default > it will be set to ~0 to not impose any limits beyond > driver.driver_features. Drivers can then clear specific flags > in the per-device bitmask to limit the capabilities of the device. > > An alternative approach would be to copy the driver_features from > the driver into the device in drm_dev_init(), however that would > require verifying that no driver is currently changing > driver.driver_features after drm_dev_init(). Hence the ~0 apporach > was easier. > > Ideally we'd also make drm_driver const but there is plenty of code > left that wants to mutate it (eg. various vfunc assignments). We'll > need to fix all that up before we can make it const. > > And while at it fix up the type of the feature flag passed to > drm_core_check_feature(). > > v2: Streamline the && vs. & (Chris) > s/int/u32/ in drm_core_check_feature() args > > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä The gradual transition makes sense (less work!), as does being able to deselect features on individual devices. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Clear DRIVER_ATOMIC on a per-device basis
Quoting Ville Syrjala (2018-09-13 14:16:22) > From: Ville Syrjälä > > Currently we're clearing DRIVER_ATOMIC in driver.driver_features > for older platforms. This will not work correctly should we ever > have a system with and old and new GPU in it. While that is not > possible currently let's make the code more correct and use > the per-device driver_features instead. > > Cc: Chris Wilson > Signed-off-by: Ville Syrjälä One day we will be able to have driver const again, Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm: Differentiate the lack of an interface from invalid parameter
On Wed, Sep 12, 2018 at 10:29:42AM +0100, Chris Wilson wrote:
> If the ioctl is not supported on a particular piece of HW/driver
> combination, report ENOTSUPP so that it can be easily distinguished from
> both the lack of the ioctl and from a regular invalid parameter.
>
> v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
> ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
> drm_core_check_feature(). Update everybody to report ENOTSUPP.
>
> Signed-off-by: Chris Wilson
> Cc: Daniel Vetter
> Cc: Ville Syrjälä
I think there's a few somewhat questionable ones among the legacy
functions (not sure we should throw an ENOTSUPP when it's only called by
driver code, not userspace, WARN_ON feels more appropriate).
But I only spotted that for legacy functionality, nothing we'll ever care
about. Ang sprinkling this all over definitely increases the odds that
it'll be adopted successfully.
As-is:
Reviewed-by: Daniel Vetter
> ---
> drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
> drivers/gpu/drm/drm_bufs.c| 32 +++
> drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
> drivers/gpu/drm/drm_connector.c | 2 +-
> drivers/gpu/drm/drm_context.c | 16
> drivers/gpu/drm/drm_crtc.c| 4 ++--
> drivers/gpu/drm/drm_encoder.c | 2 +-
> drivers/gpu/drm/drm_framebuffer.c | 13 -
> drivers/gpu/drm/drm_gem.c | 6 +++---
> drivers/gpu/drm/drm_ioctl.c | 2 +-
> drivers/gpu/drm/drm_irq.c | 4 ++--
> drivers/gpu/drm/drm_lease.c | 8
> drivers/gpu/drm/drm_lock.c| 4 ++--
> drivers/gpu/drm/drm_mode_config.c | 2 +-
> drivers/gpu/drm/drm_mode_object.c | 4 ++--
> drivers/gpu/drm/drm_pci.c | 4 ++--
> drivers/gpu/drm/drm_plane.c | 10 +-
> drivers/gpu/drm/drm_prime.c | 4 ++--
> drivers/gpu/drm/drm_property.c| 8
> drivers/gpu/drm/drm_scatter.c | 8
> drivers/gpu/drm/drm_syncobj.c | 14 +++---
> drivers/gpu/drm/drm_vblank.c | 4 ++--
> 22 files changed, 80 insertions(+), 77 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
> b/drivers/gpu/drm/drm_atomic_uapi.c
> index 26690a664ec6..dc4502464126 100644
> --- a/drivers/gpu/drm/drm_atomic_uapi.c
> +++ b/drivers/gpu/drm/drm_atomic_uapi.c
> @@ -1251,7 +1251,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
>
> /* disallow for drivers not supporting atomic: */
> if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> /* disallow for userspace that has not enabled atomic cap (even
>* though this may be a bit overkill, since legacy userspace
> diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
> index ba8cfe65c65b..a07e7a781d64 100644
> --- a/drivers/gpu/drm/drm_bufs.c
> +++ b/drivers/gpu/drm/drm_bufs.c
> @@ -398,7 +398,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
> *data,
>
> if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> !drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> err = drm_addmap_core(dev, map->offset, map->size, map->type,
> map->flags, &maplist);
> @@ -444,7 +444,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
> *data,
>
> if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> !drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> idx = map->offset;
> if (idx < 0)
> @@ -596,7 +596,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
> *data,
>
> if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
> !drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> mutex_lock(&dev->struct_mutex);
> list_for_each_entry(r_list, &dev->maplist, head) {
> @@ -860,7 +860,7 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
> struct drm_buf **temp_buflist;
>
> if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> if (!dma)
> return -EINVAL;
> @@ -1064,7 +1064,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
> struct drm_buf **temp_buflist;
>
> if (!drm_core_check_feature(dev, DRIVER_SG))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> if (!dma)
> return -EINVAL;
> @@ -1221,10 +1221,10 @@ int drm_legacy_addbufs(struct drm_device *dev, void
> *data,
> int ret;
>
> if (!drm_core_check_feature(dev, DRIVER_LEGACY))
> - return -EINVAL;
> + return -ENOTSUPP;
>
> if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
> - return -EINVAL;
> +
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Mark up a couple of KMS debug messages as such
== Series Details == Series: series starting with [1/4] drm/i915: Mark up a couple of KMS debug messages as such URL : https://patchwork.freedesktop.org/series/49641/ State : warning == Summary == $ dim checkpatch origin/drm-tip b7501effb8ce drm/i915: Mark up a couple of KMS debug messages as such 020c81668c9d drm/i915/fbdev: Use i915/drm_i915_private consistently -:284: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #284: FILE: drivers/gpu/drm/i915/intel_fbdev.c:541: +static bool intel_fbdev_init_bios(struct drm_i915_private *i915, struct intel_fbdev *ifbdev) total: 0 errors, 0 warnings, 1 checks, 397 lines checked f54c19c75cc9 drm/i915: Disable displays at the user's request -:59: WARNING:IF_0: Consider removing the code enclosed by this #if 0 and its #endif #59: FILE: drivers/gpu/drm/i915/i915_drv.c:1359: +#if 0 /* XXX flushes deadlock under modprobe??? */ total: 0 errors, 1 warnings, 0 checks, 95 lines checked 2313360e29d8 HAX: force i915.disable_display=1 -:8: WARNING:COMMIT_MESSAGE: Missing commit description - Add an appropriate one -:19: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 8 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/4] drm/i915: Mark up a couple of KMS debug messages as such
== Series Details == Series: series starting with [1/4] drm/i915: Mark up a couple of KMS debug messages as such URL : https://patchwork.freedesktop.org/series/49641/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Mark up a couple of KMS debug messages as such Okay! Commit: drm/i915/fbdev: Use i915/drm_i915_private consistently -O:drivers/gpu/drm/i915/intel_fbdev.c:340:30: warning: expression using sizeof(void) +drivers/gpu/drm/i915/intel_fbdev.c:337:30: warning: expression using sizeof(void) Commit: drm/i915: Disable displays at the user's request Okay! Commit: HAX: force i915.disable_display=1 Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> We wish to control certain driver_features flags on a per-device basis
> while still sharing a single drm_driver instance across all the
> devices. To that end introduce device.driver_features. By default
> it will be set to ~0 to not impose any limits beyond
> driver.driver_features. Drivers can then clear specific flags
> in the per-device bitmask to limit the capabilities of the device.
>
> An alternative approach would be to copy the driver_features from
> the driver into the device in drm_dev_init(), however that would
> require verifying that no driver is currently changing
> driver.driver_features after drm_dev_init(). Hence the ~0 apporach
> was easier.
>
> Ideally we'd also make drm_driver const but there is plenty of code
> left that wants to mutate it (eg. various vfunc assignments). We'll
> need to fix all that up before we can make it const.
>
> And while at it fix up the type of the feature flag passed to
> drm_core_check_feature().
>
> v2: Streamline the && vs. & (Chris)
> s/int/u32/ in drm_core_check_feature() args
>
> Cc: Chris Wilson
> Signed-off-by: Ville Syrjälä
git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting
case for this. Exactly same problem as we have here. Would be good to also
convert that one, for a bit of OCD.
Irrespective of that, on the series:
Reviewed-by: Daniel Vetter
Feel free to also add the r-b to the nouveau patch if you do it, it's
rather obvious.
-Daniel
> ---
> drivers/gpu/drm/drm_drv.c | 3 +++
> include/drm/drm_device.h | 10 ++
> include/drm/drm_drv.h | 8
> 3 files changed, 17 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> index ea4941da9b27..36e8e9cbec52 100644
> --- a/drivers/gpu/drm/drm_drv.c
> +++ b/drivers/gpu/drm/drm_drv.c
> @@ -506,6 +506,9 @@ int drm_dev_init(struct drm_device *dev,
> dev->dev = parent;
> dev->driver = driver;
>
> + /* no per-device feature limits by default */
> + dev->driver_features = ~0u;
> +
> INIT_LIST_HEAD(&dev->filelist);
> INIT_LIST_HEAD(&dev->filelist_internal);
> INIT_LIST_HEAD(&dev->clientlist);
> diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> index f9c6e0e3aec7..42411b3ea0c8 100644
> --- a/include/drm/drm_device.h
> +++ b/include/drm/drm_device.h
> @@ -45,6 +45,16 @@ struct drm_device {
> /* currently active master for this device. Protected by master_mutex */
> struct drm_master *master;
>
> + /**
> + * @driver_features: per-device driver features
> + *
> + * Drivers can clear specific flags here to disallow
> + * certain features on a per-device basis while still
> + * sharing a single &struct drm_driver instance across
> + * all devices.
> + */
> + u32 driver_features;
> +
> /**
>* @unplugged:
>*
> diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> index 23b9678137a6..8830e3de3a86 100644
> --- a/include/drm/drm_drv.h
> +++ b/include/drm/drm_drv.h
> @@ -653,14 +653,14 @@ static inline bool drm_dev_is_unplugged(struct
> drm_device *dev)
> * @dev: DRM device to check
> * @feature: feature flag
> *
> - * This checks @dev for driver features, see &drm_driver.driver_features and
> the
> - * various DRIVER_\* flags.
> + * This checks @dev for driver features, see &drm_driver.driver_features,
> + * &drm_device.driver_features, and the various DRIVER_\* flags.
> *
> * Returns true if the @feature is supported, false otherwise.
> */
> -static inline bool drm_core_check_feature(struct drm_device *dev, int
> feature)
> +static inline bool drm_core_check_feature(struct drm_device *dev, u32
> feature)
> {
> - return dev->driver->driver_features & feature;
> + return dev->driver->driver_features & dev->driver_features & feature;
> }
>
> /**
> --
> 2.16.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/4] drm/i915: Mark up a couple of KMS debug messages as such
== Series Details ==
Series: series starting with [1/4] drm/i915: Mark up a couple of KMS debug
messages as such
URL : https://patchwork.freedesktop.org/series/49641/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4816 -> Patchwork_10167 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10167 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10167, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49641/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_10167:
=== IGT changes ===
Possible regressions
igt@debugfs_test@read_all_entries:
fi-kbl-soraka: PASS -> FAIL
igt@kms_addfb_basic@addfb25-bad-modifier:
fi-bdw-gvtdvm: PASS -> FAIL +73
fi-gdg-551: PASS -> FAIL +66
igt@kms_addfb_basic@addfb25-modifier-no-flag:
fi-cfl-guc: PASS -> FAIL +77
igt@kms_addfb_basic@addfb25-y-tiled:
fi-kbl-r: PASS -> FAIL +76
fi-byt-n2820: PASS -> FAIL +69
igt@kms_addfb_basic@addfb25-y-tiled-small:
fi-bdw-samus: SKIP -> FAIL +4
fi-bdw-5557u: SKIP -> FAIL +4
fi-byt-n2820: SKIP -> FAIL +11
fi-hsw-4770:SKIP -> FAIL
fi-ivb-3770:SKIP -> FAIL +3
igt@kms_addfb_basic@bad-pitch-1024:
fi-ivb-3520m: PASS -> FAIL +76
igt@kms_addfb_basic@bad-pitch-32:
fi-whl-u: PASS -> FAIL +76
igt@kms_addfb_basic@bad-pitch-63:
fi-kbl-7567u: PASS -> FAIL +77
igt@kms_addfb_basic@basic:
fi-byt-j1900: PASS -> FAIL +73
igt@kms_addfb_basic@basic-y-tiled:
fi-bdw-samus: PASS -> FAIL +68
fi-cfl-8109u: PASS -> FAIL +77
fi-cfl-s3: PASS -> FAIL +76
igt@kms_addfb_basic@invalid-get-prop-any:
fi-skl-6600u: PASS -> FAIL +76
fi-bsw-n3050: PASS -> FAIL +61
fi-ivb-3770:PASS -> FAIL +77
fi-kbl-7560u: PASS -> FAIL +76
igt@kms_addfb_basic@invalid-set-prop:
fi-hsw-4770:PASS -> FAIL +80
igt@kms_addfb_basic@invalid-set-prop-any:
fi-glk-dsi: PASS -> FAIL +76
igt@kms_addfb_basic@no-handle:
fi-cfl-8700k: PASS -> FAIL +77
igt@kms_addfb_basic@too-high:
fi-glk-j4005: PASS -> FAIL +77
igt@kms_addfb_basic@unused-modifier:
fi-bdw-5557u: PASS -> FAIL +76
fi-kbl-8809g: PASS -> FAIL +40
fi-kbl-guc: PASS -> FAIL +40
igt@kms_addfb_basic@unused-offsets:
fi-bwr-2160:PASS -> FAIL +66
fi-blb-e6850: PASS -> FAIL +66
igt@kms_addfb_basic@unused-pitches:
fi-kbl-x1275: PASS -> FAIL +40
fi-skl-gvtdvm: PASS -> FAIL +74
igt@kms_busy@basic-flip-b:
fi-kbl-8809g: SKIP -> FAIL +40
igt@kms_chamelium@dp-hpd-fast:
fi-skl-6700k2: SKIP -> FAIL +8
igt@kms_chamelium@hdmi-crc-fast:
fi-skl-6700k2: PASS -> FAIL +81
igt@kms_chamelium@vga-hpd-fast:
fi-kbl-7500u: SKIP -> FAIL +8
igt@kms_cursor_legacy@basic-flip-after-cursor-varying-size:
fi-skl-guc: PASS -> FAIL +77
igt@kms_flip@basic-flip-vs-dpms:
fi-ilk-650: PASS -> FAIL +70
fi-pnv-d510:PASS -> FAIL +66
fi-skl-6770hq: PASS -> FAIL +77
igt@kms_flip@basic-flip-vs-modeset:
fi-kbl-x1275: SKIP -> FAIL +40
{fi-cnl-u}: NOTRUN -> FAIL +81
igt@kms_flip@basic-flip-vs-wf_vblank:
fi-icl-u: NOTRUN -> FAIL +81
fi-hsw-peppy: PASS -> FAIL +74
fi-snb-2600:PASS -> FAIL +70
fi-skl-6260u: PASS -> FAIL +77
igt@kms_force_connector_basic@force-connector-state:
fi-cfl-8700k: SKIP -> FAIL +3
fi-skl-6600u: SKIP -> FAIL +4
fi-byt-clapper: SKIP -> FAIL +12
fi-kbl-r: SKIP -> FAIL +4
fi-skl-6770hq: SKIP -> FAIL +3
igt@kms_force_connector_basic@force-edid:
fi-snb-2520m: PASS -> FAIL +69
fi-glk-dsi: SKIP -> FAIL +4
fi-skl-6260u: SKIP -> FAIL +3
igt@kms_force_connector_basic@force-load-detect:
fi-kbl-7560u: SKIP -> FAIL +4
fi-bxt-dsi: SKIP -> FAIL +4
fi-bxt-j4205: SKIP -> FAIL +3
fi-skl-iommu: SKIP -> FAIL +3
fi-glk-j4005: SKIP -> FAIL +3
fi-cfl-guc: SKIP -> FAIL +3
fi-kbl-7567u: SKIP -> FAIL +3
fi-skl-guc: SKIP -> FAIL +3
fi-hsw-4770r: SKIP -> FAIL +4
igt@kms_force_connector_basic@prune-stale-modes:
fi-hsw-peppy: SKIP -> FAIL +5
fi-cfl-8109u: SKIP -> FAIL +3
fi-cfl-s3:
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
On Wed, Sep 12, 2018 at 08:18:37PM +0200, Takashi Iwai wrote:
> On Wed, 12 Sep 2018 15:18:47 +0200,
> Imre Deak wrote:
> >
> > +Takashi
> >
> > On Wed, Sep 12, 2018 at 04:18:12PM +0300, Imre Deak wrote:
> > > Hi Kumar, Takashi,
> > >
> > > On Tue, Jun 19, 2018 at 03:01:11PM -0700, Abhay Kumar wrote:
> > > > From: Ville Syrjälä
> > > >
> > > > CDCLK has to be at least twice the BLCK regardless of audio. Audio
> > > > driver has to probe using this hook and increase the clock even in
> > > > absence of any display.
> > > >
> > > > v2: Use atomic refcount for get_power, put_power so that we can
> > > > call each once(Abhay).
> > > > v3: Reset power well 2 to avoid any transaction on iDisp link
> > > > during cdclk change(Abhay).
> > > > v4: Remove Power well 2 reset workaround(Ville).
> > > > v5: Remove unwanted Power well 2 register defined in v4(Abhay).
> > > >
> > > > Signed-off-by: Ville Syrjälä
> > > > Signed-off-by: Abhay Kumar
> > > > ---
> > > > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > > > drivers/gpu/drm/i915/intel_audio.c | 67
> > > > +---
> > > > drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
> > > > drivers/gpu/drm/i915/intel_display.c | 7 +++-
> > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > > > 5 files changed, 83 insertions(+), 25 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 6104d7115054..a4a386a5db69 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -1702,6 +1702,7 @@ struct drm_i915_private {
> > > > unsigned int hpll_freq;
> > > > unsigned int fdi_pll_freq;
> > > > unsigned int czclk_freq;
> > > > + u32 get_put_refcount;
> > > >
> > > > struct {
> > > > /*
> > > > @@ -1719,6 +1720,8 @@ struct drm_i915_private {
> > > > struct intel_cdclk_state actual;
> > > > /* The current hardware cdclk state */
> > > > struct intel_cdclk_state hw;
> > > > +
> > > > + int force_min_cdclk;
> > > > } cdclk;
> > > >
> > > > /**
> > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > index 3ea566f99450..ca8f04c7cbb3 100644
> > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct intel_encoder
> > > > *encoder,
> > > >
> > > > if (!connector->eld[0])
> > > > return;
> > > > -
> > > > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> > > > connector->base.id,
> > > > connector->name,
> > > > @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct
> > > > drm_i915_private *dev_priv)
> > > > }
> > > > }
> > > >
> > > > +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> > > > + bool enable)
> > > > +{
> > > > + struct drm_modeset_acquire_ctx ctx;
> > > > + struct drm_atomic_state *state;
> > > > + int ret;
> > > > +
> > > > + drm_modeset_acquire_init(&ctx, 0);
> > > > + state = drm_atomic_state_alloc(&dev_priv->drm);
> > > > + if (WARN_ON(!state))
> > > > + return;
> > > > +
> > > > + state->acquire_ctx = &ctx;
> > > > +
> > > > +retry:
> > > > + to_intel_atomic_state(state)->modeset = true;
> > > > + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> > > > + enable ? 2 * 96000 : 0;
> > > > +
> > > > + /*
> > > > +* Protects dev_priv->cdclk.force_min_cdclk
> > > > +* Need to lock this here in case we have no active pipes
> > > > +* and thus wouldn't lock it during the commit otherwise.
> > > > +*/
> > > > + ret =
> > > > drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex, &ctx);
> > > > + if (!ret)
> > > > + ret = drm_atomic_commit(state);
> > >
> > > Ville mentioned a potential dead-lock problem here: a normal modeset
> > > enabling an HDMI/DP output with an audio sink will call the
> > > drm_audio_component_audio_ops::pin_eld_notify() callback with the
> > > connection_mutex already held. This callback in turn could call
> > > drm_audio_component_ops::get_power()/put_power() callbacks and
> > > dead-lock at the above drm_modeset_lock() call.
> > >
> > > Looks like that
> > >
> > >sound/pci/hda/patch_hdmi.c / intel_pin_eld_notify()->
> > >check_presence_and_report()->
> > >hdmi_present_sense()
> > >
> > > would prevent this, but for instance
> > >
> > >sound/soc/codecs/hdac_hdmi.c / hdac_hdmi_eld_notify_cb()->
> > >hdac_hdmi_present_sense()->
> > >hdac_hdmi_jack_report()->
> > >snd_soc_jack_report()->
> > >snd_soc_dapm_sync()->
> > >
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm: Introduce per-device driver_features
== Series Details ==
Series: series starting with [1/2] drm: Introduce per-device driver_features
URL : https://patchwork.freedesktop.org/series/49639/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4816 -> Patchwork_10168 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49639/revisions/1/mbox/
== Known issues ==
Here are the changes found in Patchwork_10168 that come from known issues:
=== IGT changes ===
Issues hit
igt@amdgpu/amd_cs_nop@sync-fork-gfx0:
fi-kbl-8809g: PASS -> DMESG-WARN (fdo#107762) +1
igt@drv_selftest@live_coherency:
fi-gdg-551: PASS -> DMESG-FAIL (fdo#107164)
igt@kms_frontbuffer_tracking@basic:
fi-byt-clapper: PASS -> FAIL (fdo#103167)
igt@kms_psr@primary_mmap_gtt:
{fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3
igt@kms_psr@primary_page_flip:
fi-kbl-r: PASS -> FAIL (fdo#107336)
igt@pm_rpm@basic-pci-d3-state:
fi-glk-dsi: PASS -> INCOMPLETE (fdo#103359, k.org#198133)
Possible fixes
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359
fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
fdo#107762 https://bugs.freedesktop.org/show_bug.cgi?id=107762
k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133
== Participating hosts (49 -> 45) ==
Additional (2): fi-cnl-u fi-icl-u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4816 -> Patchwork_10168
CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10168: c466afab936d8b828149178fc0adcf72bfcefa9c @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c466afab936d drm/i915: Clear DRIVER_ATOMIC on a per-device basis
ff6ab987a3f2 drm: Introduce per-device driver_features
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10168/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote:
> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > We wish to control certain driver_features flags on a per-device basis
> > while still sharing a single drm_driver instance across all the
> > devices. To that end introduce device.driver_features. By default
> > it will be set to ~0 to not impose any limits beyond
> > driver.driver_features. Drivers can then clear specific flags
> > in the per-device bitmask to limit the capabilities of the device.
> >
> > An alternative approach would be to copy the driver_features from
> > the driver into the device in drm_dev_init(), however that would
> > require verifying that no driver is currently changing
> > driver.driver_features after drm_dev_init(). Hence the ~0 apporach
> > was easier.
> >
> > Ideally we'd also make drm_driver const but there is plenty of code
> > left that wants to mutate it (eg. various vfunc assignments). We'll
> > need to fix all that up before we can make it const.
> >
> > And while at it fix up the type of the feature flag passed to
> > drm_core_check_feature().
> >
> > v2: Streamline the && vs. & (Chris)
> > s/int/u32/ in drm_core_check_feature() args
> >
> > Cc: Chris Wilson
> > Signed-off-by: Ville Syrjälä
>
> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting
> case for this. Exactly same problem as we have here. Would be good to also
> convert that one, for a bit of OCD.
Thanks for pointing it out. I'll cook it up and send separately after
this lands.
>
> Irrespective of that, on the series:
>
> Reviewed-by: Daniel Vetter
>
> Feel free to also add the r-b to the nouveau patch if you do it, it's
> rather obvious.
> -Daniel
>
> > ---
> > drivers/gpu/drm/drm_drv.c | 3 +++
> > include/drm/drm_device.h | 10 ++
> > include/drm/drm_drv.h | 8
> > 3 files changed, 17 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index ea4941da9b27..36e8e9cbec52 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -506,6 +506,9 @@ int drm_dev_init(struct drm_device *dev,
> > dev->dev = parent;
> > dev->driver = driver;
> >
> > + /* no per-device feature limits by default */
> > + dev->driver_features = ~0u;
> > +
> > INIT_LIST_HEAD(&dev->filelist);
> > INIT_LIST_HEAD(&dev->filelist_internal);
> > INIT_LIST_HEAD(&dev->clientlist);
> > diff --git a/include/drm/drm_device.h b/include/drm/drm_device.h
> > index f9c6e0e3aec7..42411b3ea0c8 100644
> > --- a/include/drm/drm_device.h
> > +++ b/include/drm/drm_device.h
> > @@ -45,6 +45,16 @@ struct drm_device {
> > /* currently active master for this device. Protected by master_mutex */
> > struct drm_master *master;
> >
> > + /**
> > +* @driver_features: per-device driver features
> > +*
> > +* Drivers can clear specific flags here to disallow
> > +* certain features on a per-device basis while still
> > +* sharing a single &struct drm_driver instance across
> > +* all devices.
> > +*/
> > + u32 driver_features;
> > +
> > /**
> > * @unplugged:
> > *
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index 23b9678137a6..8830e3de3a86 100644
> > --- a/include/drm/drm_drv.h
> > +++ b/include/drm/drm_drv.h
> > @@ -653,14 +653,14 @@ static inline bool drm_dev_is_unplugged(struct
> > drm_device *dev)
> > * @dev: DRM device to check
> > * @feature: feature flag
> > *
> > - * This checks @dev for driver features, see &drm_driver.driver_features
> > and the
> > - * various DRIVER_\* flags.
> > + * This checks @dev for driver features, see &drm_driver.driver_features,
> > + * &drm_device.driver_features, and the various DRIVER_\* flags.
> > *
> > * Returns true if the @feature is supported, false otherwise.
> > */
> > -static inline bool drm_core_check_feature(struct drm_device *dev, int
> > feature)
> > +static inline bool drm_core_check_feature(struct drm_device *dev, u32
> > feature)
> > {
> > - return dev->driver->driver_features & feature;
> > + return dev->driver->driver_features & dev->driver_features & feature;
> > }
> >
> > /**
> > --
> > 2.16.4
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> http://blog.ffwll.ch
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5] drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
On Thu, 13 Sep 2018 15:54:37 +0200,
Imre Deak wrote:
>
> On Wed, Sep 12, 2018 at 08:18:37PM +0200, Takashi Iwai wrote:
> > On Wed, 12 Sep 2018 15:18:47 +0200,
> > Imre Deak wrote:
> > >
> > > +Takashi
> > >
> > > On Wed, Sep 12, 2018 at 04:18:12PM +0300, Imre Deak wrote:
> > > > Hi Kumar, Takashi,
> > > >
> > > > On Tue, Jun 19, 2018 at 03:01:11PM -0700, Abhay Kumar wrote:
> > > > > From: Ville Syrjälä
> > > > >
> > > > > CDCLK has to be at least twice the BLCK regardless of audio. Audio
> > > > > driver has to probe using this hook and increase the clock even in
> > > > > absence of any display.
> > > > >
> > > > > v2: Use atomic refcount for get_power, put_power so that we can
> > > > > call each once(Abhay).
> > > > > v3: Reset power well 2 to avoid any transaction on iDisp link
> > > > > during cdclk change(Abhay).
> > > > > v4: Remove Power well 2 reset workaround(Ville).
> > > > > v5: Remove unwanted Power well 2 register defined in v4(Abhay).
> > > > >
> > > > > Signed-off-by: Ville Syrjälä
> > > > > Signed-off-by: Abhay Kumar
> > > > > ---
> > > > > drivers/gpu/drm/i915/i915_drv.h | 3 ++
> > > > > drivers/gpu/drm/i915/intel_audio.c | 67
> > > > > +---
> > > > > drivers/gpu/drm/i915/intel_cdclk.c | 29 +---
> > > > > drivers/gpu/drm/i915/intel_display.c | 7 +++-
> > > > > drivers/gpu/drm/i915/intel_drv.h | 2 ++
> > > > > 5 files changed, 83 insertions(+), 25 deletions(-)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > > index 6104d7115054..a4a386a5db69 100644
> > > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > > @@ -1702,6 +1702,7 @@ struct drm_i915_private {
> > > > > unsigned int hpll_freq;
> > > > > unsigned int fdi_pll_freq;
> > > > > unsigned int czclk_freq;
> > > > > + u32 get_put_refcount;
> > > > >
> > > > > struct {
> > > > > /*
> > > > > @@ -1719,6 +1720,8 @@ struct drm_i915_private {
> > > > > struct intel_cdclk_state actual;
> > > > > /* The current hardware cdclk state */
> > > > > struct intel_cdclk_state hw;
> > > > > +
> > > > > + int force_min_cdclk;
> > > > > } cdclk;
> > > > >
> > > > > /**
> > > > > diff --git a/drivers/gpu/drm/i915/intel_audio.c
> > > > > b/drivers/gpu/drm/i915/intel_audio.c
> > > > > index 3ea566f99450..ca8f04c7cbb3 100644
> > > > > --- a/drivers/gpu/drm/i915/intel_audio.c
> > > > > +++ b/drivers/gpu/drm/i915/intel_audio.c
> > > > > @@ -618,7 +618,6 @@ void intel_audio_codec_enable(struct
> > > > > intel_encoder *encoder,
> > > > >
> > > > > if (!connector->eld[0])
> > > > > return;
> > > > > -
> > > > > DRM_DEBUG_DRIVER("ELD on [CONNECTOR:%d:%s], [ENCODER:%d:%s]\n",
> > > > >connector->base.id,
> > > > >connector->name,
> > > > > @@ -713,14 +712,74 @@ void intel_init_audio_hooks(struct
> > > > > drm_i915_private *dev_priv)
> > > > > }
> > > > > }
> > > > >
> > > > > +static void glk_force_audio_cdclk(struct drm_i915_private *dev_priv,
> > > > > + bool enable)
> > > > > +{
> > > > > + struct drm_modeset_acquire_ctx ctx;
> > > > > + struct drm_atomic_state *state;
> > > > > + int ret;
> > > > > +
> > > > > + drm_modeset_acquire_init(&ctx, 0);
> > > > > + state = drm_atomic_state_alloc(&dev_priv->drm);
> > > > > + if (WARN_ON(!state))
> > > > > + return;
> > > > > +
> > > > > + state->acquire_ctx = &ctx;
> > > > > +
> > > > > +retry:
> > > > > + to_intel_atomic_state(state)->modeset = true;
> > > > > + to_intel_atomic_state(state)->cdclk.force_min_cdclk =
> > > > > + enable ? 2 * 96000 : 0;
> > > > > +
> > > > > + /*
> > > > > + * Protects dev_priv->cdclk.force_min_cdclk
> > > > > + * Need to lock this here in case we have no active pipes
> > > > > + * and thus wouldn't lock it during the commit otherwise.
> > > > > + */
> > > > > + ret =
> > > > > drm_modeset_lock(&dev_priv->drm.mode_config.connection_mutex, &ctx);
> > > > > + if (!ret)
> > > > > + ret = drm_atomic_commit(state);
> > > >
> > > > Ville mentioned a potential dead-lock problem here: a normal modeset
> > > > enabling an HDMI/DP output with an audio sink will call the
> > > > drm_audio_component_audio_ops::pin_eld_notify() callback with the
> > > > connection_mutex already held. This callback in turn could call
> > > > drm_audio_component_ops::get_power()/put_power() callbacks and
> > > > dead-lock at the above drm_modeset_lock() call.
> > > >
> > > > Looks like that
> > > >
> > > >sound/pci/hda/patch_hdmi.c / intel_pin_eld_notify()->
> > > >check_presence_and_report()->
> > > >hdmi_present_sense()
> > > >
> > > > would prevent this, but for instance
> >
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On 2018-09-13 4:29 p.m., Ville Syrjälä wrote: > On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote: >> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote: >>> From: Ville Syrjälä >>> >>> We wish to control certain driver_features flags on a per-device basis >>> while still sharing a single drm_driver instance across all the >>> devices. To that end introduce device.driver_features. By default >>> it will be set to ~0 to not impose any limits beyond >>> driver.driver_features. Drivers can then clear specific flags >>> in the per-device bitmask to limit the capabilities of the device. >>> >>> An alternative approach would be to copy the driver_features from >>> the driver into the device in drm_dev_init(), however that would >>> require verifying that no driver is currently changing >>> driver.driver_features after drm_dev_init(). Hence the ~0 apporach >>> was easier. >>> >>> Ideally we'd also make drm_driver const but there is plenty of code >>> left that wants to mutate it (eg. various vfunc assignments). We'll >>> need to fix all that up before we can make it const. >>> >>> And while at it fix up the type of the feature flag passed to >>> drm_core_check_feature(). >>> >>> v2: Streamline the && vs. & (Chris) >>> s/int/u32/ in drm_core_check_feature() args >>> >>> Cc: Chris Wilson >>> Signed-off-by: Ville Syrjälä >> >> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting >> case for this. Exactly same problem as we have here. Would be good to also >> convert that one, for a bit of OCD. > > Thanks for pointing it out. I'll cook it up and send separately after > this lands. I don't suppose you'd like to do amdgpu as well, while you're at it? :) Either way, this is awesome stuff! This patch is Reviewed-by: Michel Dänzer -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
From: Ville Syrjälä
Use I915_GTT_PAGE_SIZE when talking about GTT pages rather than
physical pages.
There are some PAGE_SHIFTs left though. Not sure if we want to
introduce I915_GTT_PAGE_SHIFT or what?
Cc: Chris Wilson
Suggested-by: Chris Wilson # at least some of it :)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 18 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ea442033a57..9ca0829f1cfa 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2284,7 +2284,7 @@ static inline struct scatterlist *__sg_next(struct
scatterlist *sg)
#define for_each_sgt_dma(__dmap, __iter, __sgt)
\
for ((__iter) = __sgt_iter((__sgt)->sgl, true); \
((__dmap) = (__iter).dma + (__iter).curr); \
-(((__iter).curr += PAGE_SIZE) >= (__iter).max) ? \
+(((__iter).curr += I915_GTT_PAGE_SIZE) >= (__iter).max) ? \
(__iter) = __sgt_iter(__sg_next((__iter).sgp), true), 0 : 0)
/**
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index eb0e446d6482..8be1acd097db 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -1050,7 +1050,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt,
do {
vaddr[idx->pte] = pte_encode | iter->dma;
- iter->dma += PAGE_SIZE;
+ iter->dma += I915_GTT_PAGE_SIZE;
if (iter->dma >= iter->max) {
iter->sg = __sg_next(iter->sg);
if (!iter->sg) {
@@ -1759,7 +1759,7 @@ static void gen6_dump_ppgtt(struct i915_hw_ppgtt *base,
struct seq_file *m)
seq_printf(m, "\t\t(%03d, %04d) %08lx: ",
pde, pte,
- (pde * GEN6_PTES + pte) * PAGE_SIZE);
+ (pde * GEN6_PTES + pte) *
I915_GTT_PAGE_SIZE);
for (i = 0; i < 4; i++) {
if (vaddr[pte + i] != scratch_pte)
seq_printf(m, " %08x", vaddr[pte + i]);
@@ -1899,7 +1899,7 @@ static void gen6_ppgtt_insert_entries(struct
i915_address_space *vm,
do {
vaddr[act_pte] = pte_encode | GEN6_PTE_ADDR_ENCODE(iter.dma);
- iter.dma += PAGE_SIZE;
+ iter.dma += I915_GTT_PAGE_SIZE;
if (iter.dma == iter.max) {
iter.sg = __sg_next(iter.sg);
if (!iter.sg)
@@ -2037,7 +2037,7 @@ static int pd_vma_bind(struct i915_vma *vma,
{
struct i915_ggtt *ggtt = i915_vm_to_ggtt(vma->vm);
struct gen6_hw_ppgtt *ppgtt = vma->private;
- u32 ggtt_offset = i915_ggtt_offset(vma) / PAGE_SIZE;
+ u32 ggtt_offset = i915_ggtt_offset(vma) / I915_GTT_PAGE_SIZE;
struct i915_page_table *pt;
unsigned int pde;
@@ -2163,7 +2163,7 @@ static struct i915_hw_ppgtt *gen6_ppgtt_create(struct
drm_i915_private *i915)
ppgtt->base.vm.i915 = i915;
ppgtt->base.vm.dma = &i915->drm.pdev->dev;
- ppgtt->base.vm.total = I915_PDES * GEN6_PTES * PAGE_SIZE;
+ ppgtt->base.vm.total = I915_PDES * GEN6_PTES * I915_GTT_PAGE_SIZE;
i915_address_space_init(&ppgtt->base.vm, i915);
@@ -3023,7 +3023,7 @@ static unsigned int gen8_get_total_gtt_size(u16
bdw_gmch_ctl)
bdw_gmch_ctl = 1 << bdw_gmch_ctl;
#ifdef CONFIG_X86_32
- /* Limit 32b platforms to a 2GB GGTT: 4 << 20 / pte size * PAGE_SIZE */
+ /* Limit 32b platforms to a 2GB GGTT: 4 << 20 / pte size *
I915_GTT_PAGE_SIZE */
if (bdw_gmch_ctl > 4)
bdw_gmch_ctl = 4;
#endif
@@ -3727,9 +3727,9 @@ rotate_pages(const dma_addr_t *in, unsigned int offset,
* the entries so the sg list can be happily traversed.
* The only thing we need are DMA addresses.
*/
- sg_set_page(sg, NULL, PAGE_SIZE, 0);
+ sg_set_page(sg, NULL, I915_GTT_PAGE_SIZE, 0);
sg_dma_address(sg) = in[offset + src_idx];
- sg_dma_len(sg) = PAGE_SIZE;
+ sg_dma_len(sg) = I915_GTT_PAGE_SIZE;
sg = sg_next(sg);
src_idx -= stride;
}
@@ -3742,7 +3742,7 @@ static noinline struct sg_table *
intel_rotate_pages(struct intel_rotation_info *rot_info,
struct drm_i915_gem_object *obj)
{
- const unsigned long n_pages = obj->base.size / PAGE_SIZE;
+ const unsigned long n_pages = obj->base.size / I915_GTT_PAGE_SIZE;
unsigned int size = intel_rotation_info_size(rot_info);
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 04:52:34PM +0200, Michel Dänzer wrote: > On 2018-09-13 4:29 p.m., Ville Syrjälä wrote: > > On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote: > >> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote: > >>> From: Ville Syrjälä > >>> > >>> We wish to control certain driver_features flags on a per-device basis > >>> while still sharing a single drm_driver instance across all the > >>> devices. To that end introduce device.driver_features. By default > >>> it will be set to ~0 to not impose any limits beyond > >>> driver.driver_features. Drivers can then clear specific flags > >>> in the per-device bitmask to limit the capabilities of the device. > >>> > >>> An alternative approach would be to copy the driver_features from > >>> the driver into the device in drm_dev_init(), however that would > >>> require verifying that no driver is currently changing > >>> driver.driver_features after drm_dev_init(). Hence the ~0 apporach > >>> was easier. > >>> > >>> Ideally we'd also make drm_driver const but there is plenty of code > >>> left that wants to mutate it (eg. various vfunc assignments). We'll > >>> need to fix all that up before we can make it const. > >>> > >>> And while at it fix up the type of the feature flag passed to > >>> drm_core_check_feature(). > >>> > >>> v2: Streamline the && vs. & (Chris) > >>> s/int/u32/ in drm_core_check_feature() args > >>> > >>> Cc: Chris Wilson > >>> Signed-off-by: Ville Syrjälä > >> > >> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting > >> case for this. Exactly same problem as we have here. Would be good to also > >> convert that one, for a bit of OCD. > > > > Thanks for pointing it out. I'll cook it up and send separately after > > this lands. > > I don't suppose you'd like to do amdgpu as well, while you're at it? :) Sure. I'll take a gander at it as well. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATH i-g-t] igt_sysfs: Avoid double closing the fd in igt_sysfs_scanf
From: Tvrtko Ursulin
fdopen takes ownership of the fd so only one flavour of closing it is
needed.
Signed-off-by: Tvrtko Ursulin
---
lib/igt_sysfs.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/lib/igt_sysfs.c b/lib/igt_sysfs.c
index 9012cc73f6e3..d323b81dd986 100644
--- a/lib/igt_sysfs.c
+++ b/lib/igt_sysfs.c
@@ -379,8 +379,9 @@ int igt_sysfs_scanf(int dir, const char *attr, const char
*fmt, ...)
va_end(ap);
fclose(file);
+ } else {
+ close(fd);
}
- close(fd);
return ret;
}
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev8)
== Series Details == Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev8) URL : https://patchwork.freedesktop.org/series/42459/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8d4f7a2b425b drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled -:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #25: > > > > > CDCLK has to be at least twice the BLCK regardless of audio. Audio -:189: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #189: FILE: sound/soc/codecs/hdac_hdmi.c:164: +static void __hdac_hdmi_jack_report(struct hdac_hdmi_pcm *pcm, struct hdac_hdmi_port *port, bool is_connect) -:226: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #226: FILE: sound/soc/codecs/hdac_hdmi.c:214: +static void hdac_hdmi_jack_report(struct hdac_hdmi_pcm *pcm, + struct hdac_hdmi_port *port, bool is_connect) -:274: ERROR:SPACING: space prohibited after that '&' (ctx:BxW) #274: FILE: sound/soc/codecs/hdac_hdmi.c:2092: + cancel_work_sync(& pin->ports[i].dapm_work); ^ -:278: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 2 errors, 1 warnings, 2 checks, 101 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATH i-g-t] igt_sysfs: Avoid double closing the fd in igt_sysfs_scanf
Quoting Tvrtko Ursulin (2018-09-13 16:06:13) > From: Tvrtko Ursulin > > fdopen takes ownership of the fd so only one flavour of closing it is > needed. Indeed, I always seem to get burned by this. One day I might remember... Who am I kidding? :) > Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
Quoting Ville Syrjala (2018-09-13 16:04:05) > From: Ville Syrjälä > > Use I915_GTT_PAGE_SIZE when talking about GTT pages rather than > physical pages. Yup, these are all concerned with GTT units so we prefer I915_GTT_PAGE_SIZE. > There are some PAGE_SHIFTs left though. Not sure if we want to > introduce I915_GTT_PAGE_SHIFT or what? Nah, I think gcc is good for doing the right thing for a constant divide by a power of two. If you spot some, just change them over to (x / GTT_PAGE_SIZE) and double check gcc emits the same code. If it doesn't just flag it in the commit message and then one day we may feel the urge for another cleanup. > Cc: Chris Wilson > Suggested-by: Chris Wilson # at least some of it :) > Signed-off-by: Ville Syrjälä Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev8)
== Series Details ==
Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled
(rev8)
URL : https://patchwork.freedesktop.org/series/42459/
State : success
== Summary ==
= CI Bug Log - changes from CI_DRM_4816 -> Patchwork_10169 =
== Summary - SUCCESS ==
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/42459/revisions/8/mbox/
== Known issues ==
Here are the changes found in Patchwork_10169 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_psr@primary_mmap_gtt:
{fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3
igt@kms_psr@primary_page_flip:
fi-cfl-s3: PASS -> FAIL (fdo#107336)
fi-kbl-r: PASS -> FAIL (fdo#107336)
Possible fixes
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
== Participating hosts (49 -> 45) ==
Additional (2): fi-cnl-u fi-icl-u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4816 -> Patchwork_10169
CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10169: 8d4f7a2b425b893afe5b2b4ecea3d185e45e399f @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
8d4f7a2b425b drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is
enabled
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10169/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
== Series Details == Series: drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE URL : https://patchwork.freedesktop.org/series/49645/ State : warning == Summary == $ dim checkpatch origin/drm-tip f7ce7c3fcf8c drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE -:16: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #16: Suggested-by: Chris Wilson # at least some of it :) total: 0 errors, 1 warnings, 0 checks, 75 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm: Introduce per-device driver_features
== Series Details == Series: series starting with [1/2] drm: Introduce per-device driver_features URL : https://patchwork.freedesktop.org/series/49639/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4816_full -> Patchwork_10168_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10168_full that come from known issues: === IGT changes === Issues hit igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS igt@kms_color@pipe-c-ctm-max: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +34 igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4816 -> Patchwork_10168 CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10168: c466afab936d8b828149178fc0adcf72bfcefa9c @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10168/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
== Series Details ==
Series: drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
URL : https://patchwork.freedesktop.org/series/49645/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4816 -> Patchwork_10170 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10170 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10170, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49645/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_10170:
=== IGT changes ===
Possible regressions
igt@drv_selftest@live_hangcheck:
fi-icl-u: NOTRUN -> INCOMPLETE
== Known issues ==
Here are the changes found in Patchwork_10170 that come from known issues:
=== IGT changes ===
Issues hit
igt@kms_pipe_crc_basic@read-crc-pipe-b:
fi-byt-clapper: PASS -> FAIL (fdo#107362)
igt@kms_pipe_crc_basic@read-crc-pipe-b-frame-sequence:
fi-byt-clapper: PASS -> FAIL (fdo#103191, fdo#107362) +1
igt@kms_psr@primary_mmap_gtt:
{fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: PASS -> FAIL (fdo#104008)
Possible fixes
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#103191, fdo#107362) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
== Participating hosts (49 -> 45) ==
Additional (2): fi-cnl-u fi-icl-u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4816 -> Patchwork_10170
CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10170: f7ce7c3fcf8c08487b2382429792704e802d4e85 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f7ce7c3fcf8c drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10170/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915, HDMI/DP audio with multiple monitors
On Wed, 12 Sep 2018 20:06:43 +0200 Takashi Iwai wrote: > On Wed, 12 Sep 2018 19:46:58 +0200, > Ville Syrjälä wrote: > > > > On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote: > > > Hi, > > > > > > I have a system with multiple monitors and would like to send > > > notification sounds to the monitor on which corresponding > > > window is visible. > > > > > > For a workstation and a tiny computer things look different: > > > - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon E3-1200 > > > v3/4th Gen Core Processor Integrated Graphics Controller [8086:0412] (rev > > > 06) > > > 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen > > > Core Processor HD Audio Controller [8086:0c0c] (rev 06) > > > 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series > > > Chipset High Definition Audio Controller [8086:8c20] (rev 04) > > > > > > Here alsa show me two cards: > > > - HDA Intel PCH (Realtek ALC671) > > > - HDA Intel HDMI (Intel Generic) > > > > > > List of PLAYBACK Hardware Devices > > > card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic > > > Digital] > > >Subdevices: 1/1 > > >Subdevice #0: subdevice #0 > > Is a proper kernel config (CONFIG_SND_HDA_CODEC_HDMI) enabled? It was missing and adding it helps a lot. Would there be a way to auto-select it when corresponding DRM driver is selected? Kind of select SND_HDA_CODEC_HDMI if SND_HDA or at least mention it in description, maybe as conditional comment is done for HDA codecs. > The device name looks strange as if it's not properly bound with the > HDMI codec driver. With SND_HDA_CODEC_HDMI enabled I get better results on the tiny computer (not checked on workstation yet): List of PLAYBACK Hardware Devices card 0: PCH [HDA Intel PCH], device 0: ALC671 Analog [ALC671 Analog] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 3: HDMI 0 [HDMI 0] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 7: HDMI 1 [HDMI 1] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 8: HDMI 2 [HDMI 2] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 9: HDMI 3 [HDMI 3] Subdevices: 1/1 Subdevice #0: subdevice #0 card 0: PCH [HDA Intel PCH], device 10: HDMI 4 [HDMI 4] Subdevices: 1/1 Subdevice #0: subdevice #0 Shown by aplay -L as: ... hdmi:CARD=PCH,DEV=0 HDA Intel PCH, HDMI 0 HDMI Audio Output hdmi:CARD=PCH,DEV=1 HDA Intel PCH, HDMI 1 HDMI Audio Output hdmi:CARD=PCH,DEV=2 HDA Intel PCH, HDMI 2 HDMI Audio Output hdmi:CARD=PCH,DEV=3 HDA Intel PCH, HDMI 3 HDMI Audio Output hdmi:CARD=PCH,DEV=4 HDA Intel PCH, HDMI 4 HDMI Audio Output Alsamixer shows me 5 S/PDIFs (S/PDIF, S/PDIF 1, ..., S/PDIF 4) which is not that helpful. Why don't alsamixer and aplay -L at least use the same naming scheme? If the naming there would match output naming as show by xrandr (or /sys/class/drm/... it would be even better! xrandr: HDMI-1 disconnected (normal left inverted right x axis y axis) DP-1 connected primary 3840x2160+0+0 (normal left inverted right x axis y axis) 1439mm x 809mm HDMI-2 disconnected (normal left inverted right x axis y axis) DP-2 disconnected (normal left inverted right x axis y axis) HDMI-3 connected 3840x2160+3840+0 (normal left inverted right x axis y axis) 1872mm x 1053mm DP-3 disconnected (normal left inverted right x axis y axis) /sys/class/drm/: card0-DP-1 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-DP-1 card0-DP-2 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-DP-2 card0-DP-3 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-DP-3 card0-HDMI-A-1 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-1 card0-HDMI-A-2 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-2 card0-HDMI-A-3 -> ../../devices/pci:00/:00:02.0/drm/card0/card0-HDMI-A-3 Testing each output with aplay I could determine that hw:0,7 (currently) matches DP-1 (as reported by xrandr) and hw:0,8 matches HDMI-3 (as reported by xrandr). Though while testing often the first sound played never reaches the monitor's speakers, only a second run shortly after the first reaches speakers. (played sound is rather short: aplay -D hw:0,7 /usr/share/sounds/purple/receive.wav same with slightly longer login.wav) Cheers, Bruno ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [REGRESSION 4.19-rc2] sometimes hangs with black screen when resuming from suspend or hibernation (was: Re: Linux 4.19-rc2)
Ville Syrjälä - 12.09.18, 19:10: > On Tue, Sep 11, 2018 at 12:17:05PM +0200, Martin Steigerwald wrote: > > Cc´d Intel Gfx mailing list, in case somebody there knows something: > > > > Cc´d Thorsten for regression tracking… forgot initially. Can also > > open bug report at a later time but so far I cannot provide many > > details about the issue. > > > > Rafael J. Wysocki - 11.09.18, 10:17: > > > On Tue, Sep 11, 2018 at 10:01 AM Martin Steigerwald > > > > wrote: > > > > Hi. > > > > > > > > Linus Torvalds - 02.09.18, 23:45: > > > > > As usual, the rc2 release is pretty small. People are taking a > > > > > > > > With 4.19-rc2 this ThinkPad T520 with i5 Sandybrdige sometimes > > > > hangs > > > > with black screen when resuming from suspend or hibernation. > > > > With > > > > 4.18.1 it did not. Of course there have been userspace related > > > > updates that could be related. > > > > > > > > I currently have no time to dig into this and on this production > > > > laptop I generally do not do bisects between major kernel > > > > releases. > > > > So currently I only answer questions that do not require much > > > > time > > > > to answer. > > > > > > > > For now I switched back to 4.18. If that is stable – and thus > > > > likely > > > > no userspace component is related –, I go with 4.19-rc3 or > > > > whatever > > > > is most recent version to see if the issue has been fixed > > > > already. > > > > > > There were almost no general changes related to system-wide PM > > > between 4.18 and current, so I would suspect one of the device > > > drivers or the x86 core. It also may be something like CPU > > > online/offline, however.> > > I see. I wondered about intel-gfx driver already. Of course it could > > also be something else. > > > > I forgot to mention: The mouse pointer was visible, but the screen > > remained black. > > Did the mouse cursor still move or not? No, it did not move. > Could also try suspend without any GUI stuff in the way. Or try the > intel ddx instead of the modesetting ddx (assuming that's what > you're using now) and no compositor to rule out GPU hangs killing > the compositor. The intel ddx can also deal with the GPU not > recovering from a hang by switching to software rendering, > whereas modesetting cannot. Thanks for these suggestions. Currently laptop is still on 4.18 again (4.18.7) and I did not see this hang after resume so far. If it continues to be stable for a few more days, I try with latest 4.19 again as then its very likely kernel related. > Hmm. Also T520 is an optimus laptop maybe? If there's an nvidia > GPU involved it's going to be hard to get anyone to care. Better > switch that off in the BIOS if you haven't already. I decided back then for Intel only graphics. I never regretted this. For me NVidia graphics is not an option, unless NVidia significantly changes their policy regarding free software drivers. Thanks, -- Martin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] i915, HDMI/DP audio with multiple monitors
On Thu, 13 Sep 2018 09:25:37 +0200, Bruno Prémont wrote: > > On Wed, 12 Sep 2018 20:06:43 +0200 Takashi Iwai wrote: > > On Wed, 12 Sep 2018 19:46:58 +0200, > > Ville Syrjälä wrote: > > > > > > On Tue, Sep 11, 2018 at 03:50:13PM +0200, Bruno Prémont wrote: > > > > Hi, > > > > > > > > I have a system with multiple monitors and would like to send > > > > notification sounds to the monitor on which corresponding > > > > window is visible. > > > > > > > > For a workstation and a tiny computer things look different: > > > > - workstation (Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz): > > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon > > > > E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller > > > > [8086:0412] (rev 06) > > > > 00:03.0 Audio device [0403]: Intel Corporation Xeon E3-1200 v3/4th Gen > > > > Core Processor HD Audio Controller [8086:0c0c] (rev 06) > > > > 00:1b.0 Audio device [0403]: Intel Corporation 8 Series/C220 Series > > > > Chipset High Definition Audio Controller [8086:8c20] (rev 04) > > > > > > > > Here alsa show me two cards: > > > > - HDA Intel PCH (Realtek ALC671) > > > > - HDA Intel HDMI (Intel Generic) > > > > > > > > List of PLAYBACK Hardware Devices > > > > card 0: HDMI [HDA Intel HDMI], device 3: Generic Digital [Generic > > > > Digital] > > > >Subdevices: 1/1 > > > >Subdevice #0: subdevice #0 > > > > Is a proper kernel config (CONFIG_SND_HDA_CODEC_HDMI) enabled? > > It was missing and adding it helps a lot. > Would there be a way to auto-select it when corresponding DRM driver is > selected? > > Kind of > select SND_HDA_CODEC_HDMI if SND_HDA > or at least mention it in description, maybe as conditional comment is > done for HDA codecs. Yeah, a patch like below should work. --- a/drivers/gpu/drm/i915/Kconfig +++ b/drivers/gpu/drm/i915/Kconfig @@ -23,6 +23,7 @@ config DRM_I915 select SYNC_FILE select IOSF_MBI select CRC32 + select SND_HDA_CODEC_HDMI if SND_HDA_INTEL select SND_HDA_I915 if SND_HDA_CORE select CEC_CORE if CEC_NOTIFIER help But I'm not going to advocate it. Feel free to cook up and submit a proper patch if you really need it. Takashi ___ 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: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev8)
== Series Details == Series: drm/i915: Force 2*96 MHz cdclk on glk/cnl when audio power is enabled (rev8) URL : https://patchwork.freedesktop.org/series/42459/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4816_full -> Patchwork_10169_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10169_full that come from known issues: === IGT changes === Issues hit igt@drv_suspend@shrink: shard-glk: PASS -> INCOMPLETE (k.org#198133, fdo#106886, fdo#103359) igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-shrfb-draw-mmap-gtt: shard-glk: PASS -> FAIL (fdo#103167) igt@kms_setmode@basic: shard-apl: PASS -> FAIL (fdo#99912) shard-kbl: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS igt@kms_color@pipe-c-ctm-max: shard-kbl: DMESG-WARN (fdo#105602, fdo#103558) -> PASS +34 igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103359 https://bugs.freedesktop.org/show_bug.cgi?id=103359 fdo#103558 https://bugs.freedesktop.org/show_bug.cgi?id=103558 fdo#105602 https://bugs.freedesktop.org/show_bug.cgi?id=105602 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#106886 https://bugs.freedesktop.org/show_bug.cgi?id=106886 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 k.org#198133 https://bugzilla.kernel.org/show_bug.cgi?id=198133 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4816 -> Patchwork_10169 CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10169: 8d4f7a2b425b893afe5b2b4ecea3d185e45e399f @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10169/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for i915, HDMI/DP audio with multiple monitors
== Series Details == Series: i915, HDMI/DP audio with multiple monitors URL : https://patchwork.freedesktop.org/series/49647/ State : warning == Summary == $ dim checkpatch origin/drm-tip a3ce8c6aec87 i915, HDMI/DP audio with multiple monitors -:25: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #25: > > > > 00:02.0 VGA compatible controller [0300]: Intel Corporation Xeon > > > > E3-1200 v3/4th Gen Core Processor Integrated Graphics Controller > > > > [8086:0412] (rev 06) -:67: ERROR:MISSING_SIGN_OFF: Missing Signed-off-by: line(s) total: 1 errors, 1 warnings, 0 checks, 7 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm: Introduce per-device driver_features
On Thu, Sep 13, 2018 at 06:06:01PM +0300, Ville Syrjälä wrote: > On Thu, Sep 13, 2018 at 04:52:34PM +0200, Michel Dänzer wrote: > > On 2018-09-13 4:29 p.m., Ville Syrjälä wrote: > > > On Thu, Sep 13, 2018 at 03:50:01PM +0200, Daniel Vetter wrote: > > >> On Thu, Sep 13, 2018 at 04:16:21PM +0300, Ville Syrjala wrote: > > >>> From: Ville Syrjälä > > >>> > > >>> We wish to control certain driver_features flags on a per-device basis > > >>> while still sharing a single drm_driver instance across all the > > >>> devices. To that end introduce device.driver_features. By default > > >>> it will be set to ~0 to not impose any limits beyond > > >>> driver.driver_features. Drivers can then clear specific flags > > >>> in the per-device bitmask to limit the capabilities of the device. > > >>> > > >>> An alternative approach would be to copy the driver_features from > > >>> the driver into the device in drm_dev_init(), however that would > > >>> require verifying that no driver is currently changing > > >>> driver.driver_features after drm_dev_init(). Hence the ~0 apporach > > >>> was easier. > > >>> > > >>> Ideally we'd also make drm_driver const but there is plenty of code > > >>> left that wants to mutate it (eg. various vfunc assignments). We'll > > >>> need to fix all that up before we can make it const. > > >>> > > >>> And while at it fix up the type of the feature flag passed to > > >>> drm_core_check_feature(). > > >>> > > >>> v2: Streamline the && vs. & (Chris) > > >>> s/int/u32/ in drm_core_check_feature() args > > >>> > > >>> Cc: Chris Wilson > > >>> Signed-off-by: Ville Syrjälä > > >> > > >> git grep DRIVER_ATOMIC -- drivers/gpu/drm/nouveau has a 2nd supporting > > >> case for this. Exactly same problem as we have here. Would be good to > > >> also > > >> convert that one, for a bit of OCD. > > > > > > Thanks for pointing it out. I'll cook it up and send separately after > > > this lands. > > > > I don't suppose you'd like to do amdgpu as well, while you're at it? :) > > Sure. I'll take a gander at it as well. Series pushed to drm-misc-next. Thanks for the reviews. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/nouveau: Disable atomic support on a per-device basis
From: Ville Syrjälä We now have per-device driver_features, so let's use that to disable atomic only for pre-nv50. Cc: Ben Skeggs Cc: Lyude Paul Cc: nouv...@lists.freedesktop.org Cc: Daniel Vetter Reviewed-by: Daniel Vetter Suggested-by: Daniel Vetter Signed-off-by: Ville Syrjälä --- drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c b/drivers/gpu/drm/nouveau/dispnv04/disp.c index 70dce544984e..670535a68d3b 100644 --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) nouveau_display(dev)->fini = nv04_display_fini; /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ - dev->driver->driver_features &= ~DRIVER_ATOMIC; + dev->driver_features &= ~DRIVER_ATOMIC; nouveau_hw_save_vga_fonts(dev, 1); -- 2.16.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
From: Ville Syrjälä
Disable atomic on a per-device basis instead of for all devices.
Made possible by the new device.driver_features thing.
Cc: Alex Deucher
Cc: "Christian König"
Cc: "David (ChunMing) Zhou"
Cc: Harry Wentland
Cc: Michel Dänzer
Suggested-by: Michel Dänzer
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 6870909da926..8c1db96be070 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
if (ret)
return ret;
- /* warn the user if they mix atomic and non-atomic capable GPUs */
- if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
- DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
- /* support atomic early so the atomic debugfs stuff gets created */
- if (supports_atomic)
- kms_driver.driver_features |= DRIVER_ATOMIC;
-
dev = drm_dev_alloc(&kms_driver, &pdev->dev);
if (IS_ERR(dev))
return PTR_ERR(dev);
+ if (!supports_atomic)
+ dev->driver_features &= ~DRIVER_ATOMIC;
+
ret = pci_enable_device(pdev);
if (ret)
goto err_free;
@@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device *dev,
unsigned int pipe,
static struct drm_driver kms_driver = {
.driver_features =
- DRIVER_USE_AGP |
+ DRIVER_USE_AGP | DRIVER_ATOMIC |
DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
.load = amdgpu_driver_load_kms,
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for i915, HDMI/DP audio with multiple monitors
== Series Details ==
Series: i915, HDMI/DP audio with multiple monitors
URL : https://patchwork.freedesktop.org/series/49647/
State : failure
== Summary ==
= CI Bug Log - changes from CI_DRM_4816 -> Patchwork_10171 =
== Summary - FAILURE ==
Serious unknown changes coming with Patchwork_10171 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_10171, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/49647/revisions/1/mbox/
== Possible new issues ==
Here are the unknown changes that may have been introduced in Patchwork_10171:
=== IGT changes ===
Possible regressions
igt@drv_selftest@live_contexts:
fi-bsw-n3050: PASS -> DMESG-WARN
igt@drv_selftest@mock_hugepages:
fi-bwr-2160:PASS -> DMESG-FAIL
== Known issues ==
Here are the changes found in Patchwork_10171 that come from known issues:
=== IGT changes ===
Issues hit
igt@gem_mmap_gtt@basic-wc:
fi-blb-e6850: PASS -> FAIL (fdo#107307)
igt@kms_frontbuffer_tracking@basic:
fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614)
igt@kms_psr@primary_mmap_gtt:
{fi-cnl-u}: NOTRUN -> FAIL (fdo#107383) +3
igt@kms_psr@primary_page_flip:
fi-kbl-r: PASS -> FAIL (fdo#107336)
igt@prime_vgem@basic-fence-flip:
fi-ilk-650: PASS -> FAIL (fdo#104008)
Possible fixes
igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b:
fi-byt-clapper: FAIL (fdo#107362) -> PASS
igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614
fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191
fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008
fdo#107307 https://bugs.freedesktop.org/show_bug.cgi?id=107307
fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336
fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362
fdo#107383 https://bugs.freedesktop.org/show_bug.cgi?id=107383
== Participating hosts (49 -> 44) ==
Additional (1): fi-cnl-u
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-ctg-p8600 fi-bdw-samus
== Build changes ==
* Linux: CI_DRM_4816 -> Patchwork_10171
CI_DRM_4816: 5bebc54ac552e3716bfe0f1f7eb0babfbda49f09 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_10171: a3ce8c6aec87648d69e49d09fa91bbf3f7f36136 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a3ce8c6aec87 i915, HDMI/DP audio with multiple monitors
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10171/issues.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
On 2018-09-13 6:31 p.m., Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Disable atomic on a per-device basis instead of for all devices.
> Made possible by the new device.driver_features thing.
>
> Cc: Alex Deucher
> Cc: "Christian König"
> Cc: "David (ChunMing) Zhou"
> Cc: Harry Wentland
> Cc: Michel Dänzer
> Suggested-by: Michel Dänzer
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> 1 file changed, 4 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> index 6870909da926..8c1db96be070 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> if (ret)
> return ret;
>
> - /* warn the user if they mix atomic and non-atomic capable GPUs */
> - if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
> - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> - /* support atomic early so the atomic debugfs stuff gets created */
> - if (supports_atomic)
> - kms_driver.driver_features |= DRIVER_ATOMIC;
> -
> dev = drm_dev_alloc(&kms_driver, &pdev->dev);
> if (IS_ERR(dev))
> return PTR_ERR(dev);
>
> + if (!supports_atomic)
> + dev->driver_features &= ~DRIVER_ATOMIC;
> +
> ret = pci_enable_device(pdev);
> if (ret)
> goto err_free;
> @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> *dev, unsigned int pipe,
>
> static struct drm_driver kms_driver = {
> .driver_features =
> - DRIVER_USE_AGP |
> + DRIVER_USE_AGP | DRIVER_ATOMIC |
> DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> .load = amdgpu_driver_load_kms,
>
Thanks Ville for taking care of this!
Reviewed-by: Michel Dänzer
If Alex agrees, probably best to push this to drm-misc-next as well.
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
On Thu, Sep 13, 2018 at 12:39 PM Michel Dänzer wrote:
>
> On 2018-09-13 6:31 p.m., Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > Disable atomic on a per-device basis instead of for all devices.
> > Made possible by the new device.driver_features thing.
> >
> > Cc: Alex Deucher
> > Cc: "Christian König"
> > Cc: "David (ChunMing) Zhou"
> > Cc: Harry Wentland
> > Cc: Michel Dänzer
> > Suggested-by: Michel Dänzer
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> > 1 file changed, 4 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > index 6870909da926..8c1db96be070 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > if (ret)
> > return ret;
> >
> > - /* warn the user if they mix atomic and non-atomic capable GPUs */
> > - if ((kms_driver.driver_features & DRIVER_ATOMIC) && !supports_atomic)
> > - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> > - /* support atomic early so the atomic debugfs stuff gets created */
> > - if (supports_atomic)
> > - kms_driver.driver_features |= DRIVER_ATOMIC;
> > -
> > dev = drm_dev_alloc(&kms_driver, &pdev->dev);
> > if (IS_ERR(dev))
> > return PTR_ERR(dev);
> >
> > + if (!supports_atomic)
> > + dev->driver_features &= ~DRIVER_ATOMIC;
> > +
> > ret = pci_enable_device(pdev);
> > if (ret)
> > goto err_free;
> > @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> > *dev, unsigned int pipe,
> >
> > static struct drm_driver kms_driver = {
> > .driver_features =
> > - DRIVER_USE_AGP |
> > + DRIVER_USE_AGP | DRIVER_ATOMIC |
> > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> > DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> > .load = amdgpu_driver_load_kms,
> >
>
> Thanks Ville for taking care of this!
>
> Reviewed-by: Michel Dänzer
>
> If Alex agrees, probably best to push this to drm-misc-next as well.
>
Reviewed-by: Alex Deucher
Please go ahead and merge through drm-misc.
Thanks!
Alex
>
> --
> Earthling Michel Dänzer | http://www.amd.com
> Libre software enthusiast | Mesa and X developer
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v4)
On Wed, 12 Sep 2018 17:10:58 +0100 Chris Wilson wrote: > Quoting Bob Paauwe (2018-09-12 17:04:30) > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > index 43ed8b28aeaa..33d7225edbbb 100644 > > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > @@ -181,6 +181,8 @@ struct drm_i915_private *mock_gem_device(void) > > I915_GTT_PAGE_SIZE_64K | > > I915_GTT_PAGE_SIZE_2M; > > > > + mkwrite_device_info(i915)->full_ppgtt_bits = 48; > > Actually the mock ppgtt is 64b. > -Chris Setting it 64 bit causes mock_hugepages to fail. I don't believe the current driver code ever uses anything other than 32 or 48 bit so this may mean there's a bug somewhere if we go over 48 bit. Bob -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v4)
On Thu, Sep 13, 2018 at 10:02:57AM -0700, Bob Paauwe wrote: > On Wed, 12 Sep 2018 17:10:58 +0100 > Chris Wilson wrote: > > > Quoting Bob Paauwe (2018-09-12 17:04:30) > > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > index 43ed8b28aeaa..33d7225edbbb 100644 > > > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > @@ -181,6 +181,8 @@ struct drm_i915_private *mock_gem_device(void) > > > I915_GTT_PAGE_SIZE_64K | > > > I915_GTT_PAGE_SIZE_2M; > > > > > > + mkwrite_device_info(i915)->full_ppgtt_bits = 48; > > > > Actually the mock ppgtt is 64b. > > -Chris > > Setting it 64 bit causes mock_hugepages to fail. 1<<64 somewhere? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v4)
On Thu, 13 Sep 2018 20:05:54 +0300 Ville Syrjälä wrote: > On Thu, Sep 13, 2018 at 10:02:57AM -0700, Bob Paauwe wrote: > > On Wed, 12 Sep 2018 17:10:58 +0100 > > Chris Wilson wrote: > > > > > Quoting Bob Paauwe (2018-09-12 17:04:30) > > > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > index 43ed8b28aeaa..33d7225edbbb 100644 > > > > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > @@ -181,6 +181,8 @@ struct drm_i915_private *mock_gem_device(void) > > > > I915_GTT_PAGE_SIZE_64K | > > > > I915_GTT_PAGE_SIZE_2M; > > > > > > > > + mkwrite_device_info(i915)->full_ppgtt_bits = 48; > > > > > > Actually the mock ppgtt is 64b. > > > -Chris > > > > Setting it 64 bit causes mock_hugepages to fail. > > 1<<64 somewhere? > Doh, yeah, there is that. So what does 64b mean for ppgtt->vm.total? Should it really be 63b? -- Bob Paauwe bob.j.paa...@intel.com IOTG / PED Software Organization Intel Corp. Folsom, CA (916) 356-6193 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Make 48bit full ppgtt configuration generic (v4)
On Thu, Sep 13, 2018 at 10:12:06AM -0700, Bob Paauwe wrote: > On Thu, 13 Sep 2018 20:05:54 +0300 > Ville Syrjälä wrote: > > > On Thu, Sep 13, 2018 at 10:02:57AM -0700, Bob Paauwe wrote: > > > On Wed, 12 Sep 2018 17:10:58 +0100 > > > Chris Wilson wrote: > > > > > > > Quoting Bob Paauwe (2018-09-12 17:04:30) > > > > > diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > > b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > > index 43ed8b28aeaa..33d7225edbbb 100644 > > > > > --- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > > +++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c > > > > > @@ -181,6 +181,8 @@ struct drm_i915_private *mock_gem_device(void) > > > > > I915_GTT_PAGE_SIZE_64K | > > > > > I915_GTT_PAGE_SIZE_2M; > > > > > > > > > > + mkwrite_device_info(i915)->full_ppgtt_bits = 48; > > > > > > > > Actually the mock ppgtt is 64b. > > > > -Chris > > > > > > Setting it 64 bit causes mock_hugepages to fail. > > > > 1<<64 somewhere? > > > > Doh, yeah, there is that. So what does 64b mean for ppgtt->vm.total? > Should it really be 63b? GENMASK() & ~(GTT_PAGE_SIZE-1) maybe? -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/nouveau: Disable atomic support on a per-device basis
== Series Details == Series: series starting with [1/2] drm/nouveau: Disable atomic support on a per-device basis URL : https://patchwork.freedesktop.org/series/49650/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4817 -> Patchwork_10172 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10172 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10172, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/49650/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10172: === IGT changes === Possible regressions igt@drv_selftest@mock_hugepages: fi-bwr-2160:PASS -> DMESG-FAIL Warnings igt@pm_rpm@module-reload: fi-hsw-4770r: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10172 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-kbl-soraka: NOTRUN -> INCOMPLETE (fdo#107774, fdo#107556) igt@gem_exec_suspend@basic-s4-devices: fi-blb-e6850: NOTRUN -> INCOMPLETE (fdo#107718) igt@kms_frontbuffer_tracking@basic: fi-hsw-peppy: PASS -> DMESG-WARN (fdo#102614) fi-byt-clapper: PASS -> FAIL (fdo#103167) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-hsw-4770r: DMESG-WARN -> PASS igt@drv_selftest@live_coherency: fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS igt@gem_exec_suspend@basic-s3: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS fdo#102614 https://bugs.freedesktop.org/show_bug.cgi?id=102614 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774 == Participating hosts (48 -> 44) == Additional (1): fi-kbl-soraka Missing(5): fi-byt-j1900 fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4817 -> Patchwork_10172 CI_DRM_4817: 0725fa5c5756ff86de0f33f10b9d92ac452d5118 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10172: f57b35508efe08d2294d622ac5a93d2113c04a4e @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == f57b35508efe drm/amdgpu: Use per-device driver_features to disable atomic c47608435df1 drm/nouveau: Disable atomic support on a per-device basis == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10172/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915/execlists: Use coherent writes into the context image
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
v2: With extra enthusiasm.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_perf.c| 4 +++-
drivers/gpu/drm/i915/intel_engine_cs.c | 2 +-
drivers/gpu/drm/i915/intel_lrc.c| 8 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
6 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ea442033a57..5c833a45682d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3074,6 +3074,12 @@ enum i915_map_type {
I915_MAP_FORCE_WC = I915_MAP_WC | I915_MAP_OVERRIDE,
};
+static inline enum i915_map_type
+i915_coherent_map_type(struct drm_i915_private *i915)
+{
+ return HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
+}
+
/**
* i915_gem_object_pin_map - return a contiguous mapping of the entire object
* @obj: the object to map into kernel address space
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 89834ce19acd..d6f2bbd6a0dc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5417,6 +5417,8 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
for_each_engine(engine, i915, id) {
struct i915_vma *state;
+ GEM_BUG_ON(to_intel_context(ctx, engine)->pin_count);
+
state = to_intel_context(ctx, engine)->state;
if (!state)
continue;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3d7a052b4cca..90168ac845c2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1735,13 +1735,15 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
struct intel_context *ce = to_intel_context(ctx, engine);
+ unsigned int map_type;
u32 *regs;
/* OA settings will be set upon first use */
if (!ce->state)
continue;
- regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ map_type = i915_coherent_map_type(dev_priv);
+ regs = i915_gem_object_pin_map(ce->state->obj, map_type);
if (IS_ERR(regs))
return PTR_ERR(regs);
diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 10cd051ba29e..c99f2cb9b0e1 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -1150,7 +1150,7 @@ void intel_engines_unpark(struct drm_i915_private *i915)
map = NULL;
if (engine->default_state)
map = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MAP_FORCE_WB);
if (!IS_ERR_OR_NULL(map))
engine->pinned_default_state = map;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d7fcbba8e982..7b1f322f232b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1294,7 +1294,7 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
* on an active context (which by nature is already on the GPU).
*/
if (!(vma->flags & I915_VMA_GLOBAL_BIND)) {
- err = i915_gem_object_set_to_gtt_domain(vma->obj, true);
+ err = i915_gem_object_set_to_wc_domain(vma->obj, true);
if (err)
return err;
}
@@ -1322,7 +1322,9 @@ __execlists_context_pin(struct intel_engine_cs *engine,
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(ctx->i915) |
+ I915_MAP_OVERRIDE);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto unpin_vma;
@@ -2753,7 +2755,7 @@ populate_lr_context(struct i915_gem_context *ctx,
void *defaults;
defaults = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MA
[Intel-gfx] [PATCH 1/2] drm/i915/execlists: Delay updating ring register state after resume
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
v3: Set RING_TAIL on context-pin so that we always have known state in
the context image for the ring registers and all parties have similar
code (ripe for refactoring).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 33 +++-
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9b1f0e5211a0..d7fcbba8e982 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1338,11 +1338,13 @@ __execlists_context_pin(struct intel_engine_cs *engine,
intel_lr_context_descriptor_update(ctx, engine, ce);
+ GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
+
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
i915_ggtt_offset(ce->ring->vma);
- GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
- ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
+ ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
+ ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -2841,13 +2843,14 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return ret;
}
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
- /* Because we emit WA_TAIL_DWORDS there may be a disparity
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
* between our bookkeeping in ce->ring->head and ce->ring->tail and
* that stored in context. As we only write new commands from
* ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2857,28 +2860,22 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
* So to avoid that we reset the context images upon resume. For
* simplicity, we just zero everything out.
*/
- list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
- for_each_engine(engine, dev_priv, id) {
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ for_each_engine(engine, i915, id) {
struct intel_context *ce =
to_intel_context(ctx, engine);
- u32 *reg;
if (!ce->state)
continue;
- reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
- if (WARN_ON(IS_ERR(reg)))
- continue;
-
- reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
- reg[CTX_RING_HEAD+1] = 0;
- reg[CTX_RING_TAIL+1] = 0;
+ intel_ring_reset(ce->ring, 0);
- ce->state->obj->mm.dirty = true;
- i915_gem_object_unpin_map(ce->state->obj);
+ if (ce->pin_count) { /* otherwise done in context_pin */
+ u32 *regs = ce->lrc_reg_state;
- intel_ring_reset(ce->ring, 0);
+ regs[CTX_RING_HEAD + 1] = ce->ring->head;
+ regs[CTX_RING_TAIL + 1] = ce->ring->tail;
+ }
}
}
}
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
== Series Details == Series: drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE URL : https://patchwork.freedesktop.org/series/49645/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4817 -> Patchwork_10173 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10173 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10173, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/49645/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10173: === IGT changes === Warnings igt@pm_rpm@module-reload: fi-hsw-4770r: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10173 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-kbl-soraka: NOTRUN -> INCOMPLETE (fdo#107774, fdo#107556) fi-icl-u: PASS -> INCOMPLETE (fdo#107901) igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cfl-8109u: PASS -> INCOMPLETE (fdo#106070) fi-blb-e6850: NOTRUN -> INCOMPLETE (fdo#107718) igt@kms_psr@primary_page_flip: fi-kbl-r: PASS -> FAIL (fdo#107336) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-hsw-4770r: DMESG-WARN -> PASS igt@drv_selftest@live_coherency: fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS igt@gem_exec_suspend@basic-s3: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: DMESG-WARN (fdo#105128, fdo#107139) -> PASS igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-byt-clapper: FAIL (fdo#107362, fdo#103191) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774 fdo#107901 https://bugs.freedesktop.org/show_bug.cgi?id=107901 == Participating hosts (48 -> 44) == Additional (1): fi-kbl-soraka Missing(5): fi-bsw-cyan fi-ilk-m540 fi-byt-squawks fi-bdw-5557u fi-hsw-4200u == Build changes == * Linux: CI_DRM_4817 -> Patchwork_10173 CI_DRM_4817: 0725fa5c5756ff86de0f33f10b9d92ac452d5118 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10173: cb4d2347b96d80ca07d8dfbf20d9ed43425d5c17 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cb4d2347b96d drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10173/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/execlists: Delay updating ring register state after resume
On 13/09/2018 18:32, Chris Wilson wrote:
Now that we reload both RING_HEAD and RING_TAIL when rebinding the
context, we do not need to scrub those registers immediately on resume.
v2: Handle the perma-pinned contexts.
v3: Set RING_TAIL on context-pin so that we always have known state in
the context image for the ring registers and all parties have similar
code (ripe for refactoring).
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/intel_lrc.c | 33 +++-
1 file changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 9b1f0e5211a0..d7fcbba8e982 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1338,11 +1338,13 @@ __execlists_context_pin(struct intel_engine_cs *engine,
intel_lr_context_descriptor_update(ctx, engine, ce);
+ GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
+
ce->lrc_reg_state = vaddr + LRC_STATE_PN * PAGE_SIZE;
ce->lrc_reg_state[CTX_RING_BUFFER_START+1] =
i915_ggtt_offset(ce->ring->vma);
- GEM_BUG_ON(!intel_ring_offset_valid(ce->ring, ce->ring->head));
- ce->lrc_reg_state[CTX_RING_HEAD+1] = ce->ring->head;
+ ce->lrc_reg_state[CTX_RING_HEAD + 1] = ce->ring->head;
+ ce->lrc_reg_state[CTX_RING_TAIL + 1] = ce->ring->tail;
ce->state->obj->pin_global++;
i915_gem_context_get(ctx);
@@ -2841,13 +2843,14 @@ static int execlists_context_deferred_alloc(struct
i915_gem_context *ctx,
return ret;
}
-void intel_lr_context_resume(struct drm_i915_private *dev_priv)
+void intel_lr_context_resume(struct drm_i915_private *i915)
{
struct intel_engine_cs *engine;
struct i915_gem_context *ctx;
enum intel_engine_id id;
- /* Because we emit WA_TAIL_DWORDS there may be a disparity
+ /*
+* Because we emit WA_TAIL_DWORDS there may be a disparity
* between our bookkeeping in ce->ring->head and ce->ring->tail and
* that stored in context. As we only write new commands from
* ce->ring->tail onwards, everything before that is junk. If the GPU
@@ -2857,28 +2860,22 @@ void intel_lr_context_resume(struct drm_i915_private
*dev_priv)
* So to avoid that we reset the context images upon resume. For
* simplicity, we just zero everything out.
*/
- list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
- for_each_engine(engine, dev_priv, id) {
+ list_for_each_entry(ctx, &i915->contexts.list, link) {
+ for_each_engine(engine, i915, id) {
struct intel_context *ce =
to_intel_context(ctx, engine);
- u32 *reg;
if (!ce->state)
continue;
- reg = i915_gem_object_pin_map(ce->state->obj,
- I915_MAP_WB);
- if (WARN_ON(IS_ERR(reg)))
- continue;
-
- reg += LRC_STATE_PN * PAGE_SIZE / sizeof(*reg);
- reg[CTX_RING_HEAD+1] = 0;
- reg[CTX_RING_TAIL+1] = 0;
+ intel_ring_reset(ce->ring, 0);
- ce->state->obj->mm.dirty = true;
- i915_gem_object_unpin_map(ce->state->obj);
+ if (ce->pin_count) { /* otherwise done in context_pin */
+ u32 *regs = ce->lrc_reg_state;
- intel_ring_reset(ce->ring, 0);
+ regs[CTX_RING_HEAD + 1] = ce->ring->head;
+ regs[CTX_RING_TAIL + 1] = ce->ring->tail;
+ }
}
}
}
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume URL : https://patchwork.freedesktop.org/series/49654/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/execlists: Delay updating ring register state after resume Okay! Commit: drm/i915/execlists: Use coherent writes into the context image -drivers/gpu/drm/i915/selftests/../i915_drv.h:3689:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3695:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume URL : https://patchwork.freedesktop.org/series/49654/ State : failure == Summary == = CI Bug Log - changes from CI_DRM_4817 -> Patchwork_10174 = == Summary - FAILURE == Serious unknown changes coming with Patchwork_10174 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10174, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/49654/revisions/1/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10174: === IGT changes === Possible regressions igt@drv_selftest@live_contexts: fi-bsw-n3050: PASS -> DMESG-FAIL Warnings igt@pm_rpm@module-reload: fi-hsw-4770r: SKIP -> PASS == Known issues == Here are the changes found in Patchwork_10174 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload: fi-blb-e6850: NOTRUN -> INCOMPLETE (fdo#107718) igt@gem_exec_suspend@basic-s3: fi-kbl-soraka: NOTRUN -> INCOMPLETE (fdo#107556, fdo#107774) Possible fixes igt@drv_module_reload@basic-reload-inject: fi-hsw-4770r: DMESG-WARN (fdo#107924) -> PASS igt@drv_selftest@live_coherency: fi-gdg-551: DMESG-FAIL (fdo#107164) -> PASS igt@gem_exec_suspend@basic-s3: fi-blb-e6850: INCOMPLETE (fdo#107718) -> PASS fdo#107164 https://bugs.freedesktop.org/show_bug.cgi?id=107164 fdo#107556 https://bugs.freedesktop.org/show_bug.cgi?id=107556 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107774 https://bugs.freedesktop.org/show_bug.cgi?id=107774 fdo#107924 https://bugs.freedesktop.org/show_bug.cgi?id=107924 == Participating hosts (48 -> 45) == Additional (1): fi-kbl-soraka Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4817 -> Patchwork_10174 CI_DRM_4817: 0725fa5c5756ff86de0f33f10b9d92ac452d5118 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10174: c701befaed7dfa1b985984037d6bf5e4299ce391 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c701befaed7d drm/i915/execlists: Use coherent writes into the context image 0c773550b623 drm/i915/execlists: Delay updating ring register state after resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10174/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/amdgpu: Use per-device driver_features to disable atomic
On Thu, Sep 13, 2018 at 12:40:20PM -0400, Alex Deucher wrote:
> On Thu, Sep 13, 2018 at 12:39 PM Michel Dänzer wrote:
> >
> > On 2018-09-13 6:31 p.m., Ville Syrjala wrote:
> > > From: Ville Syrjälä
> > >
> > > Disable atomic on a per-device basis instead of for all devices.
> > > Made possible by the new device.driver_features thing.
> > >
> > > Cc: Alex Deucher
> > > Cc: "Christian König"
> > > Cc: "David (ChunMing) Zhou"
> > > Cc: Harry Wentland
> > > Cc: Michel Dänzer
> > > Suggested-by: Michel Dänzer
> > > Signed-off-by: Ville Syrjälä
> > > ---
> > > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12
> > > 1 file changed, 4 insertions(+), 8 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > index 6870909da926..8c1db96be070 100644
> > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
> > > @@ -816,17 +816,13 @@ static int amdgpu_pci_probe(struct pci_dev *pdev,
> > > if (ret)
> > > return ret;
> > >
> > > - /* warn the user if they mix atomic and non-atomic capable GPUs */
> > > - if ((kms_driver.driver_features & DRIVER_ATOMIC) &&
> > > !supports_atomic)
> > > - DRM_ERROR("Mixing atomic and non-atomic capable GPUs!\n");
> > > - /* support atomic early so the atomic debugfs stuff gets created */
> > > - if (supports_atomic)
> > > - kms_driver.driver_features |= DRIVER_ATOMIC;
> > > -
> > > dev = drm_dev_alloc(&kms_driver, &pdev->dev);
> > > if (IS_ERR(dev))
> > > return PTR_ERR(dev);
> > >
> > > + if (!supports_atomic)
> > > + dev->driver_features &= ~DRIVER_ATOMIC;
> > > +
> > > ret = pci_enable_device(pdev);
> > > if (ret)
> > > goto err_free;
> > > @@ -1078,7 +1074,7 @@ amdgpu_get_crtc_scanout_position(struct drm_device
> > > *dev, unsigned int pipe,
> > >
> > > static struct drm_driver kms_driver = {
> > > .driver_features =
> > > - DRIVER_USE_AGP |
> > > + DRIVER_USE_AGP | DRIVER_ATOMIC |
> > > DRIVER_HAVE_IRQ | DRIVER_IRQ_SHARED | DRIVER_GEM |
> > > DRIVER_PRIME | DRIVER_RENDER | DRIVER_MODESET | DRIVER_SYNCOBJ,
> > > .load = amdgpu_driver_load_kms,
> > >
> >
> > Thanks Ville for taking care of this!
> >
> > Reviewed-by: Michel Dänzer
> >
> > If Alex agrees, probably best to push this to drm-misc-next as well.
> >
>
> Reviewed-by: Alex Deucher
>
> Please go ahead and merge through drm-misc.
>
> Thanks!
You are welcome, and thanks for the r-bs. Pushed.
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE
== Series Details == Series: drm/i915: Replace some PAGE_SIZE with I915_GTT_PAGE_SIZE URL : https://patchwork.freedesktop.org/series/49645/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4817_full -> Patchwork_10173_full = == Summary - SUCCESS == No regressions found. == Known issues == Here are the changes found in Patchwork_10173_full that come from known issues: === IGT changes === Issues hit igt@gem_ctx_isolation@rcs0-s3: shard-apl: PASS -> INCOMPLETE (fdo#103927) igt@gem_exec_schedule@preempt-hang-blt: shard-snb: NOTRUN -> INCOMPLETE (fdo#105411) igt@kms_cursor_legacy@2x-long-cursor-vs-flip-atomic: shard-hsw: PASS -> FAIL (fdo#105767) igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: shard-glk: PASS -> FAIL (fdo#105363) igt@kms_setmode@basic: shard-hsw: PASS -> FAIL (fdo#99912) Possible fixes igt@gem_eio@in-flight-suspend: shard-glk: DMESG-WARN (fdo#107925) -> PASS igt@gem_exec_await@wide-contexts: shard-glk: FAIL (fdo#106680) -> PASS igt@gem_exec_schedule@preempt-other-chain-vebox: shard-snb: INCOMPLETE (fdo#105411) -> SKIP igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: shard-hsw: FAIL (fdo#105767) -> PASS igt@kms_setmode@basic: shard-apl: FAIL (fdo#99912) -> PASS fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fdo#105363 https://bugs.freedesktop.org/show_bug.cgi?id=105363 fdo#105411 https://bugs.freedesktop.org/show_bug.cgi?id=105411 fdo#105767 https://bugs.freedesktop.org/show_bug.cgi?id=105767 fdo#106680 https://bugs.freedesktop.org/show_bug.cgi?id=106680 fdo#107925 https://bugs.freedesktop.org/show_bug.cgi?id=107925 fdo#99912 https://bugs.freedesktop.org/show_bug.cgi?id=99912 == Participating hosts (5 -> 5) == No changes in participating hosts == Build changes == * Linux: CI_DRM_4817 -> Patchwork_10173 CI_DRM_4817: 0725fa5c5756ff86de0f33f10b9d92ac452d5118 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10173: cb4d2347b96d80ca07d8dfbf20d9ed43425d5c17 @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10173/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3] drm: Differentiate the lack of an interface from invalid parameter
If the ioctl is not supported on a particular piece of HW/driver
combination, report ENOTSUP (aka EOPNOTSUPP) so that it can be easily
distinguished from both the lack of the ioctl and from a regular invalid
parameter.
v2: Across all the kms ioctls we had a mixture of reporting EINVAL,
ENODEV and a few ENOTSUPP (most where EINVAL) for a failed
drm_core_check_feature(). Update everybody to report ENOTSUPP.
v3: ENOTSUPP is an internal errno! It's value (524) does not correspond
to a POSIX errno, the one we want is ENOTSUP. However,
uapi/asm-generic/errno.h doesn't include ENOTSUP but man errno says
"ENOTSUP and EOPNOTSUPP have the same value on Linux,
but according to POSIX.1 these error values should be
distinct."
so use EOPNOTSUPP as its equivalent.
Signed-off-by: Chris Wilson
Cc: Daniel Vetter
Cc: Ville Syrjälä
Reviewed-by: Daniel Vetter #v2
---
drivers/gpu/drm/drm_atomic_uapi.c | 2 +-
drivers/gpu/drm/drm_bufs.c| 32 +++
drivers/gpu/drm/drm_client.c | 2 +-
drivers/gpu/drm/drm_color_mgmt.c | 4 ++--
drivers/gpu/drm/drm_connector.c | 2 +-
drivers/gpu/drm/drm_context.c | 16
drivers/gpu/drm/drm_crtc.c| 4 ++--
drivers/gpu/drm/drm_encoder.c | 2 +-
drivers/gpu/drm/drm_framebuffer.c | 13 -
drivers/gpu/drm/drm_gem.c | 6 +++---
drivers/gpu/drm/drm_ioctl.c | 4 ++--
drivers/gpu/drm/drm_irq.c | 4 ++--
drivers/gpu/drm/drm_lease.c | 8
drivers/gpu/drm/drm_lock.c| 4 ++--
drivers/gpu/drm/drm_mode_config.c | 3 +--
drivers/gpu/drm/drm_mode_object.c | 4 ++--
drivers/gpu/drm/drm_pci.c | 4 ++--
drivers/gpu/drm/drm_plane.c | 10 +-
drivers/gpu/drm/drm_prime.c | 4 ++--
drivers/gpu/drm/drm_property.c| 8
drivers/gpu/drm/drm_scatter.c | 8
drivers/gpu/drm/drm_syncobj.c | 14 +++---
drivers/gpu/drm/drm_vblank.c | 4 ++--
23 files changed, 82 insertions(+), 80 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_uapi.c
b/drivers/gpu/drm/drm_atomic_uapi.c
index 26690a664ec6..d5b7f315098c 100644
--- a/drivers/gpu/drm/drm_atomic_uapi.c
+++ b/drivers/gpu/drm/drm_atomic_uapi.c
@@ -1251,7 +1251,7 @@ int drm_mode_atomic_ioctl(struct drm_device *dev,
/* disallow for drivers not supporting atomic: */
if (!drm_core_check_feature(dev, DRIVER_ATOMIC))
- return -EINVAL;
+ return -EOPNOTSUPP;
/* disallow for userspace that has not enabled atomic cap (even
* though this may be a bit overkill, since legacy userspace
diff --git a/drivers/gpu/drm/drm_bufs.c b/drivers/gpu/drm/drm_bufs.c
index ba8cfe65c65b..7412acaf3cde 100644
--- a/drivers/gpu/drm/drm_bufs.c
+++ b/drivers/gpu/drm/drm_bufs.c
@@ -398,7 +398,7 @@ int drm_legacy_addmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
err = drm_addmap_core(dev, map->offset, map->size, map->type,
map->flags, &maplist);
@@ -444,7 +444,7 @@ int drm_legacy_getmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
idx = map->offset;
if (idx < 0)
@@ -596,7 +596,7 @@ int drm_legacy_rmmap_ioctl(struct drm_device *dev, void
*data,
if (!drm_core_check_feature(dev, DRIVER_KMS_LEGACY_CONTEXT) &&
!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
mutex_lock(&dev->struct_mutex);
list_for_each_entry(r_list, &dev->maplist, head) {
@@ -860,7 +860,7 @@ int drm_legacy_addbufs_pci(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_PCI_DMA))
- return -EINVAL;
+ return -EOPNOTSUPP;
if (!dma)
return -EINVAL;
@@ -1064,7 +1064,7 @@ static int drm_legacy_addbufs_sg(struct drm_device *dev,
struct drm_buf **temp_buflist;
if (!drm_core_check_feature(dev, DRIVER_SG))
- return -EINVAL;
+ return -EOPNOTSUPP;
if (!dma)
return -EINVAL;
@@ -1221,10 +1221,10 @@ int drm_legacy_addbufs(struct drm_device *dev, void
*data,
int ret;
if (!drm_core_check_feature(dev, DRIVER_LEGACY))
- return -EINVAL;
+ return -EOPNOTSUPP;
if (!drm_core_check_feature(dev, DRIVER_HAVE_DMA))
- return -EINVAL;
+ return -EOPNOTSUPP;
#if IS_ENABLED(CONFIG_AGP)
if (request->flags & _DRM_AGP_BUFFER)
@@ -1267,10 +1267,10 @@ int __
[Intel-gfx] [PATCH v3] drm/i915/execlists: Use coherent writes into the context image
That we use a WB mapping for updating the RING_TAIL register inside the
context image even on !llc machines has been a source of consternation
for every reader. It appears to work on bsw+, but it may just have been
that we have been incredibly bad at detecting the errors.
v2: With extra enthusiasm.
v3: Drop force of map type for pinned default_state as by the time we
pin it, the map type is always WB and doesn't conflict with the earlier
use by ce->state.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 ++
drivers/gpu/drm/i915/i915_perf.c| 4 +++-
drivers/gpu/drm/i915/intel_lrc.c| 8 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +-
5 files changed, 17 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7ea442033a57..5c833a45682d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -3074,6 +3074,12 @@ enum i915_map_type {
I915_MAP_FORCE_WC = I915_MAP_WC | I915_MAP_OVERRIDE,
};
+static inline enum i915_map_type
+i915_coherent_map_type(struct drm_i915_private *i915)
+{
+ return HAS_LLC(i915) ? I915_MAP_WB : I915_MAP_WC;
+}
+
/**
* i915_gem_object_pin_map - return a contiguous mapping of the entire object
* @obj: the object to map into kernel address space
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 89834ce19acd..d6f2bbd6a0dc 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5417,6 +5417,8 @@ static int __intel_engines_record_defaults(struct
drm_i915_private *i915)
for_each_engine(engine, i915, id) {
struct i915_vma *state;
+ GEM_BUG_ON(to_intel_context(ctx, engine)->pin_count);
+
state = to_intel_context(ctx, engine)->state;
if (!state)
continue;
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 3d7a052b4cca..90168ac845c2 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1735,13 +1735,15 @@ static int gen8_configure_all_contexts(struct
drm_i915_private *dev_priv,
/* Update all contexts now that we've stalled the submission. */
list_for_each_entry(ctx, &dev_priv->contexts.list, link) {
struct intel_context *ce = to_intel_context(ctx, engine);
+ unsigned int map_type;
u32 *regs;
/* OA settings will be set upon first use */
if (!ce->state)
continue;
- regs = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ map_type = i915_coherent_map_type(dev_priv);
+ regs = i915_gem_object_pin_map(ce->state->obj, map_type);
if (IS_ERR(regs))
return PTR_ERR(regs);
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index d7fcbba8e982..7b1f322f232b 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -1294,7 +1294,7 @@ static int __context_pin(struct i915_gem_context *ctx,
struct i915_vma *vma)
* on an active context (which by nature is already on the GPU).
*/
if (!(vma->flags & I915_VMA_GLOBAL_BIND)) {
- err = i915_gem_object_set_to_gtt_domain(vma->obj, true);
+ err = i915_gem_object_set_to_wc_domain(vma->obj, true);
if (err)
return err;
}
@@ -1322,7 +1322,9 @@ __execlists_context_pin(struct intel_engine_cs *engine,
if (ret)
goto err;
- vaddr = i915_gem_object_pin_map(ce->state->obj, I915_MAP_WB);
+ vaddr = i915_gem_object_pin_map(ce->state->obj,
+ i915_coherent_map_type(ctx->i915) |
+ I915_MAP_OVERRIDE);
if (IS_ERR(vaddr)) {
ret = PTR_ERR(vaddr);
goto unpin_vma;
@@ -2753,7 +2755,7 @@ populate_lr_context(struct i915_gem_context *ctx,
void *defaults;
defaults = i915_gem_object_pin_map(engine->default_state,
- I915_MAP_WB);
+ I915_MAP_FORCE_WB);
if (IS_ERR(defaults)) {
ret = PTR_ERR(defaults);
goto err_unpin_ctx;
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.c
b/drivers/gpu/drm/i915/intel_ringbuffer.c
index d0ef50bf930a..1eb68d77b66c 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.c
@@ -1288,7 +1288,7 @@ alloc_context_vma(struct intel_engine_cs *engine)
}
defaults = i915_gem_object_pin_map(engine->default_state,
-
[Intel-gfx] [PATCH] drm/i915/icl: Enable DC9 as lowest possible state during screen-off
From: Animesh Manna
ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable
DC5/6 when appropriate.
v2: (James Ausmus)
- Also handle ICL as GEN9_LP in i915_drm_suspend_late and
i915_drm_suspend_early
- Add DC9 to gen9_dc_mask for ICL
- Re-order GEN checks for newest platform first
- Use INTEL_GEN instead of INTEL_INFO->gen
- Use INTEL_GEN >= 11 instead of IS_ICELAKE
- Consolidate GEN checks
v3: (James Ausmus)
- Also allow DC6 for ICL (Imre, Art)
- Simplify !(GEN >= 11) to GEN < 11 (Imre)
v4: (James Ausmus)
- Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the
PPS regs are Always On
- Rebase against upstream changes
v5: (Anusha Srivatsa)
- rebased against the latest upstream changes.
Cc: Imre Deak
Cc: Rodrigo Vivi
Signed-off-by: Animesh Manna
Signed-off-by: James Ausmus
Signed-off-by: Anusha Srivatsa
---
drivers/gpu/drm/i915/i915_drv.c | 20 ++---
drivers/gpu/drm/i915/intel_drv.h| 3 +++
drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +++--
3 files changed, 37 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 2ddf8538cb47..86a83e0a7ef2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -1855,7 +1855,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
intel_uncore_resume_early(dev_priv);
- if (IS_GEN9_LP(dev_priv)) {
+ if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
gen9_sanitize_dc_state(dev_priv);
bxt_disable_dc9(dev_priv);
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
@@ -2622,7 +2622,10 @@ static int intel_runtime_suspend(struct device *kdev)
intel_uncore_suspend(dev_priv);
ret = 0;
- if (IS_GEN9_LP(dev_priv)) {
+ if (IS_ICELAKE(dev_priv)) {
+ icl_display_core_uninit(dev_priv);
+ bxt_enable_dc9(dev_priv);
+ } else if (IS_GEN9_LP(dev_priv)) {
bxt_display_core_uninit(dev_priv);
bxt_enable_dc9(dev_priv);
} else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
@@ -2707,7 +2710,18 @@ static int intel_runtime_resume(struct device *kdev)
if (intel_uncore_unclaimed_mmio(dev_priv))
DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
- if (IS_GEN9_LP(dev_priv)) {
+ if (IS_ICELAKE(dev_priv)) {
+ bxt_disable_dc9(dev_priv);
+ icl_display_core_init(dev_priv, true);
+ if (dev_priv->csr.dmc_payload) {
+ if (dev_priv->csr.allowed_dc_mask &
+ DC_STATE_EN_UPTO_DC6)
+ skl_enable_dc6(dev_priv);
+ else if (dev_priv->csr.allowed_dc_mask &
+DC_STATE_EN_UPTO_DC5)
+ gen9_enable_dc5(dev_priv);
+ }
+ } else if (IS_GEN9_LP(dev_priv)) {
bxt_disable_dc9(dev_priv);
bxt_display_core_init(dev_priv, true);
if (dev_priv->csr.dmc_payload &&
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index bf1c38728a59..f0385fe5bb15 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1627,6 +1627,7 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
void bxt_disable_dc9(struct drm_i915_private *dev_priv);
void gen9_enable_dc5(struct drm_i915_private *dev_priv);
unsigned int skl_cdclk_get_vco(unsigned int freq);
+void skl_enable_dc6(struct drm_i915_private *dev_priv);
void intel_dp_get_m_n(struct intel_crtc *crtc,
struct intel_crtc_state *pipe_config);
void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
@@ -1966,6 +1967,8 @@ int intel_power_domains_init(struct drm_i915_private *);
void intel_power_domains_cleanup(struct drm_i915_private *dev_priv);
void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool
resume);
void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv);
+void icl_display_core_init(struct drm_i915_private *dev_priv, bool resume);
+void icl_display_core_uninit(struct drm_i915_private *dev_priv);
void intel_power_domains_enable(struct drm_i915_private *dev_priv);
void intel_power_domains_disable(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
b/drivers/gpu/drm/i915/intel_runtime_pm.c
index 480dadb1047b..3e2c936217f8 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.c
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.c
@@ -551,7 +551,9 @@ static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
u32 mask;
mask = DC_STATE_EN_UPTO_DC5;
- if (IS_GEN9_LP(dev_priv))
+ if (INTEL_GEN(dev_priv) >= 11)
+ mask |= DC_STATE_EN_UPTO_DC6 | DC_STATE_EN_DC9;
+ else if (IS_GEN9_LP(dev_priv))
[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Differentiate the lack of an interface from invalid parameter (rev4)
== Series Details == Series: drm: Differentiate the lack of an interface from invalid parameter (rev4) URL : https://patchwork.freedesktop.org/series/49536/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4818 -> Patchwork_10175 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49536/revisions/4/mbox/ == Known issues == Here are the changes found in Patchwork_10175 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s4-devices: fi-kbl-7500u: PASS -> DMESG-WARN (fdo#107139, fdo#105128) igt@kms_psr@primary_page_flip: fi-kbl-r: PASS -> FAIL (fdo#107336) Possible fixes igt@drv_selftest@mock_hugepages: fi-bwr-2160:DMESG-FAIL -> PASS igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a: fi-byt-clapper: FAIL (fdo#107362) -> PASS fdo#105128 https://bugs.freedesktop.org/show_bug.cgi?id=105128 fdo#107139 https://bugs.freedesktop.org/show_bug.cgi?id=107139 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107362 https://bugs.freedesktop.org/show_bug.cgi?id=107362 == Participating hosts (48 -> 44) == Additional (1): fi-snb-2520m Missing(5): fi-hsw-4770r fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4818 -> Patchwork_10175 CI_DRM_4818: da3d33f1d75f54cf29f08dba582694792980cd9b @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10175: e4b70966e99a538f3460e1e6640d6f5389c1aa2d @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == e4b70966e99a drm: Differentiate the lack of an interface from invalid parameter == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10175/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/5] drm/i915: Add a new "remapped" gtt_view
From: Ville Syrjälä
To overcome display engine stride limits we'll want to remap the
pages in the GTT. To that end we need a new gtt_view type which
is just like the "rotated" type except not rotated.
v2: Use intel_remapped_plane_info base type
s/unused/unused_mbz/ (Chris)
Separate BUILD_BUG_ON()s (Chris)
Use I915_GTT_PAGE_SIZE (Chris)
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/i915_debugfs.c | 12
drivers/gpu/drm/i915/i915_gem_gtt.c | 91 +++
drivers/gpu/drm/i915/i915_gem_gtt.h | 25 +++--
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/i915/i915_vma.h | 3 +
drivers/gpu/drm/i915/intel_display.c | 11
drivers/gpu/drm/i915/intel_drv.h | 1 +
drivers/gpu/drm/i915/selftests/i915_vma.c | 6 +-
8 files changed, 147 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b4744a68cd88..edb9f6f3c0cf 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -196,6 +196,18 @@ describe_obj(struct seq_file *m, struct
drm_i915_gem_object *obj)
vma->ggtt_view.rotated.plane[1].offset);
break;
+ case I915_GGTT_VIEW_REMAPPED:
+ seq_printf(m, ", remapped [(%ux%u, stride=%u,
offset=%u), (%ux%u, stride=%u, offset=%u)]",
+
vma->ggtt_view.remapped.plane[0].width,
+
vma->ggtt_view.remapped.plane[0].height,
+
vma->ggtt_view.remapped.plane[0].stride,
+
vma->ggtt_view.remapped.plane[0].offset,
+
vma->ggtt_view.remapped.plane[1].width,
+
vma->ggtt_view.remapped.plane[1].height,
+
vma->ggtt_view.remapped.plane[1].stride,
+
vma->ggtt_view.remapped.plane[1].offset);
+ break;
+
default:
MISSING_CASE(vma->ggtt_view.type);
break;
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8be1acd097db..d805f49647ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -3798,6 +3798,92 @@ intel_rotate_pages(struct intel_rotation_info *rot_info,
return ERR_PTR(ret);
}
+static struct scatterlist *
+remap_pages(const dma_addr_t *in, unsigned int offset,
+ unsigned int width, unsigned int height,
+ unsigned int stride,
+ struct sg_table *st, struct scatterlist *sg)
+{
+ unsigned int column, row;
+
+ for (row = 0; row < height; row++) {
+ for (column = 0; column < width; column++) {
+ st->nents++;
+ /* We don't need the pages, but need to initialize
+* the entries so the sg list can be happily traversed.
+* The only thing we need are DMA addresses.
+*/
+ sg_set_page(sg, NULL, I915_GTT_PAGE_SIZE, 0);
+ sg_dma_address(sg) = in[offset + column];
+ sg_dma_len(sg) = I915_GTT_PAGE_SIZE;
+ sg = sg_next(sg);
+ }
+ offset += stride;
+ }
+
+ return sg;
+}
+
+static noinline struct sg_table *
+intel_remap_pages(struct intel_remapped_info *rem_info,
+ struct drm_i915_gem_object *obj)
+{
+ const unsigned long n_pages = obj->base.size / I915_GTT_PAGE_SIZE;
+ unsigned int size = intel_remapped_info_size(rem_info);
+ struct sgt_iter sgt_iter;
+ dma_addr_t dma_addr;
+ unsigned long i;
+ dma_addr_t *page_addr_list;
+ struct sg_table *st;
+ struct scatterlist *sg;
+ int ret = -ENOMEM;
+
+ /* Allocate a temporary list of source pages for random access. */
+ page_addr_list = kvmalloc_array(n_pages,
+ sizeof(dma_addr_t),
+ GFP_KERNEL);
+ if (!page_addr_list)
+ return ERR_PTR(ret);
+
+ /* Allocate target SG list. */
+ st = kmalloc(sizeof(*st), GFP_KERNEL);
+ if (!st)
+ goto err_st_alloc;
+
+ ret = sg_alloc_table(st, size, GFP_KERNEL);
+ if (ret)
+ goto err_sg_alloc;
+
+ /* Populate source page list from the object. */
+ i = 0;
+ for_each_sgt_dma(dma_addr, sgt_iter, obj->mm.pages)
+ page_addr_list[i++] = dma_addr;
+
+ GEM_BUG_ON(i != n_pages);
+ st->nents = 0;
+ sg = st->sgl;
+
+ for (i = 0 ;
[Intel-gfx] [PATCH v2 1/5] drm/i915: Decouple SKL stride units from intel_fb_stride_alignment()
From: Ville Syrjälä
In the future framebuffer stride alignment requirements won't exactly
match the units in which skl+ plane stride is specified. So extract
the code for the skl+ stuff into a separate helper.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 28 +---
1 file changed, 17 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 947301312ea3..3c9151a28103 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3503,6 +3503,21 @@ static void skl_detach_scalers(struct intel_crtc
*intel_crtc)
}
}
+static unsigned int skl_plane_stride_mult(const struct drm_framebuffer *fb,
+ int color_plane, unsigned int
rotation)
+{
+ /*
+* The stride is either expressed as a multiple of 64 bytes chunks for
+* linear buffers or in number of tiles for tiled buffers.
+*/
+ if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
+ return 64;
+ else if (drm_rotation_90_or_270(rotation))
+ return intel_tile_height(fb, color_plane);
+ else
+ return intel_tile_width_bytes(fb, color_plane);
+}
+
u32 skl_plane_stride(const struct intel_plane_state *plane_state,
int color_plane)
{
@@ -3513,16 +3528,7 @@ u32 skl_plane_stride(const struct intel_plane_state
*plane_state,
if (color_plane >= fb->format->num_planes)
return 0;
- /*
-* The stride is either expressed as a multiple of 64 bytes chunks for
-* linear buffers or in number of tiles for tiled buffers.
-*/
- if (drm_rotation_90_or_270(rotation))
- stride /= intel_tile_height(fb, color_plane);
- else
- stride /= intel_fb_stride_alignment(fb, color_plane);
-
- return stride;
+ return stride / skl_plane_stride_mult(fb, color_plane, rotation);
}
static u32 skl_plane_ctl_format(uint32_t pixel_format)
@@ -8875,7 +8881,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
fb->width = ((val >> 0) & 0x1fff) + 1;
val = I915_READ(PLANE_STRIDE(pipe, plane_id));
- stride_mult = intel_fb_stride_alignment(fb, 0);
+ stride_mult = skl_plane_stride_mult(fb, 0, DRM_MODE_ROTATE_0);
fb->pitches[0] = (val & 0x3ff) * stride_mult;
aligned_height = intel_fb_align_height(fb, 0, fb->height);
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 5/5] drm/i915: Bump gen4+ fb size limits to 32kx32k
From: Ville Syrjälä
With gtt remapping in place we can use arbitraily large framebuffers.
Let's bump the limits as high as we can (32k-1). Going beyond that
would require switching our s16.16 src coordinate representation to
something with more spare bits.
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 346572cf734a..0ee6255cd040 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -15527,8 +15527,8 @@ int intel_modeset_init(struct drm_device *dev)
dev->mode_config.max_width = 4096;
dev->mode_config.max_height = 4096;
} else {
- dev->mode_config.max_width = 8192;
- dev->mode_config.max_height = 8192;
+ dev->mode_config.max_width = 32767;
+ dev->mode_config.max_height = 32767;
}
if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/5] drm/i915: Bump gen4+ fb stride limit to 256KiB
From: Ville Syrjälä
With gtt remapping plugged in we can simply raise the stride
limit on gen4+. Let's just arbitraily pick 256 KiB as the limit.
No remapping CCS because the virtual address of each page actually
matters due to the new hash mode
(WaCompressedResourceDisplayNewHashMode:skl,kbl etc.), and no remapping
on gen2/3 due to lack of fence on the remapped vma.
v2: Rebase due to is_ccs_modifier()
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 93b0de594c5d..346572cf734a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2506,6 +2506,19 @@ static
u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
u32 pixel_format, u64 modifier)
{
+ /*
+* Arbitrary limit for gen4+. We can deal with any page
+* aligned stride via GTT remapping. Gen2/3 need a fence
+* for tiled scanout which the remapped vma won't have,
+* so we don't allow remapping on those platforms.
+*
+* Also the new hash mode we use for CCS isn't compatible
+* with remapping as the virtual address of the pages
+* affects the compressed data.
+*/
+ if (INTEL_GEN(dev_priv) >= 4 && !is_ccs_modifier(modifier))
+ return 256*1024;
+
return intel_plane_fb_max_stride(dev_priv, pixel_format, modifier);
}
--
2.16.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 0/5] drm/i915: drm/i915: GTT remapping for display
From: Ville Syrjälä Lots of prep stuff for the GTT remapping already landed, so now we're left with just the real meat: the remapped vma and actually constructing it. I spotted that I kinda busted up the skl+ stride_mult stuff for linear buffers in the BIOS fb takeover path so I included a fix for that as a separate patch. Ville Syrjälä (5): drm/i915: Decouple SKL stride units from intel_fb_stride_alignment() drm/i915: Add a new "remapped" gtt_view drm/i915: Overcome display engine stride limits via GTT remapping drm/i915: Bump gen4+ fb stride limit to 256KiB drm/i915: Bump gen4+ fb size limits to 32kx32k drivers/gpu/drm/i915/i915_debugfs.c | 12 + drivers/gpu/drm/i915/i915_gem_gtt.c | 91 +++ drivers/gpu/drm/i915/i915_gem_gtt.h | 25 +- drivers/gpu/drm/i915/i915_vma.c | 6 +- drivers/gpu/drm/i915/i915_vma.h | 3 + drivers/gpu/drm/i915/intel_display.c | 428 -- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/selftests/i915_vma.c | 6 +- 8 files changed, 480 insertions(+), 92 deletions(-) -- 2.16.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/5] drm/i915: Overcome display engine stride limits via GTT remapping
From: Ville Syrjälä
The display engine stride limits are getting in our way. On SKL+
we are limited to 8k pixels, which is easily exceeded with three
4k displays. To overcome this limitation we can remap the pages
in the GTT to provide the display engine with a view of memory
with a smaller stride.
The code is mostly already there as We already play tricks with
the plane surface address and x/y offsets.
A few caveats apply:
* linear buffers need the fb stride to be page aligned, as
otherwise the remapped lines wouldn't start at the same
spot
* compressed buffers can't be remapped due to the new
ccs hash mode causing the virtual address of the pages
to affect the interpretation of the compressed data. IIRC
the old hash was limited to the low 12 bits so if we were
using that mode we could remap. As it stands we just refuse
to remapp with compressed fbs.
* no remapping gen2/3 as we'd need a fence for the remapped
vma, which we currently don't have. Need to deal with the
fence POT requirements, and do something about the gen2
gtt page size vs tile size difference
v2: Reabase due to is_ccs_modifier()
Fix up the skl+ stride_mult mess
memset() the gtt_view because otherwise we could leave
junk in plane[1] when going from 2 plane to 1 plane format
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/i915/intel_display.c | 372 ---
1 file changed, 301 insertions(+), 71 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 21aa0c0321b6..93b0de594c5d 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -1924,7 +1924,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
switch (fb->modifier) {
case DRM_FORMAT_MOD_LINEAR:
- return cpp;
+ return intel_tile_size(dev_priv);
case I915_FORMAT_MOD_X_TILED:
if (IS_GEN2(dev_priv))
return 128;
@@ -1967,11 +1967,8 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
static unsigned int
intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
{
- if (fb->modifier == DRM_FORMAT_MOD_LINEAR)
- return 1;
- else
- return intel_tile_size(to_i915(fb->dev)) /
- intel_tile_width_bytes(fb, color_plane);
+ return intel_tile_size(to_i915(fb->dev)) /
+ intel_tile_width_bytes(fb, color_plane);
}
/* Return the tile dimensions in pixel units */
@@ -2226,16 +2223,8 @@ void intel_add_fb_offsets(int *x, int *y,
int color_plane)
{
- const struct intel_framebuffer *intel_fb =
to_intel_framebuffer(state->base.fb);
- unsigned int rotation = state->base.rotation;
-
- if (drm_rotation_90_or_270(rotation)) {
- *x += intel_fb->rotated[color_plane].x;
- *y += intel_fb->rotated[color_plane].y;
- } else {
- *x += intel_fb->normal[color_plane].x;
- *y += intel_fb->normal[color_plane].y;
- }
+ *x += state->color_plane[color_plane].x;
+ *y += state->color_plane[color_plane].y;
}
static u32 intel_adjust_tile_offset(int *x, int *y,
@@ -2495,6 +2484,105 @@ bool is_ccs_modifier(u64 modifier)
modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
}
+static
+u32 intel_plane_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier)
+{
+ struct intel_crtc *crtc;
+ struct intel_plane *plane;
+
+ /*
+* We assume the primary plane for pipe A has
+* the highest stride limits of them all.
+*/
+ crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A);
+ plane = to_intel_plane(crtc->base.primary);
+
+ return plane->max_stride(plane, pixel_format, modifier,
+DRM_MODE_ROTATE_0);
+}
+
+static
+u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
+ u32 pixel_format, u64 modifier)
+{
+ return intel_plane_fb_max_stride(dev_priv, pixel_format, modifier);
+}
+
+static u32
+intel_fb_stride_alignment(const struct drm_framebuffer *fb, int color_plane)
+{
+ struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+ if (fb->modifier == DRM_FORMAT_MOD_LINEAR) {
+ u32 max_stride = intel_plane_fb_max_stride(dev_priv,
+ fb->format->format,
+ fb->modifier);
+
+ /*
+* To make remapping with linear generally feasible
+* we need the stride to be page aligned.
+*/
+ if (fb->pitches[color_plane] > max_stride)
+ return intel_tile_size(dev_priv);
+ else
+ return 64;
+ }
Re: [Intel-gfx] [PATCH] drm/i915/icl: Enable DC9 as lowest possible state during screen-off
On Thu, Sep 13, 2018 at 12:31:09PM -0700, Anusha Srivatsa wrote:
> From: Animesh Manna
>
> ICL supports DC5, DC6, and DC9. Enable DC9 during screen-off, and enable
> DC5/6 when appropriate.
>
> v2: (James Ausmus)
> - Also handle ICL as GEN9_LP in i915_drm_suspend_late and
>i915_drm_suspend_early
> - Add DC9 to gen9_dc_mask for ICL
> - Re-order GEN checks for newest platform first
> - Use INTEL_GEN instead of INTEL_INFO->gen
> - Use INTEL_GEN >= 11 instead of IS_ICELAKE
> - Consolidate GEN checks
>
> v3: (James Ausmus)
> - Also allow DC6 for ICL (Imre, Art)
> - Simplify !(GEN >= 11) to GEN < 11 (Imre)
>
> v4: (James Ausmus)
> - Don't call intel_power_sequencer_reset after DC9 for Gen11+, as the
>PPS regs are Always On
> - Rebase against upstream changes
>
> v5: (Anusha Srivatsa)
> - rebased against the latest upstream changes.
First concern with this patch is regarding the tests...
How is this getting tested? Are you able to see DC6 and DC9?
>
> Cc: Imre Deak
> Cc: Rodrigo Vivi
> Signed-off-by: Animesh Manna
> Signed-off-by: James Ausmus
> Signed-off-by: Anusha Srivatsa
> ---
> drivers/gpu/drm/i915/i915_drv.c | 20 ++---
> drivers/gpu/drm/i915/intel_drv.h| 3 +++
> drivers/gpu/drm/i915/intel_runtime_pm.c | 29 +++--
> 3 files changed, 37 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 2ddf8538cb47..86a83e0a7ef2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1855,7 +1855,7 @@ static int i915_drm_resume_early(struct drm_device *dev)
>
> intel_uncore_resume_early(dev_priv);
>
> - if (IS_GEN9_LP(dev_priv)) {
> + if (INTEL_GEN(dev_priv) >= 11 || IS_GEN9_LP(dev_priv)) {
> gen9_sanitize_dc_state(dev_priv);
> bxt_disable_dc9(dev_priv);
> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> @@ -2622,7 +2622,10 @@ static int intel_runtime_suspend(struct device *kdev)
> intel_uncore_suspend(dev_priv);
>
> ret = 0;
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_ICELAKE(dev_priv)) {
> + icl_display_core_uninit(dev_priv);
> + bxt_enable_dc9(dev_priv);
> + } else if (IS_GEN9_LP(dev_priv)) {
> bxt_display_core_uninit(dev_priv);
> bxt_enable_dc9(dev_priv);
> } else if (IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) {
> @@ -2707,7 +2710,18 @@ static int intel_runtime_resume(struct device *kdev)
> if (intel_uncore_unclaimed_mmio(dev_priv))
> DRM_DEBUG_DRIVER("Unclaimed access during suspend, bios?\n");
>
> - if (IS_GEN9_LP(dev_priv)) {
> + if (IS_ICELAKE(dev_priv)) {
commit message mention the use of INTEL_GEN instead of ICELAKE,
but it seems we are missing some replacements here
> + bxt_disable_dc9(dev_priv);
> + icl_display_core_init(dev_priv, true);
> + if (dev_priv->csr.dmc_payload) {
> + if (dev_priv->csr.allowed_dc_mask &
> + DC_STATE_EN_UPTO_DC6)
> + skl_enable_dc6(dev_priv);
> + else if (dev_priv->csr.allowed_dc_mask &
> + DC_STATE_EN_UPTO_DC5)
> + gen9_enable_dc5(dev_priv);
> + }
> + } else if (IS_GEN9_LP(dev_priv)) {
> bxt_disable_dc9(dev_priv);
> bxt_display_core_init(dev_priv, true);
> if (dev_priv->csr.dmc_payload &&
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index bf1c38728a59..f0385fe5bb15 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1627,6 +1627,7 @@ void bxt_enable_dc9(struct drm_i915_private *dev_priv);
> void bxt_disable_dc9(struct drm_i915_private *dev_priv);
> void gen9_enable_dc5(struct drm_i915_private *dev_priv);
> unsigned int skl_cdclk_get_vco(unsigned int freq);
> +void skl_enable_dc6(struct drm_i915_private *dev_priv);
> void intel_dp_get_m_n(struct intel_crtc *crtc,
> struct intel_crtc_state *pipe_config);
> void intel_dp_set_m_n(struct intel_crtc *crtc, enum link_m_n_set m_n);
> @@ -1966,6 +1967,8 @@ int intel_power_domains_init(struct drm_i915_private *);
> void intel_power_domains_cleanup(struct drm_i915_private *dev_priv);
> void intel_power_domains_init_hw(struct drm_i915_private *dev_priv, bool
> resume);
> void intel_power_domains_fini_hw(struct drm_i915_private *dev_priv);
> +void icl_display_core_init(struct drm_i915_private *dev_priv, bool resume);
> +void icl_display_core_uninit(struct drm_i915_private *dev_priv);
> void intel_power_domains_enable(struct drm_i915_private *dev_priv);
> void intel_power_domains_disable(struct drm_i915_private *dev_priv);
>
> diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.c
> b/drivers/gpu/drm/i915/intel_runtime_
Re: [Intel-gfx] [PATCH v2 3/5] drm/i915: Overcome display engine stride limits via GTT remapping
Quoting Ville Syrjala (2018-09-13 21:01:38)
> +static void
> +intel_plane_remap_gtt(struct intel_plane_state *plane_state)
> +{
> + struct drm_i915_private *dev_priv =
> + to_i915(plane_state->base.plane->dev);
> + struct drm_framebuffer *fb = plane_state->base.fb;
> + struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> + struct intel_rotation_info *info = &plane_state->view.rotated;
> + unsigned int rotation = plane_state->base.rotation;
> + int i, num_planes = fb->format->num_planes;
> + unsigned int tile_size = intel_tile_size(dev_priv);
> + unsigned int tile_width, tile_height;
> + unsigned int aligned_x, aligned_y;
> + unsigned int aligned_w, aligned_h;
> + unsigned int src_x, src_y;
> + unsigned int src_w, src_h;
> + unsigned int x, y;
> + u32 gtt_offset = 0;
> +
> + memset(&plane_state->view, 0, sizeof(plane_state->view));
> + plane_state->view.type = drm_rotation_90_or_270(rotation) ?
> + I915_GGTT_VIEW_ROTATED : I915_GGTT_VIEW_REMAPPED;
> +
> + src_x = plane_state->base.src.x1 >> 16;
> + src_y = plane_state->base.src.y1 >> 16;
> + src_w = drm_rect_width(&plane_state->base.src) >> 16;
> + src_h = drm_rect_height(&plane_state->base.src) >> 16;
Just doing a quick exercise to see if we might overflow later.
src_w/src_h are 15 bits (int 31 bits >> 16). So size is 30 bits and
total size of planes[2], 31 bits. (I'm assuming we go in and out of
pages.)
Did I miss anything? Should I be asking "what about the overflow?" :)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2) URL : https://patchwork.freedesktop.org/series/49654/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915/execlists: Delay updating ring register state after resume Okay! Commit: drm/i915/execlists: Use coherent writes into the context image -drivers/gpu/drm/i915/selftests/../i915_drv.h:3689:16: warning: expression using sizeof(void) +drivers/gpu/drm/i915/selftests/../i915_drv.h:3695:16: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 4/5] drm/i915: Bump gen4+ fb stride limit to 256KiB
Quoting Ville Syrjala (2018-09-13 21:01:39)
> From: Ville Syrjälä
>
> With gtt remapping plugged in we can simply raise the stride
> limit on gen4+. Let's just arbitraily pick 256 KiB as the limit.
>
> No remapping CCS because the virtual address of each page actually
> matters due to the new hash mode
> (WaCompressedResourceDisplayNewHashMode:skl,kbl etc.), and no remapping
> on gen2/3 due to lack of fence on the remapped vma.
>
> v2: Rebase due to is_ccs_modifier()
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/intel_display.c | 13 +
> 1 file changed, 13 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 93b0de594c5d..346572cf734a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2506,6 +2506,19 @@ static
> u32 intel_fb_max_stride(struct drm_i915_private *dev_priv,
> u32 pixel_format, u64 modifier)
> {
> + /*
> +* Arbitrary limit for gen4+. We can deal with any page
> +* aligned stride via GTT remapping. Gen2/3 need a fence
> +* for tiled scanout which the remapped vma won't have,
> +* so we don't allow remapping on those platforms.
> +*
> +* Also the new hash mode we use for CCS isn't compatible
> +* with remapping as the virtual address of the pages
> +* affects the compressed data.
> +*/
> + if (INTEL_GEN(dev_priv) >= 4 && !is_ccs_modifier(modifier))
> + return 256*1024;
If arbitrary, why 256k? Will we not go beyond 8 bytes per pixel in the
future? If you used U32_MAX then we will just reject v.large strides on
other grounds (too large for GTT, stride/size overflow).
Hmm, or is the 256k to keep the overflow checks simpler?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 2/5] drm/i915: Add a new "remapped" gtt_view
Quoting Ville Syrjala (2018-09-13 21:01:37)
> diff --git a/drivers/gpu/drm/i915/selftests/i915_vma.c
> b/drivers/gpu/drm/i915/selftests/i915_vma.c
> index ffa74290e054..4fc49c27f13c 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_vma.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_vma.c
> @@ -395,8 +395,8 @@ assert_rotated(struct drm_i915_gem_object *obj,
> return sg;
> }
>
> -static unsigned int rotated_size(const struct intel_rotation_plane_info *a,
> -const struct intel_rotation_plane_info *b)
> +static unsigned int rotated_size(const struct intel_remapped_plane_info *a,
> +const struct intel_remapped_plane_info *b)
> {
> return a->width * a->height + b->width * b->height;
> }
> @@ -406,7 +406,7 @@ static int igt_vma_rotate(void *arg)
> struct drm_i915_private *i915 = arg;
> struct i915_address_space *vm = &i915->ggtt.vm;
> struct drm_i915_gem_object *obj;
> - const struct intel_rotation_plane_info planes[] = {
> + const struct intel_remapped_plane_info planes[] = {
> { .width = 1, .height = 1, .stride = 1 },
> { .width = 2, .height = 2, .stride = 2 },
> { .width = 4, .height = 4, .stride = 4 },
Could we prove our remapping vma works by doing an i915_vma_pin_iomap()
and checking that a write into each page ends up in the correct address?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2)
== Series Details == Series: series starting with [1/2] drm/i915/execlists: Delay updating ring register state after resume (rev2) URL : https://patchwork.freedesktop.org/series/49654/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4819 -> Patchwork_10176 = == Summary - WARNING == Minor unknown changes coming with Patchwork_10176 need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_10176, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://patchwork.freedesktop.org/api/1.0/series/49654/revisions/2/mbox/ == Possible new issues == Here are the unknown changes that may have been introduced in Patchwork_10176: === IGT changes === Warnings igt@pm_rpm@module-reload: fi-hsw-4770r: PASS -> SKIP == Known issues == Here are the changes found in Patchwork_10176 that come from known issues: === IGT changes === Issues hit igt@drv_module_reload@basic-reload-inject: fi-hsw-4770r: PASS -> DMESG-WARN (fdo#107425, fdo#107924) igt@gem_exec_suspend@basic-s3: fi-blb-e6850: PASS -> INCOMPLETE (fdo#107718) igt@kms_psr@primary_page_flip: fi-cfl-s3: PASS -> FAIL (fdo#107336) fi-kbl-r: PASS -> FAIL (fdo#107336) Possible fixes igt@kms_frontbuffer_tracking@basic: fi-byt-clapper: FAIL (fdo#103167) -> PASS igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: fi-skl-6700k2: FAIL (fdo#103191) -> PASS igt@kms_psr@primary_page_flip: fi-whl-u: FAIL (fdo#107336) -> PASS fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107425 https://bugs.freedesktop.org/show_bug.cgi?id=107425 fdo#107718 https://bugs.freedesktop.org/show_bug.cgi?id=107718 fdo#107924 https://bugs.freedesktop.org/show_bug.cgi?id=107924 == Participating hosts (48 -> 45) == Additional (1): fi-icl-u Missing(4): fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4819 -> Patchwork_10176 CI_DRM_4819: 974889a04616f44de2f342dfdc9753b6dad8de88 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10176: 727e57a655b11345ea5681cf75a691d2440669c6 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 727e57a655b1 drm/i915/execlists: Use coherent writes into the context image de52a519af9f drm/i915/execlists: Delay updating ring register state after resume == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10176/issues.html ___ 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 1/2] lib: Require drmModeResources()
On Thu, 2018-09-13 at 14:24 +0100, Chris Wilson wrote: > If modesetting is not supported, the drmModeGetResources() call will > fail with -EINVAL (or -ENOTSUPP). As no displays are connected, skip. This one sounds better than the second patch to me. I just sent this patch together with other patch skiping the tests not handled by this one. Reviewed-by: José Roberto de Souza > > Signed-off-by: Chris Wilson > --- > lib/igt_kms.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/lib/igt_kms.c b/lib/igt_kms.c > index 3e0a07b98..0e6f91475 100644 > --- a/lib/igt_kms.c > +++ b/lib/igt_kms.c > @@ -1857,7 +1857,7 @@ void igt_display_init(igt_display_t *display, > int drm_fd) > display->drm_fd = drm_fd; > > resources = drmModeGetResources(display->drm_fd); > - igt_assert(resources); > + igt_require(resources); > > /* >* We cache the number of pipes, that number is a physical > limit of the ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: Enable DC9 as lowest possible state during screen-off (rev2)
== Series Details == Series: drm/i915/icl: Enable DC9 as lowest possible state during screen-off (rev2) URL : https://patchwork.freedesktop.org/series/49447/ State : success == Summary == = CI Bug Log - changes from CI_DRM_4819 -> Patchwork_10177 = == Summary - SUCCESS == No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/49447/revisions/2/mbox/ == Known issues == Here are the changes found in Patchwork_10177 that come from known issues: === IGT changes === Issues hit igt@gem_exec_suspend@basic-s3: fi-cfl-8109u: PASS -> DMESG-WARN (fdo#107345) +1 igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b: fi-cfl-8109u: PASS -> INCOMPLETE (fdo#106070) Possible fixes igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: fi-skl-6700k2: FAIL (fdo#103191) -> PASS igt@kms_psr@primary_page_flip: fi-whl-u: FAIL (fdo#107336) -> PASS fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#106070 https://bugs.freedesktop.org/show_bug.cgi?id=106070 fdo#107336 https://bugs.freedesktop.org/show_bug.cgi?id=107336 fdo#107345 https://bugs.freedesktop.org/show_bug.cgi?id=107345 == Participating hosts (48 -> 44) == Additional (1): fi-icl-u Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-hsw-4200u == Build changes == * Linux: CI_DRM_4819 -> Patchwork_10177 CI_DRM_4819: 974889a04616f44de2f342dfdc9753b6dad8de88 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4640: 9a8da36e708f9ed15b20689dfe305e41f9a19008 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_10177: 94673256d4f12daa56f9faf2a48c933fecfa2c33 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 94673256d4f1 drm/i915/icl: Enable DC9 as lowest possible state during screen-off == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_10177/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/nouveau: Disable atomic support on a per-device basis
Hm, one nitpick here. Since /sys/kernel/debug/dri/*/state creation depends on the driver supporting atomic, maybe it would be good to make it so that we set DRIVER_ATOMIC in the driver_stub structure, then disable it per-device depending on the nouveau_atomic setting + hw support. That way we can always have the state debugfs file while maintaining nouveau's current behavior with exposing atomic ioctls. Assuming that wouldn't have any unintended side-effects of course On Thu, 2018-09-13 at 19:31 +0300, Ville Syrjala wrote: > From: Ville Syrjälä > > We now have per-device driver_features, so let's use that > to disable atomic only for pre-nv50. > > Cc: Ben Skeggs > Cc: Lyude Paul > Cc: nouv...@lists.freedesktop.org > Cc: Daniel Vetter > Reviewed-by: Daniel Vetter > Suggested-by: Daniel Vetter > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/nouveau/dispnv04/disp.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/nouveau/dispnv04/disp.c > b/drivers/gpu/drm/nouveau/dispnv04/disp.c > index 70dce544984e..670535a68d3b 100644 > --- a/drivers/gpu/drm/nouveau/dispnv04/disp.c > +++ b/drivers/gpu/drm/nouveau/dispnv04/disp.c > @@ -56,7 +56,7 @@ nv04_display_create(struct drm_device *dev) > nouveau_display(dev)->fini = nv04_display_fini; > > /* Pre-nv50 doesn't support atomic, so don't expose the ioctls */ > - dev->driver->driver_features &= ~DRIVER_ATOMIC; > + dev->driver_features &= ~DRIVER_ATOMIC; > > nouveau_hw_save_vga_fonts(dev, 1); > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: drm/i915: GTT remapping for display
== Series Details == Series: drm/i915: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/49663/ State : warning == Summary == $ dim checkpatch origin/drm-tip b24877977210 drm/i915: Decouple SKL stride units from intel_fb_stride_alignment() 7a895a3a3d0d drm/i915: Add a new "remapped" gtt_view -:190: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #190: FILE: drivers/gpu/drm/i915/i915_gem_gtt.h:193: + BUILD_BUG_ON(sizeof(struct intel_remapped_info) != 9*sizeof(unsigned int)); ^ total: 0 errors, 0 warnings, 1 checks, 248 lines checked 018b3a571a49 drm/i915: Overcome display engine stride limits via GTT remapping 0a5360d29ad3 drm/i915: Bump gen4+ fb stride limit to 256KiB -:40: CHECK:SPACING: spaces preferred around that '*' (ctx:VxV) #40: FILE: drivers/gpu/drm/i915/intel_display.c:2520: + return 256*1024; ^ total: 0 errors, 0 warnings, 1 checks, 19 lines checked ddda39100946 drm/i915: Bump gen4+ fb size limits to 32kx32k ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: drm/i915: GTT remapping for display
== Series Details == Series: drm/i915: drm/i915: GTT remapping for display URL : https://patchwork.freedesktop.org/series/49663/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: Decouple SKL stride units from intel_fb_stride_alignment() Okay! Commit: drm/i915: Add a new "remapped" gtt_view +./include/linux/mm.h:592:13: error: not a function Commit: drm/i915: Overcome display engine stride limits via GTT remapping Okay! Commit: drm/i915: Bump gen4+ fb stride limit to 256KiB Okay! Commit: drm/i915: Bump gen4+ fb size limits to 32kx32k Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Mark up a couple of KMS debug messages as such
On Thu, Sep 13, 2018 at 02:16:26PM +0100, Chris Wilson wrote:
> For finding the panel fitter and PLL for a particular modeset is a part
> of that modeset and should be included with the reset of the
> DRM_DEBUG_KMS.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/intel_display.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7fbc006be44a..3be5fa0acee8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -6155,8 +6155,8 @@ static void i9xx_pfit_disable(struct intel_crtc *crtc)
>
> assert_pipe_disabled(dev_priv, crtc->pipe);
>
> - DRM_DEBUG_DRIVER("disabling pfit, current: 0x%08x\n",
> - I915_READ(PFIT_CONTROL));
> + DRM_DEBUG_KMS("disabling pfit, current: 0x%08x\n",
> + I915_READ(PFIT_CONTROL));
> I915_WRITE(PFIT_CONTROL, 0);
> }
>
> @@ -8678,8 +8678,8 @@ static int ironlake_crtc_compute_clock(struct
> intel_crtc *crtc,
> ironlake_compute_dpll(crtc, crtc_state, NULL);
>
> if (!intel_get_shared_dpll(crtc, crtc_state, NULL)) {
> - DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
> - pipe_name(crtc->pipe));
> + DRM_DEBUG_KMS("failed to find PLL for pipe %c\n",
> + pipe_name(crtc->pipe));
> return -EINVAL;
> }
>
> @@ -9246,8 +9246,8 @@ static int haswell_crtc_compute_clock(struct intel_crtc
> *crtc,
> intel_get_crtc_new_encoder(state, crtc_state);
>
> if (!intel_get_shared_dpll(crtc, crtc_state, encoder)) {
> - DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
> - pipe_name(crtc->pipe));
> + DRM_DEBUG_KMS("failed to find PLL for pipe %c\n",
> + pipe_name(crtc->pipe));
> return -EINVAL;
> }
> }
> --
> 2.19.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
