Re: [Intel-gfx] [PATCH] drm/i915: Allow set context SSEU on platforms after gen 11
On 18/09/2019 18:31, Stuart Summers wrote: Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110559 Unless there was some discussion I missed we can't just turn it on to work around a SKIP in IGT. Feature was deliberately limited to Icelake and even there just to a sub-set of possible configurations. Regards, Tvrtko Cc: Tvrtko Ursulin Signed-off-by: Stuart Summers --- drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c index f1c0e5d958f3..39af4c81b29a 100644 --- a/drivers/gpu/drm/i915/gem/i915_gem_context.c +++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c @@ -1310,7 +1310,7 @@ static int set_sseu(struct i915_gem_context *ctx, if (args->size < sizeof(user_sseu)) return -EINVAL; - if (!IS_GEN(i915, 11)) + if (INTEL_GEN(i915) < 11) return -ENODEV; if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value), ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Fix S0ix/S3 suspend stress issue
-Original Message-
From: Souza, Jose
Sent: Wednesday, September 18, 2019 11:14 PM
To: Singh, Gaurav K ; intel-gfx@lists.freedesktop.org
Subject: Re: [Intel-gfx] [PATCH] drm/i915: Fix S0ix/S3 suspend stress issue
On Wed, 2019-09-18 at 11:23 +0530, Gaurav K Singh wrote:
> During S0ix/S3 suspend stress test on Cometlake chromebook, after few
> iterations we are seeing failure wrt PSR link CRC Error and stress
> test stops. This S0ix test is failing only when there is a CRC
> mismatch. In case of CRC mismatch, panel generates IRQ_HD and whenever
> there is CRC mismatch, we are disabling PSR2 in driver.
>
> By not disabling PSR2 in driver and only by writing 1 to clear sticky
> bit 0 in DPCD 0x2006 in panel,issue goes away.
> Completed 2500 S0ix/S3 test cycles on multiple CML chromebooks.
>
> As per EDP spec for CRC mismatch, nothing has been mentioned
> explicitly for Source device, only by writing 1 to clear sticky bit 0
> in DPCD 0x2006 in sink is mentioned.
>
> Signed-off-by: Gaurav K Singh
> ---
> drivers/gpu/drm/i915/display/intel_psr.c | 6 +-
> 1 file changed, 1 insertion(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
> b/drivers/gpu/drm/i915/display/intel_psr.c
> index b3c7eef53bf3..502e29dbbea9 100644
> --- a/drivers/gpu/drm/i915/display/intel_psr.c
> +++ b/drivers/gpu/drm/i915/display/intel_psr.c
> @@ -1325,15 +1325,11 @@ void intel_psr_short_pulse(struct intel_dp
> *intel_dp)
> if (val & DP_PSR_VSC_SDP_UNCORRECTABLE_ERROR)
> DRM_DEBUG_KMS("PSR VSC SDP uncorrectable error, disabling
> PSR\n");
> if (val & DP_PSR_LINK_CRC_ERROR)
> - DRM_ERROR("PSR Link CRC error, disabling PSR\n");
> + DRM_DEBUG_KMS("PSR Link CRC error, clearing PSR error
> status DPCD\n");
>
> if (val & ~errors)
> DRM_ERROR("PSR_ERROR_STATUS unhandled errors %x\n",
> val & ~errors);
> - if (val & errors) {
> - intel_psr_disable_locked(intel_dp);
> - psr->sink_not_reliable = true;
> - }
With this change you are breaking CRC and all the other error handling.
If CRC did not match, it means the image that was received by sink do not match
the expected, it could happen because of problems on sink, source or flat cable.
It is better have perfect frames than save power, so this is not acceptable.
Thanks Jose for your comments. There is issue with my thunderbird, using
outlook for the reply.
We do not see any such CRC issue on Innolux PSR2 panel but seeing only on AUO
PSR2 panel. Now since this issue can happen because of problems on sink, source
or flat cable, I see this as expected behavior from driver side. Please
comment.
With regards,
Gaurav
> /* clear status register */
> drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_ERROR_STATUS, val);
> exit:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
Would the following be appropriate fix?
if (connector || connector->base.status == connector_status_connected) {
ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
if (ret) {
DRM_ERROR("failed to update payload %d\n", ret);
}
}
Regards,
-Original Message-
From: dri-devel On Behalf Of Manasi
Navare
Sent: Wednesday, September 18, 2019 11:55 PM
To: Ville Syrjälä
Cc: S, Srinivasan ; intel-gfx@lists.freedesktop.org;
dri-de...@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
On Wed, Sep 18, 2019 at 09:11:36PM +0300, Ville Syrjälä wrote:
> On Wed, Sep 18, 2019 at 10:50:39AM -0700, Manasi Navare wrote:
> > On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
> > > From: Srinivasan S
> > >
> > > This patch avoids DP MST payload error message in dmesg, as it is
> > > trying to read the payload from the disconnected DP MST device.
> > > After the unplug the connector status is disconnected and we
> > > should not be looking for the payload and hence remove the error and
> > > throw the warning.
> > >
> > > This details can be found in:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=111632
> >
> > Please add this link as Bugzilla:
> > https://bugs.freedesktop.org/show_bug.cgi?id=111632 after the Sign
> > off statement
> >
> > >
> > > Signed-off-by: Srinivasan S
> > > ---
> > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++-
> > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > index eeeb3f933aa4..5b2278fdf675 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > @@ -215,7 +215,12 @@ static void intel_mst_disable_dp(struct
> > > intel_encoder *encoder,
> > >
> > > ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > > if (ret) {
> > > - DRM_ERROR("failed to update payload %d\n", ret);
> > > + if (!connector ||
> > > + connector->base.status != connector_status_connected) {
> > > + DRM_WARN("DP MST disconnect\n");
> >
> > May be adding this check before calling drm_dp_update_payload_part1() is a
> > better idea?
> > If the connector is disconnected, why update payload?
> >
> > Jani, Ville, thoughts?
>
> Or just convert it to a debug?
Sure that will work, but do we really want to update the payload if the
connector status is disconnected.
So shouldnt checking that before calling the function be a better fix?
Manasi
>
> >
> > Regards
> > Manasi
> >
> > > + } else {
> > > + DRM_ERROR("failed to update payload %d\n", ret);
> > > + }
> > > }
> > > if (old_crtc_state->has_audio)
> > > intel_audio_codec_disable(encoder,
> > > --
> > > 2.7.4
> > >
>
> --
> Ville Syrjälä
> Intel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
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
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Engine relative MMIO (rev8)
== Series Details ==
Series: drm/i915: Engine relative MMIO (rev8)
URL : https://patchwork.freedesktop.org/series/57117/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6917 -> Patchwork_14452
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14452 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14452, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14452:
### IGT changes ###
Possible regressions
* igt@gem_workarounds@basic-read:
- fi-icl-u3: [PASS][1] -> [FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@gem_workarou...@basic-read.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u3/igt@gem_workarou...@basic-read.html
- fi-icl-u2: [PASS][3] -> [FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u2/igt@gem_workarou...@basic-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u2/igt@gem_workarou...@basic-read.html
* igt@i915_selftest@live_workarounds:
- fi-icl-u3: [PASS][5] -> [DMESG-FAIL][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@i915_selftest@live_workarounds.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u3/igt@i915_selftest@live_workarounds.html
- fi-icl-u2: [PASS][7] -> [DMESG-FAIL][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u2/igt@i915_selftest@live_workarounds.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u2/igt@i915_selftest@live_workarounds.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_workarounds@basic-read:
- {fi-icl-u4}:[PASS][9] -> [FAIL][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u4/igt@gem_workarou...@basic-read.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u4/igt@gem_workarou...@basic-read.html
- {fi-icl-dsi}: [PASS][11] -> [FAIL][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-dsi/igt@gem_workarou...@basic-read.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-dsi/igt@gem_workarou...@basic-read.html
- {fi-icl-guc}: [PASS][13] -> [FAIL][14]
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-guc/igt@gem_workarou...@basic-read.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-guc/igt@gem_workarou...@basic-read.html
* igt@i915_selftest@live_workarounds:
- {fi-icl-dsi}: [PASS][15] -> [DMESG-FAIL][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-dsi/igt@i915_selftest@live_workarounds.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-dsi/igt@i915_selftest@live_workarounds.html
- {fi-icl-guc}: [PASS][17] -> [DMESG-FAIL][18]
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-guc/igt@i915_selftest@live_workarounds.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-guc/igt@i915_selftest@live_workarounds.html
Known issues
Here are the changes found in Patchwork_14452 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-read-write:
- fi-icl-u3: [PASS][19] -> [DMESG-WARN][20] ([fdo#107724])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@gem_mmap_...@basic-read-write.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u3/igt@gem_mmap_...@basic-read-write.html
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [INCOMPLETE][21] ([fdo#107718]) -> [PASS][22]
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][23] ([fdo#107724]) -> [PASS][24] +1
similar issue
[23]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[24]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14452/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
{name}: This element is suppressed. This means it is ignored when computing
Re: [Intel-gfx] [PATCH v2] drm/i915: fix SFC reset flow
Quoting Daniele Ceraolo Spurio (2019-09-19 02:53:30)
> Our assumption that the we can ask the HW to lock the SFC even if not
> currently in use does not match the HW commitment. The expectation from
> the HW is that SW will not try to lock the SFC if the engine is not
> using it and if we do that the behavior is undefined; on ICL the HW
> ends up to returning the ack and ignoring our lock request, but this is
> not guaranteed and we shouldn't expect it going forward.
>
> Also, failing to get the ack while the SFC is in use means that we can't
> cleanly reset it, so fail the engine reset in that scenario.
>
> v2: drop rmw change, keep the log as debug and handle failure (Chris),
> improve comments (Tvrtko).
>
> Reported-by: Owen Zhang
> Signed-off-by: Daniele Ceraolo Spurio
> Cc: Tvrtko Ursulin
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_reset.c | 51 +--
> 1 file changed, 33 insertions(+), 18 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
> b/drivers/gpu/drm/i915/gt/intel_reset.c
> index 8327220ac558..797cf50625cb 100644
> --- a/drivers/gpu/drm/i915/gt/intel_reset.c
> +++ b/drivers/gpu/drm/i915/gt/intel_reset.c
> @@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
> return gen6_hw_domain_reset(gt, hw_mask);
> }
>
> -static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
> +static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
> {
> struct intel_uncore *uncore = engine->uncore;
> u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
> @@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
> i915_reg_t sfc_usage;
> u32 sfc_usage_bit;
> u32 sfc_reset_bit;
> + int ret;
>
> switch (engine->class) {
> case VIDEO_DECODE_CLASS:
> @@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs
> *engine)
> }
>
> /*
> -* Tell the engine that a software reset is going to happen. The
> engine
> -* will then try to force lock the SFC (if currently locked, it will
> -* remain so until we tell the engine it is safe to unlock; if
> currently
> -* unlocked, it will ignore this and all new lock requests). If SFC
> -* ends up being locked to the engine we want to reset, we have to
> reset
> -* it as well (we will unlock it once the reset sequence is
> completed).
> +* If the engine is using a SFC, tell the engine that a software reset
> +* is going to happen. The engine will then try to force lock the SFC.
> +* If SFC ends up being locked to the engine we want to reset, we have
> +* to reset it as well (we will unlock it once the reset sequence is
> +* completed).
> */
> + if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
> + return 0;
> +
> rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
>
> - if (__intel_wait_for_register_fw(uncore,
> -sfc_forced_lock_ack,
> -sfc_forced_lock_ack_bit,
> -sfc_forced_lock_ack_bit,
> -1000, 0, NULL)) {
> - DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
> + ret = __intel_wait_for_register_fw(uncore,
> + sfc_forced_lock_ack,
> + sfc_forced_lock_ack_bit,
> + sfc_forced_lock_ack_bit,
> + 1000, 0, NULL);
> +
> + /* was the SFC released while we were trying to lock it? */
> + if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
> return 0;
> - }
>
> - if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
> - return sfc_reset_bit;
> + if (ret)
> + DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
This unnerves me as on the lock_sfc it would result in lots of full-gpu
resets. However, I do believe that we catch those fallbacks in our
selftests -- so the tests that were triggering the wait timeout must be
taking the earlier return for sfc_usage == 0
Not having per-engine reset is greatly upsetting; we are baking the
assumption we can reset engines & contexts independently into our system
management. We rely on it...
However, this passed on icl so it can't be all bad!
Acked-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.IGT: success for drm/i915: Allow set context SSEU on platforms after gen 11
== Series Details == Series: drm/i915: Allow set context SSEU on platforms after gen 11 URL : https://patchwork.freedesktop.org/series/66870/ State : success == Summary == CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14447_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14447_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +11 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb4/igt@gem_exec_sched...@independent-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-iclb7/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +10 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-iclb4/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl8/igt@gem_soft...@noreloc-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-apl3/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_rpm@debugfs-read: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl5/igt@i915_pm_...@debugfs-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-skl4/igt@i915_pm_...@debugfs-read.html * igt@kms_cursor_edge_walk@pipe-b-64x64-left-edge: - shard-apl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103927]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl2/igt@kms_cursor_edge_w...@pipe-b-64x64-left-edge.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-apl2/igt@kms_cursor_edge_w...@pipe-b-64x64-left-edge.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][11] -> [FAIL][12] ([fdo#103167]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [fdo#110403]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103166]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-y.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-iclb8/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_psr@psr2_basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-iclb7/igt@kms_psr@psr2_basic.html * igt@kms_setmode@basic: - shard-apl: [PASS][19] -> [FAIL][20] ([fdo#99912]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl4/igt@kms_setm...@basic.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-apl4/igt@kms_setm...@basic.html - shard-hsw: [PASS][21] -> [FAIL][22] ([fdo#99912]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw5/igt@kms_setm...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-hsw1/igt@kms_setm...@basic.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/shard-apl8/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [SKIP][25] ([fdo#110841]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb4/igt@gem
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Allow set context SSEU on platforms after gen 11
On 18/09/2019 23:28, Summers, Stuart wrote:
> On Wed, 2019-09-18 at 19:31 +, Patchwork wrote:
>> == Series Details ==
>>
>> Series: drm/i915: Allow set context SSEU on platforms after gen 11
>> URL : https://patchwork.freedesktop.org/series/66870/
>> State : success
>>
>> == Summary ==
>>
>> CI Bug Log - changes from CI_DRM_6917 -> Patchwork_14447
>>
>>
>> Summary
>> ---
>>
>> **SUCCESS**
>>
>> No regressions found.
>>
>> External URL:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/
>>
>> Known issues
>>
>>
>> Here are the changes found in Patchwork_14447 that come from known
>> issues:
>>
>> ### IGT changes ###
>>
>> Issues hit
>>
>> * igt@debugfs_test@read_all_entries:
>> - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
>> +1 similar issue
>>[1]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@debugfs_test@read_all_entries.html
>>[2]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-icl-u3/igt@debugfs_test@read_all_entries.html
>>
>> * igt@i915_module_load@reload:
>> - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]
>> / [fdo#111214])
>>[3]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@i915_module_l...@reload.html
>>[4]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-icl-u3/igt@i915_module_l...@reload.html
>>
>> * igt@i915_selftest@live_hangcheck:
>> - fi-icl-u3: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]
>> / [fdo#108569])
>>[5]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
>>[6]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-icl-u3/igt@i915_selftest@live_hangcheck.html
>>
>> * igt@kms_chamelium@dp-edid-read:
>> - fi-icl-u2: [PASS][7] -> [FAIL][8] ([fdo#109483] /
>> [fdo#109635 ])
>>[7]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
>>[8]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-icl-u2/igt@kms_chamel...@dp-edid-read.html
>>
>> * igt@kms_frontbuffer_tracking@basic:
>> - fi-icl-u2: [PASS][9] -> [FAIL][10] ([fdo#103167])
>>[9]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
>>[10]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
>>
>>
>> Possible fixes
>>
>> * igt@gem_ctx_create@basic-files:
>> - {fi-tgl-u}: [INCOMPLETE][11] ([fdo#111735]) ->
>> [PASS][12]
>>[11]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html
>>[12]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-tgl-u/igt@gem_ctx_cre...@basic-files.html
>>
>> * igt@gem_exec_suspend@basic-s3:
>> - fi-blb-e6850: [INCOMPLETE][13] ([fdo#107718]) ->
>> [PASS][14]
>>[13]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
>>[14]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
>>
>> * igt@gem_mmap_gtt@basic-write-no-prefault:
>> - fi-icl-u3: [DMESG-WARN][15] ([fdo#107724]) ->
>> [PASS][16] +1 similar issue
>>[15]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
>>[16]:
>> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14447/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
>>
>>
>> {name}: This element is suppressed. This means it is ignored when
>> computing
>> the status of the difference (SUCCESS, WARNING, or
>> FAILURE).
>>
>> [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
>> [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
>> [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
>> [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
>> [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
>> [fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
>> [fdo#109635 ]: https://bugs.freedesktop.org/show_bug.cgi?id=109635
>> [fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
>> [fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
>>
>>
>> Participating hosts (53 -> 47)
>> --
>>
>> Additional (1): fi-bxt-dsi
>> Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
>> fi-icl-y fi-byt-clapper fi-bdw-samus
>
> Hi Martin,
>
> Is there an easy way to tell if these missing machines are a result of
> changes made to the patches here vs something else in the test
> infrastructure?
Thanks for asking!
Sometimes, some machines fail to boot for reasons unre
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Don't advertise modes that exceed the max plane size
Op 18-09-2019 om 17:07 schreef Ville Syrjala: > From: Ville Syrjälä > > Modern platforms allow the transcoders hdisplay/vdisplay to exceed the > planes' max resolution. This has the nasty implication that modes on the > connectors' mode list may not be usable when the user asks for a > fullscreen plane. Seeing as that is the most common use case it seems > prudent to filter out modes that don't allow for fullscreen planes to > be enabled. > > Let's do that in the connetor .mode_valid() hook so that normally > such modes are kept hidden but the user is still able to forcibly > specify such a mode if they know they don't need fullscreen planes. > > This is in line with ealier policies regarding certain clock limits. > The idea is to prevent the casual user from encountering a mode that > would fail under typical conditions, but allow the expert user to > force things if they so wish. > > Maybe in the future we should consider automagically using two > planes when one can't cover the entire screen? Wouldn't be a > great match for the current uapi with explicit planes though, > but I guess no worse than using two pipes (which we apparently > have to in the future anyway). Either that or we'd have to > teach userspace to do it for us. In theory this is what bigjoiner is doing, except the planes are on a different pipe. Will be fun with SDR vs HDR planes though.. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: fix SFC reset flow
On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Also, failing to get the ack while the SFC is in use means that we can't
cleanly reset it, so fail the engine reset in that scenario.
v2: drop rmw change, keep the log as debug and handle failure (Chris),
improve comments (Tvrtko).
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 51 +--
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 8327220ac558..797cf50625cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
return gen6_hw_domain_reset(gt, hw_mask);
}
-static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
+static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
{
struct intel_uncore *uncore = engine->uncore;
u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
@@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
i915_reg_t sfc_usage;
u32 sfc_usage_bit;
u32 sfc_reset_bit;
+ int ret;
switch (engine->class) {
case VIDEO_DECODE_CLASS:
@@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
}
/*
-* Tell the engine that a software reset is going to happen. The engine
-* will then try to force lock the SFC (if currently locked, it will
-* remain so until we tell the engine it is safe to unlock; if currently
-* unlocked, it will ignore this and all new lock requests). If SFC
-* ends up being locked to the engine we want to reset, we have to reset
-* it as well (we will unlock it once the reset sequence is completed).
+* If the engine is using a SFC, tell the engine that a software reset
+* is going to happen. The engine will then try to force lock the SFC.
+* If SFC ends up being locked to the engine we want to reset, we have
+* to reset it as well (we will unlock it once the reset sequence is
+* completed).
*/
+ if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
+ return 0;
+
rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
- if (__intel_wait_for_register_fw(uncore,
-sfc_forced_lock_ack,
-sfc_forced_lock_ack_bit,
-sfc_forced_lock_ack_bit,
-1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ ret = __intel_wait_for_register_fw(uncore,
+ sfc_forced_lock_ack,
+ sfc_forced_lock_ack_bit,
+ sfc_forced_lock_ack_bit,
+ 1000, 0, NULL);
+
+ /* was the SFC released while we were trying to lock it? */
+ if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
return 0;
- }
- if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
- return sfc_reset_bit;
+ if (ret)
+ DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ else
+ *hw_mask |= sfc_reset_bit;
- return 0;
+ return ret;
}
static void gen11_unlock_sfc(struct intel_engine_cs *engine)
@@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
hw_mask |= hw_engine_mask[engine->id];
- hw_mask |= gen11_lock_sfc(engine);
+ ret = gen11_lock_sfc(engine, &hw_mask);
+ if (ret)
+ goto sfc_unlock;
Break on first failure looks unsafe to me. I think it would be more
robust to continue, no? Like if we have been asked to reset multiple
engines and only one failed, why not do the ones we can?
}
}
ret = gen6_hw_domain_reset(gt, hw_mask);
+sfc_unlock:
+ /*
+* we unlock the SFC based on the lock status and not the result of
+* gen11_
Re: [Intel-gfx] [PATCH v2] drm/i915: fix SFC reset flow
Quoting Tvrtko Ursulin (2019-09-19 10:34:15)
>
> On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
> > Our assumption that the we can ask the HW to lock the SFC even if not
> > currently in use does not match the HW commitment. The expectation from
> > the HW is that SW will not try to lock the SFC if the engine is not
> > using it and if we do that the behavior is undefined; on ICL the HW
> > ends up to returning the ack and ignoring our lock request, but this is
> > not guaranteed and we shouldn't expect it going forward.
> >
> > Also, failing to get the ack while the SFC is in use means that we can't
> > cleanly reset it, so fail the engine reset in that scenario.
> >
> > v2: drop rmw change, keep the log as debug and handle failure (Chris),
> > improve comments (Tvrtko).
> >
> > Reported-by: Owen Zhang
> > Signed-off-by: Daniele Ceraolo Spurio
> > Cc: Tvrtko Ursulin
> > Cc: Chris Wilson
> > ---
> > static void gen11_unlock_sfc(struct intel_engine_cs *engine)
> > @@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
> > for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
> > GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
> > hw_mask |= hw_engine_mask[engine->id];
> > - hw_mask |= gen11_lock_sfc(engine);
> > + ret = gen11_lock_sfc(engine, &hw_mask);
> > + if (ret)
> > + goto sfc_unlock;
>
> Break on first failure looks unsafe to me. I think it would be more
> robust to continue, no? Like if we have been asked to reset multiple
> engines and only one failed, why not do the ones we can?
Any failure means a fallback to a full device reset. It doesn't matter
if we could reset one of two+ engines at that point, it's past the point
of no return.
> > ret = gen6_hw_domain_reset(gt, hw_mask);
> >
> > +sfc_unlock:
> > + /*
> > + * we unlock the SFC based on the lock status and not the result of
> > + * gen11_lock_sfc to make sure that we clean properly if something
> > + * wrong happened during the lock (e.g. lock acquired after timeout
> > + * expiration).
> > + */
> > if (engine_mask != ALL_ENGINES)
> > for_each_engine_masked(engine, gt->i915, engine_mask, tmp)
> > gen11_unlock_sfc(engine);
> >
>
> So you decided not to read the register and cross check?
Very meh, that check didn't seem like it would improve our ability to
handle resets. If you wanted to actually check, we should check the
lock_ack_bit is cleared as well. (Or at least check that is clear before
we start the next lock_sfc().) I think skipping an unnecessary
gen11_lock_sfc() is a solid improvement by itself (I'm hopeful that's
enough to make icl more robust...). Tightening up the unlock can be done
separately.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: fix SFC reset flow
On 19/09/2019 10:34, Tvrtko Ursulin wrote:
On 19/09/2019 02:53, Daniele Ceraolo Spurio wrote:
Our assumption that the we can ask the HW to lock the SFC even if not
currently in use does not match the HW commitment. The expectation from
the HW is that SW will not try to lock the SFC if the engine is not
using it and if we do that the behavior is undefined; on ICL the HW
ends up to returning the ack and ignoring our lock request, but this is
not guaranteed and we shouldn't expect it going forward.
Also, failing to get the ack while the SFC is in use means that we can't
cleanly reset it, so fail the engine reset in that scenario.
v2: drop rmw change, keep the log as debug and handle failure (Chris),
improve comments (Tvrtko).
Reported-by: Owen Zhang
Signed-off-by: Daniele Ceraolo Spurio
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 51 +--
1 file changed, 33 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index 8327220ac558..797cf50625cb 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -309,7 +309,7 @@ static int gen6_reset_engines(struct intel_gt *gt,
return gen6_hw_domain_reset(gt, hw_mask);
}
-static u32 gen11_lock_sfc(struct intel_engine_cs *engine)
+static int gen11_lock_sfc(struct intel_engine_cs *engine, u32 *hw_mask)
{
struct intel_uncore *uncore = engine->uncore;
u8 vdbox_sfc_access = RUNTIME_INFO(engine->i915)->vdbox_sfc_access;
@@ -318,6 +318,7 @@ static u32 gen11_lock_sfc(struct intel_engine_cs
*engine)
i915_reg_t sfc_usage;
u32 sfc_usage_bit;
u32 sfc_reset_bit;
+ int ret;
switch (engine->class) {
case VIDEO_DECODE_CLASS:
@@ -352,28 +353,33 @@ static u32 gen11_lock_sfc(struct intel_engine_cs
*engine)
}
/*
- * Tell the engine that a software reset is going to happen. The
engine
- * will then try to force lock the SFC (if currently locked, it will
- * remain so until we tell the engine it is safe to unlock; if
currently
- * unlocked, it will ignore this and all new lock requests). If SFC
- * ends up being locked to the engine we want to reset, we have
to reset
- * it as well (we will unlock it once the reset sequence is
completed).
+ * If the engine is using a SFC, tell the engine that a software
reset
+ * is going to happen. The engine will then try to force lock the
SFC.
+ * If SFC ends up being locked to the engine we want to reset, we
have
+ * to reset it as well (we will unlock it once the reset sequence is
+ * completed).
*/
+ if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
+ return 0;
+
rmw_set_fw(uncore, sfc_forced_lock, sfc_forced_lock_bit);
- if (__intel_wait_for_register_fw(uncore,
- sfc_forced_lock_ack,
- sfc_forced_lock_ack_bit,
- sfc_forced_lock_ack_bit,
- 1000, 0, NULL)) {
- DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ ret = __intel_wait_for_register_fw(uncore,
+ sfc_forced_lock_ack,
+ sfc_forced_lock_ack_bit,
+ sfc_forced_lock_ack_bit,
+ 1000, 0, NULL);
+
+ /* was the SFC released while we were trying to lock it? */
+ if (!(intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit))
return 0;
- }
- if (intel_uncore_read_fw(uncore, sfc_usage) & sfc_usage_bit)
- return sfc_reset_bit;
+ if (ret)
+ DRM_DEBUG_DRIVER("Wait for SFC forced lock ack failed\n");
+ else
+ *hw_mask |= sfc_reset_bit;
- return 0;
+ return ret;
}
static void gen11_unlock_sfc(struct intel_engine_cs *engine)
@@ -430,12 +436,21 @@ static int gen11_reset_engines(struct intel_gt *gt,
for_each_engine_masked(engine, gt->i915, engine_mask, tmp) {
GEM_BUG_ON(engine->id >= ARRAY_SIZE(hw_engine_mask));
hw_mask |= hw_engine_mask[engine->id];
- hw_mask |= gen11_lock_sfc(engine);
+ ret = gen11_lock_sfc(engine, &hw_mask);
+ if (ret)
+ goto sfc_unlock;
Break on first failure looks unsafe to me. I think it would be more
robust to continue, no? Like if we have been asked to reset multiple
engines and only one failed, why not do the ones we can?
Chris corrected me on IRC explaining that as longs as we fail to reset
one engine from engine_mask we fall back to full reset anyway. So this
early return is immaterial to end behavior and I have no further
complaints. :)
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
}
}
ret = gen6_hw_domain_reset(gt, hw_mask);
+sfc_unlock:
+ /*
+ * we unlock the SFC based on the lock status and not the result of
+ * gen11_lock_sfc to make sure that we clean properly
Re: [Intel-gfx] [PATCH 1/4] drm/i915: Verify the engine after acquiring the active.lock
On 18/09/2019 15:54, Chris Wilson wrote:
When using virtual engines, the rq->engine is not stable until we hold
the engine->active.lock (as the virtual engine may be exchanged with the
sibling). Since commit 22b7a426bbe1 ("drm/i915/execlists: Preempt-to-busy")
we may retire a request concurrently with resubmitting it to HW, we need
to be extra careful to verify we are holding the correct lock for the
request's active list. This is similar to the issue we saw with
rescheduling the virtual requests, see sched_lock_engine().
Or else:
<4> [876.736126] list_add corruption. prev->next should be next
(8883f931a1f8), but was dead0100. (prev=888361ffa610).
<4> [876.736136] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [876.736137] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether usbnet mii
snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth
ecdh_generic ecc [last unloaded: i915]
<4> [876.736154] CPU: 2 PID: 21 Comm: ksoftirqd/2 Tainted: G U
5.3.0-CI-CI_DRM_6898+ #1
<4> [876.736156] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411
05/02/2019
<4> [876.736157] RIP: 0010:__list_add_valid+0x4d/0x70
<4> [876.736159] Code: c3 48 89 d1 48 c7 c7 20 33 0e 82 48 89 c2 e8 4a 4a bc ff 0f 0b
31 c0 c3 48 89 c1 4c 89 c6 48 c7 c7 70 33 0e 82 e8 33 4a bc ff <0f> 0b 31 c0 c3 48 89
f2 4c 89 c1 48 89 fe 48 c7 c7 c0 33 0e 82 e8
<4> [876.736160] RSP: 0018:c918bd30 EFLAGS: 00010082
<4> [876.736162] RAX: RBX: 888361ffc840 RCX:
0104
<4> [876.736163] RDX: 8104 RSI: RDI:
<4> [876.736164] RBP: c918bd68 R08: R09:
0001
<4> [876.736165] R10: aed95de3 R11: 7fe927eb R12:
888361ffca10
<4> [876.736166] R13: 888361ffa610 R14: 888361ffc880 R15:
8883f931a1f8
<4> [876.736168] FS: () GS:88849fd0()
knlGS:
<4> [876.736169] CS: 0010 DS: ES: CR0: 80050033
<4> [876.736170] CR2: 7f093a9173c0 CR3: 0003bba08005 CR4:
00760ee0
<4> [876.736171] PKRU: 5554
<4> [876.736172] Call Trace:
<4> [876.736226] __i915_request_submit+0x152/0x370 [i915]
<4> [876.736263] __execlists_submission_tasklet+0x6da/0x1f50 [i915]
<4> [876.736293] ? execlists_submission_tasklet+0x29/0x50 [i915]
<4> [876.736321] execlists_submission_tasklet+0x34/0x50 [i915]
<4> [876.736325] tasklet_action_common.isra.5+0x47/0xb0
<4> [876.736328] __do_softirq+0xd8/0x4ae
<4> [876.736332] ? smpboot_thread_fn+0x23/0x280
<4> [876.736334] ? smpboot_thread_fn+0x6b/0x280
<4> [876.736336] run_ksoftirqd+0x2b/0x50
<4> [876.736338] smpboot_thread_fn+0x1d3/0x280
<4> [876.736341] ? sort_range+0x20/0x20
<4> [876.736343] kthread+0x119/0x130
<4> [876.736345] ? kthread_park+0xa0/0xa0
<4> [876.736347] ret_from_fork+0x24/0x50
<4> [876.736353] irq event stamp: 2290145
<4> [876.736356] hardirqs last enabled at (2290144): []
__slab_free+0x3e8/0x500
<4> [876.736358] hardirqs last disabled at (2290145): []
_raw_spin_lock_irqsave+0xd/0x50
<4> [876.736360] softirqs last enabled at (2290114): []
__do_softirq+0x33e/0x4ae
<4> [876.736361] softirqs last disabled at (2290119): []
run_ksoftirqd+0x2b/0x50
<4> [876.736363] WARNING: CPU: 2 PID: 21 at lib/list_debug.c:28
__list_add_valid+0x4d/0x70
<4> [876.736364] ---[ end trace 3e58d6c7356c65bf ]---
<4> [876.736406] [ cut here ]
<4> [876.736415] list_del corruption. prev->next should be 888361ffca10,
but was 88840ac2c730
<4> [876.736421] WARNING: CPU: 2 PID: 5490 at lib/list_debug.c:53
__list_del_entry_valid+0x79/0x90
<4> [876.736422] Modules linked in: i915(+) amdgpu gpu_sched ttm vgem
snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic mei_hdcp
x86_pkg_temp_thermal coretemp crct10dif_pclmul crc32_pclmul snd_intel_nhlt
snd_hda_codec snd_hwdep snd_hda_core ghash_clmulni_intel e1000e cdc_ether usbnet mii
snd_pcm ptp pps_core mei_me mei prime_numbers btusb btrtl btbcm btintel bluetooth
ecdh_generic ecc [last unloaded: i915]
<4> [876.736433] CPU: 2 PID: 5490 Comm: i915_selftest Tainted: G U W
5.3.0-CI-CI_DRM_6898+ #1
<4> [876.736435] Hardware name: Intel Corporation Ice Lake Client
Platform/IceLake U DDR4 SODIMM PD RVP TLC, BIOS ICLSFWR1.R00.3183.A00.1905020411
05/02/2019
<4> [876.736436] RIP: 0010:__list_del_entry_valid+0x79/0x90
<4> [876.736438] Code: 0b 31 c0 c3 48 89 fe 48 c7 c7 30 34 0e 82 e8 ae 49 bc ff 0f 0b
31 c0 c3 48 89 f2 48 89 fe 48 c7 c7 68 34 0e 82 e8 97 49 bc ff <0f> 0b 31 c0 c3 48 c7
c7 a8 34 0e 82 e8 86 49 bc ff 0f 0b 31 c0 c3
<4> [876.7
Re: [Intel-gfx] [PATCH 3/4] drm/i915: Lock signaler timeline while navigating
On 18/09/2019 15:54, Chris Wilson wrote:
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
v2: Tvrtko made me realise I was being lax and using annotations to
ignore the AB-BA deadlock from the timeline overlap. As it would be
possible to construct a second request that was using a semaphore from the
same timeline as ourselves, we could quite easily end up in a situation
where we deadlocked in our mutex waits. Avoid that by using a trylock
and falling back to a normal dma-fence await if contended.
v3: Eek, the signal->timeline is volatile and must be carefully
dereferenced to ensure it is valid.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin #v2
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
---
drivers/gpu/drm/i915/i915_request.c | 68 +++--
1 file changed, 46 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index fb6f21c41934..9bd8538b1907 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -768,17 +768,43 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
{
- if (list_is_first(&signal->link, &signal->timeline->requests))
- return 0;
+ struct intel_timeline *tl;
+ struct dma_fence *fence;
+ int err;
+
+ GEM_BUG_ON(i915_request_timeline(rq) ==
+ rcu_access_pointer(signal->timeline));
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(i915_request_timeline(rq),
-&signal->fence))
+ rcu_read_lock();
+ tl = rcu_dereference(signal->timeline);
+ if (i915_request_started(signal) || !kref_get_unless_zero(&tl->kref))
+ tl = NULL;
+ rcu_read_unlock();
+ if (!tl) /* already started or maybe even completed */
return 0;
- return i915_sw_fence_await_dma_fence(&rq->submit,
-&signal->fence, 0,
-I915_FENCE_GFP);
+ fence = ERR_PTR(-EBUSY);
+ if (mutex_trylock(&tl->mutex)) {
+ fence = NULL;
+ if (!i915_request_started(signal) &&
+ !list_is_first(&signal->link, &tl->requests)) {
+ signal = list_prev_entry(signal, link);
+ fence = dma_fence_get(&signal->fence);
+ }
+ mutex_unlock(&tl->mutex);
+ }
+ intel_timeline_put(tl);
+ if (IS_ERR_OR_NULL(fence))
+ return PTR_ERR_OR_ZERO(fence);
+
+ err = 0;
+ if (intel_timeline_sync_is_later(i915_request_timeline(rq), fence))
+ err = i915_sw_fence_await_dma_fence(&rq->submit,
+ fence, 0,
+ I915_FENCE_GFP);
+ dma_fence_put(fence);
+
+ return err;
}
static intel_engine_mask_t
@@ -808,30 +834,23 @@ emit_semaphore_wait(struct i915_request *to,
u32 hwsp_offset;
int len;
u32 *cs;
- int err;
- GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
/* Just emit the first semaphore we see as request space is limited. */
if (already_busywaiting(to) & from->engine->mask)
- return i915_sw_fence_await_dma_fence(&to->submit,
-&from->fence, 0,
-I915_FENCE_GFP);
+ goto await_fence;
- err = i915_request_await_start(to, from);
- if (err < 0)
- return err;
+ if (i915_request_await_start(to, from) < 0)
+ goto await_fence;
/* Only submit our spinner after the signaler is running! */
- err = __i915_request_await_execution(to, from, NULL, gfp);
- if (err)
- return err;
+ if (__i915_request_await_execution(to, from, NULL, gfp))
+ goto await_fence;
/* We need to pin the signaler's HWSP until we are finished reading. */
- err = intel_timeline_read_hwsp(from, to, &hwsp_offset);
- if (err)
- return err;
+ if (intel_timeline_read_hwsp(from, to, &hwsp_offset))
+ goto await_fence;
len = 4;
if (has_token)
@@ -866,6 +885,11 @@ emit_semaphore_wait(struct i915_request *to,
to->sched.semaphores |= from->engine->mask;
to->sch
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Protect timeline->hwsp dereferencing
On 18/09/2019 15:54, Chris Wilson wrote:
As not only is the signal->timeline volatile, so will be acquiring the
timeline's HWSP. We must first carefully acquire the timeline from the
signaling request and then lock the timeline. With the removal of the
struct_mutex serialisation of request construction, we can have multiple
timelines active at once, and so we must avoid using the nested mutex
lock as it is quite possible for both timelines to be establishing
semaphores on the other and so deadlock.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 32 ++--
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 2ce81bdf7f86..7b1d4098dd2e 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -500,17 +500,32 @@ int intel_timeline_read_hwsp(struct i915_request *from,
struct i915_request *to,
u32 *hwsp)
{
- struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
- struct intel_timeline *tl = from->timeline;
I think this should have been annotated in 2/4.
+ struct intel_timeline *tl;
int err;
+ rcu_read_lock();
+ tl = rcu_dereference(from->timeline);
+ if (i915_request_completed(from) || !kref_get_unless_zero(&tl->kref))
+ tl = NULL;
+ rcu_read_unlock();
+ if (!tl) /* already completed */
+ return 1;
+
GEM_BUG_ON(rcu_access_pointer(to->timeline) == tl);
- mutex_lock_nested(&tl->mutex, SINGLE_DEPTH_NESTING);
- err = i915_request_completed(from);
- if (!err)
+ err = -EBUSY;
+ if (mutex_trylock(&tl->mutex)) {
+ struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
+
+ if (i915_request_completed(from)) {
+ err = 1;
+ goto unlock;
+ }
+
err = cacheline_ref(cl, to);
- if (!err) {
+ if (err)
+ goto unlock;
+
if (likely(cl == tl->hwsp_cacheline)) {
*hwsp = tl->hwsp_offset;
} else { /* across a seqno wrap, recover the original offset */
@@ -518,8 +533,11 @@ int intel_timeline_read_hwsp(struct i915_request *from,
ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) *
CACHELINE_BYTES;
}
+
+unlock:
+ mutex_unlock(&tl->mutex);
}
- mutex_unlock(&tl->mutex);
+ intel_timeline_put(tl);
return err;
}
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] [PATCH] Docs: fix incorrect use of kernel-doc format in structure description.
Insert structure members names into their descriptions to follow
kernel-doc format
Signed-off-by: Anna Karas
---
drivers/gpu/drm/i915/i915_drv.h | 26 ++
1 file changed, 14 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 0d1949a78c44..dc6c9f52d3a5 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1225,7 +1225,7 @@ struct i915_perf_stream {
struct i915_oa_config *oa_config;
/**
-* The OA context specific information.
+* @pinned_ctx: The OA context specific information.
*/
struct intel_context *pinned_ctx;
u32 specific_ctx_id;
@@ -1239,7 +1239,7 @@ struct i915_perf_stream {
int period_exponent;
/**
-* State of the OA buffer.
+* @oa_buffer: State of the OA buffer.
*/
struct {
struct i915_vma *vma;
@@ -1250,7 +1250,7 @@ struct i915_perf_stream {
int size_exponent;
/**
-* Locks reads and writes to all head/tail state
+* @ptr_lock: Locks reads and writes to all head/tail state
*
* Consider: the head and tail pointer state needs to be read
* consistently from a hrtimer callback (atomic context) and
@@ -1272,8 +1272,8 @@ struct i915_perf_stream {
spinlock_t ptr_lock;
/**
-* One 'aging' tail pointer and one 'aged' tail pointer ready to
-* used for reading.
+* @tails: One 'aging' tail pointer and one 'aged' tail pointer
+* ready to used for reading.
*
* Initial values of 0x are invalid and imply that an
* update is required (and should be ignored by an attempted
@@ -1284,21 +1284,23 @@ struct i915_perf_stream {
} tails[2];
/**
-* Index for the aged tail ready to read() data up to.
+* @aged_tail_idx: Index for the aged tail ready to read() data
+* up to.
*/
unsigned int aged_tail_idx;
/**
-* A monotonic timestamp for when the current aging tail pointer
-* was read; used to determine when it is old enough to trust.
+* @aging_timestamp: A monotonic timestamp for when the current
+* aging tail pointer was read; used to determine when it is old
+* enough to trust.
*/
u64 aging_timestamp;
/**
-* Although we can always read back the head pointer register,
-* we prefer to avoid trusting the HW state, just to avoid any
-* risk that some hardware condition could * somehow bump the
-* head pointer unpredictably and cause us to forward the wrong
+* @head: Although we can always read back the head pointer
+* register, we prefer to avoid trusting the HW state, just to
+* avoid any risk that some hardware condition could somehow
bump
+* the head pointer unpredictably and cause us to forward the
wrong
* OA buffer data to userspace.
*/
u32 head;
--
2.19.0
-
Intel Finland Oy
Registered Address: PL 281, 00181 Helsinki
Business Identity Code: 0357606 - 4
Domiciled in Helsinki
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Docs: fix incorrect use of kernel-doc format in structure description.
Quoting Anna Karas (2019-09-19 11:49:28) > Insert structure members names into their descriptions to follow > kernel-doc format > > Signed-off-by: Anna Karas Lgtm, Reviewed-by: Chris Wilson > - > Intel Finland Oy > Registered Address: PL 281, 00181 Helsinki > Business Identity Code: 0357606 - 4 > Domiciled in Helsinki > > This e-mail and any attachments may contain confidential material for > the sole use of the intended recipient(s). Any review or distribution > by others is strictly prohibited. If you are not the intended > recipient, please contact the sender and delete all copies. We'll need to strip this disclaimer off for inclusion though :) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/19] drm/i915: Make .modeset_calc_cdclk() mandatory
Op 08-07-2019 om 14:53 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> While not all platforms allow us to change the cdclk frequency
> we should still verify that the fixed cdclk frequency isn't
> too low. To that end let's cook up a .modeset_calc_cdclk()
> implementation that only does the min_cdclk vs. actual cdclk
> frequency check for such platforms.
>
> Also we mustn't forget about double wide pipe on gen2/3 when
> doing this.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/display/intel_cdclk.c | 31
> drivers/gpu/drm/i915/display/intel_display.c | 8 ++---
> 2 files changed, 28 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
> b/drivers/gpu/drm/i915/display/intel_cdclk.c
> index f2910c0c3e3e..4649485fee33 100644
> --- a/drivers/gpu/drm/i915/display/intel_cdclk.c
> +++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
> @@ -2209,9 +2209,11 @@ intel_set_cdclk_post_plane_update(struct
> drm_i915_private *dev_priv,
> intel_set_cdclk(dev_priv, new_state, pipe);
> }
>
> -static int intel_pixel_rate_to_cdclk(struct drm_i915_private *dev_priv,
> - int pixel_rate)
> +static int intel_pixel_rate_to_cdclk(const struct intel_crtc_state
> *crtc_state)
> {
> + struct drm_i915_private *dev_priv = to_i915(crtc_state->base.crtc->dev);
> + int pixel_rate = crtc_state->pixel_rate;
> +
> if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv))
> return DIV_ROUND_UP(pixel_rate, 2);
> else if (IS_GEN(dev_priv, 9) ||
> @@ -2219,6 +2221,8 @@ static int intel_pixel_rate_to_cdclk(struct
> drm_i915_private *dev_priv,
> return pixel_rate;
> else if (IS_CHERRYVIEW(dev_priv))
> return DIV_ROUND_UP(pixel_rate * 100, 95);
> + else if (crtc_state->double_wide)
> + return DIV_ROUND_UP(pixel_rate * 100, 90 * 2);
> else
> return DIV_ROUND_UP(pixel_rate * 100, 90);
> }
> @@ -2232,7 +2236,7 @@ int intel_crtc_compute_min_cdclk(const struct
> intel_crtc_state *crtc_state)
> if (!crtc_state->base.enable)
> return 0;
>
> - min_cdclk = intel_pixel_rate_to_cdclk(dev_priv, crtc_state->pixel_rate);
> + min_cdclk = intel_pixel_rate_to_cdclk(crtc_state);
>
> /* pixel rate mustn't exceed 95% of cdclk with IPS on BDW */
> if (IS_BROADWELL(dev_priv) && hsw_crtc_state_ips_capable(crtc_state))
> @@ -2647,15 +2651,28 @@ static int icl_modeset_calc_cdclk(struct
> intel_atomic_state *state)
> return 0;
> }
>
> +static int fixed_modeset_calc_cdclk(struct intel_atomic_state *state)
> +{
> + int min_cdclk;
> +
> + /*
> + * We can't change the cdclk frequency, but we still want to
> + * check that the required minimum frequency doesn't exceed
> + * the actual cdclk frequency.
> + */
> + min_cdclk = intel_compute_min_cdclk(state);
> + if (min_cdclk < 0)
> + return min_cdclk;
> +
> + return 0;
> +}
Reviewed-by: Maarten Lankhorst
> +
> int intel_modeset_calc_cdclk(struct intel_atomic_state *state)
> {
> struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> enum pipe pipe;
> int ret;
>
> - if (!dev_priv->display.modeset_calc_cdclk)
> - return 0;
> -
> ret = dev_priv->display.modeset_calc_cdclk(state);
> if (ret)
> return ret;
> @@ -2957,6 +2974,8 @@ void intel_init_cdclk_hooks(struct drm_i915_private
> *dev_priv)
> } else if (IS_VALLEYVIEW(dev_priv)) {
> dev_priv->display.set_cdclk = vlv_set_cdclk;
> dev_priv->display.modeset_calc_cdclk = vlv_modeset_calc_cdclk;
> + } else {
> + dev_priv->display.modeset_calc_cdclk = fixed_modeset_calc_cdclk;
> }
>
> if (INTEL_GEN(dev_priv) >= 11)
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5a42cbfa72c3..2d3cfdc80fd3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16701,11 +16701,9 @@ static void intel_modeset_readout_hw_state(struct
> drm_device *dev)
>
> intel_crtc_compute_pixel_rate(crtc_state);
>
> - if (dev_priv->display.modeset_calc_cdclk) {
> - min_cdclk =
> intel_crtc_compute_min_cdclk(crtc_state);
> - if (WARN_ON(min_cdclk < 0))
> - min_cdclk = 0;
> - }
> + min_cdclk = intel_crtc_compute_min_cdclk(crtc_state);
> + if (WARN_ON(min_cdclk < 0))
> + min_cdclk = 0;
>
> drm_calc_timestamping_constants(&crtc->base,
>
> &crtc_state->base.adjusted_mode);
___
In
Re: [Intel-gfx] [PATCH 08/19] drm/i915: Stop using drm_atomic_helper_check_planes()
Op 08-07-2019 om 14:53 schreef Ville Syrjala:
> From: Ville Syrjälä
>
> We need to insert stuff between the plane and crtc .atomic_check()
> drm_atomic_helper_check_planes() doesn't allow us to do that so
> stop using it and hand roll the loops instead.
>
> Signed-off-by: Ville Syrjälä
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 10 +---
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 57 +++
> 3 files changed, 50 insertions(+), 19 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index 7ff19b524f9d..d7493551b28c 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -194,14 +194,11 @@ get_crtc_from_states(const struct intel_plane_state
> *old_plane_state,
> return NULL;
> }
>
> -static int intel_plane_atomic_check(struct drm_plane *_plane,
> - struct drm_plane_state *_new_plane_state)
> +int intel_plane_atomic_check(struct intel_atomic_state *state,
> + struct intel_plane *plane)
> {
> - struct intel_plane *plane = to_intel_plane(_plane);
> - struct intel_atomic_state *state =
> - to_intel_atomic_state(_new_plane_state->state);
> struct intel_plane_state *new_plane_state =
> - to_intel_plane_state(_new_plane_state);
> + intel_atomic_get_new_plane_state(state, plane);
> const struct intel_plane_state *old_plane_state =
> intel_atomic_get_old_plane_state(state, plane);
> struct intel_crtc *crtc =
> @@ -368,5 +365,4 @@ void i9xx_update_planes_on_crtc(struct intel_atomic_state
> *state,
> const struct drm_plane_helper_funcs intel_plane_helper_funcs = {
> .prepare_fb = intel_prepare_plane_fb,
> .cleanup_fb = intel_cleanup_plane_fb,
> - .atomic_check = intel_plane_atomic_check,
> };
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index cb7ef4f9eafd..dc85af02e9b7 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -41,6 +41,8 @@ int intel_plane_atomic_check_with_state(const struct
> intel_crtc_state *old_crtc_
> struct intel_crtc_state *crtc_state,
> const struct intel_plane_state
> *old_plane_state,
> struct intel_plane_state *intel_state);
> +int intel_plane_atomic_check(struct intel_atomic_state *state,
> + struct intel_plane *plane);
> int intel_plane_atomic_calc_changes(const struct intel_crtc_state
> *old_crtc_state,
> struct intel_crtc_state *crtc_state,
> const struct intel_plane_state
> *old_plane_state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index 5635f2079e4c..5a42cbfa72c3 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -11733,15 +11733,14 @@ static bool c8_planes_changed(const struct
> intel_crtc_state *new_crtc_state)
> return !old_crtc_state->c8_planes != !new_crtc_state->c8_planes;
> }
>
> -static int intel_crtc_atomic_check(struct drm_crtc *_crtc,
> -struct drm_crtc_state *_crtc_state)
> +static int intel_crtc_atomic_check(struct intel_atomic_state *state,
> +struct intel_crtc *crtc)
> {
> - struct intel_crtc *crtc = to_intel_crtc(_crtc);
> struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> struct intel_crtc_state *crtc_state =
> - to_intel_crtc_state(_crtc_state);
> - int ret;
> + intel_atomic_get_new_crtc_state(state, crtc);
> bool mode_changed = needs_modeset(crtc_state);
> + int ret;
>
> if (INTEL_GEN(dev_priv) < 5 && !IS_G4X(dev_priv) &&
> mode_changed && !crtc_state->base.active)
> @@ -11813,10 +11812,6 @@ static int intel_crtc_atomic_check(struct drm_crtc
> *_crtc,
> return ret;
> }
>
> -static const struct drm_crtc_helper_funcs intel_helper_funcs = {
> - .atomic_check = intel_crtc_atomic_check,
> -};
> -
> static void intel_modeset_update_connector_atomic_state(struct drm_device
> *dev)
> {
> struct intel_connector *connector;
> @@ -13457,6 +13452,42 @@ static void intel_crtc_check_fastset(const struct
> intel_crtc_state *old_crtc_sta
> new_crtc_state->has_drrs = old_crtc_state->has_drrs;
> }
>
> +static int intel_atomic_check_planes(struct intel_atomic_state *state)
> +{
> + struct intel_plane_state *plane_state;
> + struct intel_plane *plane;
> + int i, ret;
> +
> + for_each_new_inte
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Protect timeline->hwsp dereferencing
Quoting Tvrtko Ursulin (2019-09-19 11:48:25)
>
> On 18/09/2019 15:54, Chris Wilson wrote:
> > As not only is the signal->timeline volatile, so will be acquiring the
> > timeline's HWSP. We must first carefully acquire the timeline from the
> > signaling request and then lock the timeline. With the removal of the
> > struct_mutex serialisation of request construction, we can have multiple
> > timelines active at once, and so we must avoid using the nested mutex
> > lock as it is quite possible for both timelines to be establishing
> > semaphores on the other and so deadlock.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
> > ---
> > drivers/gpu/drm/i915/gt/intel_timeline.c | 32 ++--
> > 1 file changed, 25 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
> > b/drivers/gpu/drm/i915/gt/intel_timeline.c
> > index 2ce81bdf7f86..7b1d4098dd2e 100644
> > --- a/drivers/gpu/drm/i915/gt/intel_timeline.c
> > +++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
> > @@ -500,17 +500,32 @@ int intel_timeline_read_hwsp(struct i915_request
> > *from,
> >struct i915_request *to,
> >u32 *hwsp)
> > {
> > - struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
> > - struct intel_timeline *tl = from->timeline;
>
> I think this should have been annotated in 2/4.
I left it un-annotated so that it would be left with a warning, as I felt
this change was substantial enough to merit its own patch.
> > + struct intel_timeline *tl;
> > int err;
> >
> > + rcu_read_lock();
> > + tl = rcu_dereference(from->timeline);
> > + if (i915_request_completed(from) || !kref_get_unless_zero(&tl->kref))
> > + tl = NULL;
> > + rcu_read_unlock();
> > + if (!tl) /* already completed */
> > + return 1;
> > +
> > GEM_BUG_ON(rcu_access_pointer(to->timeline) == tl);
> >
> > - mutex_lock_nested(&tl->mutex, SINGLE_DEPTH_NESTING);
> > - err = i915_request_completed(from);
> > - if (!err)
> > + err = -EBUSY;
> > + if (mutex_trylock(&tl->mutex)) {
> > + struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
> > +
> > + if (i915_request_completed(from)) {
> > + err = 1;
> > + goto unlock;
> > + }
> > +
> > err = cacheline_ref(cl, to);
> > - if (!err) {
> > + if (err)
> > + goto unlock;
> > +
> > if (likely(cl == tl->hwsp_cacheline)) {
> > *hwsp = tl->hwsp_offset;
> > } else { /* across a seqno wrap, recover the original offset
> > */
> > @@ -518,8 +533,11 @@ int intel_timeline_read_hwsp(struct i915_request *from,
> > ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) *
> > CACHELINE_BYTES;
> > }
> > +
> > +unlock:
> > + mutex_unlock(&tl->mutex);
> > }
> > - mutex_unlock(&tl->mutex);
> > + intel_timeline_put(tl);
> >
> > return err;
> > }
> >
>
> Reviewed-by: Tvrtko Ursulin
Thanks,
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915: Lock signaler timeline while navigating
As we need to take a walk back along the signaler timeline to find the
fence before upon which we want to wait, we need to lock that timeline
to prevent it being modified as we walk. Similarly, we also need to
acquire a reference to the earlier fence while it still exists!
Though we lack the correct locking today, we are saved by the
overarching struct_mutex -- but that protection is being removed.
v2: Tvrtko made me realise I was being lax and using annotations to
ignore the AB-BA deadlock from the timeline overlap. As it would be
possible to construct a second request that was using a semaphore from the
same timeline as ourselves, we could quite easily end up in a situation
where we deadlocked in our mutex waits. Avoid that by using a trylock
and falling back to a normal dma-fence await if contended.
v3: Eek, the signal->timeline is volatile and must be carefully
dereferenced to ensure it is valid.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 68 +++--
1 file changed, 46 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index fb6f21c41934..9bd8538b1907 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -768,17 +768,43 @@ i915_request_create(struct intel_context *ce)
static int
i915_request_await_start(struct i915_request *rq, struct i915_request *signal)
{
- if (list_is_first(&signal->link, &signal->timeline->requests))
- return 0;
+ struct intel_timeline *tl;
+ struct dma_fence *fence;
+ int err;
+
+ GEM_BUG_ON(i915_request_timeline(rq) ==
+ rcu_access_pointer(signal->timeline));
- signal = list_prev_entry(signal, link);
- if (intel_timeline_sync_is_later(i915_request_timeline(rq),
-&signal->fence))
+ rcu_read_lock();
+ tl = rcu_dereference(signal->timeline);
+ if (i915_request_started(signal) || !kref_get_unless_zero(&tl->kref))
+ tl = NULL;
+ rcu_read_unlock();
+ if (!tl) /* already started or maybe even completed */
return 0;
- return i915_sw_fence_await_dma_fence(&rq->submit,
-&signal->fence, 0,
-I915_FENCE_GFP);
+ fence = ERR_PTR(-EBUSY);
+ if (mutex_trylock(&tl->mutex)) {
+ fence = NULL;
+ if (!i915_request_started(signal) &&
+ !list_is_first(&signal->link, &tl->requests)) {
+ signal = list_prev_entry(signal, link);
+ fence = dma_fence_get(&signal->fence);
+ }
+ mutex_unlock(&tl->mutex);
+ }
+ intel_timeline_put(tl);
+ if (IS_ERR_OR_NULL(fence))
+ return PTR_ERR_OR_ZERO(fence);
+
+ err = 0;
+ if (intel_timeline_sync_is_later(i915_request_timeline(rq), fence))
+ err = i915_sw_fence_await_dma_fence(&rq->submit,
+ fence, 0,
+ I915_FENCE_GFP);
+ dma_fence_put(fence);
+
+ return err;
}
static intel_engine_mask_t
@@ -808,30 +834,23 @@ emit_semaphore_wait(struct i915_request *to,
u32 hwsp_offset;
int len;
u32 *cs;
- int err;
- GEM_BUG_ON(!from->timeline->has_initial_breadcrumb);
GEM_BUG_ON(INTEL_GEN(to->i915) < 8);
/* Just emit the first semaphore we see as request space is limited. */
if (already_busywaiting(to) & from->engine->mask)
- return i915_sw_fence_await_dma_fence(&to->submit,
-&from->fence, 0,
-I915_FENCE_GFP);
+ goto await_fence;
- err = i915_request_await_start(to, from);
- if (err < 0)
- return err;
+ if (i915_request_await_start(to, from) < 0)
+ goto await_fence;
/* Only submit our spinner after the signaler is running! */
- err = __i915_request_await_execution(to, from, NULL, gfp);
- if (err)
- return err;
+ if (__i915_request_await_execution(to, from, NULL, gfp))
+ goto await_fence;
/* We need to pin the signaler's HWSP until we are finished reading. */
- err = intel_timeline_read_hwsp(from, to, &hwsp_offset);
- if (err)
- return err;
+ if (intel_timeline_read_hwsp(from, to, &hwsp_offset))
+ goto await_fence;
len = 4;
if (has_token)
@@ -866,6 +885,11 @@ emit_semaphore_wait(struct i915_request *to,
to->sched.semaphores |= from->engine->mask;
to->sched.flags |= I915_SCHED_HAS_SEMAPHORE_CHAIN;
return 0;
+
+await_fence:
+
[Intel-gfx] [PATCH v2 1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 57 ---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +++---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 27 +
drivers/gpu/drm/i915/gt/intel_timeline.c | 6 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 1 +
drivers/gpu/drm/i915/gt/selftest_context.c| 18 --
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
drivers/gpu/drm/i915/i915_active.c| 2 +-
drivers/gpu/drm/i915/i915_active.h| 6 ++
drivers/gpu/drm/i915/i915_request.c | 28 +
drivers/gpu/drm/i915/i915_request.h | 22 ++-
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
20 files changed, 147 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 29edfc343716..5efef9babadb 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -230,7 +230,7 @@ alloc_request(struct intel_overlay *overlay, void
(*fn)(struct intel_overlay *))
if (IS_ERR(rq))
return rq;
- err = i915_active_ref(&overlay->last_flip, rq->timeline, rq);
+ err = i915_active_add_request(&overlay->last_flip, rq);
if (err) {
i915_request_add(rq);
return ERR_PTR(err);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index f99920652751..7f61a8024133 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -211,7 +211,7 @@ static void clear_pages_worker(struct work_struct *work)
* keep track of the GPU activity within this vma/request, and
* propagate the signal from the request to w->dma.
*/
- err = i915_active_ref(&vma->active, rq->timeline, rq);
+ err = i915_active_add_request(&vma->active, rq);
if (err)
goto out_request;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f1c0e5d958f3..4a34c4f62065 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -910,7 +910,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (emit)
err = emit(rq, data);
if (err == 0)
- err = i915_active_ref(&cb->base, rq->timeline, rq);
+ err = i915_active_add_request(&cb->base, rq);
i915_request_add(rq);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c0495811f493..26cb838c272c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -298,7 +298,7 @@ int intel_context_prepare_remote_request(struct
intel_context *ce,
[Intel-gfx] [PATCH v2 3/3] drm/i915: Protect timeline->hwsp dereferencing
As not only is the signal->timeline volatile, so will be acquiring the
timeline's HWSP. We must first carefully acquire the timeline from the
signaling request and then lock the timeline. With the removal of the
struct_mutex serialisation of request construction, we can have multiple
timelines active at once, and so we must avoid using the nested mutex
lock as it is quite possible for both timelines to be establishing
semaphores on the other and so deadlock.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_timeline.c | 32 ++--
1 file changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_timeline.c
b/drivers/gpu/drm/i915/gt/intel_timeline.c
index 115a24d4a20a..9d436e14ea8d 100644
--- a/drivers/gpu/drm/i915/gt/intel_timeline.c
+++ b/drivers/gpu/drm/i915/gt/intel_timeline.c
@@ -500,17 +500,32 @@ int intel_timeline_read_hwsp(struct i915_request *from,
struct i915_request *to,
u32 *hwsp)
{
- struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
- struct intel_timeline *tl = from->timeline;
+ struct intel_timeline *tl;
int err;
+ rcu_read_lock();
+ tl = rcu_dereference(from->timeline);
+ if (i915_request_completed(from) || !kref_get_unless_zero(&tl->kref))
+ tl = NULL;
+ rcu_read_unlock();
+ if (!tl) /* already completed */
+ return 1;
+
GEM_BUG_ON(rcu_access_pointer(to->timeline) == tl);
- mutex_lock_nested(&tl->mutex, SINGLE_DEPTH_NESTING);
- err = i915_request_completed(from);
- if (!err)
+ err = -EBUSY;
+ if (mutex_trylock(&tl->mutex)) {
+ struct intel_timeline_cacheline *cl = from->hwsp_cacheline;
+
+ if (i915_request_completed(from)) {
+ err = 1;
+ goto unlock;
+ }
+
err = cacheline_ref(cl, to);
- if (!err) {
+ if (err)
+ goto unlock;
+
if (likely(cl == tl->hwsp_cacheline)) {
*hwsp = tl->hwsp_offset;
} else { /* across a seqno wrap, recover the original offset */
@@ -518,8 +533,11 @@ int intel_timeline_read_hwsp(struct i915_request *from,
ptr_unmask_bits(cl->vaddr, CACHELINE_BITS) *
CACHELINE_BYTES;
}
+
+unlock:
+ mutex_unlock(&tl->mutex);
}
- mutex_unlock(&tl->mutex);
+ intel_timeline_put(tl);
return err;
}
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
On Thu, Sep 19, 2019 at 07:23:30AM +, S, Srinivasan wrote:
> Would the following be appropriate fix?
>
> if (connector || connector->base.status ==
> connector_status_connected) {
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> if (ret) {
> DRM_ERROR("failed to update payload %d\n", ret);
> }
> }
The whole connector->status check is racy. IMO don't do it.
>
> Regards,
> -Original Message-
> From: dri-devel On Behalf Of Manasi
> Navare
> Sent: Wednesday, September 18, 2019 11:55 PM
> To: Ville Syrjälä
> Cc: S, Srinivasan ; intel-gfx@lists.freedesktop.org;
> dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC
> cable
>
> On Wed, Sep 18, 2019 at 09:11:36PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 18, 2019 at 10:50:39AM -0700, Manasi Navare wrote:
> > > On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
> > > > From: Srinivasan S
> > > >
> > > > This patch avoids DP MST payload error message in dmesg, as it is
> > > > trying to read the payload from the disconnected DP MST device.
> > > > After the unplug the connector status is disconnected and we
> > > > should not be looking for the payload and hence remove the error and
> > > > throw the warning.
> > > >
> > > > This details can be found in:
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=111632
> > >
> > > Please add this link as Bugzilla:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=111632 after the Sign
> > > off statement
> > >
> > > >
> > > > Signed-off-by: Srinivasan S
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index eeeb3f933aa4..5b2278fdf675 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -215,7 +215,12 @@ static void intel_mst_disable_dp(struct
> > > > intel_encoder *encoder,
> > > >
> > > > ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > > > if (ret) {
> > > > - DRM_ERROR("failed to update payload %d\n", ret);
> > > > + if (!connector ||
> > > > + connector->base.status !=
> > > > connector_status_connected) {
> > > > + DRM_WARN("DP MST disconnect\n");
> > >
> > > May be adding this check before calling drm_dp_update_payload_part1() is
> > > a better idea?
> > > If the connector is disconnected, why update payload?
> > >
> > > Jani, Ville, thoughts?
> >
> > Or just convert it to a debug?
>
> Sure that will work, but do we really want to update the payload if the
> connector status is disconnected.
> So shouldnt checking that before calling the function be a better fix?
>
> Manasi
>
> >
> > >
> > > Regards
> > > Manasi
> > >
> > > > + } else {
> > > > + DRM_ERROR("failed to update payload %d\n", ret);
> > > > + }
> > > > }
> > > > if (old_crtc_state->has_audio)
> > > > intel_audio_codec_disable(encoder,
> > > > --
> > > > 2.7.4
> > > >
> >
> > --
> > Ville Syrjälä
> > Intel
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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: success for Docs: fix incorrect use of kernel-doc format in structure description.
== Series Details ==
Series: Docs: fix incorrect use of kernel-doc format in structure description.
URL : https://patchwork.freedesktop.org/series/66922/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6919 -> Patchwork_14453
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/
Known issues
Here are the changes found in Patchwork_14453 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_mmap_gtt@basic-write-cpu-read-gtt:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) +1
similar issue
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/fi-icl-u3/igt@gem_mmap_...@basic-write-cpu-read-gtt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [PASS][3] -> [FAIL][4] ([fdo#111407])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-cml-u2: [INCOMPLETE][5] ([fdo#110566]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-cml-u2/igt@gem_close_r...@basic-threads.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/fi-cml-u2/igt@gem_close_r...@basic-threads.html
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] +1
similar issue
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-guc}: [INCOMPLETE][9] ([fdo#107713] / [fdo#108569]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-icl-guc/igt@i915_selftest@live_hangcheck.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/fi-icl-guc/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#106350]: https://bugs.freedesktop.org/show_bug.cgi?id=106350
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
Participating hosts (53 -> 48)
--
Additional (1): fi-bsw-n3050
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-icl-y fi-byt-clapper
fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6919 -> Patchwork_14453
CI-20190529: 20190529
CI_DRM_6919: c36c0d42ee009514f713d0b51961c8e8fddfc641 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5192: 77c53210779c30cfb8a4ca2312675fe5be94f4d5 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14453: 3d8ee314db1c3cb18e237ff31a52e0ce3604c275 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
3d8ee314db1c Docs: fix incorrect use of kernel-doc format in structure
description.
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14453/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
On Wed, 18 Sep 2019, Manasi Navare wrote:
> On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
>> From: Srinivasan S
>>
>> This patch avoids DP MST payload error message in dmesg, as it is trying
>> to read the payload from the disconnected DP MST device. After the unplug
>> the connector status is disconnected and we should not be looking for the
>> payload and hence remove the error and throw the warning.
>>
>> This details can be found in:
>> https://bugs.freedesktop.org/show_bug.cgi?id=111632
>
> Please add this link as Bugzilla:
> https://bugs.freedesktop.org/show_bug.cgi?id=111632 after the Sign off
> statement
ITYM *before* Signed-off-by. But yeah, use the Bugzilla: tag, and please
use git log to see plenty of examples.
BR,
Jani.
>
>>
>> Signed-off-by: Srinivasan S
>> ---
>> drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++-
>> 1 file changed, 6 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> index eeeb3f933aa4..5b2278fdf675 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
>> @@ -215,7 +215,12 @@ static void intel_mst_disable_dp(struct intel_encoder
>> *encoder,
>>
>> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
>> if (ret) {
>> -DRM_ERROR("failed to update payload %d\n", ret);
>> +if (!connector ||
>> +connector->base.status != connector_status_connected) {
>> +DRM_WARN("DP MST disconnect\n");
>
> May be adding this check before calling drm_dp_update_payload_part1() is a
> better idea?
> If the connector is disconnected, why update payload?
>
> Jani, Ville, thoughts?
>
> Regards
> Manasi
>
>> +} else {
>> +DRM_ERROR("failed to update payload %d\n", ret);
>> +}
>> }
>> if (old_crtc_state->has_audio)
>> intel_audio_codec_disable(encoder,
>> --
>> 2.7.4
>>
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] Docs: fix incorrect use of kernel-doc format in structure description.
On Thu, 19 Sep 2019, Chris Wilson wrote: > Quoting Anna Karas (2019-09-19 11:49:28) >> Insert structure members names into their descriptions to follow >> kernel-doc format >> >> Signed-off-by: Anna Karas > > Lgtm, > Reviewed-by: Chris Wilson Yes, apart from subject prefix. Maybe something like "drm/i915/perf: " would be more accurate. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
== Series Details == Series: series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer URL : https://patchwork.freedesktop.org/series/66923/ State : warning == Summary == $ dim checkpatch origin/drm-tip e13eda0cac6a drm/i915: Mark i915_request.timeline as a volatile, rcu pointer -:361: WARNING:LONG_LINE: line over 100 characters #361: FILE: drivers/gpu/drm/i915/gt/intel_ringbuffer.c:444: + GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR); -:372: WARNING:LONG_LINE: line over 100 characters #372: FILE: drivers/gpu/drm/i915/gt/intel_ringbuffer.c:464: + GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR); -:383: WARNING:LONG_LINE: line over 100 characters #383: FILE: drivers/gpu/drm/i915/gt/intel_ringbuffer.c:943: + GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR); -:394: WARNING:LONG_LINE: line over 100 characters #394: FILE: drivers/gpu/drm/i915/gt/intel_ringbuffer.c:966: + GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR); -:509: WARNING:LONG_LINE: line over 100 characters #509: FILE: drivers/gpu/drm/i915/gt/selftest_lrc.c:1092: + __i915_active_request_set(&i915_request_timeline(rq[i])->last_request, total: 0 errors, 5 warnings, 0 checks, 573 lines checked d80bab4e522c drm/i915: Lock signaler timeline while navigating e3ec03a920da drm/i915: Protect timeline->hwsp dereferencing ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/tgl: Implement Wa_1406941453
== Series Details == Series: drm/i915/tgl: Implement Wa_1406941453 URL : https://patchwork.freedesktop.org/series/66886/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14448_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14448_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14448_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_14448_full: ### Piglit changes ### Possible regressions * spec@glsl-1.30@execution@texelfetch fs sampler2darray 98x129x1-98x129x9 (NEW): - pig-hsw-4770r: NOTRUN -> [FAIL][1] [1]: None New tests - New tests have been introduced between CI_DRM_6917_full and Patchwork_14448_full: ### New Piglit tests (1) ### * spec@glsl-1.30@execution@texelfetch fs sampler2darray 98x129x1-98x129x9: - Statuses : 1 fail(s) - Exec time: [1.26] s Known issues Here are the changes found in Patchwork_14448_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][2] -> [SKIP][3] ([fdo#111325]) +6 similar issues [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][4] -> [DMESG-WARN][5] ([fdo#108566]) +7 similar issues [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-apl7/igt@gem_workarou...@suspend-resume-context.html * igt@kms_flip@blocking-absolute-wf_vblank: - shard-hsw: [PASS][6] -> [INCOMPLETE][7] ([fdo#103540]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw5/igt@kms_flip@blocking-absolute-wf_vblank.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-hsw5/igt@kms_flip@blocking-absolute-wf_vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][8] -> [FAIL][9] ([fdo#103167]) +2 similar issues [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes: - shard-kbl: [PASS][10] -> [DMESG-WARN][11] ([fdo#103313]) [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-kbl2/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-kbl3/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-b-planes.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][12] -> [FAIL][13] ([fdo#108145] / [fdo#110403]) [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][14] -> [SKIP][15] ([fdo#109441]) +2 similar issues [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_psr@psr2_basic.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-iclb1/igt@kms_psr@psr2_basic.html * igt@kms_rotation_crc@multiplane-rotation: - shard-apl: [PASS][16] -> [INCOMPLETE][17] ([fdo#103927]) +1 similar issue [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl4/igt@kms_rotation_...@multiplane-rotation.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-apl8/igt@kms_rotation_...@multiplane-rotation.html * igt@kms_setmode@basic: - shard-hsw: [PASS][18] -> [FAIL][19] ([fdo#99912]) [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw5/igt@kms_setm...@basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14448/shard-hsw2/igt@kms_setm...@basic.html * igt@prime_vgem@fence-wait-bsd2: - shard-iclb: [PASS][20] -> [SKIP][21] ([fdo#109276]) +21 similar issues [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@prime_v...@
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
== Series Details == Series: series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer URL : https://patchwork.freedesktop.org/series/66923/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.6.0 Commit: drm/i915: Mark i915_request.timeline as a volatile, rcu pointer +drivers/gpu/drm/i915/gt/intel_timeline.c:504:41:expected struct intel_timeline *tl +drivers/gpu/drm/i915/gt/intel_timeline.c:504:41:got struct intel_timeline [noderef] *timeline +drivers/gpu/drm/i915/gt/intel_timeline.c:504:41: warning: incorrect type in initializer (different address spaces) +drivers/gpu/drm/i915/i915_request.c:771:49:expected struct list_head const *head +drivers/gpu/drm/i915/i915_request.c:771:49:got struct list_head [noderef] * +drivers/gpu/drm/i915/i915_request.c:771:49: warning: incorrect type in argument 2 (different address spaces) +drivers/gpu/drm/i915/i915_request.c:813:9: warning: dereference of noderef expression Commit: drm/i915: Lock signaler timeline while navigating -O:drivers/gpu/drm/i915/i915_request.c:771:49:expected struct list_head const *head -O:drivers/gpu/drm/i915/i915_request.c:771:49:got struct list_head [noderef] * -O:drivers/gpu/drm/i915/i915_request.c:771:49: warning: incorrect type in argument 2 (different address spaces) -O:drivers/gpu/drm/i915/i915_request.c:813:9: warning: dereference of noderef expression + Commit: drm/i915: Protect timeline->hwsp dereferencing -O:drivers/gpu/drm/i915/gt/intel_timeline.c:504:41:expected struct intel_timeline *tl -O:drivers/gpu/drm/i915/gt/intel_timeline.c:504:41:got struct intel_timeline [noderef] *timeline -O:drivers/gpu/drm/i915/gt/intel_timeline.c:504:41: warning: incorrect type in initializer (different address spaces) + ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [v2][PATCH 2/3] drm/i915/display: Extract icl_read_luts()
On Wed, 18 Sep 2019, "Sharma, Swati2" wrote:
> On 18-Sep-19 3:31 PM, Jani Nikula wrote:
>> On Tue, 17 Sep 2019, Swati Sharma wrote:
>>> For icl+, have hw read out to create hw blob of gamma
>>> lut values. icl+ platforms supports multi segmented gamma
>>> mode, add hw lut creation for this mode.
>>>
>>> This will be used to validate gamma programming using dsb
>>> (display state buffer) which is a tgl feature.
>>>
>>> v2: -readout code for multisegmented gamma has to come
>>> up with some intermediate entries that aren't preserved
>>> in hardware (Jani N)
>>> -linear interpolation (Ville)
>>> -moved common code to check gamma_enable to specific funcs,
>>> since icl doesn't support that
>>>
>>> Signed-off-by: Swati Sharma
>>> ---
>>> drivers/gpu/drm/i915/display/intel_color.c | 243
>>> ++---
>>> drivers/gpu/drm/i915/i915_reg.h| 7 +
>>> 2 files changed, 230 insertions(+), 20 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_color.c
>>> b/drivers/gpu/drm/i915/display/intel_color.c
>>> index b1f0f7e..0008011 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_color.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_color.c
>>> @@ -1370,6 +1370,9 @@ static int icl_color_check(struct intel_crtc_state
>>> *crtc_state)
>>>
>>> static int i9xx_gamma_precision(const struct intel_crtc_state *crtc_state)
>>> {
>>> + if (!crtc_state->gamma_enable)
>>> + return 0;>> +
>>
>> Why are you moving these checks back to the individual functions?
> As stated in commit message, moved common code to check gamma_enable to
> specific funcs, since icl doesn't support gamma_enable and code will
> return 0. If i need to make it generic, i need to make gamma_enable true
> in icl_color_check() func. Is it fine? ICL enables gamma through
> gamma_mode unlike other platforms.
Argh. Right. Okay, let's go with what you have in this patch. We can
clean this stuff up later.
Please write the main part of the commit message such that it is
independent of the changelog. The changelog is good, but the actual
changes need to be evident from the message part.
BR,
Jani.
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] i915: intel_dp_aux_backlight: Fix max backlight calculations
On Wed, 2019-07-10 at 17:43 -0700, Furquan Shaikh wrote:
> Max backlight value for the panel was being calculated using byte
> count i.e. 0x if 2 bytes are supported for backlight brightness
> and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
> determines the number of active control bits used for the brightness
> setting. Thus, even if the panel uses 2 byte setting, it might not
> use
> all the control bits. Thus, max backlight should be set based on the
> value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255.
>
> Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT
> frequency which results in a different max backlight value. Thus,
> setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of
> enable so that max backlight can be calculated correctly. Only the
> frequency divider is set during the enable phase using the value of
> EDP_PWMGEN_BIT_COUNT.
>
> Signed-off-by: Furquan Shaikh
> Reviewed-by: Stéphane Marchesin
Hi,
Thank you for your patch. See comments inline.
> ---
> v2: In case of DPCD failure and pn being uninitialized, return
> max_backlight as 0.
>
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 134 --
>
> 1 file changed, 90 insertions(+), 44 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> index 357136f17f85..b3678b8a5b4d 100644
> --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> @@ -110,61 +110,34 @@ static bool intel_dp_aux_set_pwm_freq(struct
> intel_connector *connector)
> {
> struct drm_i915_private *dev_priv = to_i915(connector-
> >base.dev);
> struct intel_dp *intel_dp = enc_to_intel_dp(&connector-
> >encoder->base);
> - int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
> - u8 pn, pn_min, pn_max;
> + int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
> + u8 pn;
>
> - /* Find desired value of (F x P)
> - * Note that, if F x P is out of supported range, the maximum
> value or
> - * minimum value will applied automatically. So no need to
> check that.
> - */
> freq = dev_priv->vbt.backlight.pwm_freq_hz;
> - DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
> if (!freq) {
> DRM_DEBUG_KMS("Use panel default backlight
> frequency\n");
> return false;
> }
>
> - fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ),
> freq);
> -
> - /* Use highest possible value of Pn for more granularity of
> brightness
> - * adjustment while satifying the conditions below.
> - * - Pn is in the range of Pn_min and Pn_max
> - * - F is in the range of 1 and 255
> - * - FxP is within 25% of desired value.
> - * Note: 25% is arbitrary value and may need some tweak.
> - */
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> -DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN,
> &pn_min) != 1) {
> - DRM_DEBUG_KMS("Failed to read pwmgen bit count cap
> min\n");
> + if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
> + &pn) < 0) {
> + DRM_DEBUG_KMS("Failed to read aux pwmgen bit count\n");
> return false;
> }
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> -DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX,
> &pn_max) != 1) {
> - DRM_DEBUG_KMS("Failed to read pwmgen bit count cap
> max\n");
> - return false;
> - }
> - pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
> - pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
>
> + fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ),
> freq);
> + f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
> + fxp_actual = f << pn;
> +
> + /* Ensure frequency is within 25% of desired value */
> fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
> fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
> - if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
> - DRM_DEBUG_KMS("VBT defined backlight frequency out of
> range\n");
> - return false;
> - }
>
> - for (pn = pn_max; pn >= pn_min; pn--) {
> - f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
> - fxp_actual = f << pn;
> - if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
> - break;
> - }
> -
> - if (drm_dp_dpcd_writeb(&intel_dp->aux,
> -DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
> - DRM_DEBUG_KMS("Failed to write aux pwmgen bit
> count\n");
> + if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
> + DRM_DEBUG_KMS("Actual frequency out of range\n");
> return false;
> }
> +
> if (drm_dp_dpcd_writeb(&intel_dp->aux,
> DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0)
> {
> DRM_DEBUG_KMS("Failed to write aux bac
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
== Series Details ==
Series: series starting with [v2,1/3] drm/i915: Mark i915_request.timeline as a
volatile, rcu pointer
URL : https://patchwork.freedesktop.org/series/66923/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6919 -> Patchwork_14454
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14454/
Known issues
Here are the changes found in Patchwork_14454 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_addfb_basic@basic:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-icl-u3/igt@kms_addfb_ba...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14454/fi-icl-u3/igt@kms_addfb_ba...@basic.html
Possible fixes
* igt@gem_close_race@basic-threads:
- fi-cml-u2: [INCOMPLETE][3] ([fdo#110566]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-cml-u2/igt@gem_close_r...@basic-threads.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14454/fi-cml-u2/igt@gem_close_r...@basic-threads.html
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14454/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@i915_selftest@live_hangcheck:
- {fi-icl-guc}: [INCOMPLETE][7] ([fdo#107713] / [fdo#108569]) ->
[PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6919/fi-icl-guc/igt@i915_selftest@live_hangcheck.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14454/fi-icl-guc/igt@i915_selftest@live_hangcheck.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111739]: https://bugs.freedesktop.org/show_bug.cgi?id=111739
Participating hosts (53 -> 48)
--
Additional (1): fi-bsw-n3050
Missing(6): fi-ilk-m540 fi-hsw-4200u fi-bsw-cyan fi-icl-y fi-byt-clapper
fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6919 -> Patchwork_14454
CI-20190529: 20190529
CI_DRM_6919: c36c0d42ee009514f713d0b51961c8e8fddfc641 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5192: 77c53210779c30cfb8a4ca2312675fe5be94f4d5 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14454: e3ec03a920da8604bfd0e12663cdcebf44490e01 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e3ec03a920da drm/i915: Protect timeline->hwsp dereferencing
d80bab4e522c drm/i915: Lock signaler timeline while navigating
e13eda0cac6a drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14454/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise CS TLB invalidation
Chris Wilson writes:
> Check that we are correctly invalidating the TLB at the start of a
> batch after updating the GTT.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 227 ++
> 1 file changed, 227 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 598c18d10640..f8709b332bd7 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -25,13 +25,16 @@
> #include
> #include
>
> +#include "gem/i915_gem_context.h"
> #include "gem/selftests/mock_context.h"
> +#include "gt/intel_context.h"
>
> #include "i915_random.h"
> #include "i915_selftest.h"
>
> #include "mock_drm.h"
> #include "mock_gem_device.h"
> +#include "igt_flush_test.h"
>
> static void cleanup_freed_objects(struct drm_i915_private *i915)
> {
> @@ -1705,6 +1708,229 @@ int i915_gem_gtt_mock_selftests(void)
> return err;
> }
>
> +static int context_sync(struct intel_context *ce)
> +{
> + struct i915_request *rq;
> + long timeout;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + i915_request_get(rq);
> + i915_request_add(rq);
> +
> + timeout = i915_request_wait(rq, 0, HZ / 5);
> + i915_request_put(rq);
> +
> + return timeout < 0 ? -EIO : 0;
> +}
> +
> +static int submit_batch(struct intel_context *ce, u64 addr)
> +{
> + struct i915_request *rq;
> + int err;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + err = 0;
> + if (rq->engine->emit_init_breadcrumb) /* detect a hang */
for seqno write?
> + err = rq->engine->emit_init_breadcrumb(rq);
> + if (err == 0)
> + err = rq->engine->emit_bb_start(rq, addr, 0, 0);
> +
In context_sync part we grabbed a reference. In here we
don't. I don't see how we can get away without it even
if we don't wait in here.
> + i915_request_add(rq);
> +
> + return err;
> +}
> +
> +static int igt_cs_tlb(void *arg)
> +{
> + const unsigned int count = PAGE_SIZE / 64;
> + const unsigned int chunk_size = count * PAGE_SIZE;
> + struct drm_i915_private *i915 = arg;
> + struct drm_i915_gem_object *bbe, *out;
> + struct i915_gem_engines_iter it;
> + struct i915_address_space *vm;
> + struct i915_gem_context *ctx;
> + struct intel_context *ce;
> + struct drm_file *file;
> + struct i915_vma *vma;
> + unsigned int i;
> + u32 *result;
> + u32 *batch;
> + int err = 0;
> +
> + file = mock_file(i915);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + mutex_lock(&i915->drm.struct_mutex);
> + ctx = live_context(i915, file);
> + if (IS_ERR(ctx)) {
> + err = PTR_ERR(ctx);
> + goto out_unlock;
> + }
> +
> + vm = ctx->vm;
> + if (!vm)
> + goto out_unlock;
> +
> + bbe = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + if (IS_ERR(bbe)) {
> + err = PTR_ERR(bbe);
> + goto out_unlock;
> + }
> +
> + batch = i915_gem_object_pin_map(bbe, I915_MAP_WC);
> + if (IS_ERR(batch)) {
> + err = PTR_ERR(batch);
> + goto out_bbe;
> + }
> + for (i = 0; i < count; i++) {
> + u32 *cs = batch + i * 64 / sizeof(*cs);
> + u64 addr = (vm->total - PAGE_SIZE) + i * sizeof(u32);
> +
> + GEM_BUG_ON(INTEL_GEN(i915) < 6);
> + cs[0] = MI_STORE_DWORD_IMM_GEN4;
> + if (INTEL_GEN(i915) >= 8) {
> + cs[1] = lower_32_bits(addr);
> + cs[2] = upper_32_bits(addr);
> + cs[3] = i;
> + cs[4] = MI_NOOP;
> + cs[5] = MI_BATCH_BUFFER_START_GEN8;
> + } else {
> + cs[1] = 0;
> + cs[2] = lower_32_bits(addr);
> + cs[3] = i;
> + cs[4] = MI_NOOP;
> + cs[5] = MI_BATCH_BUFFER_START;
> + }
> + }
> +
> + out = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + if (IS_ERR(out)) {
> + err = PTR_ERR(out);
> + goto out_batch;
> + }
> + i915_gem_object_set_cache_coherency(out, I915_CACHING_CACHED);
> +
> + vma = i915_vma_instance(out, vm, NULL);
> + if (IS_ERR(vma)) {
> + err = PTR_ERR(vma);
> + goto out_batch;
> + }
> +
> + err = i915_vma_pin(vma, 0, 0,
> +PIN_USER |
> +PIN_OFFSET_FIXED |
> +(vm->total - PAGE_SIZE));
> + if (err)
> + goto out_out;
out_put?
Oh and we don't have to do anything with the instance on
error paths?
> + GEM_BUG_O
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
On 19/09/2019 12:19, Chris Wilson wrote:
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/display/intel_overlay.c | 2 +-
.../gpu/drm/i915/gem/i915_gem_client_blt.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_context.c | 2 +-
drivers/gpu/drm/i915/gt/intel_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 57 ---
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 2 +-
drivers/gpu/drm/i915/gt/intel_engine_pool.h | 2 +-
drivers/gpu/drm/i915/gt/intel_lrc.c | 17 +++---
drivers/gpu/drm/i915/gt/intel_ringbuffer.c| 27 +
drivers/gpu/drm/i915/gt/intel_timeline.c | 6 +-
.../gpu/drm/i915/gt/intel_timeline_types.h| 1 +
drivers/gpu/drm/i915/gt/selftest_context.c| 18 --
drivers/gpu/drm/i915/gt/selftest_lrc.c| 2 +-
drivers/gpu/drm/i915/i915_active.c| 2 +-
drivers/gpu/drm/i915/i915_active.h| 6 ++
drivers/gpu/drm/i915/i915_request.c | 28 +
drivers/gpu/drm/i915/i915_request.h | 22 ++-
drivers/gpu/drm/i915/i915_vma.c | 6 +-
drivers/gpu/drm/i915/selftests/i915_active.c | 2 +-
drivers/gpu/drm/i915/selftests/igt_spinner.c | 2 +-
20 files changed, 147 insertions(+), 63 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_overlay.c
b/drivers/gpu/drm/i915/display/intel_overlay.c
index 29edfc343716..5efef9babadb 100644
--- a/drivers/gpu/drm/i915/display/intel_overlay.c
+++ b/drivers/gpu/drm/i915/display/intel_overlay.c
@@ -230,7 +230,7 @@ alloc_request(struct intel_overlay *overlay, void
(*fn)(struct intel_overlay *))
if (IS_ERR(rq))
return rq;
- err = i915_active_ref(&overlay->last_flip, rq->timeline, rq);
+ err = i915_active_add_request(&overlay->last_flip, rq);
if (err) {
i915_request_add(rq);
return ERR_PTR(err);
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
index f99920652751..7f61a8024133 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
@@ -211,7 +211,7 @@ static void clear_pages_worker(struct work_struct *work)
* keep track of the GPU activity within this vma/request, and
* propagate the signal from the request to w->dma.
*/
- err = i915_active_ref(&vma->active, rq->timeline, rq);
+ err = i915_active_add_request(&vma->active, rq);
if (err)
goto out_request;
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index f1c0e5d958f3..4a34c4f62065 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -910,7 +910,7 @@ static int context_barrier_task(struct i915_gem_context
*ctx,
if (emit)
err = emit(rq, data);
if (err == 0)
- err = i915_active_ref(&cb->base, rq->timeline, rq);
+ err = i915_active_add_request(&cb->base, rq);
i915_request_add(rq);
if (err)
diff --git a/drivers/gpu/drm/i915/gt/intel_context.c
b/drivers/gpu/drm/i915/gt/intel_context.c
index c0495811f493..26cb838c272c 100644
--- a/drivers/gpu/drm/i915/gt/intel_context.c
+++ b/drivers/gpu/drm/i915/gt/intel_context.c
@@ -298,7 +298,7 @@ int intel_context_pre
Re: [Intel-gfx] FW: [PATCH 1/5] drm/i915: Allow i915 to manage the vma offset nodes instead of drm core
On Wed, Sep 11, 2019 at 2:19 PM Chris Wilson wrote: > Quoting Balestrieri, Francesco (2019-09-11 13:03:25) > > On 04/09/2019, 13.33, "Intel-gfx on behalf of Daniel Vetter" > > > > wrote: > > > > On Mon, Aug 26, 2019 at 2:21 PM Abdiel Janulgue > > > - ret = create_mmap_offset(obj); > > > - if (ret == 0) > > > - *offset = > > drm_vma_node_offset_addr(&obj->base.vma_node); > > > + mmo = kzalloc(sizeof(*mmo), GFP_KERNEL); > > > > I got thrown off a bunch of times here reading the code, but I think I > > got this right now. > > > > Why exactly do we want multiple vma offsets? Yes this makes it a > > drop-in replacement for the old cpu mmap ioctl, which was a bit > > dubious design. But if we go all new here, I really wonder about why > > this is necessary. No other discrete driver needs this, they all fix > > the mmap mode for the lifetime of an object, because flushing stuff is > > as expensive as just reallocating (or at least close enough). > > > > I think us going once again our separate route here needs a lot more > > justification than just "we've accidentally ended up with uapi like > > this 10 years ago". > > That's exactly the whole point, to replace the uapi we accidentally > ended up with 10 years ago with the api that doesn't cause valgrind to > complain, is easily extensible and supports all legacy usecases which > should be a very good position to be in to support unknown future > usecases as well. Letting userspace control their mmapings is very > powerful, and we definitely do not want to be limiting their > flexibility. > > That no other driver even seems to allow multiple mmaps, and so has > not developed a desire to manage multiple vma per object does not seem > to be a reason to limit ourselves. The infrastructure all supports it; > the only thing that is at odds is the desire to force the lowest common > denominator as the defacto standard. Just because something is possible (or looks possible at first) doesn't make it good uapi. That's how we get stuff like gtt mmap on userptr bo, and then regrets. This entire thing here gets sold as "uapi cleanup for lmem". Which makes sense, except most of the uapi isn't really cleaned up at all: - We still have relocations (and we even made them more powerful by pipelining them, at a time when all our mesa drivers finally managed to move to softpin). We could ditch all the reloc stuff for gen12+ and lmem instead. Both amdgpu and nv50+ have done that. - We're still adding more uapi that's all adding variable state. Meanwhile everything else (gallium/iris, vk) move to invariant state object models, where you create stuff once with the right properties and call it a day. lmem does add quite a few new state bits here, would be a lot simpler if we could make them as invariant as possible. For placement we might need to allow changes to the priority, but not to the placement list itself. For mmap, you just select the mmap mode that you want (because once you fixing caching mode, placement list and tiling bits, there's really not a choice anymore), and that's the one you get with the single mmap offset. Instead we just hang onto all the accumulated complexity, add more, and the only cleanup I'm seeing is that we bake in the multi-mmap model to save one single line in userspace for the valgrind annotation. Which everyone has already anyway, that is not really going to go away. I think using lmem to clean up the uapi makes tons of sense, but if we bother with that it should be a real cleanup. Not just cosmetics for the one valgrind annotation line in userspace we have right now. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915: Future-proof DDC pin mapping
== Series Details == Series: series starting with [1/2] drm/i915: Future-proof DDC pin mapping URL : https://patchwork.freedesktop.org/series/66887/ State : success == Summary == CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14449_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14449_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-skl: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl8/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-skl9/igt@gem_...@reset-stress.html * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +8 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-iclb1/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@i915_pm_rpm@universal-planes: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#108840]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb7/igt@i915_pm_...@universal-planes.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-iclb1/igt@i915_pm_...@universal-planes.html * igt@i915_pm_sseu@full-enable: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl1/igt@i915_pm_s...@full-enable.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-apl6/igt@i915_pm_s...@full-enable.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl8/igt@i915_susp...@sysfs-reader.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-apl7/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#105767]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw5/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-hsw4/igt@kms_cursor_leg...@2x-long-cursor-vs-flip-legacy.html * igt@kms_flip@2x-modeset-vs-vblank-race: - shard-glk: [PASS][13] -> [FAIL][14] ([fdo#111609]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-glk4/igt@kms_f...@2x-modeset-vs-vblank-race.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-glk1/igt@kms_f...@2x-modeset-vs-vblank-race.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#105363]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#109507]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl9/igt@kms_f...@flip-vs-suspend-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-skl6/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +7 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-pri-indfb-draw-mmap-cpu.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb6/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_psr@psr2_basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14449/shard-iclb6/igt@kms_psr@psr2_basic.html * igt@kms_setmode@basic: - shard-apl: [PASS][25] -> [FAIL][26] ([fdo#99912]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl4/igt@kms_setm...@basic.html [26]: https:/
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise CS TLB invalidation
Quoting Mika Kuoppala (2019-09-19 13:57:45)
> Chris Wilson writes:
>
> > Check that we are correctly invalidating the TLB at the start of a
> > batch after updating the GTT.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Mika Kuoppala
> > Cc: Daniele Ceraolo Spurio
> > ---
> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 227 ++
> > 1 file changed, 227 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> > b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> > index 598c18d10640..f8709b332bd7 100644
> > --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> > +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> > @@ -25,13 +25,16 @@
> > #include
> > #include
> >
> > +#include "gem/i915_gem_context.h"
> > #include "gem/selftests/mock_context.h"
> > +#include "gt/intel_context.h"
> >
> > #include "i915_random.h"
> > #include "i915_selftest.h"
> >
> > #include "mock_drm.h"
> > #include "mock_gem_device.h"
> > +#include "igt_flush_test.h"
> >
> > static void cleanup_freed_objects(struct drm_i915_private *i915)
> > {
> > @@ -1705,6 +1708,229 @@ int i915_gem_gtt_mock_selftests(void)
> > return err;
> > }
> >
> > +static int context_sync(struct intel_context *ce)
> > +{
> > + struct i915_request *rq;
> > + long timeout;
> > +
> > + rq = intel_context_create_request(ce);
> > + if (IS_ERR(rq))
> > + return PTR_ERR(rq);
> > +
> > + i915_request_get(rq);
> > + i915_request_add(rq);
> > +
> > + timeout = i915_request_wait(rq, 0, HZ / 5);
> > + i915_request_put(rq);
> > +
> > + return timeout < 0 ? -EIO : 0;
> > +}
> > +
> > +static int submit_batch(struct intel_context *ce, u64 addr)
> > +{
> > + struct i915_request *rq;
> > + int err;
> > +
> > + rq = intel_context_create_request(ce);
> > + if (IS_ERR(rq))
> > + return PTR_ERR(rq);
> > +
> > + err = 0;
> > + if (rq->engine->emit_init_breadcrumb) /* detect a hang */
>
> for seqno write?
If we expect an initial breadcrumb, we use it during reset to identify
if we are inside a payload (as opposed to being inside the semaphore
wait). So we need to emit the breadcrumb if we may hang in our batch.
> > + err = rq->engine->emit_init_breadcrumb(rq);
> > + if (err == 0)
> > + err = rq->engine->emit_bb_start(rq, addr, 0, 0);
> > +
>
> In context_sync part we grabbed a reference. In here we
> don't. I don't see how we can get away without it even
> if we don't wait in here.
Hmm, I suppose you can argue that we do now have a later deref in the
spinner. That wasn't there before...
> > + vma = i915_vma_instance(out, vm, NULL);
> > + if (IS_ERR(vma)) {
> > + err = PTR_ERR(vma);
> > + goto out_batch;
> > + }
> > +
> > + err = i915_vma_pin(vma, 0, 0,
> > +PIN_USER |
> > +PIN_OFFSET_FIXED |
> > +(vm->total - PAGE_SIZE));
> > + if (err)
> > + goto out_out;
>
> out_put?
Joonas likes out: for normal exit paths that double for error handling.
> Oh and we don't have to do anything with the instance on
> error paths?
No. The vma does not yet have an independent lifetime from the object
(they are all owned by objects currently).
> > + /* Replace the TLB with target batches */
> > + for (i = 0; i < count; i++) {
> > + u32 *cs = batch + i * 64 / sizeof(*cs);
> > + u64 addr;
> > +
> > + vma->node.start = offset + i * PAGE_SIZE;
>
> on previous loop, we have now primed the pte to tlb in here?
We're using the same PTE as before, in the expectation that the TLB
still contains that lookup.
> > + vm->insert_entries(vm, vma, I915_CACHE_NONE,
> > 0);
>
> ..now changing in it here...
>
> > +
> > + addr = vma->node.start + i * 64;
> > + cs[4] = MI_NOOP;
> > + cs[6] = lower_32_bits(addr);
> > + cs[7] = upper_32_bits(addr);
> > + wmb();
> > +
> > + err = submit_batch(ce, addr);
>
> in hope that with this submission hardware will see the old one and
> completely miss the store+bb start?
The hope is we see the right page of course! The test is to detect when
it sees the old page instead.
> Perhaps rewiring a more dummy emit only to prove this case
> is pushing it.
>
> But I am curious to know if you did try it out by removing
> the invalidate on the emits and managed to bring
> out the missing writes?
We can demonstrate it on Tigerlake :)
Indeed it detects the remove of MI_INVALIDATE_TLB elsewhere.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-
Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Don't advertise modes that exceed the max plane size
On Wed, Sep 18, 2019 at 04:21:06PM -0400, Sean Paul wrote: > On Wed, Sep 18, 2019 at 07:02:18PM +0300, Ville Syrjälä wrote: > > On Wed, Sep 18, 2019 at 11:24:09AM -0400, Sean Paul wrote: > > > On Wed, Sep 18, 2019 at 06:07:07PM +0300, Ville Syrjala wrote: > > > > From: Ville Syrjälä > > > > > > > > Modern platforms allow the transcoders hdisplay/vdisplay to exceed the > > > > planes' max resolution. This has the nasty implication that modes on the > > > > connectors' mode list may not be usable when the user asks for a > > > > fullscreen plane. Seeing as that is the most common use case it seems > > > > prudent to filter out modes that don't allow for fullscreen planes to > > > > be enabled. > > > > > > > > Let's do that in the connetor .mode_valid() hook so that normally > > > > such modes are kept hidden but the user is still able to forcibly > > > > specify such a mode if they know they don't need fullscreen planes. > > > > > > > > This is in line with ealier policies regarding certain clock limits. > > > > The idea is to prevent the casual user from encountering a mode that > > > > would fail under typical conditions, but allow the expert user to > > > > force things if they so wish. > > > > > > Isn't this exactly what atomic_check is for? Why not just add a debug > > > message in > > > get_max_plane_size to leave a breadcrumb? > > > > There's already a debug message. Won't really help when the screen fails > > to light up automagically on account of the preferred mode being too > > big. > > That's not the kernel's fault, why are we working around it at this level? > There > are lots of reasons beyond max plane size that can cause a modeset to fail. If > userspace doesn't already have the smarts to fallback to a lower resolution on > modeset failure, we should fix it or just ¯\_(ツ)_/¯ Sure, userspace (and fb_helper) should be smarter about this. Unfortunately I don't have a time machine to deploy such a backport so this is the best I can do for current userspace. -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise CS TLB invalidation
Check that we are correctly invalidating the TLB at the start of a
batch after updating the GTT.
v2: Comments and hold the request reference while spinning
Signed-off-by: Chris Wilson
Cc: Mika Kuoppala
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 308 ++
1 file changed, 308 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
index 598c18d10640..aa7be9089e2d 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
@@ -25,13 +25,16 @@
#include
#include
+#include "gem/i915_gem_context.h"
#include "gem/selftests/mock_context.h"
+#include "gt/intel_context.h"
#include "i915_random.h"
#include "i915_selftest.h"
#include "mock_drm.h"
#include "mock_gem_device.h"
+#include "igt_flush_test.h"
static void cleanup_freed_objects(struct drm_i915_private *i915)
{
@@ -1705,6 +1708,310 @@ int i915_gem_gtt_mock_selftests(void)
return err;
}
+static int context_sync(struct intel_context *ce)
+{
+ struct i915_request *rq;
+ long timeout;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return PTR_ERR(rq);
+
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ timeout = i915_request_wait(rq, 0, HZ / 5);
+ i915_request_put(rq);
+
+ return timeout < 0 ? -EIO : 0;
+}
+
+static struct i915_request *
+submit_batch(struct intel_context *ce, u64 addr)
+{
+ struct i915_request *rq;
+ int err;
+
+ rq = intel_context_create_request(ce);
+ if (IS_ERR(rq))
+ return rq;
+
+ err = 0;
+ if (rq->engine->emit_init_breadcrumb) /* detect a hang */
+ err = rq->engine->emit_init_breadcrumb(rq);
+ if (err == 0)
+ err = rq->engine->emit_bb_start(rq, addr, 0, 0);
+
+ if (err == 0)
+ i915_request_get(rq);
+ i915_request_add(rq);
+
+ return err ? ERR_PTR(err) : rq;
+}
+
+static u32 *spinner(u32 *batch, int i)
+{
+ return batch + i * 64 / sizeof(*batch) + 4;
+}
+
+static void end_spin(u32 *batch, int i)
+{
+ *spinner(batch, i) = MI_BATCH_BUFFER_END;
+ wmb();
+}
+
+static int igt_cs_tlb(void *arg)
+{
+ const unsigned int count = PAGE_SIZE / 64;
+ const unsigned int chunk_size = count * PAGE_SIZE;
+ struct drm_i915_private *i915 = arg;
+ struct drm_i915_gem_object *bbe, *act, *out;
+ struct i915_gem_engines_iter it;
+ struct i915_address_space *vm;
+ struct i915_gem_context *ctx;
+ struct intel_context *ce;
+ struct drm_file *file;
+ struct i915_vma *vma;
+ unsigned int i;
+ u32 *result;
+ u32 *batch;
+ int err = 0;
+
+ /*
+* Our mission here is to fool the hardware to execute something
+* from scratch as it has not seen the batch move (due to missing
+* the TLB invalidate).
+*/
+
+ file = mock_file(i915);
+ if (IS_ERR(file))
+ return PTR_ERR(file);
+
+ mutex_lock(&i915->drm.struct_mutex);
+ ctx = live_context(i915, file);
+ if (IS_ERR(ctx)) {
+ err = PTR_ERR(ctx);
+ goto out_unlock;
+ }
+
+ vm = ctx->vm;
+ if (!vm)
+ goto out_unlock;
+
+ /* Create two pages; dummy we prefill the TLB, and intended */
+ bbe = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(bbe)) {
+ err = PTR_ERR(bbe);
+ goto out_unlock;
+ }
+
+ batch = i915_gem_object_pin_map(bbe, I915_MAP_WC);
+ if (IS_ERR(batch)) {
+ err = PTR_ERR(batch);
+ goto out_bbe;
+ }
+ memset32(batch, MI_BATCH_BUFFER_END, PAGE_SIZE / sizeof(u32));
+ i915_gem_object_flush_map(bbe);
+ i915_gem_object_unpin_map(bbe);
+
+ act = i915_gem_object_create_internal(i915, PAGE_SIZE);
+ if (IS_ERR(act)) {
+ err = PTR_ERR(act);
+ goto out_bbe;
+ }
+
+ /* Track the execution of each request by writing into different slot */
+ batch = i915_gem_object_pin_map(act, I915_MAP_WC);
+ if (IS_ERR(batch)) {
+ err = PTR_ERR(batch);
+ goto out_act;
+ }
+ for (i = 0; i < count; i++) {
+ u32 *cs = batch + i * 64 / sizeof(*cs);
+ u64 addr = (vm->total - PAGE_SIZE) + i * sizeof(u32);
+
+ GEM_BUG_ON(INTEL_GEN(i915) < 6);
+ cs[0] = MI_STORE_DWORD_IMM_GEN4;
+ if (INTEL_GEN(i915) >= 8) {
+ cs[1] = lower_32_bits(addr);
+ cs[2] = upper_32_bits(addr);
+ cs[3] = i;
+ cs[4] = MI_NOOP;
+ cs[5] = MI_BATCH_BUFFER_START_GEN8;
+ } else {
+ cs[1] = 0;
+
Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
Quoting Tvrtko Ursulin (2019-09-19 14:02:19)
>
> On 19/09/2019 12:19, Chris Wilson wrote:
> > +static struct intel_timeline *get_timeline(struct i915_request *rq)
> > +{
> > + struct intel_timeline *tl;
> > +
> > + /*
> > + * Even though we are holding the engine->active.lock here, there
> > + * is no control over the submission queue per-se and we are
> > + * inspecting the active state at a random point in time, with an
> > + * unknown queue. Play safe and make sure the timeline remains valid.
> > + * (Only being used for pretty printing, one extra kref shouldn't
> > + * cause a camel stampede!)
> > + */
> > + rcu_read_lock();
> > + tl = rcu_dereference(rq->timeline);
> > + if (!kref_get_unless_zero(&tl->kref))
> > + tl = NULL;
> > + rcu_read_unlock();
>
> How can it be NULL under the active lock? Isn't that the same assertion
> from i915_timeline_get_active.
Not NULL, but retired. The difference is that during submission we know
that this request's context/timeline must be currently pinned until
a subsequent request (containing the idle-barriers) is submitted. The
danger I worry about here is that subsequent idle request may be already
submitted and since the queued requests may *already* have been retired,
the timeline may be unpinned and indeed dropped it's last reference.
> > diff --git a/drivers/gpu/drm/i915/gt/selftest_context.c
> > b/drivers/gpu/drm/i915/gt/selftest_context.c
> > index 9d1ea26c7a2d..4ce1e25433d2 100644
> > --- a/drivers/gpu/drm/i915/gt/selftest_context.c
> > +++ b/drivers/gpu/drm/i915/gt/selftest_context.c
> > @@ -14,22 +14,28 @@
> >
> > static int request_sync(struct i915_request *rq)
> > {
> > + struct intel_timeline *tl = i915_request_timeline(rq);
> > long timeout;
> > int err = 0;
> >
> > + intel_timeline_get(tl);
> > i915_request_get(rq);
> >
> > - i915_request_add(rq);
> > + /* Opencode i915_request_add() so we can keep the timeline locked. */
> > + __i915_request_commit(rq);
> > + __i915_request_queue(rq, NULL);
>
> Looking at i915_request_add here we also have tasklet kicking but I
> guess for selftests it's not important.
Yup, and immediately before a wait, that tasklet should be scheduled
naturally in the near future.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] video/hdmi: Fix AVI bar unpack
From: Ville Syrjälä
The bar values are little endian, not big endian. The pack
function did it right but the unpack got it wrong. Fix it.
Cc: sta...@vger.kernel.org
Cc: linux-me...@vger.kernel.org
Cc: Martin Bugge
Cc: Hans Verkuil
Cc: Thierry Reding
Cc: Mauro Carvalho Chehab
Fixes: 2c676f378edb ("[media] hdmi: added unpack and logging functions for
InfoFrames")
Signed-off-by: Ville Syrjälä
---
drivers/video/hdmi.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/video/hdmi.c b/drivers/video/hdmi.c
index b939bc28d886..9c82e2a0a411 100644
--- a/drivers/video/hdmi.c
+++ b/drivers/video/hdmi.c
@@ -1576,12 +1576,12 @@ static int hdmi_avi_infoframe_unpack(struct
hdmi_avi_infoframe *frame,
if (ptr[0] & 0x10)
frame->active_aspect = ptr[1] & 0xf;
if (ptr[0] & 0x8) {
- frame->top_bar = (ptr[5] << 8) + ptr[6];
- frame->bottom_bar = (ptr[7] << 8) + ptr[8];
+ frame->top_bar = (ptr[6] << 8) | ptr[5];
+ frame->bottom_bar = (ptr[8] << 8) | ptr[7];
}
if (ptr[0] & 0x4) {
- frame->left_bar = (ptr[9] << 8) + ptr[10];
- frame->right_bar = (ptr[11] << 8) + ptr[12];
+ frame->left_bar = (ptr[10] << 8) | ptr[9];
+ frame->right_bar = (ptr[12] << 8) | ptr[11];
}
frame->scan_mode = ptr[0] & 0x3;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/21] drm/i915: Pull i915_vma_pin under the vm->mutex
On 17/09/2019 19:56, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-09-17 13:37:55)
On 02/09/2019 05:02, Chris Wilson wrote:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
index 82db2b783123..9a8c307c5aeb 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_mman.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_mman.c
@@ -251,16 +251,6 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
goto err_rpm;
}
- ret = i915_mutex_lock_interruptible(dev);
- if (ret)
- goto err_reset;
-
- /* Access to snoopable pages through the GTT is incoherent. */
- if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(i915)) {
- ret = -EFAULT;
- goto err_unlock;
- }
-
/* Now pin it into the GTT as needed */
vma = i915_gem_object_ggtt_pin(obj, NULL, 0, 0,
PIN_MAPPABLE |
@@ -293,7 +283,13 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
}
if (IS_ERR(vma)) {
ret = PTR_ERR(vma);
- goto err_unlock;
+ goto err_reset;
+ }
+
+ /* Access to snoopable pages through the GTT is incoherent. */
+ if (obj->cache_level != I915_CACHE_NONE && !HAS_LLC(i915)) {
+ ret = -EFAULT;
+ goto err_unpin;
}
Why have you moved this check to after pinning?
Since we've dropped the lock around this check, the intent is to use the
pin as a guarantee that the vma cannot be changed. What we actually want
here, for clarity, is vma->cache_level.
ret = i915_vma_pin_fence(vma);
@@ -321,14 +317,12 @@ vm_fault_t i915_gem_fault(struct vm_fault *vmf)
intel_wakeref_auto(&i915->ggtt.userfault_wakeref,
msecs_to_jiffies_timeout(CONFIG_DRM_I915_USERFAULT_AUTOSUSPEND));
- i915_vma_set_ggtt_write(vma);
-
+ if (write)
+ i915_vma_set_ggtt_write(vma);
Noise for what this patch is concerned?
Yeah, I had to stare at an incorrect __set_bit(GGTT_WRITE) for too long.
err_fence:
i915_vma_unpin_fence(vma);
err_unpin:
__i915_vma_unpin(vma);
-err_unlock:
- mutex_unlock(&dev->struct_mutex);
err_reset:
intel_gt_reset_unlock(ggtt->vm.gt, srcu);
err_rpm:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index 0ef60dae23a7..dbf9be9a79f4 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -155,21 +155,30 @@ static void __i915_gem_free_objects(struct
drm_i915_private *i915,
wakeref = intel_runtime_pm_get(&i915->runtime_pm);
llist_for_each_entry_safe(obj, on, freed, freed) {
- struct i915_vma *vma, *vn;
-
trace_i915_gem_object_destroy(obj);
- mutex_lock(&i915->drm.struct_mutex);
-
- list_for_each_entry_safe(vma, vn, &obj->vma.list, obj_link) {
- GEM_BUG_ON(i915_vma_is_active(vma));
- atomic_and(~I915_VMA_PIN_MASK, &vma->flags);
- i915_vma_destroy(vma);
+ if (!list_empty(&obj->vma.list)) {
+ struct i915_vma *vma;
+
+ /*
+ * Note that the vma keeps an object reference while
+ * it is active, so it *should* not sleep while we
+ * destroy it. Our debug code errs insits it *might*.
+ * For the moment, play along.
+ */
+ spin_lock(&obj->vma.lock);
+ while ((vma = list_first_entry_or_null(&obj->vma.list,
+struct i915_vma,
+obj_link)))
What is the point of having a while loop inside top-level if !list_empty
check? Looks theoretically racy, and even if that is irrelevant, it
would be clearer to just do the while loop.
We can't add more vma to the object, as there are no more refs to the
object. The challenge is in dropping the links. In the end it makes no
difference, it's an unlocked compare before the spinlock (and ugly
loop).
I was simply thinking it would be one indent level less for readability
both on the visual and conceptual level. But doesn't matter hugely.
GEM_BUG_ON(!drm_mm_node_allocated(&vma->node));
+ GEM_BUG_ON(vma->pages);
vma->pages = obj->mm.pages;
+ atomic_set(&vma->pages_count, I915_VMA_PAGES_ACTIVE);
What is I915_VMA_PAGES_ACTIVE used for? Pinned? Has pages?
It's a counter for the number of unique binds as opposed to callers
merely acquiring the pages prior to binding; so that we can balance
vma_unbind_pages() which is called once (i915_vma_unbind) but
i915_vma_bind() can be called for both PIN_GLOBAL and PIN_USER.
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_tiling.c
b/drivers/gpu/drm/i
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise CS TLB invalidation
Chris Wilson writes:
> Quoting Mika Kuoppala (2019-09-19 13:57:45)
>> Chris Wilson writes:
>>
>> > Check that we are correctly invalidating the TLB at the start of a
>> > batch after updating the GTT.
>> >
>> > Signed-off-by: Chris Wilson
>> > Cc: Mika Kuoppala
>> > Cc: Daniele Ceraolo Spurio
>> > ---
>> > drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 227 ++
>> > 1 file changed, 227 insertions(+)
>> >
>> > diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> > b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> > index 598c18d10640..f8709b332bd7 100644
>> > --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> > +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
>> > @@ -25,13 +25,16 @@
>> > #include
>> > #include
>> >
>> > +#include "gem/i915_gem_context.h"
>> > #include "gem/selftests/mock_context.h"
>> > +#include "gt/intel_context.h"
>> >
>> > #include "i915_random.h"
>> > #include "i915_selftest.h"
>> >
>> > #include "mock_drm.h"
>> > #include "mock_gem_device.h"
>> > +#include "igt_flush_test.h"
>> >
>> > static void cleanup_freed_objects(struct drm_i915_private *i915)
>> > {
>> > @@ -1705,6 +1708,229 @@ int i915_gem_gtt_mock_selftests(void)
>> > return err;
>> > }
>> >
>> > +static int context_sync(struct intel_context *ce)
>> > +{
>> > + struct i915_request *rq;
>> > + long timeout;
>> > +
>> > + rq = intel_context_create_request(ce);
>> > + if (IS_ERR(rq))
>> > + return PTR_ERR(rq);
>> > +
>> > + i915_request_get(rq);
>> > + i915_request_add(rq);
>> > +
>> > + timeout = i915_request_wait(rq, 0, HZ / 5);
>> > + i915_request_put(rq);
>> > +
>> > + return timeout < 0 ? -EIO : 0;
>> > +}
>> > +
>> > +static int submit_batch(struct intel_context *ce, u64 addr)
>> > +{
>> > + struct i915_request *rq;
>> > + int err;
>> > +
>> > + rq = intel_context_create_request(ce);
>> > + if (IS_ERR(rq))
>> > + return PTR_ERR(rq);
>> > +
>> > + err = 0;
>> > + if (rq->engine->emit_init_breadcrumb) /* detect a hang */
>>
>> for seqno write?
>
> If we expect an initial breadcrumb, we use it during reset to identify
> if we are inside a payload (as opposed to being inside the semaphore
> wait). So we need to emit the breadcrumb if we may hang in our batch.
>
>> > + err = rq->engine->emit_init_breadcrumb(rq);
>> > + if (err == 0)
>> > + err = rq->engine->emit_bb_start(rq, addr, 0, 0);
>> > +
>>
>> In context_sync part we grabbed a reference. In here we
>> don't. I don't see how we can get away without it even
>> if we don't wait in here.
>
> Hmm, I suppose you can argue that we do now have a later deref in the
> spinner. That wasn't there before...
>
>> > + vma = i915_vma_instance(out, vm, NULL);
>> > + if (IS_ERR(vma)) {
>> > + err = PTR_ERR(vma);
>> > + goto out_batch;
>> > + }
>> > +
>> > + err = i915_vma_pin(vma, 0, 0,
>> > +PIN_USER |
>> > +PIN_OFFSET_FIXED |
>> > +(vm->total - PAGE_SIZE));
>> > + if (err)
>> > + goto out_out;
>>
>> out_put?
>
> Joonas likes out: for normal exit paths that double for error handling.
Ok. Fine with me. I just like the last part to describe what the first part
of onion out does. Don't have to so much scroll back and forth
in editor.
>
>> Oh and we don't have to do anything with the instance on
>> error paths?
>
> No. The vma does not yet have an independent lifetime from the object
> (they are all owned by objects currently).
>
>> > + /* Replace the TLB with target batches */
>> > + for (i = 0; i < count; i++) {
>> > + u32 *cs = batch + i * 64 / sizeof(*cs);
>> > + u64 addr;
>> > +
>> > + vma->node.start = offset + i * PAGE_SIZE;
>>
>> on previous loop, we have now primed the pte to tlb in here?
>
> We're using the same PTE as before, in the expectation that the TLB
> still contains that lookup.
>
>> > + vm->insert_entries(vm, vma, I915_CACHE_NONE,
>> > 0);
>>
>> ..now changing in it here...
>>
>> > +
>> > + addr = vma->node.start + i * 64;
>> > + cs[4] = MI_NOOP;
>> > + cs[6] = lower_32_bits(addr);
>> > + cs[7] = upper_32_bits(addr);
>> > + wmb();
>> > +
>> > + err = submit_batch(ce, addr);
>>
>> in hope that with this submission hardware will see the old one and
>> completely miss the store+bb start?
>
> The hope is we see the right page of course! The test is to detect when
> it sees the old page instead.
Right, I guess it just depends who is hoping wrt to outcome =)
>
>> Perhaps rewiring a more dummy emit only to prove this case
>> is pushing it.
>>
>>
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Exercise CS TLB invalidation
Chris Wilson writes:
> Check that we are correctly invalidating the TLB at the start of a
> batch after updating the GTT.
>
> v2: Comments and hold the request reference while spinning
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Daniele Ceraolo Spurio
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 308 ++
> 1 file changed, 308 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> index 598c18d10640..aa7be9089e2d 100644
> --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c
> @@ -25,13 +25,16 @@
> #include
> #include
>
> +#include "gem/i915_gem_context.h"
> #include "gem/selftests/mock_context.h"
> +#include "gt/intel_context.h"
>
> #include "i915_random.h"
> #include "i915_selftest.h"
>
> #include "mock_drm.h"
> #include "mock_gem_device.h"
> +#include "igt_flush_test.h"
>
> static void cleanup_freed_objects(struct drm_i915_private *i915)
> {
> @@ -1705,6 +1708,310 @@ int i915_gem_gtt_mock_selftests(void)
> return err;
> }
>
> +static int context_sync(struct intel_context *ce)
> +{
> + struct i915_request *rq;
> + long timeout;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return PTR_ERR(rq);
> +
> + i915_request_get(rq);
> + i915_request_add(rq);
> +
> + timeout = i915_request_wait(rq, 0, HZ / 5);
> + i915_request_put(rq);
> +
> + return timeout < 0 ? -EIO : 0;
> +}
> +
> +static struct i915_request *
> +submit_batch(struct intel_context *ce, u64 addr)
> +{
> + struct i915_request *rq;
> + int err;
> +
> + rq = intel_context_create_request(ce);
> + if (IS_ERR(rq))
> + return rq;
> +
> + err = 0;
> + if (rq->engine->emit_init_breadcrumb) /* detect a hang */
> + err = rq->engine->emit_init_breadcrumb(rq);
> + if (err == 0)
> + err = rq->engine->emit_bb_start(rq, addr, 0, 0);
> +
> + if (err == 0)
> + i915_request_get(rq);
> + i915_request_add(rq);
> +
> + return err ? ERR_PTR(err) : rq;
> +}
> +
> +static u32 *spinner(u32 *batch, int i)
> +{
> + return batch + i * 64 / sizeof(*batch) + 4;
> +}
> +
> +static void end_spin(u32 *batch, int i)
> +{
> + *spinner(batch, i) = MI_BATCH_BUFFER_END;
> + wmb();
> +}
> +
> +static int igt_cs_tlb(void *arg)
> +{
> + const unsigned int count = PAGE_SIZE / 64;
> + const unsigned int chunk_size = count * PAGE_SIZE;
> + struct drm_i915_private *i915 = arg;
> + struct drm_i915_gem_object *bbe, *act, *out;
> + struct i915_gem_engines_iter it;
> + struct i915_address_space *vm;
> + struct i915_gem_context *ctx;
> + struct intel_context *ce;
> + struct drm_file *file;
> + struct i915_vma *vma;
> + unsigned int i;
> + u32 *result;
> + u32 *batch;
> + int err = 0;
> +
> + /*
> + * Our mission here is to fool the hardware to execute something
> + * from scratch as it has not seen the batch move (due to missing
> + * the TLB invalidate).
> + */
> +
> + file = mock_file(i915);
> + if (IS_ERR(file))
> + return PTR_ERR(file);
> +
> + mutex_lock(&i915->drm.struct_mutex);
> + ctx = live_context(i915, file);
> + if (IS_ERR(ctx)) {
> + err = PTR_ERR(ctx);
> + goto out_unlock;
> + }
> +
> + vm = ctx->vm;
> + if (!vm)
> + goto out_unlock;
> +
> + /* Create two pages; dummy we prefill the TLB, and intended */
> + bbe = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + if (IS_ERR(bbe)) {
> + err = PTR_ERR(bbe);
> + goto out_unlock;
> + }
> +
> + batch = i915_gem_object_pin_map(bbe, I915_MAP_WC);
> + if (IS_ERR(batch)) {
> + err = PTR_ERR(batch);
> + goto out_bbe;
> + }
> + memset32(batch, MI_BATCH_BUFFER_END, PAGE_SIZE / sizeof(u32));
> + i915_gem_object_flush_map(bbe);
> + i915_gem_object_unpin_map(bbe);
> +
> + act = i915_gem_object_create_internal(i915, PAGE_SIZE);
> + if (IS_ERR(act)) {
> + err = PTR_ERR(act);
> + goto out_bbe;
> + }
> +
> + /* Track the execution of each request by writing into different slot */
> + batch = i915_gem_object_pin_map(act, I915_MAP_WC);
> + if (IS_ERR(batch)) {
> + err = PTR_ERR(batch);
> + goto out_act;
> + }
> + for (i = 0; i < count; i++) {
> + u32 *cs = batch + i * 64 / sizeof(*cs);
> + u64 addr = (vm->total - PAGE_SIZE) + i * sizeof(u32);
> +
> + GEM_BUG_ON(INTEL_GEN(i915) < 6);
> + cs[0] = MI_STORE_DWORD_IMM_GEN4;
> + if (INTEL_GEN(i915) >= 8) {
> + cs[1] = lower_32_bits(addr);
> + cs[2] = upper_32_bits(addr);
> +
Re: [Intel-gfx] [PATCH] drm/i915/selftests: Exercise CS TLB invalidation
Quoting Mika Kuoppala (2019-09-19 14:39:59)
> Chris Wilson writes:
>
> > Quoting Mika Kuoppala (2019-09-19 13:57:45)
> >> Chris Wilson writes:
> >> > + vma = i915_vma_instance(out, vm, NULL);
> >> > + if (IS_ERR(vma)) {
> >> > + err = PTR_ERR(vma);
> >> > + goto out_batch;
> >> > + }
> >> > +
> >> > + err = i915_vma_pin(vma, 0, 0,
> >> > +PIN_USER |
> >> > +PIN_OFFSET_FIXED |
> >> > +(vm->total - PAGE_SIZE));
> >> > + if (err)
> >> > + goto out_out;
> >>
> >> out_put?
> >
> > Joonas likes out: for normal exit paths that double for error handling.
>
> Ok. Fine with me. I just like the last part to describe what the first part
> of onion out does. Don't have to so much scroll back and forth
> in editor.
Oh, I didn't notice I had a typo. I thought it was out_put!
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
Then it's better that, could we change it to DRM_DEBUG_KMS("failed to update
payload %d\n", ret); instead of DRM_ERROR("failed to update payload %d\n",
ret);, without any connector status check, would that be fine?
Regards,
-Original Message-
From: Ville Syrjälä
Sent: Thursday, September 19, 2019 5:34 PM
To: S, Srinivasan
Cc: Navare, Manasi D ;
intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging TypeC cable
On Thu, Sep 19, 2019 at 07:23:30AM +, S, Srinivasan wrote:
> Would the following be appropriate fix?
>
> if (connector || connector->base.status ==
> connector_status_connected) {
> ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> if (ret) {
> DRM_ERROR("failed to update payload %d\n", ret);
> }
> }
The whole connector->status check is racy. IMO don't do it.
>
> Regards,
> -Original Message-
> From: dri-devel On Behalf Of
> Manasi Navare
> Sent: Wednesday, September 18, 2019 11:55 PM
> To: Ville Syrjälä
> Cc: S, Srinivasan ;
> intel-gfx@lists.freedesktop.org; dri-de...@lists.freedesktop.org
> Subject: Re: [PATCH] drm/i915/dp: Fix DP MST error after unplugging
> TypeC cable
>
> On Wed, Sep 18, 2019 at 09:11:36PM +0300, Ville Syrjälä wrote:
> > On Wed, Sep 18, 2019 at 10:50:39AM -0700, Manasi Navare wrote:
> > > On Wed, Sep 18, 2019 at 07:09:43AM +0530, srinivasa...@intel.com wrote:
> > > > From: Srinivasan S
> > > >
> > > > This patch avoids DP MST payload error message in dmesg, as it
> > > > is trying to read the payload from the disconnected DP MST device.
> > > > After the unplug the connector status is disconnected and we
> > > > should not be looking for the payload and hence remove the error and
> > > > throw the warning.
> > > >
> > > > This details can be found in:
> > > > https://bugs.freedesktop.org/show_bug.cgi?id=111632
> > >
> > > Please add this link as Bugzilla:
> > > https://bugs.freedesktop.org/show_bug.cgi?id=111632 after the Sign
> > > off statement
> > >
> > > >
> > > > Signed-off-by: Srinivasan S
> > > > ---
> > > > drivers/gpu/drm/i915/display/intel_dp_mst.c | 7 ++-
> > > > 1 file changed, 6 insertions(+), 1 deletion(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > index eeeb3f933aa4..5b2278fdf675 100644
> > > > --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> > > > @@ -215,7 +215,12 @@ static void intel_mst_disable_dp(struct
> > > > intel_encoder *encoder,
> > > >
> > > > ret = drm_dp_update_payload_part1(&intel_dp->mst_mgr);
> > > > if (ret) {
> > > > - DRM_ERROR("failed to update payload %d\n", ret);
> > > > + if (!connector ||
> > > > + connector->base.status !=
> > > > connector_status_connected) {
> > > > + DRM_WARN("DP MST disconnect\n");
> > >
> > > May be adding this check before calling drm_dp_update_payload_part1() is
> > > a better idea?
> > > If the connector is disconnected, why update payload?
> > >
> > > Jani, Ville, thoughts?
> >
> > Or just convert it to a debug?
>
> Sure that will work, but do we really want to update the payload if the
> connector status is disconnected.
> So shouldnt checking that before calling the function be a better fix?
>
> Manasi
>
> >
> > >
> > > Regards
> > > Manasi
> > >
> > > > + } else {
> > > > + DRM_ERROR("failed to update payload %d\n", ret);
> > > > + }
> > > > }
> > > > if (old_crtc_state->has_audio)
> > > > intel_audio_codec_disable(encoder,
> > > > --
> > > > 2.7.4
> > > >
> >
> > --
> > Ville Syrjälä
> > Intel
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
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 TGL TC enabling (rev2)
== Series Details == Series: TGL TC enabling (rev2) URL : https://patchwork.freedesktop.org/series/66695/ State : success == Summary == CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14450_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14450_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-other-chain-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#111325]) +5 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@gem_exec_sched...@preempt-other-chain-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-iclb2/igt@gem_exec_sched...@preempt-other-chain-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-iclb8/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#108566]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl8/igt@i915_susp...@sysfs-reader.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-apl4/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_edge_walk@pipe-b-64x64-left-edge: - shard-apl: [PASS][7] -> [INCOMPLETE][8] ([fdo#103927]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl2/igt@kms_cursor_edge_w...@pipe-b-64x64-left-edge.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-apl8/igt@kms_cursor_edge_w...@pipe-b-64x64-left-edge.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][9] -> [FAIL][10] ([fdo#105363]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl6/igt@kms_f...@flip-vs-expired-vblank.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-glk: [PASS][11] -> [FAIL][12] ([fdo#105363]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-glk7/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-glk1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: - shard-iclb: [PASS][13] -> [FAIL][14] ([fdo#103167]) +4 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [fdo#110403]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl5/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-skl2/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_plane_lowres@pipe-a-tiling-y: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103166]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb6/igt@kms_plane_low...@pipe-a-tiling-y.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-iclb1/igt@kms_plane_low...@pipe-a-tiling-y.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#108341]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb6/igt@kms_psr@no_drrs.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_mmap_cpu: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_cpu.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-iclb1/igt@kms_psr@psr2_sprite_mmap_cpu.html * igt@kms_setmode@basic: - shard-apl: [PASS][23] -> [FAIL][24] ([fdo#99912]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl4/igt@kms_setm...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14450/shard-apl1/igt@kms_setm...@basic.html - shard-hsw: [PASS][25] -> [FAIL][26] ([fdo#99912]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw5/igt@kms_setm...@basic
[Intel-gfx] [PATCH 01/13] drm/i915: add i915_driver_modeset_remove()
For completeness, add counterpart to i915_driver_modeset_probe() and
remove the asymmetry in the probe/remove parts. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 25 +++--
1 file changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 9904f762f4bb..4cb95fd9b35d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -422,6 +422,20 @@ static int i915_driver_modeset_probe(struct drm_device
*dev)
return ret;
}
+static void i915_driver_modeset_remove(struct drm_i915_private *i915)
+{
+ struct pci_dev *pdev = i915->drm.pdev;
+
+ intel_modeset_driver_remove(&i915->drm);
+
+ intel_bios_driver_remove(i915);
+
+ vga_switcheroo_unregister_client(pdev);
+ vga_client_register(pdev, NULL, NULL, NULL);
+
+ intel_csr_ucode_fini(i915);
+}
+
static void intel_init_dpio(struct drm_i915_private *dev_priv)
{
/*
@@ -1586,8 +1600,6 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
void i915_driver_remove(struct drm_i915_private *i915)
{
- struct pci_dev *pdev = i915->drm.pdev;
-
disable_rpm_wakeref_asserts(&i915->runtime_pm);
i915_driver_unregister(i915);
@@ -1608,14 +1620,7 @@ void i915_driver_remove(struct drm_i915_private *i915)
intel_gvt_driver_remove(i915);
- intel_modeset_driver_remove(&i915->drm);
-
- intel_bios_driver_remove(i915);
-
- vga_switcheroo_unregister_client(pdev);
- vga_client_register(pdev, NULL, NULL, NULL);
-
- intel_csr_ucode_fini(i915);
+ i915_driver_modeset_remove(i915);
/* Free error state after interrupts are fully disabled. */
cancel_delayed_work_sync(&i915->gt.hangcheck.work);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 00/13] drm/i915: modeset probe/remove path refactoring
Hi all, I started looking into cleaning up the modeset probe/remove paths. We have a number of issues there. Modeset and non-modeset initialization and cleanup happily mixed up. Initialization and cleanup of various things happen at different layers in the stack. This is tied to the previous patches on display disable / no display. The first 6 patches are really straightforward cleanup. Then things start getting interesting. In general I'm trying to split the init/cleanup to parts before and after irq&gem init/cleanup, so that we can have the irq&gem stuff at the higher level of i915 probe instead of in modeset code. There are several levels of ugliness associated with this. First, naming. (Door open for bikeshedding, yay.) Second, the split init and cleanup are not symmetrical. The init before irq installed does not match the cleanup after irq uninstalled, for various reasons. This is not so bad for overall probe and driver remove in general, but: Third, the probe failure paths are a total mess. They are already now, in many ways, but this doesn't really help, either. So I'm not sure this should be a blocker, but it's not pretty. BR, Jani. Jani Nikula (13): drm/i915: add i915_driver_modeset_remove() drm/i915: pass i915 to i915_driver_modeset_probe() drm/i915: pass i915 to intel_modeset_driver_remove() drm/i915: abstract intel_panel_sanitize_ssc() from intel_modeset_init() drm/i915: abstract intel_mode_config_init() from intel_modeset_init() drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw() drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstall drm/i915: move gmbus setup down to intel_modeset_init() drm/i915: split i915_driver_modeset_probe() to pre/post irq install drm/i915: move gem init up from modeset init drm/i915: push intel_overlay_init() down to intel_modeset_init() drm/i915: split intel_modeset_init() to pre/post irq install drivers/gpu/drm/i915/display/intel_display.c | 249 ++- drivers/gpu/drm/i915/display/intel_display.h | 8 +- drivers/gpu/drm/i915/i915_drv.c | 139 +++ 3 files changed, 225 insertions(+), 171 deletions(-) -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/13] drm/i915: pass i915 to intel_modeset_driver_remove()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. Also propagate
to intel_hpd_poll_fini(). No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 38 ++--
drivers/gpu/drm/i915/display/intel_display.h | 2 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +--
3 files changed, 21 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1cc74844d3ea..c0fc66903fec 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17027,13 +17027,13 @@ void intel_display_resume(struct drm_device *dev)
drm_atomic_state_put(state);
}
-static void intel_hpd_poll_fini(struct drm_device *dev)
+static void intel_hpd_poll_fini(struct drm_i915_private *i915)
{
struct intel_connector *connector;
struct drm_connector_list_iter conn_iter;
/* Kill all the work that may have been queued by hpd. */
- drm_connector_list_iter_begin(dev, &conn_iter);
+ drm_connector_list_iter_begin(&i915->drm, &conn_iter);
for_each_intel_connector_iter(connector, &conn_iter) {
if (connector->modeset_retry_work.func)
cancel_work_sync(&connector->modeset_retry_work);
@@ -17045,51 +17045,49 @@ static void intel_hpd_poll_fini(struct drm_device
*dev)
drm_connector_list_iter_end(&conn_iter);
}
-void intel_modeset_driver_remove(struct drm_device *dev)
+void intel_modeset_driver_remove(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
- flush_workqueue(dev_priv->flip_wq);
- flush_workqueue(dev_priv->modeset_wq);
+ flush_workqueue(i915->flip_wq);
+ flush_workqueue(i915->modeset_wq);
- flush_work(&dev_priv->atomic_helper.free_work);
- WARN_ON(!llist_empty(&dev_priv->atomic_helper.free_list));
+ flush_work(&i915->atomic_helper.free_work);
+ WARN_ON(!llist_empty(&i915->atomic_helper.free_list));
/*
* Interrupts and polling as the first thing to avoid creating havoc.
* Too much stuff here (turning of connectors, ...) would
* experience fancy races otherwise.
*/
- intel_irq_uninstall(dev_priv);
+ intel_irq_uninstall(i915);
/*
* Due to the hpd irq storm handling the hotplug work can re-arm the
* poll handlers. Hence disable polling after hpd handling is shut down.
*/
- intel_hpd_poll_fini(dev);
+ intel_hpd_poll_fini(i915);
/* poll work can call into fbdev, hence clean that up afterwards */
- intel_fbdev_fini(dev_priv);
+ intel_fbdev_fini(i915);
intel_unregister_dsm_handler();
- intel_fbc_global_disable(dev_priv);
+ intel_fbc_global_disable(i915);
/* flush any delayed tasks or pending work */
flush_scheduled_work();
- intel_hdcp_component_fini(dev_priv);
+ intel_hdcp_component_fini(i915);
- drm_mode_config_cleanup(dev);
+ drm_mode_config_cleanup(&i915->drm);
- intel_overlay_cleanup(dev_priv);
+ intel_overlay_cleanup(i915);
- intel_gmbus_teardown(dev_priv);
+ intel_gmbus_teardown(i915);
- destroy_workqueue(dev_priv->flip_wq);
- destroy_workqueue(dev_priv->modeset_wq);
+ destroy_workqueue(i915->flip_wq);
+ destroy_workqueue(i915->modeset_wq);
- intel_fbc_cleanup_cfb(dev_priv);
+ intel_fbc_cleanup_cfb(i915);
}
/*
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 66330fcb10d4..dfa6291f1f37 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -574,7 +574,7 @@ void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
/* modesetting */
void intel_modeset_init_hw(struct drm_device *dev);
int intel_modeset_init(struct drm_device *dev);
-void intel_modeset_driver_remove(struct drm_device *dev);
+void intel_modeset_driver_remove(struct drm_i915_private *i915);
int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool state);
void intel_display_resume(struct drm_device *dev);
void i915_redisable_vga(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 3e4ea5d6fcc2..d9b9e9644f5c 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -407,7 +407,7 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
i915_gem_driver_remove(i915);
i915_gem_driver_release(i915);
cleanup_modeset:
- intel_modeset_driver_remove(&i915->drm);
+ intel_modeset_driver_remove(i915);
cleanup_irq:
intel_irq_uninstall(i915);
intel_gmbus_teardo
[Intel-gfx] [PATCH 05/13] drm/i915: abstract intel_mode_config_init() from intel_modeset_init()
The i915 specific mode config init code is too specific and detailed to
have open in a high level function. Abstract away. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 85 +++-
1 file changed, 46 insertions(+), 39 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index ee0d34d76b08..040ee006b047 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16100,6 +16100,50 @@ static int intel_initial_commit(struct drm_device *dev)
return ret;
}
+static void intel_mode_config_init(struct drm_i915_private *i915)
+{
+ struct drm_mode_config *mode_config = &i915->drm.mode_config;
+
+ mode_config->min_width = 0;
+ mode_config->min_height = 0;
+
+ mode_config->preferred_depth = 24;
+ mode_config->prefer_shadow = 1;
+
+ mode_config->allow_fb_modifiers = true;
+
+ mode_config->funcs = &intel_mode_funcs;
+
+ /*
+* Maximum framebuffer dimensions, chosen to match
+* the maximum render engine surface size on gen4+.
+*/
+ if (INTEL_GEN(i915) >= 7) {
+ mode_config->max_width = 16384;
+ mode_config->max_height = 16384;
+ } else if (INTEL_GEN(i915) >= 4) {
+ mode_config->max_width = 8192;
+ mode_config->max_height = 8192;
+ } else if (IS_GEN(i915, 3)) {
+ mode_config->max_width = 4096;
+ mode_config->max_height = 4096;
+ } else {
+ mode_config->max_width = 2048;
+ mode_config->max_height = 2048;
+ }
+
+ if (IS_I845G(i915) || IS_I865G(i915)) {
+ mode_config->cursor_width = IS_I845G(i915) ? 64 : 512;
+ mode_config->cursor_height = 1023;
+ } else if (IS_GEN(i915, 2)) {
+ mode_config->cursor_width = 64;
+ mode_config->cursor_height = 64;
+ } else {
+ mode_config->cursor_width = 256;
+ mode_config->cursor_height = 256;
+ }
+}
+
int intel_modeset_init(struct drm_device *dev)
{
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -16113,20 +16157,12 @@ int intel_modeset_init(struct drm_device *dev)
drm_mode_config_init(dev);
+ intel_mode_config_init(dev_priv);
+
ret = intel_bw_init(dev_priv);
if (ret)
return ret;
- dev->mode_config.min_width = 0;
- dev->mode_config.min_height = 0;
-
- dev->mode_config.preferred_depth = 24;
- dev->mode_config.prefer_shadow = 1;
-
- dev->mode_config.allow_fb_modifiers = true;
-
- dev->mode_config.funcs = &intel_mode_funcs;
-
init_llist_head(&dev_priv->atomic_helper.free_list);
INIT_WORK(&dev_priv->atomic_helper.free_work,
intel_atomic_helper_free_state_worker);
@@ -16139,35 +16175,6 @@ int intel_modeset_init(struct drm_device *dev)
intel_panel_sanitize_ssc(dev_priv);
- /*
-* Maximum framebuffer dimensions, chosen to match
-* the maximum render engine surface size on gen4+.
-*/
- if (INTEL_GEN(dev_priv) >= 7) {
- dev->mode_config.max_width = 16384;
- dev->mode_config.max_height = 16384;
- } else if (INTEL_GEN(dev_priv) >= 4) {
- dev->mode_config.max_width = 8192;
- dev->mode_config.max_height = 8192;
- } else if (IS_GEN(dev_priv, 3)) {
- dev->mode_config.max_width = 4096;
- dev->mode_config.max_height = 4096;
- } else {
- dev->mode_config.max_width = 2048;
- dev->mode_config.max_height = 2048;
- }
-
- if (IS_I845G(dev_priv) || IS_I865G(dev_priv)) {
- dev->mode_config.cursor_width = IS_I845G(dev_priv) ? 64 : 512;
- dev->mode_config.cursor_height = 1023;
- } else if (IS_GEN(dev_priv, 2)) {
- dev->mode_config.cursor_width = 64;
- dev->mode_config.cursor_height = 64;
- } else {
- dev->mode_config.cursor_width = 256;
- dev->mode_config.cursor_height = 256;
- }
-
DRM_DEBUG_KMS("%d display pipe%s available.\n",
INTEL_NUM_PIPES(dev_priv),
INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/13] drm/i915: abstract intel_panel_sanitize_ssc() from intel_modeset_init()
The code is too specific and detailed to have open in a high level
function. Abstract away. As a drive-by improvement switch to using
enableddisabled() in logging. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 39 +++-
1 file changed, 22 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index c0fc66903fec..ee0d34d76b08 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7539,6 +7539,27 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
constant_n);
}
+static void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
+{
+ /*
+* There may be no VBT; and if the BIOS enabled SSC we can
+* just keep using it to avoid unnecessary flicker. Whereas if the
+* BIOS isn't using it, don't assume it will work even if the VBT
+* indicates as much.
+*/
+ if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)) {
+ bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
+ DREF_SSC1_ENABLE);
+
+ if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
+ DRM_DEBUG_KMS("SSC %s by BIOS, overriding VBT which
says %s\n",
+ enableddisabled(bios_lvds_use_ssc),
+
enableddisabled(dev_priv->vbt.lvds_use_ssc));
+ dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
+ }
+ }
+}
+
static inline bool intel_panel_use_ssc(struct drm_i915_private *dev_priv)
{
if (i915_modparams.panel_use_ssc >= 0)
@@ -16116,23 +16137,7 @@ int intel_modeset_init(struct drm_device *dev)
intel_init_pm(dev_priv);
- /*
-* There may be no VBT; and if the BIOS enabled SSC we can
-* just keep using it to avoid unnecessary flicker. Whereas if the
-* BIOS isn't using it, don't assume it will work even if the VBT
-* indicates as much.
-*/
- if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)) {
- bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
- DREF_SSC1_ENABLE);
-
- if (dev_priv->vbt.lvds_use_ssc != bios_lvds_use_ssc) {
- DRM_DEBUG_KMS("SSC %sabled by BIOS, overriding VBT
which says %sabled\n",
-bios_lvds_use_ssc ? "en" : "dis",
-dev_priv->vbt.lvds_use_ssc ? "en" : "dis");
- dev_priv->vbt.lvds_use_ssc = bios_lvds_use_ssc;
- }
- }
+ intel_panel_sanitize_ssc(dev_priv);
/*
* Maximum framebuffer dimensions, chosen to match
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/13] drm/i915: pass i915 to i915_driver_modeset_probe()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variable to i915. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 59 -
1 file changed, 29 insertions(+), 30 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4cb95fd9b35d..3e4ea5d6fcc2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -329,23 +329,22 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
};
-static int i915_driver_modeset_probe(struct drm_device *dev)
+static int i915_driver_modeset_probe(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
- struct pci_dev *pdev = dev_priv->drm.pdev;
+ struct pci_dev *pdev = i915->drm.pdev;
int ret;
- if (i915_inject_probe_failure(dev_priv))
+ if (i915_inject_probe_failure(i915))
return -ENODEV;
- if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
- ret = drm_vblank_init(&dev_priv->drm,
- INTEL_NUM_PIPES(dev_priv));
+ if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
+ ret = drm_vblank_init(&i915->drm,
+ INTEL_NUM_PIPES(i915));
if (ret)
goto out;
}
- intel_bios_init(dev_priv);
+ intel_bios_init(i915);
/* If we have > 1 VGA cards, then we need to arbitrate access
* to the common VGA resources.
@@ -354,7 +353,7 @@ static int i915_driver_modeset_probe(struct drm_device *dev)
* then we do not take part in VGA arbitration and the
* vga_client_register() fails with -ENODEV.
*/
- ret = vga_client_register(pdev, dev_priv, NULL, i915_vga_set_decode);
+ ret = vga_client_register(pdev, i915, NULL, i915_vga_set_decode);
if (ret && ret != -ENODEV)
goto out;
@@ -365,56 +364,56 @@ static int i915_driver_modeset_probe(struct drm_device
*dev)
goto cleanup_vga_client;
/* must happen before intel_power_domains_init_hw() on VLV/CHV */
- intel_update_rawclk(dev_priv);
+ intel_update_rawclk(i915);
- intel_power_domains_init_hw(dev_priv, false);
+ intel_power_domains_init_hw(i915, false);
- intel_csr_ucode_init(dev_priv);
+ intel_csr_ucode_init(i915);
- ret = intel_irq_install(dev_priv);
+ ret = intel_irq_install(i915);
if (ret)
goto cleanup_csr;
- intel_gmbus_setup(dev_priv);
+ intel_gmbus_setup(i915);
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
- ret = intel_modeset_init(dev);
+ ret = intel_modeset_init(&i915->drm);
if (ret)
goto cleanup_irq;
- ret = i915_gem_init(dev_priv);
+ ret = i915_gem_init(i915);
if (ret)
goto cleanup_modeset;
- intel_overlay_setup(dev_priv);
+ intel_overlay_setup(i915);
- if (!HAS_DISPLAY(dev_priv) || !INTEL_DISPLAY_ENABLED(dev_priv))
+ if (!HAS_DISPLAY(i915) || !INTEL_DISPLAY_ENABLED(i915))
return 0;
- ret = intel_fbdev_init(dev);
+ ret = intel_fbdev_init(&i915->drm);
if (ret)
goto cleanup_gem;
/* Only enable hotplug handling once the fbdev is fully set up. */
- intel_hpd_init(dev_priv);
+ intel_hpd_init(i915);
- intel_init_ipc(dev_priv);
+ intel_init_ipc(i915);
return 0;
cleanup_gem:
- i915_gem_suspend(dev_priv);
- i915_gem_driver_remove(dev_priv);
- i915_gem_driver_release(dev_priv);
+ i915_gem_suspend(i915);
+ i915_gem_driver_remove(i915);
+ i915_gem_driver_release(i915);
cleanup_modeset:
- intel_modeset_driver_remove(dev);
+ intel_modeset_driver_remove(&i915->drm);
cleanup_irq:
- intel_irq_uninstall(dev_priv);
- intel_gmbus_teardown(dev_priv);
+ intel_irq_uninstall(i915);
+ intel_gmbus_teardown(i915);
cleanup_csr:
- intel_csr_ucode_fini(dev_priv);
- intel_power_domains_driver_remove(dev_priv);
+ intel_csr_ucode_fini(i915);
+ intel_power_domains_driver_remove(i915);
vga_switcheroo_unregister_client(pdev);
cleanup_vga_client:
vga_client_register(pdev, NULL, NULL, NULL);
@@ -1570,7 +1569,7 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_mmio;
- ret = i915_driver_modeset_probe(&dev_priv->drm);
+ ret = i915_driver_modeset_probe(dev_priv);
if (ret < 0)
goto out_cleanup_hw;
--
2.20.1
___
[Intel-gfx] [PATCH 08/13] drm/i915: split i915_driver_modeset_remove() to pre/post irq uninstall
Push irq uninstall further up, by splitting i915_driver_modeset_remove()
to two, the part with working irqs before irq uninstall, and the part
after irq uninstall. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 15 +++
1 file changed, 11 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f2af3ba24ce9..e10d3ce5db09 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -422,13 +422,16 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
return ret;
}
-static void i915_driver_modeset_remove(struct drm_i915_private *i915)
+/* part #1: call before irq uninstall */
+static void i915_driver_modeset_remove_irq(struct drm_i915_private *i915)
{
- struct pci_dev *pdev = i915->drm.pdev;
-
intel_modeset_driver_remove_irq(i915);
+}
- intel_irq_uninstall(i915);
+/* part #2: call after irq uninstall */
+static void i915_driver_modeset_remove(struct drm_i915_private *i915)
+{
+ struct pci_dev *pdev = i915->drm.pdev;
intel_modeset_driver_remove(i915);
@@ -1624,6 +1627,10 @@ void i915_driver_remove(struct drm_i915_private *i915)
intel_gvt_driver_remove(i915);
+ i915_driver_modeset_remove_irq(i915);
+
+ intel_irq_uninstall(i915);
+
i915_driver_modeset_remove(i915);
/* Free error state after interrupts are fully disabled. */
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/13] drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw()
In general, prefer struct drm_i915_private * over struct drm_device *
when either will do. Rename the local variables to i915. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 69 ++--
drivers/gpu/drm/i915/display/intel_display.h | 4 +-
drivers/gpu/drm/i915/i915_drv.c | 4 +-
3 files changed, 37 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 040ee006b047..78edb5e66cdb 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -4347,7 +4347,7 @@ void intel_finish_reset(struct drm_i915_private *dev_priv)
* so need a full re-initialization.
*/
intel_pps_unlock_regs_wa(dev_priv);
- intel_modeset_init_hw(dev);
+ intel_modeset_init_hw(dev_priv);
intel_init_clock_gating(dev_priv);
spin_lock_irq(&dev_priv->irq_lock);
@@ -15934,13 +15934,11 @@ static void i915_disable_vga(struct drm_i915_private
*dev_priv)
POSTING_READ(vga_reg);
}
-void intel_modeset_init_hw(struct drm_device *dev)
+void intel_modeset_init_hw(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
-
- intel_update_cdclk(dev_priv);
- intel_dump_cdclk_state(&dev_priv->cdclk.hw, "Current CDCLK");
- dev_priv->cdclk.logical = dev_priv->cdclk.actual = dev_priv->cdclk.hw;
+ intel_update_cdclk(i915);
+ intel_dump_cdclk_state(&i915->cdclk.hw, "Current CDCLK");
+ i915->cdclk.logical = i915->cdclk.actual = i915->cdclk.hw;
}
/*
@@ -16144,44 +16142,44 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
}
}
-int intel_modeset_init(struct drm_device *dev)
+int intel_modeset_init(struct drm_i915_private *i915)
{
- struct drm_i915_private *dev_priv = to_i915(dev);
+ struct drm_device *dev = &i915->drm;
enum pipe pipe;
struct intel_crtc *crtc;
int ret;
- dev_priv->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
- dev_priv->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
- WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
+ i915->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
+ i915->flip_wq = alloc_workqueue("i915_flip", WQ_HIGHPRI |
+ WQ_UNBOUND, WQ_UNBOUND_MAX_ACTIVE);
drm_mode_config_init(dev);
- intel_mode_config_init(dev_priv);
+ intel_mode_config_init(i915);
- ret = intel_bw_init(dev_priv);
+ ret = intel_bw_init(i915);
if (ret)
return ret;
- init_llist_head(&dev_priv->atomic_helper.free_list);
- INIT_WORK(&dev_priv->atomic_helper.free_work,
+ init_llist_head(&i915->atomic_helper.free_list);
+ INIT_WORK(&i915->atomic_helper.free_work,
intel_atomic_helper_free_state_worker);
- intel_init_quirks(dev_priv);
+ intel_init_quirks(i915);
- intel_fbc_init(dev_priv);
+ intel_fbc_init(i915);
- intel_init_pm(dev_priv);
+ intel_init_pm(i915);
- intel_panel_sanitize_ssc(dev_priv);
+ intel_panel_sanitize_ssc(i915);
DRM_DEBUG_KMS("%d display pipe%s available.\n",
- INTEL_NUM_PIPES(dev_priv),
- INTEL_NUM_PIPES(dev_priv) > 1 ? "s" : "");
+ INTEL_NUM_PIPES(i915),
+ INTEL_NUM_PIPES(i915) > 1 ? "s" : "");
- if (HAS_DISPLAY(dev_priv) && INTEL_DISPLAY_ENABLED(dev_priv)) {
- for_each_pipe(dev_priv, pipe) {
- ret = intel_crtc_init(dev_priv, pipe);
+ if (HAS_DISPLAY(i915) && INTEL_DISPLAY_ENABLED(i915)) {
+ for_each_pipe(i915, pipe) {
+ ret = intel_crtc_init(i915, pipe);
if (ret) {
drm_mode_config_cleanup(dev);
return ret;
@@ -16190,19 +16188,19 @@ int intel_modeset_init(struct drm_device *dev)
}
intel_shared_dpll_init(dev);
- intel_update_fdi_pll_freq(dev_priv);
+ intel_update_fdi_pll_freq(i915);
- intel_update_czclk(dev_priv);
- intel_modeset_init_hw(dev);
+ intel_update_czclk(i915);
+ intel_modeset_init_hw(i915);
- intel_hdcp_component_init(dev_priv);
+ intel_hdcp_component_init(i915);
- if (dev_priv->max_cdclk_freq == 0)
- intel_update_max_cdclk(dev_priv);
+ if (i915->max_cdclk_freq == 0)
+ intel_update_max_cdclk(i915);
/* Just disable it once at startup */
- i915_disable_vga(dev_priv);
- intel_setup_outputs(dev_priv);
+ i915_disable_vga(i915);
+ intel_setup_outputs(i915);
drm_modeset_lock_all(dev);
[Intel-gfx] [PATCH 09/13] drm/i915: move gmbus setup down to intel_modeset_init()
Pair the gmbus setup and teardown in the same layer. This also fixes the
double gmbus teardown on the i915_driver_modeset_probe() error path.
Move the gmbus setup a bit later in the sequence to make the follow-up
refactoring easier, and to pinpoint any unexpected consequences of this
change right here, instead of the later refactoring.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 4
2 files changed, 2 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 2c474be4a011..902b7fe5adf3 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16173,6 +16173,8 @@ int intel_modeset_init(struct drm_i915_private *i915)
intel_panel_sanitize_ssc(i915);
+ intel_gmbus_setup(i915);
+
DRM_DEBUG_KMS("%d display pipe%s available.\n",
INTEL_NUM_PIPES(i915),
INTEL_NUM_PIPES(i915) > 1 ? "s" : "");
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index e10d3ce5db09..7a7a1b7d5da2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -54,7 +54,6 @@
#include "display/intel_display_types.h"
#include "display/intel_dp.h"
#include "display/intel_fbdev.h"
-#include "display/intel_gmbus.h"
#include "display/intel_hotplug.h"
#include "display/intel_overlay.h"
#include "display/intel_pipe_crc.h"
@@ -374,8 +373,6 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
if (ret)
goto cleanup_csr;
- intel_gmbus_setup(i915);
-
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
ret = intel_modeset_init(i915);
@@ -411,7 +408,6 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
intel_modeset_driver_remove(i915);
cleanup_irq:
intel_irq_uninstall(i915);
- intel_gmbus_teardown(i915);
cleanup_csr:
intel_csr_ucode_fini(i915);
intel_power_domains_driver_remove(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/13] drm/i915: split i915_driver_modeset_probe() to pre/post irq install
Pair the irq install and uninstall in the same layer. There are no
functional changes in the happy day scenario. The cleanup paths are
currently a mess though.
Note that modeset probe pre-irq + post-irq install are matched by
modeset driver remove pre-irq + post-irq uninstall, together, but not
independently. They are not symmetric pairs.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.c | 41 +++--
1 file changed, 29 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 7a7a1b7d5da2..30b0548a5648 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -328,6 +328,7 @@ static const struct vga_switcheroo_client_ops
i915_switcheroo_ops = {
.can_switch = i915_switcheroo_can_switch,
};
+/* part #1: call before irq install */
static int i915_driver_modeset_probe(struct drm_i915_private *i915)
{
struct pci_dev *pdev = i915->drm.pdev;
@@ -369,15 +370,27 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
intel_csr_ucode_init(i915);
- ret = intel_irq_install(i915);
- if (ret)
- goto cleanup_csr;
+ return 0;
+
+cleanup_vga_client:
+ vga_client_register(pdev, NULL, NULL, NULL);
+out:
+ return ret;
+}
+
+/* part #2: call after irq install */
+static int i915_driver_modeset_probe_irq(struct drm_i915_private *i915)
+{
+ int ret;
+
+ if (i915_inject_probe_failure(i915))
+ return -ENODEV;
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
ret = intel_modeset_init(i915);
if (ret)
- goto cleanup_irq;
+ goto out;
ret = i915_gem_init(i915);
if (ret)
@@ -406,14 +419,6 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
cleanup_modeset:
intel_modeset_driver_remove_irq(i915);
intel_modeset_driver_remove(i915);
-cleanup_irq:
- intel_irq_uninstall(i915);
-cleanup_csr:
- intel_csr_ucode_fini(i915);
- intel_power_domains_driver_remove(i915);
- vga_switcheroo_unregister_client(pdev);
-cleanup_vga_client:
- vga_client_register(pdev, NULL, NULL, NULL);
out:
return ret;
}
@@ -1577,6 +1582,14 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
if (ret < 0)
goto out_cleanup_hw;
+ ret = intel_irq_install(dev_priv);
+ if (ret)
+ goto out_cleanup_modeset;
+
+ ret = i915_driver_modeset_probe_irq(dev_priv);
+ if (ret < 0)
+ goto out_cleanup_irq;
+
i915_driver_register(dev_priv);
enable_rpm_wakeref_asserts(&dev_priv->runtime_pm);
@@ -1585,6 +1598,10 @@ int i915_driver_probe(struct pci_dev *pdev, const struct
pci_device_id *ent)
return 0;
+out_cleanup_irq:
+ intel_irq_uninstall(dev_priv);
+out_cleanup_modeset:
+ /* FIXME */
out_cleanup_hw:
i915_driver_hw_remove(dev_priv);
i915_ggtt_driver_release(dev_priv);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/13] drm/i915: move gem init up from modeset init
Pair the gem init and cleanup in the same layer. This moves the gem init before the modeset init. The error paths remain a mess. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/i915_drv.c | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 30b0548a5648..27613f497a46 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -392,10 +392,6 @@ static int i915_driver_modeset_probe_irq(struct drm_i915_private *i915) if (ret) goto out; - ret = i915_gem_init(i915); - if (ret) - goto cleanup_modeset; - intel_overlay_setup(i915); if (!HAS_DISPLAY(i915) || !INTEL_DISPLAY_ENABLED(i915)) @@ -403,7 +399,7 @@ static int i915_driver_modeset_probe_irq(struct drm_i915_private *i915) ret = intel_fbdev_init(&i915->drm); if (ret) - goto cleanup_gem; + goto cleanup_modeset; /* Only enable hotplug handling once the fbdev is fully set up. */ intel_hpd_init(i915); @@ -412,10 +408,6 @@ static int i915_driver_modeset_probe_irq(struct drm_i915_private *i915) return 0; -cleanup_gem: - i915_gem_suspend(i915); - i915_gem_driver_remove(i915); - i915_gem_driver_release(i915); cleanup_modeset: intel_modeset_driver_remove_irq(i915); intel_modeset_driver_remove(i915); @@ -1586,9 +1578,13 @@ int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent) if (ret) goto out_cleanup_modeset; + ret = i915_gem_init(dev_priv); + if (ret) + goto out_cleanup_irq; + ret = i915_driver_modeset_probe_irq(dev_priv); if (ret < 0) - goto out_cleanup_irq; + goto out_cleanup_gem; i915_driver_register(dev_priv); @@ -1598,6 +1594,10 @@ int i915_driver_probe(struct pci_dev *pdev, const struct pci_device_id *ent) return 0; +out_cleanup_gem: + i915_gem_suspend(dev_priv); + i915_gem_driver_remove(dev_priv); + i915_gem_driver_release(dev_priv); out_cleanup_irq: intel_irq_uninstall(dev_priv); out_cleanup_modeset: -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/13] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
Split intel_modeset_driver_remove() to two, the part with working irqs
before irq uninstall, and the part after irq uninstall.
The error path in i915_driver_modeset_probe() looks obviously weird
after this, but remains as good or broken as it ever was. No functional
changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 14 ++
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/i915_drv.c | 5 +
3 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 78edb5e66cdb..2c474be4a011 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -17054,21 +17054,19 @@ static void intel_hpd_poll_fini(struct
drm_i915_private *i915)
drm_connector_list_iter_end(&conn_iter);
}
-void intel_modeset_driver_remove(struct drm_i915_private *i915)
+/* part #1: call before irq uninstall */
+void intel_modeset_driver_remove_irq(struct drm_i915_private *i915)
{
flush_workqueue(i915->flip_wq);
flush_workqueue(i915->modeset_wq);
flush_work(&i915->atomic_helper.free_work);
WARN_ON(!llist_empty(&i915->atomic_helper.free_list));
+}
- /*
-* Interrupts and polling as the first thing to avoid creating havoc.
-* Too much stuff here (turning of connectors, ...) would
-* experience fancy races otherwise.
-*/
- intel_irq_uninstall(i915);
-
+/* part #2: call after irq uninstall */
+void intel_modeset_driver_remove(struct drm_i915_private *i915)
+{
/*
* Due to the hpd irq storm handling the hotplug work can re-arm the
* poll handlers. Hence disable polling after hpd handling is shut down.
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 0405a74b513c..1783f4062fc9 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -574,6 +574,7 @@ void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
/* modesetting */
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init(struct drm_i915_private *i915);
+void intel_modeset_driver_remove_irq(struct drm_i915_private *i915);
void intel_modeset_driver_remove(struct drm_i915_private *i915);
int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool state);
void intel_display_resume(struct drm_device *dev);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a9ee73b61f4d..f2af3ba24ce9 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -407,6 +407,7 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
i915_gem_driver_remove(i915);
i915_gem_driver_release(i915);
cleanup_modeset:
+ intel_modeset_driver_remove_irq(i915);
intel_modeset_driver_remove(i915);
cleanup_irq:
intel_irq_uninstall(i915);
@@ -425,6 +426,10 @@ static void i915_driver_modeset_remove(struct
drm_i915_private *i915)
{
struct pci_dev *pdev = i915->drm.pdev;
+ intel_modeset_driver_remove_irq(i915);
+
+ intel_irq_uninstall(i915);
+
intel_modeset_driver_remove(i915);
intel_bios_driver_remove(i915);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/13] drm/i915: push intel_overlay_init() down to intel_modeset_init()
Pair the overlay init and fini in the same layer. No functional changes.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 2 ++
drivers/gpu/drm/i915/i915_drv.c | 2 --
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 902b7fe5adf3..902c4cc033cd 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16248,6 +16248,8 @@ int intel_modeset_init(struct drm_i915_private *i915)
if (ret)
DRM_DEBUG_KMS("Initial commit in probe failed.\n");
+ intel_overlay_setup(i915);
+
return 0;
}
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 27613f497a46..c14b468384ec 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -392,8 +392,6 @@ static int i915_driver_modeset_probe_irq(struct
drm_i915_private *i915)
if (ret)
goto out;
- intel_overlay_setup(i915);
-
if (!HAS_DISPLAY(i915) || !INTEL_DISPLAY_ENABLED(i915))
return 0;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/13] drm/i915: split intel_modeset_init() to pre/post irq install
Move some of the modeset init that does not require irqs installed or
gem initialized to before irq install and gem init.
Signed-off-by: Jani Nikula
---
drivers/gpu/drm/i915/display/intel_display.c | 14 --
drivers/gpu/drm/i915/display/intel_display.h | 1 +
drivers/gpu/drm/i915/i915_drv.c | 8 +++-
3 files changed, 20 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 902c4cc033cd..7d294a6b76ce 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -16142,11 +16142,10 @@ static void intel_mode_config_init(struct
drm_i915_private *i915)
}
}
+/* part #1: call before irq install (and gem init) */
int intel_modeset_init(struct drm_i915_private *i915)
{
struct drm_device *dev = &i915->drm;
- enum pipe pipe;
- struct intel_crtc *crtc;
int ret;
i915->modeset_wq = alloc_ordered_workqueue("i915_modeset", 0);
@@ -16169,6 +16168,17 @@ int intel_modeset_init(struct drm_i915_private *i915)
intel_fbc_init(i915);
+ return 0;
+}
+
+/* part #2: call after irq install (and gem init) */
+int intel_modeset_init_irq(struct drm_i915_private *i915)
+{
+ struct drm_device *dev = &i915->drm;
+ enum pipe pipe;
+ struct intel_crtc *crtc;
+ int ret;
+
intel_init_pm(i915);
intel_panel_sanitize_ssc(i915);
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index 1783f4062fc9..5d5e3afec30e 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -574,6 +574,7 @@ void intel_display_print_error_state(struct
drm_i915_error_state_buf *e,
/* modesetting */
void intel_modeset_init_hw(struct drm_i915_private *i915);
int intel_modeset_init(struct drm_i915_private *i915);
+int intel_modeset_init_irq(struct drm_i915_private *i915);
void intel_modeset_driver_remove_irq(struct drm_i915_private *i915);
void intel_modeset_driver_remove(struct drm_i915_private *i915);
int intel_modeset_vga_set_state(struct drm_i915_private *dev_priv, bool state);
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c14b468384ec..8e28b690d406 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -370,8 +370,14 @@ static int i915_driver_modeset_probe(struct
drm_i915_private *i915)
intel_csr_ucode_init(i915);
+ ret = intel_modeset_init(i915);
+ if (ret)
+ goto cleanup_vga_switcheroo;
+
return 0;
+cleanup_vga_switcheroo:
+ vga_switcheroo_unregister_client(pdev);
cleanup_vga_client:
vga_client_register(pdev, NULL, NULL, NULL);
out:
@@ -388,7 +394,7 @@ static int i915_driver_modeset_probe_irq(struct
drm_i915_private *i915)
/* Important: The output setup functions called by modeset_init need
* working irqs for e.g. gmbus and dp aux transfers. */
- ret = intel_modeset_init(i915);
+ ret = intel_modeset_init_irq(i915);
if (ret)
goto out;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 13/21] drm/i915: Pull i915_vma_pin under the vm->mutex
Quoting Tvrtko Ursulin (2019-09-19 14:37:01)
>
> On 17/09/2019 19:56, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-09-17 13:37:55)
> >> On 02/09/2019 05:02, Chris Wilson wrote:
> >>> +void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence
> >>> *f)
> >>> +{
> >>> + GEM_BUG_ON(i915_active_is_idle(ref));
> >>> +
> >>> + dma_fence_get(f);
> >>> +
> >>> + rcu_read_lock();
> >>> + if (rcu_access_pointer(ref->excl)) {
> >>> + struct dma_fence *old;
> >>> +
> >>> + old = dma_fence_get_rcu_safe(&ref->excl);
> >>> + if (old) {
> >>> + if (dma_fence_remove_callback(old, &ref->excl_cb))
> >>> + atomic_dec(&ref->count);
> >>> + dma_fence_put(old);
> >>> + }
> >>
> >> Put some commentary in describing the business done with ref->excl and
> >> callbacks. Or this goes away later?
> >
> > void i915_active_set_exclusive(struct i915_active *ref, struct dma_fence *f)
> > {
> > GEM_BUG_ON(i915_active_is_idle(ref));
> >
> > mutex_acquire(&ref->mutex.dep_map, 0, 0, _THIS_IP_);
> > if (!__i915_active_fence_set(&ref->excl, f))
> > atomic_inc(&ref->count);
> > mutex_release(&ref->mutex.dep_map, 0, _THIS_IP_);
> > }
>
> What is this?
What is becomes in a couple of patches time, where the entire
i915_active is built out of the same i915_active_fence (wrapping the
dma_fence_cb), and so this exclusive slot becomes more clearly a
preallocated version of one of the nodes (and not a special case, except
for the special case that the order is given by the caller and not our
mutex, which is a bit of a nuisance I admit).
> >>> @@ -109,20 +121,31 @@ int i915_gem_object_unbind(struct
> >>> drm_i915_gem_object *obj,
> >>>LIST_HEAD(still_in_list);
> >>>int ret = 0;
> >>>
> >>> - lockdep_assert_held(&obj->base.dev->struct_mutex);
> >>> -
> >>>spin_lock(&obj->vma.lock);
> >>>while (!ret && (vma = list_first_entry_or_null(&obj->vma.list,
> >>> struct i915_vma,
> >>> obj_link))) {
> >>> + struct i915_address_space *vm = vma->vm;
> >>> +
> >>> + ret = -EBUSY;
> >>> + if (!i915_vm_tryopen(vm))
> >>> + break;
> >>
> >> This is some race between different paths of vm closing/destruction and
> >> vma cleanup? We need a comment about it somewhere.. Here I guess is a
> >> good place.
> >
> > 4 different paths all fighting; and coordinate by preventing the other 2
> > destruction paths from running as they run, and spinlocks to prevent the
> > other.
> >
> >> And why break and not continue, there will be a second call coming from
> >> somewhere when it fails?
> >
> > It failed to unbind the object, so it would end up in a busy spin
> > preventing the actual vm release from removing the vma.
>
> But it could proceed to unbind what can be unbound. Otherwise is it
> guaranteed to be called again when it fails, so eventually it will clean
> up everything?
We gain nothing by doing so, except unbind things that were in use. We
have to completely unbind the object for the callers to make progress.
> >>> + work->vma = vma;
> >>> + work->cache_level = cache_level;
> >>> + work->flags = bind_flags | I915_VMA_ALLOC;
> >>> +
> >>> + /*
> >>> + * Note we only want to chain up to the migration fence on
> >>> + * the pages (not the object itself). As we don't track
> >>> that,
> >>> + * yet, we have to use the exclusive fence instead.
> >>> + *
> >>> + * Also note that we do not want to track the async vma as
> >>> + * part of the obj->resv->excl_fence as it only affects
> >>> + * execution and not content or object's backing store
> >>> lifetime.
> >>> + */
> >>> + GEM_BUG_ON(i915_active_has_exclusive(&vma->active));
> >>> + i915_active_set_exclusive(&vma->active, &work->base.dma);
> >>
> >> Oh right, dma_fence_work since it's not a worker but callback on
> >> signalling the fence... From what context it gets called (holding any
> >> locks?) and which locks the callback can/will take?
> >
> > dma_fence_work has a dma_fence_cb that schedules a work_stuct which
> > executes our function. (And it also has a dma-fence through which we can
> > signal the completion/error of that function.)
>
> And this is to avoid some allocation somewhere?
The fence-work generally is to schedule some work that has to wait for a
set of fences and wants to signal fence upon completion. We are using it
here to do the allocation after we drop the mutex. (Which means we have
to protect that work itself from the shrinker, which is fun.)
> >>> +static bool try_fast_pin(struct i915_vma *vma, uns
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/3] i915/gem_eio: Race kms on/off vs reset
Hi Chris, On Wed, Sep 11, 2019 at 11:14:59AM +0100, Chris Wilson wrote: > On older platforms, performing a GPU reset clobbers the display. > Exercise the interactions between reset/wedge and the display and > hopefully prevent any races creeping in. > > Signed-off-by: Chris Wilson > Cc: Ville Syrjälä Is Ville Cc'ed for real or just nominally? looks straight forward, Reviewed-by: Andi Shyti Andi ___ 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 2/3] Force spin-batch to cause a hang as required
On Wed, Sep 11, 2019 at 11:15:00AM +0100, Chris Wilson wrote:
> When using a spinner to trigger a hang, make it unpreemptable so that it
> appears like a true hang.
>
> References: https://bugs.freedesktop.org/show_bug.cgi?id=109661
> Signed-off-by: Chris Wilson
Reviewed-by: Andi Shyti
Andi
> ---
> tests/i915/gem_eio.c| 4 +++-
> tests/i915/gem_exec_fence.c | 3 ++-
> tests/kms_busy.c| 3 ++-
> 3 files changed, 7 insertions(+), 3 deletions(-)
>
> diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> index e0213c76c..e7f5d4ddb 100644
> --- a/tests/i915/gem_eio.c
> +++ b/tests/i915/gem_eio.c
> @@ -178,7 +178,9 @@ static igt_spin_t * __spin_poll(int fd, uint32_t ctx,
> unsigned long flags)
> struct igt_spin_factory opts = {
> .ctx = ctx,
> .engine = flags,
> - .flags = IGT_SPIN_FAST | IGT_SPIN_FENCE_OUT,
> + .flags = (IGT_SPIN_FAST |
> + IGT_SPIN_NO_PREEMPTION |
> + IGT_SPIN_FENCE_OUT),
> };
>
> if (gem_can_store_dword(fd, opts.engine))
> diff --git a/tests/i915/gem_exec_fence.c b/tests/i915/gem_exec_fence.c
> index 207182922..2f04d7af4 100644
> --- a/tests/i915/gem_exec_fence.c
> +++ b/tests/i915/gem_exec_fence.c
> @@ -331,7 +331,8 @@ static void test_fence_await(int fd, unsigned ring,
> unsigned flags)
>
> spin = igt_spin_new(fd,
> .engine = ring,
> - .flags = IGT_SPIN_FENCE_OUT);
> + .flags = (IGT_SPIN_FENCE_OUT |
> + IGT_SPIN_NO_PREEMPTION));
> igt_assert(spin->out_fence != -1);
>
> i = 0;
> diff --git a/tests/kms_busy.c b/tests/kms_busy.c
> index 66f26cd08..7e5ab3d19 100644
> --- a/tests/kms_busy.c
> +++ b/tests/kms_busy.c
> @@ -271,7 +271,8 @@ static void test_pageflip_modeset_hang(igt_display_t *dpy,
>
> t = igt_spin_new(dpy->drm_fd,
>.engine = ring,
> - .dependency = fb.gem_handle);
> + .dependency = fb.gem_handle,
> + .flags = IGT_SPIN_NO_PREEMPTION);
>
> do_or_die(drmModePageFlip(dpy->drm_fd, dpy->pipes[pipe].crtc_id,
> fb.fb_id, DRM_MODE_PAGE_FLIP_EVENT, &fb));
>
> --
> 2.23.0
>
> ___
> igt-dev mailing list
> igt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/igt-dev
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] kms_busy: Replace fiddling with hangcheck modparam with explicit fence
Hi Chris, On Wed, Sep 11, 2019 at 11:15:01AM +0100, Chris Wilson wrote: > Use an explicit fence to circumvent the [i915] GPU hang detection rather > than tweak the i915 specific modparam (and remove the assertion that > such a param exists). Note, that with a bit more work, the fence could > be used be directly rather than via dirtying the fb with a dummyload. > > Signed-off-by: Chris Wilson looks OK, Reviewed-by: Andi Shyti Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-intel-next-fixes
Hi Dave and Daniel, Here goes drm-intel-next-fixes-2019-09-19: - Extend old HSW workaround to fix some GPU hangs on Haswell GT2 - Fix return error code on GEM mmap. - White list a chicken bit register for push constants legacy mode on Mesa - Fix resume issue related to GGTT restore - Remove incorrect BUG_ON on execlist's schedule-out - Fix unrecoverable GPU hangs with Vulkan compute workloads on SKL Thanks, Rodrigo. The following changes since commit 6e5c5272ca00809aae20817efb6f25881268b50b: drm/i915: Use NOEVICT for first pass on attemping to pin a GGTT mmap (2019-09-06 09:53:15 -0700) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-intel tags/drm-intel-next-fixes-2019-09-19 for you to fetch changes up to a95819a173788bec7414d260f76f42a9934890b4: drm/i915: Extend Haswell GT1 PSMI workaround to all (2019-09-18 10:53:38 -0700) - Extend old HSW workaround to fix some GPU hangs on Haswell GT2 - Fix return error code on GEM mmap. - White list a chicken bit register for push constants legacy mode on Mesa - Fix resume issue related to GGTT restore - Remove incorrect BUG_ON on execlist's schedule-out - Fix unrecoverable GPU hangs with Vulkan compute workloads on SKL Chris Wilson (5): drm/i915: Restore relaxed padding (OCL_OOB_SUPPRES_ENABLE) for skl+ drm/i915/execlists: Remove incorrect BUG_ON for schedule-out drm/i915: Perform GGTT restore much earlier during resume drm/i915: Don't mix srcu tag and negative error codes drm/i915: Extend Haswell GT1 PSMI workaround to all Kenneth Graunke (1): drm/i915: Whitelist COMMON_SLICE_CHICKEN2 drivers/gpu/drm/i915/gem/i915_gem_mman.c| 6 ++ drivers/gpu/drm/i915/gem/i915_gem_pm.c | 3 --- drivers/gpu/drm/i915/gt/intel_lrc.c | 1 - drivers/gpu/drm/i915/gt/intel_reset.c | 8 +++- drivers/gpu/drm/i915/gt/intel_reset.h | 2 +- drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 2 +- drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +++- drivers/gpu/drm/i915/i915_drv.c | 5 + drivers/gpu/drm/i915/selftests/i915_gem.c | 6 ++ 9 files changed, 21 insertions(+), 20 deletions(-) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/13] drm/i915: move gem init up from modeset init
Quoting Jani Nikula (2019-09-19 15:03:58) > Pair the gem init and cleanup in the same layer. This moves the gem init > before the modeset init. The important part here was that BIOS takeover by display is before we clear the GGTT in i915_gem_init -> i915_init_ggtt. iirc marking up the preallocated GGTT ranges is in intel_modeset_init. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/rect: Return scaling factor and error code separately
From: Ville Syrjälä
We may want to dump out the calculated scaling factor(s) when
they exceed the limits. To achieve that we need to return the
error code and scaling factor separately.
Side note: the code in dpu_plane_validate_multirect_v2()
looks rather dubious on account of it not using fixed point
numbers. Not sure the rounding behaviour we have really
satisfies what it's trying to do. Maybe it should just do
(src_w!=dst_w || src_h!=dst_h) ?
Cc: Jeykumar Sankaran
Suggested-by: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 8 ++---
drivers/gpu/drm/drm_rect.c | 34 -
drivers/gpu/drm/i915/display/intel_sprite.c | 12
drivers/gpu/drm/msm/disp/dpu1/dpu_plane.c | 8 +++--
include/drm/drm_rect.h | 6 ++--
5 files changed, 39 insertions(+), 29 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c861a871299d..c60db3bf2a83 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -765,7 +765,7 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
struct drm_rect *dst = &plane_state->dst;
unsigned int rotation = plane_state->rotation;
struct drm_rect clip = {};
- int hscale, vscale;
+ int hscale, vscale, ret;
WARN_ON(plane_state->crtc && plane_state->crtc != crtc_state->crtc);
@@ -791,9 +791,9 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
drm_rect_rotate(src, fb->width << 16, fb->height << 16, rotation);
/* Check scaling */
- hscale = drm_rect_calc_hscale(src, dst, min_scale, max_scale);
- vscale = drm_rect_calc_vscale(src, dst, min_scale, max_scale);
- if (hscale < 0 || vscale < 0) {
+ ret = drm_rect_calc_hscale(src, dst, min_scale, max_scale, &hscale);
+ ret |= drm_rect_calc_vscale(src, dst, min_scale, max_scale, &vscale);
+ if (ret) {
DRM_DEBUG_KMS("Invalid scaling of plane\n");
drm_rect_debug_print("src: ", &plane_state->src, true);
drm_rect_debug_print("dst: ", &plane_state->dst, false);
diff --git a/drivers/gpu/drm/drm_rect.c b/drivers/gpu/drm/drm_rect.c
index b8363aaa9032..f014107d11a5 100644
--- a/drivers/gpu/drm/drm_rect.c
+++ b/drivers/gpu/drm/drm_rect.c
@@ -145,6 +145,7 @@ static int drm_calc_scale(int src, int dst)
* @dst: destination window rectangle
* @min_hscale: minimum allowed horizontal scaling factor
* @max_hscale: maximum allowed horizontal scaling factor
+ * @hscale: calculated horizontal scaling factor
*
* Calculate the horizontal scaling factor as
* (@src width) / (@dst width).
@@ -154,23 +155,25 @@ static int drm_calc_scale(int src, int dst)
* pessimistic limit calculation.
*
* RETURNS:
- * The horizontal scaling factor, or errno of out of limits.
+ * Zero on success, or errno on out of limits.
*/
int drm_rect_calc_hscale(const struct drm_rect *src,
const struct drm_rect *dst,
-int min_hscale, int max_hscale)
+int min_hscale, int max_hscale,
+int *hscale)
{
int src_w = drm_rect_width(src);
int dst_w = drm_rect_width(dst);
- int hscale = drm_calc_scale(src_w, dst_w);
- if (hscale < 0 || dst_w == 0)
- return hscale;
+ *hscale = drm_calc_scale(src_w, dst_w);
- if (hscale < min_hscale || hscale > max_hscale)
+ if (*hscale < 0 || dst_w == 0)
+ return *hscale;
+
+ if (*hscale < min_hscale || *hscale > max_hscale)
return -ERANGE;
- return hscale;
+ return 0;
}
EXPORT_SYMBOL(drm_rect_calc_hscale);
@@ -180,6 +183,7 @@ EXPORT_SYMBOL(drm_rect_calc_hscale);
* @dst: destination window rectangle
* @min_vscale: minimum allowed vertical scaling factor
* @max_vscale: maximum allowed vertical scaling factor
+ * @hscale: calculated vertical scaling factor
*
* Calculate the vertical scaling factor as
* (@src height) / (@dst height).
@@ -189,23 +193,25 @@ EXPORT_SYMBOL(drm_rect_calc_hscale);
* pessimistic limit calculation.
*
* RETURNS:
- * The vertical scaling factor, or errno of out of limits.
+ * Zero on success, or errno on out of limits.
*/
int drm_rect_calc_vscale(const struct drm_rect *src,
const struct drm_rect *dst,
-int min_vscale, int max_vscale)
+int min_vscale, int max_vscale,
+int *vscale)
{
int src_h = drm_rect_height(src);
int dst_h = drm_rect_height(dst);
- int vscale = drm_calc_scale(src_h, dst_h);
- if (vscale < 0 || dst_h == 0)
- return vscale;
+ *vscale = drm_calc_scale(src_h, dst_h);
+
+ if (*vscale < 0 || dst_h == 0)
+ return *vscale;
- if (vs
[Intel-gfx] [PATCH 3/3] drm/atomic-helper: Improve drm_atomic_helper_check_plane_state() debugs
From: Ville Syrjälä
Dump out the plane/crtc id/name in the failure debug messages.
Makes a bit easier to figure out which plane exactly has failed
when you have tons of them.
Cc: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 9 +++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index 9de39da54c48..86a2839dbfdd 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -761,6 +761,7 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
bool can_update_disabled)
{
struct drm_plane *plane = plane_state->plane;
+ struct drm_crtc *crtc = crtc_state->crtc;
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect *src = &plane_state->src;
struct drm_rect *dst = &plane_state->dst;
@@ -785,7 +786,9 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
}
if (!crtc_state->enable && !can_update_disabled) {
- DRM_DEBUG_KMS("Cannot update plane of a disabled CRTC.\n");
+ DRM_DEBUG_KMS("Cannot update [PLANE:%d:%s] of disabled
[CRTC:%d:%s].\n",
+ plane->base.id, plane->name,
+ crtc->base.id, crtc->name);
return -EINVAL;
}
@@ -831,7 +834,9 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
return 0;
if (!can_position && !drm_rect_equals(dst, &clip)) {
- DRM_DEBUG_KMS("Plane must cover entire CRTC\n");
+ DRM_DEBUG_KMS("[PLANE:%d:%s] must cover entire [CRTC:%d:%s]\n",
+ plane->base.id, plane->name,
+ crtc->base.id, crtc->name);
drm_rect_debug_print("dst: ", dst, false);
drm_rect_debug_print("clip: ", &clip, false);
return -EINVAL;
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/atomic: Pimp the debugs for scaling fails
From: Ville Syrjälä
When the calculate scaling factors are out of range let's
print out the calculated value and the min/max. Should make
life a bit less confusing when decoding failure logs.
I decided to print them in decimal rather than hex. Not sure
which people prefer but maybe this is less confusing to the
casual reader at least.
Also write out the magic 15625 constant we use in
the binary->decimal conversion as '100 >> (16-10)'
to make it more clear how it relates to the final '>> 10'.
Suggested-by: Sean Paul
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_atomic_helper.c | 19 ---
include/drm/drm_rect.h | 29 ++---
2 files changed, 38 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_atomic_helper.c
b/drivers/gpu/drm/drm_atomic_helper.c
index c60db3bf2a83..9de39da54c48 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -760,6 +760,7 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
bool can_position,
bool can_update_disabled)
{
+ struct drm_plane *plane = plane_state->plane;
struct drm_framebuffer *fb = plane_state->fb;
struct drm_rect *src = &plane_state->src;
struct drm_rect *dst = &plane_state->dst;
@@ -792,12 +793,24 @@ int drm_atomic_helper_check_plane_state(struct
drm_plane_state *plane_state,
/* Check scaling */
ret = drm_rect_calc_hscale(src, dst, min_scale, max_scale, &hscale);
- ret |= drm_rect_calc_vscale(src, dst, min_scale, max_scale, &vscale);
if (ret) {
- DRM_DEBUG_KMS("Invalid scaling of plane\n");
+ DRM_DEBUG_KMS("[PLANE:%d:%s] Invalid horizontal scaling factor:
"
+ DRM_FP_FMT " (limits: " DRM_FP_FMT " - "
DRM_FP_FMT ")\n",
+ plane->base.id, plane->name, DRM_FP_ARG(hscale),
+ DRM_FP_ARG(min_scale), DRM_FP_ARG(max_scale));
drm_rect_debug_print("src: ", &plane_state->src, true);
drm_rect_debug_print("dst: ", &plane_state->dst, false);
- return -ERANGE;
+ return ret;
+ }
+ ret = drm_rect_calc_vscale(src, dst, min_scale, max_scale, &vscale);
+ if (ret) {
+ DRM_DEBUG_KMS("[PLANE:%d:%s] Invalid vertical scaling factor: "
+ DRM_FP_FMT " (limits: " DRM_FP_FMT " - "
DRM_FP_FMT ")\n",
+ plane->base.id, plane->name, DRM_FP_ARG(vscale),
+ DRM_FP_ARG(min_scale), DRM_FP_ARG(max_scale));
+ drm_rect_debug_print("src: ", &plane_state->src, true);
+ drm_rect_debug_print("dst: ", &plane_state->dst, false);
+ return ret;
}
if (crtc_state->enable)
diff --git a/include/drm/drm_rect.h b/include/drm/drm_rect.h
index 34a88ba9ca7b..f700ef39f328 100644
--- a/include/drm/drm_rect.h
+++ b/include/drm/drm_rect.h
@@ -53,21 +53,36 @@ struct drm_rect {
#define DRM_RECT_ARG(r) drm_rect_width(r), drm_rect_height(r), (r)->x1, (r)->y1
/**
- * DRM_RECT_FP_FMT - printf string for &struct drm_rect in 16.16 fixed point
+ * DRM_FP_FMT - printf string for 16.16 binary fixed point
+ *
+ * Format a 16.16 binary fixed point number as .6 decimal fixed point.
+ */
+#define DRM_FP_FMT "%d.%06u"
+/**
+ * DRM_FP_ARG - printf arguments for 16.16 binary fixed point
+ * @f: 16.16 binary fixed point number
+ *
+ * This is useful for e.g. printing plane scaling factors, which are in 16.16
+ * binary fixed point.
+ */
+#define DRM_FP_ARG(f) (f) >> 16, (((f) & 0x) * (100 >> (16 - 10))) >>
10
+
+/**
+ * DRM_RECT_FP_FMT - printf string for &struct drm_rect in 16.16 binary fixed
point
+ *
+ * Format a 16.16 binary fixed point rectangle as .6 decimal fixed point.
*/
#define DRM_RECT_FP_FMT "%d.%06ux%d.%06u%+d.%06u%+d.%06u"
/**
- * DRM_RECT_FP_ARG - printf arguments for &struct drm_rect in 16.16 fixed point
+ * DRM_RECT_FP_ARG - printf arguments for &struct drm_rect in 16.16 binary
fixed point
* @r: rectangle struct
*
* This is useful for e.g. printing plane source rectangles, which are in 16.16
- * fixed point.
+ * binary fixed point.
*/
#define DRM_RECT_FP_ARG(r) \
- drm_rect_width(r) >> 16, ((drm_rect_width(r) & 0x) * 15625)
>> 10, \
- drm_rect_height(r) >> 16, ((drm_rect_height(r) & 0x) *
15625) >> 10, \
- (r)->x1 >> 16, (((r)->x1 & 0x) * 15625) >> 10, \
- (r)->y1 >> 16, (((r)->y1 & 0x) * 15625) >> 10
+ DRM_FP_ARG(drm_rect_width(r)), DRM_FP_ARG(drm_rect_height(r)), \
+ DRM_FP_ARG((r)->x1), DRM_FP_ARG((r)->y1)
/**
* drm_rect_adjust_size - adjust the size of the rectangle
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.or
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/3] i915/gem_eio: Race kms on/off vs reset
Quoting Andi Shyti (2019-09-19 15:08:57) > Hi Chris, > > On Wed, Sep 11, 2019 at 11:14:59AM +0100, Chris Wilson wrote: > > On older platforms, performing a GPU reset clobbers the display. > > Exercise the interactions between reset/wedge and the display and > > hopefully prevent any races creeping in. > > > > Signed-off-by: Chris Wilson > > Cc: Ville Syrjälä > > Is Ville Cc'ed for real or just nominally? He's in the original cc. As it is using "Syrjälä", that means I copied his email address from one of his commits, so it should be the right address. mailman naturally drops cc of list members... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Extract GT render sleep (rc6) management
Continuing the theme of breaking intel_pm.c up in a reasonable chunk of
powermanagement utilities, pull out the rc6 setup into its GT handler.
Based on a patch by Chris Wilson.
Signed-off-by: Andi Shyti
Cc: Chris Wilson
---
drivers/gpu/drm/i915/Makefile | 1 +
drivers/gpu/drm/i915/gt/intel_engine_pm.c | 1 +
drivers/gpu/drm/i915/gt/intel_gt.c| 1 +
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 +
drivers/gpu/drm/i915/gt/intel_rc6.c | 666 ++
drivers/gpu/drm/i915/gt/intel_rc6.h | 24 +
drivers/gpu/drm/i915/gt/intel_rc6_types.h | 26 +
drivers/gpu/drm/i915/i915_debugfs.c | 11 +-
drivers/gpu/drm/i915/i915_drv.h | 7 -
drivers/gpu/drm/i915/i915_pmu.c | 9 +-
drivers/gpu/drm/i915/i915_sysfs.c | 4 +-
drivers/gpu/drm/i915/intel_pm.c | 607 +---
drivers/gpu/drm/i915/intel_pm.h | 2 -
13 files changed, 741 insertions(+), 621 deletions(-)
create mode 100644 drivers/gpu/drm/i915/gt/intel_rc6.c
create mode 100644 drivers/gpu/drm/i915/gt/intel_rc6.h
create mode 100644 drivers/gpu/drm/i915/gt/intel_rc6_types.h
diff --git a/drivers/gpu/drm/i915/Makefile b/drivers/gpu/drm/i915/Makefile
index 658b930d34a8..d6c25d21413c 100644
--- a/drivers/gpu/drm/i915/Makefile
+++ b/drivers/gpu/drm/i915/Makefile
@@ -85,6 +85,7 @@ gt-y += \
gt/intel_gt_pm_irq.o \
gt/intel_hangcheck.o \
gt/intel_lrc.o \
+ gt/intel_rc6.o \
gt/intel_renderstate.o \
gt/intel_reset.o \
gt/intel_ringbuffer.o \
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
index 65b5ca74b394..aee39ba3951a 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_pm.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_pm.c
@@ -11,6 +11,7 @@
#include "intel_engine_pool.h"
#include "intel_gt.h"
#include "intel_gt_pm.h"
+#include "intel_rc6.h"
static int __engine_unpark(struct intel_wakeref *wf)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index eef9bdae8ebb..f63d59cdb512 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -7,6 +7,7 @@
#include "intel_gt.h"
#include "intel_gt_pm.h"
#include "intel_mocs.h"
+#include "intel_rc6.h"
#include "intel_uncore.h"
#include "intel_pm.h"
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 3039cef64b11..dd2c612be42a 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -18,6 +18,7 @@
#include "i915_vma.h"
#include "intel_engine_types.h"
#include "intel_reset_types.h"
+#include "intel_rc6_types.h"
#include "intel_wakeref.h"
struct drm_i915_private;
@@ -67,6 +68,8 @@ struct intel_gt {
*/
intel_wakeref_t awake;
+ struct intel_rc6 rc6;
+
struct blocking_notifier_head pm_notifications;
ktime_t last_init_time;
diff --git a/drivers/gpu/drm/i915/gt/intel_rc6.c
b/drivers/gpu/drm/i915/gt/intel_rc6.c
new file mode 100644
index ..9b4ea8a00199
--- /dev/null
+++ b/drivers/gpu/drm/i915/gt/intel_rc6.c
@@ -0,0 +1,666 @@
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2019 Intel Corporation
+ */
+
+#include
+
+#include "i915_drv.h"
+#include "intel_gt.h"
+#include "intel_rc6.h"
+#include "intel_sideband.h"
+
+/**
+ * DOC: RC6
+ *
+ * RC6 is a special power stage which allows the GPU to enter an very
+ * low-voltage mode when idle, using down to 0V while at this stage. This
+ * stage is entered automatically when the GPU is idle when RC6 support is
+ * enabled, and as soon as new workload arises GPU wakes up automatically as
+ * well.
+ *
+ * There are different RC6 modes available in Intel GPU, which differentiate
+ * among each other with the latency required to enter and leave RC6 and
+ * voltage consumed by the GPU in different states.
+ *
+ * The combination of the following flags define which states GPU is allowed
+ * to enter, while RC6 is the normal RC6 state, RC6p is the deep RC6, and
+ * RC6pp is deepest RC6. Their support by hardware varies according to the
+ * GPU, BIOS, chipset and platform. RC6 is usually the safest one and the one
+ * which brings the most power savings; deeper states save more power, but
+ * require higher latency to switch to and wake up.
+ */
+
+static struct intel_gt *rc6_to_gt(struct intel_rc6 *rc6)
+{
+ return container_of(rc6, struct intel_gt, rc6);
+}
+
+static struct intel_uncore *rc6_to_uncore(struct intel_rc6 *rc)
+{
+ return rc6_to_gt(rc)->uncore;
+}
+
+static struct drm_i915_private *rc6_to_i915(struct intel_rc6 *rc)
+{
+ return rc6_to_gt(rc)->i915;
+}
+
+static void gen11_rc6_enable(struct intel_rc6 *rc6)
+{
+ struct intel_uncore *uncore = rc6_to_uncore(rc6);
+ struct intel_engine_cs *engine;
+ enum intel_engine_id id;
+
+ /* 1a: Software RC state - RC0 */
+ intel_u
Re: [Intel-gfx] [PATCH i-g-t 1/3] i915/gem_eio: Race kms on/off vs reset
On Wed, Sep 11, 2019 at 11:14:59AM +0100, Chris Wilson wrote:
> On older platforms, performing a GPU reset clobbers the display.
> Exercise the interactions between reset/wedge and the display and
> hopefully prevent any races creeping in.
>
> Signed-off-by: Chris Wilson
> Cc: Ville Syrjälä
> ---
> tests/i915/gem_eio.c | 79
> 1 file changed, 79 insertions(+)
>
> diff --git a/tests/i915/gem_eio.c b/tests/i915/gem_eio.c
> index 9b086a039..e0213c76c 100644
> --- a/tests/i915/gem_eio.c
> +++ b/tests/i915/gem_eio.c
> @@ -42,6 +42,8 @@
>
> #include "igt.h"
> #include "igt_device.h"
> +#include "igt_fb.h"
> +#include "igt_kms.h"
> #include "igt_stats.h"
> #include "igt_sysfs.h"
> #include "sw_sync.h"
> @@ -813,6 +815,67 @@ static void test_reset_stress(int fd, unsigned int flags)
> gem_context_destroy(fd, ctx0);
> }
>
> +/*
> + * Modesetting vs wedged
> + */
> +
> +static void display_helper(igt_display_t *dpy, int *done)
> +{
> + const int commit = dpy->is_atomic ? COMMIT_ATOMIC : COMMIT_LEGACY;
> + struct igt_fb fb = {};
> +
> + while (!READ_ONCE(*done)) {
> + drmModeModeInfoPtr mode;
> + igt_plane_t *primary;
> + igt_output_t *output;
> + int pipe;
> +
> + pipe = rand() % dpy->n_pipes;
I guess this ends up doing nothing if we get the same pipe twice in a
row? Hmm, I guess it does actually do something but since nothing
significant would change the kernel likely just downgrades it to a
fastset. But maybe that's fine.
There are some reset vs. modeset type of tests in kms_flip, but those
are rather more carefully sequenced so they are probably not so great
at finding new races.
Reviewed-by: Ville Syrjälä
> + output = igt_get_single_output_for_pipe(dpy, pipe);
> + if (!output)
> + continue;
> +
> + igt_output_set_pipe(output, pipe);
> + mode = igt_output_get_mode(output);
> +
> + if (fb.width != mode->hdisplay || fb.height != mode->vdisplay) {
> + igt_remove_fb(dpy->drm_fd, &fb);
> + igt_create_pattern_fb(dpy->drm_fd,
> + mode->hdisplay, mode->vdisplay,
> + DRM_FORMAT_XRGB,
> + LOCAL_I915_FORMAT_MOD_X_TILED,
> + &fb);
> + }
> +
> + primary = igt_output_get_plane_type(output,
> + DRM_PLANE_TYPE_PRIMARY);
> + igt_plane_set_fb(primary, &fb);
> +
> + igt_display_commit2(dpy, commit);
> + igt_display_reset(dpy);
> + }
> +
> + igt_remove_fb(dpy->drm_fd, &fb);
> +}
> +
> +static void test_kms(int i915, igt_display_t *dpy)
> +{
> + int *shared;
> +
> + shared = mmap(NULL, 4096, PROT_WRITE, MAP_SHARED | MAP_ANON, -1, 0);
> + igt_assert(shared != MAP_FAILED);
> +
> + igt_fork(child, 1)
> + display_helper(dpy, shared);
> +
> + test_reset_stress(i915, 0);
> + test_reset_stress(i915, TEST_WEDGE);
> +
> + *shared = 1;
> + igt_waitchildren();
> + munmap(shared, 4096);
> +}
> +
> static int fd = -1;
>
> static void
> @@ -906,4 +969,20 @@ igt_main
> }
> }
> }
> +
> + igt_subtest_group {
> + igt_display_t display = {
> + .drm_fd = -1, .n_pipes = IGT_MAX_PIPES
> + };
> +
> + igt_fixture {
> + igt_device_set_master(fd);
> +
> + igt_display_require(&display, fd);
> + igt_display_require_output(&display);
> + }
> +
> + igt_subtest("kms")
> + test_kms(fd, &display);
> + }
> }
> --
> 2.23.0
--
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: Extract GT render sleep (rc6) management
Quoting Andi Shyti (2019-09-19 15:38:40) > Continuing the theme of breaking intel_pm.c up in a reasonable chunk of > powermanagement utilities, pull out the rc6 setup into its GT handler. > > Based on a patch by Chris Wilson. > > Signed-off-by: Andi Shyti > Cc: Chris Wilson Nothing jumped out as odd on reading, and I'm confident in our detection of lack of rc6 in igt. Hoping CI doesn't prove me wrong, 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 11/13] drm/i915: move gem init up from modeset init
On Thu, 19 Sep 2019, Chris Wilson wrote: > Quoting Jani Nikula (2019-09-19 15:03:58) >> Pair the gem init and cleanup in the same layer. This moves the gem init >> before the modeset init. > > The important part here was that BIOS takeover by display is before we > clear the GGTT in i915_gem_init -> i915_init_ggtt. iirc marking up the > preallocated GGTT ranges is in intel_modeset_init. Aww, thanks. More dragons to tame. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: fix SFC reset flow (rev2)
== Series Details == Series: drm/i915: fix SFC reset flow (rev2) URL : https://patchwork.freedesktop.org/series/66779/ State : success == Summary == CI Bug Log - changes from CI_DRM_6917_full -> Patchwork_14451_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14451_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@nop: - shard-apl: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927]) +2 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl7/igt@gem_exec_balan...@nop.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl4/igt@gem_exec_balan...@nop.html * igt@gem_exec_schedule@preempt-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb8/igt@gem_exec_sched...@preempt-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb1/igt@gem_exec_sched...@preempt-bsd.html * igt@gem_exec_schedule@preempt-queue-bsd1: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +14 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb1/igt@gem_exec_sched...@preempt-queue-bsd1.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb3/igt@gem_exec_sched...@preempt-queue-bsd1.html * igt@gem_workarounds@suspend-resume-fd: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl5/igt@gem_workarou...@suspend-resume-fd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl1/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rpm@system-suspend-modeset: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#104108] / [fdo#107807]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl8/igt@i915_pm_...@system-suspend-modeset.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl10/igt@i915_pm_...@system-suspend-modeset.html * igt@i915_selftest@mock_fence: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@i915_selftest@mock_fence.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb7/igt@i915_selftest@mock_fence.html * igt@kms_cursor_legacy@cursor-vs-flip-legacy: - shard-hsw: [PASS][13] -> [FAIL][14] ([fdo#103355]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-hsw8/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-hsw6/igt@kms_cursor_leg...@cursor-vs-flip-legacy.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#109507]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-skl7/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-skl1/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +6 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl3/igt@kms_frontbuffer_track...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl8/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +5 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_psr@psr2_basic: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109441]) +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-iclb2/igt@kms_psr@psr2_basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-iclb3/igt@kms_psr@psr2_basic.html Possible fixes * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [DMESG-WARN][23] ([fdo#108566]) -> [PASS][24] +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6917/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14451/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [SKIP][25] ([fdo#111325]) -> [PASS][26] +5 similar issues [25]: https://intel-gfx-
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/selftests: Exercise CS TLB invalidation (rev2)
== Series Details == Series: drm/i915/selftests: Exercise CS TLB invalidation (rev2) URL : https://patchwork.freedesktop.org/series/66718/ State : warning == Summary == $ dim checkpatch origin/drm-tip e5422e652e53 drm/i915/selftests: Exercise CS TLB invalidation -:90: WARNING:MEMORY_BARRIER: memory barrier without comment #90: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1760: + wmb(); -:282: WARNING:MEMORY_BARRIER: memory barrier without comment #282: FILE: drivers/gpu/drm/i915/selftests/i915_gem_gtt.c:1952: + wmb(); total: 0 errors, 2 warnings, 0 checks, 333 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops
It is expected that processes will pass dma-buf fd between drivers, and
only using the fd themselves for mmaping and synchronisation ioctls.
However, it may be convenient for an application to read/write into the
dma-buf, for instance a test case to check the internal
dma_buf->ops->kmap interface. There may also be a small advantage to
avoiding the mmap() for very simple/small operations.
Note in particular, synchronisation with the device is left to the
caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
inside the read/write, so that the user can avoid synchronisation if
they so choose.
"It is easier to add synchronisation later, than it is to take it away."
v2: Lots of little fixes, plus a real llseek() implements so that the
first basic little test cases work!
Testcase: igt/prime_rw
Signed-off-by: Chris Wilson
Cc: Laura Abbott
Cc: Sumit Semwal
Cc: Daniel Vetter
Cc: Sean Paul
Cc: Janusz Krzysztofik
Tested-by: Laura Abbott
---
Dusting this off again as it would be nice as a user to operate on dmabuf
agnostic to the underyling driver. We have mmap, so naturally we would
like to have read/write as well!
---
drivers/dma-buf/dma-buf.c | 108 --
1 file changed, 93 insertions(+), 15 deletions(-)
diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
index 433d91d710e4..a19fc881a99c 100644
--- a/drivers/dma-buf/dma-buf.c
+++ b/drivers/dma-buf/dma-buf.c
@@ -135,28 +135,104 @@ static int dma_buf_mmap_internal(struct file *file,
struct vm_area_struct *vma)
static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
{
- struct dma_buf *dmabuf;
- loff_t base;
+ struct dma_buf *dmabuf = file->private_data;
if (!is_dma_buf_file(file))
return -EBADF;
- dmabuf = file->private_data;
+ return fixed_size_llseek(file, offset, whence, dmabuf->size);
+}
- /* only support discovering the end of the buffer,
- but also allow SEEK_SET to maintain the idiomatic
- SEEK_END(0), SEEK_CUR(0) pattern */
- if (whence == SEEK_END)
- base = dmabuf->size;
- else if (whence == SEEK_SET)
- base = 0;
- else
- return -EINVAL;
+static ssize_t dma_buf_read(struct file *file,
+ char __user *ubuf, size_t remain,
+ loff_t *offset)
+{
+ struct dma_buf *dmabuf = file->private_data;
+ unsigned long idx;
+ unsigned int start;
+ size_t total;
- if (offset != 0)
- return -EINVAL;
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ total = 0;
+ idx = *offset >> PAGE_SHIFT;
+ start = offset_in_page(*offset);
+ while (remain) {
+ unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+ unsigned int copied;
+ void *vaddr;
+
+ if (*offset >= dmabuf->size)
+ return total;
+
+ vaddr = dma_buf_kmap(dmabuf, idx);
+ if (!vaddr)
+ return total ?: -EIO;
+
+ copied = copy_to_user(ubuf, vaddr + start, len);
+ dma_buf_kunmap(dmabuf, idx, vaddr);
+
+ total += copied ?: len;
+ if (copied) {
+ *offset += copied;
+ return total ?: -EFAULT;
+ }
+
+ remain -= len;
+ *offset += len;
+ ubuf += len;
+ start = 0;
+ idx++;
+ }
+
+ return total;
+}
+
+static ssize_t dma_buf_write(struct file *file,
+const char __user *ubuf, size_t remain,
+loff_t *offset)
+{
+ struct dma_buf *dmabuf = file->private_data;
+ unsigned long idx;
+ unsigned int start;
+ size_t total;
+
+ if (!is_dma_buf_file(file))
+ return -EBADF;
+
+ total = 0;
+ idx = *offset >> PAGE_SHIFT;
+ start = offset_in_page(*offset);
+ while (remain) {
+ unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
+ unsigned int copied;
+ void *vaddr;
+
+ if (*offset >= dmabuf->size)
+ return total;
+
+ vaddr = dma_buf_kmap(dmabuf, idx);
+ if (!vaddr)
+ return total ?: -EIO;
+
+ copied = copy_from_user(vaddr + start, ubuf, len);
+ dma_buf_kunmap(dmabuf, idx, vaddr);
+
+ total += copied ?: len;
+ if (copied) {
+ *offset += copied;
+ return total ?: -EFAULT;
+ }
+
+ remain -= len;
+ *offset += len;
+ ubuf += len;
+ start = 0;
+ idx++;
+ }
- return base + offset;
+ return total;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Exercise CS TLB invalidation (rev2)
== Series Details ==
Series: drm/i915/selftests: Exercise CS TLB invalidation (rev2)
URL : https://patchwork.freedesktop.org/series/66718/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6920 -> Patchwork_14455
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14455:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@i915_selftest@live_gtt:
- {fi-tgl-u}: [PASS][1] -> [DMESG-FAIL][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-tgl-u/igt@i915_selftest@live_gtt.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-tgl-u/igt@i915_selftest@live_gtt.html
- {fi-tgl-u2}:[PASS][3] -> [DMESG-FAIL][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-tgl-u2/igt@i915_selftest@live_gtt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-tgl-u2/igt@i915_selftest@live_gtt.html
Known issues
Here are the changes found in Patchwork_14455 that come from known issues:
### IGT changes ###
Issues hit
* igt@vgem_basic@sysfs:
- fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1
similar issue
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-icl-u3/igt@vgem_ba...@sysfs.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-icl-u3/igt@vgem_ba...@sysfs.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- {fi-tgl-u2}:[DMESG-WARN][7] ([fdo#111600]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
* igt@gem_close_race@basic-threads:
- fi-bxt-dsi: [INCOMPLETE][9] ([fdo#103927]) -> [PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-bxt-dsi/igt@gem_close_r...@basic-threads.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-bxt-dsi/igt@gem_close_r...@basic-threads.html
* igt@gem_ctx_create@basic-files:
- {fi-icl-u4}:[INCOMPLETE][11] ([fdo#107713] / [fdo#109100]) ->
[PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] +2
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-guc: [INCOMPLETE][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html
Warnings
* igt@i915_pm_rpm@basic-pci-d3-state:
- fi-kbl-guc: [SKIP][17] ([fdo#109271]) -> [FAIL][18] ([fdo#110829])
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14455/fi-kbl-guc/igt@i915_pm_...@basic-pci-d3-state.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#110829]: https://bugs.freedesktop.org/show_bug.cgi?id=110829
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111739]: https://bugs.freedesktop.org/show_bug.cgi?id=111739
Participating hosts (53 -> 46)
--
Additional (1): fi-bsw-n3050
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-apl-guc fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_692
[Intel-gfx] [PATCH v2] drm/i915/tgl: Suspend pre-parser across GTT invalidations
Before we execute a batch, we must first issue any and all TLB
invalidations so that batch picks up the new page table entries.
Tigerlake's preparser is weakening our post-sync CS_STALL inside the
invalidate pipe-control and allowing the loading of the batch buffer
before we have setup its page table (and so it loads the wrong page and
executes indefinitely).
The igt_cs_tlb indicates that this issue can only be observed on rcs,
even though the preparser is common to all engines. Alternatively, we
could do TLB shootdown via mmio on updating the GTT.
By inserting the pre-parser disable inside EMIT_INVALIDATE, we will also
accidentally fixup execution that writes into subsequent batches, such
as gem_exec_whisper and even relocations performed on the GPU. We should
be careful not to allow this disable to become baked into the uABI!
Testcase: igt/i915_selftests/live_gtt/igt_cs_tlb
Signed-off-by: Chris Wilson
Cc: Daniele Ceraolo Spurio
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_lrc.c | 75 -
1 file changed, 74 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index a99166a2d2eb..60b7b163c3d0 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2807,6 +2807,79 @@ static int gen11_emit_flush_render(struct i915_request
*request,
return 0;
}
+static u32 preparser_disable(bool state)
+{
+ return MI_ARB_CHECK | 1 << 8 | state;
+}
+
+static int gen12_emit_flush_render(struct i915_request *request,
+ u32 mode)
+{
+ struct intel_engine_cs *engine = request->engine;
+ const u32 scratch_addr =
+ intel_gt_scratch_offset(engine->gt,
+ INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
+
+ if (mode & EMIT_FLUSH) {
+ u32 flags = 0;
+ u32 *cs;
+
+ flags |= PIPE_CONTROL_TILE_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
+ flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
+ flags |= PIPE_CONTROL_FLUSH_ENABLE;
+
+ flags |= PIPE_CONTROL_QW_WRITE;
+ flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+
+ flags |= PIPE_CONTROL_CS_STALL;
+
+ cs = intel_ring_begin(request, 6);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ cs = gen8_emit_pipe_control(cs, flags, scratch_addr);
+ intel_ring_advance(request, cs);
+ }
+
+ if (mode & EMIT_INVALIDATE) {
+ u32 flags = 0;
+ u32 *cs;
+
+ flags |= PIPE_CONTROL_COMMAND_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_TLB_INVALIDATE;
+ flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
+ flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
+
+ flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+ flags |= PIPE_CONTROL_QW_WRITE;
+
+ flags |= PIPE_CONTROL_CS_STALL;
+
+ cs = intel_ring_begin(request, 8);
+ if (IS_ERR(cs))
+ return PTR_ERR(cs);
+
+ /*
+* Prevent the pre-parser from skipping past the TLB
+* invalidate and loading a stale page for the batch
+* buffer / request payload.
+*/
+ *cs++ = preparser_disable(true);
+
+ cs = gen8_emit_pipe_control(cs, flags, scratch_addr);
+
+ *cs++ = preparser_disable(false);
+ intel_ring_advance(request, cs);
+ }
+
+ return 0;
+}
+
/*
* Reserve space for 2 NOOPs at the end of each request to be
* used as a workaround for not being allowed to do lite
@@ -3072,7 +3145,7 @@ static void rcs_submission_override(struct
intel_engine_cs *engine)
{
switch (INTEL_GEN(engine->i915)) {
case 12:
- engine->emit_flush = gen11_emit_flush_render;
+ engine->emit_flush = gen12_emit_flush_render;
engine->emit_fini_breadcrumb = gen12_emit_fini_breadcrumb_rcs;
break;
case 11:
--
2.23.0
___
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: Unify ICP and MCC hotplug pin tables
On Wed, Sep 18, 2019 at 05:45:27PM -0700, Souza, Jose wrote:
> On Wed, 2019-09-18 at 16:56 -0700, Matt Roper wrote:
> > The MCC hpd table is just a subset of the ICP table; we can eliminate
> > it
> > and use the ICP table everywhere. The extra pins in the table won't
> > be
> > a problem for MCC since we still supply an appropriate hotplug
> > trigger
> > mask anywhere the pin table is used.
> >
>
> Reviewed-by: José Roberto de Souza
Applied both to dinq. Thanks for the reviews.
Matt
>
> > Cc: José Roberto de Souza
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 10 ++
> > 1 file changed, 2 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index ae7228032d2c..bc83f094065a 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -157,12 +157,6 @@ static const u32 hpd_icp[HPD_NUM_PINS] = {
> > [HPD_PORT_F] = SDE_TC_HOTPLUG_ICP(PORT_TC4),
> > };
> >
> > -static const u32 hpd_mcc[HPD_NUM_PINS] = {
> > - [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
> > - [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
> > - [HPD_PORT_C] = SDE_TC_HOTPLUG_ICP(PORT_TC1),
> > -};
> > -
> > static const u32 hpd_tgp[HPD_NUM_PINS] = {
> > [HPD_PORT_A] = SDE_DDI_HOTPLUG_ICP(PORT_A),
> > [HPD_PORT_B] = SDE_DDI_HOTPLUG_ICP(PORT_B),
> > @@ -2258,7 +2252,7 @@ static void icp_irq_handler(struct
> > drm_i915_private *dev_priv, u32 pch_iir)
> > } else if (HAS_PCH_MCC(dev_priv)) {
> > ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_TGP;
> > tc_hotplug_trigger = 0;
> > - pins = hpd_mcc;
> > + pins = hpd_icp;
> > } else {
> > ddi_hotplug_trigger = pch_iir & SDE_DDI_MASK_ICP;
> > tc_hotplug_trigger = pch_iir & SDE_TC_MASK_ICP;
> > @@ -3434,7 +3428,7 @@ static void mcc_hpd_irq_setup(struct
> > drm_i915_private *dev_priv)
> > icp_hpd_irq_setup(dev_priv,
> > SDE_DDI_MASK_TGP, 0,
> > TGP_DDI_HPD_ENABLE_MASK, 0,
> > - hpd_mcc);
> > + hpd_icp);
> > }
> >
> > static void gen11_hpd_detection_setup(struct drm_i915_private
> > *dev_priv)
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/tgl: Implement Wa_1409142259
On Wed, Sep 18, 2019 at 04:05:06PM -0700, Sripada, Radhakrishna wrote:
> Hi Daniele,
>
> Thanks for the review. Can you help me merge this pathc?
>
> Thanks,
> Radhakrishna(RK) Sripada
Applied to dinq. Thanks for the patch and review.
Matt
>
> > -Original Message-
> > From: Ceraolo Spurio, Daniele
> > Sent: Wednesday, September 11, 2019 11:12 AM
> > To: Sripada, Radhakrishna ; intel-
> > g...@lists.freedesktop.org
> > Cc: Summers, Stuart ; Roper, Matthew D
> >
> > Subject: Re: [PATCH v2] drm/i915/tgl: Implement Wa_1409142259
> >
> >
> >
> > On 9/9/19 4:14 PM, Radhakrishna Sripada wrote:
> > > Disable CPS aware color pipe by setting chicken bit.
> > >
> > > BSpec: 52890
> > > HSDES: 1409142259
> > >
> > > v2: Move WA to ctx WA's(Daniele)
> > >
> > > Cc: Daniele Ceraolo Spurio
> > > Cc: Stuart Summers
> > > Cc: Matt Roper
> > > Signed-off-by: Radhakrishna Sripada
> >
> > Reviewed-by: Daniele Ceraolo Spurio
> >
> > Daniele
> >
> > > ---
> > > drivers/gpu/drm/i915/gt/intel_workarounds.c | 3 +++
> > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > 2 files changed, 4 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > index 243d3f77be13..95ef2f1dfdbb 100644
> > > --- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > +++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
> > > @@ -567,6 +567,9 @@ static void icl_ctx_workarounds_init(struct
> > intel_engine_cs *engine,
> > > static void tgl_ctx_workarounds_init(struct intel_engine_cs *engine,
> > >struct i915_wa_list *wal)
> > > {
> > > + /* Wa_1409142259 */
> > > + WA_SET_BIT_MASKED(GEN11_COMMON_SLICE_CHICKEN3,
> > > + GEN12_DISABLE_CPS_AWARE_COLOR_PIPE);
> > > }
> > >
> > > static void
> > > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > > b/drivers/gpu/drm/i915/i915_reg.h index 006cffd56be2..53e07882efb7
> > > 100644
> > > --- a/drivers/gpu/drm/i915/i915_reg.h
> > > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > > @@ -7668,6 +7668,7 @@ enum {
> > >
> > > #define GEN11_COMMON_SLICE_CHICKEN3
> > _MMIO(0x7304)
> > > #define GEN11_BLEND_EMB_FIX_DISABLE_IN_RCC(1 << 11)
> > > + #define GEN12_DISABLE_CPS_AWARE_COLOR_PIPE (1 << 9)
> > >
> > > #define HIZ_CHICKEN
> > _MMIO(0x7018)
> > > # define CHV_HZ_8X8_MODE_IN_1X (1 <<
> > 15)
> > >
--
Matt Roper
Graphics Software Engineer
VTT-OSGC Platform Enablement
Intel Corporation
(916) 356-2795
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops
On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote:
>
> It is expected that processes will pass dma-buf fd between drivers, and
> only using the fd themselves for mmaping and synchronisation ioctls.
> However, it may be convenient for an application to read/write into the
> dma-buf, for instance a test case to check the internal
> dma_buf->ops->kmap interface. There may also be a small advantage to
> avoiding the mmap() for very simple/small operations.
>
> Note in particular, synchronisation with the device is left to the
> caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly
> inside the read/write, so that the user can avoid synchronisation if
> they so choose.
>
> "It is easier to add synchronisation later, than it is to take it away."
Hm for mmap I think the explicit sync makes sense (we might even want
to do it in userspace). Not so sure it's a great idea for read/write
... I guess we'd need to see what people have/had in mind for the
userspace for this to decide.
Only other thought I have on this is that many dma-buf exporters don't
bother with the kmap/kunmap interface (probably fewer than those who
bother with kernel vmap and mmap), maybe we want at least a vmap
fallback for this. Or maybe just use that as an excuse to get more
people to wire up the kmap stuff :-)
-Daniel
> v2: Lots of little fixes, plus a real llseek() implements so that the
> first basic little test cases work!
>
> Testcase: igt/prime_rw
> Signed-off-by: Chris Wilson
> Cc: Laura Abbott
> Cc: Sumit Semwal
> Cc: Daniel Vetter
> Cc: Sean Paul
> Cc: Janusz Krzysztofik
> Tested-by: Laura Abbott
> ---
> Dusting this off again as it would be nice as a user to operate on dmabuf
> agnostic to the underyling driver. We have mmap, so naturally we would
> like to have read/write as well!
>
> ---
> drivers/dma-buf/dma-buf.c | 108 --
> 1 file changed, 93 insertions(+), 15 deletions(-)
>
> diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c
> index 433d91d710e4..a19fc881a99c 100644
> --- a/drivers/dma-buf/dma-buf.c
> +++ b/drivers/dma-buf/dma-buf.c
> @@ -135,28 +135,104 @@ static int dma_buf_mmap_internal(struct file *file,
> struct vm_area_struct *vma)
>
> static loff_t dma_buf_llseek(struct file *file, loff_t offset, int whence)
> {
> - struct dma_buf *dmabuf;
> - loff_t base;
> + struct dma_buf *dmabuf = file->private_data;
>
> if (!is_dma_buf_file(file))
> return -EBADF;
>
> - dmabuf = file->private_data;
> + return fixed_size_llseek(file, offset, whence, dmabuf->size);
> +}
>
> - /* only support discovering the end of the buffer,
> - but also allow SEEK_SET to maintain the idiomatic
> - SEEK_END(0), SEEK_CUR(0) pattern */
> - if (whence == SEEK_END)
> - base = dmabuf->size;
> - else if (whence == SEEK_SET)
> - base = 0;
> - else
> - return -EINVAL;
> +static ssize_t dma_buf_read(struct file *file,
> + char __user *ubuf, size_t remain,
> + loff_t *offset)
> +{
> + struct dma_buf *dmabuf = file->private_data;
> + unsigned long idx;
> + unsigned int start;
> + size_t total;
>
> - if (offset != 0)
> - return -EINVAL;
> + if (!is_dma_buf_file(file))
> + return -EBADF;
> +
> + total = 0;
> + idx = *offset >> PAGE_SHIFT;
> + start = offset_in_page(*offset);
> + while (remain) {
> + unsigned int len = min_t(size_t, remain, PAGE_SIZE - start);
> + unsigned int copied;
> + void *vaddr;
> +
> + if (*offset >= dmabuf->size)
> + return total;
> +
> + vaddr = dma_buf_kmap(dmabuf, idx);
> + if (!vaddr)
> + return total ?: -EIO;
> +
> + copied = copy_to_user(ubuf, vaddr + start, len);
> + dma_buf_kunmap(dmabuf, idx, vaddr);
> +
> + total += copied ?: len;
> + if (copied) {
> + *offset += copied;
> + return total ?: -EFAULT;
> + }
> +
> + remain -= len;
> + *offset += len;
> + ubuf += len;
> + start = 0;
> + idx++;
> + }
> +
> + return total;
> +}
> +
> +static ssize_t dma_buf_write(struct file *file,
> +const char __user *ubuf, size_t remain,
> +loff_t *offset)
> +{
> + struct dma_buf *dmabuf = file->private_data;
> + unsigned long idx;
> + unsigned int start;
> + size_t total;
> +
> + if (!is_dma_buf_file(file))
> + return -EBADF;
> +
> + total = 0;
> + idx = *offset >> PAGE_SHIFT;
> + start = offset_in_page(*offset);
> + while (remain) {
> +
Re: [Intel-gfx] [PATCH 01/13] drm/i915: add i915_driver_modeset_remove()
Quoting Jani Nikula (2019-09-19 15:03:48) > For completeness, add counterpart to i915_driver_modeset_probe() and > remove the asymmetry in the probe/remove parts. No functional changes. > > Signed-off-by: Jani Nikula 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 02/13] drm/i915: pass i915 to i915_driver_modeset_probe()
Quoting Jani Nikula (2019-09-19 15:03:49) > In general, prefer struct drm_i915_private * over struct drm_device * > when either will do. Rename the local variable to i915. No functional > changes. > > Signed-off-by: Jani Nikula 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 03/13] drm/i915: pass i915 to intel_modeset_driver_remove()
Quoting Jani Nikula (2019-09-19 15:03:50) > In general, prefer struct drm_i915_private * over struct drm_device * > when either will do. Rename the local variable to i915. Also propagate > to intel_hpd_poll_fini(). No functional changes. > > Signed-off-by: Jani Nikula 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 04/13] drm/i915: abstract intel_panel_sanitize_ssc() from intel_modeset_init()
Quoting Jani Nikula (2019-09-19 15:03:51)
> The code is too specific and detailed to have open in a high level
> function. Abstract away. As a drive-by improvement switch to using
> enableddisabled() in logging. No functional changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 39 +++-
> 1 file changed, 22 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index c0fc66903fec..ee0d34d76b08 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -7539,6 +7539,27 @@ intel_link_compute_m_n(u16 bits_per_pixel, int nlanes,
> constant_n);
> }
>
> +static void intel_panel_sanitize_ssc(struct drm_i915_private *dev_priv)
> +{
> + /*
> +* There may be no VBT; and if the BIOS enabled SSC we can
> +* just keep using it to avoid unnecessary flicker. Whereas if the
> +* BIOS isn't using it, don't assume it will work even if the VBT
> +* indicates as much.
> +*/
> + if (HAS_PCH_IBX(dev_priv) || HAS_PCH_CPT(dev_priv)) {
> + bool bios_lvds_use_ssc = !!(I915_READ(PCH_DREF_CONTROL) &
> + DREF_SSC1_ENABLE);
You could drive-by remove !! as well.
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 05/13] drm/i915: abstract intel_mode_config_init() from intel_modeset_init()
Quoting Jani Nikula (2019-09-19 15:03:52)
> The i915 specific mode config init code is too specific and detailed to
> have open in a high level function. Abstract away. No functional
> changes.
>
> Signed-off-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/display/intel_display.c | 85 +++-
> 1 file changed, 46 insertions(+), 39 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/intel_display.c
> index ee0d34d76b08..040ee006b047 100644
> --- a/drivers/gpu/drm/i915/display/intel_display.c
> +++ b/drivers/gpu/drm/i915/display/intel_display.c
> @@ -16100,6 +16100,50 @@ static int intel_initial_commit(struct drm_device
> *dev)
> return ret;
> }
>
> +static void intel_mode_config_init(struct drm_i915_private *i915)
> +{
> + struct drm_mode_config *mode_config = &i915->drm.mode_config;
Nest
drm_mode_config_init(mode_config);
here?
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 06/13] drm/i915: pass i915 to intel_modeset_init() and intel_modeset_init_hw()
Quoting Jani Nikula (2019-09-19 15:03:53) > In general, prefer struct drm_i915_private * over struct drm_device * > when either will do. Rename the local variables to i915. No functional > changes. > > Signed-off-by: Jani Nikula 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 video/hdmi: Fix AVI bar unpack
== Series Details ==
Series: video/hdmi: Fix AVI bar unpack
URL : https://patchwork.freedesktop.org/series/66930/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6920 -> Patchwork_14456
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/
Known issues
Here are the changes found in Patchwork_14456 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_module_load@reload:
- fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724] /
[fdo#111214])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-icl-u3/igt@i915_module_l...@reload.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-icl-u3/igt@i915_module_l...@reload.html
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: [PASS][3] -> [INCOMPLETE][4] ([fdo#107718])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html
Possible fixes
* igt@debugfs_test@read_all_entries:
- {fi-tgl-u2}:[DMESG-WARN][5] ([fdo#111600]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-tgl-u2/igt@debugfs_test@read_all_entries.html
* igt@gem_close_race@basic-threads:
- fi-bxt-dsi: [INCOMPLETE][7] ([fdo#103927]) -> [PASS][8]
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-bxt-dsi/igt@gem_close_r...@basic-threads.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-bxt-dsi/igt@gem_close_r...@basic-threads.html
* igt@gem_ctx_create@basic-files:
- {fi-icl-u4}:[INCOMPLETE][9] ([fdo#107713] / [fdo#109100]) ->
[PASS][10]
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-icl-u4/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_fence@nb-await-default:
- {fi-tgl-u}: [FAIL][11] ([fdo#111562] / [fdo#111597]) -> [PASS][12]
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-tgl-u/igt@gem_exec_fe...@nb-await-default.html
* igt@gem_mmap_gtt@basic-write-no-prefault:
- fi-icl-u3: [DMESG-WARN][13] ([fdo#107724]) -> [PASS][14] +3
similar issues
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-icl-u3/igt@gem_mmap_...@basic-write-no-prefault.html
* igt@i915_selftest@live_gem_contexts:
- fi-skl-guc: [INCOMPLETE][15] -> [PASS][16]
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6920/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14456/fi-skl-guc/igt@i915_selftest@live_gem_contexts.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724
[fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#111214]: https://bugs.freedesktop.org/show_bug.cgi?id=111214
[fdo#111562]: https://bugs.freedesktop.org/show_bug.cgi?id=111562
[fdo#111597]: https://bugs.freedesktop.org/show_bug.cgi?id=111597
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
[fdo#111739]: https://bugs.freedesktop.org/show_bug.cgi?id=111739
Participating hosts (53 -> 46)
--
Additional (1): fi-bsw-n3050
Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-byt-clapper fi-icl-y fi-icl-dsi fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6920 -> Patchwork_14456
CI-20190529: 20190529
CI_DRM_6920: 7b7f2c82b41efd0468f75fa935687f670c6bd9e3 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5192: 77c53210779c30cfb8a4ca2312675fe5be94f4d5 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14456: f032213fe152fa7654da48b6d47d4163c25dce1b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
f032213fe152 video/hdmi: Fix AVI bar unpack
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/dr
Re: [Intel-gfx] [PATCH 07/13] drm/i915: split intel_modeset_driver_remove() to pre/post irq uninstall
Quoting Jani Nikula (2019-09-19 15:03:54) > Split intel_modeset_driver_remove() to two, the part with working irqs > before irq uninstall, and the part after irq uninstall. > > The error path in i915_driver_modeset_probe() looks obviously weird > after this, but remains as good or broken as it ever was. No functional > changes. > > Signed-off-by: Jani Nikula Memory says _noirq is used by pm code as having irqs available is the norm. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops
Quoting Daniel Vetter (2019-09-19 16:28:41) > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson wrote: > > > > It is expected that processes will pass dma-buf fd between drivers, and > > only using the fd themselves for mmaping and synchronisation ioctls. > > However, it may be convenient for an application to read/write into the > > dma-buf, for instance a test case to check the internal > > dma_buf->ops->kmap interface. There may also be a small advantage to > > avoiding the mmap() for very simple/small operations. > > > > Note in particular, synchronisation with the device is left to the > > caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly > > inside the read/write, so that the user can avoid synchronisation if > > they so choose. > > > > "It is easier to add synchronisation later, than it is to take it away." > > Hm for mmap I think the explicit sync makes sense (we might even want > to do it in userspace). Not so sure it's a great idea for read/write > ... I guess we'd need to see what people have/had in mind for the > userspace for this to decide. There's an O_SYNC flag for open(2): O_SYNC Write operations on the file will complete according to the requirements of synchronized I/O file integrity completion (by contrast with the synchronized I/O data integrity completion provided by O_DSYNC.) By the time write(2) (or similar) returns, the output data and associated file metadata have been transferred to the underly‐ ing hardware (i.e., as though each write(2) was followed by a call to fsync(2)). That seems applicable here? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] dma-buf: Implement simple read/write vfs ops
On Thu, Sep 19, 2019 at 5:53 PM Chris Wilson wrote: > > Quoting Daniel Vetter (2019-09-19 16:28:41) > > On Thu, Sep 19, 2019 at 5:09 PM Chris Wilson > > wrote: > > > > > > It is expected that processes will pass dma-buf fd between drivers, and > > > only using the fd themselves for mmaping and synchronisation ioctls. > > > However, it may be convenient for an application to read/write into the > > > dma-buf, for instance a test case to check the internal > > > dma_buf->ops->kmap interface. There may also be a small advantage to > > > avoiding the mmap() for very simple/small operations. > > > > > > Note in particular, synchronisation with the device is left to the > > > caller with an explicit DMA_BUF_IOCTL_SYNC, rather than done implicitly > > > inside the read/write, so that the user can avoid synchronisation if > > > they so choose. > > > > > > "It is easier to add synchronisation later, than it is to take it away." > > > > Hm for mmap I think the explicit sync makes sense (we might even want > > to do it in userspace). Not so sure it's a great idea for read/write > > ... I guess we'd need to see what people have/had in mind for the > > userspace for this to decide. > > There's an O_SYNC flag for open(2): > >O_SYNC Write operations on the file will complete according to the > requirements of synchronized I/O file integrity completion (by > contrast with the synchronized I/O data integrity completion > provided by O_DSYNC.) > > By the time write(2) (or similar) returns, the output data and > associated file metadata have been transferred to the underly‐ > ing hardware (i.e., as though each write(2) was followed by a > call to fsync(2)). > > That seems applicable here? Hm yeah, sounds like a neat idea to use O_SYNC to decide whether writes/reads flushes or not. It's a bit a stretch since !O_SYNC would also give you un-coherent reads (or could at least). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 01/21] sna: Use -Wno-clobbered
From: Ville Syrjälä
../src/sna/sna_composite.c:567:11: warning: variable ‘sx’ might be clobbered by
‘longjmp’ or ‘vfork’ [-Wclobbered]
int16_t sx = src_x + tx - (dst->pDrawable->x + dst_x);
^~
etc.
I had a quick look at a few of the cases and they seemed fine to me,
so feels like gcc just being dense.
Signed-off-by: Ville Syrjälä
---
src/sna/meson.build | 1 +
1 file changed, 1 insertion(+)
diff --git a/src/sna/meson.build b/src/sna/meson.build
index 5631d4d8047f..4af181f37b29 100644
--- a/src/sna/meson.build
+++ b/src/sna/meson.build
@@ -135,5 +135,6 @@ sna = static_library('sna',
'-Wno-unused-parameter',
'-Wno-sign-compare',
'-Wno-type-limits',
+ '-Wno-clobbered',
],
install : false)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 03/21] sna: undef FontSetPrivate() before redefining it
From: Ville Syrjälä Avoid the compiler gettings upset about us redefining FontSetPrivate(). Signed-off-by: Ville Syrjälä --- src/sna/sna_accel.c | 1 + 1 file changed, 1 insertion(+) diff --git a/src/sna/sna_accel.c b/src/sna/sna_accel.c index 7fd00b9af679..934c8f662bea 100644 --- a/src/sna/sna_accel.c +++ b/src/sna/sna_accel.c @@ -121,6 +121,7 @@ #if XFONT2_CLIENT_FUNCS_VERSION >= 1 #define AllocateFontPrivateIndex() xfont2_allocate_font_private_index() +#undef FontSetPrivate #define FontSetPrivate(font, idx, data) xfont2_font_set_private(font, idx, data) #endif -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 02/21] sna: Shut up more compiler warns
From: Ville Syrjälä
Suppress more compiler warnings.
Signed-off-by: Ville Syrjälä
---
src/sna/meson.build | 3 +++
1 file changed, 3 insertions(+)
diff --git a/src/sna/meson.build b/src/sna/meson.build
index 4af181f37b29..b1276ab3aa6e 100644
--- a/src/sna/meson.build
+++ b/src/sna/meson.build
@@ -131,8 +131,11 @@ sna = static_library('sna',
c_args : [
'-Wno-missing-field-initializers',
'-Wno-unused-but-set-variable',
+ '-Wno-expansion-to-defined',
'-Wno-shift-negative-value',
'-Wno-unused-parameter',
+ '-Wno-unused-function',
+ '-Wno-unused-variable',
'-Wno-sign-compare',
'-Wno-type-limits',
'-Wno-clobbered',
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 00/21] Compiler warn elimination
From: Ville Syrjälä Random smattering of patches to eliminate compiler warnings. Some I just suppressed out of lazyness, others I tried to silence by adjusting the code a bit. Afterwards the build is clean on my gcc 8.3, though with a bunch of stuff still suppressed I'm not 100% sure that's a good thing. git://github.com/vsyrjala/xf86-video-intel.git compiler_warns_3 Ville Syrjälä (21): sna: Use -Wno-clobbered sna: Shut up more compiler warns sna: undef FontSetPrivate() before redefining it sna: Replace fall through comments with standard form sna: Annotate more fall throughs sna: Add sna_br13_color_depth() sna/fb: Eliminate implicit fallthrough uxa: Use named initializers Avoid missing initializer warning sna: Use named initializers sna: Increase the size of the path name buffer a bit sna: Use memcmp() to avoid strict aliasing warns sna: Avoid strict aliasing violations with glyphinfo sna/fb: Use memcpy() to avoid strict aliasing violations xvmc: Eliminate strict aliasing violations sna/fb: Initialize xoff/yoff sna: Use -Wno-maybe-uninitialized sna: Get rid of -Wno-shift-negative-value uxa: Get rid of -Wno-shift-negative-value tools: Get rid of -Wno-sign-compare sna: Fix compiler warnings due to DrawablePtr vs. PixmapPtr src/intel_device.c | 2 +- src/intel_module.c | 3 +- src/legacy/i810/xvmc/I810XvMC.c | 48 ++-- src/meson.build | 1 - src/sna/blt.c | 2 ++ src/sna/fb/fb.h | 6 ++-- src/sna/fb/fbpict.c | 6 +++- src/sna/fb/fbspan.c | 6 ++-- src/sna/gen2_render.c | 21 ++--- src/sna/gen3_render.c | 24 ++ src/sna/gen4_render.c | 6 ++-- src/sna/gen5_render.c | 6 ++-- src/sna/gen6_render.c | 6 ++-- src/sna/gen7_render.c | 6 ++-- src/sna/gen8_render.c | 6 ++-- src/sna/gen9_render.c | 6 ++-- src/sna/kgem.c | 10 ++ src/sna/meson.build | 7 +++-- src/sna/sna.h | 19 +++ src/sna/sna_accel.c | 24 +- src/sna/sna_blt.c | 56 +++-- src/sna/sna_composite.c | 2 +- src/sna/sna_damage.h| 1 + src/sna/sna_display.c | 15 - src/sna/sna_display_fake.c | 2 +- src/sna/sna_dri2.c | 6 ++-- src/sna/sna_driver.c| 1 + src/sna/sna_glyphs.c| 7 +++-- src/sna/sna_io.c| 30 ++ src/sna/sna_render.c| 4 +-- src/sna/sna_render.h| 2 +- src/sna/sna_trapezoids_mono.c | 2 +- src/sna/sna_video_overlay.c | 6 +++- src/sna/sna_video_sprite.c | 8 - src/sna/sna_video_textured.c| 5 ++- src/uxa/i965_render.c | 2 +- src/uxa/i965_video.c| 2 +- src/uxa/intel_display.c | 2 +- src/uxa/intel_dri.c | 1 + src/uxa/meson.build | 1 - tools/backlight_helper.c| 2 +- tools/meson.build | 2 -- tools/virtual.c | 18 +-- 43 files changed, 221 insertions(+), 171 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 04/21] sna: Replace fall through comments with standard form
From: Ville Syrjälä gcc doesn't like extra stuff in the fall through comments. Replace them with the standard form. Signed-off-by: Ville Syrjälä --- src/sna/gen4_render.c | 6 +++--- src/sna/gen5_render.c | 6 +++--- src/sna/gen6_render.c | 6 +++--- src/sna/gen7_render.c | 6 +++--- src/sna/gen8_render.c | 6 +++--- src/sna/gen9_render.c | 6 +++--- src/sna/sna_dri2.c| 4 ++-- src/sna/sna_render.h | 2 +- 8 files changed, 21 insertions(+), 21 deletions(-) diff --git a/src/sna/gen4_render.c b/src/sna/gen4_render.c index ae26debf049a..5a4f968d0268 100644 --- a/src/sna/gen4_render.c +++ b/src/sna/gen4_render.c @@ -2019,7 +2019,7 @@ gen4_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->src, 0)) goto cleanup_dst; - /* fall through to fixup */ + /* fall through */ case 1: if (mask == NULL && sna_blt_composite__convert(sna, @@ -2071,7 +2071,7 @@ gen4_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->mask, 0)) goto cleanup_src; - /* fall through to fixup */ + /* fall through */ case 1: gen4_composite_channel_convert(&tmp->mask); break; @@ -2328,7 +2328,7 @@ gen4_render_composite_spans(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->base.src, 0)) goto cleanup_dst; - /* fall through to fixup */ + /* fall through */ case 1: gen4_composite_channel_convert(&tmp->base.src); break; diff --git a/src/sna/gen5_render.c b/src/sna/gen5_render.c index 3d9d35f113aa..3b1f25aacb39 100644 --- a/src/sna/gen5_render.c +++ b/src/sna/gen5_render.c @@ -1972,7 +1972,7 @@ gen5_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->src, 0)) goto cleanup_dst; - /* fall through to fixup */ + /* fall through */ case 1: if (mask == NULL && sna_blt_composite__convert(sna, @@ -2023,7 +2023,7 @@ gen5_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->mask, 0)) goto cleanup_src; - /* fall through to fixup */ + /* fall through */ case 1: gen5_composite_channel_convert(&tmp->mask); break; @@ -2268,7 +2268,7 @@ gen5_render_composite_spans(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->base.src, 0)) goto cleanup_dst; - /* fall through to fixup */ + /* fall through */ case 1: gen5_composite_channel_convert(&tmp->base.src); break; diff --git a/src/sna/gen6_render.c b/src/sna/gen6_render.c index 9eefcbda3e26..1a64d5b915e3 100644 --- a/src/sna/gen6_render.c +++ b/src/sna/gen6_render.c @@ -2346,7 +2346,7 @@ gen6_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->src, 0)) goto cleanup_dst; - /* fall through to fixup */ + /* fall through */ case 1: /* Did we just switch rings to prepare the source? */ if (mask == NULL && @@ -2399,7 +2399,7 @@ gen6_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->mask, 0)) goto cleanup_src; - /* fall through to fixup */ + /* fall through */ case 1: gen6_composite_channel_convert(&tmp->mask); break; @@ -2653,7 +2653,7 @@ gen6_render_composite_spans(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->base.src, 0)) goto cleanup_dst; - /* fall through to fixup */ + /* fall through */ case 1: gen6_composite_channel_convert(&tmp->base.src); break; diff --git a/src/sna/gen7_render.c b/src/sna/gen7_render.c index a33ba902d665..f58f39d457dc 100644 --- a/src/sna/gen7_render.c +++ b/src/sna/gen7_render.c @@ -2576,7 +2576,7 @@ gen7_render_composite(struct sna *sna, case 0: if (!gen4_channel_init_solid(sna, &tmp->src, 0)) goto cleanup_ds
[Intel-gfx] [PATCH xf86-video-intel 09/21] Avoid missing initializer warning
From: Ville Syrjälä
Use an empty {} as the terminator in intel_device_match[] to avoid
the warning about missing initlizers.
Signed-off-by: Ville Syrjälä
---
src/intel_module.c | 2 +-
src/meson.build| 1 -
2 files changed, 1 insertion(+), 2 deletions(-)
diff --git a/src/intel_module.c b/src/intel_module.c
index 171b20d83d33..a71c2e40b774 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -388,7 +388,7 @@ static const struct pci_id_match intel_device_match[] = {
INTEL_VGA_DEVICE(PCI_MATCH_ANY, &intel_generic_info),
#endif
- { 0, 0, 0 },
+ {},
};
void
diff --git a/src/meson.build b/src/meson.build
index 0a46e233a94c..1125c65b73be 100644
--- a/src/meson.build
+++ b/src/meson.build
@@ -150,7 +150,6 @@ shared_module('intel_drv',
'-DMAJOR_IN_SYSMACROS',
'-Wno-unused-parameter',
'-Wno-sign-compare',
- '-Wno-missing-field-initializers',
],
name_prefix : '',
install_dir : join_paths(moduledir, 'drivers'),
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH xf86-video-intel 05/21] sna: Annotate more fall throughs
From: Ville Syrjälä
Sprinkle fall through comments where needed.
Signed-off-by: Ville Syrjälä
---
src/intel_module.c| 1 +
src/sna/blt.c | 2 ++
src/sna/gen2_render.c | 21 +
src/sna/gen3_render.c | 24 ++--
src/sna/sna_accel.c | 3 +++
src/sna/sna_damage.h | 1 +
src/sna/sna_display.c | 7 ---
src/sna/sna_dri2.c| 2 ++
src/sna/sna_driver.c | 1 +
src/sna/sna_render.c | 4 ++--
src/uxa/intel_dri.c | 1 +
11 files changed, 52 insertions(+), 15 deletions(-)
diff --git a/src/intel_module.c b/src/intel_module.c
index a8c9768ee9f8..171b20d83d33 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -692,6 +692,7 @@ static Bool intel_pci_probe(DriverPtr driver,
case PCI_CHIP_I815:
if (!hosted())
break;
+ /* fall through */
default:
return FALSE;
}
diff --git a/src/sna/blt.c b/src/sna/blt.c
index cb90437ad5ad..afc719f6dc8c 100644
--- a/src/sna/blt.c
+++ b/src/sna/blt.c
@@ -1404,6 +1404,7 @@ memcpy_xor(const void *src, void *dst, int bpp,
width /= 2;
or |= or << 8;
}
+ /* fall through */
case 2:
if (width & 1) {
do {
@@ -1421,6 +1422,7 @@ memcpy_xor(const void *src, void *dst, int bpp,
width /= 2;
or |= or << 16;
}
+ /* fall through */
case 4:
w = width;
if (w * 4 == dst_stride && dst_stride == src_stride) {
diff --git a/src/sna/gen2_render.c b/src/sna/gen2_render.c
index e03c44015701..80f684543149 100644
--- a/src/sna/gen2_render.c
+++ b/src/sna/gen2_render.c
@@ -116,10 +116,17 @@ gen2_buf_tiling(uint32_t tiling)
{
uint32_t v = 0;
switch (tiling) {
- default: assert(0);
- case I915_TILING_Y: v |= BUF_3D_TILE_WALK_Y;
- case I915_TILING_X: v |= BUF_3D_TILED_SURFACE;
- case I915_TILING_NONE: break;
+ default:
+ assert(0);
+ /* fall through */
+ case I915_TILING_Y:
+ v |= BUF_3D_TILE_WALK_Y;
+ /* fall through */
+ case I915_TILING_X:
+ v |= BUF_3D_TILED_SURFACE;
+ /* fall through */
+ case I915_TILING_NONE:
+ break;
}
return v;
}
@@ -131,6 +138,7 @@ gen2_get_dst_format(uint32_t format)
switch (format) {
default:
assert(0);
+ /* fall through */
case PICT_a8r8g8b8:
case PICT_x8r8g8b8:
return COLR_BUF_ARGB | BIAS;
@@ -219,10 +227,13 @@ gen2_sampler_tiling_bits(uint32_t tiling)
switch (tiling) {
default:
assert(0);
+ /* fall through */
case I915_TILING_Y:
bits |= TM0S1_TILE_WALK;
+ /* fall through */
case I915_TILING_X:
bits |= TM0S1_TILED_SURFACE;
+ /* fall through */
case I915_TILING_NONE:
break;
}
@@ -277,6 +288,7 @@ gen2_emit_texture(struct sna *sna,
switch (channel->repeat) {
default:
assert(0);
+ /* fall through */
case RepeatNone:
wrap_mode_u = TEXCOORDMODE_CLAMP_BORDER;
break;
@@ -298,6 +310,7 @@ gen2_emit_texture(struct sna *sna,
switch (channel->filter) {
default:
assert(0);
+ /* fall through */
case PictFilterNearest:
filter = (FILTER_NEAREST << TM0S3_MAG_FILTER_SHIFT |
FILTER_NEAREST << TM0S3_MIN_FILTER_SHIFT |
diff --git a/src/sna/gen3_render.c b/src/sna/gen3_render.c
index 166635eba055..e0a7d158015a 100644
--- a/src/sna/gen3_render.c
+++ b/src/sna/gen3_render.c
@@ -131,9 +131,14 @@ static inline uint32_t gen3_buf_tiling(uint32_t tiling)
{
uint32_t v = 0;
switch (tiling) {
- case I915_TILING_Y: v |= BUF_3D_TILE_WALK_Y;
- case I915_TILING_X: v |= BUF_3D_TILED_SURFACE;
- case I915_TILING_NONE: break;
+ case I915_TILING_Y:
+ v |= BUF_3D_TILE_WALK_Y;
+ /* fall through */
+ case I915_TILING_X:
+ v |= BUF_3D_TILED_SURFACE;
+ /* fall through */
+ case I915_TILING_NONE:
+ break;
}
return v;
}
@@ -400,6 +405,7 @@ static uint32_t gen3_filter(uint32_t filter)
switch (filter) {
default:
assert(0);
+ /* fall through */
case PictFilterNearest:
return (FILTER_NEAREST << SS2_MAG_FILTER_SHIFT |
FILTER_NEAREST << S
