[Intel-gfx] [PATCH] drm/modes: Prevent division by zero htotal
This patch prevents division by zero htotal. Signed-off-by: Tina Zhang Cc: Adam Jackson Cc: Dave Airlie Cc: Daniel Vetter --- drivers/gpu/drm/drm_modes.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_modes.c b/drivers/gpu/drm/drm_modes.c index adce9a2..59b92b1 100644 --- a/drivers/gpu/drm/drm_modes.c +++ b/drivers/gpu/drm/drm_modes.c @@ -751,7 +751,7 @@ int drm_mode_hsync(const struct drm_display_mode *mode) if (mode->hsync) return mode->hsync; - if (mode->htotal < 0) + if (mode->htotal <= 0) return 0; calc_val = (mode->clock * 1000) / mode->htotal; /* hsync in Hz */ -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 2019-01-22 at 21:09 +0200, Ville Syrjälä wrote: > On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote: > > On Tue, 22 Jan 2019, Ville Syrjälä > > wrote: > > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: > > > > Avoid divide by zero warning on static analysis. > > > > > > > > Signed-off-by: Mika Kahola > > > > --- > > > > drivers/gpu/drm/i915/intel_pm.c | 6 -- > > > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > > > b/drivers/gpu/drm/i915/intel_pm.c > > > > index 8b63afa3a221..6a8e8b3f44c2 100644 > > > > --- a/drivers/gpu/drm/i915/intel_pm.c > > > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > > > @@ -3912,8 +3912,10 @@ > > > > skl_ddb_get_pipe_allocation_limits(struct drm_i915_private > > > > *dev_priv, > > > > pipe_width = hdisplay; > > > > } > > > > > > > > - alloc->start = ddb_size * width_before_pipe / > > > > total_width; > > > > - alloc->end = ddb_size * (width_before_pipe + > > > > pipe_width) / total_width; > > > > + alloc->start = total_width == 0 ? > > > > + 0 : ddb_size * width_before_pipe / total_width; > > > > + alloc->end = total_width == 0 ? > > > > + 0 : ddb_size * (width_before_pipe + pipe_width) > > > > / total_width; > > > > > > Can't happen. I'd say it's very unlikely to happen but in theory possible. If we don't have any crtc_state enabled we end up having total_width = 0. In this case it probably won't matter what numbers we end up with alloc- >start and alloc->end. Anyway, this was something that caught my eye while looking into crc mismatch errors and static checker results. Like Jani said, warn is sufficient with this case. Cheers, Mika > > > > Yeah, it's about stfu the checker... > > Feels like the tip of an iceberg. How many more uglies are we going > to > have to add? > > > > > > > > > > } > > > > > > > > static unsigned int skl_cursor_allocation(int num_active) > > > > -- > > > > 2.17.1 > > > > > > > > ___ > > > > Intel-gfx mailing list > > > > Intel-gfx@lists.freedesktop.org > > > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > > > -- > > Jani Nikula, Intel Open Source Graphics Center > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: correct the pitch check for NV12 framebuffer (rev3)
== Series Details ==
Series: drm/i915: correct the pitch check for NV12 framebuffer (rev3)
URL : https://patchwork.freedesktop.org/series/53928/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468 -> Patchwork_12011
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/53928/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12011 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@read-crc-pipe-a:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (46 -> 40)
--
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ivb-3770 fi-snb-2600
Build changes
-
* Linux: CI_DRM_5468 -> Patchwork_12011
CI_DRM_5468: fc4e30d30d90ed5d5bd467de0439e9522d34cdf0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4784: 1c5a4432293369f85859c748c08155e79d92c4ce @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12011: 27aba8615f29290773c979725346ee45761a17a0 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
27aba8615f29 drm/i915: correct the pitch check for NV12 framebuffer
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12011/
___
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/icl: do a posting read after irq install
== Series Details == Series: drm/i915/icl: do a posting read after irq install URL : https://patchwork.freedesktop.org/series/55598/ State : success == Summary == CI Bug Log - changes from CI_DRM_5468_full -> Patchwork_12010_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_12010_full that come from known issues: ### IGT changes ### Issues hit * igt@kms_ccs@pipe-a-crc-sprite-planes-basic: - shard-apl: PASS -> FAIL [fdo#106510] / [fdo#108145] - shard-glk: PASS -> FAIL [fdo#108145] * igt@kms_cursor_crc@cursor-128x128-random: - shard-apl: PASS -> FAIL [fdo#103232] +3 * igt@kms_cursor_crc@cursor-256x85-onscreen: - shard-glk: PASS -> FAIL [fdo#103232] +1 * igt@kms_plane@pixel-format-pipe-c-planes-source-clamping: - shard-apl: PASS -> FAIL [fdo#108948] * igt@kms_plane_multiple@atomic-pipe-a-tiling-y: - shard-glk: PASS -> FAIL [fdo#103166] * igt@kms_universal_plane@universal-plane-pipe-a-functional: - shard-apl: PASS -> FAIL [fdo#103166] +1 Possible fixes * igt@kms_cursor_crc@cursor-128x128-random: - shard-glk: FAIL [fdo#103232] -> PASS * igt@kms_flip@2x-flip-vs-expired-vblank: - shard-glk: FAIL [fdo#105363] -> PASS +1 * igt@kms_flip@dpms-vs-vblank-race: - shard-kbl: FAIL [fdo#103060] -> PASS - shard-glk: FAIL [fdo#103060] -> PASS * igt@kms_plane@plane-position-covered-pipe-c-planes: - shard-apl: FAIL [fdo#103166] -> PASS * igt@kms_plane_multiple@atomic-pipe-c-tiling-none: - shard-glk: FAIL [fdo#103166] -> PASS +1 [fdo#103060]: https://bugs.freedesktop.org/show_bug.cgi?id=103060 [fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166 [fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232 [fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363 [fdo#106510]: https://bugs.freedesktop.org/show_bug.cgi?id=106510 [fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145 [fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948 Participating hosts (7 -> 4) -- Missing(3): shard-snb shard-skl shard-iclb Build changes - * Linux: CI_DRM_5468 -> Patchwork_12010 CI_DRM_5468: fc4e30d30d90ed5d5bd467de0439e9522d34cdf0 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_4784: 1c5a4432293369f85859c748c08155e79d92c4ce @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_12010: dcb852034e635befa89d31d17a50ec69aad8d1ef @ git://anongit.freedesktop.org/gfx-ci/linux piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12010/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt: switch to kernel types
On 2019.01.21 11:51:41 +0200, Jani Nikula wrote:
> Mixed C99 and kernel types use is getting ugly. Prefer kernel types.
>
> sed -i 's/\buint\(8\|16\|32\|64\)_t\b/u\1/g'
>
> Signed-off-by: Jani Nikula
> ---
Looks good to me.
Acked-by: Zhenyu Wang
Will queue this up. Thanks!
> drivers/gpu/drm/i915/gvt/cmd_parser.c | 14 +++---
> drivers/gpu/drm/i915/gvt/handlers.c | 6 +++---
> drivers/gpu/drm/i915/gvt/kvmgt.c| 24
> drivers/gpu/drm/i915/gvt/mmio.c | 6 +++---
> drivers/gpu/drm/i915/gvt/sched_policy.c | 2 +-
> drivers/gpu/drm/i915/gvt/scheduler.h| 2 +-
> 6 files changed, 27 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index 77ae634eb11c..bac014031c4b 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -399,10 +399,10 @@ struct cmd_info {
> #define R_VECS (1 << VECS)
> #define R_ALL (R_RCS | R_VCS | R_BCS | R_VECS)
> /* rings that support this cmd: BLT/RCS/VCS/VECS */
> - uint16_t rings;
> + u16 rings;
>
> /* devices that support this cmd: SNB/IVB/HSW/... */
> - uint16_t devices;
> + u16 devices;
>
> /* which DWords are address that need fix up.
>* bit 0 means a 32-bit non address operand in command
> @@ -412,13 +412,13 @@ struct cmd_info {
>* No matter the address length, each address only takes
>* one bit in the bitmap.
>*/
> - uint16_t addr_bitmap;
> + u16 addr_bitmap;
>
> /* flag == F_LEN_CONST : command length
>* flag == F_LEN_VAR : length bias bits
>* Note: length is in DWord
>*/
> - uint8_t len;
> + u8 len;
>
> parser_cmd_handler handler;
> };
> @@ -1644,7 +1644,7 @@ static int find_bb_size(struct parser_exec_state *s,
> unsigned long *bb_size)
> {
> unsigned long gma = 0;
> struct cmd_info *info;
> - uint32_t cmd_len = 0;
> + u32 cmd_len = 0;
> bool bb_end = false;
> struct intel_vgpu *vgpu = s->vgpu;
> u32 cmd;
> @@ -2683,7 +2683,7 @@ static int scan_wa_ctx(struct intel_shadow_wa_ctx
> *wa_ctx)
> I915_GTT_PAGE_SIZE)))
> return -EINVAL;
>
> - ring_tail = wa_ctx->indirect_ctx.size + 3 * sizeof(uint32_t);
> + ring_tail = wa_ctx->indirect_ctx.size + 3 * sizeof(u32);
> ring_size = round_up(wa_ctx->indirect_ctx.size + CACHELINE_BYTES,
> PAGE_SIZE);
> gma_head = wa_ctx->indirect_ctx.guest_gma;
> @@ -2850,7 +2850,7 @@ static int shadow_indirect_ctx(struct
> intel_shadow_wa_ctx *wa_ctx)
>
> static int combine_wa_ctx(struct intel_shadow_wa_ctx *wa_ctx)
> {
> - uint32_t per_ctx_start[CACHELINE_DWORDS] = {0};
> + u32 per_ctx_start[CACHELINE_DWORDS] = {0};
> unsigned char *bb_start_sva;
>
> if (!wa_ctx->per_ctx.valid)
> diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> b/drivers/gpu/drm/i915/gvt/handlers.c
> index e9f343b124b0..2837baa55128 100644
> --- a/drivers/gpu/drm/i915/gvt/handlers.c
> +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> @@ -276,7 +276,7 @@ static int mul_force_wake_write(struct intel_vgpu *vgpu,
> unsigned int offset, void *p_data, unsigned int bytes)
> {
> u32 old, new;
> - uint32_t ack_reg_offset;
> + u32 ack_reg_offset;
>
> old = vgpu_vreg(vgpu, offset);
> new = CALC_MODE_MASK_REG(old, *(u32 *)p_data);
> @@ -833,7 +833,7 @@ static int dp_aux_ch_ctl_trans_done(struct intel_vgpu
> *vgpu, u32 value,
> }
>
> static void dp_aux_ch_ctl_link_training(struct intel_vgpu_dpcd_data *dpcd,
> - uint8_t t)
> + u8 t)
> {
> if ((t & DPCD_TRAINING_PATTERN_SET_MASK) == DPCD_TRAINING_PATTERN_1) {
> /* training pattern 1 for CR */
> @@ -919,7 +919,7 @@ static int dp_aux_ch_ctl_mmio_write(struct intel_vgpu
> *vgpu,
>
> if (op == GVT_AUX_NATIVE_WRITE) {
> int t;
> - uint8_t buf[16];
> + u8 buf[16];
>
> if ((addr + len + 1) >= DPCD_SIZE) {
> /*
> diff --git a/drivers/gpu/drm/i915/gvt/kvmgt.c
> b/drivers/gpu/drm/i915/gvt/kvmgt.c
> index dd3dfd00f4e6..413c6a13ec02 100644
> --- a/drivers/gpu/drm/i915/gvt/kvmgt.c
> +++ b/drivers/gpu/drm/i915/gvt/kvmgt.c
> @@ -703,7 +703,7 @@ static void intel_vgpu_release_work(struct work_struct
> *work)
> __intel_vgpu_release(vgpu);
> }
>
> -static uint64_t intel_vgpu_get_bar_addr(struct intel_vgpu *vgpu, int bar)
> +static u64 intel_vgpu_get_bar_addr(struct intel_vgpu *vgpu, int bar)
> {
> u32 start_lo, start_hi;
> u32 mem_type;
> @@ -730,10 +730,10 @@ static uint64_t intel_vgpu_get_bar_addr(struct
> intel_vgpu *vgpu, int bar)
> return ((u64)start_hi << 32) | start_lo;
> }
>
> -static int intel_vgpu_bar_rw(struct intel_vgpu *vgpu, int bar, uint64_t off,
> +static int
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: do a posting read after irq install
== Series Details ==
Series: drm/i915/icl: do a posting read after irq install
URL : https://patchwork.freedesktop.org/series/55598/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5468 -> Patchwork_12010
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55598/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12010 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: PASS -> FAIL [fdo#107362]
Possible fixes
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: FAIL [fdo#108767] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS +1
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (46 -> 39)
--
Missing(7): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-ivb-3770 fi-pnv-d510 fi-icl-y
Build changes
-
* Linux: CI_DRM_5468 -> Patchwork_12010
CI_DRM_5468: fc4e30d30d90ed5d5bd467de0439e9522d34cdf0 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4784: 1c5a4432293369f85859c748c08155e79d92c4ce @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12010: dcb852034e635befa89d31d17a50ec69aad8d1ef @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
dcb852034e63 drm/i915/icl: do a posting read after irq install
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12010/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install
On 1/22/2019 6:32 PM, Daniele Ceraolo Spurio wrote: When reading GEN11_GT_INTR_DWx closely after enabling the interrupts in gen11_irq_postinstall, the returned value is garbage. This can To clarify, this only happens (or at least I've only seen it) during runtime_resume. Daniele cause other parts of the setup code (e.g. gen11_reset_one_iir) to think that there are interrupts to be cleared when there are none. The garbage value is only seen on the first read done after the enable, so this looks like a posting issue. Adding a posting read after enabling the interrupts does indeed fix the problem. Note that the posting read has been purposely added outside of gen11_master_intr_enable since the issue has only been observed when the full interrupt setup is performed. Cc: Mika Kuoppala Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 5fd5080c4ccb..7056ae2d1e0e 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4089,6 +4089,7 @@ static int gen11_irq_postinstall(struct drm_device *dev) I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE); gen11_master_intr_enable(dev_priv->regs); + POSTING_READ(GEN11_GFX_MSTR_IRQ); return 0; } ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/icl: do a posting read after irq install
When reading GEN11_GT_INTR_DWx closely after enabling the interrupts in gen11_irq_postinstall, the returned value is garbage. This can cause other parts of the setup code (e.g. gen11_reset_one_iir) to think that there are interrupts to be cleared when there are none. The garbage value is only seen on the first read done after the enable, so this looks like a posting issue. Adding a posting read after enabling the interrupts does indeed fix the problem. Note that the posting read has been purposely added outside of gen11_master_intr_enable since the issue has only been observed when the full interrupt setup is performed. Cc: Mika Kuoppala Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_irq.c | 1 + 1 file changed, 1 insertion(+) diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index 5fd5080c4ccb..7056ae2d1e0e 100644 --- a/drivers/gpu/drm/i915/i915_irq.c +++ b/drivers/gpu/drm/i915/i915_irq.c @@ -4089,6 +4089,7 @@ static int gen11_irq_postinstall(struct drm_device *dev) I915_WRITE(GEN11_DISPLAY_INT_CTL, GEN11_DISPLAY_IRQ_ENABLE); gen11_master_intr_enable(dev_priv->regs); + POSTING_READ(GEN11_GFX_MSTR_IRQ); return 0; } -- 2.20.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 20/34] drm/i915: Introduce concept of per-timeline (context) HWSP
On 1/21/2019 14:21, Chris Wilson wrote:
Supplement the per-engine HWSP with a per-timeline HWSP. That is a
per-request pointer through which we can check a local seqno,
abstracting away the presumption of a global seqno. In this first step,
we point each request back into the engine's HWSP so everything
continues to work with the global timeline.
v2: s/i915_request_hwsp/hwsp_seqno/ to emphasis that this is the current
HW value and that we are accessing it via i915_request merely as a
convenience.
Signed-off-by: Chris Wilson
Reviewed-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_request.c | 16 ++
drivers/gpu/drm/i915/i915_request.h | 45 -
drivers/gpu/drm/i915/intel_lrc.c| 9 --
3 files changed, 55 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index 2721a356368f..d61e86c6a1d1 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -182,10 +182,11 @@ static void free_capture_list(struct i915_request
*request)
static void __retire_engine_request(struct intel_engine_cs *engine,
struct i915_request *rq)
{
- GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s(%s) fence %llx:%lld, global=%d, current %d:%d\n",
__func__, engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ hwsp_seqno(rq),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!i915_request_completed(rq));
@@ -244,10 +245,11 @@ static void i915_request_retire(struct i915_request
*request)
{
struct i915_gem_active *active, *next;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
request->engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ hwsp_seqno(request),
intel_engine_get_seqno(request->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -307,10 +309,11 @@ void i915_request_retire_upto(struct i915_request *rq)
struct intel_ring *ring = rq->ring;
struct i915_request *tmp;
- GEM_TRACE("%s fence %llx:%lld, global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld, global=%d, current %d:%d\n",
rq->engine->name,
rq->fence.context, rq->fence.seqno,
rq->global_seqno,
+ hwsp_seqno(rq),
intel_engine_get_seqno(rq->engine));
lockdep_assert_held(>i915->drm.struct_mutex);
@@ -355,10 +358,11 @@ void __i915_request_submit(struct i915_request *request)
struct intel_engine_cs *engine = request->engine;
u32 seqno;
- GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld -> global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
engine->timeline.seqno + 1,
+ hwsp_seqno(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -405,10 +409,11 @@ void __i915_request_unsubmit(struct i915_request *request)
{
struct intel_engine_cs *engine = request->engine;
- GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d\n",
+ GEM_TRACE("%s fence %llx:%lld <- global=%d, current %d:%d\n",
engine->name,
request->fence.context, request->fence.seqno,
request->global_seqno,
+ hwsp_seqno(request),
intel_engine_get_seqno(engine));
GEM_BUG_ON(!irqs_disabled());
@@ -616,6 +621,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
+ rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index c0f084ca4f29..ade010fe6e26 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -130,6 +130,13 @@ struct i915_request {
struct i915_sched_node sched;
struct i915_dependency dep;
+ /*
+* A convenience pointer to the current breadcrumb value stored in
+* the HW status page (or our timeline's local equivalent). The full
+* path would be rq->hw_context->ring->timeline->hwsp_seqno.
+*/
+ const u32 *hwsp_seqno;
+
/**
* GEM sequence number associated with this request on the
* global execution timeline. It is zero when the request is not
@@ -285,11 +292,6 @@ static inline bool
Re: [Intel-gfx] [PATCH 12/34] drm/i915: Issue engine resets onto idle engines
Quoting John Harrison (2019-01-23 01:18:36) > On 1/21/2019 14:20, Chris Wilson wrote: > > @@ -479,8 +477,6 @@ static int __igt_reset_engine(struct drm_i915_private > > *i915, bool active) > > break; > > } > > > > - GEM_BUG_ON(!rq->global_seqno); > > - seqno = rq->global_seqno - 1; > AFAICT this saved seqno value was never used anyway? It only exists > inside the loop, was only used in a pr_err earlier in the loop, and the > start of the loop always (re-)initialises it. Or am I missing some > hidden macro magic somewhere? I can't remember what I intended it to be in the first place. History says that we had to set engine->hangcheck.seqno correctly to force a per-engine reset. Lost in commit bba0869b18e44ff2f713c98575ddad8c7c5e9b10 Author: Chris Wilson Date: Fri Apr 6 23:03:53 2018 +0100 drm/i915: Treat i915_reset_engine() as guilty until proven innocent -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/gem_exec_schedule: Verify that using HW semaphores doesn't block
We may use HW semaphores to schedule nearly-ready work such that they
are already spinning on the GPU waiting for the completion on another
engine. However, we don't want for that spinning task to actually block
any real work should it be scheduled.
Signed-off-by: Chris Wilson
---
tests/i915/gem_exec_schedule.c | 87 ++
1 file changed, 87 insertions(+)
diff --git a/tests/i915/gem_exec_schedule.c b/tests/i915/gem_exec_schedule.c
index 0462ce84f..e947dde41 100644
--- a/tests/i915/gem_exec_schedule.c
+++ b/tests/i915/gem_exec_schedule.c
@@ -47,6 +47,10 @@
#define MAX_CONTEXTS 1024
+#define LOCAL_I915_EXEC_BSD_SHIFT (13)
+#define LOCAL_I915_EXEC_BSD_MASK (3 << LOCAL_I915_EXEC_BSD_SHIFT)
+#define ENGINE_MASK (I915_EXEC_RING_MASK | LOCAL_I915_EXEC_BSD_MASK)
+
IGT_TEST_DESCRIPTION("Check that we can control the order of execution");
static uint32_t __store_dword(int fd, uint32_t ctx, unsigned ring,
@@ -305,6 +309,86 @@ static void smoketest(int fd, unsigned ring, unsigned
timeout)
munmap(ptr, 4096);
}
+static uint32_t __batch_create(int i915, uint32_t offset)
+{
+ const uint32_t bbe = MI_BATCH_BUFFER_END;
+ uint32_t handle;
+
+ handle = gem_create(i915, ALIGN(offset + 4, 4096));
+ gem_write(i915, handle, offset, , sizeof(bbe));
+
+ return handle;
+}
+
+static uint32_t batch_create(int i915)
+{
+ return __batch_create(i915, 0);
+}
+
+static void semaphore(int i915)
+{
+ struct drm_i915_gem_exec_object2 obj = {
+ .handle = batch_create(i915),
+ };
+ igt_spin_t *spin = NULL;
+ unsigned int engine;
+ uint32_t scratch;
+
+ igt_require(gem_scheduler_has_preemption(i915));
+
+ /*
+* Given the use of semaphores to govern parallel submission
+* of nearly-ready work to HW, we still want to run actually
+* ready work immediately. Without semaphores, the dependent
+* work wouldn't be submitted so our ready work will run.
+*/
+
+ scratch = gem_create(i915, 4096);
+ for_each_physical_engine(i915, engine) {
+ if (!spin) {
+ spin = igt_spin_batch_new(i915,
+ .dependency = scratch,
+ .engine = engine);
+ } else {
+ typeof(spin->execbuf.flags) saved = spin->execbuf.flags;
+
+ spin->execbuf.flags &= ~ENGINE_MASK;
+ spin->execbuf.flags |= engine;
+
+ gem_execbuf(i915, >execbuf);
+
+ spin->execbuf.flags = saved;
+ }
+ }
+ igt_require(spin);
+ gem_close(i915, scratch);
+
+ /*
+* On all dependent engines, the request may be executing (busywaiting
+* on a HW semaphore) but it should not prevent any real work from
+* taking precedence.
+*/
+ scratch = gem_context_create(i915);
+ for_each_physical_engine(i915, engine) {
+ struct drm_i915_gem_execbuffer2 execbuf = {
+ .buffers_ptr = to_user_pointer(),
+ .buffer_count = 1,
+ .flags = engine,
+ .rsvd1 = scratch,
+ };
+
+ if (engine == (spin->execbuf.flags & ENGINE_MASK))
+ continue;
+
+ gem_execbuf(i915, );
+ }
+ gem_context_destroy(i915, scratch);
+ gem_sync(i915, obj.handle); /* to hang unless we can preempt */
+ gem_close(i915, obj.handle);
+
+ igt_spin_batch_free(i915, spin);
+}
+
static void reorder(int fd, unsigned ring, unsigned flags)
#define EQUAL 1
{
@@ -1236,6 +1320,9 @@ igt_main
igt_require(gem_scheduler_has_ctx_priority(fd));
}
+ igt_subtest("semaphore")
+ semaphore(fd);
+
igt_subtest("smoketest-all")
smoketest(fd, ALL_ENGINES, 30);
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 12/34] drm/i915: Issue engine resets onto idle engines
On 1/21/2019 14:20, Chris Wilson wrote:
Always perform the requested reset, even if we believe the engine is
idle. Presumably there was a reason the caller wanted the reset, and in
the near future we lose the easy tracking for whether the engine is
idle.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_reset.c | 4
.../gpu/drm/i915/selftests/intel_hangcheck.c | 22 +--
2 files changed, 6 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 064fc6da1512..d44b095e2860 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -1063,10 +1063,6 @@ int i915_reset_engine(struct intel_engine_cs *engine,
const char *msg)
GEM_TRACE("%s flags=%lx\n", engine->name, error->flags);
GEM_BUG_ON(!test_bit(I915_RESET_ENGINE + engine->id, >flags));
- if (i915_seqno_passed(intel_engine_get_seqno(engine),
- intel_engine_last_submit(engine)))
- return 0;
-
reset_prepare_engine(engine);
if (msg)
diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
index 8025c7e0bf6c..2c38ea5892d9 100644
--- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
+++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
@@ -449,8 +449,6 @@ static int __igt_reset_engine(struct drm_i915_private
*i915, bool active)
set_bit(I915_RESET_ENGINE + id, >gpu_error.flags);
do {
- u32 seqno = intel_engine_get_seqno(engine);
-
if (active) {
struct i915_request *rq;
@@ -479,8 +477,6 @@ static int __igt_reset_engine(struct drm_i915_private *i915, bool active)
break;
}
-GEM_BUG_ON(!rq->global_seqno);
- seqno = rq->global_seqno - 1;
AFAICT this saved seqno value was never used anyway? It only exists
inside the loop, was only used in a pr_err earlier in the loop, and the
start of the loop always (re-)initialises it. Or am I missing some
hidden macro magic somewhere?
i915_request_put(rq);
}
@@ -496,11 +492,10 @@ static int __igt_reset_engine(struct drm_i915_private *i915, bool active)
break;
}
- reset_engine_count += active;
if (i915_reset_engine_count(>gpu_error, engine) !=
- reset_engine_count) {
- pr_err("%s engine reset %srecorded!\n",
- engine->name, active ? "not " : "");
+ ++reset_engine_count) {
+ pr_err("%s engine reset not recorded!\n",
+ engine->name);
err = -EINVAL;
break;
}
@@ -728,7 +723,6 @@ static int __igt_reset_engines(struct drm_i915_private
*i915,
set_bit(I915_RESET_ENGINE + id, >gpu_error.flags);
do {
- u32 seqno = intel_engine_get_seqno(engine);
struct i915_request *rq = NULL;
if (flags & TEST_ACTIVE) {
@@ -756,9 +750,6 @@ static int __igt_reset_engines(struct drm_i915_private
*i915,
err = -EIO;
break;
}
-
- GEM_BUG_ON(!rq->global_seqno);
- seqno = rq->global_seqno - 1;
}
err = i915_reset_engine(engine, NULL);
@@ -795,10 +786,9 @@ static int __igt_reset_engines(struct drm_i915_private
*i915,
reported = i915_reset_engine_count(>gpu_error, engine);
reported -= threads[engine->id].resets;
- if (reported != (flags & TEST_ACTIVE ? count : 0)) {
- pr_err("i915_reset_engine(%s:%s): reset %lu times, but
reported %lu, expected %lu reported\n",
- engine->name, test_name, count, reported,
- (flags & TEST_ACTIVE ? count : 0));
+ if (reported != count) {
+ pr_err("i915_reset_engine(%s:%s): reset %lu times, but
reported %lu\n",
+ engine->name, test_name, count, reported);
if (!err)
err = -EINVAL;
}
Reviewed-by: John Harrison
___
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/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
== Series Details ==
Series: drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
URL : https://patchwork.freedesktop.org/series/55586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465_full -> Patchwork_12009_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12009_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_tiled_blits@normal:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-random:
- shard-glk: PASS -> FAIL [fdo#103232] +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-glk: PASS -> FAIL [fdo#103166]
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_alpha_blend@pipe-b-constant-alpha-max:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-a-tiling-none:
- shard-apl: PASS -> FAIL [fdo#103166]
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- shard-hsw: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-snb: {SKIP} [fdo#109271] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-glk: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_alpha_blend@pipe-c-alpha-opaque-fb:
- shard-glk: FAIL [fdo#108145] -> PASS
* igt@kms_plane_multiple@atomic-pipe-a-tiling-y:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@perf_pmu@rc6:
- shard-kbl: {SKIP} [fdo#109271] -> PASS
* igt@tools_test@tools_test:
- shard-glk: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5465 -> Patchwork_12009
CI_DRM_5465: 95a4790b382426fed48253664a12a4d7b63167b6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4783: 23f39950e824b8a8f31cfb26fc9b37ab1aca656f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12009: 7cdae183412046e7cb8ccf0a4f85ed76268ade6b @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12009/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be enabled when debugfs asks (rev2)
On Fri, 2019-01-18 at 22:23 +, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v4,1/4] drm/i915/psr: Allow PSR2 to be
> enabled when debugfs asks (rev2)
> URL : https://patchwork.freedesktop.org/series/55379/
> State : success
IGT series that this patches was depending on was merged
https://patchwork.freedesktop.org/series/55390/
So just pushed it to drm-intel-next-queued
Thanks for the reviews DK.
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5449_full -> Patchwork_11987_full
>
>
> Summary
> ---
>
> **SUCCESS**
>
> No regressions found.
>
>
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_11987_full:
>
> ### IGT changes ###
>
> Suppressed
>
> The following results come from untrusted machines, tests, or
> statuses.
> They do not affect the overall result.
>
> * igt@kms_fbcon_fbt@psr-suspend:
> - shard-iclb: FAIL [fdo#107882] -> {SKIP} +1
>
> * igt@kms
> _frontbuffer_tracking@fbcpsr-1p-primscrn-spr-indfb-draw-mmap-gtt:
> - shard-iclb: FAIL [fdo#103167] -> {SKIP} +4
>
> * igt@kms_frontbuffer_tracking@psr-rgb101010-draw-blt:
> - shard-iclb: PASS -> {SKIP} +146
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_11987_full that come from
> known issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@gem_exec_schedule@pi-ringfull-blt:
> - shard-skl: NOTRUN -> FAIL [fdo#103158]
>
> * igt@gem_softpin@noreloc-s3:
> - shard-snb: PASS -> DMESG-WARN [fdo#102365]
>
> * igt@i915_suspend@sysfs-reader:
> - shard-kbl: PASS -> INCOMPLETE [fdo#103665]
>
> * igt@kms_atomic_transition@plane-all-transition-fencing:
> - shard-iclb: PASS -> DMESG-WARN [fdo#107724] /
> [fdo#109225]
>
> * igt@kms_busy@extended-modeset-hang-newfb-render-c:
> - shard-skl: NOTRUN -> DMESG-WARN [fdo#107956] +1
>
> * igt@kms_chv_cursor_fail@pipe-b-128x128-left-edge:
> - shard-iclb: PASS -> DMESG-WARN [fdo#107724] /
> [fdo#108336]
>
> * igt@kms_cursor_crc@cursor-256x256-offscreen:
> - shard-skl: NOTRUN -> FAIL [fdo#103232]
>
> * igt@kms_cursor_crc@cursor-256x256-suspend:
> - shard-glk: PASS -> FAIL [fdo#103232] +2
>
> * igt@kms_cursor_crc@cursor-64x21-onscreen:
> - shard-apl: PASS -> FAIL [fdo#103232]
>
> * igt@kms
> _frontbuffer_tracking@fbc-1p-primscrn-pri-indfb-draw-render:
> - shard-iclb: PASS -> DMESG-FAIL [fdo#107724] +2
>
> * igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
> - shard-glk: PASS -> FAIL [fdo#103167] +3
>
> * igt@kms_frontbuffer_tracking@fbc-badstride:
> - shard-skl: NOTRUN -> FAIL [fdo#105682] +1
>
> * igt@kms_plane@pixel-format-pipe-b-planes-source-clamping:
> - shard-skl: NOTRUN -> DMESG-WARN [fdo#106885]
>
> * igt@kms_plane@plane-position-covered-pipe-c-planes:
> - shard-iclb: PASS -> FAIL [fdo#103166]
>
> * igt@kms_plane_alpha_blend@pipe-a-alpha-basic:
> - shard-skl: NOTRUN -> FAIL [fdo#107815] / [fdo#108145]
>
> * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-max:
> - shard-skl: NOTRUN -> FAIL [fdo#108145]
>
> * igt@kms_setmode@basic:
> - shard-apl: PASS -> FAIL [fdo#99912]
> - shard-kbl: PASS -> FAIL [fdo#99912]
>
> * igt@kms_universal_plane@universal-plane-pipe-c-functional:
> - shard-glk: PASS -> FAIL [fdo#103166]
>
> * igt@pm_rpm@fences:
> - shard-iclb: PASS -> DMESG-WARN [fdo#107724] +7
>
> * igt@pm_rpm@system-suspend-execbuf:
> - shard-iclb: PASS -> INCOMPLETE [fdo#107713] /
> [fdo#108840]
>
>
> Possible fixes
>
> * igt@gem_ctx_isolation@rcs0-s3:
> - shard-skl: INCOMPLETE [fdo#104108] / [fdo#107773] ->
> PASS +1
>
> * igt@i915_selftest@live_hangcheck:
> - shard-iclb: INCOMPLETE [fdo#108569] -> PASS
>
> * igt@kms
> _atomic_transition@plane-all-modeset-transition-internal-panels:
> - shard-iclb: DMESG-WARN [fdo#107724] -> PASS +2
>
> * igt@kms_busy@extended-pageflip-hang-newfb-render-b:
> - shard-glk: DMESG-WARN [fdo#107956] -> PASS
>
> * igt@kms_color@pipe-b-ctm-max:
> - shard-apl: FAIL [fdo#108147] -> PASS
>
> * igt@kms_color@pipe-c-degamma:
> - shard-apl: FAIL [fdo#104782] -> PASS
>
> * igt@kms_cursor_crc@cursor-256x256-random:
> - shard-apl: FAIL [fdo#103232] -> PASS
>
> * igt@kms_draw_crc@draw-method-rgb565-mmap-gtt-xtiled:
> - shard-skl: FAIL [fdo#103184] -> PASS
>
> * igt@kms_flip@flip-vs-expired-vblank-interruptible:
> - shard-skl: FAIL [fdo#105363] -> PASS
>
> * igt@kms_flip@modeset-vs-vblank-race:
> - shard-apl:
Re: [Intel-gfx] [PATCH 33/34] drm/i915: Prioritise non-busywait semaphore workloads
Quoting Chris Wilson (2019-01-21 22:21:16) > We don't want to busywait on the GPU if we have other work to do. If we > give non-busywaiting workloads higher (initial) priority than workloads > that require a busywait, we will prioritise work that is ready to run > immediately. Fwiw, without preemption using HW semaphore does perturb user visible scheduling behaviour (enough for me to be able to write a userspace deadlock). -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/selftests: Apply a subtest filter (rev3)
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev3)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465_full -> Patchwork_12008_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12008_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-kbl: NOTRUN -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-legacy-gamma:
- shard-apl: PASS -> FAIL [fdo#104782]
* igt@kms_cursor_crc@cursor-128x42-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_plane@pixel-format-pipe-a-planes:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-apl: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_alpha_blend@pipe-b-alpha-transparant-fb:
- shard-kbl: NOTRUN -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-b-tiling-y:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_setmode@basic:
- shard-apl: PASS -> FAIL [fdo#99912]
- shard-hsw: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-onoff:
- shard-glk: FAIL [fdo#103167] -> PASS +2
* igt@kms_frontbuffer_tracking@fbc-rgb101010-draw-pwrite:
- shard-snb: {SKIP} [fdo#109271] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-a-planes:
- shard-apl: FAIL [fdo#103166] -> PASS +1
* igt@kms_plane@plane-position-covered-pipe-c-planes:
- shard-glk: FAIL [fdo#103166] -> PASS +1
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
* igt@perf_pmu@rc6:
- shard-kbl: {SKIP} [fdo#109271] -> PASS
* igt@tools_test@tools_test:
- shard-glk: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104782]: https://bugs.freedesktop.org/show_bug.cgi?id=104782
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109350]: https://bugs.freedesktop.org/show_bug.cgi?id=109350
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5465 -> Patchwork_12008
CI_DRM_5465: 95a4790b382426fed48253664a12a4d7b63167b6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4783: 23f39950e824b8a8f31cfb26fc9b37ab1aca656f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12008: 5a359e5187f7b0a252abced300a08ac39d88a29b @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12008/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vbt: Parse and use the new field with PSR2 TP2/3/4 wakeup time
On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
These values are for PSR1, aren't they? Like you write in Patch 4/4,
the PSR2 control register does not have a bit to set anything other
than Tp2.
-DK
> added to VBT, so lets use it when available otherwise it will
> fallback to PSR1 wakeup time.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_bios.c | 10 ++
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index d9893d35f0e2..e739ed9ce60c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -967,6 +967,13 @@ enum psr_tp_wakeup_time {
> PSR_TP_WAKEUP_TIME_LAST
> };
>
> +enum psr2_tp_wakeup_time {
> + PSR2_TP_WAKEUP_TIME_500USEC = 0,
> + PSR2_TP_WAKEUP_TIME_100USEC,
> + PSR2_TP_WAKEUP_TIME_2500USEC,
> + PSR2_TP_WAKEUP_TIME_50USEC
> +};
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -1005,6 +1012,7 @@ struct intel_vbt_data {
> enum psr_lines_to_wait lines_to_wait;
> enum psr_tp_wakeup_time tp1_wakeup_time;
> enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
> + enum psr2_tp_wakeup_time psr2_tp2_tp3_tp4_wakeup_time;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 6de6f6f1deec..23130e0d5e6c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -757,6 +757,16 @@ parse_psr(struct drm_i915_private *dev_priv,
> const struct bdb_header *bdb)
>
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time =
> wakeup_time;
> }
> +
> + if (bdb->version >= 226) {
> + u32 wakeup_time = psr_table-
> >psr2_tp2_tp3_tp4_wakeup_time;
> +
> + wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
> wakeup_time;
> + } else {
> + /* Reusing PSR1 wakeup time for PSR2 in older VBTs */
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time;
> + }
> }
>
> static void parse_dsi_backlight_ports(struct drm_i915_private
> *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 5daf0b9e2b42..2fc537fb6e78 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -494,7 +494,7 @@ static void hsw_activate_psr2(struct intel_dp
> *intel_dp)
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency
> + 1);
>
> - val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
> + val |= dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
>
> I915_WRITE(EDP_PSR2_CTL, val);
> }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 4ed66efde49f..dc0a14977953 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -772,6 +772,9 @@ struct psr_table {
> /* TP wake up time in multiple of 100 */
> u16 tp1_wakeup_time;
> u16 tp2_tp3_tp4_wakeup_time;
> +
> + /* PSR2 TP2/TP3/TP4 wakeup time for 16 panels */
This needs to fixed as well.
> + u32 psr2_tp2_tp3_tp4_wakeup_time;
> } __packed;
>
> struct bdb_psr {
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/4] drm/i915/psr: Add HBR3 support
On Wed, 2019-01-16 at 15:43 -0800, José Roberto de Souza wrote:
> If the sink and source supports HBR3, TP4 should be used as link
> training pattern.
> For PSR2 there is no register to set and enable TP4 but according to
> eDP spec TP3 is still a training pattern acceptable for HBR3 panels.
>
Sounds like TP3 and TP4 are used only with PSR1, please document that
in the commit message.
> Cc: Manasi Navare
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
>
> Still trying to understand how PSR1 was working on ICL while sending
> TP4 to a panel that only supports HBR2.
That's a good point, along with that please find out what Bit 11: "TPS4
Control" does. I'd like us get these questions answered, if possible,
before merging this series.
>
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_dp_link_training.c | 2 +-
> drivers/gpu/drm/i915/intel_drv.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 24 ++---
> --
> 4 files changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 5faca634ee70..1e792309a79e 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4162,6 +4162,7 @@ enum {
> #define EDP_PSR_TP1_TP3_SEL(1 << 11)
> #define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
> #define EDP_PSR_TP2_TP3_TIME_SHIFT (8)
> +#define EDP_PSR_TP4_TIME_SHIFT (6) /* ICL+ */
> #define EDP_PSR_TP1_TIME_SHIFT (4)
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> diff --git a/drivers/gpu/drm/i915/intel_dp_link_training.c
> b/drivers/gpu/drm/i915/intel_dp_link_training.c
> index 30be0e39bd5f..3e9798a5498c 100644
> --- a/drivers/gpu/drm/i915/intel_dp_link_training.c
> +++ b/drivers/gpu/drm/i915/intel_dp_link_training.c
> @@ -238,7 +238,7 @@ intel_dp_link_training_clock_recovery(struct
> intel_dp *intel_dp)
> * or for 1.4 devices that support it, training Pattern 3 for HBR2
> * or 1.2 devices that support it, Training Pattern 2 otherwise.
> */
> -static u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
> +u32 intel_dp_training_pattern(struct intel_dp *intel_dp)
> {
> bool source_tps3, sink_tps3, source_tps4, sink_tps4;
>
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index e5a436c33307..fc3e6ae92276 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1807,6 +1807,7 @@ int
> intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> int link_rate, uint8_t
> lane_count);
> void intel_dp_start_link_train(struct intel_dp *intel_dp);
> void intel_dp_stop_link_train(struct intel_dp *intel_dp);
> +u32 intel_dp_training_pattern(struct intel_dp *intel_dp);
> int intel_dp_retrain_link(struct intel_encoder *encoder,
> struct drm_modeset_acquire_ctx *ctx);
> void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 2fc537fb6e78..b0525940e5e9 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -440,6 +440,7 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = dp_to_i915(intel_dp);
> u32 max_sleep_time = 0x1f;
> u32 val = EDP_PSR_ENABLE;
> + u32 tp;
>
> /* Let's use 6 as the minimum to cover all known cases
> including the
>* off-by-one issue that HW has in some cases.
> @@ -460,13 +461,24 @@ static void hsw_activate_psr1(struct intel_dp
> *intel_dp)
> val |= EDP_PSR_LINK_STANDBY;
>
> val |= dev_priv->vbt.psr.tp1_wakeup_time <<
> EDP_PSR_TP1_TIME_SHIFT;
> - val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR_TP2_TP3_TIME_SHIFT;
>
> - if (intel_dp_source_supports_hbr2(intel_dp) &&
Now that you are removing a caller, make this function static and move
to intel_dp_link_tranining.c instead ? Or just inline the code there.
> - drm_dp_tps3_supported(intel_dp->dpcd))
> - val |= EDP_PSR_TP1_TP3_SEL;
> - else
> - val |= EDP_PSR_TP1_TP2_SEL;
> + tp = intel_dp_training_pattern(intel_dp);
> + if (tp == DP_TRAINING_PATTERN_4) {
> + /*
> + * TP4 is selected by setting EDP_PSR_TP4_TIME with
> other value
> + * than PSR_TP_WAKEUP_TIME_NONE
> + */
IMHO I think we should skip this comment, we'd have to write
documentation for every other register if we are going to do this :)
> + val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR_TP4_TIME_SHIFT;
So, the EDP_PSR_TP1_TP3_SEL bit has no effect when the TP4 duration is
non-zero, seems like an indirect way of switching to TP4 compared to
TP2 and TP3.
>
Re: [Intel-gfx] [PATCH 02/34] drm/i915/execlists: Suppress preempting self
Quoting John Harrison (2019-01-22 22:18:46)
> On 1/21/2019 14:20, Chris Wilson wrote:
> > In order to avoid preempting ourselves, we currently refuse to schedule
> > the tasklet if we reschedule an inflight context. However, this glosses
> > over a few issues such as what happens after a CS completion event and
> > we then preempt the newly executing context with itself, or if something
> > else causes a tasklet_schedule triggering the same evaluation to
> > preempt the active context with itself.
> >
> > To avoid the extra complications, after deciding that we have
> > potentially queued a request with higher priority than the currently
> > executing request, inspect the head of the queue to see if it is indeed
> > higher priority from another context.
> >
> > References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on
> > the current context")
> > Signed-off-by: Chris Wilson
> > Cc: Tvrtko Ursulin
>
> Can you explain what was wrong with the previous version of this patch
> (drm/i915/execlists: Store the highest priority context)? It seemed simpler.
The goal here is to be a more general suppression mechanism than the
first version. queue_priority is a hint and can't be trusted as we may
have set it for an inflight request since completed. Given that it tells
us that a preemption point _was_ required, but we don't want to forcibly
inject an idle barrier, we inspect the queue instead and not take the
hint at face value. In that light, queue_context is superfluous as we
ignore the ELSP[0] context anyway.
The patch is slightly bigger than it needed to be because I was
refactoring out some changes for later, and a bit of paranoid asserts
from debugging that didn't really belong in the bugfix.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/34] drm/i915: Make all GPU resets atomic
Quoting John Harrison (2019-01-22 22:19:04)
> On 1/21/2019 14:20, Chris Wilson wrote:
> > In preparation for the next few commits, make resetting the GPU atomic.
> > Currently, we have prepared gen6+ for atomic resetting of individual
> > engines, but now there is a requirement to perform the whole device
> > level reset (just the register poking) from inside an atomic context.
> >
> > Signed-off-by: Chris Wilson
> > Reviewed-by: Mika Kuoppala
> > ---
> > drivers/gpu/drm/i915/i915_reset.c | 50 +--
> > 1 file changed, 27 insertions(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c
> > b/drivers/gpu/drm/i915/i915_reset.c
> > index 342d9ee42601..b9d0ea70361c 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -144,14 +144,14 @@ static int i915_do_reset(struct drm_i915_private
> > *i915,
> >
> > /* Assert reset for at least 20 usec, and wait for acknowledgement. */
> > pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
> > - usleep_range(50, 200);
> > - err = wait_for(i915_in_reset(pdev), 500);
> > + udelay(50);
> > + err = wait_for_atomic(i915_in_reset(pdev), 50);
> Is it known to be safe to reduce all of these time out values? Where did
> the originally 500ms value come from?
I chose it entirely upon a whim, picking a huge number unlikely to ever
be exceeded, and if it were we would be right to conclude the HW was
unrecoverable.
> Is there any chance of getting
> sporadic failures because 50ms is borderline in the worst case scenario?
> It still sounds huge but an order of magnitude change in a timeout
> always seems worrying!
Whereas 50us is more in line with the little bits of documentation that
still exist.
> > @@ -218,27 +218,29 @@ static int ironlake_do_reset(struct drm_i915_private
> > *dev_priv,
> > {
> > int ret;
> >
> > - I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
> > - ret = intel_wait_for_register(dev_priv,
> > - ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
> > - 500);
> > + I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
> > + ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
> > +ILK_GRDOM_RESET_ENABLE, 0,
> > +5000, 0,
> > +NULL);
> These two timeouts are now two orders of magnitude smaller? It was 500ms
> but is now 5000us (=5ms)?
0.5 was the same number plucked from the air. No guidance here, that I
know of, except we have lots of runs through CI to try and estimate
bounds.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/34] drm/i915/guc: Disable global reset
On 1/21/2019 14:20, Chris Wilson wrote:
The guc (and huc) currently inexcruitably depend on struct_mutex for
device reinitialisation from inside the reset, and indeed taking any
mutex here is verboten (as we must be able to reset from underneath any
of our mutexes). That makes recovering the guc unviable without, for
example, reserving contiguous vma space and pages for it to use.
The plan to re-enable global reset for the GuC centres around reusing the
WOPM reserved space at the top of the aperture (that we know we can
populate a contiguous range large enough to dma xfer the fw image).
In the meantime, hopefully no one even notices as the device-reset is
only used as a backup to the per-engine resets for handling GPU hangs.
Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
Acked-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_reset.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index b9d0ea70361c..2961c21d9420 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -590,6 +590,9 @@ int intel_gpu_reset(struct drm_i915_private *i915, unsigned
int engine_mask)
bool intel_has_gpu_reset(struct drm_i915_private *i915)
{
+ if (USES_GUC(i915))
+ return false;
+
return intel_get_gpu_reset(i915);
}
Reviewed-by: John Harrison
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/34] drm/i915/execlists: Suppress preempting self
On 1/21/2019 14:20, Chris Wilson wrote:
In order to avoid preempting ourselves, we currently refuse to schedule
the tasklet if we reschedule an inflight context. However, this glosses
over a few issues such as what happens after a CS completion event and
we then preempt the newly executing context with itself, or if something
else causes a tasklet_schedule triggering the same evaluation to
preempt the active context with itself.
To avoid the extra complications, after deciding that we have
potentially queued a request with higher priority than the currently
executing request, inspect the head of the queue to see if it is indeed
higher priority from another context.
References: a2bf92e8cc16 ("drm/i915/execlists: Avoid kicking priority on the current
context")
Signed-off-by: Chris Wilson
Cc: Tvrtko Ursulin
Can you explain what was wrong with the previous version of this patch
(drm/i915/execlists: Store the highest priority context)? It seemed simpler.
John.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/34] drm/i915: Make all GPU resets atomic
On 1/21/2019 14:20, Chris Wilson wrote:
In preparation for the next few commits, make resetting the GPU atomic.
Currently, we have prepared gen6+ for atomic resetting of individual
engines, but now there is a requirement to perform the whole device
level reset (just the register poking) from inside an atomic context.
Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_reset.c | 50 +--
1 file changed, 27 insertions(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reset.c
b/drivers/gpu/drm/i915/i915_reset.c
index 342d9ee42601..b9d0ea70361c 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -144,14 +144,14 @@ static int i915_do_reset(struct drm_i915_private *i915,
/* Assert reset for at least 20 usec, and wait for acknowledgement. */
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
- usleep_range(50, 200);
- err = wait_for(i915_in_reset(pdev), 500);
+ udelay(50);
+ err = wait_for_atomic(i915_in_reset(pdev), 50);
Is it known to be safe to reduce all of these time out values? Where did
the originally 500ms value come from? Is there any chance of getting
sporadic failures because 50ms is borderline in the worst case scenario?
It still sounds huge but an order of magnitude change in a timeout
always seems worrying!
/* Clear the reset request. */
pci_write_config_byte(pdev, I915_GDRST, 0);
- usleep_range(50, 200);
+ udelay(50);
if (!err)
- err = wait_for(!i915_in_reset(pdev), 500);
+ err = wait_for_atomic(!i915_in_reset(pdev), 50);
return err;
}
@@ -171,7 +171,7 @@ static int g33_do_reset(struct drm_i915_private *i915,
struct pci_dev *pdev = i915->drm.pdev;
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
- return wait_for(g4x_reset_complete(pdev), 500);
+ return wait_for_atomic(g4x_reset_complete(pdev), 50);
}
static int g4x_do_reset(struct drm_i915_private *dev_priv,
@@ -182,13 +182,13 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
int ret;
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
- I915_WRITE(VDECCLK_GATE_D,
- I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
- POSTING_READ(VDECCLK_GATE_D);
+ I915_WRITE_FW(VDECCLK_GATE_D,
+ I915_READ(VDECCLK_GATE_D) | VCP_UNIT_CLOCK_GATE_DISABLE);
+ POSTING_READ_FW(VDECCLK_GATE_D);
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_MEDIA | GRDOM_RESET_ENABLE);
- ret = wait_for(g4x_reset_complete(pdev), 500);
+ ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
if (ret) {
DRM_DEBUG_DRIVER("Wait for media reset failed\n");
goto out;
@@ -196,7 +196,7 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
pci_write_config_byte(pdev, I915_GDRST,
GRDOM_RENDER | GRDOM_RESET_ENABLE);
- ret = wait_for(g4x_reset_complete(pdev), 500);
+ ret = wait_for_atomic(g4x_reset_complete(pdev), 50);
if (ret) {
DRM_DEBUG_DRIVER("Wait for render reset failed\n");
goto out;
@@ -205,9 +205,9 @@ static int g4x_do_reset(struct drm_i915_private *dev_priv,
out:
pci_write_config_byte(pdev, I915_GDRST, 0);
- I915_WRITE(VDECCLK_GATE_D,
- I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
- POSTING_READ(VDECCLK_GATE_D);
+ I915_WRITE_FW(VDECCLK_GATE_D,
+ I915_READ(VDECCLK_GATE_D) & ~VCP_UNIT_CLOCK_GATE_DISABLE);
+ POSTING_READ_FW(VDECCLK_GATE_D);
return ret;
}
@@ -218,27 +218,29 @@ static int ironlake_do_reset(struct drm_i915_private
*dev_priv,
{
int ret;
- I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
- ret = intel_wait_for_register(dev_priv,
- ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
- 500);
+ I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
+ ret = __intel_wait_for_register_fw(dev_priv, ILK_GDSR,
+ ILK_GRDOM_RESET_ENABLE, 0,
+ 5000, 0,
+ NULL);
These two timeouts are now two orders of magnitude smaller? It was 500ms
but is now 5000us (=5ms)?
John.
if (ret) {
DRM_DEBUG_DRIVER("Wait for render reset failed\n");
goto out;
}
- I915_WRITE(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
- ret = intel_wait_for_register(dev_priv,
- ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
- 500);
+ I915_WRITE_FW(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
+
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
== Series Details ==
Series: drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
URL : https://patchwork.freedesktop.org/series/55586/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12009
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55586/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12009 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: PASS -> DMESG-WARN [fdo#108965]
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_chamelium@dp-hpd-fast:
- fi-kbl-7500u: PASS -> DMESG-WARN [fdo#102505] / [fdo#103558] /
[fdo#105602]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#102505]: https://bugs.freedesktop.org/show_bug.cgi?id=102505
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103558]: https://bugs.freedesktop.org/show_bug.cgi?id=103558
[fdo#105602]: https://bugs.freedesktop.org/show_bug.cgi?id=105602
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108654]: https://bugs.freedesktop.org/show_bug.cgi?id=108654
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 42)
--
Additional (2): fi-byt-j1900 fi-gdg-551
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5465 -> Patchwork_12009
CI_DRM_5465: 95a4790b382426fed48253664a12a4d7b63167b6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4783: 23f39950e824b8a8f31cfb26fc9b37ab1aca656f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12009: 7cdae183412046e7cb8ccf0a4f85ed76268ade6b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7cdae1834120 drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12009/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries
Quoting Lucas De Marchi (2019-01-22 21:33:25) > On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote: > > > > Quoting Lucas De Marchi (2019-01-22 05:12:24) > > > Let's use a macro to make tables smaller and at the same time allow us > > > to add fields that apply to all entries in future. > > > > > > For the sake of readability, I'm calling an exception on 80 chars limit. > > > Lines are aligned for easy comparison of the entry values. > > > > > + MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, \ > > > + L3_1_UC), \ > > > > MOCS_ENTRY(I915_MOCS_UNCACHED, > > LE_1_UC | LE_TC_2_LLC_ELLC, L3_1_UC), \ > > My intention was to split the lines for each *value*, so it's easy to > see what control_value vs l3cc_value is set to > (too difficult to spot mistakes on adding a comma rather than a |). > > But I'm not strongly against your version, so I'll switch to that. Have another new line :) Because you are right as I confused that \ for a |. MOCS_ENTRY(I915_MOCS_UNCACHED, \ LE_1_UC | LE_TC_2_LLC_ELLC, \ L3_1_UC), \ -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries
On Tue, Jan 22, 2019 at 6:32 AM Chris Wilson wrote: > > Quoting Lucas De Marchi (2019-01-22 05:12:24) > > Let's use a macro to make tables smaller and at the same time allow us > > to add fields that apply to all entries in future. > > > > For the sake of readability, I'm calling an exception on 80 chars limit. > > Lines are aligned for easy comparison of the entry values. > > > + MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, \ > > + L3_1_UC), \ > > MOCS_ENTRY(I915_MOCS_UNCACHED, > LE_1_UC | LE_TC_2_LLC_ELLC, L3_1_UC), \ My intention was to split the lines for each *value*, so it's easy to see what control_value vs l3cc_value is set to (too difficult to spot mistakes on adding a comma rather than a |). But I'm not strongly against your version, so I'll switch to that. thanks Lucas De Marchi > > is even more readable with the visual clustering of attribute flags. > -Chris > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Lucas De Marchi ___ 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/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
== Series Details == Series: drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120 URL : https://patchwork.freedesktop.org/series/55586/ State : warning == Summary == $ dim checkpatch origin/drm-tip 7cdae1834120 drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120 -:22: WARNING:COMMIT_LOG_LONG_LINE: Possible unwrapped commit description (prefer a maximum 75 chars per line) #22: This is currently not tested, but I wanted to get some inputs on this approach. -:96: CHECK:BRACES: Blank lines aren't necessary before a close brace '}' #96: FILE: drivers/gpu/drm/i915/intel_display.c:10958: + +} total: 0 errors, 1 warnings, 1 checks, 87 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC] drm/i915/dp: Preliminary support for 2 pipe 1 port mode for 5K@120
On Gen 11 platform, to enable resolutions like 5K@120 where
the pixel clock is greater than pipe pixel rate, we need to split it across
2 pipes and enable it using DSC and big joiner. In order to support this
dual pipe single port mode, we need to link two crtcs involved in this
ganged mode.
This patch is a RFC patch that links two crtcs using linked_crtc pointer
in intel_crtc_state and slave to indicate if the crtc is a master or slave.
Here the HW necessitates the first CRTC to be the master CRTC through which
the final output will be driven and the next consecutive CRTC should be
slave crtc.
This is currently not tested, but I wanted to get some inputs on this approach.
The idea is to follow the same approach used in Ganged plane mode for NV12
planes.
Suggested-by: Maarten Lankhorst ,
Matt Roper
Cc: Ville Syrjälä
Cc: Matt Roper
Cc: Maarten Lankhorst
Signed-off-by: Manasi Navare
---
drivers/gpu/drm/i915/intel_display.c | 63
drivers/gpu/drm/i915/intel_drv.h | 6 +++
2 files changed, 69 insertions(+)
diff --git a/drivers/gpu/drm/i915/intel_display.c
b/drivers/gpu/drm/i915/intel_display.c
index 2fa9f4aec08e..9910dad7371b 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -10900,6 +10900,63 @@ static bool check_single_encoder_cloning(struct
drm_atomic_state *state,
return true;
}
+static bool icl_dual_pipe_mode(struct drm_i915_private *dev_priv,
+ struct drm_crtc_state *crtc_state)
+{
+ if (crtc_state->mode.clock <= 2 * dev_priv->max_cdclk_freq)
+ return false;
+
+ return true;
+}
+
+static int icl_set_linked_crtcs(struct drm_atomic_state *state)
+{
+ struct drm_i915_private *dev_priv = to_i915(state->dev);
+ struct drm_crtc *crtc;
+ struct drm_crtc_state *crtc_state;
+ struct intel_crtc_state *linked_state = NULL;
+ struct intel_crtc *slave_crtc = NULL;
+ int i;
+
+ for_each_new_crtc_in_state(state, crtc, crtc_state, i) {
+ struct intel_crtc_state *pipe_config =
+ to_intel_crtc_state(crtc_state);
+ struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
+
+ if (crtc_state->active)
+ continue;
+
+ if (!icl_dual_pipe_mode(dev_priv, crtc_state))
+ continue;
+
+ if (!pipe_config->linked_crtc) {
+ slave_crtc = intel_get_crtc_for_pipe(dev_priv,
+intel_crtc->pipe +
1);
+ if (!slave_crtc)
+ return PTR_ERR(slave_crtc);
+
+ linked_state = intel_atomic_get_crtc_state(state,
slave_crtc);
+ if (IS_ERR(linked_state))
+ return PTR_ERR(linked_state);
+
+ pipe_config->linked_crtc = slave_crtc;
+ pipe_config->slave = false;
+ linked_state->linked_crtc = intel_crtc;
+ linked_state->slave = true;
+ // Update the intel_state->active_crtcs if needed
+
+ DRM_DEBUG_KMS("Using [CRTC:%d:%s] as master and
[CRTC:%d:%s] as slave\n",
+ intel_crtc->base.base.id,
intel_crtc->base.name,
+ slave_crtc->base.base.id,
slave_crtc->base.name);
+
+ break;
+ }
+ }
+
+ return 0;
+
+}
+
static int icl_add_linked_planes(struct intel_atomic_state *state)
{
struct intel_plane *plane, *linked;
@@ -12702,6 +12759,12 @@ static int intel_atomic_check(struct drm_device *dev,
if (ret)
return ret;
+ if (INTEL_GEN(dev_priv) >= 11) {
+ ret = icl_set_linked_crtcs(state);
+ if (ret)
+ return ret;
+ }
+
for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, crtc_state,
i) {
struct intel_crtc_state *pipe_config =
to_intel_crtc_state(crtc_state);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 33b733d37706..f8bbed525ec3 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -959,6 +959,12 @@ struct intel_crtc_state {
/* Forward Error correction State */
bool fec_enable;
+
+ /* Pointer to linked crtc in dual pipe mode */
+ struct intel_crtc *linked_crtc;
+
+ /* Flag to indicate whether this crtc is master or slave */
+ bool slave;
};
struct intel_crtc {
--
2.19.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Apply a subtest filter (rev3)
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev3)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12008
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55576/revisions/3/mbox/
Known issues
Here are the changes found in Patchwork_12008 that come from known issues:
### IGT changes ###
Issues hit
* igt@gem_exec_suspend@basic-s4-devices:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-b-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362] +1
* igt@prime_vgem@basic-fence-flip:
- fi-gdg-551: NOTRUN -> FAIL [fdo#103182]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 40)
--
Additional (2): fi-byt-j1900 fi-gdg-551
Missing(6): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
fi-pnv-d510 fi-icl-y
Build changes
-
* Linux: CI_DRM_5465 -> Patchwork_12008
CI_DRM_5465: 95a4790b382426fed48253664a12a4d7b63167b6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4783: 23f39950e824b8a8f31cfb26fc9b37ab1aca656f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12008: 5a359e5187f7b0a252abced300a08ac39d88a29b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
5a359e5187f7 drm/i915/selftests: Apply a subtest filter
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12008/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type
On Tue, Jan 22, 2019 at 08:39:53PM -, Patchwork wrote:
> == Series Details ==
>
> Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
> NAK reply type
> URL : https://patchwork.freedesktop.org/series/55581/
> State : failure
>
> == Summary ==
>
> CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12007
>
>
> Summary
> ---
>
> **FAILURE**
>
> Serious unknown changes coming with Patchwork_12007 absolutely need to be
> verified manually.
>
> If you think the reported changes have nothing to do with the changes
> introduced in Patchwork_12007, please notify your bug team to allow them
> to document this new failure mode, which will reduce false positives in CI.
>
> External URL:
> https://patchwork.freedesktop.org/api/1.0/series/55581/revisions/1/mbox/
>
> Possible new issues
> ---
>
> Here are the unknown changes that may have been introduced in
> Patchwork_12007:
>
> ### IGT changes ###
>
> Possible regressions
>
> * igt@pm_rpm@module-reload:
> - fi-skl-6770hq: PASS -> FAIL
(pm_rpm:4020) CRITICAL: Test assertion failure function
assert_drm_connectors_equal, file ../tests/pm_rpm.c:510:
(pm_rpm:4020) CRITICAL: Failed assertion: c1->mmWidth == c2->mmWidth
(pm_rpm:4020) CRITICAL: error: 520 != 0
I suppose the display/lspcon just decided to go AWOL for a while there:
<7>[ 311.282098] [drm:drm_helper_probe_single_connector_modes]
[CONNECTOR:85:DP-1] status updated from connected to disconnected
...
<7>[ 311.363264] [drm:drm_helper_hpd_irq_event] [CONNECTOR:85:DP-1] status
updated from disconnected to connected
>
>
> Known issues
>
>
> Here are the changes found in Patchwork_12007 that come from known issues:
>
> ### IGT changes ###
>
> Issues hit
>
> * igt@kms_chamelium@hdmi-hpd-fast:
> - fi-kbl-7500u: PASS -> FAIL [fdo#108767]
>
> * igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
> - fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
>
> * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
> - fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
>
>
> {name}: This element is suppressed. This means it is ignored when computing
> the status of the difference (SUCCESS, WARNING, or FAILURE).
>
> [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
> [fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
> [fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
> [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
> [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
> [fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
> [fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
> [fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
>
>
> Participating hosts (44 -> 42)
> --
>
> Additional (2): fi-byt-j1900 fi-gdg-551
> Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
>
>
> Build changes
> -
>
> * Linux: CI_DRM_5465 -> Patchwork_12007
>
> CI_DRM_5465: 95a4790b382426fed48253664a12a4d7b63167b6 @
> git://anongit.freedesktop.org/gfx-ci/linux
> IGT_4783: 23f39950e824b8a8f31cfb26fc9b37ab1aca656f @
> git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
> Patchwork_12007: c3c8c7c4136f32872681668340855e722dac464b @
> git://anongit.freedesktop.org/gfx-ci/linux
>
>
> == Linux commits ==
>
> c3c8c7c4136f drm/dp/mst: Provide better debugs for NAK replies
> 84875e8bb29f drm/dp/mst: Provide defines for ACK vs. NAK reply type
>
> == Logs ==
>
> For more details see:
> https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12007/
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/kms_flip: Add test to check suspend/resume
This patch adds one test to evaluate suspend/resume operations using kms_flip.
Signed-off-by: Shayenne Moura
v2: Reduce test time to 10 (Daniel)
---
tests/kms_flip.c | 1 +
1 file changed, 1 insertion(+)
mode change 100644 => 100755 tests/kms_flip.c
diff --git a/tests/kms_flip.c b/tests/kms_flip.c
old mode 100644
new mode 100755
index f28272dd..3c29f47a
--- a/tests/kms_flip.c
+++ b/tests/kms_flip.c
@@ -1567,6 +1567,7 @@ int main(int argc, char **argv)
{ 10, TEST_DPMS_OFF | TEST_DPMS | TEST_VBLANK_RACE,
"dpms-vs-vblank-race" },
{ 10, TEST_MODESET | TEST_VBLANK_RACE, "modeset-vs-vblank-race"
},
{ 0, TEST_BO_TOOBIG | TEST_NO_2X_OUTPUT, "bo-too-big" },
+ { 10, TEST_FLIP | TEST_SUSPEND, "flip-vs-suspend" },
};
int i;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type
== Series Details ==
Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs.
NAK reply type
URL : https://patchwork.freedesktop.org/series/55581/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_5465 -> Patchwork_12007
Summary
---
**FAILURE**
Serious unknown changes coming with Patchwork_12007 absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_12007, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55581/revisions/1/mbox/
Possible new issues
---
Here are the unknown changes that may have been introduced in Patchwork_12007:
### IGT changes ###
Possible regressions
* igt@pm_rpm@module-reload:
- fi-skl-6770hq: PASS -> FAIL
Known issues
Here are the changes found in Patchwork_12007 that come from known issues:
### IGT changes ###
Issues hit
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: PASS -> FAIL [fdo#103191] / [fdo#107362]
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a:
- fi-blb-e6850: PASS -> INCOMPLETE [fdo#107718]
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (44 -> 42)
--
Additional (2): fi-byt-j1900 fi-gdg-551
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5465 -> Patchwork_12007
CI_DRM_5465: 95a4790b382426fed48253664a12a4d7b63167b6 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4783: 23f39950e824b8a8f31cfb26fc9b37ab1aca656f @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12007: c3c8c7c4136f32872681668340855e722dac464b @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
c3c8c7c4136f drm/dp/mst: Provide better debugs for NAK replies
84875e8bb29f drm/dp/mst: Provide defines for ACK vs. NAK reply type
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12007/
___
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/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type
== Series Details == Series: series starting with [v2,1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type URL : https://patchwork.freedesktop.org/series/55581/ State : warning == Summary == $ dim checkpatch origin/drm-tip 84875e8bb29f drm/dp/mst: Provide defines for ACK vs. NAK reply type c3c8c7c4136f drm/dp/mst: Provide better debugs for NAK replies -:26: ERROR:BRACKET_SPACE: space prohibited before open square bracket '[' #26: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:71: +#define DP_STR(x) [DP_ ## x] = #x -:57: ERROR:BRACKET_SPACE: space prohibited before open square bracket '[' #57: FILE: drivers/gpu/drm/drm_dp_mst_topology.c:102: +#define DP_STR(x) [DP_NAK_ ## x] = #x total: 2 errors, 0 warnings, 0 checks, 102 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Apply a subtest filter
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably subsubtests!). For simplicity, allow the user to provide a
command line parameter such as
i915.st_filter=i915_timeline_mock_selftests/igt_sync
to restrict ourselves to only running on subtest. The exact name to use
is given during a normal run, highlighted as an error if it failed,
debug otherwise. The test group is optional, and then all subtests are
compared for an exact match with the filter (most subtests have unique
names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
then all tests but those that match will be run. More than one match can
be supplied separated by a comma, e.g.
i915.st_filter=igt_vma_create,igt_vma_pin1
to only run those specified, or
i915.st_filter=!igt_vma_create,!igt_vma_pin1
to run all but those named. Mixing a blacklist and whitelist will only
execute those subtests matching the whitelist so long as they are
previously excluded in the blacklist.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
Condensed error handling.
---
drivers/gpu/drm/i915/i915_selftest.h | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c| 44 +++
2 files changed, 45 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index a73472dd12fd..207e21b478f2 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -31,6 +31,7 @@ struct i915_selftest {
unsigned long timeout_jiffies;
unsigned int timeout_ms;
unsigned int random_seed;
+ char *filter;
int mock;
int live;
};
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 86c54ea37f48..69952d246098 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -197,6 +197,46 @@ int i915_live_selftests(struct pci_dev *pdev)
return 0;
}
+static bool apply_subtest_filter(const char *caller, const char *name)
+{
+ char *filter, *sep, *tok;
+ bool result = true;
+
+ filter = kstrdup(i915_selftest.filter, GFP_KERNEL);
+ for (sep = filter; (tok = strsep(, ","));) {
+ bool allow = true;
+ char *sl;
+
+ if (*tok == '!') {
+ allow = false;
+ tok++;
+ }
+
+ sl = strchr(tok, '/');
+ if (sl) {
+ *sl++ = '\0';
+ if (strcmp(tok, caller)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+ tok = sl;
+ }
+
+ if (strcmp(tok, name)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+
+ result = allow;
+ break;
+ }
+
+ kfree(filter);
+ return result;
+}
+
int __i915_subtests(const char *caller,
const struct i915_subtest *st,
unsigned int count,
@@ -209,6 +249,9 @@ int __i915_subtests(const char *caller,
if (signal_pending(current))
return -EINTR;
+ if (!apply_subtest_filter(caller, st->name))
+ continue;
+
pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
GEM_TRACE("Running %s/%s\n", caller, st->name);
@@ -244,6 +287,7 @@ bool __igt_timeout(unsigned long timeout, const char *fmt,
...)
module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
+module_param_named(st_filter, i915_selftest.filter, charp, 0400);
module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock
hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then
exit module)");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/2] drm/dp/mst: Provide defines for ACK vs. NAK reply type
From: Ville Syrjälä
Make the code a bit easier to read by providing symbolic names
for the reply_type (ACK vs. NAK). Also clean up some brace stuff
while at it.
v2: s/DP_REPLY/DP_SIDEBAND_REPLY/ (DK)
Fix some checkpatch issues
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_dp_mst_topology.c | 26 +-
include/drm/drm_dp_helper.h | 4
2 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 196ebba8af5f..c2ae56eabe44 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -568,7 +568,7 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
msg->reply_type = (raw->msg[0] & 0x80) >> 7;
msg->req_type = (raw->msg[0] & 0x7f);
- if (msg->reply_type) {
+ if (msg->reply_type == DP_SIDEBAND_REPLY_NAK) {
memcpy(msg->u.nak.guid, >msg[1], 16);
msg->u.nak.reason = raw->msg[17];
msg->u.nak.nak_data = raw->msg[18];
@@ -1969,9 +1969,9 @@ static void drm_dp_send_link_address(struct
drm_dp_mst_topology_mgr *mgr,
if (ret > 0) {
int i;
- if (txmsg->reply.reply_type == 1)
+ if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK) {
DRM_DEBUG_KMS("link address nak received\n");
- else {
+ } else {
DRM_DEBUG_KMS("link address reply: %d\n",
txmsg->reply.u.link_addr.nports);
for (i = 0; i < txmsg->reply.u.link_addr.nports; i++) {
DRM_DEBUG_KMS("port %d: input %d, pdt: %d, pn:
%d, dpcd_rev: %02x, mcs: %d, ddps: %d, ldps %d, sdp %d/%d\n", i,
@@ -2020,9 +2020,9 @@ static int drm_dp_send_enum_path_resources(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
if (ret > 0) {
- if (txmsg->reply.reply_type == 1)
+ if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK) {
DRM_DEBUG_KMS("enum path resources nak received\n");
- else {
+ } else {
if (port->port_num !=
txmsg->reply.u.path_resources.port_number)
DRM_ERROR("got incorrect port in response\n");
DRM_DEBUG_KMS("enum path resources %d: %d %d\n",
txmsg->reply.u.path_resources.port_number,
txmsg->reply.u.path_resources.full_payload_bw_number,
@@ -2132,7 +2132,7 @@ static int drm_dp_payload_send_msg(struct
drm_dp_mst_topology_mgr *mgr,
*/
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
if (ret > 0) {
- if (txmsg->reply.reply_type == 1)
+ if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK)
ret = -EINVAL;
else
ret = 0;
@@ -2165,7 +2165,7 @@ int drm_dp_send_power_updown_phy(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_mst_wait_tx_reply(port->parent, txmsg);
if (ret > 0) {
- if (txmsg->reply.reply_type == 1)
+ if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK)
ret = -EINVAL;
else
ret = 0;
@@ -2423,9 +2423,9 @@ static int drm_dp_send_dpcd_write(struct
drm_dp_mst_topology_mgr *mgr,
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
if (ret > 0) {
- if (txmsg->reply.reply_type == 1) {
+ if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK)
ret = -EINVAL;
- } else
+ else
ret = 0;
}
kfree(txmsg);
@@ -2438,7 +2438,7 @@ static int drm_dp_encode_up_ack_reply(struct
drm_dp_sideband_msg_tx *msg, u8 req
{
struct drm_dp_sideband_msg_reply_body reply;
- reply.reply_type = 0;
+ reply.reply_type = DP_SIDEBAND_REPLY_ACK;
reply.req_type = req_type;
drm_dp_encode_sideband_reply(, msg);
return 0;
@@ -2745,9 +2745,9 @@ static int drm_dp_mst_handle_down_rep(struct
drm_dp_mst_topology_mgr *mgr)
}
drm_dp_sideband_parse_reply(>down_rep_recv, >reply);
- if (txmsg->reply.reply_type == 1) {
+
+ if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK)
DRM_DEBUG_KMS("Got NAK reply: req 0x%02x, reason
0x%02x, nak data 0x%02x\n", txmsg->reply.req_type, txmsg->reply.u.nak.reason,
txmsg->reply.u.nak.nak_data);
- }
memset(>down_rep_recv, 0, sizeof(struct
drm_dp_sideband_msg_rx));
drm_dp_mst_topology_put_mstb(mstb);
@@ -3893,7 +3893,7 @@ static int drm_dp_mst_i2c_xfer(struct i2c_adapter
*adapter, struct i2c_msg *msgs
ret = drm_dp_mst_wait_tx_reply(mstb, txmsg);
[Intel-gfx] [PATCH v2 2/2] drm/dp/mst: Provide better debugs for NAK replies
From: Ville Syrjälä
Decode the NAK reply fields to make it easier to parse the logs.
v2: s/STR/DP_STR/ to avoid conflict with some header stuff (0day)
Use drm_dp_mst_req_type_str() more (DK)
Signed-off-by: Ville Syrjälä
Reviewed-by: Dhinakaran Pandiyan
---
drivers/gpu/drm/drm_dp_mst_topology.c | 71 +--
include/drm/drm_dp_helper.h | 1 +
2 files changed, 69 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
b/drivers/gpu/drm/drm_dp_mst_topology.c
index c2ae56eabe44..0eafde53bd81 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -67,6 +67,64 @@ static bool drm_dp_validate_guid(struct
drm_dp_mst_topology_mgr *mgr,
static int drm_dp_mst_register_i2c_bus(struct drm_dp_aux *aux);
static void drm_dp_mst_unregister_i2c_bus(struct drm_dp_aux *aux);
static void drm_dp_mst_kick_tx(struct drm_dp_mst_topology_mgr *mgr);
+
+#define DP_STR(x) [DP_ ## x] = #x
+
+static const char *drm_dp_mst_req_type_str(u8 req_type)
+{
+ static const char * const req_type_str[] = {
+ DP_STR(GET_MSG_TRANSACTION_VERSION),
+ DP_STR(LINK_ADDRESS),
+ DP_STR(CONNECTION_STATUS_NOTIFY),
+ DP_STR(ENUM_PATH_RESOURCES),
+ DP_STR(ALLOCATE_PAYLOAD),
+ DP_STR(QUERY_PAYLOAD),
+ DP_STR(RESOURCE_STATUS_NOTIFY),
+ DP_STR(CLEAR_PAYLOAD_ID_TABLE),
+ DP_STR(REMOTE_DPCD_READ),
+ DP_STR(REMOTE_DPCD_WRITE),
+ DP_STR(REMOTE_I2C_READ),
+ DP_STR(REMOTE_I2C_WRITE),
+ DP_STR(POWER_UP_PHY),
+ DP_STR(POWER_DOWN_PHY),
+ DP_STR(SINK_EVENT_NOTIFY),
+ DP_STR(QUERY_STREAM_ENC_STATUS),
+ };
+
+ if (req_type >= ARRAY_SIZE(req_type_str) ||
+ !req_type_str[req_type])
+ return "unknown";
+
+ return req_type_str[req_type];
+}
+
+#undef DP_STR
+#define DP_STR(x) [DP_NAK_ ## x] = #x
+
+static const char *drm_dp_mst_nak_reason_str(u8 nak_reason)
+{
+ static const char * const nak_reason_str[] = {
+ DP_STR(WRITE_FAILURE),
+ DP_STR(INVALID_READ),
+ DP_STR(CRC_FAILURE),
+ DP_STR(BAD_PARAM),
+ DP_STR(DEFER),
+ DP_STR(LINK_FAILURE),
+ DP_STR(NO_RESOURCES),
+ DP_STR(DPCD_FAIL),
+ DP_STR(I2C_NAK),
+ DP_STR(ALLOCATE_FAIL),
+ };
+
+ if (nak_reason >= ARRAY_SIZE(nak_reason_str) ||
+ !nak_reason_str[nak_reason])
+ return "unknown";
+
+ return nak_reason_str[nak_reason];
+}
+
+#undef DP_STR
+
/* sideband msg handling */
static u8 drm_dp_msg_header_crc4(const uint8_t *data, size_t num_nibbles)
{
@@ -594,7 +652,8 @@ static bool drm_dp_sideband_parse_reply(struct
drm_dp_sideband_msg_rx *raw,
case DP_POWER_UP_PHY:
return drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
default:
- DRM_ERROR("Got unknown reply 0x%02x\n", msg->req_type);
+ DRM_ERROR("Got unknown reply 0x%02x (%s)\n", msg->req_type,
+ drm_dp_mst_req_type_str(msg->req_type));
return false;
}
}
@@ -661,7 +720,8 @@ static bool drm_dp_sideband_parse_req(struct
drm_dp_sideband_msg_rx *raw,
case DP_RESOURCE_STATUS_NOTIFY:
return drm_dp_sideband_parse_resource_status_notify(raw, msg);
default:
- DRM_ERROR("Got unknown request 0x%02x\n", msg->req_type);
+ DRM_ERROR("Got unknown request 0x%02x (%s)\n", msg->req_type,
+ drm_dp_mst_req_type_str(msg->req_type));
return false;
}
}
@@ -2747,7 +2807,12 @@ static int drm_dp_mst_handle_down_rep(struct
drm_dp_mst_topology_mgr *mgr)
drm_dp_sideband_parse_reply(>down_rep_recv, >reply);
if (txmsg->reply.reply_type == DP_SIDEBAND_REPLY_NAK)
- DRM_DEBUG_KMS("Got NAK reply: req 0x%02x, reason
0x%02x, nak data 0x%02x\n", txmsg->reply.req_type, txmsg->reply.u.nak.reason,
txmsg->reply.u.nak.nak_data);
+ DRM_DEBUG_KMS("Got NAK reply: req 0x%02x (%s), reason
0x%02x (%s), nak data 0x%02x\n",
+ txmsg->reply.req_type,
+
drm_dp_mst_req_type_str(txmsg->reply.req_type),
+ txmsg->reply.u.nak.reason,
+
drm_dp_mst_nak_reason_str(txmsg->reply.u.nak.reason),
+ txmsg->reply.u.nak.nak_data);
memset(>down_rep_recv, 0, sizeof(struct
drm_dp_sideband_msg_rx));
drm_dp_mst_topology_put_mstb(mstb);
diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index a62d3750663a..5db7fb8c8b50 100644
---
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/selftests: Apply a subtest filter (rev2)
== Series Details ==
Series: drm/i915/selftests: Apply a subtest filter (rev2)
URL : https://patchwork.freedesktop.org/series/55576/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464 -> Patchwork_12006
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55576/revisions/2/mbox/
Known issues
Here are the changes found in Patchwork_12006 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@i915_selftest@live_hangcheck:
- fi-skl-iommu: PASS -> INCOMPLETE [fdo#108602] / [fdo#108744]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104108]: https://bugs.freedesktop.org/show_bug.cgi?id=104108
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108602]: https://bugs.freedesktop.org/show_bug.cgi?id=108602
[fdo#108744]: https://bugs.freedesktop.org/show_bug.cgi?id=108744
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (45 -> 42)
--
Additional (1): fi-skl-6770hq
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5464 -> Patchwork_12006
CI_DRM_5464: af90b519a670a3aec89045d9fcca8f2d174adeda @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12006: 7f8a9a520a95c1a5db71698787756cdeab8f78c6 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
7f8a9a520a95 drm/i915/selftests: Apply a subtest filter
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12006/
___
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: Avoid divide by zero
== Series Details ==
Series: drm/i915: Avoid divide by zero
URL : https://patchwork.freedesktop.org/series/55560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464_full -> Patchwork_12005_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12005_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@kms_available_modes_crc@available_mode_test_crc:
- shard-apl: PASS -> FAIL [fdo#106641]
- shard-glk: PASS -> FAIL [fdo#106641]
* igt@kms_busy@extended-pageflip-hang-newfb-render-a:
- shard-glk: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-a:
- shard-snb: PASS -> DMESG-WARN [fdo#107956]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-256x85-sliding:
- shard-glk: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-onscreen:
- shard-apl: PASS -> FAIL [fdo#103232] +2
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: PASS -> FAIL [fdo#105767]
* igt@kms_cursor_legacy@cursor-vs-flip-toggle:
- shard-hsw: PASS -> FAIL [fdo#103355]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-cur-indfb-draw-blt:
- shard-apl: PASS -> FAIL [fdo#103167]
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-wc:
- shard-glk: PASS -> FAIL [fdo#103167] +1
* igt@kms_plane_alpha_blend@pipe-a-alpha-opaque-fb:
- shard-glk: PASS -> FAIL [fdo#108145]
* igt@kms_plane_multiple@atomic-pipe-c-tiling-x:
- shard-glk: PASS -> FAIL [fdo#103166] +1
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: PASS -> FAIL [fdo#103166] +1
Possible fixes
* igt@gem_tiled_swapping@non-threaded:
- shard-apl: INCOMPLETE [fdo#103927] -> PASS
* igt@kms_busy@extended-modeset-hang-newfb-with-reset-render-a:
- shard-snb: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_busy@extended-pageflip-modeset-hang-oldfb-render-b:
- shard-apl: DMESG-WARN [fdo#107956] -> PASS
* igt@kms_cursor_crc@cursor-256x256-dpms:
- shard-glk: FAIL [fdo#103232] -> PASS +3
* igt@kms_cursor_legacy@cursora-vs-flipa-atomic-transitions-varying-size:
- shard-snb: {SKIP} [fdo#109271] -> PASS +4
* igt@kms_cursor_legacy@pipe-c-torture-move:
- shard-hsw: DMESG-WARN [fdo#107122] -> PASS
* igt@kms_flip@flip-vs-expired-vblank:
- shard-glk: FAIL [fdo#105363] -> PASS
* igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-mmap-gtt:
- shard-apl: FAIL [fdo#103167] -> PASS +1
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-move:
- shard-glk: FAIL [fdo#103167] -> PASS
* igt@kms_plane@pixel-format-pipe-a-planes-source-clamping:
- shard-apl: FAIL [fdo#108948] -> PASS
* igt@kms_plane_multiple@atomic-pipe-b-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS +2
* igt@kms_plane_multiple@atomic-pipe-c-tiling-y:
- shard-glk: FAIL [fdo#103166] -> PASS +1
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-apl: DMESG-FAIL [fdo#108950] -> PASS
* igt@kms_setmode@basic:
- shard-glk: FAIL [fdo#99912] -> PASS
* igt@prime_vgem@basic-fence-flip:
- shard-kbl: FAIL [fdo#104008] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103355]: https://bugs.freedesktop.org/show_bug.cgi?id=103355
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#105767]: https://bugs.freedesktop.org/show_bug.cgi?id=105767
[fdo#106641]: https://bugs.freedesktop.org/show_bug.cgi?id=106641
[fdo#107122]: https://bugs.freedesktop.org/show_bug.cgi?id=107122
[fdo#107956]: https://bugs.freedesktop.org/show_bug.cgi?id=107956
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#108948]: https://bugs.freedesktop.org/show_bug.cgi?id=108948
[fdo#108950]: https://bugs.freedesktop.org/show_bug.cgi?id=108950
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#99912]:
[Intel-gfx] [PATCH] drm/i915/selftests: Apply a subtest filter
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably subsubtests!). For simplicity, allow the user to provide a
command line parameter such as
i915.st_filter=i915_timeline_mock_selftests/igt_sync
to restrict ourselves to only running on subtest. The exact name to use
is given during a normal run, highlighted as an error if it failed,
debug otherwise. The test group is optional, and then all subtests are
compared for an exact match with the filter (most subtests have unique
names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
then all tests but those that match will be run. More than one match can
be supplied separated by a comma, e.g.
i915.st_filter=igt_vma_create,igt_vma_pin1
to only run those specified, or
i915.st_filter=!igt_vma_create,!igt_vma_pin1
to run all but those named. Mixing a blacklist and whitelist will only
execute those subtests matching the whitelist so long as they are
previously excluded in the blacklist.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
Fixup the no filter fail.
-Chris
---
drivers/gpu/drm/i915/i915_selftest.h | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c| 47 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index a73472dd12fd..207e21b478f2 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -31,6 +31,7 @@ struct i915_selftest {
unsigned long timeout_jiffies;
unsigned int timeout_ms;
unsigned int random_seed;
+ char *filter;
int mock;
int live;
};
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 86c54ea37f48..050af81b8028 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -197,6 +197,49 @@ int i915_live_selftests(struct pci_dev *pdev)
return 0;
}
+static bool apply_subtest_filter(const char *caller, const char *name)
+{
+ char *str, *filter, *tok;
+ bool result = true;
+
+ str = kstrdup(i915_selftest.filter, GFP_KERNEL);
+ if (!str)
+ return true;
+
+ for (filter = str; (tok = strsep(, ","));) {
+ bool allow = true;
+ char *sl;
+
+ if (*tok == '!') {
+ allow = false;
+ tok++;
+ }
+
+ sl = strchr(tok, '/');
+ if (sl) {
+ *sl++ = '\0';
+ if (strcmp(tok, caller)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+ tok = sl;
+ }
+
+ if (strcmp(tok, name)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+
+ result = allow;
+ break;
+ }
+
+ kfree(str);
+ return result;
+}
+
int __i915_subtests(const char *caller,
const struct i915_subtest *st,
unsigned int count,
@@ -209,6 +252,9 @@ int __i915_subtests(const char *caller,
if (signal_pending(current))
return -EINTR;
+ if (!apply_subtest_filter(caller, st->name))
+ continue;
+
pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
GEM_TRACE("Running %s/%s\n", caller, st->name);
@@ -244,6 +290,7 @@ bool __igt_timeout(unsigned long timeout, const char *fmt,
...)
module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
+module_param_named(st_filter, i915_selftest.filter, charp, 0400);
module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock
hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then
exit module)");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, Jan 22, 2019 at 08:09:40PM +0200, Jani Nikula wrote: > On Tue, 22 Jan 2019, Ville Syrjälä wrote: > > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: > >> Avoid divide by zero warning on static analysis. > >> > >> Signed-off-by: Mika Kahola > >> --- > >> drivers/gpu/drm/i915/intel_pm.c | 6 -- > >> 1 file changed, 4 insertions(+), 2 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_pm.c > >> b/drivers/gpu/drm/i915/intel_pm.c > >> index 8b63afa3a221..6a8e8b3f44c2 100644 > >> --- a/drivers/gpu/drm/i915/intel_pm.c > >> +++ b/drivers/gpu/drm/i915/intel_pm.c > >> @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > >> drm_i915_private *dev_priv, > >>pipe_width = hdisplay; > >>} > >> > >> - alloc->start = ddb_size * width_before_pipe / total_width; > >> - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; > >> + alloc->start = total_width == 0 ? > >> + 0 : ddb_size * width_before_pipe / total_width; > >> + alloc->end = total_width == 0 ? > >> + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; > > > > Can't happen. > > Yeah, it's about stfu the checker... Feels like the tip of an iceberg. How many more uglies are we going to have to add? > > > > >> } > >> > >> static unsigned int skl_cursor_allocation(int num_active) > >> -- > >> 2.17.1 > >> > >> ___ > >> Intel-gfx mailing list > >> Intel-gfx@lists.freedesktop.org > >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx > > -- > Jani Nikula, Intel Open Source Graphics Center -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t] i915/selftest: Allow filtering of individual subtests
Take an environment variable, SELFTESTS=foo,bar, and pass that along to
the kernel (as i915.st_filter=foo,bar) to provide fine grained test
selection. This can be either as an exact match to select only that
test, or to exclude only test. For example,
SELFTESTS=igt_vma_create,igt_vma_pin1 i915_selftest --run mock_vma
SELFTESTS=!igt_vma_create i915_selftest --run mock_vma
Signed-off-by: Chris Wilson
---
tests/i915/selftest.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/tests/i915/selftest.c b/tests/i915/selftest.c
index 80e515c61..b8d7f0af1 100644
--- a/tests/i915/selftest.c
+++ b/tests/i915/selftest.c
@@ -28,10 +28,16 @@ IGT_TEST_DESCRIPTION("Basic unit tests for i915.ko");
igt_main
{
- igt_kselftests("i915",
- "mock_selftests=-1 disable_display=1",
- NULL, "mock");
- igt_kselftests("i915",
- "live_selftests=-1 disable_display=1",
- "live_selftests", "live");
+ const char *env = getenv("SELFTESTS");
+ char opts[1024];
+
+ igt_assert(snprintf(opts, sizeof(opts),
+ "mock_selftests=-1 disable_display=1 st_filter=%s",
+ env) < sizeof(opts));
+ igt_kselftests("i915", opts, NULL, "mock");
+
+ igt_assert(snprintf(opts, sizeof(opts),
+ "live_selftests=-1 disable_display=1 st_filter=%s",
+ env) < sizeof(opts));
+ igt_kselftests("i915", opts, "live_selftests", "live");
}
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/selftests: Apply a subtest filter
In bringup on simulated HW even rudimentary tests are slow, and so many
may fail that we want to be able to filter out the noise to focus on the
specific problem. Even just the tests groups provided for igt is not
specific enough, and we would like to isolate one particular subtest
(and probably subsubtests!). For simplicity, allow the user to provide a
command line parameter such as
i915.st_filter=i915_timeline_mock_selftests/igt_sync
to restrict ourselves to only running on subtest. The exact name to use
is given during a normal run, highlighted as an error if it failed,
debug otherwise. The test group is optional, and then all subtests are
compared for an exact match with the filter (most subtests have unique
names). The filter can be negated, e.g. i915.st_filter=!igt_sync and
then all tests but those that match will be run. More than one match can
be supplied separated by a comma, e.g.
i915.st_filter=igt_vma_create,igt_vma_pin1
to only run those specified, or
i915.st_filter=!igt_vma_create,!igt_vma_pin1
to run all but those named. Mixing a blacklist and whitelist will only
execute those subtests matching the whitelist so long as they are
previously blacklisted.
Signed-off-by: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_selftest.h | 1 +
.../gpu/drm/i915/selftests/i915_selftest.c| 47 +++
2 files changed, 48 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_selftest.h
b/drivers/gpu/drm/i915/i915_selftest.h
index a73472dd12fd..207e21b478f2 100644
--- a/drivers/gpu/drm/i915/i915_selftest.h
+++ b/drivers/gpu/drm/i915/i915_selftest.h
@@ -31,6 +31,7 @@ struct i915_selftest {
unsigned long timeout_jiffies;
unsigned int timeout_ms;
unsigned int random_seed;
+ char *filter;
int mock;
int live;
};
diff --git a/drivers/gpu/drm/i915/selftests/i915_selftest.c
b/drivers/gpu/drm/i915/selftests/i915_selftest.c
index 86c54ea37f48..b77dbf3f0690 100644
--- a/drivers/gpu/drm/i915/selftests/i915_selftest.c
+++ b/drivers/gpu/drm/i915/selftests/i915_selftest.c
@@ -197,6 +197,49 @@ int i915_live_selftests(struct pci_dev *pdev)
return 0;
}
+static bool apply_subtest_filter(const char *caller, const char *name)
+{
+ char *str, *filter, *tok;
+ bool result = true;
+
+ str = kstrdup(i915_selftest.filter, GFP_KERNEL);
+ if (!str)
+ return false;
+
+ for (filter = str; (tok = strsep(, ","));) {
+ bool allow = true;
+ char *sl;
+
+ if (*tok == '!') {
+ allow = false;
+ tok++;
+ }
+
+ sl = strchr(tok, '/');
+ if (sl) {
+ *sl++ = '\0';
+ if (strcmp(tok, caller)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+ tok = sl;
+ }
+
+ if (strcmp(tok, name)) {
+ if (allow)
+ result = false;
+ continue;
+ }
+
+ result = allow;
+ break;
+ }
+
+ kfree(str);
+ return result;
+}
+
int __i915_subtests(const char *caller,
const struct i915_subtest *st,
unsigned int count,
@@ -209,6 +252,9 @@ int __i915_subtests(const char *caller,
if (signal_pending(current))
return -EINTR;
+ if (!apply_subtest_filter(caller, st->name))
+ continue;
+
pr_debug(DRIVER_NAME ": Running %s/%s\n", caller, st->name);
GEM_TRACE("Running %s/%s\n", caller, st->name);
@@ -244,6 +290,7 @@ bool __igt_timeout(unsigned long timeout, const char *fmt,
...)
module_param_named(st_random_seed, i915_selftest.random_seed, uint, 0400);
module_param_named(st_timeout, i915_selftest.timeout_ms, uint, 0400);
+module_param_named(st_filter, i915_selftest.filter, charp, 0400);
module_param_named_unsafe(mock_selftests, i915_selftest.mock, int, 0400);
MODULE_PARM_DESC(mock_selftests, "Run selftests before loading, using mock
hardware (0:disabled [default], 1:run tests then load driver, -1:run tests then
exit module)");
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 22 Jan 2019, Ville Syrjälä wrote: > On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: >> Avoid divide by zero warning on static analysis. >> >> Signed-off-by: Mika Kahola >> --- >> drivers/gpu/drm/i915/intel_pm.c | 6 -- >> 1 file changed, 4 insertions(+), 2 deletions(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_pm.c >> b/drivers/gpu/drm/i915/intel_pm.c >> index 8b63afa3a221..6a8e8b3f44c2 100644 >> --- a/drivers/gpu/drm/i915/intel_pm.c >> +++ b/drivers/gpu/drm/i915/intel_pm.c >> @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct >> drm_i915_private *dev_priv, >> pipe_width = hdisplay; >> } >> >> -alloc->start = ddb_size * width_before_pipe / total_width; >> -alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; >> +alloc->start = total_width == 0 ? >> +0 : ddb_size * width_before_pipe / total_width; >> +alloc->end = total_width == 0 ? >> +0 : ddb_size * (width_before_pipe + pipe_width) / total_width; > > Can't happen. Yeah, it's about stfu the checker... > >> } >> >> static unsigned int skl_cursor_allocation(int num_active) >> -- >> 2.17.1 >> >> ___ >> Intel-gfx mailing list >> Intel-gfx@lists.freedesktop.org >> https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
On 22/01/2019 16:25, Joonas Lahtinen wrote: Quoting Lionel Landwerlin (2019-01-16 17:36:22) With the currently available parameters for the i915-perf stream, there are still situations that are not well covered : If an application opens the stream with polling disable or at very low frequency and OA interrupt enabled, no data will be available even though somewhere between nothing and half of the OA buffer worth of data might have landed in memory. To solve this issue we have a new flush ioctl on the perf stream that forces the i915-perf driver to look at the state of the buffer when called and makes any data available through both poll() & read() type syscalls. Signed-off-by: Lionel Landwerlin Link to userspace changes? Regards, Joonas Trying to get them uploaded to a branch on https://github.com/intel/metrics-discovery I'll let you know when it's available. -Lionel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/5] drm/i915: Enable fastset for non-boot modesets.
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> Now that our state comparison functions are pretty complete, we should
> enable fastset by default when a modeset can be avoided. Even if we're
> not completely certain about the inherited state, we can be certain
> after the first modeset that our sw state matches the hw state.
>
> There is one testcase explicitly testing fastset,
> kms_panel_fitting.atomic-fastset but other testcases do so indirectly
> because most tests don't clean up the display during exit, or otherwise
> indirectly preserve mode by doing igt_display_reset or inheriting during
> init.
>
> Signed-off-by: Maarten Lankhorst
> Reviewed-by: Hans de Goede
> Cc: Daniel Vetter
> ---
> drivers/gpu/drm/i915/intel_display.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 696e6f5680df..f8cbdd50fa38 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11671,6 +11671,11 @@ intel_pipe_config_compare(struct drm_i915_private
> *dev_priv,
> (current_config->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED) &&
> !(pipe_config->base.mode.private_flags &
> I915_MODE_FLAG_INHERITED);
>
> + if (fixup_inherited && !i915_modparams.fastboot) {
> + drm_dbg(DRM_UT_KMS, "initial modeset and fastboot not set\n");
DRM_DEBUG_KMS() please.
> + ret = false;
> + }
> +
> #define PIPE_CONF_CHECK_X(name) do { \
> if (current_config->name != pipe_config->name) { \
> pipe_config_err(adjust, __stringify(name), \
> @@ -12694,8 +12699,7 @@ static int intel_atomic_check(struct drm_device *dev,
> return ret;
> }
>
> - if (i915_modparams.fastboot &&
> - intel_pipe_config_compare(dev_priv,
> + if (intel_pipe_config_compare(dev_priv,
> to_intel_crtc_state(old_crtc_state),
> pipe_config, true)) {
> crtc_state->mode_changed = false;
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/5] drm/i915/backlight: Fix backlight takeover on LPT, v3.
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> On lynxpoint the bios sometimes sets up the backlight using the CPU
> display, but the driver expects using the PWM PCH override register.
>
> Read the value from the CPU register, then convert it to the other
> units by converting from the old duty cycle, to freq, to the new units.
>
> This value is then programmed in the override register, after which
> we set the override and disable the CPU display control. This allows
> us to switch the source without flickering, and make the backlight
> controls work in the driver.
>
> Changes since v1:
> - Read BLC_PWM_CPU_CTL2 to cpu_ctl2.
> - Clean up cpu_mode if slightly.
> - Always disable BLM_PWM_ENABLE in cpu_ctl2.
> Changes since v2:
> - Simplify cpu_mode handling (Jani)
>
> Signed-off-by: Maarten Lankhorst
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=108225
> Cc: Basil Eric Rabi
> Cc: Hans de Goede
> Cc: Tolga Cakir
> Cc: Ville Syrjälä
> Tested-by: Tolga Cakir
> Cc: Jani Nikula
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/intel_panel.c | 26 ++
> 1 file changed, 22 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index f71b33cf1c97..1c9ef54d58fe 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1493,8 +1493,8 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
> {
> struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
> struct intel_panel *panel = >panel;
> - u32 pch_ctl1, pch_ctl2, val;
> - bool alt;
> + u32 cpu_ctl2, pch_ctl1, pch_ctl2, val;
> + bool alt, cpu_mode;
>
> if (HAS_PCH_LPT(dev_priv))
> alt = I915_READ(SOUTH_CHICKEN2) & LPT_PWM_GRANULARITY;
> @@ -1508,6 +1508,8 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
> pch_ctl2 = I915_READ(BLC_PWM_PCH_CTL2);
> panel->backlight.max = pch_ctl2 >> 16;
>
> + cpu_ctl2 = I915_READ(BLC_PWM_CPU_CTL2);
> +
> if (!panel->backlight.max)
> panel->backlight.max = get_backlight_max_vbt(connector);
>
> @@ -1516,12 +1518,28 @@ static int lpt_setup_backlight(struct intel_connector
> *connector, enum pipe unus
>
> panel->backlight.min = get_backlight_min_vbt(connector);
>
> - val = lpt_get_backlight(connector);
> + panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> +
> + cpu_mode = panel->backlight.enabled && HAS_PCH_LPT(dev_priv) &&
> +!(pch_ctl1 & BLM_PCH_OVERRIDE_ENABLE) &&
> +(cpu_ctl2 & BLM_PWM_ENABLE);
> + if (cpu_mode)
> + val = pch_get_backlight(connector);
> + else
> + val = lpt_get_backlight(connector);
> val = intel_panel_compute_brightness(connector, val);
> panel->backlight.level = clamp(val, panel->backlight.min,
> panel->backlight.max);
>
> - panel->backlight.enabled = pch_ctl1 & BLM_PCH_PWM_ENABLE;
> + if (cpu_mode) {
> + DRM_DEBUG_KMS("CPU backlight register was enabled, switching to
> PCH override\n");
> +
> + /* Write converted CPU PWM value to PCH override register */
> + lpt_set_backlight(connector->base.state,
> panel->backlight.level);
> + I915_WRITE(BLC_PWM_PCH_CTL1, pch_ctl1 |
> BLM_PCH_OVERRIDE_ENABLE);
> +
> + I915_WRITE(BLC_PWM_CPU_CTL2, cpu_ctl2 & ~BLM_PWM_ENABLE);
> + }
>
> return 0;
> }
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915/backlight: Restore backlight on resume, v3.
On Tue, 08 Jan 2019, Maarten Lankhorst
wrote:
> Restore our saved values for backlight. This way even with fastset on
> S4 resume we will correctly restore the backlight to the active values.
>
> Changes since v1:
> - Call enable_backlight() when backlight.level is set. On suspend
> backlight.enabled is always cleared, this makes it not a good
> indicator. Also check for crtc->state->active.
> Changes since v2:
> - Use the new update_pipe() callback to run this on resume as well.
>
> Signed-off-by: Maarten Lankhorst
> Cc: Tolga Cakir
> Cc: Basil Eric Rabi
> Cc: Hans de Goede
> Cc: Ville Syrjälä
> Reported-by: Ville Syrjälä
> Signed-off-by: Maarten Lankhorst
Reviewed-by: Jani Nikula
> ---
> drivers/gpu/drm/i915/icl_dsi.c | 1 +
> drivers/gpu/drm/i915/intel_ddi.c | 2 ++
> drivers/gpu/drm/i915/intel_dp.c| 1 +
> drivers/gpu/drm/i915/intel_drv.h | 3 ++
> drivers/gpu/drm/i915/intel_lvds.c | 1 +
> drivers/gpu/drm/i915/intel_panel.c | 49 +++---
> drivers/gpu/drm/i915/vlv_dsi.c | 1 +
> 7 files changed, 47 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/icl_dsi.c b/drivers/gpu/drm/i915/icl_dsi.c
> index 4dd793b78996..3f92881600c5 100644
> --- a/drivers/gpu/drm/i915/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/icl_dsi.c
> @@ -1378,6 +1378,7 @@ void icl_dsi_init(struct drm_i915_private *dev_priv)
> encoder->disable = gen11_dsi_disable;
> encoder->port = port;
> encoder->get_config = gen11_dsi_get_config;
> + encoder->update_pipe = intel_panel_update_backlight;
> encoder->compute_config = gen11_dsi_compute_config;
> encoder->get_hw_state = gen11_dsi_get_hw_state;
> encoder->type = INTEL_OUTPUT_DSI;
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 2d6ed990a232..d32865dc44e8 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -3548,6 +3548,8 @@ static void intel_ddi_update_pipe_dp(struct
> intel_encoder *encoder,
>
> intel_psr_enable(intel_dp, crtc_state);
> intel_edp_drrs_enable(intel_dp, crtc_state);
> +
> + intel_panel_update_backlight(encoder, crtc_state, conn_state);
> }
>
> static void intel_ddi_update_pipe(struct intel_encoder *encoder,
> diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
> index 62fd11540942..0cbacdc70b07 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6981,6 +6981,7 @@ bool intel_dp_init(struct drm_i915_private *dev_priv,
> intel_encoder->compute_config = intel_dp_compute_config;
> intel_encoder->get_hw_state = intel_dp_get_hw_state;
> intel_encoder->get_config = intel_dp_get_config;
> + intel_encoder->update_pipe = intel_panel_update_backlight;
> intel_encoder->suspend = intel_dp_encoder_suspend;
> if (IS_CHERRYVIEW(dev_priv)) {
> intel_encoder->pre_pll_enable = chv_dp_pre_pll_enable;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 1a11c2beb7f3..0a6fb42e2086 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -2023,6 +2023,9 @@ int intel_panel_setup_backlight(struct drm_connector
> *connector,
> enum pipe pipe);
> void intel_panel_enable_backlight(const struct intel_crtc_state *crtc_state,
> const struct drm_connector_state *conn_state);
> +void intel_panel_update_backlight(struct intel_encoder *encoder,
> + const struct intel_crtc_state *crtc_state,
> + const struct drm_connector_state *conn_state);
> void intel_panel_disable_backlight(const struct drm_connector_state
> *old_conn_state);
> extern struct drm_display_mode *intel_find_panel_downclock(
> struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_lvds.c
> b/drivers/gpu/drm/i915/intel_lvds.c
> index b85e195f7c8a..189693b4c5e8 100644
> --- a/drivers/gpu/drm/i915/intel_lvds.c
> +++ b/drivers/gpu/drm/i915/intel_lvds.c
> @@ -909,6 +909,7 @@ void intel_lvds_init(struct drm_i915_private *dev_priv)
> }
> intel_encoder->get_hw_state = intel_lvds_get_hw_state;
> intel_encoder->get_config = intel_lvds_get_config;
> + intel_encoder->update_pipe = intel_panel_update_backlight;
> intel_connector->get_hw_state = intel_connector_get_hw_state;
>
> intel_connector_attach_encoder(intel_connector, intel_encoder);
> diff --git a/drivers/gpu/drm/i915/intel_panel.c
> b/drivers/gpu/drm/i915/intel_panel.c
> index ee3e0842d542..f71b33cf1c97 100644
> --- a/drivers/gpu/drm/i915/intel_panel.c
> +++ b/drivers/gpu/drm/i915/intel_panel.c
> @@ -1087,20 +1087,11 @@ static void pwm_enable_backlight(const struct
> intel_crtc_state *crtc_state,
> intel_panel_actually_set_backlight(conn_state,
Re: [Intel-gfx] [PATCH 13/15] drm/i915/tv: Generate better pipe timings for TV encoder
On Tue, Jan 22, 2019 at 07:22:24PM +0200, Imre Deak wrote:
> On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> > From: Ville Syrjälä
> >
> > To make vblank timestamps work better with the TV encoder let's
> > scale the pipe timings such that the relationship between the
> > TV active and TV blanking periods is mirrored in the
> > corresponding pipe timings.
> >
> > Note that in reality the pipe runs at a faster speed during the
> > TV vblank, and correspondigly there are periods when the pipe
> > is enitrely stopped. We pretend that this isn't the case and
> > as such we incur some error in the vblank timestamps during
> > the TV vblank. Further explanation of the issues in a big
> > comment in the code.
> >
> > This makes the vblank timestamps good enough to make
> > i965gm (which doesn't have a working frame counter with
> > the TV encoder) report correct frame numbers. Previously
> > you could get all kinds of nonsense which resulted in
> > eg. glxgears reporting that it's running at twice the
> > actual framerate in most cases.
> >
> > Signed-off-by: Ville Syrjälä
> > ---
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > drivers/gpu/drm/i915/intel_tv.c | 322 +++-
> > 2 files changed, 278 insertions(+), 45 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index fe4b913e46ac..10813ae7bee7 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -4848,6 +4848,7 @@ enum {
> > # define TV_OVERSAMPLE_NONE(2 << 18)
> > /* Selects 8x oversampling */
> > # define TV_OVERSAMPLE_8X (3 << 18)
> > +# define TV_OVERSAMPLE_MASK(3 << 18)
> > /* Selects progressive mode rather than interlaced */
> > # define TV_PROGRESSIVE(1 << 17)
> > /* Sets the colorburst to PAL mode. Required for non-M PAL modes. */
> > diff --git a/drivers/gpu/drm/i915/intel_tv.c
> > b/drivers/gpu/drm/i915/intel_tv.c
> > index 216525dd144a..75126fce655d 100644
> > --- a/drivers/gpu/drm/i915/intel_tv.c
> > +++ b/drivers/gpu/drm/i915/intel_tv.c
> > @@ -340,7 +340,6 @@ struct tv_mode {
> > const struct video_levels *composite_levels, *svideo_levels;
> > const struct color_conversion *composite_color, *svideo_color;
> > const u32 *filter_table;
> > - u16 max_srcw;
> > };
> >
> >
> > @@ -729,7 +728,6 @@ static const struct tv_mode tv_modes[] = {
> > .burst_ena = false,
> >
> > .filter_table = filter_table,
> > - .max_srcw = 800
> > },
> > {
> > .name = "1080i@50Hz",
> > @@ -947,13 +945,183 @@ intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> > return 2 * (tv_mode->nbr_end + 1);
> > }
> >
> > +static void
> > +intel_tv_mode_to_mode(struct drm_display_mode *mode,
> > + const struct tv_mode *tv_mode)
> > +{
> > + mode->clock = tv_mode->clock /
> > + (tv_mode->oversample >> !tv_mode->progressive);
> > +
> > + /*
> > +* tv_mode horizontal timings:
> > +*
> > +* hsync_end
> > +*| hblank_end
> > +*|| hblank_start
> > +*|| | htotal
> > +*| ___|
> > +* / \___
> > +* \__/\
> > +*/
> > + mode->hdisplay =
> > + tv_mode->hblank_start - tv_mode->hblank_end;
> > + mode->hsync_start = mode->hdisplay +
> > + tv_mode->htotal - tv_mode->hblank_start;
> > + mode->hsync_end = mode->hsync_start +
> > + tv_mode->hsync_end;
> > + mode->htotal = tv_mode->htotal + 1;
> > +
> > + /*
> > +* tv_mode vertical timings:
> > +*
> > +* vsync_start
> > +*| vsync_end
> > +*| | vi_end nbr_end
> > +*| || |
> > +*| | ___
> > +* \__/ \
> > +*\__/
> > +*/
> > + mode->vdisplay = intel_tv_mode_vdisplay(tv_mode);
> > + if (tv_mode->progressive) {
> > + mode->vsync_start = mode->vdisplay +
> > + tv_mode->vsync_start_f1 + 1;
> > + mode->vsync_end = mode->vsync_start +
> > + tv_mode->vsync_len;
> > + mode->vtotal = mode->vdisplay +
> > + tv_mode->vi_end_f1 + 1;
> > + } else {
> > + mode->vsync_start = mode->vdisplay +
> > + tv_mode->vsync_start_f1 + 1 +
> > + tv_mode->vsync_start_f2 + 1;
> > + mode->vsync_end = mode->vsync_start +
> > + 2 * tv_mode->vsync_len;
> > + mode->vtotal = mode->vdisplay +
> > + tv_mode->vi_end_f1 + 1 +
> > + tv_mode->vi_end_f2 + 1;
> > + }
> > +
> > + /* TV has it's own notion of sync and other mode flags, so clear them.
> > */
> > + mode->flags = 0;
> > +
> > + mode->vrefresh = 0;
>
> Redundant line.
drm_mode_vrefresh() won't recompute the value if it's already
Re: [Intel-gfx] [PATCH 13/15] drm/i915/tv: Generate better pipe timings for TV encoder
On Mon, Nov 12, 2018 at 06:59:58PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> To make vblank timestamps work better with the TV encoder let's
> scale the pipe timings such that the relationship between the
> TV active and TV blanking periods is mirrored in the
> corresponding pipe timings.
>
> Note that in reality the pipe runs at a faster speed during the
> TV vblank, and correspondigly there are periods when the pipe
> is enitrely stopped. We pretend that this isn't the case and
> as such we incur some error in the vblank timestamps during
> the TV vblank. Further explanation of the issues in a big
> comment in the code.
>
> This makes the vblank timestamps good enough to make
> i965gm (which doesn't have a working frame counter with
> the TV encoder) report correct frame numbers. Previously
> you could get all kinds of nonsense which resulted in
> eg. glxgears reporting that it's running at twice the
> actual framerate in most cases.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> drivers/gpu/drm/i915/intel_tv.c | 322 +++-
> 2 files changed, 278 insertions(+), 45 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fe4b913e46ac..10813ae7bee7 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4848,6 +4848,7 @@ enum {
> # define TV_OVERSAMPLE_NONE (2 << 18)
> /* Selects 8x oversampling */
> # define TV_OVERSAMPLE_8X(3 << 18)
> +# define TV_OVERSAMPLE_MASK (3 << 18)
> /* Selects progressive mode rather than interlaced */
> # define TV_PROGRESSIVE (1 << 17)
> /* Sets the colorburst to PAL mode. Required for non-M PAL modes. */
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 216525dd144a..75126fce655d 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -340,7 +340,6 @@ struct tv_mode {
> const struct video_levels *composite_levels, *svideo_levels;
> const struct color_conversion *composite_color, *svideo_color;
> const u32 *filter_table;
> - u16 max_srcw;
> };
>
>
> @@ -729,7 +728,6 @@ static const struct tv_mode tv_modes[] = {
> .burst_ena = false,
>
> .filter_table = filter_table,
> - .max_srcw = 800
> },
> {
> .name = "1080i@50Hz",
> @@ -947,13 +945,183 @@ intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> return 2 * (tv_mode->nbr_end + 1);
> }
>
> +static void
> +intel_tv_mode_to_mode(struct drm_display_mode *mode,
> + const struct tv_mode *tv_mode)
> +{
> + mode->clock = tv_mode->clock /
> + (tv_mode->oversample >> !tv_mode->progressive);
> +
> + /*
> + * tv_mode horizontal timings:
> + *
> + * hsync_end
> + *| hblank_end
> + *|| hblank_start
> + *|| | htotal
> + *| ___|
> + * / \___
> + * \__/\
> + */
> + mode->hdisplay =
> + tv_mode->hblank_start - tv_mode->hblank_end;
> + mode->hsync_start = mode->hdisplay +
> + tv_mode->htotal - tv_mode->hblank_start;
> + mode->hsync_end = mode->hsync_start +
> + tv_mode->hsync_end;
> + mode->htotal = tv_mode->htotal + 1;
> +
> + /*
> + * tv_mode vertical timings:
> + *
> + * vsync_start
> + *| vsync_end
> + *| | vi_end nbr_end
> + *| || |
> + *| | ___
> + * \__/ \
> + *\__/
> + */
> + mode->vdisplay = intel_tv_mode_vdisplay(tv_mode);
> + if (tv_mode->progressive) {
> + mode->vsync_start = mode->vdisplay +
> + tv_mode->vsync_start_f1 + 1;
> + mode->vsync_end = mode->vsync_start +
> + tv_mode->vsync_len;
> + mode->vtotal = mode->vdisplay +
> + tv_mode->vi_end_f1 + 1;
> + } else {
> + mode->vsync_start = mode->vdisplay +
> + tv_mode->vsync_start_f1 + 1 +
> + tv_mode->vsync_start_f2 + 1;
> + mode->vsync_end = mode->vsync_start +
> + 2 * tv_mode->vsync_len;
> + mode->vtotal = mode->vdisplay +
> + tv_mode->vi_end_f1 + 1 +
> + tv_mode->vi_end_f2 + 1;
> + }
> +
> + /* TV has it's own notion of sync and other mode flags, so clear them.
> */
> + mode->flags = 0;
> +
> + mode->vrefresh = 0;
Redundant line.
> + mode->vrefresh = drm_mode_vrefresh(mode);
> +
> + snprintf(mode->name, sizeof(mode->name),
> + "%dx%d%c (%s)",
> + mode->hdisplay, mode->vdisplay,
> + tv_mode->progressive ? 'p' : 'i',
> +
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
== Series Details ==
Series: drm/i915: Use fb width to measure fb width instead of visible plane
width when verify NV12
URL : https://patchwork.freedesktop.org/series/8/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5463_full -> Patchwork_12004_full
Summary
---
**SUCCESS**
No regressions found.
Known issues
Here are the changes found in Patchwork_12004_full that come from known
issues:
### IGT changes ###
Issues hit
* igt@gem_exec_nop@signal-all:
- shard-apl: PASS -> INCOMPLETE [fdo#103927]
* igt@kms_color@pipe-c-ctm-max:
- shard-apl: PASS -> FAIL [fdo#108147]
* igt@kms_cursor_crc@cursor-256x256-sliding:
- shard-apl: PASS -> FAIL [fdo#103232]
* igt@kms_cursor_crc@cursor-64x64-suspend:
- shard-apl: PASS -> FAIL [fdo#103191] / [fdo#103232]
* igt@kms_flip@2x-flip-vs-expired-vblank-interruptible:
- shard-glk: PASS -> FAIL [fdo#105363]
* igt@kms_frontbuffer_tracking@fbc-2p-primscrn-spr-indfb-fullscreen:
- shard-glk: PASS -> FAIL [fdo#103167]
* igt@kms_setmode@basic:
- shard-kbl: PASS -> FAIL [fdo#99912]
Possible fixes
* igt@kms_cursor_crc@cursor-128x42-sliding:
- shard-apl: FAIL [fdo#103232] -> PASS
* igt@kms_plane_multiple@atomic-pipe-c-tiling-yf:
- shard-apl: FAIL [fdo#103166] -> PASS
* igt@kms_rotation_crc@multiplane-rotation-cropping-top:
- shard-kbl: FAIL [fdo#109381] -> PASS
* igt@kms_setmode@basic:
- shard-apl: FAIL [fdo#99912] -> PASS
* igt@perf_pmu@rc6:
- shard-kbl: {SKIP} [fdo#109271] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103166]: https://bugs.freedesktop.org/show_bug.cgi?id=103166
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#103232]: https://bugs.freedesktop.org/show_bug.cgi?id=103232
[fdo#103927]: https://bugs.freedesktop.org/show_bug.cgi?id=103927
[fdo#105363]: https://bugs.freedesktop.org/show_bug.cgi?id=105363
[fdo#108147]: https://bugs.freedesktop.org/show_bug.cgi?id=108147
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
[fdo#109381]: https://bugs.freedesktop.org/show_bug.cgi?id=109381
[fdo#99912]: https://bugs.freedesktop.org/show_bug.cgi?id=99912
Participating hosts (7 -> 5)
--
Missing(2): shard-skl shard-iclb
Build changes
-
* Linux: CI_DRM_5463 -> Patchwork_12004
CI_DRM_5463: 6bd1569466edcb2f890a374be27f0eb6780963f9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12004: d607a5109524a7bf7a9d77b1465a627a20c42021 @
git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @
git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12004/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
On Tue, Jan 22, 2019 at 04:48:26PM +0200, Joonas Lahtinen wrote: > According to our IOMMU folks there exists some desire to be able to assign > the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off > due to how the devices might be grouped in IOMMU groups. Even when you > would not be using the iGFX device. You can force the igfx device into a SI domain, or does that also trigger the iommu issues on the chipset? In any case, if iommu=on breaks these systems I want to make them work again with opt-out, even at the cost of breaking assignability. Regards, Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915: correct the pitch check for NV12 framebuffer
Hi Ville,
NV12 support for small src viewport sizes and rotation vs clipping scenarios
are added into IGT by JP.
Commit details are as follows.
commit 8614d5eb114a660c3bd7ff77eab8bed53424cd30
Author: Juha-Pekka Heikkila
Date: Fri Dec 21 15:42:33 2018 +0200
tests/kms_rotation_crc: add NV12 support for multiplane* tests
Can you please review the patch again? As suggested I have removed the if..else
check in intel_framebuffer_init().
Regards,
Raviraj
> -Original Message-
> From: Sitaram, Raviraj P
> Sent: Wednesday, December 19, 2018 1:59 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Sitaram, Raviraj P ; Hwang, Dongseong
> ; Konduru, Chandra ;
> Srinivas, Vidya ; Ville Syrjälä
> ; Juha-Pekka Heikkila
>
> Subject: [PATCH v3] drm/i915: correct the pitch check for NV12 framebuffer
>
> From: P Raviraj Sitaram
>
> framebuffer for NV12 requires the pitch to the multiplier of 4, instead of
> the width.
> This patch corrects it.
>
> For instance, a 480p video, whose width and pitch are 854 and 896
> respectively, is
> excluded for NV12 plane so far.
>
> Changes since v1:
> - Removed check for NV12 buffer dimensions since additional checks
> are done for viewport size in intel_sprite.c
>
> Signed-off-by: Dongseong Hwang
> Signed-off-by: P Raviraj Sitaram
> Cc: Chandra Konduru
> Cc: Vidya Srinivas
> Cc: Ville Syrjälä
> Cc: Juha-Pekka Heikkila
> ---
> drivers/gpu/drm/i915/intel_display.c | 8
> 1 file changed, 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 3b7094822aa9..fa349182d0da 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14597,14 +14597,6 @@ static int intel_framebuffer_init(struct
> intel_framebuffer
> *intel_fb,
>
> drm_helper_mode_fill_fb_struct(_priv->drm, fb, mode_cmd);
>
> - if (fb->format->format == DRM_FORMAT_NV12 &&
> - (fb->width < SKL_MIN_YUV_420_SRC_W ||
> - fb->height < SKL_MIN_YUV_420_SRC_H ||
> - (fb->width % 4) != 0 || (fb->height % 4) != 0)) {
> - DRM_DEBUG_KMS("src dimensions not correct for NV12\n");
> - goto err;
> - }
> -
> for (i = 0; i < fb->format->num_planes; i++) {
> u32 stride_alignment;
>
> --
> 2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 7/7] drm/i915/perf: add flushing ioctl
Quoting Lionel Landwerlin (2019-01-16 17:36:22)
> With the currently available parameters for the i915-perf stream,
> there are still situations that are not well covered :
>
> If an application opens the stream with polling disable or at very low
> frequency and OA interrupt enabled, no data will be available even
> though somewhere between nothing and half of the OA buffer worth of
> data might have landed in memory.
>
> To solve this issue we have a new flush ioctl on the perf stream that
> forces the i915-perf driver to look at the state of the buffer when
> called and makes any data available through both poll() & read() type
> syscalls.
>
> Signed-off-by: Lionel Landwerlin
Link to userspace changes?
Regards, Joonas
> ---
> drivers/gpu/drm/i915/i915_perf.c | 17 +
> include/uapi/drm/i915_drm.h | 19 +++
> 2 files changed, 36 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_perf.c
> b/drivers/gpu/drm/i915/i915_perf.c
> index da721fce2543..6c98ffa2135e 100644
> --- a/drivers/gpu/drm/i915/i915_perf.c
> +++ b/drivers/gpu/drm/i915/i915_perf.c
> @@ -2433,6 +2433,20 @@ static void i915_perf_disable_locked(struct
> i915_perf_stream *stream)
> stream->ops->disable(stream);
> }
>
> +/**
> + * i915_perf_flush_data - handle `I915_PERF_IOCTL_FLUSH_DATA` ioctl
> + * @stream: An enabled i915 perf stream
> + *
> + * The intention is to flush all the data available for reading from the OA
> + * buffer
> + */
> +static void i915_perf_flush_data(struct i915_perf_stream *stream)
> +{
> + struct drm_i915_private *dev_priv = stream->dev_priv;
> +
> + dev_priv->perf.oa.pollin = oa_buffer_check(stream->dev_priv, true);
> +}
> +
> /**
> * i915_perf_ioctl - support ioctl() usage with i915 perf stream FDs
> * @stream: An i915 perf stream
> @@ -2456,6 +2470,9 @@ static long i915_perf_ioctl_locked(struct
> i915_perf_stream *stream,
> case I915_PERF_IOCTL_DISABLE:
> i915_perf_disable_locked(stream);
> return 0;
> + case I915_PERF_IOCTL_FLUSH_DATA:
> + i915_perf_flush_data(stream);
> + return 0;
> }
>
> return -EINVAL;
> diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
> index b6db5e544a35..0f0d20080572 100644
> --- a/include/uapi/drm/i915_drm.h
> +++ b/include/uapi/drm/i915_drm.h
> @@ -1594,6 +1594,25 @@ struct drm_i915_perf_open_param {
> */
> #define I915_PERF_IOCTL_DISABLE_IO('i', 0x1)
>
> +/**
> + * Actively check the availability of data from a stream.
> + *
> + * A stream data availability can be driven by two types of events :
> + *
> + * - if enabled, the kernel's hrtimer checking the amount of available data
> + * in the OA buffer through head/tail registers.
> + *
> + * - if enabled, the OA unit's interrupt mechanism
> + *
> + * The kernel hrtimer incur a cost of running callback at fixed time
> + * intervals, while the OA interrupt might only happen rarely. In the
> + * situation where the application has disabled the kernel's hrtimer and only
> + * uses the OA interrupt to know about available data, the application can
> + * request an active check of the available OA data through this ioctl. This
> + * will make any data in the OA buffer available with either poll() or
> read().
> + */
> +#define I915_PERF_IOCTL_FLUSH_DATA _IO('i', 0x2)
> +
> /**
> * Common to all i915 perf records
> */
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, Jan 22, 2019 at 02:58:24PM +0200, Mika Kahola wrote: > Avoid divide by zero warning on static analysis. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_pm.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 8b63afa3a221..6a8e8b3f44c2 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > drm_i915_private *dev_priv, > pipe_width = hdisplay; > } > > - alloc->start = ddb_size * width_before_pipe / total_width; > - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; > + alloc->start = total_width == 0 ? > + 0 : ddb_size * width_before_pipe / total_width; > + alloc->end = total_width == 0 ? > + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; Can't happen. > } > > static unsigned int skl_cursor_allocation(int num_active) > -- > 2.17.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Ville Syrjälä Intel ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Avoid divide by zero
== Series Details ==
Series: drm/i915: Avoid divide by zero
URL : https://patchwork.freedesktop.org/series/55560/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5464 -> Patchwork_12005
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/55560/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12005 that come from known issues:
### IGT changes ###
Issues hit
* igt@amdgpu/amd_basic@cs-compute:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#108094]
* igt@amdgpu/amd_prime@amd-to-i915:
- fi-kbl-8809g: NOTRUN -> FAIL [fdo#107341]
* igt@i915_module_load@reload:
- fi-blb-e6850: NOTRUN -> INCOMPLETE [fdo#107718]
* igt@kms_busy@basic-flip-b:
- fi-gdg-551: PASS -> FAIL [fdo#103182]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
* igt@kms_flip@basic-flip-vs-dpms:
- fi-skl-6700hq: PASS -> DMESG-WARN [fdo#105998]
* igt@prime_vgem@basic-fence-flip:
- fi-ilk-650: PASS -> FAIL [fdo#104008]
Possible fixes
* igt@amdgpu/amd_basic@userptr:
- fi-kbl-8809g: DMESG-WARN [fdo#108965] -> PASS
* igt@gem_exec_suspend@basic-s3:
- fi-blb-e6850: INCOMPLETE [fdo#107718] -> PASS
* igt@kms_pipe_crc_basic@suspend-read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103182]: https://bugs.freedesktop.org/show_bug.cgi?id=103182
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#104008]: https://bugs.freedesktop.org/show_bug.cgi?id=104008
[fdo#105998]: https://bugs.freedesktop.org/show_bug.cgi?id=105998
[fdo#107341]: https://bugs.freedesktop.org/show_bug.cgi?id=107341
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718
[fdo#108094]: https://bugs.freedesktop.org/show_bug.cgi?id=108094
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#108965]: https://bugs.freedesktop.org/show_bug.cgi?id=108965
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109278]: https://bugs.freedesktop.org/show_bug.cgi?id=109278
Participating hosts (45 -> 41)
--
Additional (1): fi-skl-6770hq
Missing(5): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan fi-icl-y
Build changes
-
* Linux: CI_DRM_5464 -> Patchwork_12005
CI_DRM_5464: af90b519a670a3aec89045d9fcca8f2d174adeda @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12005: d2fc4d12140ad34b584bb8c0ca2074af9a821794 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d2fc4d12140a drm/i915: Avoid divide by zero
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12005/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 27/34] drm/i915: Remove the intel_engine_notify tracepoint
On 21/01/2019 22:21, Chris Wilson wrote:
The global seqno is defunct and so we have no meaningful indicator of
forward progress for an engine. You need to listen to the request
signaling tracepoints instead.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_irq.c | 2 --
drivers/gpu/drm/i915/i915_trace.h | 25 -
2 files changed, 27 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 5fd5080c4ccb..71d11dc2c235 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -1209,8 +1209,6 @@ static void notify_ring(struct intel_engine_cs *engine)
wake_up_process(tsk);
rcu_read_unlock();
-
- trace_intel_engine_notify(engine, wait);
}
static void vlv_c0_read(struct drm_i915_private *dev_priv,
diff --git a/drivers/gpu/drm/i915/i915_trace.h
b/drivers/gpu/drm/i915/i915_trace.h
index 33d90eca9cdd..cb5bc65d575d 100644
--- a/drivers/gpu/drm/i915/i915_trace.h
+++ b/drivers/gpu/drm/i915/i915_trace.h
@@ -750,31 +750,6 @@ trace_i915_request_out(struct i915_request *rq)
#endif
#endif
-TRACE_EVENT(intel_engine_notify,
- TP_PROTO(struct intel_engine_cs *engine, bool waiters),
- TP_ARGS(engine, waiters),
-
- TP_STRUCT__entry(
-__field(u32, dev)
-__field(u16, class)
-__field(u16, instance)
-__field(u32, seqno)
-__field(bool, waiters)
-),
-
- TP_fast_assign(
- __entry->dev = engine->i915->drm.primary->index;
- __entry->class = engine->uabi_class;
- __entry->instance = engine->instance;
- __entry->seqno = intel_engine_get_seqno(engine);
- __entry->waiters = waiters;
- ),
-
- TP_printk("dev=%u, engine=%u:%u, seqno=%u, waiters=%u",
- __entry->dev, __entry->class, __entry->instance,
- __entry->seqno, __entry->waiters)
-);
-
DEFINE_EVENT(i915_request, i915_request_retire,
TP_PROTO(struct i915_request *rq),
TP_ARGS(rq)
I cannot decide if keeping what we can would make it useful. Certainly
not for debugging intel_engine_breadcrumbs_irq.. a sequence of
intel_engine_notify(dev, class, instance) -> dma_fence_signaled would be
a very unreliable trace of what engine actually executed something. What
do you think?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 26/34] drm/i915: Identify active requests
Quoting Tvrtko Ursulin (2019-01-22 15:34:07)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > To allow requests to forgo a common execution timeline, one question we
> > need to be able to answer is "is this request running?". To track
> > whether a request has started on HW, we can emit a breadcrumb at the
> > beginning of the request and check its timeline's HWSP to see if the
> > breadcrumb has advanced past the start of this request. (This is in
> > contrast to the global timeline where we need only ask if we are on the
> > global timeline and if the timeline has advanced past the end of the
> > previous request.)
> >
> > There is still confusion from a preempted request, which has already
> > started but relinquished the HW to a high priority request. For the
> > common case, this discrepancy should be negligible. However, for
> > identification of hung requests, knowing which one was running at the
> > time of the hang will be much more important.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++
> > drivers/gpu/drm/i915/i915_request.c | 9 ++--
> > drivers/gpu/drm/i915/i915_request.h | 1 +
> > drivers/gpu/drm/i915/i915_timeline.c | 1 +
> > drivers/gpu/drm/i915/i915_timeline.h | 2 +
> > drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
> > drivers/gpu/drm/i915/intel_lrc.c | 47
> > drivers/gpu/drm/i915/intel_ringbuffer.c | 43 ++
> > drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++-
> > drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
> > 10 files changed, 86 insertions(+), 35 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > index f250109e1f66..defe7d60bb88 100644
> > --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> > @@ -1976,6 +1976,12 @@ static int eb_submit(struct i915_execbuffer *eb)
> > return err;
> > }
> >
> > + if (eb->engine->emit_init_breadcrumb) {
> > + err = eb->engine->emit_init_breadcrumb(eb->request);
> > + if (err)
> > + return err;
> > + }
> > +
> > err = eb->engine->emit_bb_start(eb->request,
> > eb->batch->node.start +
> > eb->batch_start_offset,
> > diff --git a/drivers/gpu/drm/i915/i915_request.c
> > b/drivers/gpu/drm/i915/i915_request.c
> > index bb2885f1dc1e..0a8a2a1bf55d 100644
> > --- a/drivers/gpu/drm/i915/i915_request.c
> > +++ b/drivers/gpu/drm/i915/i915_request.c
> > @@ -333,6 +333,7 @@ void i915_request_retire_upto(struct i915_request *rq)
> >
> > static u32 timeline_get_seqno(struct i915_timeline *tl)
> > {
> > + tl->seqno += tl->has_initial_breadcrumb;
> > return ++tl->seqno;
>
> return tl->seqno += 1 + tl->has_initial_breadcrumb?
>
> Not sure if it would make any difference in the code.
Identical code generation, but looks better than conditional increment
then pre-increment.
> > @@ -382,8 +383,8 @@ void __i915_request_submit(struct i915_request *request)
> > intel_engine_enable_signaling(request, false);
> > spin_unlock(>lock);
> >
> > - engine->emit_breadcrumb(request,
> > - request->ring->vaddr + request->postfix);
> > + engine->emit_fini_breadcrumb(request,
> > + request->ring->vaddr + request->postfix);
> >
> > /* Transfer from per-context onto the global per-engine timeline */
> > move_to_timeline(request, >timeline);
> > @@ -657,7 +658,7 @@ i915_request_alloc(struct intel_engine_cs *engine,
> > struct i915_gem_context *ctx)
> >* around inside i915_request_add() there is sufficient space at
> >* the beginning of the ring as well.
> >*/
> > - rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
> > + rq->reserved_space = 2 * engine->emit_fini_breadcrumb_sz *
> > sizeof(u32);
>
> Logic being fini breadcrumb is at least as big as the init one? I can't
> think of any easy asserts to verify that.
We emit engine->emit_init_breadcrumbs() normally, it's just
engine->emit_fini_breadcrumbs() that is in the reserved portion.
The factor of 2 is to waste space on wraparound.
> Also, a little bit of ring space wastage but I guess we don't care.
We don't actually waste space, we only use emit_fini_breadcrumbs_sz, we
just flush enough of the ring for 2*sz to be sure that even if we have
to wrap, there's enough room at the start of the ring for our emit.
So overzealous on flushing if the ring is full, in which case we are
throttling a millisecond earlier than is strictly required (given that
the ring already contains about a few seconds worth of batches)
The real problem here is that throttling one client, strangles them
Re: [Intel-gfx] [PATCH 26/34] drm/i915: Identify active requests
On 21/01/2019 22:21, Chris Wilson wrote:
To allow requests to forgo a common execution timeline, one question we
need to be able to answer is "is this request running?". To track
whether a request has started on HW, we can emit a breadcrumb at the
beginning of the request and check its timeline's HWSP to see if the
breadcrumb has advanced past the start of this request. (This is in
contrast to the global timeline where we need only ask if we are on the
global timeline and if the timeline has advanced past the end of the
previous request.)
There is still confusion from a preempted request, which has already
started but relinquished the HW to a high priority request. For the
common case, this discrepancy should be negligible. However, for
identification of hung requests, knowing which one was running at the
time of the hang will be much more important.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_execbuffer.c | 6 +++
drivers/gpu/drm/i915/i915_request.c | 9 ++--
drivers/gpu/drm/i915/i915_request.h | 1 +
drivers/gpu/drm/i915/i915_timeline.c | 1 +
drivers/gpu/drm/i915/i915_timeline.h | 2 +
drivers/gpu/drm/i915/intel_engine_cs.c | 4 +-
drivers/gpu/drm/i915/intel_lrc.c | 47
drivers/gpu/drm/i915/intel_ringbuffer.c | 43 ++
drivers/gpu/drm/i915/intel_ringbuffer.h | 6 ++-
drivers/gpu/drm/i915/selftests/mock_engine.c | 2 +-
10 files changed, 86 insertions(+), 35 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
index f250109e1f66..defe7d60bb88 100644
--- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
+++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
@@ -1976,6 +1976,12 @@ static int eb_submit(struct i915_execbuffer *eb)
return err;
}
+ if (eb->engine->emit_init_breadcrumb) {
+ err = eb->engine->emit_init_breadcrumb(eb->request);
+ if (err)
+ return err;
+ }
+
err = eb->engine->emit_bb_start(eb->request,
eb->batch->node.start +
eb->batch_start_offset,
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index bb2885f1dc1e..0a8a2a1bf55d 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -333,6 +333,7 @@ void i915_request_retire_upto(struct i915_request *rq)
static u32 timeline_get_seqno(struct i915_timeline *tl)
{
+ tl->seqno += tl->has_initial_breadcrumb;
return ++tl->seqno;
return tl->seqno += 1 + tl->has_initial_breadcrumb?
Not sure if it would make any difference in the code.
}
@@ -382,8 +383,8 @@ void __i915_request_submit(struct i915_request *request)
intel_engine_enable_signaling(request, false);
spin_unlock(>lock);
- engine->emit_breadcrumb(request,
- request->ring->vaddr + request->postfix);
+ engine->emit_fini_breadcrumb(request,
+request->ring->vaddr + request->postfix);
/* Transfer from per-context onto the global per-engine timeline */
move_to_timeline(request, >timeline);
@@ -657,7 +658,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
* around inside i915_request_add() there is sufficient space at
* the beginning of the ring as well.
*/
- rq->reserved_space = 2 * engine->emit_breadcrumb_sz * sizeof(u32);
+ rq->reserved_space = 2 * engine->emit_fini_breadcrumb_sz * sizeof(u32);
Logic being fini breadcrumb is at least as big as the init one? I can't
think of any easy asserts to verify that.
Also, a little bit of ring space wastage but I guess we don't care.
/*
* Record the position of the start of the request so that
@@ -908,7 +909,7 @@ void i915_request_add(struct i915_request *request)
* GPU processing the request, we never over-estimate the
* position of the ring's HEAD.
*/
- cs = intel_ring_begin(request, engine->emit_breadcrumb_sz);
+ cs = intel_ring_begin(request, engine->emit_fini_breadcrumb_sz);
GEM_BUG_ON(IS_ERR(cs));
request->postfix = intel_ring_offset(request, cs);
diff --git a/drivers/gpu/drm/i915/i915_request.h b/drivers/gpu/drm/i915/i915_request.h
index 96c586d6ff4d..340d6216791c 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -344,6 +344,7 @@ static inline bool i915_request_started(const struct
i915_request *rq)
if (i915_request_signaled(rq))
return true;
+ /* Remember: started but may have since been preempted! */
return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
}
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
Re: [Intel-gfx] [PATCH 25/34] drm/i915: Track active timelines
Quoting Tvrtko Ursulin (2019-01-22 14:56:32)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > Now that we pin timelines around use, we have a clearly defined lifetime
> > and convenient points at which we can track only the active timelines.
> > This allows us to reduce the list iteration to only consider those
> > active timelines and not all.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 2 +-
> > drivers/gpu/drm/i915/i915_gem.c | 4 +--
> > drivers/gpu/drm/i915/i915_reset.c| 2 +-
> > drivers/gpu/drm/i915/i915_timeline.c | 39 ++--
> > 4 files changed, 29 insertions(+), 18 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c00eaf2889fb..5577e0e1034f 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1977,7 +1977,7 @@ struct drm_i915_private {
> >
> > struct i915_gt_timelines {
> > struct mutex mutex; /* protects list, tainted by GPU
> > */
> > - struct list_head list;
> > + struct list_head active_list;
> >
> > /* Pack multiple timelines' seqnos into the same page
> > */
> > spinlock_t hwsp_lock;
> > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > b/drivers/gpu/drm/i915/i915_gem.c
> > index 4e0de22f0166..9c499edb4c13 100644
> > --- a/drivers/gpu/drm/i915/i915_gem.c
> > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > @@ -3246,7 +3246,7 @@ wait_for_timelines(struct drm_i915_private *i915,
> > return timeout;
> >
> > mutex_lock(>mutex);
> > - list_for_each_entry(tl, >list, link) {
> > + list_for_each_entry(tl, >active_list, link) {
> > struct i915_request *rq;
> >
> > rq = i915_gem_active_get_unlocked(>last_request);
> > @@ -3274,7 +3274,7 @@ wait_for_timelines(struct drm_i915_private *i915,
> >
> > /* restart after reacquiring the lock */
> > mutex_lock(>mutex);
> > - tl = list_entry(>list, typeof(*tl), link);
> > + tl = list_entry(>active_list, typeof(*tl), link);
> > }
> > mutex_unlock(>mutex);
> >
> > diff --git a/drivers/gpu/drm/i915/i915_reset.c
> > b/drivers/gpu/drm/i915/i915_reset.c
> > index 09edf488f711..9b9169508139 100644
> > --- a/drivers/gpu/drm/i915/i915_reset.c
> > +++ b/drivers/gpu/drm/i915/i915_reset.c
> > @@ -852,7 +852,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private
> > *i915)
> >* No more can be submitted until we reset the wedged bit.
> >*/
> > mutex_lock(>gt.timelines.mutex);
> > - list_for_each_entry(tl, >gt.timelines.list, link) {
> > + list_for_each_entry(tl, >gt.timelines.active_list, link) {
> > struct i915_request *rq;
> > long timeout;
> >
> > diff --git a/drivers/gpu/drm/i915/i915_timeline.c
> > b/drivers/gpu/drm/i915/i915_timeline.c
> > index 69ee33dfa340..007348b1b469 100644
> > --- a/drivers/gpu/drm/i915/i915_timeline.c
> > +++ b/drivers/gpu/drm/i915/i915_timeline.c
> > @@ -117,7 +117,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
> > const char *name,
> > struct i915_vma *hwsp)
> > {
> > - struct i915_gt_timelines *gt = >gt.timelines;
> > void *vaddr;
> >
> > /*
> > @@ -161,10 +160,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
> >
> > i915_syncmap_init(>sync);
> >
> > - mutex_lock(>mutex);
> > - list_add(>link, >list);
> > - mutex_unlock(>mutex);
> > -
> > return 0;
> > }
> >
> > @@ -173,7 +168,7 @@ void i915_timelines_init(struct drm_i915_private *i915)
> > struct i915_gt_timelines *gt = >gt.timelines;
> >
> > mutex_init(>mutex);
> > - INIT_LIST_HEAD(>list);
> > + INIT_LIST_HEAD(>active_list);
> >
> > spin_lock_init(>hwsp_lock);
> > INIT_LIST_HEAD(>hwsp_free_list);
> > @@ -182,6 +177,24 @@ void i915_timelines_init(struct drm_i915_private *i915)
> > i915_gem_shrinker_taints_mutex(i915, >mutex);
> > }
> >
> > +static void timeline_active(struct i915_timeline *tl)
> > +{
> > + struct i915_gt_timelines *gt = >i915->gt.timelines;
> > +
> > + mutex_lock(>mutex);
> > + list_add(>link, >active_list);
> > + mutex_unlock(>mutex);
> > +}
> > +
> > +static void timeline_inactive(struct i915_timeline *tl)
> > +{
> > + struct i915_gt_timelines *gt = >i915->gt.timelines;
> > +
> > + mutex_lock(>mutex);
> > + list_del(>link);
> > + mutex_unlock(>mutex);
> > +}
>
> Bike shedding comments only:
> Would it be better to use a verb suffix? Even though timeline_activate
> also wouldn't sound perfect. Since it is file local - activate_timeline?
> Or even just inline to pin/unpin. Unless more gets put into them later..
Haven't got any plans for more here, yet, and was
Re: [Intel-gfx] [PATCH 12/15] drm/i915/tv: Add 1080p30/50/60 TV modes
On Mon, Nov 12, 2018 at 06:59:57PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Add the missing 1080p TV modes. On gen4 all of them work just fine,
> whereas on gen3 only the 30Hz mode actually works correctly.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 90 +++--
> 1 file changed, 86 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index c39e9a5b43db..216525dd144a 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -783,6 +783,84 @@ static const struct tv_mode tv_modes[] = {
>
> .filter_table = filter_table,
> },
> +
> + {
> + .name = "1080p@30Hz",
> + .clock = 148500,
> + .refresh= 3,
> + .oversample = 2,
> + .component_only = true,
> +
> + .hsync_end = 88, .hblank_end = 235,
> + .hblank_start = 2155, .htotal = 2199,
> +
> + .progressive= true, .trilevel_sync = true,
> +
> + .vsync_start_f1 = 8, .vsync_start_f2 = 8,
> + .vsync_len = 10,
> +
> + .veq_ena= false,.veq_start_f1 = 0,
> + .veq_start_f2 = 0,.veq_len= 0,
> +
> + .vi_end_f1 = 44, .vi_end_f2 = 44,
> + .nbr_end= 1079,
> +
> + .burst_ena = false,
> +
> + .filter_table = filter_table,
> + },
> +
> + {
> + .name = "1080p@50Hz",
> + .clock = 148500,
> + .refresh= 5,
> + .oversample = 1,
> + .component_only = true,
> +
> + .hsync_end = 88, .hblank_end = 235,
> + .hblank_start = 2155, .htotal = 2639,
> +
> + .progressive= true, .trilevel_sync = true,
> +
> + .vsync_start_f1 = 8, .vsync_start_f2 = 8,
> + .vsync_len = 10,
> +
> + .veq_ena= false,.veq_start_f1 = 0,
> + .veq_start_f2 = 0,.veq_len= 0,
> +
> + .vi_end_f1 = 44, .vi_end_f2 = 44,
> + .nbr_end= 1079,
> +
> + .burst_ena = false,
> +
> + .filter_table = filter_table,
> + },
> +
> + {
> + .name = "1080p@60Hz",
> + .clock = 148500,
> + .refresh= 6,
> + .oversample = 1,
> + .component_only = true,
> +
> + .hsync_end = 88, .hblank_end = 235,
> + .hblank_start = 2155, .htotal = 2199,
> +
> + .progressive= true, .trilevel_sync = true,
> +
> + .vsync_start_f1 = 8, .vsync_start_f2 = 8,
> + .vsync_len = 10,
> +
> + .veq_ena= false,.veq_start_f1
> = 0,
> + .veq_start_f2 = 0,.veq_len= 0,
> +
> + .vi_end_f1 = 44, .vi_end_f2 = 44,
> + .nbr_end= 1079,
> +
> + .burst_ena = false,
> +
> + .filter_table = filter_table,
> + },
> };
>
> static struct intel_tv *enc_to_tv(struct intel_encoder *encoder)
> @@ -1538,11 +1616,15 @@ intel_tv_init(struct drm_i915_private *dev_priv)
> connector->doublescan_allowed = false;
>
> /* Create TV properties then attach current values */
> - for (i = 0; i < ARRAY_SIZE(tv_modes); i++)
> + for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> + /* 1080p50/1080p60 not supported on gen3 */
> + if (IS_GEN3(dev_priv) &&
> + tv_modes[i].oversample == 1)
> + break;
> +
> tv_format_names[i] = tv_modes[i].name;
> - drm_mode_create_tv_properties(dev,
> - ARRAY_SIZE(tv_modes),
> - tv_format_names);
> + }
> + drm_mode_create_tv_properties(dev, i, tv_format_names);
>
> drm_object_attach_property(>base,
> dev->mode_config.tv_mode_property,
> state->tv.mode);
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/15] drm/i915/tv: Nuke reported_modes[]
On Mon, Nov 12, 2018 at 06:59:56PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Remove the silly reported_modes[] array. I suppse once upon a time
> this actually had something to do with modes we reported to userspace.
> Now it is just the placeholder for the mode we use for load detection.
> We don't need it even for that, and instead we can just rely on
> the fallback mode in intel_get_load_detect_pipe().
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 22 +-
> 1 file changed, 1 insertion(+), 21 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 32a8786fe0da..c39e9a5b43db 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1130,23 +1130,6 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> I915_WRITE(TV_CTL, tv_ctl);
> }
>
> -static const struct drm_display_mode reported_modes[] = {
> - {
> - .name = "NTSC 480i",
> - .clock = 108000,
> - .hdisplay = 1280,
> - .hsync_start = 1368,
> - .hsync_end = 1496,
> - .htotal = 1712,
> -
> - .vdisplay = 1024,
> - .vsync_start = 1027,
> - .vsync_end = 1034,
> - .vtotal = 1104,
> - .type = DRM_MODE_TYPE_DRIVER,
> - },
> -};
> -
> static int
> intel_tv_detect_type(struct intel_tv *intel_tv,
> struct drm_connector *connector)
> @@ -1276,7 +1259,6 @@ intel_tv_detect(struct drm_connector *connector,
> struct drm_modeset_acquire_ctx *ctx,
> bool force)
> {
> - struct drm_display_mode mode;
> struct intel_tv *intel_tv = intel_attached_tv(connector);
> enum drm_connector_status status;
> int type;
> @@ -1285,13 +1267,11 @@ intel_tv_detect(struct drm_connector *connector,
> connector->base.id, connector->name,
> force);
>
> - mode = reported_modes[0];
> -
> if (force) {
> struct intel_load_detect_pipe tmp;
> int ret;
>
> - ret = intel_get_load_detect_pipe(connector, , , ctx);
> + ret = intel_get_load_detect_pipe(connector, NULL, , ctx);
> if (ret < 0)
> return ret;
>
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 25/34] drm/i915: Track active timelines
On 21/01/2019 22:21, Chris Wilson wrote:
Now that we pin timelines around use, we have a clearly defined lifetime
and convenient points at which we can track only the active timelines.
This allows us to reduce the list iteration to only consider those
active timelines and not all.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 4 +--
drivers/gpu/drm/i915/i915_reset.c| 2 +-
drivers/gpu/drm/i915/i915_timeline.c | 39 ++--
4 files changed, 29 insertions(+), 18 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c00eaf2889fb..5577e0e1034f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1977,7 +1977,7 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
- struct list_head list;
+ struct list_head active_list;
/* Pack multiple timelines' seqnos into the same page */
spinlock_t hwsp_lock;
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 4e0de22f0166..9c499edb4c13 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3246,7 +3246,7 @@ wait_for_timelines(struct drm_i915_private *i915,
return timeout;
mutex_lock(>mutex);
- list_for_each_entry(tl, >list, link) {
+ list_for_each_entry(tl, >active_list, link) {
struct i915_request *rq;
rq = i915_gem_active_get_unlocked(>last_request);
@@ -3274,7 +3274,7 @@ wait_for_timelines(struct drm_i915_private *i915,
/* restart after reacquiring the lock */
mutex_lock(>mutex);
- tl = list_entry(>list, typeof(*tl), link);
+ tl = list_entry(>active_list, typeof(*tl), link);
}
mutex_unlock(>mutex);
diff --git a/drivers/gpu/drm/i915/i915_reset.c b/drivers/gpu/drm/i915/i915_reset.c
index 09edf488f711..9b9169508139 100644
--- a/drivers/gpu/drm/i915/i915_reset.c
+++ b/drivers/gpu/drm/i915/i915_reset.c
@@ -852,7 +852,7 @@ bool i915_gem_unset_wedged(struct drm_i915_private *i915)
* No more can be submitted until we reset the wedged bit.
*/
mutex_lock(>gt.timelines.mutex);
- list_for_each_entry(tl, >gt.timelines.list, link) {
+ list_for_each_entry(tl, >gt.timelines.active_list, link) {
struct i915_request *rq;
long timeout;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c b/drivers/gpu/drm/i915/i915_timeline.c
index 69ee33dfa340..007348b1b469 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -117,7 +117,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
const char *name,
struct i915_vma *hwsp)
{
- struct i915_gt_timelines *gt = >gt.timelines;
void *vaddr;
/*
@@ -161,10 +160,6 @@ int i915_timeline_init(struct drm_i915_private *i915,
i915_syncmap_init(>sync);
- mutex_lock(>mutex);
- list_add(>link, >list);
- mutex_unlock(>mutex);
-
return 0;
}
@@ -173,7 +168,7 @@ void i915_timelines_init(struct drm_i915_private *i915)
struct i915_gt_timelines *gt = >gt.timelines;
mutex_init(>mutex);
- INIT_LIST_HEAD(>list);
+ INIT_LIST_HEAD(>active_list);
spin_lock_init(>hwsp_lock);
INIT_LIST_HEAD(>hwsp_free_list);
@@ -182,6 +177,24 @@ void i915_timelines_init(struct drm_i915_private *i915)
i915_gem_shrinker_taints_mutex(i915, >mutex);
}
+static void timeline_active(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+
+ mutex_lock(>mutex);
+ list_add(>link, >active_list);
+ mutex_unlock(>mutex);
+}
+
+static void timeline_inactive(struct i915_timeline *tl)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+
+ mutex_lock(>mutex);
+ list_del(>link);
+ mutex_unlock(>mutex);
+}
Bike shedding comments only:
Would it be better to use a verb suffix? Even though timeline_activate
also wouldn't sound perfect. Since it is file local - activate_timeline?
Or even just inline to pin/unpin. Unless more gets put into them later..
+
/**
* i915_timelines_park - called when the driver idles
* @i915: the drm_i915_private device
@@ -198,7 +211,7 @@ void i915_timelines_park(struct drm_i915_private *i915)
struct i915_timeline *timeline;
mutex_lock(>mutex);
- list_for_each_entry(timeline, >list, link) {
+ list_for_each_entry(timeline, >active_list, link) {
/*
* All known fences are completed so we can scrap
* the current sync point tracking and start afresh,
@@ -212,15 +225,9 @@ void i915_timelines_park(struct
Re: [Intel-gfx] [PATCH 10/15] drm/i915/tv: Make TV mode autoselection actually useable
On Mon, Nov 12, 2018 at 06:59:55PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The current code insists on picking a new TV mode when
> switching between component and non-component cables.
> That's super annoying. Let's just keep the current TV
> mode unless the new cable type actually disagrees with it.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 12 +++-
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 433f538261c1..32a8786fe0da 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1253,16 +1253,18 @@ static void intel_tv_find_better_format(struct
> drm_connector *connector)
> const struct tv_mode *tv_mode = intel_tv_mode_find(connector->state);
> int i;
>
> - if ((intel_tv->type == DRM_MODE_CONNECTOR_Component) ==
> - tv_mode->component_only)
> + /* Component supports everything so we can keep the current mode */
> + if (intel_tv->type == DRM_MODE_CONNECTOR_Component)
> return;
>
> + /* If the current mode is fine don't change it */
> + if (!tv_mode->component_only)
> + return;
>
> for (i = 0; i < ARRAY_SIZE(tv_modes); i++) {
> - tv_mode = tv_modes + i;
> + tv_mode = _modes[i];
>
> - if ((intel_tv->type == DRM_MODE_CONNECTOR_Component) ==
> - tv_mode->component_only)
> + if (!tv_mode->component_only)
> break;
> }
>
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] iommu/intel: quirk to disable DMAR for QM57 igfx
Quoting Joerg Roedel (2019-01-22 13:01:09) > Hi Daniel, > > On Tue, Jan 22, 2019 at 11:46:39AM +0100, Daniel Vetter wrote: > > Note that the string of platforms which have various issues with iommu > > and igfx is very long, thus far we only disabled it where there's no > > workaround to stop it from hanging the box, but otherwise left it > > enabled. So if we make a policy change to also disable it anywhere > > where it doesn't work well (instead of not at all), there's a pile > > more platforms to switch. > > I think its best to just disable iommu for the igfx devices on these > platforms. Can you pick up Eric's patch and extend it with the list of > affected platforms? We've been discussing this again more actively since a few months ago, and the discussion is still ongoing internally. According to our IOMMU folks there exists some desire to be able to assign the iGFX device aka have intel_iommu=on instead of intel_iommu=igfx_off due to how the devices might be grouped in IOMMU groups. Even when you would not be using the iGFX device. So for some uses, the fact that the device (group) is assignable seems to be more important than the iGFX device to be working. I'm afraid that retroactively disabling the assignment for such an old platform might break those usage scenarios. By my quick reading of the code, there's no way for user to turn the iGFX DMAR on once the quirk disables it. I guess one solution would be to default to intel_iommu=igfx_off for platforms that are older than certain threshold. But still allow user to enable. But that then requires duplicating the PCI ID database into iommu code. I don't really have winning moves to present, but I'm open to hearing how we can avoid more damage than starting to default to intel_iommu=on did already. Regards, Joonas > > Thanks, > > Joerg ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/15] drm/i915/tv: Use drm_mode_set_name() to name TV modes
On Mon, Nov 12, 2018 at 06:59:54PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> No point in storing the mode names in the array. drm_mode_set_name()
> will give us the same names without wasting space for these string
> constants.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 21 +++--
> 1 file changed, 11 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 54189080cfb1..433f538261c1 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -1313,16 +1313,15 @@ intel_tv_detect(struct drm_connector *connector,
> }
>
> static const struct input_res {
> - const char *name;
> - int w, h;
> + u16 w, h;
> } input_res_table[] = {
> - {"640x480", 640, 480},
> - {"800x600", 800, 600},
> - {"1024x768", 1024, 768},
> - {"1280x1024", 1280, 1024},
> - {"848x480", 848, 480},
> - {"1280x720", 1280, 720},
> - {"1920x1080", 1920, 1080},
> + { 640, 480 },
> + { 800, 600 },
> + { 1024, 768 },
> + { 1280, 1024 },
> + { 848, 480 },
> + { 1280, 720 },
> + { 1920, 1080 },
> };
>
> /* Choose preferred mode according to line number of TV format */
> @@ -1373,7 +1372,6 @@ intel_tv_get_modes(struct drm_connector *connector)
> mode_ptr = drm_mode_create(connector->dev);
> if (!mode_ptr)
> continue;
> - strlcpy(mode_ptr->name, input->name, DRM_DISPLAY_MODE_LEN);
>
> mode_ptr->hdisplay = hactive_s;
> mode_ptr->hsync_start = hactive_s + 1;
> @@ -1395,6 +1393,9 @@ intel_tv_get_modes(struct drm_connector *connector)
> mode_ptr->clock = (int) tmp;
>
> intel_tv_set_mode_type(mode_ptr, tv_mode);
> +
> + drm_mode_set_name(mode_ptr);
> +
> drm_mode_probed_add(connector, mode_ptr);
> count++;
> }
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/15] drm/i915/tv: Deobfuscate preferred mode selection
On Mon, Nov 12, 2018 at 06:59:53PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Rewrite the preferred mode selection to just check
> whether the TV modes is HD or SD. For SD TV modes we
> favor 480 line modes, for 720p we prefer 720 line modes,
> and for 1080i/p we prefer 1080 line modes.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 50 -
> 1 file changed, 30 insertions(+), 20 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 97a82878359f..54189080cfb1 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -860,6 +860,14 @@ intel_tv_mode_valid(struct drm_connector *connector,
> return MODE_CLOCK_RANGE;
> }
>
> +static int
> +intel_tv_mode_vdisplay(const struct tv_mode *tv_mode)
> +{
> + if (tv_mode->progressive)
> + return tv_mode->nbr_end + 1;
> + else
> + return 2 * (tv_mode->nbr_end + 1);
> +}
>
> static void
> intel_tv_get_config(struct intel_encoder *encoder,
> @@ -1098,10 +1106,7 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> /* Filter ctl must be set before TV_WIN_SIZE */
> I915_WRITE(TV_FILTER_CTL_1, TV_AUTO_SCALE);
> xsize = tv_mode->hblank_start - tv_mode->hblank_end;
> - if (tv_mode->progressive)
> - ysize = tv_mode->nbr_end + 1;
> - else
> - ysize = 2 * (tv_mode->nbr_end + 1);
> + ysize = intel_tv_mode_vdisplay(tv_mode);
>
> xpos = conn_state->tv.margins.left;
> ypos = conn_state->tv.margins.top;
> @@ -1320,22 +1325,28 @@ static const struct input_res {
> {"1920x1080", 1920, 1080},
> };
>
> -/*
> - * Chose preferred mode according to line number of TV format
> - */
> +/* Choose preferred mode according to line number of TV format */
> +static bool
> +intel_tv_is_preferred_mode(const struct drm_display_mode *mode,
> +const struct tv_mode *tv_mode)
> +{
> + int vdisplay = intel_tv_mode_vdisplay(tv_mode);
> +
> + /* prefer 480 line modes for all SD TV modes */
> + if (vdisplay <= 576)
> + vdisplay = 480;
> +
> + return vdisplay == mode->vdisplay;
> +}
> +
> static void
> -intel_tv_choose_preferred_modes(const struct tv_mode *tv_mode,
> -struct drm_display_mode *mode_ptr)
> +intel_tv_set_mode_type(struct drm_display_mode *mode,
> +const struct tv_mode *tv_mode)
> {
> - if (tv_mode->nbr_end < 480 && mode_ptr->vdisplay == 480)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - else if (tv_mode->nbr_end > 480) {
> - if (tv_mode->progressive == true && tv_mode->nbr_end < 720) {
> - if (mode_ptr->vdisplay == 720)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - } else if (mode_ptr->vdisplay == 1080)
> - mode_ptr->type |= DRM_MODE_TYPE_PREFERRED;
> - }
> + mode->type = DRM_MODE_TYPE_DRIVER;
> +
> + if (intel_tv_is_preferred_mode(mode, tv_mode))
> + mode->type |= DRM_MODE_TYPE_PREFERRED;
> }
>
> static int
> @@ -1383,8 +1394,7 @@ intel_tv_get_modes(struct drm_connector *connector)
> tmp = div_u64(tmp, 100);
> mode_ptr->clock = (int) tmp;
>
> - mode_ptr->type = DRM_MODE_TYPE_DRIVER;
> - intel_tv_choose_preferred_modes(tv_mode, mode_ptr);
> + intel_tv_set_mode_type(mode_ptr, tv_mode);
> drm_mode_probed_add(connector, mode_ptr);
> count++;
> }
> --
> 2.18.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 5/7] drm/i915: keep track of used entries in MOCS table
Quoting Lucas De Marchi (2019-01-22 05:12:25)
> Instead of considering we have defined entries for any index in the
> table, let's keep track of the ones we explicitly defined. This will
> allow Gen 11 to have it's new table defined in which we have holes of
> undefined entries.
>
> Repeated comments about the meaning of undefined entries were removed
> since they are overly verbose and copy-pasted in several functions: now
> the definition is in the top only.
>
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_mocs.c | 88 ---
> 1 file changed, 57 insertions(+), 31 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index faae2eefc5cc..af2ae2f396ae 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -28,6 +28,7 @@
> struct drm_i915_mocs_entry {
> u32 control_value;
> u16 l3cc_value;
> + u16 used;
> };
> + /* Set unused values to PTE */
> + unused_index = I915_MOCS_PTE;
> +
> + for (i = 0; i < table.size / 2; i++) {
> + u16 low = table.table[2 * i].used ?
> + 2 * i : unused_index;
> + u16 high = table.table[2 * i + 1].used ?
> + 2 * i + 1 : unused_index;
I'm underwhelmed here.
Could we not do something like
static unsigned int
get_entry_index(struct tbl *tbl, unsigned int idx, unsigned int unused_index)
{
return tbl->used ? idx : unused_index;
}
u16 lo = get_entry_index(table.table, 2 * i, unused_index);
u16 hi = get_entry_index(table.table, 2 * i + 1, unused_index);
That just fits and repeated enough to be worth a little extra effort.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
== Series Details ==
Series: drm/i915: Use fb width to measure fb width instead of visible plane
width when verify NV12
URL : https://patchwork.freedesktop.org/series/8/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_5463 -> Patchwork_12004
Summary
---
**SUCCESS**
No regressions found.
External URL:
https://patchwork.freedesktop.org/api/1.0/series/8/revisions/1/mbox/
Known issues
Here are the changes found in Patchwork_12004 that come from known issues:
### IGT changes ###
Issues hit
* igt@i915_selftest@live_hangcheck:
- fi-bwr-2160:PASS -> DMESG-FAIL [fdo#108735]
* igt@kms_chamelium@hdmi-hpd-fast:
- fi-kbl-7500u: PASS -> FAIL [fdo#108767]
Possible fixes
* igt@kms_frontbuffer_tracking@basic:
- {fi-icl-u3}:FAIL [fdo#103167] -> PASS
* igt@kms_pipe_crc_basic@nonblocking-crc-pipe-a-frame-sequence:
- fi-byt-clapper: FAIL [fdo#103191] / [fdo#107362] -> PASS
* igt@kms_pipe_crc_basic@read-crc-pipe-b:
- fi-byt-clapper: FAIL [fdo#107362] -> PASS
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167
[fdo#103191]: https://bugs.freedesktop.org/show_bug.cgi?id=103191
[fdo#107362]: https://bugs.freedesktop.org/show_bug.cgi?id=107362
[fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569
[fdo#108735]: https://bugs.freedesktop.org/show_bug.cgi?id=108735
[fdo#108767]: https://bugs.freedesktop.org/show_bug.cgi?id=108767
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109285]: https://bugs.freedesktop.org/show_bug.cgi?id=109285
[fdo#109289]: https://bugs.freedesktop.org/show_bug.cgi?id=109289
[fdo#109309]: https://bugs.freedesktop.org/show_bug.cgi?id=109309
[fdo#109315]: https://bugs.freedesktop.org/show_bug.cgi?id=109315
[fdo#109316]: https://bugs.freedesktop.org/show_bug.cgi?id=109316
Participating hosts (41 -> 39)
--
Additional (2): fi-icl-u2 fi-apl-guc
Missing(4): fi-kbl-soraka fi-ilk-m540 fi-byt-squawks fi-bsw-cyan
Build changes
-
* Linux: CI_DRM_5463 -> Patchwork_12004
CI_DRM_5463: 6bd1569466edcb2f890a374be27f0eb6780963f9 @
git://anongit.freedesktop.org/gfx-ci/linux
IGT_4782: 96f3a1b876e0dd24706b85fb872f12031a436e84 @
git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_12004: d607a5109524a7bf7a9d77b1465a627a20c42021 @
git://anongit.freedesktop.org/gfx-ci/linux
== Linux commits ==
d607a5109524 drm/i915: Use fb width to measure fb width instead of visible
plane width when verify NV12
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_12004/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 6/7] drm/i915: cache number of MOCS entries
Quoting Lucas De Marchi (2019-01-22 05:12:26) > Instead of checking the gen number every time we need to know the max > number of entries, just save it into the table struct so we don't need > extra branches throughout the code. This will be useful for Ice Lake > that has 64 rather than 62 defined entries. Ice Lake changes will be > added in a follow up. > > v2: make size and n_entries `unsigned int` and introduce changes as a > pre-work for the Ice Lake changes (Tvrtko) > > Suggested-by: Tvrtko Ursulin > Signed-off-by: Lucas De Marchi Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 4/7] drm/i915: use a macro to define MOCS entries
Quoting Lucas De Marchi (2019-01-22 05:12:24) > Let's use a macro to make tables smaller and at the same time allow us > to add fields that apply to all entries in future. > > For the sake of readability, I'm calling an exception on 80 chars limit. > Lines are aligned for easy comparison of the entry values. > + MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, \ > + L3_1_UC), \ MOCS_ENTRY(I915_MOCS_UNCACHED, LE_1_UC | LE_TC_2_LLC_ELLC, L3_1_UC), \ is even more readable with the visual clustering of attribute flags. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 3/7] drm/i915/skl: Rework MOCS tables to keep common part in a define
Quoting Lucas De Marchi (2019-01-22 05:12:23)
> From: Tomasz Lis
>
> The MOCS tables are going to be very similar across platforms.
>
> To reduce the amount of copied code, this patch rips the common part and
> puts it into a definition valid for all gen9 platforms.
>
> v2: Made defines for or-ing flags. Renamed macros from MOCS_TABLE
> to MOCS_ENTRIES. (Joonas)
> v3 (Lucas):
> - Fix indentation
> - Rebase on rework done by additional patch
> - Remove define for or-ing flags as it made the table more complex by
> requiring zeroed values to be passed
> - Do not embed comma in the macro, so to treat that just as another
> item and please source code formatting tools
>
> Signed-off-by: Tomasz Lis
> Suggested-by: Lucas De Marchi
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_mocs.c | 57 ++-
> 1 file changed, 25 insertions(+), 32 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_mocs.c
> b/drivers/gpu/drm/i915/intel_mocs.c
> index 4ea80bb7dcc8..c7a2a8d81d90 100644
> --- a/drivers/gpu/drm/i915/intel_mocs.c
> +++ b/drivers/gpu/drm/i915/intel_mocs.c
> @@ -93,46 +93,39 @@ struct drm_i915_mocs_table {
> * may only be updated incrementally by adding entries at the
> * end.
> */
> +
> +#define GEN9_MOCS_ENTRIES \
> + [I915_MOCS_UNCACHED] = { \
> + /* 0x0009 */ \
> + .control_value = LE_1_UC | LE_TC_2_LLC_ELLC, \
> + /* 0x0010 */ \
> + .l3cc_value = L3_1_UC, \
> + }, \
> + [I915_MOCS_PTE] = { \
> + /* 0x0038 */ \
> + .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC |
> LE_LRUM(3), \
> + /* 0x0030 */ \
> + .l3cc_value = L3_3_WB, \
> + }
> +
> static const struct drm_i915_mocs_entry skylake_mocs_table[] = {
> - [I915_MOCS_UNCACHED] = {
> - /* 0x0009 */
> - .control_value = LE_1_UC | LE_TC_2_LLC_ELLC,
> - /* 0x0010 */
> - .l3cc_value =L3_1_UC,
> - },
> - [I915_MOCS_PTE] = {
> - /* 0x0038 */
> - .control_value = LE_0_PAGETABLE | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> - /* 0x0030 */
> - .l3cc_value =L3_3_WB,
> - },
> + GEN9_MOCS_ENTRIES,
> [I915_MOCS_CACHED] = {
> - /* 0x003b */
> - .control_value = LE_3_WB | LE_TC_2_LLC_ELLC | LE_LRUM(3),
> - /* 0x0030 */
> - .l3cc_value = L3_3_WB,
> + /* 0x003b */
You scared me with the indentation change at the same time.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v8 1/7] drm/i915: initialize unused MOCS entries to PTE
Quoting Lucas De Marchi (2019-01-22 05:12:21) > Instead of initializing them to uncached, let's set them to PTE for > kernel tracking. While at it do some minor adjustments to comments and > coding style. > > Signed-off-by: Lucas De Marchi I'm in favour. I do not think this contributes an ABI change, as these values are explicitly outside of the ABI. What it does mean is that the buffer contents are consistent with our cache tracking; and for userspace the results were always undefined. So we should at least be able to guarantee that the data written by userspace from the CPU is visible. After that, your caches are on your own. Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/38] drm/i915: Stop tracking MRU activity on VMA
Quoting Tvrtko Ursulin (2019-01-18 16:03:27) > > On 18/01/2019 14:00, Chris Wilson wrote: > > Our goal is to remove struct_mutex and replace it with fine grained > > locking. One of the thorny issues is our eviction logic for reclaiming > > space for an execbuffer (or GTT mmaping, among a few other examples). > > While eviction itself is easy to move under a per-VM mutex, performing > > the activity tracking is less agreeable. One solution is not to do any > > MRU tracking and do a simple coarse evaluation during eviction of > > active/inactive, with a loose temporal ordering of last > > insertion/evaluation. That keeps all the locking constrained to when we > > are manipulating the VM itself, neatly avoiding the tricky handling of > > possible recursive locking during execbuf and elsewhere. > > > > Note that discarding the MRU is unlikely to impact upon our efficiency > > to reclaim VM space (where we think a LRU model is best) as our > > current strategy is to use random idle replacement first before doing > > a search, and over time the use of softpinned 48b per-ppGTT is growing > > (thereby eliminating any need to perform any eviction searches, in > > theory at least). > > There is still no mention of list consolidation. "Note that discarding the MRU (currently implemented as a pair of lists, to avoid scanning the active list for a NONBLOCKING search)" Is that enough to make it clear? -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
Please ignore this. This patch is all wrong.
/Juha-Pekka
On 22.1.2019 14.41, Juha-Pekka Heikkila wrote:
Using visible plane width for testing NV12 source suitability may fail
randomly when plane is clipped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b02d3d9..a15c5ef 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1516,7 +1516,7 @@ static int skl_plane_check_nv12_rotation(const struct
intel_plane_state *plane_s
{
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
- int src_w = drm_rect_width(_state->base.src) >> 16;
+ int src_w = plane_state->base.fb->width;
/* Display WA #1106 */
if (fb->format->format == DRM_FORMAT_NV12 && src_w & 3 &&
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 2019-01-22 at 15:07 +0200, Jani Nikula wrote: > On Tue, 22 Jan 2019, Mika Kahola wrote: > > Avoid divide by zero warning on static analysis. > > > > Signed-off-by: Mika Kahola > > --- > > drivers/gpu/drm/i915/intel_pm.c | 6 -- > > 1 file changed, 4 insertions(+), 2 deletions(-) > > > > diff --git a/drivers/gpu/drm/i915/intel_pm.c > > b/drivers/gpu/drm/i915/intel_pm.c > > index 8b63afa3a221..6a8e8b3f44c2 100644 > > --- a/drivers/gpu/drm/i915/intel_pm.c > > +++ b/drivers/gpu/drm/i915/intel_pm.c > > @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > > drm_i915_private *dev_priv, > > pipe_width = hdisplay; > > } > > if (WARN_ON(total_width == 0)) > return; Warning might be enough here. Switching to use this in this patch. Thanks for the review! Cheers, Mika > > ? > > BR, > Jani. > > > > > > - alloc->start = ddb_size * width_before_pipe / total_width; > > - alloc->end = ddb_size * (width_before_pipe + pipe_width) / > > total_width; > > + alloc->start = total_width == 0 ? > > + 0 : ddb_size * width_before_pipe / total_width; > > + alloc->end = total_width == 0 ? > > + 0 : ddb_size * (width_before_pipe + pipe_width) / > > total_width; > > } > > > > static unsigned int skl_cursor_allocation(int num_active) > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/15] drm/i915/tv: Nuke silly 0 initialzation of xpos/ypos
On Mon, Nov 12, 2018 at 06:59:51PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Just assign the margin values directly to xpos/ypos instead > of first initializing to zero and then adding the values. > > Signed-off-by: Ville Syrjälä Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_tv.c | 6 +++--- > 1 file changed, 3 insertions(+), 3 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c > index 72de154b8627..97a82878359f 100644 > --- a/drivers/gpu/drm/i915/intel_tv.c > +++ b/drivers/gpu/drm/i915/intel_tv.c > @@ -994,7 +994,7 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > const struct video_levels *video_levels; > const struct color_conversion *color_conversion; > bool burst_ena; > - int xpos = 0x0, ypos = 0x0; > + int xpos, ypos; > unsigned int xsize, ysize; > > if (!tv_mode) > @@ -1103,8 +1103,8 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > else > ysize = 2 * (tv_mode->nbr_end + 1); > > - xpos += conn_state->tv.margins.left; > - ypos += conn_state->tv.margins.top; > + xpos = conn_state->tv.margins.left; > + ypos = conn_state->tv.margins.top; > xsize -= (conn_state->tv.margins.left + > conn_state->tv.margins.right); > ysize -= (conn_state->tv.margins.top + > -- > 2.18.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/15] drm/i915/tv: Use bools where appropriate
On Mon, Nov 12, 2018 at 06:59:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> 'component_only' is a bool. Initialize it like a bool.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 24
> 1 file changed, 12 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 96257b29d07c..72de154b8627 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -380,7 +380,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
>
> .hsync_end = 64, .hblank_end = 124,
> @@ -423,7 +423,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 4.43MHz */
> .hsync_end = 64, .hblank_end = 124,
> .hblank_start = 836, .htotal = 857,
> @@ -465,7 +465,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -508,7 +508,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -552,7 +552,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> .hsync_end = 64, .hblank_end = 128,
> .hblank_start = 844,.htotal = 863,
> @@ -597,7 +597,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 8,
> - .component_only = 0,
> + .component_only = false,
>
> .hsync_end = 64, .hblank_end = 142,
> .hblank_start = 844, .htotal = 863,
> @@ -639,7 +639,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 59940,
> .oversample = 4,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 64, .hblank_end = 122,
> .hblank_start = 842, .htotal = 857,
> @@ -663,7 +663,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 108000,
> .refresh= 5,
> .oversample = 4,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 64, .hblank_end = 139,
> .hblank_start = 859, .htotal = 863,
> @@ -687,7 +687,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 6,
> .oversample = 2,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 80, .hblank_end = 300,
> .hblank_start = 1580, .htotal = 1649,
> @@ -711,7 +711,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 5,
> .oversample = 2,
> - .component_only = 1,
> + .component_only = true,
>
> .hsync_end = 80, .hblank_end = 300,
> .hblank_start = 1580, .htotal = 1979,
> @@ -736,7 +736,7 @@ static const struct tv_mode tv_modes[] = {
> .clock = 148500,
> .refresh= 5,
Re: [Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
On Tue, 22 Jan 2019, Mika Kahola wrote: > Avoid divide by zero warning on static analysis. > > Signed-off-by: Mika Kahola > --- > drivers/gpu/drm/i915/intel_pm.c | 6 -- > 1 file changed, 4 insertions(+), 2 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c > index 8b63afa3a221..6a8e8b3f44c2 100644 > --- a/drivers/gpu/drm/i915/intel_pm.c > +++ b/drivers/gpu/drm/i915/intel_pm.c > @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct > drm_i915_private *dev_priv, > pipe_width = hdisplay; > } if (WARN_ON(total_width == 0)) return; ? BR, Jani. > > - alloc->start = ddb_size * width_before_pipe / total_width; > - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; > + alloc->start = total_width == 0 ? > + 0 : ddb_size * width_before_pipe / total_width; > + alloc->end = total_width == 0 ? > + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; > } > > static unsigned int skl_cursor_allocation(int num_active) -- Jani Nikula, Intel Open Source Graphics Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/15] drm/i915/tv: Store the TV oversampling factor in the TV mode
On Mon, Nov 12, 2018 at 06:59:49PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> Store the oversampling factor as a number in the TV modes. We
> shall want to arithmetic with this which is easier if it's
> a number we can use directly.
>
> Signed-off-by: Ville Syrjälä
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 42 ++---
> 1 file changed, 28 insertions(+), 14 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index dea24ef88763..96257b29d07c 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -307,7 +307,7 @@ struct tv_mode {
>
> u32 clock;
> u16 refresh; /* in millihertz (for precision) */
> - u32 oversample;
> + u8 oversample;
> u8 hsync_end;
> u16 hblank_start, hblank_end, htotal;
> bool progressive : 1, trilevel_sync : 1, component_only : 1;
> @@ -379,7 +379,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-M",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
>
> @@ -422,7 +422,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-443",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 4.43MHz */
> .hsync_end = 64, .hblank_end = 124,
> @@ -464,7 +464,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "NTSC-J",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> @@ -507,7 +507,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL-M",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> /* 525 Lines, 60 Fields, 15.734KHz line, Sub-Carrier 3.580MHz */
> @@ -551,7 +551,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL-N",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> .hsync_end = 64, .hblank_end = 128,
> @@ -596,7 +596,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "PAL",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_8X,
> + .oversample = 8,
> .component_only = 0,
>
> .hsync_end = 64, .hblank_end = 142,
> @@ -638,7 +638,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "480p",
> .clock = 108000,
> .refresh= 59940,
> - .oversample = TV_OVERSAMPLE_4X,
> + .oversample = 4,
> .component_only = 1,
>
> .hsync_end = 64, .hblank_end = 122,
> @@ -662,7 +662,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "576p",
> .clock = 108000,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_4X,
> + .oversample = 4,
> .component_only = 1,
>
> .hsync_end = 64, .hblank_end = 139,
> @@ -686,7 +686,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "720p@60Hz",
> .clock = 148500,
> .refresh= 6,
> - .oversample = TV_OVERSAMPLE_2X,
> + .oversample = 2,
> .component_only = 1,
>
> .hsync_end = 80, .hblank_end = 300,
> @@ -710,7 +710,7 @@ static const struct tv_mode tv_modes[] = {
> .name = "720p@50Hz",
> .clock = 148500,
> .refresh= 5,
> - .oversample = TV_OVERSAMPLE_2X,
> + .oversample = 2,
> .component_only = 1,
>
> .hsync_end = 80,
[Intel-gfx] [PATCH] drm/i915: Avoid divide by zero
Avoid divide by zero warning on static analysis. Signed-off-by: Mika Kahola --- drivers/gpu/drm/i915/intel_pm.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 8b63afa3a221..6a8e8b3f44c2 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -3912,8 +3912,10 @@ skl_ddb_get_pipe_allocation_limits(struct drm_i915_private *dev_priv, pipe_width = hdisplay; } - alloc->start = ddb_size * width_before_pipe / total_width; - alloc->end = ddb_size * (width_before_pipe + pipe_width) / total_width; + alloc->start = total_width == 0 ? + 0 : ddb_size * width_before_pipe / total_width; + alloc->end = total_width == 0 ? + 0 : ddb_size * (width_before_pipe + pipe_width) / total_width; } static unsigned int skl_cursor_allocation(int num_active) -- 2.17.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/15] drm/i915/tv: Fix tv mode clocks
On Mon, Nov 12, 2018 at 06:59:48PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> The oversample clock is always supposed to be either 108 MHz
> or 148.5 MHz. Make it so.
>
> Signed-off-by: Ville Syrjälä
Matches the spec:
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tv.c | 14 +++---
> 1 file changed, 7 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c
> index 219a16d6dcc2..dea24ef88763 100644
> --- a/drivers/gpu/drm/i915/intel_tv.c
> +++ b/drivers/gpu/drm/i915/intel_tv.c
> @@ -636,7 +636,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "480p",
> - .clock = 107520,
> + .clock = 108000,
> .refresh= 59940,
> .oversample = TV_OVERSAMPLE_4X,
> .component_only = 1,
> @@ -660,7 +660,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "576p",
> - .clock = 107520,
> + .clock = 108000,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_4X,
> .component_only = 1,
> @@ -684,7 +684,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "720p@60Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 6,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -708,7 +708,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "720p@50Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -733,7 +733,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "1080i@50Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 5,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -759,7 +759,7 @@ static const struct tv_mode tv_modes[] = {
> },
> {
> .name = "1080i@60Hz",
> - .clock = 148800,
> + .clock = 148500,
> .refresh= 6,
> .oversample = TV_OVERSAMPLE_2X,
> .component_only = 1,
> @@ -1114,7 +1114,7 @@ static void intel_tv_pre_enable(struct intel_encoder
> *encoder,
> static const struct drm_display_mode reported_modes[] = {
> {
> .name = "NTSC 480i",
> - .clock = 107520,
> + .clock = 108000,
> .hdisplay = 1280,
> .hsync_start = 1368,
> .hsync_end = 1496,
> --
> 2.18.1
>
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/15] drm/i915/tv: Fix interlaced ysize calculation
On Mon, Nov 12, 2018 at 06:59:47PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Fix the calculation of the vertical active period for interlaced > TV modes. > > Signed-off-by: Ville Syrjälä Matches the spec: Reviewed-by: Imre Deak > --- > drivers/gpu/drm/i915/intel_tv.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_tv.c b/drivers/gpu/drm/i915/intel_tv.c > index 860f306a23ba..219a16d6dcc2 100644 > --- a/drivers/gpu/drm/i915/intel_tv.c > +++ b/drivers/gpu/drm/i915/intel_tv.c > @@ -1087,7 +1087,7 @@ static void intel_tv_pre_enable(struct intel_encoder > *encoder, > if (tv_mode->progressive) > ysize = tv_mode->nbr_end + 1; > else > - ysize = 2*tv_mode->nbr_end + 1; > + ysize = 2 * (tv_mode->nbr_end + 1); > > xpos += conn_state->tv.margins.left; > ypos += conn_state->tv.margins.top; > -- > 2.18.1 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/15] drm/i915: Don't try to use the hardware frame counter with i965gm TV output
On Tue, Nov 27, 2018 at 10:05:50PM +0200, Ville Syrjala wrote:
> From: Ville Syrjälä
>
> On i965gm the hardware frame counter does not work when
> the TV encoder is active. So let's not try to consult
> the hardware frame counter in that case. Instead we'll
> fall back to the timestamp based guesstimation method
> used on gen2.
>
> Note that the pipe timings generated by the TV encoder
> are also rather peculiar. Apparently the pipe wants to
> run at a much higher speed (related to the oversample
> clock somehow it seems) but during the vertical active
> period the TV encoder stalls the pipe every few lines
> to keep its speed in check. But once the vertical
> blanking period is reached the pipe gets to run at full
> speed. This means our vblank timestamp estimates are
> suspect. Fixing all that would require quite a bit
> more work. This simple fix at least avoids the nasty
> vblank timeouts that are happening currently.
>
> Curiously the frame counter works just fine on i945gm
> and gm45. I don't really understand what kind of mishap
> occurred with the hardware design on i965gm. Sadly
> I wasn't able to find any chicken bits etc. that would
> fix the frame counter :(
>
> v2: Move the zero vs. non-zero hw counter value handling
> into i915_get_vblank_counter() (Daniel)
> Use the per-crtc maximum exclusively, leaving the
> per-device maximum at zero
> v3: max_vblank_count not populated yet in intel_enable_pipe()
> use intel_crtc_max_vblank_count() instead
>
> Cc: sta...@vger.kernel.org
> Cc: Daniel Vetter
> Fixes: 51e31d49c890 ("drm/i915: Use generic vblank wait")
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=93782
> Signed-off-by: Ville Syrjälä
>
> fix# _slub_broken.S
^ some remnant
Reviewed-by: Imre Deak
> ---
> drivers/gpu/drm/i915/i915_irq.c | 27 ++--
> drivers/gpu/drm/i915/intel_display.c | 48 +++-
> 2 files changed, 58 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
> index d447d7d508f4..ab2d4eefef18 100644
> --- a/drivers/gpu/drm/i915/i915_irq.c
> +++ b/drivers/gpu/drm/i915/i915_irq.c
> @@ -822,11 +822,26 @@ static void i915_enable_asle_pipestat(struct
> drm_i915_private *dev_priv)
> static u32 i915_get_vblank_counter(struct drm_device *dev, unsigned int pipe)
> {
> struct drm_i915_private *dev_priv = to_i915(dev);
> + struct drm_vblank_crtc *vblank = >vblank[pipe];
> + const struct drm_display_mode *mode = >hwmode;
> i915_reg_t high_frame, low_frame;
> u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
> - const struct drm_display_mode *mode = >vblank[pipe].hwmode;
> unsigned long irqflags;
>
> + /*
> + * On i965gm TV output the frame counter only works up to
> + * the point when we enable the TV encoder. After that the
> + * frame counter ceases to work and reads zero. We need a
> + * vblank wait before enabling the TV encoder and so we
> + * have to enable vblank interrupts while the frame counter
> + * is still in a working state. However the core vblank code
> + * does not like us returning non-zero frame counter values
> + * when we've told it that we don't have a working frame
> + * counter. Thus we must stop non-zero values leaking out.
> + */
> + if (!vblank->max_vblank_count)
> + return 0;
> +
> htotal = mode->crtc_htotal;
> hsync_start = mode->crtc_hsync_start;
> vbl_start = mode->crtc_vblank_start;
> @@ -4836,16 +4851,10 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> if (INTEL_GEN(dev_priv) >= 8)
> rps->pm_intrmsk_mbz |= GEN8_PMINTR_DISABLE_REDIRECT_TO_GUC;
>
> - if (IS_GEN2(dev_priv)) {
> - /* Gen2 doesn't have a hardware frame counter */
> - dev->max_vblank_count = 0;
> - } else if (IS_G4X(dev_priv) || INTEL_GEN(dev_priv) >= 5) {
> - dev->max_vblank_count = 0x; /* full 32 bit counter */
> + if (INTEL_GEN(dev_priv) >= 5 || IS_G4X(dev_priv))
> dev->driver->get_vblank_counter = g4x_get_vblank_counter;
> - } else {
> + else if (INTEL_GEN(dev_priv) >= 3)
> dev->driver->get_vblank_counter = i915_get_vblank_counter;
> - dev->max_vblank_count = 0xff; /* only 24 bits of frame
> count */
> - }
>
> /*
>* Opt out of the vblank disable timer on everything except gen2.
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e9f4e22b2a4e..cb13eff78ad9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -1754,6 +1754,35 @@ enum pipe intel_crtc_pch_transcoder(struct intel_crtc
> *crtc)
> return crtc->pipe;
> }
>
> +static u32 intel_crtc_max_vblank_count(const struct intel_crtc_state
> *crtc_state)
> +{
> + struct drm_i915_private
Re: [Intel-gfx] [PATCH 07/34] drm/i915: Refactor out intel_context_init()
Quoting Mika Kuoppala (2019-01-22 12:39:08)
> Chris Wilson writes:
> > +static inline void
> > +intel_context_init(struct intel_context *ce,
> > +struct i915_gem_context *ctx,
> > +struct intel_engine_cs *engine)
> > +{
> > + ce->gem_context = ctx;
> > +}
> > +
>
> Audience was also waiting intel_context_init_engines()
struct intel_context is the per-engine instance, and it's not actually
guaranteed that there will be a contiguous set :) One should always skip
to the end of the novel to find out it was the butler who did it.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/34] drm/i915: Show all active engines on hangcheck
Quoting Mika Kuoppala (2019-01-22 12:33:00)
> Chris Wilson writes:
>
> > This turns out to be quite useful if one happens to be debugging
> > semaphore deadlocks.
> >
> > Signed-off-by: Chris Wilson
> > ---
> > drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
> > 1 file changed, 11 insertions(+), 4 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
> > b/drivers/gpu/drm/i915/intel_hangcheck.c
> > index 7dc11fcb13de..741441daae32 100644
> > --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> > +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> > @@ -195,10 +195,6 @@ static void hangcheck_accumulate_sample(struct
> > intel_engine_cs *engine,
> > break;
> >
> > case ENGINE_DEAD:
> > - if (GEM_SHOW_DEBUG()) {
> > - struct drm_printer p = drm_debug_printer("hangcheck");
> > - intel_engine_dump(engine, , "%s\n", engine->name);
> > - }
> > break;
> >
> > default:
> > @@ -285,6 +281,17 @@ static void i915_hangcheck_elapsed(struct work_struct
> > *work)
> > wedged |= intel_engine_flag(engine);
> > }
> >
> > + if (GEM_SHOW_DEBUG() && (hung | stuck)) {
> > + struct drm_printer p = drm_debug_printer("hangcheck");
> > +
> > + for_each_engine(engine, dev_priv, id) {
> > + if (intel_engine_is_idle(engine))
> > + continue;
>
> Looks rather harmless tho there is that local_bh_disable.
> I was pondering if it was worthwhile to determine idle here
> with more lightweight approach, but as we already use
> the exact same method on determining hangcheck action, lets
> stick to this as it is should be then in parity with the
> engine action we got earlier.
Plus it's only for glancing at the dmesg; the error state is meant to be
the be-all-end-all of debugging information. I just find it convenient
when watching netconsole and most kernel bugs can be deduced from the
register state itself.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Use fb width to measure fb width instead of visible plane width when verify NV12
Using visible plane width for testing NV12 source suitability may fail
randomly when plane is clipped.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=109381
Signed-off-by: Juha-Pekka Heikkila
---
drivers/gpu/drm/i915/intel_sprite.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_sprite.c
b/drivers/gpu/drm/i915/intel_sprite.c
index b02d3d9..a15c5ef 100644
--- a/drivers/gpu/drm/i915/intel_sprite.c
+++ b/drivers/gpu/drm/i915/intel_sprite.c
@@ -1516,7 +1516,7 @@ static int skl_plane_check_nv12_rotation(const struct
intel_plane_state *plane_s
{
const struct drm_framebuffer *fb = plane_state->base.fb;
unsigned int rotation = plane_state->base.rotation;
- int src_w = drm_rect_width(_state->base.src) >> 16;
+ int src_w = plane_state->base.fb->width;
/* Display WA #1106 */
if (fb->format->format == DRM_FORMAT_NV12 && src_w & 3 &&
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/34] drm/i915: Refactor out intel_context_init()
Chris Wilson writes:
> Prior to adding a third instance of intel_context_init() and extending
> the information stored therewithin, refactor out the common assignments.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_gem_context.c | 7 ++-
> drivers/gpu/drm/i915/i915_gem_context.h | 8
> drivers/gpu/drm/i915/selftests/mock_context.c | 7 ++-
> 3 files changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.c
> b/drivers/gpu/drm/i915/i915_gem_context.c
> index 5933adbe3d99..fae68c4c4683 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.c
> +++ b/drivers/gpu/drm/i915/i915_gem_context.c
> @@ -338,11 +338,8 @@ __create_hw_context(struct drm_i915_private *dev_priv,
> ctx->i915 = dev_priv;
> ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
>
> - for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++) {
> - struct intel_context *ce = >__engine[n];
> -
> - ce->gem_context = ctx;
> - }
> + for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
> + intel_context_init(>__engine[n], ctx, dev_priv->engine[n]);
>
> INIT_RADIX_TREE(>handles_vma, GFP_KERNEL);
> INIT_LIST_HEAD(>handles_list);
> diff --git a/drivers/gpu/drm/i915/i915_gem_context.h
> b/drivers/gpu/drm/i915/i915_gem_context.h
> index f6d870b1f73e..47d82ce7ba6a 100644
> --- a/drivers/gpu/drm/i915/i915_gem_context.h
> +++ b/drivers/gpu/drm/i915/i915_gem_context.h
> @@ -364,4 +364,12 @@ static inline void i915_gem_context_put(struct
> i915_gem_context *ctx)
> kref_put(>ref, i915_gem_context_release);
> }
>
> +static inline void
> +intel_context_init(struct intel_context *ce,
> +struct i915_gem_context *ctx,
> +struct intel_engine_cs *engine)
> +{
> + ce->gem_context = ctx;
> +}
> +
Audience was also waiting intel_context_init_engines()
Reviewed-by: Mika Kuoppala
> #endif /* !__I915_GEM_CONTEXT_H__ */
> diff --git a/drivers/gpu/drm/i915/selftests/mock_context.c
> b/drivers/gpu/drm/i915/selftests/mock_context.c
> index d937bdff26f9..b646cdcdd602 100644
> --- a/drivers/gpu/drm/i915/selftests/mock_context.c
> +++ b/drivers/gpu/drm/i915/selftests/mock_context.c
> @@ -45,11 +45,8 @@ mock_context(struct drm_i915_private *i915,
> INIT_LIST_HEAD(>handles_list);
> INIT_LIST_HEAD(>hw_id_link);
>
> - for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++) {
> - struct intel_context *ce = >__engine[n];
> -
> - ce->gem_context = ctx;
> - }
> + for (n = 0; n < ARRAY_SIZE(ctx->__engine); n++)
> + intel_context_init(>__engine[n], ctx, i915->engine[n]);
>
> ret = i915_gem_context_pin_hw_id(ctx);
> if (ret < 0)
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/34] drm/i915/selftests: Refactor common live_test framework
On Mon, 21 Jan 2019 at 22:22, Chris Wilson wrote: > > Before adding yet another copy of struct live_test and its handler, > refactor the existing code into a common framework for live selftests. > For many live selftests, we want to know if the GPU hung or otherwise > misbehaved during the execution of the test (beyond any infraction in > the behaviour under test), live_test provides this by comparing the > GPU state before and after, alerting if it unexpectedly changed (e.g. > the reset counter changed). It also ensures that the GPU is idle before > and after the test, so that residual code running on the GPU is flushed > before testing. > > 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
Re: [Intel-gfx] [PATCH 03/34] drm/i915: Show all active engines on hangcheck
Chris Wilson writes:
> This turns out to be quite useful if one happens to be debugging
> semaphore deadlocks.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/intel_hangcheck.c | 15 +++
> 1 file changed, 11 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_hangcheck.c
> b/drivers/gpu/drm/i915/intel_hangcheck.c
> index 7dc11fcb13de..741441daae32 100644
> --- a/drivers/gpu/drm/i915/intel_hangcheck.c
> +++ b/drivers/gpu/drm/i915/intel_hangcheck.c
> @@ -195,10 +195,6 @@ static void hangcheck_accumulate_sample(struct
> intel_engine_cs *engine,
> break;
>
> case ENGINE_DEAD:
> - if (GEM_SHOW_DEBUG()) {
> - struct drm_printer p = drm_debug_printer("hangcheck");
> - intel_engine_dump(engine, , "%s\n", engine->name);
> - }
> break;
>
> default:
> @@ -285,6 +281,17 @@ static void i915_hangcheck_elapsed(struct work_struct
> *work)
> wedged |= intel_engine_flag(engine);
> }
>
> + if (GEM_SHOW_DEBUG() && (hung | stuck)) {
> + struct drm_printer p = drm_debug_printer("hangcheck");
> +
> + for_each_engine(engine, dev_priv, id) {
> + if (intel_engine_is_idle(engine))
> + continue;
Looks rather harmless tho there is that local_bh_disable.
I was pondering if it was worthwhile to determine idle here
with more lightweight approach, but as we already use
the exact same method on determining hangcheck action, lets
stick to this as it is should be then in parity with the
engine action we got earlier.
Reviewed-by: Mika Kuoppala
> +
> + intel_engine_dump(engine, , "%s\n", engine->name);
> + }
> + }
> +
> if (wedged) {
> dev_err(dev_priv->drm.dev,
> "GPU recovery timed out,"
> --
> 2.20.1
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/34] drm/i915: Refactor out intel_context_init()
On Mon, 21 Jan 2019 at 23:41, Chris Wilson wrote: > > Prior to adding a third instance of intel_context_init() and extending > the information stored therewithin, refactor out the common assignments. > > 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
Re: [Intel-gfx] [PATCH 24/34] drm/i915: Track the context's seqno in its own timeline HWSP
On 21/01/2019 22:21, Chris Wilson wrote:
Now that we have allocated ourselves a cacheline to store a breadcrumb,
we can emit a write from the GPU into the timeline's HWSP of the
per-context seqno as we complete each request. This drops the mirroring
of the per-engine HWSP and allows each context to operate independently.
We do not need to unwind the per-context timeline, and so requests are
always consistent with the timeline breadcrumb, greatly simplifying the
completion checks as we no longer need to be concerned about the
global_seqno changing mid check.
One complication though is that we have to be wary that the request may
outlive the HWSP and so avoid touching the potentially danging pointer
after we have retired the fence. We also have to guard our access of the
HWSP with RCU, the release of the obj->mm.pages should already be RCU-safe.
At this point, we are emitting both per-context and global seqno and
still using the single per-engine execution timeline for resolving
interrupts.
v2: s/fake_complete/mark_complete/
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem.c | 2 +-
drivers/gpu/drm/i915/i915_request.c | 3 +-
drivers/gpu/drm/i915/i915_request.h | 30 +++
drivers/gpu/drm/i915/i915_reset.c| 1 +
drivers/gpu/drm/i915/i915_vma.h | 6 ++
drivers/gpu/drm/i915/intel_engine_cs.c | 7 +-
drivers/gpu/drm/i915/intel_lrc.c | 35 +---
drivers/gpu/drm/i915/intel_ringbuffer.c | 88 +++-
drivers/gpu/drm/i915/selftests/mock_engine.c | 20 -
9 files changed, 132 insertions(+), 60 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 761714448ff3..4e0de22f0166 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -2890,7 +2890,7 @@ i915_gem_find_active_request(struct intel_engine_cs
*engine)
*/
spin_lock_irqsave(>timeline.lock, flags);
list_for_each_entry(request, >timeline.requests, link) {
- if (__i915_request_completed(request, request->global_seqno))
+ if (i915_request_completed(request))
continue;
active = request;
diff --git a/drivers/gpu/drm/i915/i915_request.c
b/drivers/gpu/drm/i915/i915_request.c
index d61e86c6a1d1..bb2885f1dc1e 100644
--- a/drivers/gpu/drm/i915/i915_request.c
+++ b/drivers/gpu/drm/i915/i915_request.c
@@ -199,6 +199,7 @@ static void __retire_engine_request(struct intel_engine_cs
*engine,
spin_unlock(>timeline.lock);
spin_lock(>lock);
+ i915_request_mark_complete(rq);
if (!i915_request_signaled(rq))
dma_fence_signal_locked(>fence);
if (test_bit(DMA_FENCE_FLAG_ENABLE_SIGNAL_BIT, >fence.flags))
@@ -621,7 +622,7 @@ i915_request_alloc(struct intel_engine_cs *engine, struct
i915_gem_context *ctx)
rq->ring = ce->ring;
rq->timeline = ce->ring->timeline;
GEM_BUG_ON(rq->timeline == >timeline);
- rq->hwsp_seqno = >status_page.addr[I915_GEM_HWS_INDEX];
+ rq->hwsp_seqno = rq->timeline->hwsp_seqno;
spin_lock_init(>lock);
dma_fence_init(>fence,
diff --git a/drivers/gpu/drm/i915/i915_request.h
b/drivers/gpu/drm/i915/i915_request.h
index ade010fe6e26..96c586d6ff4d 100644
--- a/drivers/gpu/drm/i915/i915_request.h
+++ b/drivers/gpu/drm/i915/i915_request.h
@@ -289,6 +289,7 @@ long i915_request_wait(struct i915_request *rq,
static inline bool i915_request_signaled(const struct i915_request *rq)
{
+ /* The request may live longer than its HWSP, so check flags first! */
return test_bit(DMA_FENCE_FLAG_SIGNALED_BIT, >fence.flags);
}
@@ -340,32 +341,23 @@ static inline u32 hwsp_seqno(const struct i915_request *rq)
*/
static inline bool i915_request_started(const struct i915_request *rq)
{
- u32 seqno;
-
- seqno = i915_request_global_seqno(rq);
- if (!seqno) /* not yet submitted to HW */
- return false;
+ if (i915_request_signaled(rq))
+ return true;
- return i915_seqno_passed(hwsp_seqno(rq), seqno - 1);
-}
-
-static inline bool
-__i915_request_completed(const struct i915_request *rq, u32 seqno)
-{
- GEM_BUG_ON(!seqno);
- return i915_seqno_passed(hwsp_seqno(rq), seqno) &&
- seqno == i915_request_global_seqno(rq);
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno - 1);
}
static inline bool i915_request_completed(const struct i915_request *rq)
{
- u32 seqno;
+ if (i915_request_signaled(rq))
+ return true;
- seqno = i915_request_global_seqno(rq);
- if (!seqno)
- return false;
+ return i915_seqno_passed(hwsp_seqno(rq), rq->fence.seqno);
+}
- return __i915_request_completed(rq, seqno);
+static inline void i915_request_mark_complete(struct i915_request *rq)
+{
+ rq->hwsp_seqno = (u32 *)>fence.seqno; /*
Re: [Intel-gfx] [PATCH 3/4] drm/i915/vbt: Parse and use the new field with PSR2 TP2/3/4 wakeup time
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> A new field with the training pattern(TP) wakeup time for PSR2 was
> added to VBT, so lets use it when available otherwise it will
> fallback to PSR1 wakeup time.
Same problems as with the two previous patches:
- The new field name is too long.
- The abstraction between VBT and hardware is lost.
BR,
Jani.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 8
> drivers/gpu/drm/i915/intel_bios.c | 10 ++
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> drivers/gpu/drm/i915/intel_vbt_defs.h | 3 +++
> 4 files changed, 22 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index d9893d35f0e2..e739ed9ce60c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -967,6 +967,13 @@ enum psr_tp_wakeup_time {
> PSR_TP_WAKEUP_TIME_LAST
> };
>
> +enum psr2_tp_wakeup_time {
> + PSR2_TP_WAKEUP_TIME_500USEC = 0,
> + PSR2_TP_WAKEUP_TIME_100USEC,
> + PSR2_TP_WAKEUP_TIME_2500USEC,
> + PSR2_TP_WAKEUP_TIME_50USEC
> +};
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -1005,6 +1012,7 @@ struct intel_vbt_data {
> enum psr_lines_to_wait lines_to_wait;
> enum psr_tp_wakeup_time tp1_wakeup_time;
> enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
> + enum psr2_tp_wakeup_time psr2_tp2_tp3_tp4_wakeup_time;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 6de6f6f1deec..23130e0d5e6c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -757,6 +757,16 @@ parse_psr(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
>
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time = wakeup_time;
> }
> +
> + if (bdb->version >= 226) {
> + u32 wakeup_time = psr_table->psr2_tp2_tp3_tp4_wakeup_time;
> +
> + wakeup_time = (wakeup_time >> (2 * panel_type)) & 0x3;
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time = wakeup_time;
> + } else {
> + /* Reusing PSR1 wakeup time for PSR2 in older VBTs */
> + dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time =
> dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time;
> + }
> }
>
> static void parse_dsi_backlight_ports(struct drm_i915_private *dev_priv,
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 5daf0b9e2b42..2fc537fb6e78 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -494,7 +494,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>
> - val |= dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
> + val |= dev_priv->vbt.psr.psr2_tp2_tp3_tp4_wakeup_time <<
> EDP_PSR2_TP2_TP3_TIME_SHIFT;
>
> I915_WRITE(EDP_PSR2_CTL, val);
> }
> diff --git a/drivers/gpu/drm/i915/intel_vbt_defs.h
> b/drivers/gpu/drm/i915/intel_vbt_defs.h
> index 4ed66efde49f..dc0a14977953 100644
> --- a/drivers/gpu/drm/i915/intel_vbt_defs.h
> +++ b/drivers/gpu/drm/i915/intel_vbt_defs.h
> @@ -772,6 +772,9 @@ struct psr_table {
> /* TP wake up time in multiple of 100 */
> u16 tp1_wakeup_time;
> u16 tp2_tp3_tp4_wakeup_time;
> +
> + /* PSR2 TP2/TP3/TP4 wakeup time for 16 panels */
> + u32 psr2_tp2_tp3_tp4_wakeup_time;
> } __packed;
>
> struct bdb_psr {
--
Jani Nikula, Intel Open Source Graphics Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/4] drm/i915/psr: Store VBT TP wakeup times into a enum
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> Newer VBTs and the PSR registers uses a enum to set the TPs wakeup
> time, so lets use this format to store wakeup times and avoid
> conversions every time that PSR is activated.
The VBT is a messy blob of data, and intel_bios.c in many places tries
very hard to abstract and hide all the quirks in there from the
driver. Observe how intel_vbt_defs.h has extra safeguards to try to keep
it private to intel_bios.c. We don't want the VBT implementation details
to leak into the driver.
This patch goes against that abstraction. Please don't do it.
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 12 +-
> drivers/gpu/drm/i915/i915_reg.h | 16 ++--
> drivers/gpu/drm/i915/intel_bios.c | 65 +++
> drivers/gpu/drm/i915/intel_psr.c | 29 ++
> 4 files changed, 47 insertions(+), 75 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e717c3132692..d9893d35f0e2 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -959,6 +959,14 @@ enum psr_lines_to_wait {
> PSR_8_LINES_TO_WAIT
> };
>
> +enum psr_tp_wakeup_time {
> + PSR_TP_WAKEUP_TIME_500USEC = 0,
> + PSR_TP_WAKEUP_TIME_100USEC,
> + PSR_TP_WAKEUP_TIME_2500USEC,
> + PSR_TP_WAKEUP_TIME_NONE,
> + PSR_TP_WAKEUP_TIME_LAST
> +};
Here's the problem. This enum now describes both the VBT internals as
well as the hardware register contents. Imagine either the VBT or the
hardware changing to a different bit layout. You'll be in trouble
decoupling them again. (Yeah, they'll say neither will change. They've
said things like that before.)
Moreover, this looks like an innocent enumeration here, separated from
both the VBT parsing and the hardware.
The VBT needs to be described in intel_vbt_defs.h and intel_bios.c, and
the register needs to be desribed in i915_regs.h.
> +
> struct intel_vbt_data {
> struct drm_display_mode *lfp_lvds_vbt_mode; /* if any */
> struct drm_display_mode *sdvo_lvds_vbt_mode; /* if any */
> @@ -995,8 +1003,8 @@ struct intel_vbt_data {
> bool require_aux_wakeup;
> int idle_frames;
> enum psr_lines_to_wait lines_to_wait;
> - int tp1_wakeup_time_us;
> - int tp2_tp3_tp4_wakeup_time_us;
> + enum psr_tp_wakeup_time tp1_wakeup_time;
> + enum psr_tp_wakeup_time tp2_tp3_tp4_wakeup_time;
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index fad5a9e8b44d..5faca634ee70 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -4161,14 +4161,8 @@ enum {
> #define EDP_PSR_TP1_TP2_SEL(0 << 11)
> #define EDP_PSR_TP1_TP3_SEL(1 << 11)
> #define EDP_PSR_CRC_ENABLE (1 << 10) /* BDW+ */
> -#define EDP_PSR_TP2_TP3_TIME_500us (0 << 8)
> -#define EDP_PSR_TP2_TP3_TIME_100us (1 << 8)
> -#define EDP_PSR_TP2_TP3_TIME_2500us(2 << 8)
> -#define EDP_PSR_TP2_TP3_TIME_0us (3 << 8)
> -#define EDP_PSR_TP1_TIME_500us (0 << 4)
> -#define EDP_PSR_TP1_TIME_100us (1 << 4)
> -#define EDP_PSR_TP1_TIME_2500us(2 << 4)
> -#define EDP_PSR_TP1_TIME_0us (3 << 4)
> +#define EDP_PSR_TP2_TP3_TIME_SHIFT (8)
> +#define EDP_PSR_TP1_TIME_SHIFT (4)
Please do not remove these. They describe the register contents as we
understand them, and not everyone has access or cares to dig up bspec
every time they need to figure things out.
Side note, parens are superfluous for plain values.
> #define EDP_PSR_IDLE_FRAME_SHIFT 0
>
> /* Bspec claims those aren't shifted but stay at 0x64800 */
> @@ -4234,11 +4228,7 @@ enum {
> #define EDP_Y_COORDINATE_ENABLE(1 << 25) /* GLK and CNL+ */
> #define EDP_MAX_SU_DISABLE_TIME(t) ((t) << 20)
> #define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f << 20)
> -#define EDP_PSR2_TP2_TIME_500us(0 << 8)
> -#define EDP_PSR2_TP2_TIME_100us(1 << 8)
> -#define EDP_PSR2_TP2_TIME_2500us (2 << 8)
> -#define EDP_PSR2_TP2_TIME_50us (3 << 8)
> -#define EDP_PSR2_TP2_TIME_MASK (3 << 8)
> +#define EDP_PSR2_TP2_TP3_TIME_SHIFT(8)
Ditto.
> #define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> #define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf << 4)
> #define EDP_PSR2_FRAME_BEFORE_SU(a)((a) << 4)
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index cd99bf88bf6c..6de6f6f1deec 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -719,46 +719,43 @@ parse_psr(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
> if (bdb->version >= 205 &&
>
Re: [Intel-gfx] [PATCH 06/34] drm/i915/selftests: Create a clean GGTT for vma/gtt selftesting
On Mon, 21 Jan 2019 at 23:41, Chris Wilson wrote: > > Some tests (e.g. igt_vma_pin1) presume that we have a completely clean > GGTT so that it can probe boundaries without fear that something is > already allocated there. However, the mock device is starting to get > complicated and following similar rules to the live device, i.e. we > can't guarantee that i915->ggtt remains clean, so create a temporary > address_space equivalent to the mock ggtt for the purpose. > > 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
Re: [Intel-gfx] [PATCH 2/5] drm/i915: always return something
Patch look ok to me.
On Thu, 2019-01-17 at 12:21 -0800, Lucas De Marchi wrote:
> Even if we don't have the correct clock and get a warning, we should
> not
> skip the return.
>
> Fixes: 1fa11ee2d9d0 ("drm/i915/icl: start adding the TBT pll")
> Cc: Paulo Zanoni
> Cc: # v4.19+
Reviewed-by: Mika Kahola
> Signed-off-by: Lucas De Marchi
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8dbf6c9e22fb..4dc03e8c6c10 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1021,7 +1021,7 @@ static uint32_t icl_pll_to_ddi_pll_sel(struct
> intel_encoder *encoder,
> return DDI_CLK_SEL_TBT_810;
> default:
> MISSING_CASE(clock);
> - break;
> + return DDI_CLK_SEL_NONE;
> }
> case DPLL_ID_ICL_MGPLL1:
> case DPLL_ID_ICL_MGPLL2:
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 05/34] drm/i915/selftests: Track evict objects explicitly
On Mon, 21 Jan 2019 at 22:22, Chris Wilson wrote:
>
> During review of commit 71fc448c1aaf ("drm/i915/selftests: Make evict
> tolerant of foreign objects"), Matthew mentioned it would be better if
> we explicitly tracked the objects we created. We have an obj->st_link
> hook for this purpose, so add the corresponding list of objects and
> reduce our loops to only consider our own list.
>
> References: 71fc448c1aaf ("drm/i915/selftests: Make evict tolerant of foreign
> objects")
> 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
Re: [Intel-gfx] [PATCH 1/4] drm/i915/vbt: Add 'tp4' to varibles holding TP2/3/4 PSR wakeup time
On Wed, 16 Jan 2019, José Roberto de Souza wrote:
> Recent update in spec made the field holding the TP2 and TP3 wakeup
> time for PSR also hold the TP4, so lets rename the variables to
> reflect that.
>
> BSpec: 20131
>
> Cc: Dhinakaran Pandiyan
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 2 +-
> drivers/gpu/drm/i915/intel_bios.c | 16
> drivers/gpu/drm/i915/intel_psr.c | 14 +++---
> drivers/gpu/drm/i915/intel_vbt_defs.h | 2 +-
> 4 files changed, 17 insertions(+), 17 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 310d9e1e1620..e717c3132692 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -996,7 +996,7 @@ struct intel_vbt_data {
> int idle_frames;
> enum psr_lines_to_wait lines_to_wait;
> int tp1_wakeup_time_us;
> - int tp2_tp3_wakeup_time_us;
> + int tp2_tp3_tp4_wakeup_time_us;
I think this is too long, perhaps just tp234_wakeup_time_us or
something?
BR,
Jani.
> } psr;
>
> struct {
> diff --git a/drivers/gpu/drm/i915/intel_bios.c
> b/drivers/gpu/drm/i915/intel_bios.c
> index 561a4f9f044c..cd99bf88bf6c 100644
> --- a/drivers/gpu/drm/i915/intel_bios.c
> +++ b/drivers/gpu/drm/i915/intel_bios.c
> @@ -738,27 +738,27 @@ parse_psr(struct drm_i915_private *dev_priv, const
> struct bdb_header *bdb)
> break;
> }
>
> - switch (psr_table->tp2_tp3_wakeup_time) {
> + switch (psr_table->tp2_tp3_tp4_wakeup_time) {
> case 0:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 500;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 500;
> break;
> case 1:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 100;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 100;
> break;
> case 3:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 0;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 0;
> break;
> default:
> - DRM_DEBUG_KMS("VBT tp2_tp3 wakeup time value %d is
> outside range[0-3], defaulting to max value 2500us\n",
> - psr_table->tp2_tp3_wakeup_time);
> + DRM_DEBUG_KMS("VBT tp2_tp3_tp4 wakeup time value %d is
> outside range[0-3], defaulting to max value 2500us\n",
> + psr_table->tp2_tp3_tp4_wakeup_time);
> /* fallthrough */
> case 2:
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us = 2500;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us = 2500;
> break;
> }
> } else {
> dev_priv->vbt.psr.tp1_wakeup_time_us =
> psr_table->tp1_wakeup_time * 100;
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us =
> psr_table->tp2_tp3_wakeup_time * 100;
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us =
> psr_table->tp2_tp3_tp4_wakeup_time * 100;
> }
> }
>
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 0f6b2b4702e3..49b4b3371bef 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -468,11 +468,11 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
> else
> val |= EDP_PSR_TP1_TIME_2500us;
>
> - if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us == 0)
> + if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us == 0)
> val |= EDP_PSR_TP2_TP3_TIME_0us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
> + else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 100)
> val |= EDP_PSR_TP2_TP3_TIME_100us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
> + else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 500)
> val |= EDP_PSR_TP2_TP3_TIME_500us;
> else
> val |= EDP_PSR_TP2_TP3_TIME_2500us;
> @@ -509,12 +509,12 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>
> val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>
> - if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us >= 0 &&
> - dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 50)
> + if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us >= 0 &&
> + dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 50)
> val |= EDP_PSR2_TP2_TIME_50us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 100)
> + else if (dev_priv->vbt.psr.tp2_tp3_tp4_wakeup_time_us <= 100)
> val |= EDP_PSR2_TP2_TIME_100us;
> - else if (dev_priv->vbt.psr.tp2_tp3_wakeup_time_us <= 500)
> + else if
Re: [Intel-gfx] [PATCH 23/34] drm/i915: Share per-timeline HWSP using a slab suballocator
On 22/01/2019 11:12, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 10:47:11)
On 21/01/2019 22:21, Chris Wilson wrote:
If we restrict ourselves to only using a cacheline for each timeline's
HWSP (we could go smaller, but want to avoid needless polluting
cachelines on different engines between different contexts), then we can
suballocate a single 4k page into 64 different timeline HWSP. By
treating each fresh allocation as a slab of 64 entries, we can keep it
around for the next 64 allocation attempts until we need to refresh the
slab cache.
John Harrison noted the issue of fragmentation leading to the same worst
case performance of one page per timeline as before, which can be
mitigated by adopting a freelist.
v2: Keep all partially allocated HWSP on a freelist
This is still without migration, so it is possible for the system to end
up with each timeline in its own page, but we ensure that no new
allocation would needless allocate a fresh page!
v3: Throw a selftest at the allocator to try and catch invalid cacheline
reuse.
Signed-off-by: Chris Wilson
Cc: John Harrison
---
drivers/gpu/drm/i915/i915_drv.h | 4 +
drivers/gpu/drm/i915/i915_timeline.c | 117 ---
drivers/gpu/drm/i915/i915_timeline.h | 1 +
drivers/gpu/drm/i915/i915_vma.h | 12 ++
drivers/gpu/drm/i915/selftests/i915_random.c | 33 -
drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
.../gpu/drm/i915/selftests/i915_timeline.c| 140 ++
7 files changed, 282 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 364067f811f7..c00eaf2889fb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1978,6 +1978,10 @@ struct drm_i915_private {
struct i915_gt_timelines {
struct mutex mutex; /* protects list, tainted by GPU */
struct list_head list;
+
+ /* Pack multiple timelines' seqnos into the same page */
+ spinlock_t hwsp_lock;
+ struct list_head hwsp_free_list;
} timelines;
struct list_head active_rings;
diff --git a/drivers/gpu/drm/i915/i915_timeline.c
b/drivers/gpu/drm/i915/i915_timeline.c
index 8d5792311a8f..69ee33dfa340 100644
--- a/drivers/gpu/drm/i915/i915_timeline.c
+++ b/drivers/gpu/drm/i915/i915_timeline.c
@@ -9,6 +9,12 @@
#include "i915_timeline.h"
#include "i915_syncmap.h"
+struct i915_timeline_hwsp {
+ struct i915_vma *vma;
+ struct list_head free_link;
+ u64 free_bitmap;
+};
+
static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
{
struct drm_i915_gem_object *obj;
@@ -27,28 +33,92 @@ static struct i915_vma *__hwsp_alloc(struct
drm_i915_private *i915)
return vma;
}
-static int hwsp_alloc(struct i915_timeline *timeline)
+static struct i915_vma *
+hwsp_alloc(struct i915_timeline *timeline, int *offset)
{
- struct i915_vma *vma;
+ struct drm_i915_private *i915 = timeline->i915;
+ struct i915_gt_timelines *gt = >gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+ int cacheline;
- vma = __hwsp_alloc(timeline->i915);
- if (IS_ERR(vma))
- return PTR_ERR(vma);
+ BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
- timeline->hwsp_ggtt = vma;
- timeline->hwsp_offset = 0;
+ spin_lock(>hwsp_lock);
- return 0;
+ /* hwsp_free_list only contains HWSP that have available cachelines */
+ hwsp = list_first_entry_or_null(>hwsp_free_list,
+ typeof(*hwsp), free_link);
+ if (!hwsp) {
+ struct i915_vma *vma;
+
+ spin_unlock(>hwsp_lock);
+
+ hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
+ if (!hwsp)
+ return ERR_PTR(-ENOMEM);
+
+ vma = __hwsp_alloc(i915);
+ if (IS_ERR(vma)) {
+ kfree(hwsp);
+ return vma;
+ }
+
+ vma->private = hwsp;
+ hwsp->vma = vma;
+ hwsp->free_bitmap = ~0ull;
+
+ spin_lock(>hwsp_lock);
+ list_add(>free_link, >hwsp_free_list);
+ }
+
+ GEM_BUG_ON(!hwsp->free_bitmap);
+ cacheline = __ffs64(hwsp->free_bitmap);
+ hwsp->free_bitmap &= ~BIT_ULL(cacheline);
+ if (!hwsp->free_bitmap)
+ list_del(>free_link);
+
+ spin_unlock(>hwsp_lock);
+
+ GEM_BUG_ON(hwsp->vma->private != hwsp);
+
+ *offset = cacheline * CACHELINE_BYTES;
+ return hwsp->vma;
+}
+
+static void hwsp_free(struct i915_timeline *timeline)
+{
+ struct i915_gt_timelines *gt = >i915->gt.timelines;
+ struct i915_timeline_hwsp *hwsp;
+
+ hwsp = i915_timeline_hwsp(timeline);
+ if (!hwsp) /* leave global HWSP alone! */
Later you add i915_timeline_is_global so
Re: [Intel-gfx] [PATCH 23/34] drm/i915: Share per-timeline HWSP using a slab suballocator
Quoting Tvrtko Ursulin (2019-01-22 10:47:11)
>
> On 21/01/2019 22:21, Chris Wilson wrote:
> > If we restrict ourselves to only using a cacheline for each timeline's
> > HWSP (we could go smaller, but want to avoid needless polluting
> > cachelines on different engines between different contexts), then we can
> > suballocate a single 4k page into 64 different timeline HWSP. By
> > treating each fresh allocation as a slab of 64 entries, we can keep it
> > around for the next 64 allocation attempts until we need to refresh the
> > slab cache.
> >
> > John Harrison noted the issue of fragmentation leading to the same worst
> > case performance of one page per timeline as before, which can be
> > mitigated by adopting a freelist.
> >
> > v2: Keep all partially allocated HWSP on a freelist
> >
> > This is still without migration, so it is possible for the system to end
> > up with each timeline in its own page, but we ensure that no new
> > allocation would needless allocate a fresh page!
> >
> > v3: Throw a selftest at the allocator to try and catch invalid cacheline
> > reuse.
> >
> > Signed-off-by: Chris Wilson
> > Cc: John Harrison
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 4 +
> > drivers/gpu/drm/i915/i915_timeline.c | 117 ---
> > drivers/gpu/drm/i915/i915_timeline.h | 1 +
> > drivers/gpu/drm/i915/i915_vma.h | 12 ++
> > drivers/gpu/drm/i915/selftests/i915_random.c | 33 -
> > drivers/gpu/drm/i915/selftests/i915_random.h | 3 +
> > .../gpu/drm/i915/selftests/i915_timeline.c| 140 ++
> > 7 files changed, 282 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 364067f811f7..c00eaf2889fb 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -1978,6 +1978,10 @@ struct drm_i915_private {
> > struct i915_gt_timelines {
> > struct mutex mutex; /* protects list, tainted by GPU
> > */
> > struct list_head list;
> > +
> > + /* Pack multiple timelines' seqnos into the same page
> > */
> > + spinlock_t hwsp_lock;
> > + struct list_head hwsp_free_list;
> > } timelines;
> >
> > struct list_head active_rings;
> > diff --git a/drivers/gpu/drm/i915/i915_timeline.c
> > b/drivers/gpu/drm/i915/i915_timeline.c
> > index 8d5792311a8f..69ee33dfa340 100644
> > --- a/drivers/gpu/drm/i915/i915_timeline.c
> > +++ b/drivers/gpu/drm/i915/i915_timeline.c
> > @@ -9,6 +9,12 @@
> > #include "i915_timeline.h"
> > #include "i915_syncmap.h"
> >
> > +struct i915_timeline_hwsp {
> > + struct i915_vma *vma;
> > + struct list_head free_link;
> > + u64 free_bitmap;
> > +};
> > +
> > static struct i915_vma *__hwsp_alloc(struct drm_i915_private *i915)
> > {
> > struct drm_i915_gem_object *obj;
> > @@ -27,28 +33,92 @@ static struct i915_vma *__hwsp_alloc(struct
> > drm_i915_private *i915)
> > return vma;
> > }
> >
> > -static int hwsp_alloc(struct i915_timeline *timeline)
> > +static struct i915_vma *
> > +hwsp_alloc(struct i915_timeline *timeline, int *offset)
> > {
> > - struct i915_vma *vma;
> > + struct drm_i915_private *i915 = timeline->i915;
> > + struct i915_gt_timelines *gt = >gt.timelines;
> > + struct i915_timeline_hwsp *hwsp;
> > + int cacheline;
> >
> > - vma = __hwsp_alloc(timeline->i915);
> > - if (IS_ERR(vma))
> > - return PTR_ERR(vma);
> > + BUILD_BUG_ON(BITS_PER_TYPE(u64) * CACHELINE_BYTES > PAGE_SIZE);
> >
> > - timeline->hwsp_ggtt = vma;
> > - timeline->hwsp_offset = 0;
> > + spin_lock(>hwsp_lock);
> >
> > - return 0;
> > + /* hwsp_free_list only contains HWSP that have available cachelines */
> > + hwsp = list_first_entry_or_null(>hwsp_free_list,
> > + typeof(*hwsp), free_link);
> > + if (!hwsp) {
> > + struct i915_vma *vma;
> > +
> > + spin_unlock(>hwsp_lock);
> > +
> > + hwsp = kmalloc(sizeof(*hwsp), GFP_KERNEL);
> > + if (!hwsp)
> > + return ERR_PTR(-ENOMEM);
> > +
> > + vma = __hwsp_alloc(i915);
> > + if (IS_ERR(vma)) {
> > + kfree(hwsp);
> > + return vma;
> > + }
> > +
> > + vma->private = hwsp;
> > + hwsp->vma = vma;
> > + hwsp->free_bitmap = ~0ull;
> > +
> > + spin_lock(>hwsp_lock);
> > + list_add(>free_link, >hwsp_free_list);
> > + }
> > +
> > + GEM_BUG_ON(!hwsp->free_bitmap);
> > + cacheline = __ffs64(hwsp->free_bitmap);
> > + hwsp->free_bitmap &= ~BIT_ULL(cacheline);
> > + if (!hwsp->free_bitmap)
> > + list_del(>free_link);
> > +
> > +
Re: [Intel-gfx] [PATCH 27/38] drm/i915: Introduce the i915_user_extension_method
On 22/01/2019 10:47, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-22 09:31:31)
On 18/01/2019 14:00, Chris Wilson wrote:
+/*
+ * SPDX-License-Identifier: MIT
+ *
+ * Copyright © 2018 Intel Corporation
+ */
+
+#include
+#include
+#include
+
+#include "i915_user_extensions.h"
+
+int i915_user_extensions(struct i915_user_extension __user *ext,
+ const i915_user_extension_fn *tbl,
+ unsigned long count,
I would be tempted to limit the count to unsigned int. 4 billion
extensions should be enough for everyone. :)
I just picked the natural type, thinking having it the same width as
ARRAY_SIZE might save a few questions from semantic analysers.
+{
+ while (ext) {
+ int err;
+ u64 x;
+
+ cond_resched();
+ if (signal_pending(current))
+ return -EINTR;
What was your thinking behind this? It feels like, since here we are not
doing any explicit wait/sleeps, that at this level the code shouldn't
bother with it.
This ties into the discussion vvv
+ if (get_user(x, >name))
+ return -EFAULT;
+
+ err = -EINVAL;
+ if (x < count && tbl[x])
+ err = tbl[x](ext, data);
+ if (err)
+ return err;
We talked about providing unwind on failure ie. option for destructor
call backs. You gave up on that?
The patch is simply called 'merde'. Yes, unwind on failure does not lend
itself to a simple tail call implementation :) And it doesn't lend
itself nicely to writing the stacked cleanup handlers either. (So I
stuck with the solution of just doing a single cleanup on failure, safe
in the knowledge that the most complicated case in this series is
trivial.)
Thinking about the issues with providing a stack for unwind, leads to
the nasty question of how big a stack exactly do we want to provide.
Limiting the chain is required for defense against misuse, but what
depth? For the chained parameter setup of a single shot context create,
we could easily be into the dozens of parameters and extensions blocks.
The extreme I've been contemplating is a multi-batch execbuf setup (with
all the fancy extensions for e.g. semi-privileged fancy register setup),
for that I've been thinking about how this interface would extend to
supporting many chained chunks. What makes a good upper bound for stack
depth? 32? 64? 512? Pick a number, it won't be enough for someone. (Now,
really passing that much information through an ioctl means our design
is broken ;)
So... The break on interrupt there was for the silly protection against
recursion, if it doesn't result in an invalid command.
Another reason the patch was called merde.
I think the chained API extension is very powerful. Being able to do
arbitrary things like a single-shot context creation ioctl and still be
able to redefine/extend the interface as needs demands, is compelling.
I did not think about unwind implementation details. :)
We could make the ABI double linked list? But the feeling is bad..
Or have some reasonable stack size and if overflows fall back to a very
inefficient lookup from root to walk backwards. Sounds okay for this use
case since we would never overflow even a small stack, and even the
inefficient walk on unwind would be a) fast and b) rare.
But since you mention stack sizes like 512 I wonder I did not quite
grasp how much you'd want to use extensions in the future. :)
+/*
+ * i915_user_extension: Base class for defining a chain of extensions
+ *
+ * Many interfaces need to grow over time. In most cases we can simply
+ * extend the struct and have userspace pass in more data. Another option,
+ * as demonstrated by Vulkan's approach to providing extensions for forward
+ * and backward compatibility, is to use a list of optional structs to
+ * provide those extra details.
+ *
+ * The key advantage to using an extension chain is that it allows us to
+ * redefine the interface more easily than an ever growing struct of
+ * increasing complexity, and for large parts of that interface to be
+ * entirely optional. The downside is more pointer chasing; chasing across
+ * the __user boundary with pointers encapsulated inside u64.
+ */
+struct i915_user_extension {
+ __u64 next_extension;
+ __u64 name;
s/name/id/ ?
I think name is common parlance for extensions/parameters? At least I've
been using it like it was :) And I was trying to retrospectively restrict
'id' for handles tracked by an idr! :)
I don't know if it is common, it is completely new to me. Maybe it is..
Or how about type?
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
