Re: [Intel-gfx] [PATCH 2/3] drm/i915: Allowed memory region for GEM obj
Quoting Ramalingam C (2019-09-26 06:21:34) > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c > b/drivers/gpu/drm/i915/gem/i915_gem_object.c > index 0f33da5e541d..e6f8426dedff 100644 > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c > @@ -49,6 +49,7 @@ void i915_gem_object_free(struct drm_i915_gem_object *obj) > } > > void i915_gem_object_init(struct drm_i915_gem_object *obj, > + struct drm_i915_private *dev_priv, to_i915(obj) is valid at this point. Please never add dev_priv. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/huc: fix version parsing from CSS header
On Thu, 26 Sep 2019 01:03:20 +0200, Summers, Stuart
wrote:
On Wed, 2019-09-25 at 15:21 -0700, Daniele Ceraolo Spurio wrote:
The HuC FW has silently switched to encoding the version the same way
as
the GuC FW does, i.e. major.minor.patch instead of just major.minor.
All
the current blobs follow the new scheme, but since minor and patch
are
both zero there is no difference in the end results and we happily
load
them. New binaries, however, will have non-zero values in there, so
we
need to make sure to parse them correctly.
Signed-off-by: Daniele Ceraolo Spurio <
daniele.ceraolospu...@intel.com>
I don't have insight into the HuC change, so just taking your word
here. The code below looks sane and is an obvious improvement.
It might be interesting to get a look from someone a little closer to
this for a HuC perspective. With that disclaimer:
Reviewed-by: Stuart Summers
Double checked offline with HuC team, so
Acked-by: Michal Wajdeczko
Cc: Anusha Srivatsa
Cc: Michal Wajdeczko
---
drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c | 23
drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h | 8 +++
2 files changed, 7 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
index ea9a807abd4f..bb878119f06c 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw.c
@@ -339,25 +339,10 @@ int intel_uc_fw_fetch(struct intel_uc_fw
*uc_fw, struct drm_i915_private *i915)
}
/* Get version numbers from the CSS header */
- switch (uc_fw->type) {
- case INTEL_UC_FW_TYPE_GUC:
- uc_fw->major_ver_found =
FIELD_GET(CSS_SW_VERSION_GUC_MAJOR,
- css->sw_version);
- uc_fw->minor_ver_found =
FIELD_GET(CSS_SW_VERSION_GUC_MINOR,
- css->sw_version);
- break;
-
- case INTEL_UC_FW_TYPE_HUC:
- uc_fw->major_ver_found =
FIELD_GET(CSS_SW_VERSION_HUC_MAJOR,
- css->sw_version);
- uc_fw->minor_ver_found =
FIELD_GET(CSS_SW_VERSION_HUC_MINOR,
- css->sw_version);
- break;
-
- default:
- MISSING_CASE(uc_fw->type);
- break;
- }
+ uc_fw->major_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MAJOR,
+ css->sw_version);
+ uc_fw->minor_ver_found = FIELD_GET(CSS_SW_VERSION_UC_MINOR,
+ css->sw_version);
if (uc_fw->major_ver_found != uc_fw->major_ver_wanted ||
uc_fw->minor_ver_found < uc_fw->minor_ver_wanted) {
diff --git a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
index ae58e8a8c53b..f8f6c91a0df6 100644
--- a/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
+++ b/drivers/gpu/drm/i915/gt/uc/intel_uc_fw_abi.h
@@ -69,11 +69,9 @@ struct uc_css_header {
char username[8];
char buildnumber[12];
u32 sw_version;
-#define CSS_SW_VERSION_GUC_MAJOR (0xFF << 16)
-#define CSS_SW_VERSION_GUC_MINOR (0xFF << 8)
-#define CSS_SW_VERSION_GUC_PATCH (0xFF << 0)
-#define CSS_SW_VERSION_HUC_MAJOR (0x << 16)
-#define CSS_SW_VERSION_HUC_MINOR (0x << 0)
+#define CSS_SW_VERSION_UC_MAJOR(0xFF << 16)
+#define CSS_SW_VERSION_UC_MINOR(0xFF << 8)
+#define CSS_SW_VERSION_UC_PATCH(0xFF << 0)
u32 reserved[14];
u32 header_info;
} __packed;
___
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/3] drm/dp/mst: Reduce nested ifs
== Series Details == Series: series starting with [1/3] drm/dp/mst: Reduce nested ifs URL : https://patchwork.freedesktop.org/series/67222/ State : success == Summary == CI Bug Log - changes from CI_DRM_6956_full -> Patchwork_14531_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14531_full that come from known issues: ### IGT changes ### Issues hit * igt@drm_import_export@import-close-race-prime: - shard-iclb: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@drm_import_exp...@import-close-race-prime.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-iclb7/igt@drm_import_exp...@import-close-race-prime.html * igt@gem_exec_parallel@bcs0-fds: - shard-apl: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl5/igt@gem_exec_paral...@bcs0-fds.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-apl6/igt@gem_exec_paral...@bcs0-fds.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#109276]) +11 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@gem_exec_sched...@independent-bsd2.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-iclb3/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@reorder-wide-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +7 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@gem_exec_sched...@reorder-wide-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-iclb2/igt@gem_exec_sched...@reorder-wide-bsd.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-kbl6/igt@gem_soft...@noreloc-s3.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-kbl3/igt@gem_soft...@noreloc-s3.html * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +6 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl8/igt@gem_workarou...@suspend-resume-context.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-apl7/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103232]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-skl2/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html * igt@kms_flip@plain-flip-fb-recreate: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#100368]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl4/igt@kms_f...@plain-flip-fb-recreate.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-skl7/igt@kms_f...@plain-flip-fb-recreate.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-hsw: [PASS][17] -> [INCOMPLETE][18] ([fdo#103540]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw4/igt@kms_f...@plain-flip-ts-check-interruptible.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-hsw8/igt@kms_f...@plain-flip-ts-check-interruptible.html * igt@kms_flip_tiling@flip-x-tiled: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145] / [fdo#108303]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl1/igt@kms_flip_til...@flip-x-tiled.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-skl2/igt@kms_flip_til...@flip-x-tiled.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +7 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_frontbuffer_tracking@fbcpsr-slowdraw: - shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([fdo#106978] / [fdo#107713]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb5/igt@kms_frontbuffer_track...@fbcpsr-slowdraw.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14531/shard-iclb7/igt@kms_frontbuffer_track...@fbcpsr-slowdraw.html
Re: [Intel-gfx] [PATCH v2 0/9] drm/print: add and use drm_debug_enabled()
On Tuesday, 2019-09-24 15:58:56 +0300, Jani Nikula wrote: > Hi all, v2 of [1], a little refactoring around drm_debug access to > abstract it better. There shouldn't be any functional changes. > > I'd appreciate acks for merging the lot via drm-misc. If there are any > objections to that, we'll need to postpone the last patch until > everything has been merged and converted in drm-next. > > BR, > Jani. > > Cc: Eric Engestrom > Cc: Alex Deucher > Cc: Christian König > Cc: David (ChunMing) Zhou > Cc: amd-...@lists.freedesktop.org > Cc: Ben Skeggs > Cc: nouv...@lists.freedesktop.org > Cc: Rob Clark > Cc: Sean Paul > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: Francisco Jerez > Cc: Lucas Stach > Cc: Russell King > Cc: Christian Gmeiner > Cc: etna...@lists.freedesktop.org > > > [1] cover.1568375189.git.jani.nikula@intel.com">http://mid.mail-archive.com/cover.1568375189.git.jani.nikula@intel.com > > Jani Nikula (9): > drm/print: move drm_debug variable to drm_print.[ch] > drm/print: add drm_debug_enabled() > drm/i915: use drm_debug_enabled() to check for debug categories > drm/print: rename drm_debug to __drm_debug to discourage use The above four patches are: Reviewed-by: Eric Engestrom Did you check to make sure the `unlikely()` is propagated correctly outside the `drm_debug_enabled()` call? ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On 2019/9/26 上午8:48, Tian, Kevin wrote: +}; I'm not sure how stable above ops are. It's the kernel internal API, so there's no strict requirement for this. We will export a version value for userspace for compatibility. Does it make sense if defining just two callbacks here, e.g. vq_ctrl and device_ctrl, and then let the vendor driver to handle specific ops in each category (similar to how ioctl works)? My understanding is that it introduce another indirection, you still need to differ from different command, and it's less flexible than direct callback. What's the value of doing this? I just thought doing so may provide better compatibility to the parent driver. Even when new op is introduced, a parent driver that was developed against the old set can still be loaded in the new kernel. It just returns error when unrecognized ops are routed through vq_ctrl and device_ctrl, if the userspace doesn't favor the exposed version value. But if above ops set is pretty stable, then this comment can be ignored. This is really good point, we should keep it stable as a real transport. And when there's major changes, we should advertise through version then we can provide a new set of functions. Thanks Thanks Kevin ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On Thu, Sep 26, 2019 at 12:04:46PM +0800, Jason Wang wrote: > > > > I'm not sure how stable above ops are. > > > It's the kernel internal API, so there's no strict requirement for this. > > > We > > > will export a version value for userspace for compatibility. > > Given it's tied to virtio we probably want kernel+userspace > > feature bits? > > > Yes, then I think we could probably have a version field inside e.g > device_ops structure. Then it could be fetched from both kernel and > userspace driver. > > Thanks > my point was feature bits not a version number. > > ___ 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/edid: Add new modes from CTA-861-G (rev2)
== Series Details == Series: drm/edid: Add new modes from CTA-861-G (rev2) URL : https://patchwork.freedesktop.org/series/63554/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6956_full -> Patchwork_14532_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14532_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14532_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_14532_full: ### IGT changes ### Possible regressions * igt@i915_pm_rpm@debugfs-read: - shard-hsw: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw5/igt@i915_pm_...@debugfs-read.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-hsw4/igt@i915_pm_...@debugfs-read.html Known issues Here are the changes found in Patchwork_14532_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-snb: [PASS][3] -> [FAIL][4] ([fdo#109661]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-snb6/igt@gem_...@reset-stress.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-snb7/igt@gem_...@reset-stress.html * igt@gem_exec_nop@basic-series: - shard-iclb: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#109100]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb3/igt@gem_exec_...@basic-series.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-iclb7/igt@gem_exec_...@basic-series.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#109276]) +15 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@gem_exec_sched...@independent-bsd2.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][9] -> [SKIP][10] ([fdo#111325]) +8 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_persistent_relocs@forked-interruptible-thrashing: - shard-apl: [PASS][11] -> [INCOMPLETE][12] ([fdo#103927]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl2/igt@gem_persistent_rel...@forked-interruptible-thrashing.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-apl7/igt@gem_persistent_rel...@forked-interruptible-thrashing.html * igt@gem_tiled_swapping@non-threaded: - shard-apl: [PASS][13] -> [DMESG-WARN][14] ([fdo#108686]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl8/igt@gem_tiled_swapp...@non-threaded.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-apl1/igt@gem_tiled_swapp...@non-threaded.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl3/igt@i915_susp...@sysfs-reader.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-apl8/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-kbl3/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@flip-vs-expired-vblank: - shard-glk: [PASS][19] -> [FAIL][20] ([fdo#105363]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-glk6/igt@kms_f...@flip-vs-expired-vblank.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-glk5/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14532/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_plane@plane-panning-bottom-righ
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Remove begin/finish_crtc_commit, v2.
Op 25-09-2019 om 23:42 schreef Matt Roper:
> On Wed, Sep 25, 2019 at 04:59:01PM +0200, Maarten Lankhorst wrote:
>> This can all be done from the intel_update_crtc function. Split out the
>> pipe update into a separate function, just like is done for the planes.
>> Pull in all the changes done during fastset as well. It makes no sense
>> for it to still exist as a separate function.
>>
>> Changes since v1:
>> - Inline intel_update_pipe_config()
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 197 ---
>> 1 file changed, 86 insertions(+), 111 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index b77574cda648..5a9d06af9f29 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
>> const struct intel_crtc_state *pipe_config);
>> static void chv_prepare_pll(struct intel_crtc *crtc,
>> const struct intel_crtc_state *pipe_config);
>> -static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
>> intel_crtc *);
>> -static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
>> intel_crtc *);
>> static void intel_crtc_init_scalers(struct intel_crtc *crtc,
>> struct intel_crtc_state *crtc_state);
>> static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
>> @@ -4409,45 +4407,6 @@ static void icl_set_pipe_chicken(struct intel_crtc
>> *crtc)
>> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
>> }
>>
>> -static void intel_update_pipe_config(const struct intel_crtc_state
>> *old_crtc_state,
>> - const struct intel_crtc_state
>> *new_crtc_state)
>> -{
>> -struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>> -struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> -
>> -/* drm_atomic_helper_update_legacy_modeset_state might not be called. */
>> -crtc->base.mode = new_crtc_state->uapi.mode;
>> -
>> -/*
>> - * Update pipe size and adjust fitter if needed: the reason for this is
>> - * that in compute_mode_changes we check the native mode (not the pfit
>> - * mode) to see if we can flip rather than do a full mode set. In the
>> - * fastboot case, we'll flip, but if we don't update the pipesrc and
>> - * pfit state, we'll end up with a big fb scanned out into the wrong
>> - * sized surface.
>> - */
>> -
>> -I915_WRITE(PIPESRC(crtc->pipe),
>> - ((new_crtc_state->pipe_src_w - 1) << 16) |
>> - (new_crtc_state->pipe_src_h - 1));
>> -
>> -/* on skylake this is done by detaching scalers */
>> -if (INTEL_GEN(dev_priv) >= 9) {
>> -skl_detach_scalers(new_crtc_state);
>> -
>> -if (new_crtc_state->pch_pfit.enabled)
>> -skylake_pfit_enable(new_crtc_state);
>> -} else if (HAS_PCH_SPLIT(dev_priv)) {
>> -if (new_crtc_state->pch_pfit.enabled)
>> -ironlake_pfit_enable(new_crtc_state);
>> -else if (old_crtc_state->pch_pfit.enabled)
>> -ironlake_pfit_disable(old_crtc_state);
>> -}
>> -
>> -if (INTEL_GEN(dev_priv) >= 11)
>> -icl_set_pipe_chicken(crtc);
>> -}
>> -
>> static void intel_fdi_normal_train(struct intel_crtc *crtc)
>> {
>> struct drm_device *dev = crtc->base.dev;
>> @@ -13739,13 +13698,88 @@ u32 intel_crtc_get_vblank_counter(struct
>> intel_crtc *crtc)
>> return crtc->base.funcs->get_vblank_counter(&crtc->base);
>> }
>>
>> +void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
>> + struct intel_crtc_state *crtc_state)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +
>> +if (!IS_GEN(dev_priv, 2))
>> +intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
>> true);
>> +
>> +if (crtc_state->has_pch_encoder) {
>> +enum pipe pch_transcoder =
>> +intel_crtc_pch_transcoder(crtc);
>> +
>> +intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
>> true);
>> +}
>> +}
>> +
>> +static void commit_pipe_config(struct intel_atomic_state *state,
>> + struct intel_crtc_state *old_crtc_state,
>> + struct intel_crtc_state *new_crtc_state)
>> +{
>> +struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>> +bool modeset = needs_modeset(new_crtc_state);
>> +
>> +if (!modeset) {
>> +if (new_crtc_state->uapi.color_mgmt_changed ||
>> +new_crtc_state->update_pipe)
>> +intel_color_commit(new_crtc_state);
>> +
>> +i
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
On 26/09/2019 06:21, Ramalingam C wrote:
If Local memory is supported by hardware, we want framebuffer backing
gem objects out of local memory.
If local memory is supported and gem object if not from local memory we
migrate the obj into local memory. And once framebuffer is created we
block the migration of the associated object out of local memory.
This is developed on top of v3 LMEM series
https://patchwork.freedesktop.org/series/56683/
cc: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.c | 25 +
drivers/gpu/drm/i915/gem/i915_gem_object.c | 58
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
3 files changed, 62 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1cc74844d3ea..d1921a317066 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -56,6 +56,8 @@
#include "display/intel_tv.h"
#include "display/intel_vdsc.h"
+#include "gem/i915_gem_object.h"
+
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_acpi.h"
@@ -15496,6 +15498,10 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+ /* removing the FB memory region restriction on obj, if any */
+ intel_fb->front_buffer->obj = INTEL_INFO(dev_priv)->memory_regions;
Is this right, assigning bitmask to something called obj?
drm_framebuffer_cleanup(fb);
intel_frontbuffer_put(intel_fb->frontbuffer);
@@ -15543,11 +15549,26 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = &intel_fb->base;
+ u32 *region_map;
u32 max_stride;
unsigned int tiling, stride;
int ret = -EINVAL;
int i;
+ /* GEM Obj for frame buffer is expected to be in LMEM. */
+ if (HAS_LMEM(dev_priv))
+ if (obj->mm.region->type != INTEL_LMEM) {
+ region_map = &intel_region_map[INTEL_MEMORY_LMEM];
+ ret = i915_gem_object_mem_region_migrate(dev_priv, obj,
+region_map,
+1);
+ if (ret) {
+ DRM_ERROR("FB migration to LMEM Failed(%d)\n",
+ ret);
Probably should be just debug level since it is imaginably user
triggerable and not really an error for the kernel as such.
+ return ret;
+ }
+ }
+
intel_fb->frontbuffer = intel_frontbuffer_get(obj);
if (!intel_fb->frontbuffer)
return -ENOMEM;
@@ -15666,6 +15687,10 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
+ /* Blocking the migration of gem obj out of LMEM */
+ if (HAS_LMEM(dev_priv))
+ obj->memory_regions = REGION_LMEM;
+
return 0;
err:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index e6f8426dedff..65b47054130b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -501,30 +501,11 @@ __region_id(u32 region)
return INTEL_MEMORY_UKNOWN;
}
-static int i915_gem_object_region_select(struct drm_i915_private *dev_priv,
-struct drm_i915_gem_object_param *args,
-struct drm_file *file,
-struct drm_i915_gem_object *obj)
+int i915_gem_object_mem_region_migrate(struct drm_i915_private *dev_priv,
+ struct drm_i915_gem_object *obj,
+ u32 *uregions, u32 region_count)
{
struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
- u32 __user *uregions = u64_to_user_ptr(args->data);
- u32 uregions_copy[INTEL_MEMORY_UKNOWN];
- int i, ret;
-
- if (args->size > INTEL_MEMORY_UKNOWN)
- return -EINVAL;
-
- memset(uregions_copy, 0, sizeof(uregions_copy));
- for (i = 0; i < args->size; i++) {
- u32 region;
-
- ret = get_user(region, uregions);
- if (ret)
- return ret;
-
- uregions_copy[i] = region;
- ++uregions;
- }
mutex_lock(&dev_priv->drm.struct_mutex);
ret = i915_gem_object_prepare_move(obj);
@@ -533,8 +514,8 @@ static int
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Create dumb buffer from LMEM
On 26/09/2019 06:21, Ramalingam C wrote:
When LMEM is supported, dumb buffer preferred to be created from LMEM.
This is developed on top of v3 LMEM series
https://patchwork.freedesktop.org/series/56683/.
v2:
Parameters are reshuffled. [Chris]
Signed-off-by: Ramalingam C
cc: Matthew Auld
---
drivers/gpu/drm/i915/i915_gem.c | 18 +++---
1 file changed, 15 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e458507b1558..6810a549ee98 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -44,6 +44,7 @@
#include "gem/i915_gem_clflush.h"
#include "gem/i915_gem_context.h"
#include "gem/i915_gem_ioctls.h"
+#include "gem/i915_gem_lmem.h"
#include "gem/i915_gem_pm.h"
#include "gt/intel_engine_user.h"
#include "gt/intel_gt.h"
@@ -160,6 +161,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
static int
i915_gem_create(struct drm_file *file,
struct drm_i915_private *dev_priv,
+ enum intel_region_id mem_region,
u64 *size_p,
u32 *handle_p)
{
@@ -173,7 +175,12 @@ i915_gem_create(struct drm_file *file,
return -EINVAL;
/* Allocate the new object */
- obj = i915_gem_object_create_shmem(dev_priv, size);
+ if (mem_region == INTEL_MEMORY_LMEM)
+ obj = i915_gem_object_create_lmem(dev_priv, size, 0);
+ else if (mem_region == INTEL_MEMORY_STOLEN)
+ obj = i915_gem_object_create_stolen(dev_priv, size);
+ else
+ obj = i915_gem_object_create_shmem(dev_priv, size);
if (IS_ERR(obj))
return PTR_ERR(obj);
@@ -193,6 +200,7 @@ i915_gem_dumb_create(struct drm_file *file,
struct drm_device *dev,
struct drm_mode_create_dumb *args)
{
+ enum intel_region_id mem_region = INTEL_MEMORY_UKNOWN;
int cpp = DIV_ROUND_UP(args->bpp, 8);
u32 format;
@@ -219,7 +227,11 @@ i915_gem_dumb_create(struct drm_file *file,
args->pitch = ALIGN(args->pitch, 4096);
args->size = args->pitch * args->height;
- return i915_gem_create(file, to_i915(dev),
+
+ if (HAS_LMEM(to_i915(dev)))
+ mem_region = INTEL_MEMORY_LMEM;
+
+ return i915_gem_create(file, to_i915(dev), mem_region,
&args->size, &args->handle);
}
@@ -238,7 +250,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void *data,
i915_gem_flush_free_objects(dev_priv);
- return i915_gem_create(file, dev_priv,
+ return i915_gem_create(file, dev_priv, INTEL_MEMORY_UKNOWN,
&args->size, &args->handle);
We don't have shmem memory region? Or default? Or is unknown supposed to
mean default for a given platform?
Regards,
Tvrtko
}
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Create dumb buffer from LMEM
On 2019-09-26 at 09:55:16 +0100, Tvrtko Ursulin wrote:
>
> On 26/09/2019 06:21, Ramalingam C wrote:
> > When LMEM is supported, dumb buffer preferred to be created from LMEM.
> >
> > This is developed on top of v3 LMEM series
> > https://patchwork.freedesktop.org/series/56683/.
> >
> > v2:
> >Parameters are reshuffled. [Chris]
> >
> > Signed-off-by: Ramalingam C
> > cc: Matthew Auld
> > ---
> > drivers/gpu/drm/i915/i915_gem.c | 18 +++---
> > 1 file changed, 15 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index e458507b1558..6810a549ee98 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -44,6 +44,7 @@
> > #include "gem/i915_gem_clflush.h"
> > #include "gem/i915_gem_context.h"
> > #include "gem/i915_gem_ioctls.h"
> > +#include "gem/i915_gem_lmem.h"
> > #include "gem/i915_gem_pm.h"
> > #include "gt/intel_engine_user.h"
> > #include "gt/intel_gt.h"
> > @@ -160,6 +161,7 @@ i915_gem_phys_pwrite(struct drm_i915_gem_object *obj,
> > static int
> > i915_gem_create(struct drm_file *file,
> > struct drm_i915_private *dev_priv,
> > + enum intel_region_id mem_region,
> > u64 *size_p,
> > u32 *handle_p)
> > {
> > @@ -173,7 +175,12 @@ i915_gem_create(struct drm_file *file,
> > return -EINVAL;
> > /* Allocate the new object */
> > - obj = i915_gem_object_create_shmem(dev_priv, size);
> > + if (mem_region == INTEL_MEMORY_LMEM)
> > + obj = i915_gem_object_create_lmem(dev_priv, size, 0);
> > + else if (mem_region == INTEL_MEMORY_STOLEN)
> > + obj = i915_gem_object_create_stolen(dev_priv, size);
> > + else
> > + obj = i915_gem_object_create_shmem(dev_priv, size);
> > if (IS_ERR(obj))
> > return PTR_ERR(obj);
> > @@ -193,6 +200,7 @@ i915_gem_dumb_create(struct drm_file *file,
> > struct drm_device *dev,
> > struct drm_mode_create_dumb *args)
> > {
> > + enum intel_region_id mem_region = INTEL_MEMORY_UKNOWN;
> > int cpp = DIV_ROUND_UP(args->bpp, 8);
> > u32 format;
> > @@ -219,7 +227,11 @@ i915_gem_dumb_create(struct drm_file *file,
> > args->pitch = ALIGN(args->pitch, 4096);
> > args->size = args->pitch * args->height;
> > - return i915_gem_create(file, to_i915(dev),
> > +
> > + if (HAS_LMEM(to_i915(dev)))
> > + mem_region = INTEL_MEMORY_LMEM;
> > +
> > + return i915_gem_create(file, to_i915(dev), mem_region,
> >&args->size, &args->handle);
> > }
> > @@ -238,7 +250,7 @@ i915_gem_create_ioctl(struct drm_device *dev, void
> > *data,
> > i915_gem_flush_free_objects(dev_priv);
> > - return i915_gem_create(file, dev_priv,
> > + return i915_gem_create(file, dev_priv, INTEL_MEMORY_UKNOWN,
> >&args->size, &args->handle);
>
> We don't have shmem memory region? Or default? Or is unknown supposed to
> mean default for a given platform?
I take this as default. Not sure if we need to pass anything (default
region) specifically.
-Ram
>
> Regards,
>
> Tvrtko
>
> > }
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
On 2019-09-26 at 09:53:03 +0100, Tvrtko Ursulin wrote:
>
> On 26/09/2019 06:21, Ramalingam C wrote:
> > If Local memory is supported by hardware, we want framebuffer backing
> > gem objects out of local memory.
> >
> > If local memory is supported and gem object if not from local memory we
> > migrate the obj into local memory. And once framebuffer is created we
> > block the migration of the associated object out of local memory.
> >
> > This is developed on top of v3 LMEM series
> > https://patchwork.freedesktop.org/series/56683/
> >
> > cc: Matthew Auld
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 25 +
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 58
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
> > 3 files changed, 62 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 1cc74844d3ea..d1921a317066 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -56,6 +56,8 @@
> > #include "display/intel_tv.h"
> > #include "display/intel_vdsc.h"
> > +#include "gem/i915_gem_object.h"
> > +
> > #include "i915_drv.h"
> > #include "i915_trace.h"
> > #include "intel_acpi.h"
> > @@ -15496,6 +15498,10 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> > static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > {
> > struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> > + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> > +
> > + /* removing the FB memory region restriction on obj, if any */
> > + intel_fb->front_buffer->obj = INTEL_INFO(dev_priv)->memory_regions;
>
> Is this right, assigning bitmask to something called obj?
Oops. wanted to assign into the obj->memory_regions. Thanks for
catching it.
>
> > drm_framebuffer_cleanup(fb);
> > intel_frontbuffer_put(intel_fb->frontbuffer);
> > @@ -15543,11 +15549,26 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > {
> > struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> > struct drm_framebuffer *fb = &intel_fb->base;
> > + u32 *region_map;
> > u32 max_stride;
> > unsigned int tiling, stride;
> > int ret = -EINVAL;
> > int i;
> > + /* GEM Obj for frame buffer is expected to be in LMEM. */
> > + if (HAS_LMEM(dev_priv))
> > + if (obj->mm.region->type != INTEL_LMEM) {
> > + region_map = &intel_region_map[INTEL_MEMORY_LMEM];
> > + ret = i915_gem_object_mem_region_migrate(dev_priv, obj,
> > +region_map,
> > +1);
> > + if (ret) {
> > + DRM_ERROR("FB migration to LMEM Failed(%d)\n",
> > + ret);
>
> Probably should be just debug level since it is imaginably user triggerable
> and not really an error for the kernel as such.
Sure.
>
> > + return ret;
> > + }
> > + }
> > +
> > intel_fb->frontbuffer = intel_frontbuffer_get(obj);
> > if (!intel_fb->frontbuffer)
> > return -ENOMEM;
> > @@ -15666,6 +15687,10 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > goto err;
> > }
> > + /* Blocking the migration of gem obj out of LMEM */
> > + if (HAS_LMEM(dev_priv))
> > + obj->memory_regions = REGION_LMEM;
> > +
> > return 0;
> > err:
> > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > index e6f8426dedff..65b47054130b 100644
> > --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> > @@ -501,30 +501,11 @@ __region_id(u32 region)
> > return INTEL_MEMORY_UKNOWN;
> > }
> > -static int i915_gem_object_region_select(struct drm_i915_private *dev_priv,
> > -struct drm_i915_gem_object_param *args,
> > -struct drm_file *file,
> > -struct drm_i915_gem_object *obj)
> > +int i915_gem_object_mem_region_migrate(struct drm_i915_private *dev_priv,
> > + struct drm_i915_gem_object *obj,
> > + u32 *uregions, u32 region_count)
> > {
> > struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
> > - u32 __user *uregions = u64_to_user_ptr(args->data);
> > - u32 uregions_copy[INTEL_MEMORY_UKNOWN];
> > - int i, ret;
> > -
> > - if (args->size > INTEL_MEMORY_UKNOWN)
> > - return -EINVAL;
> > -
> > - memset(uregions_copy, 0, sizeof(uregions_copy));
> > - for (i = 0; i < ar
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
Quoting Tvrtko Ursulin (2019-09-26 09:53:03)
>
> On 26/09/2019 06:21, Ramalingam C wrote:
> > If Local memory is supported by hardware, we want framebuffer backing
> > gem objects out of local memory.
> >
> > If local memory is supported and gem object if not from local memory we
> > migrate the obj into local memory. And once framebuffer is created we
> > block the migration of the associated object out of local memory.
> >
> > This is developed on top of v3 LMEM series
> > https://patchwork.freedesktop.org/series/56683/
> >
> > cc: Matthew Auld
> > Signed-off-by: Ramalingam C
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 25 +
> > drivers/gpu/drm/i915/gem/i915_gem_object.c | 58
> > drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
> > 3 files changed, 62 insertions(+), 24 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index 1cc74844d3ea..d1921a317066 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -56,6 +56,8 @@
> > #include "display/intel_tv.h"
> > #include "display/intel_vdsc.h"
> >
> > +#include "gem/i915_gem_object.h"
> > +
> > #include "i915_drv.h"
> > #include "i915_trace.h"
> > #include "intel_acpi.h"
> > @@ -15496,6 +15498,10 @@ static void intel_setup_outputs(struct
> > drm_i915_private *dev_priv)
> > static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
> > {
> > struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
> > + struct drm_i915_private *dev_priv = to_i915(fb->dev);
> > +
> > + /* removing the FB memory region restriction on obj, if any */
> > + intel_fb->front_buffer->obj = INTEL_INFO(dev_priv)->memory_regions;
>
> Is this right, assigning bitmask to something called obj?
>
> >
> > drm_framebuffer_cleanup(fb);
> > intel_frontbuffer_put(intel_fb->frontbuffer);
> > @@ -15543,11 +15549,26 @@ static int intel_framebuffer_init(struct
> > intel_framebuffer *intel_fb,
> > {
> > struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
> > struct drm_framebuffer *fb = &intel_fb->base;
> > + u32 *region_map;
> > u32 max_stride;
> > unsigned int tiling, stride;
> > int ret = -EINVAL;
> > int i;
> >
> > + /* GEM Obj for frame buffer is expected to be in LMEM. */
> > + if (HAS_LMEM(dev_priv))
> > + if (obj->mm.region->type != INTEL_LMEM) {
> > + region_map = &intel_region_map[INTEL_MEMORY_LMEM];
> > + ret = i915_gem_object_mem_region_migrate(dev_priv,
> > obj,
> > + region_map,
> > + 1);
> > + if (ret) {
> > + DRM_ERROR("FB migration to LMEM Failed(%d)\n",
> > + ret);
>
> Probably should be just debug level since it is imaginably user
> triggerable and not really an error for the kernel as such.
This would be a part of pin_to_display? That's where we do the other
conversions required for scanout objects.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Remove begin/finish_crtc_commit, v2.
Op 25-09-2019 om 23:42 schreef Matt Roper:
> On Wed, Sep 25, 2019 at 04:59:01PM +0200, Maarten Lankhorst wrote:
>> This can all be done from the intel_update_crtc function. Split out the
>> pipe update into a separate function, just like is done for the planes.
>> Pull in all the changes done during fastset as well. It makes no sense
>> for it to still exist as a separate function.
>>
>> Changes since v1:
>> - Inline intel_update_pipe_config()
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> drivers/gpu/drm/i915/display/intel_display.c | 197 ---
>> 1 file changed, 86 insertions(+), 111 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
>> b/drivers/gpu/drm/i915/display/intel_display.c
>> index b77574cda648..5a9d06af9f29 100644
>> --- a/drivers/gpu/drm/i915/display/intel_display.c
>> +++ b/drivers/gpu/drm/i915/display/intel_display.c
>> @@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
>> const struct intel_crtc_state *pipe_config);
>> static void chv_prepare_pll(struct intel_crtc *crtc,
>> const struct intel_crtc_state *pipe_config);
>> -static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
>> intel_crtc *);
>> -static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
>> intel_crtc *);
>> static void intel_crtc_init_scalers(struct intel_crtc *crtc,
>> struct intel_crtc_state *crtc_state);
>> static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
>> @@ -4409,45 +4407,6 @@ static void icl_set_pipe_chicken(struct intel_crtc
>> *crtc)
>> I915_WRITE(PIPE_CHICKEN(pipe), tmp);
>> }
>>
>> -static void intel_update_pipe_config(const struct intel_crtc_state
>> *old_crtc_state,
>> - const struct intel_crtc_state
>> *new_crtc_state)
>> -{
>> -struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>> -struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> -
>> -/* drm_atomic_helper_update_legacy_modeset_state might not be called. */
>> -crtc->base.mode = new_crtc_state->uapi.mode;
>> -
>> -/*
>> - * Update pipe size and adjust fitter if needed: the reason for this is
>> - * that in compute_mode_changes we check the native mode (not the pfit
>> - * mode) to see if we can flip rather than do a full mode set. In the
>> - * fastboot case, we'll flip, but if we don't update the pipesrc and
>> - * pfit state, we'll end up with a big fb scanned out into the wrong
>> - * sized surface.
>> - */
>> -
>> -I915_WRITE(PIPESRC(crtc->pipe),
>> - ((new_crtc_state->pipe_src_w - 1) << 16) |
>> - (new_crtc_state->pipe_src_h - 1));
>> -
>> -/* on skylake this is done by detaching scalers */
>> -if (INTEL_GEN(dev_priv) >= 9) {
>> -skl_detach_scalers(new_crtc_state);
>> -
>> -if (new_crtc_state->pch_pfit.enabled)
>> -skylake_pfit_enable(new_crtc_state);
>> -} else if (HAS_PCH_SPLIT(dev_priv)) {
>> -if (new_crtc_state->pch_pfit.enabled)
>> -ironlake_pfit_enable(new_crtc_state);
>> -else if (old_crtc_state->pch_pfit.enabled)
>> -ironlake_pfit_disable(old_crtc_state);
>> -}
>> -
>> -if (INTEL_GEN(dev_priv) >= 11)
>> -icl_set_pipe_chicken(crtc);
>> -}
>> -
>> static void intel_fdi_normal_train(struct intel_crtc *crtc)
>> {
>> struct drm_device *dev = crtc->base.dev;
>> @@ -13739,13 +13698,88 @@ u32 intel_crtc_get_vblank_counter(struct
>> intel_crtc *crtc)
>> return crtc->base.funcs->get_vblank_counter(&crtc->base);
>> }
>>
>> +void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
>> + struct intel_crtc_state *crtc_state)
>> +{
>> +struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
>> +
>> +if (!IS_GEN(dev_priv, 2))
>> +intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
>> true);
>> +
>> +if (crtc_state->has_pch_encoder) {
>> +enum pipe pch_transcoder =
>> +intel_crtc_pch_transcoder(crtc);
>> +
>> +intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
>> true);
>> +}
>> +}
>> +
>> +static void commit_pipe_config(struct intel_atomic_state *state,
>> + struct intel_crtc_state *old_crtc_state,
>> + struct intel_crtc_state *new_crtc_state)
>> +{
>> +struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
>> +struct drm_i915_private *dev_priv = to_i915(state->base.dev);
>> +bool modeset = needs_modeset(new_crtc_state);
>> +
>> +if (!modeset) {
>> +if (new_crtc_state->uapi.color_mgmt_changed ||
>> +new_crtc_state->update_pipe)
>> +intel_color_commit(new_crtc_state);
>> +
>> +i
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/4] drm/i915: Prepare to split crtc state in uapi and hw state
== Series Details == Series: series starting with [1/4] drm/i915: Prepare to split crtc state in uapi and hw state URL : https://patchwork.freedesktop.org/series/67227/ State : success == Summary == CI Bug Log - changes from CI_DRM_6956_full -> Patchwork_14533_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14533_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl5/igt@gem_ctx_isolat...@bcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-apl5/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +14 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@gem_exec_sched...@independent-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-iclb5/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +7 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-iclb2/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@kms_draw_crc@draw-method-rgb565-render-xtiled: - shard-skl: [PASS][7] -> [FAIL][8] ([fdo#103184] / [fdo#103232]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl2/igt@kms_draw_...@draw-method-rgb565-render-xtiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-skl7/igt@kms_draw_...@draw-method-rgb565-render-xtiled.html * igt@kms_flip@2x-modeset-vs-vblank-race-interruptible: - shard-hsw: [PASS][9] -> [DMESG-FAIL][10] ([fdo#102614]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw6/igt@kms_f...@2x-modeset-vs-vblank-race-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-hsw5/igt@kms_f...@2x-modeset-vs-vblank-race-interruptible.html * igt@kms_flip@basic-flip-vs-wf_vblank: - shard-hsw: [PASS][11] -> [INCOMPLETE][12] ([fdo#103540]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw5/igt@kms_flip@basic-flip-vs-wf_vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-hsw6/igt@kms_flip@basic-flip-vs-wf_vblank.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#105363]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl9/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-skl10/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@wf_vblank-ts-check-interruptible: - shard-apl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927]) +4 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl4/igt@kms_flip@wf_vblank-ts-check-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-apl4/igt@kms_flip@wf_vblank-ts-check-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-pri-shrfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb4/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-pri-shrfb-draw-render.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][19] -> [DMESG-WARN][20] ([fdo#108566]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#108145] / [fdo#110403]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14533/shard-skl9/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html * igt@kms_psr2_su@frontbuffer: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109642] / [fdo#111068]) +1 similar issue [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM
[Intel-gfx] [PATCH] drm/i915: Remove begin/finish_crtc_commit, v3.
This can all be done from the intel_update_crtc function. Split out the
pipe update into a separate function, just like is done for the planes.
Pull in all the changes done during fastset as well. It makes no sense
for it to still exist as a separate function.
Changes since v1:
- Inline intel_update_pipe_config()
Changes since v2:
- Add comments suggested by matt.
- Reorder commit_pipe_config() to remove all nesting. (Ville, Matt)
- Use intel_set_pipe_src_size((). (Matt)
Signed-off-by: Maarten Lankhorst
---
drivers/gpu/drm/i915/display/intel_display.c | 206 +--
1 file changed, 95 insertions(+), 111 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index b77574cda648..239e0ca3e3ec 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
static void chv_prepare_pll(struct intel_crtc *crtc,
const struct intel_crtc_state *pipe_config);
-static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
intel_crtc *);
-static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
intel_crtc *);
static void intel_crtc_init_scalers(struct intel_crtc *crtc,
struct intel_crtc_state *crtc_state);
static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
@@ -4409,45 +4407,6 @@ static void icl_set_pipe_chicken(struct intel_crtc *crtc)
I915_WRITE(PIPE_CHICKEN(pipe), tmp);
}
-static void intel_update_pipe_config(const struct intel_crtc_state
*old_crtc_state,
-const struct intel_crtc_state
*new_crtc_state)
-{
- struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
- struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
-
- /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
- crtc->base.mode = new_crtc_state->uapi.mode;
-
- /*
-* Update pipe size and adjust fitter if needed: the reason for this is
-* that in compute_mode_changes we check the native mode (not the pfit
-* mode) to see if we can flip rather than do a full mode set. In the
-* fastboot case, we'll flip, but if we don't update the pipesrc and
-* pfit state, we'll end up with a big fb scanned out into the wrong
-* sized surface.
-*/
-
- I915_WRITE(PIPESRC(crtc->pipe),
- ((new_crtc_state->pipe_src_w - 1) << 16) |
- (new_crtc_state->pipe_src_h - 1));
-
- /* on skylake this is done by detaching scalers */
- if (INTEL_GEN(dev_priv) >= 9) {
- skl_detach_scalers(new_crtc_state);
-
- if (new_crtc_state->pch_pfit.enabled)
- skylake_pfit_enable(new_crtc_state);
- } else if (HAS_PCH_SPLIT(dev_priv)) {
- if (new_crtc_state->pch_pfit.enabled)
- ironlake_pfit_enable(new_crtc_state);
- else if (old_crtc_state->pch_pfit.enabled)
- ironlake_pfit_disable(old_crtc_state);
- }
-
- if (INTEL_GEN(dev_priv) >= 11)
- icl_set_pipe_chicken(crtc);
-}
-
static void intel_fdi_normal_train(struct intel_crtc *crtc)
{
struct drm_device *dev = crtc->base.dev;
@@ -13739,13 +13698,91 @@ u32 intel_crtc_get_vblank_counter(struct intel_crtc
*crtc)
return crtc->base.funcs->get_vblank_counter(&crtc->base);
}
+void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
+ struct intel_crtc_state *crtc_state)
+{
+ struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
+
+ if (!IS_GEN(dev_priv, 2))
+ intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
true);
+
+ if (crtc_state->has_pch_encoder) {
+ enum pipe pch_transcoder =
+ intel_crtc_pch_transcoder(crtc);
+
+ intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
true);
+ }
+}
+
+static void commit_pipe_config(struct intel_atomic_state *state,
+ struct intel_crtc_state *old_crtc_state,
+ struct intel_crtc_state *new_crtc_state)
+{
+ struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
+ struct drm_i915_private *dev_priv = to_i915(state->base.dev);
+ bool modeset = needs_modeset(new_crtc_state);
+
+ if (dev_priv->display.atomic_update_watermarks)
+ dev_priv->display.atomic_update_watermarks(state,
+ new_crtc_state);
+
+ /*
+* During modesets pipe configuration was programmed as the
+* CRTC was enabled.
+*/
+ if (modeset)
+
Re: [Intel-gfx] [PATCH 3/3] drm/i915: FB backing gem obj should reside in LMEM
On 26/09/2019 10:14, Ramalingam C wrote:
On 2019-09-26 at 09:53:03 +0100, Tvrtko Ursulin wrote:
On 26/09/2019 06:21, Ramalingam C wrote:
If Local memory is supported by hardware, we want framebuffer backing
gem objects out of local memory.
If local memory is supported and gem object if not from local memory we
migrate the obj into local memory. And once framebuffer is created we
block the migration of the associated object out of local memory.
This is developed on top of v3 LMEM series
https://patchwork.freedesktop.org/series/56683/
cc: Matthew Auld
Signed-off-by: Ramalingam C
---
drivers/gpu/drm/i915/display/intel_display.c | 25 +
drivers/gpu/drm/i915/gem/i915_gem_object.c | 58
drivers/gpu/drm/i915/gem/i915_gem_object.h | 3 +
3 files changed, 62 insertions(+), 24 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 1cc74844d3ea..d1921a317066 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -56,6 +56,8 @@
#include "display/intel_tv.h"
#include "display/intel_vdsc.h"
+#include "gem/i915_gem_object.h"
+
#include "i915_drv.h"
#include "i915_trace.h"
#include "intel_acpi.h"
@@ -15496,6 +15498,10 @@ static void intel_setup_outputs(struct
drm_i915_private *dev_priv)
static void intel_user_framebuffer_destroy(struct drm_framebuffer *fb)
{
struct intel_framebuffer *intel_fb = to_intel_framebuffer(fb);
+ struct drm_i915_private *dev_priv = to_i915(fb->dev);
+
+ /* removing the FB memory region restriction on obj, if any */
+ intel_fb->front_buffer->obj = INTEL_INFO(dev_priv)->memory_regions;
Is this right, assigning bitmask to something called obj?
Oops. wanted to assign into the obj->memory_regions. Thanks for
catching it.
drm_framebuffer_cleanup(fb);
intel_frontbuffer_put(intel_fb->frontbuffer);
@@ -15543,11 +15549,26 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
{
struct drm_i915_private *dev_priv = to_i915(obj->base.dev);
struct drm_framebuffer *fb = &intel_fb->base;
+ u32 *region_map;
u32 max_stride;
unsigned int tiling, stride;
int ret = -EINVAL;
int i;
+ /* GEM Obj for frame buffer is expected to be in LMEM. */
+ if (HAS_LMEM(dev_priv))
+ if (obj->mm.region->type != INTEL_LMEM) {
+ region_map = &intel_region_map[INTEL_MEMORY_LMEM];
+ ret = i915_gem_object_mem_region_migrate(dev_priv, obj,
+region_map,
+1);
+ if (ret) {
+ DRM_ERROR("FB migration to LMEM Failed(%d)\n",
+ ret);
Probably should be just debug level since it is imaginably user triggerable
and not really an error for the kernel as such.
Sure.
+ return ret;
+ }
+ }
+
intel_fb->frontbuffer = intel_frontbuffer_get(obj);
if (!intel_fb->frontbuffer)
return -ENOMEM;
@@ -15666,6 +15687,10 @@ static int intel_framebuffer_init(struct
intel_framebuffer *intel_fb,
goto err;
}
+ /* Blocking the migration of gem obj out of LMEM */
+ if (HAS_LMEM(dev_priv))
+ obj->memory_regions = REGION_LMEM;
+
return 0;
err:
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
b/drivers/gpu/drm/i915/gem/i915_gem_object.c
index e6f8426dedff..65b47054130b 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
@@ -501,30 +501,11 @@ __region_id(u32 region)
return INTEL_MEMORY_UKNOWN;
}
-static int i915_gem_object_region_select(struct drm_i915_private *dev_priv,
-struct drm_i915_gem_object_param *args,
-struct drm_file *file,
-struct drm_i915_gem_object *obj)
+int i915_gem_object_mem_region_migrate(struct drm_i915_private *dev_priv,
+ struct drm_i915_gem_object *obj,
+ u32 *uregions, u32 region_count)
{
struct intel_context *ce = dev_priv->engine[BCS0]->kernel_context;
- u32 __user *uregions = u64_to_user_ptr(args->data);
- u32 uregions_copy[INTEL_MEMORY_UKNOWN];
- int i, ret;
-
- if (args->size > INTEL_MEMORY_UKNOWN)
- return -EINVAL;
-
- memset(uregions_copy, 0, sizeof(uregions_copy));
- for (i = 0; i < args->size; i++) {
- u32 region;
-
- ret = get_user(region, uregions);
- if (ret)
- return ret;
-
-
[Intel-gfx] [PATCH 3/6] drm/i915: Adjust length of MI_LOAD_REGISTER_REG
Default length value of MI_LOAD_REGISTER_REG is 1. Also move it out of cmd-parser-only registers since we're going to use it in i915. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Jani Nikula --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index f78b13d74e17..9211b1ad401b 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -152,6 +152,7 @@ #define MI_FLUSH_DW_USE_PPGTT(0<<2) #define MI_LOAD_REGISTER_MEM MI_INSTR(0x29, 1) #define MI_LOAD_REGISTER_MEM_GEN8 MI_INSTR(0x29, 2) +#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1) #define MI_BATCH_BUFFERMI_INSTR(0x30, 1) #define MI_BATCH_NON_SECURE (1) /* for snb/ivb/vlv this also means "batch in ppgtt" when ppgtt is enabled. */ @@ -256,7 +257,6 @@ #define MI_CLFLUSH MI_INSTR(0x27, 0) #define MI_REPORT_PERF_COUNTMI_INSTR(0x28, 0) #define MI_REPORT_PERF_COUNT_GGTT (1<<0) -#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 0) #define MI_RS_STORE_DATA_IMMMI_INSTR(0x2B, 0) #define MI_LOAD_URB_MEM MI_INSTR(0x2C, 0) #define MI_STORE_URB_MEMMI_INSTR(0x2D, 0) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/6] drm/i915/execlists: Use per-process HWSP as scratch
Some of our commands (MI_FLUSH_DW / PIPE_CONTROL) require a post-sync write
operation to be performed. Currently we're using dedicated VMA for
PIPE_CONTROL and global HWSP for MI_FLUSH_DW.
On execlists platforms, each of our contexts has an area that can be
used as scratch space. Let's use that instead.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 45 +++-
drivers/gpu/drm/i915/gt/intel_lrc.h | 4 +++
3 files changed, 17 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 3039cef64b11..e64db4c13df6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -89,9 +89,6 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_DEFAULT = 0,
- /* 8 bytes */
- INTEL_GT_SCRATCH_FIELD_CLEAR_SLM_WA = 128,
-
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH = 128,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ab725a6ca0ac..fa385218ce92 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2308,12 +2308,6 @@ gen8_emit_flush_coherentl3_wa(struct intel_engine_cs
*engine, u32 *batch)
return batch;
}
-static u32 slm_offset(struct intel_engine_cs *engine)
-{
- return intel_gt_scratch_offset(engine->gt,
- INTEL_GT_SCRATCH_FIELD_CLEAR_SLM_WA);
-}
-
/*
* Typically we only have one indirect_ctx and per_ctx batch buffer which are
* initialized at the beginning and shared across all contexts but this field
@@ -2342,10 +2336,10 @@ static u32 *gen8_init_indirectctx_bb(struct
intel_engine_cs *engine, u32 *batch)
/* Actual scratch location is at 128 bytes offset */
batch = gen8_emit_pipe_control(batch,
PIPE_CONTROL_FLUSH_L3 |
- PIPE_CONTROL_GLOBAL_GTT_IVB |
+ PIPE_CONTROL_STORE_DATA_INDEX |
PIPE_CONTROL_CS_STALL |
PIPE_CONTROL_QW_WRITE,
- slm_offset(engine));
+ LRC_PPHWSP_SCRATCH_ADDR);
*batch++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
@@ -3052,7 +3046,7 @@ static int gen8_emit_flush(struct i915_request *request,
u32 mode)
}
*cs++ = cmd;
- *cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
+ *cs++ = LRC_PPHWSP_SCRATCH_ADDR;
*cs++ = 0; /* upper addr */
*cs++ = 0; /* value */
intel_ring_advance(request, cs);
@@ -3063,10 +3057,6 @@ static int gen8_emit_flush(struct i915_request *request,
u32 mode)
static int gen8_emit_flush_render(struct i915_request *request,
u32 mode)
{
- struct intel_engine_cs *engine = request->engine;
- u32 scratch_addr =
- intel_gt_scratch_offset(engine->gt,
- INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
bool vf_flush_wa = false, dc_flush_wa = false;
u32 *cs, flags = 0;
int len;
@@ -3088,7 +3078,7 @@ static int gen8_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
flags |= PIPE_CONTROL_QW_WRITE;
- flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+ flags |= PIPE_CONTROL_STORE_DATA_INDEX;
/*
* On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
@@ -3121,7 +3111,7 @@ static int gen8_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_DC_FLUSH_ENABLE,
0);
- cs = gen8_emit_pipe_control(cs, flags, scratch_addr);
+ cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
if (dc_flush_wa)
cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_CS_STALL, 0);
@@ -3134,11 +3124,6 @@ static int gen8_emit_flush_render(struct i915_request
*request,
static int gen11_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 *cs;
u32 flags = 0;
@@ -3151,13 +3136,13 @@ static int gen11_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
flags |= PIPE_CONTROL_FLUS
[Intel-gfx] [PATCH 1/6] drm/i915: Define explicit wedged on init reset state
We're currently using scratch presence as a way of identifying that we
entered wedged state at driver initialization time.
Let's use a separate flag rather than rely on scratch.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Mika Kuoppala
---
drivers/gpu/drm/i915/gt/intel_reset.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_reset.h | 9 +
drivers/gpu/drm/i915/gt/intel_reset_types.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ae68c3786f63..0f1534ac823f 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -811,7 +811,8 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
if (!test_bit(I915_WEDGED, >->reset.flags))
return true;
- if (!gt->scratch) /* Never full initialised, recovery impossible */
+ /* Never fullly initialised, recovery impossible */
+ if (test_bit(I915_WEDGED_ON_INIT, >->reset.flags))
return false;
GEM_TRACE("start\n");
@@ -1279,6 +1280,14 @@ int intel_gt_terminally_wedged(struct intel_gt *gt)
return intel_gt_is_wedged(gt) ? -EIO : 0;
}
+void intel_gt_set_wedged_on_init(struct intel_gt *gt)
+{
+ BUILD_BUG_ON(I915_RESET_ENGINE + I915_NUM_ENGINES >
+I915_WEDGED_ON_INIT);
+ intel_gt_set_wedged(gt);
+ set_bit(I915_WEDGED_ON_INIT, >->reset.flags);
+}
+
void intel_gt_init_reset(struct intel_gt *gt)
{
init_waitqueue_head(>->reset.queue);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.h
b/drivers/gpu/drm/i915/gt/intel_reset.h
index 52c00199e069..0b6ff1ee7f06 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset.h
@@ -45,6 +45,12 @@ void intel_gt_set_wedged(struct intel_gt *gt);
bool intel_gt_unset_wedged(struct intel_gt *gt);
int intel_gt_terminally_wedged(struct intel_gt *gt);
+/*
+ * There's no unset_wedged_on_init paired with this one.
+ * Once we're wedged on init, there's no going back.
+ */
+void intel_gt_set_wedged_on_init(struct intel_gt *gt);
+
int __intel_gt_reset(struct intel_gt *gt, intel_engine_mask_t engine_mask);
int intel_reset_guc(struct intel_gt *gt);
@@ -68,6 +74,9 @@ void __intel_fini_wedge(struct intel_wedge_me *w);
static inline bool __intel_reset_failed(const struct intel_reset *reset)
{
+ GEM_BUG_ON(test_bit(I915_WEDGED_ON_INIT, &reset->flags) ?
+ !test_bit(I915_WEDGED, &reset->flags) : false);
+
return unlikely(test_bit(I915_WEDGED, &reset->flags));
}
diff --git a/drivers/gpu/drm/i915/gt/intel_reset_types.h
b/drivers/gpu/drm/i915/gt/intel_reset_types.h
index 31968356e0c0..f43bc3a0fe4f 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset_types.h
@@ -29,11 +29,17 @@ struct intel_reset {
* we set the #I915_WEDGED bit. Prior to command submission, e.g.
* i915_request_alloc(), this bit is checked and the sequence
* aborted (with -EIO reported to userspace) if set.
+*
+* #I915_WEDGED_ON_INIT - If we fail to initialize the GPU we can no
+* longer use the GPU - similar to #I915_WEDGED bit. The difference in
+* in the way we're handling "forced" unwedged (e.g. through debugfs),
+* which is not allowed in case we failed to initialize.
*/
unsigned long flags;
#define I915_RESET_BACKOFF 0
#define I915_RESET_MODESET 1
#define I915_RESET_ENGINE 2
+#define I915_WEDGED_ON_INIT(BITS_PER_LONG - 2)
#define I915_WEDGED(BITS_PER_LONG - 1)
struct mutex mutex; /* serialises wedging/unwedging */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2da9544fa9a4..e2897a666225 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1411,7 +1411,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
err_gt:
mutex_unlock(&dev_priv->drm.struct_mutex);
- intel_gt_set_wedged(&dev_priv->gt);
+ intel_gt_set_wedged_on_init(&dev_priv->gt);
i915_gem_suspend(dev_priv);
i915_gem_suspend_late(dev_priv);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 5/6] drm/i915: Don't use scratch in WA batch.
We're currently doing one workaround where we're using scratch as a
temporary storage place, while we're overwriting the value of one
register with some known constant value in order to perform a
workaround.
While we could just do similar thing with CS_GPR register
and MI_LOAD_REGISTER_REG instead of scratch, since we would use CS_GPR
anyways, let's just drop the constant values and do the bitops using
MI_MATH.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_engine.h | 53
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 27 +++-
3 files changed, 58 insertions(+), 25 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index d3c6993f4f46..2dfe0b23af1d 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -400,6 +400,59 @@ gen8_emit_ggtt_write(u32 *cs, u32 value, u32 gtt_offset,
u32 flags)
return cs;
}
+/*
+ * We're using CS_GPR registers for the MI_MATH ops.
+ * Note that user contexts are free to use those registers, which means that we
+ * should only use this this function during context initialization, before
+ * context restore (WA batch) or inside i915-owned contexts.
+ */
+static inline u32 *
+gen8_emit_bitop_reg_mask(struct intel_engine_cs *engine,
+u32 *cs, u32 op, i915_reg_t reg, u32 mask)
+{
+ const u32 base = engine->mmio_base;
+
+ GEM_BUG_ON(op != MI_MATH_OR && op != MI_MATH_AND);
+
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = i915_mmio_reg_offset(GEN8_RING_CS_GPR(base, 0));
+ *cs++ = MI_NOOP;
+
+ *cs++ = MI_LOAD_REGISTER_IMM(1);
+ *cs++ = i915_mmio_reg_offset(GEN8_RING_CS_GPR(base, 1));
+ *cs++ = mask;
+ *cs++ = MI_NOOP;
+
+ *cs++ = MI_MATH(4);
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(0));
+ *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(1));
+ *cs++ = op;
+ *cs++ = MI_MATH_STORE(MI_MATH_REG(0), MI_MATH_REG_ACCU);
+ *cs++ = MI_NOOP;
+
+ *cs++ = MI_LOAD_REGISTER_REG;
+ *cs++ = i915_mmio_reg_offset(GEN8_RING_CS_GPR(base, 0));
+ *cs++ = i915_mmio_reg_offset(reg);
+ *cs++ = MI_NOOP;
+
+ return cs;
+}
+
+static inline u32 *
+gen8_emit_set_register(struct intel_engine_cs *engine,
+ u32 *cs, i915_reg_t reg, u32 mask)
+{
+ return gen8_emit_bitop_reg_mask(engine, cs, MI_MATH_OR, reg, mask);
+}
+
+static inline u32 *
+gen8_emit_clear_register(struct intel_engine_cs *engine,
+u32 *cs, i915_reg_t reg, u32 mask)
+{
+ return gen8_emit_bitop_reg_mask(engine, cs, MI_MATH_AND, reg, ~mask);
+}
+
static inline void __intel_engine_reset(struct intel_engine_cs *engine,
bool stalled)
{
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index e64db4c13df6..d9f25ac520a8 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -92,9 +92,6 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH = 128,
- /* 8 bytes */
- INTEL_GT_SCRATCH_FIELD_COHERENTL3_WA = 256,
-
};
#endif /* __INTEL_GT_TYPES_H__ */
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index fa385218ce92..089c17599ca4 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2269,13 +2269,7 @@ static int execlists_request_alloc(struct i915_request
*request)
* PIPE_CONTROL instruction. This is required for the flush to happen correctly
* but there is a slight complication as this is applied in WA batch where the
* values are only initialized once so we cannot take register value at the
- * beginning and reuse it further; hence we save its value to memory, upload a
- * constant value with bit21 set and then we restore it back with the saved
value.
- * To simplify the WA, a constant value is formed by using the default value
- * of this register. This shouldn't be a problem because we are only modifying
- * it for a short period and this batch in non-premptible. We can ofcourse
- * use additional instructions that read the actual value of the register
- * at that time and set our bit of interest but it makes the WA complicated.
+ * beginning and reuse it further;
*
* This WA is also required for Gen9 so extracting as a function avoids
* code duplication.
@@ -2283,27 +2277,16 @@ static int execlists_request_alloc(struct i915_request
*request)
static u32 *
gen8_emit_flush_coherentl3_wa(struct intel_engine_cs *engine, u32 *batch)
{
- /* NB no one else is allowed to scribble over scratch + 256! */
- *batch++ = MI_STORE_REGISTER_MEM_GEN8 | MI_SRM_LRM_GLOBAL_GTT;
-
[Intel-gfx] [PATCH 4/6] drm/i915: Add definitions for MI_MATH command
We can use it in i915 for updating parts of unmasked registers from within a batch. We're also adding Gen8+ versions of CS_GPR registers (aka MI_MATH_REG in the coprocessor). Signed-off-by: Michał Winiarski Cc: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 24 drivers/gpu/drm/i915/i915_reg.h | 4 2 files changed, 28 insertions(+) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index 9211b1ad401b..26c286bc9625 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -241,6 +241,30 @@ #define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1<<0) #define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */ +#define MI_MATH(x) MI_INSTR(0x1A, (x)-1) +#define MI_MATH_INSTR(opcode, op1, op2) (((opcode) << 20) | \ +((op1) << 10) | (op2)) +/* Opcodes for MI_MATH_INSTR */ +#define MI_MATH_NOOP MI_MATH_INSTR(0x0, 0x0, 0x0) +#define MI_MATH_LOAD(op1, op2) MI_MATH_INSTR(0x80, op1, op2) +#define MI_MATH_LOADINV(op1, op2)MI_MATH_INSTR(0x480, op1, op2) +#define MI_MATH_LOAD0(op1) MI_MATH_INSTR(0x081, op1) +#define MI_MATH_LOAD1(op1) MI_MATH_INSTR(0x481, op1) +#define MI_MATH_ADD MI_MATH_INSTR(0x100, 0x0, 0x0) +#define MI_MATH_SUB MI_MATH_INSTR(0x101, 0x0, 0x0) +#define MI_MATH_AND MI_MATH_INSTR(0x102, 0x0, 0x0) +#define MI_MATH_OR MI_MATH_INSTR(0x103, 0x0, 0x0) +#define MI_MATH_XOR MI_MATH_INSTR(0x104, 0x0, 0x0) +#define MI_MATH_STORE(op1, op2) MI_MATH_INSTR(0x180, op1, op2) +#define MI_MATH_STOREINV(op1, op2) MI_MATH_INSTR(0x580, op1, op2) +/* Registers used as operands in MI_MATH_INSTR */ +#define MI_MATH_REG(x) (x) +#define MI_MATH_REG_SRCA 0x20 +#define MI_MATH_REG_SRCB 0x21 +#define MI_MATH_REG_ACCU 0x31 +#define MI_MATH_REG_ZF 0x32 +#define MI_MATH_REG_CF 0x33 + /* * Commands used only by the command parser */ diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index e752de9470bd..fbedf89fc0bb 100644 --- a/drivers/gpu/drm/i915/i915_reg.h +++ b/drivers/gpu/drm/i915/i915_reg.h @@ -2483,6 +2483,10 @@ static inline bool i915_mmio_reg_valid(i915_reg_t reg) #define RING_WAIT(1 << 11) /* gen3+, PRBx_CTL */ #define RING_WAIT_SEMAPHORE (1 << 10) /* gen6+ */ +/* There are 16 64-bit CS General Purpose Registers per-engine on Gen8+ */ +#define GEN8_RING_CS_GPR(base, n) _MMIO(((base) + 0x600) + (n) * 8) +#define GEN8_RING_CS_GPR_UDW(base, n) _MMIO(((base) + 0x600) + (n) * 8 + 4) + #define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) * 4) #define RING_FORCE_TO_NONPRIV_ACCESS_RW (0 << 28)/* CFL+ & Gen11+ */ #define RING_FORCE_TO_NONPRIV_ACCESS_RD (1 << 28) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/4] drm/i915: Prepare to split crtc state in uapi and hw state (rev2)
== Series Details == Series: series starting with [1/4] drm/i915: Prepare to split crtc state in uapi and hw state (rev2) URL : https://patchwork.freedesktop.org/series/67227/ State : warning == Summary == $ dim checkpatch origin/drm-tip 1368d49f2ac9 drm/i915: Prepare to split crtc state in uapi and hw state -:2130: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #2130: FILE: drivers/gpu/drm/i915/display/intel_display.c:11264: + crtc_state->uapi.active = crtc_state->uapi.enable = true; -:2837: CHECK:MULTIPLE_ASSIGNMENTS: multiple assignments should be avoided #2837: FILE: drivers/gpu/drm/i915/display/intel_display.c:16735: + crtc_state->hw.active = crtc_state->hw.enable = -:4001: ERROR:CODE_INDENT: code indent should use tabs where possible #4001: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:211: +^I^I^I^I new_crtc_state->uapi.event);$ -:4001: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #4001: FILE: drivers/gpu/drm/i915/display/intel_sprite.c:211: + drm_crtc_arm_vblank_event(&crtc->base, + new_crtc_state->uapi.event); total: 1 errors, 0 warnings, 3 checks, 4371 lines checked e3721d7eec35 drm/i915: Handle a few more cases for hw/sw split 4e6a21fdedd8 drm/i915: Complete sw/hw split, v2. -:15: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #15: - Clear crtc_state->hw on disable, instead of using clear_intel_crtc_state(). total: 0 errors, 1 warnings, 0 checks, 204 lines checked a971c9fd2236 drm/i915: Remove begin/finish_crtc_commit, v3. -:191: ERROR:CODE_INDENT: code indent should use tabs where possible #191: FILE: drivers/gpu/drm/i915/display/intel_display.c:13821: +/*$ -:192: ERROR:CODE_INDENT: code indent should use tabs where possible #192: FILE: drivers/gpu/drm/i915/display/intel_display.c:13822: + * We usually enable FIFO underrun interrupts as part of the$ -:193: ERROR:CODE_INDENT: code indent should use tabs where possible #193: FILE: drivers/gpu/drm/i915/display/intel_display.c:13823: + * CRTC enable sequence during modesets. But when we inherit a$ -:194: ERROR:CODE_INDENT: code indent should use tabs where possible #194: FILE: drivers/gpu/drm/i915/display/intel_display.c:13824: + * valid pipe configuration from the BIOS we need to take care$ -:195: ERROR:CODE_INDENT: code indent should use tabs where possible #195: FILE: drivers/gpu/drm/i915/display/intel_display.c:13825: + * of enabling them on the CRTC's first fastset.$ -:196: ERROR:CODE_INDENT: code indent should use tabs where possible #196: FILE: drivers/gpu/drm/i915/display/intel_display.c:13826: + */$ total: 6 errors, 0 warnings, 0 checks, 247 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 6/6] drm/i915/execlists: Don't allocate scratch
We're no longer using it on execlists platforms. There's no point in
allocating it.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 --
drivers/gpu/drm/i915/gt/intel_gt.c| 6 ++
2 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f451d5076bde..a4e5aceff678 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -669,8 +669,6 @@ static int measure_breadcrumb_dw(struct intel_engine_cs
*engine)
struct measure_breadcrumb *frame;
int dw = -ENOMEM;
- GEM_BUG_ON(!engine->gt->scratch);
-
frame = kzalloc(sizeof(*frame), GFP_KERNEL);
if (!frame)
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index eef9bdae8ebb..e135a66b7242 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -329,6 +329,9 @@ static int intel_gt_init_scratch(struct intel_gt *gt,
unsigned int size)
struct i915_vma *vma;
int ret;
+ if (HAS_EXECLISTS(i915))
+ return 0;
+
obj = i915_gem_object_create_stolen(i915, size);
if (!obj)
obj = i915_gem_object_create_internal(i915, size);
@@ -358,6 +361,9 @@ static int intel_gt_init_scratch(struct intel_gt *gt,
unsigned int size)
static void intel_gt_fini_scratch(struct intel_gt *gt)
{
+ if (HAS_EXECLISTS(gt->i915))
+ return;
+
i915_vma_unpin_and_release(>->scratch, 0);
}
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/6] drm/i915: Adjust length of MI_LOAD_REGISTER_REG
Quoting Michał Winiarski (2019-09-26 11:06:32) > Default length value of MI_LOAD_REGISTER_REG is 1. > Also move it out of cmd-parser-only registers since we're going to use > it in i915. Hmm. So we do find_cmd_in_table() [cmdparser] that ignores the length field, this should not affect cmdparser. This is checked by gem_exec_parse/load-register-reg. So long as hsw 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 2/6] drm/i915/execlists: Use per-process HWSP as scratch
Quoting Michał Winiarski (2019-09-26 11:06:31) > Some of our commands (MI_FLUSH_DW / PIPE_CONTROL) require a post-sync write > operation to be performed. Currently we're using dedicated VMA for > PIPE_CONTROL and global HWSP for MI_FLUSH_DW. > On execlists platforms, each of our contexts has an area that can be > used as scratch space. Let's use that instead. > > Signed-off-by: Michał Winiarski > Cc: Chris Wilson > Cc: Daniele Ceraolo Spurio 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 1/6] drm/i915: Define explicit wedged on init reset state
Quoting Michał Winiarski (2019-09-26 11:06:30) > We're currently using scratch presence as a way of identifying that we > entered wedged state at driver initialization time. > Let's use a separate flag rather than rely on scratch. > > Signed-off-by: Michał Winiarski > Cc: Chris Wilson > Cc: Mika Kuoppala > --- > drivers/gpu/drm/i915/gt/intel_reset.c | 11 ++- > drivers/gpu/drm/i915/gt/intel_reset.h | 9 + > drivers/gpu/drm/i915/gt/intel_reset_types.h | 6 ++ > drivers/gpu/drm/i915/i915_gem.c | 2 +- > 4 files changed, 26 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c > b/drivers/gpu/drm/i915/gt/intel_reset.c > index ae68c3786f63..0f1534ac823f 100644 > --- a/drivers/gpu/drm/i915/gt/intel_reset.c > +++ b/drivers/gpu/drm/i915/gt/intel_reset.c > @@ -811,7 +811,8 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt) > if (!test_bit(I915_WEDGED, >->reset.flags)) > return true; > > - if (!gt->scratch) /* Never full initialised, recovery impossible */ > + /* Never fullly initialised, recovery impossible */ You went one 'l' too far in the correction. Ok, hard to argue against. 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 5/6] drm/i915: Don't use scratch in WA batch.
Quoting Michał Winiarski (2019-09-26 11:06:34) > We're currently doing one workaround where we're using scratch as a > temporary storage place, while we're overwriting the value of one > register with some known constant value in order to perform a > workaround. > While we could just do similar thing with CS_GPR register > and MI_LOAD_REGISTER_REG instead of scratch, since we would use CS_GPR > anyways, let's just drop the constant values and do the bitops using > MI_MATH. I'd like to have your confirmation that the w/a batch is executed before the CS_GPR are restored from the context image, and I'm going to wait for gem_ctx_isolation verification :-p -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Define explicit wedged on init reset state
== Series Details == Series: series starting with [1/6] drm/i915: Define explicit wedged on init reset state URL : https://patchwork.freedesktop.org/series/67276/ State : warning == Summary == $ dim checkpatch origin/drm-tip 8abcbd48e83e drm/i915: Define explicit wedged on init reset state f0d1bbf3054e drm/i915/execlists: Use per-process HWSP as scratch 15a08f2fa23c drm/i915: Adjust length of MI_LOAD_REGISTER_REG d0c06fd7dc46 drm/i915: Add definitions for MI_MATH command -:24: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #24: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:244: +#define MI_MATH(x) MI_INSTR(0x1A, (x)-1) ^ total: 0 errors, 0 warnings, 1 checks, 40 lines checked 6e224dde1fbc drm/i915: Don't use scratch in WA batch. 0dd27d5e1ca2 drm/i915/execlists: Don't allocate scratch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] drm/i915/execlists: Don't allocate scratch
Quoting Michał Winiarski (2019-09-26 11:06:35)
> We're no longer using it on execlists platforms. There's no point in
> allocating it.
>
> Signed-off-by: Michał Winiarski
> Cc: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 --
> drivers/gpu/drm/i915/gt/intel_gt.c| 6 ++
> 2 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> index f451d5076bde..a4e5aceff678 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> +++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
> @@ -669,8 +669,6 @@ static int measure_breadcrumb_dw(struct intel_engine_cs
> *engine)
> struct measure_breadcrumb *frame;
> int dw = -ENOMEM;
>
> - GEM_BUG_ON(!engine->gt->scratch);
> -
> frame = kzalloc(sizeof(*frame), GFP_KERNEL);
> if (!frame)
> return -ENOMEM;
> diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
> b/drivers/gpu/drm/i915/gt/intel_gt.c
> index eef9bdae8ebb..e135a66b7242 100644
> --- a/drivers/gpu/drm/i915/gt/intel_gt.c
> +++ b/drivers/gpu/drm/i915/gt/intel_gt.c
> @@ -329,6 +329,9 @@ static int intel_gt_init_scratch(struct intel_gt *gt,
> unsigned int size)
> struct i915_vma *vma;
> int ret;
>
> + if (HAS_EXECLISTS(i915))
> + return 0;
Push the decision to the backends then, and
if (gt->scratch)
return;
> +
> obj = i915_gem_object_create_stolen(i915, size);
> if (!obj)
> obj = i915_gem_object_create_internal(i915, size);
> @@ -358,6 +361,9 @@ static int intel_gt_init_scratch(struct intel_gt *gt,
> unsigned int size)
>
> static void intel_gt_fini_scratch(struct intel_gt *gt)
> {
> + if (HAS_EXECLISTS(gt->i915))
> + return;
Not required, as release NULL is a no-op. After pushing the init to the
backends, we keep the central free at the end, agnostic to whether or not
we needed the scratch.
> +
> i915_vma_unpin_and_release(>->scratch, 0);
> }
>
> --
> 2.21.0
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/4] drm/i915: Prepare to split crtc state in uapi and hw state (rev2)
== Series Details ==
Series: series starting with [1/4] drm/i915: Prepare to split crtc state in
uapi and hw state (rev2)
URL : https://patchwork.freedesktop.org/series/67227/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14549
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14549/
Known issues
Here are the changes found in Patchwork_14549 that come from known issues:
### IGT changes ###
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][1] ([fdo#109483]) -> [PASS][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14549/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][3] ([fdo#111045] / [fdo#111096]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14549/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
Participating hosts (50 -> 39)
--
Missing(11): fi-icl-u4 fi-bxt-dsi fi-ilk-m540 fi-tgl-u2 fi-hsw-4200u
fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14549
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14549: a971c9fd223648f1e5c4a0da49926414d78429c3 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a971c9fd2236 drm/i915: Remove begin/finish_crtc_commit, v3.
4e6a21fdedd8 drm/i915: Complete sw/hw split, v2.
e3721d7eec35 drm/i915: Handle a few more cases for hw/sw split
1368d49f2ac9 drm/i915: Prepare to split crtc state in uapi and hw state
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14549/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On 2019/9/26 下午4:21, Michael S. Tsirkin wrote: On Thu, Sep 26, 2019 at 12:04:46PM +0800, Jason Wang wrote: I'm not sure how stable above ops are. It's the kernel internal API, so there's no strict requirement for this. We will export a version value for userspace for compatibility. Given it's tied to virtio we probably want kernel+userspace feature bits? Yes, then I think we could probably have a version field inside e.g device_ops structure. Then it could be fetched from both kernel and userspace driver. Thanks my point was feature bits not a version number. Something like backend_feature that current vhost_net did? Thanks ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v4 9/9] Gen-12 display can decompress surfaces compressed by the media engine.
Detect the modifier corresponding to media compression to enable
display decompression for YUV and xRGB packed formats. A new modifier is
added so that the driver can distinguish between media and render
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
support media decompression.
v2: Fix checkpatch warnings on code style (Lucas)
From DK:
Separate modifier array for planes that cannot decompress media (Ville)
v3: Support planar formats
v4: Switch plane order
Cc: Nanley G Chery
Cc: Ville Syrjälä
Cc: Matt Roper
Signed-off-by: Dhinakaran Pandiyan
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/display/intel_display.c | 290 +-
.../drm/i915/display/intel_display_types.h| 2 +-
drivers/gpu/drm/i915/display/intel_sprite.c | 55 +++-
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 267 insertions(+), 81 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8ea55d67442c..df3ebaa167ab 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -1888,6 +1888,22 @@ static void intel_disable_pipe(const struct
intel_crtc_state *old_crtc_state)
intel_wait_for_pipe_off(old_crtc_state);
}
+bool is_ccs_modifier(u64 modifier)
+{
+ return modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS ||
+ modifier == I915_FORMAT_MOD_Y_TILED_CCS ||
+ modifier == I915_FORMAT_MOD_Yf_TILED_CCS;
+}
+
+static bool is_ccs_plane(const struct drm_framebuffer *fb, int color_plane)
+{
+ if (!is_ccs_modifier(fb->modifier))
+ return false;
+
+ return color_plane >= fb->format->num_planes / 2;
+}
+
static unsigned int intel_tile_size(const struct drm_i915_private *dev_priv)
{
return IS_GEN(dev_priv, 2) ? 2048 : 4096;
@@ -1908,11 +1924,13 @@ intel_tile_width_bytes(const struct drm_framebuffer
*fb, int color_plane)
else
return 512;
case I915_FORMAT_MOD_Y_TILED_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 128;
/* fall through */
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ /* fall through */
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 64;
/* fall through */
case I915_FORMAT_MOD_Y_TILED:
@@ -1921,7 +1939,7 @@ intel_tile_width_bytes(const struct drm_framebuffer *fb,
int color_plane)
else
return 512;
case I915_FORMAT_MOD_Yf_TILED_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 128;
/* fall through */
case I915_FORMAT_MOD_Yf_TILED:
@@ -1949,8 +1967,9 @@ static unsigned int
intel_tile_height(const struct drm_framebuffer *fb, int color_plane)
{
switch (fb->modifier) {
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
- if (color_plane == 1)
+ if (is_ccs_plane(fb, color_plane))
return 1;
/* fall through */
default:
@@ -2055,6 +2074,7 @@ static unsigned int intel_surf_alignment(const struct
drm_framebuffer *fb,
if (INTEL_GEN(dev_priv) >= 9)
return 256 * 1024;
return 0;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
return 16 * 1024;
case I915_FORMAT_MOD_Y_TILED_CCS:
@@ -2254,10 +2274,17 @@ static u32 intel_adjust_tile_offset(int *x, int *y,
return new_offset;
}
-static bool is_surface_linear(u64 modifier, int color_plane)
+static bool is_surface_linear(const struct drm_framebuffer *fb, int
color_plane)
{
- return modifier == DRM_FORMAT_MOD_LINEAR ||
- (modifier == I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS && color_plane
== 1);
+ switch (fb->modifier) {
+ case DRM_FORMAT_MOD_LINEAR:
+ return true;
+ case I915_FORMAT_MOD_Y_TILED_GEN12_RC_CCS:
+ case I915_FORMAT_MOD_Y_TILED_GEN12_MC_CCS:
+ return is_ccs_plane(fb, color_plane);
+ default:
+ return false;
+ }
}
static u32 intel_adjust_aligned_offset(int *x, int *y,
@@ -2272,7 +2299,7 @@ static u32 intel_adjust_aligned_offset(int *x, int *y,
WARN_ON(new_offset > old_offset);
- if (!is_surface_linear(fb->modifier, color_plane)) {
+ if (!is_surface_linear(fb, color_plane)) {
unsigned int tile_size, tile_width, tile_height;
unsigned int pitch_tiles;
@@ -2342,7 +2
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/6] drm/i915: Define explicit wedged on init reset state
== Series Details ==
Series: series starting with [1/6] drm/i915: Define explicit wedged on init
reset state
URL : https://patchwork.freedesktop.org/series/67276/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14550
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14550/
Known issues
Here are the changes found in Patchwork_14550 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_switch@legacy-render:
- fi-bxt-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#103927] /
[fdo#111381])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14550/fi-bxt-dsi/igt@gem_ctx_swi...@legacy-render.html
Possible fixes
* igt@i915_selftest@live_gtt:
- {fi-tgl-u2}:[INCOMPLETE][3] -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-tgl-u2/igt@i915_selftest@live_gtt.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14550/fi-tgl-u2/igt@i915_selftest@live_gtt.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][5] ([fdo#109483]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14550/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
Participating hosts (50 -> 42)
--
Additional (1): fi-kbl-soraka
Missing(9): fi-icl-u4 fi-ilk-m540 fi-hsw-4200u fi-byt-j1900
fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14550
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14550: 0dd27d5e1ca27637642936422f4a065d0280f783 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
0dd27d5e1ca2 drm/i915/execlists: Don't allocate scratch
6e224dde1fbc drm/i915: Don't use scratch in WA batch.
d0c06fd7dc46 drm/i915: Add definitions for MI_MATH command
15a08f2fa23c drm/i915: Adjust length of MI_LOAD_REGISTER_REG
f0d1bbf3054e drm/i915/execlists: Use per-process HWSP as scratch
8abcbd48e83e drm/i915: Define explicit wedged on init reset state
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14550/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Drop the IRQ-off asserts
The lockdep_assert_irqs_disabled() check is needless. The previous
lockdep_assert_held() check ensures that the lock is acquired and while
the lock is acquired lockdep also prints a warning if the interrupts are
not disabled if they have to be.
These IRQ-off asserts trigger on PREEMPT_RT because the locks become
sleeping locks and do not really disable interrupts.
Remove lockdep_assert_irqs_disabled().
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index f750375056de4..55317081d48b0 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -120,7 +120,6 @@ __dma_fence_signal__notify(struct dma_fence *fence,
struct dma_fence_cb *cur, *tmp;
lockdep_assert_held(fence->lock);
- lockdep_assert_irqs_disabled();
list_for_each_entry_safe(cur, tmp, list, node) {
INIT_LIST_HEAD(&cur->node);
@@ -269,7 +268,6 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
bool i915_request_enable_breadcrumb(struct i915_request *rq)
{
lockdep_assert_held(&rq->lock);
- lockdep_assert_irqs_disabled();
if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
@@ -319,7 +317,6 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
lockdep_assert_held(&rq->lock);
- lockdep_assert_irqs_disabled();
/*
* We must wait for b->irq_lock so that we know the interrupt handler
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/2] drm/i915: Acquire locks with interrupts disabled
Two locking related changed which popped up on PREEMPT_RT. Sebastian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915: Don't disable interrupts for intel_engine_breadcrumbs_irq()
The function intel_engine_breadcrumbs_irq() is always invoked from an interrupt
handler and for that reason it invokes (as an optimisation) only spin_lock()
for locking assuming that the interrupts are already disabled. The
function intel_engine_signal_breadcrumbs() is provided to disable
interrupts while the former function is invoked so that assumption is
also true for callers from preemptible context.
On PREEMPT_RT local_irq_disable() really disables interrupts and this
forbids to invoke spin_lock() which becomes a sleeping spinlock.
This is also problematic with `threadirqs' in conjunction with
irq_work. With force threading the interrupt handler, the handler is
invoked with disabled BH but with interrupts enabled. This is okay and
the lock itself is never acquired in IRQ context. This changes with
irq_work (signal_irq_work()) which _still_ invokes
intel_engine_breadcrumbs_irq() from IRQ context. Lockdep should see this
and complain.
Acquire the locks in intel_engine_breadcrumbs_irq() with _irqsave()
suffix and let all callers invoke intel_engine_breadcrumbs_irq()
directly instead using intel_engine_signal_breadcrumbs().
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 16 +---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 -
drivers/gpu/drm/i915/gt/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
4 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 09c68dda20988..f750375056de4 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -134,9 +134,10 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
const ktime_t timestamp = ktime_get();
struct intel_context *ce, *cn;
struct list_head *pos, *next;
+ unsigned long flags;
LIST_HEAD(signal);
- spin_lock(&b->irq_lock);
+ spin_lock_irqsave(&b->irq_lock, flags);
if (b->irq_armed && list_empty(&b->signalers))
__intel_breadcrumbs_disarm_irq(b);
@@ -182,30 +183,23 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
}
}
- spin_unlock(&b->irq_lock);
+ spin_unlock_irqrestore(&b->irq_lock, flags);
list_for_each_safe(pos, next, &signal) {
struct i915_request *rq =
list_entry(pos, typeof(*rq), signal_link);
struct list_head cb_list;
- spin_lock(&rq->lock);
+ spin_lock_irqsave(&rq->lock, flags);
list_replace(&rq->fence.cb_list, &cb_list);
__dma_fence_signal__timestamp(&rq->fence, timestamp);
__dma_fence_signal__notify(&rq->fence, &cb_list);
- spin_unlock(&rq->lock);
+ spin_unlock_irqrestore(&rq->lock, flags);
i915_request_put(rq);
}
}
-void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
-{
- local_irq_disable();
- intel_engine_breadcrumbs_irq(engine);
- local_irq_enable();
-}
-
static void signal_irq_work(struct irq_work *work)
{
struct intel_engine_cs *engine =
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index d3c6993f4f46f..c9e8c8ccbd47f 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -335,7 +335,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
*engine);
void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
static inline void
diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
index 05d042cdefe24..7ca67aac27d4d 100644
--- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
@@ -283,7 +283,7 @@ static void hangcheck_elapsed(struct work_struct *work)
for_each_engine(engine, gt->i915, id) {
struct hangcheck hc;
- intel_engine_signal_breadcrumbs(engine);
+ intel_engine_breadcrumbs_irq(engine);
hangcheck_load_sample(engine, &hc);
hangcheck_accumulate_sample(engine, &hc);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index b9d84d52e9864..1d5497a58eeb1 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -697,7 +697,7 @@ static void reset_finish_engine(struct intel_engine_cs
*engine)
engine->reset.finish(engine);
intel_uncore_forcewake_put(engine->uncore, FORCEWAKE_ALL);
- inte
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Gen12 E2E compression (rev2)
== Series Details ==
Series: Gen12 E2E compression (rev2)
URL : https://patchwork.freedesktop.org/series/67078/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
b4a0858736dc drm/framebuffer: Format modifier for Intel Gen-12 render
compression
97529f698ecd drm/i915: Use intel_tile_height() instead of re-implementing
e0aac1d19bd8 drm/i915: Move CCS stride alignment W/A inside
intel_fb_stride_alignment
32db1b3e4687 drm/i915/tgl: Gen-12 render decompression
f9b5443feb41 drm/i915: Extract framebufer CCS offset checks into a function
-:46: WARNING:BLOCK_COMMENT_STYLE: Block comments should align the * on each
line
#46: FILE: drivers/gpu/drm/i915/display/intel_display.c:2706:
+ /*
+ * CCS doesn't have its own x/y offset register, so the intra CCS tile
total: 0 errors, 1 warnings, 0 checks, 81 lines checked
3815b3cf3f91 drm/framebuffer: Format modifier for Intel Gen-12 media compression
70f5e38938bb drm/i915: Skip rotated offset adjustment for unsupported modifiers
1a74294adf44 drm/fb: Extend format_info member arrays to handle four planes
cd165d81961a Gen-12 display can decompress surfaces compressed by the media
engine.
-:13: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description
(prefer a maximum 75 chars per line)
#13:
compressed buffers. Unlike render decompression, plane 6 and plane 7 do not
-:230: WARNING:LONG_LINE: line over 100 characters
#230: FILE: drivers/gpu/drm/i915/display/intel_display.c:2723:
+intel_fb_plane_get_subsampling(int *hsub, int *vsub, const struct
drm_framebuffer *fb, int color_plane)
-:264: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#264: FILE: drivers/gpu/drm/i915/display/intel_display.c:2757:
+ *w = fb->width/hsub;
^
-:265: CHECK:SPACING: spaces preferred around that '/' (ctx:VxV)
#265: FILE: drivers/gpu/drm/i915/display/intel_display.c:2758:
+ *h = fb->height/vsub;
^
-:415: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#415: FILE: drivers/gpu/drm/i915/display/intel_display.c:3627:
if (is_ccs_modifier(fb->modifier)) {
+
-:443: CHECK:LINE_SPACING: Please don't use multiple blank lines
#443: FILE: drivers/gpu/drm/i915/display/intel_display.c:3689:
+
+
-:453: CHECK:BRACES: Blank lines aren't necessary before a close brace '}'
#453: FILE: drivers/gpu/drm/i915/display/intel_display.c:3699:
+
+ }
-:496: CHECK:SPACING: spaces preferred around that '/' (ctx:VxW)
#496: FILE: drivers/gpu/drm/i915/display/intel_display.c:3738:
+ intel_fb_plane_get_subsampling(&main_hsub, &main_vsub, fb, (ccs
- 1)/ 2);
^
total: 0 errors, 2 warnings, 6 checks, 659 lines checked
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/tgl: Swap rps disable for rc6 disable (rev2)
== Series Details == Series: drm/i915/tgl: Swap rps disable for rc6 disable (rev2) URL : https://patchwork.freedesktop.org/series/67214/ State : success == Summary == CI Bug Log - changes from CI_DRM_6956_full -> Patchwork_14534_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14534_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#110841]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb5/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-iclb1/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_exec_schedule@independent-bsd2: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) +11 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb2/igt@gem_exec_sched...@independent-bsd2.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-iclb6/igt@gem_exec_sched...@independent-bsd2.html * igt@gem_exec_schedule@preemptive-hang-bsd: - shard-iclb: [PASS][5] -> [SKIP][6] ([fdo#111325]) +5 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb8/igt@gem_exec_sched...@preemptive-hang-bsd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-iclb4/igt@gem_exec_sched...@preemptive-hang-bsd.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl3/igt@gem_soft...@noreloc-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-skl9/igt@gem_soft...@noreloc-s3.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl3/igt@i915_susp...@sysfs-reader.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-apl8/igt@i915_susp...@sysfs-reader.html - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-kbl1/igt@i915_susp...@sysfs-reader.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-kbl3/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-a-cursor-64x64-random: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103232]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-skl1/igt@kms_cursor_...@pipe-a-cursor-64x64-random.html * igt@kms_cursor_edge_walk@pipe-a-64x64-right-edge: - shard-apl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927]) +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl5/igt@kms_cursor_edge_w...@pipe-a-64x64-right-edge.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-apl3/igt@kms_cursor_edge_w...@pipe-a-64x64-right-edge.html * igt@kms_flip@plain-flip-fb-recreate: - shard-iclb: [PASS][17] -> [INCOMPLETE][18] ([fdo#107713]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@kms_f...@plain-flip-fb-recreate.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-iclb7/igt@kms_f...@plain-flip-fb-recreate.html * igt@kms_flip@plain-flip-ts-check-interruptible: - shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([fdo#103540]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw4/igt@kms_f...@plain-flip-ts-check-interruptible.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-hsw1/igt@kms_f...@plain-flip-ts-check-interruptible.html * igt@kms_frontbuffer_tracking@fbc-1p-pri-indfb-multidraw: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#103167]) +4 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-pri-indfb-multidraw.html * igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-gtt: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#103167]) +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14534/shard-skl1/igt@kms_frontbuffer_track...@psr-1p-primscrn-spr-indfb-draw-mmap-gtt.html * igt@kms_pl
[Intel-gfx] ✗ Fi.CI.BAT: failure for Gen12 E2E compression (rev2)
== Series Details == Series: Gen12 E2E compression (rev2) URL : https://patchwork.freedesktop.org/series/67078/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14551 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14551 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14551, 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_14551/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14551: ### IGT changes ### Possible regressions * igt@kms_addfb_basic@bo-too-small-due-to-tiling: - fi-blb-e6850: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-blb-e6850/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-blb-e6850/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-kbl-x1275: [PASS][3] -> [FAIL][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-x1275/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-kbl-x1275/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-apl-guc: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-apl-guc/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-apl-guc/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-bsw-kefka: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-bsw-kefka/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-bsw-kefka/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-bdw-5557u: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-bdw-5557u/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-bdw-5557u/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-bwr-2160:[PASS][11] -> [FAIL][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-bwr-2160/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-bwr-2160/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-skl-6770hq: [PASS][13] -> [FAIL][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-6770hq/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-skl-6770hq/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-skl-6600u: [PASS][15] -> [FAIL][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-6600u/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-skl-6600u/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-kbl-guc: [PASS][17] -> [FAIL][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-guc/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-kbl-guc/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-kbl-8809g: [PASS][19] -> [FAIL][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-8809g/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-kbl-8809g/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-skl-lmem:[PASS][21] -> [FAIL][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-lmem/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-skl-lmem/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-kbl-r: [PASS][23] -> [FAIL][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-r/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-kbl-r/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-skl-6260u: [PASS][25] -> [FAIL][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-6260u/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14551/fi-skl-6260u/igt@kms_addfb_ba...@bo-too-small-due-to-tiling.html - fi-byt-n2820: [PASS][27] -> [FAIL][28] [27]: https://inte
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915: Acquire locks with interrupts disabled
== Series Details == Series: drm/i915: Acquire locks with interrupts disabled URL : https://patchwork.freedesktop.org/series/67280/ State : warning == Summary == $ dim checkpatch origin/drm-tip ad5e66a449c0 drm/i915: Don't disable interrupts for intel_engine_breadcrumbs_irq() -:7: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #7: The function intel_engine_breadcrumbs_irq() is always invoked from an interrupt total: 0 errors, 1 warnings, 0 checks, 67 lines checked a46b9a438393 drm/i915: Drop the IRQ-off asserts ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Acquire locks with interrupts disabled
== Series Details ==
Series: drm/i915: Acquire locks with interrupts disabled
URL : https://patchwork.freedesktop.org/series/67280/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14552
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/
Known issues
Here are the changes found in Patchwork_14552 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-cml-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#110566])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/fi-cml-u2/igt@gem_ctx_cre...@basic-files.html
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][3] ([fdo#109483]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][5] ([fdo#111045] / [fdo#111096]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#106107]: https://bugs.freedesktop.org/show_bug.cgi?id=106107
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
Participating hosts (50 -> 43)
--
Additional (1): fi-kbl-soraka
Missing(8): fi-icl-u4 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14552
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14552: a46b9a438393fbbb6c997c3add1f7a108591adc1 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
a46b9a438393 drm/i915: Drop the IRQ-off asserts
ad5e66a449c0 drm/i915: Don't disable interrupts for
intel_engine_breadcrumbs_irq()
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14552/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 1/4] drm/i915/tc: Update DP_MODE programming
On Wed, Sep 25, 2019 at 04:45:06PM -0700, José Roberto de Souza wrote:
> From: Clinton A Taylor
>
> BSpec was updated(r146548) with a new MG_DP_MODE Programming table,
> now taking in consideration the pin assignment and allowing us to
> optimize power by shutting down available but not needed lanes.
>
> It was tested on ICL and TGL, with adaptors that used pin assignment
> C and B, reversing the connector and going to different modes testing
> the not needed lane shutdown.
>
> BSpec: 21735
> BSpec: 49292
>
> Cc: Imre Deak
> Cc: Lucas De Marchi
> Signed-off-by: Clinton A Taylor
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 82 +---
> drivers/gpu/drm/i915/display/intel_tc.c | 15 +
> drivers/gpu/drm/i915/display/intel_tc.h | 1 +
> drivers/gpu/drm/i915/i915_reg.h | 5 ++
> 4 files changed, 66 insertions(+), 37 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index aa470c70a198..316cedb16935 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -3095,7 +3095,8 @@ static void icl_program_mg_dp_mode(struct
> intel_digital_port *intel_dig_port)
> {
> struct drm_i915_private *dev_priv =
> to_i915(intel_dig_port->base.base.dev);
> enum port port = intel_dig_port->base.port;
> - u32 ln0, ln1, lane_mask;
> + u32 ln0, ln1, pin_assignment;
> + u8 width;
>
> if (intel_dig_port->tc_mode == TC_PORT_TBT_ALT)
> return;
> @@ -3103,50 +3104,57 @@ static void icl_program_mg_dp_mode(struct
> intel_digital_port *intel_dig_port)
> ln0 = I915_READ(MG_DP_MODE(0, port));
> ln1 = I915_READ(MG_DP_MODE(1, port));
>
> - switch (intel_dig_port->tc_mode) {
> - case TC_PORT_DP_ALT:
> - ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> - ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> + ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X1_MODE);
> + ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
>
> - lane_mask = intel_tc_port_get_lane_mask(intel_dig_port);
> + /* DPPATC */
> + pin_assignment = intel_tc_port_get_pin_assignment_mask(intel_dig_port);
> + width = intel_dig_port->dp.lane_count;
Should be crtc_state->lane_count. (dp.lane_count makes no sense for HDMI
and it's also only set for link training)
>
> - switch (lane_mask) {
> - case 0x1:
> - case 0x4:
> - break;
> - case 0x2:
> + switch (pin_assignment) {
> + case 0x0:
> + WARN_ON(intel_dig_port->tc_mode != TC_PORT_LEGACY);
> + if (width == 1) {
> + ln1 |= MG_DP_MODE_CFG_DP_X1_MODE;
> + } else {
> + ln0 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + ln1 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + }
> + break;
> + case 0x1:
> + if (width == 4) {
> + ln0 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + ln1 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + }
> + break;
> + case 0x2:
> + if (width == 2) {
> + ln0 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + ln1 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + }
nit: WARN_ON(width==4)?
> + break;
> + case 0x3:
> + case 0x5:
> + if (width == 1) {
> ln0 |= MG_DP_MODE_CFG_DP_X1_MODE;
> - break;
> - case 0x3:
> - ln0 |= MG_DP_MODE_CFG_DP_X1_MODE |
> -MG_DP_MODE_CFG_DP_X2_MODE;
> - break;
> - case 0x8:
> ln1 |= MG_DP_MODE_CFG_DP_X1_MODE;
> - break;
> - case 0xC:
> - ln1 |= MG_DP_MODE_CFG_DP_X1_MODE |
> -MG_DP_MODE_CFG_DP_X2_MODE;
> - break;
> - case 0xF:
> - ln0 |= MG_DP_MODE_CFG_DP_X1_MODE |
> -MG_DP_MODE_CFG_DP_X2_MODE;
> - ln1 |= MG_DP_MODE_CFG_DP_X1_MODE |
> -MG_DP_MODE_CFG_DP_X2_MODE;
> - break;
> - default:
> - MISSING_CASE(lane_mask);
> + } else {
> + ln0 |= MG_DP_MODE_CFG_DP_X2_MODE;
> + ln1 |= MG_DP_MODE_CFG_DP_X2_MODE;
> }
> break;
> -
> - case TC_PORT_LEGACY:
> - ln0 |= MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE;
> - ln1 |= MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE;
> + case 0x4:
> + case 0x6:
> + if (width == 1) {
> + ln0 |= MG_DP_MODE_CFG_DP_X1_MODE;
> +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Don't skip debug messages when dp link config fails
== Series Details == Series: drm/i915: Don't skip debug messages when dp link config fails URL : https://patchwork.freedesktop.org/series/67232/ State : success == Summary == CI Bug Log - changes from CI_DRM_6956_full -> Patchwork_14535_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14535_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_schedule@preempt-other-bsd2: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) +4 similar issues [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb1/igt@gem_exec_sched...@preempt-other-bsd2.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-iclb6/igt@gem_exec_sched...@preempt-other-bsd2.html * igt@gem_exec_schedule@preempt-queue-contexts-chain-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb3/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-iclb4/igt@gem_exec_sched...@preempt-queue-contexts-chain-bsd.html * igt@i915_pm_rpm@debugfs-read: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#107807]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl10/igt@i915_pm_...@debugfs-read.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-skl1/igt@i915_pm_...@debugfs-read.html * igt@i915_pm_rpm@system-suspend: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713] / [fdo#108840]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@i915_pm_...@system-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-iclb7/igt@i915_pm_...@system-suspend.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([fdo#110741]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-skl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +3 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl6/igt@kms_cursor_...@pipe-c-cursor-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-apl4/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-hsw: [PASS][13] -> [INCOMPLETE][14] ([fdo#103540]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-hsw4/igt@kms_f...@flip-vs-suspend-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-hsw1/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_flip@wf_vblank-ts-check-interruptible: - shard-apl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103927]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-apl4/igt@kms_flip@wf_vblank-ts-check-interruptible.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-apl1/igt@kms_flip@wf_vblank-ts-check-interruptible.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-shrfb-plflip-blt: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb6/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-shrfb-plflip-blt.html * igt@kms_frontbuffer_tracking@psr-rgb565-draw-render: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#106978] / [fdo#107713]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-iclb7/igt@kms_frontbuffer_track...@psr-rgb565-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-iclb7/igt@kms_frontbuffer_track...@psr-rgb565-draw-render.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([fdo#108566]) +3 similar issues [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-kbl4/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14535/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_plane_alpha_blend@pipe-c-coverage-7efc: - shard-skl: [PASS][23] -> [FAIL][24] ([fdo#108145] / [fdo#110403]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6956/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-coverage-7efc.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patch
Re: [Intel-gfx] [PATCH V2 6/8] mdev: introduce virtio device and its device ops
On Thu, Sep 26, 2019 at 06:48:54PM +0800, Jason Wang wrote: > > On 2019/9/26 下午4:21, Michael S. Tsirkin wrote: > > On Thu, Sep 26, 2019 at 12:04:46PM +0800, Jason Wang wrote: > > > > > > I'm not sure how stable above ops are. > > > > > It's the kernel internal API, so there's no strict requirement for > > > > > this. We > > > > > will export a version value for userspace for compatibility. > > > > Given it's tied to virtio we probably want kernel+userspace > > > > feature bits? > > > > > > Yes, then I think we could probably have a version field inside e.g > > > device_ops structure. Then it could be fetched from both kernel and > > > userspace driver. > > > > > > Thanks > > > > > > > my point was feature bits not a version number. > > > Something like backend_feature that current vhost_net did? > > Thanks > > > > right ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/6] drm/i915/execlists: Don't allocate scratch
We're no longer using it on execlists platforms. There's no point in
allocating it.
v2: Move scratch init to legacy ring submission backend. (Chris)
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 2 --
drivers/gpu/drm/i915/gt/intel_gt.c | 17 +
drivers/gpu/drm/i915/gt/intel_gt.h | 2 +-
drivers/gpu/drm/i915/gt/intel_ringbuffer.c | 5 +
drivers/gpu/drm/i915/i915_gem.c| 2 --
5 files changed, 11 insertions(+), 17 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index f451d5076bde..a4e5aceff678 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -669,8 +669,6 @@ static int measure_breadcrumb_dw(struct intel_engine_cs
*engine)
struct measure_breadcrumb *frame;
int dw = -ENOMEM;
- GEM_BUG_ON(!engine->gt->scratch);
-
frame = kzalloc(sizeof(*frame), GFP_KERNEL);
if (!frame)
return -ENOMEM;
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.c
b/drivers/gpu/drm/i915/gt/intel_gt.c
index eef9bdae8ebb..e67a6cabc81d 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.c
+++ b/drivers/gpu/drm/i915/gt/intel_gt.c
@@ -322,13 +322,17 @@ void intel_gt_driver_register(struct intel_gt *gt)
intel_gpu_ips_init(gt->i915);
}
-static int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
+int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size)
{
struct drm_i915_private *i915 = gt->i915;
struct drm_i915_gem_object *obj;
struct i915_vma *vma;
int ret;
+ /* Created lazily - submission backend calls us at its init time */
+ if (gt->scratch)
+ return 0;
+
obj = i915_gem_object_create_stolen(i915, size);
if (!obj)
obj = i915_gem_object_create_internal(i915, size);
@@ -361,17 +365,6 @@ static void intel_gt_fini_scratch(struct intel_gt *gt)
i915_vma_unpin_and_release(>->scratch, 0);
}
-int intel_gt_init(struct intel_gt *gt)
-{
- int err;
-
- err = intel_gt_init_scratch(gt, IS_GEN(gt->i915, 2) ? SZ_256K : SZ_4K);
- if (err)
- return err;
-
- return 0;
-}
-
void intel_gt_driver_remove(struct intel_gt *gt)
{
GEM_BUG_ON(gt->awake);
diff --git a/drivers/gpu/drm/i915/gt/intel_gt.h
b/drivers/gpu/drm/i915/gt/intel_gt.h
index e6ab0bff0efb..b9ed8ea3706e 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt.h
@@ -30,7 +30,7 @@ static inline struct intel_gt *huc_to_gt(struct intel_huc
*huc)
void intel_gt_init_early(struct intel_gt *gt, struct drm_i915_private *i915);
void intel_gt_init_hw_early(struct drm_i915_private *i915);
int __must_check intel_gt_init_hw(struct intel_gt *gt);
-int intel_gt_init(struct intel_gt *gt);
+int intel_gt_init_scratch(struct intel_gt *gt, unsigned int size);
void intel_gt_driver_register(struct intel_gt *gt);
void intel_gt_driver_unregister(struct intel_gt *gt);
diff --git a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
index 0747b8c9f768..64d22239df8a 100644
--- a/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
+++ b/drivers/gpu/drm/i915/gt/intel_ringbuffer.c
@@ -2315,6 +2315,11 @@ int intel_ring_submission_init(struct intel_engine_cs
*engine)
struct intel_ring *ring;
int err;
+ err = intel_gt_init_scratch(engine->gt,
+ IS_GEN(engine->i915, 2) ? SZ_256K : SZ_4K);
+ if (err)
+ goto err;
+
timeline = intel_timeline_create(engine->gt, engine->status_page.vma);
if (IS_ERR(timeline)) {
err = PTR_ERR(timeline);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e2897a666225..09d387f4d46b 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1337,8 +1337,6 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
goto err_unlock;
}
- intel_gt_init(&dev_priv->gt);
-
ret = intel_engines_setup(dev_priv);
if (ret) {
GEM_BUG_ON(ret == -EIO);
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/perf: Fix use of kernel-doc format in structure members
Insert structure members names into their descriptions to follow
kernel-doc format.
Cc: Chris Wilson
Signed-off-by: Anna Karas
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fcf7423075ef..b3c7dbc1832a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1134,7 +1134,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;
@@ -1148,7 +1148,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;
@@ -1159,7 +1159,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
@@ -1181,7 +1181,7 @@ struct i915_perf_stream {
spinlock_t ptr_lock;
/**
-* One 'aging' tail pointer and one 'aged' tail pointer ready to
+* @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
@@ -1193,18 +1193,18 @@ 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
+* @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,
+* @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
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/6] drm/i915: Define explicit wedged on init reset state (rev2)
== Series Details == Series: series starting with [1/6] drm/i915: Define explicit wedged on init reset state (rev2) URL : https://patchwork.freedesktop.org/series/67276/ State : warning == Summary == $ dim checkpatch origin/drm-tip 5883d760ee3b drm/i915: Define explicit wedged on init reset state cc46370e91dd drm/i915/execlists: Use per-process HWSP as scratch cf8540776b9a drm/i915: Adjust length of MI_LOAD_REGISTER_REG 381b1a902308 drm/i915: Add definitions for MI_MATH command -:24: CHECK:SPACING: spaces preferred around that '-' (ctx:VxV) #24: FILE: drivers/gpu/drm/i915/gt/intel_gpu_commands.h:244: +#define MI_MATH(x) MI_INSTR(0x1A, (x)-1) ^ total: 0 errors, 0 warnings, 1 checks, 40 lines checked 1676f481a1d1 drm/i915: Don't use scratch in WA batch. edec173d749e drm/i915/execlists: Don't allocate scratch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 3/6] drm/i915/display/icl: HW state readout for transcoder port sync config
On Wed, Sep 25, 2019 at 11:37:58AM -0700, Manasi Navare wrote:
> On Wed, Sep 25, 2019 at 01:08:23PM +0300, Ville Syrjälä wrote:
> > On Tue, Sep 24, 2019 at 10:59:57AM -0700, Manasi Navare wrote:
> > > On Tue, Sep 24, 2019 at 05:38:00PM +0200, Maarten Lankhorst wrote:
> > > > Op 22-09-2019 om 19:08 schreef Manasi Navare:
> > > > > After the state is committed, we readout the HW registers and compare
> > > > > the HW state with the SW state that we just committed.
> > > > > For Transcdoer port sync, we add master_transcoder and the
> > > > > salves bitmask to the crtc_state, hence we need to read those during
> > > > > the HW state readout to avoid pipe state mismatch.
> > > > >
> > > > > v4:
> > > > > * Get power domains in master loop for get_config (Ville)
> > > > > v3:
> > > > > * Add TRANSCODER_D (Maarten)
> > > > > * v3 Reviewed-by: Maarten Lankhorst
> > > > >
> > > > > v2:
> > > > > * Add Transcoder_D and MISSING_CASE (Maarten)
> > > > >
> > > > > Cc: Ville Syrjälä
> > > > > Cc: Maarten Lankhorst
> > > > > Cc: Matt Roper
> > > > > Cc: Jani Nikula
> > > > > Signed-off-by: Manasi Navare
> > > > > ---
> > > > > drivers/gpu/drm/i915/display/intel_display.c | 69
> > > > >
> > > > > 1 file changed, 69 insertions(+)
> > > > >
> > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > index 1ae5eafe2892..711987eb4e9e 100644
> > > > > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > > > > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > > > > @@ -10470,6 +10470,72 @@ static void
> > > > > haswell_get_ddi_port_state(struct intel_crtc *crtc,
> > > > > }
> > > > > }
> > > > >
> > > > > +static enum transcoder transcoder_master(struct drm_i915_private
> > > > > *dev_priv,
> > > > > + enum transcoder cpu_transcoder)
> > > > > +{
> > > > > + u32 trans_port_sync, master_select;
> > > > > +
> > > > > + trans_port_sync =
> > > > > I915_READ(TRANS_DDI_FUNC_CTL2(cpu_transcoder));
> > > > > +
> > > > > + if ((trans_port_sync & PORT_SYNC_MODE_ENABLE) == 0)
> > > > > + return INVALID_TRANSCODER;
> > > > > +
> > > > > + master_select = trans_port_sync &
> > > > > + PORT_SYNC_MODE_MASTER_SELECT_MASK;
> > > > > + switch (master_select) {
> > > > > + case 1:
> > > > > + return TRANSCODER_A;
> > > > > + case 2:
> > > > > + return TRANSCODER_B;
> > > > > + case 3:
> > > > > + return TRANSCODER_C;
> > > > > + case 4:
> > > > > + return TRANSCODER_D;
> > > > > + default:
> > > > > + MISSING_CASE(master_select);
> > > > > + }
> > > > > +
> > > > > + return INVALID_TRANSCODER;
> > > > Could move this return up to default. :)
> > >
> > > Yes will do this
> > >
> > > > > +}
> > > > > +
> > > > > +static void icelake_get_trans_port_sync_config(struct intel_crtc
> > > > > *crtc,
> > > > > +struct intel_crtc_state
> > > > > *pipe_config)
> > > > > +{
> > > > > + struct drm_device *dev = crtc->base.dev;
> > > > > + struct drm_i915_private *dev_priv = to_i915(dev);
> > > > > + u32 transcoders;
> > > > > + enum transcoder cpu_transcoder;
> > > > > +
> > > > > + pipe_config->master_transcoder = transcoder_master(dev_priv,
> > > > > +
> > > > > pipe_config->cpu_transcoder);
> > > > > + if (pipe_config->master_transcoder != INVALID_TRANSCODER) {
> > > > > + pipe_config->sync_mode_slaves_mask = 0;
> > > > > + return;
> > > > > + }
> > > > > +
> > > >
> > > > It could still be useful to go through the loop below anyway, in case
> > > > we messed up. We are reading out from hw after all.
> > > >
> > >
> > > The loop below will be called always in case of the HW state readout for
> > > master, in case of the slave it will execute
> > > the firs part, get the master transcoder and return, why do we need to
> > > call the loop below for slave? Why cant we just return here
> > > as in the code?
> >
> > I think Maarten's point was to catch cases where the same transcoder is
> > accidentally configure as both slave and master.
> >
> But shouldnt we add a warn on for such a case, if we let it go through both
> the first part and the loop below
> then it will populate the master_trans and slave_bitmask both for the same
> crtc which would be wrong
> How can we flag such a case?
During state readout it'll get flagged by the state checker. For the
purposes of the initial readout I guess we could WARN_ON() since it
never should happen.
>
> Manasi
>
> > >
> > > > And then also add this as a PIPE_CONF_CHECK_X check to
> > > > pipe_config_compare().
> > > >
> > >
> > > This is already added in pipe_config_compare() in the patch that adds
> > > these two master_trans and slave_bitmask to
Re: [Intel-gfx] [PATCH 3/3] drm/i915/tgl: Remove single pipe restriction from SAGV
On Wed, Sep 25, 2019 at 01:33:52PM -0700, James Ausmus wrote:
> For Gen12, BSpec no longer tells us to disable SAGV when > 1 pipe is
> active. Update intel_can_enable_sagv to allow this, and loop through all
> active planes on all active crtcs to check against the interlaced and
> latency restrictions.
>
> BSpec: 49325
>
> Cc: Ville Syrjälä
> Cc: Stanislav Lisovskiy
> Cc: Lucas De Marchi
> Signed-off-by: James Ausmus
> ---
> drivers/gpu/drm/i915/intel_pm.c | 63 +
> 1 file changed, 32 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index ca2bec09edb5..cb50c697a6b8 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3775,7 +3775,6 @@ bool intel_can_enable_sagv(struct intel_atomic_state
> *state)
> struct intel_crtc *crtc;
> struct intel_plane *plane;
> struct intel_crtc_state *crtc_state;
> - enum pipe pipe;
> int level, latency;
> int sagv_block_time_us;
>
> @@ -3791,47 +3790,49 @@ bool intel_can_enable_sagv(struct intel_atomic_state
> *state)
> return true;
>
> /*
> - * SKL+ workaround: bspec recommends we disable SAGV when we have
> + * SKL-ICL workaround: bspec recommends we disable SAGV when we have
>* more then one pipe enabled
>*/
> - if (hweight8(state->active_pipes) > 1)
> + if (INTEL_GEN(dev_priv) < 12 && hweight8(state->active_pipes) > 1)
> return false;
>
> - /* Since we're now guaranteed to only have one active CRTC... */
> - pipe = ffs(state->active_pipes) - 1;
> - crtc = intel_get_crtc_for_pipe(dev_priv, pipe);
> - crtc_state = to_intel_crtc_state(crtc->base.state);
> + for_each_intel_crtc(&dev_priv->drm, crtc) {
> + crtc_state = to_intel_crtc_state(crtc->base.state);
> + if (!crtc_state->base.active)
> + continue;
>
> - if (crtc->base.state->adjusted_mode.flags & DRM_MODE_FLAG_INTERLACE)
> - return false;
> + if (crtc->base.state->adjusted_mode.flags &
> + DRM_MODE_FLAG_INTERLACE)
> + return false;
>
> - for_each_intel_plane_on_crtc(dev, crtc, plane) {
> - struct skl_plane_wm *wm =
> - &crtc_state->wm.skl.optimal.planes[plane->id];
> + for_each_intel_plane_on_crtc(dev, crtc, plane) {
> + struct skl_plane_wm *wm =
> + &crtc_state->wm.skl.optimal.planes[plane->id];
This whole loop is bothering me. I'd much rather we move to a scheme
where each plane computes it's SAGV friendlyness when computing the
watermarks. We'll anyway need that since we need to caclulate the
watermarks differently for the SAGV on vs. off cases.
>
> - /* Skip this plane if it's not enabled */
> - if (!wm->wm[0].plane_en)
> - continue;
> + /* Skip this plane if it's not enabled */
> + if (!wm->wm[0].plane_en)
> + continue;
>
> - /* Find the highest enabled wm level for this plane */
> - for (level = ilk_wm_max_level(dev_priv);
> - !wm->wm[level].plane_en; --level)
> - { }
> + /* Find the highest enabled wm level for this plane */
> + for (level = ilk_wm_max_level(dev_priv);
> + !wm->wm[level].plane_en; --level)
> + { }
>
> - latency = dev_priv->wm.skl_latency[level];
> + latency = dev_priv->wm.skl_latency[level];
>
> - if (skl_needs_memory_bw_wa(dev_priv) &&
> - plane->base.state->fb->modifier ==
> - I915_FORMAT_MOD_X_TILED)
> - latency += 15;
> + if (skl_needs_memory_bw_wa(dev_priv) &&
> + plane->base.state->fb->modifier ==
> + I915_FORMAT_MOD_X_TILED)
> + latency += 15;
>
> - /*
> - * If any of the planes on this pipe don't enable wm levels that
> - * incur memory latencies higher than sagv_block_time_us we
> - * can't enable SAGV.
> - */
> - if (latency < sagv_block_time_us)
> - return false;
> + /*
> + * If any of the planes on this pipe don't enable wm
> + * levels that incur memory latencies higher than
> + * sagv_block_time_us we can't enable SAGV.
> + */
> + if (latency < sagv_block_time_us)
> + return false;
> + }
> }
>
> return true;
> --
> 2.22.1
--
Ville Syrjälä
Intel
___
Re: [Intel-gfx] [PATCH] drm/i915: Add feature flag for platforms with DRAM
On Wed, Sep 25, 2019 at 02:07:27PM -0700, Stuart Summers wrote:
No commit message.
> Signed-off-by: Stuart Summers
> ---
> drivers/gpu/drm/i915/i915_drv.c | 2 +-
> drivers/gpu/drm/i915/i915_drv.h | 2 ++
> drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> drivers/gpu/drm/i915/intel_device_info.h | 1 +
> 4 files changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a9ee73b61f4d..552ba7607e9a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -1128,7 +1128,7 @@ intel_get_dram_info(struct drm_i915_private *dev_priv)
>*/
> dram_info->is_16gb_dimm = !IS_GEN9_LP(dev_priv);
>
> - if (INTEL_GEN(dev_priv) < 9)
> + if (!HAS_DRAM(dev_priv))
> return;
As opposed to what? SRAM?
>
> if (IS_GEN9_LP(dev_priv))
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index fcf7423075ef..e82ca38be59e 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2151,6 +2151,8 @@ IS_SUBPLATFORM(const struct drm_i915_private *i915,
>
> #define HAS_DP_MST(dev_priv) (INTEL_INFO(dev_priv)->display.has_dp_mst)
>
> +#define HAS_DRAM(dev_priv) (INTEL_INFO(dev_priv)->has_dram)
> +
> #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)->display.has_ddi)
> #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)->has_fpga_dbg)
> #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)->display.has_psr)
> diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
> index ea53dfe2fba0..98d7e07dba6a 100644
> --- a/drivers/gpu/drm/i915/i915_pci.c
> +++ b/drivers/gpu/drm/i915/i915_pci.c
> @@ -602,7 +602,8 @@ static const struct intel_device_info
> intel_cherryview_info = {
> .display.has_csr = 1, \
> .has_gt_uc = 1, \
> .display.has_ipc = 1, \
> - .ddb_size = 896
> + .ddb_size = 896, \
> + .has_dram = 1
>
> #define SKL_PLATFORM \
> GEN9_FEATURES, \
> diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> b/drivers/gpu/drm/i915/intel_device_info.h
> index 0cdc2465534b..c9c858100ea3 100644
> --- a/drivers/gpu/drm/i915/intel_device_info.h
> +++ b/drivers/gpu/drm/i915/intel_device_info.h
> @@ -109,6 +109,7 @@ enum intel_ppgtt_type {
> func(require_force_probe); \
> /* Keep has_* in alphabetical order */ \
> func(has_64bit_reloc); \
> + func(has_dram); \
> func(gpu_reset_clobbers_display); \
> func(has_reset_engine); \
> func(has_fpga_dbg); \
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/tgl: Fix doc not corresponding to code
Replace PLLs names used in documentation to that used in the code.
Cc: Vandita Kulkarni
Fixes: commit d0570414f3d1 ("drm/i915/tgl: Add new pll ids")
Signed-off-by: Anna Karas
---
drivers/gpu/drm/i915/display/intel_dpll_mgr.h | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
index e7588799fce5..104cf6d42333 100644
--- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
+++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.h
@@ -147,11 +147,11 @@ enum intel_dpll_id {
*/
DPLL_ID_ICL_MGPLL4 = 6,
/**
-* @DPLL_ID_TGL_TCPLL5: TGL TC PLL port 5 (TC5)
+* @DPLL_ID_TGL_MGPLL5: TGL TC PLL port 5 (TC5)
*/
DPLL_ID_TGL_MGPLL5 = 7,
/**
-* @DPLL_ID_TGL_TCPLL6: TGL TC PLL port 6 (TC6)
+* @DPLL_ID_TGL_MGPLL6: TGL TC PLL port 6 (TC6)
*/
DPLL_ID_TGL_MGPLL6 = 8,
};
--
2.19.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Remove begin/finish_crtc_commit, v2.
On Wed, Sep 25, 2019 at 02:42:12PM -0700, Matt Roper wrote:
> On Wed, Sep 25, 2019 at 04:59:01PM +0200, Maarten Lankhorst wrote:
> > This can all be done from the intel_update_crtc function. Split out the
> > pipe update into a separate function, just like is done for the planes.
> > Pull in all the changes done during fastset as well. It makes no sense
> > for it to still exist as a separate function.
> >
> > Changes since v1:
> > - Inline intel_update_pipe_config()
> >
> > Signed-off-by: Maarten Lankhorst
> > ---
> > drivers/gpu/drm/i915/display/intel_display.c | 197 ---
> > 1 file changed, 86 insertions(+), 111 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> > b/drivers/gpu/drm/i915/display/intel_display.c
> > index b77574cda648..5a9d06af9f29 100644
> > --- a/drivers/gpu/drm/i915/display/intel_display.c
> > +++ b/drivers/gpu/drm/i915/display/intel_display.c
> > @@ -136,8 +136,6 @@ static void vlv_prepare_pll(struct intel_crtc *crtc,
> > const struct intel_crtc_state *pipe_config);
> > static void chv_prepare_pll(struct intel_crtc *crtc,
> > const struct intel_crtc_state *pipe_config);
> > -static void intel_begin_crtc_commit(struct intel_atomic_state *, struct
> > intel_crtc *);
> > -static void intel_finish_crtc_commit(struct intel_atomic_state *, struct
> > intel_crtc *);
> > static void intel_crtc_init_scalers(struct intel_crtc *crtc,
> > struct intel_crtc_state *crtc_state);
> > static void skylake_pfit_enable(const struct intel_crtc_state *crtc_state);
> > @@ -4409,45 +4407,6 @@ static void icl_set_pipe_chicken(struct intel_crtc
> > *crtc)
> > I915_WRITE(PIPE_CHICKEN(pipe), tmp);
> > }
> >
> > -static void intel_update_pipe_config(const struct intel_crtc_state
> > *old_crtc_state,
> > -const struct intel_crtc_state
> > *new_crtc_state)
> > -{
> > - struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> > - struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > -
> > - /* drm_atomic_helper_update_legacy_modeset_state might not be called. */
> > - crtc->base.mode = new_crtc_state->uapi.mode;
> > -
> > - /*
> > -* Update pipe size and adjust fitter if needed: the reason for this is
> > -* that in compute_mode_changes we check the native mode (not the pfit
> > -* mode) to see if we can flip rather than do a full mode set. In the
> > -* fastboot case, we'll flip, but if we don't update the pipesrc and
> > -* pfit state, we'll end up with a big fb scanned out into the wrong
> > -* sized surface.
> > -*/
> > -
> > - I915_WRITE(PIPESRC(crtc->pipe),
> > - ((new_crtc_state->pipe_src_w - 1) << 16) |
> > - (new_crtc_state->pipe_src_h - 1));
> > -
> > - /* on skylake this is done by detaching scalers */
> > - if (INTEL_GEN(dev_priv) >= 9) {
> > - skl_detach_scalers(new_crtc_state);
> > -
> > - if (new_crtc_state->pch_pfit.enabled)
> > - skylake_pfit_enable(new_crtc_state);
> > - } else if (HAS_PCH_SPLIT(dev_priv)) {
> > - if (new_crtc_state->pch_pfit.enabled)
> > - ironlake_pfit_enable(new_crtc_state);
> > - else if (old_crtc_state->pch_pfit.enabled)
> > - ironlake_pfit_disable(old_crtc_state);
> > - }
> > -
> > - if (INTEL_GEN(dev_priv) >= 11)
> > - icl_set_pipe_chicken(crtc);
> > -}
> > -
> > static void intel_fdi_normal_train(struct intel_crtc *crtc)
> > {
> > struct drm_device *dev = crtc->base.dev;
> > @@ -13739,13 +13698,88 @@ u32 intel_crtc_get_vblank_counter(struct
> > intel_crtc *crtc)
> > return crtc->base.funcs->get_vblank_counter(&crtc->base);
> > }
> >
> > +void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
> > + struct intel_crtc_state *crtc_state)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(crtc->base.dev);
> > +
> > + if (!IS_GEN(dev_priv, 2))
> > + intel_set_cpu_fifo_underrun_reporting(dev_priv, crtc->pipe,
> > true);
> > +
> > + if (crtc_state->has_pch_encoder) {
> > + enum pipe pch_transcoder =
> > + intel_crtc_pch_transcoder(crtc);
> > +
> > + intel_set_pch_fifo_underrun_reporting(dev_priv, pch_transcoder,
> > true);
> > + }
> > +}
> > +
> > +static void commit_pipe_config(struct intel_atomic_state *state,
> > + struct intel_crtc_state *old_crtc_state,
> > + struct intel_crtc_state *new_crtc_state)
> > +{
> > + struct intel_crtc *crtc = to_intel_crtc(new_crtc_state->uapi.crtc);
> > + struct drm_i915_private *dev_priv = to_i915(state->base.dev);
> > + bool modeset = needs_modeset(new_crtc_state);
> > +
> > + if (!modeset) {
> > + if (new_crtc_state->uapi.color_mgmt_changed ||
> > + new_crtc_state->update_pipe)
>
Re: [Intel-gfx] [PATCH V2 5/8] mdev: introduce device specific ops
On Wed, Sep 25, 2019 at 4:52 AM Tian, Kevin wrote:
> > From: Alex Williamson
> > Sent: Wednesday, September 25, 2019 7:07 AM
> >
> > On Tue, 24 Sep 2019 21:53:29 +0800
> > Jason Wang wrote:
> >
> > > Currently, except for the create and remove, the rest of
> > > mdev_parent_ops is designed for vfio-mdev driver only and may not help
> > > for kernel mdev driver. With the help of class id, this patch
> > > introduces device specific callbacks inside mdev_device
> > > structure. This allows different set of callback to be used by
> > > vfio-mdev and virtio-mdev.
> > >
> > > Signed-off-by: Jason Wang
> > > ---
> > > .../driver-api/vfio-mediated-device.rst | 4 +-
> > > MAINTAINERS | 1 +
> > > drivers/gpu/drm/i915/gvt/kvmgt.c | 17 +++---
> > > drivers/s390/cio/vfio_ccw_ops.c | 17 --
> > > drivers/s390/crypto/vfio_ap_ops.c | 13 +++--
> > > drivers/vfio/mdev/mdev_core.c | 12 +
> > > drivers/vfio/mdev/mdev_private.h | 1 +
> > > drivers/vfio/mdev/vfio_mdev.c | 37 ++---
> > > include/linux/mdev.h | 42 ---
> > > include/linux/vfio_mdev.h | 52 +++
> > > samples/vfio-mdev/mbochs.c| 19 ---
> > > samples/vfio-mdev/mdpy.c | 19 ---
> > > samples/vfio-mdev/mtty.c | 17 --
> > > 13 files changed, 168 insertions(+), 83 deletions(-)
> > > create mode 100644 include/linux/vfio_mdev.h
> > >
> > > diff --git a/Documentation/driver-api/vfio-mediated-device.rst
> > b/Documentation/driver-api/vfio-mediated-device.rst
> > > index a5bdc60d62a1..d50425b368bb 100644
> > > --- a/Documentation/driver-api/vfio-mediated-device.rst
> > > +++ b/Documentation/driver-api/vfio-mediated-device.rst
> > > @@ -152,7 +152,9 @@ callbacks per mdev parent device, per mdev type,
> > or any other categorization.
> > > Vendor drivers are expected to be fully asynchronous in this respect
> or
> > > provide their own internal resource protection.)
> > >
> > > -The callbacks in the mdev_parent_ops structure are as follows:
> > > +The device specific callbacks are referred through device_ops pointer
> > > +in mdev_parent_ops. For vfio-mdev device, its callbacks in device_ops
> > > +are as follows:
> >
> > This is not accurate. device_ops is now on the mdev_device and is an
> > mdev bus driver specific structure of callbacks that must be registered
> > for each mdev device by the parent driver during the create callback.
> > There's a one to one mapping of class_id to mdev_device_ops callbacks.
>
> there is also a mistake in include/Linux/mdev.h, where device_ops is
> still part of mdev_parent_ops in the comment line.
>
> >
> > That also suggests to me that we could be more clever in registering
> > both of these with mdev-core. Can we embed the class_id in the ops
> > structure in a common way so that the core can extract it and the bus
> > drivers can access their specific callbacks?
> >
> > > * open: open callback of mediated device
> > > * close: close callback of mediated device
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > index b2326dece28e..89832b316500 100644
> > > --- a/MAINTAINERS
> > > +++ b/MAINTAINERS
> > > @@ -17075,6 +17075,7 @@ S: Maintained
> > > F: Documentation/driver-api/vfio-mediated-device.rst
> > > F: drivers/vfio/mdev/
> > > F: include/linux/mdev.h
> > > +F: include/linux/vfio_mdev.h
> > > F: samples/vfio-mdev/
> > >
> > > VFIO PLATFORM DRIVER
> > > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > > index f793252a3d2a..b274f5ee481f 100644
> > > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> > > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> > > @@ -42,6 +42,7 @@
> > > #include
> > > #include
> > > #include
> > > +#include
> > > #include
> > >
> > > #include
> > > @@ -643,6 +644,8 @@ static void kvmgt_put_vfio_device(void *vgpu)
> > > vfio_device_put(((struct intel_vgpu *)vgpu)->vdev.vfio_device);
> > > }
> > >
> > > +static struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops;
> > > +
> > > static int intel_vgpu_create(struct kobject *kobj, struct mdev_device
> > *mdev)
> > > {
> > > struct intel_vgpu *vgpu = NULL;
> > > @@ -679,6 +682,7 @@ static int intel_vgpu_create(struct kobject *kobj,
> > struct mdev_device *mdev)
> > > ret = 0;
> > >
> > > mdev_set_class_id(mdev, MDEV_ID_VFIO);
> > > + mdev_set_dev_ops(mdev, &intel_vfio_vgpu_dev_ops);
> >
> > This seems rather unrefined. We're registering interdependent data in
> > separate calls. All drivers need to make both of these calls. I'm not
> > sure if this is a good idea, but what if we had:
> >
> > static const struct vfio_mdev_device_ops intel_vfio_vgpu_dev_ops = {
> > .id = MDEV_ID_VFIO,
> > .open = intel_vgpu_open,
> > .release= int
Re: [Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.
On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote:
> Now that we can program planes from the update_slave callback, and
> we have done all fb pinning correctly, it's time to program those
> planes as well.
>
> We use the update_slave callback as it allows us to use the
> separate states correctly.
>
> Signed-off-by: Maarten Lankhorst
> ---
> .../gpu/drm/i915/display/intel_atomic_plane.c | 53 +++
> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
> drivers/gpu/drm/i915/display/intel_display.c | 4 +-
> 3 files changed, 57 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> index cc088676f0a2..5db091e4ad6a 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
> @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct intel_atomic_state
> *state,
> }
> }
>
> +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc)
This plane stuff is where things go very much off the rails IMO.
Planes should not have to know anything about bigjoiner. They should
just have their appropriate hw state and blindly bash it into the
hardware.
> +{
> + struct intel_crtc_state *old_crtc_state =
> + intel_atomic_get_old_crtc_state(state, crtc);
> + struct intel_crtc_state *new_crtc_state =
> + intel_atomic_get_new_crtc_state(state, crtc);
> + struct skl_ddb_entry entries_y[I915_MAX_PLANES];
> + struct skl_ddb_entry entries_uv[I915_MAX_PLANES];
> + u32 update_mask = new_crtc_state->update_planes;
> + struct intel_plane *plane;
> +
> + memcpy(entries_y, old_crtc_state->wm.skl.plane_ddb_y,
> +sizeof(old_crtc_state->wm.skl.plane_ddb_y));
> + memcpy(entries_uv, old_crtc_state->wm.skl.plane_ddb_uv,
> +sizeof(old_crtc_state->wm.skl.plane_ddb_uv));
> +
> + while ((plane = skl_next_plane_to_commit(state, crtc,
> + entries_y, entries_uv,
> + &update_mask))) {
> + struct intel_plane_state *new_plane_state =
> + intel_atomic_get_new_plane_state(state, plane);
> + const struct intel_plane_state *master_plane_state;
> +
> + if (new_plane_state->base.visible) {
> + master_plane_state =
> + intel_atomic_get_new_plane_state(state,
> new_plane_state->bigjoiner_plane);
> +
> + intel_update_slave(plane, new_crtc_state,
> +master_plane_state, new_plane_state);
> + } else if (new_plane_state->slave) {
> + /*
> + * bigjoiner slave + planar slave.
> + * The correct sequence is to get from the planar slave
> to planar master,
> + * then to the master plane state for the
> master_plane_state.
> + */
> +
> + struct intel_plane *linked =
> new_plane_state->linked_plane;
> + const struct intel_plane_state *uv_plane_state =
> + intel_atomic_get_new_plane_state(state, linked);
> +
> + linked = uv_plane_state->bigjoiner_plane;
> + master_plane_state =
> + intel_atomic_get_new_plane_state(state, linked);
> +
> + intel_update_slave(plane, new_crtc_state,
> +master_plane_state, new_plane_state);
> + } else {
> + intel_disable_plane(plane, new_crtc_state);
> + }
> + }
> +}
> +
> void i9xx_update_planes_on_crtc(struct intel_atomic_state *state,
> struct intel_crtc *crtc)
> {
> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> index 901a50e6e2d3..1cffda2b50b5 100644
> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
> @@ -30,6 +30,8 @@ void intel_plane_free(struct intel_plane *plane);
> struct drm_plane_state *intel_plane_duplicate_state(struct drm_plane *plane);
> void intel_plane_destroy_state(struct drm_plane *plane,
> struct drm_plane_state *state);
> +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state *state,
> + struct intel_crtc *crtc);
> void skl_update_planes_on_crtc(struct intel_atomic_state *state,
> struct intel_crtc *crtc);
> void i9xx_update_planes_on_crtc(struct intel_atomic_state *state,
> diff --git a/drivers/gpu/drm/i915/display/intel_display.c
> b/drivers/gpu/drm/i915/display/in
Re: [Intel-gfx] [PATCH v4 3/4] drm/i915/tgl: Fix dkl link training
On Wed, Sep 25, 2019 at 04:45:08PM -0700, José Roberto de Souza wrote:
> Link training is failling when running link at 2.7GHz and 1.62GHz and
> following BSpec pll algorithm.
>
> Comparing the values calculated and the ones from the reference table
> it looks like MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO should not always set
> to 5. For DP ports ICL mg pll algorithm sets it to 10 or 5 based on
> div2 value, that matches with dkl hardcoded table.
>
> So implementing this way as it proved to work in HW and leaving a
> comment so we know why it do not match BSpec.
>
> v4:
> Using the same is_dp check as ICL, need testing on HDMI over tc port
>
> Issue reported on BSpec 49204.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/display/intel_dpll_mgr.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> index 69abafa45ce9..be69a2344294 100644
> --- a/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/display/intel_dpll_mgr.c
> @@ -2630,13 +2630,13 @@ static bool icl_mg_pll_find_divisors(int clock_khz,
> bool is_dp, bool use_ssc,
> continue;
>
> if (div2 >= 2) {
> - if (is_dkl) {
> - a_divratio = 5;
> - tlinedrv = 1;
> - } else {
> - a_divratio = is_dp ? 10 : 5;
> - tlinedrv = 2;
> - }
> + /*
> + * Note: a_divratio not matching TGL BSpec
> + * algorithm but matching hardcoded values and
> + * working on HW for DP alt-mode at least
> + */
> + a_divratio = is_dp ? 10 : 5;
> + tlinedrv = is_dkl ? 1 : 2;
> } else {
> a_divratio = 5;
> tlinedrv = 0;
> --
> 2.23.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/pm_rpm: Include breadcrumbs in the kernel log before i915.ko reloads
Make it easier to discern in the noise of the module reload where each
begins.
Signed-off-by: Chris Wilson
Cc: Andi Shyti
---
tests/i915/i915_pm_rpm.c | 4
1 file changed, 4 insertions(+)
diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
index a2bdabee2..f5f813c3d 100644
--- a/tests/i915/i915_pm_rpm.c
+++ b/tests/i915/i915_pm_rpm.c
@@ -2113,6 +2113,8 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
igt_subtest("module-reload") {
igt_debug("Reload w/o display\n");
igt_i915_driver_unload();
+
+ igt_kmsg(KMSG_INFO "Reloading i915 w/o display\n");
igt_assert_eq(igt_i915_driver_load("disable_display=1
mmio_debug=-1"), 0);
igt_assert(setup_environment());
@@ -2121,6 +2123,8 @@ igt_main_args("", long_options, help_str, opt_handler,
NULL)
igt_debug("Reload as normal\n");
igt_i915_driver_unload();
+
+ igt_kmsg(KMSG_INFO "Reloading i915 as normal\n");
igt_assert_eq(igt_i915_driver_load("mmio_debug=-1"), 0);
igt_assert(setup_environment());
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/6] drm/i915: Define explicit wedged on init reset state (rev2)
== Series Details ==
Series: series starting with [1/6] drm/i915: Define explicit wedged on init
reset state (rev2)
URL : https://patchwork.freedesktop.org/series/67276/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14553
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_14553 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_14553, 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_14553/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_14553:
### IGT changes ###
Possible regressions
* igt@gem_exec_create@basic:
- fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-byt-n2820/igt@gem_exec_cre...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-byt-n2820/igt@gem_exec_cre...@basic.html
* igt@runner@aborted:
- fi-byt-n2820: NOTRUN -> [FAIL][3]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-byt-n2820/igt@run...@aborted.html
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* igt@gem_exec_suspend@basic-s4-devices:
- {fi-tgl-u2}:[PASS][4] -> [INCOMPLETE][5]
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-tgl-u2/igt@gem_exec_susp...@basic-s4-devices.html
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-tgl-u2/igt@gem_exec_susp...@basic-s4-devices.html
Known issues
Here are the changes found in Patchwork_14553 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][6] -> [INCOMPLETE][7] ([fdo#107718])
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][8] ([fdo#111045]) -> [PASS][9]
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][10] ([fdo#109483]) -> [PASS][11]
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
- fi-kbl-7500u: [FAIL][12] ([fdo#111045] / [fdo#111096]) -> [PASS][13]
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14553/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
Participating hosts (50 -> 45)
--
Additional (2): fi-kbl-soraka fi-icl-u3
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14553
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14553: edec173d749e20592d7a683e8463cbf82429dc97 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
edec173d749e drm/i915/execlists: Don't allocate scratch
1676f481a1d1 drm/i915: Don't use scratch in WA batch.
381b1a902308 drm/i915: Add definitions for MI_MATH command
cf8540776b9a drm/i915: Adjust length of MI_LOAD_REGISTER_REG
cc46370e91dd drm/i915/execlists: Use per-process HWSP as scratch
5883d760ee3b drm/i915: Define explicit wedged on init reset state
== Logs ==
Fo
Re: [Intel-gfx] [PATCH i-g-t] i915/pm_rpm: Include breadcrumbs in the kernel log before i915.ko reloads
Hi Chris,
On Thu, Sep 26, 2019 at 02:10:06PM +0100, Chris Wilson wrote:
> Make it easier to discern in the noise of the module reload where each
> begins.
>
> Signed-off-by: Chris Wilson
> Cc: Andi Shyti
thanks for this patch!
Acked-by: Andi Shyti
Andi
> ---
> tests/i915/i915_pm_rpm.c | 4
> 1 file changed, 4 insertions(+)
>
> diff --git a/tests/i915/i915_pm_rpm.c b/tests/i915/i915_pm_rpm.c
> index a2bdabee2..f5f813c3d 100644
> --- a/tests/i915/i915_pm_rpm.c
> +++ b/tests/i915/i915_pm_rpm.c
> @@ -2113,6 +2113,8 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
> igt_subtest("module-reload") {
> igt_debug("Reload w/o display\n");
> igt_i915_driver_unload();
> +
> + igt_kmsg(KMSG_INFO "Reloading i915 w/o display\n");
> igt_assert_eq(igt_i915_driver_load("disable_display=1
> mmio_debug=-1"), 0);
>
> igt_assert(setup_environment());
> @@ -2121,6 +2123,8 @@ igt_main_args("", long_options, help_str, opt_handler,
> NULL)
>
> igt_debug("Reload as normal\n");
> igt_i915_driver_unload();
> +
> + igt_kmsg(KMSG_INFO "Reloading i915 as normal\n");
> igt_assert_eq(igt_i915_driver_load("mmio_debug=-1"), 0);
>
> igt_assert(setup_environment());
> --
> 2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/perf: Fix use of kernel-doc format in structure members
== Series Details ==
Series: drm/i915/perf: Fix use of kernel-doc format in structure members
URL : https://patchwork.freedesktop.org/series/67282/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14554
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/
Known issues
Here are the changes found in Patchwork_14554 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html
Possible fixes
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][3] ([fdo#111045]) -> [PASS][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][5] ([fdo#109483]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
Warnings
* igt@kms_chamelium@common-hpd-after-suspend:
- fi-icl-u2: [DMESG-WARN][7] ([fdo#102505] / [fdo#110390]) ->
[FAIL][8] ([fdo#109483])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/fi-icl-u2/igt@kms_chamel...@common-hpd-after-suspend.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][9] ([fdo#111045] / [fdo#111096]) -> [FAIL][10]
([fdo#111407])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#110390]: https://bugs.freedesktop.org/show_bug.cgi?id=110390
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
[fdo#111647]: https://bugs.freedesktop.org/show_bug.cgi?id=111647
Participating hosts (50 -> 46)
--
Additional (3): fi-kbl-soraka fi-hsw-4770r fi-icl-u3
Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y
fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14554
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14554: 84c229fae11a9b5d56b2c6e7c52b3ff57e385562 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
84c229fae11a drm/i915/perf: Fix use of kernel-doc format in structure members
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14554/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/perf: Fix use of kernel-doc format in structure members
On 26/09/2019 15:21, Anna Karas wrote:
Insert structure members names into their descriptions to follow
kernel-doc format.
Cc: Chris Wilson
Signed-off-by: Anna Karas
Still
Acked-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_drv.h | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fcf7423075ef..b3c7dbc1832a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1134,7 +1134,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;
@@ -1148,7 +1148,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;
@@ -1159,7 +1159,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
@@ -1181,7 +1181,7 @@ struct i915_perf_stream {
spinlock_t ptr_lock;
/**
-* One 'aging' tail pointer and one 'aged' tail pointer ready to
+* @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
@@ -1193,18 +1193,18 @@ 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
+* @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,
+* @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
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: Add definitions for MI_MATH command
Quoting Michał Winiarski (2019-09-26 11:06:33) > We can use it in i915 for updating parts of unmasked registers from > within a batch. We're also adding Gen8+ versions of CS_GPR registers > (aka MI_MATH_REG in the coprocessor). > > Signed-off-by: Michał Winiarski > Cc: Chris Wilson Checked against mesa's xml for convenience, Reviewed-by: Chris Wilson > --- > drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 24 > drivers/gpu/drm/i915/i915_reg.h | 4 > 2 files changed, 28 insertions(+) > > diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > index 9211b1ad401b..26c286bc9625 100644 > --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h > @@ -241,6 +241,30 @@ > #define PIPE_CONTROL_DEPTH_CACHE_FLUSH (1<<0) > #define PIPE_CONTROL_GLOBAL_GTT (1<<2) /* in addr dword */ > > +#define MI_MATH(x) MI_INSTR(0x1A, (x)-1) > +#define MI_MATH_INSTR(opcode, op1, op2) (((opcode) << 20) | \ > +((op1) << 10) | (op2)) Perhaps this would benefit from a touch of REG_FIELD for value checking. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 6/6] drm/i915/execlists: Don't allocate scratch
Quoting Michał Winiarski (2019-09-26 13:20:19) > We're no longer using it on execlists platforms. There's no point in > allocating it. > > v2: Move scratch init to legacy ring submission backend. (Chris) > > Signed-off-by: Michał Winiarski > Cc: Chris Wilson Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915: Define explicit wedged on init reset state
From: Michał Winiarski
We're currently using scratch presence as a way of identifying that we
entered wedged state at driver initialization time.
Let's use a separate flag rather than rely on scratch.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_reset.c | 11 ++-
drivers/gpu/drm/i915/gt/intel_reset.h | 9 +
drivers/gpu/drm/i915/gt/intel_reset_types.h | 6 ++
drivers/gpu/drm/i915/i915_gem.c | 2 +-
4 files changed, 26 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ae68c3786f63..ec978b4d1be3 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -811,7 +811,8 @@ static bool __intel_gt_unset_wedged(struct intel_gt *gt)
if (!test_bit(I915_WEDGED, >->reset.flags))
return true;
- if (!gt->scratch) /* Never full initialised, recovery impossible */
+ /* Never fully initialised, recovery impossible */
+ if (test_bit(I915_WEDGED_ON_INIT, >->reset.flags))
return false;
GEM_TRACE("start\n");
@@ -1279,6 +1280,14 @@ int intel_gt_terminally_wedged(struct intel_gt *gt)
return intel_gt_is_wedged(gt) ? -EIO : 0;
}
+void intel_gt_set_wedged_on_init(struct intel_gt *gt)
+{
+ BUILD_BUG_ON(I915_RESET_ENGINE + I915_NUM_ENGINES >
+I915_WEDGED_ON_INIT);
+ intel_gt_set_wedged(gt);
+ set_bit(I915_WEDGED_ON_INIT, >->reset.flags);
+}
+
void intel_gt_init_reset(struct intel_gt *gt)
{
init_waitqueue_head(>->reset.queue);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.h
b/drivers/gpu/drm/i915/gt/intel_reset.h
index 52c00199e069..0b6ff1ee7f06 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset.h
@@ -45,6 +45,12 @@ void intel_gt_set_wedged(struct intel_gt *gt);
bool intel_gt_unset_wedged(struct intel_gt *gt);
int intel_gt_terminally_wedged(struct intel_gt *gt);
+/*
+ * There's no unset_wedged_on_init paired with this one.
+ * Once we're wedged on init, there's no going back.
+ */
+void intel_gt_set_wedged_on_init(struct intel_gt *gt);
+
int __intel_gt_reset(struct intel_gt *gt, intel_engine_mask_t engine_mask);
int intel_reset_guc(struct intel_gt *gt);
@@ -68,6 +74,9 @@ void __intel_fini_wedge(struct intel_wedge_me *w);
static inline bool __intel_reset_failed(const struct intel_reset *reset)
{
+ GEM_BUG_ON(test_bit(I915_WEDGED_ON_INIT, &reset->flags) ?
+ !test_bit(I915_WEDGED, &reset->flags) : false);
+
return unlikely(test_bit(I915_WEDGED, &reset->flags));
}
diff --git a/drivers/gpu/drm/i915/gt/intel_reset_types.h
b/drivers/gpu/drm/i915/gt/intel_reset_types.h
index 31968356e0c0..f43bc3a0fe4f 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_reset_types.h
@@ -29,11 +29,17 @@ struct intel_reset {
* we set the #I915_WEDGED bit. Prior to command submission, e.g.
* i915_request_alloc(), this bit is checked and the sequence
* aborted (with -EIO reported to userspace) if set.
+*
+* #I915_WEDGED_ON_INIT - If we fail to initialize the GPU we can no
+* longer use the GPU - similar to #I915_WEDGED bit. The difference in
+* in the way we're handling "forced" unwedged (e.g. through debugfs),
+* which is not allowed in case we failed to initialize.
*/
unsigned long flags;
#define I915_RESET_BACKOFF 0
#define I915_RESET_MODESET 1
#define I915_RESET_ENGINE 2
+#define I915_WEDGED_ON_INIT(BITS_PER_LONG - 2)
#define I915_WEDGED(BITS_PER_LONG - 1)
struct mutex mutex; /* serialises wedging/unwedging */
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 2da9544fa9a4..e2897a666225 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1411,7 +1411,7 @@ int i915_gem_init(struct drm_i915_private *dev_priv)
err_gt:
mutex_unlock(&dev_priv->drm.struct_mutex);
- intel_gt_set_wedged(&dev_priv->gt);
+ intel_gt_set_wedged_on_init(&dev_priv->gt);
i915_gem_suspend(dev_priv);
i915_gem_suspend_late(dev_priv);
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915/execlists: Use per-process HWSP as scratch
From: Michał Winiarski
Some of our commands (MI_FLUSH_DW / PIPE_CONTROL) require a post-sync write
operation to be performed. Currently we're using dedicated VMA for
PIPE_CONTROL and global HWSP for MI_FLUSH_DW.
On execlists platforms, each of our contexts has an area that can be
used as scratch space. Let's use that instead.
Signed-off-by: Michał Winiarski
Cc: Chris Wilson
Cc: Daniele Ceraolo Spurio
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 --
drivers/gpu/drm/i915/gt/intel_lrc.c | 45 +++-
drivers/gpu/drm/i915/gt/intel_lrc.h | 4 +++
3 files changed, 17 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_gt_types.h
b/drivers/gpu/drm/i915/gt/intel_gt_types.h
index 3039cef64b11..e64db4c13df6 100644
--- a/drivers/gpu/drm/i915/gt/intel_gt_types.h
+++ b/drivers/gpu/drm/i915/gt/intel_gt_types.h
@@ -89,9 +89,6 @@ enum intel_gt_scratch_field {
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_DEFAULT = 0,
- /* 8 bytes */
- INTEL_GT_SCRATCH_FIELD_CLEAR_SLM_WA = 128,
-
/* 8 bytes */
INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH = 128,
diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
b/drivers/gpu/drm/i915/gt/intel_lrc.c
index ab725a6ca0ac..fa385218ce92 100644
--- a/drivers/gpu/drm/i915/gt/intel_lrc.c
+++ b/drivers/gpu/drm/i915/gt/intel_lrc.c
@@ -2308,12 +2308,6 @@ gen8_emit_flush_coherentl3_wa(struct intel_engine_cs
*engine, u32 *batch)
return batch;
}
-static u32 slm_offset(struct intel_engine_cs *engine)
-{
- return intel_gt_scratch_offset(engine->gt,
- INTEL_GT_SCRATCH_FIELD_CLEAR_SLM_WA);
-}
-
/*
* Typically we only have one indirect_ctx and per_ctx batch buffer which are
* initialized at the beginning and shared across all contexts but this field
@@ -2342,10 +2336,10 @@ static u32 *gen8_init_indirectctx_bb(struct
intel_engine_cs *engine, u32 *batch)
/* Actual scratch location is at 128 bytes offset */
batch = gen8_emit_pipe_control(batch,
PIPE_CONTROL_FLUSH_L3 |
- PIPE_CONTROL_GLOBAL_GTT_IVB |
+ PIPE_CONTROL_STORE_DATA_INDEX |
PIPE_CONTROL_CS_STALL |
PIPE_CONTROL_QW_WRITE,
- slm_offset(engine));
+ LRC_PPHWSP_SCRATCH_ADDR);
*batch++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
@@ -3052,7 +3046,7 @@ static int gen8_emit_flush(struct i915_request *request,
u32 mode)
}
*cs++ = cmd;
- *cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
+ *cs++ = LRC_PPHWSP_SCRATCH_ADDR;
*cs++ = 0; /* upper addr */
*cs++ = 0; /* value */
intel_ring_advance(request, cs);
@@ -3063,10 +3057,6 @@ static int gen8_emit_flush(struct i915_request *request,
u32 mode)
static int gen8_emit_flush_render(struct i915_request *request,
u32 mode)
{
- struct intel_engine_cs *engine = request->engine;
- u32 scratch_addr =
- intel_gt_scratch_offset(engine->gt,
- INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
bool vf_flush_wa = false, dc_flush_wa = false;
u32 *cs, flags = 0;
int len;
@@ -3088,7 +3078,7 @@ static int gen8_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
flags |= PIPE_CONTROL_QW_WRITE;
- flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
+ flags |= PIPE_CONTROL_STORE_DATA_INDEX;
/*
* On GEN9: before VF_CACHE_INVALIDATE we need to emit a NULL
@@ -3121,7 +3111,7 @@ static int gen8_emit_flush_render(struct i915_request
*request,
cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_DC_FLUSH_ENABLE,
0);
- cs = gen8_emit_pipe_control(cs, flags, scratch_addr);
+ cs = gen8_emit_pipe_control(cs, flags, LRC_PPHWSP_SCRATCH_ADDR);
if (dc_flush_wa)
cs = gen8_emit_pipe_control(cs, PIPE_CONTROL_CS_STALL, 0);
@@ -3134,11 +3124,6 @@ static int gen8_emit_flush_render(struct i915_request
*request,
static int gen11_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 *cs;
u32 flags = 0;
@@ -3151,13 +3136,13 @@ static int gen11_emit_flush_render(struct i915_request
*request,
flags |= PIPE_CONTROL_DC_FLUS
[Intel-gfx] [CI 3/3] drm/i915: Adjust length of MI_LOAD_REGISTER_REG
From: Michał Winiarski Default length value of MI_LOAD_REGISTER_REG is 1. Also move it out of cmd-parser-only registers since we're going to use it in i915. Signed-off-by: Michał Winiarski Cc: Chris Wilson Cc: Jani Nikula Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h index f78b13d74e17..9211b1ad401b 100644 --- a/drivers/gpu/drm/i915/gt/intel_gpu_commands.h +++ b/drivers/gpu/drm/i915/gt/intel_gpu_commands.h @@ -152,6 +152,7 @@ #define MI_FLUSH_DW_USE_PPGTT(0<<2) #define MI_LOAD_REGISTER_MEM MI_INSTR(0x29, 1) #define MI_LOAD_REGISTER_MEM_GEN8 MI_INSTR(0x29, 2) +#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 1) #define MI_BATCH_BUFFERMI_INSTR(0x30, 1) #define MI_BATCH_NON_SECURE (1) /* for snb/ivb/vlv this also means "batch in ppgtt" when ppgtt is enabled. */ @@ -256,7 +257,6 @@ #define MI_CLFLUSH MI_INSTR(0x27, 0) #define MI_REPORT_PERF_COUNTMI_INSTR(0x28, 0) #define MI_REPORT_PERF_COUNT_GGTT (1<<0) -#define MI_LOAD_REGISTER_REGMI_INSTR(0x2A, 0) #define MI_RS_STORE_DATA_IMMMI_INSTR(0x2B, 0) #define MI_LOAD_URB_MEM MI_INSTR(0x2C, 0) #define MI_STORE_URB_MEMMI_INSTR(0x2D, 0) -- 2.23.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: Don't use scratch in WA batch.
Quoting Michał Winiarski (2019-09-26 11:06:34)
> We're currently doing one workaround where we're using scratch as a
> temporary storage place, while we're overwriting the value of one
> register with some known constant value in order to perform a
> workaround.
> While we could just do similar thing with CS_GPR register
> and MI_LOAD_REGISTER_REG instead of scratch, since we would use CS_GPR
> anyways, let's just drop the constant values and do the bitops using
> MI_MATH.
>
> Signed-off-by: Michał Winiarski
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_engine.h | 53
> drivers/gpu/drm/i915/gt/intel_gt_types.h | 3 --
> drivers/gpu/drm/i915/gt/intel_lrc.c | 27 +++-
> 3 files changed, 58 insertions(+), 25 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
> b/drivers/gpu/drm/i915/gt/intel_engine.h
> index d3c6993f4f46..2dfe0b23af1d 100644
> --- a/drivers/gpu/drm/i915/gt/intel_engine.h
> +++ b/drivers/gpu/drm/i915/gt/intel_engine.h
> @@ -400,6 +400,59 @@ gen8_emit_ggtt_write(u32 *cs, u32 value, u32 gtt_offset,
> u32 flags)
> return cs;
> }
>
> +/*
> + * We're using CS_GPR registers for the MI_MATH ops.
> + * Note that user contexts are free to use those registers, which means that
> we
> + * should only use this this function during context initialization, before
> + * context restore (WA batch) or inside i915-owned contexts.
> + */
> +static inline u32 *
> +gen8_emit_bitop_reg_mask(struct intel_engine_cs *engine,
> +u32 *cs, u32 op, i915_reg_t reg, u32 mask)
Useful, we had discussed using MI_MATH to perform rmw for our
workarounds.
> +{
> + const u32 base = engine->mmio_base;
> +
> + GEM_BUG_ON(op != MI_MATH_OR && op != MI_MATH_AND);
> +
> + *cs++ = MI_LOAD_REGISTER_REG;
> + *cs++ = i915_mmio_reg_offset(reg);
> + *cs++ = i915_mmio_reg_offset(GEN8_RING_CS_GPR(base, 0));
> + *cs++ = MI_NOOP;
> +
> + *cs++ = MI_LOAD_REGISTER_IMM(1);
> + *cs++ = i915_mmio_reg_offset(GEN8_RING_CS_GPR(base, 1));
> + *cs++ = mask;
> + *cs++ = MI_NOOP;
> +
> + *cs++ = MI_MATH(4);
> + *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCA, MI_MATH_REG(0));
> + *cs++ = MI_MATH_LOAD(MI_MATH_REG_SRCB, MI_MATH_REG(1));
> + *cs++ = op;
> + *cs++ = MI_MATH_STORE(MI_MATH_REG(0), MI_MATH_REG_ACCU);
> + *cs++ = MI_NOOP;
> +
> + *cs++ = MI_LOAD_REGISTER_REG;
> + *cs++ = i915_mmio_reg_offset(GEN8_RING_CS_GPR(base, 0));
> + *cs++ = i915_mmio_reg_offset(reg);
> + *cs++ = MI_NOOP;
4 nicely paired redundant MI_NOOP. Can be removed, leaving the packet
still oword aligned.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 21/27] drm/i915: Move context management under GEM
On 25/09/2019 11:01, Chris Wilson wrote:
Keep track of the GEM contexts underneath i915->gem.contexts and assign
them their own lock for the purposes of list management.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 155 +++---
drivers/gpu/drm/i915/gem/i915_gem_context.h | 4 +-
.../gpu/drm/i915/gem/i915_gem_context_types.h | 2 +-
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 2 +-
drivers/gpu/drm/i915/gem/i915_gem_userptr.c | 2 +-
.../gpu/drm/i915/gem/selftests/huge_pages.c | 12 +-
.../drm/i915/gem/selftests/i915_gem_context.c | 122 ++
.../gpu/drm/i915/gem/selftests/mock_context.c | 4 +-
drivers/gpu/drm/i915/gt/intel_context.c | 8 +-
drivers/gpu/drm/i915/gt/selftest_context.c| 24 +--
drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 19 +--
drivers/gpu/drm/i915/gt/selftest_lrc.c| 4 +-
.../gpu/drm/i915/gt/selftest_workarounds.c| 10 +-
drivers/gpu/drm/i915/gvt/scheduler.c | 20 +--
drivers/gpu/drm/i915/i915_debugfs.c | 50 +++---
drivers/gpu/drm/i915/i915_drv.c | 2 -
drivers/gpu/drm/i915/i915_drv.h | 27 +--
drivers/gpu/drm/i915/i915_gem.c | 10 +-
drivers/gpu/drm/i915/i915_gem_gtt.c | 4 +-
drivers/gpu/drm/i915/i915_perf.c | 24 ++-
drivers/gpu/drm/i915/i915_sysfs.c | 77 -
drivers/gpu/drm/i915/i915_trace.h | 2 +-
drivers/gpu/drm/i915/selftests/i915_gem.c | 8 -
.../gpu/drm/i915/selftests/i915_gem_evict.c | 3 -
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 4 +-
drivers/gpu/drm/i915/selftests/i915_request.c | 11 +-
drivers/gpu/drm/i915/selftests/i915_vma.c | 5 +-
.../gpu/drm/i915/selftests/mock_gem_device.c | 6 +-
28 files changed, 272 insertions(+), 349 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 4e59b809d901..a77f439358d7 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -219,9 +219,12 @@ static struct i915_gem_engines *default_engines(struct
i915_gem_context *ctx)
static void i915_gem_context_free(struct i915_gem_context *ctx)
{
- lockdep_assert_held(&ctx->i915->drm.struct_mutex);
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
+ spin_lock(&ctx->i915->gem.contexts.lock);
+ list_del(&ctx->link);
+ spin_unlock(&ctx->i915->gem.contexts.lock);
+
free_engines(rcu_access_pointer(ctx->engines));
mutex_destroy(&ctx->engines_mutex);
@@ -231,56 +234,40 @@ static void i915_gem_context_free(struct i915_gem_context *ctx)
kfree(ctx->name);
put_pid(ctx->pid);
- list_del(&ctx->link);
mutex_destroy(&ctx->mutex);
kfree_rcu(ctx, rcu);
}
-static void contexts_free(struct drm_i915_private *i915)
+static void contexts_free_all(struct llist_node *list)
{
- struct llist_node *freed = llist_del_all(&i915->contexts.free_list);
struct i915_gem_context *ctx, *cn;
- lockdep_assert_held(&i915->drm.struct_mutex);
-
- llist_for_each_entry_safe(ctx, cn, freed, free_link)
+ llist_for_each_entry_safe(ctx, cn, list, free_link)
i915_gem_context_free(ctx);
}
-static void contexts_free_first(struct drm_i915_private *i915)
+static void contexts_flush_free(struct i915_gem_contexts *gc)
{
- struct i915_gem_context *ctx;
- struct llist_node *freed;
-
- lockdep_assert_held(&i915->drm.struct_mutex);
-
- freed = llist_del_first(&i915->contexts.free_list);
- if (!freed)
- return;
-
- ctx = container_of(freed, typeof(*ctx), free_link);
- i915_gem_context_free(ctx);
+ contexts_free_all(llist_del_all(&gc->free_list));
}
static void contexts_free_worker(struct work_struct *work)
{
- struct drm_i915_private *i915 =
- container_of(work, typeof(*i915), contexts.free_work);
+ struct i915_gem_contexts *gc =
+ container_of(work, typeof(*gc), free_work);
- mutex_lock(&i915->drm.struct_mutex);
- contexts_free(i915);
- mutex_unlock(&i915->drm.struct_mutex);
+ contexts_flush_free(gc);
}
void i915_gem_context_release(struct kref *ref)
{
struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
- struct drm_i915_private *i915 = ctx->i915;
+ struct i915_gem_contexts *gc = &ctx->i915->gem.contexts;
trace_i915_context_free(ctx);
- if (llist_add(&ctx->free_link, &i915->contexts.free_list))
- queue_work(i915->wq, &i915->contexts.free_work);
+ if (llist_add(&ctx->free_link, &gc->free_list))
+ queue_work(ctx->i915->wq, &gc->free_work);
At first I thought gc was some sort of garbage collection list. But it
is a GEM contexts list. :) This hunk l
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/tgl: Fix doc not corresponding to code (rev2)
== Series Details ==
Series: drm/i915/tgl: Fix doc not corresponding to code (rev2)
URL : https://patchwork.freedesktop.org/series/67088/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14555
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/
Known issues
Here are the changes found in Patchwork_14555 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_gem_contexts:
- fi-kbl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#111519])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-guc/igt@i915_selftest@live_gem_contexts.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/fi-kbl-guc/igt@i915_selftest@live_gem_contexts.html
Possible fixes
* igt@kms_chamelium@hdmi-edid-read:
- {fi-icl-u4}:[FAIL][3] ([fdo#111045]) -> [PASS][4] +1 similar issue
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/fi-icl-u4/igt@kms_chamel...@hdmi-edid-read.html
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][5] ([fdo#109483]) -> [PASS][6]
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111049]: https://bugs.freedesktop.org/show_bug.cgi?id=111049
[fdo#111519]: https://bugs.freedesktop.org/show_bug.cgi?id=111519
[fdo#111600]: https://bugs.freedesktop.org/show_bug.cgi?id=111600
Participating hosts (50 -> 44)
--
Additional (3): fi-kbl-soraka fi-hsw-4770r fi-icl-u3
Missing(9): fi-ilk-m540 fi-hsw-4200u fi-bsw-n3050 fi-byt-squawks
fi-bsw-cyan fi-icl-y fi-byt-n2820 fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14555
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14555: 9be913c6e5fcbb7fef7cb156fdd0ca7adcd41041 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
9be913c6e5fc drm/i915/tgl: Fix doc not corresponding to code
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14555/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
Moving our primary irq handler to a RT thread incurs an extra 1us delay
in process interrupts. This is most notice in waking up client threads,
where it adds about 20% of extra latency. It also imposes a delay in
feeding the GPU, an extra 1us before signaling secondary engines and
extra latency in resubmitting work to keep the GPU busy. The latter case
is insignificant as the latency hidden by the active GPU, and
preempt-to-busy ensures that no extra latency is incurred for
preemption.
The benefit is that we reduced the impact on the rest of the system, the
cycletest shows a reduction from 5us mean latency to 2us, with the
maximum observed latency (in a 2 minute window) reduced by over 160us.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Clark Williams
Cc: Sebastian Andrzej Siewior
---
Note this should need the fixes in
20190926105644.16703-2-bige...@linutronix.de, by itself this should be a
test vehicle to exercise that patch!
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc83f094065a..f3df7714a3f3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private *dev_priv)
intel_irq_reset(dev_priv);
- ret = request_irq(irq, intel_irq_handler(dev_priv),
- IRQF_SHARED, DRIVER_NAME, dev_priv);
+ ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv),
+ IRQF_SHARED, DRIVER_NAME, dev_priv);
if (ret < 0) {
dev_priv->drm.irq_enabled = false;
return ret;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Update references to previously renamed files
Update references to reservation.c and reservation.h since these files have been renamed to dma-resv.c and dma-resv.h respectively. Cc: Christian König Link: https://patchwork.freedesktop.org/patch/323401/?series=65037&rev=1 Signed-off-by: Anna Karas --- Documentation/driver-api/dma-buf.rst | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/driver-api/dma-buf.rst b/Documentation/driver-api/dma-buf.rst index b541e97c7ab1..c78db28519f7 100644 --- a/Documentation/driver-api/dma-buf.rst +++ b/Documentation/driver-api/dma-buf.rst @@ -118,13 +118,13 @@ Kernel Functions and Structures Reference Reservation Objects --- -.. kernel-doc:: drivers/dma-buf/reservation.c +.. kernel-doc:: drivers/dma-buf/dma-resv.c :doc: Reservation Object Overview -.. kernel-doc:: drivers/dma-buf/reservation.c +.. kernel-doc:: drivers/dma-buf/dma-resv.c :export: -.. kernel-doc:: include/linux/reservation.h +.. kernel-doc:: include/linux/dma-resv.h :internal: DMA Fences -- 2.19.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Exercise concurrent submission to all engines
== Series Details == Series: drm/i915/selftests: Exercise concurrent submission to all engines URL : https://patchwork.freedesktop.org/series/67237/ State : success == Summary == CI Bug Log - changes from CI_DRM_6958_full -> Patchwork_14537_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14537_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@reset-stress: - shard-snb: [PASS][1] -> [FAIL][2] ([fdo#109661]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb6/igt@gem_...@reset-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-snb4/igt@gem_...@reset-stress.html * igt@gem_exec_schedule@preempt-contexts-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#111325]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb3/igt@gem_exec_sched...@preempt-contexts-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-iclb1/igt@gem_exec_sched...@preempt-contexts-bsd.html * igt@gem_pwrite@small-cpu-backwards: - shard-apl: [PASS][5] -> [INCOMPLETE][6] ([fdo#103927]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-apl7/igt@gem_pwr...@small-cpu-backwards.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-apl3/igt@gem_pwr...@small-cpu-backwards.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108] / [fdo#107807]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl3/igt@i915_pm_...@system-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-skl4/igt@i915_pm_...@system-suspend.html * igt@kms_frontbuffer_tracking@fbc-stridechange: - shard-iclb: [PASS][9] -> [FAIL][10] ([fdo#103167]) +6 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb5/igt@kms_frontbuffer_track...@fbc-stridechange.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-iclb6/igt@kms_frontbuffer_track...@fbc-stridechange.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-apl7/igt@kms_frontbuffer_track...@fbc-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-apl1/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_pipe_crc_basic@hang-read-crc-pipe-a: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#103191]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl9/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-skl1/igt@kms_pipe_crc_ba...@hang-read-crc-pipe-a.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-c: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([fdo#108566]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-kbl3/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-c.html * igt@kms_plane@plane-panning-bottom-right-suspend-pipe-c-planes: - shard-skl: [PASS][17] -> [INCOMPLETE][18] ([fdo#104108]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl7/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-skl6/igt@kms_pl...@plane-panning-bottom-right-suspend-pipe-c-planes.html * igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) +2 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-skl3/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html * igt@perf@blocking: - shard-skl: [PASS][21] -> [FAIL][22] ([fdo#110728]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl7/igt@p...@blocking.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-skl1/igt@p...@blocking.html * igt@perf_pmu@enable-race-vcs0: - shard-iclb: [PASS][23] -> [INCOMPLETE][24] ([fdo#107713]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb5/igt@perf_...@enable-race-vcs0.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14537/shard-iclb7/igt@perf_...@enable-race-vcs0.html * igt@prime_busy@hang-bsd2: - shard-iclb: [PASS][25] -> [SKIP][26] ([fdo#109276]) +7 similar issues [25]: https:
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
On 26/09/2019 15:25, Chris Wilson wrote:
Moving our primary irq handler to a RT thread incurs an extra 1us delay
in process interrupts. This is most notice in waking up client threads,
where it adds about 20% of extra latency. It also imposes a delay in
feeding the GPU, an extra 1us before signaling secondary engines and
extra latency in resubmitting work to keep the GPU busy. The latter case
is insignificant as the latency hidden by the active GPU, and
preempt-to-busy ensures that no extra latency is incurred for
preemption.
The benefit is that we reduced the impact on the rest of the system, the
cycletest shows a reduction from 5us mean latency to 2us, with the
maximum observed latency (in a 2 minute window) reduced by over 160us.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Clark Williams
Cc: Sebastian Andrzej Siewior
---
Note this should need the fixes in
20190926105644.16703-2-bige...@linutronix.de, by itself this should be a
test vehicle to exercise that patch!
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc83f094065a..f3df7714a3f3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private *dev_priv)
intel_irq_reset(dev_priv);
- ret = request_irq(irq, intel_irq_handler(dev_priv),
- IRQF_SHARED, DRIVER_NAME, dev_priv);
+ ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv),
+ IRQF_SHARED, DRIVER_NAME, dev_priv);
if (ret < 0) {
dev_priv->drm.irq_enabled = false;
return ret;
Two questions:
1. Should we split out the master_ctl handling into the fast handler?
Although can we pass anything from the fast to threaded handler? If not
we'd have to re-read the master_ctl from the threaded handler.
2. What about our tasklets - with threaded irqs we don't need them any
more, right? So in this case they just add additional latency.
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Add feature flag for platforms with DRAM
On Thu, 2019-09-26 at 15:36 +0300, Ville Syrjälä wrote:
> On Wed, Sep 25, 2019 at 02:07:27PM -0700, Stuart Summers wrote:
>
> No commit message.
I'll add one here, should have caught this before posting, sorry.
>
> > Signed-off-by: Stuart Summers
> > ---
> > drivers/gpu/drm/i915/i915_drv.c | 2 +-
> > drivers/gpu/drm/i915/i915_drv.h | 2 ++
> > drivers/gpu/drm/i915/i915_pci.c | 3 ++-
> > drivers/gpu/drm/i915/intel_device_info.h | 1 +
> > 4 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.c
> > b/drivers/gpu/drm/i915/i915_drv.c
> > index a9ee73b61f4d..552ba7607e9a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.c
> > +++ b/drivers/gpu/drm/i915/i915_drv.c
> > @@ -1128,7 +1128,7 @@ intel_get_dram_info(struct drm_i915_private
> > *dev_priv)
> > */
> > dram_info->is_16gb_dimm = !IS_GEN9_LP(dev_priv);
> >
> > - if (INTEL_GEN(dev_priv) < 9)
> > + if (!HAS_DRAM(dev_priv))
> > return;
>
> As opposed to what? SRAM?
Hm.. perhaps this could be named better? I was hoping we could more
clearly identify platforms which don't have these dram structures
available through MMIO. Do you have another suggestion?
Thanks,
Stuart
>
> >
> > if (IS_GEN9_LP(dev_priv))
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index fcf7423075ef..e82ca38be59e 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -2151,6 +2151,8 @@ IS_SUBPLATFORM(const struct drm_i915_private
> > *i915,
> >
> > #define HAS_DP_MST(dev_priv) (INTEL_INFO(dev_priv)-
> > >display.has_dp_mst)
> >
> > +#define HAS_DRAM(dev_priv) (INTEL_INFO(dev_priv)->has_dram)
> > +
> > #define HAS_DDI(dev_priv) (INTEL_INFO(dev_priv)-
> > >display.has_ddi)
> > #define HAS_FPGA_DBG_UNCLAIMED(dev_priv) (INTEL_INFO(dev_priv)-
> > >has_fpga_dbg)
> > #define HAS_PSR(dev_priv) (INTEL_INFO(dev_priv)-
> > >display.has_psr)
> > diff --git a/drivers/gpu/drm/i915/i915_pci.c
> > b/drivers/gpu/drm/i915/i915_pci.c
> > index ea53dfe2fba0..98d7e07dba6a 100644
> > --- a/drivers/gpu/drm/i915/i915_pci.c
> > +++ b/drivers/gpu/drm/i915/i915_pci.c
> > @@ -602,7 +602,8 @@ static const struct intel_device_info
> > intel_cherryview_info = {
> > .display.has_csr = 1, \
> > .has_gt_uc = 1, \
> > .display.has_ipc = 1, \
> > - .ddb_size = 896
> > + .ddb_size = 896, \
> > + .has_dram = 1
> >
> > #define SKL_PLATFORM \
> > GEN9_FEATURES, \
> > diff --git a/drivers/gpu/drm/i915/intel_device_info.h
> > b/drivers/gpu/drm/i915/intel_device_info.h
> > index 0cdc2465534b..c9c858100ea3 100644
> > --- a/drivers/gpu/drm/i915/intel_device_info.h
> > +++ b/drivers/gpu/drm/i915/intel_device_info.h
> > @@ -109,6 +109,7 @@ enum intel_ppgtt_type {
> > func(require_force_probe); \
> > /* Keep has_* in alphabetical order */ \
> > func(has_64bit_reloc); \
> > + func(has_dram); \
> > func(gpu_reset_clobbers_display); \
> > func(has_reset_engine); \
> > func(has_fpga_dbg); \
> > --
> > 2.22.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>
>
smime.p7s
Description: S/MIME cryptographic signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Define explicit wedged on init reset state
== Series Details ==
Series: series starting with [CI,1/3] drm/i915: Define explicit wedged on init
reset state
URL : https://patchwork.freedesktop.org/series/67289/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14556
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/
Known issues
Here are the changes found in Patchwork_14556 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_create@basic-files:
- fi-icl-u2: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] /
[fdo#109100])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/fi-icl-u2/igt@gem_ctx_cre...@basic-files.html
- fi-apl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#103927])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-apl-guc/igt@gem_ctx_cre...@basic-files.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/fi-apl-guc/igt@gem_ctx_cre...@basic-files.html
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: [PASS][5] -> [INCOMPLETE][6] ([fdo#107718])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/fi-blb-e6850/igt@gem_exec_susp...@basic-s3.html
Warnings
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: [FAIL][7] ([fdo#111045] / [fdo#111096]) -> [FAIL][8]
([fdo#111407])
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#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#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100
[fdo#110566]: https://bugs.freedesktop.org/show_bug.cgi?id=110566
[fdo#111045]: https://bugs.freedesktop.org/show_bug.cgi?id=111045
[fdo#111096]: https://bugs.freedesktop.org/show_bug.cgi?id=111096
[fdo#111381]: https://bugs.freedesktop.org/show_bug.cgi?id=111381
[fdo#111407]: https://bugs.freedesktop.org/show_bug.cgi?id=111407
Participating hosts (50 -> 44)
--
Additional (3): fi-kbl-soraka fi-hsw-4770r fi-icl-u3
Missing(9): fi-ilk-m540 fi-tgl-u2 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14556
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14556: e92ad4e942314b836922d003f34e13f0fcca9492 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
e92ad4e94231 drm/i915: Adjust length of MI_LOAD_REGISTER_REG
e63a3d6f8435 drm/i915/execlists: Use per-process HWSP as scratch
8e88d1917684 drm/i915: Define explicit wedged on init reset state
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14556/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 1/7] drm/i915/tgl: Add DC3CO required register and bits
Adding following definition to i915_reg.h
1. DC_STATE_EN register DC3CO bit fields and masks.
DC3CO enable bit will be used by driver to make DC3CO
ready for DMC f/w and status bit will be used as DC3CO
entry status.
2. Transcoder EXITLINE register and its bit fields and mask.
Transcoder EXITLINE enable bit represents PSR2 idle frame
reset should be applied at exit line and exitlines mask
represent required number of scanlines at which DC3CO
exit happens.
B.Specs:49196
v1: Use of REG_BIT and using extra space for EXITLINE_ macro
definition. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_reg.h | 8
1 file changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e752de9470bd..3ee9720af207 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -4140,6 +4140,7 @@ enum {
#define _VTOTAL_A 0x6000c
#define _VBLANK_A 0x60010
#define _VSYNC_A 0x60014
+#define _EXITLINE_A0x60018
#define _PIPEASRC 0x6001c
#define _BCLRPAT_A 0x60020
#define _VSYNCSHIFT_A 0x60028
@@ -4186,11 +4187,16 @@ enum {
#define VTOTAL(trans) _MMIO_TRANS2(trans, _VTOTAL_A)
#define VBLANK(trans) _MMIO_TRANS2(trans, _VBLANK_A)
#define VSYNC(trans) _MMIO_TRANS2(trans, _VSYNC_A)
+#define EXITLINE(trans)_MMIO_TRANS2(trans, _EXITLINE_A)
#define BCLRPAT(trans) _MMIO_TRANS2(trans, _BCLRPAT_A)
#define VSYNCSHIFT(trans) _MMIO_TRANS2(trans, _VSYNCSHIFT_A)
#define PIPESRC(trans) _MMIO_TRANS2(trans, _PIPEASRC)
#define PIPE_MULT(trans) _MMIO_TRANS2(trans, _PIPE_MULT_A)
+#define EXITLINE_ENABLE REG_BIT(31)
+#define EXITLINE_MASKREG_GENMASK(12, 0)
+#define EXITLINE_SHIFT 0
+
/*
* HSW+ eDP PSR registers
*
@@ -10292,6 +10298,8 @@ enum skl_power_gate {
/* GEN9 DC */
#define DC_STATE_EN_MMIO(0x45504)
#define DC_STATE_DISABLE 0
+#define DC_STATE_EN_DC3CO REG_BIT(30)
+#define DC_STATE_DC3CO_STATUS REG_BIT(29)
#define DC_STATE_EN_UPTO_DC5 (1 << 0)
#define DC_STATE_EN_DC9 (1 << 3)
#define DC_STATE_EN_UPTO_DC6 (2 << 0)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 2/7] drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask
Enable dc3co state in enable_dc module param and add dc3co
enable mask to allowed_dc_mask and gen9_dc_mask.
v1: Adding enable_dc=3,4 options to enable DC3CO with DC5 and DC6
independently. [Animesh]
v2: Using a switch statement for cleaner code. [Animesh]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Reviewed-by: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 29 +++
drivers/gpu/drm/i915/i915_params.c| 3 +-
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index f1186bc23542..0b685c517bcb 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -711,7 +711,11 @@ static u32 gen9_dc_mask(struct drm_i915_private *dev_priv)
u32 mask;
mask = DC_STATE_EN_UPTO_DC5;
- if (INTEL_GEN(dev_priv) >= 11)
+
+ if (INTEL_GEN(dev_priv) >= 12)
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6
+ | DC_STATE_EN_DC9;
+ else if (IS_GEN(dev_priv, 11))
mask |= DC_STATE_EN_UPTO_DC6 | DC_STATE_EN_DC9;
else if (IS_GEN9_LP(dev_priv))
mask |= DC_STATE_EN_DC9;
@@ -3940,14 +3944,17 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
int requested_dc;
int max_dc;
- if (INTEL_GEN(dev_priv) >= 11) {
- max_dc = 2;
+ if (INTEL_GEN(dev_priv) >= 12) {
+ max_dc = 4;
/*
* DC9 has a separate HW flow from the rest of the DC states,
* not depending on the DMC firmware. It's needed by system
* suspend/resume, so allow it unconditionally.
*/
mask = DC_STATE_EN_DC9;
+ } else if (IS_GEN(dev_priv, 11)) {
+ max_dc = 2;
+ mask = DC_STATE_EN_DC9;
} else if (IS_GEN(dev_priv, 10) || IS_GEN9_BC(dev_priv)) {
max_dc = 2;
mask = 0;
@@ -3966,7 +3973,7 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = enable_dc;
} else if (enable_dc == -1) {
requested_dc = max_dc;
- } else if (enable_dc > max_dc && enable_dc <= 2) {
+ } else if (enable_dc > max_dc && enable_dc <= 4) {
DRM_DEBUG_KMS("Adjusting requested max DC state (%d->%d)\n",
enable_dc, max_dc);
requested_dc = max_dc;
@@ -3975,10 +3982,20 @@ static u32 get_allowed_dc_mask(const struct
drm_i915_private *dev_priv,
requested_dc = max_dc;
}
- if (requested_dc > 1)
+ switch (requested_dc) {
+ case 4:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC6;
+ break;
+ case 3:
+ mask |= DC_STATE_EN_DC3CO | DC_STATE_EN_UPTO_DC5;
+ break;
+ case 2:
mask |= DC_STATE_EN_UPTO_DC6;
- if (requested_dc > 0)
+ break;
+ case 1:
mask |= DC_STATE_EN_UPTO_DC5;
+ break;
+ }
DRM_DEBUG_KMS("Allowed DC state mask %02x\n", mask);
diff --git a/drivers/gpu/drm/i915/i915_params.c
b/drivers/gpu/drm/i915/i915_params.c
index 296452f9efe4..4f1806f65040 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -46,7 +46,8 @@ i915_param_named(modeset, int, 0400,
i915_param_named_unsafe(enable_dc, int, 0400,
"Enable power-saving display C-states. "
- "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6)");
+ "(-1=auto [default]; 0=disable; 1=up to DC5; 2=up to DC6; "
+ "3=up to DC5 with DC3CO; 4=up to DC6 with DC3CO)");
i915_param_named_unsafe(enable_fbc, int, 0600,
"Enable frame buffer compression for power savings "
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 3/7] drm/i915/tgl: Enable DC3CO state in "DC Off" power well
Add target_dc_state and tgl_set_target_dc_state() API
in order to enable DC3CO state with existing DC states.
target_dc_state will enable/disable the desired DC state in
DC_STATE_EN reg when "DC Off" power well gets disable/enable.
v2: commit log improvement.
v3: Used intel_wait_for_register to wait for DC3CO exit. [Imre]
Used gen9_set_dc_state() to allow/disallow DC3CO. [Imre]
Moved transcoder psr2 exit line enablement from tgl_allow_dc3co()
to a appropriate place haswell_crtc_enable(). [Imre]
Changed the DC3CO power well enabled call back logic as
recommended in review comments. [Imre]
v4: Used wait_for_us() instead of intel_wait_for_reg(). [Imre (IRC)]
v5: using udelay() instead of waiting for DC3CO exit status.
v6: Fixed minor unwanted change.
v7: Removed DC3CO powerwell and POWER_DOMAIN_VIDEO.
v8: Uniform checks by using only target_dc_state instead of allowed_dc_mask
in "DC off" power well callback. [Imre]
Adding "DC off" power well id to older platforms. [Imre]
Removed psr2_deep_sleep flag from tgl_set_target_dc_state. [Imre]
v9: Used switch case for target DC state in
gen9_dc_off_power_well_disable(), checking DC3CO state against
allowed DC mask, using WARN_ON() in
tgl_set_target_dc_state(). [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 110 --
.../drm/i915/display/intel_display_power.h| 2 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
3 files changed, 104 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0b685c517bcb..9f787556f80d 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -785,6 +785,38 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+static void
+allowed_dc_mask_to_target_dc_state(struct drm_i915_private *dev_priv)
+{
+ if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC6)
+ dev_priv->csr.target_dc_state = DC_STATE_EN_UPTO_DC6;
+ else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
+ dev_priv->csr.target_dc_state = DC_STATE_EN_UPTO_DC5;
+ else
+ dev_priv->csr.target_dc_state = DC_STATE_DISABLE;
+}
+
+static void tgl_enable_dc3co(struct drm_i915_private *dev_priv)
+{
+ DRM_DEBUG_KMS("Enabling DC3CO\n");
+ gen9_set_dc_state(dev_priv, DC_STATE_EN_DC3CO);
+}
+
+static void tgl_disable_dc3co(struct drm_i915_private *dev_priv)
+{
+ u32 val;
+
+ DRM_DEBUG_KMS("Disabling DC3CO\n");
+ val = I915_READ(DC_STATE_EN);
+ val &= ~DC_STATE_DC3CO_STATUS;
+ I915_WRITE(DC_STATE_EN, val);
+ gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
+ /*
+* Delay of 200us DC3CO Exit time B.Spec 49196
+*/
+ usleep_range(200, 210);
+}
+
static void bxt_enable_dc9(struct drm_i915_private *dev_priv)
{
assert_can_enable_dc9(dev_priv);
@@ -952,7 +984,8 @@ static void bxt_verify_ddi_phy_power_wells(struct
drm_i915_private *dev_priv)
static bool gen9_dc_off_power_well_enabled(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- return (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0;
+ return ((I915_READ(DC_STATE_EN) & DC_STATE_EN_DC3CO) == 0 &&
+ (I915_READ(DC_STATE_EN) & DC_STATE_EN_UPTO_DC5_DC6_MASK) == 0);
}
static void gen9_assert_dbuf_enabled(struct drm_i915_private *dev_priv)
@@ -968,6 +1001,11 @@ static void gen9_disable_dc_states(struct
drm_i915_private *dev_priv)
{
struct intel_cdclk_state cdclk_state = {};
+ if (dev_priv->csr.target_dc_state == DC_STATE_EN_DC3CO) {
+ tgl_disable_dc3co(dev_priv);
+ return;
+ }
+
gen9_set_dc_state(dev_priv, DC_STATE_DISABLE);
dev_priv->display.get_cdclk(dev_priv, &cdclk_state);
@@ -1000,10 +1038,63 @@ static void gen9_dc_off_power_well_disable(struct
drm_i915_private *dev_priv,
if (!dev_priv->csr.dmc_payload)
return;
- if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC6)
+ switch (dev_priv->csr.target_dc_state) {
+ case DC_STATE_EN_DC3CO:
+ tgl_enable_dc3co(dev_priv);
+ break;
+ case DC_STATE_EN_UPTO_DC6:
skl_enable_dc6(dev_priv);
- else if (dev_priv->csr.allowed_dc_mask & DC_STATE_EN_UPTO_DC5)
+ break;
+ case DC_STATE_EN_UPTO_DC5:
gen9_enable_dc5(dev_priv);
+ break;
+ }
+}
+
+void tgl_set_target_dc_state(struct drm_i915_private *dev_priv, u32 state)
+{
+ struct i915_power_well *power_well;
+ bool dc_off_enabled;
+ struct i915_power_domains *power_
[Intel-gfx] [PATCH v9 5/7] drm/i915/tgl: DC3CO PSR2 helper
Disallow DC3CO state before PSR2 exit.
Store dc3co_exitline from crtc state to psr dev_priv
structure to use it easily whenever it requires.
v1: Moved calling of tgl_enable_psr2_transcoder_exitline() to
intel_psr_enable(). [Imre]
v2: Moved tgl_psr2_deep_sleep_enable/disable function to
the patches where they are getting used and used dc3co_exitline
check instead of TGL check. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_psr.c | 8
drivers/gpu/drm/i915/i915_drv.h | 1 +
2 files changed, 9 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_psr.c
b/drivers/gpu/drm/i915/display/intel_psr.c
index b3c7eef53bf3..bf0b741d3243 100644
--- a/drivers/gpu/drm/i915/display/intel_psr.c
+++ b/drivers/gpu/drm/i915/display/intel_psr.c
@@ -534,6 +534,12 @@ transcoder_has_psr2(struct drm_i915_private *dev_priv,
enum transcoder trans)
return trans == TRANSCODER_EDP;
}
+static void tgl_disallow_dc3co_on_psr2_exit(struct drm_i915_private *dev_priv)
+{
+ if (!dev_priv->psr.dc3co_exitline)
+ return;
+}
+
static bool intel_psr2_config_valid(struct intel_dp *intel_dp,
struct intel_crtc_state *crtc_state)
{
@@ -746,6 +752,7 @@ static void intel_psr_enable_locked(struct drm_i915_private
*dev_priv,
dev_priv->psr.psr2_enabled = intel_psr2_enabled(dev_priv, crtc_state);
dev_priv->psr.busy_frontbuffer_bits = 0;
dev_priv->psr.pipe = to_intel_crtc(crtc_state->base.crtc)->pipe;
+ dev_priv->psr.dc3co_exitline = crtc_state->dc3co_exitline;
dev_priv->psr.transcoder = crtc_state->cpu_transcoder;
/*
@@ -829,6 +836,7 @@ static void intel_psr_exit(struct drm_i915_private
*dev_priv)
}
if (dev_priv->psr.psr2_enabled) {
+ tgl_disallow_dc3co_on_psr2_exit(dev_priv);
val = I915_READ(EDP_PSR2_CTL(dev_priv->psr.transcoder));
WARN_ON(!(val & EDP_PSR2_ENABLE));
val &= ~EDP_PSR2_ENABLE;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cddc98ea9965..c3aba078262f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -501,6 +501,7 @@ struct i915_psr {
bool sink_not_reliable;
bool irq_aux_error;
u16 su_x_granularity;
+ u32 dc3co_exitline;
};
#define QUIRK_LVDS_SSC_DISABLE (1<<1)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 6/7] drm/i915/tgl: switch between dc3co and dc5 based on display idleness
DC3CO is useful power state, when DMC detects PSR2 idle frame
while an active video playback, playing 30fps video on 60hz panel
is the classic example of this use case.
B.Specs:49196 has a restriction to enable DC3CO only for Video Playback.
It will be worthy to enable DC3CO after completion of each pageflip
and switch back to DC5 when display is idle because driver doesn't
differentiate between video playback and a normal pageflip.
We will use Frontbuffer flush call tgl_dc3co_flush() to enable DC3CO
state only for ORIGIN_FLIP flush call, because DC3CO state has primarily
targeted for VPB use case. We are not interested here for frontbuffer
invalidates calls because that triggers PSR2 exit, which will
explicitly disable DC3CO.
DC5 and DC6 saves more power, but can't be entered during video
playback because there are not enough idle frames in a row to meet
most PSR2 panel deep sleep entry requirement typically 4 frames.
As PSR2 existing implementation is using minimum 6 idle frames for
deep sleep, it is safer to enable DC5/6 after 6 idle frames
(By scheduling a delayed work of 6 idle frames, once DC3CO has been
enabled after a pageflip).
After manually waiting for 6 idle frames DC5/6 will be enabled and
PSR2 deep sleep idle frames will be restored to 6 idle frames, at this
point DMC will triggers DC5/6 once PSR2 enters to deep sleep after
6 idle frames.
In future when we will enable S/W PSR2 tracking, we can change the
PSR2 required deep sleep idle frames to 1 so DMC can trigger the
DC5/6 immediately after S/W manual waiting of 6 idle frames get
complete.
v2: calculated s/w state to switch over dc3co when there is an
update. [Imre]
Used cancel_delayed_work_sync() in order to avoid any race
with already scheduled delayed work. [Imre]
v3: Cancel_delayed_work_sync() may blocked the commit work.
hence dropping it, dc5_idle_thread() checks the valid wakeref before
putting the reference count, which avoids any chances of dropping
a zero wakeref. [Imre (IRC)]
v4: Used frontbuffer flush mechanism. [Imre]
v5: Used psr.pipe to extract frontbuffer busy bits. [Imre]
Used cancel_delayed_work_sync() in encoder disable path. [Imre]
Used mod_delayed_work() instead of cancelling and scheduling a
delayed work. [Imre]
Used psr.lock in tgl_dc5_idle_thread() to enable psr2 deep
sleep. [Imre]
Removed DC5_REQ_IDLE_FRAMES macro. [Imre]
v6: Inited the busy_frontbuffer_bits, used dc3co_exitline check instead
of TGL and dc3co allowed_dc_mask checks, used delayed_work_pending
with the psr lock and removed the psr2_deep_slp_disabled flag. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
.../drm/i915/display/intel_display_power.c| 84 +++
.../drm/i915/display/intel_display_power.h| 4 +
.../gpu/drm/i915/display/intel_frontbuffer.c | 1 +
drivers/gpu/drm/i915/display/intel_psr.c | 34
drivers/gpu/drm/i915/display/intel_psr.h | 2 +
drivers/gpu/drm/i915/i915_drv.h | 1 +
6 files changed, 126 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 84e4cfd95b43..00bb82e6a18f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -20,6 +20,7 @@
#include "intel_sideband.h"
#include "intel_tc.h"
#include "intel_pm.h"
+#include "intel_psr.h"
bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
enum i915_power_well_id power_well_id);
@@ -797,6 +798,9 @@ void tgl_clear_psr2_transcoder_exitline(const struct
intel_crtc_state *cstate)
val = I915_READ(EXITLINE(cstate->cpu_transcoder));
val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+
+ /* As psr2 encoder has disabled, cancel the dc5 idle delayed work */
+ cancel_delayed_work_sync(&dev_priv->csr.idle_work);
}
void tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
@@ -816,6 +820,19 @@ void tgl_set_psr2_transcoder_exitline(const struct
intel_crtc_state *cstate)
I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
}
+static u32 intel_get_frame_time_us(const struct intel_crtc_state *cstate)
+{
+ u32 frametime_us;
+
+ if (!cstate || !cstate->base.active)
+ return 0;
+
+ frametime_us = DIV_ROUND_UP(1000*1000,
+
drm_mode_vrefresh(&cstate->base.adjusted_mode));
+
+ return frametime_us;
+}
+
/*
* DC3CO requires to enable exitline and program DC3CO requires
* exit scanlines to TRANS_EXITLINE register, which should only
@@ -872,6 +889,72 @@ void tgl_dc3co_exitline_get_config(struct intel_crtc_state
*crtc_state)
crtc_state->dc3co_exitline = val & EXITLINE_MASK;
}
+/*
+ * When we will enable manual PSR2 S/W tracking i
[Intel-gfx] [PATCH v9 7/7] drm/i915/tgl: Add DC3CO counter in i915_dmc_info
Adding DC3CO counter in i915_dmc_info debugfs will be
useful for DC3CO validation.
DMC firmware uses DMC_DEBUG3 register as DC3CO counter
register on TGL, as per B.Specs DMC_DEBUG3 is general
purpose register.
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/i915_debugfs.c | 6 ++
drivers/gpu/drm/i915/i915_reg.h | 2 ++
2 files changed, 8 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index b5b449a88cf1..8a16bbd31212 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2407,6 +2407,12 @@ static int i915_dmc_info(struct seq_file *m, void
*unused)
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
CSR_VERSION_MINOR(csr->version));
+ /*
+* TGL DMC f/w uses DMC_DEBUG3 register for DC3CO counter.
+*/
+ if (IS_TIGERLAKE(dev_priv))
+ seq_printf(m, "DC3CO count: %d\n", I915_READ(DMC_DEBUG3));
+
if (INTEL_GEN(dev_priv) >= 12) {
dc5_reg = TGL_DMC_DEBUG_DC5_COUNT;
dc6_reg = TGL_DMC_DEBUG_DC6_COUNT;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 3ee9720af207..af810f6ed652 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7263,6 +7263,8 @@ enum {
#define TGL_DMC_DEBUG_DC5_COUNT_MMIO(0x101084)
#define TGL_DMC_DEBUG_DC6_COUNT_MMIO(0x101088)
+#define DMC_DEBUG3 _MMIO(0x101090)
+
/* interrupts */
#define DE_MASTER_IRQ_CONTROL (1 << 31)
#define DE_SPRITEB_FLIP_DONE(1 << 29)
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH RESEND v9 0/7] DC3CO Support for TGL
Resending V9 series after fixing CI warnings and CI IGT failures. v9 revision is a rework of series, which has fixed the review comments provided by Imre and added Animesh's RB on following two patches. 1.Add DC3CO required register and bits 2.Add DC3CO mask to allowed_dc_mask and gen9_dc_mask Anshuman Gupta (7): drm/i915/tgl: Add DC3CO required register and bits drm/i915/tgl: Add DC3CO mask to allowed_dc_mask and gen9_dc_mask drm/i915/tgl: Enable DC3CO state in "DC Off" power well drm/i915/tgl: Do modeset to enable and configure DC3CO exitline drm/i915/tgl: DC3CO PSR2 helper drm/i915/tgl: switch between dc3co and dc5 based on display idleness drm/i915/tgl: Add DC3CO counter in i915_dmc_info drivers/gpu/drm/i915/display/intel_ddi.c | 7 + drivers/gpu/drm/i915/display/intel_display.c | 1 + .../drm/i915/display/intel_display_power.c| 310 +- .../drm/i915/display/intel_display_power.h| 14 + .../drm/i915/display/intel_display_types.h| 1 + drivers/gpu/drm/i915/display/intel_dp.c | 2 + .../gpu/drm/i915/display/intel_frontbuffer.c | 1 + drivers/gpu/drm/i915/display/intel_psr.c | 42 +++ drivers/gpu/drm/i915/display/intel_psr.h | 2 + drivers/gpu/drm/i915/i915_debugfs.c | 6 + drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_params.c| 3 +- drivers/gpu/drm/i915/i915_reg.h | 10 + 13 files changed, 386 insertions(+), 16 deletions(-) -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v9 4/7] drm/i915/tgl: Do modeset to enable and configure DC3CO exitline
DC3CO enabling B.Specs sequence requires to enable end configure
exit scanlines to TRANS_EXITLINE register, programming this register
has to be part of modeset sequence as this can't be change when
transcoder or port is enabled.
When system boots with only eDP panel there may not be real
modeset as BIOS has already programmed the necessary registers,
therefore it needs to force a modeset to enable and configure
DC3CO exitline.
v1: Computing dc3co_exitline crtc state from a DP encoder
compute config. [Imre]
Enabling and disabling DC3CO PSR2 transcoder exitline from
encoder pre_enable and post_disable hooks. [Imre]
Computing dc3co_exitline instead of has_dc3co_exitline bool. [Imre]
Cc: Jani Nikula
Cc: Imre Deak
Cc: Animesh Manna
Signed-off-by: Anshuman Gupta
---
drivers/gpu/drm/i915/display/intel_ddi.c | 7 ++
drivers/gpu/drm/i915/display/intel_display.c | 1 +
.../drm/i915/display/intel_display_power.c| 87 +++
.../drm/i915/display/intel_display_power.h| 8 ++
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_dp.c | 2 +
6 files changed, 106 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
b/drivers/gpu/drm/i915/display/intel_ddi.c
index aa470c70a198..e0e276909e76 100644
--- a/drivers/gpu/drm/i915/display/intel_ddi.c
+++ b/drivers/gpu/drm/i915/display/intel_ddi.c
@@ -3212,6 +3212,8 @@ static void tgl_ddi_pre_enable_dp(struct intel_encoder
*encoder,
int level = intel_ddi_dp_level(intel_dp);
enum transcoder transcoder = crtc_state->cpu_transcoder;
+ /* Program the dc3co psr2 transcoder exitline */
+ tgl_set_psr2_transcoder_exitline(crtc_state);
intel_dp_set_link_params(intel_dp, crtc_state->port_clock,
crtc_state->lane_count, is_mst);
@@ -3524,6 +3526,8 @@ static void intel_ddi_post_disable_dp(struct
intel_encoder *encoder,
dig_port->ddi_io_power_domain);
intel_ddi_clk_disable(encoder);
+ /* Disable the dc3co psr2 transcoder exitline */
+ tgl_clear_psr2_transcoder_exitline(old_crtc_state);
}
static void intel_ddi_post_disable_hdmi(struct intel_encoder *encoder,
@@ -4070,6 +4074,9 @@ void intel_ddi_get_config(struct intel_encoder *encoder,
break;
}
+ if (encoder->type == INTEL_OUTPUT_EDP)
+ tgl_dc3co_exitline_get_config(pipe_config);
+
pipe_config->has_audio =
intel_ddi_is_audio_enabled(dev_priv, cpu_transcoder);
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 8f125f1624bd..a467c7523e06 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -12820,6 +12820,7 @@ intel_pipe_config_compare(const struct intel_crtc_state
*current_config,
PIPE_CONF_CHECK_I(pixel_multiplier);
PIPE_CONF_CHECK_I(output_format);
+ PIPE_CONF_CHECK_I(dc3co_exitline);
PIPE_CONF_CHECK_BOOL(has_hdmi_sink);
if ((INTEL_GEN(dev_priv) < 8 && !IS_HASWELL(dev_priv)) ||
IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 9f787556f80d..84e4cfd95b43 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -19,6 +19,7 @@
#include "intel_hotplug.h"
#include "intel_sideband.h"
#include "intel_tc.h"
+#include "intel_pm.h"
bool intel_display_power_well_is_enabled(struct drm_i915_private *dev_priv,
enum i915_power_well_id power_well_id);
@@ -785,6 +786,92 @@ static void gen9_set_dc_state(struct drm_i915_private
*dev_priv, u32 state)
dev_priv->csr.dc_state = val & mask;
}
+void tgl_clear_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+ u32 val;
+
+ if (!cstate->dc3co_exitline)
+ return;
+
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+void tgl_set_psr2_transcoder_exitline(const struct intel_crtc_state *cstate)
+{
+ u32 val, exit_scanlines;
+ struct drm_i915_private *dev_priv = to_i915(cstate->base.crtc->dev);
+
+ if (!cstate->dc3co_exitline)
+ return;
+
+ exit_scanlines = cstate->dc3co_exitline;
+ exit_scanlines <<= EXITLINE_SHIFT;
+ val = I915_READ(EXITLINE(cstate->cpu_transcoder));
+ val &= ~(EXITLINE_MASK | EXITLINE_ENABLE);
+ val |= exit_scanlines;
+ val |= EXITLINE_ENABLE;
+ I915_WRITE(EXITLINE(cstate->cpu_transcoder), val);
+}
+
+/*
+ * DC3CO requires to enable exitline and pr
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
Quoting Tvrtko Ursulin (2019-09-26 15:57:07)
>
> On 26/09/2019 15:25, Chris Wilson wrote:
> > Moving our primary irq handler to a RT thread incurs an extra 1us delay
> > in process interrupts. This is most notice in waking up client threads,
> > where it adds about 20% of extra latency. It also imposes a delay in
> > feeding the GPU, an extra 1us before signaling secondary engines and
> > extra latency in resubmitting work to keep the GPU busy. The latter case
> > is insignificant as the latency hidden by the active GPU, and
> > preempt-to-busy ensures that no extra latency is incurred for
> > preemption.
> >
> > The benefit is that we reduced the impact on the rest of the system, the
> > cycletest shows a reduction from 5us mean latency to 2us, with the
> > maximum observed latency (in a 2 minute window) reduced by over 160us.
> >
> > Signed-off-by: Chris Wilson
> > Cc: Joonas Lahtinen
> > Cc: Tvrtko Ursulin
> > Cc: Clark Williams
> > Cc: Sebastian Andrzej Siewior
> > ---
> > Note this should need the fixes in
> > 20190926105644.16703-2-bige...@linutronix.de, by itself this should be a
> > test vehicle to exercise that patch!
> > ---
> > drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > b/drivers/gpu/drm/i915/i915_irq.c
> > index bc83f094065a..f3df7714a3f3 100644
> > --- a/drivers/gpu/drm/i915/i915_irq.c
> > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private
> > *dev_priv)
> >
> > intel_irq_reset(dev_priv);
> >
> > - ret = request_irq(irq, intel_irq_handler(dev_priv),
> > - IRQF_SHARED, DRIVER_NAME, dev_priv);
> > + ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv),
> > +IRQF_SHARED, DRIVER_NAME, dev_priv);
> > if (ret < 0) {
> > dev_priv->drm.irq_enabled = false;
> > return ret;
> >
>
> Two questions:
>
> 1. Should we split out the master_ctl handling into the fast handler?
> Although can we pass anything from the fast to threaded handler? If not
> we'd have to re-read the master_ctl from the threaded handler.
I did look at using the primary/threaded irq handler to do some
fast/slow handling (but RT is probably going to force the primary into a
thread, so long term prospect there looked bleak ;)
In our pre-gen11 model we could certainly do the ack in the fast
primary handler, pushing the processing into the secondary thread. Post
gen11 is more annoying and we probably only do the master_ctl
immediately. (It's very tempting to put GT handler into fast, but that
defeats the PREEMPT_RT objections ;)
We can accumulate into i915 anything we want to pass from primary to
secondary. Or we can use per-cpu handlers and data structures.
> 2. What about our tasklets - with threaded irqs we don't need them any
> more, right? So in this case they just add additional latency.
Our tasklets run immediately within the RT thread. That appears to be a
positive outcome of this. We keep our direct submission so our initial
latency is not impacted at all, and the impact of the thread latency is
minimised by keeping the GPU busy. So the only (easily?) measurable
impact is client wakeup. (I have a modicum of concern that there is a
priority inversion here for an RT client waiting on the GPU.)
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
On 2019-09-26 15:25:38 [+0100], Chris Wilson wrote:
> Moving our primary irq handler to a RT thread incurs an extra 1us delay
> in process interrupts. This is most notice in waking up client threads,
> where it adds about 20% of extra latency. It also imposes a delay in
> feeding the GPU, an extra 1us before signaling secondary engines and
> extra latency in resubmitting work to keep the GPU busy. The latter case
> is insignificant as the latency hidden by the active GPU, and
> preempt-to-busy ensures that no extra latency is incurred for
> preemption.
>
> The benefit is that we reduced the impact on the rest of the system, the
> cycletest shows a reduction from 5us mean latency to 2us, with the
> maximum observed latency (in a 2 minute window) reduced by over 160us.
cycletest is the name of the tool I don't know about, right? It is not
cyclictest with a typo?
I don't know how many interrupts you have in a system but if this is the
only one for the card then you could remove _irqsave() from locking if
the lock is never observed in IRQ context (but then you have irqwork
which requires this irqsave).
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Tvrtko Ursulin
> Cc: Clark Williams
> Cc: Sebastian Andrzej Siewior
> ---
> Note this should need the fixes in
> 20190926105644.16703-2-bige...@linutronix.de, by itself this should be a
> test vehicle to exercise that patch!
> ---
> drivers/gpu/drm/i915/i915_irq.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index bc83f094065a..f3df7714a3f3 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private *dev_priv)
>
> intel_irq_reset(dev_priv);
>
> - ret = request_irq(irq, intel_irq_handler(dev_priv),
> - IRQF_SHARED, DRIVER_NAME, dev_priv);
> + ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv),
> +IRQF_SHARED, DRIVER_NAME, dev_priv);
I think you should add IRQF_ONESHOT. Otherwise a LEVEL interrupt will
keep interrupting the CPU and you never manage to switch to the thread.
> if (ret < 0) {
> dev_priv->drm.irq_enabled = false;
> return ret;
Sebastian
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
On 2019-09-26 15:57:07 [+0100], Tvrtko Ursulin wrote: > 2. What about our tasklets - with threaded irqs we don't need them any more, > right? So in this case they just add additional latency. If you enqueue / schedule tasklets from your threaded handler then this will wake up ksoftirqd and perform the work there (based on my memory of the code). > Regards, > > Tvrtko Sebastian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
Quoting Sebastian Andrzej Siewior (2019-09-26 16:13:08) > On 2019-09-26 15:25:38 [+0100], Chris Wilson wrote: > > Moving our primary irq handler to a RT thread incurs an extra 1us delay > > in process interrupts. This is most notice in waking up client threads, > > where it adds about 20% of extra latency. It also imposes a delay in > > feeding the GPU, an extra 1us before signaling secondary engines and > > extra latency in resubmitting work to keep the GPU busy. The latter case > > is insignificant as the latency hidden by the active GPU, and > > preempt-to-busy ensures that no extra latency is incurred for > > preemption. > > > > The benefit is that we reduced the impact on the rest of the system, the > > cycletest shows a reduction from 5us mean latency to 2us, with the > > maximum observed latency (in a 2 minute window) reduced by over 160us. > > cycletest is the name of the tool I don't know about, right? It is not > cyclictest with a typo? It's a tool like cyclictest that measures the timer latency in one thread while flooding the system with GPU work, filling the page cache, grabbing as many THP as possible etc. (It's actually called gem_syslatency.) > I don't know how many interrupts you have in a system but if this is the > only one for the card then you could remove _irqsave() from locking if > the lock is never observed in IRQ context (but then you have irqwork > which requires this irqsave). True, pushing the irq into a thread should allow us to re-evaluate a lot of our spin_lock_irq. > > Signed-off-by: Chris Wilson > > Cc: Joonas Lahtinen > > Cc: Tvrtko Ursulin > > Cc: Clark Williams > > Cc: Sebastian Andrzej Siewior > > --- > > Note this should need the fixes in > > 20190926105644.16703-2-bige...@linutronix.de, by itself this should be a > > test vehicle to exercise that patch! > > --- > > drivers/gpu/drm/i915/i915_irq.c | 4 ++-- > > 1 file changed, 2 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > b/drivers/gpu/drm/i915/i915_irq.c > > index bc83f094065a..f3df7714a3f3 100644 > > --- a/drivers/gpu/drm/i915/i915_irq.c > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private > > *dev_priv) > > > > intel_irq_reset(dev_priv); > > > > - ret = request_irq(irq, intel_irq_handler(dev_priv), > > - IRQF_SHARED, DRIVER_NAME, dev_priv); > > + ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv), > > +IRQF_SHARED, DRIVER_NAME, dev_priv); > > I think you should add IRQF_ONESHOT. Otherwise a LEVEL interrupt will > keep interrupting the CPU and you never manage to switch to the thread. The interrupts only keep coming if we feed the GPU, and we only feed the GPU if we service the interrupt. That should provide a natural quiescence :) -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/dmc: Update ICL DMC version to v1.09 (rev2)
== Series Details == Series: drm/i915/dmc: Update ICL DMC version to v1.09 (rev2) URL : https://patchwork.freedesktop.org/series/66560/ State : success == Summary == CI Bug Log - changes from CI_DRM_6958_full -> Patchwork_14538_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_14538_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-apl3/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-apl4/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_ctx_shared@exec-single-timeline-bsd: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#110841]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb6/igt@gem_ctx_sha...@exec-single-timeline-bsd.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-iclb4/igt@gem_ctx_sha...@exec-single-timeline-bsd.html * igt@gem_eio@reset-stress: - shard-snb: [PASS][5] -> [FAIL][6] ([fdo#109661]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb6/igt@gem_...@reset-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-snb1/igt@gem_...@reset-stress.html * igt@gem_exec_async@concurrent-writes-bsd: - shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#111325]) +6 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-iclb5/igt@gem_exec_as...@concurrent-writes-bsd.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-iclb2/igt@gem_exec_as...@concurrent-writes-bsd.html * igt@gem_tiled_swapping@non-threaded: - shard-glk: [PASS][9] -> [DMESG-WARN][10] ([fdo#108686]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-glk9/igt@gem_tiled_swapp...@non-threaded.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-glk2/igt@gem_tiled_swapp...@non-threaded.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#108566]) +4 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-kbl6/igt@gem_workarou...@suspend-resume-fd.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_rpm@pm-tiling: - shard-skl: [PASS][13] -> [SKIP][14] ([fdo#109271]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl10/igt@i915_pm_...@pm-tiling.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-skl2/igt@i915_pm_...@pm-tiling.html * igt@i915_pm_rpm@system-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108] / [fdo#107807]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-skl3/igt@i915_pm_...@system-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-skl7/igt@i915_pm_...@system-suspend.html * igt@i915_pm_rpm@universal-planes-dpms: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([fdo#103313]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-kbl4/igt@i915_pm_...@universal-planes-dpms.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-kbl2/igt@i915_pm_...@universal-planes-dpms.html * igt@kms_busy@extended-modeset-hang-newfb-render-a: - shard-snb: [PASS][19] -> [SKIP][20] ([fdo#109271] / [fdo#109278]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb4/igt@kms_b...@extended-modeset-hang-newfb-render-a.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-snb2/igt@kms_b...@extended-modeset-hang-newfb-render-a.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [PASS][21] -> [INCOMPLETE][22] ([fdo#103927]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu: - shard-snb: [PASS][23] -> [SKIP][24] ([fdo#109271]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6958/shard-snb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14538/shard-snb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-mmap-cpu.html * igt@kms_frontbuffer_tracking@fbc-rgb565-draw-blt: - shard-iclb: [PASS][25] -> [FAIL][26] ([fdo#103167]) +6 similar issues [25]
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Delegate our irq handler to a thread
== Series Details == Series: drm/i915: Delegate our irq handler to a thread URL : https://patchwork.freedesktop.org/series/67294/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14557 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_14557 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_14557, 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_14557/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_14557: ### IGT changes ### Possible regressions * igt@gem_busy@busy-all: - fi-kbl-guc: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-guc/igt@gem_b...@busy-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-kbl-guc/igt@gem_b...@busy-all.html - fi-icl-u2: [PASS][3] -> [DMESG-WARN][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@gem_b...@busy-all.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-icl-u2/igt@gem_b...@busy-all.html - fi-cfl-8700k: [PASS][5] -> [DMESG-WARN][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-cfl-8700k/igt@gem_b...@busy-all.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-cfl-8700k/igt@gem_b...@busy-all.html - fi-skl-guc: [PASS][7] -> [DMESG-WARN][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-guc/igt@gem_b...@busy-all.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-skl-guc/igt@gem_b...@busy-all.html - fi-cfl-guc: [PASS][9] -> [DMESG-WARN][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-cfl-guc/igt@gem_b...@busy-all.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-cfl-guc/igt@gem_b...@busy-all.html - fi-icl-u3: NOTRUN -> [DMESG-WARN][11] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-icl-u3/igt@gem_b...@busy-all.html - fi-kbl-r: [PASS][12] -> [DMESG-WARN][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-r/igt@gem_b...@busy-all.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-kbl-r/igt@gem_b...@busy-all.html - fi-kbl-x1275: [PASS][14] -> [DMESG-WARN][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-kbl-x1275/igt@gem_b...@busy-all.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-kbl-x1275/igt@gem_b...@busy-all.html - fi-skl-6600u: [PASS][16] -> [DMESG-WARN][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-6600u/igt@gem_b...@busy-all.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-skl-6600u/igt@gem_b...@busy-all.html - fi-whl-u: [PASS][18] -> [DMESG-WARN][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-whl-u/igt@gem_b...@busy-all.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-whl-u/igt@gem_b...@busy-all.html - fi-byt-j1900: [PASS][20] -> [DMESG-WARN][21] [20]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-byt-j1900/igt@gem_b...@busy-all.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-byt-j1900/igt@gem_b...@busy-all.html - fi-cfl-8109u: [PASS][22] -> [DMESG-WARN][23] [22]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-cfl-8109u/igt@gem_b...@busy-all.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-cfl-8109u/igt@gem_b...@busy-all.html * igt@gem_close_race@basic-process: - fi-ivb-3770:[PASS][24] -> [DMESG-WARN][25] [24]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-ivb-3770/igt@gem_close_r...@basic-process.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-ivb-3770/igt@gem_close_r...@basic-process.html - fi-cml-u2: [PASS][26] -> [DMESG-WARN][27] [26]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-cml-u2/igt@gem_close_r...@basic-process.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-cml-u2/igt@gem_close_r...@basic-process.html - fi-hsw-4770:[PASS][28] -> [DMESG-WARN][29] [28]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-hsw-4770/igt@gem_close_r...@basic-process.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14557/fi-hsw-4770/igt@gem_close_r...@basic-process.html - fi-skl-6700k2: [PASS][30] -> [DMESG-WARN][31] [30]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-skl-6700k2/igt@gem_close_r
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
On 2019-09-26 16:24:59 [+0100], Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > > b/drivers/gpu/drm/i915/i915_irq.c > > > index bc83f094065a..f3df7714a3f3 100644 > > > --- a/drivers/gpu/drm/i915/i915_irq.c > > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > > @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private > > > *dev_priv) > > > > > > intel_irq_reset(dev_priv); > > > > > > - ret = request_irq(irq, intel_irq_handler(dev_priv), > > > - IRQF_SHARED, DRIVER_NAME, dev_priv); > > > + ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv), > > > +IRQF_SHARED, DRIVER_NAME, dev_priv); > > > > I think you should add IRQF_ONESHOT. Otherwise a LEVEL interrupt will > > keep interrupting the CPU and you never manage to switch to the thread. > > The interrupts only keep coming if we feed the GPU, and we only feed the > GPU if we service the interrupt. That should provide a natural > quiescence :) In IRQ-context your primary handler gets invoked which wakes the thread (what ever intel_irq_handler() returns). Then you leave the IRQ context and should switch to your IRQ-handler. This will never happen because the IRQ line remains asserted and CPU ends up in the primary handler again. An EDGE typed IRQ wouldn't notice a difference. But a LINE typed IRQ will remain asserted until the hardware de-asserts the interrupt again. Since you never reach your thread handler, I don't see how this can happen. > -Chris Sebastian ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v4 2/4] drm/i915/tgl: Add dkl phy programming sequences
On Wed, Sep 25, 2019 at 04:45:07PM -0700, José Roberto de Souza wrote:
> From: Clinton A Taylor
>
> Added DKL Phy sequences and helpers functions to program voltage
> swing, clock gating and dp mode.
>
> It is not written in DP enabling sequence but "PHY Clockgating
> programming" states that clock gating should be enabled after the
> link training but doing so causes all the following trainings to fail
> so not enabling it for.
>
> v2:
> Setting the right HIP_INDEX_REG bits (José)
>
> v3:
> Adding the meaning of each column of tgl_dkl_phy_ddi_translations
> Adding if gen >= 12 on intel_ddi_hdmi_level() and
> intel_ddi_pre_enable_hdmi() instead of reuse part of gen >= 11 if
>
> v4:
> Moved the DP_MODE lane programing to another patch as ICL also
> needed it
> Sharing icl_phy_set_clock_gating() and icl_program_mg_dp_mode() with
> TGL as bits and programing as now it almost identical to ICL
>
> BSpec: 49292
> BSpec: 49190
>
> Cc: Imre Deak
> Cc: Lucas De Marchi
> Signed-off-by: José Roberto de Souza
> Signed-off-by: Clinton A Taylor
> ---
> drivers/gpu/drm/i915/display/intel_ddi.c | 175 ---
> drivers/gpu/drm/i915/i915_reg.h | 8 --
> 2 files changed, 155 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> b/drivers/gpu/drm/i915/display/intel_ddi.c
> index 316cedb16935..4da7940f1fcf 100644
> --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> @@ -586,6 +586,26 @@ static const struct icl_mg_phy_ddi_buf_trans
> icl_mg_phy_ddi_translations[] = {
> { 0x0, 0x00, 0x00 },/* 3 0 */
> };
>
> +struct tgl_dkl_phy_ddi_buf_trans {
> + u32 dkl_vswing_control;
> + u32 dkl_preshoot_control;
> + u32 dkl_de_emphasis_control;
> +};
> +
> +static const struct tgl_dkl_phy_ddi_buf_trans tgl_dkl_phy_ddi_translations[]
> = {
> + /* VS pre-emp Non-trans mVPre-emph dB */
> + { 0x7, 0x0, 0x00 }, /* 00 400mV 0 dB */
> + { 0x5, 0x0, 0x03 }, /* 01 400mV 3.5 dB */
> + { 0x2, 0x0, 0x0b }, /* 02 400mV 6 dB */
> + { 0x0, 0x0, 0x19 }, /* 03 400mV 9.5 dB */
> + { 0x5, 0x0, 0x00 }, /* 10 600mV 0 dB */
> + { 0x2, 0x0, 0x03 }, /* 11 600mV 3.5 dB */
> + { 0x0, 0x0, 0x14 }, /* 12 600mV 6 dB */
> + { 0x2, 0x0, 0x00 }, /* 20 800mV 0 dB */
> + { 0x0, 0x0, 0x0B }, /* 21 800mV 3.5 dB */
> + { 0x0, 0x0, 0x00 }, /* 30 1200mV 0 dB HDMI
> default */
> +};
> +
> static const struct ddi_buf_trans *
> bdw_get_buf_trans_edp(struct drm_i915_private *dev_priv, int *n_entries)
> {
> @@ -872,7 +892,14 @@ static int intel_ddi_hdmi_level(struct drm_i915_private
> *dev_priv, enum port por
>
> level = dev_priv->vbt.ddi_port_info[port].hdmi_level_shift;
>
> - if (INTEL_GEN(dev_priv) >= 11) {
> + if (INTEL_GEN(dev_priv) >= 12) {
> + if (intel_phy_is_combo(dev_priv, phy))
> + icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> + 0, &n_entries);
> + else
> + n_entries = ARRAY_SIZE(tgl_dkl_phy_ddi_translations);
> + default_entry = n_entries - 1;
> + } else if (INTEL_GEN(dev_priv) == 11) {
> if (intel_phy_is_combo(dev_priv, phy))
> icl_get_combo_buf_trans(dev_priv, INTEL_OUTPUT_HDMI,
> 0, &n_entries);
> @@ -2334,7 +2361,13 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
> *encoder)
> enum phy phy = intel_port_to_phy(dev_priv, port);
> int n_entries;
>
> - if (INTEL_GEN(dev_priv) >= 11) {
> + if (INTEL_GEN(dev_priv) >= 12) {
> + if (intel_phy_is_combo(dev_priv, phy))
> + icl_get_combo_buf_trans(dev_priv, encoder->type,
> + intel_dp->link_rate,
> &n_entries);
> + else
> + n_entries = ARRAY_SIZE(tgl_dkl_phy_ddi_translations);
> + } else if (INTEL_GEN(dev_priv) == 11) {
> if (intel_phy_is_combo(dev_priv, phy))
> icl_get_combo_buf_trans(dev_priv, encoder->type,
> intel_dp->link_rate,
> &n_entries);
> @@ -2776,6 +2809,63 @@ static void icl_ddi_vswing_sequence(struct
> intel_encoder *encoder,
> icl_mg_phy_ddi_vswing_sequence(encoder, link_clock, level);
> }
>
> +static void
> +tgl_dkl_phy_ddi_vswing_sequence(struct intel_encoder *encoder, int
> link_clock,
> + u32 level)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, encoder-
[Intel-gfx] [CI 1/3] drm/i915: Delegate our irq handler to a thread
Moving our primary irq handler to a RT thread incurs an extra 1us delay
in process interrupts. This is most notice in waking up client threads,
where it adds about 20% of extra latency. It also imposes a delay in
feeding the GPU, an extra 1us before signaling secondary engines and
extra latency in resubmitting work to keep the GPU busy. The latter case
is insignificant as the latency hidden by the active GPU, and
preempt-to-busy ensures that no extra latency is incurred for
preemption.
The benefit is that we reduced the impact on the rest of the system, the
cycletest shows a reduction from 5us mean latency to 2us, with the
maximum observed latency (in a 2 minute window) reduced by over 160us.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Clark Williams
Cc: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/i915_irq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index bc83f094065a..f3df7714a3f3 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private *dev_priv)
intel_irq_reset(dev_priv);
- ret = request_irq(irq, intel_irq_handler(dev_priv),
- IRQF_SHARED, DRIVER_NAME, dev_priv);
+ ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv),
+ IRQF_SHARED, DRIVER_NAME, dev_priv);
if (ret < 0) {
dev_priv->drm.irq_enabled = false;
return ret;
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 3/3] drm/i915: Drop the IRQ-off asserts
From: Sebastian Andrzej Siewior
The lockdep_assert_irqs_disabled() check is needless. The previous
lockdep_assert_held() check ensures that the lock is acquired and while
the lock is acquired lockdep also prints a warning if the interrupts are
not disabled if they have to be.
These IRQ-off asserts trigger on PREEMPT_RT because the locks become
sleeping locks and do not really disable interrupts.
Remove lockdep_assert_irqs_disabled().
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index f750375056de..55317081d48b 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -120,7 +120,6 @@ __dma_fence_signal__notify(struct dma_fence *fence,
struct dma_fence_cb *cur, *tmp;
lockdep_assert_held(fence->lock);
- lockdep_assert_irqs_disabled();
list_for_each_entry_safe(cur, tmp, list, node) {
INIT_LIST_HEAD(&cur->node);
@@ -269,7 +268,6 @@ void intel_engine_fini_breadcrumbs(struct intel_engine_cs
*engine)
bool i915_request_enable_breadcrumb(struct i915_request *rq)
{
lockdep_assert_held(&rq->lock);
- lockdep_assert_irqs_disabled();
if (test_bit(I915_FENCE_FLAG_ACTIVE, &rq->fence.flags)) {
struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
@@ -319,7 +317,6 @@ void i915_request_cancel_breadcrumb(struct i915_request *rq)
struct intel_breadcrumbs *b = &rq->engine->breadcrumbs;
lockdep_assert_held(&rq->lock);
- lockdep_assert_irqs_disabled();
/*
* We must wait for b->irq_lock so that we know the interrupt handler
--
2.23.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: Don't disable interrupts for intel_engine_breadcrumbs_irq()
From: Sebastian Andrzej Siewior
The function intel_engine_breadcrumbs_irq() is always invoked from an interrupt
handler and for that reason it invokes (as an optimisation) only spin_lock()
for locking assuming that the interrupts are already disabled. The
function intel_engine_signal_breadcrumbs() is provided to disable
interrupts while the former function is invoked so that assumption is
also true for callers from preemptible context.
On PREEMPT_RT local_irq_disable() really disables interrupts and this
forbids to invoke spin_lock() which becomes a sleeping spinlock.
This is also problematic with `threadirqs' in conjunction with
irq_work. With force threading the interrupt handler, the handler is
invoked with disabled BH but with interrupts enabled. This is okay and
the lock itself is never acquired in IRQ context. This changes with
irq_work (signal_irq_work()) which _still_ invokes
intel_engine_breadcrumbs_irq() from IRQ context. Lockdep should see this
and complain.
Acquire the locks in intel_engine_breadcrumbs_irq() with _irqsave()
suffix and let all callers invoke intel_engine_breadcrumbs_irq()
directly instead using intel_engine_signal_breadcrumbs().
Reported-by: Clark Williams
Signed-off-by: Sebastian Andrzej Siewior
---
drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 16 +---
drivers/gpu/drm/i915/gt/intel_engine.h | 1 -
drivers/gpu/drm/i915/gt/intel_hangcheck.c | 2 +-
drivers/gpu/drm/i915/gt/intel_reset.c | 2 +-
4 files changed, 7 insertions(+), 14 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
index 09c68dda2098..f750375056de 100644
--- a/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
+++ b/drivers/gpu/drm/i915/gt/intel_breadcrumbs.c
@@ -134,9 +134,10 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
const ktime_t timestamp = ktime_get();
struct intel_context *ce, *cn;
struct list_head *pos, *next;
+ unsigned long flags;
LIST_HEAD(signal);
- spin_lock(&b->irq_lock);
+ spin_lock_irqsave(&b->irq_lock, flags);
if (b->irq_armed && list_empty(&b->signalers))
__intel_breadcrumbs_disarm_irq(b);
@@ -182,30 +183,23 @@ void intel_engine_breadcrumbs_irq(struct intel_engine_cs
*engine)
}
}
- spin_unlock(&b->irq_lock);
+ spin_unlock_irqrestore(&b->irq_lock, flags);
list_for_each_safe(pos, next, &signal) {
struct i915_request *rq =
list_entry(pos, typeof(*rq), signal_link);
struct list_head cb_list;
- spin_lock(&rq->lock);
+ spin_lock_irqsave(&rq->lock, flags);
list_replace(&rq->fence.cb_list, &cb_list);
__dma_fence_signal__timestamp(&rq->fence, timestamp);
__dma_fence_signal__notify(&rq->fence, &cb_list);
- spin_unlock(&rq->lock);
+ spin_unlock_irqrestore(&rq->lock, flags);
i915_request_put(rq);
}
}
-void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine)
-{
- local_irq_disable();
- intel_engine_breadcrumbs_irq(engine);
- local_irq_enable();
-}
-
static void signal_irq_work(struct irq_work *work)
{
struct intel_engine_cs *engine =
diff --git a/drivers/gpu/drm/i915/gt/intel_engine.h
b/drivers/gpu/drm/i915/gt/intel_engine.h
index d3c6993f4f46..c9e8c8ccbd47 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine.h
+++ b/drivers/gpu/drm/i915/gt/intel_engine.h
@@ -335,7 +335,6 @@ void intel_engine_init_execlists(struct intel_engine_cs
*engine);
void intel_engine_init_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_fini_breadcrumbs(struct intel_engine_cs *engine);
-void intel_engine_signal_breadcrumbs(struct intel_engine_cs *engine);
void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine);
static inline void
diff --git a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
index 40f62f780be5..9814b18b32ad 100644
--- a/drivers/gpu/drm/i915/gt/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/gt/intel_hangcheck.c
@@ -284,7 +284,7 @@ static void hangcheck_elapsed(struct work_struct *work)
for_each_engine(engine, gt->i915, id) {
struct hangcheck hc;
- intel_engine_signal_breadcrumbs(engine);
+ intel_engine_breadcrumbs_irq(engine);
hangcheck_load_sample(engine, &hc);
hangcheck_accumulate_sample(engine, &hc);
diff --git a/drivers/gpu/drm/i915/gt/intel_reset.c
b/drivers/gpu/drm/i915/gt/intel_reset.c
index ae68c3786f63..754e5b321a5f 100644
--- a/drivers/gpu/drm/i915/gt/intel_reset.c
+++ b/drivers/gpu/drm/i915/gt/intel_reset.c
@@ -711,7 +711,7 @@ static void reset_finish_engine(struct intel_engine_cs
*engine)
engine->reset.finish(engine);
intel_uncore_forcewake_put(engine->uncore, FORC
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
Quoting Sebastian Andrzej Siewior (2019-09-26 16:32:52) > On 2019-09-26 16:24:59 [+0100], Chris Wilson wrote: > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > > > b/drivers/gpu/drm/i915/i915_irq.c > > > > index bc83f094065a..f3df7714a3f3 100644 > > > > --- a/drivers/gpu/drm/i915/i915_irq.c > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > > > @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private > > > > *dev_priv) > > > > > > > > intel_irq_reset(dev_priv); > > > > > > > > - ret = request_irq(irq, intel_irq_handler(dev_priv), > > > > - IRQF_SHARED, DRIVER_NAME, dev_priv); > > > > + ret = request_threaded_irq(irq, NULL, intel_irq_handler(dev_priv), > > > > +IRQF_SHARED, DRIVER_NAME, dev_priv); > > > > > > I think you should add IRQF_ONESHOT. Otherwise a LEVEL interrupt will > > > keep interrupting the CPU and you never manage to switch to the thread. > > > > The interrupts only keep coming if we feed the GPU, and we only feed the > > GPU if we service the interrupt. That should provide a natural > > quiescence :) > > In IRQ-context your primary handler gets invoked which wakes the thread > (what ever intel_irq_handler() returns). Then you leave the IRQ context > and should switch to your IRQ-handler. This will never happen because > the IRQ line remains asserted and CPU ends up in the primary handler > again. > An EDGE typed IRQ wouldn't notice a difference. But a LINE typed IRQ > will remain asserted until the hardware de-asserts the interrupt again. > Since you never reach your thread handler, I don't see how this can > happen. It's all edge interrupts -- although for gen2/3 my memory is hazy. But the GPU (circa gen6) can generate more than enough interrupts to saturate a CPU. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Delegate our irq handler to a thread
Quoting Chris Wilson (2019-09-26 16:40:34) > Quoting Sebastian Andrzej Siewior (2019-09-26 16:32:52) > > On 2019-09-26 16:24:59 [+0100], Chris Wilson wrote: > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c > > > > > b/drivers/gpu/drm/i915/i915_irq.c > > > > > index bc83f094065a..f3df7714a3f3 100644 > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c > > > > > @@ -4491,8 +4491,8 @@ int intel_irq_install(struct drm_i915_private > > > > > *dev_priv) > > > > > > > > > > intel_irq_reset(dev_priv); > > > > > > > > > > - ret = request_irq(irq, intel_irq_handler(dev_priv), > > > > > - IRQF_SHARED, DRIVER_NAME, dev_priv); > > > > > + ret = request_threaded_irq(irq, NULL, > > > > > intel_irq_handler(dev_priv), > > > > > +IRQF_SHARED, DRIVER_NAME, dev_priv); > > > > > > > > I think you should add IRQF_ONESHOT. Otherwise a LEVEL interrupt will > > > > keep interrupting the CPU and you never manage to switch to the thread. > > > > > > The interrupts only keep coming if we feed the GPU, and we only feed the > > > GPU if we service the interrupt. That should provide a natural > > > quiescence :) > > > > In IRQ-context your primary handler gets invoked which wakes the thread > > (what ever intel_irq_handler() returns). Then you leave the IRQ context > > and should switch to your IRQ-handler. This will never happen because > > the IRQ line remains asserted and CPU ends up in the primary handler > > again. > > An EDGE typed IRQ wouldn't notice a difference. But a LINE typed IRQ > > will remain asserted until the hardware de-asserts the interrupt again. > > Since you never reach your thread handler, I don't see how this can > > happen. > > It's all edge interrupts -- although for gen2/3 my memory is hazy. But > the GPU (circa gen6) can generate more than enough interrupts to saturate > a CPU. So everything older than gen5 has MSI disabled it appears and needs ONESHOT. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V2 5/8] mdev: introduce device specific ops
On Wed, Sep 25, 2019 at 10:30:28AM -0600, Alex Williamson wrote:
> On Wed, 25 Sep 2019 10:11:00 -0400
> Rob Miller wrote:
> > > > On Tue, 24 Sep 2019 21:53:29 +0800
> > > > Jason Wang wrote:
> > > > > diff --git a/drivers/vfio/mdev/vfio_mdev.c
> > > > b/drivers/vfio/mdev/vfio_mdev.c
> > > > > index 891cf83a2d9a..95efa054442f 100644
> > > > > --- a/drivers/vfio/mdev/vfio_mdev.c
> > > > > +++ b/drivers/vfio/mdev/vfio_mdev.c
> > > > > @@ -14,6 +14,7 @@
> > > > > #include
> > > > > #include
> > > > > #include
> > > > > +#include
> > > > >
> > > > > #include "mdev_private.h"
> > > > >
> > > > > @@ -24,16 +25,16 @@
> > > > > static int vfio_mdev_open(void *device_data)
> > > > > {
> > > > > struct mdev_device *mdev = device_data;
> > > > > - struct mdev_parent *parent = mdev->parent;
> > > > > + const struct vfio_mdev_device_ops *ops =
> > > > mdev_get_dev_ops(mdev);
> > > > > int ret;
> > > > >
> > > > > - if (unlikely(!parent->ops->open))
> > > > > + if (unlikely(!ops->open))
> > > > > return -EINVAL;
> > > > >
> > > > > if (!try_module_get(THIS_MODULE))
> > > > > return -ENODEV;
> > >
> >
> > RJM>] My understanding lately is that this call to
> > try_module_get(THIS_MODULE) is no longer needed as is considered as a
> > latent bug.
> > Quote from
> > https://stackoverflow.com/questions/1741415/linux-kernel-modules-when-to-use-try-module-get-module-put
> > :
> > There are a number of uses of try_module_get(THIS_MODULE) in the kernel
> > source but most if not all of them are latent bugs that should be cleaned
> > up.
>
> This use seems to fall exactly into the case where it is necessary, the
> open here is not a direct VFS call, it's an internal interface between
> modules. The user is interacting with filesystem objects from the vfio
> module and the module reference we're trying to acquire here is to the
> vfio-mdev module. Thanks,
>
> Alex
I think the latent bug refers not to module get per se,
but to the module_put tied to it. E.g.:
static void vfio_mdev_release(void *device_data)
{
struct mdev_device *mdev = device_data;
struct mdev_parent *parent = mdev->parent;
if (likely(parent->ops->release))
parent->ops->release(mdev);
module_put(THIS_MODULE);
Does anything prevent the module from unloading at this point?
if not then ...
}
it looks like the implicit return (with instructions for argument pop
and functuon return) here can get overwritten on module
unload, causing a crash when executed.
IOW there's generally no way for module to keep a reference
to itself: it can take a reference but it needs someone else
to keep it and put.
--
MST
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 16/23] drm/i915: Program planes in bigjoiner mode.
Op 26-09-2019 om 15:06 schreef Ville Syrjälä:
> On Fri, Sep 20, 2019 at 01:42:28PM +0200, Maarten Lankhorst wrote:
>> Now that we can program planes from the update_slave callback, and
>> we have done all fb pinning correctly, it's time to program those
>> planes as well.
>>
>> We use the update_slave callback as it allows us to use the
>> separate states correctly.
>>
>> Signed-off-by: Maarten Lankhorst
>> ---
>> .../gpu/drm/i915/display/intel_atomic_plane.c | 53 +++
>> .../gpu/drm/i915/display/intel_atomic_plane.h | 2 +
>> drivers/gpu/drm/i915/display/intel_display.c | 4 +-
>> 3 files changed, 57 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> index cc088676f0a2..5db091e4ad6a 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.c
>> @@ -366,6 +366,59 @@ void skl_update_planes_on_crtc(struct
>> intel_atomic_state *state,
>> }
>> }
>>
>> +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state *state,
>> + struct intel_crtc *crtc)
> This plane stuff is where things go very much off the rails IMO.
> Planes should not have to know anything about bigjoiner. They should
> just have their appropriate hw state and blindly bash it into the
> hardware.
We already need this for planar slave/master, what's the issue exactly?
We're using master_plane_state for all plane properties (fb/rotation/props) and
plane_state for writing all state.
>> +{
>> +struct intel_crtc_state *old_crtc_state =
>> +intel_atomic_get_old_crtc_state(state, crtc);
>> +struct intel_crtc_state *new_crtc_state =
>> +intel_atomic_get_new_crtc_state(state, crtc);
>> +struct skl_ddb_entry entries_y[I915_MAX_PLANES];
>> +struct skl_ddb_entry entries_uv[I915_MAX_PLANES];
>> +u32 update_mask = new_crtc_state->update_planes;
>> +struct intel_plane *plane;
>> +
>> +memcpy(entries_y, old_crtc_state->wm.skl.plane_ddb_y,
>> + sizeof(old_crtc_state->wm.skl.plane_ddb_y));
>> +memcpy(entries_uv, old_crtc_state->wm.skl.plane_ddb_uv,
>> + sizeof(old_crtc_state->wm.skl.plane_ddb_uv));
>> +
>> +while ((plane = skl_next_plane_to_commit(state, crtc,
>> + entries_y, entries_uv,
>> + &update_mask))) {
>> +struct intel_plane_state *new_plane_state =
>> +intel_atomic_get_new_plane_state(state, plane);
>> +const struct intel_plane_state *master_plane_state;
>> +
>> +if (new_plane_state->base.visible) {
>> +master_plane_state =
>> +intel_atomic_get_new_plane_state(state,
>> new_plane_state->bigjoiner_plane);
>> +
>> +intel_update_slave(plane, new_crtc_state,
>> + master_plane_state, new_plane_state);
>> +} else if (new_plane_state->slave) {
>> +/*
>> + * bigjoiner slave + planar slave.
>> + * The correct sequence is to get from the planar slave
>> to planar master,
>> + * then to the master plane state for the
>> master_plane_state.
>> + */
>> +
>> +struct intel_plane *linked =
>> new_plane_state->linked_plane;
>> +const struct intel_plane_state *uv_plane_state =
>> +intel_atomic_get_new_plane_state(state, linked);
>> +
>> +linked = uv_plane_state->bigjoiner_plane;
>> +master_plane_state =
>> +intel_atomic_get_new_plane_state(state, linked);
>> +
>> +intel_update_slave(plane, new_crtc_state,
>> + master_plane_state, new_plane_state);
>> +} else {
>> +intel_disable_plane(plane, new_crtc_state);
>> +}
>> +}
>> +}
>> +
>> void i9xx_update_planes_on_crtc(struct intel_atomic_state *state,
>> struct intel_crtc *crtc)
>> {
>> diff --git a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
>> b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
>> index 901a50e6e2d3..1cffda2b50b5 100644
>> --- a/drivers/gpu/drm/i915/display/intel_atomic_plane.h
>> +++ b/drivers/gpu/drm/i915/display/intel_atomic_plane.h
>> @@ -30,6 +30,8 @@ void intel_plane_free(struct intel_plane *plane);
>> struct drm_plane_state *intel_plane_duplicate_state(struct drm_plane
>> *plane);
>> void intel_plane_destroy_state(struct drm_plane *plane,
>> struct drm_plane_state *state);
>> +void icl_update_bigjoiner_planes_on_crtc(struct intel_atomic_state *state,
>> + struct intel_crtc *cr
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Update references to previously renamed files
== Series Details ==
Series: drm/i915: Update references to previously renamed files
URL : https://patchwork.freedesktop.org/series/67295/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_6963 -> Patchwork_14558
Summary
---
**SUCCESS**
No regressions found.
External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/
Known issues
Here are the changes found in Patchwork_14558 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_frontbuffer_tracking@basic:
- fi-icl-u2: [PASS][1] -> [FAIL][2] ([fdo#103167])
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html
Possible fixes
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-icl-u2: [FAIL][3] ([fdo#109483]) -> [PASS][4]
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6963/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/fi-icl-u2/igt@kms_chamel...@hdmi-hpd-fast.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713
[fdo#109483]: https://bugs.freedesktop.org/show_bug.cgi?id=109483
[fdo#111735]: https://bugs.freedesktop.org/show_bug.cgi?id=111735
Participating hosts (50 -> 43)
--
Additional (3): fi-kbl-soraka fi-hsw-4770r fi-icl-u3
Missing(10): fi-ilk-m540 fi-bxt-dsi fi-hsw-4200u fi-byt-squawks
fi-bsw-cyan fi-byt-clapper fi-pnv-d510 fi-icl-y fi-icl-dsi fi-bdw-samus
Build changes
-
* CI: CI-20190529 -> None
* Linux: CI_DRM_6963 -> Patchwork_14558
CI-20190529: 20190529
CI_DRM_6963: 364bf33c246115063174fa2a07e9f5a6bddc9f72 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_5203: 82326332f7af336d390e00ae87187bc207fd33dd @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_14558: 413e09d5427a62a9b3e7959a2681e478a23fafb5 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
413e09d5427a drm/i915: Update references to previously renamed files
== Logs ==
For more details see:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_14558/index.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/23] drm/i915/dp: Allow big joiner modes in intel_dp_mode_valid()
Op 26-09-2019 om 00:09 schreef Manasi Navare:
> On Tue, Sep 24, 2019 at 10:30:39PM -0700, Matt Roper wrote:
>> On Fri, Sep 20, 2019 at 01:42:22PM +0200, Maarten Lankhorst wrote:
>>> Small changes to intel_dp_mode_valid(), allow listing modes that
>>> can only be supported in the bigjoiner configuration, which is
>>> not supported yet.
>>>
>>> Also unexport a few functions only used internally in intel_dp.c
>>>
>>> Signed-off-by: Maarten Lankhorst
>>> ---
>>> drivers/gpu/drm/i915/display/intel_dp.c | 98 +++--
>>> 1 file changed, 75 insertions(+), 23 deletions(-)
>>>
>>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>>> b/drivers/gpu/drm/i915/display/intel_dp.c
>>> index 2fceb71f7f70..046e1662d1e3 100644
>>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>>> @@ -247,7 +247,7 @@ intel_dp_max_data_rate(int max_link_clock, int
>>> max_lanes)
>>> }
>>>
>>> static int
>>> -intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp)
>>> +intel_dp_downstream_max_dotclock(struct intel_dp *intel_dp, bool
>>> allow_bigjoiner)
>>> {
>>> struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
>>> struct intel_encoder *encoder = &intel_dig_port->base;
>>> @@ -257,6 +257,9 @@ intel_dp_downstream_max_dotclock(struct intel_dp
>>> *intel_dp)
>>>
>>> int type = intel_dp->downstream_ports[0] & DP_DS_PORT_TYPE_MASK;
>>>
>>> + if (allow_bigjoiner && INTEL_GEN(dev_priv) >= 11)
>>> + max_dotclk *= 2;
>>> +
> Since here we allow the big joiner for >=11 (ICL+), we need to update the
> plane_mode_valid check to ensure that we allow the 8K mode only for TGL+
> else with big joiner enabled on ICL we will enable it on ICL which is not
> permitted (not POR)
Should we decrease hdisplay_max to 5120 then for < gen12?
intel_mode_valid() currently allows the full mode.
>
>
>> Should we be checking if the specific pipe can do big joiner on the
>> platform (gen11 vs gen12 differences) and also omitting eDP from
>> consideration?
>>
>>
>>> if (type != DP_DS_PORT_TYPE_VGA)
>>> return max_dotclk;
>>>
>>> @@ -505,8 +508,10 @@ u32 intel_dp_fec_to_mode_clock(u32 fec_clock)
>>>100U);
>>> }
>>>
>>> -static u16 intel_dp_dsc_get_output_bpp(u32 link_clock, u32 lane_count,
>>> - u32 mode_clock, u32 mode_hdisplay)
>>> +static u16 intel_dp_dsc_get_output_bpp(struct drm_i915_private *dev_priv,
>>> + u32 link_clock, u32 lane_count,
>>> + u32 mode_clock, u32 mode_hdisplay,
>>> + bool bigjoiner)
>>> {
>>> u32 bits_per_pixel, max_bpp_small_joiner_ram;
>>> int i;
>>> @@ -523,6 +528,10 @@ static u16 intel_dp_dsc_get_output_bpp(u32 link_clock,
>>> u32 lane_count,
>>>
>>> /* Small Joiner Check: output bpp <= joiner RAM (bits) / Horiz. width */
>>> max_bpp_small_joiner_ram = DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER /
>>> mode_hdisplay;
>>> +
>>> + if (bigjoiner)
>>> + max_bpp_small_joiner_ram *= 2;
>>> +
>> This change is correct, but while confirming in the bspec I noticed that
>> we may have the wrong DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER value for
>> gen11+. It indicates 6144 for GLK, CNL, but 7680 for ICL+ (and double
>> that to 15360 when using big joiner).
>>
>> Bspec: 20388
>> Bspec: 49259
> @Matt, the 7680 is in bytes which translates to 61440 bits and thats what
> we are using, see the #DP_DSC_MAX_SMALL_JOINER_RAM_BUFFER
>
> and then its double for big joiner, so this is correct
>
>>> DRM_DEBUG_KMS("Max small joiner bpp: %u\n", max_bpp_small_joiner_ram);
>>>
>>> /*
>>> @@ -531,6 +540,15 @@ static u16 intel_dp_dsc_get_output_bpp(u32 link_clock,
>>> u32 lane_count,
>>> */
>>> bits_per_pixel = min(bits_per_pixel, max_bpp_small_joiner_ram);
>>>
>>> + if (bigjoiner) {
>>> + u32 max_bpp_bigjoiner =
>>> + dev_priv->max_cdclk_freq * 48 /
>>> + intel_dp_mode_to_fec_clock(mode_clock);
>> Minor nitpick, but just to match the bspec (PPC * CDCLK * 24 bits /
>> pixel clock), I'd keep the 2 PPC and 24 bit factors separate here.
>>
> Yes I agree her with Matt that we shd keep the 2ppc separate just to match
> bspec
>
>>> +
>>> + DRM_DEBUG_KMS("Max big joiner bpp: %u\n", max_bpp_bigjoiner);
>>> + bits_per_pixel = min(bits_per_pixel, max_bpp_bigjoiner);
>>> + }
>>> +
>>> /* Error out if the max bpp is less than smallest allowed valid bpp */
>>> if (bits_per_pixel < valid_dsc_bpp[0]) {
>>> DRM_DEBUG_KMS("Unsupported BPP %u, min %u\n",
>>> @@ -553,7 +571,8 @@ static u16 intel_dp_dsc_get_output_bpp(u32 link_clock,
>>> u32 lane_count,
>>> }
>>>
>>> static u8 intel_dp_dsc_get_slice_count(struct intel_dp *intel_dp,
>>> - int mode_clock, int mode_hdisplay)
>>> + int mode_
