[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/1] drm/i915: Suspend GuC during GEM Suspend prior to GPU Reset

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Sagar Arun Kamble
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 McGee 
Cc: 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

2017-04-04 Thread Patchwork
== 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.

2017-04-04 Thread Wang, Quanxian
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.

2017-04-04 Thread Yang, Libin
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.

2017-04-04 Thread Yang, 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.

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.

2017-04-04 Thread Wang, Quanxian
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)

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Chuanxiao Dong
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

2017-04-04 Thread Chuanxiao Dong
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

2017-04-04 Thread Chuanxiao Dong
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

2017-04-04 Thread Xiong Zhang
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 Zhang 
Reviewed-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

2017-04-04 Thread Manasi Navare
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

2017-04-04 Thread Manasi Navare
On Wed, Mar 29, 2017 at 10:22:32AM +0300, Jani Nikula wrote:
> On Wed, 29 Mar 2017, Manasi Navare  wrote:
> > 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

2017-04-04 Thread Manasi Navare
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

2017-04-04 Thread Manasi Navare
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

2017-04-04 Thread Manasi Navare
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

2017-04-04 Thread Manasi Navare

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

2017-04-04 Thread Stephen Rothwell
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)

2017-04-04 Thread Pandiyan, Dhinakaran

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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
Export color_differs so that we can use it elsewhere.

v2: better naming

Signed-off-by: Matthew Auld 
Cc: 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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
Rid the code of any mm.color_adjust assumptions to allow adding another
flavour of coloring.

v2: better naming

Signed-off-by: Matthew Auld 
Cc: 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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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 Auld 
Cc: 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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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

2017-04-04 Thread Matthew Auld
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)

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Dhinakaran Pandiyan
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

2017-04-04 Thread Dhinakaran Pandiyan
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

2017-04-04 Thread Dhinakaran Pandiyan
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

2017-04-04 Thread Dhinakaran Pandiyan
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

2017-04-04 Thread Dhinakaran Pandiyan
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

2017-04-04 Thread Manasi Navare
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()

2017-04-04 Thread Manasi Navare
On Wed, Mar 29, 2017 at 10:17:41AM +0300, Jani Nikula wrote:
> On Tue, 28 Mar 2017, Manasi Navare  wrote:
> > 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

2017-04-04 Thread Manasi Navare
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

2017-04-04 Thread Daniel Vetter
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

2017-04-04 Thread Daniel Vetter
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'

2017-04-04 Thread Patchwork
== 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'

2017-04-04 Thread Dhinakaran Pandiyan
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

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Ville Syrjälä
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

2017-04-04 Thread Maarten Lankhorst
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Daniel Vetter
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Joonas Lahtinen
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]

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Neil Armstrong
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

2017-04-04 Thread Chris Wilson
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 Wilson 
Cc: 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

2017-04-04 Thread Patchwork
== 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."

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Jani Nikula
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

2017-04-04 Thread Jani Nikula
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

2017-04-04 Thread Jani Nikula
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

2017-04-04 Thread Jani Nikula
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

2017-04-04 Thread Tvrtko Ursulin


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 Wajdeczko 
Cc: 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

2017-04-04 Thread Michal Wajdeczko
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 Wajdeczko 
Cc: 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

2017-04-04 Thread Chauhan, Madhav
> -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()

2017-04-04 Thread Tvrtko Ursulin


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

2017-04-04 Thread Maarten Lankhorst
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."

2017-04-04 Thread Maarten Lankhorst
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

2017-04-04 Thread Chris Wilson
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

2017-04-04 Thread Chris Wilson
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 
Reviewed-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

2017-04-04 Thread Chris Wilson
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 Wilson 
Cc: 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

2017-04-04 Thread Chris Wilson
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 Wilson 
Reviewed-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

2017-04-04 Thread Chris Wilson
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

2017-04-04 Thread Ville Syrjälä
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)

2017-04-04 Thread Chris Wilson
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

2017-04-04 Thread Tvrtko Ursulin


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 Wilson 
Cc: 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

2017-04-04 Thread Chris Wilson
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

2017-04-04 Thread Maarten Lankhorst
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)

2017-04-04 Thread Patchwork
== 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

2017-04-04 Thread Chris Wilson
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 Wilson 
Cc: 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

2017-04-04 Thread 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 {
+   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

2017-04-04 Thread Chauhan, Madhav
> -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

2017-04-04 Thread Chauhan, Madhav
> -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

2017-04-04 Thread Ville Syrjälä
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
> > >> > 

  1   2   >