[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [CI,1/3] drm/i915: Make exclusive awaits on i915_active optional
== Series Details == Series: series starting with [CI,1/3] drm/i915: Make exclusive awaits on i915_active optional URL : https://patchwork.freedesktop.org/series/75556/ State : success == Summary == CI Bug Log - changes from CI_DRM_8261_full -> Patchwork_17222_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17222_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_balancer@hang: - shard-tglb: [PASS][1] -> [FAIL][2] ([i915#1277]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-tglb8/igt@gem_exec_balan...@hang.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-tglb2/igt@gem_exec_balan...@hang.html * igt@gem_exec_params@invalid-bsd-ring: - shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#109276]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-iclb4/igt@gem_exec_par...@invalid-bsd-ring.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-iclb8/igt@gem_exec_par...@invalid-bsd-ring.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-iclb5/igt@i915_pm...@dc6-psr.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-iclb4/igt@i915_pm...@dc6-psr.html * igt@kms_cursor_crc@pipe-b-cursor-64x64-offscreen: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#54]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-64x64-offscreen.html * igt@kms_draw_crc@draw-method-rgb565-mmap-wc-ytiled: - shard-glk: [PASS][9] -> [FAIL][10] ([i915#52] / [i915#54]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-glk8/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-glk6/igt@kms_draw_...@draw-method-rgb565-mmap-wc-ytiled.html * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: [PASS][11] -> [FAIL][12] ([i915#46]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-glk4/igt@kms_f...@2x-flip-vs-expired-vblank.html * igt@kms_plane_alpha_blend@pipe-b-constant-alpha-min: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-skl2/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-skl6/igt@kms_plane_alpha_bl...@pipe-b-constant-alpha-min.html * igt@kms_vblank@pipe-a-ts-continuation-suspend: - shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-kbl4/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-kbl2/igt@kms_vbl...@pipe-a-ts-continuation-suspend.html * igt@kms_vblank@pipe-b-ts-continuation-suspend: - shard-apl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-apl3/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-apl4/igt@kms_vbl...@pipe-b-ts-continuation-suspend.html Possible fixes * igt@gem_ctx_persistence@engines-mixed-process@vecs0: - shard-skl: [FAIL][19] ([i915#1528]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-skl8/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-skl3/igt@gem_ctx_persistence@engines-mixed-proc...@vecs0.html * igt@gem_softpin@noreloc-s3: - shard-apl: [DMESG-WARN][21] ([i915#180] / [i915#95]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-apl4/igt@gem_soft...@noreloc-s3.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-apl8/igt@gem_soft...@noreloc-s3.html * igt@i915_suspend@sysfs-reader: - shard-apl: [DMESG-WARN][23] ([i915#180]) -> [PASS][24] +2 similar issues [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/shard-apl4/igt@i915_susp...@sysfs-reader.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/shard-apl1/igt@i915_susp...@sysfs-reader.html * igt@kms_flip@flip-vs-expired-vblank: - shard-apl: [FAIL][25]
Re: [Intel-gfx] [PATCH 2/6] i915/gvt/kvm: a NULL ->mm does not mean a thread is a kthread
On Sat, Apr 04, 2020 at 11:40:57AM +0200, Christoph Hellwig wrote:
> Use the proper API instead.
>
> Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API")
> Signed-off-by: Christoph Hellwig
> ---
> drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index 074c4efb58eb..5848400620b4 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -2037,7 +2037,7 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
> long gpa,
> struct kvmgt_guest_info *info;
> struct kvm *kvm;
> int idx, ret;
> - bool kthread = current->mm == NULL;
> + bool kthread = (current->flags & PF_KTHREAD);
>
> if (!handle_valid(handle))
> return -ESRCH;
> --
> 2.25.1
>
hi
we were removing this code. see
https://lore.kernel.org/kvm/20200313031109.7989-1-yan.y.z...@intel.com/
The implementation of vfio_dma_rw() has been in vfio next tree.
https://github.com/awilliam/linux-vfio/commit/8d46c0cca5f4dc0538173d62cd36b1119b5105bc
in vfio_dma_rw(), we still use
bool kthread = current->mm == NULL.
because if current->mm != NULL and current->flags & PF_KTHREAD, instead
of calling use_mm(), we first check if (current->mm == mm) and allow
copy_to_user() if it's true.
Do you think it's all right?
Thanks
Yan
> ___
> intel-gvt-dev mailing list
> intel-gvt-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gvt-dev
___
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 [v2,1/8] drm/i915/display: Move out code to return the digital_port of the aux ch
== Series Details == Series: series starting with [v2,1/8] drm/i915/display: Move out code to return the digital_port of the aux ch URL : https://patchwork.freedesktop.org/series/75576/ State : success == Summary == CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17226 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/index.html Known issues Here are the changes found in Patchwork_17226 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] ([i915#203]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-skl-6770hq: [PASS][3] -> [DMESG-FAIL][4] ([i915#165]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6770hq/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/fi-skl-6770hq/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@prime_vgem@basic-fence-flip: - fi-skl-6770hq: [PASS][5] -> [SKIP][6] ([fdo#109271]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6770hq/igt@prime_v...@basic-fence-flip.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/fi-skl-6770hq/igt@prime_v...@basic-fence-flip.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][7] ([i915#1158]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@hangcheck: - fi-icl-y: [INCOMPLETE][9] ([i915#1580]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8264 -> Patchwork_17226 CI-20190529: 20190529 CI_DRM_8264: e0104585f880a64d4a9b40803cf4fb51ab499f7c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5573: 9c582425d6b4fc1de9fc2ffc8015cc6f0a0d3e98 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17226: ba04f3ced69643939779e78860b0d7054875c784 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ba04f3ced696 drm/i915/tc: Do not warn when aux power well of static TC ports timeout c6c9a63090ff drm/i915/tc: Catch TC users accessing FIA registers without enable aux 08d2500517e6 drm/i915/tc/tgl: Implement TC cold sequences ec375378fe3a drm/i915/tc: Skip ref held check for TC legacy aux power wells 4492ad74909c drm/i915/tc/icl: Implement TC cold sequences c35b853ace69 drm/i915/display: Split hsw_power_well_enable() into two d3f4ac71f6b3 drm/i915/display: Add intel_legacy_aux_to_power_domain() 14654d404b1a drm/i915/display: Move out code to return the digital_port of the aux ch == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17226/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 16/17] drm: Nuke mode->private_flags
Hi Jani On 2020-04-06 02:11, Jani Nikula wrote: On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote: Hi Ville Thanks for the patch. Our understanding of private_flags was that we can use it within our drivers to handle vendor specific features. Hence we do have several features in our downstream drivers as well as some planned work based on this. This was the only method to pass around and consume the driver only information which we have been using. In the current qualcomm upstream display drivers, the only usage of the mode->private_flags is what you have removed in https://patchwork.kernel.org/patch/11473497/. However, for other projects which do not use upstream drivers yet, we have several features already which are using the mode->private_flags. We do have a plan to remove the usage of mode->private_flags for those drivers as well but its not ready yet. These downstream drivers still use the upstream drm files for compilation. So how it works is we use all the headers under include/drm and also the files under drivers/gpu/drm as-it-is from upstream but maintain our drivers on top of this. Removing this will result in compilation failures for us in the near term. Can we keep this one as-it-is and when our changes are ready to post it upstream we shall remove private_flags from the drm_modes.h If your driver were upstream, Ville would have fixed it in the process of removing private_flags. It would be part of this patch series. That is the only guarantee you get for kernel internal APIs, and you only get that guarantee for drivers in the upstream kernel. Otherwise, all bets are off. Taking all the upstream considerations into account is complicated enough. It is simply not reasonable to hold back internal kernel changes due to out-of-tree or downstream drivers. I know it is painful, but that's the cost of maintaining a driver out-of-tree. Sorry, but no. Further reading [1]. BR, Jani. [1] https://www.kernel.org/doc/html/latest/process/stable-api-nonsense.html Thanks for the response. We will plan to remove mode->private_flags in our downstream driver as well. Abhinav ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [v2,1/8] drm/i915/display: Move out code to return the digital_port of the aux ch
== Series Details == Series: series starting with [v2,1/8] drm/i915/display: Move out code to return the digital_port of the aux ch URL : https://patchwork.freedesktop.org/series/75576/ State : warning == Summary == $ dim checkpatch origin/drm-tip 14654d404b1a drm/i915/display: Move out code to return the digital_port of the aux ch d3f4ac71f6b3 drm/i915/display: Add intel_legacy_aux_to_power_domain() c35b853ace69 drm/i915/display: Split hsw_power_well_enable() into two 4492ad74909c drm/i915/tc/icl: Implement TC cold sequences -:68: WARNING:MSLEEP: msleep < 20ms can sleep for up to 20ms; see Documentation/timers/timers-howto.rst #68: FILE: drivers/gpu/drm/i915/display/intel_display_power.c:591: + msleep(1); total: 0 errors, 1 warnings, 0 checks, 166 lines checked ec375378fe3a drm/i915/tc: Skip ref held check for TC legacy aux power wells 08d2500517e6 drm/i915/tc/tgl: Implement TC cold sequences c6c9a63090ff drm/i915/tc: Catch TC users accessing FIA registers without enable aux ba04f3ced696 drm/i915/tc: Do not warn when aux power well of static TC ports timeout ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 03/17] drm: Nuke mode->vrefresh
Hi Jani
On 2020-04-06 01:32, Jani Nikula wrote:
On Fri, 03 Apr 2020, abhin...@codeaurora.org wrote:
On 2020-04-03 13:39, Ville Syrjala wrote:
diff --git a/drivers/gpu/drm/drm_modes.c
b/drivers/gpu/drm/drm_modes.c
index fec1c33b3045..e3d5f011f7bd 100644
--- a/drivers/gpu/drm/drm_modes.c
+++ b/drivers/gpu/drm/drm_modes.c
@@ -759,9 +759,7 @@ int drm_mode_vrefresh(const struct
drm_display_mode
*mode)
{
int refresh = 0;
- if (mode->vrefresh > 0)
- refresh = mode->vrefresh;
The mode->vrefresh has been replaced with calling this API in all its
usages.
However in this API, the above if statement was returning the vrefresh
if it was already
set. mode->clock is holding the pixel clock . So this will not cause
any
issues in non-compressed cases.
In case of compression like DSC, the pixel
clock will be different based on the compression ratio hence the
mode->clock will change but fps will not.
So we did have usages in our downstream driver where we would use this
API and the refresh rate
returned will be the mode->vrefresh which did not change but after
this
change for those cases it will end up returning the refresh rate
calculated using mode->clock which will result in a different value
now.
So is the recommendation that even in the case of compression
mode->clock should always hold
uncompressed pixel clock value because with this part of the change we
will now get a different value when we call this API.
Yes. The mode remains the same regardless of compression, and
compression is just an implementation detail of the transport.
You may need to maintain separate "physical port clock" and "logical
port clock" for DSC, where the latter is a function of the former and
the DSC parameters. And then you can see if your logical port clock
provides enough bandwidth for your mode. But this is up to your driver
and encoder implementation.
BR,
Jani.
Thanks for the information. We will make changes to our driver to
accommodate the changes in the
drm_mode_vrefresh API.
Thanks
Abhinav
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 4/8] drm/i915/tc/icl: Implement TC cold sequences
This is required for legacy/static TC ports as IOM is not aware of
the connection and will not trigger the TC cold exit.
Just request PCODE to exit TCCOLD is not enough as it could enter
again before driver makes use of the port, to prevent it BSpec states
that aux powerwell should be held.
So here embedding the TC cold exit sequence into ICL aux enable,
it will enable aux and then request TC cold to exit.
The TC cold block(exit and aux hold) and unblock was added to some
exported TC functions for the others and to access PHY registers,
callers should enable and keep aux powerwell enabled during access.
Also adding TC cold check and warnig in tc_port_load_fia_params() as
at this point of the driver initialization we can't request power
wells, if we get this warning we will need to figure out how to handle
it.
v2:
- moved ICL TC cold exit function to intel_display_power
- using dig_port->tc_legacy_port to only execute sequences for legacy
ports, hopefully VBTs will have this right
- fixed check to call _hsw_power_well_continue_enable()
- calling _hsw_power_well_continue_enable() unconditionally in
icl_tc_phy_aux_power_well_enable(), if needed we will surpress timeout
warnings of TC legacy ports
- only blocking TC cold around fia access
BSpec: 21750
Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1296
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
squash icl
---
.../drm/i915/display/intel_display_power.c| 22 ++-
.../drm/i915/display/intel_display_types.h| 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 64 +--
drivers/gpu/drm/i915/i915_reg.h | 1 +
4 files changed, 80 insertions(+), 8 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 62e49f06d467..1336247743c4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -575,6 +575,25 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
#define TGL_AUX_PW_TO_TC_PORT(pw_idx) ((pw_idx) - TGL_PW_CTL_IDX_AUX_TC1)
+static void icl_tc_cold_exit(struct drm_i915_private *i915)
+{
+ int ret;
+
+ do {
+ ret = sandybridge_pcode_write_timeout(i915,
+ ICL_PCODE_EXIT_TCCOLD,
+ 0, 250, 1);
+
+ } while (ret == -EAGAIN);
+
+ /* Spec states that TC cold exit can take up to 1ms to complete */
+ if (!ret)
+ msleep(1);
+
+ drm_dbg_kms(>drm, "TC cold block %s\n", ret == 0 ? "succeeded" :
+ "failed");
+}
+
static void
icl_tc_phy_aux_power_well_enable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
@@ -593,7 +612,8 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
hsw_power_well_enable_prepare(dev_priv, power_well);
- /* TODO ICL TC cold handling */
+ if (INTEL_GEN(dev_priv) == 11 && dig_port->tc_legacy_port)
+ icl_tc_cold_exit(dev_priv);
hsw_power_well_enable_complete(dev_priv, power_well);
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5a0adf14ebef..f7506ac40eb4 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -1400,6 +1400,7 @@ struct intel_digital_port {
enum intel_display_power_domain ddi_io_power_domain;
struct mutex tc_lock; /* protects the TypeC port mode */
intel_wakeref_t tc_lock_wakeref;
+ intel_wakeref_t tc_cold_wakeref;
int tc_link_refcount;
bool tc_legacy_port:1;
char tc_port_name[8];
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 9b850c11aa78..7564259d677e 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -34,6 +34,7 @@ tc_port_load_fia_params(struct drm_i915_private *i915,
if (INTEL_INFO(i915)->display.has_modular_fia) {
modular_fia = intel_uncore_read(>uncore,
PORT_TX_DFLEXDPSP(FIA1));
+ drm_WARN_ON(>drm, modular_fia == 0x);
modular_fia &= MODULAR_FIA_MASK;
} else {
modular_fia = 0;
@@ -52,6 +53,37 @@ tc_port_load_fia_params(struct drm_i915_private *i915,
}
}
+static intel_wakeref_t
+tc_cold_block(struct intel_digital_port *dig_port)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ enum intel_display_power_domain domain;
+
+ if (INTEL_GEN(i915) != 11 || !dig_port->tc_legacy_port)
+ return 0;
+
+ domain = intel_legacy_aux_to_power_domain(dig_port->aux_ch);
+
[Intel-gfx] [PATCH v2 8/8] drm/i915/tc: Do not warn when aux power well of static TC ports timeout
This is a expected timeout of static TC ports not conneceted, so
not throwing warnings that would taint CI.
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 37 +++
1 file changed, 21 insertions(+), 16 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 5d33929f3724..50af5854658e 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -284,6 +284,21 @@ static void hsw_power_well_pre_disable(struct
drm_i915_private *dev_priv,
gen8_irq_power_well_pre_disable(dev_priv, irq_pipe_mask);
}
+#define ICL_AUX_PW_TO_CH(pw_idx) \
+ ((pw_idx) - ICL_PW_CTL_IDX_AUX_A + AUX_CH_A)
+
+#define ICL_TBT_AUX_PW_TO_CH(pw_idx) \
+ ((pw_idx) - ICL_PW_CTL_IDX_AUX_TBT1 + AUX_CH_C)
+
+static enum aux_ch icl_tc_phy_aux_ch(struct drm_i915_private *dev_priv,
+struct i915_power_well *power_well)
+{
+ int pw_idx = power_well->desc->hsw.idx;
+
+ return power_well->desc->hsw.is_tc_tbt ? ICL_TBT_AUX_PW_TO_CH(pw_idx) :
+ICL_AUX_PW_TO_CH(pw_idx);
+}
+
static struct intel_digital_port *
aux_ch_to_digital_port(struct drm_i915_private *dev_priv,
enum aux_ch aux_ch)
@@ -320,11 +335,16 @@ static void hsw_wait_for_power_well_enable(struct
drm_i915_private *dev_priv,
/* Timeout for PW1:10 us, AUX:not specified, other PWs:20 us. */
if (intel_de_wait_for_set(dev_priv, regs->driver,
HSW_PWR_WELL_CTL_STATE(pw_idx), 1)) {
+ enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
+ struct intel_digital_port *dig_port =
aux_ch_to_digital_port(dev_priv, aux_ch);
+
drm_dbg_kms(_priv->drm, "%s power well enable timeout\n",
power_well->desc->name);
/* An AUX timeout is expected if the TBT DP tunnel is down. */
- drm_WARN_ON(_priv->drm, !power_well->desc->hsw.is_tc_tbt);
+ drm_WARN_ON(_priv->drm, !power_well->desc->hsw.is_tc_tbt &&
+ !(INTEL_GEN(dev_priv) == 11 &&
dig_port->tc_legacy_port));
+
}
}
@@ -520,21 +540,6 @@ icl_combo_phy_aux_power_well_disable(struct
drm_i915_private *dev_priv,
hsw_wait_for_power_well_disable(dev_priv, power_well);
}
-#define ICL_AUX_PW_TO_CH(pw_idx) \
- ((pw_idx) - ICL_PW_CTL_IDX_AUX_A + AUX_CH_A)
-
-#define ICL_TBT_AUX_PW_TO_CH(pw_idx) \
- ((pw_idx) - ICL_PW_CTL_IDX_AUX_TBT1 + AUX_CH_C)
-
-static enum aux_ch icl_tc_phy_aux_ch(struct drm_i915_private *dev_priv,
-struct i915_power_well *power_well)
-{
- int pw_idx = power_well->desc->hsw.idx;
-
- return power_well->desc->hsw.is_tc_tbt ? ICL_TBT_AUX_PW_TO_CH(pw_idx) :
-ICL_AUX_PW_TO_CH(pw_idx);
-}
-
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_RUNTIME_PM)
static u64 async_put_domains_mask(struct i915_power_domains *power_domains);
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/8] drm/i915/display: Move out code to return the digital_port of the aux ch
Moving the code to return the digital port of the aux channel also
removing the intel_phy_is_tc() to make it generic.
digital_port will be needed in icl_tc_phy_aux_power_well_enable()
so adding it as a parameter to icl_tc_port_assert_ref_held().
While at at removing the duplicated call to icl_tc_phy_aux_ch() in
icl_tc_port_assert_ref_held().
v2:
- fixed build when DRM_I915_DEBUG_RUNTIME_PM is not set
- moved to before hsw_wait_for_power_well_enable() as it will be
needed by hsw_wait_for_power_well_enable() in a future patch
Cc: You-Sheng Yang
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 69 ++-
1 file changed, 37 insertions(+), 32 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 433e5a81dd4d..f2f42b5960df 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -282,6 +282,33 @@ static void hsw_power_well_pre_disable(struct
drm_i915_private *dev_priv,
gen8_irq_power_well_pre_disable(dev_priv, irq_pipe_mask);
}
+static struct intel_digital_port *
+aux_ch_to_digital_port(struct drm_i915_private *dev_priv,
+ enum aux_ch aux_ch)
+{
+ struct intel_digital_port *dig_port = NULL;
+ struct intel_encoder *encoder;
+
+ for_each_intel_encoder(_priv->drm, encoder) {
+ /* We'll check the MST primary port */
+ if (encoder->type == INTEL_OUTPUT_DP_MST)
+ continue;
+
+ dig_port = enc_to_dig_port(encoder);
+ if (drm_WARN_ON(_priv->drm, !dig_port))
+ continue;
+
+ if (dig_port->aux_ch != aux_ch) {
+ dig_port = NULL;
+ continue;
+ }
+
+ break;
+ }
+
+ return dig_port;
+}
+
static void hsw_wait_for_power_well_enable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
@@ -501,41 +528,14 @@ static int power_well_async_ref_count(struct
drm_i915_private *dev_priv,
}
static void icl_tc_port_assert_ref_held(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
+ struct i915_power_well *power_well,
+ struct intel_digital_port *dig_port)
{
- enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
- struct intel_digital_port *dig_port = NULL;
- struct intel_encoder *encoder;
-
/* Bypass the check if all references are released asynchronously */
if (power_well_async_ref_count(dev_priv, power_well) ==
power_well->count)
return;
- aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
-
- for_each_intel_encoder(_priv->drm, encoder) {
- enum phy phy = intel_port_to_phy(dev_priv, encoder->port);
-
- if (!intel_phy_is_tc(dev_priv, phy))
- continue;
-
- /* We'll check the MST primary port */
- if (encoder->type == INTEL_OUTPUT_DP_MST)
- continue;
-
- dig_port = enc_to_dig_port(encoder);
- if (drm_WARN_ON(_priv->drm, !dig_port))
- continue;
-
- if (dig_port->aux_ch != aux_ch) {
- dig_port = NULL;
- continue;
- }
-
- break;
- }
-
if (drm_WARN_ON(_priv->drm, !dig_port))
return;
@@ -545,7 +545,8 @@ static void icl_tc_port_assert_ref_held(struct
drm_i915_private *dev_priv,
#else
static void icl_tc_port_assert_ref_held(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
+ struct i915_power_well *power_well,
+ struct intel_digital_port *dig_port)
{
}
@@ -558,9 +559,10 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
struct i915_power_well *power_well)
{
enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv, power_well);
+ struct intel_digital_port *dig_port = aux_ch_to_digital_port(dev_priv,
aux_ch);
u32 val;
- icl_tc_port_assert_ref_held(dev_priv, power_well);
+ icl_tc_port_assert_ref_held(dev_priv, power_well, dig_port);
val = intel_de_read(dev_priv, DP_AUX_CH_CTL(aux_ch));
val &= ~DP_AUX_CH_CTL_TBT_IO;
@@ -588,7 +590,10 @@ static void
icl_tc_phy_aux_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
- icl_tc_port_assert_ref_held(dev_priv, power_well);
+ enum aux_ch aux_ch = icl_tc_phy_aux_ch(dev_priv,
[Intel-gfx] [PATCH v2 7/8] drm/i915/tc: Catch TC users accessing FIA registers without enable aux
As described in "drm/i915/tc/icl: Implement TC cold sequences" users
of TC functions should held aux power well during access to avoid
read garbage due HW in TC cold state.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_tc.c | 22 --
1 file changed, 20 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_tc.c
b/drivers/gpu/drm/i915/display/intel_tc.c
index 83861653768d..e473bb4a9b0b 100644
--- a/drivers/gpu/drm/i915/display/intel_tc.c
+++ b/drivers/gpu/drm/i915/display/intel_tc.c
@@ -95,6 +95,20 @@ tc_cold_unblock(struct intel_digital_port *dig_port,
intel_wakeref_t wakeref)
intel_display_power_put_async(i915, domain, wakeref);
}
+static void
+is_tc_cold_blocked(struct intel_digital_port *dig_port)
+{
+ struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
+ bool enabled;
+
+ if (INTEL_GEN(i915) == 11 && !dig_port->tc_legacy_port)
+ return;
+
+ enabled = intel_display_power_is_enabled(i915,
+
tc_cold_get_power_domain(dig_port));
+ drm_WARN_ON(>drm, !enabled);
+}
+
u32 intel_tc_port_get_lane_mask(struct intel_digital_port *dig_port)
{
struct drm_i915_private *i915 = to_i915(dig_port->base.base.dev);
@@ -104,7 +118,7 @@ u32 intel_tc_port_get_lane_mask(struct intel_digital_port
*dig_port)
lane_mask = intel_uncore_read(uncore,
PORT_TX_DFLEXDPSP(dig_port->tc_phy_fia));
- drm_WARN_ON(>drm, lane_mask == 0x);
+ is_tc_cold_blocked(dig_port);
lane_mask &= DP_LANE_ASSIGNMENT_MASK(dig_port->tc_phy_fia_idx);
return lane_mask >> DP_LANE_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
@@ -119,7 +133,7 @@ u32 intel_tc_port_get_pin_assignment_mask(struct
intel_digital_port *dig_port)
pin_mask = intel_uncore_read(uncore,
PORT_TX_DFLEXPA1(dig_port->tc_phy_fia));
- drm_WARN_ON(>drm, pin_mask == 0x);
+ is_tc_cold_blocked(dig_port);
return (pin_mask & DP_PIN_ASSIGNMENT_MASK(dig_port->tc_phy_fia_idx)) >>
DP_PIN_ASSIGNMENT_SHIFT(dig_port->tc_phy_fia_idx);
@@ -134,6 +148,8 @@ int intel_tc_port_fia_max_lane_count(struct
intel_digital_port *dig_port)
if (dig_port->tc_mode != TC_PORT_DP_ALT)
return 4;
+ is_tc_cold_blocked(dig_port);
+
lane_mask = 0;
with_intel_display_power(i915, POWER_DOMAIN_DISPLAY_CORE, wakeref)
lane_mask = intel_tc_port_get_lane_mask(dig_port);
@@ -166,6 +182,8 @@ void intel_tc_port_set_fia_lane_count(struct
intel_digital_port *dig_port,
drm_WARN_ON(>drm,
lane_reversal && dig_port->tc_mode != TC_PORT_LEGACY);
+ is_tc_cold_blocked(dig_port);
+
val = intel_uncore_read(uncore,
PORT_TX_DFLEXDPMLE1(dig_port->tc_phy_fia));
val &= ~DFLEXDPMLE1_DPMLETC_MASK(dig_port->tc_phy_fia_idx);
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 3/8] drm/i915/display: Split hsw_power_well_enable() into two
This is a preparation for ICL TC cold exit sequences.
v2:
- renamed new functions to hsw_power_well_enable_prepare()/complete()
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 39 +++
1 file changed, 32 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 f2f42b5960df..62e49f06d467 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -380,16 +380,16 @@ static void gen9_wait_for_power_well_fuses(struct
drm_i915_private *dev_priv,
SKL_FUSE_PG_DIST_STATUS(pg), 1));
}
-static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
- struct i915_power_well *power_well)
+static void hsw_power_well_enable_prepare(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
{
const struct i915_power_well_regs *regs = power_well->desc->hsw.regs;
int pw_idx = power_well->desc->hsw.idx;
- bool wait_fuses = power_well->desc->hsw.has_fuses;
- enum skl_power_gate uninitialized_var(pg);
u32 val;
- if (wait_fuses) {
+ if (power_well->desc->hsw.has_fuses) {
+ enum skl_power_gate pg;
+
pg = INTEL_GEN(dev_priv) >= 11 ? ICL_PW_CTL_IDX_TO_PG(pw_idx) :
SKL_PW_CTL_IDX_TO_PG(pw_idx);
/*
@@ -406,25 +406,46 @@ static void hsw_power_well_enable(struct drm_i915_private
*dev_priv,
val = intel_de_read(dev_priv, regs->driver);
intel_de_write(dev_priv, regs->driver,
val | HSW_PWR_WELL_CTL_REQ(pw_idx));
+}
+
+static void hsw_power_well_enable_complete(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ int pw_idx = power_well->desc->hsw.idx;
+
hsw_wait_for_power_well_enable(dev_priv, power_well);
/* Display WA #1178: cnl */
if (IS_CANNONLAKE(dev_priv) &&
pw_idx >= GLK_PW_CTL_IDX_AUX_B &&
pw_idx <= CNL_PW_CTL_IDX_AUX_F) {
+ u32 val;
+
val = intel_de_read(dev_priv, CNL_AUX_ANAOVRD1(pw_idx));
val |= CNL_AUX_ANAOVRD1_ENABLE | CNL_AUX_ANAOVRD1_LDO_BYPASS;
intel_de_write(dev_priv, CNL_AUX_ANAOVRD1(pw_idx), val);
}
- if (wait_fuses)
+ if (power_well->desc->hsw.has_fuses) {
+ enum skl_power_gate pg;
+
+ pg = INTEL_GEN(dev_priv) >= 11 ? ICL_PW_CTL_IDX_TO_PG(pw_idx) :
+SKL_PW_CTL_IDX_TO_PG(pw_idx);
gen9_wait_for_power_well_fuses(dev_priv, pg);
+ }
hsw_power_well_post_enable(dev_priv,
power_well->desc->hsw.irq_pipe_mask,
power_well->desc->hsw.has_vga);
}
+static void hsw_power_well_enable(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ hsw_power_well_enable_prepare(dev_priv, power_well);
+ hsw_power_well_enable_complete(dev_priv, power_well);
+}
+
static void hsw_power_well_disable(struct drm_i915_private *dev_priv,
struct i915_power_well *power_well)
{
@@ -570,7 +591,11 @@ icl_tc_phy_aux_power_well_enable(struct drm_i915_private
*dev_priv,
val |= DP_AUX_CH_CTL_TBT_IO;
intel_de_write(dev_priv, DP_AUX_CH_CTL(aux_ch), val);
- hsw_power_well_enable(dev_priv, power_well);
+ hsw_power_well_enable_prepare(dev_priv, power_well);
+
+ /* TODO ICL TC cold handling */
+
+ hsw_power_well_enable_complete(dev_priv, power_well);
if (INTEL_GEN(dev_priv) >= 12 && !power_well->desc->hsw.is_tc_tbt) {
enum tc_port tc_port;
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 6/8] drm/i915/tc/tgl: Implement TC cold sequences
TC ports can enter in TCCOLD to save power and is required to request
to PCODE to exit this state before use or read to TC registers.
For TGL there is a new MBOX command to do that with a parameter to ask
PCODE to exit and block TCCOLD entry or unblock TCCOLD entry.
So adding a new power domain to reuse the refcount and only allow
TC cold when all TC ports are not in use.
v2:
- fixed missing case in intel_display_power_domain_str()
- moved tgl_tc_cold_request to intel_display_power.c
- renamed TGL_TC_COLD_OFF to TGL_TC_COLD_OFF_POWER_DOMAINS
- added all TC and TBT aux power domains to
TGL_TC_COLD_OFF_POWER_DOMAINS
BSpec: 49294
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
.../drm/i915/display/intel_display_power.c| 98 +++
.../drm/i915/display/intel_display_power.h| 1 +
drivers/gpu/drm/i915/display/intel_tc.c | 17 +++-
drivers/gpu/drm/i915/i915_reg.h | 3 +
4 files changed, 116 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c
b/drivers/gpu/drm/i915/display/intel_display_power.c
index 0383801a9acc..5d33929f3724 100644
--- a/drivers/gpu/drm/i915/display/intel_display_power.c
+++ b/drivers/gpu/drm/i915/display/intel_display_power.c
@@ -151,6 +151,8 @@ intel_display_power_domain_str(enum
intel_display_power_domain domain)
return "GT_IRQ";
case POWER_DOMAIN_DPLL_DC_OFF:
return "DPLL_DC_OFF";
+ case POWER_DOMAIN_TC_COLD_OFF:
+ return "TC_COLD_OFF";
default:
MISSING_CASE(domain);
return "?";
@@ -2858,6 +2860,21 @@ void intel_display_power_put(struct drm_i915_private
*dev_priv,
#define TGL_AUX_I_TBT6_IO_POWER_DOMAINS ( \
BIT_ULL(POWER_DOMAIN_AUX_I_TBT))
+#define TGL_TC_COLD_OFF_POWER_DOMAINS (\
+ BIT_ULL(POWER_DOMAIN_AUX_D) | \
+ BIT_ULL(POWER_DOMAIN_AUX_E) | \
+ BIT_ULL(POWER_DOMAIN_AUX_F) | \
+ BIT_ULL(POWER_DOMAIN_AUX_G) | \
+ BIT_ULL(POWER_DOMAIN_AUX_H) | \
+ BIT_ULL(POWER_DOMAIN_AUX_I) | \
+ BIT_ULL(POWER_DOMAIN_AUX_D_TBT) | \
+ BIT_ULL(POWER_DOMAIN_AUX_E_TBT) | \
+ BIT_ULL(POWER_DOMAIN_AUX_F_TBT) | \
+ BIT_ULL(POWER_DOMAIN_AUX_G_TBT) | \
+ BIT_ULL(POWER_DOMAIN_AUX_H_TBT) | \
+ BIT_ULL(POWER_DOMAIN_AUX_I_TBT) | \
+ BIT_ULL(POWER_DOMAIN_TC_COLD_OFF))
+
static const struct i915_power_well_ops i9xx_always_on_power_well_ops = {
.sync_hw = i9xx_power_well_sync_hw_noop,
.enable = i9xx_always_on_power_well_noop,
@@ -3960,6 +3977,81 @@ static const struct i915_power_well_desc
ehl_power_wells[] = {
},
};
+static void
+tgl_tc_cold_request(struct drm_i915_private *i915, bool block)
+{
+ u32 low_val, high_val;
+ u8 tries = 0;
+ int ret;
+
+ do {
+ low_val = 0;
+ high_val = block ? 0 : TGL_PCODE_EXIT_TCCOLD_DATA_H_UNBLOCK_REQ;
+
+ /*
+* Spec states that we should timeout the request after 200us
+* but the function below will timeout after 500us
+*/
+ ret = sandybridge_pcode_read(i915, TGL_PCODE_TCCOLD, _val,
+_val);
+ if (ret == 0) {
+ if (block &&
+ (low_val &
TGL_PCODE_EXIT_TCCOLD_DATA_L_EXIT_FAILED))
+ ret = -EIO;
+ else
+ break;
+ }
+
+ if (ret != -EAGAIN)
+ tries++;
+ } while (tries < 3);
+
+ drm_dbg_kms(>drm, "TC cold %sblock %s\n", block ? "" : "un",
+ ret == 0 ? "succeeded" : "failed");
+}
+
+static void
+tgl_tc_cold_off_power_well_enable(struct drm_i915_private *i915,
+ struct i915_power_well *power_well)
+{
+ tgl_tc_cold_request(i915, true);
+}
+
+static void
+tgl_tc_cold_off_power_well_disable(struct drm_i915_private *i915,
+ struct i915_power_well *power_well)
+{
+ tgl_tc_cold_request(i915, false);
+}
+
+static void
+tgl_tc_cold_off_power_well_sync_hw(struct drm_i915_private *i915,
+ struct i915_power_well *power_well)
+{
+ if (power_well->count > 0)
+ tgl_tc_cold_off_power_well_enable(i915, power_well);
+ else
+ tgl_tc_cold_off_power_well_disable(i915, power_well);
+}
+
+static bool
+tgl_tc_cold_off_power_well_is_enabled(struct drm_i915_private *dev_priv,
+ struct i915_power_well *power_well)
+{
+ /*
+* Not the correctly implementation but there is no way to just read it
+* from PCODE, so returning count to avoid state mismatch errors
+
[Intel-gfx] [PATCH v2 5/8] drm/i915/tc: Skip ref held check for TC legacy aux power wells
As part of ICL TC cold exit sequences we need to request aux power well before lock the access to TC ports, so skiping the intel_tc_port_ref_held() check for TC legacy ports. Signed-off-by: José Roberto de Souza --- drivers/gpu/drm/i915/display/intel_display_power.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c b/drivers/gpu/drm/i915/display/intel_display_power.c index 1336247743c4..0383801a9acc 100644 --- a/drivers/gpu/drm/i915/display/intel_display_power.c +++ b/drivers/gpu/drm/i915/display/intel_display_power.c @@ -560,6 +560,9 @@ static void icl_tc_port_assert_ref_held(struct drm_i915_private *dev_priv, if (drm_WARN_ON(_priv->drm, !dig_port)) return; + if (INTEL_GEN(dev_priv) == 11 && dig_port->tc_legacy_port) + return; + drm_WARN_ON(_priv->drm, !intel_tc_port_ref_held(dig_port)); } -- 2.26.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/8] drm/i915/display: Add intel_legacy_aux_to_power_domain()
This is a similar function to intel_aux_power_domain() but it do not
care about TBT ports, this will be needed by ICL TC sequences.
v2:
- renamed to intel_legacy_aux_to_power_domain()
Cc: Imre Deak
Cc: Cooper Chiou
Cc: Kai-Heng Feng
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_display.c | 14 --
drivers/gpu/drm/i915/display/intel_display.h | 2 ++
2 files changed, 14 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display.c
b/drivers/gpu/drm/i915/display/intel_display.c
index 70ec301fe6e3..a95960b71001 100644
--- a/drivers/gpu/drm/i915/display/intel_display.c
+++ b/drivers/gpu/drm/i915/display/intel_display.c
@@ -7291,7 +7291,17 @@ intel_aux_power_domain(struct intel_digital_port
*dig_port)
}
}
- switch (dig_port->aux_ch) {
+ return intel_legacy_aux_to_power_domain(dig_port->aux_ch);
+}
+
+/*
+ * Converts aux_ch to power_domain without caring about TBT ports for that use
+ * intel_aux_power_domain()
+ */
+enum intel_display_power_domain
+intel_legacy_aux_to_power_domain(enum aux_ch aux_ch)
+{
+ switch (aux_ch) {
case AUX_CH_A:
return POWER_DOMAIN_AUX_A;
case AUX_CH_B:
@@ -7307,7 +7317,7 @@ intel_aux_power_domain(struct intel_digital_port
*dig_port)
case AUX_CH_G:
return POWER_DOMAIN_AUX_G;
default:
- MISSING_CASE(dig_port->aux_ch);
+ MISSING_CASE(aux_ch);
return POWER_DOMAIN_AUX_A;
}
}
diff --git a/drivers/gpu/drm/i915/display/intel_display.h
b/drivers/gpu/drm/i915/display/intel_display.h
index cc7f287804d7..8d872ed0de36 100644
--- a/drivers/gpu/drm/i915/display/intel_display.h
+++ b/drivers/gpu/drm/i915/display/intel_display.h
@@ -583,6 +583,8 @@ void hsw_disable_ips(const struct intel_crtc_state
*crtc_state);
enum intel_display_power_domain intel_port_to_power_domain(enum port port);
enum intel_display_power_domain
intel_aux_power_domain(struct intel_digital_port *dig_port);
+enum intel_display_power_domain
+intel_legacy_aux_to_power_domain(enum aux_ch aux_ch);
void intel_mode_from_pipe_config(struct drm_display_mode *mode,
struct intel_crtc_state *pipe_config);
void intel_crtc_arm_fifo_underrun(struct intel_crtc *crtc,
--
2.26.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/3] drm/i915: introduce a mechanism to extend execbuf2
== Series Details == Series: series starting with [1/3] drm/i915: introduce a mechanism to extend execbuf2 URL : https://patchwork.freedesktop.org/series/75570/ State : success == Summary == CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17225 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17225/index.html Known issues Here are the changes found in Patchwork_17225 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@basic-rte: - fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([i915#189]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-icl-dsi/igt@i915_pm_...@basic-rte.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17225/fi-icl-dsi/igt@i915_pm_...@basic-rte.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][3] ([i915#1158]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17225/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@hangcheck: - fi-icl-y: [INCOMPLETE][5] ([i915#1580]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17225/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 [i915#189]: https://gitlab.freedesktop.org/drm/intel/issues/189 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8264 -> Patchwork_17225 CI-20190529: 20190529 CI_DRM_8264: e0104585f880a64d4a9b40803cf4fb51ab499f7c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5573: 9c582425d6b4fc1de9fc2ffc8015cc6f0a0d3e98 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17225: afdb9ac918aca5d4a603ec3d33e2b4932e3dc1ca @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == afdb9ac918ac drm/i915: peel dma-fence-chains wait fences 26b10e8e5551 drm/i915: add syncobj timeline support 296bd5133612 drm/i915: introduce a mechanism to extend execbuf2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17225/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915: introduce a mechanism to extend execbuf2
== Series Details == Series: series starting with [1/3] drm/i915: introduce a mechanism to extend execbuf2 URL : https://patchwork.freedesktop.org/series/75570/ State : warning == Summary == $ dim checkpatch origin/drm-tip 296bd5133612 drm/i915: introduce a mechanism to extend execbuf2 -:141: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #141: FILE: include/uapi/drm/i915_drm.h:1204: +#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_USE_EXTENSIONS<<1)) ^ total: 0 errors, 0 warnings, 1 checks, 113 lines checked 26b10e8e5551 drm/i915: add syncobj timeline support -:26: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #26: https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html -:34: ERROR:BAD_SIGN_OFF: Unrecognized email address: 'Venkata Sandeep Dhanalakota ' #34: Signed-off-by: Venkata Sandeep Dhanalakota -:622: WARNING:NO_AUTHOR_SIGN_OFF: Missing Signed-off-by: line by nominal patch author 'Venkata Sandeep Dhanalakota ' total: 1 errors, 2 warnings, 0 checks, 551 lines checked afdb9ac918ac drm/i915: peel dma-fence-chains wait fences ___ 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 [v2,1/2] drm/i915/dp_mst: Cast intel_connector->port as drm_dp_mst_port
== Series Details == Series: series starting with [v2,1/2] drm/i915/dp_mst: Cast intel_connector->port as drm_dp_mst_port URL : https://patchwork.freedesktop.org/series/75569/ State : success == Summary == CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17224 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17224/index.html Known issues Here are the changes found in Patchwork_17224 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][1] ([i915#1158]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17224/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@hangcheck: - fi-icl-y: [INCOMPLETE][3] ([i915#1580]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17224/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 Participating hosts (53 -> 45) -- Additional (1): fi-kbl-7560u Missing(9): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-skl-lmem fi-byt-clapper fi-bdw-samus fi-kbl-r Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8264 -> Patchwork_17224 CI-20190529: 20190529 CI_DRM_8264: e0104585f880a64d4a9b40803cf4fb51ab499f7c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5573: 9c582425d6b4fc1de9fc2ffc8015cc6f0a0d3e98 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17224: 1074d40fdfd265882144a6a7d878d8ed066151c1 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 1074d40fdfd2 drm/dp_mst: Remove drm_dp_mst_has_audio() 06b887718d43 drm/i915/dp_mst: Cast intel_connector->port as drm_dp_mst_port == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17224/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 6/6] kernel: set USER_DS in kthread_use_mm
On Sat, Apr 04, 2020 at 11:41:01AM +0200, Christoph Hellwig wrote:
> Some architectures like arm64 and s390 require USER_DS to be set for
> kernel threads to access user address space, which is the whole purpose
> of kthread_use_mm, but other like x86 don't. That has lead to a huge
> mess where some callers are fixed up once they are tested on said
> architectures, while others linger around and yet other like io_uring
> try to do "clever" optimizations for what usually is just a trivial
> asignment to a member in the thread_struct for most architectures.
>
> Make kthread_use_mm set USER_DS, and kthread_unuse_mm restore to the
> previous value instead.
>
> Signed-off-by: Christoph Hellwig
I'm ok with vhost bits:
Acked-by: Michael S. Tsirkin
> ---
> drivers/usb/gadget/function/f_fs.c | 4
> drivers/vhost/vhost.c | 3 ---
> fs/io-wq.c | 8 ++--
> fs/io_uring.c | 4
> kernel/kthread.c | 6 ++
> 5 files changed, 8 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index d9e48bd7c692..a1198f4c527c 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -824,13 +824,9 @@ static void ffs_user_copy_worker(struct work_struct
> *work)
> bool kiocb_has_eventfd = io_data->kiocb->ki_flags & IOCB_EVENTFD;
>
> if (io_data->read && ret > 0) {
> - mm_segment_t oldfs = get_fs();
> -
> - set_fs(USER_DS);
> kthread_use_mm(io_data->mm);
> ret = ffs_copy_to_iter(io_data->buf, ret, _data->data);
> kthread_unuse_mm(io_data->mm);
> - set_fs(oldfs);
> }
>
> io_data->kiocb->ki_complete(io_data->kiocb, ret, ret);
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 1787d426a956..b5229ae01d3b 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -333,9 +333,7 @@ static int vhost_worker(void *data)
> struct vhost_dev *dev = data;
> struct vhost_work *work, *work_next;
> struct llist_node *node;
> - mm_segment_t oldfs = get_fs();
>
> - set_fs(USER_DS);
> kthread_use_mm(dev->mm);
>
> for (;;) {
> @@ -365,7 +363,6 @@ static int vhost_worker(void *data)
> }
> }
> kthread_unuse_mm(dev->mm);
> - set_fs(oldfs);
> return 0;
> }
>
> diff --git a/fs/io-wq.c b/fs/io-wq.c
> index 83c2868eff2a..75cc2f31816d 100644
> --- a/fs/io-wq.c
> +++ b/fs/io-wq.c
> @@ -168,7 +168,6 @@ static bool __io_worker_unuse(struct io_wqe *wqe, struct
> io_worker *worker)
> dropped_lock = true;
> }
> __set_current_state(TASK_RUNNING);
> - set_fs(KERNEL_DS);
> kthread_unuse_mm(worker->mm);
> mmput(worker->mm);
> worker->mm = NULL;
> @@ -420,14 +419,11 @@ static void io_wq_switch_mm(struct io_worker *worker,
> struct io_wq_work *work)
> mmput(worker->mm);
> worker->mm = NULL;
> }
> - if (!work->mm) {
> - set_fs(KERNEL_DS);
> + if (!work->mm)
> return;
> - }
> +
> if (mmget_not_zero(work->mm)) {
> kthread_use_mm(work->mm);
> - if (!worker->mm)
> - set_fs(USER_DS);
> worker->mm = work->mm;
> /* hang on to this mm */
> work->mm = NULL;
> diff --git a/fs/io_uring.c b/fs/io_uring.c
> index 367406381044..c332a34e8b34 100644
> --- a/fs/io_uring.c
> +++ b/fs/io_uring.c
> @@ -5871,15 +5871,12 @@ static int io_sq_thread(void *data)
> struct io_ring_ctx *ctx = data;
> struct mm_struct *cur_mm = NULL;
> const struct cred *old_cred;
> - mm_segment_t old_fs;
> DEFINE_WAIT(wait);
> unsigned long timeout;
> int ret = 0;
>
> complete(>completions[1]);
>
> - old_fs = get_fs();
> - set_fs(USER_DS);
> old_cred = override_creds(ctx->creds);
>
> timeout = jiffies + ctx->sq_thread_idle;
> @@ -5985,7 +5982,6 @@ static int io_sq_thread(void *data)
> if (current->task_works)
> task_work_run();
>
> - set_fs(old_fs);
> if (cur_mm) {
> kthread_unuse_mm(cur_mm);
> mmput(cur_mm);
> diff --git a/kernel/kthread.c b/kernel/kthread.c
> index 316db17f6b4f..9e27d01b6d78 100644
> --- a/kernel/kthread.c
> +++ b/kernel/kthread.c
> @@ -52,6 +52,7 @@ struct kthread {
> unsigned long flags;
> unsigned int cpu;
> void *data;
> + mm_segment_t oldfs;
> struct completion parked;
> struct completion exited;
> #ifdef CONFIG_BLK_CGROUP
> @@ -1235,6 +1236,9 @@ void kthread_use_mm(struct mm_struct *mm)
>
> if (active_mm != mm)
> mmdrop(active_mm);
> +
> + to_kthread(tsk)->oldfs = get_fs();
> + set_fs(USER_DS);
> }
>
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Apply more mb() around clflush relocation paths
== Series Details == Series: drm/i915/gem: Apply more mb() around clflush relocation paths URL : https://patchwork.freedesktop.org/series/75558/ State : success == Summary == CI Bug Log - changes from CI_DRM_8264 -> Patchwork_17223 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/index.html Known issues Here are the changes found in Patchwork_17223 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] ([i915#203]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6770hq/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/fi-skl-6770hq/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@basic-pci-d3-state: - fi-skl-6770hq: [PASS][3] -> [SKIP][4] ([fdo#109271]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6770hq/igt@i915_pm_...@basic-pci-d3-state.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/fi-skl-6770hq/igt@i915_pm_...@basic-pci-d3-state.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-skl-6770hq: [PASS][5] -> [DMESG-FAIL][6] ([i915#165]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-skl-6770hq/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/fi-skl-6770hq/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [FAIL][7] ([i915#1158]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@hangcheck: - fi-icl-y: [INCOMPLETE][9] ([i915#1580]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8264/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/fi-icl-y/igt@i915_selftest@l...@hangcheck.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 [i915#165]: https://gitlab.freedesktop.org/drm/intel/issues/165 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 Participating hosts (53 -> 45) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bsw-nick fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8264 -> Patchwork_17223 CI-20190529: 20190529 CI_DRM_8264: e0104585f880a64d4a9b40803cf4fb51ab499f7c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5573: 9c582425d6b4fc1de9fc2ffc8015cc6f0a0d3e98 @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17223: 0e6160631516555fbf01aed3e3d15925c16ed3f0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0e6160631516 drm/i915/gem: Apply more mb() around clflush relocation paths == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17223/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for drm/i915/gem: Apply more mb() around clflush relocation paths
== Series Details == Series: drm/i915/gem: Apply more mb() around clflush relocation paths URL : https://patchwork.freedesktop.org/series/75558/ State : warning == Summary == $ dim checkpatch origin/drm-tip 0e6160631516 drm/i915/gem: Apply more mb() around clflush relocation paths -:24: WARNING:MEMORY_BARRIER: memory barrier without comment #24: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1041: + mb(); -:41: WARNING:MEMORY_BARRIER: memory barrier without comment #41: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1063: + mb(); -:52: WARNING:MEMORY_BARRIER: memory barrier without comment #52: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1170: + mb(); total: 0 errors, 3 warnings, 0 checks, 36 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/18] drm/i915/display/ddi: Prefer drm_WARN* over WARN*
Hi Pankaj,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200406]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Pankaj-Bharadiya/Prefer-drm_WARN-over-WARN/20200406-210932
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-f002-20200406 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
a43e23360657e3df82af6b96b403d1a5a3174744)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/intel_ddi.c:3624:14: error: use of undeclared
>> identifier 'state'
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
^
>> drivers/gpu/drm/i915/display/intel_ddi.c:3624:14: error: use of undeclared
>> identifier 'state'
2 errors generated.
vim +/state +3624 drivers/gpu/drm/i915/display/intel_ddi.c
3619
3620 static void intel_enable_ddi(struct intel_encoder *encoder,
3621 const struct intel_crtc_state *crtc_state,
3622 const struct drm_connector_state
*conn_state)
3623 {
> 3624 drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
3625
3626 intel_enable_pipe(crtc_state);
3627
3628 intel_crtc_vblank_on(crtc_state);
3629
3630 if (intel_crtc_has_type(crtc_state, INTEL_OUTPUT_HDMI))
3631 intel_enable_ddi_hdmi(encoder, crtc_state, conn_state);
3632 else
3633 intel_enable_ddi_dp(encoder, crtc_state, conn_state);
3634
3635 /* Enable hdcp if it's desired */
3636 if (conn_state->content_protection ==
3637 DRM_MODE_CONTENT_PROTECTION_DESIRED)
3638
intel_hdcp_enable(to_intel_connector(conn_state->connector),
3639crtc_state->cpu_transcoder,
3640(u8)conn_state->hdcp_content_type);
3641 }
3642
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: add syncobj timeline support
Introduces a new parameters to execbuf so that we can specify syncobj
handles as well as timeline points.
v2: Reuse i915_user_extension_fn
v3: Check that the chained extension is only present once (Chris)
v4: Check that dma_fence_chain_find_seqno returns a non NULL fence
(Lionel)
v5: Use BIT_ULL (Chris)
v6: Fix issue with already signaled timeline points,
dma_fence_chain_find_seqno() setting fence to NULL (Chris)
v7: Report ENOENT with invalid syncobj handle (Lionel)
v8: Check for out of order timeline point insertion (Chris)
v9: After explanations on
https://lists.freedesktop.org/archives/dri-devel/2019-August/229287.html
drop the ordering check from v8 (Lionel)
v10: Set first extension enum item to 1 (Jason)
v11: Add wait on previous sync points in timelines (Sandeep)
Signed-off-by: Lionel Landwerlin
Signed-off-by: Venkata Sandeep Dhanalakota
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 312 ++
drivers/gpu/drm/i915/i915_drv.c | 3 +-
drivers/gpu/drm/i915/i915_getparam.c | 1 +
include/uapi/drm/i915_drm.h | 38 +++
4 files changed, 296 insertions(+), 58 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 16831f715daa..4cb4cd035daa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -230,6 +230,13 @@ enum {
* the batchbuffer in trusted mode, otherwise the ioctl is rejected.
*/
+struct i915_eb_fences {
+ struct drm_syncobj *syncobj; /* Use with ptr_mask_bits() */
+ struct dma_fence *dma_fence;
+ u64 value;
+ struct dma_fence_chain *chain_fence;
+};
+
struct i915_execbuffer {
struct drm_i915_private *i915; /** i915 backpointer */
struct drm_file *file; /** per-file lookup tables and limits */
@@ -292,6 +299,7 @@ struct i915_execbuffer {
struct {
u64 flags; /** Available extensions parameters */
+ struct drm_i915_gem_execbuffer_ext_timeline_fences
timeline_fences;
} extensions;
};
@@ -2244,67 +2252,219 @@ eb_pin_engine(struct i915_execbuffer *eb,
}
static void
-__free_fence_array(struct drm_syncobj **fences, unsigned int n)
+__free_fence_array(struct i915_eb_fences *fences, unsigned int n)
{
- while (n--)
- drm_syncobj_put(ptr_mask_bits(fences[n], 2));
+ while (n--) {
+ drm_syncobj_put(ptr_mask_bits(fences[n].syncobj, 2));
+ dma_fence_put(fences[n].dma_fence);
+ kfree(fences[n].chain_fence);
+ }
kvfree(fences);
}
-static struct drm_syncobj **
-get_fence_array(struct drm_i915_gem_execbuffer2 *args,
- struct drm_file *file)
+static struct i915_eb_fences *
+get_timeline_fence_array(struct i915_execbuffer *eb, int *out_n_fences)
+{
+ struct drm_i915_gem_execbuffer_ext_timeline_fences *timeline_fences =
+ >extensions.timeline_fences;
+ struct drm_i915_gem_exec_fence __user *user_fences;
+ struct i915_eb_fences *fences;
+ u64 __user *user_values;
+ u64 num_fences, num_user_fences = timeline_fences->fence_count;
+ unsigned long n;
+ int err = 0;
+
+ /* Check multiplication overflow for access_ok() and kvmalloc_array() */
+ BUILD_BUG_ON(sizeof(size_t) > sizeof(unsigned long));
+ if (num_user_fences > min_t(unsigned long,
+ ULONG_MAX / sizeof(*user_fences),
+ SIZE_MAX / sizeof(*fences)))
+ return ERR_PTR(-EINVAL);
+
+ user_fences = u64_to_user_ptr(timeline_fences->handles_ptr);
+ if (!access_ok(user_fences, num_user_fences * sizeof(*user_fences)))
+ return ERR_PTR(-EFAULT);
+
+ user_values = u64_to_user_ptr(timeline_fences->values_ptr);
+ if (!access_ok(user_values, num_user_fences * sizeof(*user_values)))
+ return ERR_PTR(-EFAULT);
+
+ fences = kvmalloc_array(num_user_fences, sizeof(*fences),
+ __GFP_NOWARN | GFP_KERNEL);
+ if (!fences)
+ return ERR_PTR(-ENOMEM);
+
+ BUILD_BUG_ON(~(ARCH_KMALLOC_MINALIGN - 1) &
+~__I915_EXEC_FENCE_UNKNOWN_FLAGS);
+
+ for (n = 0, num_fences = 0; n < timeline_fences->fence_count; n++) {
+ struct drm_i915_gem_exec_fence user_fence;
+ struct drm_syncobj *syncobj;
+ struct dma_fence *fence = NULL;
+ u64 point;
+
+ if (__copy_from_user(_fence, user_fences++,
sizeof(user_fence))) {
+ err = -EFAULT;
+ goto err;
+ }
+
+ if (user_fence.flags & __I915_EXEC_FENCE_UNKNOWN_FLAGS) {
+ err = -EINVAL;
+ goto err;
+ }
+
+ if (__get_user(point, user_values++)) {
+
[Intel-gfx] [PATCH 1/3] drm/i915: introduce a mechanism to extend execbuf2
From: Lionel Landwerlin
We're planning to use this for a couple of new feature where we need
to provide additional parameters to execbuf.
v2: Check for invalid flags in execbuffer2 (Lionel)
v3: Rename I915_EXEC_EXT -> I915_EXEC_USE_EXTENSIONS (Chris)
Signed-off-by: Lionel Landwerlin
Reviewed-by: Chris Wilson (v1)
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 ++-
include/uapi/drm/i915_drm.h | 26 +++--
2 files changed, 61 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9d11bad74e9a..16831f715daa 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -26,6 +26,7 @@
#include "i915_gem_ioctls.h"
#include "i915_sw_fence_work.h"
#include "i915_trace.h"
+#include "i915_user_extensions.h"
struct eb_vma {
struct i915_vma *vma;
@@ -288,6 +289,10 @@ struct i915_execbuffer {
int lut_size;
struct hlist_head *buckets; /** ht for relocation handles */
struct eb_vma_array *array;
+
+ struct {
+ u64 flags; /** Available extensions parameters */
+ } extensions;
};
static inline bool eb_use_cmdparser(const struct i915_execbuffer *eb)
@@ -1698,7 +1703,8 @@ static int i915_gem_check_execbuffer(struct
drm_i915_gem_execbuffer2 *exec)
return -EINVAL;
/* Kernel clipping was a DRI1 misfeature */
- if (!(exec->flags & I915_EXEC_FENCE_ARRAY)) {
+ if (!(exec->flags & (I915_EXEC_FENCE_ARRAY |
+I915_EXEC_USE_EXTENSIONS))) {
if (exec->num_cliprects || exec->cliprects_ptr)
return -EINVAL;
}
@@ -2431,6 +2437,33 @@ static void eb_request_add(struct i915_execbuffer *eb)
mutex_unlock(>mutex);
}
+static const i915_user_extension_fn execbuf_extensions[] = {
+};
+
+static int
+parse_execbuf2_extensions(struct drm_i915_gem_execbuffer2 *args,
+ struct i915_execbuffer *eb)
+{
+ eb->extensions.flags = 0;
+
+ if (!(args->flags & I915_EXEC_USE_EXTENSIONS))
+ return 0;
+
+ /* The execbuf2 extension mechanism reuses cliprects_ptr. So we cannot
+* have another flag also using it at the same time.
+*/
+ if (eb->args->flags & I915_EXEC_FENCE_ARRAY)
+ return -EINVAL;
+
+ if (args->num_cliprects != 0)
+ return -EINVAL;
+
+ return i915_user_extensions(u64_to_user_ptr(args->cliprects_ptr),
+ execbuf_extensions,
+ ARRAY_SIZE(execbuf_extensions),
+ eb);
+}
+
static int
i915_gem_do_execbuffer(struct drm_device *dev,
struct drm_file *file,
@@ -2484,6 +2517,10 @@ i915_gem_do_execbuffer(struct drm_device *dev,
if (args->flags & I915_EXEC_IS_PINNED)
eb.batch_flags |= I915_DISPATCH_PINNED;
+ err = parse_execbuf2_extensions(args, );
+ if (err)
+ return err;
+
if (args->flags & I915_EXEC_FENCE_IN) {
in_fence = sync_file_get_fence(lower_32_bits(args->rsvd2));
if (!in_fence)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..7ea38aa6502c 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1046,6 +1046,10 @@ struct drm_i915_gem_exec_fence {
__u32 flags;
};
+enum drm_i915_gem_execbuffer_ext {
+ DRM_I915_GEM_EXECBUFFER_EXT_MAX /* non-ABI */
+};
+
struct drm_i915_gem_execbuffer2 {
/**
* List of gem_exec_object2 structs
@@ -1062,8 +1066,15 @@ struct drm_i915_gem_execbuffer2 {
__u32 num_cliprects;
/**
* This is a struct drm_clip_rect *cliprects if I915_EXEC_FENCE_ARRAY
-* is not set. If I915_EXEC_FENCE_ARRAY is set, then this is a
-* struct drm_i915_gem_exec_fence *fences.
+* & I915_EXEC_USE_EXTENSIONS are not set.
+*
+* If I915_EXEC_FENCE_ARRAY is set, then this is a pointer to an array
+* of struct drm_i915_gem_exec_fence and num_cliprects is the length
+* of the array.
+*
+* If I915_EXEC_USE_EXTENSIONS is set, then this is a pointer to a
+* single struct drm_i915_gem_base_execbuffer_ext and num_cliprects is
+* 0.
*/
__u64 cliprects_ptr;
#define I915_EXEC_RING_MASK (0x3f)
@@ -1181,7 +1192,16 @@ struct drm_i915_gem_execbuffer2 {
*/
#define I915_EXEC_FENCE_SUBMIT (1 << 20)
-#define __I915_EXEC_UNKNOWN_FLAGS (-(I915_EXEC_FENCE_SUBMIT << 1))
+/*
+ * Setting I915_EXEC_USE_EXTENSIONS implies that
+ * drm_i915_gem_execbuffer2.cliprects_ptr is treated as a pointer to an linked
+ * list of i915_user_extension. Each i915_user_extension node is the base of a
+ * larger structure. The list of
[Intel-gfx] [PATCH v2 1/2] drm/i915/dp_mst: Cast intel_connector->port as drm_dp_mst_port
The only reason for having this cast as void * before was because we
originally needed to use drm_dp_mst_get_port_validated() and friends in
order to (attempt to) safely access MST ports. However, we've since
improved how reference counting works with ports and mstbs such that we
can now rely on drm_dp_mst_port structs remaining in memory for as long
as the driver needs. This means we don't really need to cast this as
void* anymore, and can just access the struct directly.
We'll also need this for the next commit, so that we can remove
drm_dp_mst_port_has_audio().
Signed-off-by: Lyude Paul
Reviewed-by: Sean Paul
---
drivers/gpu/drm/i915/display/intel_display_types.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
b/drivers/gpu/drm/i915/display/intel_display_types.h
index 5a0adf14ebef..0ddc98afe252 100644
--- a/drivers/gpu/drm/i915/display/intel_display_types.h
+++ b/drivers/gpu/drm/i915/display/intel_display_types.h
@@ -438,7 +438,7 @@ struct intel_connector {
state of connector->polled in case hotplug storm detection changes
it */
u8 polled;
- void *port; /* store this opaque as its illegal to dereference it */
+ struct drm_dp_mst_port *port;
struct intel_dp *mst_port;
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/2] drm/dp_mst: Remove drm_dp_mst_has_audio()
Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
made sense back when we still had to validate ports before accessing
them in order to (attempt to) avoid NULL dereferences. Since we have
proper reference counting that guarantees we always can safely access
the MST port, there's no use in keeping this function around as all it
does is validate the port pointer before checking the audio status.
Note - drm_dp_mst_port->has_audio is technically protected by
drm_device->mode_config.connection_mutex, since it's only ever updated
from drm_dp_mst_get_edid(). Additionally, we change the declaration for
port in struct intel_connector to be properly typed, so we can directly
access it.
Changes since v1:
* Change type of intel_connector->port in a separate patch - Sean Paul
Cc: "Lee, Shawn C"
Reviewed-by: Sean Paul
Signed-off-by: Lyude Paul
---
drivers/gpu/drm/drm_dp_mst_topology.c | 21 ---
.../drm/i915/display/intel_display_debugfs.c | 10 ++---
drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +--
include/drm/drm_dp_mst_helper.h | 2 --
4 files changed, 3 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 5b205aea58d4..8289d59b62da 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -4063,27 +4063,6 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
}
EXPORT_SYMBOL(drm_dp_mst_detect_port);
-/**
- * drm_dp_mst_port_has_audio() - Check whether port has audio capability or not
- * @mgr: manager for this port
- * @port: unverified pointer to a port.
- *
- * This returns whether the port supports audio or not.
- */
-bool drm_dp_mst_port_has_audio(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_dp_mst_port *port)
-{
- bool ret = false;
-
- port = drm_dp_mst_topology_get_port_validated(mgr, port);
- if (!port)
- return ret;
- ret = port->has_audio;
- drm_dp_mst_topology_put_port(port);
- return ret;
-}
-EXPORT_SYMBOL(drm_dp_mst_port_has_audio);
-
/**
* drm_dp_mst_get_edid() - get EDID for an MST port
* @connector: toplevel connector to get EDID for
diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
index 424f4e52f783..9f736420d83f 100644
--- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
+++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
@@ -631,15 +631,9 @@ static void intel_dp_info(struct seq_file *m,
}
static void intel_dp_mst_info(struct seq_file *m,
- struct intel_connector *intel_connector)
+ struct intel_connector *intel_connector)
{
- struct intel_encoder *intel_encoder =
intel_attached_encoder(intel_connector);
- struct intel_dp_mst_encoder *intel_mst =
- enc_to_mst(intel_encoder);
- struct intel_digital_port *intel_dig_port = intel_mst->primary;
- struct intel_dp *intel_dp = _dig_port->dp;
- bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
- intel_connector->port);
+ bool has_audio = intel_connector->port->has_audio;
seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
}
diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
b/drivers/gpu/drm/i915/display/intel_dp_mst.c
index 61605eb8c2af..c35efc9e628d 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
@@ -114,8 +114,7 @@ static int intel_dp_mst_compute_config(struct intel_encoder
*encoder,
if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
pipe_config->has_audio =
- drm_dp_mst_port_has_audio(_dp->mst_mgr,
- connector->port);
+ connector->port->has_audio;
else
pipe_config->has_audio =
intel_conn_state->force_audio == HDMI_AUDIO_ON;
diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h
index 7af51c947b81..2d7c26592c05 100644
--- a/include/drm/drm_dp_mst_helper.h
+++ b/include/drm/drm_dp_mst_helper.h
@@ -732,8 +732,6 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_mst_port *port);
-bool drm_dp_mst_port_has_audio(struct drm_dp_mst_topology_mgr *mgr,
- struct drm_dp_mst_port *port);
struct edid *drm_dp_mst_get_edid(struct drm_connector *connector, struct
drm_dp_mst_topology_mgr *mgr, struct drm_dp_mst_port *port);
--
2.25.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915: peel dma-fence-chains wait fences
From: Lionel Landwerlin
To allow faster engine to engine synchronization, peel the layer of
dma-fence-chain to expose potential i915 fences so that the
i915-request code can emit HW semaphore wait/signal operations in the
ring which is faster than waking up the host to submit unblocked
workloads after interrupt notification.
Signed-off-by: Lionel Landwerlin
---
.../gpu/drm/i915/gem/i915_gem_execbuffer.c| 39 +--
1 file changed, 35 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 4cb4cd035daa..9b01f7c51b65 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -2504,6 +2504,7 @@ await_fence_array(struct i915_execbuffer *eb,
for (n = 0; n < nfences; n++) {
struct drm_syncobj *syncobj;
+ struct dma_fence_chain *chain;
unsigned int flags;
syncobj = ptr_unpack_bits(fences[n].syncobj, , 2);
@@ -2511,10 +2512,40 @@ await_fence_array(struct i915_execbuffer *eb,
if (!fences[n].dma_fence)
continue;
- err = i915_request_await_dma_fence(eb->request,
- fences[n].dma_fence);
- if (err < 0)
- return err;
+ /*
+* If we're dealing with a dma-fence-chain, peel the chain by
+* adding all of the unsignaled fences
+* (dma_fence_chain_for_each does that for us) the chain
+* points to.
+*
+* This enables us to identify waits on i915 fences and allows
+* for faster engine-to-engine synchronization using HW
+* semaphores.
+*/
+ chain = to_dma_fence_chain(fences[n].dma_fence);
+ if (chain) {
+ struct dma_fence *iter;
+
+ dma_fence_chain_for_each(iter, fences[n].dma_fence) {
+ struct dma_fence_chain *iter_chain =
+ to_dma_fence_chain(iter);
+
+ GEM_BUG_ON(!iter_chain);
+
+ err = i915_request_await_dma_fence(eb->request,
+
iter_chain->fence);
+ if (err < 0) {
+ dma_fence_put(iter);
+ return err;
+ }
+ }
+
+ } else {
+ err = i915_request_await_dma_fence(eb->request,
+ fences[n].dma_fence);
+ if (err < 0)
+ return err;
+ }
}
return 0;
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Prefer drm_WARN* over WARN* (rev2)
== Series Details == Series: Prefer drm_WARN* over WARN* (rev2) URL : https://patchwork.freedesktop.org/series/75543/ State : success == Summary == CI Bug Log - changes from CI_DRM_8260_full -> Patchwork_17221_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17221_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_params@invalid-bsd-ring: - shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#109276]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-iclb2/igt@gem_exec_par...@invalid-bsd-ring.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-iclb3/igt@gem_exec_par...@invalid-bsd-ring.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180] / [i915#95]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl4/igt@gem_soft...@noreloc-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-apl4/igt@gem_soft...@noreloc-s3.html * igt@i915_pm_dc@dc6-psr: - shard-iclb: [PASS][5] -> [FAIL][6] ([i915#454]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-iclb1/igt@i915_pm...@dc6-psr.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-iclb6/igt@i915_pm...@dc6-psr.html - shard-skl: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl3/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-skl7/igt@i915_pm...@dc6-psr.html * igt@i915_suspend@forcewake: - shard-kbl: [PASS][9] -> [DMESG-WARN][10] ([i915#180]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl1/igt@i915_susp...@forcewake.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-kbl2/igt@i915_susp...@forcewake.html * igt@kms_plane_alpha_blend@pipe-a-coverage-7efc: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#108145] / [i915#265]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl10/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-skl1/igt@kms_plane_alpha_bl...@pipe-a-coverage-7efc.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][13] -> [SKIP][14] ([fdo#109441]) +1 similar issue [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-iclb3/igt@kms_psr@psr2_sprite_render.html Possible fixes * igt@gem_media_fill: - shard-kbl: [DMESG-WARN][15] ([i915#165]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl2/igt@gem_media_fill.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-kbl4/igt@gem_media_fill.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [DMESG-WARN][17] ([i915#180] / [i915#93] / [i915#95]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl6/igt@gem_soft...@noreloc-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-kbl6/igt@gem_soft...@noreloc-s3.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [DMESG-WARN][19] ([i915#716]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-glk6/igt@gen9_exec_pa...@allowed-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-glk7/igt@gen9_exec_pa...@allowed-all.html * igt@kms_color@pipe-b-ctm-0-5: - shard-kbl: [DMESG-WARN][21] ([i915#78]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl2/igt@kms_co...@pipe-b-ctm-0-5.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-kbl4/igt@kms_co...@pipe-b-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [FAIL][23] ([i915#54] / [i915#95]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_dp_aux_dev: - shard-iclb: [DMESG-FAIL][25] ([i915#1645]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-iclb7/igt@kms_dp_aux_dev.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/shard-iclb7/igt@kms_dp_aux_dev.html * igt@kms_dp_dsc@basic-dsc-enable-edp: - shard-iclb: [SKIP][27] ([fdo#109349]) -> [PASS][28] [27]:
Re: [Intel-gfx] [PATCH] drm/dp_mst: Remove drm_dp_mst_has_audio()
On Fri, Apr 3, 2020 at 6:23 PM Lyude Paul wrote:
>
> Drive-by fix I noticed the other day - drm_dp_mst_has_audio() only ever
> made sense back when we still had to validate ports before accessing
> them in order to (attempt to) avoid NULL dereferences. Since we have
> proper reference counting that guarantees we always can safely access
> the MST port, there's no use in keeping this function around as all it
> does is validate the port pointer before checking the audio status.
>
> Note - drm_dp_mst_port->has_audio is technically protected by
> drm_device->mode_config.connection_mutex, since it's only ever updated
> from drm_dp_mst_get_edid(). Additionally, we change the declaration for
> port in struct intel_connector to be properly typed, so we can directly
> access it.
>
This is kind of burying the lede. I'd almost prefer a 2 patch series:
drm/i915: Allow connectors to directly access drm_dp_mst_port
drm/dp_mst: Remove unused drm_dp_mst_port_has_audio()
That way if anyone objects to the idea of accessing mst_port directly
from i915 driver, it's more obvious from the patch subject.
Nitpicks aside, the code looks good to me, it's a nice cleanup!
Reviewed-by: Sean Paul
> Cc: "Lee, Shawn C"
> Cc: Sean Paul
> Signed-off-by: Lyude Paul
> ---
> drivers/gpu/drm/drm_dp_mst_topology.c | 21 ---
> .../drm/i915/display/intel_display_debugfs.c | 10 ++---
> .../drm/i915/display/intel_display_types.h| 2 +-
> drivers/gpu/drm/i915/display/intel_dp_mst.c | 3 +--
> include/drm/drm_dp_mst_helper.h | 2 --
> 5 files changed, 4 insertions(+), 34 deletions(-)
>
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 1ff49547b2e8..129126091e90 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -4063,27 +4063,6 @@ drm_dp_mst_detect_port(struct drm_connector *connector,
> }
> EXPORT_SYMBOL(drm_dp_mst_detect_port);
>
> -/**
> - * drm_dp_mst_port_has_audio() - Check whether port has audio capability or
> not
> - * @mgr: manager for this port
> - * @port: unverified pointer to a port.
> - *
> - * This returns whether the port supports audio or not.
> - */
> -bool drm_dp_mst_port_has_audio(struct drm_dp_mst_topology_mgr *mgr,
> - struct drm_dp_mst_port *port)
> -{
> - bool ret = false;
> -
> - port = drm_dp_mst_topology_get_port_validated(mgr, port);
> - if (!port)
> - return ret;
> - ret = port->has_audio;
> - drm_dp_mst_topology_put_port(port);
> - return ret;
> -}
> -EXPORT_SYMBOL(drm_dp_mst_port_has_audio);
> -
> /**
> * drm_dp_mst_get_edid() - get EDID for an MST port
> * @connector: toplevel connector to get EDID for
> diff --git a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> index 424f4e52f783..9f736420d83f 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> +++ b/drivers/gpu/drm/i915/display/intel_display_debugfs.c
> @@ -631,15 +631,9 @@ static void intel_dp_info(struct seq_file *m,
> }
>
> static void intel_dp_mst_info(struct seq_file *m,
> - struct intel_connector *intel_connector)
> + struct intel_connector *intel_connector)
> {
> - struct intel_encoder *intel_encoder =
> intel_attached_encoder(intel_connector);
> - struct intel_dp_mst_encoder *intel_mst =
> - enc_to_mst(intel_encoder);
> - struct intel_digital_port *intel_dig_port = intel_mst->primary;
> - struct intel_dp *intel_dp = _dig_port->dp;
> - bool has_audio = drm_dp_mst_port_has_audio(_dp->mst_mgr,
> - intel_connector->port);
> + bool has_audio = intel_connector->port->has_audio;
>
> seq_printf(m, "\taudio support: %s\n", yesno(has_audio));
> }
> diff --git a/drivers/gpu/drm/i915/display/intel_display_types.h
> b/drivers/gpu/drm/i915/display/intel_display_types.h
> index 2bedd626c686..1de7bef0a49b 100644
> --- a/drivers/gpu/drm/i915/display/intel_display_types.h
> +++ b/drivers/gpu/drm/i915/display/intel_display_types.h
> @@ -436,7 +436,7 @@ struct intel_connector {
>state of connector->polled in case hotplug storm detection changes
> it */
> u8 polled;
>
> - void *port; /* store this opaque as its illegal to dereference it */
> + struct drm_dp_mst_port *port;
>
> struct intel_dp *mst_port;
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> index 61605eb8c2af..c35efc9e628d 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp_mst.c
> @@ -114,8 +114,7 @@ static int intel_dp_mst_compute_config(struct
> intel_encoder *encoder,
>
> if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
>
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/3] drm/i915: Make exclusive awaits on i915_active optional
== Series Details == Series: series starting with [CI,1/3] drm/i915: Make exclusive awaits on i915_active optional URL : https://patchwork.freedesktop.org/series/75556/ State : success == Summary == CI Bug Log - changes from CI_DRM_8261 -> Patchwork_17222 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/index.html Known issues Here are the changes found in Patchwork_17222 that come from known issues: ### IGT changes ### Possible fixes * igt@kms_chamelium@dp-crc-fast: - fi-cml-u2: [DMESG-WARN][1] ([i915#892]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8261/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/fi-cml-u2/igt@kms_chamel...@dp-crc-fast.html [i915#892]: https://gitlab.freedesktop.org/drm/intel/issues/892 Participating hosts (53 -> 47) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8261 -> Patchwork_17222 CI-20190529: 20190529 CI_DRM_8261: 80b64adc6f5ffeb1c69996737dbdc5ad275d8e6c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5572: 6c124b5c8501d900966c033ac86c3dc55c16a2da @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17222: cb6f691aa367a0074e18f8e5676a2d9429e15062 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == cb6f691aa367 drm/i915/gem: Wait until the context is finally retired before releasing engines 730297c3e327 drm/i915: Allow asynchronous waits on the i915_active barriers b810c3955e8f drm/i915: Make exclusive awaits on i915_active optional == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17222/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/3] drm/i915/perf: break OA config buffer object in 2
== Series Details == Series: series starting with [1/3] drm/i915/perf: break OA config buffer object in 2 URL : https://patchwork.freedesktop.org/series/75550/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8260_full -> Patchwork_17220_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17220_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17220_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_17220_full: ### IGT changes ### Possible regressions * igt@gem_ctx_persistence@engines-mixed-process@vcs1: - shard-tglb: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-tglb8/igt@gem_ctx_persistence@engines-mixed-proc...@vcs1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-tglb7/igt@gem_ctx_persistence@engines-mixed-proc...@vcs1.html Known issues Here are the changes found in Patchwork_17220_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_workarounds@suspend-resume-context: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +4 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl2/igt@gem_workarou...@suspend-resume-context.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-apl8/igt@gem_workarou...@suspend-resume-context.html * igt@gem_workarounds@suspend-resume-fd: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([i915#180]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl3/igt@gem_workarou...@suspend-resume-fd.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-kbl1/igt@gem_workarou...@suspend-resume-fd.html * igt@i915_pm_dc@dc6-psr: - shard-skl: [PASS][7] -> [FAIL][8] ([i915#454]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl3/igt@i915_pm...@dc6-psr.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-skl10/igt@i915_pm...@dc6-psr.html * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [PASS][9] -> [FAIL][10] ([i915#1066]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-snb4/igt@i915_pm_rc6_reside...@rc6-idle.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-snb6/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@kms_cursor_crc@pipe-a-cursor-128x128-onscreen: - shard-apl: [PASS][11] -> [FAIL][12] ([i915#54] / [i915#95]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl7/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-apl8/igt@kms_cursor_...@pipe-a-cursor-128x128-onscreen.html * igt@kms_flip@2x-dpms-vs-vblank-race: - shard-glk: [PASS][13] -> [FAIL][14] ([i915#407]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-glk8/igt@kms_f...@2x-dpms-vs-vblank-race.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-glk3/igt@kms_f...@2x-dpms-vs-vblank-race.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-skl10/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html * igt@kms_psr@psr2_sprite_render: - shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-iclb2/igt@kms_psr@psr2_sprite_render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-iclb8/igt@kms_psr@psr2_sprite_render.html * igt@perf@blocking: - shard-hsw: [PASS][19] -> [INCOMPLETE][20] ([i915#61]) +11 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-hsw8/igt@p...@blocking.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-hsw6/igt@p...@blocking.html * igt@perf@oa-formats: - shard-hsw: [PASS][21] -> [INCOMPLETE][22] ([CI#80] / [i915#61]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-hsw7/igt@p...@oa-formats.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/shard-hsw1/igt@p...@oa-formats.html Possible fixes * igt@gem_media_fill: - shard-kbl: [DMESG-WARN][23] ([i915#165]) -> [PASS][24] [23]:
Re: [Intel-gfx] [PATCH 06/10] dma-buf: Proxy fence, an unsignaled fence placeholder
On Sun, Apr 5, 2020 at 3:16 PM kbuild test robot wrote: > > Hi Chris, > > Thank you for the patch! Perhaps something to improve: > > [auto build test WARNING on drm-tip/drm-tip] > [cannot apply to drm-intel/for-linux-next linus/master v5.6 next-20200405] > [if your patch is applied to the wrong git tree, please drop us a note to help > improve the system. BTW, we also suggest to use '--base' option to specify the > base tree in git format-patch, please see > https://stackoverflow.com/a/37406982] > > url: > https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-selftests-Add-request-throughput-measurement-to-perf/20200404-174829 > base: git://anongit.freedesktop.org/drm/drm-tip drm-tip > config: x86_64-randconfig-d001-20200405 (attached as .config) > compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project > be84d2b5b7e9c98e93bf8565e3e178e43ea0ec0a) > reproduce: > wget > https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O > ~/bin/make.cross > chmod +x ~/bin/make.cross > # save the attached .config to linux build tree > COMPILER=clang make.cross ARCH=x86_64 > > If you fix the issue, kindly add following tag as appropriate > Reported-by: kbuild test robot > > All warnings (new ones prefixed by >>): > > >> drivers/dma-buf/dma-fence-proxy.o: warning: objtool: > >> __llvm_gcov_writeout()+0x1: call without frame pointer save/setup > >> drivers/dma-buf/dma-fence-proxy.o: warning: objtool: > >> __llvm_gcov_flush()+0x0: call without frame pointer save/setup > >> drivers/dma-buf/dma-fence-proxy.o: warning: objtool: > >> __llvm_gcov_init()+0x0: call without frame pointer save/setup Sorry for the noise, this is a known pre-existing issue not caused by this patch. -- Thanks, ~Nick Desaulniers ___ 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/5] drm/i915: Make exclusive awaits on i915_active optional (rev2)
== Series Details == Series: series starting with [1/5] drm/i915: Make exclusive awaits on i915_active optional (rev2) URL : https://patchwork.freedesktop.org/series/75535/ State : success == Summary == CI Bug Log - changes from CI_DRM_8260_full -> Patchwork_17219_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17219_full that come from known issues: ### IGT changes ### Issues hit * igt@gen9_exec_parse@allowed-single: - shard-skl: [PASS][1] -> [DMESG-WARN][2] ([i915#716]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl4/igt@gen9_exec_pa...@allowed-single.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-skl2/igt@gen9_exec_pa...@allowed-single.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl8/igt@i915_susp...@sysfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-apl8/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([i915#300]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-skl10/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_fbcon_fbt@fbc-suspend: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([i915#180] / [i915#95]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-apl6/igt@kms_fbcon_...@fbc-suspend.html * igt@kms_flip@flip-vs-expired-vblank-interruptible: - shard-apl: [PASS][9] -> [FAIL][10] ([i915#46]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl2/igt@kms_f...@flip-vs-expired-vblank-interruptible.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-apl1/igt@kms_f...@flip-vs-expired-vblank-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([i915#180]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl1/igt@kms_f...@flip-vs-suspend.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-kbl6/igt@kms_f...@flip-vs-suspend.html * igt@kms_plane_alpha_blend@pipe-b-coverage-7efc: - shard-skl: [PASS][13] -> [FAIL][14] ([fdo#108145] / [i915#265]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl1/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-skl5/igt@kms_plane_alpha_bl...@pipe-b-coverage-7efc.html Possible fixes * igt@gem_media_fill: - shard-kbl: [DMESG-WARN][15] ([i915#165]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl2/igt@gem_media_fill.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-kbl1/igt@gem_media_fill.html * igt@gem_softpin@noreloc-s3: - shard-kbl: [DMESG-WARN][17] ([i915#180] / [i915#93] / [i915#95]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl6/igt@gem_soft...@noreloc-s3.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-kbl4/igt@gem_soft...@noreloc-s3.html * igt@gen9_exec_parse@allowed-all: - shard-glk: [DMESG-WARN][19] ([i915#716]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-glk6/igt@gen9_exec_pa...@allowed-all.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-glk5/igt@gen9_exec_pa...@allowed-all.html * igt@kms_color@pipe-b-ctm-0-5: - shard-kbl: [DMESG-WARN][21] ([i915#78]) -> [PASS][22] +1 similar issue [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-kbl2/igt@kms_co...@pipe-b-ctm-0-5.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-kbl1/igt@kms_co...@pipe-b-ctm-0-5.html * igt@kms_cursor_crc@pipe-a-cursor-128x42-sliding: - shard-apl: [FAIL][23] ([i915#54] / [i915#95]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-apl3/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/shard-apl4/igt@kms_cursor_...@pipe-a-cursor-128x42-sliding.html * igt@kms_cursor_legacy@flip-vs-cursor-atomic-transitions: - shard-skl: [FAIL][25] ([IGT#5]) -> [PASS][26] [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/shard-skl1/igt@kms_cursor_leg...@flip-vs-cursor-atomic-transitions.html [26]:
Re: [Intel-gfx] [PATCH 40/44] drm/cirrus: Don't use drm_device->dev_private
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> Upcasting using a container_of macro is more typesafe, faster and
> easier for the compiler to optimize.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: Daniel Vetter
> Cc: "Noralf Trønnes"
> Cc: Sam Ravnborg
> Cc: Eric Anholt
> Cc: Thomas Zimmermann
> Cc: virtualizat...@lists.linux-foundation.org
> ---
> drivers/gpu/drm/cirrus/cirrus.c | 9 +
> 1 file changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/cirrus/cirrus.c b/drivers/gpu/drm/cirrus/cirrus.c
> index 4b65637147ba..744a8e337e41 100644
> --- a/drivers/gpu/drm/cirrus/cirrus.c
> +++ b/drivers/gpu/drm/cirrus/cirrus.c
> @@ -59,6 +59,8 @@ struct cirrus_device {
> void __iomem *mmio;
> };
>
> +#define to_cirrus(_dev) container_of(_dev, struct cirrus_device, dev)
> +
Maybe to_cirrus_device() ? I had the same comment for vbox and I think
it applies to all patches.
Best regards
Thomas
> /* -- */
> /*
> * The meat of this driver. The core passes us a mode and we have to program
> @@ -311,7 +313,7 @@ static int cirrus_mode_set(struct cirrus_device *cirrus,
> static int cirrus_fb_blit_rect(struct drm_framebuffer *fb,
> struct drm_rect *rect)
> {
> - struct cirrus_device *cirrus = fb->dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(fb->dev);
> void *vmap;
> int idx, ret;
>
> @@ -436,7 +438,7 @@ static void cirrus_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> struct drm_crtc_state *crtc_state,
> struct drm_plane_state *plane_state)
> {
> - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
>
> cirrus_mode_set(cirrus, _state->mode, plane_state->fb);
> cirrus_fb_blit_fullscreen(plane_state->fb);
> @@ -445,7 +447,7 @@ static void cirrus_pipe_enable(struct
> drm_simple_display_pipe *pipe,
> static void cirrus_pipe_update(struct drm_simple_display_pipe *pipe,
> struct drm_plane_state *old_state)
> {
> - struct cirrus_device *cirrus = pipe->crtc.dev->dev_private;
> + struct cirrus_device *cirrus = to_cirrus(pipe->crtc.dev);
> struct drm_plane_state *state = pipe->plane.state;
> struct drm_crtc *crtc = >crtc;
> struct drm_rect rect;
> @@ -573,7 +575,6 @@ static int cirrus_pci_probe(struct pci_dev *pdev,
> return PTR_ERR(cirrus);
>
> dev = >dev;
> - dev->dev_private = cirrus;
>
> cirrus->vram = devm_ioremap(>dev, pci_resource_start(pdev, 0),
> pci_resource_len(pdev, 0));
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/18] drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON
Hi Pankaj,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20200406]
[cannot apply to v5.6]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system. BTW, we also suggest to use '--base' option to specify the
base tree in git format-patch, please see https://stackoverflow.com/a/37406982]
url:
https://github.com/0day-ci/linux/commits/Pankaj-Bharadiya/Prefer-drm_WARN-over-WARN/20200406-210932
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-randconfig-f002-20200406 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project
a43e23360657e3df82af6b96b403d1a5a3174744)
reproduce:
wget
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
COMPILER=clang make.cross ARCH=x86_64
If you fix the issue, kindly add following tag as appropriate
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
>> drivers/gpu/drm/i915/display/icl_dsi.c:1127:14: error: use of undeclared
>> identifier 'state'
drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
^
>> drivers/gpu/drm/i915/display/icl_dsi.c:1127:14: error: use of undeclared
>> identifier 'state'
2 errors generated.
vim +/state +1127 drivers/gpu/drm/i915/display/icl_dsi.c
1120
1121 static void gen11_dsi_enable(struct intel_encoder *encoder,
1122 const struct intel_crtc_state *crtc_state,
1123 const struct drm_connector_state
*conn_state)
1124 {
1125 struct intel_dsi *intel_dsi = enc_to_intel_dsi(encoder);
1126
> 1127 drm_WARN_ON(state->base.dev, crtc_state->has_pch_encoder);
1128
1129 /* step6d: enable dsi transcoder */
1130 gen11_dsi_enable_transcoder(encoder);
1131
1132 /* step7: enable backlight */
1133 intel_panel_enable_backlight(crtc_state, conn_state);
1134 intel_dsi_vbt_exec_sequence(intel_dsi, MIPI_SEQ_BACKLIGHT_ON);
1135
1136 intel_crtc_vblank_on(crtc_state);
1137 }
1138
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 10:04 AM Michel Dänzer wrote: > > On 2020-04-06 6:34 p.m., Rob Clark wrote: > > > > The ideal thing would be to be able to click any jobs that we want to > > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > > to automatically trigger dependencies of that job (meson-arm64, and > > arm_build+arm_test). But not sure if that is a thing gitlab can do. > > Not that I know of. The dependency handling is still pretty rudimentary > in general. > > > > Triggering just the first container jobs and having everything from > > there run automatically would be ok if the current rules to filter out > > unneeded jobs still apply, ie. a panfrost change isn't triggering > > freedreno CI jobs and visa versa. But tbh I don't understand enough > > of what that MR is doing to understand if that is what it does. (It > > was suggested on IRC that this is probably what it does.) > > It is. Filtered jobs don't exist at all in the pipeline, so they can't > be triggered by any means. :) > ahh, ok, I didn't realize that.. thx for the explaination BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 30/44] drm/qxl: Use devm_drm_dev_alloc
Am 03.04.20 um 15:58 schrieb Daniel Vetter:
> Also need to remove the drm_dev_put from the remove hook.
>
> Signed-off-by: Daniel Vetter
> Cc: Dave Airlie
> Cc: Gerd Hoffmann
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: spice-de...@lists.freedesktop.org
> ---
> drivers/gpu/drm/qxl/qxl_drv.c | 15 ---
> drivers/gpu/drm/qxl/qxl_drv.h | 3 +--
> drivers/gpu/drm/qxl/qxl_kms.c | 12 +---
> 3 files changed, 10 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.c b/drivers/gpu/drm/qxl/qxl_drv.c
> index 09102e2efabc..6b4ae4c5fb76 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.c
> +++ b/drivers/gpu/drm/qxl/qxl_drv.c
> @@ -81,13 +81,16 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> return -EINVAL; /* TODO: ENODEV ? */
> }
>
> - qdev = kzalloc(sizeof(struct qxl_device), GFP_KERNEL);
> - if (!qdev)
> + qdev = devm_drm_dev_alloc(>dev, _driver,
> + struct qxl_device, ddev);
> + if (IS_ERR(qdev)) {
> + pr_err("Unable to init drm dev");
> return -ENOMEM;
> + }
My feeling is that it is too early to allocate. Wouldn't it be better to
first do the pdev and conflicting-fb stuff and allocate right before
qxl_device_init() ?
Best regards
Thomas
>
> ret = pci_enable_device(pdev);
> if (ret)
> - goto free_dev;
> + return ret;
>
> ret = drm_fb_helper_remove_conflicting_pci_framebuffers(pdev, "qxl");
> if (ret)
> @@ -101,7 +104,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> }
> }
>
> - ret = qxl_device_init(qdev, _driver, pdev);
> + ret = qxl_device_init(qdev, pdev);
> if (ret)
> goto put_vga;
>
> @@ -128,8 +131,7 @@ qxl_pci_probe(struct pci_dev *pdev, const struct
> pci_device_id *ent)
> vga_put(pdev, VGA_RSRC_LEGACY_IO);
> disable_pci:
> pci_disable_device(pdev);
> -free_dev:
> - kfree(qdev);
> +
> return ret;
> }
>
> @@ -155,7 +157,6 @@ qxl_pci_remove(struct pci_dev *pdev)
> drm_atomic_helper_shutdown(dev);
> if (is_vga(pdev))
> vga_put(pdev, VGA_RSRC_LEGACY_IO);
> - drm_dev_put(dev);
> }
>
> DEFINE_DRM_GEM_FOPS(qxl_fops);
> diff --git a/drivers/gpu/drm/qxl/qxl_drv.h b/drivers/gpu/drm/qxl/qxl_drv.h
> index 435126facc9b..86ac191d9205 100644
> --- a/drivers/gpu/drm/qxl/qxl_drv.h
> +++ b/drivers/gpu/drm/qxl/qxl_drv.h
> @@ -276,8 +276,7 @@ struct qxl_device {
> extern const struct drm_ioctl_desc qxl_ioctls[];
> extern int qxl_max_ioctl;
>
> -int qxl_device_init(struct qxl_device *qdev, struct drm_driver *drv,
> - struct pci_dev *pdev);
> +int qxl_device_init(struct qxl_device *qdev, struct pci_dev *pdev);
> void qxl_device_fini(struct qxl_device *qdev);
>
> int qxl_modeset_init(struct qxl_device *qdev);
> diff --git a/drivers/gpu/drm/qxl/qxl_kms.c b/drivers/gpu/drm/qxl/qxl_kms.c
> index 9eed1a375f24..91a34dd835d7 100644
> --- a/drivers/gpu/drm/qxl/qxl_kms.c
> +++ b/drivers/gpu/drm/qxl/qxl_kms.c
> @@ -108,21 +108,13 @@ static void qxl_gc_work(struct work_struct *work)
> }
>
> int qxl_device_init(struct qxl_device *qdev,
> - struct drm_driver *drv,
> struct pci_dev *pdev)
> {
> int r, sb;
>
> - r = drm_dev_init(>ddev, drv, >dev);
> - if (r) {
> - pr_err("Unable to init drm dev");
> - goto error;
> - }
> -
> qdev->ddev.pdev = pdev;
> pci_set_drvdata(pdev, >ddev);
> qdev->ddev.dev_private = qdev;
> - drmm_add_final_kfree(>ddev, qdev);
>
> mutex_init(>gem.mutex);
> mutex_init(>update_area_mutex);
> @@ -138,8 +130,7 @@ int qxl_device_init(struct qxl_device *qdev,
> qdev->vram_mapping = io_mapping_create_wc(qdev->vram_base,
> pci_resource_len(pdev, 0));
> if (!qdev->vram_mapping) {
> pr_err("Unable to create vram_mapping");
> - r = -ENOMEM;
> - goto error;
> + return -ENOMEM;
> }
>
> if (pci_resource_len(pdev, 4) > 0) {
> @@ -293,7 +284,6 @@ int qxl_device_init(struct qxl_device *qdev,
> io_mapping_free(qdev->surface_mapping);
> vram_mapping_free:
> io_mapping_free(qdev->vram_mapping);
> -error:
> return r;
> }
>
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/44] drm/udl: Use demv_drm_dev_alloc
Am 05.04.20 um 12:18 schrieb Noralf Trønnes:
>
>
> Den 03.04.2020 15.57, skrev Daniel Vetter:
>> Also init the fbdev emulation before we register the device, that way
>> we can rely on the auto-cleanup and simplify the probe error code even
>> more.
>>
>> Signed-off-by: Daniel Vetter
>> Cc: Dave Airlie
>> Cc: Sean Paul
>> Cc: Thomas Zimmermann
>> Cc: Daniel Vetter
>> Cc: Emil Velikov
>> Cc: Sam Ravnborg
>> Cc: Thomas Gleixner
>> ---
>> drivers/gpu/drm/udl/udl_drv.c | 36 +++
>> 1 file changed, 11 insertions(+), 25 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/udl/udl_drv.c b/drivers/gpu/drm/udl/udl_drv.c
>> index 1ce2d865c36d..4ba5149fdd57 100644
>> --- a/drivers/gpu/drm/udl/udl_drv.c
>> +++ b/drivers/gpu/drm/udl/udl_drv.c
>> @@ -57,27 +57,20 @@ static struct udl_device *udl_driver_create(struct
>> usb_interface *interface)
>> struct udl_device *udl;
>> int r;
>>
>> -udl = kzalloc(sizeof(*udl), GFP_KERNEL);
>> -if (!udl)
>> -return ERR_PTR(-ENOMEM);
>> -
>> -r = drm_dev_init(>drm, , >dev);
>> -if (r) {
>> -kfree(udl);
>> -return ERR_PTR(r);
>> -}
>> +udl = devm_drm_dev_alloc(>dev, ,
>> + struct udl_device, drm);
>> +if (IS_ERR(udl))
>> +return udl;
>>
>> udl->udev = udev;
>> udl->drm.dev_private = udl;
>> -drmm_add_final_kfree(>drm, udl);
>>
>> r = udl_init(udl);
>> -if (r) {
>> -drm_dev_put(>drm);
>> +if (r)
>> return ERR_PTR(r);
>> -}
>>
>> usb_set_intfdata(interface, udl);
>> +
>> return udl;
>> }
>>
>> @@ -91,23 +84,17 @@ static int udl_usb_probe(struct usb_interface *interface,
>> if (IS_ERR(udl))
>> return PTR_ERR(udl);
>>
>> +r = drm_fbdev_generic_setup(>drm, 0);
>
> It doesn't feel right to have a client open the device before the DRM
> device itself is registered. I would prefer to keep it where it is but
Agreed. IMHO we should also go through drivers and make the fbdev setup
the final step everywhere.
Best regards
Thomas
> ignore any errors. A failing client shouldn't prevent the driver from
> probing. drm_fbdev_generic_setup() do print errors if it fails. So yeah,
> in hindsight I should have made drm_fbdev_generic_setup() return void.
>
> Noralf.
>
>> +if (r)
>> +return r;
>> +
>> r = drm_dev_register(>drm, 0);
>> if (r)
>> -goto err_free;
>> +return r;
>>
>> DRM_INFO("Initialized udl on minor %d\n", udl->drm.primary->index);
>>
>> -r = drm_fbdev_generic_setup(>drm, 0);
>> -if (r)
>> -goto err_drm_dev_unregister;
>> -
>> return 0;
>> -
>> -err_drm_dev_unregister:
>> -drm_dev_unregister(>drm);
>> -err_free:
>> -drm_dev_put(>drm);
>> -return r;
>> }
>>
>> static void udl_usb_disconnect(struct usb_interface *interface)
>> @@ -117,7 +104,6 @@ static void udl_usb_disconnect(struct usb_interface
>> *interface)
>> drm_kms_helper_poll_fini(dev);
>> udl_drop_usb(dev);
>> drm_dev_unplug(dev);
>> -drm_dev_put(dev);
>> }
>>
>> /*
>>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/44] drm/vboxvideo: Stop using drm_device->dev_private
Hi
Am 03.04.20 um 15:57 schrieb Daniel Vetter:
> We use the baseclass pattern here, so lets to the proper (and more
> typesafe) upcasting.
>
> Signed-off-by: Daniel Vetter
> Cc: Hans de Goede
> ---
> drivers/gpu/drm/vboxvideo/vbox_drv.c | 1 -
> drivers/gpu/drm/vboxvideo/vbox_drv.h | 1 +
> drivers/gpu/drm/vboxvideo/vbox_irq.c | 2 +-
> drivers/gpu/drm/vboxvideo/vbox_mode.c | 10 +-
> 4 files changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> index be0600b22cf5..d34cddd809fd 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.c
> @@ -52,7 +52,6 @@ static int vbox_pci_probe(struct pci_dev *pdev, const
> struct pci_device_id *ent)
> return PTR_ERR(vbox);
>
> vbox->ddev.pdev = pdev;
> - vbox->ddev.dev_private = vbox;
> pci_set_drvdata(pdev, vbox);
> mutex_init(>hw_mutex);
>
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_drv.h
> b/drivers/gpu/drm/vboxvideo/vbox_drv.h
> index 87421903816c..ac7c2effc46f 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_drv.h
> +++ b/drivers/gpu/drm/vboxvideo/vbox_drv.h
> @@ -127,6 +127,7 @@ struct vbox_encoder {
> #define to_vbox_crtc(x) container_of(x, struct vbox_crtc, base)
> #define to_vbox_connector(x) container_of(x, struct vbox_connector, base)
> #define to_vbox_encoder(x) container_of(x, struct vbox_encoder, base)
> +#define to_vbox_dev(x) container_of(x, struct vbox_private, ddev)
I suggest ot call this macro to to_vbox_device(). At some point, we
should rename struct vbox_private to struct vbox_device for consistency
among drivers. The new macro's name would then fit.
For the overall patch:
Acked-by: Thomas Zimmermann
Best regards
Thomas
>
> bool vbox_check_supported(u16 id);
> int vbox_hw_init(struct vbox_private *vbox);
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_irq.c
> b/drivers/gpu/drm/vboxvideo/vbox_irq.c
> index 16a1e29f5292..631657fa554f 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_irq.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_irq.c
> @@ -34,7 +34,7 @@ void vbox_report_hotplug(struct vbox_private *vbox)
> irqreturn_t vbox_irq_handler(int irq, void *arg)
> {
> struct drm_device *dev = (struct drm_device *)arg;
> - struct vbox_private *vbox = (struct vbox_private *)dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(dev);
> u32 host_flags = vbox_get_flags(vbox);
>
> if (!(host_flags & HGSMIHOSTFLAGS_IRQ))
> diff --git a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> index 0883a435e62b..d9a5af62af89 100644
> --- a/drivers/gpu/drm/vboxvideo/vbox_mode.c
> +++ b/drivers/gpu/drm/vboxvideo/vbox_mode.c
> @@ -36,7 +36,7 @@ static void vbox_do_modeset(struct drm_crtc *crtc)
> u16 flags;
> s32 x_offset, y_offset;
>
> - vbox = crtc->dev->dev_private;
> + vbox = to_vbox_dev(crtc->dev);
> width = vbox_crtc->width ? vbox_crtc->width : 640;
> height = vbox_crtc->height ? vbox_crtc->height : 480;
> bpp = fb ? fb->format->cpp[0] * 8 : 32;
> @@ -77,7 +77,7 @@ static void vbox_do_modeset(struct drm_crtc *crtc)
> static int vbox_set_view(struct drm_crtc *crtc)
> {
> struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
> - struct vbox_private *vbox = crtc->dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(crtc->dev);
> struct vbva_infoview *p;
>
> /*
> @@ -174,7 +174,7 @@ static void vbox_crtc_set_base_and_mode(struct drm_crtc
> *crtc,
> int x, int y)
> {
> struct drm_gem_vram_object *gbo = drm_gem_vram_of_gem(fb->obj[0]);
> - struct vbox_private *vbox = crtc->dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(crtc->dev);
> struct vbox_crtc *vbox_crtc = to_vbox_crtc(crtc);
> bool needs_modeset = drm_atomic_crtc_needs_modeset(crtc->state);
>
> @@ -272,7 +272,7 @@ static void vbox_primary_atomic_update(struct drm_plane
> *plane,
> {
> struct drm_crtc *crtc = plane->state->crtc;
> struct drm_framebuffer *fb = plane->state->fb;
> - struct vbox_private *vbox = fb->dev->dev_private;
> + struct vbox_private *vbox = to_vbox_dev(fb->dev);
> struct drm_mode_rect *clips;
> uint32_t num_clips, i;
>
> @@ -704,7 +704,7 @@ static int vbox_get_modes(struct drm_connector *connector)
> int preferred_width, preferred_height;
>
> vbox_connector = to_vbox_connector(connector);
> - vbox = connector->dev->dev_private;
> + vbox = to_vbox_dev(connector->dev);
>
> hgsmi_report_flags_location(vbox->guest_pool, GUEST_HEAP_OFFSET(vbox) +
> HOST_FLAGS_OFFSET);
>
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg)
Geschäftsführer: Felix Imendörffer
signature.asc
Description: OpenPGP
Re: [Intel-gfx] gitlab.fd.o financial situation and impact on services
On 2020-04-06 6:34 p.m., Rob Clark wrote: > > The ideal thing would be to be able to click any jobs that we want to > run, say "arm64_a630_gles31", and for gitlab to realize that it needs > to automatically trigger dependencies of that job (meson-arm64, and > arm_build+arm_test). But not sure if that is a thing gitlab can do. Not that I know of. The dependency handling is still pretty rudimentary in general. > Triggering just the first container jobs and having everything from > there run automatically would be ok if the current rules to filter out > unneeded jobs still apply, ie. a panfrost change isn't triggering > freedreno CI jobs and visa versa. But tbh I don't understand enough > of what that MR is doing to understand if that is what it does. (It > was suggested on IRC that this is probably what it does.) It is. Filtered jobs don't exist at all in the pipeline, so they can't be triggered by any means. :) -- Earthling Michel Dänzer | https://redhat.com Libre software enthusiast | Mesa and X developer ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
== Series Details == Series: drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu URL : https://patchwork.freedesktop.org/series/75546/ State : success == Summary == CI Bug Log - changes from CI_DRM_8259_full -> Patchwork_17218_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_17218_full that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@requests: - shard-tglb: [PASS][1] -> [INCOMPLETE][2] ([i915#1531]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-tglb2/igt@i915_selftest@l...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-tglb8/igt@i915_selftest@l...@requests.html * igt@i915_suspend@sysfs-reader: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-apl6/igt@i915_susp...@sysfs-reader.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-apl8/igt@i915_susp...@sysfs-reader.html * igt@kms_cursor_edge_walk@pipe-c-128x128-left-edge: - shard-kbl: [PASS][5] -> [FAIL][6] ([i915#70]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-kbl7/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-kbl1/igt@kms_cursor_edge_w...@pipe-c-128x128-left-edge.html * igt@kms_draw_crc@draw-method-rgb565-pwrite-ytiled: - shard-glk: [PASS][7] -> [FAIL][8] ([i915#52] / [i915#54]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-glk6/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-glk9/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html * igt@kms_fbcon_fbt@psr-suspend: - shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl9/igt@kms_fbcon_...@psr-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-skl1/igt@kms_fbcon_...@psr-suspend.html * igt@kms_flip@flip-vs-expired-vblank: - shard-skl: [PASS][11] -> [FAIL][12] ([i915#79]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl9/igt@kms_f...@flip-vs-expired-vblank.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-skl1/igt@kms_f...@flip-vs-expired-vblank.html * igt@kms_flip@plain-flip-ts-check: - shard-skl: [PASS][13] -> [FAIL][14] ([i915#34]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl7/igt@kms_f...@plain-flip-ts-check.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-skl6/igt@kms_f...@plain-flip-ts-check.html * igt@kms_hdr@bpc-switch: - shard-skl: [PASS][15] -> [FAIL][16] ([i915#1188]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl10/igt@kms_...@bpc-switch.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-skl10/igt@kms_...@bpc-switch.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([i915#180]) +3 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-kbl7/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-kbl1/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html * igt@kms_psr@psr2_primary_page_flip: - shard-iclb: [PASS][19] -> [SKIP][20] ([fdo#109441]) +3 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-iclb3/igt@kms_psr@psr2_primary_page_flip.html * igt@kms_vblank@pipe-c-ts-continuation-suspend: - shard-tglb: [PASS][21] -> [INCOMPLETE][22] ([i915#456] / [i915#460]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-tglb1/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-tglb6/igt@kms_vbl...@pipe-c-ts-continuation-suspend.html Possible fixes * igt@i915_pm_rc6_residency@rc6-idle: - shard-snb: [FAIL][23] ([i915#1066]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-snb7/igt@i915_pm_rc6_reside...@rc6-idle.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/shard-snb4/igt@i915_pm_rc6_reside...@rc6-idle.html * igt@i915_suspend@fence-restore-tiled2untiled: - shard-apl: [DMESG-WARN][25] ([i915#180]) -> [PASS][26] +3 similar issues [25]:
[Intel-gfx] [PATCH] drm/i915/gem: Apply more mb() around clflush relocation paths
Having spent some time with DBG_FORCE_RELOC == FORCE_CPU_RELOC, it
appears that our memory barriers around the clflush are lackluster for
our more seldom used paths. Seldom used does not mean never, so apply
the memory barriers or else we may randomly see incorrect relocation
addresses inside batches.
Signed-off-by: Chris Wilson
Cc: sta...@vger.kernel.org
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 230ba1aee355..d9ab517bbce9 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1037,6 +1037,8 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
void *vaddr;
if (cache->vaddr) {
+ if (cache->vaddr & CLFLUSH_AFTER)
+ mb();
kunmap_atomic(unmask_page(cache->vaddr));
} else {
unsigned int flushes;
@@ -1051,14 +1053,15 @@ static void *reloc_kmap(struct drm_i915_gem_object *obj,
cache->vaddr = flushes | KMAP;
cache->node.mm = (void *)obj;
- if (flushes)
- mb();
}
vaddr = kmap_atomic(i915_gem_object_get_dirty_page(obj, page));
cache->vaddr = unmask_flags(cache->vaddr) | (unsigned long)vaddr;
cache->page = page;
+ if (cache->vaddr & CLFLUSH_BEFORE)
+ mb();
+
return vaddr;
}
@@ -1163,8 +1166,10 @@ static void clflush_write32(u32 *addr, u32 value,
unsigned int flushes)
* mb barriers at the start and end of the relocation phase
* to ensure ordering of clflush wrt to the system.
*/
- if (flushes & CLFLUSH_AFTER)
+ if (flushes & CLFLUSH_AFTER) {
+ mb();
clflushopt(addr);
+ }
} else
*addr = value;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Mon, Apr 6, 2020 at 8:43 AM Adam Jackson wrote: > > On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > strictly > > > > pre-merge CI. > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > click first the container jobs.. then wait.. then the build jobs.. > > then wait some more.. and then finally the actual runners. That would > > be a real step back in terms of usefulness of CI.. one might call it a > > regression :-( > > I think that's mostly a complaint about the conditionals we've written > so far, tbh. As I commented on the bug, when I clicked the container > job (which the rules happen to have evaluated to being "manual"), every > job (recursively) downstream of it got enqueued, which isn't what > you're describing. So I think if you can describe the UX you'd like we > can write rules to make that reality. Ok, I was fearing that we'd have to manually trigger each stage of dependencies in the pipeline. Which wouldn't be so bad except that gitlab makes you wait for the previous stage to complete before triggering the next one. The ideal thing would be to be able to click any jobs that we want to run, say "arm64_a630_gles31", and for gitlab to realize that it needs to automatically trigger dependencies of that job (meson-arm64, and arm_build+arm_test). But not sure if that is a thing gitlab can do. Triggering just the first container jobs and having everything from there run automatically would be ok if the current rules to filter out unneeded jobs still apply, ie. a panfrost change isn't triggering freedreno CI jobs and visa versa. But tbh I don't understand enough of what that MR is doing to understand if that is what it does. (It was suggested on IRC that this is probably what it does.) BR, -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2 0/2] tests/gem_userptr_blits: Refresh still MMAP_GTT dependent subtests
Refresh subtests which are still using pre-v4 MMAP_GTT API. v2: Patch 2/2: clear 'map' before reuse (Zbigniew). Janusz Krzysztofik (2): tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise tests/gem_userptr_blits: Refresh other still MMAP_GTT dependent subtests tests/i915/gem_userptr_blits.c | 132 - 1 file changed, 97 insertions(+), 35 deletions(-) -- 2.21.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t 1/2] tests/gem_userptr_blits: Refresh readonly-mmap-unsync exercise
Upgrade the subtest to use MMAP_GTT API v4 (aka MMAP_OFFSET),
dynamically examine each mapping type supported by i915 driver.
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index beced298a..975cd9dab 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -1277,7 +1277,7 @@ static void sigjmp_handler(int sig)
siglongjmp(sigjmp, sig);
}
-static void test_readonly_mmap(int i915)
+static void test_readonly_mmap(int i915, const struct mmap_offset *t)
{
char *original, *result;
uint32_t handle;
@@ -1294,6 +1294,14 @@ static void test_readonly_mmap(int i915)
* on the GPU as well.
*/
+ handle = gem_create(i915, PAGE_SIZE);
+ ptr = __gem_mmap_offset(i915, handle, 0, PAGE_SIZE,
+ PROT_READ | PROT_WRITE, t->type);
+ gem_close(i915, handle);
+ igt_require_f(ptr, "HW & kernel support for mmap-offset(%s)\n",
+ t->name);
+ munmap(ptr, PAGE_SIZE);
+
igt_require(igt_setup_clflush());
sz = 16 << 12;
@@ -1307,11 +1315,11 @@ static void test_readonly_mmap(int i915)
igt_clflush_range(pages, sz);
original = g_compute_checksum_for_data(G_CHECKSUM_SHA1, pages, sz);
- ptr = __gem_mmap__gtt(i915, handle, sz, PROT_WRITE);
+ ptr = __gem_mmap_offset(i915, handle, 0, sz, PROT_WRITE, t->type);
igt_assert(ptr == NULL);
/* Optional kernel support for GTT mmaps of userptr */
- ptr = __gem_mmap__gtt(i915, handle, sz, PROT_READ);
+ ptr = __gem_mmap_offset(i915, handle, 0, sz, PROT_READ, t->type);
gem_close(i915, handle);
if (ptr) { /* Check that a write into the GTT readonly map fails */
@@ -2110,8 +2118,11 @@ igt_main_args("c:", NULL, help_str, opt_handler, NULL)
igt_subtest("readonly-unsync")
test_readonly(fd);
- igt_subtest("readonly-mmap-unsync")
- test_readonly_mmap(fd);
+ igt_describe("Examine mmap-offset mapping to read-only
userptr");
+ igt_subtest_with_dynamic("readonly-mmap-unsync")
+ for_each_mmap_offset_type(fd, t)
+ igt_dynamic(t->name)
+ test_readonly_mmap(fd, t);
igt_subtest("readonly-pwrite-unsync")
test_readonly_pwrite(fd);
--
2.21.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2 2/2] tests/gem_userptr_blits: Refresh other still MMAP_GTT dependent subtests
Extend initial check for support of MMAP_GTT mapping to userptr with
equivalent checks for each MMAP_OFFSET mapping type supported by i915
driver. Based on that, extend coverage of process-exit-gtt* subtests
over non-GTT mapping types. In case of dmabuf-* subtests, use first
supported mapping type if there are any.
v2: Clear 'map' before reuse (Zbigniew).
Signed-off-by: Janusz Krzysztofik
Reviewed-by: Zbigniew Kempczyński
---
tests/i915/gem_userptr_blits.c | 111 -
1 file changed, 81 insertions(+), 30 deletions(-)
diff --git a/tests/i915/gem_userptr_blits.c b/tests/i915/gem_userptr_blits.c
index 975cd9dab..9b80cf634 100644
--- a/tests/i915/gem_userptr_blits.c
+++ b/tests/i915/gem_userptr_blits.c
@@ -73,18 +73,31 @@
static uint32_t userptr_flags = LOCAL_I915_USERPTR_UNSYNCHRONIZED;
-static bool can_gtt_mmap;
+static bool *can_mmap;
#define WIDTH 512
#define HEIGHT 512
static uint32_t linear[WIDTH*HEIGHT];
-static bool has_gtt_mmap(int i915)
+static bool has_mmap(int i915, const struct mmap_offset *t)
{
- void *ptr, *map = NULL;
+ void *ptr, *map;
uint32_t handle;
+ handle = gem_create(i915, PAGE_SIZE);
+ map = __gem_mmap_offset(i915, handle, 0, PAGE_SIZE, PROT_WRITE,
+ t->type);
+ gem_close(i915, handle);
+ if (map) {
+ munmap(map, PAGE_SIZE);
+ } else {
+ igt_debug("no HW / kernel support for mmap-offset(%s)\n",
+ t->name);
+ return false;
+ }
+ map = NULL;
+
igt_assert(posix_memalign(, PAGE_SIZE, PAGE_SIZE) == 0);
if (__gem_userptr(i915, ptr, 4096, 0,
@@ -92,9 +105,12 @@ static bool has_gtt_mmap(int i915)
goto out_ptr;
igt_assert(handle != 0);
- map = __gem_mmap__gtt(i915, handle, 4096, PROT_WRITE);
+ map = __gem_mmap_offset(i915, handle, 0, 4096, PROT_WRITE, t->type);
if (map)
munmap(map, 4096);
+ else if (errno == ENODEV)
+ igt_debug("mmap-offset(%s) banned, lockdep loop prevention\n",
+ t->name);
gem_close(i915, handle);
out_ptr:
@@ -642,20 +658,25 @@ static int test_invalid_mapping(int fd, const struct
mmap_offset *t)
return 0;
}
-#define PE_GTT_MAP 0x1
-#define PE_BUSY 0x2
-static void test_process_exit(int fd, int flags)
+#define PE_BUSY 0x1
+static void test_process_exit(int fd, const struct mmap_offset *mmo, int flags)
{
- if (flags & PE_GTT_MAP)
- igt_require(can_gtt_mmap);
+ if (mmo)
+ igt_require_f(can_mmap[mmo->type],
+ "HW & kernel support for LLC and mmap-offset(%s)
over userptr\n",
+ mmo->name);
igt_fork(child, 1) {
uint32_t handle;
handle = create_userptr_bo(fd, sizeof(linear));
- if (flags & PE_GTT_MAP) {
- uint32_t *ptr = __gem_mmap__gtt(fd, handle,
sizeof(linear), PROT_READ | PROT_WRITE);
+ if (mmo) {
+ uint32_t *ptr;
+
+ ptr = __gem_mmap_offset(fd, handle, 0, sizeof(linear),
+ PROT_READ | PROT_WRITE,
+ mmo->type);
if (ptr)
*ptr = 0;
}
@@ -933,13 +954,14 @@ static void (* volatile orig_sigbus)(int sig, siginfo_t
*info, void *param);
static volatile unsigned long sigbus_start;
static volatile long sigbus_cnt = -1;
-static void *umap(int fd, uint32_t handle)
+static void *umap(int fd, uint32_t handle, const struct mmap_offset *mmo)
{
void *ptr;
- if (can_gtt_mmap) {
- ptr = gem_mmap__gtt(fd, handle, sizeof(linear),
- PROT_READ | PROT_WRITE);
+ if (mmo) {
+ ptr = __gem_mmap_offset(fd, handle, 0, sizeof(linear),
+ PROT_READ | PROT_WRITE, mmo->type);
+ igt_assert(ptr);
} else {
uint32_t tmp = gem_create(fd, sizeof(linear));
igt_assert_eq(copy(fd, tmp, handle), 0);
@@ -951,16 +973,17 @@ static void *umap(int fd, uint32_t handle)
}
static void
-check_bo(int fd1, uint32_t handle1, int is_userptr, int fd2, uint32_t handle2)
+check_bo(int fd1, uint32_t handle1, int is_userptr, int fd2, uint32_t handle2,
+const struct mmap_offset *mmo)
{
unsigned char *ptr1, *ptr2;
unsigned long size = sizeof(linear);
- ptr2 = umap(fd2, handle2);
+ ptr2 = umap(fd2, handle2, mmo);
if (is_userptr)
ptr1 = is_userptr > 0 ? get_handle_ptr(handle1) : ptr2;
else
- ptr1 = umap(fd1, handle1);
+ ptr1 = umap(fd1, handle1, mmo);
igt_assert(ptr1);
igt_assert(ptr2);
@@ -968,7
Re: [Intel-gfx] [PATCH i-g-t] i915/i915_hangman: Drop last reference to bygone 'i915_error_state'
Hi Chris, On Mon, Apr 06, 2020 at 04:35:18PM +0100, Chris Wilson wrote: > The test is looking at sysfs/error so dumping the old > debugfs/i915_error_state looks quite silly. The only dilemma is whether > it is worth replacing with a line-by-line dump. I propose we make that a > future problem -- and leave it to whoever has to debug it next time. > > Signed-off-by: Chris Wilson Reviewed-by: Andi Shyti Thanks, Andi ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] kernel: better document the use_mm/unuse_mm API contract
Am 2020-04-04 um 5:41 a.m. schrieb Christoph Hellwig:
> Switch the function documentation to kerneldoc comments, and add
> WARN_ON_ONCE asserts that the calling thread is a kernel thread and
> does not have ->mm set (or has ->mm set in the case of unuse_mm).
>
> Also give the functions a kthread_ prefix to better document the
> use case.
>
> Signed-off-by: Christoph Hellwig
Acked-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 4 +--
> drivers/gpu/drm/i915/gvt/kvmgt.c | 4 +--
> drivers/usb/gadget/function/f_fs.c | 4 +--
> drivers/usb/gadget/legacy/inode.c | 4 +--
> drivers/vhost/vhost.c | 4 +--
> fs/io-wq.c | 6 ++--
> fs/io_uring.c | 6 ++--
> include/linux/kthread.h| 4 +--
> kernel/kthread.c | 33 +++---
> mm/oom_kill.c | 6 ++--
> mm/vmacache.c | 4 +--
> 11 files changed, 39 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index bce5e93fefc8..63db84e09408 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -192,9 +192,9 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev
> *dst, struct kgd_dev *s
> if ((mmptr) == current->mm) { \
> valid = !get_user((dst), (wptr)); \
> } else if (current->flags & PF_KTHREAD) { \
> - use_mm(mmptr); \
> + kthread_use_mm(mmptr); \
> valid = !get_user((dst), (wptr)); \
> - unuse_mm(mmptr);\
> + kthread_unuse_mm(mmptr);\
> } \
> pagefault_enable(); \
> } \
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index dee01c371bf5..92e9b340dbc2 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -2048,7 +2048,7 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
> long gpa,
> if (kthread) {
> if (!mmget_not_zero(kvm->mm))
> return -EFAULT;
> - use_mm(kvm->mm);
> + kthread_use_mm(kvm->mm);
> }
>
> idx = srcu_read_lock(>srcu);
> @@ -2057,7 +2057,7 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
> long gpa,
> srcu_read_unlock(>srcu, idx);
>
> if (kthread) {
> - unuse_mm(kvm->mm);
> + kthread_unuse_mm(kvm->mm);
> mmput(kvm->mm);
> }
>
> diff --git a/drivers/usb/gadget/function/f_fs.c
> b/drivers/usb/gadget/function/f_fs.c
> index c57b1b2507c6..d9e48bd7c692 100644
> --- a/drivers/usb/gadget/function/f_fs.c
> +++ b/drivers/usb/gadget/function/f_fs.c
> @@ -827,9 +827,9 @@ static void ffs_user_copy_worker(struct work_struct *work)
> mm_segment_t oldfs = get_fs();
>
> set_fs(USER_DS);
> - use_mm(io_data->mm);
> + kthread_use_mm(io_data->mm);
> ret = ffs_copy_to_iter(io_data->buf, ret, _data->data);
> - unuse_mm(io_data->mm);
> + kthread_unuse_mm(io_data->mm);
> set_fs(oldfs);
> }
>
> diff --git a/drivers/usb/gadget/legacy/inode.c
> b/drivers/usb/gadget/legacy/inode.c
> index 8b5233888bf8..a05552bc2ff8 100644
> --- a/drivers/usb/gadget/legacy/inode.c
> +++ b/drivers/usb/gadget/legacy/inode.c
> @@ -462,9 +462,9 @@ static void ep_user_copy_worker(struct work_struct *work)
> struct kiocb *iocb = priv->iocb;
> size_t ret;
>
> - use_mm(mm);
> + kthread_use_mm(mm);
> ret = copy_to_iter(priv->buf, priv->actual, >to);
> - unuse_mm(mm);
> + kthread_unuse_mm(mm);
> if (!ret)
> ret = -EFAULT;
>
> diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c
> index 4e9ce54869af..1787d426a956 100644
> --- a/drivers/vhost/vhost.c
> +++ b/drivers/vhost/vhost.c
> @@ -336,7 +336,7 @@ static int vhost_worker(void *data)
> mm_segment_t oldfs = get_fs();
>
> set_fs(USER_DS);
> - use_mm(dev->mm);
> + kthread_use_mm(dev->mm);
>
> for (;;) {
> /* mb paired w/ kthread_stop */
> @@ -364,7 +364,7 @@ static int vhost_worker(void *data)
> schedule();
> }
> }
> - unuse_mm(dev->mm);
> + kthread_unuse_mm(dev->mm);
> set_fs(oldfs);
> return 0;
> }
> diff --git
Re: [Intel-gfx] [PATCH 4/6] kernel: move use_mm/unuse_mm to kthread.c
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig: > These helpers are only for use with kernel threads, and I will tie them > more into the kthread infrastructure going forward. Also move the > prototypes to kthread.h - mmu_context.h was a little weird to start with > as it otherwise contains very low-level MM bits. > > Signed-off-by: Christoph Hellwig Acked-by: Felix Kuehling Thanks for cleaning up the unnecessary includes in amdgpu. Regards, Felix > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 1 + > .../drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c | 1 - > .../drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c| 1 - > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c | 2 - > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c | 2 - > .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c | 2 - > drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +- > drivers/usb/gadget/function/f_fs.c| 2 +- > drivers/usb/gadget/legacy/inode.c | 2 +- > drivers/vhost/vhost.c | 1 - > fs/aio.c | 1 - > fs/io-wq.c| 1 - > fs/io_uring.c | 1 - > include/linux/kthread.h | 5 ++ > include/linux/mmu_context.h | 5 -- > kernel/kthread.c | 56 > mm/Makefile | 2 +- > mm/mmu_context.c | 64 --- > 18 files changed, 66 insertions(+), 85 deletions(-) > delete mode 100644 mm/mmu_context.c > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > index 4db143c19dcc..bce5e93fefc8 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h > @@ -27,6 +27,7 @@ > > #include > #include > +#include > #include > #include > #include > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > index 6529caca88fe..35d4a5ab0228 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_arcturus.c > @@ -22,7 +22,6 @@ > #include > #include > #include > -#include > #include > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > index 4ec6d0c03201..b1655054b919 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v10.c > @@ -19,7 +19,6 @@ > * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > * OTHER DEALINGS IN THE SOFTWARE. > */ > -#include > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "gc/gc_10_1_0_offset.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > index 0b7e78748540..7d01420c0c85 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v7.c > @@ -20,8 +20,6 @@ > * OTHER DEALINGS IN THE SOFTWARE. > */ > > -#include > - > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "cikd.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > index ccd635b812b5..635cd1a26bed 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v8.c > @@ -20,8 +20,6 @@ > * OTHER DEALINGS IN THE SOFTWARE. > */ > > -#include > - > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "gfx_v8_0.h" > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > index df841c2ac5e7..c7fd0c47b254 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gfx_v9.c > @@ -19,8 +19,6 @@ > * ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR > * OTHER DEALINGS IN THE SOFTWARE. > */ > -#include > - > #include "amdgpu.h" > #include "amdgpu_amdkfd.h" > #include "gc/gc_9_0_offset.h" > diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c > b/drivers/gpu/drm/i915/gvt/kvmgt.c > index 5848400620b4..dee01c371bf5 100644 > --- a/drivers/gpu/drm/i915/gvt/kvmgt.c > +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c > @@ -31,7 +31,7 @@ > #include > #include > #include > -#include > +#include > #include > #include > #include > diff --git a/drivers/usb/gadget/function/f_fs.c > b/drivers/usb/gadget/function/f_fs.c > index c81023b195c3..c57b1b2507c6 100644 > --- a/drivers/usb/gadget/function/f_fs.c > +++ b/drivers/usb/gadget/function/f_fs.c > @@ -32,7 +32,7 @@ > #include > > #include > -#include > +#include > #include > #include > > diff --git
Re: [Intel-gfx] [PATCH 1/6] amdgpu: a NULL ->mm does not mean a thread is a kthread
Am 2020-04-04 um 5:40 a.m. schrieb Christoph Hellwig:
> Use the proper API instead.
>
> Fixes: 70539bd795002 ("drm/amd: Update MEC HQD loading code for KFD")
> Signed-off-by: Christoph Hellwig
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> index 13feb313e9b3..4db143c19dcc 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h
> @@ -190,7 +190,7 @@ uint8_t amdgpu_amdkfd_get_xgmi_hops_count(struct kgd_dev
> *dst, struct kgd_dev *s
> pagefault_disable();\
> if ((mmptr) == current->mm) { \
> valid = !get_user((dst), (wptr)); \
> - } else if (current->mm == NULL) { \
> + } else if (current->flags & PF_KTHREAD) { \
> use_mm(mmptr); \
> valid = !get_user((dst), (wptr)); \
> unuse_mm(mmptr);\
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 2/3] drm/i915: Allow asynchronous waits on the i915_active barriers
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we must be careful that we do not free it as we
iterate.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 73 ++
drivers/gpu/drm/i915/i915_active.h | 1 +
2 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d5e24be759f7..d960d0be5bd2 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -542,35 +542,88 @@ static int __await_active(struct i915_active_fence
*active,
return 0;
}
+struct wait_barrier {
+ struct wait_queue_entry base;
+ struct i915_active *ref;
+};
+
+static int
+barrier_wake(wait_queue_entry_t *wq, unsigned int mode, int flags, void *key)
+{
+ struct wait_barrier *wb = container_of(wq, typeof(*wb), base);
+
+ if (i915_active_is_idle(wb->ref)) {
+ list_del(>entry);
+ i915_sw_fence_complete(wq->private);
+ kfree(wq);
+ }
+
+ return 0;
+}
+
+static int __await_barrier(struct i915_active *ref, struct i915_sw_fence
*fence)
+{
+ struct wait_barrier *wb;
+
+ wb = kmalloc(sizeof(*wb), GFP_KERNEL);
+ if (unlikely(!wb))
+ return -ENOMEM;
+
+ GEM_BUG_ON(i915_active_is_idle(ref));
+ if (!i915_sw_fence_await(fence)) {
+ kfree(wb);
+ return -EINVAL;
+ }
+
+ wb->base.flags = 0;
+ wb->base.func = barrier_wake;
+ wb->base.private = fence;
+ wb->ref = ref;
+
+ add_wait_queue(__var_waitqueue(ref), >base);
+ return 0;
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+ void *arg, struct i915_sw_fence *barrier)
{
int err = 0;
+ if (!i915_active_acquire_if_busy(ref))
+ return 0;
+
if (flags & I915_ACTIVE_AWAIT_EXCL &&
rcu_access_pointer(ref->excl.fence)) {
err = __await_active(>excl, fn, arg);
if (err)
- return err;
+ goto out;
}
- if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
- i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
err = __await_active(>base, fn, arg);
if (err)
- break;
+ goto out;
}
- i915_active_release(ref);
+ }
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_lazy_signals(ref);
if (err)
- return err;
+ goto out;
+
+ err = __await_barrier(ref, barrier);
+ if (err)
+ goto out;
}
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
static int rq_await_fence(void *arg, struct dma_fence *fence)
@@ -582,7 +635,7 @@ int i915_request_await_active(struct i915_request *rq,
struct i915_active *ref,
unsigned int flags)
{
- return await_active(ref, flags, rq_await_fence, rq);
+ return await_active(ref, flags, rq_await_fence, rq, >submit);
}
static int sw_await_fence(void *arg, struct dma_fence *fence)
@@ -595,7 +648,7 @@ int i915_sw_fence_await_active(struct i915_sw_fence *fence,
struct i915_active *ref,
unsigned int flags)
{
- return await_active(ref, flags, sw_await_fence, fence);
+ return await_active(ref, flags, sw_await_fence, fence, fence);
}
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index ffafaa78c494..cf4058150966 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -195,6 +195,7 @@ int i915_request_await_active(struct i915_request *rq,
unsigned int flags);
#define I915_ACTIVE_AWAIT_EXCL BIT(0)
#define I915_ACTIVE_AWAIT_ACTIVE BIT(1)
+#define I915_ACTIVE_AWAIT_BARRIER BIT(2)
int i915_active_acquire(struct i915_active *ref);
bool i915_active_acquire_if_busy(struct i915_active *ref);
--
2.20.1
___
Intel-gfx mailing list
[Intel-gfx] [CI 3/3] drm/i915/gem: Wait until the context is finally retired before releasing engines
If we want to percolate information back from the HW, up through the GEM
context, we need to wait until the intel_context is scheduled out for
the last time. This is handled by the retirement of the intel_context's
barrier, i.e. by listening to the pulse after the notional unpin. So
wait until the intel_context is finally retired before releasing the
engine, so that we can inspect the final context state and pass it on.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 16 ++--
1 file changed, 6 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_context.c
b/drivers/gpu/drm/i915/gem/i915_gem_context.c
index 2b6dd08de6f1..11d9135cf21a 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_context.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_context.c
@@ -570,23 +570,19 @@ static void engines_idle_release(struct i915_gem_context
*ctx,
engines->ctx = i915_gem_context_get(ctx);
for_each_gem_engine(ce, engines, it) {
- struct dma_fence *fence;
- int err = 0;
+ int err;
/* serialises with execbuf */
set_bit(CONTEXT_CLOSED_BIT, >flags);
if (!intel_context_pin_if_active(ce))
continue;
- fence = i915_active_fence_get(>timeline->last_request);
- if (fence) {
- err = i915_sw_fence_await_dma_fence(>fence,
- fence, 0,
- GFP_KERNEL);
- dma_fence_put(fence);
- }
+ /* Wait until context is finally scheduled out and retired */
+ err = i915_sw_fence_await_active(>fence,
+>active,
+I915_ACTIVE_AWAIT_BARRIER);
intel_context_unpin(ce);
- if (err < 0)
+ if (err)
goto kill;
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [CI 1/3] drm/i915: Make exclusive awaits on i915_active optional
Later use will require asynchronous waits on the active timelines, but
will not utilize an async wait on the exclusive channel. Make the await
on the exclusive fence explicit in the selection flags.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 7 ---
drivers/gpu/drm/i915/i915_active.h | 3 ++-
drivers/gpu/drm/i915/i915_perf.c | 2 +-
drivers/gpu/drm/i915/i915_vma.c| 3 ++-
4 files changed, 9 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index 5df7704369fd..d5e24be759f7 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -549,14 +549,15 @@ static int await_active(struct i915_active *ref,
{
int err = 0;
- /* We must always wait for the exclusive fence! */
- if (rcu_access_pointer(ref->excl.fence)) {
+ if (flags & I915_ACTIVE_AWAIT_EXCL &&
+ rcu_access_pointer(ref->excl.fence)) {
err = __await_active(>excl, fn, arg);
if (err)
return err;
}
- if (flags & I915_ACTIVE_AWAIT_ALL && i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
+ i915_active_acquire_if_busy(ref)) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index b526d310a585..ffafaa78c494 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -193,7 +193,8 @@ int i915_sw_fence_await_active(struct i915_sw_fence *fence,
int i915_request_await_active(struct i915_request *rq,
struct i915_active *ref,
unsigned int flags);
-#define I915_ACTIVE_AWAIT_ALL BIT(0)
+#define I915_ACTIVE_AWAIT_EXCL BIT(0)
+#define I915_ACTIVE_AWAIT_ACTIVE BIT(1)
int i915_active_acquire(struct i915_active *ref);
bool i915_active_acquire_if_busy(struct i915_active *ref);
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2f78b147bb2d..5cde3e4e7be6 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -1948,7 +1948,7 @@ emit_oa_config(struct i915_perf_stream *stream,
if (!IS_ERR_OR_NULL(active)) {
/* After all individual context modifications */
err = i915_request_await_active(rq, active,
- I915_ACTIVE_AWAIT_ALL);
+ I915_ACTIVE_AWAIT_ACTIVE);
if (err)
goto err_add_request;
diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 6cc2d9c44015..f0383a68c981 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -1167,7 +1167,8 @@ int __i915_vma_move_to_active(struct i915_vma *vma,
struct i915_request *rq)
GEM_BUG_ON(!i915_vma_is_pinned(vma));
/* Wait for the vma to be bound before we start! */
- err = i915_request_await_active(rq, >active, 0);
+ err = i915_request_await_active(rq, >active,
+ I915_ACTIVE_AWAIT_EXCL);
if (err)
return err;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Allow asynchronous waits on the i915_active barriers
On 06/04/2020 14:21, Chris Wilson wrote:
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we must be careful that we do not free it as we
iterate.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 73 ++
drivers/gpu/drm/i915/i915_active.h | 1 +
2 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d5e24be759f7..d960d0be5bd2 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -542,35 +542,88 @@ static int __await_active(struct i915_active_fence
*active,
return 0;
}
+struct wait_barrier {
+ struct wait_queue_entry base;
+ struct i915_active *ref;
+};
+
+static int
+barrier_wake(wait_queue_entry_t *wq, unsigned int mode, int flags, void *key)
+{
+ struct wait_barrier *wb = container_of(wq, typeof(*wb), base);
+
+ if (i915_active_is_idle(wb->ref)) {
+ list_del(>entry);
+ i915_sw_fence_complete(wq->private);
+ kfree(wq);
+ }
+
+ return 0;
+}
+
+static int __await_barrier(struct i915_active *ref, struct i915_sw_fence
*fence)
+{
+ struct wait_barrier *wb;
+
+ wb = kmalloc(sizeof(*wb), GFP_KERNEL);
+ if (unlikely(!wb))
+ return -ENOMEM;
+
+ GEM_BUG_ON(i915_active_is_idle(ref));
+ if (!i915_sw_fence_await(fence)) {
+ kfree(wb);
+ return -EINVAL;
+ }
+
+ wb->base.flags = 0;
+ wb->base.func = barrier_wake;
+ wb->base.private = fence;
+ wb->ref = ref;
+
+ add_wait_queue(__var_waitqueue(ref), >base);
+ return 0;
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+ void *arg, struct i915_sw_fence *barrier)
{
int err = 0;
+ if (!i915_active_acquire_if_busy(ref))
+ return 0;
+
if (flags & I915_ACTIVE_AWAIT_EXCL &&
rcu_access_pointer(ref->excl.fence)) {
err = __await_active(>excl, fn, arg);
if (err)
- return err;
+ goto out;
}
- if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
- i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
err = __await_active(>base, fn, arg);
if (err)
- break;
+ goto out;
}
- i915_active_release(ref);
+ }
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_lazy_signals(ref);
if (err)
- return err;
+ goto out;
+
+ err = __await_barrier(ref, barrier);
+ if (err)
+ goto out;
}
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
static int rq_await_fence(void *arg, struct dma_fence *fence)
@@ -582,7 +635,7 @@ int i915_request_await_active(struct i915_request *rq,
struct i915_active *ref,
unsigned int flags)
{
- return await_active(ref, flags, rq_await_fence, rq);
+ return await_active(ref, flags, rq_await_fence, rq, >submit);
}
static int sw_await_fence(void *arg, struct dma_fence *fence)
@@ -595,7 +648,7 @@ int i915_sw_fence_await_active(struct i915_sw_fence *fence,
struct i915_active *ref,
unsigned int flags)
{
- return await_active(ref, flags, sw_await_fence, fence);
+ return await_active(ref, flags, sw_await_fence, fence, fence);
}
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index ffafaa78c494..cf4058150966 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -195,6 +195,7 @@ int i915_request_await_active(struct i915_request *rq,
unsigned int flags);
#define I915_ACTIVE_AWAIT_EXCL BIT(0)
#define I915_ACTIVE_AWAIT_ACTIVE BIT(1)
+#define I915_ACTIVE_AWAIT_BARRIER BIT(2)
int i915_active_acquire(struct i915_active *ref);
bool i915_active_acquire_if_busy(struct i915_active *ref);
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, 2020-04-04 at 08:11 -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I think that's mostly a complaint about the conditionals we've written so far, tbh. As I commented on the bug, when I clicked the container job (which the rules happen to have evaluated to being "manual"), every job (recursively) downstream of it got enqueued, which isn't what you're describing. So I think if you can describe the UX you'd like we can write rules to make that reality. But I don't really know which jobs are most expensive in terms of bandwidth, or storage, or CPUs, and even if I knew those I don't know how to map those to currency. So I'm not sure if the UI we'd like would minimize the cost the way we'd like. - ajax ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/i915_hangman: Drop last reference to bygone 'i915_error_state'
The test is looking at sysfs/error so dumping the old
debugfs/i915_error_state looks quite silly. The only dilemma is whether
it is worth replacing with a line-by-line dump. I propose we make that a
future problem -- and leave it to whoever has to debug it next time.
Signed-off-by: Chris Wilson
---
lib/igt_aux.c | 1 -
tests/i915/i915_hangman.c | 2 --
2 files changed, 3 deletions(-)
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 1a5648444..ecab5d998 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -484,7 +484,6 @@ hang_detector_process(int fd, pid_t pid, dev_t rdev)
str = udev_device_get_property_value(dev, "ERROR");
if (str && atoi(str) == 1) {
- igt_debugfs_dump(fd, "i915_error_state");
show_kernel_stack(pid);
kill(pid, SIGIO);
}
diff --git a/tests/i915/i915_hangman.c b/tests/i915/i915_hangman.c
index 08b06217e..13cd62087 100644
--- a/tests/i915/i915_hangman.c
+++ b/tests/i915/i915_hangman.c
@@ -140,8 +140,6 @@ static void check_error_state(const char
*expected_ring_name,
size_t line_size = 0;
bool found = false;
- igt_debugfs_dump(device, "i915_error_state");
-
igt_assert(getline(, _size, file) != -1);
igt_require(strcasecmp(line, "No error state collected"));
--
2.26.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
Le samedi 04 avril 2020 à 15:55 +0200, Andreas Bergmeier a écrit : > The problem of data transfer costs is not new in Cloud environments. At work > we usually just opt for paying for it since dev time is scarser. For private > projects though, I opt for aggressive (remote) caching. > So you can setup a global cache in Google Cloud Storage and more local caches > wherever your executors are (reduces egress as much as possible). > This setup works great with Bazel and Pants among others. Note that these > systems are pretty hermetic in contrast to Meson. > IIRC Eric by now works at Google. They internally use Blaze which AFAIK does > aggressive caching, too. > So maybe using any of these systems would be a way of not having to sacrifice > any of the current functionality. > Downside is that you have lower a bit of dev productivity since you cannot > eyeball your build definitions anymore. > Did you mean Bazel [0] ? I'm not sure I follow your reflection, why is Meson vs Bazel related to this issue ? Nicolas [0] https://bazel.build/ > ym2c > > > On Fri, 28 Feb 2020 at 20:34, Eric Anholt wrote: > > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > > > > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > > > b) we probably need to take a large step back here. > > > > > > > > > > Look at this from a sponsor POV, why would I give X.org/fd.o > > > > > sponsorship money that they are just giving straight to google to pay > > > > > for hosting credits? Google are profiting in some minor way from these > > > > > hosting credits being bought by us, and I assume we aren't getting any > > > > > sort of discounts here. Having google sponsor the credits costs google > > > > > substantially less than having any other company give us money to do > > > > > it. > > > > > > > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty > > > > comparable in terms of what you get and what you pay for them. > > > > Obviously providers like Packet and Digital Ocean who offer bare-metal > > > > services are cheaper, but then you need to find someone who is going > > > > to properly administer the various machines, install decent > > > > monitoring, make sure that more storage is provisioned when we need > > > > more storage (which is basically all the time), make sure that the > > > > hardware is maintained in decent shape (pretty sure one of the fd.o > > > > machines has had a drive in imminent-failure state for the last few > > > > months), etc. > > > > > > > > Given the size of our service, that's a much better plan (IMO) than > > > > relying on someone who a) isn't an admin by trade, b) has a million > > > > other things to do, and c) hasn't wanted to do it for the past several > > > > years. But as long as that's the resources we have, then we're paying > > > > the cloud tradeoff, where we pay more money in exchange for fewer > > > > problems. > > > > > > Admin for gitlab and CI is a full time role anyways. The system is > > > definitely not self sustaining without time being put in by you and > > > anholt still. If we have $75k to burn on credits, and it was diverted > > > to just pay an admin to admin the real hw + gitlab/CI would that not > > > be a better use of the money? I didn't know if we can afford $75k for > > > an admin, but suddenly we can afford it for gitlab credits? > > > > As I think about the time that I've spent at google in less than a > > year on trying to keep the lights on for CI and optimize our > > infrastructure in the current cloud environment, that's more than the > > entire yearly budget you're talking about here. Saying "let's just > > pay for people to do more work instead of paying for full-service > > cloud" is not a cost optimization. > > > > > > > > Yes, we could federate everything back out so everyone runs their own > > > > builds and executes those. Tinderbox did something really similar to > > > > that IIRC; not sure if Buildbot does as well. Probably rules out > > > > pre-merge testing, mind. > > > > > > Why? does gitlab not support the model? having builds done in parallel > > > on runners closer to the test runners seems like it should be a thing. > > > I guess artifact transfer would cost less then as a result. > > > > Let's do some napkin math. The biggest artifacts cost we have in Mesa > > is probably meson-arm64/meson-arm (60MB zipped from meson-arm64, > > downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day, > > makes ~1.8TB/month ($180 or so). We could build a local storage next > > to the lava dispatcher so that the artifacts didn't have to contain > > the rootfs that came from the container (~2/3 of the insides of the > > zip file), but that's another service to build and maintain. Building > > the drivers once locally and storing it would save downloading the > > other ~1/3 of the inside of the zip file, but that requires a big > > enough system to do
Re: [Intel-gfx] [PATCH 2/6] i915/gvt/kvm: a NULL ->mm does not mean a thread is a kthread
Hello!
On 04.04.2020 12:40, Christoph Hellwig wrote:
Use the proper API instead.
Fixes: f440c8a572d7 ("drm/i915/gvt/kvmgt: read/write GPA via KVM API")
Signed-off-by: Christoph Hellwig
---
drivers/gpu/drm/i915/gvt/kvmgt.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c b/drivers/gpu/drm/i915/gvt/kvmgt.c
index 074c4efb58eb..5848400620b4 100644
--- a/drivers/gpu/drm/i915/gvt/kvmgt.c
+++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
@@ -2037,7 +2037,7 @@ static int kvmgt_rw_gpa(unsigned long handle, unsigned
long gpa,
struct kvmgt_guest_info *info;
struct kvm *kvm;
int idx, ret;
- bool kthread = current->mm == NULL;
+ bool kthread = (current->flags & PF_KTHREAD);
Don't need the parens.
[...]
MBR, Sergei
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PULL] drm-misc-next-fixes
Hi Daniel, Dave, Here's this week round of drm-misc-next fixes. Thanks! Maxime drm-misc-next-fixes-2020-04-04: A bunch of fixes to avoid null pointer dereference in fbcon, fix a return in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation, and a conflicting framebuffer in vboxvideo. The following changes since commit 6afe6929964bca6847986d0507a555a041f07753: drm: Mark up racy check of drm_gem_object.handle_count (2020-03-16 10:31:35 +) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-next-fixes-2020-04-04 for you to fetch changes up to d8a26d8fc37c5b8b9e95f2fa194f287cf8cab3f4: drm/mm: revert "Break long searches in fragmented address spaces" (2020-03-31 17:35:56 +0200) A bunch of fixes to avoid null pointer dereference in fbcon, fix a return in xen, some DT bindings fixes, a vc4 issue with 1920x1200 mode validation, and a conflicting framebuffer in vboxvideo. Christian König (1): drm/mm: revert "Break long searches in fragmented address spaces" Ding Xiang (1): drm/xen: fix passing zero to 'PTR_ERR' warning Geert Uytterhoeven (1): dma-buf: Improve CONFIG_DMABUF_MOVE_NOTIFY help text Hans de Goede (1): drm/vboxvideo: Add missing remove_conflicting_pci_framebuffers call, v2 Mauro Carvalho Chehab (1): docs: dt: display/ti: fix typos at the devicetree/ directory name Nicolas Saenz Julienne (1): drm/vc4: Fix HDMI mode validation Qiujun Huang (1): fbcon: fix null-ptr-deref in fbcon_switch Rob Herring (1): dt-bindings: display: ti: Fix dtc unit-address warnings in examples Sam Ravnborg (2): dt-bindings: display: drop data-mapping from panel-dpi drm/panel-simple: drop use of data-mapping property .../devicetree/bindings/display/panel/panel-dpi.yaml | 10 -- .../devicetree/bindings/display/ti/ti,am65x-dss.yaml | 4 ++-- .../devicetree/bindings/display/ti/ti,j721e-dss.yaml | 4 ++-- .../devicetree/bindings/display/ti/ti,k2g-dss.yaml | 4 ++-- drivers/dma-buf/Kconfig | 11 ++- drivers/gpu/drm/drm_mm.c | 8 +--- drivers/gpu/drm/panel/panel-simple.c | 11 --- drivers/gpu/drm/vboxvideo/vbox_drv.c | 4 drivers/gpu/drm/vc4/vc4_hdmi.c | 20 drivers/gpu/drm/xen/xen_drm_front.c | 2 +- drivers/video/fbdev/core/fbcon.c | 3 +++ 11 files changed, 37 insertions(+), 44 deletions(-) signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 5/5] uaccess: Rename user_access_begin/end() to user_full_access_begin/end()
Le 03/04/2020 à 20:01, Linus Torvalds a écrit : On Fri, Apr 3, 2020 at 12:21 AM Christophe Leroy wrote: Now we have user_read_access_begin() and user_write_access_begin() in addition to user_access_begin(). I realize Al asked for this, but I don't think it really adds anything to the series. The "full" makes the names longer, but not really any more legible. So I like 1-4, but am unconvinced about 5 and would prefer that to be dropped. Sorry for the bikeshedding. Yes I was not sure about it, that's the reason why I added it as the last patch of the series. And in the meantime, we see Robots reporting build failures due to additional use of user_access_begin() in parallele to this change, so I guess it would anyway be a challenge to perform such a change without coordination. And I like this series much better without the cookie that was discussed, and just making the hard rule be that they can't nest. Some architecture may obviously use a cookie internally if they have some nesting behavior of their own, but it doesn't look like we have any major reason to expose that as the actual interface. The only other question is how to synchronize this? I'm ok with it going through the ppc tree, for example, and just let others build on that. Maybe using a shared immutable branch with 5.6 as a base? Michael, can you take patches 1 to 4 ? Otherwise, can you ack patch 4 to enable merging through another tree ? Christophe ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, Apr 04, 2020 at 11:16:08AM -0700, Rob Clark wrote: > On Sat, Apr 4, 2020 at 10:47 AM Nicolas Dufresne wrote: > > > > Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > > > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > > > For Mesa, we could run CI only when Marge pushes, so that it's a > > > > > strictly > > > > > pre-merge CI. > > > > > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > > > > > > > I wouldn't mind manually triggering pipelines, but unless there is > > > some trick I'm not realizing, it is super cumbersome. Ie. you have to > > > click first the container jobs.. then wait.. then the build jobs.. > > > then wait some more.. and then finally the actual runners. That would > > > be a real step back in terms of usefulness of CI.. one might call it a > > > regression :-( > > > > On GStreamer side we have moved some existing pipeline to manual mode. > > As we use needs: between jobs, we could simply set the first job to > > manual (in our case it's a single job called manifest in your case it > > would be the N container jobs). This way you can have a manual pipeline > > that is triggered in single (or fewer) clicks. Here's an example: > > > > https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 > > > > That our post-merge pipelines, we only trigger then if we suspect a > > problem. > > > > I'm not sure that would work for mesa since the hierarchy of jobs > branches out pretty far.. ie. if I just clicked the arm64 build + test > container jobs, and everything else ran automatically after that, it > would end up running all the CI jobs for all the arm devices (or at > least all the 64b ones) generate your gitlab-ci from a template so each pipeline has its own job dependency. The duplication won't hurt you if it's expanded through templating and it gives you fine-grained running of the manual jobs. We're using this in ci-templates/libevdev/libinput for the various distributions and their versions so each distribution+version is effectively its own pipeline. But we only need to maintain one job in the actual template file. https://freedesktop.pages.freedesktop.org/ci-templates/ci-fairy.html#templating-gitlab-ci-yml Cheers, Peter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 12/12] doc/admin-guide: update kernel.rst with CAP_PERFMON information
Em Sun, Apr 05, 2020 at 05:54:37PM +0300, Alexey Budankov escreveu: > > On 05.04.2020 17:41, Alexey Budankov wrote: > > > > On 05.04.2020 17:10, Arnaldo Carvalho de Melo wrote: > >> Em Thu, Apr 02, 2020 at 11:54:39AM +0300, Alexey Budankov escreveu: > >>> > >>> Update kernel.rst documentation file with the information > >>> related to usage of CAP_PERFMON capability to secure performance > >>> monitoring and observability operations in system. > >> > >> This one is failing in my perf/core branch, please take a look. I'm > > Please try applying this: Thanks, applied with the original commit log message, - Arnaldo > --- > Documentation/admin-guide/sysctl/kernel.rst | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/Documentation/admin-guide/sysctl/kernel.rst > b/Documentation/admin-guide/sysctl/kernel.rst > index 335696d3360d..aaa5bbcd1e33 100644 > --- a/Documentation/admin-guide/sysctl/kernel.rst > +++ b/Documentation/admin-guide/sysctl/kernel.rst > @@ -709,7 +709,13 @@ perf_event_paranoid > === > > Controls use of the performance events system by unprivileged > -users (without CAP_SYS_ADMIN). The default value is 2. > +users (without CAP_PERFMON). The default value is 2. > + > +For backward compatibility reasons access to system performance > +monitoring and observability remains open for CAP_SYS_ADMIN > +privileged processes but CAP_SYS_ADMIN usage for secure system > +performance monitoring and observability operations is discouraged > +with respect to CAP_PERFMON use cases. > > === == > -1 Allow use of (almost) all events by all users. > @@ -718,13 +724,13 @@ users (without CAP_SYS_ADMIN). The default value is 2. > ``CAP_IPC_LOCK``. > > >=0 Disallow ftrace function tracepoint by users without > - ``CAP_SYS_ADMIN``. > + ``CAP_PERFMON``. > > - Disallow raw tracepoint access by users without ``CAP_SYS_ADMIN``. > + Disallow raw tracepoint access by users without ``CAP_PERFMON``. > > ->=1 Disallow CPU event access by users without ``CAP_SYS_ADMIN``. > +>=1 Disallow CPU event access by users without ``CAP_PERFMON``. > > ->=2 Disallow kernel profiling by users without ``CAP_SYS_ADMIN``. > +>=2 Disallow kernel profiling by users without ``CAP_PERFMON``. > === == > > --- > > Thanks, > Alexey > > > > > Trying to reproduce right now. What kind of failure do you see? > > Please share some specifics so I could follow up properly. > > > > Thanks, > > Alexey > > > >> pushing my perf/core branch with this series applied, please check that > >> everything is ok, I'll do some testing now, but it all seems ok. > >> > >> Thanks, > >> > >> - Arnaldo > >> > >>> Signed-off-by: Alexey Budankov > >>> --- > >>> Documentation/admin-guide/sysctl/kernel.rst | 16 +++- > >>> 1 file changed, 11 insertions(+), 5 deletions(-) > >>> > >>> diff --git a/Documentation/admin-guide/sysctl/kernel.rst > >>> b/Documentation/admin-guide/sysctl/kernel.rst > >>> index def074807cee..b06ae9389809 100644 > >>> --- a/Documentation/admin-guide/sysctl/kernel.rst > >>> +++ b/Documentation/admin-guide/sysctl/kernel.rst > >>> @@ -720,20 +720,26 @@ perf_event_paranoid: > >>> > >>> > >>> Controls use of the performance events system by unprivileged > >>> -users (without CAP_SYS_ADMIN). The default value is 2. > >>> +users (without CAP_PERFMON). The default value is 2. > >>> + > >>> +For backward compatibility reasons access to system performance > >>> +monitoring and observability remains open for CAP_SYS_ADMIN > >>> +privileged processes but CAP_SYS_ADMIN usage for secure system > >>> +performance monitoring and observability operations is discouraged > >>> +with respect to CAP_PERFMON use cases. > >>> > >>> === == > >>> -1 Allow use of (almost) all events by all users > >>> > >>> Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK > >>> > >>> ->=0 Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN > >>> +>=0 Disallow ftrace function tracepoint by users without CAP_PERFMON > >>> > >>> - Disallow raw tracepoint access by users without CAP_SYS_ADMIN > >>> + Disallow raw tracepoint access by users without CAP_PERFMON > >>> > >>> ->=1 Disallow CPU event access by users without CAP_SYS_ADMIN > >>> +>=1 Disallow CPU event access by users without CAP_PERFMON > >>> > >>> ->=2 Disallow kernel profiling by users without CAP_SYS_ADMIN > >>> +>=2 Disallow kernel profiling by users without CAP_PERFMON > >>> === == > >>> > >>> > >>> -- > >>> 2.24.1 > >>> > >> -- - Arnaldo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
On Sat, Apr 04, 2020 at 08:11:23AM -0700, Rob Clark wrote: > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( I *think* this should work though if you set up the right job dependencies. very simple example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128601 job1 is "when:manual", job2 has "needs: job1", job3 has "needs: job2". Nothing runs at first, if you trigger job1 it'll cascade down to job 2 and 3. The main limit you have here are the stages - where a job is part of a stage but does not have an explicit "needs:" it will wait for the previous stage to complete. That will never happen if one job in that stage has a manual dependency. See this pipeline as an example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128605 So basically: if you set up all your jobs with the correct "needs" you could even have a noop stage for user interface purposes. Here's an example: https://gitlab.freedesktop.org/whot/ci-playground/pipelines/128606 It has a UI stage with "test-arm" and "test-x86" manual jobs. It has other stages with dependent jobs on those (cascading down) but it also has a set of autorun jobs that run independent of the manual triggers. When you push, the autorun jobs run. When you trigger "test-arm" manually, it triggers the various dependent jobs. So I think what you want to do is possible, it just requires some tweaking of the "needs" entries. Cheers, Peter ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 12/12] doc/admin-guide: update kernel.rst with CAP_PERFMON information
Em Thu, Apr 02, 2020 at 11:54:39AM +0300, Alexey Budankov escreveu: > > Update kernel.rst documentation file with the information > related to usage of CAP_PERFMON capability to secure performance > monitoring and observability operations in system. This one is failing in my perf/core branch, please take a look. I'm pushing my perf/core branch with this series applied, please check that everything is ok, I'll do some testing now, but it all seems ok. Thanks, - Arnaldo > Signed-off-by: Alexey Budankov > --- > Documentation/admin-guide/sysctl/kernel.rst | 16 +++- > 1 file changed, 11 insertions(+), 5 deletions(-) > > diff --git a/Documentation/admin-guide/sysctl/kernel.rst > b/Documentation/admin-guide/sysctl/kernel.rst > index def074807cee..b06ae9389809 100644 > --- a/Documentation/admin-guide/sysctl/kernel.rst > +++ b/Documentation/admin-guide/sysctl/kernel.rst > @@ -720,20 +720,26 @@ perf_event_paranoid: > > > Controls use of the performance events system by unprivileged > -users (without CAP_SYS_ADMIN). The default value is 2. > +users (without CAP_PERFMON). The default value is 2. > + > +For backward compatibility reasons access to system performance > +monitoring and observability remains open for CAP_SYS_ADMIN > +privileged processes but CAP_SYS_ADMIN usage for secure system > +performance monitoring and observability operations is discouraged > +with respect to CAP_PERFMON use cases. > > === == > -1 Allow use of (almost) all events by all users > > Ignore mlock limit after perf_event_mlock_kb without CAP_IPC_LOCK > > ->=0 Disallow ftrace function tracepoint by users without CAP_SYS_ADMIN > +>=0 Disallow ftrace function tracepoint by users without CAP_PERFMON > > - Disallow raw tracepoint access by users without CAP_SYS_ADMIN > + Disallow raw tracepoint access by users without CAP_PERFMON > > ->=1 Disallow CPU event access by users without CAP_SYS_ADMIN > +>=1 Disallow CPU event access by users without CAP_PERFMON > > ->=2 Disallow kernel profiling by users without CAP_SYS_ADMIN > +>=2 Disallow kernel profiling by users without CAP_PERFMON > === == > > > -- > 2.24.1 > -- - Arnaldo ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: Synchronize active and retire callbacks
On Fri, Apr 03, 2020 at 03:35:15PM -0700, Sultan Alsawaf wrote: > + ref->retire(ref); > + mutex_unlock(>callback_lock); Ugh, this patch is still wrong because the mutex unlock after ref->retire() is a use-after-free. Fun times... Sultan ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
The problem of data transfer costs is not new in Cloud environments. At work we usually just opt for paying for it since dev time is scarser. For private projects though, I opt for aggressive (remote) caching. So you can setup a global cache in Google Cloud Storage and more local caches wherever your executors are (reduces egress as much as possible). This setup works great with Bazel and Pants among others. Note that these systems are pretty hermetic in contrast to Meson. IIRC Eric by now works at Google. They internally use Blaze which AFAIK does aggressive caching, too. So maybe using any of these systems would be a way of not having to sacrifice any of the current functionality. Downside is that you have lower a bit of dev productivity since you cannot eyeball your build definitions anymore. ym2c On Fri, 28 Feb 2020 at 20:34, Eric Anholt wrote: > On Fri, Feb 28, 2020 at 12:48 AM Dave Airlie wrote: > > > > On Fri, 28 Feb 2020 at 18:18, Daniel Stone wrote: > > > > > > On Fri, 28 Feb 2020 at 03:38, Dave Airlie wrote: > > > > b) we probably need to take a large step back here. > > > > > > > > Look at this from a sponsor POV, why would I give X.org/fd.o > > > > sponsorship money that they are just giving straight to google to pay > > > > for hosting credits? Google are profiting in some minor way from > these > > > > hosting credits being bought by us, and I assume we aren't getting > any > > > > sort of discounts here. Having google sponsor the credits costs > google > > > > substantially less than having any other company give us money to do > > > > it. > > > > > > The last I looked, Google GCP / Amazon AWS / Azure were all pretty > > > comparable in terms of what you get and what you pay for them. > > > Obviously providers like Packet and Digital Ocean who offer bare-metal > > > services are cheaper, but then you need to find someone who is going > > > to properly administer the various machines, install decent > > > monitoring, make sure that more storage is provisioned when we need > > > more storage (which is basically all the time), make sure that the > > > hardware is maintained in decent shape (pretty sure one of the fd.o > > > machines has had a drive in imminent-failure state for the last few > > > months), etc. > > > > > > Given the size of our service, that's a much better plan (IMO) than > > > relying on someone who a) isn't an admin by trade, b) has a million > > > other things to do, and c) hasn't wanted to do it for the past several > > > years. But as long as that's the resources we have, then we're paying > > > the cloud tradeoff, where we pay more money in exchange for fewer > > > problems. > > > > Admin for gitlab and CI is a full time role anyways. The system is > > definitely not self sustaining without time being put in by you and > > anholt still. If we have $75k to burn on credits, and it was diverted > > to just pay an admin to admin the real hw + gitlab/CI would that not > > be a better use of the money? I didn't know if we can afford $75k for > > an admin, but suddenly we can afford it for gitlab credits? > > As I think about the time that I've spent at google in less than a > year on trying to keep the lights on for CI and optimize our > infrastructure in the current cloud environment, that's more than the > entire yearly budget you're talking about here. Saying "let's just > pay for people to do more work instead of paying for full-service > cloud" is not a cost optimization. > > > > > Yes, we could federate everything back out so everyone runs their own > > > builds and executes those. Tinderbox did something really similar to > > > that IIRC; not sure if Buildbot does as well. Probably rules out > > > pre-merge testing, mind. > > > > Why? does gitlab not support the model? having builds done in parallel > > on runners closer to the test runners seems like it should be a thing. > > I guess artifact transfer would cost less then as a result. > > Let's do some napkin math. The biggest artifacts cost we have in Mesa > is probably meson-arm64/meson-arm (60MB zipped from meson-arm64, > downloaded by 4 freedreno and 6ish lava, about 100 pipelines/day, > makes ~1.8TB/month ($180 or so). We could build a local storage next > to the lava dispatcher so that the artifacts didn't have to contain > the rootfs that came from the container (~2/3 of the insides of the > zip file), but that's another service to build and maintain. Building > the drivers once locally and storing it would save downloading the > other ~1/3 of the inside of the zip file, but that requires a big > enough system to do builds in time. > > I'm planning on doing a local filestore for google's lava lab, since I > need to be able to move our xml files off of the lava DUTs to get the > xml results we've become accustomed to, but this would not bubble up > to being a priority for my time if I wasn't doing it anyway. If it > takes me a single day to set all this up (I estimate a couple of > weeks), that costs
Re: [Intel-gfx] [Mesa-dev] gitlab.fd.o financial situation and impact on services
Le samedi 04 avril 2020 à 08:11 -0700, Rob Clark a écrit : > On Fri, Apr 3, 2020 at 7:12 AM Michel Dänzer wrote: > > On 2020-03-01 6:46 a.m., Marek Olšák wrote: > > > For Mesa, we could run CI only when Marge pushes, so that it's a strictly > > > pre-merge CI. > > > > Thanks for the suggestion! I implemented something like this for Mesa: > > > > https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4432 > > > > I wouldn't mind manually triggering pipelines, but unless there is > some trick I'm not realizing, it is super cumbersome. Ie. you have to > click first the container jobs.. then wait.. then the build jobs.. > then wait some more.. and then finally the actual runners. That would > be a real step back in terms of usefulness of CI.. one might call it a > regression :-( On GStreamer side we have moved some existing pipeline to manual mode. As we use needs: between jobs, we could simply set the first job to manual (in our case it's a single job called manifest in your case it would be the N container jobs). This way you can have a manual pipeline that is triggered in single (or fewer) clicks. Here's an example: https://gitlab.freedesktop.org/gstreamer/gstreamer/pipelines/128292 That our post-merge pipelines, we only trigger then if we suspect a problem. > > Is there a possible middle ground where pre-marge pipelines that touch > a particular driver trigger that driver's CI jobs, but MRs that don't > touch that driver but do touch shared code don't until triggered by > marge? Ie. if I have a MR that only touches nir, it's probably ok to > not run freedreno jobs until marge triggers it. But if I have a MR > that is touching freedreno, I'd really rather not have to wait until > marge triggers the freedreno CI jobs. > > Btw, I was under the impression (from periodically skimming the logs > in #freedesktop, so I could well be missing or misunderstanding > something) that caching/etc had been improved and mesa's part of the > egress wasn't the bigger issue at this point? > > BR, > -R ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Prefer drm_WARN* over WARN* (rev2)
== Series Details == Series: Prefer drm_WARN* over WARN* (rev2) URL : https://patchwork.freedesktop.org/series/75543/ State : success == Summary == CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17221 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/index.html Known issues Here are the changes found in Patchwork_17221 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live@requests: - fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] ([i915#1531] / [i915#1581]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-icl-guc/igt@i915_selftest@l...@requests.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/fi-icl-guc/igt@i915_selftest@l...@requests.html * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][3] -> [SKIP][4] ([fdo#109271]) +24 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html Possible fixes * igt@gem_tiled_fence_blits@basic: - fi-blb-e6850: [DMESG-WARN][5] ([i915#1612]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1531]: https://gitlab.freedesktop.org/drm/intel/issues/1531 [i915#1581]: https://gitlab.freedesktop.org/drm/intel/issues/1581 [i915#1612]: https://gitlab.freedesktop.org/drm/intel/issues/1612 Participating hosts (53 -> 45) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-bdw-gvtdvm fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8260 -> Patchwork_17221 CI-20190529: 20190529 CI_DRM_8260: fa5519e01f097b7f69259be38606ff5f1bc3cc6c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5572: 6c124b5c8501d900966c033ac86c3dc55c16a2da @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17221: 0fd60ba248422a0d5663452133f23baad2764749 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 0fd60ba24842 drm/i915/runtime_pm: Prefer drm_WARN* over WARN* 5597bb572e9b drm/i915/pm: Prefer drm_WARN_ON over WARN_ON 7de0dff58893 drm/i915/pmu: Prefer drm_WARN_ON over WARN_ON 3b4763bebc0e drm/i915/i915_drv: Prefer drm_WARN_ON over WARN_ON ae80b0409828 drm/i915/gem: Prefer drm_WARN* over WARN* cd2d48c2fb37 drm/i915/display/vlv_dsi: Prefer drm_WARN_ON over WARN_ON 0856fae10111 drm/i915/display/tc: Prefer drm_WARN_ON over WARN_ON b9632947474b drm/i915/display/sdvo: Prefer drm_WARN* over WARN* da0de795981b drm/i915/display/overlay: Prefer drm_WARN_ON over WARN_ON e5fb265bcdfc drm/i915/display/global_state: Prefer drm_WARN* over WARN* 8ec55548bc42 drm/i915/display/frontbuffer: Prefer drm_WARN_ON over WARN_ON 22c03725bfb6 drm/i915/display/dpll_mgr: Prefer drm_WARN_ON over WARN_ON 81a6c4600fea drm/i915/display/dp: Prefer drm_WARN* over WARN* 1703f9a2f458 drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON 7154962ac9f6 drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON 04cd23fe drm/i915/display/ddi: Prefer drm_WARN* over WARN* 5a021e68d20b drm/i915/display/atomic_plane: Prefer drm_WARN_ON over WARN_ON fd886b340869 drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17221/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v5 7/7] drm/i915/dp: Program vswing, pre-emphasis, test-pattern
On Mon, Mar 16, 2020 at 04:07:59PM +0530, Animesh Manna wrote:
> This patch process phy compliance request by programming requested
> vswing, pre-emphasis and test pattern.
>
> v1: Initial patch.
> v2: Fixes added during testing with test-scope. (Khaled/Clint/Manasi)
> - pipe used as argument during registers programming instead of port.
> - TRANS_CONF must be disable/enable as well during ddi disable/enable.
> - harcoded PLTPAT 80 bit custom pattern as the DPR-100 does not set it
> in the sink’s DPCDs
> - TRANS_DDI_FUNC_CTL DDI_Select (Bits 27:30) need to reset/set during
> disable/enable.
> v3: used macros instead of numbers and some cosmetic changes. [Manasi]
>
> Cc: Clinton Taylor
> Cc: Manasi Navare
> Signed-off-by: Animesh Manna
> Signed-off-by: Khaled Almahallawy
Looks good to me,
Reviewed-by: Manasi Navare
Manasi
> ---
> drivers/gpu/drm/i915/display/intel_dp.c | 147
> drivers/gpu/drm/i915/display/intel_dp.h | 1 +
> 2 files changed, 148 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
> b/drivers/gpu/drm/i915/display/intel_dp.c
> index 16a4a48c8168..8846471a49b8 100644
> --- a/drivers/gpu/drm/i915/display/intel_dp.c
> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
> @@ -5020,6 +5020,151 @@ static u8 intel_dp_prepare_phytest(struct intel_dp
> *intel_dp)
> return DP_TEST_ACK;
> }
>
> +static void intel_dp_phy_pattern_update(struct intel_dp *intel_dp)
> +{
> + struct drm_i915_private *dev_priv =
> + to_i915(dp_to_dig_port(intel_dp)->base.base.dev);
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_dp_phy_test_params *data =
> + _dp->compliance.test_data.phytest;
> + struct intel_crtc *crtc = to_intel_crtc(intel_dig_port->base.base.crtc);
> + enum pipe pipe = crtc->pipe;
> + u32 pattern_val;
> +
> + switch (data->phy_pattern) {
> + case DP_PHY_TEST_PATTERN_NONE:
> + DRM_DEBUG_KMS("Disable Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe), 0x0);
> + break;
> + case DP_PHY_TEST_PATTERN_D10_2:
> + DRM_DEBUG_KMS("Set D10.2 Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> +DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_D10_2);
> + break;
> + case DP_PHY_TEST_PATTERN_ERROR_COUNT:
> + DRM_DEBUG_KMS("Set Error Count Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> +DDI_DP_COMP_CTL_ENABLE |
> +DDI_DP_COMP_CTL_SCRAMBLED_0);
> + break;
> + case DP_PHY_TEST_PATTERN_PRBS7:
> + DRM_DEBUG_KMS("Set PRBS7 Phy Test Pattern\n");
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> +DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_PRBS7);
> + break;
> + case DP_PHY_TEST_PATTERN_80BIT_CUSTOM:
> + /*
> + * FIXME: Ideally pattern should come from DPCD 0x250. As
> + * current firmware of DPR-100 could not set it, so hardcoding
> + * now for complaince test.
> + */
> + DRM_DEBUG_KMS("Set 80Bit Custom Phy Test Pattern 0x3e0f83e0
> 0x0f83e0f8 0xf83e\n");
> + pattern_val = 0x3e0f83e0;
> + intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 0), pattern_val);
> + pattern_val = 0x0f83e0f8;
> + intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 1), pattern_val);
> + pattern_val = 0xf83e;
> + intel_de_write(dev_priv, DDI_DP_COMP_PAT(pipe, 2), pattern_val);
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> +DDI_DP_COMP_CTL_ENABLE |
> +DDI_DP_COMP_CTL_CUSTOM80);
> + break;
> + case DP_PHY_TEST_PATTERN_CP2520:
> + /*
> + * FIXME: Ideally pattern should come from DPCD 0x24A. As
> + * current firmware of DPR-100 could not set it, so hardcoding
> + * now for complaince test.
> + */
> + DRM_DEBUG_KMS("Set HBR2 compliance Phy Test Pattern\n");
> + pattern_val = 0xFB;
> + intel_de_write(dev_priv, DDI_DP_COMP_CTL(pipe),
> +DDI_DP_COMP_CTL_ENABLE | DDI_DP_COMP_CTL_HBR2 |
> +pattern_val);
> + break;
> + default:
> + WARN(1, "Invalid Phy Test Pattern\n");
> + }
> +}
> +
> +static void
> +intel_dp_autotest_phy_ddi_disable(struct intel_dp *intel_dp)
> +{
> + struct intel_digital_port *intel_dig_port = dp_to_dig_port(intel_dp);
> + struct drm_device *dev = intel_dig_port->base.base.dev;
> + struct drm_i915_private *dev_priv = to_i915(dev);
> + struct intel_crtc *crtc =
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Extend hotplug detect retry on TypeC connectors to 5 seconds
On Mon, Mar 30, 2020 at 10:13:02PM +0300, Souza, Jose wrote:
> On Mon, 2020-03-30 at 12:54 +0300, Imre Deak wrote:
> > On TypeC ports if a sink deasserts/reasserts its HPD signal,
> > generating
> > a hotplug interrupt without the sink getting unplugged/replugged from
> > the connector, there can be an up to 3 seconds delay until the AUX
> > channel gets functional. To avoid detection failures this delay
> > causes
> > retry the detection for 5 seconds.
>
> 5 seconds? would it be 5 tries?
Yes, 5 tries with a 1 second delay in-between them.
Thanks for the review, patchset pushed to -dinq.
> Other than that both patches looks good.
>
> Reviewed-by: José Roberto de Souza
>
> >
> > I noticed this on ICL/TGL RVPs and a DELL XPS 13 7390 ICL laptop.
> >
> > References: https://gitlab.freedesktop.org/drm/intel/issues/1067
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/display/intel_ddi.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_ddi.c
> > b/drivers/gpu/drm/i915/display/intel_ddi.c
> > index 4f508bf70f3b..2d947ff83488 100644
> > --- a/drivers/gpu/drm/i915/display/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/display/intel_ddi.c
> > @@ -4371,7 +4371,10 @@ static enum intel_hotplug_state
> > intel_ddi_hotplug(struct intel_encoder *encoder,
> > struct intel_connector *connector)
> > {
> > + struct drm_i915_private *i915 = to_i915(encoder->base.dev);
> > struct intel_digital_port *dig_port = enc_to_dig_port(encoder);
> > + enum phy phy = intel_port_to_phy(i915, encoder->port);
> > + bool is_tc = intel_phy_is_tc(i915, phy);
> > struct drm_modeset_acquire_ctx ctx;
> > enum intel_hotplug_state state;
> > int ret;
> > @@ -4414,8 +4417,15 @@ intel_ddi_hotplug(struct intel_encoder
> > *encoder,
> > * valid EDID. To solve this schedule another detection cycle
> > if this
> > * time around we didn't detect any change in the sink's
> > connection
> > * status.
> > +*
> > +* Type-c connectors which get their HPD signal deasserted then
> > +* reasserted, without unplugging/replugging the sink from the
> > +* connector, introduce a delay until the AUX channel
> > communication
> > +* becomes functional. Retry the detection for 5 seconds on
> > type-c
> > +* connectors to account for this delay.
> > */
> > - if (state == INTEL_HOTPLUG_UNCHANGED && !connector-
> > >hotplug_retries &&
> > + if (state == INTEL_HOTPLUG_UNCHANGED &&
> > + connector->hotplug_retries < (is_tc ? 5 : 1) &&
> > !dig_port->dp.is_mst)
> > state = INTEL_HOTPLUG_RETRY;
> >
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for Prefer drm_WARN* over WARN* (rev2)
== Series Details == Series: Prefer drm_WARN* over WARN* (rev2) URL : https://patchwork.freedesktop.org/series/75543/ State : warning == Summary == $ dim checkpatch origin/drm-tip fd886b340869 drm/i915/display/icl_dsi: Prefer drm_WARN_ON over WARN_ON 5a021e68d20b drm/i915/display/atomic_plane: Prefer drm_WARN_ON over WARN_ON 04cd23fe drm/i915/display/ddi: Prefer drm_WARN* over WARN* 7154962ac9f6 drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON 1703f9a2f458 drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON -:18: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #18: + struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, power_domains); total: 0 errors, 1 warnings, 0 checks, 71 lines checked 81a6c4600fea drm/i915/display/dp: Prefer drm_WARN* over WARN* 22c03725bfb6 drm/i915/display/dpll_mgr: Prefer drm_WARN_ON over WARN_ON 8ec55548bc42 drm/i915/display/frontbuffer: Prefer drm_WARN_ON over WARN_ON e5fb265bcdfc drm/i915/display/global_state: Prefer drm_WARN* over WARN* da0de795981b drm/i915/display/overlay: Prefer drm_WARN_ON over WARN_ON b9632947474b drm/i915/display/sdvo: Prefer drm_WARN* over WARN* 0856fae10111 drm/i915/display/tc: Prefer drm_WARN_ON over WARN_ON cd2d48c2fb37 drm/i915/display/vlv_dsi: Prefer drm_WARN_ON over WARN_ON ae80b0409828 drm/i915/gem: Prefer drm_WARN* over WARN* -:24: CHECK:PARENTHESIS_ALIGNMENT: Alignment should match open parenthesis #24: FILE: drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c:1444: + if (drm_WARN_ONCE(>drm, err, "Unexpected failure to bind target VMA!")) -:50: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "!obj->userptr.mm" #50: FILE: drivers/gpu/drm/i915/gem/i915_gem_userptr.c:238: + if (drm_WARN_ON(obj->base.dev, obj->userptr.mm == NULL)) total: 0 errors, 0 warnings, 2 checks, 25 lines checked 3b4763bebc0e drm/i915/i915_drv: Prefer drm_WARN_ON over WARN_ON -:22: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'dev_priv' - possible side-effects? #22: FILE: drivers/gpu/drm/i915/i915_drv.h:1650: +#define INTEL_DISPLAY_ENABLED(dev_priv) \ + (drm_WARN_ON(_priv->drm, !HAS_DISPLAY(dev_priv)), !i915_modparams.disable_display) -:22: CHECK:MACRO_ARG_PRECEDENCE: Macro argument 'dev_priv' may be better as '(dev_priv)' to avoid precedence issues #22: FILE: drivers/gpu/drm/i915/i915_drv.h:1650: +#define INTEL_DISPLAY_ENABLED(dev_priv) \ + (drm_WARN_ON(_priv->drm, !HAS_DISPLAY(dev_priv)), !i915_modparams.disable_display) -:23: WARNING:LONG_LINE: line over 100 characters #23: FILE: drivers/gpu/drm/i915/i915_drv.h:1651: + (drm_WARN_ON(_priv->drm, !HAS_DISPLAY(dev_priv)), !i915_modparams.disable_display) total: 0 errors, 1 warnings, 2 checks, 9 lines checked 7de0dff58893 drm/i915/pmu: Prefer drm_WARN_ON over WARN_ON 5597bb572e9b drm/i915/pm: Prefer drm_WARN_ON over WARN_ON 0fd60ba24842 drm/i915/runtime_pm: Prefer drm_WARN* over WARN* -:17: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #17: + struct drm_i915_private *i915 = container_of(T, struct drm_i915_private, runtime_pm); total: 0 errors, 1 warnings, 0 checks, 89 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
On Mon, 6 Apr 2020 at 13:36, Chris Wilson wrote: > > If we set the debug flag to force ourselves not to relocate via the gpu, > do not relocate via the gpu. > > Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ___ 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/3] drm/i915/perf: break OA config buffer object in 2
== Series Details == Series: series starting with [1/3] drm/i915/perf: break OA config buffer object in 2 URL : https://patchwork.freedesktop.org/series/75550/ State : success == Summary == CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17220 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/index.html Known issues Here are the changes found in Patchwork_17220 that come from known issues: ### IGT changes ### Issues hit * igt@i915_module_load@reload: - fi-skl-6770hq: [PASS][1] -> [DMESG-WARN][2] ([i915#203]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-skl-6770hq/igt@i915_module_l...@reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/fi-skl-6770hq/igt@i915_module_l...@reload.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-skl-6770hq: [PASS][3] -> [SKIP][4] ([fdo#109271]) +5 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-skl-6770hq: [PASS][5] -> [DMESG-WARN][6] ([i915#106]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8260 -> Patchwork_17220 CI-20190529: 20190529 CI_DRM_8260: fa5519e01f097b7f69259be38606ff5f1bc3cc6c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5572: 6c124b5c8501d900966c033ac86c3dc55c16a2da @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17220: 18728c0bc637aab4293092615a268bbd3e9f83a5 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 18728c0bc637 drm/i915/perf: enable filtering on multiple contexts 122d52d6d979 drm/i915/perf: prepare driver to receive multiple ctx handles d78a933fe510 drm/i915/perf: break OA config buffer object in 2 == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17220/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
Quoting Lionel Landwerlin (2020-04-06 15:30:38)
> On 06/04/2020 17:27, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-06 15:07:30)
> >> On 06/04/2020 16:59, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> On 31/03/2020 21:08, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> >> Add 2 new properties to the i915-perf open ioctl to specify an array
> >> of GEM context handles as well as the length of the array.
> > Hmm. The other thought is ctx->engine[] where one context may have more
> > than one logical context instance that OA could track. The extension to
> > track multiple pinned contexts should equally work for multiple engines.
> >
> > I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
> > struct drm_i915_gem_context_param p = {
> > .ctx_id = gem_context_create(i915),
> > .param = I915_CONTEXT_PARAM_ENGINES,
> > .value = to_user_pointer(),
> > .size = sizeof(struct i915_context_param_engines),
> > };
> > gem_context_set_param(i915, );
> >
> > would do the trick in creating one context with 64 rcs0 that they may
> > want to track. And that also opens the door to virtual engines over top.
> > -Chris
> I rather punt this away for now :)
>
> I can't see use cases for Iris/Vulkan.
> >>> There's immediate use cases for iris, since it uses 2 contexts instead
> >>> of 2 logical instances within one GL/GEM context.
> >>
> >> I don't understand this. Are you saying Iris could use the stuff from
> >> above and still select what logical context to dispatch to?
> > Yes. And can be done so only by changing the context setup to create one
> > context with two independent rcs engines (different logical GPU state,
> > and rings, *only* sharing the same vm). And since legacy EXEC_DEFAULT[0]
> > and EXEC_RENDER[1] alias to the same engine, very little code needs to be
> > changed to support (1 ctx, 2 engines) vs (2 ctx, 1 engine).
> > -Chris
>
> Sounds like there could a performance gain somewhere...
>
> Will look into this.
A year old, so a bit stale,
https://gitlab.freedesktop.org/ickle/mesa/-/commits/iris-composite-context
Note it doesn't setup a single shared timeline as Kenneth wanted to keep
explicit control over the fencing between the pipelines.
* fingers crossed that's the right version.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gem: Flush all the reloc_gpu batch
On Mon, 6 Apr 2020 at 12:48, Chris Wilson wrote:
>
> __i915_gem_object_flush_map() takes a byte range, so feed it the written
> bytes and do not mistake the u32 index as bytes!
>
> Fixes: a679f58d0510 ("drm/i915: Flush pages on acquisition")
> Signed-off-by: Chris Wilson
> Cc: Matthew Auld
> Cc: # v5.2+
Yikes.
Reviewed-by: Matthew Auld
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.DOCS: warning for series starting with [1/3] drm/i915/perf: break OA config buffer object in 2
== Series Details == Series: series starting with [1/3] drm/i915/perf: break OA config buffer object in 2 URL : https://patchwork.freedesktop.org/series/75550/ State : warning == Summary == $ make htmldocs 2>&1 > /dev/null | grep i915 ./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or member 'pinned_ctxs' not described in 'i915_perf_stream' ./drivers/gpu/drm/i915/i915_perf_types.h:319: warning: Function parameter or member 'ctx_ids' not described in 'i915_perf_stream' ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
On 06/04/2020 17:27, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than one logical context instance that OA could track. The extension to
track multiple pinned contexts should equally work for multiple engines.
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
struct drm_i915_gem_context_param p = {
.ctx_id = gem_context_create(i915),
.param = I915_CONTEXT_PARAM_ENGINES,
.value = to_user_pointer(),
.size = sizeof(struct i915_context_param_engines),
};
gem_context_set_param(i915, );
would do the trick in creating one context with 64 rcs0 that they may
want to track. And that also opens the door to virtual engines over top.
-Chris
I rather punt this away for now :)
I can't see use cases for Iris/Vulkan.
There's immediate use cases for iris, since it uses 2 contexts instead
of 2 logical instances within one GL/GEM context.
I don't understand this. Are you saying Iris could use the stuff from
above and still select what logical context to dispatch to?
Yes. And can be done so only by changing the context setup to create one
context with two independent rcs engines (different logical GPU state,
and rings, *only* sharing the same vm). And since legacy EXEC_DEFAULT[0]
and EXEC_RENDER[1] alias to the same engine, very little code needs to be
changed to support (1 ctx, 2 engines) vs (2 ctx, 1 engine).
-Chris
Sounds like there could a performance gain somewhere...
Will look into this.
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
Quoting Lionel Landwerlin (2020-04-06 15:07:30)
> On 06/04/2020 16:59, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> >> On 31/03/2020 21:08, Chris Wilson wrote:
> >>> Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> Add 2 new properties to the i915-perf open ioctl to specify an array
> of GEM context handles as well as the length of the array.
> >>> Hmm. The other thought is ctx->engine[] where one context may have more
> >>> than one logical context instance that OA could track. The extension to
> >>> track multiple pinned contexts should equally work for multiple engines.
> >>>
> >>>I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
> >>>struct drm_i915_gem_context_param p = {
> >>>.ctx_id = gem_context_create(i915),
> >>>.param = I915_CONTEXT_PARAM_ENGINES,
> >>>.value = to_user_pointer(),
> >>>.size = sizeof(struct i915_context_param_engines),
> >>>};
> >>>gem_context_set_param(i915, );
> >>>
> >>> would do the trick in creating one context with 64 rcs0 that they may
> >>> want to track. And that also opens the door to virtual engines over top.
> >>> -Chris
> >>
> >> I rather punt this away for now :)
> >>
> >> I can't see use cases for Iris/Vulkan.
> > There's immediate use cases for iris, since it uses 2 contexts instead
> > of 2 logical instances within one GL/GEM context.
>
>
> I don't understand this. Are you saying Iris could use the stuff from
> above and still select what logical context to dispatch to?
Yes. And can be done so only by changing the context setup to create one
context with two independent rcs engines (different logical GPU state,
and rings, *only* sharing the same vm). And since legacy EXEC_DEFAULT[0]
and EXEC_RENDER[1] alias to the same engine, very little code needs to be
changed to support (1 ctx, 2 engines) vs (2 ctx, 1 engine).
-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/3] drm/i915/perf: break OA config buffer object in 2
== Series Details ==
Series: series starting with [1/3] drm/i915/perf: break OA config buffer object
in 2
URL : https://patchwork.freedesktop.org/series/75550/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
d78a933fe510 drm/i915/perf: break OA config buffer object in 2
-:27: CHECK:PREFER_KERNEL_TYPES: Prefer kernel type 'u32' over 'uint32_t'
#27: FILE: drivers/gpu/drm/i915/i915_perf.c:375:
+ uint32_t per_context_offset;
total: 0 errors, 0 warnings, 1 checks, 325 lines checked
122d52d6d979 drm/i915/perf: prepare driver to receive multiple ctx handles
-:53: CHECK:SPACING: No space is necessary after a cast
#53: FILE: drivers/gpu/drm/i915/i915_perf.c:633:
+ return *((int *) elem) - *((int *) key);
-:108: CHECK:BRACES: Blank lines aren't necessary after an open brace '{'
#108: FILE: drivers/gpu/drm/i915/i915_perf.c:814:
+ reason & OAREPORT_REASON_CTX_SWITCH) {
+
-:903: WARNING:LONG_LINE: line over 100 characters
#903: FILE: drivers/gpu/drm/i915/i915_perf.c:3715:
+ props->ctx_handles = kmalloc_array(1,
sizeof(*props->ctx_handles), GFP_KERNEL);
total: 0 errors, 1 warnings, 2 checks, 1007 lines checked
18728c0bc637 drm/i915/perf: enable filtering on multiple contexts
___
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/5] drm/i915: Make exclusive awaits on i915_active optional (rev2)
== Series Details == Series: series starting with [1/5] drm/i915: Make exclusive awaits on i915_active optional (rev2) URL : https://patchwork.freedesktop.org/series/75535/ State : success == Summary == CI Bug Log - changes from CI_DRM_8260 -> Patchwork_17219 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/index.html Known issues Here are the changes found in Patchwork_17219 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_tiled_fence_blits@basic: - fi-blb-e6850: [DMESG-WARN][1] ([i915#1612]) -> [PASS][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8260/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [i915#1612]: https://gitlab.freedesktop.org/drm/intel/issues/1612 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8260 -> Patchwork_17219 CI-20190529: 20190529 CI_DRM_8260: fa5519e01f097b7f69259be38606ff5f1bc3cc6c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5572: 6c124b5c8501d900966c033ac86c3dc55c16a2da @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17219: 47ca27b829202de5f44ed84bdb09f553f29bbfc4 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 47ca27b82920 drm/i915: Export a preallocate variant of i915_active_acquire() 9695695f7772 drm/i915/gem: Assign context id for async work 00ee83ecf4d3 drm/i915/gem: Wait until the context is finally retired before releasing engines 971c702dddb6 drm/i915: Allow asynchronous waits on the i915_active barriers 5915d0bf6f0a drm/i915: Make exclusive awaits on i915_active optional == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17219/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
On 06/04/2020 16:59, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than one logical context instance that OA could track. The extension to
track multiple pinned contexts should equally work for multiple engines.
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
struct drm_i915_gem_context_param p = {
.ctx_id = gem_context_create(i915),
.param = I915_CONTEXT_PARAM_ENGINES,
.value = to_user_pointer(),
.size = sizeof(struct i915_context_param_engines),
};
gem_context_set_param(i915, );
would do the trick in creating one context with 64 rcs0 that they may
want to track. And that also opens the door to virtual engines over top.
-Chris
I rather punt this away for now :)
I can't see use cases for Iris/Vulkan.
There's immediate use cases for iris, since it uses 2 contexts instead
of 2 logical instances within one GL/GEM context.
I don't understand this. Are you saying Iris could use the stuff from
above and still select what logical context to dispatch to?
It really wants to pin a given logical context to particular set of
commands.
-Lionel
The changes you have here trivially accommodate supporting user defined
engines[], it seems a waste not to.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
Quoting Lionel Landwerlin (2020-04-06 14:54:38)
> On 31/03/2020 21:08, Chris Wilson wrote:
> > Quoting Lionel Landwerlin (2020-03-31 12:48:21)
> >> Add 2 new properties to the i915-perf open ioctl to specify an array
> >> of GEM context handles as well as the length of the array.
> > Hmm. The other thought is ctx->engine[] where one context may have more
> > than one logical context instance that OA could track. The extension to
> > track multiple pinned contexts should equally work for multiple engines.
> >
> > I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
> > struct drm_i915_gem_context_param p = {
> > .ctx_id = gem_context_create(i915),
> > .param = I915_CONTEXT_PARAM_ENGINES,
> > .value = to_user_pointer(),
> > .size = sizeof(struct i915_context_param_engines),
> > };
> > gem_context_set_param(i915, );
> >
> > would do the trick in creating one context with 64 rcs0 that they may
> > want to track. And that also opens the door to virtual engines over top.
> > -Chris
>
>
> I rather punt this away for now :)
>
> I can't see use cases for Iris/Vulkan.
There's immediate use cases for iris, since it uses 2 contexts instead
of 2 logical instances within one GL/GEM context.
The changes you have here trivially accommodate supporting user defined
engines[], it seems a waste not to.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Mon, Apr 6, 2020 at 3:38 PM Greg Kroah-Hartman wrote: > > On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote: > > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote: > > > > > > In drm we've added nice drm_device (the main gpu driver thing, which > > > also represents the userspace interfaces and has everything else > > > dangling off it) init functions using devres, devm_drm_dev_init and > > > soon devm_drm_dev_alloc (this patch series adds that). > > > > > > A slight trouble is that drm_device itself holds a reference on the > > > struct device it's sitting on top (for sysfs links and dmesg debug and > > > lots of other things), so there's a reference loop. For real drivers > > > this is broken at remove/unplug time, where all devres resources are > > > released device_release_driver(), before the final device reference is > > > dropped. So far so good. > > > > > > There's 2 exceptions: > > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > > platform device to make them look more like normal devices to > > > userspace. These aren't drivers in the driver model sense, we simple > > > create a platform_device and register it. > > > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > > the selftests aren't proper drivers in the driver model sense. > > > > > > For these two cases the reference loop isn't broken, because devres is > > > only cleaned up when the last device reference is dropped. But that's > > > not happening, because the drm_device holds that last struct device > > > reference. > > > > > > Thus far this wasn't a problem since the above cases simply > > > hand-rolled their cleanup code. But I want to convert all drivers over > > > to the devm_ versions, hence it would be really nice if these > > > virtual/fake/mock uses-cases could also be managed with devres > > > cleanup. > > > > > > I see three possible approaches: > > > > Restarting this at the top level, because the discussion thus far just > > ended in a long "you're doing it wrong", despite that I think we're > > doing what v4l is doing (plus/minus that we can't do an exact matching > > handling in drm because our uapi has a lot more warts, which we can't > > change because no breaking userspace). > > > > So which one of the three below is the right approach? > > > > Aside, looking at the v4l solution I think there's also a confusion > > about struct device representing a char device (which v4l directly > > uses as its userspace interface refcounted thing, and which drm does > > _not_ directly). And a struct device embedded into something like > > platform_device or a virtual device, where a driver can bind to. My > > question here is about the former, I don't care how cdev struct device > > are cleaned up one bit. Now if other subsystems relies on the devres > > cleanup behaviour we currently have because of such cdev usage, then > > yeah first approach doesn't work (and I have a big surprised that use > > case, but hey would actually learn something). > > > > End of aside, since again I want to figure out which of the tree > > approaches it the right one. Not about how wrong one of them is, > > ignoring the other three I laid out. And maybe there's even more > > options for this. > > Sorry, been swamped with other things, give me a few days to get back to > this, I need to dig into how you all are dealing with the virtual > drivers. Sure, no problem. > Doing this in the middle of the merge window is a bit rough :) Ah I always forget ... we freeze drm at -rc6, so merge window is actually my most relaxed time since everyone is busy and no one has time to report drm bugs :-) Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/perf: enable filtering on multiple contexts
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
This can be used by drivers using multiple GEM contexts to implement a
single GL context.
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 58 ++--
include/uapi/drm/i915_drm.h | 21
2 files changed, 76 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 008d2e55f923..48f77a7253bc 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -3656,7 +3656,8 @@ static int read_properties_unlocked(struct i915_perf
*perf,
struct perf_open_properties *props)
{
u64 __user *uprop = uprops;
- u32 i;
+ u32 __user *uctx_handles = NULL;
+ u32 i, n_uctx_handles = 0;
int err;
memset(props, 0, sizeof(struct perf_open_properties));
@@ -3707,7 +3708,7 @@ static int read_properties_unlocked(struct i915_perf
*perf,
switch ((enum drm_i915_perf_property_id)id) {
case DRM_I915_PERF_PROP_CTX_HANDLE:
- if (props->n_ctx_handles > 0) {
+ if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
DRM_DEBUG("Context handle specified multiple
times\n");
err = -EINVAL;
goto error;
@@ -3819,6 +3820,38 @@ static int read_properties_unlocked(struct i915_perf
*perf,
}
props->poll_oa_period = value;
break;
+ case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY:
+ /* HSW can only filter in HW and only on a single
+* context.
+*/
+ if (IS_HASWELL(perf->i915)) {
+ DRM_DEBUG("Multi context filter not supported
on HSW\n");
+ err = -ENODEV;
+ goto error;
+ }
+ uctx_handles = u64_to_user_ptr(value);
+ break;
+ case DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH:
+ if (IS_HASWELL(perf->i915)) {
+ DRM_DEBUG("Multi context filter not supported
on HSW\n");
+ err = -ENODEV;
+ goto error;
+ }
+ if (props->n_ctx_handles > 0 || n_uctx_handles > 0) {
+ DRM_DEBUG("Context handle specified multiple
times\n");
+ err = -EINVAL;
+ goto error;
+ }
+ props->ctx_handles =
+ kmalloc_array(value,
+ sizeof(*props->ctx_handles),
+ GFP_KERNEL);
+ if (!props->ctx_handles) {
+ err = -ENOMEM;
+ goto error;
+ }
+ n_uctx_handles = value;
+ break;
case DRM_I915_PERF_PROP_MAX:
MISSING_CASE(id);
err = -EINVAL;
@@ -3828,6 +3861,21 @@ static int read_properties_unlocked(struct i915_perf
*perf,
uprop += 2;
}
+ if (n_uctx_handles > 0 && props->n_ctx_handles > 0) {
+ DRM_DEBUG("Context handle specified multiple times\n");
+ err = -EINVAL;
+ goto error;
+ }
+
+ for (i = 0; i < n_uctx_handles; i++) {
+ err = get_user(props->ctx_handles[i], uctx_handles);
+ if (err)
+ goto error;
+
+ uctx_handles++;
+ props->n_ctx_handles++;
+ }
+
return 0;
error:
@@ -4611,8 +4659,12 @@ int i915_perf_ioctl_version(void)
*
* 5: Add DRM_I915_PERF_PROP_POLL_OA_PERIOD parameter that controls the
*interval for the hrtimer used to check for OA data.
+*
+* 6: Add DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY &
+*DRM_I915_PERF_PROP_CTX_HANDLE_ARRAY_LENGTH to allow an
+*application monitor/pin multiple contexts.
*/
- return 5;
+ return 6;
}
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 14b67cd6b54b..f80e7932d728 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1993,6 +1993,27 @@ enum drm_i915_perf_property_id {
*/
DRM_I915_PERF_PROP_POLL_OA_PERIOD,
+ /**
+* Specifies an array of u32 GEM context handles to filter reports
+* with.
+
[Intel-gfx] [PATCH 2/3] drm/i915/perf: prepare driver to receive multiple ctx handles
Make all the internal necessary changes before we flip the switch.
v2: Use an unlimited number of intel contexts (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 587 +++--
drivers/gpu/drm/i915/i915_perf_types.h | 23 +-
2 files changed, 364 insertions(+), 246 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index e7bbb09e84a1..008d2e55f923 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -192,6 +192,7 @@
*/
#include
+#include
#include
#include
@@ -329,7 +330,8 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
* @single_context: Whether a single or all gpu contexts should be monitored
* @hold_preemption: Whether the preemption is disabled for the filtered
* context
- * @ctx_handle: A gem ctx handle for use with @single_context
+ * @n_ctx_handles: Length of @ctx_handles
+ * @ctx_handles: An array of gem context handles
* @metrics_set: An ID for an OA unit metric set advertised via sysfs
* @oa_format: An OA unit HW report format
* @oa_periodic: Whether to enable periodic OA unit sampling
@@ -349,9 +351,10 @@ static const struct i915_oa_format
gen12_oa_formats[I915_OA_FORMAT_MAX] = {
struct perf_open_properties {
u32 sample_flags;
- u64 single_context:1;
u64 hold_preemption:1;
- u64 ctx_handle;
+
+ u32 n_ctx_handles;
+ u32 *ctx_handles;
/* OA sampling state */
int metrics_set;
@@ -625,6 +628,21 @@ static int append_oa_sample(struct i915_perf_stream
*stream,
return 0;
}
+static int ctx_id_equal(const void *key, const void *elem)
+{
+ return *((int *) elem) - *((int *) key);
+}
+
+static inline bool ctx_id_match(struct i915_perf_stream *stream,
+ u32 masked_ctx_id)
+{
+ return bsearch(_ctx_id,
+ stream->ctx_ids,
+ stream->n_ctxs,
+ sizeof(*stream->ctx_ids),
+ ctx_id_equal) != NULL;
+}
+
/**
* Copies all buffered OA reports into userspace read() buffer.
* @stream: An i915-perf stream opened for OA metrics
@@ -736,7 +754,7 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
continue;
}
- ctx_id = report32[2] & stream->specific_ctx_id_mask;
+ ctx_id = report32[2] & stream->ctx_id_mask;
/*
* Squash whatever is in the CTX_ID field if it's marked as
@@ -781,26 +799,33 @@ static int gen8_append_oa_reports(struct i915_perf_stream
*stream,
* switches since it's not-uncommon for periodic samples to
* identify a switch before any 'context switch' report.
*/
- if (!stream->perf->exclusive_stream->ctx ||
- stream->specific_ctx_id == ctx_id ||
- stream->oa_buffer.last_ctx_id == stream->specific_ctx_id ||
- reason & OAREPORT_REASON_CTX_SWITCH) {
-
- /*
-* While filtering for a single context we avoid
-* leaking the IDs of other contexts.
-*/
- if (stream->perf->exclusive_stream->ctx &&
- stream->specific_ctx_id != ctx_id) {
- report32[2] = INVALID_CTX_ID;
- }
-
+ if (!stream->perf->exclusive_stream->n_ctxs) {
ret = append_oa_sample(stream, buf, count, offset,
report);
if (ret)
break;
+ } else {
+ bool ctx_match = ctx_id != INVALID_CTX_ID &&
+ ctx_id_match(stream, ctx_id);
+
+ if (ctx_match ||
+ stream->oa_buffer.last_ctx_match ||
+ reason & OAREPORT_REASON_CTX_SWITCH) {
+
+ /*
+* While filtering for a single context we avoid
+* leaking the IDs of other contexts.
+*/
+ if (!ctx_match)
+ report32[2] = INVALID_CTX_ID;
+
+ ret = append_oa_sample(stream, buf, count,
offset,
+ report);
+ if (ret)
+ break;
+ }
- stream->oa_buffer.last_ctx_id = ctx_id;
+ stream->oa_buffer.last_ctx_match = ctx_match;
}
/*
@@ -1191,138 +1216,163 @@ static int i915_oa_read(struct
[Intel-gfx] [PATCH 1/3] drm/i915/perf: break OA config buffer object in 2
We want to enable performance monitoring on multiple contexts to cover
the Iris use case of using 2 GEM contexts (3D & compute).
So start by breaking the OA configuration BO which contains global &
per context register writes.
NOA muxes & OA configurations are global, while FLEXEU register
configurations are per context.
v2: Use an offset into the same VMA (Chris)
Signed-off-by: Lionel Landwerlin
---
drivers/gpu/drm/i915/i915_perf.c | 176 ---
1 file changed, 116 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c
index 2f78b147bb2d..e7bbb09e84a1 100644
--- a/drivers/gpu/drm/i915/i915_perf.c
+++ b/drivers/gpu/drm/i915/i915_perf.c
@@ -372,6 +372,7 @@ struct i915_oa_config_bo {
struct i915_oa_config *oa_config;
struct i915_vma *vma;
+ uint32_t per_context_offset;
};
static struct ctl_table_header *sysctl_header;
@@ -1826,37 +1827,43 @@ static struct i915_oa_config_bo *
alloc_oa_config_buffer(struct i915_perf_stream *stream,
struct i915_oa_config *oa_config)
{
- struct drm_i915_gem_object *obj;
struct i915_oa_config_bo *oa_bo;
+ struct drm_i915_gem_object *obj;
size_t config_length = 0;
- u32 *cs;
+ u32 *cs_start, *cs;
int err;
oa_bo = kzalloc(sizeof(*oa_bo), GFP_KERNEL);
if (!oa_bo)
return ERR_PTR(-ENOMEM);
+ /*
+* Global configuration requires a jump into the NOA wait BO for it to
+* apply.
+*/
config_length += num_lri_dwords(oa_config->mux_regs_len);
config_length += num_lri_dwords(oa_config->b_counter_regs_len);
- config_length += num_lri_dwords(oa_config->flex_regs_len);
config_length += 3; /* MI_BATCH_BUFFER_START */
+
+ config_length += num_lri_dwords(oa_config->flex_regs_len);
+ config_length += 1 /* MI_BATCH_BUFFER_END */;
+
config_length = ALIGN(sizeof(u32) * config_length, I915_GTT_PAGE_SIZE);
- obj = i915_gem_object_create_shmem(stream->perf->i915, config_length);
+ obj = i915_gem_object_create_shmem(stream->perf->i915,
+ config_length);
if (IS_ERR(obj)) {
err = PTR_ERR(obj);
goto err_free;
}
- cs = i915_gem_object_pin_map(obj, I915_MAP_WB);
- if (IS_ERR(cs)) {
- err = PTR_ERR(cs);
- goto err_oa_bo;
+ cs_start = i915_gem_object_pin_map(obj, I915_MAP_WB);
+ if (IS_ERR(cs_start)) {
+ err = PTR_ERR(cs_start);
+ goto err_bo;
}
- cs = write_cs_mi_lri(cs,
-oa_config->mux_regs,
-oa_config->mux_regs_len);
+ cs = cs_start;
cs = write_cs_mi_lri(cs,
oa_config->b_counter_regs,
oa_config->b_counter_regs_len);
@@ -1871,6 +1878,14 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
*cs++ = i915_ggtt_offset(stream->noa_wait);
*cs++ = 0;
+ oa_bo->per_context_offset = 4 * (cs - cs_start);
+
+ cs = write_cs_mi_lri(cs,
+oa_config->mux_regs,
+oa_config->mux_regs_len);
+
+ *cs++ = MI_BATCH_BUFFER_END;
+
i915_gem_object_flush_map(obj);
i915_gem_object_unpin_map(obj);
@@ -1879,7 +1894,7 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
NULL);
if (IS_ERR(oa_bo->vma)) {
err = PTR_ERR(oa_bo->vma);
- goto err_oa_bo;
+ goto err_bo;
}
oa_bo->oa_config = i915_oa_config_get(oa_config);
@@ -1887,15 +1902,15 @@ alloc_oa_config_buffer(struct i915_perf_stream *stream,
return oa_bo;
-err_oa_bo:
+err_bo:
i915_gem_object_put(obj);
err_free:
kfree(oa_bo);
return ERR_PTR(err);
}
-static struct i915_vma *
-get_oa_vma(struct i915_perf_stream *stream, struct i915_oa_config *oa_config)
+static struct i915_oa_config_bo *
+get_oa_bo(struct i915_perf_stream *stream, struct i915_oa_config *oa_config)
{
struct i915_oa_config_bo *oa_bo;
@@ -1908,34 +1923,31 @@ get_oa_vma(struct i915_perf_stream *stream, struct
i915_oa_config *oa_config)
memcmp(oa_bo->oa_config->uuid,
oa_config->uuid,
sizeof(oa_config->uuid)) == 0)
- goto out;
+ return oa_bo;
}
- oa_bo = alloc_oa_config_buffer(stream, oa_config);
- if (IS_ERR(oa_bo))
- return ERR_CAST(oa_bo);
-
-out:
- return i915_vma_get(oa_bo->vma);
+ return alloc_oa_config_buffer(stream, oa_config);
}
static int
emit_oa_config(struct i915_perf_stream *stream,
struct i915_oa_config *oa_config,
struct
Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/perf: enable filtering on multiple contexts
On 31/03/2020 21:08, Chris Wilson wrote:
Quoting Lionel Landwerlin (2020-03-31 12:48:21)
Add 2 new properties to the i915-perf open ioctl to specify an array
of GEM context handles as well as the length of the array.
Hmm. The other thought is ctx->engine[] where one context may have more
than one logical context instance that OA could track. The extension to
track multiple pinned contexts should equally work for multiple engines.
I915_DEFINE_CONTEXT_PARAM_ENGINES(engines, 64) = {};
struct drm_i915_gem_context_param p = {
.ctx_id = gem_context_create(i915),
.param = I915_CONTEXT_PARAM_ENGINES,
.value = to_user_pointer(),
.size = sizeof(struct i915_context_param_engines),
};
gem_context_set_param(i915, );
would do the trick in creating one context with 64 rcs0 that they may
want to track. And that also opens the door to virtual engines over top.
-Chris
I rather punt this away for now :)
I can't see use cases for Iris/Vulkan.
This seems more of a media thing where we have multiple engines already.
And media doesn't do much perf queries because much of the available
counters are 3D/compute and queries are not available on media engines.
We can always bump the perf revision later once we've figured how this
would be used.
-Lionel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Mon, Apr 06, 2020 at 02:32:51PM +0200, Daniel Vetter wrote: > On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote: > > > > In drm we've added nice drm_device (the main gpu driver thing, which > > also represents the userspace interfaces and has everything else > > dangling off it) init functions using devres, devm_drm_dev_init and > > soon devm_drm_dev_alloc (this patch series adds that). > > > > A slight trouble is that drm_device itself holds a reference on the > > struct device it's sitting on top (for sysfs links and dmesg debug and > > lots of other things), so there's a reference loop. For real drivers > > this is broken at remove/unplug time, where all devres resources are > > released device_release_driver(), before the final device reference is > > dropped. So far so good. > > > > There's 2 exceptions: > > - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual > > platform device to make them look more like normal devices to > > userspace. These aren't drivers in the driver model sense, we simple > > create a platform_device and register it. > > > > - drm/i915/selftests, where we create minimal mock devices, and again > > the selftests aren't proper drivers in the driver model sense. > > > > For these two cases the reference loop isn't broken, because devres is > > only cleaned up when the last device reference is dropped. But that's > > not happening, because the drm_device holds that last struct device > > reference. > > > > Thus far this wasn't a problem since the above cases simply > > hand-rolled their cleanup code. But I want to convert all drivers over > > to the devm_ versions, hence it would be really nice if these > > virtual/fake/mock uses-cases could also be managed with devres > > cleanup. > > > > I see three possible approaches: > > Restarting this at the top level, because the discussion thus far just > ended in a long "you're doing it wrong", despite that I think we're > doing what v4l is doing (plus/minus that we can't do an exact matching > handling in drm because our uapi has a lot more warts, which we can't > change because no breaking userspace). > > So which one of the three below is the right approach? > > Aside, looking at the v4l solution I think there's also a confusion > about struct device representing a char device (which v4l directly > uses as its userspace interface refcounted thing, and which drm does > _not_ directly). And a struct device embedded into something like > platform_device or a virtual device, where a driver can bind to. My > question here is about the former, I don't care how cdev struct device > are cleaned up one bit. Now if other subsystems relies on the devres > cleanup behaviour we currently have because of such cdev usage, then > yeah first approach doesn't work (and I have a big surprised that use > case, but hey would actually learn something). > > End of aside, since again I want to figure out which of the tree > approaches it the right one. Not about how wrong one of them is, > ignoring the other three I laid out. And maybe there's even more > options for this. Sorry, been swamped with other things, give me a few days to get back to this, I need to dig into how you all are dealing with the virtual drivers. Doing this in the middle of the merge window is a bit rough :) thanks, greg k-h ___ 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/5] drm/i915: Make exclusive awaits on i915_active optional
== Series Details ==
Series: series starting with [1/5] drm/i915: Make exclusive awaits on
i915_active optional
URL : https://patchwork.freedesktop.org/series/75535/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_8259_full -> Patchwork_17215_full
Summary
---
**SUCCESS**
No regressions found.
Possible new issues
---
Here are the unknown changes that may have been introduced in
Patchwork_17215_full:
### IGT changes ###
Suppressed
The following results come from untrusted machines, tests, or statuses.
They do not affect the overall result.
* {igt@gem_exec_schedule@pi-shared-iova@vecs0}:
- shard-skl: [PASS][1] -> [INCOMPLETE][2]
[1]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl10/igt@gem_exec_schedule@pi-shared-i...@vecs0.html
[2]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-skl6/igt@gem_exec_schedule@pi-shared-i...@vecs0.html
Known issues
Here are the changes found in Patchwork_17215_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_ctx_persistence@processes:
- shard-apl: [PASS][3] -> [FAIL][4] ([i915#1528])
[3]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-apl7/igt@gem_ctx_persiste...@processes.html
[4]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-apl1/igt@gem_ctx_persiste...@processes.html
* igt@i915_suspend@forcewake:
- shard-apl: [PASS][5] -> [DMESG-WARN][6] ([i915#180])
[5]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-apl2/igt@i915_susp...@forcewake.html
[6]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-apl4/igt@i915_susp...@forcewake.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-kbl: [PASS][7] -> [DMESG-WARN][8] ([i915#180]) +4 similar
issues
[7]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-kbl6/igt@kms_cursor_...@pipe-a-cursor-suspend.html
[8]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-kbl1/igt@kms_cursor_...@pipe-a-cursor-suspend.html
* igt@kms_cursor_crc@pipe-b-cursor-128x128-sliding:
- shard-apl: [PASS][9] -> [FAIL][10] ([i915#54])
[9]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-apl1/igt@kms_cursor_...@pipe-b-cursor-128x128-sliding.html
[10]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-apl3/igt@kms_cursor_...@pipe-b-cursor-128x128-sliding.html
* igt@kms_draw_crc@draw-method-rgb565-pwrite-ytiled:
- shard-glk: [PASS][11] -> [FAIL][12] ([i915#52] / [i915#54]) +2
similar issues
[11]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-glk6/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html
[12]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-glk9/igt@kms_draw_...@draw-method-rgb565-pwrite-ytiled.html
* igt@kms_hdr@bpc-switch:
- shard-skl: [PASS][13] -> [FAIL][14] ([i915#1188])
[13]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl10/igt@kms_...@bpc-switch.html
[14]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-skl5/igt@kms_...@bpc-switch.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][15] -> [FAIL][16] ([fdo#108145] / [i915#265])
[15]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-skl2/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
[16]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-skl6/igt@kms_plane_alpha_bl...@pipe-a-constant-alpha-min.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [PASS][17] -> [SKIP][18] ([fdo#109441]) +2 similar
issues
[17]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
[18]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-iclb8/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-apl: [PASS][19] -> [FAIL][20] ([i915#31])
[19]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-apl1/igt@kms_setm...@basic.html
[20]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-apl1/igt@kms_setm...@basic.html
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-iclb: [PASS][21] -> [INCOMPLETE][22] ([i915#1185])
[21]:
https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/shard-iclb5/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
[22]:
https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17215/shard-iclb3/igt@kms_vbl...@pipe-c-ts-continuation-dpms-suspend.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-tglb: [PASS][23] -> [INCOMPLETE][24] ([i915#456] /
[i915#460])
[23]:
[Intel-gfx] [PATCH v2] drm/i915: Allow asynchronous waits on the i915_active barriers
Allow the caller to also wait upon the barriers stored in i915_active.
v2: Hook up i915_request_await_active(I915_ACTIVE_AWAIT_BARRIER) as well
for completeness, and avoid the lazy GEM_BUG_ON()!
v3: Pull flush_lazy_signals() under the active-ref protection as it too
walks the rbtree and so we must be careful that we do not free it as we
iterate.
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_active.c | 73 ++
drivers/gpu/drm/i915/i915_active.h | 1 +
2 files changed, 64 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_active.c
b/drivers/gpu/drm/i915/i915_active.c
index d5e24be759f7..d960d0be5bd2 100644
--- a/drivers/gpu/drm/i915/i915_active.c
+++ b/drivers/gpu/drm/i915/i915_active.c
@@ -542,35 +542,88 @@ static int __await_active(struct i915_active_fence
*active,
return 0;
}
+struct wait_barrier {
+ struct wait_queue_entry base;
+ struct i915_active *ref;
+};
+
+static int
+barrier_wake(wait_queue_entry_t *wq, unsigned int mode, int flags, void *key)
+{
+ struct wait_barrier *wb = container_of(wq, typeof(*wb), base);
+
+ if (i915_active_is_idle(wb->ref)) {
+ list_del(>entry);
+ i915_sw_fence_complete(wq->private);
+ kfree(wq);
+ }
+
+ return 0;
+}
+
+static int __await_barrier(struct i915_active *ref, struct i915_sw_fence
*fence)
+{
+ struct wait_barrier *wb;
+
+ wb = kmalloc(sizeof(*wb), GFP_KERNEL);
+ if (unlikely(!wb))
+ return -ENOMEM;
+
+ GEM_BUG_ON(i915_active_is_idle(ref));
+ if (!i915_sw_fence_await(fence)) {
+ kfree(wb);
+ return -EINVAL;
+ }
+
+ wb->base.flags = 0;
+ wb->base.func = barrier_wake;
+ wb->base.private = fence;
+ wb->ref = ref;
+
+ add_wait_queue(__var_waitqueue(ref), >base);
+ return 0;
+}
+
static int await_active(struct i915_active *ref,
unsigned int flags,
int (*fn)(void *arg, struct dma_fence *fence),
- void *arg)
+ void *arg, struct i915_sw_fence *barrier)
{
int err = 0;
+ if (!i915_active_acquire_if_busy(ref))
+ return 0;
+
if (flags & I915_ACTIVE_AWAIT_EXCL &&
rcu_access_pointer(ref->excl.fence)) {
err = __await_active(>excl, fn, arg);
if (err)
- return err;
+ goto out;
}
- if (flags & I915_ACTIVE_AWAIT_ACTIVE &&
- i915_active_acquire_if_busy(ref)) {
+ if (flags & I915_ACTIVE_AWAIT_ACTIVE) {
struct active_node *it, *n;
rbtree_postorder_for_each_entry_safe(it, n, >tree, node) {
err = __await_active(>base, fn, arg);
if (err)
- break;
+ goto out;
}
- i915_active_release(ref);
+ }
+
+ if (flags & I915_ACTIVE_AWAIT_BARRIER) {
+ err = flush_lazy_signals(ref);
if (err)
- return err;
+ goto out;
+
+ err = __await_barrier(ref, barrier);
+ if (err)
+ goto out;
}
- return 0;
+out:
+ i915_active_release(ref);
+ return err;
}
static int rq_await_fence(void *arg, struct dma_fence *fence)
@@ -582,7 +635,7 @@ int i915_request_await_active(struct i915_request *rq,
struct i915_active *ref,
unsigned int flags)
{
- return await_active(ref, flags, rq_await_fence, rq);
+ return await_active(ref, flags, rq_await_fence, rq, >submit);
}
static int sw_await_fence(void *arg, struct dma_fence *fence)
@@ -595,7 +648,7 @@ int i915_sw_fence_await_active(struct i915_sw_fence *fence,
struct i915_active *ref,
unsigned int flags)
{
- return await_active(ref, flags, sw_await_fence, fence);
+ return await_active(ref, flags, sw_await_fence, fence, fence);
}
#if IS_ENABLED(CONFIG_DRM_I915_DEBUG_GEM)
diff --git a/drivers/gpu/drm/i915/i915_active.h
b/drivers/gpu/drm/i915/i915_active.h
index ffafaa78c494..cf4058150966 100644
--- a/drivers/gpu/drm/i915/i915_active.h
+++ b/drivers/gpu/drm/i915/i915_active.h
@@ -195,6 +195,7 @@ int i915_request_await_active(struct i915_request *rq,
unsigned int flags);
#define I915_ACTIVE_AWAIT_EXCL BIT(0)
#define I915_ACTIVE_AWAIT_ACTIVE BIT(1)
+#define I915_ACTIVE_AWAIT_BARRIER BIT(2)
int i915_active_acquire(struct i915_active *ref);
bool i915_active_acquire_if_busy(struct i915_active *ref);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
== Series Details == Series: drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu URL : https://patchwork.freedesktop.org/series/75546/ State : success == Summary == CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17218 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/index.html Known issues Here are the changes found in Patchwork_17218 that come from known issues: ### IGT changes ### Issues hit * igt@gem_tiled_fence_blits@basic: - fi-blb-e6850: [PASS][1] -> [DMESG-WARN][2] ([i915#1612]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/fi-blb-e6850/igt@gem_tiled_fence_bl...@basic.html * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [PASS][3] -> [FAIL][4] ([i915#976]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][5] -> [SKIP][6] ([fdo#109271]) +24 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1612]: https://gitlab.freedesktop.org/drm/intel/issues/1612 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (53 -> 46) -- Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8259 -> Patchwork_17218 CI-20190529: 20190529 CI_DRM_8259: 450fc86b62651336f9b5fde79c068df7b4c95aa4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5571: da79d5fa2ebed237f0561a54b4b63bae6f21503a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17218: ba343fe4ed968ea92207838b69dd79c8e09f9b53 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == ba343fe4ed96 drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17218/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Allow asynchronous waits on the i915_active barriers
Quoting Chris Wilson (2020-04-06 14:09:44)
> Quoting Tvrtko Ursulin (2020-04-06 13:06:03)
> >
> > On 06/04/2020 10:12, Chris Wilson wrote:
> > > Allow the caller to also wait upon the barriers stored in i915_active.
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/i915_active.c | 60 ++
> > > drivers/gpu/drm/i915/i915_active.h | 1 +
> > > 2 files changed, 61 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > > b/drivers/gpu/drm/i915/i915_active.c
> > > index d5e24be759f7..048ab9edd2c2 100644
> > > --- a/drivers/gpu/drm/i915/i915_active.c
> > > +++ b/drivers/gpu/drm/i915/i915_active.c
> > > @@ -542,6 +542,55 @@ static int __await_active(struct i915_active_fence
> > > *active,
> > > return 0;
> > > }
> > >
> > > +struct wait_barrier {
> > > + struct wait_queue_entry base;
> > > + struct i915_active *ref;
> > > +};
> > > +
> > > +static int
> > > +barrier_wake(wait_queue_entry_t *wq, unsigned int mode, int flags, void
> > > *key)
> > > +{
> > > + struct wait_barrier *wb = container_of(wq, typeof(*wb), base);
> > > +
> > > + if (i915_active_is_idle(wb->ref)) { /* shared waitqueue, must
> > > check! */
> >
> > Who shares it?
>
> __var_waitqueue(ref) => uses a one of a set of global workqueues based
> off hash(ref)
>
> Or we add a wait_queue_head_t to active, but we would still need to
> recheck as it may be reused as we are signaled.
>
> > > + if (flags & I915_ACTIVE_AWAIT_BARRIER) {
> > > + err = flush_lazy_signals(ref);
> > > + if (err)
> > > + return err;
> > > +
> > > + err = __await_barrier(ref, arg);
> > > + if (err)
> > > + return err;
> > >
> >
> > Could have a single set of active_acquire_if_busy/release over the
> > previous and this new block. Not sure if that would help with any
> > atomicity concerns, or if there are such.
>
> It would not affect correctness, it will just depend on taste.
Actually, flush_lazy_signals needs to be inside the active-ref, so we
should rearrange the acquires.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915: Allow asynchronous waits on the i915_active barriers
Quoting Tvrtko Ursulin (2020-04-06 13:06:03)
>
> On 06/04/2020 10:12, Chris Wilson wrote:
> > Allow the caller to also wait upon the barriers stored in i915_active.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_active.c | 60 ++
> > drivers/gpu/drm/i915/i915_active.h | 1 +
> > 2 files changed, 61 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_active.c
> > b/drivers/gpu/drm/i915/i915_active.c
> > index d5e24be759f7..048ab9edd2c2 100644
> > --- a/drivers/gpu/drm/i915/i915_active.c
> > +++ b/drivers/gpu/drm/i915/i915_active.c
> > @@ -542,6 +542,55 @@ static int __await_active(struct i915_active_fence
> > *active,
> > return 0;
> > }
> >
> > +struct wait_barrier {
> > + struct wait_queue_entry base;
> > + struct i915_active *ref;
> > +};
> > +
> > +static int
> > +barrier_wake(wait_queue_entry_t *wq, unsigned int mode, int flags, void
> > *key)
> > +{
> > + struct wait_barrier *wb = container_of(wq, typeof(*wb), base);
> > +
> > + if (i915_active_is_idle(wb->ref)) { /* shared waitqueue, must check!
> > */
>
> Who shares it?
__var_waitqueue(ref) => uses a one of a set of global workqueues based
off hash(ref)
Or we add a wait_queue_head_t to active, but we would still need to
recheck as it may be reused as we are signaled.
> > + if (flags & I915_ACTIVE_AWAIT_BARRIER) {
> > + err = flush_lazy_signals(ref);
> > + if (err)
> > + return err;
> > +
> > + err = __await_barrier(ref, arg);
> > + if (err)
> > + return err;
> >
>
> Could have a single set of active_acquire_if_busy/release over the
> previous and this new block. Not sure if that would help with any
> atomicity concerns, or if there are such.
It would not affect correctness, it will just depend on taste.
> + }
> > +
> > return 0;
> > }
> >
> > @@ -582,6 +641,7 @@ int i915_request_await_active(struct i915_request *rq,
> > struct i915_active *ref,
> > unsigned int flags)
> > {
> > + GEM_BUG_ON(flags & I915_ACTIVE_AWAIT_BARRIER);
>
> Why is this an error?
Because I'm being lazy and not hooking up the correct signaling path.
Instead of signaling arg == fence, we would need >submit. Just
messy on how to pass down the details.
Maybe
return await_active(ref, flags, rq_await_fence, rq, >submit);
and
return await_active(ref, flags, sw_await_fence, fence, fence);
That seems better than I was expecting.
-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/tc/icl: Implement TC cold sequences
On Fri, Apr 03, 2020 at 04:18:54AM +0300, Souza, Jose wrote: > Hi Imre > > I guess I did all the requested changes but trybot got some > warnings that I will need more time to understand and fix it. > > If you have time please check if is this way that you are asking: > https://github.com/zehortigoza/linux/tree/tccold-v3 Yes looks ok overall, I added a few comments on the trybot patches. > Trybot warnings: > https://intel-gfx-ci.01.org/tree/drm-tip/Trybot_5784/bat-all.html I see here <3> [428.836598] [drm:tc_port_live_status_mask [i915]] *ERROR* Port D/TC#2: live status 0004 mismatches the legacy port flag, fix flag which is a known buggy VBT issue and i915 :00:02.0: drm_WARN_ON(!power_well->desc->hsw.is_tc_tbt || !(((&(dev_priv)->__info)->gen) == 11 && dig_port->tc_legacy_port)) which is just a typo. > Thanks > > On Thu, 2020-04-02 at 04:02 +0300, Imre Deak wrote: > > On Thu, Apr 02, 2020 at 01:35:30AM +0300, Souza, Jose wrote: > > > On Wed, 2020-04-01 at 15:43 +0300, Imre Deak wrote: > > > > On Tue, Mar 31, 2020 at 05:41:19PM -0700, José Roberto de Souza > > > > wrote: > > > > > This is required for legacy/static TC ports as IOM is not aware > > > > > of > > > > > the connection and will not trigger the TC cold exit. > > > > > > > > > > Just request PCODE to exit TCCOLD is not enough as it could > > > > > enter > > > > > again be driver makes use of the port, to prevent it BSpec > > > > > states > > > > > that > > > > > aux powerwell should be held. > > > > > > > > > > So here embedding the TC cold exit sequence into ICL aux > > > > > enable, > > > > > it will enable aux, request tc cold exit and depending in the > > > > > TC > > > > > live > > > > > state continue with the regular aux enable sequence. > > > > > > > > > > And then turning on aux power well during tc lock and turning > > > > > off > > > > > during unlock both depending into the TC port refcount. > > > > > > > > > > BSpec: 21750 > > > > > Fixes: https://gitlab.freedesktop.org/drm/intel/issues/1296 > > > > > Cc: Imre Deak > > > > > Cc: Cooper Chiou > > > > > Cc: Kai-Heng Feng > > > > > Signed-off-by: José Roberto de Souza > > > > > --- > > > > > > > > > > Will run some tests in the office with TBT dockstation to check > > > > > if > > > > > it will be a issue keep both aux enabled. Otherwise more > > > > > changes > > > > > will > > > > > be required here. > > > > > > > > > > .../drm/i915/display/intel_display_power.c| 12 - > > > > > .../drm/i915/display/intel_display_types.h| 1 + > > > > > drivers/gpu/drm/i915/display/intel_tc.c | 47 > > > > > ++- > > > > > drivers/gpu/drm/i915/display/intel_tc.h | 2 + > > > > > drivers/gpu/drm/i915/i915_reg.h | 1 + > > > > > 5 files changed, 59 insertions(+), 4 deletions(-) > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/display/intel_display_power.c > > > > > b/drivers/gpu/drm/i915/display/intel_display_power.c > > > > > index dbd61517ba63..1ccd57d645c7 100644 > > > > > --- a/drivers/gpu/drm/i915/display/intel_display_power.c > > > > > +++ b/drivers/gpu/drm/i915/display/intel_display_power.c > > > > > @@ -592,9 +592,17 @@ icl_tc_phy_aux_power_well_enable(struct > > > > > drm_i915_private *dev_priv, > > > > > > > > > > _hsw_power_well_enable(dev_priv, power_well); > > > > > > > > > > - /* TODO ICL TC cold handling */ > > > > > + if (INTEL_GEN(dev_priv) == 11) > > > > > > > > Should be if (ICL && dig_port->tc_legacy_port) > > > > > > Makes sence. > > > Oh so we could use it on __intel_tc_port_lock() too and > > > don't do this stuff for non legacy ports. Until we get a report of > > > a > > > system with a wrong VBT :P > > > > Yes, it's a loss of the vendor shipping a corrupt VBT. But we'll > > print > > an error and fix up the flag. > > > > > > > + intel_tc_icl_tc_cold_exit(dev_priv); > > > > > > > > > > - _hsw_power_well_continue_enable(dev_priv, power_well); > > > > > + /* > > > > > + * To avoid power well enable timeouts when > > > > > disconnected or in > > > > > TBT mode > > > > > + * when doing the TC cold exit sequence for GEN11 > > > > > + */ > > > > > + if (INTEL_GEN(dev_priv) != 11 || > > > > > + (intel_tc_port_live_status_mask(dig_port) & > > > > > + (TC_PORT_LEGACY | TC_PORT_DP_ALT))) > > > > > + _hsw_power_well_continue_enable(dev_priv, > > > > > power_well); > > > > > > > > Why can't we call this unconditionally? > > > > > > Because we are requesting aux power of regular TC ports as part of > > > tc > > > cold exit sequence, if the port is disconnected it will timeout in > > > hsw_wait_for_power_well_enable(). > > > > > > Anyways it is wrong as it is not > > > taking care of TBT ports, so changing to: if (INTEL_GEN(dev_priv) > > > != 11 > > > > > !dig_port->tc_legacy_port || intel_tc_port_live_status_mask()) > > > > What I thought is that the legacy AUX power request will ack after > > the > >
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gem: Flush all the reloc_gpu batch
== Series Details == Series: drm/i915/gem: Flush all the reloc_gpu batch URL : https://patchwork.freedesktop.org/series/75544/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17217 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17217 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17217, 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_17217/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17217: ### IGT changes ### Possible regressions * igt@kms_cursor_legacy@basic-busy-flip-before-cursor-atomic: - fi-cml-u2: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/fi-cml-u2/igt@kms_cursor_leg...@basic-busy-flip-before-cursor-atomic.html Known issues Here are the changes found in Patchwork_17217 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [PASS][3] -> [DMESG-WARN][4] ([i915#203]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live@hangcheck: - fi-icl-u2: [PASS][5] -> [INCOMPLETE][6] ([i915#1580]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html * igt@kms_pipe_crc_basic@read-crc-pipe-a-frame-sequence: - fi-skl-6770hq: [PASS][7] -> [SKIP][8] ([fdo#109271]) +5 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-a-frame-sequence.html * igt@kms_pipe_crc_basic@read-crc-pipe-b: - fi-skl-6770hq: [PASS][9] -> [DMESG-WARN][10] ([i915#106]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/fi-skl-6770hq/igt@kms_pipe_crc_ba...@read-crc-pipe-b.html Warnings * igt@i915_pm_rpm@basic-rte: - fi-kbl-guc: [SKIP][11] ([fdo#109271]) -> [FAIL][12] ([i915#579]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/fi-kbl-guc/igt@i915_pm_...@basic-rte.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#106]: https://gitlab.freedesktop.org/drm/intel/issues/106 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 [i915#203]: https://gitlab.freedesktop.org/drm/intel/issues/203 [i915#579]: https://gitlab.freedesktop.org/drm/intel/issues/579 Participating hosts (53 -> 47) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8259 -> Patchwork_17217 CI-20190529: 20190529 CI_DRM_8259: 450fc86b62651336f9b5fde79c068df7b4c95aa4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5571: da79d5fa2ebed237f0561a54b4b63bae6f21503a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17217: a2c2dd9e46431486ec4ad306fed2f250f5bfb2fb @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a2c2dd9e4643 drm/i915/gem: Flush all the reloc_gpu batch == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17217/index.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/17] drm/i915/dp: use struct drm_device based logging
On Mon, 06 Apr 2020, "Bharadiya,Pankaj"
wrote:
> On Thu, Apr 02, 2020 at 02:48:06PM +0300, Jani Nikula wrote:
>> Convert all the DRM_* logging macros to the struct drm_device based
>> macros to provide device specific logging.
>>
>> No functional changes.
>>
>> Generated using the following semantic patch, originally written by
>> Wambui Karuga , with manual fixups on top:
>>
>> @@
>> identifier fn, T;
>> @@
>>
>> fn(...,struct drm_i915_private *T,...) {
>> <+...
>> (
>> -DRM_INFO(
>> +drm_info(>drm,
>> ...)
>> |
>> -DRM_NOTE(
>> +drm_notice(>drm,
>> ...)
>> |
>> -DRM_ERROR(
>> +drm_err(>drm,
>> ...)
>> |
>> -DRM_WARN(
>> +drm_warn(>drm,
>> ...)
>> |
>> -DRM_DEBUG_DRIVER(
>> +drm_dbg(>drm,
>> ...)
>> |
>> -DRM_DEBUG_KMS(
>> +drm_dbg_kms(>drm,
>> ...)
>> |
>> -DRM_DEBUG_ATOMIC(
>> +drm_dbg_atomic(>drm,
>> ...)
>> )
>> ...+>
>> }
>>
>> @@
>> identifier fn, T;
>> @@
>>
>> fn(...) {
>> ...
>> struct drm_i915_private *T = ...;
>> <+...
>> (
>> -DRM_INFO(
>> +drm_info(>drm,
>> ...)
>> |
>> -DRM_NOTE(
>> +drm_notice(>drm,
>> ...)
>> |
>> -DRM_ERROR(
>> +drm_err(>drm,
>> ...)
>> |
>> -DRM_WARN(
>> +drm_warn(>drm,
>> ...)
>> |
>> -DRM_DEBUG_DRIVER(
>> +drm_dbg(>drm,
>> ...)
>> |
>> -DRM_DEBUG_KMS(
>> +drm_dbg_kms(>drm,
>> ...)
>> |
>> -DRM_DEBUG_ATOMIC(
>> +drm_dbg_atomic(>drm,
>> ...)
>> )
>> ...+>
>
> As per this script, conversion should happen at places where
> struct drm_i915_private pointer is already available, but patch
> does conversions in several other conversions not related to
> this script by adding struct drm_i915_private pointer.
>
> Here is my example script which does the WARN* conversion.
> This avoids manuallal additions.
Thanks. It's just that not all places have intel_dp. Not all places have
intel_dig_port either. Etc. I opted for the slight bit of manual work to
get the job done instead of trying to come up with the perfect semantic
patch.
BR,
Jani.
>
> @@
> identifier func, T;
> @@
> func(struct intel_dp *T,...) {
> + struct drm_i915_private *i915 = dp_to_i915(T);
> <+...
> (
> -WARN_ON(
> +drm_WARN_ON(>drm,
> ...)
> |
> -WARN_ON_ONCE(
> +drm_WARN_ON_ONCE(>drm,
> ...)
> )
> ...+>
>
> }
>
> @@
> identifier func, T;
> @@
> func(...) {
> ...
> struct intel_dp *T = ...;
> + struct drm_i915_private *i915 = dp_to_i915(T);
> <+...
> (
> -WARN_ON(
> +drm_WARN_ON(>drm,
> ...)
> |
> -WARN_ON_ONCE(
> +drm_WARN_ON_ONCE(>drm,
> ...)
> )
> ...+>
>
> }
>
>
> Thanks,
> Pankaj
>
>> }
>>
>> Cc: Wambui Karuga
>> Signed-off-by: Jani Nikula
>> ---
>> drivers/gpu/drm/i915/display/intel_dp.c | 333 +++-
>> 1 file changed, 213 insertions(+), 120 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/display/intel_dp.c
>> b/drivers/gpu/drm/i915/display/intel_dp.c
>> index 2e715e6d7bb4..aab2029877b6 100644
>> --- a/drivers/gpu/drm/i915/display/intel_dp.c
>> +++ b/drivers/gpu/drm/i915/display/intel_dp.c
>> @@ -463,6 +463,7 @@ static bool
>> intel_dp_can_link_train_fallback_for_edp(struct intel_dp *intel_dp,
>> int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
>> int link_rate, u8 lane_count)
>> {
>> +struct drm_i915_private *i915 = dp_to_i915(intel_dp);
>> int index;
>>
>> index = intel_dp_rate_index(intel_dp->common_rates,
>> @@ -473,7 +474,8 @@ int intel_dp_get_link_train_fallback_values(struct
>> intel_dp *intel_dp,
>> !intel_dp_can_link_train_fallback_for_edp(intel_dp,
>>
>> intel_dp->common_rates[index - 1],
>>lane_count)) {
>> -DRM_DEBUG_KMS("Retrying Link training for eDP with same
>> parameters\n");
>> +drm_dbg_kms(>drm,
>> +"Retrying Link training for eDP with same
>> parameters\n");
>> return 0;
>> }
>> intel_dp->max_link_rate = intel_dp->common_rates[index - 1];
>> @@ -483,13 +485,14 @@ int intel_dp_get_link_train_fallback_values(struct
>> intel_dp *intel_dp,
>> !intel_dp_can_link_train_fallback_for_edp(intel_dp,
>>
>> intel_dp_max_common_rate(intel_dp),
>>lane_count >> 1))
>> {
>> -DRM_DEBUG_KMS("Retrying Link training for eDP with same
>> parameters\n");
>> +drm_dbg_kms(>drm,
>> +"Retrying Link training for eDP with same
>> parameters\n");
>> return 0;
>> }
>> intel_dp->max_link_rate = intel_dp_max_common_rate(intel_dp);
>> intel_dp->max_link_lane_count = lane_count >> 1;
>> } else {
>> -DRM_ERROR("Link Training Unsuccessful\n");
>> +drm_err(>drm, "Link Training Unsuccessful\n");
>> return -1;
>> }
>>
>> @@ -564,6
Re: [Intel-gfx] [PATCH 02/17] drm/i915/panel: use struct drm_device based logging
On Mon, 06 Apr 2020, "Bharadiya,Pankaj" wrote: > Adding new i915 variable seems to be redundant here since we can > directly use "connector->base.dev" for getting struct drm_device > pointer. We could. However, struct drm_i915_private *i915 is widely used and needed throughout the driver, all over the place. I'd rather add i915 now instead of first using connector->base.dev or whatever, and having someone add i915 at a later time and then converting to >drm. BR, Jani. -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gem: Take DBG_FORCE_RELOC into account prior to using reloc_gpu
If we set the debug flag to force ourselves not to relocate via the gpu,
do not relocate via the gpu.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 15 ---
1 file changed, 12 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
index 9d11bad74e9a..fe66571cb84f 100644
--- a/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c
@@ -1299,6 +1299,17 @@ static u32 *reloc_gpu(struct i915_execbuffer *eb,
return cmd;
}
+static inline bool use_reloc_gpu(struct i915_vma *vma)
+{
+ if (DBG_FORCE_RELOC == FORCE_GPU_RELOC)
+ return true;
+
+ if (DBG_FORCE_RELOC)
+ return false;
+
+ return !dma_resv_test_signaled_rcu(vma->resv, true);
+}
+
static u64
relocate_entry(struct i915_vma *vma,
const struct drm_i915_gem_relocation_entry *reloc,
@@ -1310,9 +1321,7 @@ relocate_entry(struct i915_vma *vma,
bool wide = eb->reloc_cache.use_64bit_reloc;
void *vaddr;
- if (!eb->reloc_cache.vaddr &&
- (DBG_FORCE_RELOC == FORCE_GPU_RELOC ||
-!dma_resv_test_signaled_rcu(vma->resv, true))) {
+ if (!eb->reloc_cache.vaddr && use_reloc_gpu(vma)) {
const unsigned int gen = eb->reloc_cache.gen;
unsigned int len;
u32 *batch;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/44] drivers/base: Always release devres on device_del
On Fri, Apr 3, 2020 at 3:58 PM Daniel Vetter wrote:
>
> In drm we've added nice drm_device (the main gpu driver thing, which
> also represents the userspace interfaces and has everything else
> dangling off it) init functions using devres, devm_drm_dev_init and
> soon devm_drm_dev_alloc (this patch series adds that).
>
> A slight trouble is that drm_device itself holds a reference on the
> struct device it's sitting on top (for sysfs links and dmesg debug and
> lots of other things), so there's a reference loop. For real drivers
> this is broken at remove/unplug time, where all devres resources are
> released device_release_driver(), before the final device reference is
> dropped. So far so good.
>
> There's 2 exceptions:
> - drm/vkms|vgem: Virtual drivers for which we create a fake/virtual
> platform device to make them look more like normal devices to
> userspace. These aren't drivers in the driver model sense, we simple
> create a platform_device and register it.
>
> - drm/i915/selftests, where we create minimal mock devices, and again
> the selftests aren't proper drivers in the driver model sense.
>
> For these two cases the reference loop isn't broken, because devres is
> only cleaned up when the last device reference is dropped. But that's
> not happening, because the drm_device holds that last struct device
> reference.
>
> Thus far this wasn't a problem since the above cases simply
> hand-rolled their cleanup code. But I want to convert all drivers over
> to the devm_ versions, hence it would be really nice if these
> virtual/fake/mock uses-cases could also be managed with devres
> cleanup.
>
> I see three possible approaches:
Restarting this at the top level, because the discussion thus far just
ended in a long "you're doing it wrong", despite that I think we're
doing what v4l is doing (plus/minus that we can't do an exact matching
handling in drm because our uapi has a lot more warts, which we can't
change because no breaking userspace).
So which one of the three below is the right approach?
Aside, looking at the v4l solution I think there's also a confusion
about struct device representing a char device (which v4l directly
uses as its userspace interface refcounted thing, and which drm does
_not_ directly). And a struct device embedded into something like
platform_device or a virtual device, where a driver can bind to. My
question here is about the former, I don't care how cdev struct device
are cleaned up one bit. Now if other subsystems relies on the devres
cleanup behaviour we currently have because of such cdev usage, then
yeah first approach doesn't work (and I have a big surprised that use
case, but hey would actually learn something).
End of aside, since again I want to figure out which of the tree
approaches it the right one. Not about how wrong one of them is,
ignoring the other three I laid out. And maybe there's even more
options for this.
-Daniel
> - Clean up devres from device_del (or platform_device_unregister) even
> when no driver is bound. This seems like the simplest solution, but
> also the one with the widest impact, and what this patch implements.
> We might want to include more of the cleanup than just
> devres_release_all, but this is all I need to get my use case going.
>
> - Create a devres group and release that when we unbind. The code in
> virtual drivers gets a bit ugly, since every error case has a
> different cleanup code until we've chained everything
> (platform_device, devres group and then drm_device) together and a
> devres_release_group takes care of everything. Doable, but a bit
> confusing when I typed it out.
>
> - Convert the virtual drivers to real (in the device model sense)
> drivers. Feels like too much boilerplate for not much gain. And
> especially with the mock objects minimal mocking is kinda the goal,
> to limit the amount of accidentally pulled in code into our unit
> tests as much as possible.
>
> Either way I think time to discuss this a bit and figure out what's
> the recommended approach here.
>
> Signed-off-by: Daniel Vetter
> Cc: Greg Kroah-Hartman
> Cc: "Rafael J. Wysocki"
> ---
> drivers/base/dd.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/drivers/base/dd.c b/drivers/base/dd.c
> index b25bcab2a26b..1bcfb0ff5f44 100644
> --- a/drivers/base/dd.c
> +++ b/drivers/base/dd.c
> @@ -1155,6 +1155,8 @@ static void __device_release_driver(struct device *dev,
> struct device *parent)
> dev);
>
> kobject_uevent(>kobj, KOBJ_UNBIND);
> + } else {
> + devres_release_all(dev);
> }
> }
>
> --
> 2.25.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Prefer drm_WARN* over WARN*
== Series Details == Series: Prefer drm_WARN* over WARN* URL : https://patchwork.freedesktop.org/series/75543/ State : failure == Summary == CI Bug Log - changes from CI_DRM_8259 -> Patchwork_17216 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_17216 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_17216, 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_17216/index.html Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_17216: ### IGT changes ### Possible regressions * igt@runner@aborted: - fi-bsw-nick:NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17216/fi-bsw-nick/igt@run...@aborted.html Known issues Here are the changes found in Patchwork_17216 that come from known issues: ### IGT changes ### Issues hit * igt@debugfs_test@read_all_entries: - fi-bsw-nick:[PASS][2] -> [INCOMPLETE][3] ([i915#1250]) [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-bsw-nick/igt@debugfs_test@read_all_entries.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17216/fi-bsw-nick/igt@debugfs_test@read_all_entries.html * igt@gem_exec_suspend@basic-s4-devices: - fi-tgl-y: [PASS][4] -> [FAIL][5] ([i915#1158]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17216/fi-tgl-y/igt@gem_exec_susp...@basic-s4-devices.html * igt@i915_selftest@live@hangcheck: - fi-icl-u2: [PASS][6] -> [INCOMPLETE][7] ([i915#1580]) [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17216/fi-icl-u2/igt@i915_selftest@l...@hangcheck.html * igt@kms_chamelium@dp-edid-read: - fi-cml-u2: [PASS][8] -> [FAIL][9] ([i915#976]) [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17216/fi-cml-u2/igt@kms_chamel...@dp-edid-read.html * igt@kms_flip@basic-flip-vs-dpms: - fi-skl-6770hq: [PASS][10] -> [SKIP][11] ([fdo#109271]) +24 similar issues [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_8259/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_17216/fi-skl-6770hq/igt@kms_f...@basic-flip-vs-dpms.html [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271 [i915#1158]: https://gitlab.freedesktop.org/drm/intel/issues/1158 [i915#1250]: https://gitlab.freedesktop.org/drm/intel/issues/1250 [i915#1580]: https://gitlab.freedesktop.org/drm/intel/issues/1580 [i915#976]: https://gitlab.freedesktop.org/drm/intel/issues/976 Participating hosts (53 -> 47) -- Additional (1): fi-kbl-7560u Missing(7): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-byt-clapper fi-bdw-samus Build changes - * CI: CI-20190529 -> None * Linux: CI_DRM_8259 -> Patchwork_17216 CI-20190529: 20190529 CI_DRM_8259: 450fc86b62651336f9b5fde79c068df7b4c95aa4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5571: da79d5fa2ebed237f0561a54b4b63bae6f21503a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_17216: 4c4c2b16486bf668030b6be413ec16ed24ff0ed9 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 4c4c2b16486b drm/i915/runtime_pm: Prefer drm_WARN* over WARN* db552aba6881 drm/i915/pm: Prefer drm_WARN_ON over WARN_ON 0af155c5b3f1 drm/i915/pmu: Prefer drm_WARN_ON over WARN_ON d9387cef2125 drm/i915/i915_drv: Prefer drm_WARN_ON over WARN_ON a09caf119a41 drm/i915/gem: Prefer drm_WARN* over WARN* 63fc326a1fca drm/i915/display/vlv_dsi: Prefer drm_WARN_ON over WARN_ON ccea1b50c254 drm/i915/display/tc: Prefer drm_WARN_ON over WARN_ON a17137b9ca74 drm/i915/display/sdvo: Prefer drm_WARN* over WARN* e61a3429efb8 drm/i915/display/overlay: Prefer drm_WARN_ON over WARN_ON 31d144a0fd99 drm/i915/display/global_state: Prefer drm_WARN* over WARN* 9343391f6779 drm/i915/display/frontbuffer: Prefer drm_WARN_ON over WARN_ON 3a60829da48b drm/i915/display/dpll_mgr: Prefer drm_WARN_ON over WARN_ON 462c17ba380f drm/i915/display/dp: Prefer drm_WARN* over WARN* 0aae019835f6 drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON cbddf2425b98 drm/i915/display/display: Prefer drm_WARN_ON over WARN_ON 9db54cf5c0c1 drm/i915/display/ddi: Prefer drm_WARN* over WARN* ce36d1d4c808
Re: [Intel-gfx] [PATCH 02/44] drm: Add devm_drm_dev_alloc macro
On Mon, Apr 6, 2020 at 2:01 PM Laurent Pinchart
wrote:
>
> Hi Daniel,
>
> Thank you for the patch.
>
> On Fri, Apr 03, 2020 at 03:57:46PM +0200, Daniel Vetter wrote:
> > The kerneldoc is only added for this new function. Existing kerneldoc
> > and examples will be udated at the very end, since once all drivers
> > are converted over to devm_drm_dev_alloc we can unexport a lot of
> > interim functions and make the documentation for driver authors a lot
> > cleaner and less confusing. There will be only one true way to
> > initialize a drm_device at the end of this, which is going to be
> > devm_drm_dev_alloc.
>
> How about drivers that expose another interface towards userspace ? If
> the other related subsystem also required allocation of the driver
> private structure through its corresponding API, we'd be stuck. As
> stated before, I want this API to be optional.
So maybe we need to import a little bit more of our epic irc
discussion here, because this is leaving out all the context. There's
a few more things:
- Since the merging of the previous patch series this is already
mandatory, because the kfree(drm_device.managed.final_kfree) is the
last thing that will run. So I already killed your use-case (and it
seems to work just fine for all the drivers in-tree, and we have a
lot).
- As part of doing all these patches here and in the previous series
and in a next one I've seen that drivers just get this wrong. I'm
extremely hesitant to give that rope back to drivers, so I really
don't want to merge anything until we're ready to merge a driver that
needs it. I've set myself a goal to fix up all 40 odd drivers still
using drm_dev_alloc(), and that's itself already pretty stupid idea.
It's definitely not going to work if new drivers keep adding bad usage
patterns.
- Now I'm not opposed to allowing this, if/when we actually need it. I
think a very clean long-term solution would be to have a struct
kref_res, which augments a kref with automatic resource cleanup. We'd
probably need to fully demidlayer that, i.e. if you supply your own
->release hook then it's your job to call kref_release_all() at the
right point in there. With that we could then do a devm_drm_dev_init()
again, which would take that kref_res structure and the drm_device,
both embedded somewhere in your overall driver struture, and use your
drivers kref_res to attach all drm related auto-cleanup. In that case
it would then also be that kref_res' responsibility to do the final
kfree, hence drm wouldn't insist on doing that either. Prototype would
be something like:
devm_drm_dev_init(struct device *dev, struct drm_device *drm,
struct drm_driver *driver, struct kref_res *kref);
The trouble with the above idea is that it assumes I have endless
amounts of time and that I can convince Greg KH that I understand
driver unload lifetime issues. The former is atm the more realistic
looking one of these two, so interim solution would be to add some
hack or another meanwhile to do this within drm only. Or as an
alternative solution, easy to convert over to an eventual kref_res
world:
#define kref_res_get() drm_dev_get()
#define kref_res_put() drm_dev_put()
With suitable amounts of casting to make this work out correctly like
the real kref_res solution.
Until we do have such drivers though I really don't want to open the
barn door again to all the bugs that'll bring, while I'm trying to get
the other barn doors closed down and fixed meanwhile.
-Daniel
>
> > Cc: Paul Kocialkowski
> > Cc: Laurent Pinchart
> > Signed-off-by: Daniel Vetter
> > ---
> > drivers/gpu/drm/drm_drv.c | 23 +++
> > include/drm/drm_drv.h | 33 +
> > 2 files changed, 56 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/drm_drv.c b/drivers/gpu/drm/drm_drv.c
> > index 1bb4f636b83c..9e60b784b3ac 100644
> > --- a/drivers/gpu/drm/drm_drv.c
> > +++ b/drivers/gpu/drm/drm_drv.c
> > @@ -739,6 +739,29 @@ int devm_drm_dev_init(struct device *parent,
> > }
> > EXPORT_SYMBOL(devm_drm_dev_init);
> >
> > +void* __devm_drm_dev_alloc(struct device *parent, struct drm_driver
> > *driver,
> > +size_t size, size_t offset)
> > +{
> > + void *container;
> > + struct drm_device *drm;
> > + int ret;
> > +
> > + container = kzalloc(size, GFP_KERNEL);
> > + if (!container)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + drm = container + offset;
> > + ret = devm_drm_dev_init(parent, drm, driver);
> > + if (ret) {
> > + kfree(container);
> > + return ERR_PTR(ret);
> > + }
> > + drmm_add_final_kfree(drm, container);
> > +
> > + return container;
> > +}
> > +EXPORT_SYMBOL(__devm_drm_dev_alloc);
> > +
> > /**
> > * drm_dev_alloc - Allocate new DRM device
> > * @driver: DRM driver to allocate device for
> > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
> > index e7c6ea261ed1..26776be5a21e 100644
> > --- a/include/drm/drm_drv.h
>
