Re: [Intel-gfx] [PATCH 2/2] drm/i915/ehl/dsi: Enable AFE over PPI strap
> -Original Message-
> From: Kulkarni, Vandita
> Sent: Wednesday, June 19, 2019 10:49 AM
> To: José Roberto de Souza ; intel-
> g...@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: RE: [Intel-gfx] [PATCH 2/2] drm/i915/ehl/dsi: Enable AFE over PPI
> strap
>
> > -Original Message-
> > From: Intel-gfx On Behalf Of
> > José Roberto de Souza
> > Sent: Wednesday, June 19, 2019 1:30 AM
> > To: intel-gfx@lists.freedesktop.org
> > Cc: Nikula, Jani
> > Subject: [Intel-gfx] [PATCH 2/2] drm/i915/ehl/dsi: Enable AFE over PPI
> > strap
> >
> > The other additional step in the DSI sequqence for EHL.
A correction in "sequence" will be needed though.
Thanks,
Vandita
> >
> > BSpec: 20597
> > Cc: Uma Shankar
> > Cc: Jani Nikula
> > Signed-off-by: José Roberto de Souza
> > ---
> Looks good to me.
> Reviewed-by: Vandita Kulkarni
>
> Thanks.
> Vandita
> > drivers/gpu/drm/i915/display/icl_dsi.c | 8
> > drivers/gpu/drm/i915/i915_reg.h| 4
> > 2 files changed, 12 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> > b/drivers/gpu/drm/i915/display/icl_dsi.c
> > index ee85428b309f..3a601c739fc6 100644
> > --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> > +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> > @@ -542,6 +542,14 @@ static void gen11_dsi_setup_dphy_timings(struct
> > intel_encoder *encoder)
> > I915_WRITE(DSI_TA_TIMING_PARAM(port), tmp);
> > }
> > }
> > +
> > + if (IS_ELKHARTLAKE(dev_priv)) {
> > + for_each_dsi_port(port, intel_dsi->ports) {
> > + tmp = I915_READ(ICL_DPHY_CHKN(port));
> > + tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
> > + I915_WRITE(ICL_DPHY_CHKN(port), tmp);
> > + }
> > + }
> > }
> >
> > static void gen11_dsi_gate_clocks(struct intel_encoder *encoder) diff
> > --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h index
> > 1f2c3ebdf87b..dc7b34cf8b42 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -1993,6 +1993,10 @@ enum i915_power_well_id {
> > #define N_SCALAR(x) ((x) << 24)
> > #define N_SCALAR_MASK(0x7F << 24)
> >
> > +#define _ICL_DPHY_CHKN_REG 0x194
> > +#define ICL_DPHY_CHKN(port)
> > _MMIO(_ICL_COMBOPHY(port) + _ICL_DPHY_CHKN_REG)
> > +#define ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP (1 << 7)
> > +
> > #define MG_PHY_PORT_LN(ln, port, ln0p1, ln0p2, ln1p1) \
> > _MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) -
> > (ln0p1)))
> >
> > --
> > 2.22.0
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/ehl/dsi: Enable AFE over PPI strap
> -Original Message-
> From: Intel-gfx On Behalf Of José
> Roberto de Souza
> Sent: Wednesday, June 19, 2019 1:30 AM
> To: intel-gfx@lists.freedesktop.org
> Cc: Nikula, Jani
> Subject: [Intel-gfx] [PATCH 2/2] drm/i915/ehl/dsi: Enable AFE over PPI strap
>
> The other additional step in the DSI sequqence for EHL.
>
> BSpec: 20597
> Cc: Uma Shankar
> Cc: Jani Nikula
> Signed-off-by: José Roberto de Souza
> ---
Looks good to me.
Reviewed-by: Vandita Kulkarni
Thanks.
Vandita
> drivers/gpu/drm/i915/display/icl_dsi.c | 8
> drivers/gpu/drm/i915/i915_reg.h| 4
> 2 files changed, 12 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
> b/drivers/gpu/drm/i915/display/icl_dsi.c
> index ee85428b309f..3a601c739fc6 100644
> --- a/drivers/gpu/drm/i915/display/icl_dsi.c
> +++ b/drivers/gpu/drm/i915/display/icl_dsi.c
> @@ -542,6 +542,14 @@ static void gen11_dsi_setup_dphy_timings(struct
> intel_encoder *encoder)
> I915_WRITE(DSI_TA_TIMING_PARAM(port), tmp);
> }
> }
> +
> + if (IS_ELKHARTLAKE(dev_priv)) {
> + for_each_dsi_port(port, intel_dsi->ports) {
> + tmp = I915_READ(ICL_DPHY_CHKN(port));
> + tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
> + I915_WRITE(ICL_DPHY_CHKN(port), tmp);
> + }
> + }
> }
>
> static void gen11_dsi_gate_clocks(struct intel_encoder *encoder) diff --git
> a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h index
> 1f2c3ebdf87b..dc7b34cf8b42 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -1993,6 +1993,10 @@ enum i915_power_well_id {
> #define N_SCALAR(x)((x) << 24)
> #define N_SCALAR_MASK (0x7F << 24)
>
> +#define _ICL_DPHY_CHKN_REG 0x194
> +#define ICL_DPHY_CHKN(port)
> _MMIO(_ICL_COMBOPHY(port) + _ICL_DPHY_CHKN_REG)
> +#define ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP (1 << 7)
> +
> #define MG_PHY_PORT_LN(ln, port, ln0p1, ln0p2, ln1p1) \
> _MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - (ln0p1)))
>
> --
> 2.22.0
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for Implicit dev_priv removal and GT compartmentalization (rev10)
== Series Details == Series: Implicit dev_priv removal and GT compartmentalization (rev10) URL : https://patchwork.freedesktop.org/series/62046/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6291_full -> Patchwork_13327_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13327_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13327_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13327_full: ### IGT changes ### Possible regressions * igt@i915_selftest@mock_timelines: - shard-skl: [PASS][1] -> [INCOMPLETE][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-skl2/igt@i915_selftest@mock_timelines.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-skl10/igt@i915_selftest@mock_timelines.html * igt@runner@aborted: - shard-hsw: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-hsw2/igt@run...@aborted.html - shard-iclb: NOTRUN -> ([FAIL][4], [FAIL][5], [FAIL][6], [FAIL][7], [FAIL][8]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-iclb1/igt@run...@aborted.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-iclb2/igt@run...@aborted.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-iclb4/igt@run...@aborted.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-iclb1/igt@run...@aborted.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-iclb8/igt@run...@aborted.html - shard-apl: NOTRUN -> [FAIL][9] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-apl5/igt@run...@aborted.html - shard-snb: NOTRUN -> [FAIL][10] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-snb2/igt@run...@aborted.html Warnings * igt@runner@aborted: - shard-kbl: [FAIL][11] ([fdo#110938]) -> ([FAIL][12], [FAIL][13], [FAIL][14], [FAIL][15], [FAIL][16], [FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21], [FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26], [FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39]) ([fdo#108903] / [fdo#108904] / [fdo#108905]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-kbl1/igt@run...@aborted.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl1/igt@run...@aborted.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl1/igt@run...@aborted.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl3/igt@run...@aborted.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl4/igt@run...@aborted.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl3/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl6/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl4/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl6/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl3/igt@run...@aborted.html [28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl6/igt@run...@aborted.html [29]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl4/igt@run...@aborted.html [30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [31]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl2/igt@run...@aborted.html [32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/shard-kbl4/igt@run...@aborted.html [33]:
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Check backlight type while doing eDP backlight initializaiton
== Series Details == Series: drm/i915: Check backlight type while doing eDP backlight initializaiton URL : https://patchwork.freedesktop.org/series/62362/ State : success == Summary == CI Bug Log - changes from CI_DRM_6300 -> Patchwork_13341 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/ Known issues Here are the changes found in Patchwork_13341 that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_switch@basic-default: - fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#108569]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@prime_vgem@basic-write: - fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-u3/igt@prime_v...@basic-write.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-icl-u3/igt@prime_v...@basic-write.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [INCOMPLETE][7] ([fdo#107718]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@gem_mmap_gtt@basic-read-no-prefault: - fi-icl-u3: [DMESG-WARN][9] ([fdo#107724]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][11] ([fdo#109485]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][13] ([fdo#103167]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html * igt@prime_busy@basic-wait-after-default: - fi-icl-dsi: [INCOMPLETE][15] ([fdo#107713]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-dsi/igt@prime_b...@basic-wait-after-default.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/fi-icl-dsi/igt@prime_b...@basic-wait-after-default.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (44 -> 36) -- Additional (1): fi-gdg-551 Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-hsw-peppy fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6300 -> Patchwork_13341 CI_DRM_6300: a0694108fecf62a79e0be32e578f25fdcbf466e4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13341: 98ac3031bec3a2e3680bf8c57b86a77a15bbfcea @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 98ac3031bec3 drm/i915: Check backlight type while doing eDP backlight initializaiton == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13341/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Use drm_gem_object.resv
== Series Details == Series: drm/i915: Use drm_gem_object.resv URL : https://patchwork.freedesktop.org/series/62307/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6291_full -> Patchwork_13326_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13326_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13326_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13326_full: ### IGT changes ### Possible regressions * igt@gem_ctx_switch@basic-queue-light: - shard-glk: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-glk7/igt@gem_ctx_swi...@basic-queue-light.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-glk1/igt@gem_ctx_swi...@basic-queue-light.html Known issues Here are the changes found in Patchwork_13326_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@bcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-apl1/igt@gem_ctx_isolat...@bcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-apl8/igt@gem_ctx_isolat...@bcs0-s3.html - shard-skl: [PASS][5] -> [INCOMPLETE][6] ([fdo#104108]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-skl8/igt@gem_ctx_isolat...@bcs0-s3.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-skl1/igt@gem_ctx_isolat...@bcs0-s3.html * igt@gem_mmap_gtt@hang: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#110913 ]) +2 similar issues [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-apl4/igt@gem_mmap_...@hang.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-apl4/igt@gem_mmap_...@hang.html * igt@gem_partial_pwrite_pread@write: - shard-iclb: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb7/igt@gem_partial_pwrite_pr...@write.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-iclb1/igt@gem_partial_pwrite_pr...@write.html * igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup: - shard-kbl: [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-kbl1/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-kbl6/igt@gem_userptr_bl...@map-fixed-invalidate-overlap-busy-gup.html * igt@i915_pm_rpm@system-suspend-execbuf: - shard-iclb: [PASS][13] -> [INCOMPLETE][14] ([fdo#107713] / [fdo#108840]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb8/igt@i915_pm_...@system-suspend-execbuf.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-iclb3/igt@i915_pm_...@system-suspend-execbuf.html * igt@kms_cursor_crc@pipe-b-cursor-64x21-sliding: - shard-kbl: [PASS][15] -> [FAIL][16] ([fdo#103232]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x21-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-kbl6/igt@kms_cursor_...@pipe-b-cursor-64x21-sliding.html * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move: - shard-hsw: [PASS][17] -> [SKIP][18] ([fdo#109271]) +18 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-hsw5/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-move.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-hsw1/igt@kms_frontbuffer_track...@fbc-2p-scndscrn-spr-indfb-move.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 similar issues [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-iclb1/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_psr2_su@page_flip: - shard-iclb: [PASS][21] -> [SKIP][22] ([fdo#109642]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb2/igt@kms_psr2_su@page_flip.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13326/shard-iclb4/igt@kms_psr2_su@page_flip.html
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/drm_vblank: Change EINVAL by the correct errno (rev4)
== Series Details == Series: drm/drm_vblank: Change EINVAL by the correct errno (rev4) URL : https://patchwork.freedesktop.org/series/51147/ State : success == Summary == CI Bug Log - changes from CI_DRM_6300 -> Patchwork_13340 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/ Known issues Here are the changes found in Patchwork_13340 that come from known issues: ### IGT changes ### Issues hit * igt@gem_busy@busy-all: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-u3/igt@gem_b...@busy-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-icl-u3/igt@gem_b...@busy-all.html * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [PASS][3] -> [DMESG-FAIL][4] ([fdo#110235]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html Possible fixes * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [INCOMPLETE][5] ([fdo#107718]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html * igt@gem_mmap_gtt@basic-read-no-prefault: - fi-icl-u3: [DMESG-WARN][7] ([fdo#107724]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-icl-u3/igt@gem_mmap_...@basic-read-no-prefault.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#110235]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][11] ([fdo#109485]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][13] ([fdo#103167]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6300/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (44 -> 37) -- Additional (1): fi-gdg-551 Missing(8): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6300 -> Patchwork_13340 CI_DRM_6300: a0694108fecf62a79e0be32e578f25fdcbf466e4 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13340: de35918e769bceaf4d0399cf009a943e719c2408 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == de35918e769b drm/drm_vblank: Change EINVAL by the correct errno == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13340/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Check backlight type while doing eDP backlight initializaiton
If LFP backlight type setting from VBT was "VESA eDP AUX Interface".
Driver should check panel capability and try to initialize aux backlight.
No matter i915_modparams.enable_dpcd_backlight was enabled or not.
Cc: Ville Syrjälä
Cc: Jani Nikula
Cc: Jose Roberto de Souza
Cc: Cooper Chiou
Signed-off-by: Lee, Shawn C
---
drivers/gpu/drm/i915/display/intel_bios.h | 1 +
drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c | 11 ++-
2 files changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.h
b/drivers/gpu/drm/i915/display/intel_bios.h
index 4e42cfaf61a7..0b7be6389a07 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.h
+++ b/drivers/gpu/drm/i915/display/intel_bios.h
@@ -42,6 +42,7 @@ enum intel_backlight_type {
INTEL_BACKLIGHT_DISPLAY_DDI,
INTEL_BACKLIGHT_DSI_DCS,
INTEL_BACKLIGHT_PANEL_DRIVER_INTERFACE,
+ INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE,
};
struct edp_power_seq {
diff --git a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
index 7ded95a334db..0cca5b732ccf 100644
--- a/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/display/intel_dp_aux_backlight.c
@@ -261,11 +261,20 @@ intel_dp_aux_display_control_capable(struct
intel_connector *connector)
return false;
}
+static bool
+intel_dp_bios_use_aux_backlight(struct drm_i915_private *dev_priv)
+{
+ if (dev_priv->vbt.backlight.type ==
INTEL_BACKLIGHT_VESA_EDP_AUX_INTERFACE)
+ return true;
+ return false;
+}
+
int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
{
struct intel_panel *panel = _connector->panel;
- if (!i915_modparams.enable_dpcd_backlight)
+ if (!i915_modparams.enable_dpcd_backlight &&
+
!intel_dp_bios_use_aux_backlight(to_i915(intel_connector->base.dev)))
return -ENODEV;
if (!intel_dp_aux_display_control_capable(intel_connector))
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V4] drm/drm_vblank: Change EINVAL by the correct errno
For historical reason, the function drm_wait_vblank_ioctl always return -EINVAL if something gets wrong. This scenario limits the flexibility for the userspace make detailed verification of the problem and take some action. In particular, the validation of “if (!dev->irq_enabled)” in the drm_wait_vblank_ioctl is responsible for checking if the driver support vblank or not. If the driver does not support VBlank, the function drm_wait_vblank_ioctl returns EINVAL which does not represent the real issue; this patch changes this behavior by return EOPNOTSUPP. Additionally, some operations are unsupported by this function, and returns EINVAL; this patch also changes the return value to EOPNOTSUPP in this case. Lastly, the function drm_wait_vblank_ioctl is invoked by libdrm, which is used by many compositors; because of this, it is important to check if this change breaks any compositor. In this sense, the following projects were examined: * Drm-hwcomposer * Kwin * Sway * Wlroots * Wayland-core * Weston * Xorg (67 different drivers) For each repository the verification happened in three steps: * Update the main branch * Look for any occurrence "drmWaitVBlank" with the command: git grep -n "drmWaitVBlank" * Look in the git history of the project with the command: git log -SdrmWaitVBlank Finally, none of the above projects validate the use of EINVAL which make safe, at least for these projects, to change the return values. Change since V3: - Return EINVAL for _DRM_VBLANK_SIGNAL (Daniel) Change since V2: Daniel Vetter and Chris Wilson - Replace ENOTTY by EOPNOTSUPP - Return EINVAL if the parameters are wrong Signed-off-by: Rodrigo Siqueira --- drivers/gpu/drm/drm_vblank.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/drm_vblank.c b/drivers/gpu/drm/drm_vblank.c index 603ab105125d..bed233361614 100644 --- a/drivers/gpu/drm/drm_vblank.c +++ b/drivers/gpu/drm/drm_vblank.c @@ -1582,7 +1582,7 @@ int drm_wait_vblank_ioctl(struct drm_device *dev, void *data, unsigned int flags, pipe, high_pipe; if (!dev->irq_enabled) - return -EINVAL; + return -EOPNOTSUPP; if (vblwait->request.type & _DRM_VBLANK_SIGNAL) return -EINVAL; -- 2.21.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for mm: Use local variable for swap address space
== Series Details == Series: mm: Use local variable for swap address space URL : https://patchwork.freedesktop.org/series/62358/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6299 -> Patchwork_13339 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13339 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13339, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13339: ### IGT changes ### Possible regressions * igt@gem_sync@basic-store-each: - fi-skl-gvtdvm: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-gvtdvm/igt@gem_s...@basic-store-each.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-skl-gvtdvm/igt@gem_s...@basic-store-each.html Known issues Here are the changes found in Patchwork_13339 that come from known issues: ### IGT changes ### Issues hit * igt@gem_basic@bad-close: - fi-icl-dsi: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-dsi/igt@gem_ba...@bad-close.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-icl-dsi/igt@gem_ba...@bad-close.html * igt@gem_ctx_switch@basic-default: - fi-icl-guc: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713] / [fdo#108569]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html * igt@gem_exec_reloc@basic-gtt-noreloc: - fi-icl-u3: [PASS][7] -> [DMESG-WARN][8] ([fdo#107724]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u3/igt@gem_exec_re...@basic-gtt-noreloc.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-icl-u3/igt@gem_exec_re...@basic-gtt-noreloc.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [PASS][9] -> [FAIL][10] ([fdo#109485]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html Possible fixes * igt@gem_sync@basic-store-each: - fi-kbl-7567u: [FAIL][11] -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-kbl-7567u/igt@gem_s...@basic-store-each.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-kbl-7567u/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][13] ([fdo#107718]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-blb-e6850/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [FAIL][15] ([fdo#108511]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][17] ([fdo#110235]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html - fi-bdw-gvtdvm: [DMESG-FAIL][19] ([fdo#110235]) -> [PASS][20] [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][21] ([fdo#102614]) -> [PASS][22] [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html - fi-icl-u2: [FAIL][23] ([fdo#103167]) -> [PASS][24] [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13339/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [fdo#102614]:
[Intel-gfx] [PATCH] mm: Use local variable for swap address space
This addresses the following build error:
mm/huge_memory.c: In function ‘__split_huge_page’:
mm/huge_memory.c:2506:41: warning: dereferencing ‘void *’ pointer
__xa_store(_address_space(entry)->i_pages,
^~
mm/huge_memory.c:2506:41: error: request for member ‘i_pages’ in
something not a structure or union
Cc: Chris Wilson
Signed-off-by: Stuart Summers
---
mm/huge_memory.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index affb2c3667f9..bced5485137b 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2503,7 +2503,9 @@ static void __split_huge_page(struct page *page, struct
list_head *list,
head + i, 0);
} else if (PageSwapCache(page)) {
swp_entry_t entry = { .val = page_private(head + i) };
- __xa_store(_address_space(entry)->i_pages,
+ struct address_space *address_space =
+ swap_address_space(entry);
+ __xa_store(_space->i_pages,
swp_offset(entry),
head + i, 0);
}
--
2.21.0.5.gaeb582a983
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10
== Series Details == Series: series starting with [1/6] dma-buf: add dynamic DMA-buf handling v10 URL : https://patchwork.freedesktop.org/series/62299/ State : success == Summary == CI Bug Log - changes from CI_DRM_6291_full -> Patchwork_13325_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13325_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_eio@unwedge-stress: - shard-kbl: [PASS][1] -> [DMESG-WARN][2] ([fdo#110913 ]) +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-kbl2/igt@gem_...@unwedge-stress.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-kbl3/igt@gem_...@unwedge-stress.html * igt@gem_mmap_gtt@hang: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-apl4/igt@gem_mmap_...@hang.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-apl5/igt@gem_mmap_...@hang.html - shard-snb: [PASS][5] -> [INCOMPLETE][6] ([fdo#105411]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-snb2/igt@gem_mmap_...@hang.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-snb2/igt@gem_mmap_...@hang.html * igt@gem_softpin@noreloc-s3: - shard-apl: [PASS][7] -> [DMESG-WARN][8] ([fdo#108566]) +1 similar issue [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-apl2/igt@gem_soft...@noreloc-s3.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-apl3/igt@gem_soft...@noreloc-s3.html * igt@i915_selftest@live_evict: - shard-glk: [PASS][9] -> [INCOMPLETE][10] ([fdo#103359] / [fdo#110938] / [k.org#198133]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-glk5/igt@i915_selftest@live_evict.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-glk3/igt@i915_selftest@live_evict.html * igt@kms_cursor_crc@pipe-c-cursor-64x21-onscreen: - shard-skl: [PASS][11] -> [FAIL][12] ([fdo#103232]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-skl6/igt@kms_cursor_...@pipe-c-cursor-64x21-onscreen.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-skl3/igt@kms_cursor_...@pipe-c-cursor-64x21-onscreen.html * igt@kms_flip@2x-plain-flip-ts-check-interruptible: - shard-hsw: [PASS][13] -> [SKIP][14] ([fdo#109271]) +34 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-hsw7/igt@kms_f...@2x-plain-flip-ts-check-interruptible.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-hsw1/igt@kms_f...@2x-plain-flip-ts-check-interruptible.html * igt@kms_flip@flip-vs-suspend: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#109507]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-skl6/igt@kms_f...@flip-vs-suspend.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-skl3/igt@kms_f...@flip-vs-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-cur-indfb-draw-render: - shard-iclb: [PASS][17] -> [FAIL][18] ([fdo#103167]) +5 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-iclb8/igt@kms_frontbuffer_track...@fbcpsr-1p-primscrn-cur-indfb-draw-render.html * igt@kms_plane_alpha_blend@pipe-c-constant-alpha-min: - shard-skl: [PASS][19] -> [FAIL][20] ([fdo#108145]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-skl6/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-skl3/igt@kms_plane_alpha_bl...@pipe-c-constant-alpha-min.html * igt@kms_psr@no_drrs: - shard-iclb: [PASS][21] -> [FAIL][22] ([fdo#108341]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb7/igt@kms_psr@no_drrs.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-iclb1/igt@kms_psr@no_drrs.html * igt@kms_psr@psr2_sprite_mmap_gtt: - shard-iclb: [PASS][23] -> [SKIP][24] ([fdo#109441]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb2/igt@kms_psr@psr2_sprite_mmap_gtt.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13325/shard-iclb8/igt@kms_psr@psr2_sprite_mmap_gtt.html * igt@kms_setmode@basic: - shard-hsw: [PASS][25] -> [FAIL][26] ([fdo#99912]) [25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-hsw1/igt@kms_setm...@basic.html [26]:
Re: [Intel-gfx] [PATCH v5 3/3] drm/i915: Make PSR registers relative to transcoders
On Fri, 2019-06-14 at 21:27 -0700, Dhinakaran Pandiyan wrote:
> "drm/i915/psr" in the subject.
Done
>
> On Sat, 2019-04-20 at 13:55 -0700, José Roberto de Souza wrote:
> > PSR registers are a mess, some have the full address while others
> > just
> > have the additional offset from psr_mmio_base.
> >
> > For BDW+ psr_mmio_base is nothing more than TRANSCODER_EDP_OFFSET +
> > 0x800 and using it makes more difficult for people with an PSR
> > register address or PSR register name from from BSpec as i915 also
> > don't match the BSpec names.
> > For HSW psr_mmio_base is _DDI_BUF_CTL_A + 0x800 and PSR registers
> > are
> > only available in DDIA.
> >
> > Other reason to make relative to transcoder is that since BDW every
> > transcoder have PSR registers, so in theory it should be possible
> > to
> > have PSR enabled in a non-eDP transcoder.
> >
> > So for BDW+ we can use _TRANS2() to get the register offset of any
> > PSR register in any transcoder while for HSW we have _HSW_PSR_ADJ
> > that will calculate the register offset for the single PSR
> > instance,
> > noting that we are already guarded about trying to enable PSR in
> > other
> > port than DDIA on HSW by the 'if (dig_port->base.port != PORT_A)'
> > in
> > intel_psr_compute_config(), this check should only be valid for HSW
> > and will be changed in future.
> > PSR2 registers and PSR_EVENT was added after Haswell so that is why
> > _PSR_ADJ() is not used in some macros.
> >
> > The only registers that can not be relative to transcoder are
> > PSR_IMR and PSR_IIR that are not relative to anything, so keeping
> > it
> > hardcoded.
> >
> > Also removing BDW_EDP_PSR_BASE from GVT because it is not used as
> > it
> > is the only PSR register that GVT have.
> >
> > v5:
> > - Macros changed to be more explicit about HSW (Dhinakaran)
> > - Squashed with the patch that added the tran parameter to the
> > macros (Dhinakaran)
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Cc: Jani Nikula
> > Cc: Ville Syrjälä
> > Cc: Zhi Wang
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/gvt/handlers.c | 1 -
> > drivers/gpu/drm/i915/i915_debugfs.c | 18 +
> > drivers/gpu/drm/i915/i915_drv.h | 3 +-
> > drivers/gpu/drm/i915/i915_reg.h | 57 -
> >
> > drivers/gpu/drm/i915/intel_psr.c| 55 -
> > ---
> > 5 files changed, 83 insertions(+), 51 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/gvt/handlers.c
> > b/drivers/gpu/drm/i915/gvt/handlers.c
> > index 18f01eeb2510..749e3e4204f2 100644
> > --- a/drivers/gpu/drm/i915/gvt/handlers.c
> > +++ b/drivers/gpu/drm/i915/gvt/handlers.c
> > @@ -2776,7 +2776,6 @@ static int init_broadwell_mmio_info(struct
> > intel_gvt
> > *gvt)
> > MMIO_D(CHICKEN_PIPESL_1(PIPE_C), D_BDW_PLUS);
> >
> > MMIO_D(WM_MISC, D_BDW);
> > - MMIO_D(_MMIO(BDW_EDP_PSR_BASE), D_BDW);
> Change this to _SRD_CTL_EDP to keep the change non-functional? Any
> case, we'll
> need an ack to modify this.
Ping Zhi?
Do you think we should replace with _SRD_CTL_EDP or is okay to remove
it?
>
> > MMIO_D(_MMIO(0x66c00), D_BDW_PLUS);
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 5823ffb17821..2a0f5871e9a8 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2470,7 +2470,7 @@ psr_source_status(struct drm_i915_private
> > *dev_priv,
> > struct seq_file *m)
> > "BUF_ON",
> > "TG_ON"
> > };
> > - val = I915_READ(EDP_PSR2_STATUS);
> > + val = I915_READ(EDP_PSR2_STATUS(dev_priv-
> > >psr.transcoder));
> > status_val = (val & EDP_PSR2_STATUS_STATE_MASK) >>
> > EDP_PSR2_STATUS_STATE_SHIFT;
> > if (status_val < ARRAY_SIZE(live_status))
> > @@ -2486,7 +2486,7 @@ psr_source_status(struct drm_i915_private
> > *dev_priv,
> > struct seq_file *m)
> > "SRDOFFACK",
> > "SRDENT_ON",
> > };
> > - val = I915_READ(EDP_PSR_STATUS);
> > + val = I915_READ(EDP_PSR_STATUS(dev_priv-
> > >psr.transcoder));
> > status_val = (val & EDP_PSR_STATUS_STATE_MASK) >>
> > EDP_PSR_STATUS_STATE_SHIFT;
> > if (status_val < ARRAY_SIZE(live_status))
> > @@ -2529,10 +2529,10 @@ static int i915_edp_psr_status(struct
> > seq_file *m,
> > void *data)
> > goto unlock;
> >
> > if (psr->psr2_enabled) {
> > - val = I915_READ(EDP_PSR2_CTL);
> > + val = I915_READ(EDP_PSR2_CTL(dev_priv-
> > >psr.transcoder));
> > enabled = val & EDP_PSR2_ENABLE;
> > } else {
> > - val = I915_READ(EDP_PSR_CTL);
> > + val = I915_READ(EDP_PSR_CTL(dev_priv->psr.transcoder));
> > enabled = val & EDP_PSR_ENABLE;
> > }
> > seq_printf(m, "Source PSR ctl: %s
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gtt: Defer address space cleanup to an RCU worker
== Series Details == Series: drm/i915/gtt: Defer address space cleanup to an RCU worker URL : https://patchwork.freedesktop.org/series/62356/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6299 -> Patchwork_13338 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13338 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13338, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13338: ### IGT changes ### Possible regressions * igt@i915_selftest@live_contexts: - fi-byt-n2820: [PASS][1] -> [DMESG-WARN][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-byt-n2820/igt@i915_selftest@live_contexts.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-byt-n2820/igt@i915_selftest@live_contexts.html * igt@runner@aborted: - fi-byt-n2820: NOTRUN -> [FAIL][3] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-byt-n2820/igt@run...@aborted.html Warnings * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][4] ([fdo#110235]) -> [INCOMPLETE][5] [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html Known issues Here are the changes found in Patchwork_13338 that come from known issues: ### IGT changes ### Possible fixes * igt@gem_cpu_reloc@basic: - fi-icl-dsi: [INCOMPLETE][6] ([fdo#107713] / [fdo#110246]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-dsi/igt@gem_cpu_re...@basic.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-icl-dsi/igt@gem_cpu_re...@basic.html * igt@gem_sync@basic-store-each: - fi-kbl-7567u: [FAIL][8] -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-kbl-7567u/igt@gem_s...@basic-store-each.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-kbl-7567u/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][10] ([fdo#107718]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-blb-e6850/igt@i915_module_l...@reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [FAIL][12] ([fdo#108511]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][14] ([fdo#110235]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][16] ([fdo#102614]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html - fi-icl-u3: [FAIL][18] ([fdo#103167]) -> [PASS][19] [18]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13338/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246 Participating hosts (44 -> 36) -- Additional (1): fi-bdw-5557u Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6299 -> Patchwork_13338 CI_DRM_6299:
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915/gtt: Defer address space cleanup to an RCU worker
== Series Details == Series: drm/i915/gtt: Defer address space cleanup to an RCU worker URL : https://patchwork.freedesktop.org/series/62356/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/gtt: Defer address space cleanup to an RCU worker +./include/uapi/linux/perf_event.h:147:56: warning: cast truncates bits from constant value (8000 becomes 0) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915/icl: Add new supported CD clocks
== Series Details == Series: series starting with [1/3] drm/i915/icl: Add new supported CD clocks URL : https://patchwork.freedesktop.org/series/62355/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6299 -> Patchwork_13337 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13337 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13337, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13337: ### IGT changes ### Possible regressions * igt@gem_sync@basic-store-each: - fi-bdw-5557u: NOTRUN -> [FAIL][1] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-bdw-5557u/igt@gem_s...@basic-store-each.html Warnings * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][2] ([fdo#110235]) -> [INCOMPLETE][3] [2]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [3]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html Known issues Here are the changes found in Patchwork_13337 that come from known issues: ### IGT changes ### Issues hit * igt@i915_selftest@live_hangcheck: - fi-icl-u2: [PASS][4] -> [INCOMPLETE][5] ([fdo#107713] / [fdo#108569]) [4]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u2/igt@i915_selftest@live_hangcheck.html [5]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-icl-u2/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@gem_cpu_reloc@basic: - fi-icl-dsi: [INCOMPLETE][6] ([fdo#107713] / [fdo#110246]) -> [PASS][7] [6]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-dsi/igt@gem_cpu_re...@basic.html [7]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-icl-dsi/igt@gem_cpu_re...@basic.html * igt@gem_sync@basic-store-each: - fi-kbl-7567u: [FAIL][8] -> [PASS][9] [8]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-kbl-7567u/igt@gem_s...@basic-store-each.html [9]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-kbl-7567u/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][10] ([fdo#107718]) -> [PASS][11] [10]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-blb-e6850/igt@i915_module_l...@reload.html [11]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [FAIL][12] ([fdo#108511]) -> [PASS][13] [12]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [13]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][14] ([fdo#110235]) -> [PASS][15] [14]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [15]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][16] ([fdo#102614]) -> [PASS][17] [16]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13337/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246 Participating hosts (44 -> 35) -- Additional (1): fi-bdw-5557u Missing(10): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6299 -> Patchwork_13337 CI_DRM_6299: 2a6cf9f4dc05b77beab4b7d9d1c9f16c7e55a001 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/execlists: Detect cross-contamination with GuC
== Series Details == Series: drm/i915/execlists: Detect cross-contamination with GuC URL : https://patchwork.freedesktop.org/series/62296/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6291_full -> Patchwork_13324_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13324_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13324_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13324_full: ### IGT changes ### Possible regressions * igt@kms_atomic_transition@plane-use-after-nonblocking-unbind-fencing: - shard-hsw: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-hsw4/igt@kms_atomic_transit...@plane-use-after-nonblocking-unbind-fencing.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-hsw1/igt@kms_atomic_transit...@plane-use-after-nonblocking-unbind-fencing.html Known issues Here are the changes found in Patchwork_13324_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-apl6/igt@gem_ctx_isolat...@rcs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@in-flight-10ms: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +2 similar issues [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-kbl6/igt@gem_...@in-flight-10ms.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-kbl6/igt@gem_...@in-flight-10ms.html * igt@gem_exec_nop@basic-parallel: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-iclb4/igt@gem_exec_...@basic-parallel.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-iclb8/igt@gem_exec_...@basic-parallel.html * igt@gem_mmap_gtt@hang: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-apl4/igt@gem_mmap_...@hang.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-apl7/igt@gem_mmap_...@hang.html * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrash-inactive: - shard-snb: [PASS][11] -> [INCOMPLETE][12] ([fdo#105411]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-snb6/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrash-inactive.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-snb7/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrash-inactive.html * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing: - shard-snb: [PASS][13] -> [DMESG-WARN][14] ([fdo#110789] / [fdo#110913 ]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-snb2/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-snb5/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html * igt@gem_softpin@noreloc-s3: - shard-skl: [PASS][15] -> [INCOMPLETE][16] ([fdo#104108]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-skl5/igt@gem_soft...@noreloc-s3.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-skl4/igt@gem_soft...@noreloc-s3.html * igt@gem_userptr_blits@map-fixed-invalidate-busy: - shard-snb: [PASS][17] -> [DMESG-WARN][18] ([fdo#110913 ]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-snb2/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-snb4/igt@gem_userptr_bl...@map-fixed-invalidate-busy.html * igt@kms_cursor_crc@pipe-b-cursor-64x21-sliding: - shard-kbl: [PASS][19] -> [FAIL][20] ([fdo#103232]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-64x21-sliding.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13324/shard-kbl3/igt@kms_cursor_...@pipe-b-cursor-64x21-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][21] -> [INCOMPLETE][22] ([fdo#110741]) [21]:
Re: [Intel-gfx] [PATCH 5/6] drm/i915: dynamically allocate forcewake domains
On 6/18/19 4:23 PM, Chris Wilson wrote:
Quoting Daniele Ceraolo Spurio (2019-06-19 00:06:39)
On 6/18/19 2:23 AM, Tvrtko Ursulin wrote:
On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote:
-static void intel_uncore_fw_domains_init(struct intel_uncore *uncore)
+static int intel_uncore_fw_domains_init(struct intel_uncore *uncore)
{
struct drm_i915_private *i915 = uncore->i915;
+ int ret;
GEM_BUG_ON(!intel_uncore_has_forcewake(uncore));
+#define __fw_domain_init(id__, set__, ack__) \
+ ret = fw_domain_init(uncore, (id__), (set__), (ack__)); \
+ if (ret) \
+ goto out_clean;
Hidden control flow is slightly objectionable but I don't offer any nice
alternatives so I guess will have to pass. Or maybe accumulate the error
(err |= fw_domain_init(..)) as you go and then cleanup at the end if any
failed?
I'd prefer to avoid accumulating the error since it'd just cause us to
having to unroll more domains when we could've stopped early.
On the other hand the idea slightly conflicts with my other suggestion
to rename existing fw_domain_init to __fw_domain_init and call the macro
fw_domain_init and avoid all the churn below.
I'll pick this suggestion among the 2, unless there is another
suggestion on how to avoid the hidden goto.
Be careful, or you'll give Tvrtko the chance to suggest table driven
setup. Maybe?
-Chris
I did consider using a table myself, but the differences between the
domains are not easy to put in a table since some of them are per-gen
and other per-platform. We could combine a table with information in the
device_info struct like we do for the engines, but that felt a bit like
overkill to me.
Daniele
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gtt: Defer address space cleanup to an RCU worker
Enable RCU protection of i915_address_space and its ppgtt superclasses,
and defer its cleanup into a worker executed after an RCU grace period.
In the future we will be able to use the RCU protection to reduce the
locking around VM lookups, but the immediate benefit is being able to
defer the release into a kworker (process context). This is required as
we may need to sleep to reap the WC pages stashed away inside the ppgtt.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110934
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/Makefile.header-test | 1 +
drivers/gpu/drm/i915/i915_gem_gtt.c | 109 ++
drivers/gpu/drm/i915/i915_gem_gtt.h | 5 +
drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 2 -
4 files changed, 66 insertions(+), 51 deletions(-)
diff --git a/drivers/gpu/drm/i915/Makefile.header-test
b/drivers/gpu/drm/i915/Makefile.header-test
index e6ba66f787f9..cb74242f9c3b 100644
--- a/drivers/gpu/drm/i915/Makefile.header-test
+++ b/drivers/gpu/drm/i915/Makefile.header-test
@@ -6,6 +6,7 @@ header_test := \
i915_active_types.h \
i915_debugfs.h \
i915_drv.h \
+ i915_gem_gtt.h \
i915_irq.h \
i915_params.h \
i915_priolist_types.h \
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8ab820145ea6..d9eddbd79670 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -482,9 +482,69 @@ static void vm_free_page(struct i915_address_space *vm,
struct page *page)
spin_unlock(>free_pages.lock);
}
+static void i915_address_space_fini(struct i915_address_space *vm)
+{
+ spin_lock(>free_pages.lock);
+ if (pagevec_count(>free_pages.pvec))
+ vm_free_pages_release(vm, true);
+ GEM_BUG_ON(pagevec_count(>free_pages.pvec));
+ spin_unlock(>free_pages.lock);
+
+ drm_mm_takedown(>mm);
+
+ mutex_destroy(>mutex);
+}
+
+static void ppgtt_destroy_vma(struct i915_address_space *vm)
+{
+ struct list_head *phases[] = {
+ >bound_list,
+ >unbound_list,
+ NULL,
+ }, **phase;
+
+ mutex_lock(>i915->drm.struct_mutex);
+ for (phase = phases; *phase; phase++) {
+ struct i915_vma *vma, *vn;
+
+ list_for_each_entry_safe(vma, vn, *phase, vm_link)
+ i915_vma_destroy(vma);
+ }
+ mutex_unlock(>i915->drm.struct_mutex);
+}
+
+static void __i915_vm_release(struct work_struct *work)
+{
+ struct i915_address_space *vm =
+ container_of(work, struct i915_address_space, rcu.work);
+
+ ppgtt_destroy_vma(vm);
+
+ GEM_BUG_ON(!list_empty(>bound_list));
+ GEM_BUG_ON(!list_empty(>unbound_list));
+
+ vm->cleanup(vm);
+ i915_address_space_fini(vm);
+
+ kfree(vm);
+}
+
+void i915_vm_release(struct kref *kref)
+{
+ struct i915_address_space *vm =
+ container_of(kref, struct i915_address_space, ref);
+
+ GEM_BUG_ON(i915_is_ggtt(vm));
+ trace_i915_ppgtt_release(vm);
+
+ vm->closed = true;
+ queue_rcu_work(system_unbound_wq, >rcu);
+}
+
static void i915_address_space_init(struct i915_address_space *vm, int
subclass)
{
kref_init(>ref);
+ INIT_RCU_WORK(>rcu, __i915_vm_release);
/*
* The vm->mutex must be reclaim safe (for use in the shrinker).
@@ -505,19 +565,6 @@ static void i915_address_space_init(struct
i915_address_space *vm, int subclass)
INIT_LIST_HEAD(>bound_list);
}
-static void i915_address_space_fini(struct i915_address_space *vm)
-{
- spin_lock(>free_pages.lock);
- if (pagevec_count(>free_pages.pvec))
- vm_free_pages_release(vm, true);
- GEM_BUG_ON(pagevec_count(>free_pages.pvec));
- spin_unlock(>free_pages.lock);
-
- drm_mm_takedown(>mm);
-
- mutex_destroy(>mutex);
-}
-
static int __setup_page_dma(struct i915_address_space *vm,
struct i915_page_dma *p,
gfp_t gfp)
@@ -2250,42 +2297,6 @@ i915_ppgtt_create(struct drm_i915_private *i915)
return ppgtt;
}
-static void ppgtt_destroy_vma(struct i915_address_space *vm)
-{
- struct list_head *phases[] = {
- >bound_list,
- >unbound_list,
- NULL,
- }, **phase;
-
- vm->closed = true;
- for (phase = phases; *phase; phase++) {
- struct i915_vma *vma, *vn;
-
- list_for_each_entry_safe(vma, vn, *phase, vm_link)
- i915_vma_destroy(vma);
- }
-}
-
-void i915_vm_release(struct kref *kref)
-{
- struct i915_address_space *vm =
- container_of(kref, struct i915_address_space, ref);
-
- GEM_BUG_ON(i915_is_ggtt(vm));
- trace_i915_ppgtt_release(vm);
-
- ppgtt_destroy_vma(vm);
-
- GEM_BUG_ON(!list_empty(>bound_list));
-
[Intel-gfx] ✗ Fi.CI.SPARSE: warning for series starting with [1/3] drm/i915/icl: Add new supported CD clocks
== Series Details == Series: series starting with [1/3] drm/i915/icl: Add new supported CD clocks URL : https://patchwork.freedesktop.org/series/62355/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/icl: Add new supported CD clocks Okay! Commit: drm/i915/ehl: Remove unsupported cd clocks Okay! Commit: drm/i915/ehl: Add voltage level requirement table -O:drivers/gpu/drm/i915/display/intel_cdclk.c:2571:17: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/display/intel_cdclk.c:2571:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/display/intel_cdclk.c:2582:17: warning: expression using sizeof(void) +drivers/gpu/drm/i915/display/intel_cdclk.c:2582:17: warning: expression using sizeof(void) ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: dynamically allocate forcewake domains
Quoting Daniele Ceraolo Spurio (2019-06-19 00:06:39)
>
>
> On 6/18/19 2:23 AM, Tvrtko Ursulin wrote:
> >
> > On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote:
> >> -static void intel_uncore_fw_domains_init(struct intel_uncore *uncore)
> >> +static int intel_uncore_fw_domains_init(struct intel_uncore *uncore)
> >> {
> >> struct drm_i915_private *i915 = uncore->i915;
> >> + int ret;
> >> GEM_BUG_ON(!intel_uncore_has_forcewake(uncore));
> >> +#define __fw_domain_init(id__, set__, ack__) \
> >> + ret = fw_domain_init(uncore, (id__), (set__), (ack__)); \
> >> + if (ret) \
> >> + goto out_clean;
> >
> > Hidden control flow is slightly objectionable but I don't offer any nice
> > alternatives so I guess will have to pass. Or maybe accumulate the error
> > (err |= fw_domain_init(..)) as you go and then cleanup at the end if any
> > failed?
>
> I'd prefer to avoid accumulating the error since it'd just cause us to
> having to unroll more domains when we could've stopped early.
>
> >
> > On the other hand the idea slightly conflicts with my other suggestion
> > to rename existing fw_domain_init to __fw_domain_init and call the macro
> > fw_domain_init and avoid all the churn below.
> >
>
> I'll pick this suggestion among the 2, unless there is another
> suggestion on how to avoid the hidden goto.
Be careful, or you'll give Tvrtko the chance to suggest table driven
setup. Maybe?
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/6] drm/i915: dynamically allocate forcewake domains
On 6/18/19 2:23 AM, Tvrtko Ursulin wrote:
On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote:
We'd like to introduce a display uncore with no forcewake domains, so
let's avoid wasting memory and be ready to allocate only what we need.
Even without multiple uncore, we still don't need all the domains on all
gens.
Looks good in principle, only a few conversation points below.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/intel_uncore.c | 155 ++--
drivers/gpu/drm/i915/intel_uncore.h | 13 +--
2 files changed, 102 insertions(+), 66 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index c0f5567ee096..7f311827c3ef 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -344,7 +344,7 @@ intel_uncore_fw_release_timer(struct hrtimer *timer)
{
struct intel_uncore_forcewake_domain *domain =
container_of(timer, struct intel_uncore_forcewake_domain,
timer);
- struct intel_uncore *uncore = forcewake_domain_to_uncore(domain);
+ struct intel_uncore *uncore = domain->uncore;
unsigned long irqflags;
assert_rpm_device_not_suspended(uncore->rpm);
@@ -1291,23 +1291,23 @@ do { \
(uncore)->funcs.read_fw_domains = x##_reg_read_fw_domains; \
} while (0)
-static void fw_domain_init(struct intel_uncore *uncore,
+static int fw_domain_init(struct intel_uncore *uncore,
enum forcewake_domain_id domain_id,
i915_reg_t reg_set,
i915_reg_t reg_ack)
{
struct intel_uncore_forcewake_domain *d;
- if (WARN_ON(domain_id >= FW_DOMAIN_ID_COUNT))
- return;
-
- d = >fw_domain[domain_id];
+ GEM_BUG_ON(domain_id >= FW_DOMAIN_ID_COUNT);
- WARN_ON(d->wake_count);
I wonder what was this for.
Do you want to add some protection against double init of the same domain?
just a GEM_BUG_ON maybe? It shouldn't really ever happen unless we're
moving something around.
+ d = kzalloc(sizeof(*d), GFP_KERNEL);
+ if (!d)
+ return -ENOMEM;
WARN_ON(!i915_mmio_reg_valid(reg_set));
WARN_ON(!i915_mmio_reg_valid(reg_ack));
+ d->uncore = uncore;
d->wake_count = 0;
d->reg_set = uncore->regs + i915_mmio_reg_offset(reg_set);
d->reg_ack = uncore->regs + i915_mmio_reg_offset(reg_ack);
@@ -1324,7 +1324,6 @@ static void fw_domain_init(struct intel_uncore
*uncore,
BUILD_BUG_ON(FORCEWAKE_MEDIA_VEBOX0 != (1 <<
FW_DOMAIN_ID_MEDIA_VEBOX0));
BUILD_BUG_ON(FORCEWAKE_MEDIA_VEBOX1 != (1 <<
FW_DOMAIN_ID_MEDIA_VEBOX1));
-
d->mask = BIT(domain_id);
hrtimer_init(>timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);
@@ -1333,6 +1332,10 @@ static void fw_domain_init(struct intel_uncore
*uncore,
uncore->fw_domains |= BIT(domain_id);
fw_domain_reset(d);
+
+ uncore->fw_domain[domain_id] = d;
+
+ return 0;
}
static void fw_domain_fini(struct intel_uncore *uncore,
@@ -1340,77 +1343,92 @@ static void fw_domain_fini(struct intel_uncore
*uncore,
{
struct intel_uncore_forcewake_domain *d;
- if (WARN_ON(domain_id >= FW_DOMAIN_ID_COUNT))
- return;
+ GEM_BUG_ON(domain_id >= FW_DOMAIN_ID_COUNT);
- d = >fw_domain[domain_id];
+ d = fetch_and_zero(>fw_domain[domain_id]);
Maybe early if !d here and function flow just carries on?
will do.
+ uncore->fw_domains &= ~BIT(domain_id);
- WARN_ON(d->wake_count);
- WARN_ON(hrtimer_cancel(>timer));
- memset(d, 0, sizeof(*d));
+ if (d) {
+ WARN_ON(d->wake_count);
+ WARN_ON(hrtimer_cancel(>timer));
+ kfree(d);
+ }
+}
- uncore->fw_domains &= ~BIT(domain_id);
+static void intel_uncore_fw_domains_fini(struct intel_uncore *uncore)
+{
+ struct intel_uncore_forcewake_domain *d;
+ int tmp;
+
+ for_each_fw_domain(d, uncore, tmp)
+ fw_domain_fini(uncore, d->id);
}
-static void intel_uncore_fw_domains_init(struct intel_uncore *uncore)
+static int intel_uncore_fw_domains_init(struct intel_uncore *uncore)
{
struct drm_i915_private *i915 = uncore->i915;
+ int ret;
GEM_BUG_ON(!intel_uncore_has_forcewake(uncore));
+#define __fw_domain_init(id__, set__, ack__) \
+ ret = fw_domain_init(uncore, (id__), (set__), (ack__)); \
+ if (ret) \
+ goto out_clean;
Hidden control flow is slightly objectionable but I don't offer any nice
alternatives so I guess will have to pass. Or maybe accumulate the error
(err |= fw_domain_init(..)) as you go and then cleanup at the end if any
failed?
I'd prefer to avoid accumulating the error since it'd just cause us to
having to unroll more domains when we could've stopped early.
On the other hand the idea slightly conflicts with my other suggestion
to rename existing fw_domain_init to __fw_domain_init and call the macro
fw_domain_init and avoid all the churn below.
I'll pick this suggestion among the 2, unless there is another
suggestion on how to avoid the
[Intel-gfx] [PATCH 3/3] drm/i915/ehl: Add voltage level requirement table
EHL has it own voltage level requirement depending on cd clock.
BSpec: 21809
Cc: Clint Taylor
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 23 --
1 file changed, 17 insertions(+), 6 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 26c17ecf2083..575ab1a96bbc 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1872,8 +1872,17 @@ static void icl_set_cdclk(struct drm_i915_private
*dev_priv,
dev_priv->cdclk.hw.voltage_level = cdclk_state->voltage_level;
}
-static u8 icl_calc_voltage_level(int cdclk)
+static u8 icl_calc_voltage_level(struct drm_i915_private *dev_priv, int cdclk)
{
+ if (IS_ELKHARTLAKE(dev_priv)) {
+ if (cdclk > 312000)
+ return 2;
+ else if (cdclk > 18)
+ return 1;
+ else
+ return 0;
+ }
+
if (cdclk > 556800)
return 2;
else if (cdclk > 312000)
@@ -1930,7 +1939,7 @@ static void icl_get_cdclk(struct drm_i915_private
*dev_priv,
* at least what the CDCLK frequency requires.
*/
cdclk_state->voltage_level =
- icl_calc_voltage_level(cdclk_state->cdclk);
+ icl_calc_voltage_level(dev_priv, cdclk_state->cdclk);
}
static void icl_init_cdclk(struct drm_i915_private *dev_priv)
@@ -1966,7 +1975,8 @@ static void icl_init_cdclk(struct drm_i915_private
*dev_priv)
sanitized_state.vco = icl_calc_cdclk_pll_vco(dev_priv,
sanitized_state.cdclk);
sanitized_state.voltage_level =
- icl_calc_voltage_level(sanitized_state.cdclk);
+ icl_calc_voltage_level(dev_priv,
+ sanitized_state.cdclk);
icl_set_cdclk(dev_priv, _state, INVALID_PIPE);
}
@@ -1977,7 +1987,8 @@ static void icl_uninit_cdclk(struct drm_i915_private
*dev_priv)
cdclk_state.cdclk = cdclk_state.bypass;
cdclk_state.vco = 0;
- cdclk_state.voltage_level = icl_calc_voltage_level(cdclk_state.cdclk);
+ cdclk_state.voltage_level = icl_calc_voltage_level(dev_priv,
+ cdclk_state.cdclk);
icl_set_cdclk(dev_priv, _state, INVALID_PIPE);
}
@@ -2568,7 +2579,7 @@ static int icl_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.logical.vco = vco;
state->cdclk.logical.cdclk = cdclk;
state->cdclk.logical.voltage_level =
- max(icl_calc_voltage_level(cdclk),
+ max(icl_calc_voltage_level(dev_priv, cdclk),
cnl_compute_min_voltage_level(state));
if (!state->active_crtcs) {
@@ -2579,7 +2590,7 @@ static int icl_modeset_calc_cdclk(struct
intel_atomic_state *state)
state->cdclk.actual.vco = vco;
state->cdclk.actual.cdclk = cdclk;
state->cdclk.actual.voltage_level =
- icl_calc_voltage_level(cdclk);
+ icl_calc_voltage_level(dev_priv, cdclk);
} else {
state->cdclk.actual = state->cdclk.logical;
}
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/ehl: Remove unsupported cd clocks
EHL do not support 648 and 652.8 MHz.
BSpec: 20598
Cc: Clint Taylor
Cc: Matt Roper
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index d560e25d3fb5..26c17ecf2083 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1754,7 +1754,8 @@ static void cnl_sanitize_cdclk(struct drm_i915_private
*dev_priv)
dev_priv->cdclk.hw.vco = -1;
}
-static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
+static int icl_calc_cdclk(struct drm_i915_private *dev_priv, int min_cdclk,
+ unsigned int ref)
{
const int ranges_24[] = { 18, 192000, 312000, 552000, 648000 };
const int ranges_19_38[] = { 172800, 192000, 307200, 556800, 652800 };
@@ -1776,6 +1777,12 @@ static int icl_calc_cdclk(int min_cdclk, unsigned int
ref)
break;
}
+ /*
+* EHL do not support 648 and 652.8 MHz, so just decrement the len
+*/
+ if (IS_ELKHARTLAKE(dev_priv))
+ len--;
+
for (i = 0; i < len; i++) {
if (min_cdclk <= ranges[i])
return ranges[i];
@@ -1954,7 +1961,8 @@ static void icl_init_cdclk(struct drm_i915_private
*dev_priv)
DRM_DEBUG_KMS("Sanitizing cdclk programmed by pre-os\n");
sanitized_state.ref = dev_priv->cdclk.hw.ref;
- sanitized_state.cdclk = icl_calc_cdclk(0, sanitized_state.ref);
+ sanitized_state.cdclk = icl_calc_cdclk(dev_priv, 0,
+ sanitized_state.ref);
sanitized_state.vco = icl_calc_cdclk_pll_vco(dev_priv,
sanitized_state.cdclk);
sanitized_state.voltage_level =
@@ -2554,7 +2562,7 @@ static int icl_modeset_calc_cdclk(struct
intel_atomic_state *state)
if (min_cdclk < 0)
return min_cdclk;
- cdclk = icl_calc_cdclk(min_cdclk, ref);
+ cdclk = icl_calc_cdclk(dev_priv, min_cdclk, ref);
vco = icl_calc_cdclk_pll_vco(dev_priv, cdclk);
state->cdclk.logical.vco = vco;
@@ -2564,7 +2572,8 @@ static int icl_modeset_calc_cdclk(struct
intel_atomic_state *state)
cnl_compute_min_voltage_level(state));
if (!state->active_crtcs) {
- cdclk = icl_calc_cdclk(state->cdclk.force_min_cdclk, ref);
+ cdclk = icl_calc_cdclk(dev_priv, state->cdclk.force_min_cdclk,
+ ref);
vco = icl_calc_cdclk_pll_vco(dev_priv, cdclk);
state->cdclk.actual.vco = vco;
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/icl: Add new supported CD clocks
Now 180, 172.8 and 192 MHz are supported.
180 and 172.8 MHz CD clocks will only be used when audio is not
enabled as state by BSpec and implemented in
intel_crtc_compute_min_cdclk(), CD clock must be at least twice of
Azalia BCLK and BCLK by default is 96 MHz, it could be set to 48 MHz
but we are not reading it.
BSpec: 20598
BSpec: 15729
Cc: Clint Taylor
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/intel_cdclk.c | 29 +++---
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/display/intel_cdclk.c
b/drivers/gpu/drm/i915/display/intel_cdclk.c
index 8993ab283562..d560e25d3fb5 100644
--- a/drivers/gpu/drm/i915/display/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/display/intel_cdclk.c
@@ -1756,9 +1756,10 @@ static void cnl_sanitize_cdclk(struct drm_i915_private
*dev_priv)
static int icl_calc_cdclk(int min_cdclk, unsigned int ref)
{
- int ranges_24[] = { 312000, 552000, 648000 };
- int ranges_19_38[] = { 307200, 556800, 652800 };
- int *ranges;
+ const int ranges_24[] = { 18, 192000, 312000, 552000, 648000 };
+ const int ranges_19_38[] = { 172800, 192000, 307200, 556800, 652800 };
+ const int *ranges;
+ unsigned int len, i;
switch (ref) {
default:
@@ -1766,19 +1767,22 @@ static int icl_calc_cdclk(int min_cdclk, unsigned int
ref)
/* fall through */
case 24000:
ranges = ranges_24;
+ len = ARRAY_SIZE(ranges_24);
break;
case 19200:
case 38400:
ranges = ranges_19_38;
+ len = ARRAY_SIZE(ranges_19_38);
break;
}
- if (min_cdclk > ranges[1])
- return ranges[2];
- else if (min_cdclk > ranges[0])
- return ranges[1];
- else
- return ranges[0];
+ for (i = 0; i < len; i++) {
+ if (min_cdclk <= ranges[i])
+ return ranges[i];
+ }
+
+ WARN_ON(min_cdclk > ranges[len - 1]);
+ return ranges[len - 1];
}
static int icl_calc_cdclk_pll_vco(struct drm_i915_private *dev_priv, int cdclk)
@@ -1792,16 +1796,23 @@ static int icl_calc_cdclk_pll_vco(struct
drm_i915_private *dev_priv, int cdclk)
default:
MISSING_CASE(cdclk);
/* fall through */
+ case 172800:
case 307200:
case 556800:
case 652800:
WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
dev_priv->cdclk.hw.ref != 38400);
break;
+ case 18:
case 312000:
case 552000:
case 648000:
WARN_ON(dev_priv->cdclk.hw.ref != 24000);
+ break;
+ case 192000:
+ WARN_ON(dev_priv->cdclk.hw.ref != 19200 &&
+ dev_priv->cdclk.hw.ref != 38400 &&
+ dev_priv->cdclk.hw.ref != 24000);
}
ratio = cdclk / (dev_priv->cdclk.hw.ref / 2);
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH V6 i-g-t 1/6] lib/igt_kms: Add writeback support
On Thu, Jun 13, 2019 at 11:54 AM Liviu Dudau wrote:
>
> On Wed, Jun 12, 2019 at 11:16:02PM -0300, Brian Starkey wrote:
> > Add support in igt_kms for writeback connectors, with the ability
> > to attach framebuffers.
> >
> > v5: Rebase and add DRM_CLIENT_CAP_WRITEBACK_CONNECTORS before
> > drmModeGetResources()
>
> Reviewed-by: Liviu Dudau
>
> Thanks for updating this! Given that I have done the last changes and this is
> mostly a refresh, not sure if I should add more Reviewed-by's to the other
> patches.
Thanks Liviu!
I just forgot to add my SoB, and for some reason, gmail does not allow
me to send an email on someone behalf. Btw, I can fix it after
everybody agrees that the kms_writeback is ready for landing.
> Best regards,
> Liviu
>
> >
> > Signed-off-by: Brian Starkey
> > [rebased and updated to the latest igt style]
> > Signed-off-by: Liviu Dudau
> > ---
> > lib/igt_kms.c | 57 +++
> > lib/igt_kms.h | 6 ++
> > 2 files changed, 63 insertions(+)
> >
> > diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> > index da188a39..140db346 100644
> > --- a/lib/igt_kms.c
> > +++ b/lib/igt_kms.c
> > @@ -325,6 +325,9 @@ const char * const
> > igt_connector_prop_names[IGT_NUM_CONNECTOR_PROPS] = {
> > [IGT_CONNECTOR_BROADCAST_RGB] = "Broadcast RGB",
> > [IGT_CONNECTOR_CONTENT_PROTECTION] = "Content Protection",
> > [IGT_CONNECTOR_VRR_CAPABLE] = "vrr_capable",
> > + [IGT_CONNECTOR_WRITEBACK_PIXEL_FORMATS] = "WRITEBACK_PIXEL_FORMATS",
> > + [IGT_CONNECTOR_WRITEBACK_FB_ID] = "WRITEBACK_FB_ID",
> > + [IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR] = "WRITEBACK_OUT_FENCE_PTR",
> > };
> >
> > /*
> > @@ -557,6 +560,7 @@ static const struct type_name connector_type_names[] = {
> > { DRM_MODE_CONNECTOR_VIRTUAL, "Virtual" },
> > { DRM_MODE_CONNECTOR_DSI, "DSI" },
> > { DRM_MODE_CONNECTOR_DPI, "DPI" },
> > + { DRM_MODE_CONNECTOR_WRITEBACK, "Writeback" },
> > {}
> > };
> >
> > @@ -1889,6 +1893,12 @@ static void igt_output_reset(igt_output_t *output)
> > if (igt_output_has_prop(output, IGT_CONNECTOR_BROADCAST_RGB))
> > igt_output_set_prop_value(output, IGT_CONNECTOR_BROADCAST_RGB,
> > BROADCAST_RGB_FULL);
> > + if (igt_output_has_prop(output, IGT_CONNECTOR_WRITEBACK_FB_ID))
> > + igt_output_set_prop_value(output,
> > IGT_CONNECTOR_WRITEBACK_FB_ID, 0);
> > + if (igt_output_has_prop(output,
> > IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR)) {
> > + igt_output_clear_prop_changed(output,
> > IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR);
> > + output->writeback_out_fence_fd = -1;
> > + }
> > }
> >
> > /**
> > @@ -1901,6 +1911,8 @@ static void igt_output_reset(igt_output_t *output)
> > * For outputs:
> > * - %IGT_CONNECTOR_CRTC_ID
> > * - %IGT_CONNECTOR_BROADCAST_RGB (if applicable)
> > + * - %IGT_CONNECTOR_WRITEBACK_FB_ID
> > + * - %IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR
> > * - igt_output_override_mode() to default.
> > *
> > * For pipes:
> > @@ -1970,6 +1982,8 @@ void igt_display_require(igt_display_t *display, int
> > drm_fd)
> >
> > display->drm_fd = drm_fd;
> >
> > + drmSetClientCap(drm_fd, DRM_CLIENT_CAP_WRITEBACK_CONNECTORS, 1);
> > +
> > resources = drmModeGetResources(display->drm_fd);
> > if (!resources)
> > goto out;
> > @@ -2263,6 +2277,11 @@ static void igt_output_fini(igt_output_t *output)
> > kmstest_free_connector_config(>config);
> > free(output->name);
> > output->name = NULL;
> > +
> > + if (output->writeback_out_fence_fd != -1) {
> > + close(output->writeback_out_fence_fd);
> > + output->writeback_out_fence_fd = -1;
> > + }
> > }
> >
> > /**
> > @@ -3325,6 +3344,11 @@ static void
> > igt_atomic_prepare_connector_commit(igt_output_t *output, drmModeAto
> > output->props[i],
> > output->values[i]));
> > }
> > +
> > + if (output->writeback_out_fence_fd != -1) {
> > + close(output->writeback_out_fence_fd);
> > + output->writeback_out_fence_fd = -1;
> > + }
> > }
> >
> > /*
> > @@ -3447,6 +3471,16 @@ display_commit_changed(igt_display_t *display, enum
> > igt_commit_style s)
> > else
> > /* no modeset in universal commit, no change to crtc.
> > */
> > output->changed &= 1 << IGT_CONNECTOR_CRTC_ID;
> > +
> > + if (s == COMMIT_ATOMIC) {
> > + if (igt_output_is_prop_changed(output,
> > IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR))
> > + igt_assert(output->writeback_out_fence_fd >=
> > 0);
> > +
> > + output->values[IGT_CONNECTOR_WRITEBACK_OUT_FENCE_PTR]
> > = 0;
> > + output->values[IGT_CONNECTOR_WRITEBACK_FB_ID] = 0;
> > +
Re: [Intel-gfx] drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 08:01:13PM +0200, Greg Kroah-Hartman wrote: > On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote: > > On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman > > wrote: > > > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote: > > > > I could just "open code" a bunch of calls to debugfs_create_file() for > > > > these drivers, which would solve this issue, but in a more "non-drm" > > > > way. Is it worth to just do that instead of overthinking the whole > > > > thing and trying to squish it into the drm "model" of drm debugfs calls? > > > > > > An example of "open coding" this is the patch below for the sor.c > > > driver. > > > > I think open-coding is the way to go here. One of the todos is to > > extend debugfs support for crtc/connectors, but looking at the > > open-coded version we really don't need a drm-flavoured midlayer here. > > There already is debugfs support in the code for crtc/connectors, these > files are "hanging" off of those locations already. I'll keep that, but > indent it one more directory so that there's no namespace collisions. The todo was to have some drm wrappers here for the boilerplate, but after looking at your version that's not a good idea. So not just making sure crtcs/connectors have a debugfs directory made for them, but more. Wrt adding a new directory: debugfs isnt uapi, but there's usually a massive pile of script relying on them, so it's not nice to shuffle paths around. Plus the lifetimes match anyway (at least if you don't hotplug connectors, which tegra doesn't do). -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/ehl/dsi: Set lane latency optimization for DW1
== Series Details == Series: series starting with [1/2] drm/i915/ehl/dsi: Set lane latency optimization for DW1 URL : https://patchwork.freedesktop.org/series/62340/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6299 -> Patchwork_13336 Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13336 absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13336, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/ Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13336: ### IGT changes ### Possible regressions * igt@gem_sync@basic-store-each: - fi-cfl-8109u: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-cfl-8109u/igt@gem_s...@basic-store-each.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-cfl-8109u/igt@gem_s...@basic-store-each.html Known issues Here are the changes found in Patchwork_13336 that come from known issues: ### IGT changes ### Issues hit * igt@gem_cpu_reloc@basic: - fi-icl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#110246]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-guc/igt@gem_cpu_re...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-icl-guc/igt@gem_cpu_re...@basic.html * igt@gem_mmap@basic: - fi-icl-u3: [PASS][5] -> [DMESG-WARN][6] ([fdo#107724]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u3/igt@gem_m...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-icl-u3/igt@gem_m...@basic.html Possible fixes * igt@gem_cpu_reloc@basic: - fi-icl-dsi: [INCOMPLETE][7] ([fdo#107713] / [fdo#110246]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-dsi/igt@gem_cpu_re...@basic.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-icl-dsi/igt@gem_cpu_re...@basic.html * igt@gem_sync@basic-store-each: - fi-kbl-7567u: [FAIL][9] -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-kbl-7567u/igt@gem_s...@basic-store-each.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-kbl-7567u/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][11] ([fdo#107718]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-blb-e6850/igt@i915_module_l...@reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [FAIL][13] ([fdo#108511]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@i915_selftest@live_contexts: - fi-bdw-gvtdvm: [DMESG-FAIL][15] ([fdo#110235]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-bdw-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][17] ([fdo#102614]) -> [PASS][18] [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13336/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 [fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246 Participating hosts (44 -> 36) -- Additional (1): fi-bdw-5557u Missing(9): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6299 -> Patchwork_13336 CI_DRM_6299: 2a6cf9f4dc05b77beab4b7d9d1c9f16c7e55a001 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @
Re: [Intel-gfx] [PATCH 4/6] drm/i915: skip forcewake actions on forcewake-less uncore
On 6/18/19 2:00 AM, Tvrtko Ursulin wrote:
On 17/06/2019 19:09, Daniele Ceraolo Spurio wrote:
We always call some of the setup/cleanup functions for forcewake, even
if the feature is not actually available. Skipping these operations if
forcewake is not available saves us some operations on older gens and
prepares us for having a forcewake-less display uncore.
The suspend/resume functions have also been renamed to clearly indicate
that they only operate on forcewake status.
Signed-off-by: Daniele Ceraolo Spurio
---
drivers/gpu/drm/i915/i915_drv.c | 15 +--
drivers/gpu/drm/i915/intel_uncore.c | 147 +---
drivers/gpu/drm/i915/intel_uncore.h | 8 +-
3 files changed, 101 insertions(+), 69 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c
b/drivers/gpu/drm/i915/i915_drv.c
index d113296cbe34..95b36fe17f99 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -996,7 +996,7 @@ static int i915_driver_init_mmio(struct
drm_i915_private *dev_priv)
intel_device_info_init_mmio(dev_priv);
- intel_uncore_prune_mmio_domains(_priv->uncore);
+ intel_uncore_prune_forcewake_domains(_priv->uncore);
intel_uc_init_mmio(dev_priv);
@@ -2152,7 +2152,7 @@ static int i915_drm_suspend_late(struct
drm_device *dev, bool hibernation)
i915_gem_suspend_late(dev_priv);
- intel_uncore_suspend(_priv->uncore);
+ intel_uncore_forcewake_suspend(_priv->uncore);
intel_power_domains_suspend(dev_priv,
get_suspend_mode(dev_priv, hibernation));
@@ -2348,7 +2348,10 @@ static int i915_drm_resume_early(struct
drm_device *dev)
DRM_ERROR("Resume prepare failed: %d, continuing anyway\n",
ret);
- intel_uncore_resume_early(_priv->uncore);
+ if (intel_uncore_unclaimed_mmio(_priv->uncore))
+ DRM_DEBUG("unclaimed mmio detected on resume, clearing\n");
+
Why does this bit needs to be pulled up to this level? My first line of
thinking is that we should aim to keep the component specific steps
down, if possible.
The idea was to split this out to have the function below act on
forcewake only. Chris didn't like it either, so I'm going to roll back
these changes.
+ intel_uncore_forcewake_resume_early(_priv->uncore);
i915_check_and_clear_faults(dev_priv);
@@ -2923,7 +2926,7 @@ static int intel_runtime_suspend(struct device
*kdev)
intel_runtime_pm_disable_interrupts(dev_priv);
- intel_uncore_suspend(_priv->uncore);
+ intel_uncore_forcewake_suspend(_priv->uncore);
ret = 0;
if (INTEL_GEN(dev_priv) >= 11) {
@@ -2940,7 +2943,7 @@ static int intel_runtime_suspend(struct device
*kdev)
if (ret) {
DRM_ERROR("Runtime suspend failed, disabling it (%d)\n", ret);
- intel_uncore_runtime_resume(_priv->uncore);
+ intel_uncore_forcewake_runtime_resume(_priv->uncore);
intel_runtime_pm_enable_interrupts(dev_priv);
@@ -3038,7 +3041,7 @@ static int intel_runtime_resume(struct device
*kdev)
ret = vlv_resume_prepare(dev_priv, true);
}
- intel_uncore_runtime_resume(_priv->uncore);
+ intel_uncore_forcewake_runtime_resume(_priv->uncore);
intel_runtime_pm_enable_interrupts(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c
b/drivers/gpu/drm/i915/intel_uncore.c
index 88a69bf713c9..c0f5567ee096 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -485,12 +485,11 @@ check_for_unclaimed_mmio(struct intel_uncore
*uncore)
return ret;
}
-static void __intel_uncore_early_sanitize(struct intel_uncore *uncore,
+static void forcewake_early_sanitize(struct intel_uncore *uncore,
unsigned int restore_forcewake)
{
- /* clear out unclaimed reg detection bit */
- if (check_for_unclaimed_mmio(uncore))
- DRM_DEBUG("unclaimed mmio detected on uncore init, clearing\n");
+ if (!intel_uncore_has_forcewake(uncore))
+ return;
/* WaDisableShadowRegForCpd:chv */
if (IS_CHERRYVIEW(uncore->i915)) {
@@ -513,8 +512,11 @@ static void __intel_uncore_early_sanitize(struct
intel_uncore *uncore,
iosf_mbi_punit_release();
}
-void intel_uncore_suspend(struct intel_uncore *uncore)
+void intel_uncore_forcewake_suspend(struct intel_uncore *uncore)
{
+ if (!intel_uncore_has_forcewake(uncore))
+ return;
+
iosf_mbi_punit_acquire();
iosf_mbi_unregister_pmic_bus_access_notifier_unlocked(
>pmic_bus_access_nb);
@@ -522,18 +524,24 @@ void intel_uncore_suspend(struct intel_uncore
*uncore)
iosf_mbi_punit_release();
}
-void intel_uncore_resume_early(struct intel_uncore *uncore)
+void intel_uncore_forcewake_resume_early(struct intel_uncore *uncore)
{
unsigned int restore_forcewake;
+ if (!intel_uncore_has_forcewake(uncore))
+ return;
+
restore_forcewake = fetch_and_zero(>fw_domains_saved);
- __intel_uncore_early_sanitize(uncore,
[Intel-gfx] ✓ Fi.CI.BAT: success for i915/gem_ctx_engine: Prevent preemption
== Series Details == Series: i915/gem_ctx_engine: Prevent preemption URL : https://patchwork.freedesktop.org/series/62342/ State : success == Summary == CI Bug Log - changes from CI_DRM_6299 -> IGTPW_3174 Summary --- **SUCCESS** No regressions found. External URL: https://patchwork.freedesktop.org/api/1.0/series/62342/revisions/1/mbox/ Known issues Here are the changes found in IGTPW_3174 that come from known issues: ### IGT changes ### Issues hit * igt@gem_basic@create-fd-close: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u3/igt@gem_ba...@create-fd-close.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-icl-u3/igt@gem_ba...@create-fd-close.html * igt@gem_ctx_switch@basic-default: - fi-icl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html Possible fixes * igt@gem_cpu_reloc@basic: - fi-icl-dsi: [INCOMPLETE][5] ([fdo#107713] / [fdo#110246]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-dsi/igt@gem_cpu_re...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-icl-dsi/igt@gem_cpu_re...@basic.html * igt@gem_sync@basic-store-each: - fi-kbl-7567u: [FAIL][7] -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-kbl-7567u/igt@gem_s...@basic-store-each.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-kbl-7567u/igt@gem_s...@basic-store-each.html * igt@i915_module_load@reload: - fi-blb-e6850: [INCOMPLETE][9] ([fdo#107718]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-blb-e6850/igt@i915_module_l...@reload.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-blb-e6850/igt@i915_module_l...@reload.html * igt@i915_pm_rpm@module-reload: - fi-skl-6770hq: [FAIL][11] ([fdo#108511]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-skl-6770hq/igt@i915_pm_...@module-reload.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-skl-6770hq/igt@i915_pm_...@module-reload.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][13] ([fdo#102614]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html - fi-icl-u3: [FAIL][15] ([fdo#103167]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6299/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108511]: https://bugs.freedesktop.org/show_bug.cgi?id=108511 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 [fdo#110246]: https://bugs.freedesktop.org/show_bug.cgi?id=110246 Participating hosts (44 -> 35) -- Additional (1): fi-bdw-5557u Missing(10): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-icl-u2 fi-bsw-cyan fi-icl-y fi-byt-clapper fi-bdw-samus fi-snb-2600 Build changes - * IGT: IGT_5059 -> IGTPW_3174 CI_DRM_6299: 2a6cf9f4dc05b77beab4b7d9d1c9f16c7e55a001 @ git://anongit.freedesktop.org/gfx-ci/linux IGTPW_3174: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/ IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/IGTPW_3174/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Switch to per-crtc vblank vfuncs
== Series Details == Series: drm/i915: Switch to per-crtc vblank vfuncs URL : https://patchwork.freedesktop.org/series/62287/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6290_full -> Patchwork_13321_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13321_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13321_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13321_full: ### IGT changes ### Possible regressions * igt@gem_ctx_shared@exec-shared-gtt-bsd1: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-apl4/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-apl8/igt@gem_ctx_sha...@exec-shared-gtt-bsd1.html Known issues Here are the changes found in Patchwork_13321_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@vecs0-s3: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#108566]) +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-apl6/igt@gem_ctx_isolat...@vecs0-s3.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-apl4/igt@gem_ctx_isolat...@vecs0-s3.html * igt@gem_eio@unwedge-stress: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-kbl6/igt@gem_...@unwedge-stress.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-kbl2/igt@gem_...@unwedge-stress.html * igt@gem_exec_nop@basic-parallel: - shard-iclb: [PASS][7] -> [INCOMPLETE][8] ([fdo#107713]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-iclb6/igt@gem_exec_...@basic-parallel.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-iclb7/igt@gem_exec_...@basic-parallel.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: - shard-snb: [PASS][9] -> [DMESG-WARN][10] ([fdo#110789] / [fdo#110913 ]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-snb4/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-snb2/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html * igt@gem_userptr_blits@sync-unmap-cycles: - shard-apl: [PASS][11] -> [DMESG-WARN][12] ([fdo#110913 ]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-apl2/igt@gem_userptr_bl...@sync-unmap-cycles.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-apl2/igt@gem_userptr_bl...@sync-unmap-cycles.html * igt@i915_selftest@live_hangcheck: - shard-snb: [PASS][13] -> [INCOMPLETE][14] ([fdo#105411]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-snb7/igt@i915_selftest@live_hangcheck.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-snb6/igt@i915_selftest@live_hangcheck.html * igt@kms_cursor_crc@pipe-b-cursor-256x256-sliding: - shard-kbl: [PASS][15] -> [INCOMPLETE][16] ([fdo#103665]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-kbl1/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-kbl2/igt@kms_cursor_...@pipe-b-cursor-256x256-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-64x21-sliding: - shard-skl: [PASS][17] -> [FAIL][18] ([fdo#103232]) +1 similar issue [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-64x21-sliding.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-skl4/igt@kms_cursor_...@pipe-b-cursor-64x21-sliding.html * igt@kms_cursor_crc@pipe-b-cursor-suspend: - shard-skl: [PASS][19] -> [INCOMPLETE][20] ([fdo#110741]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-skl2/igt@kms_cursor_...@pipe-b-cursor-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13321/shard-skl6/igt@kms_cursor_...@pipe-b-cursor-suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-varying-size: - shard-hsw: [PASS][21] -> [FAIL][22] ([fdo#103355]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-varying-size.html [22]:
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Implement read-only support in whitelist selftest
== Series Details == Series: drm/i915: Implement read-only support in whitelist selftest URL : https://patchwork.freedesktop.org/series/62339/ State : failure == Summary == Applying: drm/i915: Implement read-only support in whitelist selftest error: sha1 information is lacking or useless (drivers/gpu/drm/i915/gt/intel_workarounds.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 drm/i915: Implement read-only support in whitelist selftest When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ 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_ctx_engine: Prevent preemption
In order to pin the engine as busy, we have to prevent the kernel from
executing other independent work ahead of our plug, so tell the spinner
to not allow preemption.
Signed-off-by: Chris Wilson
---
tests/i915/gem_ctx_engines.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/tests/i915/gem_ctx_engines.c b/tests/i915/gem_ctx_engines.c
index 3ecade417..d47cbdd7c 100644
--- a/tests/i915/gem_ctx_engines.c
+++ b/tests/i915/gem_ctx_engines.c
@@ -283,7 +283,8 @@ static void execute_one(int i915)
spin = igt_spin_new(i915,
.ctx = param.ctx_id,
- .engine = 0);
+ .engine = 0,
+ .flags = IGT_SPIN_NO_PREEMPTION);
igt_debug("Testing with map of %d engines\n", i + 1);
memset(, -1, sizeof(engines.engines));
--
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: Implement read-only support in whitelist selftest
Tvrtko, does this look plausible?
It seems to work for me in that it passes on ICL with the new read-only
registers. I'm not sure if there is a valid way to detect whether the
registers are actually readable though. How would the test know what is
a valid value? If one assumes that one gets back zero from an invalid
read, how does one know that the read-only register is not supposed to
return zero at this point anyway?
Or is it worth just putting in a test for non-zero and if we do find a
register that can validly return zero then we special case that one and
ignore it?
John.
On 6/18/2019 12:54, john.c.harri...@intel.com wrote:
From: John Harrison
Newer hardware supports extra feature in the whitelist registers. This
patch updates the selftest to test that entries marked as read only
are actually read only.
Also updated the read/write access definitions to make it clearer that
they are an enum field not a set of single bit flags.
Signed-off-by: John Harrison
CC: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +--
.../gpu/drm/i915/gt/selftest_workarounds.c| 53 +--
drivers/gpu/drm/i915/i915_reg.h | 9 ++--
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 93caa7b6d7a9..4429ee08b20e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1028,7 +1028,7 @@ whitelist_reg_ext(struct i915_wa_list *wal, i915_reg_t
reg, u32 flags)
static void
whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
{
- whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_RW);
+ whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_ACCESS_RW);
}
static void gen9_whitelist_build(struct i915_wa_list *w)
@@ -1134,13 +1134,13 @@ printk(KERN_INFO "%-32s:%4d> Boo! [engine = %s,
instance = %d, base = 0x%X, reg
/* hucStatusRegOffset */
whitelist_reg_ext(w, _MMIO(0x2000 + engine->mmio_base),
- RING_FORCE_TO_NONPRIV_RD);
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
/* hucUKernelHdrInfoRegOffset */
whitelist_reg_ext(w, _MMIO(0x2014 + engine->mmio_base),
- RING_FORCE_TO_NONPRIV_RD);
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
/* hucStatus2RegOffset */
whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
- RING_FORCE_TO_NONPRIV_RD);
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
default:
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index eb6d3aa2c8cc..a0a88ec66861 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -399,6 +399,10 @@ static bool wo_register(struct intel_engine_cs *engine,
u32 reg)
enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
int i;
+ if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
+RING_FORCE_TO_NONPRIV_ACCESS_WR)
+ return true;
+
for (i = 0; i < ARRAY_SIZE(wo_registers); i++) {
if (wo_registers[i].platform == platform &&
wo_registers[i].reg == reg)
@@ -410,7 +414,8 @@ static bool wo_register(struct intel_engine_cs *engine, u32
reg)
static bool ro_register(u32 reg)
{
- if (reg & RING_FORCE_TO_NONPRIV_RD)
+ if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
+RING_FORCE_TO_NONPRIV_ACCESS_RD)
return true;
return false;
@@ -482,12 +487,12 @@ static int check_dirty_whitelist(struct i915_gem_context
*ctx,
u32 srm, lrm, rsvd;
u32 expect;
int idx;
+ bool ro_reg;
if (wo_register(engine, reg))
continue;
- if (ro_register(reg))
- continue;
+ ro_reg = ro_register(reg);
srm = MI_STORE_REGISTER_MEM;
lrm = MI_LOAD_REGISTER_MEM;
@@ -588,24 +593,36 @@ static int check_dirty_whitelist(struct i915_gem_context
*ctx,
}
GEM_BUG_ON(values[ARRAY_SIZE(values) - 1] != 0x);
- rsvd = results[ARRAY_SIZE(values)]; /* detect write masking */
- if (!rsvd) {
- pr_err("%s: Unable to write to whitelisted register
%x\n",
- engine->name, reg);
- err = -EINVAL;
- goto out_unpin;
+ if (ro_reg) {
+ rsvd = 0x;
+ } else {
+ rsvd = results[ARRAY_SIZE(values)]; /* detect write
masking */
+ if (!rsvd) {
+
[Intel-gfx] [PATCH 2/2] drm/i915/ehl/dsi: Enable AFE over PPI strap
The other additional step in the DSI sequqence for EHL.
BSpec: 20597
Cc: Uma Shankar
Cc: Jani Nikula
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/display/icl_dsi.c | 8
drivers/gpu/drm/i915/i915_reg.h| 4
2 files changed, 12 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index ee85428b309f..3a601c739fc6 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -542,6 +542,14 @@ static void gen11_dsi_setup_dphy_timings(struct
intel_encoder *encoder)
I915_WRITE(DSI_TA_TIMING_PARAM(port), tmp);
}
}
+
+ if (IS_ELKHARTLAKE(dev_priv)) {
+ for_each_dsi_port(port, intel_dsi->ports) {
+ tmp = I915_READ(ICL_DPHY_CHKN(port));
+ tmp |= ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP;
+ I915_WRITE(ICL_DPHY_CHKN(port), tmp);
+ }
+ }
}
static void gen11_dsi_gate_clocks(struct intel_encoder *encoder)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 1f2c3ebdf87b..dc7b34cf8b42 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1993,6 +1993,10 @@ enum i915_power_well_id {
#define N_SCALAR(x) ((x) << 24)
#define N_SCALAR_MASK(0x7F << 24)
+#define _ICL_DPHY_CHKN_REG 0x194
+#define ICL_DPHY_CHKN(port)_MMIO(_ICL_COMBOPHY(port) +
_ICL_DPHY_CHKN_REG)
+#define ICL_DPHY_CHKN_AFE_OVER_PPI_STRAP (1 << 7)
+
#define MG_PHY_PORT_LN(ln, port, ln0p1, ln0p2, ln1p1) \
_MMIO(_PORT((port) - PORT_C, ln0p1, ln0p2) + (ln) * ((ln1p1) - (ln0p1)))
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/ehl/dsi: Set lane latency optimization for DW1
From: Vandita Kulkarni
EHL has 2 additional steps in the DSI sequence, this is one of then
the lane latency optimization for DW1.
BSpec: 20597
Cc: Uma Shankar
Cc: Rodrigo Vivi
Cc: Jani Nikula
Signed-off-by: Vandita Kulkarni
---
drivers/gpu/drm/i915/display/icl_dsi.c | 11 +++
drivers/gpu/drm/i915/i915_reg.h| 2 ++
2 files changed, 13 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/icl_dsi.c
b/drivers/gpu/drm/i915/display/icl_dsi.c
index 74448e6bf749..ee85428b309f 100644
--- a/drivers/gpu/drm/i915/display/icl_dsi.c
+++ b/drivers/gpu/drm/i915/display/icl_dsi.c
@@ -403,6 +403,17 @@ static void gen11_dsi_config_phy_lanes_sequence(struct
intel_encoder *encoder)
tmp &= ~FRC_LATENCY_OPTIM_MASK;
tmp |= FRC_LATENCY_OPTIM_VAL(0x5);
I915_WRITE(ICL_PORT_TX_DW2_GRP(port), tmp);
+ /* For EHL set latency optimization for PCS_DW1 lanes */
+ if (IS_ELKHARTLAKE(dev_priv)) {
+ tmp = I915_READ(ICL_PORT_PCS_DW1_AUX(port));
+ tmp &= ~LATENCY_OPTIM_MASK;
+ tmp |= LATENCY_OPTIM_VAL(0);
+ I915_WRITE(ICL_PORT_PCS_DW1_AUX(port), tmp);
+ tmp = I915_READ(ICL_PORT_PCS_DW1_LN0(port));
+ tmp &= ~LATENCY_OPTIM_MASK;
+ tmp |= LATENCY_OPTIM_VAL(0x1);
+ I915_WRITE(ICL_PORT_PCS_DW1_GRP(port), tmp);
+ }
}
}
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index d6483b5dc8e5..1f2c3ebdf87b 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1896,6 +1896,8 @@ enum i915_power_well_id {
#define ICL_PORT_PCS_DW1_GRP(port) _MMIO(_ICL_PORT_PCS_DW_GRP(1, port))
#define ICL_PORT_PCS_DW1_LN0(port) _MMIO(_ICL_PORT_PCS_DW_LN(1, 0, port))
#define COMMON_KEEPER_EN (1 << 26)
+#define LATENCY_OPTIM_MASK (0x3 << 2)
+#define LATENCY_OPTIM_VAL(x) ((x) << 2)
/* CNL/ICL Port TX registers */
#define _CNL_PORT_TX_AE_GRP_OFFSET 0x162340
--
2.22.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Implement read-only support in whitelist selftest
From: John Harrison
Newer hardware supports extra feature in the whitelist registers. This
patch updates the selftest to test that entries marked as read only
are actually read only.
Also updated the read/write access definitions to make it clearer that
they are an enum field not a set of single bit flags.
Signed-off-by: John Harrison
CC: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 8 +--
.../gpu/drm/i915/gt/selftest_workarounds.c| 53 +--
drivers/gpu/drm/i915/i915_reg.h | 9 ++--
3 files changed, 48 insertions(+), 22 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 93caa7b6d7a9..4429ee08b20e 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1028,7 +1028,7 @@ whitelist_reg_ext(struct i915_wa_list *wal, i915_reg_t
reg, u32 flags)
static void
whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
{
- whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_RW);
+ whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_ACCESS_RW);
}
static void gen9_whitelist_build(struct i915_wa_list *w)
@@ -1134,13 +1134,13 @@ printk(KERN_INFO "%-32s:%4d> Boo! [engine = %s,
instance = %d, base = 0x%X, reg
/* hucStatusRegOffset */
whitelist_reg_ext(w, _MMIO(0x2000 + engine->mmio_base),
- RING_FORCE_TO_NONPRIV_RD);
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
/* hucUKernelHdrInfoRegOffset */
whitelist_reg_ext(w, _MMIO(0x2014 + engine->mmio_base),
- RING_FORCE_TO_NONPRIV_RD);
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
/* hucStatus2RegOffset */
whitelist_reg_ext(w, _MMIO(0x23B0 + engine->mmio_base),
- RING_FORCE_TO_NONPRIV_RD);
+ RING_FORCE_TO_NONPRIV_ACCESS_RD);
break;
default:
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index eb6d3aa2c8cc..a0a88ec66861 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -399,6 +399,10 @@ static bool wo_register(struct intel_engine_cs *engine,
u32 reg)
enum intel_platform platform = INTEL_INFO(engine->i915)->platform;
int i;
+ if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
+RING_FORCE_TO_NONPRIV_ACCESS_WR)
+ return true;
+
for (i = 0; i < ARRAY_SIZE(wo_registers); i++) {
if (wo_registers[i].platform == platform &&
wo_registers[i].reg == reg)
@@ -410,7 +414,8 @@ static bool wo_register(struct intel_engine_cs *engine, u32
reg)
static bool ro_register(u32 reg)
{
- if (reg & RING_FORCE_TO_NONPRIV_RD)
+ if ((reg & RING_FORCE_TO_NONPRIV_ACCESS_MASK) ==
+RING_FORCE_TO_NONPRIV_ACCESS_RD)
return true;
return false;
@@ -482,12 +487,12 @@ static int check_dirty_whitelist(struct i915_gem_context
*ctx,
u32 srm, lrm, rsvd;
u32 expect;
int idx;
+ bool ro_reg;
if (wo_register(engine, reg))
continue;
- if (ro_register(reg))
- continue;
+ ro_reg = ro_register(reg);
srm = MI_STORE_REGISTER_MEM;
lrm = MI_LOAD_REGISTER_MEM;
@@ -588,24 +593,36 @@ static int check_dirty_whitelist(struct i915_gem_context
*ctx,
}
GEM_BUG_ON(values[ARRAY_SIZE(values) - 1] != 0x);
- rsvd = results[ARRAY_SIZE(values)]; /* detect write masking */
- if (!rsvd) {
- pr_err("%s: Unable to write to whitelisted register
%x\n",
- engine->name, reg);
- err = -EINVAL;
- goto out_unpin;
+ if (ro_reg) {
+ rsvd = 0x;
+ } else {
+ rsvd = results[ARRAY_SIZE(values)]; /* detect write
masking */
+ if (!rsvd) {
+ pr_err("%s: Unable to write to whitelisted
register %x\n",
+ engine->name, reg);
+ err = -EINVAL;
+ goto out_unpin;
+ }
}
expect = results[0];
idx = 1;
for (v = 0; v < ARRAY_SIZE(values); v++) {
- expect = reg_write(expect, values[v], rsvd);
+ if (ro_reg)
+ expect = results[0];
+ else
+
Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/psr: Force manual PSR exit in older gens
On Tue, 2019-06-18 at 12:00 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/psr: Force manual PSR exit in older gens > URL : https://patchwork.freedesktop.org/series/62249/ > State : failure > > == Summary == > > CI Bug Log - changes from CI_DRM_6287_full -> Patchwork_13316_full > > > Summary > --- > > **FAILURE** > > Serious unknown changes coming with Patchwork_13316_full absolutely > need to be > verified manually. > > If you think the reported changes have nothing to do with the > changes > introduced in Patchwork_13316_full, please notify your bug team to > allow them > to document this new failure mode, which will reduce false > positives in CI. > > > > Possible new issues > --- > > Here are the unknown changes that may have been introduced in > Patchwork_13316_full: > > ### IGT changes ### > > Possible regressions > > * igt@gem_eio@hibernate: > - shard-snb: [PASS][1] -> [DMESG-WARN][2] >[1]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-snb4/igt@gem_...@hibernate.html >[2]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-snb6/igt@gem_...@hibernate.html > Not related so pushed to dinq, thanks for the review Rodrigo. > > Known issues > > > Here are the changes found in Patchwork_13316_full that come from > known issues: > > ### IGT changes ### > > Issues hit > > * igt@gem_eio@throttle: > - shard-kbl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 > ]) +2 similar issues >[3]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-kbl7/igt@gem_...@throttle.html >[4]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-kbl4/igt@gem_...@throttle.html > > * igt@gem_userptr_blits@sync-unmap-cycles: > - shard-apl: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 > ]) >[5]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-apl8/igt@gem_userptr_bl...@sync-unmap-cycles.html >[6]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-apl4/igt@gem_userptr_bl...@sync-unmap-cycles.html > > * igt@i915_pm_rpm@i2c: > - shard-hsw: [PASS][7] -> [FAIL][8] ([fdo#104097]) >[7]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-hsw4/igt@i915_pm_...@i2c.html >[8]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-hsw1/igt@i915_pm_...@i2c.html > > * igt@i915_selftest@live_evict: > - shard-kbl: [PASS][9] -> [INCOMPLETE][10] ([fdo#103665] > / [fdo#110938]) >[9]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-kbl2/igt@i915_selftest@live_evict.html >[10]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-kbl4/igt@i915_selftest@live_evict.html > > * igt@i915_suspend@sysfs-reader: > - shard-apl: [PASS][11] -> [DMESG-WARN][12] > ([fdo#108566]) +2 similar issues >[11]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-apl6/igt@i915_susp...@sysfs-reader.html >[12]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-apl3/igt@i915_susp...@sysfs-reader.html > > * igt@kms_cursor_crc@pipe-c-cursor-suspend: > - shard-kbl: [PASS][13] -> [DMESG-WARN][14] > ([fdo#108566]) +2 similar issues >[13]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html >[14]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-kbl2/igt@kms_cursor_...@pipe-c-cursor-suspend.html > > * igt@kms_flip@2x-flip-vs-expired-vblank-interruptible: > - shard-glk: [PASS][15] -> [FAIL][16] ([fdo#105363]) >[15]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-glk9/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html >[16]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-glk5/igt@kms_f...@2x-flip-vs-expired-vblank-interruptible.html > > * igt@kms_flip@flip-vs-suspend-interruptible: > - shard-skl: [PASS][17] -> [INCOMPLETE][18] > ([fdo#109507]) >[17]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-skl3/igt@kms_f...@flip-vs-suspend-interruptible.html >[18]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-skl8/igt@kms_f...@flip-vs-suspend-interruptible.html > > * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-spr-indfb-draw-blt: > - shard-iclb: [PASS][19] -> [FAIL][20] ([fdo#103167]) +4 > similar issues >[19]: > https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6287/shard-iclb4/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html >[20]: > https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13316/shard-iclb2/igt@kms_frontbuffer_track...@fbc-1p-primscrn-spr-indfb-draw-blt.html > > * igt@kms_frontbuffer_tracking@fbc-2p-scndscrn-spr-indfb-move: > - shard-hsw:
[Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [01/26] drm/i915: Keep engine alive as we retire the context
== Series Details == Series: series starting with [01/26] drm/i915: Keep engine alive as we retire the context URL : https://patchwork.freedesktop.org/series/62278/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6290_full -> Patchwork_13320_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13320_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13320_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13320_full: ### IGT changes ### Possible regressions * igt@gem_ctx_clone@vm: - shard-glk: [PASS][1] -> [DMESG-WARN][2] +1 similar issue [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-glk9/igt@gem_ctx_cl...@vm.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-glk6/igt@gem_ctx_cl...@vm.html - shard-iclb: [PASS][3] -> [DMESG-WARN][4] +2 similar issues [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-iclb6/igt@gem_ctx_cl...@vm.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-iclb2/igt@gem_ctx_cl...@vm.html * igt@gem_ctx_engines@execute-one: - shard-skl: [PASS][5] -> [FAIL][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-skl8/igt@gem_ctx_engi...@execute-one.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-skl7/igt@gem_ctx_engi...@execute-one.html - shard-apl: [PASS][7] -> [FAIL][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-apl2/igt@gem_ctx_engi...@execute-one.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl7/igt@gem_ctx_engi...@execute-one.html - shard-glk: [PASS][9] -> [FAIL][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-glk5/igt@gem_ctx_engi...@execute-one.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-glk7/igt@gem_ctx_engi...@execute-one.html * igt@gem_vm_create@async-destroy: - shard-skl: [PASS][11] -> [DMESG-WARN][12] +1 similar issue [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-skl5/igt@gem_vm_cre...@async-destroy.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-skl10/igt@gem_vm_cre...@async-destroy.html * igt@gem_vm_create@execbuf: - shard-hsw: [PASS][13] -> [DMESG-WARN][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-hsw6/igt@gem_vm_cre...@execbuf.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-hsw1/igt@gem_vm_cre...@execbuf.html - shard-apl: [PASS][15] -> [DMESG-WARN][16] +1 similar issue [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6290/shard-apl7/igt@gem_vm_cre...@execbuf.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl8/igt@gem_vm_cre...@execbuf.html * igt@runner@aborted: - shard-hsw: NOTRUN -> ([FAIL][17], [FAIL][18], [FAIL][19], [FAIL][20], [FAIL][21]) ([fdo#108903] / [fdo#108904] / [fdo#108905]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-hsw4/igt@run...@aborted.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-hsw1/igt@run...@aborted.html [19]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-hsw1/igt@run...@aborted.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-hsw1/igt@run...@aborted.html [21]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-hsw1/igt@run...@aborted.html - shard-apl: NOTRUN -> ([FAIL][22], [FAIL][23], [FAIL][24], [FAIL][25], [FAIL][26]) [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl4/igt@run...@aborted.html [23]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl8/igt@run...@aborted.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl8/igt@run...@aborted.html [25]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl8/igt@run...@aborted.html [26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-apl8/igt@run...@aborted.html - shard-snb: NOTRUN -> ([FAIL][27], [FAIL][28], [FAIL][29], [FAIL][30], [FAIL][31], [FAIL][32], [FAIL][33], [FAIL][34], [FAIL][35], [FAIL][36], [FAIL][37], [FAIL][38], [FAIL][39], [FAIL][40], [FAIL][41], [FAIL][42], [FAIL][43], [FAIL][44], [FAIL][45], [FAIL][46], [FAIL][47], [FAIL][48]) ([fdo#107469] / [fdo#108929]) [27]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13320/shard-snb6/igt@run...@aborted.html [28]:
Re: [Intel-gfx] [PATCH 4/6] drm/i915: skip forcewake actions on forcewake-less uncore
Quoting Daniele Ceraolo Spurio (2019-06-18 19:40:40) > > > On 6/18/19 3:22 AM, Chris Wilson wrote: > > Quoting Daniele Ceraolo Spurio (2019-06-17 19:09:33) > >> We always call some of the setup/cleanup functions for forcewake, even > >> if the feature is not actually available. Skipping these operations if > >> forcewake is not available saves us some operations on older gens and > >> prepares us for having a forcewake-less display uncore. > >> The suspend/resume functions have also been renamed to clearly indicate > >> that they only operate on forcewake status. > >> > >> Signed-off-by: Daniele Ceraolo Spurio > >> --- > >> drivers/gpu/drm/i915/i915_drv.c | 15 +-- > >> drivers/gpu/drm/i915/intel_uncore.c | 147 +--- > >> drivers/gpu/drm/i915/intel_uncore.h | 8 +- > >> 3 files changed, 101 insertions(+), 69 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/i915_drv.c > >> b/drivers/gpu/drm/i915/i915_drv.c > >> index d113296cbe34..95b36fe17f99 100644 > >> --- a/drivers/gpu/drm/i915/i915_drv.c > >> +++ b/drivers/gpu/drm/i915/i915_drv.c > >> @@ -996,7 +996,7 @@ static int i915_driver_init_mmio(struct > >> drm_i915_private *dev_priv) > >> > >> intel_device_info_init_mmio(dev_priv); > >> > >> - intel_uncore_prune_mmio_domains(_priv->uncore); > >> + intel_uncore_prune_forcewake_domains(_priv->uncore); > > > > The _prune_ was the exceptional case... > > > >> intel_uc_init_mmio(dev_priv); > >> > >> @@ -2152,7 +2152,7 @@ static int i915_drm_suspend_late(struct drm_device > >> *dev, bool hibernation) > >> > >> i915_gem_suspend_late(dev_priv); > >> > >> - intel_uncore_suspend(_priv->uncore); > >> + intel_uncore_forcewake_suspend(_priv->uncore); > > > > But are you sure you want to delegate all the fw control to i915_drv.c, > > and not keep this as a call into intel_uncore_suspend() ? It is meant to > > be telling the uncore functionality that it is time to suspend, and it > > has to work out what to save. > > > > I am not sold on this yet. (One day this will just be a bunch of async > > tasks plugged into signals with ordering determined by their > > self-declared dependency tree. One day.) > > > > So sell me on why we want an uncore_forcewake object, as currently you > > are proposing a intel_uncore_suspend_forcewake(). > > -Chris > > > > My aim was to make it clear that this call will not be required for > display_uncore since there is nothing to do on suspend/resume if there > is no forcewake (and you're right, intel_uncore_suspend_forcewake is a > better naming). Ultimately I'd like to transition the GT uncore inside > intel_gt and call this inside intel_gt_suspend(). However, I don't mind > keeping the current naming and calling it for display uncore as well to > be more generic, there are checks everywhere so the overhead should me > minimal. What's your preference? I think, for the time being a sketch like i915_drm_suspend: intel_uncore_suspend(i915->gt.uncore) intel_uncore_suspend(i915->display.uncore) is preferable. Rather than pulling the knowlegde that we need only suspend the gt.uncore because it has forcewake into the high level i915_drm_suspend. A couple of ifs or a vfunc go a long way to keeping as simple as it can be (and no simpler). At the i915_drm_suspend level it is hard enough to manage a list of components and the correct order in which to call them :) -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/ehl: Allow combo PHY A to drive a third external display (rev3)
== Series Details == Series: drm/i915/ehl: Allow combo PHY A to drive a third external display (rev3) URL : https://patchwork.freedesktop.org/series/62131/ State : success == Summary == CI Bug Log - changes from CI_DRM_6297 -> Patchwork_13334 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/ Known issues Here are the changes found in Patchwork_13334 that come from known issues: ### IGT changes ### Issues hit * igt@i915_pm_rpm@module-reload: - fi-icl-dsi: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713] / [fdo#108840]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/fi-icl-dsi/igt@i915_pm_...@module-reload.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/fi-icl-dsi/igt@i915_pm_...@module-reload.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u3: [PASS][3] -> [FAIL][4] ([fdo#103167]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/fi-icl-u3/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@debugfs_test@read_all_entries: - fi-icl-u3: [DMESG-WARN][5] ([fdo#107724]) -> [PASS][6] +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/fi-icl-u3/igt@debugfs_test@read_all_entries.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/fi-icl-u3/igt@debugfs_test@read_all_entries.html * igt@gem_sync@basic-store-each: - fi-bdw-5557u: [FAIL][7] -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/fi-bdw-5557u/igt@gem_s...@basic-store-each.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/fi-bdw-5557u/igt@gem_s...@basic-store-each.html * igt@i915_selftest@live_contexts: - fi-skl-gvtdvm: [DMESG-FAIL][9] ([fdo#110235]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/fi-skl-gvtdvm/igt@i915_selftest@live_contexts.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-u2: [FAIL][11] ([fdo#103167]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6297/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/fi-icl-u2/igt@kms_frontbuffer_track...@basic.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108840]: https://bugs.freedesktop.org/show_bug.cgi?id=108840 [fdo#110235]: https://bugs.freedesktop.org/show_bug.cgi?id=110235 Participating hosts (44 -> 36) -- Missing(8): fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-pnv-d510 fi-icl-y fi-byt-clapper fi-bdw-samus Build changes - * Linux: CI_DRM_6297 -> Patchwork_13334 CI_DRM_6297: 8ebd162995143d1cc5c3ec699891e7fe059cea4c @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13334: d46fd46525511427a67d9b29881a8ce45bfea1c7 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == d46fd4652551 drm/i915/ehl: Allow combo PHY A to drive a third external display == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13334/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 4/6] drm/i915: skip forcewake actions on forcewake-less uncore
On 6/18/19 3:22 AM, Chris Wilson wrote: Quoting Daniele Ceraolo Spurio (2019-06-17 19:09:33) We always call some of the setup/cleanup functions for forcewake, even if the feature is not actually available. Skipping these operations if forcewake is not available saves us some operations on older gens and prepares us for having a forcewake-less display uncore. The suspend/resume functions have also been renamed to clearly indicate that they only operate on forcewake status. Signed-off-by: Daniele Ceraolo Spurio --- drivers/gpu/drm/i915/i915_drv.c | 15 +-- drivers/gpu/drm/i915/intel_uncore.c | 147 +--- drivers/gpu/drm/i915/intel_uncore.h | 8 +- 3 files changed, 101 insertions(+), 69 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index d113296cbe34..95b36fe17f99 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -996,7 +996,7 @@ static int i915_driver_init_mmio(struct drm_i915_private *dev_priv) intel_device_info_init_mmio(dev_priv); - intel_uncore_prune_mmio_domains(_priv->uncore); + intel_uncore_prune_forcewake_domains(_priv->uncore); The _prune_ was the exceptional case... intel_uc_init_mmio(dev_priv); @@ -2152,7 +2152,7 @@ static int i915_drm_suspend_late(struct drm_device *dev, bool hibernation) i915_gem_suspend_late(dev_priv); - intel_uncore_suspend(_priv->uncore); + intel_uncore_forcewake_suspend(_priv->uncore); But are you sure you want to delegate all the fw control to i915_drv.c, and not keep this as a call into intel_uncore_suspend() ? It is meant to be telling the uncore functionality that it is time to suspend, and it has to work out what to save. I am not sold on this yet. (One day this will just be a bunch of async tasks plugged into signals with ordering determined by their self-declared dependency tree. One day.) So sell me on why we want an uncore_forcewake object, as currently you are proposing a intel_uncore_suspend_forcewake(). -Chris My aim was to make it clear that this call will not be required for display_uncore since there is nothing to do on suspend/resume if there is no forcewake (and you're right, intel_uncore_suspend_forcewake is a better naming). Ultimately I'd like to transition the GT uncore inside intel_gt and call this inside intel_gt_suspend(). However, I don't mind keeping the current naming and calling it for display uncore as well to be more generic, there are checks everywhere so the overhead should me minimal. What's your preference? Daniele ___ 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/ehl: Allow combo PHY A to drive a third external display (rev3)
== Series Details == Series: drm/i915/ehl: Allow combo PHY A to drive a third external display (rev3) URL : https://patchwork.freedesktop.org/series/62131/ State : warning == Summary == $ dim checkpatch origin/drm-tip d46fd4652551 drm/i915/ehl: Allow combo PHY A to drive a third external display -:67: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "i915->vbt.ddi_port_info[PORT_A].child" #67: FILE: drivers/gpu/drm/i915/display/intel_combo_phy.c:265: + bool ddi_a_present = i915->vbt.ddi_port_info[PORT_A].child != NULL; -:68: CHECK:COMPARISON_TO_NULL: Comparison to NULL could be written "i915->vbt.ddi_port_info[PORT_D].child" #68: FILE: drivers/gpu/drm/i915/display/intel_combo_phy.c:266: + bool ddi_d_present = i915->vbt.ddi_port_info[PORT_D].child != NULL; total: 0 errors, 0 warnings, 2 checks, 65 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for docs: fix some broken references due to txt->rst renames
== Series Details == Series: docs: fix some broken references due to txt->rst renames URL : https://patchwork.freedesktop.org/series/62327/ State : failure == Summary == Applying: docs: fix some broken references due to txt->rst renames error: sha1 information is lacking or useless (Documentation/devicetree/bindings/arm/idle-states.txt). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0001 docs: fix some broken references due to txt->rst renames When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915/selftests: Flush live_evict
== Series Details == Series: series starting with [1/2] drm/i915/selftests: Flush live_evict URL : https://patchwork.freedesktop.org/series/62325/ State : failure == Summary == Applying: drm/i915/selftests: Flush live_evict Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/selftests/i915_gem_evict.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/i915: Don't dereference request if it may have been retired Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/gt/intel_engine_cs.c Falling back to patching base and 3-way merge... No changes -- Patch already applied. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/todo: Update drm_gem_object_funcs todo even more
On Tuesday, 2019-06-18 16:02:41 +0200, Daniel Vetter wrote:
> I rushed merging this a bit too much, and Noralf pointed out that
> we're a lot better already and have made great progress.
>
> Let's try again.
>
> Fixes: 42dbbb4b54a3 ("drm/todo: Add new debugfs todo")
> Cc: Greg Kroah-Hartman
> Cc: Daniel Vetter
> Cc: David Airlie
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Cc: Maxime Ripard
> Cc: Sean Paul
> Cc: Thomas Zimmermann
> Cc: Gerd Hoffmann
> Cc: Rob Herring
> Cc: Noralf Trønnes
> Cc: Eric Anholt
> Cc: Gerd Hoffmann
> Signed-off-by: Daniel Vetter
> ---
> Documentation/gpu/todo.rst | 8 +---
> 1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> index 25878dd048fd..66c123737c3d 100644
> --- a/Documentation/gpu/todo.rst
> +++ b/Documentation/gpu/todo.rst
> @@ -212,9 +212,11 @@ struct drm_gem_object_funcs
> GEM objects can now have a function table instead of having the callbacks on
> the
> DRM driver struct. This is now the preferred way and drivers can be moved
> over.
>
> -Unfortunately some of the recently added GEM helpers are going in the wrong
> -direction by adding OPS macros that use the old, deprecated hooks. See
> -DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS, and
> DRM_GEM_VRAM_DRIVER_PRIME.
> +DRM_GEM_CMA_VMAP_DRIVER_OPS, DRM_GEM_SHMEM_DRIVER_OPS already support this,
> but
> +DRM_GEM_VRAM_DRIVER_PRIME does not yet and needs to be aligend with the
> previous
s/aligend/aligned/
> +two. We also need a 2nd version of the CMA define that doesn't require the
> +vmapping to be present (different hook for prime importing). Plus this needs
> to
> +be rolled out to all drivers using their own implementations, too.
>
> Use DRM_MODESET_LOCK_ALL_* helpers instead of boilerplate
> -
> --
> 2.20.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] drm/i915/blt: Remove recursive vma->lock
Hi Chris,
Thank you for the patch! Yet something to improve:
[auto build test ERROR on drm-intel/for-linux-next]
[also build test ERROR on next-20190618]
[cannot apply to v5.2-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-blt-Remove-recursive-vma-lock/20190618-194749
base: git://anongit.freedesktop.org/drm-intel for-linux-next
config: x86_64-rhel (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
All errors (new ones prefixed by >>):
drivers/gpu/drm/i915/gem/i915_gem_client_blt.c: In function
'clear_pages_worker':
>> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c:201:57: error: passing
>> argument 3 of 'i915_active_ref' from incompatible pointer type
>> [-Werror=incompatible-pointer-types]
err = i915_active_ref(>active, rq->fence.context, >fence);
^
In file included from drivers/gpu/drm/i915/i915_timeline.h:30:0,
from drivers/gpu/drm/i915/gt/intel_engine.h:17,
from drivers/gpu/drm/i915/i915_drv.h:67,
from drivers/gpu/drm/i915/intel_drv.h:45,
from drivers/gpu/drm/i915/gem/i915_gem_client_blt.c:8:
drivers/gpu/drm/i915/i915_active.h:376:5: note: expected 'struct
i915_request *' but argument is of type 'struct dma_fence *'
int i915_active_ref(struct i915_active *ref,
^~~
cc1: some warnings being treated as errors
vim +/i915_active_ref +201 drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
153
154 static void clear_pages_worker(struct work_struct *work)
155 {
156 struct clear_pages_work *w = container_of(work, typeof(*w),
work);
157 struct drm_i915_private *i915 = w->ce->gem_context->i915;
158 struct drm_i915_gem_object *obj = w->sleeve->obj;
159 struct i915_vma *vma = w->sleeve->vma;
160 struct i915_request *rq;
161 int err = w->dma.error;
162
163 if (unlikely(err))
164 goto out_signal;
165
166 if (obj->cache_dirty) {
167 obj->write_domain = 0;
168 if (i915_gem_object_has_struct_page(obj))
169 drm_clflush_sg(w->sleeve->pages);
170 obj->cache_dirty = false;
171 }
172
173 /* XXX: we need to kill this */
174 mutex_lock(>drm.struct_mutex);
175 err = i915_vma_pin(vma, 0, 0, PIN_USER);
176 if (unlikely(err))
177 goto out_unlock;
178
179 rq = i915_request_create(w->ce);
180 if (IS_ERR(rq)) {
181 err = PTR_ERR(rq);
182 goto out_unpin;
183 }
184
185 /* There's no way the fence has signalled */
186 if (dma_fence_add_callback(>fence, >cb,
187 clear_pages_dma_fence_cb))
188 GEM_BUG_ON(1);
189
190 if (w->ce->engine->emit_init_breadcrumb) {
191 err = w->ce->engine->emit_init_breadcrumb(rq);
192 if (unlikely(err))
193 goto out_request;
194 }
195
196 /*
197 * w->dma is already exported via (vma|obj)->resv we need only
198 * keep track of the GPU activity within this vma/request, and
199 * propagate the signal from the request to w->dma.
200 */
> 201 err = i915_active_ref(>active, rq->fence.context,
> >fence);
202 if (err)
203 goto out_request;
204
205 err = intel_emit_vma_fill_blt(rq, vma, w->value);
206 out_request:
207 if (unlikely(err)) {
208 i915_request_skip(rq, err);
209 err = 0;
210 }
211
212 i915_request_add(rq);
213 out_unpin:
214 i915_vma_unpin(vma);
215 out_unlock:
216 mutex_unlock(>drm.struct_mutex);
217 out_signal:
218 if (unlikely(err)) {
219 dma_fence_set_error(>dma, err);
220 dma_fence_signal(>dma);
221 dma_fence_put(>dma);
222 }
223 }
224
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 19/23] drm/i915/icl: Reserve all required PLLs for TypeC ports
On Tue, Jun 18, 2019 at 08:25:52PM +0300, Ville Syrjälä wrote:
> On Fri, Jun 07, 2019 at 08:41:29PM +0300, Imre Deak wrote:
> > When enabling a TypeC port we need to reserve all the required PLLs for
> > it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks.
> > We can select the proper PLL for the current port mode from the reserved
> > PLLs only once we selected and locked down the port mode for the whole
> > duration of the port's active state. Resetting and locking down the port
> > mode can in turn happen only during the modeset commit phase once we
> > disabled the given port and the PLL it used.
> >
> > To support the above reserve-and-select PLL semantic we store the
> > reserved PLLs along with their HW state in the CRTC state and provide a
> > way to select the active PLL from these. The selected PLL along with its
> > HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as
> > in the case of other port types.
> >
> > Besides reserving all required PLLs no functional changes.
> >
> > v2:
> > - Fix releasing the ICL PLLs, not clearing the PLLs from the old
> > crtc_state.
> >
> > Cc: Ville Syrjälä
> > Cc: Daniel Vetter
> > Cc: Maarten Lankhorst
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_display.c | 11 +-
> > drivers/gpu/drm/i915/intel_dpll_mgr.c | 151 +++---
> > drivers/gpu/drm/i915/intel_dpll_mgr.h | 9 ++
> > drivers/gpu/drm/i915/intel_drv.h | 9 ++
> > 4 files changed, 138 insertions(+), 42 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 7381fb2e1240..006be3c3f1bd 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -9880,6 +9880,7 @@ static void icelake_get_ddi_pll(struct
> > drm_i915_private *dev_priv,
> > enum port port,
> > struct intel_crtc_state *pipe_config)
> > {
> > + enum icl_port_dpll_id port_dpll_id;
> > enum intel_dpll_id id;
> > u32 temp;
> >
> > @@ -9887,22 +9888,28 @@ static void icelake_get_ddi_pll(struct
> > drm_i915_private *dev_priv,
> > temp = I915_READ(DPCLKA_CFGCR0_ICL) &
> >DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> > id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
> > + port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> > } else if (intel_port_is_tc(dev_priv, port)) {
> > u32 clk_sel = I915_READ(DDI_CLK_SEL(port)) & DDI_CLK_SEL_MASK;
> >
> > if (clk_sel == DDI_CLK_SEL_MG) {
> > id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv,
> > port));
> > + port_dpll_id = ICL_PORT_DPLL_MG_PHY;
> > } else {
> > WARN_ON(clk_sel < DDI_CLK_SEL_TBT_162);
> > id = DPLL_ID_ICL_TBTPLL;
> > + port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> > }
> > } else {
> > WARN(1, "Invalid port %x\n", port);
> > return;
> > }
> >
> > - pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> > + pipe_config->icl_port_dplls[port_dpll_id].pll =
> > + intel_get_shared_dpll_by_id(dev_priv, id);
> > +
> > + icl_set_active_port_dpll(pipe_config, port_dpll_id);
> > }
> >
> > static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
> > @@ -12041,6 +12048,8 @@ clear_intel_crtc_state(struct intel_crtc_state
> > *crtc_state)
> > saved_state->scaler_state = crtc_state->scaler_state;
> > saved_state->shared_dpll = crtc_state->shared_dpll;
> > saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> > + memcpy(saved_state->icl_port_dplls, crtc_state->icl_port_dplls,
> > + sizeof(saved_state->icl_port_dplls));
> > saved_state->crc_enabled = crtc_state->crc_enabled;
> > if (IS_G4X(dev_priv) ||
> > IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> > diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > index 8ac293db43a5..17441d5f990e 100644
> > --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> > @@ -2856,34 +2856,79 @@ static bool icl_calc_mg_pll_state(struct
> > intel_crtc_state *crtc_state,
> > return true;
> > }
> >
> > +/**
> > + * icl_set_active_port_dpll - select the active port DPLL for a given CRTC
> > + * @crtc_state: state for the CRTC to select the DPLL for
> > + * @port_dpll_id: the active @port_dpll_id to select
> > + *
> > + * Select the given @port_dpll_id instance from the DPLLs reserved for the
> > + * CRTC.
> > + */
> > +void icl_set_active_port_dpll(struct intel_crtc_state *crtc_state,
> > + enum icl_port_dpll_id port_dpll_id)
> > +{
> > + struct icl_port_dpll *port_dpll =
> > +
Re: [Intel-gfx] drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 07:32:20PM +0200, Daniel Vetter wrote:
> On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
> wrote:
> > On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > > Greg is busy already, but maybe he won't do everything ...
> > > >
> > > > Cc: Greg Kroah-Hartman
> > > > Signed-off-by: Daniel Vetter
> > > > ---
> > > > Documentation/gpu/todo.rst | 3 +++
> > > > 1 file changed, 3 insertions(+)
> > > >
> > > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > > index 9717540ee28f..026e55c517e1 100644
> > > > --- a/Documentation/gpu/todo.rst
> > > > +++ b/Documentation/gpu/todo.rst
> > > > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> > > >this (together with the drm_minor->drm_device move) would allow us
> > > > to remove
> > > >debugfs_init.
> > > >
> > > > +- Drop the return code and error checking from all debugfs functions.
> > > > Greg KH is
> > > > + working on this already.
> > >
> > >
> > > Part of this work was to try to delete drm_debugfs_remove_files().
> > >
> > > There are only 4 files that currently still call this function:
> > > drivers/gpu/drm/tegra/dc.c
> > > drivers/gpu/drm/tegra/dsi.c
> > > drivers/gpu/drm/tegra/hdmi.c
> > > drivers/gpu/drm/tegra/sor.c
> > >
> > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> > > debugfs directory. Which is fine, but it has to do some special memory
> > > allocation to get the debugfs callback to point not to the struct
> > > drm_minor pointer, but rather the drm_crtc structure.
>
> There's already a todo to switch the drm_minor debugfs stuff over to
> drm_device. drm_minor is essentially different uapi flavours (/dev/
> minor nodes, hence the name) sitting on top of the same drm_device.
> Last time I checked all the debugfs files want the drm_device, not the
> minor. I think we even discussed to only register the debugfs files
> for the first minor, and create the other ones as symlinks to the
> first one. But haven't yet gotten around to typing that.
>
> drm_crtc/connector are parts of drm_device with modesetting support,
> so the drm_minor is even worse choice really.
Heh, ok, so the existing code is working around that choice right now,
but that wasn't a good choice, so I'll ignore it :)
> Not exactly sure why we went with this, but probably dates back to the
> *bsd compat layer and a lot of these files hanging out in procfs too
> (we've fixed those mistakes a few years ago, yay!).
>
> > > So, to remove this call, I need to remove this special memory allocation
> > > and to do that, I need to somehow be able to cast from drm_minor back to
> > > the drm_crtc structure being used in this driver. And I can't figure
> > > how they are related at all.
> > >
> > > Any pointers here (pun intended) would be appreciated.
> > >
> > > For the other 3 files, the situation is much the same, but I need to get
> > > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.
>
> Ditch the drm_minor, there's no no way to get from that to something
> like drm_connector/crtc, since it's a n:m relationship.
Ok, will do.
>
> > > I could just "open code" a bunch of calls to debugfs_create_file() for
> > > these drivers, which would solve this issue, but in a more "non-drm"
> > > way. Is it worth to just do that instead of overthinking the whole
> > > thing and trying to squish it into the drm "model" of drm debugfs calls?
> >
> > An example of "open coding" this is the patch below for the sor.c
> > driver.
>
> I think open-coding is the way to go here. One of the todos is to
> extend debugfs support for crtc/connectors, but looking at the
> open-coded version we really don't need a drm-flavoured midlayer here.
There already is debugfs support in the code for crtc/connectors, these
files are "hanging" off of those locations already. I'll keep that, but
indent it one more directory so that there's no namespace collisions.
> > Totally untested, not even built, but you should get the idea here.
> >
> > thanks,
> >
> > greg k-h
> >
> > ---
> >
> > diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> > index 5be5a0817dfe..3216221c77c4 100644
> > --- a/drivers/gpu/drm/tegra/sor.c
> > +++ b/drivers/gpu/drm/tegra/sor.c
> > @@ -414,7 +414,8 @@ struct tegra_sor {
> >
> > struct drm_dp_aux *aux;
> >
> > - struct drm_info_list *debugfs_files;
> > + struct dentry *debugfs_root;
> > + struct drm_device *drm;
> >
> > const struct tegra_sor_ops *ops;
> > enum tegra_io_pad pad;
> > @@ -1262,10 +1263,9 @@ static int tegra_sor_crc_wait(struct tegra_sor *sor,
> > unsigned long timeout)
> >
> > static int tegra_sor_show_crc(struct seq_file *s, void *data)
> > {
> > - struct drm_info_node *node = s->private;
> > - struct tegra_sor *sor = node->info_ent->data;
> > +
[Intel-gfx] [PATCH v3] drm/i915/ehl: Allow combo PHY A to drive a third external display
EHL has a mux on combo PHY A that allows it to be driven either by an
internal display (DDI-A or DSI DPHY) or by an external display (DDI-D).
This is a motherboard design decision that can not be changed on the
fly. Unfortunately there are no strap registers that allow us to detect
the board configuration directly, so let's use the VBT to try to figure
it out and program the mux accordingly.
For now if we run across a broken VBT that tries to claim that PHY A
is attached to both internal and external displays at the same time,
we'll resolve the conflict in favor of the internal display. To help
debug these kind of bad VBT's, let's also add a quick DRM_DEBUG message
during child device parsing so that it's easier to understand these
cases if they show up in bug reports.
v2:
- Confirmed that VBT's dvo port refers to the DDI and not the PHY.
Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If
a bad VBT contradicts itself, let internal display win. (Ville)
v3:
- Switch condition from !IS_ICELAKE to IS_ELKHARTLAKE. Although the
convention is usually to assume that future platforms will inherit
all current platform behavior, this feels more like a one-platform
quirk. (Ville)
- Update commit message to describe what we do if/when we encounter
broken VBT's, and note that the new debug print during child device
parsing is intentional.
Cc: Clint Taylor
Cc: Ville Syrjälä
Signed-off-by: Matt Roper
Reviewed-by: Ville Syrjälä
---
drivers/gpu/drm/i915/display/intel_bios.c | 3 ++
.../gpu/drm/i915/display/intel_combo_phy.c| 36 +++
drivers/gpu/drm/i915/i915_reg.h | 1 +
3 files changed, 40 insertions(+)
diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
b/drivers/gpu/drm/i915/display/intel_bios.c
index c4710889cb32..0c9808132d67 100644
--- a/drivers/gpu/drm/i915/display/intel_bios.c
+++ b/drivers/gpu/drm/i915/display/intel_bios.c
@@ -1668,6 +1668,9 @@ parse_general_definitions(struct drm_i915_private
*dev_priv,
if (!child->device_type)
continue;
+ DRM_DEBUG_KMS("Found VBT child device with type 0x%x\n",
+ child->device_type);
+
/*
* Copy as much as we know (sizeof) and is available
* (child_dev_size) of the child device. Accessing the data must
diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
b/drivers/gpu/drm/i915/display/intel_combo_phy.c
index 841708da5a56..075bab2500eb 100644
--- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
+++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
@@ -260,6 +260,32 @@ void intel_combo_phy_power_up_lanes(struct
drm_i915_private *dev_priv,
I915_WRITE(ICL_PORT_CL_DW10(port), val);
}
+static u32 ehl_combo_phy_a_mux(struct drm_i915_private *i915, u32 val)
+{
+ bool ddi_a_present = i915->vbt.ddi_port_info[PORT_A].child != NULL;
+ bool ddi_d_present = i915->vbt.ddi_port_info[PORT_D].child != NULL;
+ bool dsi_present = intel_bios_is_dsi_present(i915, NULL);
+
+ /*
+* VBT's 'dvo port' field for child devices references the DDI, not
+* the PHY. So if combo PHY A is wired up to drive an external
+* display, we should see a child device present on PORT_D and
+* nothing on PORT_A and no DSI.
+*/
+ if (ddi_d_present && !ddi_a_present && !dsi_present)
+ return val | ICL_PHY_MISC_MUX_DDID;
+
+ /*
+* If we encounter a VBT that claims to have an external display on
+* DDI-D _and_ an internal display on DDI-A/DSI leave an error message
+* in the log and let the internal display win.
+*/
+ if (ddi_d_present)
+ DRM_ERROR("VBT claims to have both internal and external
displays on PHY A. Configuring for internal.\n");
+
+ return val & ~ICL_PHY_MISC_MUX_DDID;
+}
+
static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
{
enum port port;
@@ -273,7 +299,17 @@ static void icl_combo_phys_init(struct drm_i915_private
*dev_priv)
continue;
}
+ /*
+* EHL's combo PHY A can be hooked up to either an external
+* display (via DDI-D) or an internal display (via DDI-A or
+* the DSI DPHY). This is a motherboard design decision that
+* can't be changed on the fly, so initialize the PHY's mux
+* based on whether our VBT indicates the presence of any
+* "internal" child devices.
+*/
val = I915_READ(ICL_PHY_MISC(port));
+ if (IS_ELKHARTLAKE(dev_priv) && port == PORT_A)
+ val = ehl_combo_phy_a_mux(dev_priv, val);
val &= ~ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN;
I915_WRITE(ICL_PHY_MISC(port), val);
diff --git a/drivers/gpu/drm/i915/i915_reg.h
Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Allow combo PHY A to drive a third external display
On Tue, Jun 18, 2019 at 10:30:06AM -0700, Matt Roper wrote:
> On Tue, Jun 18, 2019 at 07:08:55PM +0300, Ville Syrjälä wrote:
> > On Mon, Jun 17, 2019 at 04:48:10PM -0700, Matt Roper wrote:
> > > EHL has a mux on combo PHY A that allows it to be driven either by an
> > > internal display (DDI-A or DSI DPHY) or by an external display (DDI-D).
> > > This is a motherboard design decision that can not be changed on the
> > > fly. Unfortunately there are no strap registers that allow us to detect
> > > the board configuration directly, so let's use the VBT to try to figure
> > > it out and program the mux accordingly.
> > >
> > > v2:
> > > - Confirmed that VBT's dvo port refers to the DDI and not the PHY.
> > >Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If
> > >a bad VBT contradicts itself, let internal display win. (Ville)
> > >
> > > Cc: Clint Taylor
> > > Cc: Ville Syrjälä
> > > Signed-off-by: Matt Roper
> > > ---
> > > drivers/gpu/drm/i915/display/intel_bios.c | 3 ++
> > > .../gpu/drm/i915/display/intel_combo_phy.c| 36 +++
> > > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > > 3 files changed, 40 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > > b/drivers/gpu/drm/i915/display/intel_bios.c
> > > index c4710889cb32..0c9808132d67 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > > @@ -1668,6 +1668,9 @@ parse_general_definitions(struct drm_i915_private
> > > *dev_priv,
> > > if (!child->device_type)
> > > continue;
> > >
> > > + DRM_DEBUG_KMS("Found VBT child device with type 0x%x\n",
> > > + child->device_type);
> > > +
> >
> > Was this hunk intentional?
> >
>
> Yeah, I figured that having a little more detail on the child device
> details will probably be useful for debugging any cases where the VBT
> seems to contradict itself. I'll add a note about the debug message to
> the commit message to make it clear it's intentional.
>
>
> > > /*
> > >* Copy as much as we know (sizeof) and is available
> > >* (child_dev_size) of the child device. Accessing the data must
> > > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > > b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > > index 841708da5a56..c18079a09a2e 100644
> > > --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > > +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > > @@ -260,6 +260,32 @@ void intel_combo_phy_power_up_lanes(struct
> > > drm_i915_private *dev_priv,
> > > I915_WRITE(ICL_PORT_CL_DW10(port), val);
> > > }
> > >
> > > +static u32 ehl_combo_phy_a_mux(struct drm_i915_private *i915, u32 val)
> > > +{
> > > + bool ddi_a_present = i915->vbt.ddi_port_info[PORT_A].child != NULL;
> > > + bool ddi_d_present = i915->vbt.ddi_port_info[PORT_D].child != NULL;
> > > + bool dsi_present = intel_bios_is_dsi_present(i915, NULL);
> > > +
> > > + /*
> > > + * VBT's 'dvo port' field for child devices references the DDI, not
> > > + * the PHY. So if combo PHY A is wired up to drive an external
> > > + * display, we should see a child device present on PORT_D and
> > > + * nothing on PORT_A and no DSI.
> > > + */
> > > + if (ddi_d_present && !ddi_a_present && !dsi_present)
> > > + return val | ICL_PHY_MISC_MUX_DDID;
> > > +
> > > + /*
> > > + * If we encounter a VBT that claims to have an external display on
> > > + * DDI-D _and_ an internal display on DDI-A/DSI leave an error message
> > > + * in the log and let the internal display win.
> > > + */
> > > + if (ddi_d_present)
> > > + DRM_ERROR("VBT claims to have both internal and external
> > > displays on PHY A. Configuring for internal.\n");
> > > +
> > > + return val & ~ICL_PHY_MISC_MUX_DDID;
> > > +}
> > > +
> > > static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> > > {
> > > enum port port;
> > > @@ -273,7 +299,17 @@ static void icl_combo_phys_init(struct
> > > drm_i915_private *dev_priv)
> > > continue;
> > > }
> > >
> > > + /*
> > > + * EHL's combo PHY A can be hooked up to either an external
> > > + * display (via DDI-D) or an internal display (via DDI-A or
> > > + * the DSI DPHY). This is a motherboard design decision that
> > > + * can't be changed on the fly, so initialize the PHY's mux
> > > + * based on whether our VBT indicates the presence of any
> > > + * "internal" child devices.
> > > + */
> > > val = I915_READ(ICL_PHY_MISC(port));
> > > + if (!IS_ICELAKE(dev_priv) && port == PORT_A)
> >
> > Maybe IS_EHL instead?
>
> That's how I was originally going to write it, but I switched it to !icl
> to follow the general convention of "assume future platforms inherit all
> behavior of current platform."
This feels like a
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't dereference request if it may have been retired
Quoting Tvrtko Ursulin (2019-06-18 17:58:02) > > On 18/06/2019 17:19, Chris Wilson wrote: > > This has count me out on countless occasions, when we retrieve a pointer > > from the submission/execlists backend, it does not carry a reference to > > the context or ring. Those are only pinned while the rquest is active, > > so if we see the request is completed, it may be in the process of being > > retired and those pointers defunct. > > > > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110938 > > Signed-off-by: Chris Wilson [snip] > Reviewed-by: Tvrtko Ursulin Thanks for the quick review, pushed to see if CI wakes up happy in the morning. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 5:25 PM Greg Kroah-Hartman
wrote:
> On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > > Greg is busy already, but maybe he won't do everything ...
> > >
> > > Cc: Greg Kroah-Hartman
> > > Signed-off-by: Daniel Vetter
> > > ---
> > > Documentation/gpu/todo.rst | 3 +++
> > > 1 file changed, 3 insertions(+)
> > >
> > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > > index 9717540ee28f..026e55c517e1 100644
> > > --- a/Documentation/gpu/todo.rst
> > > +++ b/Documentation/gpu/todo.rst
> > > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> > >this (together with the drm_minor->drm_device move) would allow us to
> > > remove
> > >debugfs_init.
> > >
> > > +- Drop the return code and error checking from all debugfs functions.
> > > Greg KH is
> > > + working on this already.
> >
> >
> > Part of this work was to try to delete drm_debugfs_remove_files().
> >
> > There are only 4 files that currently still call this function:
> > drivers/gpu/drm/tegra/dc.c
> > drivers/gpu/drm/tegra/dsi.c
> > drivers/gpu/drm/tegra/hdmi.c
> > drivers/gpu/drm/tegra/sor.c
> >
> > For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> > debugfs directory. Which is fine, but it has to do some special memory
> > allocation to get the debugfs callback to point not to the struct
> > drm_minor pointer, but rather the drm_crtc structure.
There's already a todo to switch the drm_minor debugfs stuff over to
drm_device. drm_minor is essentially different uapi flavours (/dev/
minor nodes, hence the name) sitting on top of the same drm_device.
Last time I checked all the debugfs files want the drm_device, not the
minor. I think we even discussed to only register the debugfs files
for the first minor, and create the other ones as symlinks to the
first one. But haven't yet gotten around to typing that.
drm_crtc/connector are parts of drm_device with modesetting support,
so the drm_minor is even worse choice really.
Not exactly sure why we went with this, but probably dates back to the
*bsd compat layer and a lot of these files hanging out in procfs too
(we've fixed those mistakes a few years ago, yay!).
> > So, to remove this call, I need to remove this special memory allocation
> > and to do that, I need to somehow be able to cast from drm_minor back to
> > the drm_crtc structure being used in this driver. And I can't figure
> > how they are related at all.
> >
> > Any pointers here (pun intended) would be appreciated.
> >
> > For the other 3 files, the situation is much the same, but I need to get
> > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.
Ditch the drm_minor, there's no no way to get from that to something
like drm_connector/crtc, since it's a n:m relationship.
> > I could just "open code" a bunch of calls to debugfs_create_file() for
> > these drivers, which would solve this issue, but in a more "non-drm"
> > way. Is it worth to just do that instead of overthinking the whole
> > thing and trying to squish it into the drm "model" of drm debugfs calls?
>
> An example of "open coding" this is the patch below for the sor.c
> driver.
I think open-coding is the way to go here. One of the todos is to
extend debugfs support for crtc/connectors, but looking at the
open-coded version we really don't need a drm-flavoured midlayer here.
> Totally untested, not even built, but you should get the idea here.
>
> thanks,
>
> greg k-h
>
> ---
>
> diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
> index 5be5a0817dfe..3216221c77c4 100644
> --- a/drivers/gpu/drm/tegra/sor.c
> +++ b/drivers/gpu/drm/tegra/sor.c
> @@ -414,7 +414,8 @@ struct tegra_sor {
>
> struct drm_dp_aux *aux;
>
> - struct drm_info_list *debugfs_files;
> + struct dentry *debugfs_root;
> + struct drm_device *drm;
>
> const struct tegra_sor_ops *ops;
> enum tegra_io_pad pad;
> @@ -1262,10 +1263,9 @@ static int tegra_sor_crc_wait(struct tegra_sor *sor,
> unsigned long timeout)
>
> static int tegra_sor_show_crc(struct seq_file *s, void *data)
> {
> - struct drm_info_node *node = s->private;
> - struct tegra_sor *sor = node->info_ent->data;
> + struct tegra_sor *sor = s->private;
> struct drm_crtc *crtc = sor->output.encoder.crtc;
> - struct drm_device *drm = node->minor->dev;
> + struct drm_device *drm = sor->drm;
> int err = 0;
> u32 value;
>
> @@ -1302,6 +1302,20 @@ static int tegra_sor_show_crc(struct seq_file *s, void
> *data)
> return err;
> }
>
> +static int crc_open(struct inode *inode, struct file *file)
> +{
> + struct tegra_sor *sor = inode->i_private;
> + return single_open(file, tegra_sor_show_crc, sor);
> +}
> +
> +static const struct file_operations crc_fops = {
> + .owner = THIS_MODULE,
Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Allow combo PHY A to drive a third external display
On Tue, Jun 18, 2019 at 07:08:55PM +0300, Ville Syrjälä wrote:
> On Mon, Jun 17, 2019 at 04:48:10PM -0700, Matt Roper wrote:
> > EHL has a mux on combo PHY A that allows it to be driven either by an
> > internal display (DDI-A or DSI DPHY) or by an external display (DDI-D).
> > This is a motherboard design decision that can not be changed on the
> > fly. Unfortunately there are no strap registers that allow us to detect
> > the board configuration directly, so let's use the VBT to try to figure
> > it out and program the mux accordingly.
> >
> > v2:
> > - Confirmed that VBT's dvo port refers to the DDI and not the PHY.
> >Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If
> >a bad VBT contradicts itself, let internal display win. (Ville)
> >
> > Cc: Clint Taylor
> > Cc: Ville Syrjälä
> > Signed-off-by: Matt Roper
> > ---
> > drivers/gpu/drm/i915/display/intel_bios.c | 3 ++
> > .../gpu/drm/i915/display/intel_combo_phy.c| 36 +++
> > drivers/gpu/drm/i915/i915_reg.h | 1 +
> > 3 files changed, 40 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> > b/drivers/gpu/drm/i915/display/intel_bios.c
> > index c4710889cb32..0c9808132d67 100644
> > --- a/drivers/gpu/drm/i915/display/intel_bios.c
> > +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> > @@ -1668,6 +1668,9 @@ parse_general_definitions(struct drm_i915_private
> > *dev_priv,
> > if (!child->device_type)
> > continue;
> >
> > + DRM_DEBUG_KMS("Found VBT child device with type 0x%x\n",
> > + child->device_type);
> > +
>
> Was this hunk intentional?
>
Yeah, I figured that having a little more detail on the child device
details will probably be useful for debugging any cases where the VBT
seems to contradict itself. I'll add a note about the debug message to
the commit message to make it clear it's intentional.
> > /*
> > * Copy as much as we know (sizeof) and is available
> > * (child_dev_size) of the child device. Accessing the data must
> > diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > index 841708da5a56..c18079a09a2e 100644
> > --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> > @@ -260,6 +260,32 @@ void intel_combo_phy_power_up_lanes(struct
> > drm_i915_private *dev_priv,
> > I915_WRITE(ICL_PORT_CL_DW10(port), val);
> > }
> >
> > +static u32 ehl_combo_phy_a_mux(struct drm_i915_private *i915, u32 val)
> > +{
> > + bool ddi_a_present = i915->vbt.ddi_port_info[PORT_A].child != NULL;
> > + bool ddi_d_present = i915->vbt.ddi_port_info[PORT_D].child != NULL;
> > + bool dsi_present = intel_bios_is_dsi_present(i915, NULL);
> > +
> > + /*
> > +* VBT's 'dvo port' field for child devices references the DDI, not
> > +* the PHY. So if combo PHY A is wired up to drive an external
> > +* display, we should see a child device present on PORT_D and
> > +* nothing on PORT_A and no DSI.
> > +*/
> > + if (ddi_d_present && !ddi_a_present && !dsi_present)
> > + return val | ICL_PHY_MISC_MUX_DDID;
> > +
> > + /*
> > +* If we encounter a VBT that claims to have an external display on
> > +* DDI-D _and_ an internal display on DDI-A/DSI leave an error message
> > +* in the log and let the internal display win.
> > +*/
> > + if (ddi_d_present)
> > + DRM_ERROR("VBT claims to have both internal and external
> > displays on PHY A. Configuring for internal.\n");
> > +
> > + return val & ~ICL_PHY_MISC_MUX_DDID;
> > +}
> > +
> > static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> > {
> > enum port port;
> > @@ -273,7 +299,17 @@ static void icl_combo_phys_init(struct
> > drm_i915_private *dev_priv)
> > continue;
> > }
> >
> > + /*
> > +* EHL's combo PHY A can be hooked up to either an external
> > +* display (via DDI-D) or an internal display (via DDI-A or
> > +* the DSI DPHY). This is a motherboard design decision that
> > +* can't be changed on the fly, so initialize the PHY's mux
> > +* based on whether our VBT indicates the presence of any
> > +* "internal" child devices.
> > +*/
> > val = I915_READ(ICL_PHY_MISC(port));
> > + if (!IS_ICELAKE(dev_priv) && port == PORT_A)
>
> Maybe IS_EHL instead?
That's how I was originally going to write it, but I switched it to !icl
to follow the general convention of "assume future platforms inherit all
behavior of current platform."
Matt
>
> Patch is
> Reviewed-by: Ville Syrjälä
>
> > + val = ehl_combo_phy_a_mux(dev_priv, val);
> > val &= ~ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN;
> >
Re: [Intel-gfx] [PATCH] drm/i915/blt: Remove recursive vma->lock
Hi Chris,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on drm-intel/for-linux-next]
[also build test WARNING on next-20190618]
[cannot apply to v5.2-rc5]
[if your patch is applied to the wrong git tree, please drop us a note to help
improve the system]
url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/drm-i915-blt-Remove-recursive-vma-lock/20190618-194749
base: git://anongit.freedesktop.org/drm-intel for-linux-next
reproduce:
# apt-get install sparse
# sparse version: v0.6.1-rc1-7-g2b96cd8-dirty
make ARCH=x86_64 allmodconfig
make C=1 CF='-fdiagnostic-prefix -D__CHECK_ENDIAN__'
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot
sparse warnings: (new ones prefixed by >>)
>> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c:201:65: sparse: sparse:
>> incorrect type in argument 3 (different base types) @@expected struct
>> i915_request *rq @@got uct i915_request *rq @@
>> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c:201:65: sparse:expected
>> struct i915_request *rq
>> drivers/gpu/drm/i915/gem/i915_gem_client_blt.c:201:65: sparse:got struct
>> dma_fence *
include/linux/reservation.h:220:20: sparse: sparse: dereference of noderef
expression
include/linux/reservation.h:220:45: sparse: sparse: dereference of noderef
expression
include/linux/reservation.h:220:20: sparse: sparse: dereference of noderef
expression
include/linux/reservation.h:220:45: sparse: sparse: dereference of noderef
expression
vim +201 drivers/gpu/drm/i915/gem/i915_gem_client_blt.c
153
154 static void clear_pages_worker(struct work_struct *work)
155 {
156 struct clear_pages_work *w = container_of(work, typeof(*w),
work);
157 struct drm_i915_private *i915 = w->ce->gem_context->i915;
158 struct drm_i915_gem_object *obj = w->sleeve->obj;
159 struct i915_vma *vma = w->sleeve->vma;
160 struct i915_request *rq;
161 int err = w->dma.error;
162
163 if (unlikely(err))
164 goto out_signal;
165
166 if (obj->cache_dirty) {
167 obj->write_domain = 0;
168 if (i915_gem_object_has_struct_page(obj))
169 drm_clflush_sg(w->sleeve->pages);
170 obj->cache_dirty = false;
171 }
172
173 /* XXX: we need to kill this */
174 mutex_lock(>drm.struct_mutex);
175 err = i915_vma_pin(vma, 0, 0, PIN_USER);
176 if (unlikely(err))
177 goto out_unlock;
178
179 rq = i915_request_create(w->ce);
180 if (IS_ERR(rq)) {
181 err = PTR_ERR(rq);
182 goto out_unpin;
183 }
184
185 /* There's no way the fence has signalled */
186 if (dma_fence_add_callback(>fence, >cb,
187 clear_pages_dma_fence_cb))
188 GEM_BUG_ON(1);
189
190 if (w->ce->engine->emit_init_breadcrumb) {
191 err = w->ce->engine->emit_init_breadcrumb(rq);
192 if (unlikely(err))
193 goto out_request;
194 }
195
196 /*
197 * w->dma is already exported via (vma|obj)->resv we need only
198 * keep track of the GPU activity within this vma/request, and
199 * propagate the signal from the request to w->dma.
200 */
> 201 err = i915_active_ref(>active, rq->fence.context,
> >fence);
202 if (err)
203 goto out_request;
204
205 err = intel_emit_vma_fill_blt(rq, vma, w->value);
206 out_request:
207 if (unlikely(err)) {
208 i915_request_skip(rq, err);
209 err = 0;
210 }
211
212 i915_request_add(rq);
213 out_unpin:
214 i915_vma_unpin(vma);
215 out_unlock:
216 mutex_unlock(>drm.struct_mutex);
217 out_signal:
218 if (unlikely(err)) {
219 dma_fence_set_error(>dma, err);
220 dma_fence_signal(>dma);
221 dma_fence_put(>dma);
222 }
223 }
224
---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2 19/23] drm/i915/icl: Reserve all required PLLs for TypeC ports
On Fri, Jun 07, 2019 at 08:41:29PM +0300, Imre Deak wrote:
> When enabling a TypeC port we need to reserve all the required PLLs for
> it, the TBT PLL for TBT-alt and the MG PHY PLL for DP-alt/legacy sinks.
> We can select the proper PLL for the current port mode from the reserved
> PLLs only once we selected and locked down the port mode for the whole
> duration of the port's active state. Resetting and locking down the port
> mode can in turn happen only during the modeset commit phase once we
> disabled the given port and the PLL it used.
>
> To support the above reserve-and-select PLL semantic we store the
> reserved PLLs along with their HW state in the CRTC state and provide a
> way to select the active PLL from these. The selected PLL along with its
> HW state will be pointed at by crtc_state->shared_dpll/dpll_hw_state as
> in the case of other port types.
>
> Besides reserving all required PLLs no functional changes.
>
> v2:
> - Fix releasing the ICL PLLs, not clearing the PLLs from the old
> crtc_state.
>
> Cc: Ville Syrjälä
> Cc: Daniel Vetter
> Cc: Maarten Lankhorst
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_display.c | 11 +-
> drivers/gpu/drm/i915/intel_dpll_mgr.c | 151 +++---
> drivers/gpu/drm/i915/intel_dpll_mgr.h | 9 ++
> drivers/gpu/drm/i915/intel_drv.h | 9 ++
> 4 files changed, 138 insertions(+), 42 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 7381fb2e1240..006be3c3f1bd 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9880,6 +9880,7 @@ static void icelake_get_ddi_pll(struct drm_i915_private
> *dev_priv,
> enum port port,
> struct intel_crtc_state *pipe_config)
> {
> + enum icl_port_dpll_id port_dpll_id;
> enum intel_dpll_id id;
> u32 temp;
>
> @@ -9887,22 +9888,28 @@ static void icelake_get_ddi_pll(struct
> drm_i915_private *dev_priv,
> temp = I915_READ(DPCLKA_CFGCR0_ICL) &
> DPCLKA_CFGCR0_DDI_CLK_SEL_MASK(port);
> id = temp >> DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port);
> + port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> } else if (intel_port_is_tc(dev_priv, port)) {
> u32 clk_sel = I915_READ(DDI_CLK_SEL(port)) & DDI_CLK_SEL_MASK;
>
> if (clk_sel == DDI_CLK_SEL_MG) {
> id = icl_tc_port_to_pll_id(intel_port_to_tc(dev_priv,
> port));
> + port_dpll_id = ICL_PORT_DPLL_MG_PHY;
> } else {
> WARN_ON(clk_sel < DDI_CLK_SEL_TBT_162);
> id = DPLL_ID_ICL_TBTPLL;
> + port_dpll_id = ICL_PORT_DPLL_DEFAULT;
> }
> } else {
> WARN(1, "Invalid port %x\n", port);
> return;
> }
>
> - pipe_config->shared_dpll = intel_get_shared_dpll_by_id(dev_priv, id);
> + pipe_config->icl_port_dplls[port_dpll_id].pll =
> + intel_get_shared_dpll_by_id(dev_priv, id);
> +
> + icl_set_active_port_dpll(pipe_config, port_dpll_id);
> }
>
> static void bxt_get_ddi_pll(struct drm_i915_private *dev_priv,
> @@ -12041,6 +12048,8 @@ clear_intel_crtc_state(struct intel_crtc_state
> *crtc_state)
> saved_state->scaler_state = crtc_state->scaler_state;
> saved_state->shared_dpll = crtc_state->shared_dpll;
> saved_state->dpll_hw_state = crtc_state->dpll_hw_state;
> + memcpy(saved_state->icl_port_dplls, crtc_state->icl_port_dplls,
> +sizeof(saved_state->icl_port_dplls));
> saved_state->crc_enabled = crtc_state->crc_enabled;
> if (IS_G4X(dev_priv) ||
> IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> diff --git a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> index 8ac293db43a5..17441d5f990e 100644
> --- a/drivers/gpu/drm/i915/intel_dpll_mgr.c
> +++ b/drivers/gpu/drm/i915/intel_dpll_mgr.c
> @@ -2856,34 +2856,79 @@ static bool icl_calc_mg_pll_state(struct
> intel_crtc_state *crtc_state,
> return true;
> }
>
> +/**
> + * icl_set_active_port_dpll - select the active port DPLL for a given CRTC
> + * @crtc_state: state for the CRTC to select the DPLL for
> + * @port_dpll_id: the active @port_dpll_id to select
> + *
> + * Select the given @port_dpll_id instance from the DPLLs reserved for the
> + * CRTC.
> + */
> +void icl_set_active_port_dpll(struct intel_crtc_state *crtc_state,
> + enum icl_port_dpll_id port_dpll_id)
> +{
> + struct icl_port_dpll *port_dpll =
> + _state->icl_port_dplls[port_dpll_id];
> +
> + crtc_state->shared_dpll = port_dpll->pll;
> + crtc_state->dpll_hw_state = port_dpll->hw_state;
> +}
> +
> +static void icl_update_active_dpll(struct intel_atomic_state
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't dereference request if it may have been retired
On 18/06/2019 17:19, Chris Wilson wrote:
This has count me out on countless occasions, when we retrieve a pointer
from the submission/execlists backend, it does not carry a reference to
the context or ring. Those are only pinned while the rquest is active,
so if we see the request is completed, it may be in the process of being
retired and those pointers defunct.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110938
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 898692989313..7fd33e81c2d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1311,12 +1311,13 @@ static void hexdump(struct drm_printer *m, const void
*buf, size_t len)
}
}
-static void intel_engine_print_registers(const struct intel_engine_cs *engine,
+static void intel_engine_print_registers(struct intel_engine_cs *engine,
struct drm_printer *m)
{
struct drm_i915_private *dev_priv = engine->i915;
const struct intel_engine_execlists * const execlists =
>execlists;
+ unsigned long flags;
u64 addr;
if (engine->id == RCS0 && IS_GEN_RANGE(dev_priv, 4, 7))
@@ -1397,15 +1398,16 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
idx, hws[idx * 2], hws[idx * 2 + 1]);
}
- rcu_read_lock();
+ spin_lock_irqsave(>active.lock, flags);
for (idx = 0; idx < execlists_num_ports(execlists); idx++) {
struct i915_request *rq;
unsigned int count;
+ char hdr[80];
rq = port_unpack(>port[idx], );
- if (rq) {
- char hdr[80];
-
+ if (!rq) {
+ drm_printf(m, "\t\tELSP[%d] idle\n", idx);
+ } else if (!i915_request_signaled(rq)) {
snprintf(hdr, sizeof(hdr),
"\t\tELSP[%d] count=%d, ring:{start:%08x,
hwsp:%08x, seqno:%08x}, rq: ",
idx, count,
@@ -1414,11 +1416,11 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
hwsp_seqno(rq));
print_request(m, rq, hdr);
} else {
- drm_printf(m, "\t\tELSP[%d] idle\n", idx);
+ print_request(m, rq, "\t\tELSP[%d] rq: ");
}
}
drm_printf(m, "\t\tHW active? 0x%x\n", execlists->active);
- rcu_read_unlock();
+ spin_unlock_irqrestore(>active.lock, flags);
} else if (INTEL_GEN(dev_priv) > 6) {
drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
ENGINE_READ(engine, RING_PP_DIR_BASE));
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
== Series Details == Series: series starting with [1/3] drm/i915/gtt: pde entry encoding is identical URL : https://patchwork.freedesktop.org/series/62324/ State : success == Summary == CI Bug Log - changes from CI_DRM_6294 -> Patchwork_13331 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/ Known issues Here are the changes found in Patchwork_13331 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_basic@basic-all: - fi-icl-guc: [PASS][1] -> [INCOMPLETE][2] ([fdo#107713]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-icl-guc/igt@gem_exec_ba...@basic-all.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-icl-guc/igt@gem_exec_ba...@basic-all.html * igt@i915_module_load@reload-no-display: - fi-icl-u3: [PASS][3] -> [DMESG-WARN][4] ([fdo#107724]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-icl-u3/igt@i915_module_l...@reload-no-display.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-icl-u3/igt@i915_module_l...@reload-no-display.html * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][5] -> [DMESG-WARN][6] ([fdo#107709]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-bsw-kefka/igt@i915_selftest@live_evict.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-bsw-kefka/igt@i915_selftest@live_evict.html * igt@kms_chamelium@dp-edid-read: - fi-kbl-7500u: [PASS][7] -> [FAIL][8] ([fdo#106766]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-kbl-7500u/igt@kms_chamel...@dp-edid-read.html * igt@kms_frontbuffer_tracking@basic: - fi-icl-dsi: [PASS][9] -> [FAIL][10] ([fdo#103167]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-icl-dsi/igt@kms_frontbuffer_track...@basic.html Possible fixes * igt@gem_pread@basic: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-icl-u3/igt@gem_pr...@basic.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-icl-u3/igt@gem_pr...@basic.html * igt@i915_module_load@reload: - fi-icl-dsi: [INCOMPLETE][13] ([fdo#107713]) -> [PASS][14] [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-icl-dsi/igt@i915_module_l...@reload.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-icl-dsi/igt@i915_module_l...@reload.html * igt@kms_pipe_crc_basic@suspend-read-crc-pipe-a: - fi-blb-e6850: [INCOMPLETE][15] ([fdo#107718]) -> [PASS][16] [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6294/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/fi-blb-e6850/igt@kms_pipe_crc_ba...@suspend-read-crc-pipe-a.html [fdo#103167]: https://bugs.freedesktop.org/show_bug.cgi?id=103167 [fdo#106766]: https://bugs.freedesktop.org/show_bug.cgi?id=106766 [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 Participating hosts (44 -> 37) -- Missing(7): fi-kbl-soraka fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-icl-y fi-bdw-samus Build changes - * Linux: CI_DRM_6294 -> Patchwork_13331 CI_DRM_6294: 6ddceb4b9fe7a9f74bf090bd0d788c5f2fec2915 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13331: 3fc849b75c9d69c762c54dc620423bc9804631a3 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == 3fc849b75c9d drm/i915/gtt: Setup phys pages for 3lvl pdps 4f46c24d9757 drm/i915/gtt: Tear down setup and cleanup macros for page dma 224a6de52ba2 drm/i915/gtt: pde entry encoding is identical == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13331/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: Flush live_evict
On 18/06/2019 17:19, Chris Wilson wrote:
Be sure to cleanup after live_evict by flushing any residual state off
the GPU using igt_flush_test.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 8c69198c7e4e..a3cb0aade6f1 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -28,6 +28,7 @@
#include "i915_selftest.h"
+#include "igt_flush_test.h"
#include "lib_sw_fence.h"
#include "mock_drm.h"
#include "mock_gem_device.h"
@@ -505,6 +506,8 @@ static int igt_evict_contexts(void *arg)
mutex_lock(>drm.struct_mutex);
out_locked:
+ if (igt_flush_test(i915, I915_WAIT_LOCKED))
+ err = -EIO;
while (reserved) {
struct reserved *next = reserved->next;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/rcar-du: Fix error check when retrieving crtc state
On Tue, Jun 18, 2019 at 10:26:52AM +0300, Laurent Pinchart wrote:
> Hi Sean,
>
> Thank you for the patch.
>
> On Mon, Jun 17, 2019 at 02:15:42PM -0400, Sean Paul wrote:
> > From: Sean Paul
> >
> > drm_atomic_get_crtc_state() returns an error pointer when it fails, so
> > the null check is doing nothing here.
> >
> > Credit to 0-day/Dan Carpenter for reporting this.
> >
> > Fixes: 6f3b62781bbd ("drm: Convert connector_helper_funcs->atomic_check to
> > accept drm_atomic_state")
> > Cc: Daniel Vetter
> > Cc: Ville Syrjälä
> > Cc: Jani Nikula
> > Cc: Joonas Lahtinen
> > Cc: Rodrigo Vivi
> > Cc: Ben Skeggs
> > Cc: Laurent Pinchart
> > Cc: Kieran Bingham
> > Cc: Eric Anholt
> > Cc: Laurent Pinchart [for rcar lvds]
> > Cc: Sean Paul
> > Cc: Maarten Lankhorst
> > Cc: Maxime Ripard
> > Cc: Sean Paul
> > Cc: David Airlie
> > Cc: Lyude Paul
> > Cc: Karol Herbst
> > Cc: Ilia Mirkin
> > Cc: dri-de...@lists.freedesktop.org
> > Cc: intel-gfx@lists.freedesktop.org
> > Cc: linux-renesas-...@vger.kernel.org
> > Reported-by: kbuild test robot
> > Reported-by: Dan Carpenter
> > Signed-off-by: Sean Paul
>
> Reviewed-by: Laurent Pinchart
>
> I have no pending conflicting changes for rcar_lvds.c. Do you plan to
> merge this through drm-misc ?
Thanks for your review!
Yeah, since the bug is only in drm-misc-next, this will also go there. Speaking
of which, I just applied it :-)
Sean
>
> > ---
> > drivers/gpu/drm/rcar-du/rcar_lvds.c | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > index f2a5d4d997073..1c62578590f46 100644
> > --- a/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > +++ b/drivers/gpu/drm/rcar-du/rcar_lvds.c
> > @@ -115,8 +115,8 @@ static int rcar_lvds_connector_atomic_check(struct
> > drm_connector *connector,
> >
> > /* We're not allowed to modify the resolution. */
> > crtc_state = drm_atomic_get_crtc_state(state, conn_state->crtc);
> > - if (!crtc_state)
> > - return -EINVAL;
> > + if (IS_ERR(crtc_state))
> > + return PTR_ERR(crtc_state);
> >
> > if (crtc_state->mode.hdisplay != panel_mode->hdisplay ||
> > crtc_state->mode.vdisplay != panel_mode->vdisplay)
>
> --
> Regards,
>
> Laurent Pinchart
--
Sean Paul, Software Engineer, Google / Chromium OS
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 15/23] drm/i915: Sanitize the TypeC FIA lane configuration decoding
On Tue, Jun 18, 2019 at 07:39:09PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 04, 2019 at 05:58:18PM +0300, Imre Deak wrote:
> > Use hex numbers, since that makes more sense when decoding a bit pattern.
> >
> > No functional change.
> >
> > Suggested-by: Ville Syrjälä
> > Cc: Animesh Manna
> > Cc: Ville Syrjälä
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_tc.c | 15 ---
> > 1 file changed, 8 insertions(+), 7 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_tc.c
> > b/drivers/gpu/drm/i915/intel_tc.c
> > index fc0341dc50c5..4b2f525bc2a6 100644
> > --- a/drivers/gpu/drm/i915/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/intel_tc.c
> > @@ -72,15 +72,16 @@ int intel_tc_port_fia_max_lane_count(struct
> > intel_digital_port *dig_port)
> > switch (lane_info) {
> > default:
> > MISSING_CASE(lane_info);
> > - case 1:
> > - case 2:
> > - case 4:
> > - case 8:
> > + /* fall-through */
> > + case 0x1:
> > + case 0x2:
> > + case 0x4:
> > + case 0x8:
> > return 1;
> > - case 3:
> > - case 12:
> > + case 0x3:
> > + case 0xc:
> > return 2;
> > - case 15:
> > + case 0xf:
> > return 4;
> > }
>
> Still looks like a hand rolled hweight() to me ;)
Thought about that, but then we'd miss undefined encodings.
>
> > }
> > --
> > 2.17.1
>
> --
> Ville Syrjälä
> Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/23] drm/i915: Factor out common parts from TypeC port handling functions
On Tue, Jun 18, 2019 at 07:33:13PM +0300, Ville Syrjälä wrote:
> On Tue, Jun 04, 2019 at 05:58:12PM +0300, Imre Deak wrote:
> > Factor out helpers reading/parsing the TypeC specific registers, making
> > current users of them clearer and letting us use them later.
> >
> > While at it also:
> > - Simplify icl_tc_phy_connect() with an early return in legacy mode.
> > - Simplify the live status check using one bitmask for all HPD bits.
> > - Remove a micro-optimisation of the repeated safe-mode clearing.
> > - Make sure we fix the legacy port flag in all cases.
> >
> > Except for the last two, no functional changes.
> >
> > Cc: José Roberto de Souza
> > Cc: Rodrigo Vivi
> > Cc: Paulo Zanoni
> > Signed-off-by: Imre Deak
> > ---
> > drivers/gpu/drm/i915/intel_ddi.c | 5 +-
> > drivers/gpu/drm/i915/intel_tc.c | 166 +++
> > drivers/gpu/drm/i915/intel_tc.h | 1 +
> > 3 files changed, 103 insertions(+), 69 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 8f223d48d562..d236839bee19 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -2983,7 +2983,6 @@ static void icl_program_mg_dp_mode(struct
> > intel_digital_port *intel_dig_port)
> > {
> > struct drm_i915_private *dev_priv =
> > to_i915(intel_dig_port->base.base.dev);
> > enum port port = intel_dig_port->base.port;
> > - enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> > u32 ln0, ln1, lane_info;
> >
> > if (intel_dig_port->tc_mode == TC_PORT_TBT_ALT)
> > @@ -2997,9 +2996,7 @@ static void icl_program_mg_dp_mode(struct
> > intel_digital_port *intel_dig_port)
> > ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> > ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> >
> > - lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
> > -DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> > - DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> > + lane_info = intel_tc_port_get_lane_info(intel_dig_port);
> >
> > switch (lane_info) {
> > case 0x1:
> > diff --git a/drivers/gpu/drm/i915/intel_tc.c
> > b/drivers/gpu/drm/i915/intel_tc.c
> > index 07488235b67a..3fdcfa2bbaee 100644
> > --- a/drivers/gpu/drm/i915/intel_tc.c
> > +++ b/drivers/gpu/drm/i915/intel_tc.c
> > @@ -43,10 +43,19 @@ static const char *tc_port_mode_name(enum tc_port_mode
> > mode)
> > return names[mode];
> > }
> >
> > -int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> > +u32 intel_tc_port_get_lane_info(struct intel_digital_port *dig_port)
>
> get_lane_mask() or something?
Ok.
>
> > {
> > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> > + u32 lane_info = I915_READ(PORT_TX_DFLEXDPSP);
> > +
> > + return (lane_info & DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> > + DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> > +}
> > +
> > +int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > intel_wakeref_t wakeref;
> > u32 lane_info;
> >
> > @@ -55,9 +64,7 @@ int intel_tc_port_fia_max_lane_count(struct
> > intel_digital_port *dig_port)
> >
> > lane_info = 0;
> > with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> > - lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
> > -DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> > - DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> > + lane_info = intel_tc_port_get_lane_info(dig_port);
> >
> > switch (lane_info) {
> > default:
> > @@ -75,6 +82,69 @@ int intel_tc_port_fia_max_lane_count(struct
> > intel_digital_port *dig_port)
> > }
> > }
> >
> > +static void tc_port_fixup_legacy_flag(struct intel_digital_port *dig_port,
> > + u32 live_status_mask)
> > +{
> > + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> > + enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> > + u32 valid_hpd_mask = dig_port->tc_legacy_port ? BIT(TC_PORT_LEGACY) :
> > + ~BIT(TC_PORT_LEGACY);
> > +
> > + if (!(live_status_mask & ~valid_hpd_mask))
> > + return;
>
> A bit too many nots for me to follow. I guess what it's doing is
> checking if any of the other bits are set, and if so it assumes the
> mode was misdeclared in vbt?
Yes.
>
> Actually, won't this end up ping-ponging back and forth if the
> hw really reports both legacy and non-legacy bits as set?
If you mean multiple HPD bits being set by HW, we won't call this
function to fix up the flag.
>
> > +
> > + /* If live status mismatches the VBT flag, trust
Re: [Intel-gfx] [PATCH 15/23] drm/i915: Sanitize the TypeC FIA lane configuration decoding
On Tue, Jun 04, 2019 at 05:58:18PM +0300, Imre Deak wrote:
> Use hex numbers, since that makes more sense when decoding a bit pattern.
>
> No functional change.
>
> Suggested-by: Ville Syrjälä
> Cc: Animesh Manna
> Cc: Ville Syrjälä
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_tc.c | 15 ---
> 1 file changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_tc.c b/drivers/gpu/drm/i915/intel_tc.c
> index fc0341dc50c5..4b2f525bc2a6 100644
> --- a/drivers/gpu/drm/i915/intel_tc.c
> +++ b/drivers/gpu/drm/i915/intel_tc.c
> @@ -72,15 +72,16 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
> switch (lane_info) {
> default:
> MISSING_CASE(lane_info);
> - case 1:
> - case 2:
> - case 4:
> - case 8:
> + /* fall-through */
> + case 0x1:
> + case 0x2:
> + case 0x4:
> + case 0x8:
> return 1;
> - case 3:
> - case 12:
> + case 0x3:
> + case 0xc:
> return 2;
> - case 15:
> + case 0xf:
> return 4;
> }
Still looks like a hand rolled hweight() to me ;)
> }
> --
> 2.17.1
--
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.SPARSE: warning for series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
== Series Details == Series: series starting with [1/3] drm/i915/gtt: pde entry encoding is identical URL : https://patchwork.freedesktop.org/series/62324/ State : warning == Summary == $ dim sparse origin/drm-tip Sparse version: v0.5.2 Commit: drm/i915/gtt: pde entry encoding is identical -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1555:9: warning: expression using sizeof(void) -O:drivers/gpu/drm/i915/i915_gem_gtt.c:1555:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1521:9: warning: expression using sizeof(void) +drivers/gpu/drm/i915/i915_gem_gtt.c:1521:9: warning: expression using sizeof(void) Commit: drm/i915/gtt: Tear down setup and cleanup macros for page dma Okay! Commit: drm/i915/gtt: Setup phys pages for 3lvl pdps Okay! ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915/gtt: Setup phys pages for 3lvl pdps
Quoting Mika Kuoppala (2019-06-18 17:17:31)
> If we setup backing phys page for 3lvl pdps, even they
even though they
> are not used, we lose 5 pages per ppgtt.
>
> Trading this memory on bsw, we gain more common code paths for all
> gen8+ directory manipulation. And those paths are now void of checks
> for page directory type, making the hot paths faster.
>
> Signed-off-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gem_gtt.c | 106 +---
> 1 file changed, 66 insertions(+), 40 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
> b/drivers/gpu/drm/i915/i915_gem_gtt.c
> index b521b1ddd19b..ea78302c6348 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.c
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
> @@ -715,22 +715,14 @@ static struct i915_page_directory *alloc_pd(struct
> i915_address_space *vm)
> return pd;
> }
>
> -static inline bool pd_has_phys_page(const struct i915_page_directory * const
> pd)
> -{
> - return pd->base.page;
> -}
> -
> static void free_pd(struct i915_address_space *vm,
> struct i915_page_directory *pd)
> {
> - if (likely(pd_has_phys_page(pd)))
> - cleanup_page_dma(vm, >base);
> -
> + cleanup_page_dma(vm, >base);
> kfree(pd);
> }
>
> #define init_pd(vm, pd, to) { \
> - GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
> fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
> memset_p((pd)->entry, (to), 512); \
> }
> @@ -1539,6 +1531,50 @@ static void ppgtt_init(struct drm_i915_private *i915,
> ppgtt->vm.vma_ops.clear_pages = clear_pages;
> }
>
> +static void init_pd_n(struct i915_address_space *vm,
> + struct i915_page_directory *pd,
> + struct i915_page_directory *to,
> + const unsigned int entries)
> +{
> + const u64 daddr = gen8_pde_encode(px_dma(to), I915_CACHE_LLC);
> + u64 * const vaddr = kmap_atomic(pd->base.page);
> +
> + memset64(vaddr, daddr, entries);
> + kunmap_atomic(vaddr);
> +
> + memset_p(pd->entry, to, entries);
> +}
> +
> +static struct i915_page_directory *
> +gen8_alloc_top_pd(struct i915_address_space *vm)
> +{
> + struct i915_page_directory *pd;
> +
> + if (i915_vm_is_4lvl(vm)) {
> + pd = alloc_pd(vm);
> + if (!IS_ERR(pd))
> + init_pd(vm, pd, vm->scratch_pdp);
> +
> + return pd;
> + }
> +
> + /* 3lvl */
> + pd = __alloc_pd();
> + if (!pd)
> + return ERR_PTR(-ENOMEM);
> +
> + pd->entry[GEN8_3LVL_PDPES] = NULL;
> +
> + if (unlikely(setup_page_dma(vm, >base))) {
> + kfree(pd);
> + return ERR_PTR(-ENOMEM);
> + }
> +
> + init_pd_n(vm, pd, vm->scratch_pd, GEN8_3LVL_PDPES);
> +
> + return pd;
> +}
> +
> /*
> * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP
> registers
> * with a net effect resembling a 2-level page table in normal x86 terms.
> Each
> @@ -1548,6 +1584,7 @@ static void ppgtt_init(struct drm_i915_private *i915,
> */
> static struct i915_ppgtt *gen8_ppgtt_create(struct drm_i915_private *i915)
> {
> + struct i915_address_space *vm;
> struct i915_ppgtt *ppgtt;
> int err;
>
> @@ -1557,70 +1594,59 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct
> drm_i915_private *i915)
>
> ppgtt_init(i915, ppgtt);
>
> + vm = >vm;
Been having this debate with Tursulin, whether or not it is more
confusing to have a local alias here. I think on reading it, it is much
clearer that we are setting up one object if we use ppgtt->vm.foo than
it is to alternate between ppgtt->foo and vm->bar.
I'd suggest leaving it as ppgtt->vm.foo in this patch.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
== Series Details ==
Series: series starting with [1/3] drm/i915/gtt: pde entry encoding is identical
URL : https://patchwork.freedesktop.org/series/62324/
State : warning
== Summary ==
$ dim checkpatch origin/drm-tip
224a6de52ba2 drm/i915/gtt: pde entry encoding is identical
-:55: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'pd' - possible side-effects?
#55: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:734:
+#define init_pd(vm, pd, to) { \
+ GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
+ fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
+ memset_p((pd)->entry, (to), 512); \
}
-:55: CHECK:MACRO_ARG_REUSE: Macro argument reuse 'to' - possible side-effects?
#55: FILE: drivers/gpu/drm/i915/i915_gem_gtt.c:734:
+#define init_pd(vm, pd, to) { \
+ GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
+ fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
+ memset_p((pd)->entry, (to), 512); \
}
total: 0 errors, 0 warnings, 2 checks, 235 lines checked
4f46c24d9757 drm/i915/gtt: Tear down setup and cleanup macros for page dma
3fc849b75c9d drm/i915/gtt: Setup phys pages for 3lvl pdps
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On 18/06/2019 16:19, Greg Kroah-Hartman wrote: > On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote: >> Greg is busy already, but maybe he won't do everything ... >> >> Cc: Greg Kroah-Hartman >> Signed-off-by: Daniel Vetter >> --- >> Documentation/gpu/todo.rst | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst >> index 9717540ee28f..026e55c517e1 100644 >> --- a/Documentation/gpu/todo.rst >> +++ b/Documentation/gpu/todo.rst >> @@ -375,6 +375,9 @@ There's a bunch of issues with it: >>this (together with the drm_minor->drm_device move) would allow us to >> remove >>debugfs_init. >> >> +- Drop the return code and error checking from all debugfs functions. Greg >> KH is >> + working on this already. > > > Part of this work was to try to delete drm_debugfs_remove_files(). > > There are only 4 files that currently still call this function: > drivers/gpu/drm/tegra/dc.c > drivers/gpu/drm/tegra/dsi.c > drivers/gpu/drm/tegra/hdmi.c > drivers/gpu/drm/tegra/sor.c > > For dc.c, the driver wants to add debugfs files to the struct drm_crtc > debugfs directory. Which is fine, but it has to do some special memory > allocation to get the debugfs callback to point not to the struct > drm_minor pointer, but rather the drm_crtc structure. > > So, to remove this call, I need to remove this special memory allocation > and to do that, I need to somehow be able to cast from drm_minor back to > the drm_crtc structure being used in this driver. And I can't figure > how they are related at all. > > Any pointers here (pun intended) would be appreciated. > > For the other 3 files, the situation is much the same, but I need to get > from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer. > > I could just "open code" a bunch of calls to debugfs_create_file() for > these drivers, which would solve this issue, but in a more "non-drm" > way. Is it worth to just do that instead of overthinking the whole > thing and trying to squish it into the drm "model" of drm debugfs calls? > > Either way, who can test these changes? I can't even build the tegra > driver without digging up an arm64 cross-compiler, and can't test it as > I have no hardware at all. We can definitely compile and boot test these no problem. In fact anything that lands in -next we will boot test. However, I can do some quick sanity if you have something to test. Thierry may have more specific Tegra DRM tests. Cheers Jon -- nvpublic ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] i915: intel_dp_aux_backlight: Fix max backlight calculations
Max backlight value for the panel was being calculated using byte
count i.e. 0x if 2 bytes are supported for backlight brightness
and 0xff if 1 byte is supported. However, EDP_PWMGEN_BIT_COUNT
determines the number of active control bits used for the brightness
setting. Thus, even if the panel uses 2 byte setting, it might not use
all the control bits. Thus, max backlight should be set based on the
value of EDP_PWMGEN_BIT_COUNT instead of assuming 65535 or 255.
Additionally, EDP_PWMGEN_BIT_COUNT was being updated based on the VBT
frequency which results in a different max backlight value. Thus,
setting of EDP_PWMGEN_BIT_COUNT is moved to setup phase instead of
enable so that max backlight can be calculated correctly. Only the
frequency divider is set during the enable phase using the value of
EDP_PWMGEN_BIT_COUNT.
Signed-off-by: Furquan Shaikh
Reviewed-by: Stéphane Marchesin
---
drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 132 --
1 file changed, 88 insertions(+), 44 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 357136f17f85..4636c8e8ae8a 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -110,61 +110,34 @@ static bool intel_dp_aux_set_pwm_freq(struct
intel_connector *connector)
{
struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
- int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
- u8 pn, pn_min, pn_max;
+ int freq, fxp, f, fxp_actual, fxp_min, fxp_max;
+ u8 pn;
- /* Find desired value of (F x P)
-* Note that, if F x P is out of supported range, the maximum value or
-* minimum value will applied automatically. So no need to check that.
-*/
freq = dev_priv->vbt.backlight.pwm_freq_hz;
- DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
if (!freq) {
DRM_DEBUG_KMS("Use panel default backlight frequency\n");
return false;
}
- fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
-
- /* Use highest possible value of Pn for more granularity of brightness
-* adjustment while satifying the conditions below.
-* - Pn is in the range of Pn_min and Pn_max
-* - F is in the range of 1 and 255
-* - FxP is within 25% of desired value.
-* Note: 25% is arbitrary value and may need some tweak.
-*/
- if (drm_dp_dpcd_readb(_dp->aux,
- DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, _min) != 1) {
- DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+ if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_PWMGEN_BIT_COUNT,
+ ) < 0) {
+ DRM_DEBUG_KMS("Failed to read aux pwmgen bit count\n");
return false;
}
- if (drm_dp_dpcd_readb(_dp->aux,
- DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, _max) != 1) {
- DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
- return false;
- }
- pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
- pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+ fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
+ f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
+ fxp_actual = f << pn;
+
+ /* Ensure frequency is within 25% of desired value */
fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
- if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
- DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
- return false;
- }
- for (pn = pn_max; pn >= pn_min; pn--) {
- f = clamp(DIV_ROUND_CLOSEST(fxp, 1 << pn), 1, 255);
- fxp_actual = f << pn;
- if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
- break;
- }
-
- if (drm_dp_dpcd_writeb(_dp->aux,
- DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
- DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+ if (fxp_min > fxp_actual || fxp_actual > fxp_max) {
+ DRM_DEBUG_KMS("Actual frequency out of range\n");
return false;
}
+
if (drm_dp_dpcd_writeb(_dp->aux,
DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
@@ -224,16 +197,87 @@ static void intel_dp_aux_disable_backlight(const struct
drm_connector_state *old
set_aux_backlight_enable(enc_to_intel_dp(old_conn_state->best_encoder),
false);
}
+static u32 intel_dp_aux_calc_max_backlight(struct intel_connector *connector)
+{
+ struct drm_i915_private *dev_priv =
Re: [Intel-gfx] [PATCH 12/16] staging/comedi: mark as broken
On 14/06/2019 16:34, Christoph Hellwig wrote: On Fri, Jun 14, 2019 at 05:30:32PM +0200, Greg KH wrote: On Fri, Jun 14, 2019 at 04:48:57PM +0200, Christoph Hellwig wrote: On Fri, Jun 14, 2019 at 04:02:39PM +0200, Greg KH wrote: Perhaps a hint as to how we can fix this up? This is the first time I've heard of the comedi code not handling dma properly. It can be fixed by: a) never calling virt_to_page (or vmalloc_to_page for that matter) on dma allocation b) never remapping dma allocation with conflicting cache modes (no remapping should be doable after a) anyway). Ok, fair enough, have any pointers of drivers/core code that does this correctly? I can put it on my todo list, but might take a week or so... Just about everyone else. They just need to remove the vmap and either do one large allocation, or live with the fact that they need helpers to access multiple array elements instead of one net vmap, which most of the users already seem to do anyway, with just a few using the vmap (which might explain why we didn't see blowups yet). Avoiding the vmap in comedi should be do-able as it already has other means to get at the buffer pages. When comedi makes the buffer from DMA coherent memory, it currently allocates it as a series of page-sized chunks. That cannot be mmap'ed in one go with dma_mmap_coherent(), so I see the following solutions. 1. Change the buffer allocation to allocate a single chunk of DMA coherent memory and use dma_mmap_coherent() to mmap it. 2. Call dma_mmap_coherent() in a loop, adjusting vma->vm_start and vma->vm_end for each iteration (vma->vm_pgoff will be 0), and restoring the vma->vm_start and vma->vm_end at the end. I'm not sure if 2 is a legal option. -- -=( Ian Abbott || Web: www.mev.co.uk )=- -=( MEV Ltd. is a company registered in England & Wales. )=- -=( Registered number: 02862268. Registered address:)=- -=( 15 West Park Road, Bramhall, STOCKPORT, SK7 3JZ, UK. )=- ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] docs: fix some broken references due to txt->rst renames
There are three left-overs from the recent file renames,
probably due to some other conflicting patch.
Fix them.
Signed-off-by: Mauro Carvalho Chehab
---
This patch is against today's next-20190617 branch. Not sure if it
will apply cleanly at -docs tree. If not, Please let me know for me to
split.
Documentation/devicetree/bindings/arm/idle-states.txt | 2 +-
drivers/gpu/drm/i915/intel_runtime_pm.h | 2 +-
drivers/i2c/busses/i2c-nvidia-gpu.c | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/devicetree/bindings/arm/idle-states.txt
b/Documentation/devicetree/bindings/arm/idle-states.txt
index 3bdbe675b9e6..d8d9aa7167e8 100644
--- a/Documentation/devicetree/bindings/arm/idle-states.txt
+++ b/Documentation/devicetree/bindings/arm/idle-states.txt
@@ -703,4 +703,4 @@ cpus {
https://www.devicetree.org/specifications/
[6] ARM Linux Kernel documentation - Booting AArch64 Linux
-Documentation/arm64/booting.txt
+Documentation/arm64/booting.rst
diff --git a/drivers/gpu/drm/i915/intel_runtime_pm.h
b/drivers/gpu/drm/i915/intel_runtime_pm.h
index f2d6299a8161..3cb391cd81c1 100644
--- a/drivers/gpu/drm/i915/intel_runtime_pm.h
+++ b/drivers/gpu/drm/i915/intel_runtime_pm.h
@@ -44,7 +44,7 @@ enum i915_drm_suspend_mode {
* to be disabled. This shouldn't happen and we'll print some error messages in
* case it happens.
*
- * For more, read the Documentation/power/runtime_pm.txt.
+ * For more, read the Documentation/power/runtime_pm.rst.
*/
struct intel_runtime_pm {
atomic_t wakeref_count;
diff --git a/drivers/i2c/busses/i2c-nvidia-gpu.c
b/drivers/i2c/busses/i2c-nvidia-gpu.c
index cfc76b5de726..5a1235fd86bb 100644
--- a/drivers/i2c/busses/i2c-nvidia-gpu.c
+++ b/drivers/i2c/busses/i2c-nvidia-gpu.c
@@ -364,7 +364,7 @@ static void gpu_i2c_remove(struct pci_dev *pdev)
/*
* We need gpu_i2c_suspend() even if it is stub, for runtime pm to work
* correctly. Without it, lspci shows runtime pm status as "D0" for the card.
- * Documentation/power/pci.txt also insists for driver to provide this.
+ * Documentation/power/pci.rst also insists for driver to provide this.
*/
static __maybe_unused int gpu_i2c_suspend(struct device *dev)
{
--
2.21.0
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 2/7] lib/hexdump.c: Relax rowsize checks in hex_dump_to_buffer
On Mon, 2019-06-17 at 15:47 -0700, Randy Dunlap wrote:
> Hi,
> Just a comment style nit below...
>
> On 6/16/19 7:04 PM, Alastair D'Silva wrote:
> > From: Alastair D'Silva
> >
> > This patch removes the hardcoded row limits and allows for
> > other lengths. These lengths must still be a multiple of
> > groupsize.
> >
> > This allows structs that are not 16/32 bytes to display on
> > a single line.
> >
> > This patch also expands the self-tests to test row sizes
> > up to 64 bytes (though they can now be arbitrarily long).
> >
> > Signed-off-by: Alastair D'Silva
> > ---
> > lib/hexdump.c | 48 --
> > lib/test_hexdump.c | 52 ++--
> > --
> > 2 files changed, 75 insertions(+), 25 deletions(-)
> >
> > diff --git a/lib/hexdump.c b/lib/hexdump.c
> > index 81b70ed37209..3943507bc0e9 100644
> > --- a/lib/hexdump.c
> > +++ b/lib/hexdump.c
> > @@ -246,17 +248,29 @@ void print_hex_dump(const char *level, const
> > char *prefix_str, int prefix_type,
> > {
> > const u8 *ptr = buf;
> > int i, linelen, remaining = len;
> > - unsigned char linebuf[32 * 3 + 2 + 32 + 1];
> > + unsigned char *linebuf;
> > + unsigned int linebuf_len;
> >
> > - if (rowsize != 16 && rowsize != 32)
> > - rowsize = 16;
> > + if (rowsize % groupsize)
> > + rowsize -= rowsize % groupsize;
> > +
> > + /* Worst case line length:
> > +* 2 hex chars + space per byte in, 2 spaces, 1 char per byte
> > in, NULL
> > +*/
>
> According to Documentation/process/coding-style.rst:
>
> The preferred style for long (multi-line) comments is:
>
> .. code-block:: c
>
> /*
>* This is the preferred style for multi-line
>* comments in the Linux kernel source code.
>* Please use it consistently.
>*
>* Description: A column of asterisks on the left side,
>* with beginning and ending almost-blank lines.
>*/
>
Thanks Randy, I'll address this.
--
Alastair D'Silva mob: 0423 762 819
skype: alastair_dsilva
Twitter: @EvilDeece
blog: http://alastair.d-silva.org
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Update whitelist support for new hardware (rev2)
On 18/06/2019 02:50, Patchwork wrote: == Series Details == Series: Update whitelist support for new hardware (rev2) URL : https://patchwork.freedesktop.org/series/62076/ State : success == Summary == CI Bug Log - changes from CI_DRM_6289 -> Patchwork_13319 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/ Known issues Here are the changes found in Patchwork_13319 that come from known issues: ### IGT changes ### Issues hit * igt@gem_exec_suspend@basic-s4-devices: - fi-blb-e6850: [PASS][1] -> [INCOMPLETE][2] ([fdo#107718]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/fi-blb-e6850/igt@gem_exec_susp...@basic-s4-devices.html Possible fixes * igt@gem_ctx_create@basic-files: - fi-icl-y: [INCOMPLETE][3] ([fdo#107713] / [fdo#109100]) -> [PASS][4] [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/fi-icl-y/igt@gem_ctx_cre...@basic-files.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/fi-icl-y/igt@gem_ctx_cre...@basic-files.html * igt@gem_exec_create@basic: - fi-icl-u2: [INCOMPLETE][5] ([fdo#107713]) -> [PASS][6] [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/fi-icl-u2/igt@gem_exec_cre...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/fi-icl-u2/igt@gem_exec_cre...@basic.html * igt@kms_chamelium@hdmi-hpd-fast: - fi-kbl-7500u: [FAIL][7] ([fdo#109485]) -> [PASS][8] [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/fi-kbl-7500u/igt@kms_chamel...@hdmi-hpd-fast.html * igt@kms_frontbuffer_tracking@basic: - fi-hsw-peppy: [DMESG-WARN][9] ([fdo#102614]) -> [PASS][10] [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/fi-hsw-peppy/igt@kms_frontbuffer_track...@basic.html * igt@prime_vgem@basic-fence-flip: - fi-ilk-650: [DMESG-WARN][11] ([fdo#106387]) -> [PASS][12] [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/fi-ilk-650/igt@prime_v...@basic-fence-flip.html [fdo#102614]: https://bugs.freedesktop.org/show_bug.cgi?id=102614 [fdo#106387]: https://bugs.freedesktop.org/show_bug.cgi?id=106387 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107718]: https://bugs.freedesktop.org/show_bug.cgi?id=107718 [fdo#109100]: https://bugs.freedesktop.org/show_bug.cgi?id=109100 [fdo#109485]: https://bugs.freedesktop.org/show_bug.cgi?id=109485 Participating hosts (43 -> 35) -- Additional (1): fi-icl-u3 Missing(9): fi-kbl-soraka fi-ilk-m540 fi-bsw-n3050 fi-byt-squawks fi-bsw-cyan fi-byt-clapper fi-pnv-d510 fi-icl-dsi fi-bdw-samus Build changes - * Linux: CI_DRM_6289 -> Patchwork_13319 CI_DRM_6289: 897314e20de3b565ab91637f69817ebeddde07ef @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13319: c69779fec5decc771ea5ab064964b8e4065de760 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == c69779fec5de drm/i915: Update workarounds selftest for read only regs 3734e4d0d4cc drm/i915: Add whitelist workarounds for ICL 4d5289caa541 drm/i915: Support whitelist workarounds on all engines 09c357e609ef drm/i915: Support flags in whitlist WAs I have pushed this but now I ask for the read-only whitelist selftest to be written really ASAP. Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/23] drm/i915: Factor out common parts from TypeC port handling functions
On Tue, Jun 04, 2019 at 05:58:12PM +0300, Imre Deak wrote:
> Factor out helpers reading/parsing the TypeC specific registers, making
> current users of them clearer and letting us use them later.
>
> While at it also:
> - Simplify icl_tc_phy_connect() with an early return in legacy mode.
> - Simplify the live status check using one bitmask for all HPD bits.
> - Remove a micro-optimisation of the repeated safe-mode clearing.
> - Make sure we fix the legacy port flag in all cases.
>
> Except for the last two, no functional changes.
>
> Cc: José Roberto de Souza
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Signed-off-by: Imre Deak
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 5 +-
> drivers/gpu/drm/i915/intel_tc.c | 166 +++
> drivers/gpu/drm/i915/intel_tc.h | 1 +
> 3 files changed, 103 insertions(+), 69 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 8f223d48d562..d236839bee19 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2983,7 +2983,6 @@ static void icl_program_mg_dp_mode(struct
> intel_digital_port *intel_dig_port)
> {
> struct drm_i915_private *dev_priv =
> to_i915(intel_dig_port->base.base.dev);
> enum port port = intel_dig_port->base.port;
> - enum tc_port tc_port = intel_port_to_tc(dev_priv, port);
> u32 ln0, ln1, lane_info;
>
> if (intel_dig_port->tc_mode == TC_PORT_TBT_ALT)
> @@ -2997,9 +2996,7 @@ static void icl_program_mg_dp_mode(struct
> intel_digital_port *intel_dig_port)
> ln0 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
> ln1 &= ~(MG_DP_MODE_CFG_DP_X1_MODE | MG_DP_MODE_CFG_DP_X2_MODE);
>
> - lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
> - DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> - DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> + lane_info = intel_tc_port_get_lane_info(intel_dig_port);
>
> switch (lane_info) {
> case 0x1:
> diff --git a/drivers/gpu/drm/i915/intel_tc.c b/drivers/gpu/drm/i915/intel_tc.c
> index 07488235b67a..3fdcfa2bbaee 100644
> --- a/drivers/gpu/drm/i915/intel_tc.c
> +++ b/drivers/gpu/drm/i915/intel_tc.c
> @@ -43,10 +43,19 @@ static const char *tc_port_mode_name(enum tc_port_mode
> mode)
> return names[mode];
> }
>
> -int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> +u32 intel_tc_port_get_lane_info(struct intel_digital_port *dig_port)
get_lane_mask() or something?
> {
> struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + u32 lane_info = I915_READ(PORT_TX_DFLEXDPSP);
> +
> + return (lane_info & DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> +DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> +}
> +
> +int intel_tc_port_fia_max_lane_count(struct intel_digital_port *dig_port)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> intel_wakeref_t wakeref;
> u32 lane_info;
>
> @@ -55,9 +64,7 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
>
> lane_info = 0;
> with_intel_display_power(dev_priv, POWER_DOMAIN_DISPLAY_CORE, wakeref)
> - lane_info = (I915_READ(PORT_TX_DFLEXDPSP) &
> - DP_LANE_ASSIGNMENT_MASK(tc_port)) >>
> - DP_LANE_ASSIGNMENT_SHIFT(tc_port);
> + lane_info = intel_tc_port_get_lane_info(dig_port);
>
> switch (lane_info) {
> default:
> @@ -75,6 +82,69 @@ int intel_tc_port_fia_max_lane_count(struct
> intel_digital_port *dig_port)
> }
> }
>
> +static void tc_port_fixup_legacy_flag(struct intel_digital_port *dig_port,
> + u32 live_status_mask)
> +{
> + struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev);
> + enum tc_port tc_port = intel_port_to_tc(dev_priv, dig_port->base.port);
> + u32 valid_hpd_mask = dig_port->tc_legacy_port ? BIT(TC_PORT_LEGACY) :
> + ~BIT(TC_PORT_LEGACY);
> +
> + if (!(live_status_mask & ~valid_hpd_mask))
> + return;
A bit too many nots for me to follow. I guess what it's doing is
checking if any of the other bits are set, and if so it assumes the
mode was misdeclared in vbt?
Actually, won't this end up ping-ponging back and forth if the
hw really reports both legacy and non-legacy bits as set?
> +
> + /* If live status mismatches the VBT flag, trust the live status. */
> + DRM_ERROR("Port %s: live status %08x mismatches the legacy port flag,
> fix flag\n",
> + tc_port_name(dev_priv, tc_port), live_status_mask);
> +
> + dig_port->tc_legacy_port = !dig_port->tc_legacy_port;
> +}
> +
--
Ville Syrjälä
Intel
Re: [Intel-gfx] [PATCH 1/3] drm/i915/gtt: pde entry encoding is identical
Quoting Mika Kuoppala (2019-06-18 17:17:29) > For all page directory entries, the pde encoding is > identical. Don't compilicate call sites with different > versions of doing the same thing. We check the existence of > physical page before writing the entry into it. This further > generalizes the pd so that manipulation in callsites will be > identical, removing the need to handle pdps differently for gen8. And we can pull in the atomic_inc as well? At the top level the result goes unused, but since we should not be as frequently inserting new pages the higher up we go, that should be insignificant. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915: Don't dereference request if it may have been retired
Quoting Chris Wilson (2019-06-18 17:19:51)
> This has count me out on countless occasions, when we retrieve a pointer
> from the submission/execlists backend, it does not carry a reference to
> the context or ring. Those are only pinned while the rquest is active,
> so if we see the request is completed, it may be in the process of being
> retired and those pointers defunct.
>
I guess
Fixes: 3a068721a973 ("drm/i915: Show ring->start for the ELSP context/request
queue")
v4.18!
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110938
> Signed-off-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for Update whitelist support for new hardware (rev2)
== Series Details == Series: Update whitelist support for new hardware (rev2) URL : https://patchwork.freedesktop.org/series/62076/ State : success == Summary == CI Bug Log - changes from CI_DRM_6289_full -> Patchwork_13319_full Summary --- **SUCCESS** No regressions found. Known issues Here are the changes found in Patchwork_13319_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_ctx_isolation@rcs0-s3: - shard-apl: [PASS][1] -> [DMESG-WARN][2] ([fdo#108566]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-apl7/igt@gem_ctx_isolat...@rcs0-s3.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-apl2/igt@gem_ctx_isolat...@rcs0-s3.html * igt@gem_eio@in-flight-internal-immediate: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-apl3/igt@gem_...@in-flight-internal-immediate.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-apl2/igt@gem_...@in-flight-internal-immediate.html * igt@gem_eio@throttle: - shard-kbl: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-kbl4/igt@gem_...@throttle.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-kbl7/igt@gem_...@throttle.html * igt@gem_persistent_relocs@forked-faulting-reloc-thrashing: - shard-snb: [PASS][7] -> [DMESG-WARN][8] ([fdo#110789] / [fdo#110913 ]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-snb7/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-snb2/igt@gem_persistent_rel...@forked-faulting-reloc-thrashing.html * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup: - shard-snb: [PASS][9] -> [DMESG-WARN][10] ([fdo#110913 ]) +1 similar issue [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-snb7/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html * igt@i915_pm_rpm@gem-mmap-cpu: - shard-iclb: [PASS][11] -> [INCOMPLETE][12] ([fdo#107713] / [fdo#108840]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-iclb6/igt@i915_pm_...@gem-mmap-cpu.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-iclb7/igt@i915_pm_...@gem-mmap-cpu.html * igt@i915_selftest@live_evict: - shard-kbl: [PASS][13] -> [INCOMPLETE][14] ([fdo#103665] / [fdo#110938]) [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-kbl2/igt@i915_selftest@live_evict.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-kbl4/igt@i915_selftest@live_evict.html * igt@kms_busy@extended-modeset-hang-newfb-render-c: - shard-iclb: [PASS][15] -> [INCOMPLETE][16] ([fdo#107713]) [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-iclb2/igt@kms_b...@extended-modeset-hang-newfb-render-c.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-iclb7/igt@kms_b...@extended-modeset-hang-newfb-render-c.html * igt@kms_cursor_edge_walk@pipe-b-64x64-bottom-edge: - shard-snb: [PASS][17] -> [SKIP][18] ([fdo#109271] / [fdo#109278]) [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-snb7/igt@kms_cursor_edge_w...@pipe-b-64x64-bottom-edge.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-snb2/igt@kms_cursor_edge_w...@pipe-b-64x64-bottom-edge.html * igt@kms_flip@flip-vs-suspend: - shard-snb: [PASS][19] -> [INCOMPLETE][20] ([fdo#105411]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-snb2/igt@kms_f...@flip-vs-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-snb1/igt@kms_f...@flip-vs-suspend.html - shard-glk: [PASS][21] -> [INCOMPLETE][22] ([fdo#103359] / [k.org#198133]) [21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-glk3/igt@kms_f...@flip-vs-suspend.html [22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-glk6/igt@kms_f...@flip-vs-suspend.html * igt@kms_flip@flip-vs-suspend-interruptible: - shard-skl: [PASS][23] -> [INCOMPLETE][24] ([fdo#107773] / [fdo#109507]) [23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-skl5/igt@kms_f...@flip-vs-suspend-interruptible.html [24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13319/shard-skl2/igt@kms_f...@flip-vs-suspend-interruptible.html * igt@kms_frontbuffer_tracking@basic: - shard-iclb: [PASS][25] -> [FAIL][26] ([fdo#103167]) +3 similar issues [25]:
Re: [Intel-gfx] [PATCH 02/26] drm/i915: Skip shrinking already freed pages
Quoting Mika Kuoppala (2019-06-18 17:06:36) > Chris Wilson writes: > > diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > index c851c4029597..3a926a8755c6 100644 > > --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c > > @@ -241,6 +241,9 @@ i915_gem_shrink(struct drm_i915_private *i915, > > if (!can_release_pages(obj)) > > continue; > > > > + if (!kref_get_unless_zero(>base.refcount)) > > + continue; > > + > > The comment above, in this function, seems a little bit > stale on talking about struct mutex. Straighten it up. > > Reviewed-by: Mika Kuoppala There's a series with the goal of straightening that up. :-p -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/i915: Don't dereference request if it may have been retired
This has count me out on countless occasions, when we retrieve a pointer
from the submission/execlists backend, it does not carry a reference to
the context or ring. Those are only pinned while the rquest is active,
so if we see the request is completed, it may be in the process of being
retired and those pointers defunct.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=110938
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_engine_cs.c | 16 +---
1 file changed, 9 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
index 898692989313..7fd33e81c2d9 100644
--- a/drivers/gpu/drm/i915/gt/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/gt/intel_engine_cs.c
@@ -1311,12 +1311,13 @@ static void hexdump(struct drm_printer *m, const void
*buf, size_t len)
}
}
-static void intel_engine_print_registers(const struct intel_engine_cs *engine,
+static void intel_engine_print_registers(struct intel_engine_cs *engine,
struct drm_printer *m)
{
struct drm_i915_private *dev_priv = engine->i915;
const struct intel_engine_execlists * const execlists =
>execlists;
+ unsigned long flags;
u64 addr;
if (engine->id == RCS0 && IS_GEN_RANGE(dev_priv, 4, 7))
@@ -1397,15 +1398,16 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
idx, hws[idx * 2], hws[idx * 2 + 1]);
}
- rcu_read_lock();
+ spin_lock_irqsave(>active.lock, flags);
for (idx = 0; idx < execlists_num_ports(execlists); idx++) {
struct i915_request *rq;
unsigned int count;
+ char hdr[80];
rq = port_unpack(>port[idx], );
- if (rq) {
- char hdr[80];
-
+ if (!rq) {
+ drm_printf(m, "\t\tELSP[%d] idle\n", idx);
+ } else if (!i915_request_signaled(rq)) {
snprintf(hdr, sizeof(hdr),
"\t\tELSP[%d] count=%d,
ring:{start:%08x, hwsp:%08x, seqno:%08x}, rq: ",
idx, count,
@@ -1414,11 +1416,11 @@ static void intel_engine_print_registers(const struct
intel_engine_cs *engine,
hwsp_seqno(rq));
print_request(m, rq, hdr);
} else {
- drm_printf(m, "\t\tELSP[%d] idle\n", idx);
+ print_request(m, rq, "\t\tELSP[%d] rq: ");
}
}
drm_printf(m, "\t\tHW active? 0x%x\n", execlists->active);
- rcu_read_unlock();
+ spin_unlock_irqrestore(>active.lock, flags);
} else if (INTEL_GEN(dev_priv) > 6) {
drm_printf(m, "\tPP_DIR_BASE: 0x%08x\n",
ENGINE_READ(engine, RING_PP_DIR_BASE));
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/2] drm/i915/selftests: Flush live_evict
Be sure to cleanup after live_evict by flushing any residual state off
the GPU using igt_flush_test.
Signed-off-by: Chris Wilson
---
drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
index 8c69198c7e4e..a3cb0aade6f1 100644
--- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
+++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c
@@ -28,6 +28,7 @@
#include "i915_selftest.h"
+#include "igt_flush_test.h"
#include "lib_sw_fence.h"
#include "mock_drm.h"
#include "mock_gem_device.h"
@@ -505,6 +506,8 @@ static int igt_evict_contexts(void *arg)
mutex_lock(>drm.struct_mutex);
out_locked:
+ if (igt_flush_test(i915, I915_WAIT_LOCKED))
+ err = -EIO;
while (reserved) {
struct reserved *next = reserved->next;
--
2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/gtt: Setup phys pages for 3lvl pdps
If we setup backing phys page for 3lvl pdps, even they
are not used, we lose 5 pages per ppgtt.
Trading this memory on bsw, we gain more common code paths for all
gen8+ directory manipulation. And those paths are now void of checks
for page directory type, making the hot paths faster.
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 106 +---
1 file changed, 66 insertions(+), 40 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index b521b1ddd19b..ea78302c6348 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -715,22 +715,14 @@ static struct i915_page_directory *alloc_pd(struct
i915_address_space *vm)
return pd;
}
-static inline bool pd_has_phys_page(const struct i915_page_directory * const
pd)
-{
- return pd->base.page;
-}
-
static void free_pd(struct i915_address_space *vm,
struct i915_page_directory *pd)
{
- if (likely(pd_has_phys_page(pd)))
- cleanup_page_dma(vm, >base);
-
+ cleanup_page_dma(vm, >base);
kfree(pd);
}
#define init_pd(vm, pd, to) { \
- GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
memset_p((pd)->entry, (to), 512); \
}
@@ -1539,6 +1531,50 @@ static void ppgtt_init(struct drm_i915_private *i915,
ppgtt->vm.vma_ops.clear_pages = clear_pages;
}
+static void init_pd_n(struct i915_address_space *vm,
+ struct i915_page_directory *pd,
+ struct i915_page_directory *to,
+ const unsigned int entries)
+{
+ const u64 daddr = gen8_pde_encode(px_dma(to), I915_CACHE_LLC);
+ u64 * const vaddr = kmap_atomic(pd->base.page);
+
+ memset64(vaddr, daddr, entries);
+ kunmap_atomic(vaddr);
+
+ memset_p(pd->entry, to, entries);
+}
+
+static struct i915_page_directory *
+gen8_alloc_top_pd(struct i915_address_space *vm)
+{
+ struct i915_page_directory *pd;
+
+ if (i915_vm_is_4lvl(vm)) {
+ pd = alloc_pd(vm);
+ if (!IS_ERR(pd))
+ init_pd(vm, pd, vm->scratch_pdp);
+
+ return pd;
+ }
+
+ /* 3lvl */
+ pd = __alloc_pd();
+ if (!pd)
+ return ERR_PTR(-ENOMEM);
+
+ pd->entry[GEN8_3LVL_PDPES] = NULL;
+
+ if (unlikely(setup_page_dma(vm, >base))) {
+ kfree(pd);
+ return ERR_PTR(-ENOMEM);
+ }
+
+ init_pd_n(vm, pd, vm->scratch_pd, GEN8_3LVL_PDPES);
+
+ return pd;
+}
+
/*
* GEN8 legacy ppgtt programming is accomplished through a max 4 PDP registers
* with a net effect resembling a 2-level page table in normal x86 terms. Each
@@ -1548,6 +1584,7 @@ static void ppgtt_init(struct drm_i915_private *i915,
*/
static struct i915_ppgtt *gen8_ppgtt_create(struct drm_i915_private *i915)
{
+ struct i915_address_space *vm;
struct i915_ppgtt *ppgtt;
int err;
@@ -1557,70 +1594,59 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct
drm_i915_private *i915)
ppgtt_init(i915, ppgtt);
+ vm = >vm;
+
/*
* From bdw, there is hw support for read-only pages in the PPGTT.
*
* Gen11 has HSDES#:1807136187 unresolved. Disable ro support
* for now.
*/
- ppgtt->vm.has_read_only = INTEL_GEN(i915) != 11;
+ vm->has_read_only = INTEL_GEN(i915) != 11;
/* There are only few exceptions for gen >=6. chv and bxt.
* And we are not sure about the latter so play safe for now.
*/
if (IS_CHERRYVIEW(i915) || IS_BROXTON(i915))
- ppgtt->vm.pt_kmap_wc = true;
+ vm->pt_kmap_wc = true;
- err = gen8_init_scratch(>vm);
+ err = gen8_init_scratch(vm);
if (err)
goto err_free;
- ppgtt->pd = __alloc_pd();
- if (!ppgtt->pd) {
- err = -ENOMEM;
+ ppgtt->pd = gen8_alloc_top_pd(vm);
+ if (IS_ERR(ppgtt->pd)) {
+ err = PTR_ERR(ppgtt->pd);
goto err_free_scratch;
}
- if (i915_vm_is_4lvl(>vm)) {
- err = setup_page_dma(>vm, >pd->base);
- if (err)
- goto err_free_pdp;
-
- init_pd(>vm, ppgtt->pd, ppgtt->vm.scratch_pdp);
-
- ppgtt->vm.allocate_va_range = gen8_ppgtt_alloc_4lvl;
- ppgtt->vm.insert_entries = gen8_ppgtt_insert_4lvl;
- ppgtt->vm.clear_range = gen8_ppgtt_clear_4lvl;
+ if (i915_vm_is_4lvl(vm)) {
+ vm->allocate_va_range = gen8_ppgtt_alloc_4lvl;
+ vm->insert_entries = gen8_ppgtt_insert_4lvl;
+ vm->clear_range = gen8_ppgtt_clear_4lvl;
} else {
- /*
-* We
[Intel-gfx] [PATCH 2/3] drm/i915/gtt: Tear down setup and cleanup macros for page dma
We don't use common codepaths to setup and cleanup page
directories vs page tables. So their setup and cleanup macros
are of no use.
Signed-off-by: Mika Kuoppala
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 5df17db68875..b521b1ddd19b 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -551,8 +551,6 @@ static void cleanup_page_dma(struct i915_address_space *vm,
#define kmap_atomic_px(px) kmap_atomic(px_base(px)->page)
-#define setup_px(vm, px) setup_page_dma((vm), px_base(px))
-#define cleanup_px(vm, px) cleanup_page_dma((vm), px_base(px))
#define fill_px(vm, px, v) fill_page_dma((vm), px_base(px), (v))
#define fill32_px(vm, px, v) fill_page_dma_32((vm), px_base(px), (v))
@@ -654,7 +652,7 @@ static struct i915_page_table *alloc_pt(struct
i915_address_space *vm)
if (unlikely(!pt))
return ERR_PTR(-ENOMEM);
- if (unlikely(setup_px(vm, pt))) {
+ if (unlikely(setup_page_dma(vm, >base))) {
kfree(pt);
return ERR_PTR(-ENOMEM);
}
@@ -666,7 +664,7 @@ static struct i915_page_table *alloc_pt(struct
i915_address_space *vm)
static void free_pt(struct i915_address_space *vm, struct i915_page_table *pt)
{
- cleanup_px(vm, pt);
+ cleanup_page_dma(vm, >base);
kfree(pt);
}
@@ -709,7 +707,7 @@ static struct i915_page_directory *alloc_pd(struct
i915_address_space *vm)
if (unlikely(!pd))
return ERR_PTR(-ENOMEM);
- if (unlikely(setup_px(vm, pd))) {
+ if (unlikely(setup_page_dma(vm, >base))) {
kfree(pd);
return ERR_PTR(-ENOMEM);
}
@@ -726,7 +724,7 @@ static void free_pd(struct i915_address_space *vm,
struct i915_page_directory *pd)
{
if (likely(pd_has_phys_page(pd)))
- cleanup_px(vm, pd);
+ cleanup_page_dma(vm, >base);
kfree(pd);
}
@@ -1584,7 +1582,7 @@ static struct i915_ppgtt *gen8_ppgtt_create(struct
drm_i915_private *i915)
}
if (i915_vm_is_4lvl(>vm)) {
- err = setup_px(>vm, ppgtt->pd);
+ err = setup_page_dma(>vm, >pd->base);
if (err)
goto err_free_pdp;
--
2.17.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/3] drm/i915/gtt: pde entry encoding is identical
For all page directory entries, the pde encoding is
identical. Don't compilicate call sites with different
versions of doing the same thing. We check the existence of
physical page before writing the entry into it. This further
generalizes the pd so that manipulation in callsites will be
identical, removing the need to handle pdps differently for gen8.
v2: squash
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_gem_gtt.c | 114 ++--
drivers/gpu/drm/i915/i915_gem_gtt.h | 3 -
2 files changed, 40 insertions(+), 77 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 8ab820145ea6..5df17db68875 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -215,10 +215,10 @@ static u64 gen8_pte_encode(dma_addr_t addr,
return pte;
}
-static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
- const enum i915_cache_level level)
+static u64 gen8_pde_encode(const dma_addr_t addr,
+ const enum i915_cache_level level)
{
- gen8_pde_t pde = _PAGE_PRESENT | _PAGE_RW;
+ u64 pde = _PAGE_PRESENT | _PAGE_RW;
pde |= addr;
if (level != I915_CACHE_NONE)
pde |= PPAT_CACHED_PDE;
@@ -227,9 +227,6 @@ static gen8_pde_t gen8_pde_encode(const dma_addr_t addr,
return pde;
}
-#define gen8_pdpe_encode gen8_pde_encode
-#define gen8_pml4e_encode gen8_pde_encode
-
static u64 snb_pte_encode(dma_addr_t addr,
enum i915_cache_level level,
u32 flags)
@@ -734,24 +731,36 @@ static void free_pd(struct i915_address_space *vm,
kfree(pd);
}
-static void init_pd_with_page(struct i915_address_space *vm,
- struct i915_page_directory * const pd,
- struct i915_page_table *pt)
-{
- fill_px(vm, pd, gen8_pde_encode(px_dma(pt), I915_CACHE_LLC));
- memset_p(pd->entry, pt, 512);
+#define init_pd(vm, pd, to) { \
+ GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));\
+ fill_px((vm), (pd), gen8_pde_encode(px_dma(to), I915_CACHE_LLC)); \
+ memset_p((pd)->entry, (to), 512); \
}
-static void init_pd(struct i915_address_space *vm,
- struct i915_page_directory * const pd,
- struct i915_page_directory * const to)
+static void __write_dma_entry(struct i915_page_dma * const pdma,
+ const unsigned short pde,
+ const u64 encoded_entry)
{
- GEM_DEBUG_BUG_ON(!pd_has_phys_page(pd));
+ u64 *vaddr;
- fill_px(vm, pd, gen8_pdpe_encode(px_dma(to), I915_CACHE_LLC));
- memset_p(pd->entry, to, 512);
+ vaddr = kmap_atomic(pdma->page);
+ vaddr[pde] = encoded_entry;
+ kunmap_atomic(vaddr);
}
+static inline void
+__set_pd_entry(struct i915_page_directory * const pd,
+ const unsigned short pde,
+ struct i915_page_dma * const to,
+ u64 (*encode)(const dma_addr_t, const enum i915_cache_level))
+{
+ pd->entry[pde] = to;
+ __write_dma_entry(px_base(pd), pde, encode(to->daddr, I915_CACHE_LLC));
+}
+
+#define set_pd_entry(pd, pde, to) \
+ __set_pd_entry((pd), (pde), px_base(to), gen8_pde_encode)
+
/*
* PDE TLBs are a pain to invalidate on GEN8+. When we modify
* the page table structures, we mark them dirty so that
@@ -781,18 +790,6 @@ static bool gen8_ppgtt_clear_pt(const struct
i915_address_space *vm,
return !atomic_sub_return(num_entries, >used);
}
-static void gen8_ppgtt_set_pde(struct i915_address_space *vm,
- struct i915_page_directory *pd,
- struct i915_page_table *pt,
- unsigned int pde)
-{
- gen8_pde_t *vaddr;
-
- vaddr = kmap_atomic_px(pd);
- vaddr[pde] = gen8_pde_encode(px_dma(pt), I915_CACHE_LLC);
- kunmap_atomic(vaddr);
-}
-
static bool gen8_ppgtt_clear_pd(struct i915_address_space *vm,
struct i915_page_directory *pd,
u64 start, u64 length)
@@ -810,8 +807,7 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
spin_lock(>lock);
if (!atomic_read(>used)) {
- gen8_ppgtt_set_pde(vm, pd, vm->scratch_pt, pde);
- pd->entry[pde] = vm->scratch_pt;
+ set_pd_entry(pd, pde, vm->scratch_pt);
GEM_BUG_ON(!atomic_read(>used));
atomic_dec(>used);
@@ -825,20 +821,6 @@ static bool gen8_ppgtt_clear_pd(struct i915_address_space
*vm,
return !atomic_read(>used);
}
-static void gen8_ppgtt_set_pdpe(struct i915_page_directory *pdp,
- struct i915_page_directory
Re: [Intel-gfx] [PATCH 4/4] drm/i915: Update workarounds selftest for read only regs
On 18/06/2019 14:43, John Harrison wrote:
On 6/17/2019 23:42, Tvrtko Ursulin wrote:
On 18/06/2019 02:01, john.c.harri...@intel.com wrote:
From: "Robert M. Fosha"
Updates the live_workarounds selftest to handle whitelisted
registers that are flagged as read only.
Signed-off-by: Robert M. Fosha
Signed-off-by: John Harrison
---
.../gpu/drm/i915/gt/selftest_workarounds.c | 43 +--
1 file changed, 39 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
index c8d335d63f9c..eb6d3aa2c8cc 100644
--- a/drivers/gpu/drm/i915/gt/selftest_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/selftest_workarounds.c
@@ -408,6 +408,29 @@ static bool wo_register(struct intel_engine_cs
*engine, u32 reg)
return false;
}
+static bool ro_register(u32 reg)
+{
+ if (reg & RING_FORCE_TO_NONPRIV_RD)
+ return true;
+
+ return false;
+}
+
+static int whitelist_writable_count(struct intel_engine_cs *engine)
+{
+ int count = engine->whitelist.count;
+ int i;
+
+ for (i = 0; i < engine->whitelist.count; i++) {
+ u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+
+ if (ro_register(reg))
+ count--;
+ }
+
+ return count;
+}
+
static int check_dirty_whitelist(struct i915_gem_context *ctx,
struct intel_engine_cs *engine)
{
@@ -463,6 +486,9 @@ static int check_dirty_whitelist(struct
i915_gem_context *ctx,
if (wo_register(engine, reg))
continue;
+ if (ro_register(reg))
+ continue;
+
srm = MI_STORE_REGISTER_MEM;
lrm = MI_LOAD_REGISTER_MEM;
if (INTEL_GEN(ctx->i915) >= 8)
@@ -734,9 +760,13 @@ static int read_whitelisted_registers(struct
i915_gem_context *ctx,
for (i = 0; i < engine->whitelist.count; i++) {
u64 offset = results->node.start + sizeof(u32) * i;
+ u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+
+ /* Clear RD only and WR only flags */
+ reg &= ~(RING_FORCE_TO_NONPRIV_RD | RING_FORCE_TO_NONPRIV_WR);
*cs++ = srm;
- *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ *cs++ = reg;
*cs++ = lower_32_bits(offset);
*cs++ = upper_32_bits(offset);
}
@@ -769,9 +799,14 @@ static int scrub_whitelisted_registers(struct
i915_gem_context *ctx,
goto err_batch;
}
- *cs++ = MI_LOAD_REGISTER_IMM(engine->whitelist.count);
+ *cs++ = MI_LOAD_REGISTER_IMM(whitelist_writable_count(engine));
for (i = 0; i < engine->whitelist.count; i++) {
- *cs++ = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+ u32 reg = i915_mmio_reg_offset(engine->whitelist.list[i].reg);
+
+ if (ro_register(reg))
+ continue;
+
Are we not able to test the read-only property at all?
I am sure it would be possible to make such work. But can that wait
until the next round when we add support for ranges? And write only
access too if any registers actually use that and there is a way to test
that it really does do something?
I believe Robert was looking at getting something going but it wasn't
immediately working and we urgently need to get the HUC whitelist
updates merged to hit the next release window. So right now, it is
sufficient to say that the user land media driver works with these
changes and therefore the whitelisting must be working. The kernel
selftest is just a belt and braces check on top of that and therefore
can wait until later.
I don't agree that it is just belt and braces but in fact a way to check
that the thing really is read-only like it says on the tin. Lesson here
is that history keeps repeating panics which could have been avoided by
running the pre-existing tests during development.
However since I don't think there is any risk to driver or system
stability, even if the read-only property happened to be broken, which
it probably isn't, you can have a grumpy:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
___
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: Support flags in whitlist WAs
On 18/06/2019 02:01, john.c.harri...@intel.com wrote:
From: John Harrison
Newer hardware adds flags to the whitelist work-around register. These
allow per access direction privileges and ranges.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
Signed-off-by: John Harrison
Signed-off-by: Robert M. Fosha
Cc: Tvrtko Ursulin
Cc: Chris Wilson
---
drivers/gpu/drm/i915/gt/intel_workarounds.c | 9 -
drivers/gpu/drm/i915/i915_reg.h | 7 +++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gt/intel_workarounds.c
b/drivers/gpu/drm/i915/gt/intel_workarounds.c
index 165b0a45e009..ae82340fff45 100644
--- a/drivers/gpu/drm/i915/gt/intel_workarounds.c
+++ b/drivers/gpu/drm/i915/gt/intel_workarounds.c
@@ -1012,7 +1012,7 @@ bool intel_gt_verify_workarounds(struct drm_i915_private
*i915,
}
static void
-whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
+whitelist_reg_ext(struct i915_wa_list *wal, i915_reg_t reg, u32 flags)
{
struct i915_wa wa = {
.reg = reg
@@ -1021,9 +1021,16 @@ whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
if (GEM_DEBUG_WARN_ON(wal->count >= RING_MAX_NONPRIV_SLOTS))
return;
+ wa.reg.reg |= flags;
_wa_add(wal, );
}
+static void
+whitelist_reg(struct i915_wa_list *wal, i915_reg_t reg)
+{
+ whitelist_reg_ext(wal, reg, RING_FORCE_TO_NONPRIV_RW);
+}
+
static void gen9_whitelist_build(struct i915_wa_list *w)
{
/* WaVFEStateAfterPipeControlwithMediaStateClear:skl,bxt,glk,cfl */
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 7a26766ba84d..cc295a4f6e92 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2513,6 +2513,13 @@ enum i915_power_well_id {
#define RING_WAIT_SEMAPHORE (1 << 10) /* gen6+ */
#define RING_FORCE_TO_NONPRIV(base, i) _MMIO(((base) + 0x4D0) + (i) * 4)
+#define RING_FORCE_TO_NONPRIV_RW (0 << 28)/* CFL+ & Gen11+ */
+#define RING_FORCE_TO_NONPRIV_RD (1 << 28)
+#define RING_FORCE_TO_NONPRIV_WR (2 << 28)
+#define RING_FORCE_TO_NONPRIV_RANGE_1(0 << 0) /* CFL+ &
Gen11+ */
+#define RING_FORCE_TO_NONPRIV_RANGE_4(1 << 0)
+#define RING_FORCE_TO_NONPRIV_RANGE_16 (2 << 0)
+#define RING_FORCE_TO_NONPRIV_RANGE_64 (3 << 0)
#define RING_MAX_NONPRIV_SLOTS 12
#define GEN7_TLB_RD_ADDR _MMIO(0x4700)
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/ehl: Allow combo PHY A to drive a third external display
On Mon, Jun 17, 2019 at 04:48:10PM -0700, Matt Roper wrote:
> EHL has a mux on combo PHY A that allows it to be driven either by an
> internal display (DDI-A or DSI DPHY) or by an external display (DDI-D).
> This is a motherboard design decision that can not be changed on the
> fly. Unfortunately there are no strap registers that allow us to detect
> the board configuration directly, so let's use the VBT to try to figure
> it out and program the mux accordingly.
>
> v2:
> - Confirmed that VBT's dvo port refers to the DDI and not the PHY.
>Thus we can check more explicitly for (ddi_d && !(ddi_a || dsi)). If
>a bad VBT contradicts itself, let internal display win. (Ville)
>
> Cc: Clint Taylor
> Cc: Ville Syrjälä
> Signed-off-by: Matt Roper
> ---
> drivers/gpu/drm/i915/display/intel_bios.c | 3 ++
> .../gpu/drm/i915/display/intel_combo_phy.c| 36 +++
> drivers/gpu/drm/i915/i915_reg.h | 1 +
> 3 files changed, 40 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/display/intel_bios.c
> b/drivers/gpu/drm/i915/display/intel_bios.c
> index c4710889cb32..0c9808132d67 100644
> --- a/drivers/gpu/drm/i915/display/intel_bios.c
> +++ b/drivers/gpu/drm/i915/display/intel_bios.c
> @@ -1668,6 +1668,9 @@ parse_general_definitions(struct drm_i915_private
> *dev_priv,
> if (!child->device_type)
> continue;
>
> + DRM_DEBUG_KMS("Found VBT child device with type 0x%x\n",
> + child->device_type);
> +
Was this hunk intentional?
> /*
>* Copy as much as we know (sizeof) and is available
>* (child_dev_size) of the child device. Accessing the data must
> diff --git a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> index 841708da5a56..c18079a09a2e 100644
> --- a/drivers/gpu/drm/i915/display/intel_combo_phy.c
> +++ b/drivers/gpu/drm/i915/display/intel_combo_phy.c
> @@ -260,6 +260,32 @@ void intel_combo_phy_power_up_lanes(struct
> drm_i915_private *dev_priv,
> I915_WRITE(ICL_PORT_CL_DW10(port), val);
> }
>
> +static u32 ehl_combo_phy_a_mux(struct drm_i915_private *i915, u32 val)
> +{
> + bool ddi_a_present = i915->vbt.ddi_port_info[PORT_A].child != NULL;
> + bool ddi_d_present = i915->vbt.ddi_port_info[PORT_D].child != NULL;
> + bool dsi_present = intel_bios_is_dsi_present(i915, NULL);
> +
> + /*
> + * VBT's 'dvo port' field for child devices references the DDI, not
> + * the PHY. So if combo PHY A is wired up to drive an external
> + * display, we should see a child device present on PORT_D and
> + * nothing on PORT_A and no DSI.
> + */
> + if (ddi_d_present && !ddi_a_present && !dsi_present)
> + return val | ICL_PHY_MISC_MUX_DDID;
> +
> + /*
> + * If we encounter a VBT that claims to have an external display on
> + * DDI-D _and_ an internal display on DDI-A/DSI leave an error message
> + * in the log and let the internal display win.
> + */
> + if (ddi_d_present)
> + DRM_ERROR("VBT claims to have both internal and external
> displays on PHY A. Configuring for internal.\n");
> +
> + return val & ~ICL_PHY_MISC_MUX_DDID;
> +}
> +
> static void icl_combo_phys_init(struct drm_i915_private *dev_priv)
> {
> enum port port;
> @@ -273,7 +299,17 @@ static void icl_combo_phys_init(struct drm_i915_private
> *dev_priv)
> continue;
> }
>
> + /*
> + * EHL's combo PHY A can be hooked up to either an external
> + * display (via DDI-D) or an internal display (via DDI-A or
> + * the DSI DPHY). This is a motherboard design decision that
> + * can't be changed on the fly, so initialize the PHY's mux
> + * based on whether our VBT indicates the presence of any
> + * "internal" child devices.
> + */
> val = I915_READ(ICL_PHY_MISC(port));
> + if (!IS_ICELAKE(dev_priv) && port == PORT_A)
Maybe IS_EHL instead?
Patch is
Reviewed-by: Ville Syrjälä
> + val = ehl_combo_phy_a_mux(dev_priv, val);
> val &= ~ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN;
> I915_WRITE(ICL_PHY_MISC(port), val);
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 1ae36b9efc85..68afafafd312 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -11138,6 +11138,7 @@ enum skl_power_gate {
> #define _ICL_PHY_MISC_B 0x64C04
> #define ICL_PHY_MISC(port) _MMIO_PORT(port, _ICL_PHY_MISC_A, \
>_ICL_PHY_MISC_B)
> +#define ICL_PHY_MISC_MUX_DDID (1 << 28)
> #define ICL_PHY_MISC_DE_IO_COMP_PWR_DOWN(1 << 23)
>
> /* Icelake Display Stream Compression Registers */
> --
>
Re: [Intel-gfx] [PATCH 02/26] drm/i915: Skip shrinking already freed pages
Chris Wilson writes:
> Previously, we want to shrink the pages of freed objects before they
> were RCU collected. However, by removing the struct_mutex serialisation
> around the active reference, we need to acquire an extra reference
> around the wait. Unfortunately this means that we have to skip objects
> that are waiting RCU collection.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gem/i915_gem_object.c | 47 +---
> drivers/gpu/drm/i915/gem/i915_gem_shrinker.c | 5 +++
> 2 files changed, 6 insertions(+), 46 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> index 272ce30ce1d3..1b571fd26ed4 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_object.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_object.c
> @@ -149,33 +149,6 @@ void i915_gem_close_object(struct drm_gem_object *gem,
> struct drm_file *file)
> }
> }
>
> -static bool discard_backing_storage(struct drm_i915_gem_object *obj)
> -{
> - /*
> - * If we are the last user of the backing storage (be it shmemfs
> - * pages or stolen etc), we know that the pages are going to be
> - * immediately released. In this case, we can then skip copying
> - * back the contents from the GPU.
> - */
> - if (!i915_gem_object_is_shrinkable(obj))
> - return false;
> -
> - if (obj->mm.madv != I915_MADV_WILLNEED)
> - return false;
> -
> - if (!obj->base.filp)
> - return true;
> -
> - /* At first glance, this looks racy, but then again so would be
> - * userspace racing mmap against close. However, the first external
> - * reference to the filp can only be obtained through the
> - * i915_gem_mmap_ioctl() which safeguards us against the user
> - * acquiring such a reference whilst we are in the middle of
> - * freeing the object.
> - */
> - return file_count(obj->base.filp) == 1;
> -}
> -
> static void __i915_gem_free_objects(struct drm_i915_private *i915,
> struct llist_node *freed)
> {
> @@ -225,8 +198,7 @@ static void __i915_gem_free_objects(struct
> drm_i915_private *i915,
> if (obj->ops->release)
> obj->ops->release(obj);
>
> - if (WARN_ON(i915_gem_object_has_pinned_pages(obj)))
> - atomic_set(>mm.pages_pin_count, 0);
> + atomic_set(>mm.pages_pin_count, 0);
> __i915_gem_object_put_pages(obj, I915_MM_NORMAL);
> GEM_BUG_ON(i915_gem_object_has_pages(obj));
>
> @@ -324,23 +296,6 @@ void i915_gem_free_object(struct drm_gem_object *gem_obj)
> {
> struct drm_i915_gem_object *obj = to_intel_bo(gem_obj);
>
> - if (obj->mm.quirked)
> - __i915_gem_object_unpin_pages(obj);
> -
> - if (discard_backing_storage(obj)) {
> - struct drm_i915_private *i915 = to_i915(obj->base.dev);
> -
> - obj->mm.madv = I915_MADV_DONTNEED;
> -
> - if (i915_gem_object_has_pages(obj)) {
> - unsigned long flags;
> -
> - spin_lock_irqsave(>mm.obj_lock, flags);
> - list_move_tail(>mm.link, >mm.purge_list);
> - spin_unlock_irqrestore(>mm.obj_lock, flags);
> - }
> - }
> -
> /*
>* Before we free the object, make sure any pure RCU-only
>* read-side critical sections are complete, e.g.
> diff --git a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> index c851c4029597..3a926a8755c6 100644
> --- a/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
> @@ -241,6 +241,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
> if (!can_release_pages(obj))
> continue;
>
> + if (!kref_get_unless_zero(>base.refcount))
> + continue;
> +
The comment above, in this function, seems a little bit
stale on talking about struct mutex. Straighten it up.
Reviewed-by: Mika Kuoppala
> spin_unlock_irqrestore(>mm.obj_lock, flags);
>
> if (unsafe_drop_pages(obj)) {
> @@ -253,7 +256,9 @@ i915_gem_shrink(struct drm_i915_private *i915,
> }
> mutex_unlock(>mm.lock);
> }
> +
> scanned += obj->base.size >> PAGE_SHIFT;
> + i915_gem_object_put(obj);
>
> spin_lock_irqsave(>mm.obj_lock, flags);
> }
> --
> 2.20.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v3 1/4] meson: add libatomic dependency
On 18/06/2019 15:37, Ser, Simon wrote:
> On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
>> On 18/06/2019 14:20, Ser, Simon wrote:
>>> On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
Add conditional dependency on libatomic in order to be able to use the
__atomic_* functions instead of the older __sync_* ones. The
libatomic library is only needed when there aren't any native support
on the current architecture, so a linker test is used for this
purpose. This enables atomic operations to be on a wider number of
architectures including MIPS.
Signed-off-by: Guillaume Tucker
---
Notes:
v2: add linker test for libatomic
v3: use null_dep
meson.build | 14 ++
1 file changed, 14 insertions(+)
diff --git a/meson.build b/meson.build
index 6268c58d3634..118ad667ffb5 100644
--- a/meson.build
+++ b/meson.build
@@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
dlsym = cc.find_library('dl')
zlib = cc.find_library('z')
+if cc.links('''
+#include
+int main(void) {
+ uint32_t x32 = 0;
+ uint64_t x64 = 0;
+ __atomic_load_n(, __ATOMIC_SEQ_CST);
+ __atomic_load_n(, __ATOMIC_SEQ_CST);
>>>
>>> See my reply for v2. I've looked into this a little bit more and it
>>> looks like __atomic_* functions are a GCC implementation detail. OIn
>>> other words, the C11 standard [1] defines only atomic_* functions, and
>>> GCC implements them with __atomic_* builtins when the platform supports
>>> it, but other compilers might not expose those builtins and still
>>> support atomic_* functions without them. This also seems to be what [2]
>>> explains:
>>>
The first set of library functions are named __atomic_*. This set has
been “standardized” by GCC, and is described below. (See also GCC’s
documentation)
>>>
>>> (Notice the quotes around “standardized”, meaning they are a GCC
>>> extension)
>>
>> Quite, and while the stdatomic.h API is part of the C11 standard,
>> libatomic is part of GCC. So this test is to determine whether
>> linking against GCC's libatomic.so is needed for its __atomic_*
>> fallback implementation.
>>
>> It raises the question of what to do with other compilers, but
>> igt has other build errors with clang on mips at the moment.
>> With a quick search, it looks like its __atomic_* functions are
>> part of libclang.so for clang.
>
> I don't see anything in `readelf -s /usr/lib/libclang.so.8`.
Yes, well I did this:
$ for f in $(find . -name "*.so"); do strings $f | grep __atomic_load && echo
$f; done
__atomic_load
__atomic_load_1
__atomic_load_2
__atomic_load_4
__atomic_load_8
./gcc/mips-linux-gnu/8/libatomic.so
__atomic_load
__atomic_load_1
__atomic_load_2
__atomic_load_4
__atomic_load_8
__atomic_load_16
./mips-linux-gnu/libLLVM-7.so
although it's true that they don't appear as proper symbols with
readelf. It would take a bit more investigation in the LLVM
source code to get to the bottom of that, but I don't think it's
necessary to solve the problem at hand.
>> Maybe this test should only be used when the compiler name is
>> gcc? In practice it does work with both gcc and clang though, as
>> they both use the same naming convention for atomic built-ins.
>
> Hmm. I'm still not quite sure I understand why checking with __atomic_*
> is preferred.
>
> - If the compiler has __atomic_* builtins: this won't link with
> libatomic
> - If the compiler doesn't have __atomic_* builtins: this will link with
> libatomic even if stdatomic.h works without it
>
> What we're really interested in is stdatomic.h support, not __atomic_*.
> So I still think checking for atomic_* is better than __atomic_*. Am I
> missing something?
I think the issue is that there is no absolute relationship
between stdatomic.h and the __atomic_* functions. So the test is
currently designed from libatomic's point of view, and it might
add libatomic dependency even if stdatomic.h doesn't use the
__atomic_* functions. Then conversely, using the C11 atomic_*
instead in the test means that we would add dependency on
libatomic if it fails to link without being completely sure that
it is the missing library.
If you take the current test on its own, it doesn't claim to
cover stdatomic.h support but just libatomic dependency. So
that's why I prefer it.
But in practice, both variants (__atomic_* and C11 atomic_*) can
be used in the test with existing versions of GCC and I'm not
trying to cover Clang MIPS builds in this series. I think
there's no perfect solution here, and if you still think it makes
more sense to use the C11 atomic_* functions then fine, I can
change the test to do that instead.
Guillaume
>>> [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
>>> [2]: https://llvm.org/docs/Atomics.html
>>>
+ return 0;
+}''', name : 'built-in atomics')
+ libatomic = null_dep
+else
[Intel-gfx] ✗ Fi.CI.BAT: failure for prime doc polish and ... a few cleanups (rev6)
== Series Details == Series: prime doc polish and ... a few cleanups (rev6) URL : https://patchwork.freedesktop.org/series/62135/ State : failure == Summary == Applying: drm/todo: Update drm_gem_object_funcs todo even more Applying: drm/gem: Unexport drm_gem_(un)pin/v(un)map Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_gem.c M drivers/gpu/drm/drm_internal.h M include/drm/drm_gem.h Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/prime: Update docs error: sha1 information is lacking or useless (drivers/gpu/drm/drm_prime.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 drm/prime: Update docs When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Nuke drm_driver irq vfuncs
On Tue, Jun 18, 2019 at 03:54:01PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-06-18 15:21:07)
> [snip mechanical changes]
>
> > @@ -4839,65 +4792,18 @@ void intel_irq_init(struct drm_i915_private
> > *dev_priv)
> > dev->driver->get_vblank_timestamp =
> > drm_calc_vbltimestamp_from_scanoutpos;
> > dev->driver->get_scanout_position = i915_get_crtc_scanoutpos;
> >
> > - if (IS_CHERRYVIEW(dev_priv)) {
> > - dev->driver->irq_handler = cherryview_irq_handler;
> > - dev->driver->irq_preinstall = cherryview_irq_reset;
> > - dev->driver->irq_postinstall = cherryview_irq_postinstall;
> > - dev->driver->irq_uninstall = cherryview_irq_reset;
> > - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> > - } else if (IS_VALLEYVIEW(dev_priv)) {
> > - dev->driver->irq_handler = valleyview_irq_handler;
> > - dev->driver->irq_preinstall = valleyview_irq_reset;
> > - dev->driver->irq_postinstall = valleyview_irq_postinstall;
> > - dev->driver->irq_uninstall = valleyview_irq_reset;
> > - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> > - } else if (INTEL_GEN(dev_priv) >= 11) {
> > - dev->driver->irq_handler = gen11_irq_handler;
> > - dev->driver->irq_preinstall = gen11_irq_reset;
> > - dev->driver->irq_postinstall = gen11_irq_postinstall;
> > - dev->driver->irq_uninstall = gen11_irq_reset;
> > - dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
> > - } else if (INTEL_GEN(dev_priv) >= 8) {
> > - dev->driver->irq_handler = gen8_irq_handler;
> > - dev->driver->irq_preinstall = gen8_irq_reset;
> > - dev->driver->irq_postinstall = gen8_irq_postinstall;
> > - dev->driver->irq_uninstall = gen8_irq_reset;
> > - if (IS_GEN9_LP(dev_priv))
> > + if (HAS_GMCH(dev_priv)) {
> > + if (I915_HAS_HOTPLUG(dev_priv))
> > + dev_priv->display.hpd_irq_setup =
> > i915_hpd_irq_setup;
>
> Includes chv/vlv.
>
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + dev_priv->display.hpd_irq_setup =
> > gen11_hpd_irq_setup;
>
> Ok.
>
> > + else if (IS_GEN9_LP(dev_priv))
> > dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
> > else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
> > dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
>
> As before.
>
> > else
> > dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
>
> The rest of !GMCH.
>
> Code be one level if-chain though.
"could be ..."? Sure. Not entirely sure I'd be able to follow it though.
I guess just flattening it and checking for HAS_PCH_SPLIT() for ilk+
could be a reasonably non-confusing way to write it. Silly vlv/chv
always interfering with the mostly nice chronological order.
>
> > @@ -4918,6 +4824,75 @@ void intel_irq_fini(struct drm_i915_private *i915)
> > kfree(i915->l3_parity.remap_info[i]);
> > }
> >
> > +static irq_handler_t intel_irq_handler(struct drm_i915_private *dev_priv)
> > +{
> > + if (HAS_GMCH(dev_priv)) {
> > + if (IS_CHERRYVIEW(dev_priv))
> > + return cherryview_irq_handler;
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + return valleyview_irq_handler;
> > + else if (IS_GEN(dev_priv, 4))
> > + return i965_irq_handler;
> > + else if (IS_GEN(dev_priv, 3))
> > + return i915_irq_handler;
> > + else
> > + return i8xx_irq_handler;
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + return gen11_irq_handler;
> > + else if (INTEL_GEN(dev_priv) >= 8)
> > + return gen8_irq_handler;
> > + else
> > + return ironlake_irq_handler;
> > + }
> > +}
> > +
> > +static void intel_irq_reset(struct drm_i915_private *dev_priv)
> > +{
> > + if (HAS_GMCH(dev_priv)) {
> > + if (IS_CHERRYVIEW(dev_priv))
> > + cherryview_irq_reset(dev_priv);
> > + else if (IS_VALLEYVIEW(dev_priv))
> > + valleyview_irq_reset(dev_priv);
> > + else if (IS_GEN(dev_priv, 4))
> > + i965_irq_reset(dev_priv);
> > + else if (IS_GEN(dev_priv, 3))
> > + i915_irq_reset(dev_priv);
> > + else
> > + i8xx_irq_reset(dev_priv);
> > + } else {
> > + if (INTEL_GEN(dev_priv) >= 11)
> > + gen11_irq_reset(dev_priv);
> > +
Re: [Intel-gfx] drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Tue, Jun 18, 2019 at 05:19:38PM +0200, Greg Kroah-Hartman wrote:
> On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote:
> > Greg is busy already, but maybe he won't do everything ...
> >
> > Cc: Greg Kroah-Hartman
> > Signed-off-by: Daniel Vetter
> > ---
> > Documentation/gpu/todo.rst | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst
> > index 9717540ee28f..026e55c517e1 100644
> > --- a/Documentation/gpu/todo.rst
> > +++ b/Documentation/gpu/todo.rst
> > @@ -375,6 +375,9 @@ There's a bunch of issues with it:
> >this (together with the drm_minor->drm_device move) would allow us to
> > remove
> >debugfs_init.
> >
> > +- Drop the return code and error checking from all debugfs functions. Greg
> > KH is
> > + working on this already.
>
>
> Part of this work was to try to delete drm_debugfs_remove_files().
>
> There are only 4 files that currently still call this function:
> drivers/gpu/drm/tegra/dc.c
> drivers/gpu/drm/tegra/dsi.c
> drivers/gpu/drm/tegra/hdmi.c
> drivers/gpu/drm/tegra/sor.c
>
> For dc.c, the driver wants to add debugfs files to the struct drm_crtc
> debugfs directory. Which is fine, but it has to do some special memory
> allocation to get the debugfs callback to point not to the struct
> drm_minor pointer, but rather the drm_crtc structure.
>
> So, to remove this call, I need to remove this special memory allocation
> and to do that, I need to somehow be able to cast from drm_minor back to
> the drm_crtc structure being used in this driver. And I can't figure
> how they are related at all.
>
> Any pointers here (pun intended) would be appreciated.
>
> For the other 3 files, the situation is much the same, but I need to get
> from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer.
>
> I could just "open code" a bunch of calls to debugfs_create_file() for
> these drivers, which would solve this issue, but in a more "non-drm"
> way. Is it worth to just do that instead of overthinking the whole
> thing and trying to squish it into the drm "model" of drm debugfs calls?
An example of "open coding" this is the patch below for the sor.c
driver.
Totally untested, not even built, but you should get the idea here.
thanks,
greg k-h
---
diff --git a/drivers/gpu/drm/tegra/sor.c b/drivers/gpu/drm/tegra/sor.c
index 5be5a0817dfe..3216221c77c4 100644
--- a/drivers/gpu/drm/tegra/sor.c
+++ b/drivers/gpu/drm/tegra/sor.c
@@ -414,7 +414,8 @@ struct tegra_sor {
struct drm_dp_aux *aux;
- struct drm_info_list *debugfs_files;
+ struct dentry *debugfs_root;
+ struct drm_device *drm;
const struct tegra_sor_ops *ops;
enum tegra_io_pad pad;
@@ -1262,10 +1263,9 @@ static int tegra_sor_crc_wait(struct tegra_sor *sor,
unsigned long timeout)
static int tegra_sor_show_crc(struct seq_file *s, void *data)
{
- struct drm_info_node *node = s->private;
- struct tegra_sor *sor = node->info_ent->data;
+ struct tegra_sor *sor = s->private;
struct drm_crtc *crtc = sor->output.encoder.crtc;
- struct drm_device *drm = node->minor->dev;
+ struct drm_device *drm = sor->drm;
int err = 0;
u32 value;
@@ -1302,6 +1302,20 @@ static int tegra_sor_show_crc(struct seq_file *s, void
*data)
return err;
}
+static int crc_open(struct inode *inode, struct file *file)
+{
+ struct tegra_sor *sor = inode->i_private;
+ return single_open(file, tegra_sor_show_crc, sor);
+}
+
+static const struct file_operations crc_fops = {
+ .owner = THIS_MODULE,
+ .open = crc_open,
+ .read = seq_read,
+ .llseek = seq_lseek,
+ .release = single_release,
+};
+
#define DEBUGFS_REG32(_name) { .name = #_name, .offset = _name }
static const struct debugfs_reg32 tegra_sor_regs[] = {
@@ -1424,10 +1438,9 @@ static const struct debugfs_reg32 tegra_sor_regs[] = {
static int tegra_sor_show_regs(struct seq_file *s, void *data)
{
- struct drm_info_node *node = s->private;
- struct tegra_sor *sor = node->info_ent->data;
+ struct tegra_sor *sor = s->private;
struct drm_crtc *crtc = sor->output.encoder.crtc;
- struct drm_device *drm = node->minor->dev;
+ struct drm_device *drm = sor->drm;
unsigned int i;
int err = 0;
@@ -1450,51 +1463,44 @@ static int tegra_sor_show_regs(struct seq_file *s, void
*data)
return err;
}
-static const struct drm_info_list debugfs_files[] = {
- { "crc", tegra_sor_show_crc, 0, NULL },
- { "regs", tegra_sor_show_regs, 0, NULL },
+static int regs_open(struct inode *inode, struct file *file)
+{
+ struct tegra_sor *sor = inode->i_private;
+ return single_open(file, tegra_sor_show_regs, sor);
+}
+
+static const struct file_operations crc_fops = {
+ .owner = THIS_MODULE,
+ .open = crc_open,
+ .read = seq_read,
+ .llseek =
Re: [Intel-gfx] [PATCH 1/4] mm: Check if mmu notifier callbacks are allowed to fail
On Tue, May 21, 2019 at 11:44:11AM -0400, Jerome Glisse wrote:
> On Mon, May 20, 2019 at 11:39:42PM +0200, Daniel Vetter wrote:
> > Just a bit of paranoia, since if we start pushing this deep into
> > callchains it's hard to spot all places where an mmu notifier
> > implementation might fail when it's not allowed to.
> >
> > Inspired by some confusion we had discussing i915 mmu notifiers and
> > whether we could use the newly-introduced return value to handle some
> > corner cases. Until we realized that these are only for when a task
> > has been killed by the oom reaper.
> >
> > An alternative approach would be to split the callback into two
> > versions, one with the int return value, and the other with void
> > return value like in older kernels. But that's a lot more churn for
> > fairly little gain I think.
> >
> > Summary from the m-l discussion on why we want something at warning
> > level: This allows automated tooling in CI to catch bugs without
> > humans having to look at everything. If we just upgrade the existing
> > pr_info to a pr_warn, then we'll have false positives. And as-is, no
> > one will ever spot the problem since it's lost in the massive amounts
> > of overall dmesg noise.
> >
> > v2: Drop the full WARN_ON backtrace in favour of just a pr_warn for
> > the problematic case (Michal Hocko).
> >
> > v3: Rebase on top of Glisse's arg rework.
> >
> > v4: More rebase on top of Glisse reworking everything.
> >
> > Cc: Andrew Morton
> > Cc: Michal Hocko
> > Cc: "Christian König"
> > Cc: David Rientjes
> > Cc: Daniel Vetter
> > Cc: "Jérôme Glisse"
> > Cc: linux...@kvack.org
> > Cc: Paolo Bonzini
> > Reviewed-by: Christian König
> > Signed-off-by: Daniel Vetter
>
> Reviewed-by: Jérôme Glisse
-mm folks, is this (entire series of 4 patches) planned to land in the 5.3
merge window? Or do you want more reviews/testing/polish?
I think with all the hmm rework going on, a bit more validation and checks
in this tricky area would help.
Thanks, Daniel
>
> > ---
> > mm/mmu_notifier.c | 3 +++
> > 1 file changed, 3 insertions(+)
> >
> > diff --git a/mm/mmu_notifier.c b/mm/mmu_notifier.c
> > index ee36068077b6..c05e406a7cd7 100644
> > --- a/mm/mmu_notifier.c
> > +++ b/mm/mmu_notifier.c
> > @@ -181,6 +181,9 @@ int __mmu_notifier_invalidate_range_start(struct
> > mmu_notifier_range *range)
> > pr_info("%pS callback failed with %d in
> > %sblockable context.\n",
> > mn->ops->invalidate_range_start, _ret,
> > !mmu_notifier_range_blockable(range) ?
> > "non-" : "");
> > + if (!mmu_notifier_range_blockable(range))
> > + pr_warn("%pS callback failure not
> > allowed\n",
> > +
> > mn->ops->invalidate_range_start);
> > ret = _ret;
> > }
> > }
> > --
> > 2.20.1
> >
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] drm connectors, tegra, and the web they weave (was Re: [PATCH 58/59] drm/todo: Add new debugfs todo)
On Fri, Jun 14, 2019 at 10:36:14PM +0200, Daniel Vetter wrote: > Greg is busy already, but maybe he won't do everything ... > > Cc: Greg Kroah-Hartman > Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index 9717540ee28f..026e55c517e1 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -375,6 +375,9 @@ There's a bunch of issues with it: >this (together with the drm_minor->drm_device move) would allow us to > remove >debugfs_init. > > +- Drop the return code and error checking from all debugfs functions. Greg > KH is > + working on this already. Part of this work was to try to delete drm_debugfs_remove_files(). There are only 4 files that currently still call this function: drivers/gpu/drm/tegra/dc.c drivers/gpu/drm/tegra/dsi.c drivers/gpu/drm/tegra/hdmi.c drivers/gpu/drm/tegra/sor.c For dc.c, the driver wants to add debugfs files to the struct drm_crtc debugfs directory. Which is fine, but it has to do some special memory allocation to get the debugfs callback to point not to the struct drm_minor pointer, but rather the drm_crtc structure. So, to remove this call, I need to remove this special memory allocation and to do that, I need to somehow be able to cast from drm_minor back to the drm_crtc structure being used in this driver. And I can't figure how they are related at all. Any pointers here (pun intended) would be appreciated. For the other 3 files, the situation is much the same, but I need to get from a 'struct drm_minor' pointer to a 'struct drm_connector' pointer. I could just "open code" a bunch of calls to debugfs_create_file() for these drivers, which would solve this issue, but in a more "non-drm" way. Is it worth to just do that instead of overthinking the whole thing and trying to squish it into the drm "model" of drm debugfs calls? Either way, who can test these changes? I can't even build the tegra driver without digging up an arm64 cross-compiler, and can't test it as I have no hardware at all. thanks, greg k-h ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix various tracepoints for gen2
On Tue, Jun 18, 2019 at 03:46:29PM +0100, Chris Wilson wrote:
> Quoting Ville Syrjala (2019-06-18 15:21:06)
> > @@ -59,14 +57,13 @@ TRACE_EVENT(intel_pipe_disable,
> > ),
> >
> > TP_fast_assign(
> > - enum pipe _pipe;
> > - for_each_pipe(dev_priv, _pipe) {
> > - __entry->frame[_pipe] =
> > -
> > dev_priv->drm.driver->get_vblank_counter(_priv->drm, _pipe);
> > - __entry->scanline[_pipe] =
> > -
> > intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, _pipe));
> > + struct drm_i915_private *dev_priv =
> > to_i915(crtc->base.dev);
> > + struct intel_crtc *_crtc;
> > + for_each_intel_crtc(_priv->drm, _crtc) {
> > + __entry->frame[_crtc->pipe] =
> > intel_crtc_get_vblank_counter(_crtc);
> > + __entry->scanline[_crtc->pipe] =
> > intel_get_crtc_scanline(_crtc);
> >}
> > - __entry->pipe = pipe;
> > + __entry->pipe = crtc->pipe;
>
> Ok. Stared hard to make sure it was _crtc and not crtc. Would crtc__ be
> more obvious, or maybe it__ so that it doesn't look anything like the
> crtc argument.
I suppose a more distinct name might be a good idea.
>
> > TP_fast_assign(
> > - enum pipe pipe;
> > - for_each_pipe(dev_priv, pipe) {
> > - __entry->frame[pipe] =
> > -
> > dev_priv->drm.driver->get_vblank_counter(_priv->drm, pipe);
> > - __entry->scanline[pipe] =
> > -
> > intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, pipe));
> > + struct intel_crtc *crtc;
> > + for_each_intel_crtc(_priv->drm, crtc) {
> > + __entry->frame[crtc->pipe] =
> > intel_crtc_get_vblank_counter(crtc);
> > + __entry->scanline[crtc->pipe] =
> > intel_get_crtc_scanline(crtc);
> >}
>
> Or even a populate_vblanks(i915, __entry->frame, __entry->scanline)
>
> Reviewed-by: Chris Wilson
> -Chris
--
Ville Syrjälä
Intel
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Finish drm_driver vfunc cleanup
== Series Details == Series: drm/i915: Finish drm_driver vfunc cleanup URL : https://patchwork.freedesktop.org/series/62317/ State : failure == Summary == Applying: drm/i915: Fix various tracepoints for gen2 Applying: drm/i915: Nuke drm_driver irq vfuncs Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_irq.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_irq.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_irq.c error: Failed to merge in the changes. hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0002 drm/i915: Nuke drm_driver irq vfuncs When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 3/3] drm/i915: Initialize drm_driver vblank funcs at compile time
Quoting Ville Syrjala (2019-06-18 15:21:08)
> From: Ville Syrjälä
>
> Move the .get_vblank_timestamp() and .get_scanout_position()
> initialization to happen at compile time. No point in delaying
> it since we always assign the same functions.
>
> Signed-off-by: Ville Syrjälä
> ---
> drivers/gpu/drm/i915/i915_drv.c | 3 +++
> drivers/gpu/drm/i915/i915_irq.c | 11 ---
> drivers/gpu/drm/i915/i915_irq.h | 5 +
> 3 files changed, 12 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index ea6b06109d5a..178e9872b905 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -3216,6 +3216,9 @@ static struct drm_driver driver = {
> .gem_prime_export = i915_gem_prime_export,
> .gem_prime_import = i915_gem_prime_import,
>
> + .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos,
> + .get_scanout_position = i915_get_crtc_scanoutpos,
One might suggest intel_get_crtc_scanoutpos, and a push for it to be
passed drm_crtc instead of dev + pipe.
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/3] drm/i915: Nuke drm_driver irq vfuncs
Quoting Ville Syrjala (2019-06-18 15:21:07)
[snip mechanical changes]
> @@ -4839,65 +4792,18 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
> dev->driver->get_vblank_timestamp =
> drm_calc_vbltimestamp_from_scanoutpos;
> dev->driver->get_scanout_position = i915_get_crtc_scanoutpos;
>
> - if (IS_CHERRYVIEW(dev_priv)) {
> - dev->driver->irq_handler = cherryview_irq_handler;
> - dev->driver->irq_preinstall = cherryview_irq_reset;
> - dev->driver->irq_postinstall = cherryview_irq_postinstall;
> - dev->driver->irq_uninstall = cherryview_irq_reset;
> - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> - } else if (IS_VALLEYVIEW(dev_priv)) {
> - dev->driver->irq_handler = valleyview_irq_handler;
> - dev->driver->irq_preinstall = valleyview_irq_reset;
> - dev->driver->irq_postinstall = valleyview_irq_postinstall;
> - dev->driver->irq_uninstall = valleyview_irq_reset;
> - dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
> - } else if (INTEL_GEN(dev_priv) >= 11) {
> - dev->driver->irq_handler = gen11_irq_handler;
> - dev->driver->irq_preinstall = gen11_irq_reset;
> - dev->driver->irq_postinstall = gen11_irq_postinstall;
> - dev->driver->irq_uninstall = gen11_irq_reset;
> - dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
> - } else if (INTEL_GEN(dev_priv) >= 8) {
> - dev->driver->irq_handler = gen8_irq_handler;
> - dev->driver->irq_preinstall = gen8_irq_reset;
> - dev->driver->irq_postinstall = gen8_irq_postinstall;
> - dev->driver->irq_uninstall = gen8_irq_reset;
> - if (IS_GEN9_LP(dev_priv))
> + if (HAS_GMCH(dev_priv)) {
> + if (I915_HAS_HOTPLUG(dev_priv))
> + dev_priv->display.hpd_irq_setup = i915_hpd_irq_setup;
Includes chv/vlv.
> + } else {
> + if (INTEL_GEN(dev_priv) >= 11)
> + dev_priv->display.hpd_irq_setup = gen11_hpd_irq_setup;
Ok.
> + else if (IS_GEN9_LP(dev_priv))
> dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
> else if (INTEL_PCH_TYPE(dev_priv) >= PCH_SPT)
> dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
As before.
> else
> dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
The rest of !GMCH.
Code be one level if-chain though.
> @@ -4918,6 +4824,75 @@ void intel_irq_fini(struct drm_i915_private *i915)
> kfree(i915->l3_parity.remap_info[i]);
> }
>
> +static irq_handler_t intel_irq_handler(struct drm_i915_private *dev_priv)
> +{
> + if (HAS_GMCH(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv))
> + return cherryview_irq_handler;
> + else if (IS_VALLEYVIEW(dev_priv))
> + return valleyview_irq_handler;
> + else if (IS_GEN(dev_priv, 4))
> + return i965_irq_handler;
> + else if (IS_GEN(dev_priv, 3))
> + return i915_irq_handler;
> + else
> + return i8xx_irq_handler;
> + } else {
> + if (INTEL_GEN(dev_priv) >= 11)
> + return gen11_irq_handler;
> + else if (INTEL_GEN(dev_priv) >= 8)
> + return gen8_irq_handler;
> + else
> + return ironlake_irq_handler;
> + }
> +}
> +
> +static void intel_irq_reset(struct drm_i915_private *dev_priv)
> +{
> + if (HAS_GMCH(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv))
> + cherryview_irq_reset(dev_priv);
> + else if (IS_VALLEYVIEW(dev_priv))
> + valleyview_irq_reset(dev_priv);
> + else if (IS_GEN(dev_priv, 4))
> + i965_irq_reset(dev_priv);
> + else if (IS_GEN(dev_priv, 3))
> + i915_irq_reset(dev_priv);
> + else
> + i8xx_irq_reset(dev_priv);
> + } else {
> + if (INTEL_GEN(dev_priv) >= 11)
> + gen11_irq_reset(dev_priv);
> + else if (INTEL_GEN(dev_priv) >= 8)
> + gen8_irq_reset(dev_priv);
> + else
> + ironlake_irq_reset(dev_priv);
> + }
> +}
> +
> +static void intel_irq_postinstall(struct drm_i915_private *dev_priv)
> +{
> + if (HAS_GMCH(dev_priv)) {
> + if (IS_CHERRYVIEW(dev_priv))
> + cherryview_irq_postinstall(dev_priv);
> + else if (IS_VALLEYVIEW(dev_priv))
> + valleyview_irq_postinstall(dev_priv);
> + else
[Intel-gfx] ✗ Fi.CI.BAT: failure for prime doc polish and ... a few cleanups (rev5)
== Series Details == Series: prime doc polish and ... a few cleanups (rev5) URL : https://patchwork.freedesktop.org/series/62135/ State : failure == Summary == Applying: drm/todo: Update drm_gem_object_funcs todo even more Applying: drm/gem: Unexport drm_gem_(un)pin/v(un)map Using index info to reconstruct a base tree... M drivers/gpu/drm/drm_gem.c M drivers/gpu/drm/drm_internal.h M include/drm/drm_gem.h Falling back to patching base and 3-way merge... No changes -- Patch already applied. Applying: drm/prime: Update docs error: sha1 information is lacking or useless (drivers/gpu/drm/drm_prime.c). error: could not build fake ancestor hint: Use 'git am --show-current-patch' to see the failed patch Patch failed at 0003 drm/prime: Update docs When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Fix various tracepoints for gen2
Quoting Ville Syrjala (2019-06-18 15:21:06)
> @@ -59,14 +57,13 @@ TRACE_EVENT(intel_pipe_disable,
> ),
>
> TP_fast_assign(
> - enum pipe _pipe;
> - for_each_pipe(dev_priv, _pipe) {
> - __entry->frame[_pipe] =
> -
> dev_priv->drm.driver->get_vblank_counter(_priv->drm, _pipe);
> - __entry->scanline[_pipe] =
> -
> intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, _pipe));
> + struct drm_i915_private *dev_priv =
> to_i915(crtc->base.dev);
> + struct intel_crtc *_crtc;
> + for_each_intel_crtc(_priv->drm, _crtc) {
> + __entry->frame[_crtc->pipe] =
> intel_crtc_get_vblank_counter(_crtc);
> + __entry->scanline[_crtc->pipe] =
> intel_get_crtc_scanline(_crtc);
>}
> - __entry->pipe = pipe;
> + __entry->pipe = crtc->pipe;
Ok. Stared hard to make sure it was _crtc and not crtc. Would crtc__ be
more obvious, or maybe it__ so that it doesn't look anything like the
crtc argument.
> TP_fast_assign(
> - enum pipe pipe;
> - for_each_pipe(dev_priv, pipe) {
> - __entry->frame[pipe] =
> -
> dev_priv->drm.driver->get_vblank_counter(_priv->drm, pipe);
> - __entry->scanline[pipe] =
> -
> intel_get_crtc_scanline(intel_get_crtc_for_pipe(dev_priv, pipe));
> + struct intel_crtc *crtc;
> + for_each_intel_crtc(_priv->drm, crtc) {
> + __entry->frame[crtc->pipe] =
> intel_crtc_get_vblank_counter(crtc);
> + __entry->scanline[crtc->pipe] =
> intel_get_crtc_scanline(crtc);
>}
Or even a populate_vblanks(i915, __entry->frame, __entry->scanline)
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 i-g-t v3 1/4] meson: add libatomic dependency
On Tue, 2019-06-18 at 14:59 +0100, Guillaume Tucker wrote:
> On 18/06/2019 14:20, Ser, Simon wrote:
> > On Tue, 2019-06-18 at 13:27 +0100, Guillaume Tucker wrote:
> > > Add conditional dependency on libatomic in order to be able to use the
> > > __atomic_* functions instead of the older __sync_* ones. The
> > > libatomic library is only needed when there aren't any native support
> > > on the current architecture, so a linker test is used for this
> > > purpose. This enables atomic operations to be on a wider number of
> > > architectures including MIPS.
> > >
> > > Signed-off-by: Guillaume Tucker
> > > ---
> > >
> > > Notes:
> > > v2: add linker test for libatomic
> > > v3: use null_dep
> > >
> > > meson.build | 14 ++
> > > 1 file changed, 14 insertions(+)
> > >
> > > diff --git a/meson.build b/meson.build
> > > index 6268c58d3634..118ad667ffb5 100644
> > > --- a/meson.build
> > > +++ b/meson.build
> > > @@ -180,6 +180,20 @@ realtime = cc.find_library('rt')
> > > dlsym = cc.find_library('dl')
> > > zlib = cc.find_library('z')
> > >
> > > +if cc.links('''
> > > +#include
> > > +int main(void) {
> > > + uint32_t x32 = 0;
> > > + uint64_t x64 = 0;
> > > + __atomic_load_n(, __ATOMIC_SEQ_CST);
> > > + __atomic_load_n(, __ATOMIC_SEQ_CST);
> >
> > See my reply for v2. I've looked into this a little bit more and it
> > looks like __atomic_* functions are a GCC implementation detail. OIn
> > other words, the C11 standard [1] defines only atomic_* functions, and
> > GCC implements them with __atomic_* builtins when the platform supports
> > it, but other compilers might not expose those builtins and still
> > support atomic_* functions without them. This also seems to be what [2]
> > explains:
> >
> > > The first set of library functions are named __atomic_*. This set has
> > > been “standardized” by GCC, and is described below. (See also GCC’s
> > > documentation)
> >
> > (Notice the quotes around “standardized”, meaning they are a GCC
> > extension)
>
> Quite, and while the stdatomic.h API is part of the C11 standard,
> libatomic is part of GCC. So this test is to determine whether
> linking against GCC's libatomic.so is needed for its __atomic_*
> fallback implementation.
>
> It raises the question of what to do with other compilers, but
> igt has other build errors with clang on mips at the moment.
> With a quick search, it looks like its __atomic_* functions are
> part of libclang.so for clang.
I don't see anything in `readelf -s /usr/lib/libclang.so.8`.
> Maybe this test should only be used when the compiler name is
> gcc? In practice it does work with both gcc and clang though, as
> they both use the same naming convention for atomic built-ins.
Hmm. I'm still not quite sure I understand why checking with __atomic_*
is preferred.
- If the compiler has __atomic_* builtins: this won't link with
libatomic
- If the compiler doesn't have __atomic_* builtins: this will link with
libatomic even if stdatomic.h works without it
What we're really interested in is stdatomic.h support, not __atomic_*.
So I still think checking for atomic_* is better than __atomic_*. Am I
missing something?
> Guillaume
>
> > [1]: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1548.pdf
> > [2]: https://llvm.org/docs/Atomics.html
> >
> > > + return 0;
> > > +}''', name : 'built-in atomics')
> > > + libatomic = null_dep
> > > +else
> > > + libatomic = cc.find_library('atomic')
> > > +endif
> > > +
> > > if cc.has_header('linux/kd.h')
> > > config.set('HAVE_LINUX_KD_H', 1)
> > > endif
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/ehl: Allow combo PHY A to drive a third external display (rev2)
== Series Details == Series: drm/i915/ehl: Allow combo PHY A to drive a third external display (rev2) URL : https://patchwork.freedesktop.org/series/62131/ State : failure == Summary == CI Bug Log - changes from CI_DRM_6289_full -> Patchwork_13318_full Summary --- **FAILURE** Serious unknown changes coming with Patchwork_13318_full absolutely need to be verified manually. If you think the reported changes have nothing to do with the changes introduced in Patchwork_13318_full, please notify your bug team to allow them to document this new failure mode, which will reduce false positives in CI. Possible new issues --- Here are the unknown changes that may have been introduced in Patchwork_13318_full: ### IGT changes ### Possible regressions * igt@gem_ctx_switch@basic-queue-light: - shard-apl: [PASS][1] -> [FAIL][2] [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-apl6/igt@gem_ctx_swi...@basic-queue-light.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-apl1/igt@gem_ctx_swi...@basic-queue-light.html Known issues Here are the changes found in Patchwork_13318_full that come from known issues: ### IGT changes ### Issues hit * igt@gem_persistent_relocs@forked-interruptible-faulting-reloc-thrashing: - shard-apl: [PASS][3] -> [DMESG-WARN][4] ([fdo#110913 ]) +1 similar issue [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-apl7/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-apl3/igt@gem_persistent_rel...@forked-interruptible-faulting-reloc-thrashing.html * igt@gem_userptr_blits@map-fixed-invalidate-busy-gup: - shard-snb: [PASS][5] -> [DMESG-WARN][6] ([fdo#110913 ]) +1 similar issue [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-snb5/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-snb1/igt@gem_userptr_bl...@map-fixed-invalidate-busy-gup.html * igt@gem_workarounds@suspend-resume-context: - shard-skl: [PASS][7] -> [INCOMPLETE][8] ([fdo#104108]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-skl3/igt@gem_workarou...@suspend-resume-context.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-skl8/igt@gem_workarou...@suspend-resume-context.html * igt@kms_cursor_crc@pipe-c-cursor-suspend: - shard-apl: [PASS][9] -> [DMESG-WARN][10] ([fdo#108566]) +2 similar issues [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-apl5/igt@kms_cursor_...@pipe-c-cursor-suspend.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-apl5/igt@kms_cursor_...@pipe-c-cursor-suspend.html * igt@kms_cursor_legacy@cursor-vs-flip-toggle: - shard-hsw: [PASS][11] -> [FAIL][12] ([fdo#103355]) [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-hsw7/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-hsw5/igt@kms_cursor_leg...@cursor-vs-flip-toggle.html * igt@kms_flip@2x-flip-vs-dpms-off-vs-modeset: - shard-hsw: [PASS][13] -> [SKIP][14] ([fdo#109271]) +35 similar issues [13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-hsw7/igt@kms_f...@2x-flip-vs-dpms-off-vs-modeset.html [14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-hsw1/igt@kms_f...@2x-flip-vs-dpms-off-vs-modeset.html * igt@kms_frontbuffer_tracking@fbc-1p-primscrn-shrfb-msflip-blt: - shard-iclb: [PASS][15] -> [FAIL][16] ([fdo#103167]) +5 similar issues [15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-iclb7/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html [16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-iclb8/igt@kms_frontbuffer_track...@fbc-1p-primscrn-shrfb-msflip-blt.html * igt@kms_frontbuffer_tracking@fbc-suspend: - shard-kbl: [PASS][17] -> [DMESG-WARN][18] ([fdo#108566]) +2 similar issues [17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-kbl7/igt@kms_frontbuffer_track...@fbc-suspend.html [18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-kbl6/igt@kms_frontbuffer_track...@fbc-suspend.html * igt@kms_frontbuffer_tracking@fbcpsr-suspend: - shard-iclb: [PASS][19] -> [INCOMPLETE][20] ([fdo#106978] / [fdo#107713]) [19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6289/shard-iclb2/igt@kms_frontbuffer_track...@fbcpsr-suspend.html [20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13318/shard-iclb3/igt@kms_frontbuffer_track...@fbcpsr-suspend.html * igt@kms_psr@no_drrs: - shard-iclb:
[Intel-gfx] ✓ Fi.CI.BAT: success for Implicit dev_priv removal and GT compartmentalization (rev10)
== Series Details == Series: Implicit dev_priv removal and GT compartmentalization (rev10) URL : https://patchwork.freedesktop.org/series/62046/ State : success == Summary == CI Bug Log - changes from CI_DRM_6291 -> Patchwork_13327 Summary --- **SUCCESS** No regressions found. External URL: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/ Known issues Here are the changes found in Patchwork_13327 that come from known issues: ### IGT changes ### Issues hit * igt@gem_basic@create-fd-close: - fi-icl-u3: [PASS][1] -> [DMESG-WARN][2] ([fdo#107724]) [1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u3/igt@gem_ba...@create-fd-close.html [2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/fi-icl-u3/igt@gem_ba...@create-fd-close.html * igt@gem_ctx_switch@basic-default: - fi-icl-guc: [PASS][3] -> [INCOMPLETE][4] ([fdo#107713] / [fdo#108569]) [3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html [4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/fi-icl-guc/igt@gem_ctx_swi...@basic-default.html * igt@gem_render_tiled_blits@basic: - fi-icl-dsi: [PASS][5] -> [INCOMPLETE][6] ([fdo#107713]) [5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-dsi/igt@gem_render_tiled_bl...@basic.html [6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/fi-icl-dsi/igt@gem_render_tiled_bl...@basic.html * igt@i915_selftest@live_evict: - fi-bsw-kefka: [PASS][7] -> [DMESG-WARN][8] ([fdo#107709]) [7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-bsw-kefka/igt@i915_selftest@live_evict.html [8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/fi-bsw-kefka/igt@i915_selftest@live_evict.html * igt@i915_selftest@live_hangcheck: - fi-icl-u2: [PASS][9] -> [INCOMPLETE][10] ([fdo#107713] / [fdo#108569]) [9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u2/igt@i915_selftest@live_hangcheck.html [10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/fi-icl-u2/igt@i915_selftest@live_hangcheck.html Possible fixes * igt@gem_mmap_gtt@basic-short: - fi-icl-u3: [DMESG-WARN][11] ([fdo#107724]) -> [PASS][12] +2 similar issues [11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_6291/fi-icl-u3/igt@gem_mmap_...@basic-short.html [12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_13327/fi-icl-u3/igt@gem_mmap_...@basic-short.html [fdo#107709]: https://bugs.freedesktop.org/show_bug.cgi?id=107709 [fdo#107713]: https://bugs.freedesktop.org/show_bug.cgi?id=107713 [fdo#107724]: https://bugs.freedesktop.org/show_bug.cgi?id=107724 [fdo#108569]: https://bugs.freedesktop.org/show_bug.cgi?id=108569 Participating hosts (48 -> 37) -- Missing(11): fi-kbl-soraka fi-cml-u2 fi-ilk-m540 fi-hsw-4200u fi-byt-squawks fi-bsw-cyan fi-ctg-p8600 fi-icl-y fi-byt-clapper fi-bdw-samus fi-cml-u Build changes - * Linux: CI_DRM_6291 -> Patchwork_13327 CI_DRM_6291: 30a8dd688b1e9b56df650976b5058da5022dcfb8 @ git://anongit.freedesktop.org/gfx-ci/linux IGT_5059: 1f67ee0d09d6513f487f2be74aae9700e755258a @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools Patchwork_13327: a3880faf715d9f2ff81305b8eda3416d2d6d52f0 @ git://anongit.freedesktop.org/gfx-ci/linux == Linux commits == a3880faf715d drm/i915: Eliminate dual personality of i915_scratch_offset 5fdd0de3e9c2 drm/i915: Rename i915_timeline to intel_timeline and move under gt 815d5cee0e92 drm/i915: Make timelines gt centric 6a9e93ca185f drm/i915: Save trip via top-level i915 in a few more places 07be710c7ea7 drm/i915: Compartmentalize ring buffer creation a41381ff2d46 drm/i915: Store ggtt pointer in intel_gt e489e26404f5 drm/i915: Compartmentalize i915_gem_init_ggtt 8636df9732b4 drm/i915: Compartmentalize i915_ggtt_cleanup_hw f372a23f4974 drm/i915: Compartmentalize timeline_init/park/fini c8c04454a823 drm/i915: Move i915_gem_chipset_flush to intel_gt 07c9d8087a95 drm/i915: Convert i915_gem_flush_ggtt_writes to intel_gt 24acd770b767 drm/i915: Compartmentalize i915_gem_suspend/restore_gtt_mappings 055d3fb75c5f drm/i915: Store intel_gt backpointer in vm e0833e28d33d drm/i915: Make ggtt invalidation work on ggtt 0d15597ed258 drm/i915: Compartmentalize i915_ggtt_init_hw 17c76b182987 drm/i915: Compartmentalize i915_ggtt_probe_hw 80ee8d9d5c4b drm/i915: Stop using I915_READ/WRITE in intel_wopcm_init_hw 1e57741313db drm/i915: Move intel_engines_resume into common init 5902c532fa2a drm/i915: Convert i915_gem_init_hw to intel_gt d7c5ee7bc99b drm/i915: Consolidate some open coded mmio rmw b5ca0f164fd4 drm/i915: Convert i915_ppgtt_init_hw to intel_gt 12a8ade3b29f drm/i915: Convert intel_mocs_init_l3cc_table to intel_gt 61ee04e3470b drm/i915: Store backpointer to
