[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset
== Series Details == Series: series starting with [1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset URL : https://patchwork.freedesktop.org/series/22488/ State : success == Summary == Series 22488v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22488/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 433s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 427s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 564s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 505s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 528s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 480s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 486s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 408s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 427s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 472s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 464s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 449s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 570s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 566s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 489s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 433s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 527s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time: 405s bf30bc2a70b83a77ba63436023f3550083715c56 drm-tip: 2017y-04m-04d-20h-00m-56s UTC integration manifest 2284252 drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4404/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset
During S3/S4 suspend, i915 sends HOST2GUC with ENTER_S_STATE action for suspending GuC. GuC stops scheduling at this point. i915 is currently doing explicit GPU reset during suspend ensuring GEM is idle. Suspend GuC prior to triggering GPU Reset to ensure GuC stays idle too. Cc: Jeff McGeeCc: Daniele Ceraolo Spurio Cc: Chris Wilson Cc: Joonas Lahtinen Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_drv.c | 2 -- drivers/gpu/drm/i915/i915_gem.c | 2 ++ 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index c616b4e..7b4fa84 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -1469,8 +1469,6 @@ static int i915_drm_suspend(struct drm_device *dev) goto out; } - intel_guc_suspend(dev_priv); - intel_display_suspend(dev); intel_dp_mst_suspend(dev); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index bbc6f1c..9234334 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -4456,6 +4456,8 @@ int i915_gem_suspend(struct drm_i915_private *dev_priv) i915_gem_context_lost(dev_priv); mutex_unlock(>struct_mutex); + intel_guc_suspend(dev_priv); + cancel_delayed_work_sync(_priv->gpu_error.hangcheck_work); cancel_delayed_work_sync(_priv->gt.retire_work); -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915/scheduler: add gvt force-single-submission for guc
== Series Details == Series: series starting with [v3,1/2] drm/i915/scheduler: add gvt force-single-submission for guc URL : https://patchwork.freedesktop.org/series/22482/ State : success == Summary == Series 22482v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22482/revisions/1/mbox/ Test gem_exec_fence: Subgroup await-hang-default: pass -> INCOMPLETE (fi-ilk-650) fdo#100144 fdo#100144 https://bugs.freedesktop.org/show_bug.cgi?id=100144 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 428s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 423s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 573s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 506s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 552s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 480s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 479s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 407s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 404s fi-ilk-650 total:48 pass:27 dwarn:0 dfail:0 fail:0 skip:20 time: 0s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 499s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 464s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 453s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time: 569s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 572s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 491s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 433s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 532s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 401s fi-skl-6700k failed to collect. IGT log at Patchwork_4403/fi-skl-6700k/igt.log bf30bc2a70b83a77ba63436023f3550083715c56 drm-tip: 2017y-04m-04d-20h-00m-56s UTC integration manifest bf6e308 drm/i915/scheduler: add gvt notification for guc e9993ac drm/i915/scheduler: add gvt force-single-submission for guc == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4403/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.
Hi, Libin We don't have 4K resolution monitor. We will double check others resolutions. -Original Message- From: Yang, Libin Sent: Wednesday, April 5, 2017 10:22 AM To: Jani Nikula; Wang, Quanxian ; intel-gfx@lists.freedesktop.org Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL. >-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Tuesday, April 4, 2017 6:55 PM >To: Wang, Quanxian ; intel- >g...@lists.freedesktop.org >Cc: Yang, Libin >Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value >manually for KBL. > >On Sat, 01 Apr 2017, Quanxian Wang wrote: >> It doesn't work on KBL. Just using automatic N/M. > >Please provide a more elaborate commit message. In particular, have a >look at > >commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 >Author: Libin Yang >Date: Tue Oct 25 17:54:18 2016 +0300 > >drm/i915/audio: set proper N/M in modeset > >and explain why that doesn't apply to KBL. And why just KBL, why not others? > >> According to the bspec, when set N/M, should disable and enable >> transcoder which attaching DP audio. but there is no such code to do >> that. >> without this implementation except KBL platforms, seems work well. Is this a mandatory requirement on the new platform? [Wang, Quanxian] yes. At least bspec said that with 'NOTE'. We saw "disable and enable transcoder" requirement on old platforms. But it will dramatically impact on the user experience. After discussion, we skipped this step and did a lot of test on the old platforms. They all works. [Wang, Quanxian] Seems to be in old platforms. I suggested that we can talk with silicon team to figure out a proper solution, because on the new platform we may also meet the same situations like old platforms that some resolution will not work properly. BTW: please test the playback on 4K resolution to see whether the playback and delay is normal. 4K is often an issue. Regards, Libin >> >> Signed-off-by: Quanxian Wang >> Tested-By: Wang Zhijun >> Tested-By: Cui Yueping >> --- >> drivers/gpu/drm/i915/intel_audio.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_audio.c >> b/drivers/gpu/drm/i915/intel_audio.c >> index 52c207e..0542031 100644 >> --- a/drivers/gpu/drm/i915/intel_audio.c >> +++ b/drivers/gpu/drm/i915/intel_audio.c >> @@ -300,7 +300,7 @@ hsw_dp_audio_config_update(struct intel_crtc >*intel_crtc, enum port port, >> tmp &= ~AUD_CONFIG_N_PROG_ENABLE; >> tmp |= AUD_CONFIG_N_VALUE_INDEX; >> >> -if (nm) { >> +if (!IS_KABYLAKE(dev_priv) && nm) { >> tmp &= ~AUD_CONFIG_N_MASK; >> tmp |= AUD_CONFIG_N(nm->n); >> tmp |= AUD_CONFIG_N_PROG_ENABLE; >> @@ -308,6 +308,9 @@ hsw_dp_audio_config_update(struct intel_crtc >> *intel_crtc, enum port port, >> >> I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> >> +if (IS_KABYLAKE(dev_priv)) >> +return; >> + > >The debug logging near the top of the function will be wrong for KBL, >and you now bypass HSW_AUD_M_CTS_ENABLE() setting for the automatic values. > >Seems to me the simplest would be to do > > if (IS_KABYLAKE(dev_priv)) > nm = NULL; > >*but* this still needs better rationale, especially why this is specific to >KBL. > >BR, >Jani. > > >> tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe)); >> tmp &= ~AUD_CONFIG_M_MASK; >> tmp &= ~AUD_M_CTS_M_VALUE_INDEX; > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.
Hi Quanxian, >-Original Message- >From: Wang, Quanxian >Sent: Wednesday, April 5, 2017 10:21 AM >To: Jani Nikula; intel-gfx@lists.freedesktop.org >Cc: Yang, Libin >Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value >manually for KBL. > >Sorry, I don't find them in bspec. With our testing, SKL/APL works and KBL >failed. > >The commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 mentioned should >not do testing on KBL DP audio. > >We found the issue in the testing for Ubuntu latest release 17.04. (Almost >upstream) > >But really I don't know the root cause. > >Also I have mentioned in commit, for general process of DP audio in bspec, >transcoder should be restart to make it. > But no code to do that. Also I don't know why driver doesn't implement that. Please see my another email. I explained the reason on it. And I strongly suggest you doing all the resolution and audio format playback test. We did find some resolution and audio format will fail on the auto setting of N/M. Regards, Libin > >-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Tuesday, April 4, 2017 6:55 PM >To: Wang, Quanxian ; intel- >g...@lists.freedesktop.org >Cc: Yang, Libin >Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value >manually for KBL. > >On Sat, 01 Apr 2017, Quanxian Wang wrote: >> It doesn't work on KBL. Just using automatic N/M. > >Please provide a more elaborate commit message. In particular, have a look at > >commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 >Author: Libin Yang >Date: Tue Oct 25 17:54:18 2016 +0300 > >drm/i915/audio: set proper N/M in modeset > >and explain why that doesn't apply to KBL. And why just KBL, why not others? > >> According to the bspec, when set N/M, should disable and enable >> transcoder which attaching DP audio. but there is no such code to do >> that. >> without this implementation except KBL platforms, seems work well. >> >> Signed-off-by: Quanxian Wang >> Tested-By: Wang Zhijun >> Tested-By: Cui Yueping >> --- >> drivers/gpu/drm/i915/intel_audio.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_audio.c >> b/drivers/gpu/drm/i915/intel_audio.c >> index 52c207e..0542031 100644 >> --- a/drivers/gpu/drm/i915/intel_audio.c >> +++ b/drivers/gpu/drm/i915/intel_audio.c >> @@ -300,7 +300,7 @@ hsw_dp_audio_config_update(struct intel_crtc >*intel_crtc, enum port port, >> tmp &= ~AUD_CONFIG_N_PROG_ENABLE; >> tmp |= AUD_CONFIG_N_VALUE_INDEX; >> >> -if (nm) { >> +if (!IS_KABYLAKE(dev_priv) && nm) { >> tmp &= ~AUD_CONFIG_N_MASK; >> tmp |= AUD_CONFIG_N(nm->n); >> tmp |= AUD_CONFIG_N_PROG_ENABLE; >> @@ -308,6 +308,9 @@ hsw_dp_audio_config_update(struct intel_crtc >> *intel_crtc, enum port port, >> >> I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> >> +if (IS_KABYLAKE(dev_priv)) >> +return; >> + > >The debug logging near the top of the function will be wrong for KBL, and you >now bypass HSW_AUD_M_CTS_ENABLE() setting for the automatic values. > >Seems to me the simplest would be to do > > if (IS_KABYLAKE(dev_priv)) > nm = NULL; > >*but* this still needs better rationale, especially why this is specific to >KBL. > >BR, >Jani. > > >> tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe)); >> tmp &= ~AUD_CONFIG_M_MASK; >> tmp &= ~AUD_M_CTS_M_VALUE_INDEX; > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.
>-Original Message- >From: Jani Nikula [mailto:jani.nik...@linux.intel.com] >Sent: Tuesday, April 4, 2017 6:55 PM >To: Wang, Quanxian; intel- >g...@lists.freedesktop.org >Cc: Yang, Libin >Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value >manually for KBL. > >On Sat, 01 Apr 2017, Quanxian Wang wrote: >> It doesn't work on KBL. Just using automatic N/M. > >Please provide a more elaborate commit message. In particular, have a look at > >commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 >Author: Libin Yang >Date: Tue Oct 25 17:54:18 2016 +0300 > >drm/i915/audio: set proper N/M in modeset > >and explain why that doesn't apply to KBL. And why just KBL, why not others? > >> According to the bspec, when set N/M, should disable and enable >> transcoder which attaching DP audio. but there is no such code to do >> that. >> without this implementation except KBL platforms, seems work well. Is this a mandatory requirement on the new platform? We saw "disable and enable transcoder" requirement on old platforms. But it will dramatically impact on the user experience. After discussion, we skipped this step and did a lot of test on the old platforms. They all works. I suggested that we can talk with silicon team to figure out a proper solution, because on the new platform we may also meet the same situations like old platforms that some resolution will not work properly. BTW: please test the playback on 4K resolution to see whether the playback and delay is normal. 4K is often an issue. Regards, Libin >> >> Signed-off-by: Quanxian Wang >> Tested-By: Wang Zhijun >> Tested-By: Cui Yueping >> --- >> drivers/gpu/drm/i915/intel_audio.c | 5 - >> 1 file changed, 4 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/gpu/drm/i915/intel_audio.c >> b/drivers/gpu/drm/i915/intel_audio.c >> index 52c207e..0542031 100644 >> --- a/drivers/gpu/drm/i915/intel_audio.c >> +++ b/drivers/gpu/drm/i915/intel_audio.c >> @@ -300,7 +300,7 @@ hsw_dp_audio_config_update(struct intel_crtc >*intel_crtc, enum port port, >> tmp &= ~AUD_CONFIG_N_PROG_ENABLE; >> tmp |= AUD_CONFIG_N_VALUE_INDEX; >> >> -if (nm) { >> +if (!IS_KABYLAKE(dev_priv) && nm) { >> tmp &= ~AUD_CONFIG_N_MASK; >> tmp |= AUD_CONFIG_N(nm->n); >> tmp |= AUD_CONFIG_N_PROG_ENABLE; >> @@ -308,6 +308,9 @@ hsw_dp_audio_config_update(struct intel_crtc >> *intel_crtc, enum port port, >> >> I915_WRITE(HSW_AUD_CFG(pipe), tmp); >> >> +if (IS_KABYLAKE(dev_priv)) >> +return; >> + > >The debug logging near the top of the function will be wrong for KBL, and you >now bypass HSW_AUD_M_CTS_ENABLE() setting for the automatic values. > >Seems to me the simplest would be to do > > if (IS_KABYLAKE(dev_priv)) > nm = NULL; > >*but* this still needs better rationale, especially why this is specific to >KBL. > >BR, >Jani. > > >> tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe)); >> tmp &= ~AUD_CONFIG_M_MASK; >> tmp &= ~AUD_M_CTS_M_VALUE_INDEX; > >-- >Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.
Sorry, I don't find them in bspec. With our testing, SKL/APL works and KBL failed. The commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 mentioned should not do testing on KBL DP audio. We found the issue in the testing for Ubuntu latest release 17.04. (Almost upstream) But really I don't know the root cause. Also I have mentioned in commit, for general process of DP audio in bspec, transcoder should be restart to make it. But no code to do that. Also I don't know why driver doesn't implement that. -Original Message- From: Jani Nikula [mailto:jani.nik...@linux.intel.com] Sent: Tuesday, April 4, 2017 6:55 PM To: Wang, Quanxian; intel-gfx@lists.freedesktop.org Cc: Yang, Libin Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL. On Sat, 01 Apr 2017, Quanxian Wang wrote: > It doesn't work on KBL. Just using automatic N/M. Please provide a more elaborate commit message. In particular, have a look at commit 6014ac122ed081feca99217bc57b2e15c7fc1a51 Author: Libin Yang Date: Tue Oct 25 17:54:18 2016 +0300 drm/i915/audio: set proper N/M in modeset and explain why that doesn't apply to KBL. And why just KBL, why not others? > According to the bspec, when set N/M, should disable and enable > transcoder which attaching DP audio. but there is no such code to do > that. > without this implementation except KBL platforms, seems work well. > > Signed-off-by: Quanxian Wang > Tested-By: Wang Zhijun > Tested-By: Cui Yueping > --- > drivers/gpu/drm/i915/intel_audio.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/i915/intel_audio.c > b/drivers/gpu/drm/i915/intel_audio.c > index 52c207e..0542031 100644 > --- a/drivers/gpu/drm/i915/intel_audio.c > +++ b/drivers/gpu/drm/i915/intel_audio.c > @@ -300,7 +300,7 @@ hsw_dp_audio_config_update(struct intel_crtc *intel_crtc, > enum port port, > tmp &= ~AUD_CONFIG_N_PROG_ENABLE; > tmp |= AUD_CONFIG_N_VALUE_INDEX; > > - if (nm) { > + if (!IS_KABYLAKE(dev_priv) && nm) { > tmp &= ~AUD_CONFIG_N_MASK; > tmp |= AUD_CONFIG_N(nm->n); > tmp |= AUD_CONFIG_N_PROG_ENABLE; > @@ -308,6 +308,9 @@ hsw_dp_audio_config_update(struct intel_crtc > *intel_crtc, enum port port, > > I915_WRITE(HSW_AUD_CFG(pipe), tmp); > > + if (IS_KABYLAKE(dev_priv)) > + return; > + The debug logging near the top of the function will be wrong for KBL, and you now bypass HSW_AUD_M_CTS_ENABLE() setting for the automatic values. Seems to me the simplest would be to do if (IS_KABYLAKE(dev_priv)) nm = NULL; *but* this still needs better rationale, especially why this is specific to KBL. BR, Jani. > tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe)); > tmp &= ~AUD_CONFIG_M_MASK; > tmp &= ~AUD_M_CTS_M_VALUE_INDEX; -- Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Enhanced disable access to stolen memory as a guest (rev4)
== Series Details == Series: drm/i915: Enhanced disable access to stolen memory as a guest (rev4) URL : https://patchwork.freedesktop.org/series/21818/ State : success == Summary == Series 21818v4 drm/i915: Enhanced disable access to stolen memory as a guest https://patchwork.freedesktop.org/api/1.0/series/21818/revisions/4/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-kbl-7560u) fdo#100125 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 429s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 423s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 509s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 529s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 480s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 481s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 412s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 410s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 423s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 469s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 458s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 568s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 573s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 459s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 492s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 433s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 529s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time: 399s bf30bc2a70b83a77ba63436023f3550083715c56 drm-tip: 2017y-04m-04d-20h-00m-56s UTC integration manifest ab00c6af drm/i915: Enhanced disable access to stolen memory as a guest == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4402/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v3 2/2] drm/i915/scheduler: add gvt notification for guc
GVT request needs a manual mmio load/restore. Before GuC submit a request, send notification to gvt for mmio loading. And after the GuC finished this GVT request, notify gvt again for mmio restore. This follows the usage when using execlists submission. Cc: xiao.zh...@intel.com Cc: kevin.t...@intel.com Cc: joonas.lahti...@linux.intel.com Cc: ch...@chris-wilson.co.uk Signed-off-by: Chuanxiao Dong--- drivers/gpu/drm/i915/i915_guc_submission.c | 4 drivers/gpu/drm/i915/intel_gvt.h | 12 drivers/gpu/drm/i915/intel_lrc.c | 21 +++-- 3 files changed, 19 insertions(+), 18 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 862f4fd..2f3bb16 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -606,6 +606,8 @@ static void __i915_guc_submit(struct drm_i915_gem_request *rq) unsigned long flags; int b_ret; + intel_gvt_notify_context_status(rq, INTEL_CONTEXT_SCHEDULE_IN); + /* WA to flush out the pending GMADR writes to ring buffer. */ if (i915_vma_is_map_and_fenceable(rq->ring->vma)) POSTING_READ_FW(GUC_STATUS); @@ -712,6 +714,8 @@ static void i915_guc_irq_handler(unsigned long data) rq = port[0].request; while (rq && i915_gem_request_completed(rq)) { trace_i915_gem_request_out(rq); + intel_gvt_notify_context_status(rq, + INTEL_CONTEXT_SCHEDULE_OUT); i915_gem_request_put(rq); port[0].request = port[1].request; port[1].request = NULL; diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h index c0dcd66..813d0f8 100644 --- a/drivers/gpu/drm/i915/intel_gvt.h +++ b/drivers/gpu/drm/i915/intel_gvt.h @@ -38,6 +38,13 @@ intel_gvt_context_single_port_submit(const struct i915_gem_context *ctx) { return i915_gem_context_force_single_submission(ctx); } +static inline void +intel_gvt_notify_context_status(struct drm_i915_gem_request *rq, + unsigned long status) +{ + atomic_notifier_call_chain(>engine->context_status_notifier, + status, rq); +} #else static inline int intel_gvt_init(struct drm_i915_private *dev_priv) { @@ -51,6 +58,11 @@ intel_gvt_context_single_port_submit(const struct i915_gem_context *ctx) { return false; } +static inline void +intel_gvt_notify_context_status(struct drm_i915_gem_request *rq, + unsigned long status) +{ +} #endif #endif /* _INTEL_GVT_H_ */ diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 61291e9..81f9a3b 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -295,21 +295,6 @@ uint64_t intel_lr_context_descriptor(struct i915_gem_context *ctx, return ctx->engine[engine->id].lrc_desc; } -static inline void -execlists_context_status_change(struct drm_i915_gem_request *rq, - unsigned long status) -{ - /* -* Only used when GVT-g is enabled now. When GVT-g is disabled, -* The compiler should eliminate this function as dead-code. -*/ - if (!IS_ENABLED(CONFIG_DRM_I915_GVT)) - return; - - atomic_notifier_call_chain(>engine->context_status_notifier, - status, rq); -} - static void execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state) { @@ -350,7 +335,7 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) GEM_BUG_ON(port[0].count > 1); if (!port[0].count) - execlists_context_status_change(port[0].request, + intel_gvt_notify_context_status(port[0].request, INTEL_CONTEXT_SCHEDULE_IN); desc[0] = execlists_update_context(port[0].request); GEM_DEBUG_EXEC(port[0].context_id = upper_32_bits(desc[0])); @@ -358,7 +343,7 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) if (port[1].request) { GEM_BUG_ON(port[1].count); - execlists_context_status_change(port[1].request, + intel_gvt_notify_context_status(port[1].request, INTEL_CONTEXT_SCHEDULE_IN); desc[1] = execlists_update_context(port[1].request); GEM_DEBUG_EXEC(port[1].context_id = upper_32_bits(desc[1])); @@ -560,7 +545,7 @@ static void intel_lrc_irq_handler(unsigned long data) if (--port[0].count == 0) { GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);
[Intel-gfx] [PATCH v3 1/2] drm/i915/scheduler: add gvt force-single-submission for guc
GVT needs single submission and cannot allow merge. So when GuC submitting a GVT request, the next one should be submitted to guc later until the previous one is completed. This is following the usage when using execlist mode submission. v2: make force-single-submission specific to gvt (Chris) v3: keep the original code implementation (Chris) Cc: ch...@chris-wilson.co.uk Signed-off-by: Chuanxiao Dong--- drivers/gpu/drm/i915/i915_gem_context.h| 13 + drivers/gpu/drm/i915/i915_guc_submission.c | 6 +- drivers/gpu/drm/i915/intel_gvt.h | 11 +++ drivers/gpu/drm/i915/intel_lrc.c | 25 - 4 files changed, 33 insertions(+), 22 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_context.h b/drivers/gpu/drm/i915/i915_gem_context.h index 4af2ab94..2c3afec 100644 --- a/drivers/gpu/drm/i915/i915_gem_context.h +++ b/drivers/gpu/drm/i915/i915_gem_context.h @@ -246,6 +246,19 @@ static inline bool i915_gem_context_is_kernel(struct i915_gem_context *ctx) return !ctx->file_priv; } +static inline bool +i915_gem_context_can_merge(const struct i915_gem_context *prev, + const struct i915_gem_context *next) +{ + if (prev != next) + return false; + + if (i915_gem_context_force_single_submission(prev)) + return false; + + return true; +} + /* i915_gem_context.c */ int __must_check i915_gem_context_init(struct drm_i915_private *dev_priv); void i915_gem_context_lost(struct drm_i915_private *dev_priv); diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c b/drivers/gpu/drm/i915/i915_guc_submission.c index 1642fff..862f4fd 100644 --- a/drivers/gpu/drm/i915/i915_guc_submission.c +++ b/drivers/gpu/drm/i915/i915_guc_submission.c @@ -668,10 +668,14 @@ static bool i915_guc_dequeue(struct intel_engine_cs *engine) struct drm_i915_gem_request *rq = rb_entry(rb, typeof(*rq), priotree.node); - if (last && rq->ctx != last->ctx) { + if (last && !i915_gem_context_can_merge(last->ctx, rq->ctx)) { if (port != engine->execlist_port) break; + if (intel_gvt_context_single_port_submit(last->ctx) || + intel_gvt_context_single_port_submit(rq->ctx)) + break; + i915_gem_request_assign(>request, last); nested_enable_signaling(last); port++; diff --git a/drivers/gpu/drm/i915/intel_gvt.h b/drivers/gpu/drm/i915/intel_gvt.h index 25df2d6..c0dcd66 100644 --- a/drivers/gpu/drm/i915/intel_gvt.h +++ b/drivers/gpu/drm/i915/intel_gvt.h @@ -32,6 +32,12 @@ void intel_gvt_cleanup(struct drm_i915_private *dev_priv); int intel_gvt_init_device(struct drm_i915_private *dev_priv); void intel_gvt_clean_device(struct drm_i915_private *dev_priv); int intel_gvt_init_host(void); + +static inline bool +intel_gvt_context_single_port_submit(const struct i915_gem_context *ctx) +{ + return i915_gem_context_force_single_submission(ctx); +} #else static inline int intel_gvt_init(struct drm_i915_private *dev_priv) { @@ -40,6 +46,11 @@ static inline int intel_gvt_init(struct drm_i915_private *dev_priv) static inline void intel_gvt_cleanup(struct drm_i915_private *dev_priv) { } +static inline bool +intel_gvt_context_single_port_submit(const struct i915_gem_context *ctx) +{ + return false; +} #endif #endif /* _INTEL_GVT_H_ */ diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c index 0dc1cc4..61291e9 100644 --- a/drivers/gpu/drm/i915/intel_lrc.c +++ b/drivers/gpu/drm/i915/intel_lrc.c @@ -377,24 +377,6 @@ static void execlists_submit_ports(struct intel_engine_cs *engine) writel(lower_32_bits(desc[0]), elsp); } -static bool ctx_single_port_submission(const struct i915_gem_context *ctx) -{ - return (IS_ENABLED(CONFIG_DRM_I915_GVT) && - i915_gem_context_force_single_submission(ctx)); -} - -static bool can_merge_ctx(const struct i915_gem_context *prev, - const struct i915_gem_context *next) -{ - if (prev != next) - return false; - - if (ctx_single_port_submission(prev)) - return false; - - return true; -} - static void execlists_dequeue(struct intel_engine_cs *engine) { struct drm_i915_gem_request *last; @@ -450,7 +432,8 @@ static void execlists_dequeue(struct intel_engine_cs *engine) * request, and so we never need to tell the hardware about * the first. */ - if (last && !can_merge_ctx(cursor->ctx, last->ctx)) { + if (last && + !i915_gem_context_can_merge(last->ctx, cursor->ctx)) { /* If we are on the second port and cannot combine
[Intel-gfx] [PATCH v3 0/2] drm/i915/scheduler: add gvt force-single-submission and notification for guc
GVT requires force-single-submission and notification when i915 using execlist submit, and these should be extended to GuC when i915 using GuC submit. Below two patches are used to implement this Chuanxiao Dong (2): drm/i915/scheduler: add gvt force-single-submission for guc drm/i915/scheduler: add gvt notification for guc drivers/gpu/drm/i915/i915_gem_context.h| 13 + drivers/gpu/drm/i915/i915_guc_submission.c | 10 ++- drivers/gpu/drm/i915/intel_gvt.h | 23 +++ drivers/gpu/drm/i915/intel_lrc.c | 46 +- 4 files changed, 52 insertions(+), 40 deletions(-) -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH V4] drm/i915: Enhanced disable access to stolen memory as a guest
Stolen memory is in RMRR and has identity mapping in iommu, so gt could access stolen memory in host OS. While RMRR isn't supported by kvm, both EPT and guest iommu domain lack of maaping for stolen memory, so both vcpu and gt couldn't access stolen memory in guest. commit "04a68a3 drm/i915/gvt: Disable access to stolen memory as a guest" isn't enough in IGD passthrough environment where vgt code doesn't run. This patch detects i915 running as a guest through the existence of emulated ISA bridge. v2:GVT-g may run in non qemu (Zhenyu) v3:Make commit message clear (Daniel) v4:Fix typo References: c875d2c iommu/vt-d: Exclude devices using RMRRs from IOMMU API domains Link: https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99028 Signed-off-by: Xiong ZhangReviewed-by: Zhenyu Wang Cc: sta...@vger.kernel.org --- drivers/gpu/drm/i915/i915_drv.c| 1 + drivers/gpu/drm/i915/i915_drv.h| 1 + drivers/gpu/drm/i915/i915_gem_stolen.c | 4 ++-- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c index 03d9e45..8b807a9 100644 --- a/drivers/gpu/drm/i915/i915_drv.c +++ b/drivers/gpu/drm/i915/i915_drv.c @@ -223,6 +223,7 @@ static void intel_detect_pch(struct drm_i915_private *dev_priv) PCI_SUBVENDOR_ID_REDHAT_QUMRANET && pch->subsystem_device == PCI_SUBDEVICE_ID_QEMU)) { + dev_priv->run_on_qemu = true; dev_priv->pch_type = intel_virt_detect_pch(dev_priv); } else diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index a5947a4..ad95c87 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2145,6 +2145,7 @@ struct drm_i915_private { struct intel_uncore uncore; struct i915_virtual_gpu vgpu; + bool run_on_qemu; struct intel_gvt *gvt; diff --git a/drivers/gpu/drm/i915/i915_gem_stolen.c b/drivers/gpu/drm/i915/i915_gem_stolen.c index f3abdc2..6a011b0 100644 --- a/drivers/gpu/drm/i915/i915_gem_stolen.c +++ b/drivers/gpu/drm/i915/i915_gem_stolen.c @@ -409,8 +409,8 @@ int i915_gem_init_stolen(struct drm_i915_private *dev_priv) mutex_init(_priv->mm.stolen_lock); - if (intel_vgpu_active(dev_priv)) { - DRM_INFO("iGVT-g active, disabling use of stolen memory\n"); + if (dev_priv->run_on_qemu || intel_vgpu_active(dev_priv)) { + DRM_INFO("Running in guest, disabling use of stolen memory\n"); return 0; } -- 1.9.1 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 13/14] drm/i915/dp: use readb and writeb calls for single byte DPCD access
Yes this is a good optimization. Manasi On Tue, Mar 28, 2017 at 05:59:13PM +0300, Jani Nikula wrote: > This is what we have the readb and writeb variants for. Do some minor > return value and variable cleanup while at it. > > Cc: Manasi Navare> Cc: Ville Syrjälä > Signed-off-by: Jani Nikula Reviewed-by: > --- > drivers/gpu/drm/i915/intel_dp.c | 37 + > 1 file changed, 17 insertions(+), 20 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 6f743490855b..81682fd2804b 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -3661,9 +3661,9 @@ intel_edp_init_dpcd(struct intel_dp *intel_dp) > uint8_t frame_sync_cap; > > dev_priv->psr.sink_support = true; > - drm_dp_dpcd_read(_dp->aux, > - DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP, > - _sync_cap, 1); > + drm_dp_dpcd_readb(_dp->aux, > + DP_SINK_DEVICE_AUX_FRAME_SYNC_CAP, > + _sync_cap); > dev_priv->psr.aux_frame_sync = frame_sync_cap ? true : false; > /* PSR2 needs frame sync as well */ > dev_priv->psr.psr2_support = dev_priv->psr.aux_frame_sync; > @@ -3737,8 +3737,8 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) > intel_dp_set_common_rates(intel_dp); > } > > - if (drm_dp_dpcd_read(_dp->aux, DP_SINK_COUNT, > - _dp->sink_count, 1) < 0) > + if (drm_dp_dpcd_readb(_dp->aux, DP_SINK_COUNT, > + _dp->sink_count) <= 0) > return false; > > /* > @@ -3775,7 +3775,7 @@ intel_dp_get_dpcd(struct intel_dp *intel_dp) > static bool > intel_dp_can_mst(struct intel_dp *intel_dp) > { > - u8 buf[1]; > + u8 mstm_cap; > > if (!i915.enable_dp_mst) > return false; > @@ -3786,10 +3786,10 @@ intel_dp_can_mst(struct intel_dp *intel_dp) > if (intel_dp->dpcd[DP_DPCD_REV] < 0x12) > return false; > > - if (drm_dp_dpcd_read(_dp->aux, DP_MSTM_CAP, buf, 1) != 1) > + if (drm_dp_dpcd_readb(_dp->aux, DP_MSTM_CAP, _cap) != 1) > return false; > > - return buf[0] & DP_MST_CAP; > + return mstm_cap & DP_MST_CAP; > } > > static void > @@ -3935,9 +3935,8 @@ int intel_dp_sink_crc(struct intel_dp *intel_dp, u8 > *crc) > static bool > intel_dp_get_sink_irq(struct intel_dp *intel_dp, u8 *sink_irq_vector) > { > - return drm_dp_dpcd_read(_dp->aux, > -DP_DEVICE_SERVICE_IRQ_VECTOR, > -sink_irq_vector, 1) == 1; > + return drm_dp_dpcd_readb(_dp->aux, DP_DEVICE_SERVICE_IRQ_VECTOR, > + sink_irq_vector) == 1; > } > > static bool > @@ -4000,13 +3999,13 @@ static uint8_t intel_dp_autotest_link_training(struct > intel_dp *intel_dp) > static uint8_t intel_dp_autotest_video_pattern(struct intel_dp *intel_dp) > { > uint8_t test_pattern; > - uint16_t test_misc; > + uint8_t test_misc; > __be16 h_width, v_height; > int status = 0; > > /* Read the TEST_PATTERN (DP CTS 3.1.5) */ > - status = drm_dp_dpcd_read(_dp->aux, DP_TEST_PATTERN, > - _pattern, 1); > + status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_PATTERN, > +_pattern); > if (status <= 0) { > DRM_DEBUG_KMS("Test pattern read failed\n"); > return DP_TEST_NAK; > @@ -4028,8 +4027,8 @@ static uint8_t intel_dp_autotest_video_pattern(struct > intel_dp *intel_dp) > return DP_TEST_NAK; > } > > - status = drm_dp_dpcd_read(_dp->aux, DP_TEST_MISC0, > - _misc, 1); > + status = drm_dp_dpcd_readb(_dp->aux, DP_TEST_MISC0, > +_misc); > if (status <= 0) { > DRM_DEBUG_KMS("TEST MISC read failed\n"); > return DP_TEST_NAK; > @@ -4088,10 +4087,8 @@ static uint8_t intel_dp_autotest_edid(struct intel_dp > *intel_dp) >*/ > block += intel_connector->detect_edid->extensions; > > - if (!drm_dp_dpcd_write(_dp->aux, > - DP_TEST_EDID_CHECKSUM, > - >checksum, > - 1)) > + if (drm_dp_dpcd_writeb(_dp->aux, DP_TEST_EDID_CHECKSUM, > +block->checksum) <= 0) > DRM_DEBUG_KMS("Failed to write EDID checksum\n"); > > test_result = DP_TEST_ACK | DP_TEST_EDID_CHECKSUM_WRITE; > -- > 2.1.4 > ___ Intel-gfx mailing list
Re: [Intel-gfx] [PATCH v3 12/14] drm/i915/dp: localize link rate index variable more
On Wed, Mar 29, 2017 at 10:22:32AM +0300, Jani Nikula wrote: > On Wed, 29 Mar 2017, Manasi Navarewrote: > > Why not squash this with patch 08/14? and call it cleanup for obtaining the > > rate index using intel_dp_rate_index() > > Just a thought.. > > Again, usually too big patches are the problem, not the other way > around. > > BR, > Jani. > OK, your call. Functionality wise looks good and I have tested this. > > > > Regards > > Manasi > > > > On Tue, Mar 28, 2017 at 05:59:12PM +0300, Jani Nikula wrote: > >> Localize link_rate_index to the if block, and rename to just index to > >> reduce indent. > >> > >> Cc: Manasi Navare > >> Cc: Ville Syrjälä > >> Signed-off-by: Jani Nikula Reviewed-by: > >> --- > >> drivers/gpu/drm/i915/intel_dp.c | 13 +++-- > >> 1 file changed, 7 insertions(+), 6 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_dp.c > >> b/drivers/gpu/drm/i915/intel_dp.c > >> index 95f2278700e3..6f743490855b 100644 > >> --- a/drivers/gpu/drm/i915/intel_dp.c > >> +++ b/drivers/gpu/drm/i915/intel_dp.c > >> @@ -1636,7 +1636,6 @@ intel_dp_compute_config(struct intel_encoder > >> *encoder, > >>/* Conveniently, the link BW constants become indices with a shift...*/ > >>int min_clock = 0; > >>int max_clock; > >> - int link_rate_index; > >>int bpp, mode_rate; > >>int link_avail, link_clock; > >>int common_len; > >> @@ -1680,11 +1679,13 @@ intel_dp_compute_config(struct intel_encoder > >> *encoder, > >> > >>/* Use values requested by Compliance Test Request */ > >>if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) { > >> - link_rate_index = intel_dp_rate_index(intel_dp->common_rates, > >> - > >> intel_dp->num_common_rates, > >> - > >> intel_dp->compliance.test_link_rate); > >> - if (link_rate_index >= 0) > >> - min_clock = max_clock = link_rate_index; > >> + int index; > >> + > >> + index = intel_dp_rate_index(intel_dp->common_rates, > >> + intel_dp->num_common_rates, > >> + > >> intel_dp->compliance.test_link_rate); > >> + if (index >= 0) > >> + min_clock = max_clock = index; > >>min_lane_count = max_lane_count = > >> intel_dp->compliance.test_lane_count; > >>} > >>DRM_DEBUG_KMS("DP link computation with max lane count %i " > >> -- > >> 2.1.4 > >> > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/dp: do not limit rate seek when not needed
The commit message looks good now. Reviewed-by:Manasi On Wed, Mar 29, 2017 at 12:23:10PM +0300, Jani Nikula wrote: > In link training fallback, we're trying to find a rate that we know is > in a sorted array of common link rates. We don't need to limit the array > using the max rate. For test request, the DP CTS doesn't say we should > limit the rate based on earlier fallback. This lets us get rid of > intel_dp_link_rate_index() and use intel_dp_rate_index() instead. > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > > --- > > updated commit message, no changes > --- > drivers/gpu/drm/i915/intel_dp.c | 31 --- > 1 file changed, 12 insertions(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 1808af6d635d..8c061c54d481 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -317,25 +317,16 @@ static int intel_dp_common_len_rate_limit(struct > intel_dp *intel_dp, > return 0; > } > > -static int intel_dp_link_rate_index(struct intel_dp *intel_dp, int link_rate) > -{ > - int common_len; > - > - common_len = intel_dp_common_len_rate_limit(intel_dp, > - > intel_dp->max_sink_link_rate); > - > - return intel_dp_rate_index(intel_dp->common_rates, common_len, > link_rate); > -} > - > int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp, > int link_rate, uint8_t lane_count) > { > - const int *common_rates = intel_dp->common_rates; > - int link_rate_index; > + int index; > > - link_rate_index = intel_dp_link_rate_index(intel_dp, link_rate); > - if (link_rate_index > 0) { > - intel_dp->max_sink_link_rate = common_rates[link_rate_index - > 1]; > + index = intel_dp_rate_index(intel_dp->common_rates, > + intel_dp->num_common_rates, > + link_rate); > + if (index > 0) { > + intel_dp->max_sink_link_rate = intel_dp->common_rates[index - > 1]; > intel_dp->max_sink_lane_count = lane_count; > } else if (lane_count > 1) { > intel_dp->max_sink_link_rate = intel_dp_max_sink_rate(intel_dp); > @@ -1685,8 +1676,9 @@ intel_dp_compute_config(struct intel_encoder *encoder, > > /* Use values requested by Compliance Test Request */ > if (intel_dp->compliance.test_type == DP_TEST_LINK_TRAINING) { > - link_rate_index = intel_dp_link_rate_index(intel_dp, > - > intel_dp->compliance.test_link_rate); > + link_rate_index = intel_dp_rate_index(intel_dp->common_rates, > + > intel_dp->num_common_rates, > + > intel_dp->compliance.test_link_rate); > if (link_rate_index >= 0) > min_clock = max_clock = link_rate_index; > min_lane_count = max_lane_count = > intel_dp->compliance.test_lane_count; > @@ -3988,8 +3980,9 @@ static uint8_t intel_dp_autotest_link_training(struct > intel_dp *intel_dp) > } > /* Validate the requested link rate */ > test_link_rate = drm_dp_bw_code_to_link_rate(test_link_bw); > - link_rate_index = intel_dp_link_rate_index(intel_dp, > -test_link_rate); > + link_rate_index = intel_dp_rate_index(intel_dp->common_rates, > + intel_dp->num_common_rates, > + test_link_rate); > if (link_rate_index < 0) > return DP_TEST_NAK; > > -- > 2.1.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 07/14] drm/i915/dp: cache common rates with sink rates
Reviewed-by:Manasi On Tue, Mar 28, 2017 at 05:59:07PM +0300, Jani Nikula wrote: > Now that source rates are static and sink rates are updated whenever > DPCD is updated, we can do and cache the intersection of them whenever > sink rates are updated. This reduces code complexity, as we don't have > to keep calling the functions to intersect. We also get rid of several > common rates arrays on stack. > > Limiting the common rates by a max link rate can be done by picking the > first N elements of the cached common rates. > > v2: get rid of the local common_rates variable (Manasi) > v3: don't clobber cached eDP rates on short pulse (Ville) > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dp.c | 75 > ++-- > drivers/gpu/drm/i915/intel_drv.h | 3 ++ > 2 files changed, 45 insertions(+), 33 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index e4650f1625cc..1808af6d635d 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -284,17 +284,29 @@ static int intel_dp_rate_index(const int *rates, int > len, int rate) > return -1; > } > > -static int intel_dp_common_rates(struct intel_dp *intel_dp, > - int *common_rates) > +static void intel_dp_set_common_rates(struct intel_dp *intel_dp) > { > - int max_rate = intel_dp->max_sink_link_rate; > - int i, common_len; > + WARN_ON(!intel_dp->num_source_rates || !intel_dp->num_sink_rates); > > - common_len = intersect_rates(intel_dp->source_rates, > - intel_dp->num_source_rates, > - intel_dp->sink_rates, > - intel_dp->num_sink_rates, > - common_rates); > + intel_dp->num_common_rates = intersect_rates(intel_dp->source_rates, > + intel_dp->num_source_rates, > + intel_dp->sink_rates, > + intel_dp->num_sink_rates, > + intel_dp->common_rates); > + > + /* Paranoia, there should always be something in common. */ > + if (WARN_ON(intel_dp->num_common_rates == 0)) { > + intel_dp->common_rates[0] = default_rates[0]; > + intel_dp->num_common_rates = 1; > + } > +} > + > +/* get length of common rates potentially limited by max_rate */ > +static int intel_dp_common_len_rate_limit(struct intel_dp *intel_dp, > + int max_rate) > +{ > + const int *common_rates = intel_dp->common_rates; > + int i, common_len = intel_dp->num_common_rates; > > /* Limit results by potentially reduced max rate */ > for (i = 0; i < common_len; i++) { > @@ -305,25 +317,23 @@ static int intel_dp_common_rates(struct intel_dp > *intel_dp, > return 0; > } > > -static int intel_dp_link_rate_index(struct intel_dp *intel_dp, > - int *common_rates, int link_rate) > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp, int link_rate) > { > int common_len; > > - common_len = intel_dp_common_rates(intel_dp, common_rates); > + common_len = intel_dp_common_len_rate_limit(intel_dp, > + > intel_dp->max_sink_link_rate); > > - return intel_dp_rate_index(common_rates, common_len, link_rate); > + return intel_dp_rate_index(intel_dp->common_rates, common_len, > link_rate); > } > > int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp, > int link_rate, uint8_t lane_count) > { > - int common_rates[DP_MAX_SUPPORTED_RATES]; > + const int *common_rates = intel_dp->common_rates; > int link_rate_index; > > - link_rate_index = intel_dp_link_rate_index(intel_dp, > -common_rates, > -link_rate); > + link_rate_index = intel_dp_link_rate_index(intel_dp, link_rate); > if (link_rate_index > 0) { > intel_dp->max_sink_link_rate = common_rates[link_rate_index - > 1]; > intel_dp->max_sink_lane_count = lane_count; > @@ -1506,8 +1516,6 @@ static void snprintf_int_array(char *str, size_t len, > > static void intel_dp_print_rates(struct intel_dp *intel_dp) > { > - int common_len; > - int common_rates[DP_MAX_SUPPORTED_RATES]; > char str[128]; /* FIXME: too big for stack? */ > > if ((drm_debug & DRM_UT_KMS) == 0) > @@ -1521,8 +1529,8 @@ static void intel_dp_print_rates(struct intel_dp > *intel_dp) >
Re: [Intel-gfx] [PATCH v3 05/14] drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4
I agree with disentangling the fallback rate limiting from sink rates and instead just limiting the common_rates array based on max link rate. Reviewed-by:Manasi On Tue, Mar 28, 2017 at 05:59:05PM +0300, Jani Nikula wrote: > There is some conflation related to sink rates, making this change more > complicated than it would otherwise have to be. There are three changes > here that are rather difficult to split up: > > 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We >initialize it from DPCD on eDP 1.4 like before, but generate it based >on DP_MAX_LINK_RATE on others. This reduces code complexity when we >need to use the sink rates; they are all always in the sink_rates >array. > > 2) Update the sink rate array whenever we read DPCD, and use the >information from there. This increases code readability when we need >the sink rates. > > 3) Disentangle fallback rate limiting from sink rates. In the code, the >max rate is a dynamic property of the *link*, not of the *sink*. Do >the limiting after intersecting the source and sink rates, which are >static properties of the devices. > > This paves the way for follow-up refactoring that I've refrained from > doing here to keep this change as simple as it possibly can. > > v2: introduce use_rate_select and handle non-confirming eDP (Ville) > > v3: don't clobber cached eDP rates on short pulse (Ville) > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dp.c | 81 > ++- > drivers/gpu/drm/i915/intel_dp_link_training.c | 3 +- > drivers/gpu/drm/i915/intel_drv.h | 5 +- > 3 files changed, 61 insertions(+), 28 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index e9bd75ff3904..b38cba7d5abc 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -133,6 +133,34 @@ static void vlv_steal_power_sequencer(struct drm_device > *dev, > enum pipe pipe); > static void intel_dp_unset_edid(struct intel_dp *intel_dp); > > +static int intel_dp_num_rates(u8 link_bw_code) > +{ > + switch (link_bw_code) { > + default: > + WARN(1, "invalid max DP link bw val %x, using 1.62Gbps\n", > + link_bw_code); > + case DP_LINK_BW_1_62: > + return 1; > + case DP_LINK_BW_2_7: > + return 2; > + case DP_LINK_BW_5_4: > + return 3; > + } > +} > + > +/* update sink rates from dpcd */ > +static void intel_dp_set_sink_rates(struct intel_dp *intel_dp) > +{ > + int i, num_rates; > + > + num_rates = intel_dp_num_rates(intel_dp->dpcd[DP_MAX_LINK_RATE]); > + > + for (i = 0; i < num_rates; i++) > + intel_dp->sink_rates[i] = default_rates[i]; > + > + intel_dp->num_sink_rates = num_rates; > +} > + > static int > intel_dp_max_link_bw(struct intel_dp *intel_dp) > { > @@ -205,19 +233,6 @@ intel_dp_downstream_max_dotclock(struct intel_dp > *intel_dp) > return max_dotclk; > } > > -static int > -intel_dp_sink_rates(struct intel_dp *intel_dp, const int **sink_rates) > -{ > - if (intel_dp->num_sink_rates) { > - *sink_rates = intel_dp->sink_rates; > - return intel_dp->num_sink_rates; > - } > - > - *sink_rates = default_rates; > - > - return (intel_dp->max_sink_link_bw >> 3) + 1; > -} > - > static void > intel_dp_set_source_rates(struct intel_dp *intel_dp) > { > @@ -286,15 +301,22 @@ static int intel_dp_rate_index(const int *rates, int > len, int rate) > static int intel_dp_common_rates(struct intel_dp *intel_dp, >int *common_rates) > { > - const int *sink_rates; > - int sink_len; > + int max_rate = drm_dp_bw_code_to_link_rate(intel_dp->max_sink_link_bw); > + int i, common_len; > > - sink_len = intel_dp_sink_rates(intel_dp, _rates); > + common_len = intersect_rates(intel_dp->source_rates, > + intel_dp->num_source_rates, > + intel_dp->sink_rates, > + intel_dp->num_sink_rates, > + common_rates); > + > + /* Limit results by potentially reduced max rate */ > + for (i = 0; i < common_len; i++) { > + if (common_rates[common_len - i - 1] <= max_rate) > + return common_len - i; > + } > > - return intersect_rates(intel_dp->source_rates, > -intel_dp->num_source_rates, > -sink_rates, sink_len, > -common_rates); > + return 0; > } > > static int intel_dp_link_rate_index(struct intel_dp *intel_dp, > @@ -1498,8 +1520,7 @@ static void
Re: [Intel-gfx] [PATCH v3 04/14] drm/i915/dp: cache source rates at init
Reviewed-by:Manasi On Tue, Mar 28, 2017 at 05:59:04PM +0300, Jani Nikula wrote: > We need the source rates array so often that it makes sense to set it > once at init. This reduces function calls when we need the rates, making > the code easier to follow. > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dp.c | 35 +-- > drivers/gpu/drm/i915/intel_drv.h | 3 +++ > 2 files changed, 24 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 9fc066dda4e0..e9bd75ff3904 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -218,21 +218,25 @@ intel_dp_sink_rates(struct intel_dp *intel_dp, const > int **sink_rates) > return (intel_dp->max_sink_link_bw >> 3) + 1; > } > > -static int > -intel_dp_source_rates(struct intel_dp *intel_dp, const int **source_rates) > +static void > +intel_dp_set_source_rates(struct intel_dp *intel_dp) > { > struct intel_digital_port *dig_port = dp_to_dig_port(intel_dp); > struct drm_i915_private *dev_priv = to_i915(dig_port->base.base.dev); > + const int *source_rates; > int size; > > + /* This should only be done once */ > + WARN_ON(intel_dp->source_rates || intel_dp->num_source_rates); > + > if (IS_GEN9_LP(dev_priv)) { > - *source_rates = bxt_rates; > + source_rates = bxt_rates; > size = ARRAY_SIZE(bxt_rates); > } else if (IS_GEN9_BC(dev_priv)) { > - *source_rates = skl_rates; > + source_rates = skl_rates; > size = ARRAY_SIZE(skl_rates); > } else { > - *source_rates = default_rates; > + source_rates = default_rates; > size = ARRAY_SIZE(default_rates); > } > > @@ -240,7 +244,8 @@ intel_dp_source_rates(struct intel_dp *intel_dp, const > int **source_rates) > if (!intel_dp_source_supports_hbr2(intel_dp)) > size--; > > - return size; > + intel_dp->source_rates = source_rates; > + intel_dp->num_source_rates = size; > } > > static int intersect_rates(const int *source_rates, int source_len, > @@ -281,13 +286,13 @@ static int intel_dp_rate_index(const int *rates, int > len, int rate) > static int intel_dp_common_rates(struct intel_dp *intel_dp, >int *common_rates) > { > - const int *source_rates, *sink_rates; > - int source_len, sink_len; > + const int *sink_rates; > + int sink_len; > > sink_len = intel_dp_sink_rates(intel_dp, _rates); > - source_len = intel_dp_source_rates(intel_dp, _rates); > > - return intersect_rates(source_rates, source_len, > + return intersect_rates(intel_dp->source_rates, > +intel_dp->num_source_rates, > sink_rates, sink_len, > common_rates); > } > @@ -1493,16 +1498,16 @@ static void snprintf_int_array(char *str, size_t len, > > static void intel_dp_print_rates(struct intel_dp *intel_dp) > { > - const int *source_rates, *sink_rates; > - int source_len, sink_len, common_len; > + const int *sink_rates; > + int sink_len, common_len; > int common_rates[DP_MAX_SUPPORTED_RATES]; > char str[128]; /* FIXME: too big for stack? */ > > if ((drm_debug & DRM_UT_KMS) == 0) > return; > > - source_len = intel_dp_source_rates(intel_dp, _rates); > - snprintf_int_array(str, sizeof(str), source_rates, source_len); > + snprintf_int_array(str, sizeof(str), > +intel_dp->source_rates, intel_dp->num_source_rates); > DRM_DEBUG_KMS("source rates: %s\n", str); > > sink_len = intel_dp_sink_rates(intel_dp, _rates); > @@ -5943,6 +5948,8 @@ intel_dp_init_connector(struct intel_digital_port > *intel_dig_port, >intel_dig_port->max_lanes, port_name(port))) > return false; > > + intel_dp_set_source_rates(intel_dp); > + > intel_dp->reset_link_params = true; > intel_dp->pps_pipe = INVALID_PIPE; > intel_dp->active_pipe = INVALID_PIPE; > diff --git a/drivers/gpu/drm/i915/intel_drv.h > b/drivers/gpu/drm/i915/intel_drv.h > index e24641b559e2..f59574261dc6 100644 > --- a/drivers/gpu/drm/i915/intel_drv.h > +++ b/drivers/gpu/drm/i915/intel_drv.h > @@ -949,6 +949,9 @@ struct intel_dp { > uint8_t psr_dpcd[EDP_PSR_RECEIVER_CAP_SIZE]; > uint8_t downstream_ports[DP_MAX_DOWNSTREAM_PORTS]; > uint8_t edp_dpcd[EDP_DISPLAY_CTL_CAP_SIZE]; > + /* source rates */ > + int num_source_rates; > + const int *source_rates; > /* sink rates as reported by DP_SUPPORTED_LINK_RATES */ > uint8_t num_sink_rates; > int
[Intel-gfx] linux-next: build warning after merge of the drm-misc tree
Hi all, After merging the drm-misc tree, today's linux-next build (arm_multi_v7_defconfig) produced this warning: drivers/gpu/drm/bridge/synopsys/dw-hdmi.c:608:13: warning: 'hdmi_bus_fmt_is_yuv420' defined but not used [-Wunused-function] static bool hdmi_bus_fmt_is_yuv420(unsigned int bus_format) ^ Introduced by commit def23aa7e982 ("drm: bridge: dw-hdmi: Switch to V4L bus format and encodings") -- Cheers, Stephen Rothwell ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for Adding driver-private objects to atomic state (rev6)
On Tue, 2017-04-04 at 20:36 +, Patchwork wrote: > == Series Details == > > Series: Adding driver-private objects to atomic state (rev6) > URL : https://patchwork.freedesktop.org/series/22177/ > State : failure > I guess the in-reply-to confused CI. Here's the result for the same series sent to try-bot. https://lists.freedesktop.org/archives/intel-gfx-trybot/2017-April/017329.html -DK > == Summary == > > CC drivers/usb/host/xhci-dbg.o > CC net/ipv4/udp_diag.o > CC net/ipv4/tcp_cubic.o > CC net/ipv4/xfrm4_policy.o > CC drivers/usb/host/xhci-trace.o > CC drivers/usb/host/xhci-pci.o > CC net/ipv4/xfrm4_input.o > CC net/ipv4/xfrm4_state.o > CC net/ipv4/xfrm4_output.o > CC net/ipv4/xfrm4_protocol.o > LD drivers/video/backlight/built-in.o > LD drivers/mmc/core/mmc_core.o > LD drivers/mmc/host/built-in.o > LD drivers/nvme/host/nvme.o > LD drivers/nvme/host/built-in.o > LD drivers/nvme/built-in.o > LD drivers/pci/pcie/pcieportdrv.o > LD net/key/built-in.o > LD drivers/rtc/built-in.o > LD net/unix/unix.o > LD net/netlink/built-in.o > LD net/unix/built-in.o > LD lib/lz4/built-in.o > LD [M] drivers/ssb/ssb.o > LD [M] drivers/misc/mei/mei-me.o > LD drivers/md/dm-mod.o > LD drivers/misc/built-in.o > LD drivers/tty/serial/8250/8250.o > LD kernel/events/built-in.o > LD drivers/pci/pcie/aer/aerdriver.o > LD drivers/pci/pcie/aer/built-in.o > LD drivers/usb/storage/usb-storage.o > LD drivers/pci/pcie/built-in.o > LD drivers/usb/storage/built-in.o > LD drivers/mmc/core/mmc_block.o > LD drivers/mmc/core/built-in.o > LD drivers/mmc/built-in.o > LD [M] drivers/net/ethernet/broadcom/genet/genet.o > LD [M] drivers/usb/serial/usbserial.o > LD drivers/video/fbdev/core/fb.o > AR lib/lib.a > LD net/packet/built-in.o > LD drivers/video/fbdev/core/built-in.o > EXPORTS lib/lib-ksyms.o > LD kernel/sched/built-in.o > LD drivers/thermal/thermal_sys.o > LD drivers/thermal/built-in.o > LD lib/built-in.o > LD kernel/built-in.o > LD [M] sound/pci/hda/snd-hda-codec-generic.o > LD sound/pci/built-in.o > LD net/ipv6/ipv6.o > LD net/ipv6/built-in.o > LD drivers/iommu/built-in.o > LD drivers/tty/serial/8250/8250_base.o > LD drivers/tty/serial/8250/built-in.o > LD sound/built-in.o > LD drivers/tty/serial/built-in.o > LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o > LD drivers/usb/gadget/libcomposite.o > LD drivers/video/fbdev/built-in.o > LD drivers/usb/gadget/udc/udc-core.o > LD drivers/pci/built-in.o > LD drivers/usb/gadget/udc/built-in.o > LD drivers/usb/gadget/built-in.o > LD net/xfrm/built-in.o > LD drivers/video/console/built-in.o > LD drivers/video/built-in.o > LD drivers/scsi/scsi_mod.o > LD drivers/spi/built-in.o > LD drivers/scsi/sd_mod.o > LD drivers/scsi/built-in.o > LD drivers/usb/core/usbcore.o > LD drivers/usb/core/built-in.o > CC arch/x86/kernel/cpu/capflags.o > LD arch/x86/kernel/cpu/built-in.o > LD [M] drivers/net/ethernet/intel/e1000/e1000.o > LD arch/x86/kernel/built-in.o > LD drivers/tty/vt/built-in.o > LD fs/btrfs/btrfs.o > LD drivers/tty/built-in.o > LD arch/x86/built-in.o > LD fs/btrfs/built-in.o > LD net/ipv4/built-in.o > LD fs/ext4/ext4.o > LD fs/ext4/built-in.o > LD drivers/md/md-mod.o > LD drivers/md/built-in.o > LD fs/built-in.o > LD [M] drivers/net/ethernet/intel/igb/igb.o > LD net/core/built-in.o > LD drivers/usb/host/xhci-hcd.o > LD net/built-in.o > LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o > LD drivers/usb/host/built-in.o > LD drivers/usb/built-in.o > LD drivers/net/ethernet/built-in.o > LD drivers/net/built-in.o > Makefile:1002: recipe for target 'drivers' failed > make: *** [drivers] Error 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 16/18] drm/i915/debugfs: include some huge-page metrics
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_debugfs.c | 38 ++--- 1 file changed, 35 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index d689e511744e..e8a50481c703 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -117,6 +117,23 @@ static u64 i915_gem_obj_total_ggtt_size(struct drm_i915_gem_object *obj) return size; } +static const char *stringify_page_size(unsigned int page_size) +{ + switch(page_size) { + case I915_GTT_PAGE_SIZE_4K: + return "4K"; + case I915_GTT_PAGE_SIZE_64K: + return "64K"; + case I915_GTT_PAGE_SIZE_2M: + return "2M"; + case I915_GTT_PAGE_SIZE_1G: + return "1G"; + default: + MISSING_CASE(page_size); + return ""; + } +} + static void describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) { @@ -128,7 +145,7 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) lockdep_assert_held(>base.dev->struct_mutex); - seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %02x %02x %s%s%s", + seq_printf(m, "%pK: %c%c%c%c%c %8zdKiB %s %s %02x %02x %s%s%s", >base, get_active_flag(obj), get_pin_flag(obj), @@ -136,6 +153,8 @@ describe_obj(struct seq_file *m, struct drm_i915_gem_object *obj) get_global_flag(obj), get_pin_mapped_flag(obj), obj->base.size / 1024, + stringify_page_size(obj->page_size), + stringify_page_size(obj->gtt_page_size), obj->base.read_domains, obj->base.write_domain, i915_cache_level_str(dev_priv, obj->cache_level), @@ -399,8 +418,8 @@ static int i915_gem_object_info(struct seq_file *m, void *data) struct drm_i915_private *dev_priv = node_to_i915(m->private); struct drm_device *dev = _priv->drm; struct i915_ggtt *ggtt = _priv->ggtt; - u32 count, mapped_count, purgeable_count, dpy_count; - u64 size, mapped_size, purgeable_size, dpy_size; + u32 count, mapped_count, purgeable_count, dpy_count, huge_count; + u64 size, mapped_size, purgeable_size, dpy_size, huge_size; struct drm_i915_gem_object *obj; struct drm_file *file; int ret; @@ -416,6 +435,7 @@ static int i915_gem_object_info(struct seq_file *m, void *data) size = count = 0; mapped_size = mapped_count = 0; purgeable_size = purgeable_count = 0; + huge_size = huge_count = 0; list_for_each_entry(obj, _priv->mm.unbound_list, global_link) { size += obj->base.size; ++count; @@ -429,6 +449,11 @@ static int i915_gem_object_info(struct seq_file *m, void *data) mapped_count++; mapped_size += obj->base.size; } + + if (obj->page_size > PAGE_SIZE) { + huge_count++; + huge_size += obj->base.size; + } } seq_printf(m, "%u unbound objects, %llu bytes\n", count, size); @@ -451,6 +476,11 @@ static int i915_gem_object_info(struct seq_file *m, void *data) mapped_count++; mapped_size += obj->base.size; } + + if (obj->page_size > PAGE_SIZE) { + huge_count++; + huge_size += obj->base.size; + } } seq_printf(m, "%u bound objects, %llu bytes\n", count, size); @@ -458,6 +488,8 @@ static int i915_gem_object_info(struct seq_file *m, void *data) purgeable_count, purgeable_size); seq_printf(m, "%u mapped objects, %llu bytes\n", mapped_count, mapped_size); + seq_printf(m, "%u huge-paged objects, %llu bytes\n", + huge_count, huge_size); seq_printf(m, "%u display objects (pinned), %llu bytes\n", dpy_count, dpy_size); -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 18/18] drm/i915: support transparent-huge-pages through shmemfs
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_drv.h | 3 + drivers/gpu/drm/i915/i915_gem.c | 187 +--- drivers/gpu/drm/i915/i915_vma.c | 8 ++ 3 files changed, 166 insertions(+), 32 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index 838ce22a0a40..07dd4d24b93e 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -2672,6 +2672,9 @@ static inline struct scatterlist *__sg_next(struct scatterlist *sg) * @__pp: page pointer (output) * @__iter:'struct sgt_iter' (iterator state, internal) * @__sgt: sg_table to iterate over (input) + * + * Be warned, if we using huge-pages @_pp could be a part of a compound page, + * so care must be taken. Too thorny? */ #define for_each_sgt_page(__pp, __iter, __sgt) \ for ((__iter) = __sgt_iter((__sgt)->sgl, false);\ diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 5362f4d18689..1dde01676d37 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -171,7 +171,7 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj) struct sg_table *st; struct scatterlist *sg; char *vaddr; - int i; + int i, j; if (WARN_ON(i915_gem_object_needs_bit17_swizzle(obj))) return ERR_PTR(-EINVAL); @@ -187,7 +187,7 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj) return ERR_PTR(-ENOMEM); vaddr = phys->vaddr; - for (i = 0; i < obj->base.size / PAGE_SIZE; i++) { + for (i = 0; i < obj->base.size / PAGE_SIZE; ) { struct page *page; char *src; @@ -197,13 +197,15 @@ i915_gem_object_get_pages_phys(struct drm_i915_gem_object *obj) goto err_phys; } - src = kmap_atomic(page); - memcpy(vaddr, src, PAGE_SIZE); - drm_clflush_virt_range(vaddr, PAGE_SIZE); - kunmap_atomic(src); + for (j = 0; j < hpage_nr_pages(page); ++j, ++i) { + src = kmap_atomic(page + j); + memcpy(vaddr, src, PAGE_SIZE); + drm_clflush_virt_range(vaddr, PAGE_SIZE); + kunmap_atomic(src); + vaddr += PAGE_SIZE; + } put_page(page); - vaddr += PAGE_SIZE; } i915_gem_chipset_flush(to_i915(obj->base.dev)); @@ -263,9 +265,9 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj, if (obj->mm.dirty) { struct address_space *mapping = obj->base.filp->f_mapping; char *vaddr = obj->phys_handle->vaddr; - int i; + int i, j; - for (i = 0; i < obj->base.size / PAGE_SIZE; i++) { + for (i = 0; i < obj->base.size / PAGE_SIZE; ) { struct page *page; char *dst; @@ -273,16 +275,18 @@ i915_gem_object_put_pages_phys(struct drm_i915_gem_object *obj, if (IS_ERR(page)) continue; - dst = kmap_atomic(page); - drm_clflush_virt_range(vaddr, PAGE_SIZE); - memcpy(dst, vaddr, PAGE_SIZE); - kunmap_atomic(dst); + for (j = 0; j < hpage_nr_pages(page); ++j, ++i) { + dst = kmap_atomic(page + j); + drm_clflush_virt_range(vaddr, PAGE_SIZE); + memcpy(dst, vaddr, PAGE_SIZE); + kunmap_atomic(dst); + vaddr += PAGE_SIZE; + } set_page_dirty(page); if (obj->mm.madv == I915_MADV_WILLNEED) mark_page_accessed(page); put_page(page); - vaddr += PAGE_SIZE; } obj->mm.dirty = false; } @@ -2179,6 +2183,8 @@ i915_gem_object_put_pages_gtt(struct drm_i915_gem_object *obj, i915_gem_object_save_bit_17_swizzle(obj, pages); for_each_sgt_page(page, sgt_iter, pages) { + if (PageTail(page)) + continue; if (obj->mm.dirty) set_page_dirty(page); @@ -2272,6 +2278,15 @@ static bool i915_sg_trim(struct sg_table *orig_st) return true; } +static inline unsigned int i915_shmem_page_size(struct page *page) +{ +#ifdef CONFIG_TRANSPARENT_HUGE_PAGECACHE + return PageTransHuge(page) ? HPAGE_PMD_SIZE : PAGE_SIZE; +#else + return PAGE_SIZE; +#endif +} + static struct sg_table * i915_gem_object_get_pages_gtt(struct
[Intel-gfx] [PATCH 17/18] mm/shmem: tweak the huge-page interface
In its current form huge-pages through shmemfs are controlled at the super-block level, and are currently disabled by default, so to enable huge-pages for a shmem backed gem object we would need to re-mount the fs with the huge= argument, but for drm the mount is not user visible, so good luck with that. The other option is the global sysfs knob shmem_enabled which exposes the same huge= options, with the addition of DENY and FORCE. Neither option seems really workable, what we probably want is to able to control the use of huge-pages at the time of pinning the backing storage for a particular gem object, and only where it makes sense given the size of the object. One caveat is when we write into the page cache prior to pinning the backing storage. I played around with a bunch of ideas but in the end just settled with driver overridable huge option embedded in shmem_inode_info. Thoughts? Signed-off-by: Matthew Auld--- include/linux/shmem_fs.h | 1 + mm/shmem.c | 10 -- 2 files changed, 9 insertions(+), 2 deletions(-) diff --git a/include/linux/shmem_fs.h b/include/linux/shmem_fs.h index a7d6bd2a918f..001be751420d 100644 --- a/include/linux/shmem_fs.h +++ b/include/linux/shmem_fs.h @@ -21,6 +21,7 @@ struct shmem_inode_info { struct shared_policypolicy; /* NUMA memory alloc policy */ struct simple_xattrsxattrs; /* list of xattrs */ struct inodevfs_inode; + boolhuge; /* driver override shmem_huge */ }; struct shmem_sb_info { diff --git a/mm/shmem.c b/mm/shmem.c index e67d6ba4e98e..879a9e514afe 100644 --- a/mm/shmem.c +++ b/mm/shmem.c @@ -1723,6 +1723,9 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index, /* shmem_symlink() */ if (mapping->a_ops != _aops) goto alloc_nohuge; + /* driver override shmem_huge */ + if (info->huge) + goto alloc_huge; if (shmem_huge == SHMEM_HUGE_DENY || sgp_huge == SGP_NOHUGE) goto alloc_nohuge; if (shmem_huge == SHMEM_HUGE_FORCE) @@ -2000,6 +2003,7 @@ unsigned long shmem_get_unmapped_area(struct file *file, unsigned long inflated_len; unsigned long inflated_addr; unsigned long inflated_offset; + struct shmem_inode_info *info = SHMEM_I(file_inode(file)); if (len > TASK_SIZE) return -ENOMEM; @@ -2016,7 +2020,7 @@ unsigned long shmem_get_unmapped_area(struct file *file, if (addr > TASK_SIZE - len) return addr; - if (shmem_huge == SHMEM_HUGE_DENY) + if (!info->huge && shmem_huge == SHMEM_HUGE_DENY) return addr; if (len < HPAGE_PMD_SIZE) return addr; @@ -2030,7 +2034,7 @@ unsigned long shmem_get_unmapped_area(struct file *file, if (uaddr) return addr; - if (shmem_huge != SHMEM_HUGE_FORCE) { + if (!info->huge && shmem_huge != SHMEM_HUGE_FORCE) { struct super_block *sb; if (file) { @@ -4034,6 +4038,8 @@ bool shmem_huge_enabled(struct vm_area_struct *vma) loff_t i_size; pgoff_t off; + if (SHMEM_I(inode)->huge) + return true; if (shmem_huge == SHMEM_HUGE_FORCE) return true; if (shmem_huge == SHMEM_HUGE_DENY) -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 15/18] drm/i915/selftests: exercise evict-for-node page coloring
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 117 ++-- 1 file changed, 111 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c index 8c0b4dc9de3d..780585a202ba 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_evict.c @@ -25,6 +25,7 @@ #include "../i915_selftest.h" #include "mock_gem_device.h" +#include "mock_gtt.h" static int populate_ggtt(struct drm_i915_private *i915) { @@ -62,11 +63,11 @@ static int populate_ggtt(struct drm_i915_private *i915) return 0; } -static void unpin_ggtt(struct drm_i915_private *i915) +static void unpin_vm(struct i915_address_space *vm) { struct i915_vma *vma; - list_for_each_entry(vma, >ggtt.base.inactive_list, vm_link) + list_for_each_entry(vma, >inactive_list, vm_link) i915_vma_unpin(vma); } @@ -110,7 +111,7 @@ static int igt_evict_something(void *arg) goto cleanup; } - unpin_ggtt(i915); + unpin_vm(>base); /* Everything is unpinned, we should be able to evict something */ err = i915_gem_evict_something(>base, @@ -187,7 +188,7 @@ static int igt_evict_for_vma(void *arg) goto cleanup; } - unpin_ggtt(i915); + unpin_vm(>base); /* Everything is unpinned, we should be able to evict the node */ err = i915_gem_evict_for_node(>base, , 0); @@ -287,12 +288,115 @@ static int igt_evict_for_cache_color(void *arg) err = 0; cleanup: - unpin_ggtt(i915); + unpin_vm(>base); cleanup_objects(i915); ggtt->base.mm.color_adjust = NULL; return err; } +static int igt_evict_for_page_color(void *arg) +{ + struct drm_i915_private *i915 = arg; + struct i915_hw_ppgtt *ppgtt = mock_ppgtt(i915, "mock-page-color"); + const unsigned long flags = PIN_USER | PIN_OFFSET_FIXED; + struct drm_mm_node target = { + /* Straddle the end of the first page-table boundary */ + .start = (1 << GEN8_PDE_SHIFT) - I915_GTT_PAGE_SIZE_64K, + .size = I915_GTT_PAGE_SIZE_64K * 2, + .color = I915_GTT_PAGE_SIZE_4K, + }; + struct drm_i915_gem_object *obj; + struct i915_vma *vma; + int err; + + /* The mock ppgtt mm.color_adjust should be set to +* i915_page_color_adjust. +*/ + GEM_BUG_ON(!i915_vm_has_page_coloring(>base)); + + obj = i915_gem_object_create_internal(i915, I915_GTT_PAGE_SIZE); + if (IS_ERR(obj)) { + err = PTR_ERR(obj); + goto cleanup; + } + + vma = i915_vma_instance(obj, >base, NULL); + if (IS_ERR(vma)) { + pr_err("[0]i915_vma_instance failed\n"); + err = PTR_ERR(vma); + goto cleanup; + } + + err = i915_vma_pin(vma, 0, 0, flags); + if (err) { + pr_err("[0]i915_vma_pin failed with err=%d\n", err); + goto cleanup; + } + + obj = i915_gem_object_create_internal(i915, I915_GTT_PAGE_SIZE); + if (IS_ERR(obj)) { + unpin_vm(>base); + err = PTR_ERR(obj); + goto cleanup; + } + + vma = i915_vma_instance(obj, >base, NULL); + if (IS_ERR(vma)) { + pr_err("[1]i915_vma_instance failed\n"); + err = PTR_ERR(vma); + goto cleanup; + } + + err = i915_vma_pin(vma, 0, 0, + ((2 << GEN8_PDE_SHIFT) - I915_GTT_PAGE_SIZE_4K) | + flags); + if (err) { + unpin_vm(>base); + pr_err("[1]i915_vma_pin failed with err=%d\n", err); + goto cleanup; + } + + /* Target the page-table boundary between the two already *pinned* gem +* objects with the same page color - should succeed. +*/ + err = i915_gem_evict_for_node(>base, , 0); + if (err) { + unpin_vm(>base); + pr_err("[0]i915_gem_evict_for_node returned err=%d\n", err); + goto cleanup; + } + + target.color = I915_GTT_PAGE_SIZE_64K; + + /* Again target the page-table boundary between the two already *pinned* +* gem objects, but this time with conflicting page colors - should +* fail. +*/ + err = i915_gem_evict_for_node(>base, , 0); + if (!err) { + unpin_vm(>base); + pr_err("[1]i915_gem_evict_for_node returned err=%d\n", err); + err = -EINVAL; + goto cleanup; + } + + unpin_vm(>base); + + /* And finaly target the page-table boundary between the two now +* *unpinned* gem objects, again with conflicting page colors - should +* now succeed. +*/
[Intel-gfx] [PATCH 14/18] drm/i915/selftests: modify the gtt tests to also exercise huge pages
v2: s/roundup/round_up s/rounddown/round_down Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 123 ++ drivers/gpu/drm/i915/selftests/mock_gtt.c | 3 + 2 files changed, 89 insertions(+), 37 deletions(-) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index 0963dcb67996..e735de3d9975 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -92,12 +92,14 @@ static const struct drm_i915_gem_object_ops fake_ops = { }; static struct drm_i915_gem_object * -fake_dma_object(struct drm_i915_private *i915, u64 size) +fake_dma_object(struct drm_i915_private *i915, u64 size, unsigned int page_size) { struct drm_i915_gem_object *obj; GEM_BUG_ON(!size); - GEM_BUG_ON(!IS_ALIGNED(size, I915_GTT_PAGE_SIZE)); + GEM_BUG_ON(!is_valid_gtt_page_size(page_size)); + + size = round_up(size, page_size); if (overflows_type(size, obj->base.size)) return ERR_PTR(-E2BIG); @@ -107,8 +109,13 @@ fake_dma_object(struct drm_i915_private *i915, u64 size) goto err; drm_gem_private_object_init(>drm, >base, size); + i915_gem_object_init(obj, _ops); + obj->gtt_page_size = obj->page_size = page_size; + + GEM_BUG_ON(!IS_ALIGNED(obj->base.size, obj->page_size)); + obj->base.write_domain = I915_GEM_DOMAIN_CPU; obj->base.read_domains = I915_GEM_DOMAIN_CPU; obj->cache_level = I915_CACHE_NONE; @@ -194,13 +201,14 @@ static int igt_ppgtt_alloc(void *arg) static int lowlevel_hole(struct drm_i915_private *i915, struct i915_address_space *vm, u64 hole_start, u64 hole_end, +unsigned int page_size, unsigned long end_time) { I915_RND_STATE(seed_prng); unsigned int size; /* Keep creating larger objects until one cannot fit into the hole */ - for (size = 12; (hole_end - hole_start) >> size; size++) { + for (size = ilog2(page_size); (hole_end - hole_start) >> size; size++) { I915_RND_SUBSTATE(prng, seed_prng); struct drm_i915_gem_object *obj; unsigned int *order, count, n; @@ -226,7 +234,7 @@ static int lowlevel_hole(struct drm_i915_private *i915, * memory. We expect to hit -ENOMEM. */ - obj = fake_dma_object(i915, BIT_ULL(size)); + obj = fake_dma_object(i915, BIT_ULL(size), page_size); if (IS_ERR(obj)) { kfree(order); break; @@ -303,18 +311,25 @@ static void close_object_list(struct list_head *objects, static int fill_hole(struct drm_i915_private *i915, struct i915_address_space *vm, u64 hole_start, u64 hole_end, +unsigned int page_size, unsigned long end_time) { const u64 hole_size = hole_end - hole_start; struct drm_i915_gem_object *obj; - const unsigned long max_pages = - min_t(u64, ULONG_MAX - 1, hole_size/2 >> PAGE_SHIFT); - const unsigned long max_step = max(int_sqrt(max_pages), 2UL); - unsigned long npages, prime, flags; + const unsigned page_shift = ilog2(page_size); + unsigned long max_pages, max_step, npages, prime, flags; struct i915_vma *vma; LIST_HEAD(objects); int err; + hole_start = round_up(hole_start, page_size); + hole_end = round_down(hole_end, page_size); + + GEM_BUG_ON(hole_start >= hole_end); + + max_pages = min_t(u64, ULONG_MAX - 1, hole_size/2 >> page_shift); + max_step = max(int_sqrt(max_pages), 2UL); + /* Try binding many VMA working inwards from either edge */ flags = PIN_OFFSET_FIXED | PIN_USER; @@ -323,7 +338,7 @@ static int fill_hole(struct drm_i915_private *i915, for_each_prime_number_from(prime, 2, max_step) { for (npages = 1; npages <= max_pages; npages *= prime) { - const u64 full_size = npages << PAGE_SHIFT; + const u64 full_size = npages << page_shift; const struct { const char *name; u64 offset; @@ -334,7 +349,7 @@ static int fill_hole(struct drm_i915_private *i915, { } }, *p; - obj = fake_dma_object(i915, full_size); + obj = fake_dma_object(i915, full_size, page_size); if (IS_ERR(obj)) break; @@ -359,7 +374,7 @@ static int fill_hole(struct drm_i915_private *i915, offset -= obj->base.size;
[Intel-gfx] [PATCH 08/18] drm/i915: handle evict-for-node with page coloring
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_evict.c | 24 1 file changed, 24 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c index 0c9c51be0f6a..817acff2fb6c 100644 --- a/drivers/gpu/drm/i915/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/i915_gem_evict.c @@ -276,6 +276,30 @@ int i915_gem_evict_for_node(struct i915_address_space *vm, /* Always look at the page afterwards to avoid the end-of-GTT */ end += I915_GTT_PAGE_SIZE; + } else if (i915_vm_has_page_coloring(vm)) { + u64 pt_start, pt_end; + + GEM_BUG_ON(!is_valid_gtt_page_size(target->color)); + GEM_BUG_ON(!IS_ALIGNED(start, target->color)); + GEM_BUG_ON(!IS_ALIGNED(end, target->color)); + + /* We need to consider the page table coloring on both sides of +* the range, where a mismatch would require extending our +* range to evict nodes up to the page table boundry for each +* side to ensure the underlying page table(s) for the range +* match the target color. +*/ + pt_start = rounddown(start, 1 << GEN8_PDE_SHIFT); + node = __drm_mm_interval_first(>mm, pt_start, start); + if (i915_node_color_differs(node, target->color)) { + start = pt_start; + } + + pt_end = roundup(start, 1 << GEN8_PDE_SHIFT); + node = __drm_mm_interval_first(>mm, end, pt_end); + if (i915_node_color_differs(node, target->color)) { + end = pt_end; + } } GEM_BUG_ON(start >= end); -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 06/18] drm/i915: export color_differs
Export color_differs so that we can use it elsewhere. v2: better naming Signed-off-by: Matthew AuldCc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_vma.c | 11 --- drivers/gpu/drm/i915/i915_vma.h | 6 ++ 2 files changed, 10 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 4ead7d075fd3..8f0041ba328f 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -373,11 +373,6 @@ void __i915_vma_set_map_and_fenceable(struct i915_vma *vma) vma->flags &= ~I915_VMA_CAN_FENCE; } -static bool color_differs(struct drm_mm_node *node, unsigned long color) -{ - return node->allocated && node->color != color; -} - bool i915_gem_valid_gtt_space(struct i915_vma *vma, unsigned long cache_level) { struct drm_mm_node *node = >node; @@ -398,11 +393,13 @@ bool i915_gem_valid_gtt_space(struct i915_vma *vma, unsigned long cache_level) GEM_BUG_ON(list_empty(>node_list)); other = list_prev_entry(node, node_list); - if (color_differs(other, cache_level) && !drm_mm_hole_follows(other)) + if (i915_node_color_differs(other, cache_level) && + !drm_mm_hole_follows(other)) return false; other = list_next_entry(node, node_list); - if (color_differs(other, cache_level) && !drm_mm_hole_follows(node)) + if (i915_node_color_differs(other, cache_level) && + !drm_mm_hole_follows(node)) return false; return true; diff --git a/drivers/gpu/drm/i915/i915_vma.h b/drivers/gpu/drm/i915/i915_vma.h index 2e03f81dddbe..6c95926f896f 100644 --- a/drivers/gpu/drm/i915/i915_vma.h +++ b/drivers/gpu/drm/i915/i915_vma.h @@ -284,6 +284,12 @@ static inline void i915_vma_unpin(struct i915_vma *vma) __i915_vma_unpin(vma); } +static inline bool i915_node_color_differs(const struct drm_mm_node *node, + unsigned long color) +{ + return node->allocated && node->color != color; +} + /** * i915_vma_pin_iomap - calls ioremap_wc to map the GGTT VMA via the aperture * @vma: VMA to iomap -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 13/18] drm/i915/selftests: exercise 4K and 64K mm insertion
Mock test filling an address space with 4K and 64K objects, in the hope of exercising the page color adjust fun. v2: s/roundup/round_up Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 68 +++ 1 file changed, 68 insertions(+) diff --git a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c index 259b5e139df1..0963dcb67996 100644 --- a/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/selftests/i915_gem_gtt.c @@ -31,6 +31,7 @@ #include "mock_context.h" #include "mock_drm.h" #include "mock_gem_device.h" +#include "mock_gtt.h" static void fake_free_pages(struct drm_i915_gem_object *obj, struct sg_table *pages) @@ -1307,6 +1308,72 @@ static int igt_gtt_reserve(void *arg) return err; } +static int igt_ppgtt_page_color(void *arg) +{ + struct drm_mm mm; + struct drm_mm_node *node, *prev, *next; + unsigned long page_colors[] = { + I915_GTT_PAGE_SIZE, + I915_GTT_PAGE_SIZE_64K, + }; + int idx = 0; + u64 count = 0; + u64 size; + + drm_mm_init(, 0, U64_MAX); + mm.color_adjust = i915_page_color_adjust; + + /* Running out of memory is okay. */ + + for_each_prime_number_from(size, 0, U64_MAX) { + node = kzalloc(sizeof(*node), GFP_KERNEL); + if (!node) { + pr_info("finished test early, unable to allocate node, count=%llu\n", count); + break; + } + + size = round_up(size, page_colors[idx]); + + if (drm_mm_insert_node_in_range(, node, size, + page_colors[idx], + page_colors[idx], + 0, U64_MAX, + DRM_MM_INSERT_BEST)) { + pr_info("test finished, unable to insert node: color=%lu, size=%llx, count=%llu\n", + page_colors[idx], size, count); + kfree(node); + break; + } + + GEM_BUG_ON(!IS_ALIGNED(node->start, node->color)); + GEM_BUG_ON(!IS_ALIGNED(node->size, node->color)); + + /* We can't mix 4K and 64K pte's in the same pt. */ + + prev = list_prev_entry(node, node_list); + if (i915_node_color_differs(prev, node->color)) + GEM_BUG_ON(prev->start >> GEN8_PDE_SHIFT == + node->start >> GEN8_PDE_SHIFT); + + next = list_next_entry(node, node_list); + if (i915_node_color_differs(next, node->color)) + GEM_BUG_ON(((next->start + next->size) >> GEN8_PDE_SHIFT) == + ((node->start + node->size) >> GEN8_PDE_SHIFT)); + + idx ^= 1; + ++count; + } + + drm_mm_for_each_node_safe(node, next, ) { + drm_mm_remove_node(node); + kfree(node); + } + + drm_mm_takedown(); + + return 0; +} + static int igt_gtt_insert(void *arg) { struct drm_i915_private *i915 = arg; @@ -1523,6 +1590,7 @@ int i915_gem_gtt_mock_selftests(void) SUBTEST(igt_mock_fill), SUBTEST(igt_gtt_reserve), SUBTEST(igt_gtt_insert), + SUBTEST(igt_ppgtt_page_color), }; struct drm_i915_private *i915; int err; -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 05/18] drm/i915: clean up cache coloring
Rid the code of any mm.color_adjust assumptions to allow adding another flavour of coloring. v2: better naming Signed-off-by: Matthew AuldCc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/i915_gem.c | 3 ++- drivers/gpu/drm/i915/i915_gem_evict.c | 12 +--- drivers/gpu/drm/i915/i915_gem_gtt.h | 6 ++ drivers/gpu/drm/i915/i915_vma.c | 10 +++--- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 8 +--- 6 files changed, 26 insertions(+), 15 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index ab7a1072e7b5..838ce22a0a40 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -3543,7 +3543,7 @@ int i915_perf_open_ioctl(struct drm_device *dev, void *data, /* i915_gem_evict.c */ int __must_check i915_gem_evict_something(struct i915_address_space *vm, u64 min_size, u64 alignment, - unsigned cache_level, + unsigned long color, u64 start, u64 end, unsigned flags); int __must_check i915_gem_evict_for_node(struct i915_address_space *vm, diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index cbf97f4bbb72..5362f4d18689 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -3578,7 +3578,8 @@ int i915_gem_object_set_cache_level(struct drm_i915_gem_object *obj, obj->cache_dirty = true; list_for_each_entry(vma, >vma_list, obj_link) - vma->node.color = cache_level; + if (i915_vm_has_cache_coloring(vma->vm)) + vma->node.color = cache_level; obj->cache_level = cache_level; return 0; diff --git a/drivers/gpu/drm/i915/i915_gem_evict.c b/drivers/gpu/drm/i915/i915_gem_evict.c index 51e365f70464..0c9c51be0f6a 100644 --- a/drivers/gpu/drm/i915/i915_gem_evict.c +++ b/drivers/gpu/drm/i915/i915_gem_evict.c @@ -74,7 +74,7 @@ mark_free(struct drm_mm_scan *scan, * @vm: address space to evict from * @min_size: size of the desired free space * @alignment: alignment constraint of the desired free space - * @cache_level: cache_level for the desired space + * @color: color for the desired space * @start: start (inclusive) of the range from which to evict objects * @end: end (exclusive) of the range from which to evict objects * @flags: additional flags to control the eviction algorithm @@ -95,7 +95,7 @@ mark_free(struct drm_mm_scan *scan, int i915_gem_evict_something(struct i915_address_space *vm, u64 min_size, u64 alignment, -unsigned cache_level, +unsigned long color, u64 start, u64 end, unsigned flags) { @@ -134,7 +134,7 @@ i915_gem_evict_something(struct i915_address_space *vm, if (flags & PIN_MAPPABLE) mode = DRM_MM_INSERT_LOW; drm_mm_scan_init_with_range(, >mm, - min_size, alignment, cache_level, + min_size, alignment, color, start, end, mode); /* Retire before we search the active list. Although we have @@ -253,7 +253,6 @@ int i915_gem_evict_for_node(struct i915_address_space *vm, u64 start = target->start; u64 end = start + target->size; struct i915_vma *vma, *next; - bool check_color; int ret = 0; lockdep_assert_held(>i915->drm.struct_mutex); @@ -270,8 +269,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm, if (!(flags & PIN_NONBLOCK)) i915_gem_retire_requests(vm->i915); - check_color = vm->mm.color_adjust; - if (check_color) { + if (i915_vm_has_cache_coloring(vm)) { /* Expand search to cover neighbouring guard pages (or lack!) */ if (start) start -= I915_GTT_PAGE_SIZE; @@ -297,7 +295,7 @@ int i915_gem_evict_for_node(struct i915_address_space *vm, * abutt and conflict. If they are in conflict, then we evict * those as well to make room for our guard pages. */ - if (check_color) { + if (i915_vm_has_cache_coloring(vm)) { if (node->start + node->size == target->start) { if (node->color == target->color) continue; diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 232f7ef4c21b..9c592e2de516 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++
[Intel-gfx] [PATCH 12/18] drm/i915: disable GTT cache for huge-pages
As hinted by the comment and from actually testing 2M pages on a BDW machine with the GTT cache enabled, we are definitely going to need keep it disabled. Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/intel_pm.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c index 570bd603f401..2bb49bada4ea 100644 --- a/drivers/gpu/drm/i915/intel_pm.c +++ b/drivers/gpu/drm/i915/intel_pm.c @@ -7544,10 +7544,10 @@ static void broadwell_init_clock_gating(struct drm_i915_private *dev_priv) /* * WaGttCachingOffByDefault:bdw -* GTT cache may not work with big pages, so if those -* are ever enabled GTT cache may need to be disabled. +* The GTT cache must be disabled if the system is planning to use +* 2M/1G pages. */ - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL); + I915_WRITE(HSW_GTT_CACHE_EN, 0); /* WaKVMNotificationOnConfigChange:bdw */ I915_WRITE(CHICKEN_PAR2_1, I915_READ(CHICKEN_PAR2_1) @@ -7823,10 +7823,10 @@ static void cherryview_init_clock_gating(struct drm_i915_private *dev_priv) gen8_set_l3sqc_credits(dev_priv, 38, 2); /* -* GTT cache may not work with big pages, so if those -* are ever enabled GTT cache may need to be disabled. +* The GTT cache must be disabled if the system is planning to use +* 2M/1G pages. */ - I915_WRITE(HSW_GTT_CACHE_EN, GTT_CACHE_EN_ALL); + I915_WRITE(HSW_GTT_CACHE_EN, 0); } static void g4x_init_clock_gating(struct drm_i915_private *dev_priv) -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 04/18] drm/i915: s/i915_gtt_color_adjust/i915_ggtt_color_adjust
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_gtt.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0c8350f709da..0989af4a17e4 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -2395,10 +2395,10 @@ void i915_gem_gtt_finish_pages(struct drm_i915_gem_object *obj, dma_unmap_sg(kdev, pages->sgl, pages->nents, PCI_DMA_BIDIRECTIONAL); } -static void i915_gtt_color_adjust(const struct drm_mm_node *node, - unsigned long color, - u64 *start, - u64 *end) +static void i915_ggtt_color_adjust(const struct drm_mm_node *node, + unsigned long color, + u64 *start, + u64 *end) { if (node->allocated && node->color != color) *start += I915_GTT_PAGE_SIZE; @@ -2970,7 +2970,7 @@ int i915_ggtt_init_hw(struct drm_i915_private *dev_priv) mutex_lock(_priv->drm.struct_mutex); i915_address_space_init(>base, dev_priv, "[global]"); if (!HAS_LLC(dev_priv) && !USES_PPGTT(dev_priv)) - ggtt->base.mm.color_adjust = i915_gtt_color_adjust; + ggtt->base.mm.color_adjust = i915_ggtt_color_adjust; mutex_unlock(_priv->drm.struct_mutex); if (!io_mapping_init_wc(_priv->ggtt.mappable, -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 01/18] drm/i915: add page_size_mask to dev_info
v2: - move out pde/pdpe bit definitions until later - tidyup the page size definitions, use BIT - introduce helper for detecting invalid page sizes Signed-off-by: Matthew AuldCc: Mika Kuoppala Cc: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 3 +++ drivers/gpu/drm/i915/i915_gem_gtt.h | 17 - drivers/gpu/drm/i915/i915_pci.c | 23 ++- 3 files changed, 41 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h index c9b0949f6c1a..ab7a1072e7b5 100644 --- a/drivers/gpu/drm/i915/i915_drv.h +++ b/drivers/gpu/drm/i915/i915_drv.h @@ -901,6 +901,7 @@ struct intel_device_info { enum intel_platform platform; u8 ring_mask; /* Rings supported by the HW */ u8 num_rings; + unsigned int page_size_mask; /* page sizes supported by the HW */ #define DEFINE_FLAG(name) u8 name:1 DEV_INFO_FOR_EACH_FLAG(DEFINE_FLAG); #undef DEFINE_FLAG @@ -2876,6 +2877,8 @@ intel_info(const struct drm_i915_private *dev_priv) #define USES_PPGTT(dev_priv) (i915.enable_ppgtt) #define USES_FULL_PPGTT(dev_priv) (i915.enable_ppgtt >= 2) #define USES_FULL_48BIT_PPGTT(dev_priv)(i915.enable_ppgtt == 3) +#define SUPPORTS_PAGE_SIZE(dev_priv, page_size) \ + ((dev_priv)->info.page_size_mask & (page_size)) #define HAS_OVERLAY(dev_priv) ((dev_priv)->info.has_overlay) #define OVERLAY_NEEDS_PHYSICAL(dev_priv) \ diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index fb15684c1d83..27b2b9e681db 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -42,7 +42,22 @@ #include "i915_gem_request.h" #include "i915_selftest.h" -#define I915_GTT_PAGE_SIZE 4096UL +#define I915_GTT_PAGE_SIZE_4K BIT(12) +#define I915_GTT_PAGE_SIZE_64K BIT(16) +#define I915_GTT_PAGE_SIZE_2M BIT(21) +#define I915_GTT_PAGE_SIZE_1G BIT(30) + +#define I915_GTT_PAGE_SIZE I915_GTT_PAGE_SIZE_4K + +#define I915_GTT_PAGE_SIZE_MASK (I915_GTT_PAGE_SIZE_4K | \ +I915_GTT_PAGE_SIZE_64K | \ +I915_GTT_PAGE_SIZE_2M | \ +I915_GTT_PAGE_SIZE_1G) + +#define is_valid_gtt_page_size(page_size) \ + (is_power_of_2(page_size) && \ +(page_size) & I915_GTT_PAGE_SIZE_MASK) + #define I915_GTT_MIN_ALIGNMENT I915_GTT_PAGE_SIZE #define I915_FENCE_REG_NONE -1 diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c index f87b0c4e564d..25de64dfe732 100644 --- a/drivers/gpu/drm/i915/i915_pci.c +++ b/drivers/gpu/drm/i915/i915_pci.c @@ -56,6 +56,10 @@ .color = { .degamma_lut_size = 65, .gamma_lut_size = 257 } /* Keep in gen based order, and chronological order within a gen */ + +#define GEN_DEFAULT_PAGE_SZ \ + .page_size_mask = I915_GTT_PAGE_SIZE_4K + #define GEN2_FEATURES \ .gen = 2, .num_pipes = 1, \ .has_overlay = 1, .overlay_needs_physical = 1, \ @@ -64,6 +68,7 @@ .unfenced_needs_alignment = 1, \ .ring_mask = RENDER_RING, \ GEN_DEFAULT_PIPEOFFSETS, \ + GEN_DEFAULT_PAGE_SZ, \ CURSOR_OFFSETS static const struct intel_device_info intel_i830_info = { @@ -96,6 +101,7 @@ static const struct intel_device_info intel_i865g_info = { .has_gmch_display = 1, \ .ring_mask = RENDER_RING, \ GEN_DEFAULT_PIPEOFFSETS, \ + GEN_DEFAULT_PAGE_SZ, \ CURSOR_OFFSETS static const struct intel_device_info intel_i915g_info = { @@ -158,6 +164,7 @@ static const struct intel_device_info intel_pineview_info = { .has_gmch_display = 1, \ .ring_mask = RENDER_RING, \ GEN_DEFAULT_PIPEOFFSETS, \ + GEN_DEFAULT_PAGE_SZ, \ CURSOR_OFFSETS static const struct intel_device_info intel_i965g_info = { @@ -198,6 +205,7 @@ static const struct intel_device_info intel_gm45_info = { .has_gmbus_irq = 1, \ .ring_mask = RENDER_RING | BSD_RING, \ GEN_DEFAULT_PIPEOFFSETS, \ + GEN_DEFAULT_PAGE_SZ, \ CURSOR_OFFSETS static const struct intel_device_info intel_ironlake_d_info = { @@ -223,6 +231,7 @@ static const struct intel_device_info intel_ironlake_m_info = { .has_hw_contexts = 1, \ .has_aliasing_ppgtt = 1, \ GEN_DEFAULT_PIPEOFFSETS, \ + GEN_DEFAULT_PAGE_SZ, \ CURSOR_OFFSETS static const struct intel_device_info intel_sandybridge_d_info = { @@ -249,6 +258,7 @@ static const struct intel_device_info intel_sandybridge_m_info = { .has_aliasing_ppgtt = 1, \ .has_full_ppgtt = 1, \ GEN_DEFAULT_PIPEOFFSETS, \ + GEN_DEFAULT_PAGE_SZ, \ IVB_CURSOR_OFFSETS static const struct intel_device_info intel_ivybridge_d_info = { @@ -287,6 +297,7 @@ static const struct intel_device_info intel_valleyview_info = { .has_full_ppgtt
[Intel-gfx] [PATCH 11/18] drm/i915: support inserting 1G pages in the ppgtt
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_gtt.c | 45 + drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ 2 files changed, 47 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 9dc12955f557..5269092ba048 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -848,6 +848,48 @@ static __always_inline struct gen8_insert_pte gen8_insert_pte(u64 start) } static __always_inline bool +gen8_ppgtt_insert_1G_pdpe_entries(struct i915_hw_ppgtt *ppgtt, + struct i915_page_directory_pointer *pdp, + struct sgt_dma *iter, + struct gen8_insert_pte *idx, + enum i915_cache_level cache_level) +{ + const gen8_pte_t pdpe_encode = gen8_pte_encode(GEN8_PDPE_PS_1G, + cache_level); + gen8_pte_t *vaddr; + bool ret; + + GEM_BUG_ON(idx->pte); + GEM_BUG_ON(idx->pde); + GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(>base)); + vaddr = kmap_atomic_px(pdp); + do { + vaddr[idx->pdpe] = pdpe_encode | iter->dma; + iter->dma += I915_GTT_PAGE_SIZE_1G; + if (iter->dma >= iter->max) { + iter->sg = __sg_next(iter->sg); + if (!iter->sg) { + ret = false; + break; + } + + iter->dma = sg_dma_address(iter->sg); + iter->max = iter->dma + iter->sg->length; + } + + if (++idx->pdpe == GEN8_PML4ES_PER_PML4) { + idx->pdpe = 0; + ret = true; + break; + } + + } while (1); + kunmap_atomic(vaddr); + + return ret; +} + +static __always_inline bool gen8_ppgtt_insert_2M_pde_entries(struct i915_hw_ppgtt *ppgtt, struct i915_page_directory_pointer *pdp, struct sgt_dma *iter, @@ -1071,6 +1113,9 @@ static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm, case I915_GTT_PAGE_SIZE_2M: insert_entries = gen8_ppgtt_insert_2M_pde_entries; break; + case I915_GTT_PAGE_SIZE_1G: + insert_entries = gen8_ppgtt_insert_1G_pdpe_entries; + break; default: MISSING_CASE(page_size); return; diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index cfe31db6b400..8b970e9e764c 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -161,6 +161,8 @@ typedef u64 gen8_ppgtt_pml4e_t; #define GEN8_PDE_IPS_64K BIT(11) #define GEN8_PDE_PS_2M BIT(7) +#define GEN8_PDPE_PS_1G BIT(7) + struct sg_table; struct intel_rotation_info { -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 10/18] drm/i915: support inserting 2M pages in the ppgtt
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_gtt.c | 53 + drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + 2 files changed, 54 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index fb822c0bd973..9dc12955f557 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -848,6 +848,56 @@ static __always_inline struct gen8_insert_pte gen8_insert_pte(u64 start) } static __always_inline bool +gen8_ppgtt_insert_2M_pde_entries(struct i915_hw_ppgtt *ppgtt, +struct i915_page_directory_pointer *pdp, +struct sgt_dma *iter, +struct gen8_insert_pte *idx, +enum i915_cache_level cache_level) +{ + const gen8_pte_t pde_encode = gen8_pte_encode(GEN8_PDE_PS_2M, + cache_level); + gen8_pte_t *vaddr; + bool ret; + + GEM_BUG_ON(idx->pte); + GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(>base)); + vaddr = kmap_atomic_px(pdp->page_directory[idx->pdpe]); + do { + vaddr[idx->pde] = pde_encode | iter->dma; + iter->dma += I915_GTT_PAGE_SIZE_2M; + if (iter->dma >= iter->max) { + iter->sg = __sg_next(iter->sg); + if (!iter->sg) { + ret = false; + break; + } + + iter->dma = sg_dma_address(iter->sg); + iter->max = iter->dma + iter->sg->length; + } + + if (++idx->pde == I915_PDES) { + idx->pde = 0; + + if (++idx->pdpe == GEN8_PML4ES_PER_PML4) { + idx->pdpe = 0; + ret = true; + break; + } + + kunmap_atomic(vaddr); + vaddr = kmap_atomic_px(pdp->page_directory[idx->pdpe]); + } + + } while (1); + kunmap_atomic(vaddr); + + mark_tlbs_dirty(ppgtt); + + return ret; +} + +static __always_inline bool gen8_ppgtt_insert_64K_pte_entries(struct i915_hw_ppgtt *ppgtt, struct i915_page_directory_pointer *pdp, struct sgt_dma *iter, @@ -1018,6 +1068,9 @@ static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm, case I915_GTT_PAGE_SIZE_64K: insert_entries = gen8_ppgtt_insert_64K_pte_entries; break; + case I915_GTT_PAGE_SIZE_2M: + insert_entries = gen8_ppgtt_insert_2M_pde_entries; + break; default: MISSING_CASE(page_size); return; diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index d948808fcf6a..cfe31db6b400 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -159,6 +159,7 @@ typedef u64 gen8_ppgtt_pml4e_t; #define GEN8_PPAT(i, x)((u64)(x) << ((i) * 8)) #define GEN8_PDE_IPS_64K BIT(11) +#define GEN8_PDE_PS_2M BIT(7) struct sg_table; -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 03/18] drm/i915: pass page_size to insert_entries
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_gtt.c | 33 ++- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 + drivers/gpu/drm/i915/i915_vma.c | 1 + drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 3 ++- drivers/gpu/drm/i915/selftests/mock_gtt.c | 1 + 5 files changed, 32 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 8bab4aea63e6..0c8350f709da 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -205,7 +205,7 @@ static int ppgtt_bind_vma(struct i915_vma *vma, pte_flags |= PTE_READ_ONLY; vma->vm->insert_entries(vma->vm, vma->pages, vma->node.start, - cache_level, pte_flags); + vma->obj->gtt_page_size, cache_level, pte_flags); return 0; } @@ -906,6 +906,7 @@ gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt, static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm, struct sg_table *pages, u64 start, + unsigned int page_size, enum i915_cache_level cache_level, u32 unused) { @@ -924,6 +925,7 @@ static void gen8_ppgtt_insert_3lvl(struct i915_address_space *vm, static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm, struct sg_table *pages, u64 start, + unsigned int page_size, enum i915_cache_level cache_level, u32 unused) { @@ -935,9 +937,24 @@ static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm, }; struct i915_page_directory_pointer **pdps = ppgtt->pml4.pdps; struct gen8_insert_pte idx = gen8_insert_pte(start); + bool (*insert_entries)(struct i915_hw_ppgtt *ppgtt, + struct i915_page_directory_pointer *pdp, + struct sgt_dma *iter, + struct gen8_insert_pte *idx, + enum i915_cache_level cache_level); + + /* TODO: turn this into vfunc */ + switch (page_size) { + case I915_GTT_PAGE_SIZE_4K: + insert_entries = gen8_ppgtt_insert_pte_entries; + break; + default: + MISSING_CASE(page_size); + return; + } - while (gen8_ppgtt_insert_pte_entries(ppgtt, pdps[idx.pml4e++], , -, cache_level)) + while (insert_entries(ppgtt, pdps[idx.pml4e++], , , + cache_level)) GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4); } @@ -1620,6 +1637,7 @@ static void gen6_ppgtt_clear_range(struct i915_address_space *vm, static void gen6_ppgtt_insert_entries(struct i915_address_space *vm, struct sg_table *pages, u64 start, + unsigned int page_size, enum i915_cache_level cache_level, u32 flags) { @@ -2093,6 +2111,7 @@ static void gen8_ggtt_insert_page(struct i915_address_space *vm, static void gen8_ggtt_insert_entries(struct i915_address_space *vm, struct sg_table *st, u64 start, +unsigned int page_size, enum i915_cache_level level, u32 unused) { @@ -2140,6 +2159,7 @@ static void gen6_ggtt_insert_page(struct i915_address_space *vm, static void gen6_ggtt_insert_entries(struct i915_address_space *vm, struct sg_table *st, u64 start, +unsigned int page_size, enum i915_cache_level level, u32 flags) { @@ -2224,6 +2244,7 @@ static void i915_ggtt_insert_page(struct i915_address_space *vm, static void i915_ggtt_insert_entries(struct i915_address_space *vm, struct sg_table *pages, u64 start, +unsigned int page_size, enum i915_cache_level cache_level, u32 unused) { @@ -2260,7 +2281,7 @@ static int ggtt_bind_vma(struct i915_vma *vma, intel_runtime_pm_get(i915); vma->vm->insert_entries(vma->vm, vma->pages, vma->node.start, - cache_level, pte_flags); +
[Intel-gfx] [PATCH 09/18] drm/i915: support inserting 64K pages in the ppgtt
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_gtt.c | 70 + drivers/gpu/drm/i915/i915_gem_gtt.h | 2 ++ 2 files changed, 72 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index ddc3db345b76..fb822c0bd973 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -848,6 +848,73 @@ static __always_inline struct gen8_insert_pte gen8_insert_pte(u64 start) } static __always_inline bool +gen8_ppgtt_insert_64K_pte_entries(struct i915_hw_ppgtt *ppgtt, + struct i915_page_directory_pointer *pdp, + struct sgt_dma *iter, + struct gen8_insert_pte *idx, + enum i915_cache_level cache_level) +{ + struct i915_page_directory *pd; + const gen8_pte_t pte_encode = gen8_pte_encode(0, cache_level); + gen8_pte_t *vaddr; + bool ret; + + GEM_BUG_ON(idx->pte % 16); + GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(>base)); + /* TODO: probably move this to the allocation phase.. */ + pd = pdp->page_directory[idx->pdpe]; + vaddr = kmap_atomic_px(pd); + vaddr[idx->pde] |= GEN8_PDE_IPS_64K; + kunmap_atomic(vaddr); + + vaddr = kmap_atomic_px(pd->page_table[idx->pde]); + do { + vaddr[idx->pte] = pte_encode | iter->dma; + iter->dma += I915_GTT_PAGE_SIZE_64K; + if (iter->dma >= iter->max) { + iter->sg = __sg_next(iter->sg); + if (!iter->sg) { + ret = false; + break; + } + + iter->dma = sg_dma_address(iter->sg); + iter->max = iter->dma + iter->sg->length; + } + + idx->pte += 16; + + if (idx->pte == GEN8_PTES) { + idx->pte = 0; + + if (++idx->pde == I915_PDES) { + idx->pde = 0; + + /* Limited by sg length for 3lvl */ + if (++idx->pdpe == GEN8_PML4ES_PER_PML4) { + idx->pdpe = 0; + ret = true; + break; + } + + GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(>base)); + pd = pdp->page_directory[idx->pdpe]; + } + + kunmap_atomic(vaddr); + vaddr = kmap_atomic_px(pd); + vaddr[idx->pde] |= GEN8_PDE_IPS_64K; + kunmap_atomic(vaddr); + + vaddr = kmap_atomic_px(pd->page_table[idx->pde]); + } + } while (1); + kunmap_atomic(vaddr); + + return ret; +} + +static __always_inline bool gen8_ppgtt_insert_pte_entries(struct i915_hw_ppgtt *ppgtt, struct i915_page_directory_pointer *pdp, struct sgt_dma *iter, @@ -948,6 +1015,9 @@ static void gen8_ppgtt_insert_4lvl(struct i915_address_space *vm, case I915_GTT_PAGE_SIZE_4K: insert_entries = gen8_ppgtt_insert_pte_entries; break; + case I915_GTT_PAGE_SIZE_64K: + insert_entries = gen8_ppgtt_insert_64K_pte_entries; + break; default: MISSING_CASE(page_size); return; diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 8d893ddd98f2..d948808fcf6a 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -158,6 +158,8 @@ typedef u64 gen8_ppgtt_pml4e_t; #define GEN8_PPAT_ELLC_OVERRIDE(0<<2) #define GEN8_PPAT(i, x)((u64)(x) << ((i) * 8)) +#define GEN8_PDE_IPS_64K BIT(11) + struct sg_table; struct intel_rotation_info { -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 02/18] drm/i915: introduce drm_i915_gem_object page_size members
Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem.c| 5 + drivers/gpu/drm/i915/i915_gem_object.h | 3 +++ 2 files changed, 8 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 4ca88f2539c0..cbf97f4bbb72 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2441,6 +2441,8 @@ static int i915_gem_object_get_pages(struct drm_i915_gem_object *obj) struct sg_table *pages; GEM_BUG_ON(i915_gem_object_has_pinned_pages(obj)); + GEM_BUG_ON(!is_valid_gtt_page_size(obj->page_size)); + GEM_BUG_ON(!is_valid_gtt_page_size(obj->gtt_page_size)); if (unlikely(obj->mm.madv != I915_MADV_WILLNEED)) { DRM_DEBUG("Attempting to obtain a purgeable object\n"); @@ -4159,6 +4161,9 @@ void i915_gem_object_init(struct drm_i915_gem_object *obj, obj->ops = ops; + obj->page_size = PAGE_SIZE; + obj->gtt_page_size = I915_GTT_PAGE_SIZE; + reservation_object_init(>__builtin_resv); obj->resv = >__builtin_resv; diff --git a/drivers/gpu/drm/i915/i915_gem_object.h b/drivers/gpu/drm/i915/i915_gem_object.h index 174cf923c236..b1dacbfe5173 100644 --- a/drivers/gpu/drm/i915/i915_gem_object.h +++ b/drivers/gpu/drm/i915/i915_gem_object.h @@ -107,6 +107,9 @@ struct drm_i915_gem_object { unsigned int cache_level:3; unsigned int cache_dirty:1; + unsigned int page_size; /* CPU pov - 4K(default), 2M, 1G */ + unsigned int gtt_page_size; /* GPU pov - 4K(default), 64K, 2M, 1G */ + atomic_t frontbuffer_bits; unsigned int frontbuffer_ggtt_origin; /* write once */ struct i915_gem_active frontbuffer_write; -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [RFC PATCH 00/18] drm/i915: initial support for huge gtt pages V2
Same as before, folding in review comments. Notably we now hook in transparent huge pages through by shmem, and *attempt* to deal with all the fun which that brings. Again should be considered very much RFC. So far I have only gone as far as testing 2M pages on my BDW machine. Thanks, Matt Matthew Auld (18): drm/i915: add page_size_mask to dev_info drm/i915: introduce drm_i915_gem_object page_size members drm/i915: pass page_size to insert_entries drm/i915: s/i915_gtt_color_adjust/i915_ggtt_color_adjust drm/i915: clean up cache coloring drm/i915: export color_differs drm/i915: introduce ppgtt page coloring drm/i915: handle evict-for-node with page coloring drm/i915: support inserting 64K pages in the ppgtt drm/i915: support inserting 2M pages in the ppgtt drm/i915: support inserting 1G pages in the ppgtt drm/i915: disable GTT cache for huge-pages drm/i915/selftests: exercise 4K and 64K mm insertion drm/i915/selftests: modify the gtt tests to also exercise huge pages drm/i915/selftests: exercise evict-for-node page coloring drm/i915/debugfs: include some huge-page metrics mm/shmem: tweak the huge-page interface drm/i915: support transparent-huge-pages through shmemfs drivers/gpu/drm/i915/i915_debugfs.c | 38 +++- drivers/gpu/drm/i915/i915_drv.h | 8 +- drivers/gpu/drm/i915/i915_gem.c | 195 drivers/gpu/drm/i915/i915_gem_evict.c | 36 +++- drivers/gpu/drm/i915/i915_gem_gtt.c | 236 ++-- drivers/gpu/drm/i915/i915_gem_gtt.h | 35 +++- drivers/gpu/drm/i915/i915_gem_object.h | 3 + drivers/gpu/drm/i915/i915_pci.c | 23 ++- drivers/gpu/drm/i915/i915_vma.c | 32 +++- drivers/gpu/drm/i915/i915_vma.h | 6 + drivers/gpu/drm/i915/intel_pm.c | 12 +- drivers/gpu/drm/i915/selftests/i915_gem_evict.c | 125 - drivers/gpu/drm/i915/selftests/i915_gem_gtt.c | 194 +++ drivers/gpu/drm/i915/selftests/mock_gtt.c | 4 + include/linux/shmem_fs.h| 1 + mm/shmem.c | 10 +- 16 files changed, 836 insertions(+), 122 deletions(-) -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 07/18] drm/i915: introduce ppgtt page coloring
To enable 64K pages we need to set the intermediate-page-size(IPS) bit of the pde, therefore a page table is said to be either operating in 64K or 4K mode. To accommodate this vm placement restriction we introduce a color for pages and corresponding color_adjust callback. Signed-off-by: Matthew Auld--- drivers/gpu/drm/i915/i915_gem_gtt.c | 25 + drivers/gpu/drm/i915/i915_gem_gtt.h | 6 ++ drivers/gpu/drm/i915/i915_vma.c | 2 ++ 3 files changed, 33 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c index 0989af4a17e4..ddc3db345b76 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.c +++ b/drivers/gpu/drm/i915/i915_gem_gtt.c @@ -1332,6 +1332,28 @@ static int gen8_preallocate_top_level_pdp(struct i915_hw_ppgtt *ppgtt) return -ENOMEM; } +static void i915_page_color_adjust(const struct drm_mm_node *node, + unsigned long color, + u64 *start, + u64 *end) +{ + GEM_BUG_ON(!is_valid_gtt_page_size(color)); + + if (!(color & (I915_GTT_PAGE_SIZE_4K | I915_GTT_PAGE_SIZE_64K))) + return; + + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color)); + + if (i915_node_color_differs(node, color)) + *start = roundup(*start, 1 << GEN8_PDE_SHIFT); + + node = list_next_entry(node, node_list); + if (i915_node_color_differs(node, color)) + *end = rounddown(*end, 1 << GEN8_PDE_SHIFT); + + GEM_BUG_ON(node->allocated && !is_valid_gtt_page_size(node->color)); +} + /* * GEN8 legacy ppgtt programming is accomplished through a max 4 PDP registers * with a net effect resembling a 2-level page table in normal x86 terms. Each @@ -1372,6 +1394,9 @@ static int gen8_ppgtt_init(struct i915_hw_ppgtt *ppgtt) ppgtt->base.allocate_va_range = gen8_ppgtt_alloc_4lvl; ppgtt->base.insert_entries = gen8_ppgtt_insert_4lvl; ppgtt->base.clear_range = gen8_ppgtt_clear_4lvl; + + if (SUPPORTS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K)) + ppgtt->base.mm.color_adjust = i915_page_color_adjust; } else { ret = __pdp_init(>base, >pdp); if (ret) diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index 9c592e2de516..8d893ddd98f2 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h @@ -353,6 +353,12 @@ i915_vm_has_cache_coloring(const struct i915_address_space *vm) } static inline bool +i915_vm_has_page_coloring(const struct i915_address_space *vm) +{ + return vm->mm.color_adjust && !i915_is_ggtt(vm); +} + +static inline bool i915_vm_is_48bit(const struct i915_address_space *vm) { return (vm->total - 1) >> 32; diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c index 8f0041ba328f..4043145b4310 100644 --- a/drivers/gpu/drm/i915/i915_vma.c +++ b/drivers/gpu/drm/i915/i915_vma.c @@ -471,6 +471,8 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 alignment, u64 flags) if (i915_vm_has_cache_coloring(vma->vm)) color = obj->cache_level; + else if (i915_vm_has_page_coloring(vma->vm)) + color = obj->gtt_page_size; if (flags & PIN_OFFSET_FIXED) { u64 offset = flags & PIN_OFFSET_MASK; -- 2.9.3 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✗ Fi.CI.BAT: failure for Adding driver-private objects to atomic state (rev6)
== Series Details == Series: Adding driver-private objects to atomic state (rev6) URL : https://patchwork.freedesktop.org/series/22177/ State : failure == Summary == CC drivers/usb/host/xhci-dbg.o CC net/ipv4/udp_diag.o CC net/ipv4/tcp_cubic.o CC net/ipv4/xfrm4_policy.o CC drivers/usb/host/xhci-trace.o CC drivers/usb/host/xhci-pci.o CC net/ipv4/xfrm4_input.o CC net/ipv4/xfrm4_state.o CC net/ipv4/xfrm4_output.o CC net/ipv4/xfrm4_protocol.o LD drivers/video/backlight/built-in.o LD drivers/mmc/core/mmc_core.o LD drivers/mmc/host/built-in.o LD drivers/nvme/host/nvme.o LD drivers/nvme/host/built-in.o LD drivers/nvme/built-in.o LD drivers/pci/pcie/pcieportdrv.o LD net/key/built-in.o LD drivers/rtc/built-in.o LD net/unix/unix.o LD net/netlink/built-in.o LD net/unix/built-in.o LD lib/lz4/built-in.o LD [M] drivers/ssb/ssb.o LD [M] drivers/misc/mei/mei-me.o LD drivers/md/dm-mod.o LD drivers/misc/built-in.o LD drivers/tty/serial/8250/8250.o LD kernel/events/built-in.o LD drivers/pci/pcie/aer/aerdriver.o LD drivers/pci/pcie/aer/built-in.o LD drivers/usb/storage/usb-storage.o LD drivers/pci/pcie/built-in.o LD drivers/usb/storage/built-in.o LD drivers/mmc/core/mmc_block.o LD drivers/mmc/core/built-in.o LD drivers/mmc/built-in.o LD [M] drivers/net/ethernet/broadcom/genet/genet.o LD [M] drivers/usb/serial/usbserial.o LD drivers/video/fbdev/core/fb.o AR lib/lib.a LD net/packet/built-in.o LD drivers/video/fbdev/core/built-in.o EXPORTS lib/lib-ksyms.o LD kernel/sched/built-in.o LD drivers/thermal/thermal_sys.o LD drivers/thermal/built-in.o LD lib/built-in.o LD kernel/built-in.o LD [M] sound/pci/hda/snd-hda-codec-generic.o LD sound/pci/built-in.o LD net/ipv6/ipv6.o LD net/ipv6/built-in.o LD drivers/iommu/built-in.o LD drivers/tty/serial/8250/8250_base.o LD drivers/tty/serial/8250/built-in.o LD sound/built-in.o LD drivers/tty/serial/built-in.o LD [M] drivers/net/ethernet/intel/igbvf/igbvf.o LD drivers/usb/gadget/libcomposite.o LD drivers/video/fbdev/built-in.o LD drivers/usb/gadget/udc/udc-core.o LD drivers/pci/built-in.o LD drivers/usb/gadget/udc/built-in.o LD drivers/usb/gadget/built-in.o LD net/xfrm/built-in.o LD drivers/video/console/built-in.o LD drivers/video/built-in.o LD drivers/scsi/scsi_mod.o LD drivers/spi/built-in.o LD drivers/scsi/sd_mod.o LD drivers/scsi/built-in.o LD drivers/usb/core/usbcore.o LD drivers/usb/core/built-in.o CC arch/x86/kernel/cpu/capflags.o LD arch/x86/kernel/cpu/built-in.o LD [M] drivers/net/ethernet/intel/e1000/e1000.o LD arch/x86/kernel/built-in.o LD drivers/tty/vt/built-in.o LD fs/btrfs/btrfs.o LD drivers/tty/built-in.o LD arch/x86/built-in.o LD fs/btrfs/built-in.o LD net/ipv4/built-in.o LD fs/ext4/ext4.o LD fs/ext4/built-in.o LD drivers/md/md-mod.o LD drivers/md/built-in.o LD fs/built-in.o LD [M] drivers/net/ethernet/intel/igb/igb.o LD net/core/built-in.o LD drivers/usb/host/xhci-hcd.o LD net/built-in.o LD [M] drivers/net/ethernet/intel/e1000e/e1000e.o LD drivers/usb/host/built-in.o LD drivers/usb/built-in.o LD drivers/net/ethernet/built-in.o LD drivers/net/built-in.o Makefile:1002: recipe for target 'drivers' failed make: *** [drivers] Error 2 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 4/5] drm: Connector helper function to release resources
From: "Pandiyan, Dhinakaran"Having an ->atomic_release callback is useful to release shared resources that get allocated in compute_config(). This function is expected to be called in the atomic_check() phase before new resources are acquired. v5: Return an int (Maarten) v4: Document that the function is conditionally called and before other atomic_checks() (Daniel) v3: Use the new 'for_each_oldnew_connector_in_state()' macro. v2: Moved the caller hunk to this patch (Daniel) Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Reviewed-by: Maarten Lankhorst Reviewed-by: Daniel Vetter Suggested-by: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_atomic_helper.c | 22 ++ include/drm/drm_modeset_helper_vtables.h | 20 2 files changed, 42 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic_helper.c b/drivers/gpu/drm/drm_atomic_helper.c index d14094d..57d2e50 100644 --- a/drivers/gpu/drm/drm_atomic_helper.c +++ b/drivers/gpu/drm/drm_atomic_helper.c @@ -586,6 +586,28 @@ drm_atomic_helper_check_modeset(struct drm_device *dev, } } + for_each_oldnew_connector_in_state(state, connector, old_connector_state, new_connector_state, i) { + const struct drm_connector_helper_funcs *conn_funcs; + struct drm_crtc_state *crtc_state; + + conn_funcs = connector->helper_private; + if (!conn_funcs->atomic_release) + continue; + + if (!old_connector_state->crtc) + continue; + + crtc_state = drm_atomic_get_existing_crtc_state(state, old_connector_state->crtc); + + if (crtc_state->connectors_changed || + crtc_state->mode_changed || + (crtc_state->active_changed && !crtc_state->active)) { + ret = conn_funcs->atomic_release(connector, new_connector_state); + if (ret != 0) + return ret; + } + } + return mode_fixup(state); } EXPORT_SYMBOL(drm_atomic_helper_check_modeset); diff --git a/include/drm/drm_modeset_helper_vtables.h b/include/drm/drm_modeset_helper_vtables.h index 091c422..36a4b16 100644 --- a/include/drm/drm_modeset_helper_vtables.h +++ b/include/drm/drm_modeset_helper_vtables.h @@ -836,6 +836,26 @@ struct drm_connector_helper_funcs { */ struct drm_encoder *(*atomic_best_encoder)(struct drm_connector *connector, struct drm_connector_state *connector_state); + + /** +* @atomic_release: +* +* This function is conditionally called to release shared resources +* when the attached CRTC's mode changes or it's connectors change or +* becomes inactive. It is called before the corresponding +* _crtc_helper_funcs.atomic_check or +* _crtc_helper_funcs.mode_fixup hooks are called. +* +* NOTE: +* +* This function is called in the check phase of an atomic update. +* +* RETURNS: +* +* 0 on success or negative error codes on failure. +*/ + int (*atomic_release)(struct drm_connector *connector, + struct drm_connector_state *connector_state); }; /** -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v6 2/5] drm/dp: Introduce MST topology state to track available link bandwidth
From: "Pandiyan, Dhinakaran"Link bandwidth is shared between multiple display streams in DP MST configurations. The DP MST topology manager structure maintains the shared link bandwidth for a primary link directly connected to the GPU. For atomic modesetting drivers, checking if there is sufficient link bandwidth for a mode needs to be done during the atomic_check phase to avoid failed modesets. Let's encapsulate the available link bw information in a private state structure so that bw can be allocated and released atomically for each of the ports sharing the primary link. v3: WARN_ON() if connection_mutex is not held (Archit) v2: Included kernel doc, moved state initialization and switched to kmemdup() for allocation (Daniel) Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Reviewed-by: Maarten Lankhorst Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_dp_mst_topology.c | 75 +++ include/drm/drm_dp_mst_helper.h | 20 ++ 2 files changed, 95 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index d3fc7e4..0ad0baa 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2936,6 +2936,69 @@ static void drm_dp_destroy_connector_work(struct work_struct *work) (*mgr->cbs->hotplug)(mgr); } +void *drm_dp_mst_duplicate_state(struct drm_atomic_state *state, void *obj) +{ + struct drm_dp_mst_topology_mgr *mgr = obj; + struct drm_dp_mst_topology_state *new_mst_state; + + if (WARN_ON(!mgr->state)) + return NULL; + + new_mst_state = kmemdup(mgr->state, sizeof(*new_mst_state), GFP_KERNEL); + if (new_mst_state) + new_mst_state->state = state; + return new_mst_state; +} + +void drm_dp_mst_swap_state(void *obj, void **obj_state_ptr) +{ + struct drm_dp_mst_topology_mgr *mgr = obj; + struct drm_dp_mst_topology_state **topology_state_ptr; + + topology_state_ptr = (struct drm_dp_mst_topology_state **)obj_state_ptr; + + mgr->state->state = (*topology_state_ptr)->state; + swap(*topology_state_ptr, mgr->state); + mgr->state->state = NULL; +} + +void drm_dp_mst_destroy_state(void *obj_state) +{ + kfree(obj_state); +} + +static const struct drm_private_state_funcs mst_state_funcs = { + .duplicate_state = drm_dp_mst_duplicate_state, + .swap_state = drm_dp_mst_swap_state, + .destroy_state = drm_dp_mst_destroy_state, +}; + +/** + * drm_atomic_get_mst_topology_state: get MST topology state + * + * @state: global atomic state + * @mgr: MST topology manager, also the private object in this case + * + * This function wraps drm_atomic_get_priv_obj_state() passing in the MST atomic + * state vtable so that the private object state returned is that of a MST + * topology object. Also, drm_atomic_get_private_obj_state() expects the caller + * to care of the locking, so warn if don't hold the connection_mutex. + * + * RETURNS: + * + * The MST topology state or error pointer. + */ +struct drm_dp_mst_topology_state *drm_atomic_get_mst_topology_state(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr) +{ + struct drm_device *dev = mgr->dev; + + WARN_ON(!drm_modeset_is_locked(>mode_config.connection_mutex)); + return drm_atomic_get_private_obj_state(state, mgr, + _state_funcs); +} +EXPORT_SYMBOL(drm_atomic_get_mst_topology_state); + /** * drm_dp_mst_topology_mgr_init - initialise a topology manager * @mgr: manager struct to initialise @@ -2980,6 +3043,15 @@ int drm_dp_mst_topology_mgr_init(struct drm_dp_mst_topology_mgr *mgr, if (test_calc_pbn_mode() < 0) DRM_ERROR("MST PBN self-test failed\n"); + mgr->state = kzalloc(sizeof(*mgr->state), GFP_KERNEL); + if (mgr->state == NULL) + return -ENOMEM; + mgr->state->mgr = mgr; + + /* max. time slots - one slot for MTP header */ + mgr->state->avail_slots = 63; + mgr->funcs = _state_funcs; + return 0; } EXPORT_SYMBOL(drm_dp_mst_topology_mgr_init); @@ -3000,6 +3072,9 @@ void drm_dp_mst_topology_mgr_destroy(struct drm_dp_mst_topology_mgr *mgr) mutex_unlock(>payload_lock); mgr->dev = NULL; mgr->aux = NULL; + kfree(mgr->state); + mgr->state = NULL; + mgr->funcs = NULL; } EXPORT_SYMBOL(drm_dp_mst_topology_mgr_destroy); diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 5b02476..0b371df 100644 ---
[Intel-gfx] [PATCH v6 1/5] drm: Add driver-private objects to atomic state
From: "Pandiyan, Dhinakaran"It is necessary to track states for objects other than connector, crtc and plane for atomic modesets. But adding objects like DP MST link bandwidth to drm_atomic_state would mean that a non-core object will be modified by the core helper functions for swapping and clearing it's state. So, lets add void * objects and helper functions that operate on void * types to keep these objects and states private to the core. Drivers can then implement specific functions to swap and clear states. The other advantage having just void * for these objects in drm_atomic_state is that objects of different types can be managed in the same state array. v6: More kernel-doc to keep 0-day happy v5: Remove more NULL checks (Maarten) v4: Avoid redundant NULL checks when private_objs array is empty (Maarten) v3: Macro alignment (Chris) v2: Added docs and new iterator to filter private objects (Daniel) Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Acked-by: Harry Wentland Suggested-by: Daniel Vetter Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_atomic.c| 65 +++ drivers/gpu/drm/drm_atomic_helper.c | 5 ++ include/drm/drm_atomic.h| 101 3 files changed, 171 insertions(+) diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c index 9b892af..4d37019 100644 --- a/drivers/gpu/drm/drm_atomic.c +++ b/drivers/gpu/drm/drm_atomic.c @@ -57,6 +57,7 @@ void drm_atomic_state_default_release(struct drm_atomic_state *state) kfree(state->connectors); kfree(state->crtcs); kfree(state->planes); + kfree(state->private_objs); } EXPORT_SYMBOL(drm_atomic_state_default_release); @@ -184,6 +185,17 @@ void drm_atomic_state_default_clear(struct drm_atomic_state *state) state->planes[i].ptr = NULL; state->planes[i].state = NULL; } + + for (i = 0; i < state->num_private_objs; i++) { + void *obj_state = state->private_objs[i].obj_state; + + state->private_objs[i].funcs->destroy_state(obj_state); + state->private_objs[i].obj = NULL; + state->private_objs[i].obj_state = NULL; + state->private_objs[i].funcs = NULL; + } + state->num_private_objs = 0; + } EXPORT_SYMBOL(drm_atomic_state_default_clear); @@ -978,6 +990,59 @@ static void drm_atomic_plane_print_state(struct drm_printer *p, } /** + * drm_atomic_get_private_obj_state - get private object state + * @state: global atomic state + * @obj: private object to get the state for + * @funcs: pointer to the struct of function pointers that identify the object + * type + * + * This function returns the private object state for the given private object, + * allocating the state if needed. It does not grab any locks as the caller is + * expected to care of any required locking. + * + * RETURNS: + * + * Either the allocated state or the error code encoded into a pointer. + */ +void * +drm_atomic_get_private_obj_state(struct drm_atomic_state *state, void *obj, + const struct drm_private_state_funcs *funcs) +{ + int index, num_objs, i; + size_t size; + struct __drm_private_objs_state *arr; + + for (i = 0; i < state->num_private_objs; i++) + if (obj == state->private_objs[i].obj && + state->private_objs[i].obj_state) + return state->private_objs[i].obj_state; + + num_objs = state->num_private_objs + 1; + size = sizeof(*state->private_objs) * num_objs; + arr = krealloc(state->private_objs, size, GFP_KERNEL); + if (!arr) + return ERR_PTR(-ENOMEM); + + state->private_objs = arr; + index = state->num_private_objs; + memset(>private_objs[index], 0, sizeof(*state->private_objs)); + + state->private_objs[index].obj_state = funcs->duplicate_state(state, obj); + if (!state->private_objs[index].obj_state) + return ERR_PTR(-ENOMEM); + + state->private_objs[index].obj = obj; + state->private_objs[index].funcs = funcs; + state->num_private_objs = num_objs; + + DRM_DEBUG_ATOMIC("Added new private object state %p to %p\n", +state->private_objs[index].obj_state, state); + + return state->private_objs[index].obj_state; +} +EXPORT_SYMBOL(drm_atomic_get_private_obj_state); + +/** * drm_atomic_get_connector_state - get connector state * @state: global atomic state object * @connector: connector to get state object for diff --git a/drivers/gpu/drm/drm_atomic_helper.c
[Intel-gfx] [PATCH v6 3/5] drm/dp: Add DP MST helpers to atomically find and release vcpi slots
From: "Pandiyan, Dhinakaran"drm_dp_atomic_find_vcpi_slots() should be called from ->atomic_check() to check there are sufficient vcpi slots for a mode and to add that to the state. This should be followed by a call to drm_dp_mst_allocate_vcpi() in ->atomic_commit() to initialize a struct vcpi for the port. drm_dp_atomic_release_vcpi_slots() should be called from ->atomic_check() to release a port's vcpi slot allocation from the state. Drivers that do not make use of this atomic helper are expected to call drm_dp_find_vcpi_slots() instead before calling drm_dp_mst_allocate_vcpi(). v3: drm_dp_atomic_release_vcpi_slots() now needs to know how many slots to release as we may not have a valid reference to port. v2: Added checks for verifying the port reference is valid Moved get_mst_topology_state() into the helpers (Daniel) Changed find_vcpi_slots() to not depend on current allocation Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Reviewed-by: Maarten Lankhorst Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/drm_dp_mst_topology.c | 76 +++ include/drm/drm_dp_mst_helper.h | 6 +++ 2 files changed, 82 insertions(+) diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c b/drivers/gpu/drm/drm_dp_mst_topology.c index 0ad0baa..cf01ed3 100644 --- a/drivers/gpu/drm/drm_dp_mst_topology.c +++ b/drivers/gpu/drm/drm_dp_mst_topology.c @@ -2498,6 +2498,82 @@ static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr, } /** + * drm_dp_atomic_find_vcpi_slots() - Find and add vcpi slots to the state + * @state: global atomic state + * @mgr: MST topology manager for the port + * @port: port to find vcpi slots for + * @pbn: bandwidth required for the mode in PBN + * + * RETURNS: + * Total slots in the atomic state assigned for this port or error + */ +int drm_dp_atomic_find_vcpi_slots(struct drm_atomic_state *state, + struct drm_dp_mst_topology_mgr *mgr, + struct drm_dp_mst_port *port, int pbn) +{ + struct drm_dp_mst_topology_state *topology_state; + int req_slots; + + topology_state = drm_atomic_get_mst_topology_state(state, mgr); + if (topology_state == NULL) + return -ENOMEM; + + port = drm_dp_get_validated_port_ref(mgr, port); + if (port == NULL) + return -EINVAL; + req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div); + DRM_DEBUG_KMS("vcpi slots req=%d, avail=%d\n", + req_slots, topology_state->avail_slots); + + if (req_slots > topology_state->avail_slots) { + drm_dp_put_port(port); + return -ENOSPC; + } + + topology_state->avail_slots -= req_slots; + DRM_DEBUG_KMS("vcpi slots avail=%d", topology_state->avail_slots); + + drm_dp_put_port(port); + return req_slots; +} +EXPORT_SYMBOL(drm_dp_atomic_find_vcpi_slots); + +/** + * drm_dp_atomic_release_vcpi_slots() - Release allocated vcpi slots + * @state: global atomic state + * @mgr: MST topology manager for the port + * @port: port to release the vcpi slots for + * @slots: number of vcpi slots to release for @port + * + * RETURNS: + * 0 if @slots were added back to _dp_mst_topology_state->avail_slots or + * negative error code + */ +int drm_dp_atomic_release_vcpi_slots(struct drm_atomic_state *state, +struct drm_dp_mst_topology_mgr *mgr, +struct drm_dp_mst_port *port, int slots) +{ + struct drm_dp_mst_topology_state *topology_state; + + topology_state = drm_atomic_get_mst_topology_state(state, mgr); + if (topology_state == NULL) + return -ENOMEM; + + /* We cannot rely on port->vcpi.num_slots to update +* topology_state->avail_slots as the port may not exist if the parent +* branch device was unplugged. This should be fixed by tracking +* per-port slot allocation in drm_dp_mst_topology_state instead of +* depending on the caller to tell us how many slots to release. +*/ + topology_state->avail_slots += slots; + DRM_DEBUG_KMS("vcpi slots released=%d, avail=%d\n", + slots, topology_state->avail_slots); + + return 0; +} +EXPORT_SYMBOL(drm_dp_atomic_release_vcpi_slots); + +/** * drm_dp_mst_allocate_vcpi() - Allocate a virtual channel * @mgr: manager for this port * @port: port to allocate a virtual channel for. diff --git a/include/drm/drm_dp_mst_helper.h b/include/drm/drm_dp_mst_helper.h index 0b371df..c781ff7 100644 --- a/include/drm/drm_dp_mst_helper.h +++ b/include/drm/drm_dp_mst_helper.h @@ -615,5 +615,11 @@ void
[Intel-gfx] [PATCH v6 5/5] drm/dp: Track MST link bandwidth
From: "Pandiyan, Dhinakaran"Use the added helpers to track MST link bandwidth for atomic modesets. Link bw is acquired in the ->atomic_check() phase when CRTCs are being enabled with drm_atomic_find_vcpi_slots() instead of drm_find_vcpi_slots(). Similarly, link bw is released during ->atomic_check() with the connector helper callback ->atomic_release() when CRTCs are disabled. v4: Return an int from intel_dp_mst_atomic_release() (Maarten) v3: Handled the case where ->atomic_release() is called more than once during an atomic_check() for the same state. v2: Squashed atomic_release() implementation and caller (Daniel) Fixed logic for connector-crtc switching case (Daniel) Fixed logic for suspend-resume case. Cc: Daniel Vetter Cc: Maarten Lankhorst Cc: Archit Taneja Cc: Chris Wilson Cc: Harry Wentland Signed-off-by: Dhinakaran Pandiyan --- drivers/gpu/drm/i915/intel_dp_mst.c | 48 +++-- 1 file changed, 41 insertions(+), 7 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c b/drivers/gpu/drm/i915/intel_dp_mst.c index c1f62eb..1db3845 100644 --- a/drivers/gpu/drm/i915/intel_dp_mst.c +++ b/drivers/gpu/drm/i915/intel_dp_mst.c @@ -39,9 +39,9 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, struct intel_dp *intel_dp = _dig_port->dp; struct intel_connector *connector = to_intel_connector(conn_state->connector); - struct drm_atomic_state *state; + struct drm_atomic_state *state = pipe_config->base.state; int bpp; - int lane_count, slots; + int lane_count, slots = 0; const struct drm_display_mode *adjusted_mode = _config->base.adjusted_mode; int mst_pbn; @@ -57,30 +57,63 @@ static bool intel_dp_mst_compute_config(struct intel_encoder *encoder, * seem to suggest we should do otherwise. */ lane_count = drm_dp_max_lane_count(intel_dp->dpcd); - pipe_config->lane_count = lane_count; pipe_config->pipe_bpp = bpp; pipe_config->port_clock = intel_dp_max_link_rate(intel_dp); - state = pipe_config->base.state; - if (drm_dp_mst_port_has_audio(_dp->mst_mgr, connector->port)) pipe_config->has_audio = true; - mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp); + mst_pbn = drm_dp_calc_pbn_mode(adjusted_mode->crtc_clock, bpp); pipe_config->pbn = mst_pbn; - slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn); intel_link_compute_m_n(bpp, lane_count, adjusted_mode->crtc_clock, pipe_config->port_clock, _config->dp_m_n); + if (pipe_config->base.active) { + slots = drm_dp_atomic_find_vcpi_slots(state, _dp->mst_mgr, + connector->port, mst_pbn); + if (slots < 0) { + DRM_DEBUG_KMS("failed finding vcpi slots:%d\n", slots); + return false; + } + } pipe_config->dp_m_n.tu = slots; return true; +} +static int intel_dp_mst_atomic_release(struct drm_connector *connector, + struct drm_connector_state *conn_state) +{ + struct intel_dp_mst_encoder *intel_mst; + struct drm_dp_mst_topology_mgr *mgr; + struct drm_encoder *encoder; + struct intel_connector *intel_connector = to_intel_connector(connector); + struct drm_atomic_state *state = conn_state->state; + struct drm_crtc *old_crtc = connector->state->crtc; + struct intel_crtc_state *old_crtc_state = + to_intel_crtc_state(old_crtc->state); + int slots; + int ret = 0; + + encoder = connector->state->best_encoder; + intel_mst = enc_to_mst(encoder); + mgr = _mst->primary->dp.mst_mgr; + + slots = old_crtc_state->dp_m_n.tu; + if (slots > 0) { + ret = drm_dp_atomic_release_vcpi_slots(state, mgr, +intel_connector->port, slots); + if (ret) + DRM_DEBUG_KMS("failed releasing %d vcpi slots:%d\n", slots, ret); + else + old_crtc_state->dp_m_n.tu = 0; + } + return ret; } static void intel_mst_disable_dp(struct intel_encoder *encoder, @@ -387,6 +420,7 @@ static const struct drm_connector_helper_funcs intel_dp_mst_connector_helper_fun .mode_valid = intel_dp_mst_mode_valid, .atomic_best_encoder = intel_mst_atomic_best_encoder, .best_encoder = intel_mst_best_encoder, + .atomic_release = intel_dp_mst_atomic_release, }; static void intel_dp_mst_encoder_destroy(struct
Re: [Intel-gfx] [PATCH v3 03/14] drm/i915/dp: rename rate_to_index() to intel_dp_rate_index() and reuse
On Tue, Mar 28, 2017 at 05:59:03PM +0300, Jani Nikula wrote: > Rename the function, move it at the top, and reuse in > intel_dp_link_rate_index(). If there was a reason in the past to use > reverse search order here, there isn't now. > > The names may be slightly confusing now, but intel_dp_link_rate_index() > will go away in follow-up patches. > > v2: Use name intel_dp_rate_index (Dhinakaran) > > Cc: Manasi Navare> Cc: Ville Syrjälä > Signed-off-by: Jani Nikula Reviewed-by: > --- > drivers/gpu/drm/i915/intel_dp.c | 34 +++--- > 1 file changed, 15 insertions(+), 19 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index 0e200a37b75b..9fc066dda4e0 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -266,6 +266,18 @@ static int intersect_rates(const int *source_rates, int > source_len, > return k; > } > > +/* return index of rate in rates array, or -1 if not found */ > +static int intel_dp_rate_index(const int *rates, int len, int rate) > +{ > + int i; > + > + for (i = 0; i < len; i++) > + if (rate == rates[i]) > + return i; > + > + return -1; > +} > + > static int intel_dp_common_rates(struct intel_dp *intel_dp, >int *common_rates) > { > @@ -284,15 +296,10 @@ static int intel_dp_link_rate_index(struct intel_dp > *intel_dp, > int *common_rates, int link_rate) > { > int common_len; > - int index; > > common_len = intel_dp_common_rates(intel_dp, common_rates); > - for (index = 0; index < common_len; index++) { > - if (link_rate == common_rates[common_len - index - 1]) > - return common_len - index - 1; > - } > > - return -1; > + return intel_dp_rate_index(common_rates, common_len, link_rate); > } > > int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp, > @@ -1538,17 +1545,6 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp) > return true; > } > > -static int rate_to_index(const int *rates, int len, int rate) > -{ > - int i; > - > - for (i = 0; i < len; i++) > - if (rate == rates[i]) > - return i; > - > - return -1; > -} > - > int > intel_dp_max_link_rate(struct intel_dp *intel_dp) > { > @@ -1564,8 +1560,8 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp) > > int intel_dp_rate_select(struct intel_dp *intel_dp, int rate) > { > - int i = rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates, > - rate); > + int i = intel_dp_rate_index(intel_dp->sink_rates, > + intel_dp->num_sink_rates, rate); > > if (WARN_ON(i < 0)) > i = 0; > -- > 2.1.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 02/14] drm/i915/dp: return errors from rate_to_index()
On Wed, Mar 29, 2017 at 10:17:41AM +0300, Jani Nikula wrote: > On Tue, 28 Mar 2017, Manasi Navarewrote: > > Won't it make more sense to squash this patch with Patch 01 in this series? > > When i was reading Patch 1, I almost was going to comment about > > handling the case where we dont find the index.. > > Matter of taste. You might then look at patch 3 and figure it should be > squashed too... you have to draw the line somewhere, and I think it's > always easier to review smaller pieces and be sure they are each > correct. If you find an issue with the 2nd patch, the 1st one is still > valid, and the follow-up review is also easier. > > BR, > Jani. > OK. Agreed. Regards Manasi > > > > > Regards > > Manasi > > > > On Tue, Mar 28, 2017 at 05:59:02PM +0300, Jani Nikula wrote: > >> We shouldn't silently use the first element if we can't find the rate > >> we're looking for. Make rate_to_index() more generally useful, and > >> fallback to the first element in the caller, with a big warning. > >> > >> Cc: Manasi Navare > >> Cc: Ville Syrjälä > >> Signed-off-by: Jani Nikula Reviewed-by: > >> --- > >> drivers/gpu/drm/i915/intel_dp.c | 13 + > >> 1 file changed, 9 insertions(+), 4 deletions(-) > >> > >> diff --git a/drivers/gpu/drm/i915/intel_dp.c > >> b/drivers/gpu/drm/i915/intel_dp.c > >> index 88c708b07c70..0e200a37b75b 100644 > >> --- a/drivers/gpu/drm/i915/intel_dp.c > >> +++ b/drivers/gpu/drm/i915/intel_dp.c > >> @@ -1544,9 +1544,9 @@ static int rate_to_index(const int *rates, int len, > >> int rate) > >> > >>for (i = 0; i < len; i++) > >>if (rate == rates[i]) > >> - break; > >> + return i; > >> > >> - return i; > >> + return -1; > >> } > >> > >> int > >> @@ -1564,8 +1564,13 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp) > >> > >> int intel_dp_rate_select(struct intel_dp *intel_dp, int rate) > >> { > >> - return rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates, > >> - rate); > >> + int i = rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates, > >> +rate); > >> + > >> + if (WARN_ON(i < 0)) > >> + i = 0; > >> + > >> + return i; > >> } > >> > >> void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock, > >> -- > >> 2.1.4 > >> > > -- > Jani Nikula, Intel Open Source Technology Center ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v3 01/14] drm/i915/dp: use known correct array size in rate_to_index
Looks good to me. Reviewed-by:Manasi On Tue, Mar 28, 2017 at 05:59:01PM +0300, Jani Nikula wrote: > I can't think of a real world bug this could cause now, but this will be > required in follow-up work. While at it, change the parameter order to > be slightly more sensible. > > Cc: Manasi Navare > Cc: Ville Syrjälä > Signed-off-by: Jani Nikula > --- > drivers/gpu/drm/i915/intel_dp.c | 11 ++- > 1 file changed, 6 insertions(+), 5 deletions(-) > > diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c > index fd96a6cf7326..88c708b07c70 100644 > --- a/drivers/gpu/drm/i915/intel_dp.c > +++ b/drivers/gpu/drm/i915/intel_dp.c > @@ -1538,12 +1538,12 @@ bool intel_dp_read_desc(struct intel_dp *intel_dp) > return true; > } > > -static int rate_to_index(int find, const int *rates) > +static int rate_to_index(const int *rates, int len, int rate) > { > - int i = 0; > + int i; > > - for (i = 0; i < DP_MAX_SUPPORTED_RATES; ++i) > - if (find == rates[i]) > + for (i = 0; i < len; i++) > + if (rate == rates[i]) > break; > > return i; > @@ -1564,7 +1564,8 @@ intel_dp_max_link_rate(struct intel_dp *intel_dp) > > int intel_dp_rate_select(struct intel_dp *intel_dp, int rate) > { > - return rate_to_index(rate, intel_dp->sink_rates); > + return rate_to_index(intel_dp->sink_rates, intel_dp->num_sink_rates, > + rate); > } > > void intel_dp_compute_rate(struct intel_dp *intel_dp, int port_clock, > -- > 2.1.4 > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 11/11] drm/doc: Small markup fixup
On Tue, Apr 04, 2017 at 05:12:59PM +0200, Neil Armstrong wrote: > On 04/04/2017 11:53 AM, Daniel Vetter wrote: > > Drive-by cleanup. > > > > Signed-off-by: Daniel Vetter> > --- > > drivers/gpu/drm/drm_probe_helper.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/drivers/gpu/drm/drm_probe_helper.c > > b/drivers/gpu/drm/drm_probe_helper.c > > index 85005d57bde6..efb5e5e8ce62 100644 > > --- a/drivers/gpu/drm/drm_probe_helper.c > > +++ b/drivers/gpu/drm/drm_probe_helper.c > > @@ -44,7 +44,7 @@ > > * > > * This library provides some helper code for output probing. It provides > > an > > * implementation of the core _connector_funcs.fill_modes interface > > with > > - * drm_helper_probe_single_connector_modes. > > + * drm_helper_probe_single_connector_modes(). > > * > > * It also provides support for polling connectors with a work item and for > > * generic hotplug interrupt handling where the driver doesn't or cannot > > keep > > > > Reviewed-by: Neil Armstrong I merged the non-vblank patches to drm-misc, thanks a lot for your review. For the vblank patches I'd like to get some additional review from Ville/Chris or Mauro, will take all your feedback in on the next round. Thanks, Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 03/11] drm: Extract drm_ioctl.h
On Tue, Apr 04, 2017 at 04:46:06PM +0200, Neil Armstrong wrote: > On 04/04/2017 11:52 AM, Daniel Vetter wrote: > > To match the drm_ioctl.c we already have. > > > > v2: Remove spurious space (Ville). > > > > Cc: Ville Syrjälä> > Reviewed-by: Ville Syrjälä > > Signed-off-by: Daniel Vetter > > --- > > include/drm/drmP.h | 1 + > > 1 file changed, 1 insertion(+) > > > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > > index e1daa4f343cd..a5ddc2815bf4 100644 > > --- a/include/drm/drmP.h > > +++ b/include/drm/drmP.h > > @@ -81,6 +81,7 @@ > > #include > > #include > > #include > > +#include This is rebase fail, drm_ioctl.h is already included. > > struct module; > > > > > > Reviewed-by: Neil Armstrong You might want to retract that r-b ... :-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'
== Series Details == Series: drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp' URL : https://patchwork.freedesktop.org/series/22462/ State : success == Summary == Series 22462v1 drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp' https://patchwork.freedesktop.org/api/1.0/series/22462/revisions/1/mbox/ Test gem_busy: Subgroup basic-hang-default: incomplete -> PASS (fi-hsw-4770r) fdo#100561 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-bxt-t5700) fdo#100125 Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a-frame-sequence: dmesg-warn -> PASS (fi-byt-n2820) fdo#100094 fdo#100561 https://bugs.freedesktop.org/show_bug.cgi?id=100561 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 430s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 424s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 508s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 538s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 483s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 487s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 408s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 402s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 415s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 465s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 454s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 451s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 573s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 465s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 490s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 428s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 537s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 399s 5467cb1fdc74248d650217938305b8f51a0af3f8 drm-tip: 2017y-04m-04d-16h-54m-17s UTC integration manifest 885e4d3 drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp' == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4399/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Typo fix - 'pipe bpc' to 'pipe bpp'
Noticed this while I was looking at some debug output, [drm:intel_hdmi_compute_config [i915]] picking bpc to 12 for HDMI output [drm:intel_hdmi_compute_config [i915]] forcing pipe bpc to 36 for HDMI I believe the second line should be pipe *bpp* Signed-off-by: Dhinakaran Pandiyan--- drivers/gpu/drm/i915/intel_hdmi.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_hdmi.c b/drivers/gpu/drm/i915/intel_hdmi.c index 1d623b5..6efc3cb 100644 --- a/drivers/gpu/drm/i915/intel_hdmi.c +++ b/drivers/gpu/drm/i915/intel_hdmi.c @@ -1392,7 +1392,7 @@ bool intel_hdmi_compute_config(struct intel_encoder *encoder, } if (!pipe_config->bw_constrained) { - DRM_DEBUG_KMS("forcing pipe bpc to %i for HDMI\n", desired_bpp); + DRM_DEBUG_KMS("forcing pipe bpp to %i for HDMI\n", desired_bpp); pipe_config->pipe_bpp = desired_bpp; } -- 2.7.4 ___ 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: Enable atomic for VLV/CHV
== Series Details == Series: drm/i915: Enable atomic for VLV/CHV URL : https://patchwork.freedesktop.org/series/20634/ State : success == Summary == Series 20634v1 drm/i915: Enable atomic for VLV/CHV https://patchwork.freedesktop.org/api/1.0/series/20634/revisions/1/mbox/ Test gem_busy: Subgroup basic-hang-default: incomplete -> PASS (fi-hsw-4770r) fdo#100561 Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: dmesg-warn -> PASS (fi-bxt-t5700) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-atomic: skip -> PASS (fi-byt-j1900) skip -> PASS (fi-bsw-n3050) skip -> PASS (fi-byt-n2820) fdo#100415 Subgroup basic-flip-after-cursor-atomic: skip -> PASS (fi-byt-j1900) skip -> PASS (fi-bsw-n3050) skip -> PASS (fi-byt-n2820) fdo#100415 Subgroup basic-flip-after-cursor-varying-size: pass -> FAIL (fi-byt-n2820) fdo#100415 Subgroup basic-flip-before-cursor-atomic: skip -> PASS (fi-byt-j1900) skip -> PASS (fi-bsw-n3050) skip -> PASS (fi-byt-n2820) fdo#100415 Subgroup basic-flip-before-cursor-varying-size: pass -> FAIL (fi-byt-n2820) fdo#100415 Test kms_pipe_crc_basic: Subgroup nonblocking-crc-pipe-a-frame-sequence: dmesg-warn -> PASS (fi-byt-n2820) fdo#100094 fdo#100561 https://bugs.freedesktop.org/show_bug.cgi?id=100561 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100415 https://bugs.freedesktop.org/show_bug.cgi?id=100415 fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 434s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 426s fi-bsw-n3050 total:278 pass:242 dwarn:0 dfail:0 fail:0 skip:36 time: 576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 514s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 547s fi-byt-j1900 total:278 pass:254 dwarn:0 dfail:0 fail:0 skip:24 time: 485s fi-byt-n2820 total:278 pass:248 dwarn:0 dfail:0 fail:2 skip:28 time: 491s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 411s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 422s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 490s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 488s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 459s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 564s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 453s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 575s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 454s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 490s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 431s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 526s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time: 403s 5467cb1fdc74248d650217938305b8f51a0af3f8 drm-tip: 2017y-04m-04d-16h-54m-17s UTC integration manifest d6807fd5 drm/i915: Enable atomic on VLV/CHV 7e86af5 drm/i915: Use intel_wm_plane_visible() on VLV/CHV as well d300717 drm/i915: Check for id==PLANE_CURSOR instead of type==DRM_PLANE_TYPE_CURSOR == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4398/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Make legacy cursor updates more unsynced
On Tue, Apr 04, 2017 at 05:50:10PM +0200, Maarten Lankhorst wrote: > Op 29-03-17 om 16:21 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä> > > > We're clearing the legacy_cursor_update flag before calling > > drm_atomic_helper_setup_commit() which means the helper will > > wait for the flip to complete before cleaning up the framebuffers. > > That's not what we want for the legacy cursor, so let's clear > > the flag after setting up the commit. > > > > Also toss in a FIXME about solving these problems in a nicer > > way using the fabled vblank workers. > > > > v2: Also unsync with legacy page flips > > > > Cc: Maarten Lankhorst > > Cc: Daniel Vetter > > Cc: Uwe Kleine-König > > Cc: Rafael Ristovski > > Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for > > ILK-BDW") > > Signed-off-by: Ville Syrjälä > > Reviewed-by: Maarten Lankhorst Thanks. Patch pushed to dinq. -- Ville Syrjälä Intel OTC ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Make legacy cursor updates more unsynced
Op 29-03-17 om 16:21 schreef ville.syrj...@linux.intel.com: > From: Ville Syrjälä> > We're clearing the legacy_cursor_update flag before calling > drm_atomic_helper_setup_commit() which means the helper will > wait for the flip to complete before cleaning up the framebuffers. > That's not what we want for the legacy cursor, so let's clear > the flag after setting up the commit. > > Also toss in a FIXME about solving these problems in a nicer > way using the fabled vblank workers. > > v2: Also unsync with legacy page flips > > Cc: Maarten Lankhorst > Cc: Daniel Vetter > Cc: Uwe Kleine-König > Cc: Rafael Ristovski > Fixes: a5509abda48e ("drm/i915: Fix legacy cursor vs. watermarks for ILK-BDW") > Signed-off-by: Ville Syrjälä Reviewed-by: Maarten Lankhorst ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 10/11] drm/vblank: Lock down vblank->hwmode more
On 04/04/2017 11:53 AM, Daniel Vetter wrote: > In the previous patch we've implemented hwmode tracking a la i915 for > the vblank timestamp calculations. But that was just the basic > semantics, i915 has some nice sanity checks to make sure we keep > getting this right. Move them over too. > > Cc: Ville Syrjälä> Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/drm_irq.c| 8 +++- > drivers/gpu/drm/i915/i915_irq.c | 10 ++ > drivers/gpu/drm/i915/intel_display.c | 11 ++- > 3 files changed, 15 insertions(+), 14 deletions(-) > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 6e04d05455f9..41e9818666b8 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -775,8 +775,10 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct > drm_device *dev, > /* If mode timing undefined, just return as no-op: >* Happens during initial modesetting of a crtc. >*/ > - if (mode->crtc_clock == 0) { > + if (WARN_ON(mode->crtc_clock == 0)) { > DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe); > + WARN_ON(drm_drv_uses_atomic_modeset(dev)); > + > return false; > } > > @@ -1336,6 +1338,10 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc) > send_vblank_event(dev, e, seq, ); > } > spin_unlock_irqrestore(>event_lock, irqflags); > + > + /* Will be reset by the modeset helpers when re-enabling the crtc by > + * calling drm_calc_timestamping_constants(). */ > + vblank->hwmode.crtc_clock = 0; > } > EXPORT_SYMBOL(drm_crtc_vblank_off); > > diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c > index 6477bbd85772..a6046e3e36f5 100644 > --- a/drivers/gpu/drm/i915/i915_irq.c > +++ b/drivers/gpu/drm/i915/i915_irq.c > @@ -720,9 +720,7 @@ static u32 i915_get_vblank_counter(struct drm_device > *dev, unsigned int pipe) > struct drm_i915_private *dev_priv = to_i915(dev); > i915_reg_t high_frame, low_frame; > u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal; > - struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv, > - pipe); > - const struct drm_display_mode *mode = _crtc->base.hwmode; > + const struct drm_display_mode *mode = >vblank[pipe].hwmode; > unsigned long irqflags; > > htotal = mode->crtc_htotal; > @@ -779,13 +777,17 @@ static int __intel_get_crtc_scanline(struct intel_crtc > *crtc) > { > struct drm_device *dev = crtc->base.dev; > struct drm_i915_private *dev_priv = to_i915(dev); > - const struct drm_display_mode *mode = >base.hwmode; > + const struct drm_display_mode *mode; > + struct drm_vblank_crtc *vblank; > enum pipe pipe = crtc->pipe; > int position, vtotal; > > if (!crtc->active) > return -1; > > + vblank = >base.dev->vblank[drm_crtc_index(>base)]; > + mode = >hwmode; > + > vtotal = mode->crtc_vtotal; > if (mode->flags & DRM_MODE_FLAG_INTERLACE) > vtotal /= 2; > diff --git a/drivers/gpu/drm/i915/intel_display.c > b/drivers/gpu/drm/i915/intel_display.c > index 81baa5a9780c..53e732d36fda 100644 > --- a/drivers/gpu/drm/i915/intel_display.c > +++ b/drivers/gpu/drm/i915/intel_display.c > @@ -11461,12 +11461,6 @@ intel_modeset_update_crtc_state(struct > drm_atomic_state *state) > for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) { > to_intel_crtc(crtc)->config = > to_intel_crtc_state(new_crtc_state); > > - /* Update hwmode for vblank functions */ > - if (new_crtc_state->active) > - crtc->hwmode = new_crtc_state->adjusted_mode; > - else > - crtc->hwmode.crtc_clock = 0; > - > /* >* Update legacy state to satisfy fbc code. This can >* be removed when fbc uses the atomic state. > @@ -15471,8 +15465,6 @@ static void intel_modeset_readout_hw_state(struct > drm_device *dev) > to_intel_crtc_state(crtc->base.state); > int pixclk = 0; > > - crtc->base.hwmode = crtc_state->base.adjusted_mode; > - > memset(>base.mode, 0, sizeof(crtc->base.mode)); > if (crtc_state->base.active) { > intel_mode_from_pipe_config(>base.mode, > crtc_state); > @@ -15502,7 +15494,8 @@ static void intel_modeset_readout_hw_state(struct > drm_device *dev) > if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled) > pixclk = DIV_ROUND_UP(pixclk * 100, 95); > > - drm_calc_timestamping_constants(>base, > >base.hwmode); > + drm_calc_timestamping_constants(>base, > +
Re: [Intel-gfx] [PATCH 11/11] drm/doc: Small markup fixup
On 04/04/2017 11:53 AM, Daniel Vetter wrote: > Drive-by cleanup. > > Signed-off-by: Daniel Vetter> --- > drivers/gpu/drm/drm_probe_helper.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/drivers/gpu/drm/drm_probe_helper.c > b/drivers/gpu/drm/drm_probe_helper.c > index 85005d57bde6..efb5e5e8ce62 100644 > --- a/drivers/gpu/drm/drm_probe_helper.c > +++ b/drivers/gpu/drm/drm_probe_helper.c > @@ -44,7 +44,7 @@ > * > * This library provides some helper code for output probing. It provides an > * implementation of the core _connector_funcs.fill_modes interface with > - * drm_helper_probe_single_connector_modes. > + * drm_helper_probe_single_connector_modes(). > * > * It also provides support for polling connectors with a work item and for > * generic hotplug interrupt handling where the driver doesn't or cannot keep > Reviewed-by: Neil Armstrong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 01/11] drm: update todo.rst
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > Just drive-by, but we have gsoc running so better to update it now. > > Great news is that two entries can be removed because essentially all > done. > > v2: Keep a bunch of the todos, Gabriel is working on them. > > Cc: Gabriel Krisman Bertazi> Signed-off-by: Daniel Vetter > --- > Documentation/gpu/todo.rst | 31 --- > 1 file changed, 4 insertions(+), 27 deletions(-) > > diff --git a/Documentation/gpu/todo.rst b/Documentation/gpu/todo.rst > index e255b36b34a3..1bdb7356a310 100644 > --- a/Documentation/gpu/todo.rst > +++ b/Documentation/gpu/todo.rst > @@ -16,7 +16,7 @@ De-midlayer drivers > With the recent ``drm_bus`` cleanup patches for 3.17 it is no longer required > to have a ``drm_bus`` structure set up. Drivers can directly set up the > ``drm_device`` structure instead of relying on bus methods in ``drm_usb.c`` > -and ``drm_platform.c``. The goal is to get rid of the driver's ``->load`` / > +and ``drm_pci.c``. The goal is to get rid of the driver's ``->load`` / > ``->unload`` callbacks and open-code the load/unload sequence properly, using > the new two-stage ``drm_device`` setup/teardown. > > @@ -175,7 +175,7 @@ fine-grained per-buffer object and per-context lockings > scheme. Currently the > following drivers still use ``struct_mutex``: ``msm``, ``omapdrm`` and > ``udl``. > > -Contact: Daniel Vetter > +Contact: Daniel Vetter, respective driver maintainers > > Switch to drm_connector_list_iter for any connector_list walking > > @@ -217,6 +217,8 @@ plan is to switch to per-file driver API headers, which > will also structure > the kerneldoc better. This should also allow more fine-grained ``#include`` > directives. > > +In the end no .c file should need to include ``drmP.h`` anymore. > + > Contact: Daniel Vetter > > Add missing kerneldoc for exported functions > @@ -244,13 +246,8 @@ be hidden so that driver writers don't accidentally end > up using it. And to > prevent security issues in those legacy IOCTLs from being exploited on modern > drivers. This has multiple possible subtasks: > > -* Make sure legacy IOCTLs can't be used on modern drivers. > * Extract support code for legacy features into a ``drm-legacy.ko`` kernel >module and compile it only when one of the legacy drivers is enabled. > -* Extract legacy functions into their own headers and remove it that from the > - monolithic ``drmP.h`` header. > -* Remove any lingering cruft from the OS abstraction layer from modern > - drivers. > > This is mostly done, the only thing left is to split up ``drm_irq.c`` into > legacy cruft and the parts needed by modern KMS drivers. > @@ -408,23 +405,3 @@ Contact: Noralf Trønnes, Daniel Vetter > > Outside DRM > === > - > -Better kerneldoc > - > - > -This is pretty much done, but there's some advanced topics: > - > -Come up with a way to hyperlink to struct members. Currently you can > hyperlink > -to the struct using ``#struct_name``, but not to a member within. Would need > -buy-in from kerneldoc maintainers, and the big question is how to make it > work > -without totally unsightly > -``drm_foo_bar_really_long_structure->even_longer_memeber`` all over the text > -which breaks text flow. > - > -Figure out how to integrate the asciidoc support for ascii-diagrams. We have > a > -few of those (e.g. to describe mode timings), and asciidoc supports > converting > -some ascii-art dialect into pngs. Would be really pretty to make that work. > - > -Contact: Daniel Vetter, Jani Nikula > - > -Jani is working on this already, hopefully lands in 4.8. > Reviewed-by: Neil Armstrong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 09/11] drm/vblank: Simplify the get_scanout_position helper hook
On 04/04/2017 11:53 AM, Daniel Vetter wrote: > - We can drop the different return value flags, the only caller only > cares about whether the scanout position is valid or not. Also, it's > entirely undefined what "accurate" means, if we'd really care we > should probably wire the max_error through. But since we never even > report this to userspace it's kinda moot. > > - Drop all the fancy input flags, there's really only the "called from > vblank irq" one. Well except for radeon/amdgpu, which added their > own private flags. > > Since amdgpu/radoen also use the scanoutposition function internally I > just gave them a tiny wrapper, plus copies of all the old #defines > they need. Everyone else gets simplified code. > > Note how we could remove a lot of error conditions if we'd move this > helper hook to drm_crtc_helper_funcs and would pass it a crtc > directly. > > v2: Make it compile on arm. > > v3: Squash in fixup from 0day. > > Cc: Mario Kleiner> Cc: Eric Anholt > Cc: Rob Clark > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: Alex Deucher > Cc: Christian König > Cc: Ben Skeggs > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 12 +++- > drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h | 3 +++ > drivers/gpu/drm/drm_irq.c | 16 > drivers/gpu/drm/i915/i915_irq.c | 19 ++- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 19 +++ > drivers/gpu/drm/nouveau/nouveau_display.c | 18 -- > drivers/gpu/drm/nouveau/nouveau_display.h | 6 +++--- > drivers/gpu/drm/radeon/radeon_drv.c | 12 +++- > drivers/gpu/drm/radeon/radeon_mode.h | 3 +++ > drivers/gpu/drm/vc4/vc4_crtc.c| 21 ++--- > drivers/gpu/drm/vc4/vc4_drv.h | 8 > include/drm/drmP.h| 8 > include/drm/drm_drv.h | 26 ++ > 13 files changed, 84 insertions(+), 87 deletions(-) > [...] > diff --git a/drivers/gpu/drm/vc4/vc4_crtc.c b/drivers/gpu/drm/vc4/vc4_crtc.c > index 2acfecc5b811..04c390a487ba 100644 > --- a/drivers/gpu/drm/vc4/vc4_crtc.c > +++ b/drivers/gpu/drm/vc4/vc4_crtc.c > @@ -151,10 +151,10 @@ int vc4_crtc_debugfs_regs(struct seq_file *m, void > *unused) > } > #endif > > -int vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id, > - unsigned int flags, int *vpos, int *hpos, > - ktime_t *stime, ktime_t *etime, > - const struct drm_display_mode *mode) > +bool vc4_crtc_get_scanoutpos(struct drm_device *dev, unsigned int crtc_id, > + bool in_vblank_irq, int *vpos, int *hpos, > + ktime_t *stime, ktime_t *etime, > + const struct drm_display_mode *mode) > { > struct vc4_dev *vc4 = to_vc4_dev(dev); > struct drm_crtc *crtc = drm_crtc_from_index(dev, crtc_id); > @@ -162,7 +162,7 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, > unsigned int crtc_id, > u32 val; > int fifo_lines; > int vblank_lines; > - int ret = 0; > + bool ret = false; > > /* preempt_disable_rt() should go right here in PREEMPT_RT patchset. */ > > @@ -198,7 +198,7 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, > unsigned int crtc_id, > fifo_lines = vc4_crtc->cob_size / mode->crtc_hdisplay; > > if (fifo_lines > 0) > - ret |= DRM_SCANOUTPOS_VALID; > + ret = true; > > /* HVS more than fifo_lines into frame for compositing? */ > if (*vpos > fifo_lines) { > @@ -216,7 +216,6 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, > unsigned int crtc_id, >*/ > *vpos -= fifo_lines + 1; > > - ret |= DRM_SCANOUTPOS_ACCURATE; > return ret; > } > > @@ -229,10 +228,9 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, > unsigned int crtc_id, >* We can't get meaningful readings wrt. scanline position of the PV >* and need to make things up in a approximative but consistent way. >*/ > - ret |= DRM_SCANOUTPOS_IN_VBLANK; > vblank_lines = mode->vtotal - mode->vdisplay; > > - if (flags & DRM_CALLED_FROM_VBLIRQ) { > + if (in_vblank_irq) { Shouldn't this go in patch 06/11 ? > /* >* Assume the irq handler got called close to first >* line of vblank, so PV has about a full vblank > @@ -254,9 +252,10 @@ int vc4_crtc_get_scanoutpos(struct drm_device *dev, > unsigned int crtc_id, >* we are at the very beginning of vblank, as the hvs just >* started
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only report a wakeup if the waiter was truly asleep
== Series Details == Series: drm/i915: Only report a wakeup if the waiter was truly asleep URL : https://patchwork.freedesktop.org/series/22445/ State : success == Summary == Series 22445v1 drm/i915: Only report a wakeup if the waiter was truly asleep https://patchwork.freedesktop.org/api/1.0/series/22445/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test prime_vgem: Subgroup basic-fence-flip: dmesg-warn -> PASS (fi-byt-n2820) fdo#100094 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 431s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 424s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 572s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 511s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 551s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 481s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 484s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 411s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 407s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 423s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 494s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 465s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 453s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time: 571s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 459s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 572s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 462s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 489s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 434s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 527s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 407s 38a5db0d3643f519d86f42029b7a93e624807a71 drm-tip: 2017y-04m-04d-13h-24m-06s UTC integration manifest 8da28f9 drm/i915: Only report a wakeup if the waiter was truly asleep == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4397/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/11] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos
On 04/04/2017 11:53 AM, Daniel Vetter wrote: > If we restrict this helper to only kms drivers (which is the case) we > can look up the correct mode easily ourselves. But it's a bit tricky: > > - All legacy drivers look at crtc->hwmode. But that is update already is updated ? > at the beginning of the modeset helper, which means when we disable > a pipe. Hence the final timestamps might be a bit off. But since > this is an existing bug I'm not going to change it, but just try to > be bug-for-bug compatible with the current code. This only applies > to radeon > > - i915 tries to get it perfect by updating crtc->hwmode when the pipe > is off (i.e. vblank->enabled = false). > > - All other atomic drivers look at crtc->state->adjusted_mode. Those > that look at state->requested_mode simply don't adjust their mode, > so it's the same. That has two problems: Accessing crtc->state from > interrupt handling code is unsafe, and it's updated before we shut > down the pipe. For nonblocking modesets it's even worse. > > For atomic drivers try to implement what i915 does. To do that we add > a new hwmode field to the vblank structure, and update it from > drm_calc_timestamping_constants(). For atomic drivers that's called > from the right spot by the helper library already, so all fine. But > for safety let's enforce that. > > For legacy driver this function is only called at the end (oh the > fun), which is broken, so again let's not bother and just stay > bug-for-bug compatible. > > The benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos > directly to implement ->get_vblank_timestamp in every driver, deleting > a lot of code. > > v2: Completely new approach, trying to mimick the i915 solution. > > v3: Fixup kerneldoc. > > v4: Drop the WARN_ON to check that the vblank is off, atomic helpers > currently unconditionally call this. Recomputing the same stuff should > be harmless. > > Cc: Mario Kleiner> Cc: Eric Anholt > Cc: Rob Clark > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: Alex Deucher > Cc: Christian König > Cc: Ben Skeggs > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 4 --- > drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 41 > --- > drivers/gpu/drm/drm_irq.c | 27 +--- > drivers/gpu/drm/i915/i915_irq.c | 33 + > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 26 +--- > drivers/gpu/drm/nouveau/nouveau_display.c | 22 - > drivers/gpu/drm/nouveau/nouveau_display.h | 2 -- > drivers/gpu/drm/nouveau/nouveau_drm.c | 2 +- > drivers/gpu/drm/radeon/radeon_drv.c | 6 + > drivers/gpu/drm/radeon/radeon_kms.c | 37 > drivers/gpu/drm/vc4/vc4_crtc.c| 13 -- > drivers/gpu/drm/vc4/vc4_drv.c | 2 +- > drivers/gpu/drm/vc4/vc4_drv.h | 3 --- > include/drm/drm_irq.h | 15 +-- > 15 files changed, 42 insertions(+), 193 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 310b20ef794a..11ebe861ec78 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -1913,10 +1913,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool > resume, bool fbcon); > u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe); > int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe); > void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe); > -bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int > pipe, > - int *max_error, > - struct timeval *vblank_time, > - bool in_vblank_irq); > long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd, >unsigned long arg); > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > index 400917fd7486..40dd5d19f835 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c > @@ -725,7 +725,7 @@ static struct drm_driver kms_driver = { > .get_vblank_counter = amdgpu_get_vblank_counter_kms, > .enable_vblank = amdgpu_enable_vblank_kms, > .disable_vblank = amdgpu_disable_vblank_kms, > - .get_vblank_timestamp = amdgpu_get_vblank_timestamp_kms, > + .get_vblank_timestamp = drm_calc_vbltimestamp_from_scanoutpos, > .get_scanout_position = amdgpu_get_crtc_scanoutpos, > #if defined(CONFIG_DEBUG_FS) >
Re: [Intel-gfx] [dim PATCH 4/4] dim: run executables in $PATH named dim-subcommand as dim subcommands
On Tue, Apr 04, 2017 at 04:59:02PM +0300, Jani Nikula wrote: > Similar to git. Don't allow override of internal commands though. git did this, and then went to a slightly different version because git doesn't complete to a space due to the various git-foo commands in path. Imo the right way to do this is to have a libexec/ subdir, complete just those (and switch the completion to recognize them), i.e. git foo would run maintainer-tools/libexec/git-foo or maybe maintainer-tools/git-foo. But not depend upon git-foo being in your path (because that is really annoying to me). Other cleanup patches are all acked. -Daniel > > Signed-off-by: Jani Nikula> --- > dim | 6 ++ > 1 file changed, 6 insertions(+) > > diff --git a/dim b/dim > index 45dc07cd0426..85da1542087e 100755 > --- a/dim > +++ b/dim > @@ -1907,6 +1907,12 @@ fi > # look up the function by the subcommand name > subcmd_func=dim_${subcmd//-/_} > if ! declare -f $subcmd_func >/dev/null; then > + # look up dim-subcommand in PATH, and run it > + ext_subcmd=${subcmd_func//_/-} > + if hash $ext_subcmd 2>/dev/null; then > + exec $ext_subcmd "$@" > + fi > + > echoerr "'$subcommand' is not a dim command." > dim_usage > exit 1 > -- > 2.1.4 > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > https://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 07/11] drm/vblank: Add FIXME comments about moving the vblank ts hooks
On 04/04/2017 11:53 AM, Daniel Vetter wrote: > This is going to be a bit too much, but good to have at least a small > note about where this should all head towards. > > Signed-off-by: Daniel Vetter> --- > include/drm/drm_drv.h | 10 ++ > 1 file changed, 10 insertions(+) > > diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h > index 9fe6301edd6a..0a367cf5d8d5 100644 > --- a/include/drm/drm_drv.h > +++ b/include/drm/drm_drv.h > @@ -274,6 +274,11 @@ struct drm_driver { >* constant but unknown small number of scanlines wrt. real scanout >* position. >* > + * FIXME: > + * > + * Since this is a helper to implement @get_vblank_timestamp, we should > + * move it to drm_crtc_helper_funcs, like all the other > + * helper-internal hooks. >*/ > int (*get_scanout_position) (struct drm_device *dev, unsigned int pipe, >unsigned int flags, int *vpos, int *hpos, > @@ -317,6 +322,11 @@ struct drm_driver { >* >* True on success, false on failure, which means the core should >* fallback to a simple timestamp taken in drm_crtc_handle_vblank(). > + * > + * FIXME: > + * > + * We should move this hook to drm_crtc_funcs like all the other > + * vblank hooks. >*/ > bool (*get_vblank_timestamp) (struct drm_device *dev, unsigned int pipe, >int *max_error, > Reviewed-by: Neil Armstrong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 06/11] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > It's overkill to have a flag parameter which is essentially used just > as a boolean. This takes care of core + adjusting drivers. > > Adjusting the scanout position callback is a bit harder, since radeon > also supplies it's own driver-private flags in there. > > Cc: Mario Kleiner> Cc: Eric Anholt > Cc: Rob Clark > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: Alex Deucher > Cc: Christian König > Cc: Ben Skeggs > Reviewed-by: Ville Syrjälä > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 2 +- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 6 ++--- > drivers/gpu/drm/drm_irq.c | 41 > +-- > drivers/gpu/drm/i915/i915_irq.c | 4 +-- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 4 +-- > drivers/gpu/drm/nouveau/nouveau_display.c | 5 ++-- > drivers/gpu/drm/nouveau/nouveau_display.h | 2 +- > drivers/gpu/drm/radeon/radeon_drv.c | 2 +- > drivers/gpu/drm/radeon/radeon_kms.c | 4 +-- > drivers/gpu/drm/vc4/vc4_crtc.c| 4 +-- > drivers/gpu/drm/vc4/vc4_drv.h | 2 +- > include/drm/drm_drv.h | 11 - > include/drm/drm_irq.h | 2 +- > 13 files changed, 46 insertions(+), 43 deletions(-) > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > index 0dcc9ee73ab1..310b20ef794a 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h > @@ -1916,7 +1916,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, > unsigned int pipe); > bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int > pipe, >int *max_error, >struct timeval *vblank_time, > - unsigned flags); > + bool in_vblank_irq); > long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd, >unsigned long arg); > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > index ba937d763df5..109a77ffc692 100644 > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c > @@ -947,7 +947,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, > unsigned int pipe) > * @crtc: crtc to get the timestamp for > * @max_error: max error > * @vblank_time: time value > - * @flags: flags passed to the driver > + * @in_vblank_irq: called from drm_handle_vblank() > * > * Gets the timestamp on the requested crtc based on the > * scanout position. (all asics). > @@ -956,7 +956,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, > unsigned int pipe) > bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int > pipe, >int *max_error, >struct timeval *vblank_time, > - unsigned flags) > + bool in_vblank_irq) > { > struct drm_crtc *crtc; > struct amdgpu_device *adev = dev->dev_private; > @@ -977,7 +977,7 @@ bool amdgpu_get_vblank_timestamp_kms(struct drm_device > *dev, unsigned int pipe, > > /* Helper routine in DRM core does all the work: */ > return drm_calc_vbltimestamp_from_scanoutpos(dev, pipe, max_error, > - vblank_time, flags, > + vblank_time, in_vblank_irq, >>hwmode); > } > > diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c > index 319ab3661965..82b6e0521fe1 100644 > --- a/drivers/gpu/drm/drm_irq.c > +++ b/drivers/gpu/drm/drm_irq.c > @@ -54,7 +54,7 @@ > > static bool > drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe, > - struct timeval *tvblank, unsigned flags); > + struct timeval *tvblank, bool in_vblank_irq); > > static unsigned int drm_timestamp_precision = 20; /* Default to 20 usecs. */ > > @@ -138,7 +138,7 @@ static void drm_reset_vblank_timestamp(struct drm_device > *dev, unsigned int pipe >*/ > do { > cur_vblank = __get_vblank_counter(dev, pipe); > - rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, 0); > + rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, false); > } while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0); > > /* > @@ -171,7 +171,7 @@ static void drm_reset_vblank_timestamp(struct drm_device > *dev, unsigned int
Re: [Intel-gfx] [PATCH 05/11] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > There's really no reason for anything more: > - Calling this while the crtc vblank stuff isn't set up is a driver > bug. Those places arlready DRM_ERROR. s/arlready/already/ > - Calling this when the crtc is off is either a driver bug (callin s/callin/calling/ > drm_crtc_handle_vblank at the wrong time) or a core bug (for > anything else). Again, we DRM_ERROR. > - EINVAL is checked at higher levels already, and if we'd use struct > drm_crtc * instead of (dev, pipe) it would be real obvious that > those are again core bugs. > > The only valid failure mode is crap hardware that couldn't sample a > useful timestamp, to ask the core to just grab a not-so-accurate > timestampe. Bool is perfectly fine for that. s/timestampe/timestamp/ > > v2: Also fix up the one caller, I lost that in the shuffling (Jani). > > Cc: Jani Nikula> Cc: Mario Kleiner > Cc: Eric Anholt > Cc: Rob Clark > Cc: linux-arm-...@vger.kernel.org > Cc: freedr...@lists.freedesktop.org > Cc: Alex Deucher > Cc: Christian König > Cc: Ben Skeggs > Signed-off-by: Daniel Vetter > --- > drivers/gpu/drm/amd/amdgpu/amdgpu.h | 8 ++--- > drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 14 - > drivers/gpu/drm/drm_irq.c | 49 > --- > drivers/gpu/drm/i915/i915_irq.c | 8 ++--- > drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c | 12 > drivers/gpu/drm/nouveau/nouveau_display.c | 4 +-- > drivers/gpu/drm/nouveau/nouveau_display.h | 4 +-- > drivers/gpu/drm/radeon/radeon_drv.c | 8 ++--- > drivers/gpu/drm/radeon/radeon_kms.c | 14 - > drivers/gpu/drm/vc4/vc4_crtc.c| 2 +- > drivers/gpu/drm/vc4/vc4_drv.h | 2 +- > include/drm/drmP.h| 1 - > include/drm/drm_drv.h | 7 ++--- > include/drm/drm_irq.h | 10 +++ > 14 files changed, 64 insertions(+), 79 deletions(-) > [...] With the commit log typo fixes, Reviewed-by: Neil Armstrong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 08/13] drm/i915: Eliminate lots of iterations over the execobjects array
On ke, 2017-03-29 at 16:56 +0100, Chris Wilson wrote: > The major scaling bottleneck in execbuffer is the processing of the > execobjects. Creating an auxiliary list is inefficient when compared to > using the execobject array we already have allocated. > > Reservation is then split into phases. As we lookup up the VMA, we > try and bind it back into active location. Only if that fails, do we add > it to the unbound list for phase 2. In phase 2, we try and add all those > objects that could not fit into their previous location, with fallback > to retrying all objects and evicting the VM in case of severe > fragmentation. (This is the same as before, except that phase 1 is now > done inline with looking up the VMA to avoid an iteration over the > execobject array. In the ideal case, we eliminate the separate reservation > phase). During the reservation phase, we only evict from the VM between > passes (rather than currently as we try to fit every new VMA). In > testing with Unreal Engine's Atlantis demo which stresses the eviction > logic on gen7 class hardware, this speed up the framerate by a factor of > 2. > > The second loop amalgamation is between move_to_gpu and move_to_active. > As we always submit the request, even if incomplete, we can use the > current request to track active VMA as we perform the flushes and > synchronisation required. > > The next big advancement is to avoid copying back to the user any > execobjects and relocations that are not changed. > > v2: Add a Theory of Operation spiel. > v3: Fall back to slow relocations in preparation for flushing userptrs. > > Signed-off-by: Chris Wilson> struct i915_execbuffer { > struct drm_i915_private *i915; > struct drm_file *file; > @@ -63,19 +180,24 @@ struct i915_execbuffer { > struct i915_address_space *vm; > struct i915_vma *batch; > struct drm_i915_gem_request *request; > - u32 batch_start_offset; > - u32 batch_len; > - unsigned int dispatch_flags; > - struct drm_i915_gem_exec_object2 shadow_exec_entry; > - bool need_relocs; > - struct list_head vmas; > + unsigned int buffer_count; > + struct list_head unbound; > + struct list_head relocs; > struct reloc_cache { > struct drm_mm_node node; > unsigned long vaddr; > unsigned int page; > bool use_64bit_reloc : 1; > + bool has_llc : 1; > + bool has_fence : 1; > + bool needs_unfenced : 1; > } reloc_cache; > - int lut_mask; > + u64 invalid_flags; > + u32 context_flags; > + u32 dispatch_flags; > + u32 batch_start_offset; > + u32 batch_len; > + int lut_size; > struct hlist_head *buckets; Please document (new) members. > +static inline u64 gen8_noncanonical_addr(u64 address) > +{ > + return address & ((1ULL << (GEN8_HIGH_ADDRESS_BIT + 1)) - 1); GENMASK_ULL > @@ -106,71 +256,302 @@ eb_create(struct i915_execbuffer *eb) > return -ENOMEM; > } > > - eb->lut_mask = size; > + eb->lut_size = size; > } else { > - eb->lut_mask = -eb->args->buffer_count; > + eb->lut_size = -eb->buffer_count; Document the negative meaning in the doc mentioned above. > +static bool > +eb_vma_misplaced(const struct drm_i915_gem_exec_object2 *entry, > + const struct i915_vma *vma) > +{ > + if ((entry->flags & __EXEC_OBJECT_HAS_PIN) == 0) Lets try to stick to one convention, we gave up == NULL too, so !(a & FOO). > + if ((entry->flags & EXEC_OBJECT_SUPPORTS_48B_ADDRESS) == 0 && > + (vma->node.start + vma->node.size - 1) >> 32) upper_32_bits for clarity? > +static void > +eb_pin_vma(struct i915_execbuffer *eb, > + struct drm_i915_gem_exec_object2 *entry, > + struct i915_vma *vma) > +{ > + u64 flags; > + > + flags = vma->node.start; I'd be more comfortable if some mask was applied here. Or at least GEM_BUG_ON(flags & BAD_FLAGS); > +static inline void > +eb_unreserve_vma(struct i915_vma *vma, > + struct drm_i915_gem_exec_object2 *entry) > { > - struct drm_i915_gem_exec_object2 *entry = vma->exec_entry; > - > - __eb_unreserve_vma(vma, entry); > - entry->flags &= ~(__EXEC_OBJECT_HAS_FENCE | __EXEC_OBJECT_HAS_PIN); > + if (entry->flags & __EXEC_OBJECT_HAS_PIN) { I'd treat the if more as an early return, but I guess you have more code coming. > +static int > +eb_add_vma(struct i915_execbuffer *eb, > > + struct drm_i915_gem_exec_object2 *entry, > > + struct i915_vma *vma) > { > > - struct i915_vma *vma; > > + int ret; > > > - list_for_each_entry(vma, >vmas, exec_link) { > > - eb_unreserve_vma(vma); > > - i915_vma_put(vma); > > - vma->exec_entry = NULL; > > + GEM_BUG_ON(i915_vma_is_closed(vma)); > + > + if ((eb->args->flags & __EXEC_VALIDATED) == 0) {
Re: [Intel-gfx] [PATCH 04/11] drm: document drm_ioctl.[hc]
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > Also unify/merge with the existing stuff. > > I was a bit torn where to put this, but in the end I decided to put > all the ioctl/sysfs/debugfs stuff into drm-uapi.rst. That means we > have a bit a split with the other uapi related stuff used internally, > like drm_file.[hc], but I think overall this makes more sense. > > If it's too confusing we can always add more cross-links to make it > more discoverable. But the auto-sprinkling of links kernel-doc already > does seems sufficient. > > Also for prettier docs and more cross-links, switch the internal > defines over to an enum, as usual. > > v2: Update kerneldoc fro drm_compat_ioctl too (caught by 0day), plus a > bit more drive-by polish. > > v3: Fix typo, spotted by xerpi on irc (Sergi). > > Cc: Sergi Granell> Signed-off-by: Daniel Vetter > --- > Documentation/gpu/drm-internals.rst | 50 > Documentation/gpu/drm-uapi.rst | 14 + > drivers/gpu/drm/drm_ioc32.c | 76 --- > drivers/gpu/drm/drm_ioctl.c | 50 +++- > include/drm/drm_ioctl.h | 116 > +++- > 5 files changed, 203 insertions(+), 103 deletions(-) > > diff --git a/Documentation/gpu/drm-internals.rst > b/Documentation/gpu/drm-internals.rst > index a09c721f9e89..babfb6143bd9 100644 > --- a/Documentation/gpu/drm-internals.rst > +++ b/Documentation/gpu/drm-internals.rst > @@ -255,56 +255,6 @@ File Operations > .. kernel-doc:: drivers/gpu/drm/drm_file.c > :export: > > -IOCTLs > --- > - > -struct drm_ioctl_desc \*ioctls; int num_ioctls; > -Driver-specific ioctls descriptors table. > - > -Driver-specific ioctls numbers start at DRM_COMMAND_BASE. The ioctls > -descriptors table is indexed by the ioctl number offset from the base > -value. Drivers can use the DRM_IOCTL_DEF_DRV() macro to initialize > -the table entries. > - > -:: > - > -DRM_IOCTL_DEF_DRV(ioctl, func, flags) > - > -``ioctl`` is the ioctl name. Drivers must define the DRM_##ioctl and > -DRM_IOCTL_##ioctl macros to the ioctl number offset from > -DRM_COMMAND_BASE and the ioctl number respectively. The first macro is > -private to the device while the second must be exposed to userspace in a > -public header. > - > -``func`` is a pointer to the ioctl handler function compatible with the > -``drm_ioctl_t`` type. > - > -:: > - > -typedef int drm_ioctl_t(struct drm_device *dev, void *data, > -struct drm_file *file_priv); > - > -``flags`` is a bitmask combination of the following values. It restricts > -how the ioctl is allowed to be called. > - > -- DRM_AUTH - Only authenticated callers allowed > - > -- DRM_MASTER - The ioctl can only be called on the master file handle > - > -- DRM_ROOT_ONLY - Only callers with the SYSADMIN capability allowed > - > -- DRM_CONTROL_ALLOW - The ioctl can only be called on a control > - device > - > -- DRM_UNLOCKED - The ioctl handler will be called without locking the > - DRM global mutex. This is the enforced default for kms drivers (i.e. > - using the DRIVER_MODESET flag) and hence shouldn't be used any more > - for new drivers. > - > -.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c > - :export: > - > - > Misc Utilities > == > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 8b0f0e403f0c..858457567d3d 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -160,6 +160,20 @@ other hand, a driver requires shared state between > clients which is > visible to user-space and accessible beyond open-file boundaries, they > cannot support render nodes. > > +IOCTL Support on Device Nodes > += > + > +.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c > + :doc: driver specific ioctls > + > +.. kernel-doc:: include/drm/drm_ioctl.h > + :internal: > + > +.. kernel-doc:: drivers/gpu/drm/drm_ioctl.c > + :export: > + > +.. kernel-doc:: drivers/gpu/drm/drm_ioc32.c > + :export: > > Testing and validation > == > diff --git a/drivers/gpu/drm/drm_ioc32.c b/drivers/gpu/drm/drm_ioc32.c > index b134482f4022..0fa7827cb0fd 100644 > --- a/drivers/gpu/drm/drm_ioc32.c > +++ b/drivers/gpu/drm/drm_ioc32.c > @@ -1,4 +1,4 @@ > -/** > +/* > * \file drm_ioc32.c > * > * 32-bit ioctl compatibility routines for the DRM. > @@ -72,15 +72,15 @@ > #define DRM_IOCTL_MODE_ADDFB232 DRM_IOWR(0xb8, > drm_mode_fb_cmd232_t) > > typedef struct drm_version_32 { > - int version_major;/**< Major version */ > - int version_minor;/**< Minor version */ > - int version_patchlevel;/**< Patch level */ > - u32 name_len; /**< Length of name buffer */ > - u32 name; /**< Name of driver */ > - u32 date_len; /**< Length of date buffer */ > - u32 date;
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions
== Series Details == Series: drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions URL : https://patchwork.freedesktop.org/series/22436/ State : success == Summary == Series 22436v1 drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions https://patchwork.freedesktop.org/api/1.0/series/22436/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test prime_vgem: Subgroup basic-fence-flip: dmesg-warn -> PASS (fi-byt-n2820) fdo#100094 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 429s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 425s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 508s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 540s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 482s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 484s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 414s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 427s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 488s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 453s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 571s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 452s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 570s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 457s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 439s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 534s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 405s fi-skl-6770hq failed to collect. IGT log at Patchwork_4396/fi-skl-6770hq/igt.log 38a5db0d3643f519d86f42029b7a93e624807a71 drm-tip: 2017y-04m-04d-13h-24m-06s UTC integration manifest eb0b122 drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4396/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/11] drm: Consolidate and document sysfs support
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > - remove docs for internal func, doesn't add value > - add short overview snippet instead explaining that drivers don't > have to bother themselves with reg/unreg concerns > - drop the ttm comment about drmP.h, drmP.h is disappearing ... > > Signed-off-by: Daniel Vetter> --- > Documentation/gpu/drm-uapi.rst | 10 ++ > drivers/gpu/drm/drm_sysfs.c| 70 > -- > include/drm/drmP.h | 5 +-- > include/drm/drm_sysfs.h| 8 ++--- > 4 files changed, 42 insertions(+), 51 deletions(-) > > diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst > index 76356c86e358..8b0f0e403f0c 100644 > --- a/Documentation/gpu/drm-uapi.rst > +++ b/Documentation/gpu/drm-uapi.rst > @@ -219,6 +219,16 @@ Debugfs Support > .. kernel-doc:: drivers/gpu/drm/drm_debugfs.c > :export: > > +Sysfs Support > += > + > +.. kernel-doc:: drivers/gpu/drm/drm_sysfs.c > + :doc: overview > + > +.. kernel-doc:: drivers/gpu/drm/drm_sysfs.c > + :export: > + > + > VBlank event handling > = > > diff --git a/drivers/gpu/drm/drm_sysfs.c b/drivers/gpu/drm/drm_sysfs.c > index 513288b5c2f6..1c5b5ce1fd7f 100644 > --- a/drivers/gpu/drm/drm_sysfs.c > +++ b/drivers/gpu/drm/drm_sysfs.c > @@ -25,6 +25,20 @@ > #define to_drm_minor(d) dev_get_drvdata(d) > #define to_drm_connector(d) dev_get_drvdata(d) > > +/** > + * DOC: overview > + * > + * DRM provides very little additional support to drivers for sysfs > + * interactions, beyond just all the standard stuff. Drivers who want to > expose > + * additional sysfs properties and property groups can attach them at either > + * _device.dev or _connector.kdev. > + * > + * Registration is automatically handled when calling drm_dev_register(), or > + * drm_connector_register() in case of hot-plugged connectors. > Unregistration is > + * also automatically handled by drm_dev_unregister() and > + * drm_connector_unregister(). > + */ > + > static struct device_type drm_sysfs_device_minor = { > .name = "drm_minor" > }; > @@ -250,15 +264,6 @@ static const struct attribute_group > *connector_dev_groups[] = { > NULL > }; > > -/** > - * drm_sysfs_connector_add - add a connector to sysfs > - * @connector: connector to add > - * > - * Create a connector device in sysfs, along with its associated connector > - * properties (so far, connection status, dpms, mode list and edid) and > - * generate a hotplug event so userspace knows there's a new connector > - * available. > - */ > int drm_sysfs_connector_add(struct drm_connector *connector) > { > struct drm_device *dev = connector->dev; > @@ -285,19 +290,6 @@ int drm_sysfs_connector_add(struct drm_connector > *connector) > return 0; > } > > -/** > - * drm_sysfs_connector_remove - remove an connector device from sysfs > - * @connector: connector to remove > - * > - * Remove @connector and its associated attributes from sysfs. Note that > - * the device model core will take care of sending the "remove" uevent > - * at this time, so we don't need to do it. > - * > - * Note: > - * This routine should only be called if the connector was previously > - * successfully registered. If @connector hasn't been registered yet, > - * you'll likely see a panic somewhere deep in sysfs code when called. > - */ > void drm_sysfs_connector_remove(struct drm_connector *connector) > { > if (!connector->kdev) > @@ -333,20 +325,6 @@ static void drm_sysfs_release(struct device *dev) > kfree(dev); > } > > -/** > - * drm_sysfs_minor_alloc() - Allocate sysfs device for given minor > - * @minor: minor to allocate sysfs device for > - * > - * This allocates a new sysfs device for @minor and returns it. The device is > - * not registered nor linked. The caller has to use device_add() and > - * device_del() to register and unregister it. > - * > - * Note that dev_get_drvdata() on the new device will return the minor. > - * However, the device does not hold a ref-count to the minor nor to the > - * underlying drm_device. This is unproblematic as long as you access the > - * private data only in sysfs callbacks. device_del() disables those > - * synchronously, so they cannot be called after you cleanup a minor. > - */ > struct device *drm_sysfs_minor_alloc(struct drm_minor *minor) > { > const char *minor_str; > @@ -384,15 +362,13 @@ struct device *drm_sysfs_minor_alloc(struct drm_minor > *minor) > } > > /** > - * drm_class_device_register - Register a struct device in the drm class. > + * drm_class_device_register - register new device with the DRM sysfs class > + * @dev: device to register > * > - * @dev: pointer to struct device to register. > - * > - * @dev should have all relevant members pre-filled with the exception > - * of the class member. In particular, the device_type member must > - * be set. > + * Registers a new device within
Re: [Intel-gfx] [PATCH 03/11] drm: Extract drm_ioctl.h
On 04/04/2017 11:52 AM, Daniel Vetter wrote: > To match the drm_ioctl.c we already have. > > v2: Remove spurious space (Ville). > > Cc: Ville Syrjälä> Reviewed-by: Ville Syrjälä > Signed-off-by: Daniel Vetter > --- > include/drm/drmP.h | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/include/drm/drmP.h b/include/drm/drmP.h > index e1daa4f343cd..a5ddc2815bf4 100644 > --- a/include/drm/drmP.h > +++ b/include/drm/drmP.h > @@ -81,6 +81,7 @@ > #include > #include > #include > +#include > > struct module; > > Reviewed-by: Neil Armstrong ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Only report a wakeup if the waiter was truly asleep
If we attempt to wake up a waiter, who is currently checking the seqno it will be in the TASK_INTERRUPTIBLE state and ttwu will report success. However, it is actually awake and functioning -- so delay reporting the actual wake up until it sleeps. References: https://bugs.freedesktop.org/show_bug.cgi?id=17 Signed-off-by: Chris WilsonCc: Tvrtko Ursulin Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 +-- 1 file changed, 13 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 9ccbf26124c6..e8994aa1b434 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -27,6 +27,17 @@ #include "i915_drv.h" +static inline bool __wake_up_sleeper(struct task_struct *tsk) +{ + /* Be careful not to report a successful wakeup if the waiter is +* currently processing the seqno, where it will have already +* called set_task_state(TASK_INTERRUPTIBLE). We first check whether +* the task is currently asleep before calling ttwu, and then we +* only report success if we were the ones to then trigger the wakeup. +*/ + return !tsk->on_cpu && wake_up_process(tsk); +} + static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b) { struct intel_wait *wait; @@ -37,7 +48,7 @@ static unsigned int __intel_breadcrumbs_wakeup(struct intel_breadcrumbs *b) wait = b->irq_wait; if (wait) { result = ENGINE_WAKEUP_WAITER; - if (wake_up_process(wait->tsk)) + if (__wake_up_sleeper(wait->tsk)) result |= ENGINE_WAKEUP_ASLEEP; } @@ -198,7 +209,7 @@ void intel_engine_disarm_breadcrumbs(struct intel_engine_cs *engine) rbtree_postorder_for_each_entry_safe(wait, n, >waiters, node) { RB_CLEAR_NODE(>node); - if (wake_up_process(wait->tsk) && wait == first) + if (__wake_up_sleeper(wait->tsk) && wait == first) missed_breadcrumb(engine); } b->waiters = RB_ROOT; -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa
== Series Details == Series: drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa URL : https://patchwork.freedesktop.org/series/22435/ State : success == Summary == Series 22435v1 drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa https://patchwork.freedesktop.org/api/1.0/series/22435/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test prime_vgem: Subgroup basic-fence-flip: dmesg-warn -> PASS (fi-byt-n2820) fdo#100094 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 435s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 425s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 576s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 509s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 552s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 480s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 482s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 409s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 405s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 427s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 485s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 466s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 455s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time: 566s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 454s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 569s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 488s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 435s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 523s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 408s 38a5db0d3643f519d86f42029b7a93e624807a71 drm-tip: 2017y-04m-04d-13h-24m-06s UTC integration manifest 0127348 drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4395/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "drm/i915: Lock mode_config.mutex in intel_display_resume."
== Series Details == Series: Revert "drm/i915: Lock mode_config.mutex in intel_display_resume." URL : https://patchwork.freedesktop.org/series/22434/ State : success == Summary == Series 22434v1 Revert "drm/i915: Lock mode_config.mutex in intel_display_resume." https://patchwork.freedesktop.org/api/1.0/series/22434/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 432s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 430s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 582s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 515s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 537s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 409s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 409s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 424s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 483s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 464s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 456s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time: 567s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 457s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 575s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 495s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 432s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 531s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 409s fi-byt-j1900 failed to collect. IGT log at Patchwork_4394/fi-byt-j1900/igt.log fi-byt-n2820 failed to collect. IGT log at Patchwork_4394/fi-byt-n2820/igt.log 38a5db0d3643f519d86f42029b7a93e624807a71 drm-tip: 2017y-04m-04d-13h-24m-06s UTC integration manifest 6afe3a6 Revert "drm/i915: Lock mode_config.mutex in intel_display_resume." == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4394/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Make ptr_unpack_bits() more function-like
== Series Details == Series: series starting with [1/3] drm/i915: Make ptr_unpack_bits() more function-like URL : https://patchwork.freedesktop.org/series/22432/ State : success == Summary == Series 22432v1 Series without cover letter https://patchwork.freedesktop.org/api/1.0/series/22432/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-bxt-t5700) fdo#100125 pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 Test kms_pipe_crc_basic: Subgroup suspend-read-crc-pipe-a: fail -> PASS (fi-skl-6700k) fdo#100367 Test prime_vgem: Subgroup basic-fence-flip: dmesg-warn -> PASS (fi-byt-n2820) fdo#100094 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fdo#100367 https://bugs.freedesktop.org/show_bug.cgi?id=100367 fdo#100094 https://bugs.freedesktop.org/show_bug.cgi?id=100094 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 429s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 427s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 566s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 507s fi-bxt-t5700 total:278 pass:257 dwarn:1 dfail:0 fail:0 skip:20 time: 556s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 481s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 476s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 407s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 407s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 435s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 496s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 485s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 454s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time: 576s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 452s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 571s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 463s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 489s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 430s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 534s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 408s 38a5db0d3643f519d86f42029b7a93e624807a71 drm-tip: 2017y-04m-04d-13h-24m-06s UTC integration manifest a6d54fa drm/i915/execlists: Pack the count into the low bits of the port.request c096e1d drm/i915: Redefine ptr_pack_bits() and friends c6ec960 drm/i915: Make ptr_unpack_bits() more function-like == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4393/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH 4/4] dim: run executables in $PATH named dim-subcommand as dim subcommands
Similar to git. Don't allow override of internal commands though. Signed-off-by: Jani Nikula--- dim | 6 ++ 1 file changed, 6 insertions(+) diff --git a/dim b/dim index 45dc07cd0426..85da1542087e 100755 --- a/dim +++ b/dim @@ -1907,6 +1907,12 @@ fi # look up the function by the subcommand name subcmd_func=dim_${subcmd//-/_} if ! declare -f $subcmd_func >/dev/null; then + # look up dim-subcommand in PATH, and run it + ext_subcmd=${subcmd_func//_/-} + if hash $ext_subcmd 2>/dev/null; then + exec $ext_subcmd "$@" + fi + echoerr "'$subcommand' is not a dim command." dim_usage exit 1 -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH 2/4] dim: move dim update check near the end
Reserve the middle part of the script for function and alias definitions only. Signed-off-by: Jani Nikula--- dim | 13 + 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/dim b/dim index 8671bcb84845..a76e4e4d3f09 100755 --- a/dim +++ b/dim @@ -204,6 +204,10 @@ if [ "$subcommand" != "setup" ] && [ "$subcommand" != "help" ] && [ "$subcommand fi # +# Only function and alias definitions until the subcommand handling at the end. +# + +# # Variable naming convetion: # # repo: @@ -333,10 +337,6 @@ function git_branch_exists # branch fi } -if [[ "$(($(date +%s) % 100))" -eq "0" ]] ; then -dim_uptodate || true -fi - # get message id from file # $1 = file message_get_id () @@ -1893,6 +1893,11 @@ function dim_usage echo "See '$dim help' for more information." } +# occasional check for dim updates +if [[ "$(($(date +%s) % 100))" -eq "0" ]] ; then +dim_uptodate || true +fi + # dim subcommand aliases (with bash 4.3+) if ! declare -n subcmd=dim_alias_${subcommand//-/_} &> /dev/null || \ test -z "${subcmd:-}"; then -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH 3/4] dim: move helper functions above command line options handling
The functions have been added kind of in the middle at some point. Clean it up. Signed-off-by: Jani Nikula--- dim | 20 ++-- 1 file changed, 10 insertions(+), 10 deletions(-) diff --git a/dim b/dim index a76e4e4d3f09..45dc07cd0426 100755 --- a/dim +++ b/dim @@ -114,16 +114,6 @@ function read_integration_config } read_integration_config -# -# Command line options. -# - -DRY_RUN= -INTERACTIVE= -DRY= -FORCE= -HELP= - function echoerr { echo "$dim: $*" >&2 @@ -145,6 +135,16 @@ function pause echo } +# +# Command line options. +# + +DRY_RUN= +INTERACTIVE= +DRY= +FORCE= +HELP= + while getopts hdfis opt; do case "$opt" in d) -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [dim PATCH 1/4] dim: do not bail out if the script is not up-to-date
It's rather obnoxious to exit in the middle of something just because you haven't updated the script. Only issue a warning. Signed-off-by: Jani Nikula--- dim | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/dim b/dim index 33d5fd3c0303..8671bcb84845 100755 --- a/dim +++ b/dim @@ -289,18 +289,18 @@ function dim_uptodate if [[ ! -e "$using" ]]; then echoerr "could not figure out the version being used ($using)." - exit 1 + return 1 fi if [[ ! -e "$DIM_PREFIX/maintainer-tools/.git" ]]; then echoerr "could not find the upstream repo for $dim." - exit 1 + return 1 fi if ! git --git-dir=$DIM_PREFIX/maintainer-tools/.git show "@{upstream}:dim" |\ diff "$using" - >& /dev/null; then echoerr "not running upstream version of the script." - exit 1 + return 1 fi } @@ -334,7 +334,7 @@ function git_branch_exists # branch } if [[ "$(($(date +%s) % 100))" -eq "0" ]] ; then -dim_uptodate +dim_uptodate || true fi # get message id from file -- 2.1.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions
On 04/04/2017 14:38, Michal Wajdeczko wrote: Almost all other GuC fw definitions are using GUC|guc prefix. While around, in get_core_family() change explicit WARN into MISSING_CASE as it looks more appropriate, since GuC support capability we are controlling by intel_device_info.has_guc flag. Signed-off-by: Michal WajdeczkoCc: Joonas Lahtinen Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_guc_fwif.h | 4 ++-- drivers/gpu/drm/i915/intel_guc_loader.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h index cb36cbf..6156845 100644 --- a/drivers/gpu/drm/i915/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h @@ -23,8 +23,8 @@ #ifndef _INTEL_GUC_FWIF_H #define _INTEL_GUC_FWIF_H -#define GFXCORE_FAMILY_GEN912 -#define GFXCORE_FAMILY_UNKNOWN 0x7fff +#define GUC_CORE_FAMILY_GEN9 12 +#define GUC_CORE_FAMILY_UNKNOWN0x7fff #define GUC_CLIENT_PRIORITY_KMD_HIGH 0 #define GUC_CLIENT_PRIORITY_HIGH 1 diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c index 8a1a023..2793c01 100644 --- a/drivers/gpu/drm/i915/intel_guc_loader.c +++ b/drivers/gpu/drm/i915/intel_guc_loader.c @@ -86,11 +86,11 @@ static u32 get_core_family(struct drm_i915_private *dev_priv) switch (gen) { case 9: - return GFXCORE_FAMILY_GEN9; + return GUC_CORE_FAMILY_GEN9; default: - WARN(1, "GEN%d does not support GuC operation!\n", gen); - return GFXCORE_FAMILY_UNKNOWN; + MISSING_CASE(gen); + return GUC_CORE_FAMILY_UNKNOWN; } } I agree that this is much more appropriate error handling for this layer. Prefix also makes sense. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915/guc: Use GUC prefix for CORE_FAMILY definitions
Almost all other GuC fw definitions are using GUC|guc prefix. While around, in get_core_family() change explicit WARN into MISSING_CASE as it looks more appropriate, since GuC support capability we are controlling by intel_device_info.has_guc flag. Signed-off-by: Michal WajdeczkoCc: Joonas Lahtinen Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_guc_fwif.h | 4 ++-- drivers/gpu/drm/i915/intel_guc_loader.c | 6 +++--- 2 files changed, 5 insertions(+), 5 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_guc_fwif.h b/drivers/gpu/drm/i915/intel_guc_fwif.h index cb36cbf..6156845 100644 --- a/drivers/gpu/drm/i915/intel_guc_fwif.h +++ b/drivers/gpu/drm/i915/intel_guc_fwif.h @@ -23,8 +23,8 @@ #ifndef _INTEL_GUC_FWIF_H #define _INTEL_GUC_FWIF_H -#define GFXCORE_FAMILY_GEN912 -#define GFXCORE_FAMILY_UNKNOWN 0x7fff +#define GUC_CORE_FAMILY_GEN9 12 +#define GUC_CORE_FAMILY_UNKNOWN0x7fff #define GUC_CLIENT_PRIORITY_KMD_HIGH 0 #define GUC_CLIENT_PRIORITY_HIGH 1 diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c b/drivers/gpu/drm/i915/intel_guc_loader.c index 8a1a023..2793c01 100644 --- a/drivers/gpu/drm/i915/intel_guc_loader.c +++ b/drivers/gpu/drm/i915/intel_guc_loader.c @@ -86,11 +86,11 @@ static u32 get_core_family(struct drm_i915_private *dev_priv) switch (gen) { case 9: - return GFXCORE_FAMILY_GEN9; + return GUC_CORE_FAMILY_GEN9; default: - WARN(1, "GEN%d does not support GuC operation!\n", gen); - return GFXCORE_FAMILY_UNKNOWN; + MISSING_CASE(gen); + return GUC_CORE_FAMILY_UNKNOWN; } } -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, April 4, 2017 6:26 PM > To: Chauhan, Madhav> Cc: Nikula, Jani ; Ander Conselvan De Oliveira > ; intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > workaround > > On Tue, Apr 04, 2017 at 11:53:42AM +, Chauhan, Madhav wrote: > > > -Original Message- > > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > > Sent: Tuesday, April 4, 2017 5:09 PM > > > To: Chauhan, Madhav > > > Cc: Nikula, Jani ; Ander Conselvan De > > > Oliveira ; intel-gfx@lists.freedesktop.org > > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > > > workaround > > > > > > On Tue, Apr 04, 2017 at 10:27:57AM +, Chauhan, Madhav wrote: > > > > > -Original Message- > > > > > From: Nikula, Jani > > > > > Sent: Tuesday, April 4, 2017 3:48 PM > > > > > To: Ander Conselvan De Oliveira ; intel- > > > > > g...@lists.freedesktop.org > > > > > Cc: Chauhan, Madhav ; Ville Syrjälä > > > > > > > > > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of > > > > > cdclk workaround > > > > > > > > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > > > > > > > wrote: > > > > > > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: > > > > > >> On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > > wrote: > > > > > >> > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > > > > > >> > > From: Madhav Chauhan > > > > > >> > > > > > > > >> > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 > Mhz. > > > > > >> > > Practically we can achive only 99% of these cdclk values > > > > > >> > > (HW team checking on this). So cdclk should be calculated > > > > > >> > > for the given pixclk as per that otherwise it may lead to > > > > > >> > > screen corruption for some > > > > > scenarios. > > > > > >> > > > > > > > >> > > v2: Rebased to new CDLCK code framework > > > > > >> > > v3: Addressed review comments from Ander/Jani > > > > > >> > > - Add comment in code about 99% usage of CDCLK > > > > > >> > > - Calculate max dot clock as well with 99% limit > > > > > >> > > v4 by Jani: > > > > > >> > > - drop superfluous whitespace change > > > > > >> > > - rewrite code comments to clarify > > > > > >> > > > > > > > >> > > Cc: Ander Conselvan de Oliveira > > > > > >> > > > > > > > >> > > Cc: Ville Syrjälä > > > > > >> > > Signed-off-by: Madhav Chauhan > > > > > > >> > > Signed-off-by: Jani Nikula > > > > > >> > > --- > > > > > >> > > drivers/gpu/drm/i915/intel_cdclk.c | 16 +--- > > > > > >> > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > > >> > > > > > > > >> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > > > > > >> > > b/drivers/gpu/drm/i915/intel_cdclk.c > > > > > >> > > index dd3ad52b7dfe..763010f8ad89 100644 > > > > > >> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c > > > > > >> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c > > > > > >> > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int > > > > > >> > > max_pixclk) > > > > > >> > > > > > > > >> > > static int glk_calc_cdclk(int max_pixclk) { > > > > > >> > > - if (max_pixclk > 2 * 158400) > > > > > >> > > + /* > > > > > >> > > + * FIXME: Avoid using a pixel clock that is more than > > > > > >> > > +99% of > > > the cdclk > > > > > >> > > + * as a temporary workaround. Use a higher cdclk > > > > > >> > > instead. > > > > > >> > > +(Note that > > > > > >> > > > > > > >> > Temporary workaround for what? Neither the comment nor the > > > > > >> > commit message explicitly lists the scenario that triggers this > issue. > > > > > >> > > > > > >> Frankly I did not know what to write. > > > > > > > > > > > > > > > > > >> There are issues with pixel clocks near cdclk that shouldn't > > > > > >> happen. People are looking into this, but in the mean time > > > > > >> dodge the issues by using higher cdclk. The issue should not > > > > > >> be encoder specific, but in practice this has only been seen > > > > > >> with DSI because there were some modes with pixel clocks that > > > > > >> are near the cdclk. > > > > > > > > > > > > The above plus the model number of the DSI panel with which > > > > > > the issue has been seen would be good enough IMO. > > > > > > > > > > Madhav? > > > > > > > > Issue is generic (valid for DP/HDMI) not just MIPI DSI specific. > > > > Particular DSI panel exposing this issue as described below: > > > > 1. For panel (19X12) required pixclk is 157100
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/huc: Simplify intel_huc_init_hw()
On 31/03/2017 13:58, Patchwork wrote: == Series Details == Series: drm/i915/huc: Simplify intel_huc_init_hw() URL : https://patchwork.freedesktop.org/series/22280/ State : success == Summary == Series 22280v1 drm/i915/huc: Simplify intel_huc_init_hw() https://patchwork.freedesktop.org/api/1.0/series/22280/revisions/1/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: pass -> FAIL (fi-snb-2600) fdo#17 fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 427s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 425s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 574s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 514s fi-bxt-t5700 total:278 pass:258 dwarn:0 dfail:0 fail:0 skip:20 time: 597s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 479s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 488s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 412s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 412s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 424s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 495s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 471s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 453s fi-kbl-7560u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 570s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 449s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 576s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 491s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 430s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 537s fi-snb-2600 total:278 pass:248 dwarn:0 dfail:0 fail:1 skip:29 time: 408s d083fa23d514574a26bfcf91aa5e1de4e6262cd9 drm-tip: 2017y-03m-31d-11h-25m-25s UTC integration manifest 9673e6f7 drm/i915/huc: Simplify intel_huc_init_hw() Pushed, thanks for the patch and review! Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] drm/i915: Do not use lock all in hsw_trans_edp_pipe_A_crc_wa
There is no need to acquire all locks here, doing a commit after forcing a modeset on the affected crtc is enough. Any other locks needed will be acquired as needed. Signed-off-by: Maarten Lankhorst--- drivers/gpu/drm/i915/intel_pipe_crc.c | 17 ++--- 1 file changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c b/drivers/gpu/drm/i915/intel_pipe_crc.c index 9fd9c70baeed..647426c75b0a 100644 --- a/drivers/gpu/drm/i915/intel_pipe_crc.c +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c @@ -513,16 +513,20 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv, struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv, PIPE_A); struct intel_crtc_state *pipe_config; struct drm_atomic_state *state; + struct drm_modeset_acquire_ctx ctx; int ret = 0; - drm_modeset_lock_all(dev); + drm_modeset_acquire_init(, 0); + state = drm_atomic_state_alloc(dev); if (!state) { ret = -ENOMEM; goto unlock; } - state->acquire_ctx = drm_modeset_legacy_acquire_ctx(>base); + state->acquire_ctx = + +retry: pipe_config = intel_atomic_get_crtc_state(state, crtc); if (IS_ERR(pipe_config)) { ret = PTR_ERR(pipe_config); @@ -537,10 +541,17 @@ static void hsw_trans_edp_pipe_A_crc_wa(struct drm_i915_private *dev_priv, ret = drm_atomic_commit(state); put_state: + if (ret == -EDEADLK) { + drm_atomic_state_clear(state); + drm_modeset_backoff(); + goto retry; + } + drm_atomic_state_put(state); unlock: WARN(ret, "Toggling workaround to %i returns %i\n", enable, ret); - drm_modeset_unlock_all(dev); + drm_modeset_drop_locks(); + drm_modeset_acquire_fini(); } static int ivb_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv, -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH] Revert "drm/i915: Lock mode_config.mutex in intel_display_resume."
This reverts commit ea49c9acf2db7082f0406bb3a570cc6bad37082b. mode_config.mutex was originally added to fix WARNs in connector functions, but now that atomic nonblocking modeset support is included, we will likely never hold any any lock at all. The WARN mentioned in commit bbf35e9defb9a6d1 ("drm/i915: Pass atomic state to intel_audio_codec_enable, v2."), so it's safe to revert this now. Signed-off-by: Maarten Lankhorst--- drivers/gpu/drm/i915/intel_display.c | 8 1 file changed, 8 deletions(-) diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c index 65aa8e586ec5..4698503c156b 100644 --- a/drivers/gpu/drm/i915/intel_display.c +++ b/drivers/gpu/drm/i915/intel_display.c @@ -15606,13 +15606,6 @@ void intel_display_resume(struct drm_device *dev) if (state) state->acquire_ctx = - /* -* This is a cludge because with real atomic modeset mode_config.mutex -* won't be taken. Unfortunately some probed state like -* audio_codec_enable is still protected by mode_config.mutex, so lock -* it here for now. -*/ - mutex_lock(>mode_config.mutex); drm_modeset_acquire_init(, 0); while (1) { @@ -15628,7 +15621,6 @@ void intel_display_resume(struct drm_device *dev) drm_modeset_drop_locks(); drm_modeset_acquire_fini(); - mutex_unlock(>mode_config.mutex); if (ret) DRM_ERROR("Restoring old state failed with %i\n", ret); -- 2.7.4 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 2/2] drm/i915/execlists: Pack the count into the low bits of the port.request
On Fri, Mar 31, 2017 at 03:10:33PM +0100, Chris Wilson wrote: > diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h > b/drivers/gpu/drm/i915/intel_ringbuffer.h > index a82a0807f64d..51497653c830 100644 > --- a/drivers/gpu/drm/i915/intel_ringbuffer.h > +++ b/drivers/gpu/drm/i915/intel_ringbuffer.h > @@ -373,8 +373,12 @@ struct intel_engine_cs { > /* Execlists */ > struct tasklet_struct irq_tasklet; > struct execlist_port { > - struct drm_i915_gem_request *request; > - unsigned int count; > + struct drm_i915_gem_request *request_count; > +#define EXECLIST_COUNT_BITS 2 > +#define port_request(p) ptr_mask_bits((p)->request_count, > EXECLIST_COUNT_BITS) > +#define port_count(p) ptr_unmask_bits((p)->request_count, > EXECLIST_COUNT_BITS) > +#define port_pack(rq, count) ptr_pack_bits(rq, count, EXECLIST_COUNT_BITS) > +#define port_unpack(p, count) ptr_unpack_bits((p)->request_count, count, > EXECLIST_COUNT_BITS) I haven't yet found anything more agreeable (unions and packing pointers into a bitfield), so for the moment it remains an unsightly request_count (although I still think it is safer to hint about its dual purpose in the name). -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 2/3] drm/i915: Redefine ptr_pack_bits() and friends
Rebrand the current (pointer | bits) pack/unpack utility macros as explicit bit twiddling for PAGE_SIZE so that we can use the more flexible underlying macros for different bits. Signed-off-by: Chris WilsonReviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_cmd_parser.c | 2 +- drivers/gpu/drm/i915/i915_gem.c| 6 +++--- drivers/gpu/drm/i915/i915_utils.h | 19 +-- 3 files changed, 17 insertions(+), 10 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c b/drivers/gpu/drm/i915/i915_cmd_parser.c index 7af100f84410..1b69a1f9a1ea 100644 --- a/drivers/gpu/drm/i915/i915_cmd_parser.c +++ b/drivers/gpu/drm/i915/i915_cmd_parser.c @@ -1284,7 +1284,7 @@ int intel_engine_cmd_parser(struct intel_engine_cs *engine, if (*cmd == MI_BATCH_BUFFER_END) { if (needs_clflush_after) { - void *ptr = ptr_mask_bits(shadow_batch_obj->mm.mapping); + void *ptr = page_mask_bits(shadow_batch_obj->mm.mapping); drm_clflush_virt_range(ptr, (void *)(cmd + 1) - ptr); } diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index f49aca95553b..178f01226c6e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2228,7 +2228,7 @@ void __i915_gem_object_put_pages(struct drm_i915_gem_object *obj, if (obj->mm.mapping) { void *ptr; - ptr = ptr_mask_bits(obj->mm.mapping); + ptr = page_mask_bits(obj->mm.mapping); if (is_vmalloc_addr(ptr)) vunmap(ptr); else @@ -2560,7 +2560,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, } GEM_BUG_ON(!obj->mm.pages); - ptr = ptr_unpack_bits(obj->mm.mapping, _type); + ptr = page_unpack_bits(obj->mm.mapping, _type); if (ptr && has_type != type) { if (pinned) { ret = -EBUSY; @@ -2582,7 +2582,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, goto err_unpin; } - obj->mm.mapping = ptr_pack_bits(ptr, type); + obj->mm.mapping = page_pack_bits(ptr, type); } out_unlock: diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h index aca11aad5da7..f0500c65726d 100644 --- a/drivers/gpu/drm/i915/i915_utils.h +++ b/drivers/gpu/drm/i915/i915_utils.h @@ -70,20 +70,27 @@ #define overflows_type(x, T) \ (sizeof(x) > sizeof(T) && (x) >> (sizeof(T) * BITS_PER_BYTE)) -#define ptr_mask_bits(ptr) ({ \ +#define ptr_mask_bits(ptr, n) ({ \ unsigned long __v = (unsigned long)(ptr); \ - (typeof(ptr))(__v & PAGE_MASK); \ + (typeof(ptr))(__v & -BIT(n)); \ }) -#define ptr_unpack_bits(ptr, bits) ({ \ +#define ptr_unmask_bits(ptr, n) ((unsigned long)(ptr) & (BIT(n) - 1)) + +#define ptr_unpack_bits(ptr, bits, n) ({ \ unsigned long __v = (unsigned long)(ptr); \ - *(bits) = __v & ~PAGE_MASK; \ - (typeof(ptr))(__v & PAGE_MASK); \ + *(bits) = __v & (BIT(n) - 1); \ + (typeof(ptr))(__v & -BIT(n)); \ }) -#define ptr_pack_bits(ptr, bits) \ +#define ptr_pack_bits(ptr, bits, n)\ ((typeof(ptr))((unsigned long)(ptr) | (bits))) +#define page_mask_bits(ptr) ptr_mask_bits(ptr, PAGE_SHIFT) +#define page_unmask_bits(ptr) ptr_unmask_bits(ptr, PAGE_SHIFT) +#define page_pack_bits(ptr, bits) ptr_pack_bits(ptr, bits, PAGE_SHIFT) +#define page_unpack_bits(ptr, bits) ptr_unpack_bits(ptr, bits, PAGE_SHIFT) + #define ptr_offset(ptr, member) offsetof(typeof(*(ptr)), member) #define fetch_and_zero(ptr) ({ \ -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 3/3] drm/i915/execlists: Pack the count into the low bits of the port.request
add/remove: 1/1 grow/shrink: 5/4 up/down: 391/-578 (-187) function old new delta execlists_submit_ports 262 471+209 port_assign.isra - 136+136 capture 63446359 +15 reset_common_ring438 452 +14 execlists_submit_request 228 238 +10 gen8_init_common_ring334 341 +7 intel_engine_is_idle 106 105 -1 i915_engine_info23142290 -24 __i915_gem_set_wedged_BKL485 411 -74 intel_lrc_irq_handler 17891604-185 execlists_update_context 294 --294 The most important change there is the improve to the intel_lrc_irq_handler and excclist_submit_ports (net improvement since execlists_update_context is now inlined). Signed-off-by: Chris WilsonCc: Mika Kuoppala Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c| 32 --- drivers/gpu/drm/i915/i915_gem.c| 6 +- drivers/gpu/drm/i915/i915_gpu_error.c | 13 ++- drivers/gpu/drm/i915/i915_guc_submission.c | 18 ++-- drivers/gpu/drm/i915/intel_engine_cs.c | 2 +- drivers/gpu/drm/i915/intel_lrc.c | 133 - drivers/gpu/drm/i915/intel_ringbuffer.h| 8 +- 7 files changed, 120 insertions(+), 92 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_debugfs.c b/drivers/gpu/drm/i915/i915_debugfs.c index d689e511744e..0a123779f693 100644 --- a/drivers/gpu/drm/i915/i915_debugfs.c +++ b/drivers/gpu/drm/i915/i915_debugfs.c @@ -3317,6 +3317,7 @@ static int i915_engine_info(struct seq_file *m, void *unused) if (i915.enable_execlists) { u32 ptr, read, write; struct rb_node *rb; + unsigned int idx; seq_printf(m, "\tExeclist status: 0x%08x %08x\n", I915_READ(RING_EXECLIST_STATUS_LO(engine)), @@ -3334,8 +3335,7 @@ static int i915_engine_info(struct seq_file *m, void *unused) if (read > write) write += GEN8_CSB_ENTRIES; while (read < write) { - unsigned int idx = ++read % GEN8_CSB_ENTRIES; - + idx = ++read % GEN8_CSB_ENTRIES; seq_printf(m, "\tExeclist CSB[%d]: 0x%08x, context: %d\n", idx, I915_READ(RING_CONTEXT_STATUS_BUF_LO(engine, idx)), @@ -3343,21 +3343,19 @@ static int i915_engine_info(struct seq_file *m, void *unused) } rcu_read_lock(); - rq = READ_ONCE(engine->execlist_port[0].request); - if (rq) { - seq_printf(m, "\t\tELSP[0] count=%d, ", - engine->execlist_port[0].count); - print_request(m, rq, "rq: "); - } else { - seq_printf(m, "\t\tELSP[0] idle\n"); - } - rq = READ_ONCE(engine->execlist_port[1].request); - if (rq) { - seq_printf(m, "\t\tELSP[1] count=%d, ", - engine->execlist_port[1].count); - print_request(m, rq, "rq: "); - } else { - seq_printf(m, "\t\tELSP[1] idle\n"); + for (idx = 0; idx < ARRAY_SIZE(engine->execlist_port); idx++) { + unsigned int count; + + rq = port_unpack(>execlist_port[idx], +); + if (rq) { + seq_printf(m, "\t\tELSP[%d] count=%d, ", + idx, count); + print_request(m, rq, "rq: "); + } else { + seq_printf(m, "\t\tELSP[%d] idle\n", + idx); + } } rcu_read_unlock(); diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 178f01226c6e..9ad5c7b8e36b 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2967,12 +2967,14 @@ static void engine_set_wedged(struct intel_engine_cs *engine) */ if
[Intel-gfx] [PATCH 1/3] drm/i915: Make ptr_unpack_bits() more function-like
ptr_unpack_bits() is a function-like macro, as such it is meant to be replaceable by a function. In this case, we should be passing in the out-param as a pointer. Bizarrely this does affect code generation: function old new delta i915_gem_object_pin_map 409 389 -20 An improvement(?) in this case, but one can't help wonder what strict-aliasing optimisations we are preventing. The generated code looks identical in using ptr_unpack_bits (no extra motions to stack, the pointer and bits appear to be kept in registers), the difference appears to be code ordering and with a reorder it is able to use smaller forward jumps. Signed-off-by: Chris WilsonReviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem.c | 2 +- drivers/gpu/drm/i915/i915_utils.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index ae4764b0c361..f49aca95553b 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2560,7 +2560,7 @@ void *i915_gem_object_pin_map(struct drm_i915_gem_object *obj, } GEM_BUG_ON(!obj->mm.pages); - ptr = ptr_unpack_bits(obj->mm.mapping, has_type); + ptr = ptr_unpack_bits(obj->mm.mapping, _type); if (ptr && has_type != type) { if (pinned) { ret = -EBUSY; diff --git a/drivers/gpu/drm/i915/i915_utils.h b/drivers/gpu/drm/i915/i915_utils.h index c5455d36b617..aca11aad5da7 100644 --- a/drivers/gpu/drm/i915/i915_utils.h +++ b/drivers/gpu/drm/i915/i915_utils.h @@ -77,7 +77,7 @@ #define ptr_unpack_bits(ptr, bits) ({ \ unsigned long __v = (unsigned long)(ptr); \ - (bits) = __v & ~PAGE_MASK; \ + *(bits) = __v & ~PAGE_MASK; \ (typeof(ptr))(__v & PAGE_MASK); \ }) -- 2.11.0 ___ 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: Redefine ptr_pack_bits() and friends
On Mon, Apr 03, 2017 at 11:49:16AM +0300, Joonas Lahtinen wrote: > On pe, 2017-03-31 at 15:10 +0100, Chris Wilson wrote: > > Rebrand the current (pointer | bits) pack/unpack utility macros as > > explicit bit twiddling for PAGE_SIZE so that we can use the more > > flexible underlying macros for different bits. > > > > Signed-off-by: Chris Wilson> > Pass by pointer when the values get written to. Also, I'm rather unsure > how intuitive ptr_unpack_bits is, could be worth splitting to two > lines. I'm comfortable with it being a function-like macro returning two outs, the users look reasonable. So I'll stick with that for the moment. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround
On Tue, Apr 04, 2017 at 11:53:42AM +, Chauhan, Madhav wrote: > > -Original Message- > > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > > Sent: Tuesday, April 4, 2017 5:09 PM > > To: Chauhan, Madhav> > Cc: Nikula, Jani ; Ander Conselvan De Oliveira > > ; intel-gfx@lists.freedesktop.org > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > > workaround > > > > On Tue, Apr 04, 2017 at 10:27:57AM +, Chauhan, Madhav wrote: > > > > -Original Message- > > > > From: Nikula, Jani > > > > Sent: Tuesday, April 4, 2017 3:48 PM > > > > To: Ander Conselvan De Oliveira ; intel- > > > > g...@lists.freedesktop.org > > > > Cc: Chauhan, Madhav ; Ville Syrjälä > > > > > > > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > > > > workaround > > > > > > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > > > > > wrote: > > > > > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: > > > > >> On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > wrote: > > > > >> > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > > > > >> > > From: Madhav Chauhan > > > > >> > > > > > > >> > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 > > > > >> > > Mhz. > > > > >> > > Practically we can achive only 99% of these cdclk values (HW > > > > >> > > team checking on this). So cdclk should be calculated for the > > > > >> > > given pixclk as per that otherwise it may lead to screen > > > > >> > > corruption for some > > > > scenarios. > > > > >> > > > > > > >> > > v2: Rebased to new CDLCK code framework > > > > >> > > v3: Addressed review comments from Ander/Jani > > > > >> > > - Add comment in code about 99% usage of CDCLK > > > > >> > > - Calculate max dot clock as well with 99% limit > > > > >> > > v4 by Jani: > > > > >> > > - drop superfluous whitespace change > > > > >> > > - rewrite code comments to clarify > > > > >> > > > > > > >> > > Cc: Ander Conselvan de Oliveira > > > > >> > > > > > > >> > > Cc: Ville Syrjälä > > > > >> > > Signed-off-by: Madhav Chauhan > > > > >> > > Signed-off-by: Jani Nikula > > > > >> > > --- > > > > >> > > drivers/gpu/drm/i915/intel_cdclk.c | 16 +--- > > > > >> > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > >> > > > > > > >> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > > > > >> > > b/drivers/gpu/drm/i915/intel_cdclk.c > > > > >> > > index dd3ad52b7dfe..763010f8ad89 100644 > > > > >> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c > > > > >> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c > > > > >> > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int > > > > >> > > max_pixclk) > > > > >> > > > > > > >> > > static int glk_calc_cdclk(int max_pixclk) { > > > > >> > > -if (max_pixclk > 2 * 158400) > > > > >> > > +/* > > > > >> > > + * FIXME: Avoid using a pixel clock that is more than > > > > >> > > 99% of > > the cdclk > > > > >> > > + * as a temporary workaround. Use a higher cdclk > > > > >> > > instead. > > > > >> > > +(Note that > > > > >> > > > > > >> > Temporary workaround for what? Neither the comment nor the > > > > >> > commit message explicitly lists the scenario that triggers this > > > > >> > issue. > > > > >> > > > > >> Frankly I did not know what to write. > > > > > > > > > > > > > > >> There are issues with pixel clocks near cdclk that shouldn't > > > > >> happen. People are looking into this, but in the mean time dodge > > > > >> the issues by using higher cdclk. The issue should not be encoder > > > > >> specific, but in practice this has only been seen with DSI > > > > >> because there were some modes with pixel clocks that are near the > > > > >> cdclk. > > > > > > > > > > The above plus the model number of the DSI panel with which the > > > > > issue has been seen would be good enough IMO. > > > > > > > > Madhav? > > > > > > Issue is generic (valid for DP/HDMI) not just MIPI DSI specific. > > > Particular DSI panel exposing this issue as described below: > > > 1. For panel (19X12) required pixclk is 157100 KHZ > > > > And what is the actual pixel clock we end up using? As I've mentioned before > > our code is buggy because it assumes we can get any arbitrary clock > > frequency from the PLL. That is not generally true. > > > > So I'd like to know if the problem really is that we can't reach 100% of > > cdclk, > > or if we just end up with a pixel clock that slightly higher than what we > > asked > > for and thus exceeds 100% of cdclk. > > AFAIK (from testing, GOP team inputs), problem is that we can't reach > 100%CDCLK on GLK. > In this
Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply a cond_resched() to the saturated signaler (rev2)
On Tue, Apr 04, 2017 at 12:24:15PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Apply a cond_resched() to the saturated signaler (rev2) > URL : https://patchwork.freedesktop.org/series/22418/ > State : success > > == Summary == > > Series 22418v2 drm/i915: Apply a cond_resched() to the saturated signaler > https://patchwork.freedesktop.org/api/1.0/series/22418/revisions/2/mbox/ > > Test gem_exec_flush: > Subgroup basic-batch-kernel-default-uc: > fail -> PASS (fi-snb-2600) fdo#17 > Test gem_exec_suspend: > Subgroup basic-s4-devices: > pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 > pass -> DMESG-WARN (fi-bxt-t5700) fdo#100125 > Test kms_cursor_legacy: > Subgroup basic-busy-flip-before-cursor-legacy: > fail -> PASS (fi-snb-2600) > > fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 > fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 Unrelated. From the aether, Tvrtko wrote: > My thinking was to add a check before the request assignment like: > > rcu_read_lock(); > request = ...; > if (request && !need_resched()) > request = ...; > else > request = NULL; > rcu_read_unlock(); > > But this looks correct as well, maybe it is just my preference on what > would have been easier to understand. This has the danger of missing a wake-up reason. After setting TASK_INTERRUPTIBLE, we must then check all the possible wake-up sources before calling schedule, or else we risk another kthread_park() style bug. Thanks for the review and digging through the cond_resched() mystery. Pushed, -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH v2] drm/i915: Apply a cond_resched() to the saturated signaler
On 04/04/2017 13:05, Chris Wilson wrote: If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU, preventing the system from even processing ICMP echo replies. v2: Tvrtko dug into cond_resched() on x86 and found that it only depended upon preempt_cound and not tif_need_resched() - which means that we would always call schedule() at that point. Fixes: c81d46138da6 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by: Chris WilsonCc: Mika Kuoppala Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 308c56a021ab..9ccbf26124c6 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -580,6 +580,8 @@ static int intel_breadcrumbs_signaler(void *arg) signaler_set_rtpriority(); do { + bool do_schedule = true; + set_current_state(TASK_INTERRUPTIBLE); /* We are either woken up by the interrupt bottom-half, @@ -626,7 +628,18 @@ static int intel_breadcrumbs_signaler(void *arg) spin_unlock_irq(>rb_lock); i915_gem_request_put(request); - } else { + + /* If the engine is saturated we may be continually +* processing completed requests. This angers the +* NMI watchdog if we never let anything else +* have access to the CPU. Let's pretend to be nice +* and relinquish the CPU if we burn through the +* entire RT timeslice! +*/ + do_schedule = need_resched(); + } + + if (unlikely(do_schedule)) { DEFINE_WAIT(exec); if (kthread_should_park()) My thinking was to add a check before the request assignment like: rcu_read_lock(); request = ...; if (request && !need_resched()) request = ...; else request = NULL; rcu_read_unlock(); But this looks correct as well, maybe it is just my preference on what would have been easier to understand. I trust that you have tested it both for solving the NMI lockup detector issue and that it doesn't affect the signaller latency a lot. Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH] drm/i915: Park the signaler before sleeping
On Tue, Apr 04, 2017 at 10:57:15AM +0100, Tvrtko Ursulin wrote: > > On 03/04/2017 11:51, Chris Wilson wrote: > >If the signal to park arrives before we sleep, then we need to check > >kthread_should_park() before sleeping to avoid missing the signal. > >Otherwise, if the signal arrives whilst we are processing completed > >requests, we will reset the current->state back to TASK_INTERRUPTIBLE > >and so miss the wakeup. > > > >Fixes: fe3288b5da2c ("drm/i915: Park the breadcrumbs signaler across a GPU > >reset") > >Signed-off-by: Chris Wilson> >Cc: Mika Kuoppala > >Cc: Tvrtko Ursulin > >--- > > drivers/gpu/drm/i915/intel_breadcrumbs.c | 6 +++--- > > 1 file changed, 3 insertions(+), 3 deletions(-) > > > >diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c > >b/drivers/gpu/drm/i915/intel_breadcrumbs.c > >index b6ea192ad550..308c56a021ab 100644 > >--- a/drivers/gpu/drm/i915/intel_breadcrumbs.c > >+++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c > >@@ -629,6 +629,9 @@ static int intel_breadcrumbs_signaler(void *arg) > > } else { > > DEFINE_WAIT(exec); > > > >+if (kthread_should_park()) > >+kthread_parkme(); > >+ > > if (kthread_should_stop()) { > > GEM_BUG_ON(request); > > break; > >@@ -641,9 +644,6 @@ static int intel_breadcrumbs_signaler(void *arg) > > > > if (request) > > remove_wait_queue(>execute, ); > >- > >-if (kthread_should_park()) > >-kthread_parkme(); > > } > > i915_gem_request_put(request); > > } while (1); > > > > Reviewed-by: Tvrtko Ursulin Thanks, I have it my queue -- I'll push with the other signaler patch, hint hint ;) -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH i-g-t v2] tests/kms_atomic_allow_modeset: Add DRM_MODE_ATOMIC_ALLOW_MODESET test
Hey, Op 04-04-17 om 13:59 schreef Mika Kahola: > When doing a full atomic modeset, kernel should fail if the flag > DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of > Intel-GPU-Tools. The test procedure is the following: > > - Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET flag. > Kernel should reject this request. > - Do full modeset > - Enable DRM_MODE_ATOMIC_ALLOW_MODESET and try to do atmic commit. > Kernel should now allow atomic modeset. > > For: VIZ-6955 > > Signed-off-by: Mika Kahola> --- > tests/Makefile.sources | 1 + > tests/kms_atomic_allow_modeset.c | 133 > +++ > 2 files changed, 134 insertions(+) > create mode 100644 tests/kms_atomic_allow_modeset.c > > diff --git a/tests/Makefile.sources b/tests/Makefile.sources > index 45c21a0..d3ee629 100644 > --- a/tests/Makefile.sources > +++ b/tests/Makefile.sources > @@ -94,6 +94,7 @@ TESTS_progs_M = \ > kms_addfb_basic \ > kms_atomic \ > kms_atomic_transition \ > + kms_atomic_allow_modeset \ > kms_busy \ > kms_ccs \ > kms_chv_cursor_fail \ > diff --git a/tests/kms_atomic_allow_modeset.c > b/tests/kms_atomic_allow_modeset.c > new file mode 100644 > index 000..b4d8c16 > --- /dev/null > +++ b/tests/kms_atomic_allow_modeset.c > @@ -0,0 +1,133 @@ > +/* > + * Copyright © 2017 Intel Corporation > + * > + * Permission is hereby granted, free of charge, to any person obtaining a > + * copy of this software and associated documentation files (the "Software"), > + * to deal in the Software without restriction, including without limitation > + * the rights to use, copy, modify, merge, publish, distribute, sublicense, > + * and/or sell copies of the Software, and to permit persons to whom the > + * Software is furnished to do so, subject to the following conditions: > + * > + * The above copyright notice and this permission notice (including the next > + * paragraph) shall be included in all copies or substantial portions of the > + * Software. > + * > + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR > + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, > + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL > + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER > + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING > + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER > DEALINGS > + * IN THE SOFTWARE. > + * > + */ > + > +#include "igt.h" > + > +IGT_TEST_DESCRIPTION("Test that kernel rejects atomic modeset if > ALLOW_MODESET flag is not set"); > + > +static void > +test_init(igt_display_t *display, struct igt_fb *fb, igt_output_t *output) > +{ > + drmModeModeInfo *mode; > + igt_plane_t *primary; > + int id; > + > + mode = igt_output_get_mode(output); > + > + id = igt_create_pattern_fb(display->drm_fd, > +mode->hdisplay, mode->vdisplay, > +DRM_FORMAT_XRGB, > +LOCAL_I915_FORMAT_MOD_X_TILED, > +fb); > + igt_assert(id); > + > + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); > + igt_plane_set_fb(primary, fb); > +} > + > +static void > +test_finish(igt_display_t *display, struct igt_fb *fb, igt_output_t *output) > +{ > + igt_plane_t *primary; > + > + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); > + > + igt_remove_fb(display->drm_fd, fb); > + > + igt_plane_set_fb(primary, NULL); > + igt_output_set_pipe(output, PIPE_ANY); > + > + igt_display_commit2(display, COMMIT_ATOMIC); > +} > + > +static void > +test_allow_modeset(igt_display_t *display, enum pipe pipe, igt_output_t > *output) > +{ > + struct igt_fb fb; > + int flags = DRM_MODE_ATOMIC_NONBLOCK; > + int ret; > + > + igt_output_set_pipe(output, pipe); > + > + test_init(display, , output); > + > + /* > + * Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET flag. > + * Kernel should reject this request. > + */ > + ret = igt_display_try_commit_atomic(display, flags, NULL); > + igt_assert_eq(ret, -EINVAL); > + > + /* do modeset */ > + igt_output_set_pipe(output, pipe); > + > + /* > + * Try to do atomic commit with DRM_MODE_ATOMIC_ALLOW_MODESET flag set. > + * The kernel should now accept this request. > + */ > + flags |= DRM_MODE_ATOMIC_ALLOW_MODESET; > + ret = igt_display_try_commit_atomic(display, flags, NULL); > + igt_assert_eq(ret, 0); > + > + test_finish(display, , output); > +} > + > +igt_simple_main > +{ > + igt_output_t *output; > + igt_display_t display; > + drmModeResPtr res; > + enum pipe pipe; > + > + igt_skip_on_simulation(); > + > + igt_fixture {
[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Apply a cond_resched() to the saturated signaler (rev2)
== Series Details == Series: drm/i915: Apply a cond_resched() to the saturated signaler (rev2) URL : https://patchwork.freedesktop.org/series/22418/ State : success == Summary == Series 22418v2 drm/i915: Apply a cond_resched() to the saturated signaler https://patchwork.freedesktop.org/api/1.0/series/22418/revisions/2/mbox/ Test gem_exec_flush: Subgroup basic-batch-kernel-default-uc: fail -> PASS (fi-snb-2600) fdo#17 Test gem_exec_suspend: Subgroup basic-s4-devices: pass -> DMESG-WARN (fi-kbl-7560u) fdo#100125 pass -> DMESG-WARN (fi-bxt-t5700) fdo#100125 Test kms_cursor_legacy: Subgroup basic-busy-flip-before-cursor-legacy: fail -> PASS (fi-snb-2600) fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17 fdo#100125 https://bugs.freedesktop.org/show_bug.cgi?id=100125 fi-bdw-5557u total:278 pass:267 dwarn:0 dfail:0 fail:0 skip:11 time: 433s fi-bdw-gvtdvmtotal:278 pass:256 dwarn:8 dfail:0 fail:0 skip:14 time: 427s fi-bsw-n3050 total:278 pass:239 dwarn:0 dfail:0 fail:0 skip:39 time: 573s fi-bxt-j4205 total:278 pass:259 dwarn:0 dfail:0 fail:0 skip:19 time: 509s fi-bxt-t5700 total:278 pass:257 dwarn:1 dfail:0 fail:0 skip:20 time: 548s fi-byt-j1900 total:278 pass:251 dwarn:0 dfail:0 fail:0 skip:27 time: 484s fi-byt-n2820 total:278 pass:247 dwarn:0 dfail:0 fail:0 skip:31 time: 478s fi-hsw-4770 total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 414s fi-hsw-4770r total:278 pass:262 dwarn:0 dfail:0 fail:0 skip:16 time: 409s fi-ilk-650 total:278 pass:228 dwarn:0 dfail:0 fail:0 skip:50 time: 416s fi-ivb-3520m total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 483s fi-ivb-3770 total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 468s fi-kbl-7500u total:278 pass:260 dwarn:0 dfail:0 fail:0 skip:18 time: 462s fi-kbl-7560u total:278 pass:267 dwarn:1 dfail:0 fail:0 skip:10 time: 566s fi-skl-6260u total:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 457s fi-skl-6700hqtotal:278 pass:261 dwarn:0 dfail:0 fail:0 skip:17 time: 568s fi-skl-6700k total:278 pass:256 dwarn:4 dfail:0 fail:0 skip:18 time: 461s fi-skl-6770hqtotal:278 pass:268 dwarn:0 dfail:0 fail:0 skip:10 time: 495s fi-skl-gvtdvmtotal:278 pass:265 dwarn:0 dfail:0 fail:0 skip:13 time: 438s fi-snb-2520m total:278 pass:250 dwarn:0 dfail:0 fail:0 skip:28 time: 532s fi-snb-2600 total:278 pass:249 dwarn:0 dfail:0 fail:0 skip:29 time: 402s abec0508865ae60a2bb30ca3ba5ca2c4ac49afc5 drm-tip: 2017y-04m-04d-08h-52m-39s UTC integration manifest e15d53e drm/i915: Apply a cond_resched() to the saturated signaler == Logs == For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4392/ ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH v2] drm/i915: Apply a cond_resched() to the saturated signaler
If the engine is continually completing nops, we can saturate the signaler and keep it working indefinitely. This angers the NMI watchdog! A good example is to disable semaphores on snb and run igt/gem_exec_nop - the parallel, multi-engine workloads are more than sufficient to hog the CPU, preventing the system from even processing ICMP echo replies. v2: Tvrtko dug into cond_resched() on x86 and found that it only depended upon preempt_cound and not tif_need_resched() - which means that we would always call schedule() at that point. Fixes: c81d46138da6 ("drm/i915: Convert trace-irq to the breadcrumb waiter") Signed-off-by: Chris WilsonCc: Mika Kuoppala Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 15 ++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/drivers/gpu/drm/i915/intel_breadcrumbs.c b/drivers/gpu/drm/i915/intel_breadcrumbs.c index 308c56a021ab..9ccbf26124c6 100644 --- a/drivers/gpu/drm/i915/intel_breadcrumbs.c +++ b/drivers/gpu/drm/i915/intel_breadcrumbs.c @@ -580,6 +580,8 @@ static int intel_breadcrumbs_signaler(void *arg) signaler_set_rtpriority(); do { + bool do_schedule = true; + set_current_state(TASK_INTERRUPTIBLE); /* We are either woken up by the interrupt bottom-half, @@ -626,7 +628,18 @@ static int intel_breadcrumbs_signaler(void *arg) spin_unlock_irq(>rb_lock); i915_gem_request_put(request); - } else { + + /* If the engine is saturated we may be continually +* processing completed requests. This angers the +* NMI watchdog if we never let anything else +* have access to the CPU. Let's pretend to be nice +* and relinquish the CPU if we burn through the +* entire RT timeslice! +*/ + do_schedule = need_resched(); + } + + if (unlikely(do_schedule)) { DEFINE_WAIT(exec); if (kthread_should_park()) -- 2.11.0 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH i-g-t v2] tests/kms_atomic_allow_modeset: Add DRM_MODE_ATOMIC_ALLOW_MODESET test
When doing a full atomic modeset, kernel should fail if the flag DRM_MODE_ATOMIC_ALLOW_MODESET is not set. Let's add this test as part of Intel-GPU-Tools. The test procedure is the following: - Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET flag. Kernel should reject this request. - Do full modeset - Enable DRM_MODE_ATOMIC_ALLOW_MODESET and try to do atmic commit. Kernel should now allow atomic modeset. For: VIZ-6955 Signed-off-by: Mika Kahola--- tests/Makefile.sources | 1 + tests/kms_atomic_allow_modeset.c | 133 +++ 2 files changed, 134 insertions(+) create mode 100644 tests/kms_atomic_allow_modeset.c diff --git a/tests/Makefile.sources b/tests/Makefile.sources index 45c21a0..d3ee629 100644 --- a/tests/Makefile.sources +++ b/tests/Makefile.sources @@ -94,6 +94,7 @@ TESTS_progs_M = \ kms_addfb_basic \ kms_atomic \ kms_atomic_transition \ + kms_atomic_allow_modeset \ kms_busy \ kms_ccs \ kms_chv_cursor_fail \ diff --git a/tests/kms_atomic_allow_modeset.c b/tests/kms_atomic_allow_modeset.c new file mode 100644 index 000..b4d8c16 --- /dev/null +++ b/tests/kms_atomic_allow_modeset.c @@ -0,0 +1,133 @@ +/* + * Copyright © 2017 Intel Corporation + * + * Permission is hereby granted, free of charge, to any person obtaining a + * copy of this software and associated documentation files (the "Software"), + * to deal in the Software without restriction, including without limitation + * the rights to use, copy, modify, merge, publish, distribute, sublicense, + * and/or sell copies of the Software, and to permit persons to whom the + * Software is furnished to do so, subject to the following conditions: + * + * The above copyright notice and this permission notice (including the next + * paragraph) shall be included in all copies or substantial portions of the + * Software. + * + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS + * IN THE SOFTWARE. + * + */ + +#include "igt.h" + +IGT_TEST_DESCRIPTION("Test that kernel rejects atomic modeset if ALLOW_MODESET flag is not set"); + +static void +test_init(igt_display_t *display, struct igt_fb *fb, igt_output_t *output) +{ + drmModeModeInfo *mode; + igt_plane_t *primary; + int id; + + mode = igt_output_get_mode(output); + + id = igt_create_pattern_fb(display->drm_fd, + mode->hdisplay, mode->vdisplay, + DRM_FORMAT_XRGB, + LOCAL_I915_FORMAT_MOD_X_TILED, + fb); + igt_assert(id); + + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); + igt_plane_set_fb(primary, fb); +} + +static void +test_finish(igt_display_t *display, struct igt_fb *fb, igt_output_t *output) +{ + igt_plane_t *primary; + + primary = igt_output_get_plane_type(output, DRM_PLANE_TYPE_PRIMARY); + + igt_remove_fb(display->drm_fd, fb); + + igt_plane_set_fb(primary, NULL); + igt_output_set_pipe(output, PIPE_ANY); + + igt_display_commit2(display, COMMIT_ATOMIC); +} + +static void +test_allow_modeset(igt_display_t *display, enum pipe pipe, igt_output_t *output) +{ + struct igt_fb fb; + int flags = DRM_MODE_ATOMIC_NONBLOCK; + int ret; + + igt_output_set_pipe(output, pipe); + + test_init(display, , output); + + /* +* Try to do atomic commit without DRM_MODE_ATOMIC_ALLOW_MODESET flag. +* Kernel should reject this request. +*/ + ret = igt_display_try_commit_atomic(display, flags, NULL); + igt_assert_eq(ret, -EINVAL); + + /* do modeset */ + igt_output_set_pipe(output, pipe); + + /* +* Try to do atomic commit with DRM_MODE_ATOMIC_ALLOW_MODESET flag set. +* The kernel should now accept this request. +*/ + flags |= DRM_MODE_ATOMIC_ALLOW_MODESET; + ret = igt_display_try_commit_atomic(display, flags, NULL); + igt_assert_eq(ret, 0); + + test_finish(display, , output); +} + +igt_simple_main +{ + igt_output_t *output; + igt_display_t display; + drmModeResPtr res; + enum pipe pipe; + + igt_skip_on_simulation(); + + igt_fixture { + int valid_outputs = 0; + + display.drm_fd = drm_open_driver_master(DRIVER_ANY); + igt_enable_connectors(); + kmstest_set_vt_graphics_mode(); + igt_display_init(,
Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround
> -Original Message- > From: Ville Syrjälä [mailto:ville.syrj...@linux.intel.com] > Sent: Tuesday, April 4, 2017 5:09 PM > To: Chauhan, Madhav> Cc: Nikula, Jani ; Ander Conselvan De Oliveira > ; intel-gfx@lists.freedesktop.org > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > workaround > > On Tue, Apr 04, 2017 at 10:27:57AM +, Chauhan, Madhav wrote: > > > -Original Message- > > > From: Nikula, Jani > > > Sent: Tuesday, April 4, 2017 3:48 PM > > > To: Ander Conselvan De Oliveira ; intel- > > > g...@lists.freedesktop.org > > > Cc: Chauhan, Madhav ; Ville Syrjälä > > > > > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > > > workaround > > > > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > > > wrote: > > > > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: > > > >> On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > wrote: > > > >> > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > > > >> > > From: Madhav Chauhan > > > >> > > > > > >> > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 > > > >> > > Mhz. > > > >> > > Practically we can achive only 99% of these cdclk values (HW > > > >> > > team checking on this). So cdclk should be calculated for the > > > >> > > given pixclk as per that otherwise it may lead to screen > > > >> > > corruption for some > > > scenarios. > > > >> > > > > > >> > > v2: Rebased to new CDLCK code framework > > > >> > > v3: Addressed review comments from Ander/Jani > > > >> > > - Add comment in code about 99% usage of CDCLK > > > >> > > - Calculate max dot clock as well with 99% limit > > > >> > > v4 by Jani: > > > >> > > - drop superfluous whitespace change > > > >> > > - rewrite code comments to clarify > > > >> > > > > > >> > > Cc: Ander Conselvan de Oliveira > > > >> > > > > > >> > > Cc: Ville Syrjälä > > > >> > > Signed-off-by: Madhav Chauhan > > > >> > > Signed-off-by: Jani Nikula > > > >> > > --- > > > >> > > drivers/gpu/drm/i915/intel_cdclk.c | 16 +--- > > > >> > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > >> > > > > > >> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > > > >> > > b/drivers/gpu/drm/i915/intel_cdclk.c > > > >> > > index dd3ad52b7dfe..763010f8ad89 100644 > > > >> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c > > > >> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c > > > >> > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int > > > >> > > max_pixclk) > > > >> > > > > > >> > > static int glk_calc_cdclk(int max_pixclk) { > > > >> > > - if (max_pixclk > 2 * 158400) > > > >> > > + /* > > > >> > > + * FIXME: Avoid using a pixel clock that is more than 99% of > the cdclk > > > >> > > + * as a temporary workaround. Use a higher cdclk instead. > > > >> > > +(Note that > > > >> > > > > >> > Temporary workaround for what? Neither the comment nor the > > > >> > commit message explicitly lists the scenario that triggers this > > > >> > issue. > > > >> > > > >> Frankly I did not know what to write. > > > > > > > > > > > >> There are issues with pixel clocks near cdclk that shouldn't > > > >> happen. People are looking into this, but in the mean time dodge > > > >> the issues by using higher cdclk. The issue should not be encoder > > > >> specific, but in practice this has only been seen with DSI > > > >> because there were some modes with pixel clocks that are near the > > > >> cdclk. > > > > > > > > The above plus the model number of the DSI panel with which the > > > > issue has been seen would be good enough IMO. > > > > > > Madhav? > > > > Issue is generic (valid for DP/HDMI) not just MIPI DSI specific. > > Particular DSI panel exposing this issue as described below: > > 1. For panel (19X12) required pixclk is 157100 KHZ > > And what is the actual pixel clock we end up using? As I've mentioned before > our code is buggy because it assumes we can get any arbitrary clock > frequency from the PLL. That is not generally true. > > So I'd like to know if the problem really is that we can't reach 100% of > cdclk, > or if we just end up with a pixel clock that slightly higher than what we > asked > for and thus exceeds 100% of cdclk. AFAIK (from testing, GOP team inputs), problem is that we can't reach 100%CDCLK on GLK. In this scenario calculated/required pixel clock is 157100 KHZ (might be higher due to buggy code as you mentioned) which should be handled very well if we set CDCLK 79200 KHZ but causes panel corruption. > > And if the problem is really that we can't reach 100% of cdclk, then why are > we limiting this to GLK only? From discussion,
Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround
> -Original Message- > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > Sent: Tuesday, April 4, 2017 4:13 PM > To: Chauhan, Madhav; Nikula, Jani > ; intel-gfx@lists.freedesktop.org > Cc: Ville Syrjälä > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > workaround > > On Tue, 2017-04-04 at 10:27 +, Chauhan, Madhav wrote: > > > -Original Message- > > > From: Nikula, Jani > > > Sent: Tuesday, April 4, 2017 3:48 PM > > > To: Ander Conselvan De Oliveira ; intel- > > > g...@lists.freedesktop.org > > > Cc: Chauhan, Madhav ; Ville Syrjälä > > > > > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > > > workaround > > > > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > > > wrote: > > > > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: > > > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > > > > > wrote: > > > > > > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > > > > > > > From: Madhav Chauhan > > > > > > > > > > > > > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 > > > > > > > Mhz. > > > > > > > Practically we can achive only 99% of these cdclk values (HW > > > > > > > team checking on this). So cdclk should be calculated for > > > > > > > the given pixclk as per that otherwise it may lead to screen > > > > > > > corruption for some > > > > > > scenarios. > > > > > > > > > > > > > > v2: Rebased to new CDLCK code framework > > > > > > > v3: Addressed review comments from Ander/Jani > > > > > > > - Add comment in code about 99% usage of CDCLK > > > > > > > - Calculate max dot clock as well with 99% limit > > > > > > > v4 by Jani: > > > > > > > - drop superfluous whitespace change > > > > > > > - rewrite code comments to clarify > > > > > > > > > > > > > > Cc: Ander Conselvan de Oliveira > > > > > > > > > > > > > > Cc: Ville Syrjälä > > > > > > > Signed-off-by: Madhav Chauhan > > > > > > > Signed-off-by: Jani Nikula > > > > > > > --- > > > > > > > drivers/gpu/drm/i915/intel_cdclk.c | 16 +--- > > > > > > > 1 file changed, 13 insertions(+), 3 deletions(-) > > > > > > > > > > > > > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > > > > > > > b/drivers/gpu/drm/i915/intel_cdclk.c > > > > > > > index dd3ad52b7dfe..763010f8ad89 100644 > > > > > > > --- a/drivers/gpu/drm/i915/intel_cdclk.c > > > > > > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c > > > > > > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int > > > > > > > max_pixclk) > > > > > > > > > > > > > > static int glk_calc_cdclk(int max_pixclk) { > > > > > > > - if (max_pixclk > 2 * 158400) > > > > > > > + /* > > > > > > > + * FIXME: Avoid using a pixel clock that is more than 99% of > the cdclk > > > > > > > + * as a temporary workaround. Use a higher cdclk instead. > > > > > > > +(Note that > > > > > > > > > > > > Temporary workaround for what? Neither the comment nor the > > > > > > commit message explicitly lists the scenario that triggers this > > > > > > issue. > > > > > > > > > > Frankly I did not know what to write. > > > > > > > > > > > > > There are issues with pixel clocks near cdclk that shouldn't > > > > > happen. People are looking into this, but in the mean time dodge > > > > > the issues by using higher cdclk. The issue should not be > > > > > encoder specific, but in practice this has only been seen with > > > > > DSI because there were some modes with pixel clocks that are > > > > > near the cdclk. > > > > > > > > The above plus the model number of the DSI panel with which the > > > > issue has been seen would be good enough IMO. > > > > > > Madhav? > > > > Issue is generic (valid for DP/HDMI) not just MIPI DSI specific. > > Particular DSI panel exposing this issue as described below: > > 1. For panel (19X12) required pixclk is 157100 KHZ 2. > > glk_calc_cdclk returns 79200 KHZ for this pixclk. For 2PPC it will be > > 158400 KHZ 3. Practically 100% of the cdclk can’t be achieved, so 99% of > 158400 KHZ = 156816 which is less than the desired pixlclk. > > This causes the corruption. > > > > So why do we need to mention a particular panel?? > > If someone else needs to deal with this six months or a year from now and > you, me and Jani are nowhere to be found, the code or commit message > should still have enough information to let that person assess whether it is > safe to remove the workaround or not. Having the model number just makes > it easier to determine what real world scenario triggers this problem, so it > is > easier to test a fix. Agree from this perspective. Will add this explanation in commit
Re: [Intel-gfx] [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk workaround
On Tue, Apr 04, 2017 at 10:27:57AM +, Chauhan, Madhav wrote: > > -Original Message- > > From: Nikula, Jani > > Sent: Tuesday, April 4, 2017 3:48 PM > > To: Ander Conselvan De Oliveira; intel- > > g...@lists.freedesktop.org > > Cc: Chauhan, Madhav ; Ville Syrjälä > > > > Subject: Re: [PATCH] drm/i915/glk: limit pixel clock to 99% of cdclk > > workaround > > > > On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > wrote: > > > On Tue, 2017-04-04 at 11:40 +0300, Jani Nikula wrote: > > >> On Tue, 04 Apr 2017, Ander Conselvan De Oliveira > > wrote: > > >> > On Tue, 2017-04-04 at 11:15 +0300, Jani Nikula wrote: > > >> > > From: Madhav Chauhan > > >> > > > > >> > > As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. > > >> > > Practically we can achive only 99% of these cdclk values (HW team > > >> > > checking on this). So cdclk should be calculated for the given > > >> > > pixclk as per that otherwise it may lead to screen corruption for > > >> > > some > > scenarios. > > >> > > > > >> > > v2: Rebased to new CDLCK code framework > > >> > > v3: Addressed review comments from Ander/Jani > > >> > > - Add comment in code about 99% usage of CDCLK > > >> > > - Calculate max dot clock as well with 99% limit > > >> > > v4 by Jani: > > >> > > - drop superfluous whitespace change > > >> > > - rewrite code comments to clarify > > >> > > > > >> > > Cc: Ander Conselvan de Oliveira > > >> > > > > >> > > Cc: Ville Syrjälä > > >> > > Signed-off-by: Madhav Chauhan > > >> > > Signed-off-by: Jani Nikula > > >> > > --- > > >> > > drivers/gpu/drm/i915/intel_cdclk.c | 16 +--- > > >> > > 1 file changed, 13 insertions(+), 3 deletions(-) > > >> > > > > >> > > diff --git a/drivers/gpu/drm/i915/intel_cdclk.c > > >> > > b/drivers/gpu/drm/i915/intel_cdclk.c > > >> > > index dd3ad52b7dfe..763010f8ad89 100644 > > >> > > --- a/drivers/gpu/drm/i915/intel_cdclk.c > > >> > > +++ b/drivers/gpu/drm/i915/intel_cdclk.c > > >> > > @@ -1071,9 +1071,15 @@ static int bxt_calc_cdclk(int max_pixclk) > > >> > > > > >> > > static int glk_calc_cdclk(int max_pixclk) { > > >> > > -if (max_pixclk > 2 * 158400) > > >> > > +/* > > >> > > + * FIXME: Avoid using a pixel clock that is more than 99% of > > >> > > the cdclk > > >> > > + * as a temporary workaround. Use a higher cdclk instead. (Note > > >> > > +that > > >> > > > >> > Temporary workaround for what? Neither the comment nor the commit > > >> > message explicitly lists the scenario that triggers this issue. > > >> > > >> Frankly I did not know what to write. > > > > > > > > >> There are issues with pixel clocks > > >> near cdclk that shouldn't happen. People are looking into this, but > > >> in the mean time dodge the issues by using higher cdclk. The issue > > >> should not be encoder specific, but in practice this has only been > > >> seen with DSI because there were some modes with pixel clocks that > > >> are near the cdclk. > > > > > > The above plus the model number of the DSI panel with which the issue > > > has been seen would be good enough IMO. > > > > Madhav? > > Issue is generic (valid for DP/HDMI) not just MIPI DSI specific. Particular > DSI panel > exposing this issue as described below: > 1. For panel (19X12) required pixclk is 157100 KHZ And what is the actual pixel clock we end up using? As I've mentioned before our code is buggy because it assumes we can get any arbitrary clock frequency from the PLL. That is not generally true. So I'd like to know if the problem really is that we can't reach 100% of cdclk, or if we just end up with a pixel clock that slightly higher than what we asked for and thus exceeds 100% of cdclk. And if the problem is really that we can't reach 100% of cdclk, then why are we limiting this to GLK only? > 2. glk_calc_cdclk returns 79200 KHZ for this pixclk. For 2PPC it will be > 158400 KHZ > 3. Practically 100% of the cdclk can’t be achieved, so 99% of 158400 KHZ = > 156816 which is less than the desired pixlclk. > This causes the corruption. > > So why do we need to mention a particular panel?? > > > > > > > > > > > Ander > > > > > > > > >> > With that fixed, > > >> > > > >> > Reviewed-by: Ander Conselvan de Oliveira > > >> > > > >> > > + * intel_compute_max_dotclk() limits the max pixel clock to 99% > > >> > > of > > max > > >> > > + * cdclk.) > > >> > > + */ > > >> > > +if (max_pixclk > DIV_ROUND_UP(2 * 158400 * 99, 100)) > > >> > > return 316800; > > >> > > -else if (max_pixclk > 2 * 79200) > > >> > > +else if (max_pixclk > DIV_ROUND_UP(2 * 79200 * 99, 100)) > > >> > > return 158400; > > >> > > else > > >> >