Re: [Intel-gfx] [PATCH 02/12] drm: Add DP last received PSR SDP VSC register and bits
On Thu, Mar 22, 2018 at 05:59:16PM -0700, Souza, Jose wrote: > On Thu, 2018-03-22 at 16:23 -0700, Rodrigo Vivi wrote: > > On Thu, Mar 22, 2018 at 02:48:38PM -0700, José Roberto de Souza > > wrote: > > > This is a register to help debug what is in the last SDP VSC > > > packet revived by sink. > > > > > > Signed-off-by: José Roberto de Souza > > > > > > Reviewed-by: Rodrigo Vivi > > > > (just looking to 1.4b one, but the versions on the comments seems > > right) > > Thanks, I had sent this 2 ones to dri-devel directly, better give the > Reviewed-by over there? https://patchwork.freedesktop.org/series/40512/ Oh, I hadn't noticed they were disconnected. On cases like you could have cc'ed dri-devel on the series. So it gets clear when we ask for drm maintainer ack to merge on drm-intel that we have dependency on that patch. Right now I think you can split this series with the already reviewed-by series. Include my rv-b on these first two already and resend it here cc'ing dri-devel. So we ask ack there, and get ci results and already push those to dinq. Thanks, Rodrigo. > > > > > > --- > > > include/drm/drm_dp_helper.h | 9 + > > > 1 file changed, 9 insertions(+) > > > > > > diff --git a/include/drm/drm_dp_helper.h > > > b/include/drm/drm_dp_helper.h > > > index 0bac0c7d0dec..91c9bcd4196f 100644 > > > --- a/include/drm/drm_dp_helper.h > > > +++ b/include/drm/drm_dp_helper.h > > > @@ -795,6 +795,15 @@ > > > # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK (0xf > > > << 4) > > > # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT4 > > > > > > +#define DP_LAST_RECEIVED_PSR_SDP 0x200a /* eDP 1.2 */ > > > +# define DP_PSR_STATE_BIT(1 << 0) /* eDP 1.2 > > > */ > > > +# define DP_UPDATE_RFB_BIT (1 << 1) /* eDP 1.2 > > > */ > > > +# define DP_CRC_VALID_BIT(1 << 2) /* eDP 1.2 > > > */ > > > +# define DP_SU_VALID (1 << 3) /* eDP > > > 1.4 */ > > > +# define DP_FIRST_SCAN_LINE_SU_REGION(1 << 4) /* eDP > > > 1.4 */ > > > +# define DP_LAST_SCAN_LINE_SU_REGION (1 << 5) /* eDP > > > 1.4 */ > > > +# define DP_Y_COORDINATE_VALID (1 << 6) /* eDP > > > 1.4a */ > > > + > > > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP > > > 1.4 */ > > > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > > > > > -- > > > 2.16.2 > > > > > > ___ > > > 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: success for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev4)
== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev4) URL : https://patchwork.freedesktop.org/series/39979/ State : success == Summary == Known issues: Test kms_cursor_legacy: Subgroup 2x-long-flip-vs-cursor-atomic: fail -> PASS (shard-hsw) fdo#104873 Test kms_flip: Subgroup plain-flip-ts-check-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Test kms_sysfs_edid_timing: pass -> WARN (shard-apl) fdo#100047 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (shard-apl) fdo#104008 fdo#104873 https://bugs.freedesktop.org/show_bug.cgi?id=104873 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 shard-apltotal:3484 pass:1819 dwarn:1 dfail:0 fail:8 skip:1655 time:13065s shard-hswtotal:3484 pass:1773 dwarn:1 dfail:0 fail:2 skip:1707 time:11825s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7232s Blacklisted hosts: shard-kbltotal:3484 pass:1943 dwarn:1 dfail:0 fail:9 skip:1531 time:9960s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8462/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
On 2018.03.22 21:31:33 +, Chris Wilson wrote: > Quoting Gustavo A. R. Silva (2018-03-22 18:21:54) > > The checks are misleading and not required [1]. > > > > [1] https://lkml.org/lkml/2018/3/19/1792 > > > > Addresses-Coverity-ID: 1466017 > > Cc: Chris Wilson > > Signed-off-by: Gustavo A. R. Silva > Reviewed-by: Chris Wilson > Looks good to me, I will pick this up, thanks! -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827 signature.asc Description: PGP signature ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for ICL PLLs, DP/HDMI and misc display (rev4)
== Series Details == Series: ICL PLLs, DP/HDMI and misc display (rev4) URL : https://patchwork.freedesktop.org/series/38737/ State : failure == Summary == Applying: drm/i915/icl: add basic support for the ICL clocks Applying: drm/i915/icl: add basic support for the ICL clocks error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_debugfs.c M drivers/gpu/drm/i915/intel_ddi.c M drivers/gpu/drm/i915/intel_display.c M drivers/gpu/drm/i915/intel_dpll_mgr.c M drivers/gpu/drm/i915/intel_dpll_mgr.h M drivers/gpu/drm/i915/intel_drv.h Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/intel_display.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_display.c Auto-merging drivers/gpu/drm/i915/intel_ddi.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/intel_ddi.c Patch failed at 0002 drm/i915/icl: add basic support for the ICL clocks The copy of the patch that failed is found in: .git/rebase-apply/patch 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 02/12] drm: Add DP last received PSR SDP VSC register and bits
On Thu, 2018-03-22 at 16:23 -0700, Rodrigo Vivi wrote: > On Thu, Mar 22, 2018 at 02:48:38PM -0700, José Roberto de Souza > wrote: > > This is a register to help debug what is in the last SDP VSC > > packet revived by sink. > > > > Signed-off-by: José Roberto de Souza > > > Reviewed-by: Rodrigo Vivi > > (just looking to 1.4b one, but the versions on the comments seems > right) Thanks, I had sent this 2 ones to dri-devel directly, better give the Reviewed-by over there? https://patchwork.freedesktop.org/series/40512/ > > > --- > > include/drm/drm_dp_helper.h | 9 + > > 1 file changed, 9 insertions(+) > > > > diff --git a/include/drm/drm_dp_helper.h > > b/include/drm/drm_dp_helper.h > > index 0bac0c7d0dec..91c9bcd4196f 100644 > > --- a/include/drm/drm_dp_helper.h > > +++ b/include/drm/drm_dp_helper.h > > @@ -795,6 +795,15 @@ > > # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK (0xf > > << 4) > > # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT 4 > > > > +#define DP_LAST_RECEIVED_PSR_SDP 0x200a /* eDP 1.2 */ > > +# define DP_PSR_STATE_BIT (1 << 0) /* eDP 1.2 > > */ > > +# define DP_UPDATE_RFB_BIT (1 << 1) /* eDP 1.2 > > */ > > +# define DP_CRC_VALID_BIT (1 << 2) /* eDP 1.2 > > */ > > +# define DP_SU_VALID (1 << 3) /* eDP > > 1.4 */ > > +# define DP_FIRST_SCAN_LINE_SU_REGION (1 << 4) /* eDP > > 1.4 */ > > +# define DP_LAST_SCAN_LINE_SU_REGION (1 << 5) /* eDP > > 1.4 */ > > +# define DP_Y_COORDINATE_VALID (1 << 6) /* eDP > > 1.4a */ > > + > > #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP > > 1.4 */ > > # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) > > > > -- > > 2.16.2 > > > > ___ > > 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.BAT: success for series starting with [v2,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes
== Series Details == Series: series starting with [v2,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes URL : https://patchwork.freedesktop.org/series/40541/ State : success == Summary == Series 40541v1 series starting with [v2,1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes https://patchwork.freedesktop.org/api/1.0/series/40541/revisions/1/mbox/ Known issues: Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: pass -> FAIL (fi-gdg-551) fdo#102575 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:432s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:380s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:537s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:518s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:514s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:525s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:505s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:413s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:544s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:404s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:425s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:471s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:472s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:513s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:656s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:440s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:531s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:506s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:502s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:431s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:570s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:400s fi-cfl-s3 failed to connect after reboot 9e3f06af248708774c765efd55bf8e883f24fbfd drm-tip: 2018y-03m-22d-21h-17m-42s UTC integration manifest cae0ed0df19d HAX enable guc for CI ffb01eb37c38 drm/i915: Add code to accept valid locked WOPCM register values 60d168f40fdf drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register a8e8acf9f558 drm/i915: Always do WOPCM partitioning based on real firmware sizes == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8463/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/12] drm/i915/psr: Nuke aux frame sync
On Thu, 2018-03-22 at 15:57 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:39PM -0700, José Roberto de Souza
> wrote:
> > Without GTC enabled hardware is sending dummy aux frame sync value
> > that is not useful to sink do selective update, that is why it also
> > require that sink supports and requires the y-coordinate.
> >
> > So removing everything related to aux frame sync, if GTC is enabled
> > we can bring this back.
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
>
> Cc: Vathsala Nagaraju
>
> > Signed-off-by: José Roberto de Souza
>
> Acked-by: Rodrigo Vivi
> (but I would like to give a time for Vathsala to comment on this)
Okay, I will wait Vathsala comments to send another version.
Thanks
>
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 -
> > drivers/gpu/drm/i915/intel_psr.c | 23 +--
> > 2 files changed, 1 insertion(+), 23 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index c9c3b2ba6a86..7fe00509e51a 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -602,7 +602,6 @@ struct i915_psr {
> > struct delayed_work work;
> > unsigned busy_frontbuffer_bits;
> > bool psr2_support;
> > - bool aux_frame_sync;
> > bool link_standby;
> > bool y_cord_support;
> > bool colorimetry_support;
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index b8e083e10029..d46320a451d9 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -137,16 +137,9 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> >
> > if (INTEL_GEN(dev_priv) >= 9 &&
> > (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > - uint8_t frame_sync_cap;
> >
> > dev_priv->psr.sink_support = true;
> > - if (drm_dp_dpcd_readb(&intel_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_SYN
> > C_CAP,
> > - &frame_sync_cap) != 1)
> > - frame_sync_cap = 0;
> > - dev_priv->psr.aux_frame_sync = frame_sync_cap &
> > DP_AUX_FRAME_SYNC_CAP;
> > - /* PSR2 needs frame sync as well */
> > - dev_priv->psr.psr2_support = dev_priv-
> > >psr.aux_frame_sync;
> > + dev_priv->psr.psr2_support = true;
> > DRM_DEBUG_KMS("PSR2 %s on sink",
> > dev_priv->psr.psr2_support ?
> > "supported" : "not supported");
> >
> > @@ -269,11 +262,6 @@ static void hsw_psr_enable_sink(struct
> > intel_dp *intel_dp)
> > struct drm_i915_private *dev_priv = to_i915(dev);
> >
> >
> > - /* Enable AUX frame sync at sink */
> > - if (dev_priv->psr.aux_frame_sync)
> > - drm_dp_dpcd_writeb(&intel_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF
> > ,
> > - DP_AUX_FRAME_SYNC_ENABLE);
> > /* Enable ALPM at sink for psr2 */
> > if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
> > drm_dp_dpcd_writeb(&intel_dp->aux,
> > @@ -712,11 +700,6 @@ static void hsw_psr_disable(struct intel_dp
> > *intel_dp,
> > i915_reg_t psr_status;
> > u32 psr_status_mask;
> >
> > - if (dev_priv->psr.aux_frame_sync)
> > - drm_dp_dpcd_writeb(&intel_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_S
> > YNC_CONF,
> > - 0);
> > -
> > if (dev_priv->psr.psr2_support) {
> > psr_status = EDP_PSR2_STATUS;
> > psr_status_mask =
> > EDP_PSR2_STATUS_STATE_MASK;
> > @@ -860,10 +843,6 @@ static void intel_psr_exit(struct
> > drm_i915_private *dev_priv)
> > return;
> >
> > if (HAS_DDI(dev_priv)) {
> > - if (dev_priv->psr.aux_frame_sync)
> > - drm_dp_dpcd_writeb(&intel_dp->aux,
> > - DP_SINK_DEVICE_AUX_FRAME_S
> > YNC_CONF,
> > - 0);
> > if (dev_priv->psr.psr2_support) {
> > val = I915_READ(EDP_PSR2_CTL);
> > WARN_ON(!(val & EDP_PSR2_ENABLE));
> > --
> > 2.16.2
> >
> > ___
> > 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 12/12] drm/i915/debugfs: Print how many blocks were sent in a selective update
On Thu, 2018-03-22 at 16:46 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:48PM -0700, José Roberto de Souza
> wrote:
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 40
> > -
> > drivers/gpu/drm/i915/i915_reg.h | 17
> > 2 files changed, 56 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 3182e9a7cc5d..20985584cc0f 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2678,6 +2678,43 @@ static void psr_event_exit_sprintf(struct
> > seq_file *m, u32 val,
> > seq_puts(m, "\tPSR disabled\n");
> > }
> >
> > +static void psr2_su_blocks_sprintf(struct seq_file *m,
> > + struct drm_i915_private
> > *dev_priv)
> > +{
> > + u32 val;
> > + u16 su;
> > +
> > + val = I915_READ(EDP_PSR2_SU_STATUS);
> > + su = val >>
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N: %d\n", su);
> > + su = val >>
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_1_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-1: %d\n", su);
> > + su = val >>
> > EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_2_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-2: %d\n", su);
> > +
> > + val = I915_READ(EDP_PSR2_SU_STATUS2);
> > + su = val >>
> > EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_3_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-3: %d\n", su);
> > + su = val >>
> > EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_4_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-4: %d\n", su);
> > + su = val >>
> > EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_5_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-5: %d\n", su);
> > +
> > + val = I915_READ(EDP_PSR2_SU_STATUS3);
> > + su = val >>
> > EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_6_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-6: %d\n", su);
> > + su = val >>
> > EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_7_SHIFT;
> > + su &= EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK;
> > + seq_printf(m, "\tSU blocks in frame N-7: %d\n", su);
> > +}
> > +
> > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -2766,8 +2803,9 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > if (dev_priv->psr.psr2_enabled) {
> > u32 psr2 = I915_READ(EDP_PSR2_STATUS);
> >
> > - seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> > + seq_printf(m, "EDP_PSR2_STATUS: 0x%x [%s]\n",
> >psr2, psr2_live_status(psr2));
> > + psr2_su_blocks_sprintf(m, dev_priv);
> > }
> >
> > if (dev_priv->psr.enabled) {
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 45f7703a9ee6..18af3e8fd4b6 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -3929,6 +3929,23 @@ enum {
> > #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> > #define EDP_PSR2_STATUS_STATE_SHIFT28
> >
> > +#define EDP_PSR2_SU_STATUS
> > _MMIO(0x6F914)
> > +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK
> > 0x3FF
> > +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_SHIFT
> > 0
> > +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_1_SHIFT
> > 10
> > +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_2_SHIFT
> > 20
> > +
> > +#define EDP_PSR2_SU_STATUS2
> > _MMIO(0x6F918)
> > +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK
> > 0x3FF
> > +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_3_SHIFT
> > 0
> > +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_4_SHIFT
> > 10
> > +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_5_SHIFT
> > 20
> > +
> > +#define EDP_PSR2_SU_STATUS3
> > _MMIO(0x6F91C)
> > +#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK
> > 0x3FF
> > +#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_6_SHIFT
> > 0
> > +#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_7_SHIFT
> > 10
> > +
>
> Couldn't we define it unified as:
> +#define EDP_PSR2_SU_STATUS(frame)
Re: [Intel-gfx] linux-next: manual merge of the drm-intel tree with Linus' tree
Hi all,
On Thu, 22 Mar 2018 13:21:29 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-intel tree got a conflict in:
>
> drivers/gpu/drm/i915/gvt/scheduler.c
>
> between commit:
>
> fa3dd623e559 ("drm/i915/gvt: keep oa config in shadow ctx")
>
> from Linus' tree and commit:
>
> b20c0d5ce104 ("drm/i915/gvt: Update PDPs after a vGPU mm object is pinned.")
>
> from the drm-intel tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/i915/gvt/scheduler.c
> index 068126404151,a55b4975c154..
> --- a/drivers/gpu/drm/i915/gvt/scheduler.c
> +++ b/drivers/gpu/drm/i915/gvt/scheduler.c
> @@@ -52,54 -52,29 +52,77 @@@ static void set_context_pdp_root_pointe
> pdp_pair[i].val = pdp[7 - i];
> }
>
> +/*
> + * when populating shadow ctx from guest, we should not overrride oa related
> + * registers, so that they will not be overlapped by guest oa configs. Thus
> + * made it possible to capture oa data from host for both host and guests.
> + */
> +static void sr_oa_regs(struct intel_vgpu_workload *workload,
> +u32 *reg_state, bool save)
> +{
> +struct drm_i915_private *dev_priv = workload->vgpu->gvt->dev_priv;
> +u32 ctx_oactxctrl = dev_priv->perf.oa.ctx_oactxctrl_offset;
> +u32 ctx_flexeu0 = dev_priv->perf.oa.ctx_flexeu0_offset;
> +int i = 0;
> +u32 flex_mmio[] = {
> +i915_mmio_reg_offset(EU_PERF_CNTL0),
> +i915_mmio_reg_offset(EU_PERF_CNTL1),
> +i915_mmio_reg_offset(EU_PERF_CNTL2),
> +i915_mmio_reg_offset(EU_PERF_CNTL3),
> +i915_mmio_reg_offset(EU_PERF_CNTL4),
> +i915_mmio_reg_offset(EU_PERF_CNTL5),
> +i915_mmio_reg_offset(EU_PERF_CNTL6),
> +};
> +
> +if (!workload || !reg_state || workload->ring_id != RCS)
> +return;
> +
> +if (save) {
> +workload->oactxctrl = reg_state[ctx_oactxctrl + 1];
> +
> +for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
> +u32 state_offset = ctx_flexeu0 + i * 2;
> +
> +workload->flex_mmio[i] = reg_state[state_offset + 1];
> +}
> +} else {
> +reg_state[ctx_oactxctrl] =
> +i915_mmio_reg_offset(GEN8_OACTXCONTROL);
> +reg_state[ctx_oactxctrl + 1] = workload->oactxctrl;
> +
> +for (i = 0; i < ARRAY_SIZE(workload->flex_mmio); i++) {
> +u32 state_offset = ctx_flexeu0 + i * 2;
> +u32 mmio = flex_mmio[i];
> +
> +reg_state[state_offset] = mmio;
> +reg_state[state_offset + 1] = workload->flex_mmio[i];
> +}
> +}
> +}
> +
> + static void update_shadow_pdps(struct intel_vgpu_workload *workload)
> + {
> + struct intel_vgpu *vgpu = workload->vgpu;
> + int ring_id = workload->ring_id;
> + struct i915_gem_context *shadow_ctx = vgpu->submission.shadow_ctx;
> + struct drm_i915_gem_object *ctx_obj =
> + shadow_ctx->engine[ring_id].state->obj;
> + struct execlist_ring_context *shadow_ring_context;
> + struct page *page;
> +
> + if (WARN_ON(!workload->shadow_mm))
> + return;
> +
> + if (WARN_ON(!atomic_read(&workload->shadow_mm->pincount)))
> + return;
> +
> + page = i915_gem_object_get_page(ctx_obj, LRC_STATE_PN);
> + shadow_ring_context = kmap(page);
> + set_context_pdp_root_pointer(shadow_ring_context,
> + (void *)workload->shadow_mm->ppgtt_mm.shadow_pdps);
> + kunmap(page);
> + }
> +
> static int populate_shadow_context(struct intel_vgpu_workload *workload)
> {
> struct intel_vgpu *vgpu = workload->vgpu;
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpqYyNhNXEJO.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
On Thu, 15 Mar 2018 14:14:25 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> sound/pci/hda/hda_intel.c
>
> between commits:
>
> 1ba8f9d30817 ("ALSA: hda: Add a power_save blacklist")
> 40088dc4e1ea ("ALSA: hda - Revert power_save option default value")
>
> from Linus' tree and commit:
>
> 07f4f97d7b4b ("vga_switcheroo: Use device link for HDA controller")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc sound/pci/hda/hda_intel.c
> index d5017adf9feb,ec4e6b829ee2..
> --- a/sound/pci/hda/hda_intel.c
> +++ b/sound/pci/hda/hda_intel.c
> @@@ -2219,8 -2201,8 +2223,9 @@@ static int azx_probe_continue(struct az
> struct hda_intel *hda = container_of(chip, struct hda_intel, chip);
> struct hdac_bus *bus = azx_bus(chip);
> struct pci_dev *pci = chip->pci;
> + struct hda_codec *codec;
> int dev = chip->dev_index;
> +int val;
> int err;
>
> hda->probe_continued = 1;
> @@@ -2302,21 -2284,16 +2307,30 @@@
> chip->running = 1;
> azx_add_card_list(chip);
>
> +val = power_save;
> +#ifdef CONFIG_PM
> +if (pm_blacklist) {
> +const struct snd_pci_quirk *q;
> +
> +q = snd_pci_quirk_lookup(chip->pci, power_save_blacklist);
> +if (q && val) {
> +dev_info(chip->card->dev, "device %04x:%04x is on the
> power_save blacklist, forcing power_save to 0\n",
> + q->subvendor, q->subdevice);
> +val = 0;
> +}
> +}
> +#endif /* CONFIG_PM */
> ++
> + /*
> + * The discrete GPU cannot power down unless the HDA controller runtime
> + * suspends, so activate runtime PM on codecs even if power_save == 0.
> + */
> + if (use_vga_switcheroo(hda))
> + list_for_each_codec(codec, &chip->bus)
> + codec->auto_runtime_pm = 1;
> +
> -snd_hda_set_power_save(&chip->bus, power_save * 1000);
> +snd_hda_set_power_save(&chip->bus, val * 1000);
> - if (azx_has_pm_runtime(chip) || hda->use_vga_switcheroo)
> + if (azx_has_pm_runtime(chip))
> pm_runtime_put_autosuspend(&pci->dev);
>
> out_free:
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpRucZzASApC.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] linux-next: manual merge of the drm-misc tree with Linus' tree
Hi all,
On Tue, 20 Mar 2018 12:08:41 +1100 Stephen Rothwell
wrote:
>
> Today's linux-next merge of the drm-misc tree got a conflict in:
>
> drivers/gpu/drm/sun4i/sun4i_tcon.h
>
> between commit:
>
> e742a17cd360 ("drm/sun4i: tcon: Reduce the scope of the LVDS error a bit")
>
> from Linus' tree and commit:
>
> 6664e9dc5383 ("drm/sun4i: Add support for A80 TCONs")
>
> from the drm-misc tree.
>
> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging. You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.
>
> --
> Cheers,
> Stephen Rothwell
>
> diff --cc drivers/gpu/drm/sun4i/sun4i_tcon.h
> index abdc6ad6b384,d3a945b7bb60..
> --- a/drivers/gpu/drm/sun4i/sun4i_tcon.h
> +++ b/drivers/gpu/drm/sun4i/sun4i_tcon.h
> @@@ -176,7 -176,7 +176,8 @@@ struct sun4i_tcon_quirks
> boolhas_channel_1; /* a33 does not have channel 1 */
> boolhas_lvds_alt; /* Does the LVDS clock have a parent other than
> the TCON clock? */
> boolneeds_de_be_mux; /* sun6i needs mux to select backend */
> +boolsupports_lvds; /* Does the TCON support an LVDS output? */
> + boolneeds_edp_reset; /* a80 edp reset needed for tcon0 access */
>
> /* callback to handle tcon muxing options */
> int (*set_mux)(struct sun4i_tcon *, const struct drm_encoder *);
This is now a conflict between the drm tree and Linus' tree.
--
Cheers,
Stephen Rothwell
pgpUAPSL1miqC.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev4)
== Series Details == Series: drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams (rev4) URL : https://patchwork.freedesktop.org/series/39979/ State : success == Summary == Series 39979v4 drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams https://patchwork.freedesktop.org/api/1.0/series/39979/revisions/4/mbox/ Known issues: Test kms_flip: Subgroup basic-flip-vs-wf_vblank: pass -> FAIL (fi-skl-6770hq) fdo#100368 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-b: pass -> INCOMPLETE (fi-snb-2520m) fdo#103713 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:436s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:381s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:539s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:299s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:513s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:517s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:523s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:509s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:511s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:522s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:428s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:316s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:537s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:406s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:422s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:483s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:434s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:484s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:472s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:517s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:648s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:447s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:538s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:510s fi-skl-6770hqtotal:285 pass:264 dwarn:0 dfail:0 fail:1 skip:20 time:494s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:429s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:447s fi-snb-2520m total:242 pass:208 dwarn:0 dfail:0 fail:0 skip:33 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:409s fi-cfl-s3 failed to connect after reboot 9e3f06af248708774c765efd55bf8e883f24fbfd drm-tip: 2018y-03m-22d-21h-17m-42s UTC integration manifest 843f01e2c67b drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8462/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook
== Series Details == Series: series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook URL : https://patchwork.freedesktop.org/series/40514/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-wf_vblank-ts-check-interruptible: pass -> FAIL (shard-hsw) fdo#100368 Subgroup dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 +1 Subgroup flip-vs-expired-vblank: pass -> FAIL (shard-hsw) fdo#102887 Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (shard-apl) fdo#104008 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 shard-apltotal:3484 pass:1819 dwarn:1 dfail:0 fail:8 skip:1655 time:13119s shard-hswtotal:3484 pass:1772 dwarn:1 dfail:0 fail:3 skip:1707 time:11856s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7288s Blacklisted hosts: shard-kbltotal:3484 pass:1918 dwarn:27 dfail:0 fail:9 skip:1530 time:9995s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8459/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit
On Fri, 2018-03-23 at 00:16 +, Souza, Jose wrote:
> On Thu, 2018-03-22 at 16:43 -0700, Pandiyan, Dhinakaran wrote:
> >
> >
> > On Thu, 2018-03-22 at 16:27 -0700, Rodrigo Vivi wrote:
> > > On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza
> > > wrote:
> > > > This will be helpful to debug what hardware is actually tracking.
> > > >
> > > > Signed-off-by: José Roberto de Souza
> > > > Cc: Dhinakaran Pandiyan
> > > > Cc: Rodrigo Vivi
> > > > ---
> > > > drivers/gpu/drm/i915/i915_debugfs.c | 47
> > > > +
> > > > drivers/gpu/drm/i915/i915_reg.h | 18 ++
> > > > 2 files changed, 65 insertions(+)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 0a0642c61cd0..3182e9a7cc5d 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -2641,6 +2641,43 @@ static void
> > > > psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32
> > > > val)
> > > > seq_puts(m, "\tY-Coordinate valid\n");
> > > > }
> > > >
> > > > +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> > > > + bool psr2_enabled)
> > > > +{
> > > > + if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > > > + seq_puts(m, "\tPSR2 watchdog timer expired\n");
> > > > + if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > > > + seq_puts(m, "\tPSR2 disabled\n");
> > > > + if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > > > + seq_puts(m, "\tSU dirty FIFO underrun\n");
> > > > + if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > > > + seq_puts(m, "\tSU CRC FIFO underrun\n");
> > > > + if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> > > > + seq_puts(m, "\tGraphics reset\n");
> > > > + if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> > > > + seq_puts(m, "\tPCH interrupt\n");
> > > > + if (val & EDP_PSR_EVENT_MEMORY_UP)
> > > > + seq_puts(m, "\tMemory up\n");
> > > > + if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> > > > + seq_puts(m, "\tFront buffer modification\n");
> > > > + if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> > > > + seq_puts(m, "\tPSR watchdog timer expired\n");
> > > > + if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > > > + seq_puts(m, "\tPIPE registers updated\n");
> > > > + if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> > > > + seq_puts(m, "\tRegister update\n");
> > > > + if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> > > > + seq_puts(m, "\tHDCP enabled\n");
> > > > + if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> > > > + seq_puts(m, "\tKVMR session enabled\n");
> > > > + if (val & EDP_PSR_EVENT_VBI_ENABLE)
> > > > + seq_puts(m, "\tVBI enabled\n");
> > > > + if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> > > > + seq_puts(m, "\tLPSP mode exited\n");
> > > > + if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > > > + seq_puts(m, "\tPSR disabled\n");
> > > > +}
> > > > +
> > > > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > > {
> > > > struct drm_i915_private *dev_priv = node_to_i915(m-
> > > > >private);
> > > > @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct
> > > > seq_file *m, void *data)
> > > >
> > > > seq_printf(m, "Performance_Counter: %u\n",
> > > > psrperf);
> > > > }
> > > > +
> > > > + if (INTEL_GEN(dev_priv) >= 9) {
> > > > + u32 val = I915_READ(EDP_PSR_EVENT);
> > >
> > > What I'm afraid here is that this really shows the last event or
> > > the first one after we cleared.
> > >
> >
> > Both, the bits remain set unless cleared. I have plans of printing
> > the
> > events out of the PSR exit irq handler. This really was one of the
> > main
> > reasons to implement PSR interrupts. Since we get interrupt for each
> > PSR
> > exit, we'll also print out the correct event that caused exit.
> >
>
> Exactly that, so should I drop this one?
> Are you planning send a patch later showing the reasons in the debugfs?
Yeah, I was planning to do it after the interrupt series is merged.
Since you've already done all the work for this patch, I think it makes
sense for you to one this one on top of PSR interrupts.
> This way we could improve and write new IGT tests.
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/12] drm/i915/psr: Cache sink synchronization latency
On Thu, 2018-03-22 at 16:15 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:44PM -0700, José Roberto de Souza
> wrote:
> > This value do not change overtime so better cache it than
> > fetch it every PSR enable.
> >
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 +
> > drivers/gpu/drm/i915/intel_psr.c | 28
> > 2 files changed, 17 insertions(+), 12 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index a367fe5538ae..f79338821081 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -607,6 +607,7 @@ struct i915_psr {
> > bool alpm;
> > bool has_hw_tracking;
> > bool psr2_enabled;
> > + u8 sink_sync_latency;
> >
> > void (*enable_source)(struct intel_dp *,
> > const struct intel_crtc_state *);
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index ad69722c329d..19ee6120d3cd 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -122,6 +122,18 @@ static bool intel_dp_get_alpm_status(struct
> > intel_dp *intel_dp)
> > return alpm_caps & DP_ALPM_CAP;
> > }
> >
> > +static u8 intel_dp_get_sink_sync_latency(struct intel_dp
> > *intel_dp)
> > +{
> > + u8 val = 0;
> > +
> > + if (drm_dp_dpcd_readb(&intel_dp->aux,
> > + DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> > &val) == 1)
> > + val &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
> > + else
> > + DRM_ERROR("Unable to get sink synchronization
> > latency\n");
> > + return val;
> > +}
> > +
> > void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> > {
> > struct drm_i915_private *dev_priv =
> > @@ -158,6 +170,8 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > intel_dp_get_colorimetry_status(in
> > tel_dp);
> > dev_priv->psr.alpm =
> > intel_dp_get_alpm_status(intel_dp)
> > ;
> > + dev_priv->psr.sink_sync_latency =
> > + intel_dp_get_sink_sync_latency(int
> > el_dp);
> > }
> > }
> > }
> > @@ -380,10 +394,7 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > * with the 5 or 6 idle patterns.
> > */
> > uint32_t idle_frames = max(6, dev_priv-
> > >vbt.psr.idle_frames);
> > - uint32_t val;
> > - uint8_t sink_latency;
> > -
> > - val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> > + u32 val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
>
> This belongs to the previous patch apparently. With this moved there
> keep my rv-b there
> and add my rv-b here...
Good catch, fixed.
Thanks
>
> >
> > /* FIXME: selective update is probably totally broken
> > because it doesn't
> > * mesh at all with our frontbuffer tracking. And the hw
> > alone isn't
> > @@ -393,14 +404,7 @@ static void hsw_activate_psr2(struct intel_dp
> > *intel_dp)
> > val |= EDP_Y_COORDINATE_VALID |
> > EDP_Y_COORDINATE_ENABLE;
> > }
> >
> > - if (drm_dp_dpcd_readb(&intel_dp->aux,
> > - DP_SYNCHRONIZATION_LATENCY_IN_SINK
> > ,
> > - &sink_latency) == 1) {
> > - sink_latency &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
> > - } else {
> > - sink_latency = 0;
> > - }
> > - val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
> > + val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv-
> > >psr.sink_sync_latency + 1);
> >
> > if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> > val |= EDP_PSR2_TP2_TIME_2500;
> > --
> > 2.16.2
> >
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit
On Thu, 2018-03-22 at 16:43 -0700, Pandiyan, Dhinakaran wrote:
>
>
> On Thu, 2018-03-22 at 16:27 -0700, Rodrigo Vivi wrote:
> > On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza
> > wrote:
> > > This will be helpful to debug what hardware is actually tracking.
> > >
> > > Signed-off-by: José Roberto de Souza
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 47
> > > +
> > > drivers/gpu/drm/i915/i915_reg.h | 18 ++
> > > 2 files changed, 65 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 0a0642c61cd0..3182e9a7cc5d 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2641,6 +2641,43 @@ static void
> > > psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32
> > > val)
> > > seq_puts(m, "\tY-Coordinate valid\n");
> > > }
> > >
> > > +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> > > +bool psr2_enabled)
> > > +{
> > > + if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > > + seq_puts(m, "\tPSR2 watchdog timer expired\n");
> > > + if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > > + seq_puts(m, "\tPSR2 disabled\n");
> > > + if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > > + seq_puts(m, "\tSU dirty FIFO underrun\n");
> > > + if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > > + seq_puts(m, "\tSU CRC FIFO underrun\n");
> > > + if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> > > + seq_puts(m, "\tGraphics reset\n");
> > > + if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> > > + seq_puts(m, "\tPCH interrupt\n");
> > > + if (val & EDP_PSR_EVENT_MEMORY_UP)
> > > + seq_puts(m, "\tMemory up\n");
> > > + if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> > > + seq_puts(m, "\tFront buffer modification\n");
> > > + if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> > > + seq_puts(m, "\tPSR watchdog timer expired\n");
> > > + if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > > + seq_puts(m, "\tPIPE registers updated\n");
> > > + if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> > > + seq_puts(m, "\tRegister update\n");
> > > + if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> > > + seq_puts(m, "\tHDCP enabled\n");
> > > + if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> > > + seq_puts(m, "\tKVMR session enabled\n");
> > > + if (val & EDP_PSR_EVENT_VBI_ENABLE)
> > > + seq_puts(m, "\tVBI enabled\n");
> > > + if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> > > + seq_puts(m, "\tLPSP mode exited\n");
> > > + if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > > + seq_puts(m, "\tPSR disabled\n");
> > > +}
> > > +
> > > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > {
> > > struct drm_i915_private *dev_priv = node_to_i915(m-
> > > >private);
> > > @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct
> > > seq_file *m, void *data)
> > >
> > > seq_printf(m, "Performance_Counter: %u\n",
> > > psrperf);
> > > }
> > > +
> > > + if (INTEL_GEN(dev_priv) >= 9) {
> > > + u32 val = I915_READ(EDP_PSR_EVENT);
> >
> > What I'm afraid here is that this really shows the last event or
> > the first one after we cleared.
> >
>
> Both, the bits remain set unless cleared. I have plans of printing
> the
> events out of the PSR exit irq handler. This really was one of the
> main
> reasons to implement PSR interrupts. Since we get interrupt for each
> PSR
> exit, we'll also print out the correct event that caused exit.
>
Exactly that, so should I drop this one?
Are you planning send a patch later showing the reasons in the debugfs?
This way we could improve and write new IGT tests.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/12] drm/i915/debugfs: Print sink PSR state and debug info
On Thu, Mar 22, 2018 at 05:06:13PM -0700, Souza, Jose wrote:
> On Thu, 2018-03-22 at 16:31 -0700, Rodrigo Vivi wrote:
> > On Thu, Mar 22, 2018 at 02:48:46PM -0700, José Roberto de Souza
> > wrote:
> >
> > please add some justification on why this is useful
>
> Okay something like this should be fine?
>
> IGT tests could be improved with sink status, knowing for sure that
> hardware have activate PSR before get the CRC.
> This is also userful to check if hardware is really doing PSR2
> selective update with the y-coordinate.
I think so. Although for the tests I'd like you sync with DK on this
versus the Interrupt approach.
>
>
> >
> > > Signed-off-by: José Roberto de Souza
> > > Cc: Dhinakaran Pandiyan
> > > Cc: Rodrigo Vivi
> > > ---
> > > drivers/gpu/drm/i915/i915_debugfs.c | 54
> > > +
> > > 1 file changed, 54 insertions(+)
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index 16f9977995df..0a0642c61cd0 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2603,6 +2603,44 @@ static const char *psr2_live_status(u32 val)
> > > return "unknown";
> > > }
> > >
> > > +static const char *psr_sink_self_refresh_status(u8 val)
> > > +{
> > > + static const char * const sink_status[] = {
> > > + "inactive",
> > > + "transitioning to active",
> > > + "active",
> > > + "active receiving selective update",
> > > + "transitioning to inactive",
> > > + "reserved",
> > > + "reserved",
> > > + "sink internal error"
> > > + };
> > > +
> > > + val &= DP_PSR_SINK_STATE_MASK;
> > > + if (val < ARRAY_SIZE(sink_status))
> > > + return sink_status[val];
> > > +
> > > + return "unknown";
> > > +}
> > > +
> > > +static void psr_sink_last_received_psr_sdp_sprintf(struct seq_file
> > > *m, u32 val)
> > > +{
> > > + if (val & DP_PSR_STATE_BIT)
> > > + seq_puts(m, "\tPSR active\n");
> >
> > I'm a bit confused here why we are printing status here again if we
> > are adding the
> > sink_status char * array with some status definition up there.
> >
> > Any simplification possible?
>
> Huum yeah, DP_PSR_STATE_BIT and DP_SU_VALID changes will cause the
> status of the sink to change, so I this 2 can be removed.
>
> >
> > > + if (val & DP_UPDATE_RFB_BIT)
> > > + seq_puts(m, "\tUpdate RFB\n");
> > > + if (val & DP_CRC_VALID_BIT)
> > > + seq_puts(m, "\tCRC valid\n");
> > > + if (val & DP_SU_VALID)
> > > + seq_puts(m, "\tSU valid\n");
> > > + if (val & DP_FIRST_SCAN_LINE_SU_REGION)
> > > + seq_puts(m, "\tFirst scan line of the SU
> > > region\n");
> > > + if (val & DP_LAST_SCAN_LINE_SU_REGION)
> > > + seq_puts(m, "\tLast scan line of the SU
> > > region\n");
> > > + if (val & DP_Y_COORDINATE_VALID)
> > > + seq_puts(m, "\tY-Coordinate valid\n");
> > > +}
> > > +
> > > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > > {
> > > struct drm_i915_private *dev_priv = node_to_i915(m-
> > > >private);
> > > @@ -2684,6 +2722,22 @@ static int i915_edp_psr_status(struct
> > > seq_file *m, void *data)
> > > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> > > psr2, psr2_live_status(psr2));
> > > }
> > > +
> > > + if (dev_priv->psr.enabled) {
> > > + struct drm_dp_aux *aux = &dev_priv->psr.enabled-
> > > >aux;
> > > + u8 val;
> > > +
> > > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) ==
> > > 1)
> > > + seq_printf(m, "Sink self refresh status:
> > > 0x%x [%s]\n",
> > > +val,
> > > psr_sink_self_refresh_status(val));
> > > +
> > > + if (drm_dp_dpcd_readb(aux,
> > > DP_LAST_RECEIVED_PSR_SDP, &val)
> > > + == 1) {
> > > + seq_printf(m, "Sink last received PSR SDP:
> > > 0x%x\n",
> > > +val);
> > > + psr_sink_last_received_psr_sdp_sprintf(m,
> > > val);
> > > + }
> > > + }
> > > mutex_unlock(&dev_priv->psr.lock);
> > >
> > > intel_runtime_pm_put(dev_priv);
> > > --
> > > 2.16.2
> > >
> > > ___
> > > Intel-gfx mailing list
> > > Intel-gfx@lists.freedesktop.org
> > > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI
From: Manasi Navare
This is an important part of the DDI initalization as well as
for changing the voltage during DisplayPort link training.
The Voltage swing seqeuence is similar to Cannonlake.
However it has different register definitions and hence
it makes sense to create a separate vswing sequence and
program functions for ICL to leave room for more changes
in case the Bspec changes later and deviates from CNL sequence.
v2:
Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
v3:
* Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
v4:
* Call it combo_vswing, use switch statement (Paulo)
v5 (from Paulo):
* Fix a typo.
* s/rate < 60/rate <= 60/.
* Don't remove blank lines that should be there.
v6:
* Rebased by Rodrigo on top of Cannonlake changes
where non vswing sequences are not aligned with iboost
anymore.
v7: Another rebase after an upstream rework.
v8 (from Paulo):
* Adjust the code to the upstream output type changes.
* Squash the patch that moved some functions up.
* Merge both get_combo_buf_trans functions in order to simplify the
code.
* Change the changelog format.
v9 (from Paulo):
* Use RTERM_SELECT instead of SCALING_MODE_SEL.
* Adjust the output type handling according to how the other platforms
do it now.
Cc: Jani Nikula
Cc: James Ausmus
Signed-off-by: Manasi Navare
Signed-off-by: Rodrigo Vivi
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/intel_ddi.c | 191 ++-
1 file changed, 188 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 355dd4729ae8..15bafc850907 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -850,6 +850,45 @@ cnl_get_buf_trans_edp(struct drm_i915_private *dev_priv,
int *n_entries)
}
}
+static const struct icl_combo_phy_ddi_buf_trans *
+icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, enum port port,
+ int type, int *n_entries)
+{
+ u32 voltage = I915_READ(ICL_PORT_COMP_DW3(port)) & VOLTAGE_INFO_MASK;
+
+ if (type == INTEL_OUTPUT_EDP && dev_priv->vbt.edp.low_vswing) {
+ switch (voltage) {
+ case VOLTAGE_INFO_0_85V:
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_85V);
+ return icl_combo_phy_ddi_translations_edp_0_85V;
+ case VOLTAGE_INFO_0_95V:
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_95V);
+ return icl_combo_phy_ddi_translations_edp_0_95V;
+ case VOLTAGE_INFO_1_05V:
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_1_05V);
+ return icl_combo_phy_ddi_translations_edp_1_05V;
+ default:
+ MISSING_CASE(voltage);
+ return NULL;
+ }
+ } else {
+ switch (voltage) {
+ case VOLTAGE_INFO_0_85V:
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_85V);
+ return icl_combo_phy_ddi_translations_dp_hdmi_0_85V;
+ case VOLTAGE_INFO_0_95V:
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_95V);
+ return icl_combo_phy_ddi_translations_dp_hdmi_0_95V;
+ case VOLTAGE_INFO_1_05V:
+ *n_entries =
ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_1_05V);
+ return icl_combo_phy_ddi_translations_dp_hdmi_1_05V;
+ default:
+ MISSING_CASE(voltage);
+ return NULL;
+ }
+ }
+}
+
static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv, enum port
port)
{
int n_entries, level, default_entry;
@@ -2179,6 +2218,146 @@ static void cnl_ddi_vswing_sequence(struct
intel_encoder *encoder,
I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
}
+static void icl_ddi_combo_vswing_program(struct drm_i915_private *dev_priv,
+u32 level, enum port port, int type)
+{
+ const struct icl_combo_phy_ddi_buf_trans *ddi_translations = NULL;
+ u32 n_entries, val;
+ int ln;
+
+ ddi_translations = icl_get_combo_buf_trans(dev_priv, port, type,
+ &n_entries);
+ if (!ddi_translations)
+ return;
+
+ if (level >= n_entries) {
+ DRM_DEBUG_KMS("DDI translation not found for level %d. Using %d
instead.", level, n_entries - 1);
+ level = n_entries - 1;
+ }
+
+ /* Set PORT_TX_DW5 Scaling Mode Sel to 110b. */
+ val = I915_READ(ICL_PORT_TX_DW5_LN0(port));
+ val &= ~RTERM_SELECT_MASK;
+ val |= RTERM_SELECT(0x6);
+ I915_WRITE(ICL_PORT_TX_DW5_GRP(port), val);
+
+ /* Program PO
[Intel-gfx] [PATCH v2 1/4] drm/i915: Always do WOPCM partitioning based on real firmware sizes
After enabled the WOPCM write-once registers locking status checking,
reloading of the i915 module will fail with modparam enable_guc set to 3
(enable GuC and HuC firmware loading) if the module was originally loaded
with enable_guc set to 1 (only enable GuC firmware loading). This is
because WOPCM registers were updated and locked without considering the HuC
FW size. Since we need both GuC and HuC FW sizes to determine the final
layout of WOPCM, we should always calculate the WOPCM layout based on the
actual sizes of the GuC and HuC firmware available for a specific platform
if we need continue to support enable/disable HuC FW loading dynamically
with enable_guc modparam.
This patch splits uC firmware fetching into two stages. First stage is to
fetch the firmware image and verify the firmware header. uC firmware will
be marked as verified and this will make FW info available for following
WOPCM layout calculation. The second stage is to create a GEM object and
copy the FW data into the created GEM object which will only be available
when GuC/HuC loading is enabled by enable_guc modparam. This will guarantee
that the WOPCM layout will be always be calculated correctly without making
any assumptions to the GuC and HuC firmware sizes.
Signed-off-by: Jackie Li
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Michal Winiarski
Cc: John Spotswood
---
drivers/gpu/drm/i915/intel_uc.c| 10 +++---
drivers/gpu/drm/i915/intel_uc_fw.c | 31 ---
drivers/gpu/drm/i915/intel_uc_fw.h | 7 +--
3 files changed, 28 insertions(+), 20 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..5946aa3 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -175,10 +175,8 @@ void intel_uc_init_fw(struct drm_i915_private *dev_priv)
if (!USES_GUC(dev_priv))
return;
- if (USES_HUC(dev_priv))
- intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
-
- intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw);
+ intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw, USES_HUC(dev_priv));
+ intel_uc_fw_fetch(dev_priv, &dev_priv->guc.fw, true);
}
void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
@@ -187,9 +185,7 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
return;
intel_uc_fw_fini(&dev_priv->guc.fw);
-
- if (USES_HUC(dev_priv))
- intel_uc_fw_fini(&dev_priv->huc.fw);
+ intel_uc_fw_fini(&dev_priv->huc.fw);
guc_free_load_err_log(&dev_priv->guc);
}
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 30c7324..b80b509 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -33,11 +33,13 @@
*
* @dev_priv: device private
* @uc_fw: uC firmware
+ * @copy_to_obj: whether fetch uC firmware into GEM object or not
*
- * Fetch uC firmware into GEM obj.
+ * Fetch and verify uC firmware and copy firmware data into GEM object if
+ * @copy_to_obj is true.
*/
void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
- struct intel_uc_fw *uc_fw)
+ struct intel_uc_fw *uc_fw, bool copy_to_obj)
{
struct pci_dev *pdev = dev_priv->drm.pdev;
struct drm_i915_gem_object *obj;
@@ -154,17 +156,24 @@ void intel_uc_fw_fetch(struct drm_i915_private *dev_priv,
goto fail;
}
- obj = i915_gem_object_create_from_data(dev_priv, fw->data, fw->size);
- if (IS_ERR(obj)) {
- err = PTR_ERR(obj);
- DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
-intel_uc_fw_type_repr(uc_fw->type), err);
- goto fail;
+ uc_fw->size = fw->size;
+ uc_fw->fetch_status = INTEL_UC_FIRMWARE_VERIFIED;
+
+ if (copy_to_obj) {
+ obj = i915_gem_object_create_from_data(dev_priv, fw->data,
+ fw->size);
+ if (IS_ERR(obj)) {
+ err = PTR_ERR(obj);
+ DRM_DEBUG_DRIVER("%s fw object_create err=%d\n",
+intel_uc_fw_type_repr(uc_fw->type),
+err);
+ goto fail;
+ }
+
+ uc_fw->obj = obj;
+ uc_fw->fetch_status = INTEL_UC_FIRMWARE_SUCCESS;
}
- uc_fw->obj = obj;
- uc_fw->size = fw->size;
- uc_fw->fetch_status = INTEL_UC_FIRMWARE_SUCCESS;
DRM_DEBUG_DRIVER("%s fw fetch %s\n",
intel_uc_fw_type_repr(uc_fw->type),
intel_uc_fw_status_repr(uc_fw->fetch_status));
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.h
b/drivers/gpu/drm/i915/intel_uc_fw.h
index dc33b12..4e7ecc8 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.h
+++ b/drivers/gpu/drm/i915/intel_uc_fw.h
@@ -36,6 +
[Intel-gfx] [PATCH v2 3/4] drm/i915: Add code to accept valid locked WOPCM register values
In current code, we only compare the locked WOPCM register values with the
calculated values. However, we can continue loading GuC/HuC firmware if the
locked (or partially locked) values were valid for current GuC/HuC firmware
sizes.
This patch added a new code path to verify whether the locked register
values can be used for GuC/HuC firmware loading, it will recalculate the
verify the new values if these registers were partially locked, so that we
won't fail the GuC/HuC firmware loading even if the locked register values
are different from the calculated ones.
v2:
- Update WOPCM register only if it's not locked
Signed-off-by: Jackie Li
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Michal Winiarski
Cc: John Spotswood
---
drivers/gpu/drm/i915/intel_wopcm.c | 225 +++--
1 file changed, 189 insertions(+), 36 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index babb158..add23e3 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -138,6 +138,53 @@ static inline int check_hw_restriction(struct
drm_i915_private *i915,
return err;
}
+static inline u32 calculate_min_guc_wopcm_base(u32 huc_fw_size)
+{
+ return ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
+GUC_WOPCM_OFFSET_ALIGNMENT);
+}
+
+static inline u32 calculate_min_guc_wopcm_size(u32 guc_fw_size)
+{
+ return guc_fw_size + GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
+}
+
+static inline int calculate_max_guc_wopcm_size(struct intel_wopcm *wopcm,
+ u32 guc_wopcm_base,
+ u32 *guc_wopcm_size)
+{
+ struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
+ u32 ctx_rsvd = context_reserved_size(i915);
+
+ if (guc_wopcm_base >= wopcm->size ||
+ (guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
+ DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
+ guc_wopcm_base / 1024);
+ return -E2BIG;
+ }
+
+ *guc_wopcm_size =
+ (wopcm->size - guc_wopcm_base - ctx_rsvd) & GUC_WOPCM_SIZE_MASK;
+
+ return 0;
+}
+
+static inline int verify_calculated_values(struct drm_i915_private *i915,
+ u32 guc_fw_size, u32 huc_fw_size,
+ u32 guc_wopcm_base,
+ u32 guc_wopcm_size)
+{
+ if (guc_wopcm_size < calculate_min_guc_wopcm_size(guc_fw_size)) {
+ DRM_ERROR("Need %uKiB WOPCM for GuC FW, %uKiB available.\n",
+ calculate_min_guc_wopcm_size(guc_fw_size),
+ guc_wopcm_size / 1024);
+ return -E2BIG;
+ }
+
+ return check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
+ huc_fw_size);
+}
+
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
- u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
- u32 guc_wopcm_rsvd;
int err;
GEM_BUG_ON(!wopcm->size);
@@ -175,30 +220,18 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return -E2BIG;
}
- guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
- GUC_WOPCM_OFFSET_ALIGNMENT);
- if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
- DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
- guc_wopcm_base / 1024);
- return -E2BIG;
- }
-
- guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
- guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
+ guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
+ err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
+ &guc_wopcm_size);
+ if (err)
+ return err;
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
-guc_wopcm_base / 1024, guc_wopcm_size / 1024);
+guc_wopcm_base / 1024,
+(guc_wopcm_base + guc_wopcm_size) / 1024);
- guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
- if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
- DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
- (guc_fw_size + guc_wopcm_rsvd) / 1024,
- guc_wopcm_size / 1024);
- return -E2BIG;
- }
-
- err = check_hw_restriction(i
[Intel-gfx] [PATCH v2 4/4] HAX enable guc for CI
Signed-off-by: Jackie Li --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ struct drm_printer; param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/4] drm/i915: Always set HUC_LOADING_AGENT_GUC bit in WOPCM offset register
The enable_guc modparam is used to enable/disable GuC/HuC FW uploading
dynamcially during i915 module loading. If WOPCM offset register was locked
without having HUC_LOADING_AGENT_GUC bit set to 1, the module reloading
with both GuC and HuC FW will fail since we need to set this bit to 1 for
HuC FW uploading.
Since HUC_LOADING_AGENT_GUC bit has no impact on GuC FW uploading, this
patch updates the register updating code to make sure the WOPCM offset
register is always locked with HUC_LOADING_AGENT_GUC bit set to 1 which
will guarantee successful uploading of both GuC and HuC FW. We will further
take care of the locked values in the following enhancement patch.
Signed-off-by: Jackie Li
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Michal Winiarski
Cc: John Spotswood
---
drivers/gpu/drm/i915/intel_wopcm.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_wopcm.c
b/drivers/gpu/drm/i915/intel_wopcm.c
index 4117886..babb158 100644
--- a/drivers/gpu/drm/i915/intel_wopcm.c
+++ b/drivers/gpu/drm/i915/intel_wopcm.c
@@ -236,8 +236,6 @@ static inline int write_and_verify(struct drm_i915_private
*dev_priv,
int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
{
struct drm_i915_private *dev_priv = wopcm_to_i915(wopcm);
- u32 huc_agent;
- u32 mask;
int err;
if (!USES_GUC(dev_priv))
@@ -253,10 +251,10 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
if (err)
goto err_out;
- huc_agent = USES_HUC(dev_priv) ? HUC_LOADING_AGENT_GUC : 0;
- mask = GUC_WOPCM_OFFSET_MASK | GUC_WOPCM_OFFSET_VALID | huc_agent;
err = write_and_verify(dev_priv, DMA_GUC_WOPCM_OFFSET,
- wopcm->guc.base | huc_agent, mask,
+ wopcm->guc.base | HUC_LOADING_AGENT_GUC,
+ GUC_WOPCM_OFFSET_MASK | HUC_LOADING_AGENT_GUC |
+ GUC_WOPCM_OFFSET_VALID,
GUC_WOPCM_OFFSET_VALID);
if (err)
goto err_out;
--
2.7.4
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/17] drm/i915/icl: add basic support for the ICL clocks
This commit introduces the definitions for the ICL clocks and adds the
basic functions to the shared DPLL framework. It adds code for the
Enable and Disable sequences for some PLLs, but it does not have the
code to compute the actual PLL values, which are marked as TODO
comments and should be introduced as separate commits.
Special thanks to James Ausmus for investigating and fixing a bug with
the placement of icl_unmap_plls_to_ports() function.
v2:
- Rebase around dpll_lock changes.
v3:
- The spec now says what the timeouts should be.
- Touch DPCLKA_CFGCR0_ICL at the appropriate time so we don't freeze
the machine.
- Checkpatch found a white space problem.
- Small adjustments before upstreaming.
v4:
- Move the ICL checks out of the *map_plls_to_ports() functions
(James)
- Add extra encoder check (James)
- Call icl_unmap_plls_to_ports() later (James)
Cc: James Ausmus
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_debugfs.c | 22 +++
drivers/gpu/drm/i915/intel_ddi.c | 96 ++-
drivers/gpu/drm/i915/intel_display.c | 16 ++
drivers/gpu/drm/i915/intel_dpll_mgr.c | 311 +-
drivers/gpu/drm/i915/intel_dpll_mgr.h | 41 +
drivers/gpu/drm/i915/intel_drv.h | 6 +
6 files changed, 487 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..d932f1540397 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -3295,6 +3295,28 @@ static int i915_shared_dplls_info(struct seq_file *m,
void *unused)
seq_printf(m, " fp0: 0x%08x\n", pll->state.hw_state.fp0);
seq_printf(m, " fp1: 0x%08x\n", pll->state.hw_state.fp1);
seq_printf(m, " wrpll: 0x%08x\n", pll->state.hw_state.wrpll);
+ seq_printf(m, " cfgcr0: 0x%08x\n", pll->state.hw_state.cfgcr0);
+ seq_printf(m, " cfgcr1: 0x%08x\n", pll->state.hw_state.cfgcr1);
+ seq_printf(m, " mg_refclkin_ctl:0x%08x\n",
+ pll->state.hw_state.mg_refclkin_ctl);
+ seq_printf(m, " mg_clktop2_coreclkctl1: 0x%08x\n",
+ pll->state.hw_state.mg_clktop2_coreclkctl1);
+ seq_printf(m, " mg_clktop2_hsclkctl:0x%08x\n",
+ pll->state.hw_state.mg_clktop2_hsclkctl);
+ seq_printf(m, " mg_pll_div0: 0x%08x\n",
+ pll->state.hw_state.mg_pll_div0);
+ seq_printf(m, " mg_pll_div1: 0x%08x\n",
+ pll->state.hw_state.mg_pll_div1);
+ seq_printf(m, " mg_pll_lf:0x%08x\n",
+ pll->state.hw_state.mg_pll_lf);
+ seq_printf(m, " mg_pll_frac_lock: 0x%08x\n",
+ pll->state.hw_state.mg_pll_frac_lock);
+ seq_printf(m, " mg_pll_ssc: 0x%08x\n",
+ pll->state.hw_state.mg_pll_ssc);
+ seq_printf(m, " mg_pll_bias: 0x%08x\n",
+ pll->state.hw_state.mg_pll_bias);
+ seq_printf(m, " mg_pll_tdc_coldst_bias: 0x%08x\n",
+ pll->state.hw_state.mg_pll_tdc_coldst_bias);
}
drm_modeset_unlock_all(dev);
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8c2d778560f0..78cc332bf3fe 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -894,6 +894,23 @@ static uint32_t hsw_pll_to_ddi_pll_sel(const struct
intel_shared_dpll *pll)
}
}
+static uint32_t icl_pll_to_ddi_pll_sel(struct intel_encoder *encoder,
+ const struct intel_shared_dpll *pll)
+{
+ switch (pll->id) {
+ default:
+ MISSING_CASE(pll->id);
+ case DPLL_ID_ICL_DPLL0:
+ case DPLL_ID_ICL_DPLL1:
+ return DDI_CLK_SEL_NONE;
+ case DPLL_ID_ICL_MGPLL1:
+ case DPLL_ID_ICL_MGPLL2:
+ case DPLL_ID_ICL_MGPLL3:
+ case DPLL_ID_ICL_MGPLL4:
+ return DDI_CLK_SEL_MG;
+ }
+}
+
/* Starting with Haswell, different DDI ports can work in FDI mode for
* connection to the PCH-located connectors. For this, it is necessary to train
* both the DDI port and PCH receiver for the desired DDI buffer settings.
@@ -2115,6 +2132,69 @@ uint32_t ddi_signal_levels(struct intel_dp *intel_dp)
return DDI_BUF_TRANS_SELECT(level);
}
+void icl_map_plls_to_ports(struct drm_crtc *crtc,
+ struct intel_crtc_state *crtc_state,
+ struct drm_atomic_state *old_state)
+{
+ struct intel_shared_dpll *pll = crtc_state->shared_dpll;
+ struct drm_i915_private *dev_priv = to_i915(crtc->dev);
+ struct drm_connector_state *conn_state;
+ struct drm_connector *conn;
+ int i;
+
+ for_each_new_connector_in_state(old_state, conn, conn_state, i)
[Intel-gfx] [PATCH 01/17] drm/i915/icl: add definitions for the ICL PLL registers
There's a lot of code for the PLL enabling, so let's first only
introduce the register definitions in order to make patch reviewing a
little easier.
v2: Coding style (Jani).
v3: Preparation for upstreaming.
v4: Fix MG_CLKTOP2_CORECLKCTL1 address and random typos (James).
Signed-off-by: Paulo Zanoni
---
drivers/gpu/drm/i915/i915_reg.h | 149
1 file changed, 149 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index da2f6c623ab2..d123c5f57421 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -8535,6 +8535,12 @@ enum skl_power_gate {
#define PORT_CLK_SEL_NONE (7<<29)
#define PORT_CLK_SEL_MASK (7<<29)
+/* On ICL+ this is the same as PORT_CLK_SEL, but all bits change. */
+#define DDI_CLK_SEL(port) PORT_CLK_SEL(port)
+#define DDI_CLK_SEL_NONE (0x0 << 28)
+#define DDI_CLK_SEL_MG(0x8 << 28)
+#define DDI_CLK_SEL_MASK (0xF << 28)
+
/* Transcoder clock selection */
#define _TRANS_CLK_SEL_A 0x46140
#define _TRANS_CLK_SEL_B 0x46144
@@ -8665,6 +8671,7 @@ enum skl_power_gate {
* CNL Clocks
*/
#define DPCLKA_CFGCR0 _MMIO(0x6C200)
+#define DPCLKA_CFGCR0_ICL _MMIO(0x164280)
#define DPCLKA_CFGCR0_DDI_CLK_OFF(port) (1 << ((port) == PORT_F ? 23 :
\
(port)+10))
#define DPCLKA_CFGCR0_DDI_CLK_SEL_SHIFT(port) ((port) == PORT_F ? 21 : \
@@ -8681,10 +8688,141 @@ enum skl_power_gate {
#define PLL_POWER_STATE (1 << 26)
#define CNL_DPLL_ENABLE(pll) _MMIO_PLL(pll, DPLL0_ENABLE, DPLL1_ENABLE)
+#define _MG_PLL1_ENABLE0x46030
+#define _MG_PLL2_ENABLE0x46034
+#define _MG_PLL3_ENABLE0x46038
+#define _MG_PLL4_ENABLE0x4603C
+/* Bits are the same as DPLL0_ENABLE */
+#define MG_PLL_ENABLE(port)_MMIO_PORT((port) - PORT_C, _MG_PLL1_ENABLE, \
+ _MG_PLL2_ENABLE)
+
+#define _MG_REFCLKIN_CTL_PORT1 0x16892C
+#define _MG_REFCLKIN_CTL_PORT2 0x16992C
+#define _MG_REFCLKIN_CTL_PORT3 0x16A92C
+#define _MG_REFCLKIN_CTL_PORT4 0x16B92C
+#define MG_REFCLKIN_CTL_OD_2_MUX(x) ((x) << 8)
+#define MG_REFCLKIN_CTL(port) _MMIO_PORT((port) - PORT_C, \
+_MG_REFCLKIN_CTL_PORT1, \
+_MG_REFCLKIN_CTL_PORT2)
+
+#define _MG_CLKTOP2_CORECLKCTL1_PORT1 0x1688D8
+#define _MG_CLKTOP2_CORECLKCTL1_PORT2 0x1698D8
+#define _MG_CLKTOP2_CORECLKCTL1_PORT3 0x16A8D8
+#define _MG_CLKTOP2_CORECLKCTL1_PORT4 0x16B8D8
+#define MG_CLKTOP2_CORECLKCTL1_B_DIVRATIO(x) ((x) << 16)
+#define MG_CLKTOP2_CORECLKCTL1_A_DIVRATIO(x) ((x) << 8)
+#define MG_CLKTOP2_CORECLKCTL1(port) _MMIO_PORT((port) - PORT_C, \
+ _MG_CLKTOP2_CORECLKCTL1_PORT1, \
+ _MG_CLKTOP2_CORECLKCTL1_PORT2)
+
+#define _MG_CLKTOP2_HSCLKCTL_PORT1 0x1688D4
+#define _MG_CLKTOP2_HSCLKCTL_PORT2 0x1698D4
+#define _MG_CLKTOP2_HSCLKCTL_PORT3 0x16A8D4
+#define _MG_CLKTOP2_HSCLKCTL_PORT4 0x16B8D4
+#define MG_CLKTOP2_HSCLKCTL_CORE_INPUTSEL(x) ((x) << 16)
+#define MG_CLKTOP2_HSCLKCTL_TLINEDRV_CLKSEL(x) ((x) << 14)
+#define MG_CLKTOP2_HSCLKCTL_HSDIV_RATIO(x) ((x) << 12)
+#define MG_CLKTOP2_HSCLKCTL_DSDIV_RATIO(x) ((x) << 8)
+#define MG_CLKTOP2_HSCLKCTL(port) _MMIO_PORT((port) - PORT_C, \
+_MG_CLKTOP2_HSCLKCTL_PORT1, \
+_MG_CLKTOP2_HSCLKCTL_PORT2)
+
+#define _MG_PLL_DIV0_PORT1 0x168A00
+#define _MG_PLL_DIV0_PORT2 0x169A00
+#define _MG_PLL_DIV0_PORT3 0x16AA00
+#define _MG_PLL_DIV0_PORT4 0x16BA00
+#define MG_PLL_DIV0_FRACNEN_H(1 << 30)
+#define MG_PLL_DIV0_FBDIV_FRAC(x)((x) << 8)
+#define MG_PLL_DIV0_FBDIV_INT(x) ((x) << 0)
+#define MG_PLL_DIV0(port) _MMIO_PORT((port) - PORT_C, _MG_PLL_DIV0_PORT1, \
+_MG_PLL_DIV0_PORT2)
+
+#define _MG_PLL_DIV1_PORT1 0x168A04
+#define _MG_PLL_DIV1_PORT2 0x169A04
+#define _MG_PLL_DIV1_PORT3 0x16AA04
+#define _MG_PLL_DIV1_PORT4 0x16BA04
+#define MG_PLL_DIV1_IREF_NDIVRATIO(x)((x) << 16)
+#define MG_PLL_DIV1_DI
Re: [Intel-gfx] [PATCH 10/12] drm/i915/debugfs: Print sink PSR state and debug info
On Thu, 2018-03-22 at 16:31 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:46PM -0700, José Roberto de Souza
> wrote:
>
> please add some justification on why this is useful
Okay something like this should be fine?
IGT tests could be improved with sink status, knowing for sure that
hardware have activate PSR before get the CRC.
This is also userful to check if hardware is really doing PSR2
selective update with the y-coordinate.
>
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 54
> > +
> > 1 file changed, 54 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 16f9977995df..0a0642c61cd0 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2603,6 +2603,44 @@ static const char *psr2_live_status(u32 val)
> > return "unknown";
> > }
> >
> > +static const char *psr_sink_self_refresh_status(u8 val)
> > +{
> > + static const char * const sink_status[] = {
> > + "inactive",
> > + "transitioning to active",
> > + "active",
> > + "active receiving selective update",
> > + "transitioning to inactive",
> > + "reserved",
> > + "reserved",
> > + "sink internal error"
> > + };
> > +
> > + val &= DP_PSR_SINK_STATE_MASK;
> > + if (val < ARRAY_SIZE(sink_status))
> > + return sink_status[val];
> > +
> > + return "unknown";
> > +}
> > +
> > +static void psr_sink_last_received_psr_sdp_sprintf(struct seq_file
> > *m, u32 val)
> > +{
> > + if (val & DP_PSR_STATE_BIT)
> > + seq_puts(m, "\tPSR active\n");
>
> I'm a bit confused here why we are printing status here again if we
> are adding the
> sink_status char * array with some status definition up there.
>
> Any simplification possible?
Huum yeah, DP_PSR_STATE_BIT and DP_SU_VALID changes will cause the
status of the sink to change, so I this 2 can be removed.
>
> > + if (val & DP_UPDATE_RFB_BIT)
> > + seq_puts(m, "\tUpdate RFB\n");
> > + if (val & DP_CRC_VALID_BIT)
> > + seq_puts(m, "\tCRC valid\n");
> > + if (val & DP_SU_VALID)
> > + seq_puts(m, "\tSU valid\n");
> > + if (val & DP_FIRST_SCAN_LINE_SU_REGION)
> > + seq_puts(m, "\tFirst scan line of the SU
> > region\n");
> > + if (val & DP_LAST_SCAN_LINE_SU_REGION)
> > + seq_puts(m, "\tLast scan line of the SU
> > region\n");
> > + if (val & DP_Y_COORDINATE_VALID)
> > + seq_puts(m, "\tY-Coordinate valid\n");
> > +}
> > +
> > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m-
> > >private);
> > @@ -2684,6 +2722,22 @@ static int i915_edp_psr_status(struct
> > seq_file *m, void *data)
> > seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> >psr2, psr2_live_status(psr2));
> > }
> > +
> > + if (dev_priv->psr.enabled) {
> > + struct drm_dp_aux *aux = &dev_priv->psr.enabled-
> > >aux;
> > + u8 val;
> > +
> > + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) ==
> > 1)
> > + seq_printf(m, "Sink self refresh status:
> > 0x%x [%s]\n",
> > + val,
> > psr_sink_self_refresh_status(val));
> > +
> > + if (drm_dp_dpcd_readb(aux,
> > DP_LAST_RECEIVED_PSR_SDP, &val)
> > + == 1) {
> > + seq_printf(m, "Sink last received PSR SDP:
> > 0x%x\n",
> > + val);
> > + psr_sink_last_received_psr_sdp_sprintf(m,
> > val);
> > + }
> > + }
> > mutex_unlock(&dev_priv->psr.lock);
> >
> > intel_runtime_pm_put(dev_priv);
> > --
> > 2.16.2
> >
> > ___
> > 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 00/17] ICL PLLs, DP/HDMI and misc display
Em Qui, 2018-02-22 às 00:55 -0300, Paulo Zanoni escreveu: > Hello > > Here are some more ICL patches, now with the Combo & MG PLLs, some > DP/HDMI > initialization code and a few misc fixes. > > Again, the R-B tags already present in some of the patches (including > those form > me) were given a long time ago, so they need to be re-issued due to > the > rebasing. The following patches have my Reviewed-by: 6, 7, 9, 10, 13 and 15. I'll send updated patches soon. > > Thanks, > Paulo > > Arkadiusz Hiler (1): > drm/i915/icl: Calculate link clock using the new registers > > Dhinakaran Pandiyan (1): > drm/i915/icl: HPD pin for port F > > James Ausmus (1): > drm/i915/icl: Don't set pipe CSC/Gamma in PLANE_COLOR_CTL > > Manasi Navare (7): > drm/i915/icl: Add register definitions for Combo PHY vswing > sequences. > drm/i915/icl: Add Combo PHY DDI Buffer translation tables for > Icelake. > drm/i915/icl: Implement voltage swing programming sequence for > Combo > PHY DDI > drm/i915/icl: Add register defs for voltage swing sequences for MG > PHY > DDI > drm/i915/icl: Add Voltage swing table for MG PHY DDI Buffer > drm/i915/icl: Implement voltage swing programming sequence for MG > PHY > DDI > drm/i915/icl: Fix the DP Max Voltage for ICL > > Nabendu Maiti (1): > drm/i915/icl: Added 5k source scaling support for Gen11 platform > > Paulo Zanoni (6): > drm/i915/icl: add definitions for the ICL PLL registers > drm/i915/icl: add basic support for the ICL clocks > drm/i915/icl: compute the combo PHY (DPLL) HDMI registers > drm/i915/icl: compute the combo PHY (DPLL) DP registers > drm/i915/icl: compute the MG PLL registers > drm/i915/gen11: all the DDI ports on gen 11 support 4 lanes > > drivers/gpu/drm/i915/i915_debugfs.c | 22 ++ > drivers/gpu/drm/i915/i915_drv.h | 1 + > drivers/gpu/drm/i915/i915_reg.h | 313 - > drivers/gpu/drm/i915/intel_ddi.c | 529 > +++- > drivers/gpu/drm/i915/intel_display.c | 33 +- > drivers/gpu/drm/i915/intel_dpll_mgr.c | 642 > +- > drivers/gpu/drm/i915/intel_dpll_mgr.h | 41 +++ > drivers/gpu/drm/i915/intel_drv.h | 10 + > drivers/gpu/drm/i915/intel_hotplug.c | 3 + > 9 files changed, 1569 insertions(+), 25 deletions(-) > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 17/17] drm/i915/icl: Fix the DP Max Voltage for ICL
On Thu, Feb 22, 2018 at 12:55:19AM -0300, Paulo Zanoni wrote:
> From: Manasi Navare
>
> On clock recovery this function is called to find out
> the max voltage swing level that we could go.
>
> However gen 9 functions use the old buffer translation tables
> to figure that out. ICL uses different set of tables for eDP
> and DP for both Combo and MG PHY ports. This patch adds the hook
> for ICL for getting this information from appropriate buf trans tables.
>
> v5 (from Paulo):
> * New rebase after changes to earlier patches.
> v4:
> * Rebase.
> v3:
> * Follow the coding conventions here
> (https://cgit.freedesktop.org/drm-intel/tree/Documentation/process/codin
> g-style.rst#n191) (Paulo)
> v2:
> * Rebase after patch that adds voltage check inside buf trans
> function (Rodrigo)
>
> Cc: Rodrigo Vivi
> Cc: Paulo Zanoni
> Reviewed-by: Rodrigo Vivi
seems a lot change since my first review, but everything looks
correct to me still on this newer version. So
Reviewed-by: Rodrigo Vivi
> Signed-off-by: Manasi Navare
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 8 +++-
> 1 file changed, 7 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index ad82ef91263e..fbdd2340c8aa 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2085,7 +2085,13 @@ u8 intel_ddi_dp_voltage_max(struct intel_encoder
> *encoder)
> enum port port = encoder->port;
> int n_entries;
>
> - if (IS_CANNONLAKE(dev_priv)) {
> + if (IS_ICELAKE(dev_priv)) {
> + if (port == PORT_A || port == PORT_B)
> + icl_get_combo_buf_trans(dev_priv, port, encoder->type,
> + &n_entries);
> + else
> + n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + } else if (IS_CANNONLAKE(dev_priv)) {
> if (encoder->type == INTEL_OUTPUT_EDP)
> cnl_get_buf_trans_edp(dev_priv, &n_entries);
> else
> --
> 2.14.3
>
> ___
> 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 1/5] drm/i915: Enable edp psr error interrupts on hsw
On Thu, 2018-03-22 at 13:33 +0200, Ville Syrjälä wrote:
> On Thu, Mar 22, 2018 at 01:19:19AM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
> > > >
> > > >
> > > >
> > > > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > From: Daniel Vetter
> > > > > >
> > > > > > The definitions for the error register should be valid on bdw/skl
> > > > > > too,
> > > > > > but there we haven't even enabled DE_MISC handling yet.
> > > > > >
> > > > > > Somewhat confusing the the moved register offset on bdw is only for
> > > > > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have
> > > > > > been
> > > > > > on bdw.
> > > > > >
> > > > > > v2: Fixes from Ville.
> > > > > >
> > > > > > v3: From DK
> > > > > > * Rebased on drm-tip
> > > > > > * Removed BDW IIR bit definition, looks like an unintentional
> > > > > > change that
> > > > > > should be in the following patch.
> > > > > >
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Daniel Vetter
> > > > > > Signed-off-by: Daniel Vetter
> > > > > > Signed-off-by: Dhinakaran Pandiyan
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_irq.c | 34
> > > > > > ++
> > > > > > drivers/gpu/drm/i915/i915_reg.h | 8
> > > > > > drivers/gpu/drm/i915/intel_psr.c | 3 ++-
> > > > > > 3 files changed, 44 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > index 44eef355e12c..e94a835b7515 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > > ironlake_rps_change_irq_handler(dev_priv);
> > > > > > }
> > > > > >
> > > > > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > > > > > *dev_priv)
> > > > > > +{
> > > > > > + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > > > > +
> > > > > > + if (edp_psr_iir & EDP_PSR_ERROR)
> > > > > > + DRM_DEBUG_KMS("PSR error\n");
> > > > > > +
> > > > > > + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > > > > + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > > > >
> > > > > I doubt we want to have the entry/exit interrupts generate all this
> > > > > noise in dmesg all the time. We should probably only enable the
> > > > > interrupts for testing. The error interrupt I suppose we want always,
> > > > > might even want DRM_ERROR on it.
> > > >
> > > > I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.
> > >
> > > Right. It's a bit hard to read this with stuff getting
> > > added/remove/moved more or less randomly.
> > >
> > > >
> > > > >
> > > > > > + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > > > > > + }
> > > > > > +
> > > > > > + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > > > > + DRM_DEBUG_KMS("PSR exit completed\n");
> > > > > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > > > > + }
> > > > > > +
> > > > > > + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > > > > > +}
> > > > > > +
> > > > > > static void ivb_display_irq_handler(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > u32 de_iir)
> > > > > > {
> > > > > > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > > if (de_iir & DE_ERR_INT_IVB)
> > > > > > ivb_err_int_handler(dev_priv);
> > > > > >
> > > > > > + if (de_iir & DE_EDP_PSR_INT_HSW)
> > > > > > + hsw_edp_psr_irq_handler(dev_priv);
> > > > > > +
> > > > > > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > > > > > dp_aux_irq_handler(dev_priv);
> > > > > >
> > > > > > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct
> > > > > > drm_device *dev)
> > > > > > if (IS_GEN7(dev_priv))
> > > > > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > > > >
> > > > > > + if (IS_HASWELL(dev_priv)) {
> > > > > > + I915_WRITE(EDP_PSR_IMR, 0x);
> > > > > > + I915_WRITE(EDP_PSR_IIR, 0x);
> > > > > > + }
> > > > > > +
> > > > > > gen5_gt_irq_reset(dev_priv);
> > > > > >
> > > > > > ibx_irq_reset(dev_priv);
> > > > > > @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct
> > > > > > drm_device *dev)
> > > > > > DE_DP_A_HOTPLUG);
> > > > > > }
> > > > > >
> > > > > > + if (IS_HASWELL(dev_priv)) {
> > > > > > + gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> > > > > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > > > > + display_mask |= DE_EDP_P
[Intel-gfx] [PATCH v4] drm/i915: Use correct reST syntax for WOPCM and GuC kernel-doc diagrams
GuC Address Space and WOPCM Layout diagrams won't be generated correctly by sphinx build if not using proper reST syntax. This patch uses reST literal blocks to make sure GuC Address Space and WOPCM Layout diagrams to be generated correctly, and it also corrects some errors in the diagram description. v2: - Fixed errors in diagram description v3: - Updated GuC Address Space kernel-doc based on Michal's suggestion v4: - Added WOPCM layout and GuC address space docs into i915.rst (Joonas) Signed-off-by: Jackie Li Cc: Michal Wajdeczko Cc: Sagar Arun Kamble Cc: Joonas Lahtinen --- Documentation/gpu/i915.rst | 15 ++ drivers/gpu/drm/i915/intel_guc.c | 56 -- drivers/gpu/drm/i915/intel_wopcm.c | 44 -- 3 files changed, 67 insertions(+), 48 deletions(-) diff --git a/Documentation/gpu/i915.rst b/Documentation/gpu/i915.rst index 41dc881..7ecad71 100644 --- a/Documentation/gpu/i915.rst +++ b/Documentation/gpu/i915.rst @@ -335,6 +335,15 @@ objects, which has the goal to make space in gpu virtual address spaces. .. kernel-doc:: drivers/gpu/drm/i915/i915_gem_shrinker.c :internal: +WOPCM += + +WOPCM Layout + + +.. kernel-doc:: drivers/gpu/drm/i915/intel_wopcm.c + :doc: WOPCM Layout + GuC === @@ -359,6 +368,12 @@ GuC Firmware Layout .. kernel-doc:: drivers/gpu/drm/i915/intel_guc_fwif.h :doc: GuC Firmware Layout +GuC Address Space +- + +.. kernel-doc:: drivers/gpu/drm/i915/intel_guc.c + :doc: GuC Address Space + Tracing === diff --git a/drivers/gpu/drm/i915/intel_guc.c b/drivers/gpu/drm/i915/intel_guc.c index 8f93f5b..c5f64c7 100644 --- a/drivers/gpu/drm/i915/intel_guc.c +++ b/drivers/gpu/drm/i915/intel_guc.c @@ -494,35 +494,37 @@ int intel_guc_resume(struct intel_guc *guc) /** * DOC: GuC Address Space * - * The layout of GuC address space is shown as below: + * The layout of GuC address space is shown below: * - *+==> ++ <== GUC_GGTT_TOP - *^|| - *||| - *||DRAM| - *|| Memory | - *||| - * GuC || - * Address +> ++ <== WOPCM Top - * Space ^ | HW contexts RSVD | - *| | |WOPCM | - *| | +==> ++ <== GuC WOPCM Top - *|GuC^|| - *|GGTT ||| - *|Pin GuC |GuC | - *|Bias WOPCM | WOPCM| - *| |Size || - *| | ||| - *v v v|| - *+=+=+==> ++ <== GuC WOPCM Base - * | Non-GuC WOPCM| - * | (HuC/Reserved) | - * ++ <== WOPCM Base + * :: * - * The lower part [0, GuC ggtt_pin_bias) is mapped to WOPCM which consists of - * GuC WOPCM and WOPCM reserved for other usage (e.g.RC6 context). The value of - * the GuC ggtt_pin_bias is determined by the actually GuC WOPCM size which is - * set in GUC_WOPCM_SIZE register. + * +==> ++ <== GUC_GGTT_TOP + * ^|| + * ||| + * ||DRAM| + * || Memory | + * ||| + *GuC || + * Address +> ++ <== WOPCM Top + * Space ^ | HW contexts RSVD | + * | | |WOPCM | + * | | +==> ++ <== GuC WOPCM Top + * |GuC^|| + * |GGTT ||| + * |Pin GuC |GuC | + * |Bias WOPCM | WOPCM| + * | |Size || + * | | ||| + * v v v|| + * +=+=+==> ++ <== GuC WOPCM Base + * | Non-GuC WOPCM| + * | (HuC/Reserved) | + * ++ <== WOPCM Base + * + * The lower part of GuC Address Space [0, ggtt_pin_bias) is mapped to WOPCM + * while upper part of GuC Address Space [ggtt_pin_bias, GUC_GGTT_TOP) is mapped + * to DRAM. The value of the GuC ggtt_pin_bias is determined by WOPCM size and + * actual GuC WOPCM size. */ /** diff --git a/drivers/gpu/drm/i915/intel_wopcm.c b/drivers/gpu/drm/i915/intel_wopcm.c index 4117886..74bf76f 100644 --- a/drivers/gpu/drm/i915/intel_wopcm.c +++ b/drivers/gpu/drm/
Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.
On Thu, 2018-03-22 at 21:08 +, Chris Wilson wrote:
> Quoting Dhinakaran Pandiyan (2018-03-20 22:41:51)
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index 64ecea80438d..a83d95b1b587 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct drm_i915_private
> > *dev_priv, u32 psr_iir)
> > {
> > u32 transcoders = BIT(TRANSCODER_EDP);
> > enum transcoder cpu_transcoder;
> > + ktime_t time_ns = ktime_get();
> > + unsigned long flags = 0;
> >
> > if (INTEL_GEN(dev_priv) >= 8)
> > transcoders |= BIT(TRANSCODER_A) |
> >BIT(TRANSCODER_B) |
> >BIT(TRANSCODER_C);
> >
> > + write_seqlock_irqsave(&dev_priv->psr.debug_lock, flags);
>
> You are inside a hardirq handler. irqsave/irqrestore are not required.
>
> Even a seqlock here looks overkill, but whatever. (I don't buy that you
> need that precise level of coordination for a slow debugfs interface.)
>
Looks like I'll make two reviewers happy without the seqlock, will
remove it in the next version :)
> > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > transcoders) {
> > + bool handled = false;
> > +
> > + /* PSR supported only on one transcoder currently */
> > + WARN_ON_ONCE(handled);
>
> Now this is just silly. At least get the check right.
Argh, I should have caught it. Thanks.
> -Chris
> ___
> 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 12/12] drm/i915/debugfs: Print how many blocks were sent in a selective update
On Thu, Mar 22, 2018 at 02:48:48PM -0700, José Roberto de Souza wrote:
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 40
> -
> drivers/gpu/drm/i915/i915_reg.h | 17
> 2 files changed, 56 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 3182e9a7cc5d..20985584cc0f 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2678,6 +2678,43 @@ static void psr_event_exit_sprintf(struct seq_file *m,
> u32 val,
> seq_puts(m, "\tPSR disabled\n");
> }
>
> +static void psr2_su_blocks_sprintf(struct seq_file *m,
> +struct drm_i915_private *dev_priv)
> +{
> + u32 val;
> + u16 su;
> +
> + val = I915_READ(EDP_PSR2_SU_STATUS);
> + su = val >> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_SHIFT;
> + su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N: %d\n", su);
> + su = val >> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_1_SHIFT;
> + su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-1: %d\n", su);
> + su = val >> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_2_SHIFT;
> + su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-2: %d\n", su);
> +
> + val = I915_READ(EDP_PSR2_SU_STATUS2);
> + su = val >> EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_3_SHIFT;
> + su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-3: %d\n", su);
> + su = val >> EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_4_SHIFT;
> + su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-4: %d\n", su);
> + su = val >> EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_5_SHIFT;
> + su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-5: %d\n", su);
> +
> + val = I915_READ(EDP_PSR2_SU_STATUS3);
> + su = val >> EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_6_SHIFT;
> + su &= EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-6: %d\n", su);
> + su = val >> EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_7_SHIFT;
> + su &= EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK;
> + seq_printf(m, "\tSU blocks in frame N-7: %d\n", su);
> +}
> +
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2766,8 +2803,9 @@ static int i915_edp_psr_status(struct seq_file *m, void
> *data)
> if (dev_priv->psr.psr2_enabled) {
> u32 psr2 = I915_READ(EDP_PSR2_STATUS);
>
> - seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> + seq_printf(m, "EDP_PSR2_STATUS: 0x%x [%s]\n",
> psr2, psr2_live_status(psr2));
> + psr2_su_blocks_sprintf(m, dev_priv);
> }
>
> if (dev_priv->psr.enabled) {
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 45f7703a9ee6..18af3e8fd4b6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3929,6 +3929,23 @@ enum {
> #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> #define EDP_PSR2_STATUS_STATE_SHIFT28
>
> +#define EDP_PSR2_SU_STATUS _MMIO(0x6F914)
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK 0x3FF
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_SHIFT0
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_1_SHIFT10
> +#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_2_SHIFT20
> +
> +#define EDP_PSR2_SU_STATUS2_MMIO(0x6F918)
> +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK0x3FF
> +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_3_SHIFT 0
> +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_4_SHIFT 10
> +#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_5_SHIFT 20
> +
> +#define EDP_PSR2_SU_STATUS3_MMIO(0x6F91C)
> +#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK0x3FF
> +#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_6_SHIFT 0
> +#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_7_SHIFT 10
> +
Couldn't we define it unified as:
+#define EDP_PSR2_SU_STATUS(frame) _MMIO(0x6F914 +
4 * frame / 3)
+#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK 0x3FF
+#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_SHIFT(frame) (frame % 3 * 10)
> /* VGA port control */
> #define ADPA _MMIO(0x61100)
> #define PCH_ADPA
Re: [Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit
On Thu, 2018-03-22 at 16:27 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza wrote:
> > This will be helpful to debug what hardware is actually tracking.
> >
> > Signed-off-by: José Roberto de Souza
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > ---
> > drivers/gpu/drm/i915/i915_debugfs.c | 47
> > +
> > drivers/gpu/drm/i915/i915_reg.h | 18 ++
> > 2 files changed, 65 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > b/drivers/gpu/drm/i915/i915_debugfs.c
> > index 0a0642c61cd0..3182e9a7cc5d 100644
> > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > @@ -2641,6 +2641,43 @@ static void
> > psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32 val)
> > seq_puts(m, "\tY-Coordinate valid\n");
> > }
> >
> > +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> > + bool psr2_enabled)
> > +{
> > + if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> > + seq_puts(m, "\tPSR2 watchdog timer expired\n");
> > + if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> > + seq_puts(m, "\tPSR2 disabled\n");
> > + if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> > + seq_puts(m, "\tSU dirty FIFO underrun\n");
> > + if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> > + seq_puts(m, "\tSU CRC FIFO underrun\n");
> > + if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> > + seq_puts(m, "\tGraphics reset\n");
> > + if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> > + seq_puts(m, "\tPCH interrupt\n");
> > + if (val & EDP_PSR_EVENT_MEMORY_UP)
> > + seq_puts(m, "\tMemory up\n");
> > + if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> > + seq_puts(m, "\tFront buffer modification\n");
> > + if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> > + seq_puts(m, "\tPSR watchdog timer expired\n");
> > + if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> > + seq_puts(m, "\tPIPE registers updated\n");
> > + if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> > + seq_puts(m, "\tRegister update\n");
> > + if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> > + seq_puts(m, "\tHDCP enabled\n");
> > + if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> > + seq_puts(m, "\tKVMR session enabled\n");
> > + if (val & EDP_PSR_EVENT_VBI_ENABLE)
> > + seq_puts(m, "\tVBI enabled\n");
> > + if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> > + seq_puts(m, "\tLPSP mode exited\n");
> > + if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> > + seq_puts(m, "\tPSR disabled\n");
> > +}
> > +
> > static int i915_edp_psr_status(struct seq_file *m, void *data)
> > {
> > struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct seq_file *m,
> > void *data)
> >
> > seq_printf(m, "Performance_Counter: %u\n", psrperf);
> > }
> > +
> > + if (INTEL_GEN(dev_priv) >= 9) {
> > + u32 val = I915_READ(EDP_PSR_EVENT);
>
> What I'm afraid here is that this really shows the last event or the first
> one after we cleared.
>
Both, the bits remain set unless cleared. I have plans of printing the
events out of the PSR exit irq handler. This really was one of the main
reasons to implement PSR interrupts. Since we get interrupt for each PSR
exit, we'll also print out the correct event that caused exit.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
Den 22.03.2018 21.27, skrev Ville Syrjala:
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.
The long term goal is to try and get rid of tinydrm.ko by moving stuff
elsewhere as it's kind of a middle layer. So I'd really like to avoid
adding a callback like this.
Hopefully we can work out a solution based on my suggestion in the
'drm: Eliminate plane->fb/crtc usage for atomic drivers' thread.
If we do need a hook, I prefer that we add it to
drm_simple_display_pipe_funcs.
Noralf.
Cc: "Noralf Trønnes"
Cc: David Lechner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 ++
drivers/gpu/drm/tinydrm/ili9225.c | 23 ++--
drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 ++
drivers/gpu/drm/tinydrm/repaper.c | 28
drivers/gpu/drm/tinydrm/st7586.c | 23 ++--
drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
include/drm/tinydrm/mipi-dbi.h | 4 +++-
include/drm/tinydrm/tinydrm-helpers.h | 5 +
include/drm/tinydrm/tinydrm.h | 4
10 files changed, 76 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
}
EXPORT_SYMBOL(tinydrm_merge_clips);
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+ struct tinydrm_device *tdev = fb->dev->dev_private;
+ struct drm_plane *plane = &tdev->pipe.plane;
+ int ret = 0;
+
+ drm_modeset_lock(&plane->mutex, NULL);
+
+ /* fbdev can flush even when we're not interested */
+ if (plane->state->fb == fb) {
+ mutex_lock(&tdev->dirty_lock);
+ ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+ mutex_unlock(&tdev->dirty_lock);
+ }
+
+ drm_modeset_unlock(&plane->mutex);
+
+ if (ret)
+ dev_err_once(fb->dev->dev,
+"Failed to update display %d\n", ret);
+
+ return ret;
+}
+EXPORT_SYMBOL(tinydrm_fb_dirty);
+
/**
* tinydrm_memcpy - Copy clip buffer
* @dst: Destination buffer
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index 089d22798c8b..0874e877b111 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
bool full;
void *tr;
- mutex_lock(&tdev->dirty_lock);
-
if (!mipi->enabled)
- goto out_unlock;
-
- /* fbdev can flush even when we're not interested */
- if (tdev->pipe.plane.fb != fb)
- goto out_unlock;
+ return 0;
full = tinydrm_merge_clips(&clip, clips, num_clips, flags,
fb->width, fb->height);
@@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
tr = mipi->tx_buf;
ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, &clip, swap);
if (ret)
- goto out_unlock;
+ return ret;
} else {
tr = cma_obj->vaddr;
}
@@ -159,20 +153,13 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
ret = mipi_dbi_command_buf(mipi, ILI9225_WRITE_DATA_TO_GRAM, tr,
(clip.x2 - clip.x1) * (clip.y2 - clip.y1) * 2);
-out_unlock:
- mutex_unlock(&tdev->dirty_lock);
-
- if (ret)
- dev_err_once(fb->dev->dev, "Failed to update display %d\n",
-ret);
-
return ret;
}
static const struct drm_framebuffer_funcs ili9225_fb_funcs = {
.destroy= drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
- .dirty = ili9225_fb_dirty,
+ .dirty = tinydrm_fb_dirty
Re: [Intel-gfx] [PATCH 10/12] drm/i915/debugfs: Print sink PSR state and debug info
On Thu, Mar 22, 2018 at 02:48:46PM -0700, José Roberto de Souza wrote:
please add some justification on why this is useful
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 54
> +
> 1 file changed, 54 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 16f9977995df..0a0642c61cd0 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2603,6 +2603,44 @@ static const char *psr2_live_status(u32 val)
> return "unknown";
> }
>
> +static const char *psr_sink_self_refresh_status(u8 val)
> +{
> + static const char * const sink_status[] = {
> + "inactive",
> + "transitioning to active",
> + "active",
> + "active receiving selective update",
> + "transitioning to inactive",
> + "reserved",
> + "reserved",
> + "sink internal error"
> + };
> +
> + val &= DP_PSR_SINK_STATE_MASK;
> + if (val < ARRAY_SIZE(sink_status))
> + return sink_status[val];
> +
> + return "unknown";
> +}
> +
> +static void psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32
> val)
> +{
> + if (val & DP_PSR_STATE_BIT)
> + seq_puts(m, "\tPSR active\n");
I'm a bit confused here why we are printing status here again if we are adding
the
sink_status char * array with some status definition up there.
Any simplification possible?
> + if (val & DP_UPDATE_RFB_BIT)
> + seq_puts(m, "\tUpdate RFB\n");
> + if (val & DP_CRC_VALID_BIT)
> + seq_puts(m, "\tCRC valid\n");
> + if (val & DP_SU_VALID)
> + seq_puts(m, "\tSU valid\n");
> + if (val & DP_FIRST_SCAN_LINE_SU_REGION)
> + seq_puts(m, "\tFirst scan line of the SU region\n");
> + if (val & DP_LAST_SCAN_LINE_SU_REGION)
> + seq_puts(m, "\tLast scan line of the SU region\n");
> + if (val & DP_Y_COORDINATE_VALID)
> + seq_puts(m, "\tY-Coordinate valid\n");
> +}
> +
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2684,6 +2722,22 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
> seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
> psr2, psr2_live_status(psr2));
> }
> +
> + if (dev_priv->psr.enabled) {
> + struct drm_dp_aux *aux = &dev_priv->psr.enabled->aux;
> + u8 val;
> +
> + if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) == 1)
> + seq_printf(m, "Sink self refresh status: 0x%x [%s]\n",
> +val, psr_sink_self_refresh_status(val));
> +
> + if (drm_dp_dpcd_readb(aux, DP_LAST_RECEIVED_PSR_SDP, &val)
> + == 1) {
> + seq_printf(m, "Sink last received PSR SDP: 0x%x\n",
> +val);
> + psr_sink_last_received_psr_sdp_sprintf(m, val);
> + }
> + }
> mutex_unlock(&dev_priv->psr.lock);
>
> intel_runtime_pm_put(dev_priv);
> --
> 2.16.2
>
> ___
> 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 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers
Den 22.03.2018 19.49, skrev Ville Syrjälä:
On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote:
tinydrm is also using plane->fb:
$ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/
drivers/gpu/drm/tinydrm/repaper.c: if (tdev->pipe.plane.fb != fb)
drivers/gpu/drm/tinydrm/mipi-dbi.c: if (tdev->pipe.plane.fb != fb)
drivers/gpu/drm/tinydrm/mipi-dbi.c: struct drm_framebuffer *fb =
mipi->tinydrm.pipe.plane.fb;
Oh dear, and naturally it's the most annoying one of the bunch. So we
want to take the plane lock in the fb.dirty() hook to look at the fb,
but mipi-dbi.c calls that directly from the bowels of its
.atomic_enable() hook. So that would deadlock pretty neatly if the
commit happens while already holding the lock.
So we'd either need to plumb an acquire context into fb.dirty(),
or maybe have tinydrm provide a lower level lockless dirty() hook
that gets called by both (there are just too many layers in this
particular cake to immediately see where such a hook would be best
placed). Or maybe there's some other solution I didn't think of.
Looking at this I'm also left wondering how this is supposed
handle fb.dirty() getting called concurrently with a modeset.
The dirty_mutex only seems to offer any protection for
fb.dirty() against another fb.dirty()...
I have been waiting for the 'page-flip with damage'[1] work to come to
fruition so I could handle all flushing during atomic commit.
The idea is to use the same damage rect for a generic dirtyfb callback.
Maybe a temporary tinydrm specific solution is possible until that work
lands, but I don't know enough about how to implement such a dirtyfb
callback.
I imagine it could look something like this:
struct tinydrm_device {
+ struct drm_clip_rect dirtyfb_rect;
};
static int tinydrm_fb_dirty(struct drm_framebuffer *fb,
struct drm_file *file_priv,
unsigned int flags, unsigned int color,
struct drm_clip_rect *clips,
unsigned int num_clips)
{
struct tinydrm_device *tdev = fb->dev->dev_private;
struct drm_framebuffer *planefb;
/* Grab whatever lock needed to check this */
planefb = tdev->pipe.plane.state->fb;
/* fbdev can flush even when we're not interested */
if (fb != planefb)
return 0;
/* Protect dirtyfb_rect with a lock */
tinydrm_merge_clips(&tdev->dirty_rectfb, clips, num_clips, flags,
fb->width, fb->height);
/*
* Somehow do an atomic commit that results in the atomic update
* callback being called
*/
ret = drm_atomic_commit(state);
...
}
static void mipi_dbi_flush(struct drm_framebuffer *fb,
struct drm_clip_rect *clip)
{
/* Flush out framebuffer */
}
void mipi_dbi_pipe_update(struct drm_simple_display_pipe *pipe,
struct drm_plane_state *old_state)
{
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
struct drm_framebuffer *fb = pipe->plane.state->fb;
struct drm_crtc *crtc = &tdev->pipe.crtc;
if (!fb || (fb == old_state->fb && !tdev->dirty_rect.x2))
goto out_vblank;
/* Don't flush if the controller isn't initialized yet */
if (!mipi->enabled)
goto out_vblank;
if (fb != old_state->fb) { /* Page flip or new, flush all */
mipi_dbi_flush(fb, NULL);
} else { /* dirtyfb ioctl */
mipi_dbi_flush(fb, &tdev->dirtyfb_rect);
memset(&tdev->dirtyfb_rect, 0, sizeof(tdev->dirtyfb_rect));
}
out_vblank:
if (crtc->state->event) {
spin_lock_irq(&crtc->dev->event_lock);
drm_crtc_send_vblank_event(crtc, crtc->state->event);
spin_unlock_irq(&crtc->dev->event_lock);
crtc->state->event = NULL;
}
}
This is called from the driver pipe enable callback after the controller
has been initialized:
void mipi_dbi_pipe_enable(struct drm_simple_display_pipe *pipe,
struct drm_crtc_state *crtc_state)
{
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
- struct drm_framebuffer *fb = pipe->plane.fb;
+ struct drm_framebuffer *fb = pipe->plane.state->fb;
DRM_DEBUG_KMS("\n");
mipi->enabled = true;
- if (fb)
- fb->funcs->dirty(fb, NULL, 0, 0, NULL, 0);
+ mipi_dbi_flush(fb, NULL);
tinydrm_enable_backlight(mipi->backlight);
}
I can make patches if this makes any sense and you can help me with the
dirtyfb implementation.
Noralf.
[1]
https://lists.freedesktop.org/archives/dri-devel/2017-December/161003.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit
On Thu, Mar 22, 2018 at 02:48:47PM -0700, José Roberto de Souza wrote:
> This will be helpful to debug what hardware is actually tracking.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_debugfs.c | 47
> +
> drivers/gpu/drm/i915/i915_reg.h | 18 ++
> 2 files changed, 65 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 0a0642c61cd0..3182e9a7cc5d 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2641,6 +2641,43 @@ static void
> psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32 val)
> seq_puts(m, "\tY-Coordinate valid\n");
> }
>
> +static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
> +bool psr2_enabled)
> +{
> + if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
> + seq_puts(m, "\tPSR2 watchdog timer expired\n");
> + if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
> + seq_puts(m, "\tPSR2 disabled\n");
> + if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
> + seq_puts(m, "\tSU dirty FIFO underrun\n");
> + if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
> + seq_puts(m, "\tSU CRC FIFO underrun\n");
> + if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
> + seq_puts(m, "\tGraphics reset\n");
> + if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
> + seq_puts(m, "\tPCH interrupt\n");
> + if (val & EDP_PSR_EVENT_MEMORY_UP)
> + seq_puts(m, "\tMemory up\n");
> + if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
> + seq_puts(m, "\tFront buffer modification\n");
> + if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
> + seq_puts(m, "\tPSR watchdog timer expired\n");
> + if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
> + seq_puts(m, "\tPIPE registers updated\n");
> + if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
> + seq_puts(m, "\tRegister update\n");
> + if (val & EDP_PSR_EVENT_HDCP_ENABLE)
> + seq_puts(m, "\tHDCP enabled\n");
> + if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
> + seq_puts(m, "\tKVMR session enabled\n");
> + if (val & EDP_PSR_EVENT_VBI_ENABLE)
> + seq_puts(m, "\tVBI enabled\n");
> + if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
> + seq_puts(m, "\tLPSP mode exited\n");
> + if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
> + seq_puts(m, "\tPSR disabled\n");
> +}
> +
> static int i915_edp_psr_status(struct seq_file *m, void *data)
> {
> struct drm_i915_private *dev_priv = node_to_i915(m->private);
> @@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct seq_file *m,
> void *data)
>
> seq_printf(m, "Performance_Counter: %u\n", psrperf);
> }
> +
> + if (INTEL_GEN(dev_priv) >= 9) {
> + u32 val = I915_READ(EDP_PSR_EVENT);
What I'm afraid here is that this really shows the last event or the first one
after we cleared.
> +
> + seq_printf(m, "Event triggered PSR exit: 0x%x\n", val);
> + psr_event_exit_sprintf(m, val, dev_priv->psr.psr2_enabled);
> + /* clean events */
> + I915_WRITE(EDP_PSR_EVENT, val);
And to clear do we really need to set the bits or clear the bits?
> + }
> +
> if (dev_priv->psr.psr2_enabled) {
> u32 psr2 = I915_READ(EDP_PSR2_STATUS);
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index e660c8a707cf..45f7703a9ee6 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3907,6 +3907,24 @@ enum {
> #define EDP_PSR2_IDLE_FRAME_MASK 0xf
> #define EDP_PSR2_IDLE_FRAME_SHIFT 0
>
> +#define EDP_PSR_EVENT_MMIO(0x6f848)
> +#define EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE (1 << 17)
> +#define EDP_PSR_EVENT_PSR2_DISABLED (1 << 16)
> +#define EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN(1 << 15)
> +#define EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN (1 << 14)
> +#define EDP_PSR_EVENT_GRAPHICS_RESET(1 << 12)
> +#define EDP_PSR_EVENT_PCH_INTERRUPT (1 << 11)
> +#define EDP_PSR_EVENT_MEMORY_UP (1 << 10)
> +#define EDP_PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
> +#define EDP_PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
> +#define EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
> +#define EDP_PSR_EVENT_REGISTER_UPDATE (1 << 5)
> +#define EDP_PSR_EVENT_HDCP_ENABLE (1 << 4)
> +#define EDP_PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
> +#define EDP_PSR_EVENT_VBI_ENABLE(1 << 2)
> +#define EDP_PSR_EVENT_LPSP_MODE_EXIT(1 << 1)
> +#define EDP_PSR_EVENT_PSR_DISABLE (1 << 0)
> +
> #define EDP_PSR2_STATUS _MMIO(0x6f940)
> #
Re: [Intel-gfx] [PATCH 02/12] drm: Add DP last received PSR SDP VSC register and bits
On Thu, Mar 22, 2018 at 02:48:38PM -0700, José Roberto de Souza wrote: > This is a register to help debug what is in the last SDP VSC > packet revived by sink. > > Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi (just looking to 1.4b one, but the versions on the comments seems right) > --- > include/drm/drm_dp_helper.h | 9 + > 1 file changed, 9 insertions(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 0bac0c7d0dec..91c9bcd4196f 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -795,6 +795,15 @@ > # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK (0xf << 4) > # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT4 > > +#define DP_LAST_RECEIVED_PSR_SDP 0x200a /* eDP 1.2 */ > +# define DP_PSR_STATE_BIT(1 << 0) /* eDP 1.2 */ > +# define DP_UPDATE_RFB_BIT (1 << 1) /* eDP 1.2 */ > +# define DP_CRC_VALID_BIT(1 << 2) /* eDP 1.2 */ > +# define DP_SU_VALID (1 << 3) /* eDP 1.4 */ > +# define DP_FIRST_SCAN_LINE_SU_REGION(1 << 4) /* eDP 1.4 */ > +# define DP_LAST_SCAN_LINE_SU_REGION (1 << 5) /* eDP 1.4 */ > +# define DP_Y_COORDINATE_VALID (1 << 6) /* eDP 1.4a */ > + > #define DP_RECEIVER_ALPM_STATUS 0x200b /* eDP 1.4 */ > # define DP_ALPM_LOCK_TIMEOUT_ERROR (1 << 0) > > -- > 2.16.2 > > ___ > 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 14/17] drm/i915/icl: Calculate link clock using the new registers
Em Qui, 2018-02-22 às 00:55 -0300, Paulo Zanoni escreveu:
> From: Arkadiusz Hiler
>
> Start using the new registers for ICL and on.
This patch doesn't make sense at this point of the series since we
don't run this code on ICL. I'll put it at the correct series.
>
> Cc: Manasi Navare
> Cc: Rodrigo Vivi
> Reviewed-by: Paulo Zanoni
> Signed-off-by: Arkadiusz Hiler
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 9 +++--
> 1 file changed, 7 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 88a6c5107975..c1f1966d471c 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1371,8 +1371,13 @@ static int cnl_calc_wrpll_link(struct
> drm_i915_private *dev_priv,
> uint32_t cfgcr0, cfgcr1;
> uint32_t p0, p1, p2, dco_freq, ref_clock;
>
> - cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
> - cfgcr1 = I915_READ(CNL_DPLL_CFGCR1(pll_id));
> + if (INTEL_GEN(dev_priv) >= 11) {
> + cfgcr0 = I915_READ(ICL_DPLL_CFGCR0(pll_id));
> + cfgcr1 = I915_READ(ICL_DPLL_CFGCR1(pll_id));
> + } else {
> + cfgcr0 = I915_READ(CNL_DPLL_CFGCR0(pll_id));
> + cfgcr1 = I915_READ(CNL_DPLL_CFGCR1(pll_id));
> + }
>
> p0 = cfgcr1 & DPLL_CFGCR1_PDIV_MASK;
> p2 = cfgcr1 & DPLL_CFGCR1_KDIV_MASK;
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/12] drm/i915/psr: Set DPCD PSR2 enable bit when needed
On Thu, Mar 22, 2018 at 02:48:45PM -0700, José Roberto de Souza wrote: > In the 2 eDP1.4a pannels tested set or not set bit have no effect > but is better set it and comply with specification. > > Signed-off-by: José Roberto de Souza > Cc: Dhinakaran Pandiyan > Cc: Rodrigo Vivi looking at the spec it seems that we never *really* had enabled PSR2! =| Reviewed-by: Rodrigo Vivi > --- > drivers/gpu/drm/i915/intel_psr.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_psr.c > b/drivers/gpu/drm/i915/intel_psr.c > index 19ee6120d3cd..f5c3bcafde25 100644 > --- a/drivers/gpu/drm/i915/intel_psr.c > +++ b/drivers/gpu/drm/i915/intel_psr.c > @@ -278,19 +278,19 @@ static void hsw_psr_enable_sink(struct intel_dp > *intel_dp) > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > struct drm_device *dev = dig_port->base.base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > - > + u8 dpcd_val = DP_PSR_ENABLE; > > /* Enable ALPM at sink for psr2 */ > if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm) > drm_dp_dpcd_writeb(&intel_dp->aux, > DP_RECEIVER_ALPM_CONFIG, > DP_ALPM_ENABLE); > + > + if (dev_priv->psr.psr2_enabled) > + dpcd_val |= DP_PSR_ENABLE_PSR2; > if (dev_priv->psr.link_standby) > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, > -DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE); > - else > - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, > -DP_PSR_ENABLE); > + dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE; > + drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val); > > drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0); > } > -- > 2.16.2 > > ___ > 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 01/12] drm: Add DP PSR2 sink enable bit
On Thu, Mar 22, 2018 at 02:48:37PM -0700, José Roberto de Souza wrote: > To comply with eDP1.4a this bit should be set when enabling PSR2. > > Signed-off-by: José Roberto de Souza Reviewed-by: Rodrigo Vivi > --- > include/drm/drm_dp_helper.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h > index 62903bae0221..0bac0c7d0dec 100644 > --- a/include/drm/drm_dp_helper.h > +++ b/include/drm/drm_dp_helper.h > @@ -478,6 +478,7 @@ > # define DP_PSR_FRAME_CAPTURE(1 << 3) > # define DP_PSR_SELECTIVE_UPDATE (1 << 4) > # define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) > +# define DP_PSR_ENABLE_PSR2 (1 << 6) /* eDP 1.4a */ > > #define DP_ADAPTER_CTRL 0x1a0 > # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) > -- > 2.16.2 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement
On Thu, 2018-03-22 at 16:09 -0700, Rodrigo Vivi wrote:
> On Thu, Mar 22, 2018 at 02:48:40PM -0700, José Roberto de Souza
> wrote:
> > Move to only one place the sink requirements that the actual driver
> > needs to enable PSR2.
> >
> > Also intel_psr2_config_valid() is called every time the crtc config
> > is computed, wasting some time every time it was checking for
> > Y coordinate requirement.
> >
> > This allow us to nuke y_cord_support and some of VSC setup code
> > that
> > was handling a scenario that would never happen(PSR2 without Y
> > coordinate).
> >
> > Cc: Dhinakaran Pandiyan
> > Cc: Rodrigo Vivi
> > Signed-off-by: José Roberto de Souza
> > ---
> > drivers/gpu/drm/i915/i915_drv.h | 1 -
> > drivers/gpu/drm/i915/intel_psr.c | 46 +---
> >
> > 2 files changed, 19 insertions(+), 28 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 7fe00509e51a..cce32686fd75 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -603,7 +603,6 @@ struct i915_psr {
> > unsigned busy_frontbuffer_bits;
> > bool psr2_support;
> > bool link_standby;
> > - bool y_cord_support;
> > bool colorimetry_support;
> > bool alpm;
> > bool has_hw_tracking;
> > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > b/drivers/gpu/drm/i915/intel_psr.c
> > index d46320a451d9..23f38ab10636 100644
> > --- a/drivers/gpu/drm/i915/intel_psr.c
> > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp
> > *intel_dp)
> > intel_display_power_put(dev_priv,
> > psr_aux_domain(intel_dp));
> > }
> >
> > -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> > +static bool intel_dp_get_y_coord_required(struct intel_dp
> > *intel_dp)
>
> nip: I don't agree that required is a good name for this function
> call
> so maybe we should just leave status and minimize the change.
This is the name in the eDP spec: Y-coordinate Requirement of Sink
Device on PSR2 Selective Update
>
> > {
> > uint8_t psr_caps = 0;
> >
> > @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp
> > *intel_dp)
> > drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp-
> > >psr_dpcd,
> > sizeof(intel_dp->psr_dpcd));
> >
> > - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> > + if (intel_dp->psr_dpcd[0]) {
>
> hm? why?
A pannel that is PSR version 2, will not have any PSR enabled as
'intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED' and 'intel_dp-
>psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED' will be false.
>
> > dev_priv->psr.sink_support = true;
> > DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> > }
> >
> > if (INTEL_GEN(dev_priv) >= 9 &&
> > - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> > -
> > - dev_priv->psr.sink_support = true;
> > - dev_priv->psr.psr2_support = true;
> > + (intel_dp->psr_dpcd[0] ==
> > DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> > + /*
> > +* All panels that supports PSR version 03h (PSR2
> > +
> > +* Y-coordinate) can handle Y-coordinates in VSC
> > but we are
> > +* only sure that it is going to be used when
> > required by the
> > +* panel. This way panel is capable to do
> > selective update
> > +* without a aux frame sync.
> > +*
> > +* To support PSR version 02h and PSR version 03h
> > without
> > +* Y-coordinate requirement panels we would need
> > to enable
> > +* GTC first.
> > +*/
> > + dev_priv->psr.psr2_support =
> > intel_dp_get_y_coord_required(intel_dp);
>
> oh ok ok... now I saw why you changed to "required"
>
> But my question now is. Do we really need to check this bit?
>
> I believe with your change to check version 03h we don't need to
> check
> this requirement anymore.
> This looks like in the past we used that to workaround a way to
> identify
> if the panel was really y-coord... but now with 03h version we don't
> need
> to check if panel is requiring the y-coordination from the source,
> because
> we know what source is capable of.
We know that is capable of but we don't know if is going to be used by
the pannel, when pannels require the y-coordinate we are 100% sure that
it is going to use.
>
> > DRM_DEBUG_KMS("PSR2 %s on sink",
> > dev_priv->psr.psr2_support ?
> > "supported" : "not supported");
> >
> > if (dev_priv->psr.psr2_support) {
> > - dev_priv->psr.y_cord_support =
> > - intel_dp_get_y_cord_status(intel_d
> > p);
> > dev_priv->psr.colorimetry_support =
> > intel_dp_get_colorimetry_status(in
> > tel_dp);
> > dev_priv->psr.alpm =
> > @@ -191,16
Re: [Intel-gfx] [PATCH 08/12] drm/i915/psr: Cache sink synchronization latency
On Thu, Mar 22, 2018 at 02:48:44PM -0700, José Roberto de Souza wrote:
> This value do not change overtime so better cache it than
> fetch it every PSR enable.
>
> Signed-off-by: José Roberto de Souza
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 +
> drivers/gpu/drm/i915/intel_psr.c | 28
> 2 files changed, 17 insertions(+), 12 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a367fe5538ae..f79338821081 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -607,6 +607,7 @@ struct i915_psr {
> bool alpm;
> bool has_hw_tracking;
> bool psr2_enabled;
> + u8 sink_sync_latency;
>
> void (*enable_source)(struct intel_dp *,
> const struct intel_crtc_state *);
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index ad69722c329d..19ee6120d3cd 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -122,6 +122,18 @@ static bool intel_dp_get_alpm_status(struct intel_dp
> *intel_dp)
> return alpm_caps & DP_ALPM_CAP;
> }
>
> +static u8 intel_dp_get_sink_sync_latency(struct intel_dp *intel_dp)
> +{
> + u8 val = 0;
> +
> + if (drm_dp_dpcd_readb(&intel_dp->aux,
> + DP_SYNCHRONIZATION_LATENCY_IN_SINK, &val) == 1)
> + val &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
> + else
> + DRM_ERROR("Unable to get sink synchronization latency\n");
> + return val;
> +}
> +
> void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> {
> struct drm_i915_private *dev_priv =
> @@ -158,6 +170,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> intel_dp_get_colorimetry_status(intel_dp);
> dev_priv->psr.alpm =
> intel_dp_get_alpm_status(intel_dp);
> + dev_priv->psr.sink_sync_latency =
> + intel_dp_get_sink_sync_latency(intel_dp);
> }
> }
> }
> @@ -380,10 +394,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
>* with the 5 or 6 idle patterns.
>*/
> uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
> - uint32_t val;
> - uint8_t sink_latency;
> -
> - val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> + u32 val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
This belongs to the previous patch apparently. With this moved there keep my
rv-b there
and add my rv-b here...
>
> /* FIXME: selective update is probably totally broken because it doesn't
>* mesh at all with our frontbuffer tracking. And the hw alone isn't
> @@ -393,14 +404,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
> val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
> }
>
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> - DP_SYNCHRONIZATION_LATENCY_IN_SINK,
> - &sink_latency) == 1) {
> - sink_latency &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
> - } else {
> - sink_latency = 0;
> - }
> - val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
> + val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
>
> if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
> val |= EDP_PSR2_TP2_TIME_2500;
> --
> 2.16.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/12] drm/i915/psr: Use PSR2 macro for PSR2
On Thu, Mar 22, 2018 at 02:48:43PM -0700, José Roberto de Souza wrote:
> Cosmetic change.
>
> Signed-off-by: José Roberto de Souza
Reviewed-by: Rodrigo Vivi
> ---
> drivers/gpu/drm/i915/i915_reg.h | 3 ++-
> drivers/gpu/drm/i915/intel_psr.c | 2 +-
> 2 files changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 9c4be6bcd1ef..e660c8a707cf 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -3903,8 +3903,9 @@ enum {
> #define EDP_PSR2_TP2_TIME_MASK (3<<8)
> #define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
> #define EDP_PSR2_FRAME_BEFORE_SU_MASK (0xf<<4)
> -#define EDP_PSR2_IDLE_MASK 0xf
> #define EDP_PSR2_FRAME_BEFORE_SU(a)((a)<<4)
> +#define EDP_PSR2_IDLE_FRAME_MASK 0xf
> +#define EDP_PSR2_IDLE_FRAME_SHIFT 0
>
> #define EDP_PSR2_STATUS _MMIO(0x6f940)
> #define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index f73e2734a859..ad69722c329d 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -331,7 +331,7 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
> uint32_t val = EDP_PSR_ENABLE;
>
> val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
> - val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
> + val |= idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
>
> if (IS_HASWELL(dev_priv))
> val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
> --
> 2.16.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement
On Thu, Mar 22, 2018 at 02:48:40PM -0700, José Roberto de Souza wrote:
> Move to only one place the sink requirements that the actual driver
> needs to enable PSR2.
>
> Also intel_psr2_config_valid() is called every time the crtc config
> is computed, wasting some time every time it was checking for
> Y coordinate requirement.
>
> This allow us to nuke y_cord_support and some of VSC setup code that
> was handling a scenario that would never happen(PSR2 without Y
> coordinate).
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
> Signed-off-by: José Roberto de Souza
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_psr.c | 46
> +---
> 2 files changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 7fe00509e51a..cce32686fd75 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -603,7 +603,6 @@ struct i915_psr {
> unsigned busy_frontbuffer_bits;
> bool psr2_support;
> bool link_standby;
> - bool y_cord_support;
> bool colorimetry_support;
> bool alpm;
> bool has_hw_tracking;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index d46320a451d9..23f38ab10636 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp *intel_dp)
> intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
> }
>
> -static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
> +static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
nip: I don't agree that required is a good name for this function call
so maybe we should just leave status and minimize the change.
> {
> uint8_t psr_caps = 0;
>
> @@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
> drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
>sizeof(intel_dp->psr_dpcd));
>
> - if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
> + if (intel_dp->psr_dpcd[0]) {
hm? why?
> dev_priv->psr.sink_support = true;
> DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
> }
>
> if (INTEL_GEN(dev_priv) >= 9 &&
> - (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> -
> - dev_priv->psr.sink_support = true;
> - dev_priv->psr.psr2_support = true;
> + (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
> + /*
> + * All panels that supports PSR version 03h (PSR2 +
> + * Y-coordinate) can handle Y-coordinates in VSC but we are
> + * only sure that it is going to be used when required by the
> + * panel. This way panel is capable to do selective update
> + * without a aux frame sync.
> + *
> + * To support PSR version 02h and PSR version 03h without
> + * Y-coordinate requirement panels we would need to enable
> + * GTC first.
> + */
> + dev_priv->psr.psr2_support =
> intel_dp_get_y_coord_required(intel_dp);
oh ok ok... now I saw why you changed to "required"
But my question now is. Do we really need to check this bit?
I believe with your change to check version 03h we don't need to check
this requirement anymore.
This looks like in the past we used that to workaround a way to identify
if the panel was really y-coord... but now with 03h version we don't need
to check if panel is requiring the y-coordination from the source, because
we know what source is capable of.
> DRM_DEBUG_KMS("PSR2 %s on sink",
> dev_priv->psr.psr2_support ? "supported" : "not
> supported");
>
> if (dev_priv->psr.psr2_support) {
> - dev_priv->psr.y_cord_support =
> - intel_dp_get_y_cord_status(intel_dp);
> dev_priv->psr.colorimetry_support =
> intel_dp_get_colorimetry_status(intel_dp);
> dev_priv->psr.alpm =
> @@ -191,16 +198,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
> memset(&psr_vsc, 0, sizeof(psr_vsc));
> psr_vsc.sdp_header.HB0 = 0;
> psr_vsc.sdp_header.HB1 = 0x7;
> - if (dev_priv->psr.colorimetry_support &&
> - dev_priv->psr.y_cord_support) {
> + if (dev_priv->psr.colorimetry_support) {
> psr_vsc.sdp_header.HB2 = 0x5;
> psr_vsc.sdp_header.HB3 = 0x13;
> - } else if (dev_priv->psr.y_cord_support) {
> + } else {
> psr_vsc.sdp_header.HB2 = 0x4;
> psr_vsc.sdp_header.HB3 = 0xe;
> - } else {
> -
Re: [Intel-gfx] [PATCH 11/17] drm/i915/icl: Implement voltage swing programming sequence for MG PHY DDI
Em Qui, 2018-02-22 às 00:55 -0300, Paulo Zanoni escreveu:
> From: Manasi Navare
>
> This sequence is used to setup voltage swing before enabling MG PHY
> DDI
> as well as for changing the voltage during DisplayPort Link training.
>
> For ICL, there are two types of DDIs. This sequence needs to be used
> for MG PHY DDI which is ports C-F.
>
> v5 (from Paulo):
> * Checkpatch.
> v4 (from Paulo):
> * Fix bogus error message
> * Fix copy+paste bugs (missing s/TX1/TX2/ after copy+paste)
> * Use the new mask names
> * Stay under 80 columns
> * Add some blank lines
> v3:
> * Clear the regs before writing (Paulo)
> v2:
> * Rename to MG PHY in the function def (Jani Nikula)
> * Rebase on top of new revision of other patches in series
The spec has changed since this patch was written. There are two new
tables to consider.
Manasi, can you look into this?
>
> Cc: Rodrigo Vivi
> Cc: Jani Nikula
> Signed-off-by: Manasi Navare
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 85
> +++-
> 1 file changed, 83 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 98471b5c5f70..88a6c5107975 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -2364,6 +2364,88 @@ static void
> icl_combo_phy_ddi_vswing_sequence(struct intel_encoder *encoder, u32
> I915_WRITE(ICL_PORT_TX_DW5_GRP(port), val);
> }
>
> +static void icl_mg_phy_ddi_vswing_sequence(struct intel_encoder
> *encoder,
> +u32 level)
> +{
> + struct drm_i915_private *dev_priv = to_i915(encoder-
> >base.dev);
> + enum port port = encoder->port;
> + const struct icl_mg_phy_ddi_buf_trans *ddi_translations;
> + u32 n_entries, val;
> + int ln;
> +
> + /*
> + * Values are listed in voltage swing programming tables.
> + * Same values for all voltage levels and port types.
> + */
> + n_entries = ARRAY_SIZE(icl_mg_phy_ddi_translations);
> + ddi_translations = icl_mg_phy_ddi_translations;
> + /* The table does not have values for level 3 and level 9.
> */
> + if (level >= n_entries || level == 3 || level == 9) {
> + DRM_DEBUG_KMS("DDI translation not found for level
> %d. Using %d instead.",
> + level, n_entries - 2);
> + level = n_entries - 2;
> + }
> +
> + /* Set MG_TX_LINK_PARAMS cri_use_fs32 to 0. */
> + for (ln = 0; ln < 2; ln++) {
> + val = I915_READ(ICL_PORT_MG_TX1_LINK_PARAMS(port,
> ln));
> + val &= ~CRI_USE_FS32;
> + I915_WRITE(ICL_PORT_MG_TX1_LINK_PARAMS(port, ln),
> val);
> +
> + val = I915_READ(ICL_PORT_MG_TX2_LINK_PARAMS(port,
> ln));
> + val &= ~CRI_USE_FS32;
> + I915_WRITE(ICL_PORT_MG_TX2_LINK_PARAMS(port, ln),
> val);
> + }
> +
> + /* Program MG_TX_SWINGCTRL with values from vswing table */
> + for (ln = 0; ln < 2; ln++) {
> + val = I915_READ(ICL_PORT_MG_TX1_SWINGCTRL(port,
> ln));
> + val &= ~CRI_TXDEEMPH_OVERRIDE_17_12_MASK;
> + val |= CRI_TXDEEMPH_OVERRIDE_17_12(
> + ddi_translations[level].cri_txdeemph_overrid
> e_17_12);
> + I915_WRITE(ICL_PORT_MG_TX1_SWINGCTRL(port, ln),
> val);
> +
> + val = I915_READ(ICL_PORT_MG_TX2_SWINGCTRL(port,
> ln));
> + val &= ~CRI_TXDEEMPH_OVERRIDE_17_12_MASK;
> + val |= CRI_TXDEEMPH_OVERRIDE_17_12(
> + ddi_translations[level].cri_txdeemph_overrid
> e_17_12);
> + I915_WRITE(ICL_PORT_MG_TX2_SWINGCTRL(port, ln),
> val);
> + }
> +
> + /* Program MG_TX_DRVCTRL with values from vswing table */
> + for (ln = 0; ln < 2; ln++) {
> + val = I915_READ(ICL_PORT_MG_TX1_DRVCTRL(port, ln));
> + val &= ~(CRI_TXDEEMPH_OVERRIDE_11_6_MASK |
> + CRI_TXDEEMPH_OVERRIDE_5_0_MASK);
> + val |= CRI_TXDEEMPH_OVERRIDE_5_0(
> + ddi_translations[level].cri_txdeemph_overrid
> e_5_0) |
> +CRI_TXDEEMPH_OVERRIDE_11_6(
> + ddi_translations[level].cri_txdeemph_overrid
> e_11_6) |
> +CRI_TXDEEMPH_OVERRIDE_EN;
> + I915_WRITE(ICL_PORT_MG_TX1_DRVCTRL(port, ln), val);
> +
> + val = I915_READ(ICL_PORT_MG_TX2_DRVCTRL(port, ln));
> + val &= ~(CRI_TXDEEMPH_OVERRIDE_11_6_MASK |
> + CRI_TXDEEMPH_OVERRIDE_5_0_MASK);
> + val |= CRI_TXDEEMPH_OVERRIDE_5_0(
> + ddi_translations[level].cri_txdeemph_overrid
> e_5_0) |
> +CRI_TXDEEMPH_OVERRIDE_11_6(
> + ddi_translations[level].cri_txdeemph_overrid
> e_11_6) |
> + CRI_TXDEEMPH_OVERRIDE_EN;
> + I915_WRITE(ICL_PORT_MG_TX2_DRVCTRL(port, ln), val);
> + }
> + /* Program MG_T
Re: [Intel-gfx] [PATCH 03/12] drm/i915/psr: Nuke aux frame sync
On Thu, Mar 22, 2018 at 02:48:39PM -0700, José Roberto de Souza wrote:
> Without GTC enabled hardware is sending dummy aux frame sync value
> that is not useful to sink do selective update, that is why it also
> require that sink supports and requires the y-coordinate.
>
> So removing everything related to aux frame sync, if GTC is enabled
> we can bring this back.
>
> Cc: Dhinakaran Pandiyan
> Cc: Rodrigo Vivi
Cc: Vathsala Nagaraju
> Signed-off-by: José Roberto de Souza
Acked-by: Rodrigo Vivi
(but I would like to give a time for Vathsala to comment on this)
> ---
> drivers/gpu/drm/i915/i915_drv.h | 1 -
> drivers/gpu/drm/i915/intel_psr.c | 23 +--
> 2 files changed, 1 insertion(+), 23 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index c9c3b2ba6a86..7fe00509e51a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -602,7 +602,6 @@ struct i915_psr {
> struct delayed_work work;
> unsigned busy_frontbuffer_bits;
> bool psr2_support;
> - bool aux_frame_sync;
> bool link_standby;
> bool y_cord_support;
> bool colorimetry_support;
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index b8e083e10029..d46320a451d9 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -137,16 +137,9 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
>
> if (INTEL_GEN(dev_priv) >= 9 &&
> (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
> - uint8_t frame_sync_cap;
>
> dev_priv->psr.sink_support = true;
> - if (drm_dp_dpcd_readb(&intel_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
> - &frame_sync_cap) != 1)
> - frame_sync_cap = 0;
> - dev_priv->psr.aux_frame_sync = frame_sync_cap &
> DP_AUX_FRAME_SYNC_CAP;
> - /* PSR2 needs frame sync as well */
> - dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
> + dev_priv->psr.psr2_support = true;
> DRM_DEBUG_KMS("PSR2 %s on sink",
> dev_priv->psr.psr2_support ? "supported" : "not
> supported");
>
> @@ -269,11 +262,6 @@ static void hsw_psr_enable_sink(struct intel_dp
> *intel_dp)
> struct drm_i915_private *dev_priv = to_i915(dev);
>
>
> - /* Enable AUX frame sync at sink */
> - if (dev_priv->psr.aux_frame_sync)
> - drm_dp_dpcd_writeb(&intel_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> - DP_AUX_FRAME_SYNC_ENABLE);
> /* Enable ALPM at sink for psr2 */
> if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
> drm_dp_dpcd_writeb(&intel_dp->aux,
> @@ -712,11 +700,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
> i915_reg_t psr_status;
> u32 psr_status_mask;
>
> - if (dev_priv->psr.aux_frame_sync)
> - drm_dp_dpcd_writeb(&intel_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> - 0);
> -
> if (dev_priv->psr.psr2_support) {
> psr_status = EDP_PSR2_STATUS;
> psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
> @@ -860,10 +843,6 @@ static void intel_psr_exit(struct drm_i915_private
> *dev_priv)
> return;
>
> if (HAS_DDI(dev_priv)) {
> - if (dev_priv->psr.aux_frame_sync)
> - drm_dp_dpcd_writeb(&intel_dp->aux,
> - DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
> - 0);
> if (dev_priv->psr.psr2_support) {
> val = I915_READ(EDP_PSR2_CTL);
> WARN_ON(!(val & EDP_PSR2_ENABLE));
> --
> 2.16.2
>
> ___
> 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 08/17] drm/i915/icl: Implement voltage swing programming sequence for Combo PHY DDI
Em Qui, 2018-02-22 às 00:55 -0300, Paulo Zanoni escreveu:
> From: Manasi Navare
>
> This is an important part of the DDI initalization as well as
> for changing the voltage during DisplayPort link training.
>
> The Voltage swing seqeuence is similar to Cannonlake.
> However it has different register definitions and hence
> it makes sense to create a separate vswing sequence and
> program functions for ICL to leave room for more changes
> in case the Bspec changes later and deviates from CNL sequence.
>
> v2:
> Use ~TAP3_DISABLE for enbaling that bit (Jani Nikula)
>
> v3:
> * Use dw4_scaling column for PORT_TX_DW4 values (Rodrigo)
>
> v4:
> * Call it combo_vswing, use switch statement (Paulo)
>
> v5 (from Paulo):
> * Fix a typo.
> * s/rate < 60/rate <= 60/.
> * Don't remove blank lines that should be there.
>
> v6:
> * Rebased by Rodrigo on top of Cannonlake changes
> where non vswing sequences are not aligned with iboost
> anymore.
>
> v7: Another rebase after an upstream rework.
>
> v8 (from Paulo):
> * Adjust the code to the upstream output type changes.
> * Squash the patch that moved some functions up.
> * Merge both get_combo_buf_trans functions in order to simplify the
> code.
> * Change the changelog format.
>
> Cc: Jani Nikula
> Reviewed-by: Paulo Zanoni (v5)
> Signed-off-by: Manasi Navare
> Signed-off-by: Rodrigo Vivi
> Signed-off-by: Paulo Zanoni
> ---
> drivers/gpu/drm/i915/intel_ddi.c | 189
> ++-
> 1 file changed, 186 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index 0a4683991ec2..c38873cb98ca 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -849,6 +849,45 @@ cnl_get_buf_trans_edp(struct drm_i915_private
> *dev_priv, int *n_entries)
> }
> }
>
> +static const struct icl_combo_phy_ddi_buf_trans *
> +icl_get_combo_buf_trans(struct drm_i915_private *dev_priv, enum port
> port,
> + int type, int *n_entries)
> +{
> + u32 voltage = I915_READ(ICL_PORT_COMP_DW3(port)) &
> VOLTAGE_INFO_MASK;
> +
> + if (type == INTEL_OUTPUT_EDP && dev_priv-
> >vbt.edp.low_vswing) {
> + switch (voltage) {
> + case VOLTAGE_INFO_0_85V:
> + *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_85V);
> + return
> icl_combo_phy_ddi_translations_edp_0_85V;
> + case VOLTAGE_INFO_0_95V:
> + *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_0_95V);
> + return
> icl_combo_phy_ddi_translations_edp_0_95V;
> + case VOLTAGE_INFO_1_05V:
> + *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_edp_1_05V);
> + return
> icl_combo_phy_ddi_translations_edp_1_05V;
> + default:
> + MISSING_CASE(voltage);
> + return NULL;
> + }
> + } else {
> + switch (voltage) {
> + case VOLTAGE_INFO_0_85V:
> + *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_85V);
> + return
> icl_combo_phy_ddi_translations_dp_hdmi_0_85V;
> + case VOLTAGE_INFO_0_95V:
> + *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_0_95V);
> + return
> icl_combo_phy_ddi_translations_dp_hdmi_0_95V;
> + case VOLTAGE_INFO_1_05V:
> + *n_entries =
> ARRAY_SIZE(icl_combo_phy_ddi_translations_dp_hdmi_1_05V);
> + return
> icl_combo_phy_ddi_translations_dp_hdmi_1_05V;
> + default:
> + MISSING_CASE(voltage);
> + return NULL;
> + }
> + }
> +}
> +
> static int intel_ddi_hdmi_level(struct drm_i915_private *dev_priv,
> enum port port)
> {
> int n_entries, level, default_entry;
> @@ -2178,6 +2217,144 @@ static void cnl_ddi_vswing_sequence(struct
> intel_encoder *encoder,
> I915_WRITE(CNL_PORT_TX_DW5_GRP(port), val);
> }
>
> +static void icl_ddi_combo_vswing_program(struct drm_i915_private
> *dev_priv,
> + u32 level, enum port port,
> int type)
> +{
> + const struct icl_combo_phy_ddi_buf_trans *ddi_translations =
> NULL;
> + u32 n_entries, val;
> + int ln;
> +
> + ddi_translations = icl_get_combo_buf_trans(dev_priv, port,
> type,
> +&n_entries);
> + if (!ddi_translations)
> + return;
> +
> + if (level >= n_entries) {
> + DRM_DEBUG_KMS("DDI translation not found for level
> %d. Using %d instead.", level, n_entries - 1);
> + level = n_entries - 1;
> + }
> +
> + /* Set PORT_TX_DW5 Scaling Mode Sel to 110b. */
> + val = I915_READ(ICL_PORT_TX_DW5_LN0(port));
> + val &= ~SCALING_MODE_SEL_MASK;
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/3] tests/gem_eio: Speed up test execution
On 22/03/18 11:14, Chris Wilson wrote: Quoting Antonio Argenziano (2018-03-22 17:32:46) On 22/03/18 05:42, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-22 12:36:58) On 22/03/2018 11:39, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-22 11:17:11) trigger_reset(fd); + + /* HACK for CI */ + igt_assert(igt_nsec_elapsed(&ts) < 5e9); igt_seconds_elapsed() the approximation is worth the readability. In this case you might like to try igt_set_timeout(), as I think each subtest and exithandlers are in place to make them robust against premature failures. Well this was just to see that will happen on the shards here. As mentioned in the commit I get that yet unexplained GPU hang at subtest exit here. So the assert above is just to notice if the same happens on shards. And I was thinking it was a reasonable enhancement :) Probably more so for igt/gem_wait itself to ask that if we reset the request we are waiting upon it completes in a timely manner. (We don't care about wedged handling there, just reset handling.) How about checking for reset when we do gem_test_engine(), which seems to not fail on reset, (crudely https://paste.debian.net/1016059/)? I was thinking that the timeout would be good around the test as a whole, because it is now meant to be uberfast. Makes sense. Thanks, Antonio -Chris ___ 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 [01/12] drm: Add DP PSR2 sink enable bit
== Series Details == Series: series starting with [01/12] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40521/ State : failure == Summary == Series 40521v1 series starting with [01/12] drm: Add DP PSR2 sink enable bit https://patchwork.freedesktop.org/api/1.0/series/40521/revisions/1/mbox/ Possible new issues: Test drv_module_reload: Subgroup basic-reload-inject: pass -> INCOMPLETE (fi-cnl-y3) Known issues: Test prime_vgem: Subgroup basic-fence-flip: pass -> FAIL (fi-ilk-650) fdo#104008 fdo#104008 https://bugs.freedesktop.org/show_bug.cgi?id=104008 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:442s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:387s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:539s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:514s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:518s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:520s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:508s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:412s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:512s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:519s fi-cnl-y3total:284 pass:258 dwarn:0 dfail:0 fail:0 skip:25 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:427s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:316s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:405s fi-ilk-650 total:285 pass:224 dwarn:0 dfail:0 fail:1 skip:60 time:422s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:475s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:435s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:478s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:467s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:512s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:666s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:443s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:529s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:508s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:501s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:428s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:444s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:600s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:405s fi-cfl-s3 failed to connect after reboot 9e3f06af248708774c765efd55bf8e883f24fbfd drm-tip: 2018y-03m-22d-21h-17m-42s UTC integration manifest ff1a90ddf554 drm/i915/debugfs: Print how many blocks were sent in a selective update 5fda9554238b drm/i915/debugfs: Print information about what caused a PSR exit 0f9a21c67357 drm/i915/debugfs: Print sink PSR state and debug info 70148c4aea67 drm/i915/psr: Set DPCD PSR2 enable bit when needed ebf449282d26 drm/i915/psr: Cache sink synchronization latency 83a99661c27d drm/i915/psr: Use PSR2 macro for PSR2 6659daf1e4d9 drm/i915/psr: Do not override PSR2 sink support 060b501ae2f1 drm/i915/psr/cnl: Enable Y-coordinate support in source 307f5aa1e5d2 drm/i915/psr: Tie PSR2 support to Y coordinate requirement f7edbfc94e93 drm/i915/psr: Nuke aux frame sync 67ced254aa32 drm: Add DP last received PSR SDP VSC register and bits 3c6c3ba8cde6 drm: Add DP PSR2 sink enable bit == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8461/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
On 03/22/2018 11:17 AM, Piotr Piórkowski wrote:
If GuC firmware is not available on the system and we load i915 with enable
GuC, then we hit this null pointer dereference issue:
[ 71.098873] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 71.098938] IP: intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.098947] PGD 0 P4D 0
[ 71.098956] Oops: [#1] PREEMPT SMP PTI
[ 71.098965] Modules linked in: i915(O+) netconsole x86_pkg_temp_thermal
intel_powerclamp coretemp crct10dif_pclmul crc32_pclmul ghash_clmulni_intel
mei_me i2c_i801 prime_numbers mei [last unloaded: i915]
[ 71.099005] CPU: 2 PID: 1167 Comm: insmod Tainted: G U W O
4.16.0-rc1+ #337
[ 71.099018] Hardware name: /NUC6i5SYB, BIOS SYSKLi35.86A.0065.2018.0103.1000
01/03/2018
[ 71.099077] RIP: 0010:intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.099087] RSP: 0018:c9417aa0 EFLAGS: 00010282
[ 71.099097] RAX: RBX: 88084cad12f8 RCX: a03e9357
[ 71.099108] RDX: 0002 RSI: a034dba0 RDI: 88084cad12f8
[ 71.099118] RBP: 0002 R08: 88085344ca90 R09: 0001
[ 71.099128] R10: R11: R12: 88084cad
[ 71.099139] R13: a034dba0 R14: fff5 R15: 88084cad12b0
[ 71.099151] FS: 7f7f24ae2740() GS:88085e20()
knlGS:
[ 71.099162] CS: 0010 DS: ES: CR0: 80050033
[ 71.099171] CR2: 0008 CR3: 000855f48001 CR4: 003606e0
[ 71.099182] Call Trace:
[ 71.099246] intel_uc_init_hw+0xc8/0x520 [i915]
[ 71.099303] i915_gem_init_hw+0x11f/0x2d0 [i915]
[ 71.099364] i915_gem_init+0x2b9/0x640 [i915]
[ 71.099413] i915_driver_load+0xb74/0x1110 [i915]
[ 71.099462] i915_pci_probe+0x2e/0x90 [i915]
[ 71.099476] pci_device_probe+0xa1/0x130
[ 71.099488] driver_probe_device+0x302/0x470
[ 71.099502] __driver_attach+0xb9/0xe0
[ 71.099513] ? driver_probe_device+0x470/0x470
[ 71.099525] ? driver_probe_device+0x470/0x470
[ 71.099538] bus_for_each_dev+0x64/0x90
[ 71.099550] bus_add_driver+0x164/0x260
[ 71.099561] ? 0xa04d6000
[ 71.099572] driver_register+0x57/0xc0
[ 71.099582] ? 0xa04d6000
[ 71.099593] do_one_initcall+0x3b/0x160
[ 71.099606] ? kmem_cache_alloc_trace+0x1c3/0x2a0
[ 71.099621] do_init_module+0x5b/0x1f9
[ 71.099635] load_module+0x2467/0x2a70
[ 71.099654] ? SyS_finit_module+0xbd/0xe0
[ 71.099668] SyS_finit_module+0xbd/0xe0
[ 71.099682] do_syscall_64+0x73/0x1c0
[ 71.099694] entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 71.099706] RIP: 0033:0x7f7f23fb40d9
[ 71.099717] RSP: 002b:7ffda7d67ed8 EFLAGS: 0246 ORIG_RAX:
0139
[ 71.099734] RAX: ffda RBX: 55f96e2a8870 RCX: 7f7f23fb40d9
[ 71.099748] RDX: RSI: 55f96e2a8260 RDI: 0003
[ 71.099763] RBP: 55f96e2a8260 R08: R09: 7ffda7d68088
[ 71.099777] R10: 0003 R11: 0246 R12:
[ 71.099791] R13: 55f96e2a8830 R14: R15: 55f96e2a8260
[ 71.099810] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 41 55 41 54
49 89 f5 55 53 48 c7 c1 57 93 3e a0 48 8b 47 10 48 89 fb 4c 8b 07 <48> 8b 68 08
8b 47 28 85 c0 74 15 83 f8 01 48 c7 c1 5b 93 3e a0
[ 71.14] RIP: intel_uc_fw_upload+0x1f/0x360 [i915] RSP: c9417aa0
[ 71.100020] CR2: 0008
[ 71.100031] ---[ end trace d8ac93c30ceff5b2 ]--
Fixes: 6b0478fb722a ("drm/i915: Implement dynamic GuC WOPCM offset and size
calculation")
v2: don't assume it is always GuC FW (Michal)
v3: added a new variable to avoid exceeding the number of characters in the
line (Michal)
Signed-off-by: Piotr Piórkowski
Reported-by: Radoslaw Szwichtenberg
Cc: Michał Winiarski
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Joonas Lahtinen
Cc: Jackie Li
Cc: Radoslaw Szwichtenberg
---
drivers/gpu/drm/i915/intel_uc_fw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 30c73243f54d..486eb116015b 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -199,9 +199,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
int (*xfer)(struct intel_uc_fw *uc_fw,
struct i915_vma *vma))
{
- struct drm_i915_private *i915 = to_i915(uc_fw->obj->base.dev);
struct i915_vma *vma;
int err;
+ u32 ggtt_pin_bias;
DRM_DEBUG_DRIVER("%s fw load %s\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path);
@@ -222,9 +222,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
goto fail;
}
+ ggtt_pin_bias = to_i915(uc_fw->obj->base.dev)->guc.ggtt_pin_bias;
vma = i915_gem_object_ggtt_pin(uc_fw->obj, NULL, 0, 0,
-
[Intel-gfx] [PATCH i-g-t v3] tests/kms_rotation_crc: Move platform checks to one place for non exhaust fence cases
From: Anusha Srivatsa
Cleanup the testcases by moving the platform checks to a single function.
The earlier version of the path is posted here [1]
v2: Make use of the property enums to get the supported rotations
v3: Move hardcodings to a single function(Ville)
[1]: https://patchwork.freedesktop.org/patch/209647/
Cc: Radhakrishna Sripada
Cc: Ville Syrjälä
Cc: Daniel Vetter
Cc: Rodrigo Vivi
Cc: Maarten Lankhorst
Cc: Mika Kahola
Cc: Manasi Navare
Signed-off-by: Anusha Srivatsa
Signed-off-by: Radhakrishna Sripada
---
tests/kms_rotation_crc.c | 31 ---
1 file changed, 16 insertions(+), 15 deletions(-)
diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index 0cd5c6e52b57..60fb9012e14e 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -43,6 +43,7 @@ typedef struct {
uint32_t override_fmt;
uint64_t override_tiling;
int devid;
+ int gen;
} data_t;
typedef struct {
@@ -301,6 +302,17 @@ static void wait_for_pageflip(int fd)
igt_assert(drmHandleEvent(fd, &evctx) == 0);
}
+static void igt_check_rotation(data_t *data)
+{
+ if (data->rotation & (IGT_ROTATION_90 | IGT_ROTATION_270))
+ igt_require(data->gen >= 9);
+ else if (data->rotation & IGT_REFLECT_X)
+ igt_require(data->gen >= 10 ||
+ (IS_CHERRYVIEW(data->devid) && (data->rotation &
IGT_ROTATION_0)));
+ else if (data->rotation & IGT_ROTATION_180)
+ igt_require(data->gen >= 4);
+}
+
static void test_single_case(data_t *data, enum pipe pipe,
igt_output_t *output, igt_plane_t *plane,
enum rectangle_type rect,
@@ -369,13 +381,12 @@ static void test_plane_rotation(data_t *data, int
plane_type, bool test_bad_form
igt_display_require_output(display);
+ igt_check_rotation(data);
+
for_each_pipe_with_valid_output(display, pipe, output) {
igt_plane_t *plane;
int i, j;
- if (IS_CHERRYVIEW(data->devid) && pipe != PIPE_B)
- continue;
-
igt_output_set_pipe(output, pipe);
plane = igt_output_get_plane_type(output, plane_type);
@@ -538,14 +549,13 @@ igt_main
};
data_t data = {};
- int gen = 0;
igt_skip_on_simulation();
igt_fixture {
data.gfx_fd = drm_open_driver_master(DRIVER_INTEL);
data.devid = intel_get_drm_devid(data.gfx_fd);
- gen = intel_gen(data.devid);
+ data.gen = intel_gen(data.devid);
kmstest_set_vt_graphics_mode();
@@ -558,16 +568,12 @@ igt_main
igt_subtest_f("%s-rotation-%s",
plane_test_str(subtest->plane),
rot_test_str(subtest->rot)) {
- igt_require(!(subtest->rot &
- (IGT_ROTATION_90 | IGT_ROTATION_270)) ||
- gen >= 9);
data.rotation = subtest->rot;
test_plane_rotation(&data, subtest->plane, false);
}
}
igt_subtest_f("sprite-rotation-90-pos-100-0") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.pos_x = 100,
data.pos_y = 0;
@@ -577,7 +583,6 @@ igt_main
data.pos_y = 0;
igt_subtest_f("bad-pixel-format") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.override_fmt = DRM_FORMAT_RGB565;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
@@ -585,7 +590,6 @@ igt_main
data.override_fmt = 0;
igt_subtest_f("bad-tiling") {
- igt_require(gen >= 9);
data.rotation = IGT_ROTATION_90;
data.override_tiling = LOCAL_I915_FORMAT_MOD_X_TILED;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY, true);
@@ -596,9 +600,6 @@ igt_main
igt_subtest_f("primary-%s-reflect-x-%s",
tiling_test_str(reflect_x->tiling),
rot_test_str(reflect_x->rot)) {
- igt_require(gen >= 10 ||
- (IS_CHERRYVIEW(data.devid) &&
reflect_x->rot == IGT_ROTATION_0
-&& reflect_x->tiling ==
LOCAL_I915_FORMAT_MOD_X_TILED));
data.rotation = (IGT_REFLECT_X | reflect_x->rot);
data.override_tiling = reflect_x->tiling;
test_plane_rotation(&data, DRM_PLANE_TYPE_PRIMARY,
false);
@@ -613,7 +614,7 @@ igt_main
enum pipe pipe;
igt_output_t *output;
- igt_require(gen >= 9);
+ igt_require(data.gen >= 9);
igt_di
[Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/12] drm: Add DP PSR2 sink enable bit
== Series Details == Series: series starting with [01/12] drm: Add DP PSR2 sink enable bit URL : https://patchwork.freedesktop.org/series/40521/ State : warning == Summary == $ dim checkpatch origin/drm-tip 3c6c3ba8cde6 drm: Add DP PSR2 sink enable bit 67ced254aa32 drm: Add DP last received PSR SDP VSC register and bits f7edbfc94e93 drm/i915/psr: Nuke aux frame sync 307f5aa1e5d2 drm/i915/psr: Tie PSR2 support to Y coordinate requirement 060b501ae2f1 drm/i915/psr/cnl: Enable Y-coordinate support in source -:26: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #26: FILE: drivers/gpu/drm/i915/i915_reg.h:3895: +#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */ ^ -:27: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #27: FILE: drivers/gpu/drm/i915/i915_reg.h:3896: +#define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+ */ ^ -:35: CHECK:SPACING: spaces preferred around that '<<' (ctx:VxV) #35: FILE: drivers/gpu/drm/i915/i915_reg.h:6903: +#define VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and CNL+ */ ^ total: 0 errors, 0 warnings, 3 checks, 43 lines checked 6659daf1e4d9 drm/i915/psr: Do not override PSR2 sink support 83a99661c27d drm/i915/psr: Use PSR2 macro for PSR2 ebf449282d26 drm/i915/psr: Cache sink synchronization latency 70148c4aea67 drm/i915/psr: Set DPCD PSR2 enable bit when needed 0f9a21c67357 drm/i915/debugfs: Print sink PSR state and debug info 5fda9554238b drm/i915/debugfs: Print information about what caused a PSR exit ff1a90ddf554 drm/i915/debugfs: Print how many blocks were sent in a selective update ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/12] drm/i915/psr: Nuke aux frame sync
Without GTC enabled hardware is sending dummy aux frame sync value
that is not useful to sink do selective update, that is why it also
require that sink supports and requires the y-coordinate.
So removing everything related to aux frame sync, if GTC is enabled
we can bring this back.
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_psr.c | 23 +--
2 files changed, 1 insertion(+), 23 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9c3b2ba6a86..7fe00509e51a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -602,7 +602,6 @@ struct i915_psr {
struct delayed_work work;
unsigned busy_frontbuffer_bits;
bool psr2_support;
- bool aux_frame_sync;
bool link_standby;
bool y_cord_support;
bool colorimetry_support;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index b8e083e10029..d46320a451d9 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -137,16 +137,9 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
if (INTEL_GEN(dev_priv) >= 9 &&
(intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
- uint8_t frame_sync_cap;
dev_priv->psr.sink_support = true;
- if (drm_dp_dpcd_readb(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP,
- &frame_sync_cap) != 1)
- frame_sync_cap = 0;
- dev_priv->psr.aux_frame_sync = frame_sync_cap &
DP_AUX_FRAME_SYNC_CAP;
- /* PSR2 needs frame sync as well */
- dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync;
+ dev_priv->psr.psr2_support = true;
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
@@ -269,11 +262,6 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
struct drm_i915_private *dev_priv = to_i915(dev);
- /* Enable AUX frame sync at sink */
- if (dev_priv->psr.aux_frame_sync)
- drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
- DP_AUX_FRAME_SYNC_ENABLE);
/* Enable ALPM at sink for psr2 */
if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
drm_dp_dpcd_writeb(&intel_dp->aux,
@@ -712,11 +700,6 @@ static void hsw_psr_disable(struct intel_dp *intel_dp,
i915_reg_t psr_status;
u32 psr_status_mask;
- if (dev_priv->psr.aux_frame_sync)
- drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
- 0);
-
if (dev_priv->psr.psr2_support) {
psr_status = EDP_PSR2_STATUS;
psr_status_mask = EDP_PSR2_STATUS_STATE_MASK;
@@ -860,10 +843,6 @@ static void intel_psr_exit(struct drm_i915_private
*dev_priv)
return;
if (HAS_DDI(dev_priv)) {
- if (dev_priv->psr.aux_frame_sync)
- drm_dp_dpcd_writeb(&intel_dp->aux,
- DP_SINK_DEVICE_AUX_FRAME_SYNC_CONF,
- 0);
if (dev_priv->psr.psr2_support) {
val = I915_READ(EDP_PSR2_CTL);
WARN_ON(!(val & EDP_PSR2_ENABLE));
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/12] drm/i915/psr/cnl: Enable Y-coordinate support in source
From: "Souza, Jose"
For Geminilake and Cannonlake+ the Y-coordinate support must be
enabled in PSR2_CTL too.
Spec: 7713 and 7720
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 3 +++
drivers/gpu/drm/i915/intel_psr.c | 16
2 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index da2f6c623ab2..9c4be6bcd1ef 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3892,6 +3892,8 @@ enum {
#define EDP_PSR2_CTL _MMIO(0x6f900)
#define EDP_PSR2_ENABLE (1<<31)
#define EDP_SU_TRACK_ENABLE (1<<30)
+#define EDP_Y_COORDINATE_VALID (1<<26) /* GLK and CNL+ */
+#define EDP_Y_COORDINATE_ENABLE (1<<25) /* GLK and CNL+ */
#define EDP_MAX_SU_DISABLE_TIME(t) ((t)<<20)
#define EDP_MAX_SU_DISABLE_TIME_MASK (0x1f<<20)
#define EDP_PSR2_TP2_TIME_500(0<<8)
@@ -6898,6 +6900,7 @@ enum {
#define CHICKEN_TRANS_A 0x420c0
#define CHICKEN_TRANS_B 0x420c4
#define CHICKEN_TRANS(trans) _MMIO_TRANS(trans, CHICKEN_TRANS_A,
CHICKEN_TRANS_B)
+#define VSC_DATA_SEL_SOFTWARE_CONTROL (1<<25) /* GLK and CNL+ */
#define DDI_TRAINING_OVERRIDE_ENABLE (1<<19)
#define DDI_TRAINING_OVERRIDE_VALUE (1<<18)
#define DDIE_TRAINING_OVERRIDE_ENABLE (1<<17) /* CHICKEN_TRANS_A only */
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 23f38ab10636..76e021428e57 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -387,8 +387,10 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
* good enough. */
- val |= EDP_PSR2_ENABLE |
- EDP_SU_TRACK_ENABLE;
+ val |= EDP_PSR2_ENABLE | EDP_SU_TRACK_ENABLE;
+ if (INTEL_GEN(dev_priv) >= 10 || IS_GEMINILAKE(dev_priv)) {
+ val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
+ }
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_SYNCHRONIZATION_LATENCY_IN_SINK,
@@ -570,8 +572,14 @@ static void hsw_psr_enable_source(struct intel_dp
*intel_dp,
hsw_psr_setup_aux(intel_dp);
if (dev_priv->psr.psr2_support) {
- u32 chicken = PSR2_VSC_ENABLE_PROG_HEADER
- | PSR2_ADD_VERTICAL_LINE_COUNT;
+ u32 chicken = I915_READ(CHICKEN_TRANS(cpu_transcoder));
+
+ if (INTEL_GEN(dev_priv) == 9 && !IS_GEMINILAKE(dev_priv))
+ chicken |= (PSR2_VSC_ENABLE_PROG_HEADER
+ | PSR2_ADD_VERTICAL_LINE_COUNT);
+
+ else
+ chicken &= ~VSC_DATA_SEL_SOFTWARE_CONTROL;
I915_WRITE(CHICKEN_TRANS(cpu_transcoder), chicken);
I915_WRITE(EDP_PSR_DEBUG,
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v2,3/3] HAX: Enable GuC for CI (rev4)
== Series Details == Series: series starting with [v2,3/3] HAX: Enable GuC for CI (rev4) URL : https://patchwork.freedesktop.org/series/40516/ State : failure == Summary == Applying: HAX: Enable GuC for CI Applying: drm/i915/uc: Fetch uC firmware in init_early error: Failed to merge in the changes. Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/i915_drv.c Falling back to patching base and 3-way merge... Auto-merging drivers/gpu/drm/i915/i915_drv.c CONFLICT (content): Merge conflict in drivers/gpu/drm/i915/i915_drv.c Patch failed at 0002 drm/i915/uc: Fetch uC firmware in init_early The copy of the patch that failed is found in: .git/rebase-apply/patch 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 04/12] drm/i915/psr: Tie PSR2 support to Y coordinate requirement
Move to only one place the sink requirements that the actual driver
needs to enable PSR2.
Also intel_psr2_config_valid() is called every time the crtc config
is computed, wasting some time every time it was checking for
Y coordinate requirement.
This allow us to nuke y_cord_support and some of VSC setup code that
was handling a scenario that would never happen(PSR2 without Y
coordinate).
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_drv.h | 1 -
drivers/gpu/drm/i915/intel_psr.c | 46 +---
2 files changed, 19 insertions(+), 28 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 7fe00509e51a..cce32686fd75 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -603,7 +603,6 @@ struct i915_psr {
unsigned busy_frontbuffer_bits;
bool psr2_support;
bool link_standby;
- bool y_cord_support;
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index d46320a451d9..23f38ab10636 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -93,7 +93,7 @@ static void psr_aux_io_power_put(struct intel_dp *intel_dp)
intel_display_power_put(dev_priv, psr_aux_domain(intel_dp));
}
-static bool intel_dp_get_y_cord_status(struct intel_dp *intel_dp)
+static bool intel_dp_get_y_coord_required(struct intel_dp *intel_dp)
{
uint8_t psr_caps = 0;
@@ -130,22 +130,29 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
drm_dp_dpcd_read(&intel_dp->aux, DP_PSR_SUPPORT, intel_dp->psr_dpcd,
sizeof(intel_dp->psr_dpcd));
- if (intel_dp->psr_dpcd[0] & DP_PSR_IS_SUPPORTED) {
+ if (intel_dp->psr_dpcd[0]) {
dev_priv->psr.sink_support = true;
DRM_DEBUG_KMS("Detected EDP PSR Panel.\n");
}
if (INTEL_GEN(dev_priv) >= 9 &&
- (intel_dp->psr_dpcd[0] & DP_PSR2_IS_SUPPORTED)) {
-
- dev_priv->psr.sink_support = true;
- dev_priv->psr.psr2_support = true;
+ (intel_dp->psr_dpcd[0] == DP_PSR2_WITH_Y_COORD_IS_SUPPORTED)) {
+ /*
+* All panels that supports PSR version 03h (PSR2 +
+* Y-coordinate) can handle Y-coordinates in VSC but we are
+* only sure that it is going to be used when required by the
+* panel. This way panel is capable to do selective update
+* without a aux frame sync.
+*
+* To support PSR version 02h and PSR version 03h without
+* Y-coordinate requirement panels we would need to enable
+* GTC first.
+*/
+ dev_priv->psr.psr2_support =
intel_dp_get_y_coord_required(intel_dp);
DRM_DEBUG_KMS("PSR2 %s on sink",
dev_priv->psr.psr2_support ? "supported" : "not
supported");
if (dev_priv->psr.psr2_support) {
- dev_priv->psr.y_cord_support =
- intel_dp_get_y_cord_status(intel_dp);
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
@@ -191,16 +198,12 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
psr_vsc.sdp_header.HB1 = 0x7;
- if (dev_priv->psr.colorimetry_support &&
- dev_priv->psr.y_cord_support) {
+ if (dev_priv->psr.colorimetry_support) {
psr_vsc.sdp_header.HB2 = 0x5;
psr_vsc.sdp_header.HB3 = 0x13;
- } else if (dev_priv->psr.y_cord_support) {
+ } else {
psr_vsc.sdp_header.HB2 = 0x4;
psr_vsc.sdp_header.HB3 = 0xe;
- } else {
- psr_vsc.sdp_header.HB2 = 0x3;
- psr_vsc.sdp_header.HB3 = 0xc;
}
} else {
/* Prepare VSC packet as per EDP 1.3 spec, Table 3.10 */
@@ -458,15 +461,6 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
return false;
}
- /*
-* FIXME:enable psr2 only for y-cordinate psr2 panels
-* After gtc implementation , remove this restriction.
-*/
- if (!dev_priv->psr.y_cord_support) {
- DRM_DEBUG_KMS("PSR2 not enabled, panel does not support Y
coordinate\n");
- return false;
- }
-
return true;
}
@@ -566,7 +560,6 @@ static void hsw_psr_enable_source(struct intel_dp *intel_dp,
struct drm_de
[Intel-gfx] [PATCH 02/12] drm: Add DP last received PSR SDP VSC register and bits
This is a register to help debug what is in the last SDP VSC packet revived by sink. Signed-off-by: José Roberto de Souza --- include/drm/drm_dp_helper.h | 9 + 1 file changed, 9 insertions(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 0bac0c7d0dec..91c9bcd4196f 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -795,6 +795,15 @@ # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_MASK (0xf << 4) # define DP_LAST_ACTUAL_SYNCHRONIZATION_LATENCY_SHIFT 4 +#define DP_LAST_RECEIVED_PSR_SDP 0x200a /* eDP 1.2 */ +# define DP_PSR_STATE_BIT (1 << 0) /* eDP 1.2 */ +# define DP_UPDATE_RFB_BIT (1 << 1) /* eDP 1.2 */ +# define DP_CRC_VALID_BIT (1 << 2) /* eDP 1.2 */ +# define DP_SU_VALID (1 << 3) /* eDP 1.4 */ +# define DP_FIRST_SCAN_LINE_SU_REGION (1 << 4) /* eDP 1.4 */ +# define DP_LAST_SCAN_LINE_SU_REGION (1 << 5) /* eDP 1.4 */ +# define DP_Y_COORDINATE_VALID (1 << 6) /* eDP 1.4a */ + #define DP_RECEIVER_ALPM_STATUS0x200b /* eDP 1.4 */ # define DP_ALPM_LOCK_TIMEOUT_ERROR(1 << 0) -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/12] drm/i915/debugfs: Print sink PSR state and debug info
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 54 +
1 file changed, 54 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 16f9977995df..0a0642c61cd0 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2603,6 +2603,44 @@ static const char *psr2_live_status(u32 val)
return "unknown";
}
+static const char *psr_sink_self_refresh_status(u8 val)
+{
+ static const char * const sink_status[] = {
+ "inactive",
+ "transitioning to active",
+ "active",
+ "active receiving selective update",
+ "transitioning to inactive",
+ "reserved",
+ "reserved",
+ "sink internal error"
+ };
+
+ val &= DP_PSR_SINK_STATE_MASK;
+ if (val < ARRAY_SIZE(sink_status))
+ return sink_status[val];
+
+ return "unknown";
+}
+
+static void psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32 val)
+{
+ if (val & DP_PSR_STATE_BIT)
+ seq_puts(m, "\tPSR active\n");
+ if (val & DP_UPDATE_RFB_BIT)
+ seq_puts(m, "\tUpdate RFB\n");
+ if (val & DP_CRC_VALID_BIT)
+ seq_puts(m, "\tCRC valid\n");
+ if (val & DP_SU_VALID)
+ seq_puts(m, "\tSU valid\n");
+ if (val & DP_FIRST_SCAN_LINE_SU_REGION)
+ seq_puts(m, "\tFirst scan line of the SU region\n");
+ if (val & DP_LAST_SCAN_LINE_SU_REGION)
+ seq_puts(m, "\tLast scan line of the SU region\n");
+ if (val & DP_Y_COORDINATE_VALID)
+ seq_puts(m, "\tY-Coordinate valid\n");
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2684,6 +2722,22 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
psr2, psr2_live_status(psr2));
}
+
+ if (dev_priv->psr.enabled) {
+ struct drm_dp_aux *aux = &dev_priv->psr.enabled->aux;
+ u8 val;
+
+ if (drm_dp_dpcd_readb(aux, DP_PSR_STATUS, &val) == 1)
+ seq_printf(m, "Sink self refresh status: 0x%x [%s]\n",
+ val, psr_sink_self_refresh_status(val));
+
+ if (drm_dp_dpcd_readb(aux, DP_LAST_RECEIVED_PSR_SDP, &val)
+ == 1) {
+ seq_printf(m, "Sink last received PSR SDP: 0x%x\n",
+ val);
+ psr_sink_last_received_psr_sdp_sprintf(m, val);
+ }
+ }
mutex_unlock(&dev_priv->psr.lock);
intel_runtime_pm_put(dev_priv);
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/12] drm: Add DP PSR2 sink enable bit
To comply with eDP1.4a this bit should be set when enabling PSR2. Signed-off-by: José Roberto de Souza --- include/drm/drm_dp_helper.h | 1 + 1 file changed, 1 insertion(+) diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h index 62903bae0221..0bac0c7d0dec 100644 --- a/include/drm/drm_dp_helper.h +++ b/include/drm/drm_dp_helper.h @@ -478,6 +478,7 @@ # define DP_PSR_FRAME_CAPTURE (1 << 3) # define DP_PSR_SELECTIVE_UPDATE (1 << 4) # define DP_PSR_IRQ_HPD_WITH_CRC_ERRORS (1 << 5) +# define DP_PSR_ENABLE_PSR2(1 << 6) /* eDP 1.4a */ #define DP_ADAPTER_CTRL0x1a0 # define DP_ADAPTER_CTRL_FORCE_LOAD_SENSE (1 << 0) -- 2.16.2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 11/12] drm/i915/debugfs: Print information about what caused a PSR exit
This will be helpful to debug what hardware is actually tracking.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 47 +
drivers/gpu/drm/i915/i915_reg.h | 18 ++
2 files changed, 65 insertions(+)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 0a0642c61cd0..3182e9a7cc5d 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2641,6 +2641,43 @@ static void
psr_sink_last_received_psr_sdp_sprintf(struct seq_file *m, u32 val)
seq_puts(m, "\tY-Coordinate valid\n");
}
+static void psr_event_exit_sprintf(struct seq_file *m, u32 val,
+ bool psr2_enabled)
+{
+ if (val & EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE)
+ seq_puts(m, "\tPSR2 watchdog timer expired\n");
+ if ((val & EDP_PSR_EVENT_PSR2_DISABLED) && psr2_enabled)
+ seq_puts(m, "\tPSR2 disabled\n");
+ if (val & EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN)
+ seq_puts(m, "\tSU dirty FIFO underrun\n");
+ if (val & EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN)
+ seq_puts(m, "\tSU CRC FIFO underrun\n");
+ if (val & EDP_PSR_EVENT_GRAPHICS_RESET)
+ seq_puts(m, "\tGraphics reset\n");
+ if (val & EDP_PSR_EVENT_PCH_INTERRUPT)
+ seq_puts(m, "\tPCH interrupt\n");
+ if (val & EDP_PSR_EVENT_MEMORY_UP)
+ seq_puts(m, "\tMemory up\n");
+ if (val & EDP_PSR_EVENT_FRONT_BUFFER_MODIFY)
+ seq_puts(m, "\tFront buffer modification\n");
+ if (val & EDP_PSR_EVENT_WD_TIMER_EXPIRE)
+ seq_puts(m, "\tPSR watchdog timer expired\n");
+ if (val & EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE)
+ seq_puts(m, "\tPIPE registers updated\n");
+ if (val & EDP_PSR_EVENT_REGISTER_UPDATE)
+ seq_puts(m, "\tRegister update\n");
+ if (val & EDP_PSR_EVENT_HDCP_ENABLE)
+ seq_puts(m, "\tHDCP enabled\n");
+ if (val & EDP_PSR_EVENT_KVMR_SESSION_ENABLE)
+ seq_puts(m, "\tKVMR session enabled\n");
+ if (val & EDP_PSR_EVENT_VBI_ENABLE)
+ seq_puts(m, "\tVBI enabled\n");
+ if (val & EDP_PSR_EVENT_LPSP_MODE_EXIT)
+ seq_puts(m, "\tLPSP mode exited\n");
+ if ((val & EDP_PSR_EVENT_PSR_DISABLE) && !psr2_enabled)
+ seq_puts(m, "\tPSR disabled\n");
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2716,6 +2753,16 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
+
+ if (INTEL_GEN(dev_priv) >= 9) {
+ u32 val = I915_READ(EDP_PSR_EVENT);
+
+ seq_printf(m, "Event triggered PSR exit: 0x%x\n", val);
+ psr_event_exit_sprintf(m, val, dev_priv->psr.psr2_enabled);
+ /* clean events */
+ I915_WRITE(EDP_PSR_EVENT, val);
+ }
+
if (dev_priv->psr.psr2_enabled) {
u32 psr2 = I915_READ(EDP_PSR2_STATUS);
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index e660c8a707cf..45f7703a9ee6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3907,6 +3907,24 @@ enum {
#define EDP_PSR2_IDLE_FRAME_MASK 0xf
#define EDP_PSR2_IDLE_FRAME_SHIFT0
+#define EDP_PSR_EVENT _MMIO(0x6f848)
+#define EDP_PSR_EVENT_PSR2_WD_TIMER_EXPIRE(1 << 17)
+#define EDP_PSR_EVENT_PSR2_DISABLED (1 << 16)
+#define EDP_PSR_EVENT_SU_DIRTY_FIFO_UNDERRUN (1 << 15)
+#define EDP_PSR_EVENT_SU_CRC_FIFO_UNDERRUN(1 << 14)
+#define EDP_PSR_EVENT_GRAPHICS_RESET (1 << 12)
+#define EDP_PSR_EVENT_PCH_INTERRUPT (1 << 11)
+#define EDP_PSR_EVENT_MEMORY_UP (1 << 10)
+#define EDP_PSR_EVENT_FRONT_BUFFER_MODIFY (1 << 9)
+#define EDP_PSR_EVENT_WD_TIMER_EXPIRE (1 << 8)
+#define EDP_PSR_EVENT_PIPE_REGISTERS_UPDATE (1 << 6)
+#define EDP_PSR_EVENT_REGISTER_UPDATE (1 << 5)
+#define EDP_PSR_EVENT_HDCP_ENABLE (1 << 4)
+#define EDP_PSR_EVENT_KVMR_SESSION_ENABLE (1 << 3)
+#define EDP_PSR_EVENT_VBI_ENABLE (1 << 2)
+#define EDP_PSR_EVENT_LPSP_MODE_EXIT (1 << 1)
+#define EDP_PSR_EVENT_PSR_DISABLE (1 << 0)
+
#define EDP_PSR2_STATUS_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
#define EDP_PSR2_STATUS_STATE_SHIFT28
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 12/12] drm/i915/debugfs: Print how many blocks were sent in a selective update
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_debugfs.c | 40 -
drivers/gpu/drm/i915/i915_reg.h | 17
2 files changed, 56 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 3182e9a7cc5d..20985584cc0f 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2678,6 +2678,43 @@ static void psr_event_exit_sprintf(struct seq_file *m,
u32 val,
seq_puts(m, "\tPSR disabled\n");
}
+static void psr2_su_blocks_sprintf(struct seq_file *m,
+ struct drm_i915_private *dev_priv)
+{
+ u32 val;
+ u16 su;
+
+ val = I915_READ(EDP_PSR2_SU_STATUS);
+ su = val >> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_SHIFT;
+ su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N: %d\n", su);
+ su = val >> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_1_SHIFT;
+ su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-1: %d\n", su);
+ su = val >> EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_2_SHIFT;
+ su &= EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-2: %d\n", su);
+
+ val = I915_READ(EDP_PSR2_SU_STATUS2);
+ su = val >> EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_3_SHIFT;
+ su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-3: %d\n", su);
+ su = val >> EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_4_SHIFT;
+ su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-4: %d\n", su);
+ su = val >> EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_5_SHIFT;
+ su &= EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-5: %d\n", su);
+
+ val = I915_READ(EDP_PSR2_SU_STATUS3);
+ su = val >> EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_6_SHIFT;
+ su &= EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-6: %d\n", su);
+ su = val >> EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_7_SHIFT;
+ su &= EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK;
+ seq_printf(m, "\tSU blocks in frame N-7: %d\n", su);
+}
+
static int i915_edp_psr_status(struct seq_file *m, void *data)
{
struct drm_i915_private *dev_priv = node_to_i915(m->private);
@@ -2766,8 +2803,9 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
if (dev_priv->psr.psr2_enabled) {
u32 psr2 = I915_READ(EDP_PSR2_STATUS);
- seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
+ seq_printf(m, "EDP_PSR2_STATUS: 0x%x [%s]\n",
psr2, psr2_live_status(psr2));
+ psr2_su_blocks_sprintf(m, dev_priv);
}
if (dev_priv->psr.enabled) {
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 45f7703a9ee6..18af3e8fd4b6 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3929,6 +3929,23 @@ enum {
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
#define EDP_PSR2_STATUS_STATE_SHIFT28
+#define EDP_PSR2_SU_STATUS _MMIO(0x6F914)
+#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_MASK 0x3FF
+#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_SHIFT 0
+#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_1_SHIFT 10
+#define EDP_PSR2_SU_STATUS_NUM_SU_BLOCKS_FRAME_N_MINUS_2_SHIFT 20
+
+#define EDP_PSR2_SU_STATUS2 _MMIO(0x6F918)
+#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_MASK 0x3FF
+#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_3_SHIFT 0
+#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_4_SHIFT 10
+#define EDP_PSR2_SU_STATUS2_NUM_SU_BLOCKS_FRAME_N_MINUS_5_SHIFT 20
+
+#define EDP_PSR2_SU_STATUS3 _MMIO(0x6F91C)
+#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_MASK 0x3FF
+#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_6_SHIFT 0
+#define EDP_PSR2_SU_STATUS3_NUM_SU_BLOCKS_FRAME_N_MINUS_7_SHIFT 10
+
/* VGA port control */
#define ADPA _MMIO(0x61100)
#define PCH_ADPA_MMIO(0xe1100)
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/12] drm/i915/psr: Do not override PSR2 sink support
Sink can support our PSR2 requirements but userspace can request
a resolution that PSR2 hardware do not support, in this case it
was overwritten the PSR2 sink support.
Adding another flag here, this way if requested resolution changed
to a value that PSR2 hardware can handle, PSR2 can be enabled.
Cc: Dhinakaran Pandiyan
Reviewed-by: Rodrigo Vivi
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--
drivers/gpu/drm/i915/i915_drv.h | 3 ++-
drivers/gpu/drm/i915/intel_psr.c| 33 +
3 files changed, 21 insertions(+), 19 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7816cd53100a..16f9977995df 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2630,7 +2630,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
yesno(work_busy(&dev_priv->psr.work.work)));
if (HAS_DDI(dev_priv)) {
- if (dev_priv->psr.psr2_support)
+ if (dev_priv->psr.psr2_enabled)
enabled = I915_READ(EDP_PSR2_CTL) & EDP_PSR2_ENABLE;
else
enabled = I915_READ(EDP_PSR_CTL) & EDP_PSR_ENABLE;
@@ -2678,7 +2678,7 @@ static int i915_edp_psr_status(struct seq_file *m, void
*data)
seq_printf(m, "Performance_Counter: %u\n", psrperf);
}
- if (dev_priv->psr.psr2_support) {
+ if (dev_priv->psr.psr2_enabled) {
u32 psr2 = I915_READ(EDP_PSR2_STATUS);
seq_printf(m, "EDP_PSR2_STATUS: %x [%s]\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cce32686fd75..a367fe5538ae 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -601,11 +601,12 @@ struct i915_psr {
bool active;
struct delayed_work work;
unsigned busy_frontbuffer_bits;
- bool psr2_support;
+ bool sink_psr2_support;
bool link_standby;
bool colorimetry_support;
bool alpm;
bool has_hw_tracking;
+ bool psr2_enabled;
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index 76e021428e57..f73e2734a859 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -148,11 +148,12 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
* Y-coordinate requirement panels we would need to enable
* GTC first.
*/
- dev_priv->psr.psr2_support =
intel_dp_get_y_coord_required(intel_dp);
- DRM_DEBUG_KMS("PSR2 %s on sink",
- dev_priv->psr.psr2_support ? "supported" : "not
supported");
+ dev_priv->psr.sink_psr2_support =
+ intel_dp_get_y_coord_required(intel_dp);
+ DRM_DEBUG_KMS("PSR2 %s on sink", dev_priv->psr.sink_psr2_support
+ ? "supported" : "not supported");
- if (dev_priv->psr.psr2_support) {
+ if (dev_priv->psr.sink_psr2_support) {
dev_priv->psr.colorimetry_support =
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
@@ -193,7 +194,7 @@ static void hsw_psr_setup_vsc(struct intel_dp *intel_dp,
struct drm_i915_private *dev_priv =
to_i915(intel_dig_port->base.base.dev);
struct edp_vsc_psr psr_vsc;
- if (dev_priv->psr.psr2_support) {
+ if (dev_priv->psr.psr2_enabled) {
/* Prepare VSC Header for SU as per EDP 1.4 spec, Table 6.11 */
memset(&psr_vsc, 0, sizeof(psr_vsc));
psr_vsc.sdp_header.HB0 = 0;
@@ -266,7 +267,7 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp)
/* Enable ALPM at sink for psr2 */
- if (dev_priv->psr.psr2_support && dev_priv->psr.alpm)
+ if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm)
drm_dp_dpcd_writeb(&intel_dp->aux,
DP_RECEIVER_ALPM_CONFIG,
DP_ALPM_ENABLE);
@@ -425,7 +426,7 @@ static void hsw_psr_activate(struct intel_dp *intel_dp)
*/
/* psr1 and psr2 are mutually exclusive.*/
- if (dev_priv->psr.psr2_support)
+ if (dev_priv->psr.psr2_enabled)
hsw_activate_psr2(intel_dp);
else
hsw_activate_psr1(intel_dp);
@@ -445,7 +446,7 @@ static bool intel_psr2_config_valid(struct intel_dp
*intel_dp,
* dynamically during PSR enable, and extracted from sink
* caps during eDP detection.
*/
- if (!dev_priv->psr.psr2_support)
+ if (!dev_priv->psr.sink_psr2_support)
return false;
if (INTE
[Intel-gfx] [PATCH 08/12] drm/i915/psr: Cache sink synchronization latency
This value do not change overtime so better cache it than
fetch it every PSR enable.
Signed-off-by: José Roberto de Souza
Cc: Dhinakaran Pandiyan
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/i915_drv.h | 1 +
drivers/gpu/drm/i915/intel_psr.c | 28
2 files changed, 17 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a367fe5538ae..f79338821081 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -607,6 +607,7 @@ struct i915_psr {
bool alpm;
bool has_hw_tracking;
bool psr2_enabled;
+ u8 sink_sync_latency;
void (*enable_source)(struct intel_dp *,
const struct intel_crtc_state *);
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index ad69722c329d..19ee6120d3cd 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -122,6 +122,18 @@ static bool intel_dp_get_alpm_status(struct intel_dp
*intel_dp)
return alpm_caps & DP_ALPM_CAP;
}
+static u8 intel_dp_get_sink_sync_latency(struct intel_dp *intel_dp)
+{
+ u8 val = 0;
+
+ if (drm_dp_dpcd_readb(&intel_dp->aux,
+ DP_SYNCHRONIZATION_LATENCY_IN_SINK, &val) == 1)
+ val &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
+ else
+ DRM_ERROR("Unable to get sink synchronization latency\n");
+ return val;
+}
+
void intel_psr_init_dpcd(struct intel_dp *intel_dp)
{
struct drm_i915_private *dev_priv =
@@ -158,6 +170,8 @@ void intel_psr_init_dpcd(struct intel_dp *intel_dp)
intel_dp_get_colorimetry_status(intel_dp);
dev_priv->psr.alpm =
intel_dp_get_alpm_status(intel_dp);
+ dev_priv->psr.sink_sync_latency =
+ intel_dp_get_sink_sync_latency(intel_dp);
}
}
}
@@ -380,10 +394,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
* with the 5 or 6 idle patterns.
*/
uint32_t idle_frames = max(6, dev_priv->vbt.psr.idle_frames);
- uint32_t val;
- uint8_t sink_latency;
-
- val = idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
+ u32 val = idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
/* FIXME: selective update is probably totally broken because it doesn't
* mesh at all with our frontbuffer tracking. And the hw alone isn't
@@ -393,14 +404,7 @@ static void hsw_activate_psr2(struct intel_dp *intel_dp)
val |= EDP_Y_COORDINATE_VALID | EDP_Y_COORDINATE_ENABLE;
}
- if (drm_dp_dpcd_readb(&intel_dp->aux,
- DP_SYNCHRONIZATION_LATENCY_IN_SINK,
- &sink_latency) == 1) {
- sink_latency &= DP_MAX_RESYNC_FRAME_COUNT_MASK;
- } else {
- sink_latency = 0;
- }
- val |= EDP_PSR2_FRAME_BEFORE_SU(sink_latency + 1);
+ val |= EDP_PSR2_FRAME_BEFORE_SU(dev_priv->psr.sink_sync_latency + 1);
if (dev_priv->vbt.psr.tp2_tp3_wakeup_time > 5)
val |= EDP_PSR2_TP2_TIME_2500;
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/12] drm/i915/psr: Use PSR2 macro for PSR2
Cosmetic change.
Signed-off-by: José Roberto de Souza
---
drivers/gpu/drm/i915/i915_reg.h | 3 ++-
drivers/gpu/drm/i915/intel_psr.c | 2 +-
2 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9c4be6bcd1ef..e660c8a707cf 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -3903,8 +3903,9 @@ enum {
#define EDP_PSR2_TP2_TIME_MASK (3<<8)
#define EDP_PSR2_FRAME_BEFORE_SU_SHIFT 4
#define EDP_PSR2_FRAME_BEFORE_SU_MASK(0xf<<4)
-#define EDP_PSR2_IDLE_MASK 0xf
#define EDP_PSR2_FRAME_BEFORE_SU(a) ((a)<<4)
+#define EDP_PSR2_IDLE_FRAME_MASK 0xf
+#define EDP_PSR2_IDLE_FRAME_SHIFT0
#define EDP_PSR2_STATUS_MMIO(0x6f940)
#define EDP_PSR2_STATUS_STATE_MASK (0xf<<28)
diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c
index f73e2734a859..ad69722c329d 100644
--- a/drivers/gpu/drm/i915/intel_psr.c
+++ b/drivers/gpu/drm/i915/intel_psr.c
@@ -331,7 +331,7 @@ static void hsw_activate_psr1(struct intel_dp *intel_dp)
uint32_t val = EDP_PSR_ENABLE;
val |= max_sleep_time << EDP_PSR_MAX_SLEEP_TIME_SHIFT;
- val |= idle_frames << EDP_PSR_IDLE_FRAME_SHIFT;
+ val |= idle_frames << EDP_PSR2_IDLE_FRAME_SHIFT;
if (IS_HASWELL(dev_priv))
val |= EDP_PSR_MIN_LINK_ENTRY_TIME_8_LINES;
--
2.16.2
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 09/12] drm/i915/psr: Set DPCD PSR2 enable bit when needed
In the 2 eDP1.4a pannels tested set or not set bit have no effect but is better set it and comply with specification. Signed-off-by: José Roberto de Souza Cc: Dhinakaran Pandiyan Cc: Rodrigo Vivi --- drivers/gpu/drm/i915/intel_psr.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_psr.c b/drivers/gpu/drm/i915/intel_psr.c index 19ee6120d3cd..f5c3bcafde25 100644 --- a/drivers/gpu/drm/i915/intel_psr.c +++ b/drivers/gpu/drm/i915/intel_psr.c @@ -278,19 +278,19 @@ static void hsw_psr_enable_sink(struct intel_dp *intel_dp) struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); struct drm_device *dev = dig_port->base.base.dev; struct drm_i915_private *dev_priv = to_i915(dev); - + u8 dpcd_val = DP_PSR_ENABLE; /* Enable ALPM at sink for psr2 */ if (dev_priv->psr.psr2_enabled && dev_priv->psr.alpm) drm_dp_dpcd_writeb(&intel_dp->aux, DP_RECEIVER_ALPM_CONFIG, DP_ALPM_ENABLE); + + if (dev_priv->psr.psr2_enabled) + dpcd_val |= DP_PSR_ENABLE_PSR2; if (dev_priv->psr.link_standby) - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, - DP_PSR_ENABLE | DP_PSR_MAIN_LINK_ACTIVE); - else - drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, - DP_PSR_ENABLE); + dpcd_val |= DP_PSR_MAIN_LINK_ACTIVE; + drm_dp_dpcd_writeb(&intel_dp->aux, DP_PSR_EN_CFG, dpcd_val); drm_dp_dpcd_writeb(&intel_dp->aux, DP_SET_POWER, DP_SET_POWER_D0); } -- 2.16.2 ___ 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: Avoid setting ring freq on invalid rps freqs
Quoting Mika Kuoppala (2018-03-20 15:17:33) > Looping through rps frequencies when both min and max are zero > ends up into an endless loop. This can happen during hardware > enablement. > > Bail out early if rps frequencies are not correctly set yet. > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala 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] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
Quoting Gustavo A. R. Silva (2018-03-22 18:21:54) > The checks are misleading and not required [1]. > > [1] https://lkml.org/lkml/2018/3/19/1792 > > Addresses-Coverity-ID: 1466017 > Cc: Chris Wilson > Signed-off-by: Gustavo A. R. Silva Reviewed-by: Chris Wilson Zhenyu? -Chris ___ 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: Add code to accept valid locked WOPCM register values
On 03/22/2018 01:38 PM, Michał Winiarski wrote:
On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
In current code, we only compare the locked WOPCM register values with the
calculated values. However, we can continue loading GuC/HuC firmware if the
locked (or partially locked) values were valid for current GuC/HuC firmware
sizes.
This patch added a new code path to verify whether the locked register
values can be used for GuC/HuC firmware loading, it will recalculate the
verify the new values if these registers were partially locked, so that we
won't fail the GuC/HuC firmware loading even if the locked register values
are different from the calculated ones.
Signed-off-by: Jackie Li
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Michał Winiarski
Cc: John Spotswood
---
drivers/gpu/drm/i915/intel_wopcm.c | 183 +++--
1 file changed, 157 insertions(+), 26 deletions(-)
[snip]
/**
* intel_wopcm_init() - Initialize the WOPCM structure.
* @wopcm: pointer to intel_wopcm.
@@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
- u32 ctx_rsvd = context_reserved_size(i915);
u32 guc_wopcm_base;
u32 guc_wopcm_size;
- u32 guc_wopcm_rsvd;
int err;
GEM_BUG_ON(!wopcm->size);
@@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
return -E2BIG;
}
- guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
- GUC_WOPCM_OFFSET_ALIGNMENT);
- if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
- DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
- guc_wopcm_base / 1024);
- return -E2BIG;
- }
-
- guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
- guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
+ guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
We already discussed this elsewhere, but just to have this part available
for wider audience:
huc_fw_size is unknown (there may be no huc firmware present) - which means
we're still not able to handle module reload from guc-without-huc into
guc-with-huc
Question remains whether we want to support this scenario, or whether we should
tie GuC and HuC together and refuse to operate early on if either one is not
present. We could remove a lot of code this way...
Thanks. As we discussed I think we should describe this problem in this way:
we shall not make any assumption on either guc_fw_size and huc_fw_size.
On the other handle, we do need calculate the WOPCM layout based on
both GuC and HuC FW sizes, especially when we want to support modparam
enable_guc to enable/disable HuC FW loading dynamically. That's why I
suggest
to update the FW fetch code to report the FW size no matter we turn the HuC
FW loading on or not.
Other aspect of the discussion is whether we should support enable_guc
switching
from 1 to 3 + Adding new HuC FW to the filesystem without a system reboot.
In another word whether we should support FW image updates
(add/delete/update to a new version) in the filesystem without expecting
a system
reboot. My point is it's unlikely we can support this since the FW sizes
would likely
change and we need reconfigure the WO register with the latest FW
available in
the FS, and I think it worth to do it to 100% make sure we won't run
into any
module loading/init errors.
+ err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
+ &guc_wopcm_size);
+ if (err)
+ return err;
DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
guc_wopcm_base / 1024, guc_wopcm_size / 1024);
- guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
- if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
- DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
- (guc_fw_size + guc_wopcm_rsvd) / 1024,
- guc_wopcm_size / 1024);
- return -E2BIG;
- }
-
- err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
- huc_fw_size);
+ err = verify_calculated_values(i915, guc_fw_size, huc_fw_size,
+ guc_wopcm_base, guc_wopcm_size);
Ok - so we're calculating the values in init...
Most likely case, we are going to get these values ready without getting
any forcewake during the init. Then in init_hw we only need to update
these values to the register without wasting anytime on these calculation.
However, this patch introduce more code to handle the rare cases which
these regs were locked with different values from the ones we calculate
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook
== Series Details == Series: series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook URL : https://patchwork.freedesktop.org/series/40514/ State : success == Summary == Series 40514v1 series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook https://patchwork.freedesktop.org/api/1.0/series/40514/revisions/1/mbox/ Known issues: Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b-frame-sequence: incomplete -> PASS (fi-cnl-y3) fdo#103191 Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:445s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:536s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:298s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:516s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:518s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:504s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:406s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:509s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:519s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:587s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:539s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:403s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:419s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:476s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:474s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:470s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:515s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:652s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:439s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:537s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:502s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:494s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:426s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:442s fi-snb-2520m total:3pass:2dwarn:0 dfail:0 fail:0 skip:0 fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s fi-cfl-s3 failed to connect after reboot 40fcdd23bec787a5913496f2b11c5d26bdff985a drm-tip: 2018y-03m-22d-15h-28m-32s UTC integration manifest f3ea4037d879 drm/tinydrm: Make fb_dirty into a lower level hook e90adeef964f drm/simple-kms-helper: Plumb plane state to the enable hook == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8459/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 2/3] drm/i915/uc: Fetch uC firmware in init_early
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 8 ++--
drivers/gpu/drm/i915/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_huc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_uc.c | 37 ++---
drivers/gpu/drm/i915/intel_uc.h | 3 +--
5 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4d244d7..5094ea0 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -692,11 +692,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
- intel_uc_init_fw(dev_priv);
-
ret = i915_gem_init(dev_priv);
if (ret)
- goto cleanup_uc;
+ goto cleanup_irq;
intel_setup_overlay(dev_priv);
@@ -716,8 +714,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
-cleanup_uc:
- intel_uc_fini_fw(dev_priv);
cleanup_irq:
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
@@ -962,6 +958,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
intel_irq_fini(dev_priv);
+ intel_uc_cleanup_early(dev_priv);
i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
@@ -1457,7 +1454,6 @@ void i915_driver_unload(struct drm_device *dev)
i915_reset_error_state(dev_priv);
i915_gem_fini(dev_priv);
- intel_uc_fini_fw(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
intel_power_domains_fini(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 978668c..a9e6fcc 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -275,9 +275,8 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
b/drivers/gpu/drm/i915/intel_huc_fw.c
index bb0f8b7..f93d238 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -155,9 +155,8 @@ static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset. Note that HuC must be loaded before GuC.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..4aad844 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -162,36 +162,35 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
GEM_BUG_ON(i915_modparams.guc_log_level < 0);
}
-void intel_uc_init_early(struct drm_i915_private *dev_priv)
+void intel_uc_init_early(struct drm_i915_private *i915)
{
- intel_guc_init_early(&dev_priv->guc);
- intel_huc_init_early(&dev_priv->huc);
+ struct intel_guc *guc = &i915->guc;
+ struct intel_huc *huc = &i915->huc;
- sanitize_options_early(dev_priv);
-}
+ intel_guc_init_early(guc);
+ intel_huc_init_early(huc);
-void intel_uc_init_fw(struct drm_i915_private *dev_priv)
-{
- if (!USES_GUC(dev_priv))
- return;
+ sanitize_options_early(i915);
- if (USES_HUC(dev_priv))
- intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
+ if (USES_GUC(i915))
+ intel_uc_fw_fetch(i915, &guc->fw);
- intel_uc_f
Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/5] tests/i915_query: Engine queues tests
On 19/03/18 18:22, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
...
Signed-off-by: Tvrtko Ursulin
---
tests/i915_query.c | 381 +
1 file changed, 381 insertions(+)
diff --git a/tests/i915_query.c b/tests/i915_query.c
index c7de8cbd8371..94e7a3297ebd 100644
--- a/tests/i915_query.c
+++ b/tests/i915_query.c
@@ -477,8 +477,358 @@ test_query_topology_known_pci_ids(int fd, int devid)
free(topo_info);
}
+#define DRM_I915_QUERY_ENGINE_QUEUES 2
+
+struct drm_i915_query_engine_queues {
+ /** Engine class as in enum drm_i915_gem_engine_class. */
+ __u16 class;
+
+ /** Engine instance number. */
+ __u16 instance;
+
+ /** Number of requests with unresolved fences and dependencies. */
+ __u32 queued;
+
+ /** Number of ready requests waiting on a slot on GPU. */
+ __u32 runnable;
+
+ /** Number of requests executing on the GPU. */
+ __u32 running;
+
+ __u32 rsvd[5];
+};
+
+static bool query_engine_queues_supported(int fd)
+{
+ struct drm_i915_query_item item = {
+ .query_id = DRM_I915_QUERY_ENGINE_QUEUES,
+ };
+
+ return __i915_query_items(fd, &item, 1) == 0 && item.length > 0;
+}
+
+static void engine_queues_invalid(int fd)
+{
+ struct drm_i915_query_engine_queues queues;
+ struct drm_i915_query_item item;
+ unsigned int len;
+ unsigned int i;
+
+ /* Flags is MBZ. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.flags = 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EINVAL);
+
+ /* Length not zero and not greater or equal required size. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOSPC);
+
+ /* Query correct length. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ i915_query_items(fd, &item, 1);
+ igt_assert(item.length >= 0);
+ len = item.length;
+
+ /* Ivalid pointer. */
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EFAULT);
+
+ /* Reserved fields are MBZ. */
+
+ for (i = 0; i < ARRAY_SIZE(queues.rsvd); i++) {
+ memset(&queues, 0, sizeof(queues));
+ queues.rsvd[i] = 1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -EINVAL);
+ }
+
+ memset(&queues, 0, sizeof(queues));
+ queues.class = -1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOENT);
+
Looks like you've copied the few lines above after.
It seems to be the same test.
+ memset(&queues, 0, sizeof(queues));
+ queues.instance = -1;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.length = len;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, -ENOENT);
+}
+
+static void engine_queues(int fd, const struct intel_execution_engine2 *e)
+{
+ struct drm_i915_query_engine_queues queues;
+ struct drm_i915_query_item item;
+ unsigned int len;
+
+ /* Query required buffer length. */
+ memset(&queues, 0, sizeof(queues));
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ i915_query_items(fd, &item, 1);
+ igt_assert(item.length >= 0);
+ igt_assert(item.length <= sizeof(queues));
+ len = item.length;
+
+ /* Check length larger than required works and reports same length. */
+ memset(&queues, 0, sizeof(queues));
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ item.length = len + 1;
+ i915_query_items(fd, &item, 1);
+ igt_assert_eq(item.length, len);
+
+ /* Actual query. */
+ memset(&queues, 0, sizeof(queues));
+ queues.class = e->class;
+ queues.instance = e->instance;
+ memset(&item, 0, sizeof(item));
+ item.query_id = DRM_I915_QUERY_ENGINE_QUEUES;
+ item.data_ptr = to_user_pointer(&queues);
+ item.length = len;
+ i915_query_it
[Intel-gfx] [PATCH v2 3/3] HAX: Enable GuC for CI
Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2 1/3] drm/i915: Reorder early initialization
In upcoming patch, we want to perform more actions in early
initialization of the uC. This reordering will help resolve
new dependencies that will be introduced by future patch.
v2: s/i915_gem_load_init/i915_gem_init_early (Chris)
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
Reviewed-by: Chris Wilson
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
drivers/gpu/drm/i915/i915_drv.h | 2 +-
drivers/gpu/drm/i915/i915_gem.c | 3 +--
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7d3275..4d244d7 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -919,17 +919,21 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
- intel_wopcm_init_early(&dev_priv->wopcm);
- intel_uc_init_early(dev_priv);
i915_memcpy_init_early(dev_priv);
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
goto err_engines;
+ ret = i915_gem_init_early(dev_priv);
+ if (ret < 0)
+ goto err_workqueues;
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
+ intel_wopcm_init_early(&dev_priv->wopcm);
+ intel_uc_init_early(dev_priv);
intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
@@ -938,18 +942,13 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- ret = i915_gem_load_init(dev_priv);
- if (ret < 0)
- goto err_irq;
-
intel_display_crc_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
return 0;
-err_irq:
- intel_irq_fini(dev_priv);
+err_workqueues:
i915_workqueues_cleanup(dev_priv);
err_engines:
i915_engines_cleanup(dev_priv);
@@ -962,8 +961,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
*/
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
- i915_gem_load_cleanup(dev_priv);
intel_irq_fini(dev_priv);
+ i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
}
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index c9c3b2b..65a0b53 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2869,7 +2869,7 @@ int i915_gem_get_aperture_ioctl(struct drm_device *dev,
void *data,
int i915_gem_wait_ioctl(struct drm_device *dev, void *data,
struct drm_file *file_priv);
void i915_gem_sanitize(struct drm_i915_private *i915);
-int i915_gem_load_init(struct drm_i915_private *dev_priv);
+int i915_gem_init_early(struct drm_i915_private *dev_priv);
void i915_gem_load_cleanup(struct drm_i915_private *dev_priv);
void i915_gem_load_init_fences(struct drm_i915_private *dev_priv);
int i915_gem_freeze(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 802df8e..bce2e26 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -5502,8 +5502,7 @@ static void i915_gem_init__mm(struct drm_i915_private
*i915)
INIT_WORK(&i915->mm.free_work, __i915_gem_free_work);
}
-int
-i915_gem_load_init(struct drm_i915_private *dev_priv)
+int i915_gem_init_early(struct drm_i915_private *dev_priv)
{
int err = -ENOMEM;
--
1.9.1
___
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/2] drm/simple-kms-helper: Plumb plane state to the enable hook
== Series Details == Series: series starting with [1/2] drm/simple-kms-helper: Plumb plane state to the enable hook URL : https://patchwork.freedesktop.org/series/40514/ State : warning == Summary == $ dim checkpatch origin/drm-tip e90adeef964f drm/simple-kms-helper: Plumb plane state to the enable hook f3ea4037d879 drm/tinydrm: Make fb_dirty into a lower level hook -:430: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #430: FILE: include/drm/tinydrm/tinydrm.h:30: + struct drm_file *file_priv, unsigned flags, -:431: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #431: FILE: include/drm/tinydrm/tinydrm.h:31: + unsigned color, struct drm_clip_rect *clips, -:432: WARNING:UNSPECIFIED_INT: Prefer 'unsigned int' to bare use of 'unsigned' #432: FILE: include/drm/tinydrm/tinydrm.h:32: + unsigned num_clips); total: 0 errors, 3 warnings, 0 checks, 344 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.
Quoting Dhinakaran Pandiyan (2018-03-20 22:41:51)
> diff --git a/drivers/gpu/drm/i915/intel_psr.c
> b/drivers/gpu/drm/i915/intel_psr.c
> index 64ecea80438d..a83d95b1b587 100644
> --- a/drivers/gpu/drm/i915/intel_psr.c
> +++ b/drivers/gpu/drm/i915/intel_psr.c
> @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct drm_i915_private
> *dev_priv, u32 psr_iir)
> {
> u32 transcoders = BIT(TRANSCODER_EDP);
> enum transcoder cpu_transcoder;
> + ktime_t time_ns = ktime_get();
> + unsigned long flags = 0;
>
> if (INTEL_GEN(dev_priv) >= 8)
> transcoders |= BIT(TRANSCODER_A) |
>BIT(TRANSCODER_B) |
>BIT(TRANSCODER_C);
>
> + write_seqlock_irqsave(&dev_priv->psr.debug_lock, flags);
You are inside a hardirq handler. irqsave/irqrestore are not required.
Even a seqlock here looks overkill, but whatever. (I don't buy that you
need that precise level of coordination for a slow debugfs interface.)
> for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder, transcoders)
> {
> + bool handled = false;
> +
> + /* PSR supported only on one transcoder currently */
> + WARN_ON_ONCE(handled);
Now this is just silly. At least get the check right.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 5/5] drm/i915/psr: Timestamps for PSR entry and exit interrupts.
On Thu, 2018-03-22 at 11:21 +0200, Ville Syrjälä wrote:
> On Thu, Mar 22, 2018 at 01:05:24AM +, Pandiyan, Dhinakaran wrote:
> > On Wed, 2018-03-21 at 21:48 +0200, Ville Syrjälä wrote:
> > > On Tue, Mar 20, 2018 at 03:41:51PM -0700, Dhinakaran Pandiyan wrote:
> > > > Timestamps are useful for IGT tests that trigger PSR exit and/or wait
> > > > for
> > > > PSR entry.
> > > >
> > > > Cc: Ville Syrjälä
> > > > Cc: Rodrigo Vivi
> > > > Cc: Daniel Vetter
> > > > Signed-off-by: Dhinakaran Pandiyan
> > > > ---
> > > > drivers/gpu/drm/i915/i915_debugfs.c | 12
> > > > drivers/gpu/drm/i915/i915_drv.h | 3 +++
> > > > drivers/gpu/drm/i915/intel_psr.c| 21 +++--
> > > > 3 files changed, 34 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > index 669f3d56054a..d28dc4d8388e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > > @@ -2686,6 +2686,18 @@ static int i915_edp_psr_status(struct seq_file
> > > > *m, void *data)
> > > > }
> > > > mutex_unlock(&dev_priv->psr.lock);
> > > >
> > > > + if (READ_ONCE(dev_priv->psr.debug)) {
> > > > + unsigned int seq;
> > > > +
> > > > + do {
> > > > + seq = read_seqbegin(&dev_priv->psr.debug_lock);
> > > > + seq_printf(m, "Last attempted entry at: %lld\n",
> > > > + dev_priv->psr.last_entry_attempt);
> > > > + seq_printf(m, "Last exit at: %lld\n",
> > > > + dev_priv->psr.last_exit);
> > > > + } while (read_seqretry(&dev_priv->psr.debug_lock, seq));
> > >
> > > What does the seqlock buy us?
> >
> > Reading debugfs wouldn't block the update inside the irq handler,
> > compared to using a spinlock. We need to serialize the read and update
> > parts, don't we? Otherwise tests might end up reading partial updates.
>
> Hmm. ktime_t is 64 bits so I guess on 32bit systems it could be a slight
> issue. Not sure we should care that much about PSR debug on 32bit though.
> It's a rather unlikely configuration, and at least we don't do that in
> the ci.
>
Another thing is, if two IIR bits are set at the same time. EXIT and
PRE_ENTRY probably won't be though. How about if an earlier interrupt
was not handled? Won't multiple IIR bits be set? Implementing the lock
is slightly future proof and doesn't slow down irq handling.
> >
> > >
> > > > + }
> > > > +
> > > > intel_runtime_pm_put(dev_priv);
> > > > return 0;
> > > > }
> > > > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > > > b/drivers/gpu/drm/i915/i915_drv.h
> > > > index 136fa2267a66..b8170882e1ab 100644
> > > > --- a/drivers/gpu/drm/i915/i915_drv.h
> > > > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > > > @@ -609,6 +609,9 @@ struct i915_psr {
> > > > bool alpm;
> > > > bool has_hw_tracking;
> > > > bool debug;
> > > > + ktime_t last_entry_attempt;
> > > > + ktime_t last_exit;
> > > > + seqlock_t debug_lock;
> > > >
> > > > void (*enable_source)(struct intel_dp *,
> > > > const struct intel_crtc_state *);
> > > > diff --git a/drivers/gpu/drm/i915/intel_psr.c
> > > > b/drivers/gpu/drm/i915/intel_psr.c
> > > > index 64ecea80438d..a83d95b1b587 100644
> > > > --- a/drivers/gpu/drm/i915/intel_psr.c
> > > > +++ b/drivers/gpu/drm/i915/intel_psr.c
> > > > @@ -125,28 +125,44 @@ void intel_psr_irq_handler(struct
> > > > drm_i915_private *dev_priv, u32 psr_iir)
> > > > {
> > > > u32 transcoders = BIT(TRANSCODER_EDP);
> > > > enum transcoder cpu_transcoder;
> > > > + ktime_t time_ns = ktime_get();
> > > > + unsigned long flags = 0;
> > > >
> > > > if (INTEL_GEN(dev_priv) >= 8)
> > > > transcoders |= BIT(TRANSCODER_A) |
> > > >BIT(TRANSCODER_B) |
> > > >BIT(TRANSCODER_C);
> > > >
> > > > + write_seqlock_irqsave(&dev_priv->psr.debug_lock, flags);
> > > > for_each_cpu_transcoder_masked(dev_priv, cpu_transcoder,
> > > > transcoders) {
> > > > + bool handled = false;
> > > > +
> > > > + /* PSR supported only on one transcoder currently */
> > > > + WARN_ON_ONCE(handled);
> > > > +
> > > > /* FIXME: Exit PSR when this happens. */
> > > > - if (psr_iir & EDP_PSR_ERROR(cpu_transcoder))
> > > > + if (psr_iir & EDP_PSR_ERROR(cpu_transcoder)) {
> > > > + handled = true;
> > > > DRM_DEBUG_KMS("[transcoder %s] PSR aux error\n",
> > > > transcoder_name(cpu_transcoder));
> > > >
> > > > + }
> > > > +
> > > > if (psr_iir
Re: [Intel-gfx] [PATCH 2/3] drm/i915/uc: Fetch uC firmware in init_early
Quoting Michal Wajdeczko (2018-03-22 20:36:58) > We were fetching uC firmwares in separate uc_init_fw step, while > there is no reason why we can't fetch them during init_early. > This will also simplify upcoming patches, as size of the firmware > may be used for register initialization. > > Signed-off-by: Michal Wajdeczko > Cc: Michal Winiarski > Cc: Sagar Arun Kamble > Cc: Chris Wilson > Cc: Joonas Lahtinen Looked ok, didn't spot you sneaking in any major changes (who would do that???) Reviewed-by: Chris Wilson -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/3] drm/i915: Reorder early initialization
Quoting Michal Wajdeczko (2018-03-22 20:36:57)
> In upcoming patch, we want to perform more actions in early
> initialization of the uC. This reordering will help resolve
> new dependencies that will be introduced by future patch.
>
> Signed-off-by: Michal Wajdeczko
> Cc: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/i915_drv.c | 17 -
> 1 file changed, 8 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index a7d3275..f60bc04 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -919,17 +919,21 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv,
> mutex_init(&dev_priv->wm.wm_mutex);
> mutex_init(&dev_priv->pps_mutex);
>
> - intel_wopcm_init_early(&dev_priv->wopcm);
> - intel_uc_init_early(dev_priv);
> i915_memcpy_init_early(dev_priv);
>
> ret = i915_workqueues_init(dev_priv);
> if (ret < 0)
> goto err_engines;
>
> + ret = i915_gem_load_init(dev_priv);
> + if (ret < 0)
> + goto err_workqueues;
Scary. But really misnamed. I was thinking this was i915_gem_init(),
could you rename this i915_gem_init_early() to indicate that all it is
doing is the early allocations and nothing HW related.
> /* This must be called before any calls to HAS_PCH_* */
> intel_detect_pch(dev_priv);
>
> + intel_wopcm_init_early(&dev_priv->wopcm);
> + intel_uc_init_early(dev_priv);
> intel_pm_setup(dev_priv);
> intel_init_dpio(dev_priv);
> intel_power_domains_init(dev_priv);
> @@ -938,18 +942,13 @@ static int i915_driver_init_early(struct
> drm_i915_private *dev_priv,
> intel_init_display_hooks(dev_priv);
> intel_init_clock_gating_hooks(dev_priv);
> intel_init_audio_hooks(dev_priv);
> - ret = i915_gem_load_init(dev_priv);
> - if (ret < 0)
> - goto err_irq;
> -
> intel_display_crc_init(dev_priv);
>
> intel_detect_preproduction_hw(dev_priv);
>
> return 0;
>
> -err_irq:
> - intel_irq_fini(dev_priv);
> +err_workqueues:
> i915_workqueues_cleanup(dev_priv);
> err_engines:
> i915_engines_cleanup(dev_priv);
> @@ -962,8 +961,8 @@ static int i915_driver_init_early(struct drm_i915_private
> *dev_priv,
> */
> static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
> {
> - i915_gem_load_cleanup(dev_priv);
> intel_irq_fini(dev_priv);
> + i915_gem_load_cleanup(dev_priv);
Ok, onion preserved.
> i915_workqueues_cleanup(dev_priv);
> i915_engines_cleanup(dev_priv);
* mutters about dead code.
Code reordering looks fine,
Reviewed-by: Chris Wilson
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 1/5] drm/i915: Enable edp psr error interrupts on hsw
On Thu, Mar 22, 2018 at 01:33:10PM +0200, Ville Syrjälä wrote:
> On Thu, Mar 22, 2018 at 01:19:19AM +, Pandiyan, Dhinakaran wrote:
> >
> >
> >
> > On Wed, 2018-03-21 at 21:29 +0200, Ville Syrjälä wrote:
> > > On Wed, Mar 21, 2018 at 07:19:53PM +, Pandiyan, Dhinakaran wrote:
> > > >
> > > >
> > > >
> > > > On Wed, 2018-03-21 at 20:59 +0200, Ville Syrjälä wrote:
> > > > > On Tue, Mar 20, 2018 at 03:41:47PM -0700, Dhinakaran Pandiyan wrote:
> > > > > > From: Daniel Vetter
> > > > > >
> > > > > > The definitions for the error register should be valid on bdw/skl
> > > > > > too,
> > > > > > but there we haven't even enabled DE_MISC handling yet.
> > > > > >
> > > > > > Somewhat confusing the the moved register offset on bdw is only for
> > > > > > the _CTL/_AUX register, and that _IIR/IMR stayed where they have
> > > > > > been
> > > > > > on bdw.
> > > > > >
> > > > > > v2: Fixes from Ville.
> > > > > >
> > > > > > v3: From DK
> > > > > > * Rebased on drm-tip
> > > > > > * Removed BDW IIR bit definition, looks like an unintentional
> > > > > > change that
> > > > > > should be in the following patch.
> > > > > >
> > > > > > Cc: Ville Syrjälä
> > > > > > Cc: Rodrigo Vivi
> > > > > > Cc: Daniel Vetter
> > > > > > Signed-off-by: Daniel Vetter
> > > > > > Signed-off-by: Dhinakaran Pandiyan
> > > > > > ---
> > > > > > drivers/gpu/drm/i915/i915_irq.c | 34
> > > > > > ++
> > > > > > drivers/gpu/drm/i915/i915_reg.h | 8
> > > > > > drivers/gpu/drm/i915/intel_psr.c | 3 ++-
> > > > > > 3 files changed, 44 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > index 44eef355e12c..e94a835b7515 100644
> > > > > > --- a/drivers/gpu/drm/i915/i915_irq.c
> > > > > > +++ b/drivers/gpu/drm/i915/i915_irq.c
> > > > > > @@ -2392,6 +2392,26 @@ static void ilk_display_irq_handler(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > > ironlake_rps_change_irq_handler(dev_priv);
> > > > > > }
> > > > > >
> > > > > > +static void hsw_edp_psr_irq_handler(struct drm_i915_private
> > > > > > *dev_priv)
> > > > > > +{
> > > > > > + u32 edp_psr_iir = I915_READ(EDP_PSR_IIR);
> > > > > > +
> > > > > > + if (edp_psr_iir & EDP_PSR_ERROR)
> > > > > > + DRM_DEBUG_KMS("PSR error\n");
> > > > > > +
> > > > > > + if (edp_psr_iir & EDP_PSR_PRE_ENTRY) {
> > > > > > + DRM_DEBUG_KMS("PSR prepare entry in 2 vblanks\n");
> > > > >
> > > > > I doubt we want to have the entry/exit interrupts generate all this
> > > > > noise in dmesg all the time. We should probably only enable the
> > > > > interrupts for testing. The error interrupt I suppose we want always,
> > > > > might even want DRM_ERROR on it.
> > > >
> > > > I implement debugfs control in Patch 4/5, agreed on DRM_ERROR.
> > >
> > > Right. It's a bit hard to read this with stuff getting
> > > added/remove/moved more or less randomly.
> > >
> > > >
> > > > >
> > > > > > + I915_WRITE(EDP_PSR_IMR, EDP_PSR_PRE_ENTRY);
> > > > > > + }
> > > > > > +
> > > > > > + if (edp_psr_iir & EDP_PSR_POST_EXIT) {
> > > > > > + DRM_DEBUG_KMS("PSR exit completed\n");
> > > > > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > > > > + }
> > > > > > +
> > > > > > + I915_WRITE(EDP_PSR_IIR, edp_psr_iir);
> > > > > > +}
> > > > > > +
> > > > > > static void ivb_display_irq_handler(struct drm_i915_private
> > > > > > *dev_priv,
> > > > > > u32 de_iir)
> > > > > > {
> > > > > > @@ -2404,6 +2424,9 @@ static void ivb_display_irq_handler(struct
> > > > > > drm_i915_private *dev_priv,
> > > > > > if (de_iir & DE_ERR_INT_IVB)
> > > > > > ivb_err_int_handler(dev_priv);
> > > > > >
> > > > > > + if (de_iir & DE_EDP_PSR_INT_HSW)
> > > > > > + hsw_edp_psr_irq_handler(dev_priv);
> > > > > > +
> > > > > > if (de_iir & DE_AUX_CHANNEL_A_IVB)
> > > > > > dp_aux_irq_handler(dev_priv);
> > > > > >
> > > > > > @@ -3252,6 +3275,11 @@ static void ironlake_irq_reset(struct
> > > > > > drm_device *dev)
> > > > > > if (IS_GEN7(dev_priv))
> > > > > > I915_WRITE(GEN7_ERR_INT, 0x);
> > > > > >
> > > > > > + if (IS_HASWELL(dev_priv)) {
> > > > > > + I915_WRITE(EDP_PSR_IMR, 0x);
> > > > > > + I915_WRITE(EDP_PSR_IIR, 0x);
> > > > > > + }
> > > > > > +
> > > > > > gen5_gt_irq_reset(dev_priv);
> > > > > >
> > > > > > ibx_irq_reset(dev_priv);
> > > > > > @@ -3663,6 +3691,12 @@ static int ironlake_irq_postinstall(struct
> > > > > > drm_device *dev)
> > > > > > DE_DP_A_HOTPLUG);
> > > > > > }
> > > > > >
> > > > > > + if (IS_HASWELL(dev_priv)) {
> > > > > > + gen3_assert_iir_is_zero(dev_priv, EDP_PSR_IIR);
> > > > > > + I915_WRITE(EDP_PSR_IMR, 0);
> > > > > > + display_mask |= DE_E
Re: [Intel-gfx] [PATCH 1/2] drm/i915: Add code to accept valid locked WOPCM register values
On Tue, Mar 20, 2018 at 04:18:46PM -0700, Jackie Li wrote:
> In current code, we only compare the locked WOPCM register values with the
> calculated values. However, we can continue loading GuC/HuC firmware if the
> locked (or partially locked) values were valid for current GuC/HuC firmware
> sizes.
>
> This patch added a new code path to verify whether the locked register
> values can be used for GuC/HuC firmware loading, it will recalculate the
> verify the new values if these registers were partially locked, so that we
> won't fail the GuC/HuC firmware loading even if the locked register values
> are different from the calculated ones.
>
> Signed-off-by: Jackie Li
> Cc: Michal Wajdeczko
> Cc: Sagar Arun Kamble
> Cc: Michał Winiarski
> Cc: John Spotswood
> ---
> drivers/gpu/drm/i915/intel_wopcm.c | 183
> +++--
> 1 file changed, 157 insertions(+), 26 deletions(-)
[snip]
> /**
> * intel_wopcm_init() - Initialize the WOPCM structure.
> * @wopcm: pointer to intel_wopcm.
> @@ -155,10 +202,8 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> struct drm_i915_private *i915 = wopcm_to_i915(wopcm);
> u32 guc_fw_size = intel_uc_fw_get_upload_size(&i915->guc.fw);
> u32 huc_fw_size = intel_uc_fw_get_upload_size(&i915->huc.fw);
> - u32 ctx_rsvd = context_reserved_size(i915);
> u32 guc_wopcm_base;
> u32 guc_wopcm_size;
> - u32 guc_wopcm_rsvd;
> int err;
>
> GEM_BUG_ON(!wopcm->size);
> @@ -175,30 +220,17 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> return -E2BIG;
> }
>
> - guc_wopcm_base = ALIGN(huc_fw_size + WOPCM_RESERVED_SIZE,
> -GUC_WOPCM_OFFSET_ALIGNMENT);
> - if ((guc_wopcm_base + ctx_rsvd) >= wopcm->size) {
> - DRM_ERROR("GuC WOPCM base (%uKiB) is too big.\n",
> - guc_wopcm_base / 1024);
> - return -E2BIG;
> - }
> -
> - guc_wopcm_size = wopcm->size - guc_wopcm_base - ctx_rsvd;
> - guc_wopcm_size &= GUC_WOPCM_SIZE_MASK;
> + guc_wopcm_base = calculate_min_guc_wopcm_base(huc_fw_size);
We already discussed this elsewhere, but just to have this part available
for wider audience:
huc_fw_size is unknown (there may be no huc firmware present) - which means
we're still not able to handle module reload from guc-without-huc into
guc-with-huc
Question remains whether we want to support this scenario, or whether we should
tie GuC and HuC together and refuse to operate early on if either one is not
present. We could remove a lot of code this way...
> + err = calculate_max_guc_wopcm_size(wopcm, guc_wopcm_base,
> +&guc_wopcm_size);
> + if (err)
> + return err;
>
> DRM_DEBUG_DRIVER("Calculated GuC WOPCM Region: [%uKiB, %uKiB)\n",
>guc_wopcm_base / 1024, guc_wopcm_size / 1024);
>
> - guc_wopcm_rsvd = GUC_WOPCM_RESERVED + GUC_WOPCM_STACK_RESERVED;
> - if ((guc_fw_size + guc_wopcm_rsvd) > guc_wopcm_size) {
> - DRM_ERROR("Need %uKiB WOPCM for GuC, %uKiB available.\n",
> - (guc_fw_size + guc_wopcm_rsvd) / 1024,
> - guc_wopcm_size / 1024);
> - return -E2BIG;
> - }
> -
> - err = check_hw_restriction(i915, guc_wopcm_base, guc_wopcm_size,
> -huc_fw_size);
> + err = verify_calculated_values(i915, guc_fw_size, huc_fw_size,
> +guc_wopcm_base, guc_wopcm_size);
Ok - so we're calculating the values in init...
> if (err)
> return err;
>
> @@ -208,6 +240,92 @@ int intel_wopcm_init(struct intel_wopcm *wopcm)
> return 0;
> }
>
[snip]
> static inline int write_and_verify(struct drm_i915_private *dev_priv,
> i915_reg_t reg, u32 val, u32 mask,
> u32 locked_bit)
> @@ -231,7 +349,8 @@ static inline int write_and_verify(struct
> drm_i915_private *dev_priv,
> * will verify the register values to make sure the registers are locked with
> * correct values.
> *
> - * Return: 0 on success. -EIO if registers were locked with incorrect values.
> + * Return: 0 on success. Minus error code if registered were locked with
> + * incorrect values.-EIO if registers failed to lock with correct values.
> */
> int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
> {
> @@ -247,27 +366,39 @@ int intel_wopcm_init_hw(struct intel_wopcm *wopcm)
> GEM_BUG_ON(!wopcm->guc.size);
> GEM_BUG_ON(!wopcm->guc.base);
>
> + err = verify_locked_values_and_update(wopcm);
> + if (err) {
> + DRM_ERROR("WOPCM registers are locked with invalid values.\n");
> + goto err_out;
> + }
> +
...Only to throw everything out if the regs are locked in init_hw?
Since we've changed the logic, I think we should refactor a bit by changing
the ordering.
We could start from
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Include the trace as a debug aide
Quoting Jeff McGee (2018-03-22 19:29:16)
> On Thu, Mar 22, 2018 at 02:30:09PM +, Chris Wilson wrote:
> > Quoting Mika Kuoppala (2018-03-22 14:26:41)
> > > Chris Wilson writes:
> > >
> > > > If we fail to reset the GPU in a timely fashion, dump the GEM trace so
> > > > that we can see what operations were in flight when the GPU got stuck.
> > > >
> > > > v2: There's more than one timeout that deserves tracing!
> > > > v3: Silence checkpatch by not even using a product at all!
> > > >
> > > > Signed-off-by: Chris Wilson
> > > > ---
> > > > drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 23
> > > > ---
> > > > 1 file changed, 20 insertions(+), 3 deletions(-)
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > > index 4372826998aa..9b235dae8dd9 100644
> > > > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > > @@ -260,8 +260,11 @@ static void wedge_me(struct work_struct *work)
> > > > {
> > > > struct wedge_me *w = container_of(work, typeof(*w), work.work);
> > > >
> > > > - pr_err("%pS timed out, cancelling all further testing.\n",
> > > > -w->symbol);
> > > > + pr_err("%pS timed out, cancelling all further testing.\n",
> > > > w->symbol);
> > > > +
> > > > + GEM_TRACE("%pS timed out.\n", w->symbol);
> > > > + GEM_TRACE_DUMP();
> > > > +
> > > > i915_gem_set_wedged(w->i915);
> > > > }
> > > >
> > > > @@ -621,9 +624,19 @@ static int active_engine(void *data)
> > > > mutex_unlock(&engine->i915->drm.struct_mutex);
> > > >
> > > > if (old) {
> > > > - i915_request_wait(old, 0, MAX_SCHEDULE_TIMEOUT);
> > > > + if (i915_request_wait(old, 0, HZ) < 0) {
> > > > + GEM_TRACE("%s timed out.\n",
> > > > engine->name);
> > > > + GEM_TRACE_DUMP();
> > > > +
> > > > + i915_gem_set_wedged(engine->i915);
> > > > + i915_request_put(old);
> > > > + err = -EIO;
> > > > + break;
> > > > + }
> > >
> > > Using err = i915_request_wait() could have saved one extra request_put
> > > but I dunno if it would be any cleaner.
> >
> > It's also -ETIME, which didn't fit my intention.
> >
> > >
> > > > i915_request_put(old);
> > > > }
> > > > +
> > > > + cond_resched();
> > >
> > > To give more slack for other engines and main thread to proceed?
> >
> > Yes. Otherwise, it spins mighty fine.
> > >
> > > > }
> > > >
> > > > for (count = 0; count < ARRAY_SIZE(rq); count++)
> > > > @@ -1126,6 +1139,10 @@ int intel_hangcheck_live_selftests(struct
> > > > drm_i915_private *i915)
> > > >
> > > > err = i915_subtests(tests, i915);
> > > >
> > > > + mutex_lock(&i915->drm.struct_mutex);
> > > > + flush_test(i915, I915_WAIT_LOCKED);
> > > > + mutex_unlock(&i915->drm.struct_mutex);
> > > > +
> > >
> > > To wash out leftovers.
> >
> > Yeah, from the early abort we left requests unaccounted for and needed
> > to grab the struct_mutex to run retire. Otherwise we hit assertions
> > later on about trying to unload the driver with requests still inflight.
> > -Chris
>
> On this and the 3 others in this series...
>
> Reviewed-by: Jeff McGee
Much appreciated. Pushed, let's hope CI holds up and that we're ready to
start talking about the real changes required for forced preemption as
opposed to getting the existing code working.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915/uc: Fetch uC firmware in init_early
We were fetching uC firmwares in separate uc_init_fw step, while
there is no reason why we can't fetch them during init_early.
This will also simplify upcoming patches, as size of the firmware
may be used for register initialization.
Signed-off-by: Michal Wajdeczko
Cc: Michal Winiarski
Cc: Sagar Arun Kamble
Cc: Chris Wilson
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 8 ++--
drivers/gpu/drm/i915/intel_guc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_huc_fw.c | 5 ++---
drivers/gpu/drm/i915/intel_uc.c | 37 ++---
drivers/gpu/drm/i915/intel_uc.h | 3 +--
5 files changed, 25 insertions(+), 33 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index f60bc04..3d02a0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -692,11 +692,9 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (ret)
goto cleanup_irq;
- intel_uc_init_fw(dev_priv);
-
ret = i915_gem_init(dev_priv);
if (ret)
- goto cleanup_uc;
+ goto cleanup_irq;
intel_setup_overlay(dev_priv);
@@ -716,8 +714,6 @@ static int i915_load_modeset_init(struct drm_device *dev)
if (i915_gem_suspend(dev_priv))
DRM_ERROR("failed to idle hardware; continuing to unload!\n");
i915_gem_fini(dev_priv);
-cleanup_uc:
- intel_uc_fini_fw(dev_priv);
cleanup_irq:
drm_irq_uninstall(dev);
intel_teardown_gmbus(dev_priv);
@@ -962,6 +958,7 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
intel_irq_fini(dev_priv);
+ intel_uc_cleanup_early(dev_priv);
i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
@@ -1457,7 +1454,6 @@ void i915_driver_unload(struct drm_device *dev)
i915_reset_error_state(dev_priv);
i915_gem_fini(dev_priv);
- intel_uc_fini_fw(dev_priv);
intel_fbc_cleanup_cfb(dev_priv);
intel_power_domains_fini(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_guc_fw.c
b/drivers/gpu/drm/i915/intel_guc_fw.c
index 978668c..a9e6fcc 100644
--- a/drivers/gpu/drm/i915/intel_guc_fw.c
+++ b/drivers/gpu/drm/i915/intel_guc_fw.c
@@ -275,9 +275,8 @@ static int guc_fw_xfer(struct intel_uc_fw *guc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_huc_fw.c
b/drivers/gpu/drm/i915/intel_huc_fw.c
index bb0f8b7..f93d238 100644
--- a/drivers/gpu/drm/i915/intel_huc_fw.c
+++ b/drivers/gpu/drm/i915/intel_huc_fw.c
@@ -155,9 +155,8 @@ static int huc_fw_xfer(struct intel_uc_fw *huc_fw, struct
i915_vma *vma)
* Called from intel_uc_init_hw() during driver load, resume from sleep and
* after a GPU reset. Note that HuC must be loaded before GuC.
*
- * The firmware image should have already been fetched into memory by the
- * earlier call to intel_uc_init_fw(), so here we need to only check that
- * fetch succeeded, and then transfer the image to the h/w.
+ * The firmware image should have already been fetched into memory, so only
+ * check that fetch succeeded, and then transfer the image to the h/w.
*
* Return: non-zero code on error
*/
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 34f8a2c..4aad844 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -162,36 +162,35 @@ static void sanitize_options_early(struct
drm_i915_private *dev_priv)
GEM_BUG_ON(i915_modparams.guc_log_level < 0);
}
-void intel_uc_init_early(struct drm_i915_private *dev_priv)
+void intel_uc_init_early(struct drm_i915_private *i915)
{
- intel_guc_init_early(&dev_priv->guc);
- intel_huc_init_early(&dev_priv->huc);
+ struct intel_guc *guc = &i915->guc;
+ struct intel_huc *huc = &i915->huc;
- sanitize_options_early(dev_priv);
-}
+ intel_guc_init_early(guc);
+ intel_huc_init_early(huc);
-void intel_uc_init_fw(struct drm_i915_private *dev_priv)
-{
- if (!USES_GUC(dev_priv))
- return;
+ sanitize_options_early(i915);
- if (USES_HUC(dev_priv))
- intel_uc_fw_fetch(dev_priv, &dev_priv->huc.fw);
+ if (USES_GUC(i915))
+ intel_uc_fw_fetch(i915, &guc->fw);
- intel_uc_fw_fetch(dev_priv, &dev_priv
[Intel-gfx] [PATCH 3/3] HAX: Enable GuC for CI
Signed-off-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_params.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/i915_params.h b/drivers/gpu/drm/i915/i915_params.h index c963603..53037b5 100644 --- a/drivers/gpu/drm/i915/i915_params.h +++ b/drivers/gpu/drm/i915/i915_params.h @@ -47,7 +47,7 @@ param(int, disable_power_well, -1) \ param(int, enable_ips, 1) \ param(int, invert_brightness, 0) \ - param(int, enable_guc, 0) \ + param(int, enable_guc, -1) \ param(int, guc_log_level, -1) \ param(char *, guc_firmware_path, NULL) \ param(char *, huc_firmware_path, NULL) \ -- 1.9.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: Reorder early initialization
In upcoming patch, we want to perform more actions in early
initialization of the uC. This reordering will help resolve
new dependencies that will be introduced by future patch.
Signed-off-by: Michal Wajdeczko
Cc: Chris Wilson
Cc: Tvrtko Ursulin
Cc: Joonas Lahtinen
---
drivers/gpu/drm/i915/i915_drv.c | 17 -
1 file changed, 8 insertions(+), 9 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a7d3275..f60bc04 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -919,17 +919,21 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
mutex_init(&dev_priv->wm.wm_mutex);
mutex_init(&dev_priv->pps_mutex);
- intel_wopcm_init_early(&dev_priv->wopcm);
- intel_uc_init_early(dev_priv);
i915_memcpy_init_early(dev_priv);
ret = i915_workqueues_init(dev_priv);
if (ret < 0)
goto err_engines;
+ ret = i915_gem_load_init(dev_priv);
+ if (ret < 0)
+ goto err_workqueues;
+
/* This must be called before any calls to HAS_PCH_* */
intel_detect_pch(dev_priv);
+ intel_wopcm_init_early(&dev_priv->wopcm);
+ intel_uc_init_early(dev_priv);
intel_pm_setup(dev_priv);
intel_init_dpio(dev_priv);
intel_power_domains_init(dev_priv);
@@ -938,18 +942,13 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
intel_init_display_hooks(dev_priv);
intel_init_clock_gating_hooks(dev_priv);
intel_init_audio_hooks(dev_priv);
- ret = i915_gem_load_init(dev_priv);
- if (ret < 0)
- goto err_irq;
-
intel_display_crc_init(dev_priv);
intel_detect_preproduction_hw(dev_priv);
return 0;
-err_irq:
- intel_irq_fini(dev_priv);
+err_workqueues:
i915_workqueues_cleanup(dev_priv);
err_engines:
i915_engines_cleanup(dev_priv);
@@ -962,8 +961,8 @@ static int i915_driver_init_early(struct drm_i915_private
*dev_priv,
*/
static void i915_driver_cleanup_early(struct drm_i915_private *dev_priv)
{
- i915_gem_load_cleanup(dev_priv);
intel_irq_fini(dev_priv);
+ i915_gem_load_cleanup(dev_priv);
i915_workqueues_cleanup(dev_priv);
i915_engines_cleanup(dev_priv);
}
--
1.9.1
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915/guc: Fix null pointer dereference when GuC FW is not available (rev3)
== Series Details == Series: drm/i915/guc: Fix null pointer dereference when GuC FW is not available (rev3) URL : https://patchwork.freedesktop.org/series/40490/ State : success == Summary == Known issues: Test kms_flip: Subgroup 2x-flip-vs-expired-vblank-interruptible: pass -> FAIL (shard-hsw) fdo#102887 +1 Subgroup dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 +1 Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b-frame-sequence: pass -> FAIL (shard-hsw) fdo#103481 fdo#102887 https://bugs.freedesktop.org/show_bug.cgi?id=102887 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#103481 https://bugs.freedesktop.org/show_bug.cgi?id=103481 shard-apltotal:3484 pass:1820 dwarn:1 dfail:0 fail:7 skip:1655 time:13092s shard-hswtotal:3484 pass:1771 dwarn:1 dfail:0 fail:4 skip:1707 time:11828s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7277s Blacklisted hosts: shard-kbltotal:3484 pass:1910 dwarn:37 dfail:0 fail:9 skip:1528 time:10081s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8458/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/2] drm/tinydrm: Make fb_dirty into a lower level hook
From: Ville Syrjälä
mipi_dbi_enable_flush() wants to call the fb->dirty() hook from the
bowels of the .atomic_enable() hook. That prevents us from taking the
plane mutex in fb->dirty() unless we also plumb down the acquire
context.
Instead it seems simpler to split the fb->dirty() into a tinydrm
specific lower level hook that can be called from
mipi_dbi_enable_flush() and from a generic higher level
tinydrm_fb_dirty() helper. As we don't have a tinydrm specific
vfuncs table we'll just stick it into tinydrm_device directly
for now.
Cc: "Noralf Trønnes"
Cc: David Lechner
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c | 30 ++
drivers/gpu/drm/tinydrm/ili9225.c | 23 ++--
drivers/gpu/drm/tinydrm/mi0283qt.c | 2 +-
drivers/gpu/drm/tinydrm/mipi-dbi.c | 30 ++
drivers/gpu/drm/tinydrm/repaper.c | 28
drivers/gpu/drm/tinydrm/st7586.c | 23 ++--
drivers/gpu/drm/tinydrm/st7735r.c | 2 +-
include/drm/tinydrm/mipi-dbi.h | 4 +++-
include/drm/tinydrm/tinydrm-helpers.h | 5 +
include/drm/tinydrm/tinydrm.h | 4
10 files changed, 76 insertions(+), 75 deletions(-)
diff --git a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
index d1c3ce9ab294..dcd390163a4a 100644
--- a/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
+++ b/drivers/gpu/drm/tinydrm/core/tinydrm-helpers.c
@@ -78,6 +78,36 @@ bool tinydrm_merge_clips(struct drm_clip_rect *dst,
}
EXPORT_SYMBOL(tinydrm_merge_clips);
+int tinydrm_fb_dirty(struct drm_framebuffer *fb,
+struct drm_file *file_priv,
+unsigned int flags, unsigned int color,
+struct drm_clip_rect *clips,
+unsigned int num_clips)
+{
+ struct tinydrm_device *tdev = fb->dev->dev_private;
+ struct drm_plane *plane = &tdev->pipe.plane;
+ int ret = 0;
+
+ drm_modeset_lock(&plane->mutex, NULL);
+
+ /* fbdev can flush even when we're not interested */
+ if (plane->state->fb == fb) {
+ mutex_lock(&tdev->dirty_lock);
+ ret = tdev->fb_dirty(fb, file_priv, flags,
+color, clips, num_clips);
+ mutex_unlock(&tdev->dirty_lock);
+ }
+
+ drm_modeset_unlock(&plane->mutex);
+
+ if (ret)
+ dev_err_once(fb->dev->dev,
+"Failed to update display %d\n", ret);
+
+ return ret;
+}
+EXPORT_SYMBOL(tinydrm_fb_dirty);
+
/**
* tinydrm_memcpy - Copy clip buffer
* @dst: Destination buffer
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index 089d22798c8b..0874e877b111 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -88,14 +88,8 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
bool full;
void *tr;
- mutex_lock(&tdev->dirty_lock);
-
if (!mipi->enabled)
- goto out_unlock;
-
- /* fbdev can flush even when we're not interested */
- if (tdev->pipe.plane.fb != fb)
- goto out_unlock;
+ return 0;
full = tinydrm_merge_clips(&clip, clips, num_clips, flags,
fb->width, fb->height);
@@ -108,7 +102,7 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
tr = mipi->tx_buf;
ret = mipi_dbi_buf_copy(mipi->tx_buf, fb, &clip, swap);
if (ret)
- goto out_unlock;
+ return ret;
} else {
tr = cma_obj->vaddr;
}
@@ -159,20 +153,13 @@ static int ili9225_fb_dirty(struct drm_framebuffer *fb,
ret = mipi_dbi_command_buf(mipi, ILI9225_WRITE_DATA_TO_GRAM, tr,
(clip.x2 - clip.x1) * (clip.y2 - clip.y1) * 2);
-out_unlock:
- mutex_unlock(&tdev->dirty_lock);
-
- if (ret)
- dev_err_once(fb->dev->dev, "Failed to update display %d\n",
-ret);
-
return ret;
}
static const struct drm_framebuffer_funcs ili9225_fb_funcs = {
.destroy= drm_gem_fb_destroy,
.create_handle = drm_gem_fb_create_handle,
- .dirty = ili9225_fb_dirty,
+ .dirty = tinydrm_fb_dirty,
};
static void ili9225_pipe_enable(struct drm_simple_display_pipe *pipe,
@@ -269,7 +256,7 @@ static void ili9225_pipe_enable(struct
drm_simple_display_pipe *pipe,
ili9225_command(mipi, ILI9225_DISPLAY_CONTROL_1, 0x1017);
- mipi_dbi_enable_flush(mipi);
+ mipi_dbi_enable_flush(mipi, crtc_state, plane_state);
}
static void ili9225_pipe_disable(struct drm_simple_display_pipe *pipe)
@@ -342,6 +329,8 @@ static int ili9225_init
[Intel-gfx] [PATCH 1/2] drm/simple-kms-helper: Plumb plane state to the enable hook
From: Ville Syrjälä
We'll need access to the plane state during .atomic_enable().
Performed with coccinelle:
@r1@
identifier F =~ ".*enable$";
identifier P, CS;
@@
F(
struct drm_simple_display_pipe *P
,struct drm_crtc_state *CS
+ ,struct drm_plane_state *plane_state
)
{
...
}
@@
struct drm_simple_display_pipe *P;
expression E;
@@
{
+ struct drm_plane *plane;
...
+ plane = &P->plane;
P->funcs->enable(P
,E
+ ,plane->state
);
...
}
@@
identifier P, CS;
@@
struct drm_simple_display_pipe_funcs {
...
void (*enable)(struct drm_simple_display_pipe *P
,struct drm_crtc_state *CS
+ ,struct drm_plane_state *plane_state
);
...
};
Cc: Marek Vasut
Cc: Eric Anholt
Cc: David Lechner
Cc: "Noralf Trønnes"
Cc: Linus Walleij
Signed-off-by: Ville Syrjälä
---
drivers/gpu/drm/drm_simple_kms_helper.c | 4 +++-
drivers/gpu/drm/mxsfb/mxsfb_drv.c | 3 ++-
drivers/gpu/drm/pl111/pl111_display.c | 3 ++-
drivers/gpu/drm/tinydrm/ili9225.c | 3 ++-
drivers/gpu/drm/tinydrm/mi0283qt.c | 3 ++-
drivers/gpu/drm/tinydrm/repaper.c | 3 ++-
drivers/gpu/drm/tinydrm/st7586.c| 3 ++-
drivers/gpu/drm/tinydrm/st7735r.c | 3 ++-
drivers/gpu/drm/tve200/tve200_display.c | 3 ++-
include/drm/drm_simple_kms_helper.h | 3 ++-
10 files changed, 21 insertions(+), 10 deletions(-)
diff --git a/drivers/gpu/drm/drm_simple_kms_helper.c
b/drivers/gpu/drm/drm_simple_kms_helper.c
index 987a353c7f72..7a00455ca568 100644
--- a/drivers/gpu/drm/drm_simple_kms_helper.c
+++ b/drivers/gpu/drm/drm_simple_kms_helper.c
@@ -64,13 +64,15 @@ static int drm_simple_kms_crtc_check(struct drm_crtc *crtc,
static void drm_simple_kms_crtc_enable(struct drm_crtc *crtc,
struct drm_crtc_state *old_state)
{
+ struct drm_plane *plane;
struct drm_simple_display_pipe *pipe;
pipe = container_of(crtc, struct drm_simple_display_pipe, crtc);
if (!pipe->funcs || !pipe->funcs->enable)
return;
- pipe->funcs->enable(pipe, crtc->state);
+ plane = &pipe->plane;
+ pipe->funcs->enable(pipe, crtc->state, plane->state);
}
static void drm_simple_kms_crtc_disable(struct drm_crtc *crtc,
diff --git a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
index 5cae8db9dcd4..b9c7507813db 100644
--- a/drivers/gpu/drm/mxsfb/mxsfb_drv.c
+++ b/drivers/gpu/drm/mxsfb/mxsfb_drv.c
@@ -99,7 +99,8 @@ static const struct drm_mode_config_funcs
mxsfb_mode_config_funcs = {
};
static void mxsfb_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state)
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
{
struct mxsfb_drm_private *mxsfb = drm_pipe_to_mxsfb_drm_private(pipe);
diff --git a/drivers/gpu/drm/pl111/pl111_display.c
b/drivers/gpu/drm/pl111/pl111_display.c
index 310646427907..1fee578e05b0 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -120,7 +120,8 @@ static int pl111_display_check(struct
drm_simple_display_pipe *pipe,
}
static void pl111_display_enable(struct drm_simple_display_pipe *pipe,
-struct drm_crtc_state *cstate)
+struct drm_crtc_state *cstate,
+struct drm_plane_state *plane_state)
{
struct drm_crtc *crtc = &pipe->crtc;
struct drm_plane *plane = &pipe->plane;
diff --git a/drivers/gpu/drm/tinydrm/ili9225.c
b/drivers/gpu/drm/tinydrm/ili9225.c
index a0759502b81a..089d22798c8b 100644
--- a/drivers/gpu/drm/tinydrm/ili9225.c
+++ b/drivers/gpu/drm/tinydrm/ili9225.c
@@ -176,7 +176,8 @@ static const struct drm_framebuffer_funcs ili9225_fb_funcs
= {
};
static void ili9225_pipe_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state)
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
{
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev);
diff --git a/drivers/gpu/drm/tinydrm/mi0283qt.c
b/drivers/gpu/drm/tinydrm/mi0283qt.c
index d8ed6e6f8e05..82ad9b61898e 100644
--- a/drivers/gpu/drm/tinydrm/mi0283qt.c
+++ b/drivers/gpu/drm/tinydrm/mi0283qt.c
@@ -49,7 +49,8 @@
#define ILI9341_MADCTL_MY BIT(7)
static void mi0283qt_enable(struct drm_simple_display_pipe *pipe,
- struct drm_crtc_state *crtc_state)
+ struct drm_crtc_state *crtc_state,
+ struct drm_plane_state *plane_state)
{
struct tinydrm_device *tdev = pipe_to_tinydrm(pipe);
struct mipi_dbi *mipi = mipi_dbi_from_tinydrm(tdev)
Re: [Intel-gfx] [RFC 0/8] Force preemption
> From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf > Of Jeff McGee > Sent: Thursday, March 22, 2018 12:09 PM > To: Tvrtko Ursulin > Cc: Kondapally, Kalyan ; intel- > g...@lists.freedesktop.org; b...@bwidawsk.net > Subject: Re: [Intel-gfx] [RFC 0/8] Force preemption > > On Thu, Mar 22, 2018 at 05:41:57PM +, Tvrtko Ursulin wrote: > > > > On 22/03/2018 16:01, Jeff McGee wrote: > > >On Thu, Mar 22, 2018 at 03:57:49PM +, Tvrtko Ursulin wrote: > > >> > > >>On 22/03/2018 14:34, Jeff McGee wrote: > > >>>On Thu, Mar 22, 2018 at 09:28:00AM +, Chris Wilson wrote: > > Quoting Tvrtko Ursulin (2018-03-22 09:22:55) > > > > > >On 21/03/2018 17:26, jeff.mc...@intel.com wrote: > > >>From: Jeff McGee > > >> > > >>Force preemption uses engine reset to enforce a limit on the time > > >>that a request targeted for preemption can block. This feature is > > >>a requirement in automotive systems where the GPU may be > shared by > > >>clients of critically high priority and clients of low priority that > > >>may not have been curated to be preemption friendly. There may > be > > >>more general applications of this feature. I'm sharing as an RFC to > > >>stimulate that discussion and also to get any technical feedback > > >>that I can before submitting to the product kernel that needs this. > > >>I have developed the patches for ease of rebase, given that this is > > >>for the moment considered a non-upstreamable feature. It would > be > > >>possible to refactor hangcheck to fully incorporate force > preemption > > >>as another tier of patience (or impatience) with the running > request. > > > > > >Sorry if it was mentioned elsewhere and I missed it - but does this > work > > >only with stateless clients - or in other words, what would happen to > > >stateful clients which would be force preempted? Or the answer is > we > > >don't care since they are misbehaving? > > > > They get notified of being guilty for causing a gpu reset; three strikes > > and they are out (banned from using the gpu) using the current rules. > > This is a very blunt hammer that requires the rest of the system to be > > robust; one might argue time spent making the system robust would > be > > better served making sure that the timer never expired in the first > place > > thereby eliminating the need for a forced gpu reset. > > -Chris > > >>> > > >>>Yes, for simplication the policy applied to force preempted contexts > > >>>is the same as for hanging contexts. It is known that this feature > > >>>should not be required in a fully curated system. It's a requirement > > >>>if end user will be alllowed to install 3rd party apps to run in the > > >>>non-critical domain. > > >> > > >>My concern is whether it safe to call this force _preemption_, while > > >>it is not really expected to work as preemption from the point of > > >>view of preempted context. I may be missing some angle here, but I > > >>think a better name would include words like maximum request > > >>duration or something. > > >> > > >>I can see a difference between allowed maximum duration when there > > >>is something else pending, and when it isn't, but I don't > > >>immediately see that we should consider this distinction for any > > >>real benefit? > > >> > > >>So should the feature just be "maximum request duration"? This would > > >>perhaps make it just a special case of hangcheck, which ignores head > > >>progress, or whatever we do in there. > > >> > > >>Regards, > > >> > > >>Tvrtko > > > > > >I think you might be unclear about how this works. We're not starting a > > >preemption to see if we can cleanly remove a request who has begun to > > >exceed its normal time slice, i.e. hangcheck. This is about bounding > > >the time that a normal preemption can take. So first start preemption > > >in response to higher-priority request arrival, then wait for preemption > > >to complete within a certain amount of time. If it does not, resort to > > >reset. > > > > > >So it's really "force the resolution of a preemption", shortened to > > >"force preemption". > > > > You are right, I veered off in my thinking and ended up with > > something different. :) > > > > I however still think the name is potentially misleading, since the > > request/context is not getting preempted. It is getting effectively > > killed (sooner or later, directly or indirectly). > > > > Maybe that is OK for the specific use case when everything is only > > broken and not malicious. > > > > In a more general purpose system it would be a bit random when > > something would work, and when it wouldn't, depending on system > > setup and even timings. > > > > Hm, maybe you don't even really benefit from the standard three > > strikes and you are out policy, and for this specific use case, you > > should just kill it straight away. If it couldn't be preempted once, > > why pay
[Intel-gfx] ✗ Fi.CI.IGT: failure for drm: Eliminate plane->fb/crtc usage for atomic drivers (rev4)
== Series Details == Series: drm: Eliminate plane->fb/crtc usage for atomic drivers (rev4) URL : https://patchwork.freedesktop.org/series/40478/ State : failure == Summary == Possible new issues: Test kms_cursor_legacy: Subgroup flip-vs-cursor-legacy: pass -> FAIL (shard-hsw) Known issues: Test kms_flip: Subgroup dpms-vs-vblank-race: fail -> PASS (shard-hsw) fdo#103060 +1 Subgroup plain-flip-fb-recreate: pass -> FAIL (shard-hsw) fdo#100368 +1 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 shard-apltotal:3484 pass:1820 dwarn:1 dfail:0 fail:7 skip:1655 time:13121s shard-hswtotal:3484 pass:1771 dwarn:1 dfail:0 fail:4 skip:1707 time:11775s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7300s Blacklisted hosts: shard-kbltotal:3484 pass:1944 dwarn:1 dfail:0 fail:10 skip:1529 time:9956s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8456/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915/selftests: Include the trace as a debug aide
On Thu, Mar 22, 2018 at 02:30:09PM +, Chris Wilson wrote:
> Quoting Mika Kuoppala (2018-03-22 14:26:41)
> > Chris Wilson writes:
> >
> > > If we fail to reset the GPU in a timely fashion, dump the GEM trace so
> > > that we can see what operations were in flight when the GPU got stuck.
> > >
> > > v2: There's more than one timeout that deserves tracing!
> > > v3: Silence checkpatch by not even using a product at all!
> > >
> > > Signed-off-by: Chris Wilson
> > > ---
> > > drivers/gpu/drm/i915/selftests/intel_hangcheck.c | 23
> > > ---
> > > 1 file changed, 20 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > index 4372826998aa..9b235dae8dd9 100644
> > > --- a/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > +++ b/drivers/gpu/drm/i915/selftests/intel_hangcheck.c
> > > @@ -260,8 +260,11 @@ static void wedge_me(struct work_struct *work)
> > > {
> > > struct wedge_me *w = container_of(work, typeof(*w), work.work);
> > >
> > > - pr_err("%pS timed out, cancelling all further testing.\n",
> > > -w->symbol);
> > > + pr_err("%pS timed out, cancelling all further testing.\n",
> > > w->symbol);
> > > +
> > > + GEM_TRACE("%pS timed out.\n", w->symbol);
> > > + GEM_TRACE_DUMP();
> > > +
> > > i915_gem_set_wedged(w->i915);
> > > }
> > >
> > > @@ -621,9 +624,19 @@ static int active_engine(void *data)
> > > mutex_unlock(&engine->i915->drm.struct_mutex);
> > >
> > > if (old) {
> > > - i915_request_wait(old, 0, MAX_SCHEDULE_TIMEOUT);
> > > + if (i915_request_wait(old, 0, HZ) < 0) {
> > > + GEM_TRACE("%s timed out.\n", engine->name);
> > > + GEM_TRACE_DUMP();
> > > +
> > > + i915_gem_set_wedged(engine->i915);
> > > + i915_request_put(old);
> > > + err = -EIO;
> > > + break;
> > > + }
> >
> > Using err = i915_request_wait() could have saved one extra request_put
> > but I dunno if it would be any cleaner.
>
> It's also -ETIME, which didn't fit my intention.
>
> >
> > > i915_request_put(old);
> > > }
> > > +
> > > + cond_resched();
> >
> > To give more slack for other engines and main thread to proceed?
>
> Yes. Otherwise, it spins mighty fine.
> >
> > > }
> > >
> > > for (count = 0; count < ARRAY_SIZE(rq); count++)
> > > @@ -1126,6 +1139,10 @@ int intel_hangcheck_live_selftests(struct
> > > drm_i915_private *i915)
> > >
> > > err = i915_subtests(tests, i915);
> > >
> > > + mutex_lock(&i915->drm.struct_mutex);
> > > + flush_test(i915, I915_WAIT_LOCKED);
> > > + mutex_unlock(&i915->drm.struct_mutex);
> > > +
> >
> > To wash out leftovers.
>
> Yeah, from the early abort we left requests unaccounted for and needed
> to grab the struct_mutex to run retire. Otherwise we hit assertions
> later on about trying to unload the driver with requests still inflight.
> -Chris
On this and the 3 others in this series...
Reviewed-by: Jeff McGee
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [RFC 0/8] Force preemption
On Thu, Mar 22, 2018 at 05:41:57PM +, Tvrtko Ursulin wrote: > > On 22/03/2018 16:01, Jeff McGee wrote: > >On Thu, Mar 22, 2018 at 03:57:49PM +, Tvrtko Ursulin wrote: > >> > >>On 22/03/2018 14:34, Jeff McGee wrote: > >>>On Thu, Mar 22, 2018 at 09:28:00AM +, Chris Wilson wrote: > Quoting Tvrtko Ursulin (2018-03-22 09:22:55) > > > >On 21/03/2018 17:26, jeff.mc...@intel.com wrote: > >>From: Jeff McGee > >> > >>Force preemption uses engine reset to enforce a limit on the time > >>that a request targeted for preemption can block. This feature is > >>a requirement in automotive systems where the GPU may be shared by > >>clients of critically high priority and clients of low priority that > >>may not have been curated to be preemption friendly. There may be > >>more general applications of this feature. I'm sharing as an RFC to > >>stimulate that discussion and also to get any technical feedback > >>that I can before submitting to the product kernel that needs this. > >>I have developed the patches for ease of rebase, given that this is > >>for the moment considered a non-upstreamable feature. It would be > >>possible to refactor hangcheck to fully incorporate force preemption > >>as another tier of patience (or impatience) with the running request. > > > >Sorry if it was mentioned elsewhere and I missed it - but does this work > >only with stateless clients - or in other words, what would happen to > >stateful clients which would be force preempted? Or the answer is we > >don't care since they are misbehaving? > > They get notified of being guilty for causing a gpu reset; three strikes > and they are out (banned from using the gpu) using the current rules. > This is a very blunt hammer that requires the rest of the system to be > robust; one might argue time spent making the system robust would be > better served making sure that the timer never expired in the first place > thereby eliminating the need for a forced gpu reset. > -Chris > >>> > >>>Yes, for simplication the policy applied to force preempted contexts > >>>is the same as for hanging contexts. It is known that this feature > >>>should not be required in a fully curated system. It's a requirement > >>>if end user will be alllowed to install 3rd party apps to run in the > >>>non-critical domain. > >> > >>My concern is whether it safe to call this force _preemption_, while > >>it is not really expected to work as preemption from the point of > >>view of preempted context. I may be missing some angle here, but I > >>think a better name would include words like maximum request > >>duration or something. > >> > >>I can see a difference between allowed maximum duration when there > >>is something else pending, and when it isn't, but I don't > >>immediately see that we should consider this distinction for any > >>real benefit? > >> > >>So should the feature just be "maximum request duration"? This would > >>perhaps make it just a special case of hangcheck, which ignores head > >>progress, or whatever we do in there. > >> > >>Regards, > >> > >>Tvrtko > > > >I think you might be unclear about how this works. We're not starting a > >preemption to see if we can cleanly remove a request who has begun to > >exceed its normal time slice, i.e. hangcheck. This is about bounding > >the time that a normal preemption can take. So first start preemption > >in response to higher-priority request arrival, then wait for preemption > >to complete within a certain amount of time. If it does not, resort to > >reset. > > > >So it's really "force the resolution of a preemption", shortened to > >"force preemption". > > You are right, I veered off in my thinking and ended up with > something different. :) > > I however still think the name is potentially misleading, since the > request/context is not getting preempted. It is getting effectively > killed (sooner or later, directly or indirectly). > > Maybe that is OK for the specific use case when everything is only > broken and not malicious. > > In a more general purpose system it would be a bit random when > something would work, and when it wouldn't, depending on system > setup and even timings. > > Hm, maybe you don't even really benefit from the standard three > strikes and you are out policy, and for this specific use case, you > should just kill it straight away. If it couldn't be preempted once, > why pay the penalty any more? > > If you don't have it already, devising a solution which blacklists > the process (if it creates more contexts), or even a parent (if > forking is applicable and implementation feasible), for offenders > could also be beneficial. > > Regards, > > Tvrtko Fair enough. There wasn't a lot of deliberation on this name. We referred to it in various ways during development. I think I started using "force preemption" because it was short. "reset to preempt" was anot
[Intel-gfx] [PULL] drm-misc-fixes
Hi Dave, A few fixes for 4.16. Main thing here is getting getfb to reject multiplanar fbs. I should have sent some of these before but conference and traveling got in the way. Thanks, Gustavo drm-misc-fixes-2018-03-22: Main change is a patch to reject getfb call for multiplanar framebuffers, then we have a couple of error path fixes on the sun4i driver. Still on that driver there is a clk fix and finally a mmap offset fix on the udl driver. The following changes since commit b0655d668fc4faf0c1985e828820f9b9ca13abe6: Merge branch 'drm-fixes-4.16' of git://people.freedesktop.org/~agd5f/linux into drm-fixes (2018-03-09 09:23:02 +1000) are available in the Git repository at: git://anongit.freedesktop.org/drm/drm-misc tags/drm-misc-fixes-2018-03-22 for you to fetch changes up to 3b82a4db8eaccce735dffd50b4d4e1578099b8e8: drm: udl: Properly check framebuffer mmap offsets (2018-03-22 07:59:01 +0100) Main change is a patch to reject getfb call for multiplanar framebuffers, then we have a couple of error path fixes on the sun4i driver. Still on that driver there is a clk fix and finally a mmap offset fix on the udl driver. Christophe JAILLET (3): drm/sun4i: Fix an error handling path in 'sun4i_drv_bind()' drm/sun4i: hdmi: Fix an error handling path in 'sun4i_hdmi_bind()' drm/sun4i: hdmi: Fix another error handling path in 'sun4i_hdmi_bind()' Daniel Stone (1): drm: Reject getfb for multi-plane framebuffers Greg Kroah-Hartman (1): drm: udl: Properly check framebuffer mmap offsets Ondrej Jirman (1): drm/sun4i: Fix exclusivity of the TCON clocks drivers/gpu/drm/drm_framebuffer.c | 7 +++ drivers/gpu/drm/sun4i/sun4i_drv.c | 3 +-- drivers/gpu/drm/sun4i/sun4i_hdmi_enc.c | 6 -- drivers/gpu/drm/sun4i/sun4i_tcon.c | 5 +++-- drivers/gpu/drm/udl/udl_fb.c | 9 +++-- 5 files changed, 22 insertions(+), 8 deletions(-) ___ 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/guc: Fix null pointer dereference when GuC FW is not available (rev3)
== Series Details == Series: drm/i915/guc: Fix null pointer dereference when GuC FW is not available (rev3) URL : https://patchwork.freedesktop.org/series/40490/ State : success == Summary == Series 40490v3 drm/i915/guc: Fix null pointer dereference when GuC FW is not available https://patchwork.freedesktop.org/api/1.0/series/40490/revisions/3/mbox/ Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_mmap_gtt: Subgroup basic-small-bo-tiledx: fail -> PASS (fi-gdg-551) fdo#102575 Test kms_chamelium: Subgroup dp-crc-fast: pass -> DMESG-FAIL (fi-kbl-7500u) fdo#103841 Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-b-frame-sequence: incomplete -> PASS (fi-cnl-y3) fdo#103191 Subgroup suspend-read-crc-pipe-c: pass -> INCOMPLETE (fi-bxt-dsi) fdo#103927 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#102575 https://bugs.freedesktop.org/show_bug.cgi?id=102575 fdo#103841 https://bugs.freedesktop.org/show_bug.cgi?id=103841 fdo#103191 https://bugs.freedesktop.org/show_bug.cgi?id=103191 fdo#103927 https://bugs.freedesktop.org/show_bug.cgi?id=103927 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:430s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:440s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:378s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:530s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:297s fi-bxt-dsi total:243 pass:216 dwarn:0 dfail:0 fail:0 skip:26 fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:513s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:514s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:505s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:417s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:510s fi-cnl-drrs total:285 pass:254 dwarn:3 dfail:0 fail:0 skip:28 time:529s fi-cnl-y3total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:586s fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:424s fi-gdg-551 total:285 pass:177 dwarn:0 dfail:0 fail:0 skip:108 time:318s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:536s fi-hsw-4770 total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:400s fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:418s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:474s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:433s fi-kbl-7500u total:285 pass:259 dwarn:1 dfail:1 fail:0 skip:24 time:479s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:469s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:514s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:656s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:439s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:504s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:490s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:426s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:446s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:571s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s fi-cfl-s3 failed to connect after reboot 40fcdd23bec787a5913496f2b11c5d26bdff985a drm-tip: 2018y-03m-22d-15h-28m-32s UTC integration manifest d735ca60e03f drm/i915/guc: Fix null pointer dereference when GuC FW is not available == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8458/issues.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers
On Thu, Mar 22, 2018 at 05:51:35PM +0100, Noralf Trønnes wrote: > tinydrm is also using plane->fb: > > $ grep -r "plane\.fb" drivers/gpu/drm/tinydrm/ > drivers/gpu/drm/tinydrm/repaper.c: if (tdev->pipe.plane.fb != fb) > drivers/gpu/drm/tinydrm/mipi-dbi.c: if (tdev->pipe.plane.fb != fb) > drivers/gpu/drm/tinydrm/mipi-dbi.c: struct drm_framebuffer *fb = > mipi->tinydrm.pipe.plane.fb; Oh dear, and naturally it's the most annoying one of the bunch. So we want to take the plane lock in the fb.dirty() hook to look at the fb, but mipi-dbi.c calls that directly from the bowels of its .atomic_enable() hook. So that would deadlock pretty neatly if the commit happens while already holding the lock. So we'd either need to plumb an acquire context into fb.dirty(), or maybe have tinydrm provide a lower level lockless dirty() hook that gets called by both (there are just too many layers in this particular cake to immediately see where such a hook would be best placed). Or maybe there's some other solution I didn't think of. Looking at this I'm also left wondering how this is supposed handle fb.dirty() getting called concurrently with a modeset. The dirty_mutex only seems to offer any protection for fb.dirty() against another fb.dirty()... -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock ratio fails (rev4)
== Series Details == Series: drm/i915: Don't spew errors when resetting HDMI scrambling/bit clock ratio fails (rev4) URL : https://patchwork.freedesktop.org/series/40461/ State : warning == Summary == Possible new issues: Test kms_flip: Subgroup 2x-flip-vs-dpms: pass -> DMESG-WARN (shard-hsw) Known issues: Test kms_flip: Subgroup 2x-plain-flip-ts-check-interruptible: pass -> FAIL (shard-hsw) fdo#100368 +1 Subgroup modeset-vs-vblank-race-interruptible: pass -> FAIL (shard-hsw) fdo#103060 +2 Test kms_sysfs_edid_timing: warn -> PASS (shard-apl) fdo#100047 fdo#100368 https://bugs.freedesktop.org/show_bug.cgi?id=100368 fdo#103060 https://bugs.freedesktop.org/show_bug.cgi?id=103060 fdo#100047 https://bugs.freedesktop.org/show_bug.cgi?id=100047 shard-apltotal:3484 pass:1821 dwarn:1 dfail:0 fail:7 skip:1655 time:13153s shard-hswtotal:3484 pass:1770 dwarn:2 dfail:0 fail:4 skip:1707 time:11827s shard-snbtotal:3484 pass:1363 dwarn:1 dfail:0 fail:3 skip:2117 time:7284s Blacklisted hosts: shard-kbltotal:3484 pass:1945 dwarn:1 dfail:0 fail:10 skip:1528 time:9960s == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8453/shards.html ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/gvt/scheduler: Remove unnecessary NULL checks in sr_oa_regs
The checks are misleading and not required [1].
[1] https://lkml.org/lkml/2018/3/19/1792
Addresses-Coverity-ID: 1466017
Cc: Chris Wilson
Signed-off-by: Gustavo A. R. Silva
---
drivers/gpu/drm/i915/gvt/scheduler.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/gvt/scheduler.c
b/drivers/gpu/drm/i915/gvt/scheduler.c
index 78588ef..b6da223 100644
--- a/drivers/gpu/drm/i915/gvt/scheduler.c
+++ b/drivers/gpu/drm/i915/gvt/scheduler.c
@@ -74,7 +74,7 @@ static void sr_oa_regs(struct intel_vgpu_workload *workload,
i915_mmio_reg_offset(EU_PERF_CNTL6),
};
- if (!workload || !reg_state || workload->ring_id != RCS)
+ if (workload->ring_id != RCS)
return;
if (save) {
--
2.7.4
___
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/guc: Fix null pointer dereference when GuC FW is not available (rev3)
== Series Details == Series: drm/i915/guc: Fix null pointer dereference when GuC FW is not available (rev3) URL : https://patchwork.freedesktop.org/series/40490/ State : warning == Summary == $ dim checkpatch origin/drm-tip d735ca60e03f drm/i915/guc: Fix null pointer dereference when GuC FW is not available -:101: ERROR:TRAILING_WHITESPACE: trailing whitespace #101: FILE: drivers/gpu/drm/i915/intel_uc_fw.c:225: +^Iggtt_pin_bias = to_i915(uc_fw->obj->base.dev)->guc.ggtt_pin_bias; $ total: 1 errors, 0 warnings, 0 checks, 21 lines checked ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 00/23] drm: Eliminate plane->fb/crtc usage for atomic drivers
On 22 March 2018 at 18:03, Harry Wentland wrote:
> On 2018-03-22 01:54 PM, Emil Velikov wrote:
>> Hi Ville,
>>
>> On 22 March 2018 at 15:22, Ville Syrjala
>> wrote:
>>> From: Ville Syrjälä
>>>
>>> I really just wanted to fix i915 to re-enable its planes afer load
>>> detection (a two line patch). This is what I actually ended up with
>>> after I ran into a framebuffer refcount leak with said two line patch.
>>>
>>> I've tested this on a few i915 boxes and so far it's looking
>>> good. Everything else is just compile tested.
>>>
>> Mostly thinking out loud:
>>
>> Wondering if one cannot somehow (re)move plane->fb/crtc altogether.
>> Otherwise drivers will reintroduce similar code, despite the WARNs and
>> beefy documentation :-\
>
> Wouldn't that require an atomic conversion of all remaining drivers?
>
That or maybe move into plane->legacy->{fb,crtc}. Feel free to swap
'legacy' with flashier name.
Hmm back in 2015 we had a GSoC that updated BOCHS and CIRRUS drivers,
but they never got merged.
Don't recall the details - from memory the conversion seemed fine, but
there was either shortage on review/other.
Might be worth reviving that... regardless it's getting a bit off-topic.
-Emil
[1]
https://www.google-melange.com/archive/gsoc/2015/orgs/xorg/projects/johnhunter.html
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads
== Series Details == Series: series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads URL : https://patchwork.freedesktop.org/series/40503/ State : warning == Summary == Series 40503v1 series starting with [1/2] drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads https://patchwork.freedesktop.org/api/1.0/series/40503/revisions/1/mbox/ Possible new issues: Test gem_busy: Subgroup basic-hang-default: pass -> DMESG-WARN (fi-cnl-drrs) Test gem_exec_fence: Subgroup await-hang-default: pass -> DMESG-WARN (fi-cnl-drrs) Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-cnl-drrs) Test gem_ringfill: Subgroup basic-default-hang: pass -> DMESG-WARN (fi-cnl-drrs) Known issues: Test debugfs_test: Subgroup read_all_entries: incomplete -> PASS (fi-snb-2520m) fdo#103713 Test gem_exec_suspend: Subgroup basic-s3: pass -> DMESG-WARN (fi-cnl-drrs) fdo#105086 Test kms_frontbuffer_tracking: Subgroup basic: pass -> INCOMPLETE (fi-cnl-y3) fdo#103167 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: pass -> DMESG-WARN (fi-cnl-drrs) k.org#198519 +2 pass -> INCOMPLETE (fi-hsw-4770) fdo#104944 fdo#103713 https://bugs.freedesktop.org/show_bug.cgi?id=103713 fdo#105086 https://bugs.freedesktop.org/show_bug.cgi?id=105086 fdo#103167 https://bugs.freedesktop.org/show_bug.cgi?id=103167 k.org#198519 https://bugzilla.kernel.org/show_bug.cgi?id=198519 fdo#104944 https://bugs.freedesktop.org/show_bug.cgi?id=104944 fi-bdw-5557u total:285 pass:264 dwarn:0 dfail:0 fail:0 skip:21 time:433s fi-bdw-gvtdvmtotal:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:441s fi-blb-e6850 total:285 pass:220 dwarn:1 dfail:0 fail:0 skip:64 time:379s fi-bsw-n3050 total:285 pass:239 dwarn:0 dfail:0 fail:0 skip:46 time:533s fi-bwr-2160 total:285 pass:180 dwarn:0 dfail:0 fail:0 skip:105 time:296s fi-bxt-dsi total:285 pass:255 dwarn:0 dfail:0 fail:0 skip:30 time:514s fi-bxt-j4205 total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:515s fi-byt-j1900 total:285 pass:250 dwarn:0 dfail:0 fail:0 skip:35 time:514s fi-byt-n2820 total:285 pass:246 dwarn:0 dfail:0 fail:0 skip:39 time:505s fi-cfl-8700k total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:410s fi-cfl-u total:285 pass:259 dwarn:0 dfail:0 fail:0 skip:26 time:514s fi-cnl-drrs total:285 pass:246 dwarn:11 dfail:0 fail:0 skip:28 time:529s fi-cnl-y3total:224 pass:199 dwarn:0 dfail:0 fail:0 skip:24 fi-elk-e7500 total:285 pass:225 dwarn:1 dfail:0 fail:0 skip:59 time:426s fi-gdg-551 total:285 pass:176 dwarn:0 dfail:0 fail:1 skip:108 time:317s fi-glk-1 total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:538s fi-hsw-4770 total:241 pass:217 dwarn:0 dfail:0 fail:0 skip:23 fi-ilk-650 total:285 pass:225 dwarn:0 dfail:0 fail:0 skip:60 time:418s fi-ivb-3520m total:285 pass:256 dwarn:0 dfail:0 fail:0 skip:29 time:473s fi-ivb-3770 total:285 pass:252 dwarn:0 dfail:0 fail:0 skip:33 time:436s fi-kbl-7500u total:285 pass:260 dwarn:1 dfail:0 fail:0 skip:24 time:473s fi-kbl-7567u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:464s fi-kbl-r total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:511s fi-pnv-d510 total:285 pass:219 dwarn:1 dfail:0 fail:0 skip:65 time:652s fi-skl-6260u total:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:438s fi-skl-6600u total:285 pass:258 dwarn:0 dfail:0 fail:0 skip:27 time:533s fi-skl-6700k2total:285 pass:261 dwarn:0 dfail:0 fail:0 skip:24 time:503s fi-skl-6770hqtotal:285 pass:265 dwarn:0 dfail:0 fail:0 skip:20 time:496s fi-skl-guc total:285 pass:257 dwarn:0 dfail:0 fail:0 skip:28 time:430s fi-skl-gvtdvmtotal:285 pass:262 dwarn:0 dfail:0 fail:0 skip:23 time:441s fi-snb-2520m total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:587s fi-snb-2600 total:285 pass:245 dwarn:0 dfail:0 fail:0 skip:40 time:399s fi-cfl-s3 failed to connect after reboot 40fcdd23bec787a5913496f2b11c5d26bdff985a drm-tip: 2018y-03m-22d-15h-28m-32s UTC integration manifest 9632e3a2f229 drm/i915: Implement WaProgramMgsrForL3BankSpecificMmioReads 5538dcdd0612 drm/i915/cnl: Implement WaProgramMgsrForCorrectSliceSpecificMmioReads == Logs == For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_8457/issues.html ___ Intel-gfx m
Re: [Intel-gfx] [PATCH v3] drm/i915/guc: Fix null pointer dereference when GuC FW is not available
On Thu, 22 Mar 2018 19:17:28 +0100, Piotr Piórkowski
wrote:
If GuC firmware is not available on the system and we load i915 with
enable
GuC, then we hit this null pointer dereference issue:
[ 71.098873] BUG: unable to handle kernel NULL pointer dereference at
0008
[ 71.098938] IP: intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.098947] PGD 0 P4D 0
[ 71.098956] Oops: [#1] PREEMPT SMP PTI
[ 71.098965] Modules linked in: i915(O+) netconsole
x86_pkg_temp_thermal intel_powerclamp coretemp crct10dif_pclmul
crc32_pclmul ghash_clmulni_intel mei_me i2c_i801 prime_numbers mei [last
unloaded: i915]
[ 71.099005] CPU: 2 PID: 1167 Comm: insmod Tainted: G U W O
4.16.0-rc1+ #337
[ 71.099018] Hardware name: /NUC6i5SYB, BIOS
SYSKLi35.86A.0065.2018.0103.1000 01/03/2018
[ 71.099077] RIP: 0010:intel_uc_fw_upload+0x1f/0x360 [i915]
[ 71.099087] RSP: 0018:c9417aa0 EFLAGS: 00010282
[ 71.099097] RAX: RBX: 88084cad12f8 RCX:
a03e9357
[ 71.099108] RDX: 0002 RSI: a034dba0 RDI:
88084cad12f8
[ 71.099118] RBP: 0002 R08: 88085344ca90 R09:
0001
[ 71.099128] R10: R11: R12:
88084cad
[ 71.099139] R13: a034dba0 R14: fff5 R15:
88084cad12b0
[ 71.099151] FS: 7f7f24ae2740() GS:88085e20()
knlGS:
[ 71.099162] CS: 0010 DS: ES: CR0: 80050033
[ 71.099171] CR2: 0008 CR3: 000855f48001 CR4:
003606e0
[ 71.099182] Call Trace:
[ 71.099246] intel_uc_init_hw+0xc8/0x520 [i915]
[ 71.099303] i915_gem_init_hw+0x11f/0x2d0 [i915]
[ 71.099364] i915_gem_init+0x2b9/0x640 [i915]
[ 71.099413] i915_driver_load+0xb74/0x1110 [i915]
[ 71.099462] i915_pci_probe+0x2e/0x90 [i915]
[ 71.099476] pci_device_probe+0xa1/0x130
[ 71.099488] driver_probe_device+0x302/0x470
[ 71.099502] __driver_attach+0xb9/0xe0
[ 71.099513] ? driver_probe_device+0x470/0x470
[ 71.099525] ? driver_probe_device+0x470/0x470
[ 71.099538] bus_for_each_dev+0x64/0x90
[ 71.099550] bus_add_driver+0x164/0x260
[ 71.099561] ? 0xa04d6000
[ 71.099572] driver_register+0x57/0xc0
[ 71.099582] ? 0xa04d6000
[ 71.099593] do_one_initcall+0x3b/0x160
[ 71.099606] ? kmem_cache_alloc_trace+0x1c3/0x2a0
[ 71.099621] do_init_module+0x5b/0x1f9
[ 71.099635] load_module+0x2467/0x2a70
[ 71.099654] ? SyS_finit_module+0xbd/0xe0
[ 71.099668] SyS_finit_module+0xbd/0xe0
[ 71.099682] do_syscall_64+0x73/0x1c0
[ 71.099694] entry_SYSCALL_64_after_hwframe+0x26/0x9b
[ 71.099706] RIP: 0033:0x7f7f23fb40d9
[ 71.099717] RSP: 002b:7ffda7d67ed8 EFLAGS: 0246 ORIG_RAX:
0139
[ 71.099734] RAX: ffda RBX: 55f96e2a8870 RCX:
7f7f23fb40d9
[ 71.099748] RDX: RSI: 55f96e2a8260 RDI:
0003
[ 71.099763] RBP: 55f96e2a8260 R08: R09:
7ffda7d68088
[ 71.099777] R10: 0003 R11: 0246 R12:
[ 71.099791] R13: 55f96e2a8830 R14: R15:
55f96e2a8260
[ 71.099810] Code: 00 00 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
41 55 41 54 49 89 f5 55 53 48 c7 c1 57 93 3e a0 48 8b 47 10 48 89 fb 4c
8b 07 <48> 8b 68 08 8b 47 28 85 c0 74 15 83 f8 01 48 c7 c1 5b 93 3e a0
[ 71.14] RIP: intel_uc_fw_upload+0x1f/0x360 [i915] RSP:
c9417aa0
[ 71.100020] CR2: 0008
[ 71.100031] ---[ end trace d8ac93c30ceff5b2 ]--
Fixes: 6b0478fb722a ("drm/i915: Implement dynamic GuC WOPCM offset and
size calculation")
v2: don't assume it is always GuC FW (Michal)
v3: added a new variable to avoid exceeding the number of characters in
the
line (Michal)
Signed-off-by: Piotr Piórkowski
Reported-by: Radoslaw Szwichtenberg
Cc: Michał Winiarski
Cc: Michal Wajdeczko
Cc: Sagar Arun Kamble
Cc: Joonas Lahtinen
Cc: Jackie Li
Cc: Radoslaw Szwichtenberg
---
drivers/gpu/drm/i915/intel_uc_fw.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/i915/intel_uc_fw.c
b/drivers/gpu/drm/i915/intel_uc_fw.c
index 30c73243f54d..486eb116015b 100644
--- a/drivers/gpu/drm/i915/intel_uc_fw.c
+++ b/drivers/gpu/drm/i915/intel_uc_fw.c
@@ -199,9 +199,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
int (*xfer)(struct intel_uc_fw *uc_fw,
struct i915_vma *vma))
{
- struct drm_i915_private *i915 = to_i915(uc_fw->obj->base.dev);
struct i915_vma *vma;
int err;
+ u32 ggtt_pin_bias;
DRM_DEBUG_DRIVER("%s fw load %s\n",
intel_uc_fw_type_repr(uc_fw->type), uc_fw->path);
@@ -222,9 +222,9 @@ int intel_uc_fw_upload(struct intel_uc_fw *uc_fw,
goto fail;
}
+ ggtt_pin_bias = to_i915(uc_fw->obj->base.dev)->guc.ggtt_pin_bias;
