Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually for KBL.

[Wang, Quanxian]

Hi, Jani

After testing on 4K monitor. It is fine to get audio with our patch on 
KBL platform. We have tested with 'speaker' command and "play mp3/mp4 
directly", not 
found delay for DP audio.

Libin is fine with this patch.

Any comment, please let me know.

Thanks

Quanxian Wang


-Original Message-
From: Wang, Quanxian 
Sent: Wednesday, April 5, 2017 10:36 AM
To: Yang, Libin 
Cc: Jani Nikula ; intel-gfx@lists.freedesktop.org; 
Cui, YuepingX ; Wang, Quanxian 
Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually 
for KBL.

Hi, Libin

We don't have 4K resolution monitor. We will double check others resolutions.

-Original Message-
From: Yang, Libin 
Sent: Wednesday, April 5, 2017 10:22 AM
To: Jani Nikula ; Wang, Quanxian 
; intel-gfx@lists.freedesktop.org
Subject: RE: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value manually 
for KBL.


>-Original Message-
>From: Jani Nikula [mailto:jani.nik...@linux.intel.com]
>Sent: Tuesday, April 4, 2017 6:55 PM
>To: Wang, Quanxian ; intel- 
>g...@lists.freedesktop.org
>Cc: Yang, Libin 
>Subject: Re: [Intel-gfx] [PATCH] drm/i915/audio: not to set N/M value 
>manually for KBL.
>
>On Sat, 01 Apr 2017, Quanxian Wang  wrote:
>> It doesn't work on KBL. Just using automatic N/M.
>
>Please provide a more elaborate commit message. In particular, have a 
>look at
>
>commit 6014ac122ed081feca99217bc57b2e15c7fc1a51
>Author: Libin Yang 
>Date:   Tue Oct 25 17:54:18 2016 +0300
>
>drm/i915/audio: set proper N/M in modeset
>
>and explain why that doesn't apply to KBL. And why just KBL, why not others?
>
>> According to the bspec, when set N/M, should disable and enable 
>> transcoder which attaching DP audio. but there is no such code to do 
>> that.
>> without this implementation except KBL platforms, seems work well.

Is this a mandatory requirement on the new platform?
[Wang, Quanxian] yes. At least bspec said that with 'NOTE'.
We saw "disable and enable transcoder" requirement on old platforms.
But it will dramatically impact on the user experience. After discussion, we 
skipped this step and did a lot of test on the old platforms. They all works.
[Wang, Quanxian] Seems to be in old platforms.

I suggested that we can talk with silicon team to figure out a proper solution, 
because on the new platform we may also meet the same situations like old 
platforms that some resolution will not work properly.

BTW: please test the playback on 4K resolution to see whether the playback and 
delay is normal. 4K is often an issue.

Regards,
Libin

>>
>> Signed-off-by: Quanxian Wang 
>> Tested-By: Wang Zhijun
>> Tested-By: Cui Yueping
>> ---
>>  drivers/gpu/drm/i915/intel_audio.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/i915/intel_audio.c
>> b/drivers/gpu/drm/i915/intel_audio.c
>> index 52c207e..0542031 100644
>> --- a/drivers/gpu/drm/i915/intel_audio.c
>> +++ b/drivers/gpu/drm/i915/intel_audio.c
>> @@ -300,7 +300,7 @@ hsw_dp_audio_config_update(struct intel_crtc
>*intel_crtc, enum port port,
>>  tmp &= ~AUD_CONFIG_N_PROG_ENABLE;
>>  tmp |= AUD_CONFIG_N_VALUE_INDEX;
>>
>> -if (nm) {
>> +if (!IS_KABYLAKE(dev_priv) && nm) {
>>  tmp &= ~AUD_CONFIG_N_MASK;
>>  tmp |= AUD_CONFIG_N(nm->n);
>>  tmp |= AUD_CONFIG_N_PROG_ENABLE;
>> @@ -308,6 +308,9 @@ hsw_dp_audio_config_update(struct intel_crtc 
>> *intel_crtc, enum port port,
>>
>>  I915_WRITE(HSW_AUD_CFG(pipe), tmp);
>>
>> +if (IS_KABYLAKE(dev_priv))
>> +return;
>> +
>
>The debug logging near the top of the function will be wrong for KBL, 
>and you now bypass HSW_AUD_M_CTS_ENABLE() setting for the automatic values.
>
>Seems to me the simplest would be to do
>
>   if (IS_KABYLAKE(dev_priv))
>   nm = NULL;
>
>*but* this still needs better rationale, especially why this is specific to 
>KBL.
>
>BR,
>Jani.
>
>
>>  tmp = I915_READ(HSW_AUD_M_CTS_ENABLE(pipe));
>>  tmp &= ~AUD_CONFIG_M_MASK;
>>  tmp &= ~AUD_M_CTS_M_VALUE_INDEX;
>
>--
>Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: i915: Preserve old FBC status if update with no new planes

[Manasi Navare]

On Tue, May 16, 2017 at 10:27:33PM -0300, Gabriel Krisman Bertazi wrote:
> Manasi Navare  writes:
> 
> Hi Manasi,
> 
> > So the purpose of this patch is to avoid overwriting the no_fbc_reason
> > field during atomic_check in case there is no plane update so that
> > it retains the actual failure message from previous atomic commit operation
> > failure where it failed to enable fbc in intel_fbc_can_enable() during
> > the post plane update right?
> 
> yes, correct.
> 
> > On Mon, May 15, 2017 at 09:33:04PM -0300, Gabriel Krisman Bertazi wrote:
> >> If the atomic commit doesn't include any new plane, there is no need to
> >> choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out
> >> early.  Although, if the FBC setup failed beforehand for whatever reason,
> >> we don't bail early, but we change the no_fbc_reason to "no suitable
> >> CRTC for FBC", which simply hides the real reason why the FBC wasn't
> >
> > I think this can be reworded a bit like " Although, if the FBC setup failed
> > in the previous commit, if the current commit doesnt include new plane 
> > update,
> > it tries to overwrite no_fbc_reason to "no suitable CRTC for FBC".
> >
> >
> >> initialized.  For that scenario, it is better that we simply keep the
> >> old message in-place to make debugging easier.
> >> 
> >> A scenario where this happens is with the
> >> igt@kms_frontbuffer_tracking@fbc-suspend testcase when executed on a
> >> Haswell system with not enough stolen memory.  When enabling the CRTC,
> >> the FBC setup will be correctly initialized to a specific CRTC, but
> >> won't be enabled, since there is not enough memory.  The testcase will
> >> then enable CRC checking, which requires a quirk for Haswell, which
> >> issues a new atomic commit that doesn't update the planes.  Since that
> >> update doesn't include any new planes (and the FBC wasn't enabled),
> >> intel_fbc_choose_crtc() will not find any suitable CRTC, but update the
> >> error message, hiding the lack of memory information, which is the
> >> actual cause of the initialization failure.  As a result, this causes
> >> that test to fail on Haswell.
> >
> > So the problem here is just a wrong error message.
> > How does a wrong error message cause the IGT test to fail?
> 
> igt is prepared to skip the test on boxes where there isn't enough
> stolen memory, but since we overwrite that message, the test will
> execute and fail.  We discussed earlier on the list about adding a new
> check to igt for the "no suitable CRTC for FBC" message, but that could
> end up hiding other real error conditions.
>

Ok, yes then this fix makes sense. In that case it looks good to me.

Manasi 
> -- 
> Gabriel Krisman Bertazi
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: i915: Preserve old FBC status if update with no new planes

[Gabriel Krisman Bertazi]

Manasi Navare  writes:

Hi Manasi,

> So the purpose of this patch is to avoid overwriting the no_fbc_reason
> field during atomic_check in case there is no plane update so that
> it retains the actual failure message from previous atomic commit operation
> failure where it failed to enable fbc in intel_fbc_can_enable() during
> the post plane update right?

yes, correct.

> On Mon, May 15, 2017 at 09:33:04PM -0300, Gabriel Krisman Bertazi wrote:
>> If the atomic commit doesn't include any new plane, there is no need to
>> choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out
>> early.  Although, if the FBC setup failed beforehand for whatever reason,
>> we don't bail early, but we change the no_fbc_reason to "no suitable
>> CRTC for FBC", which simply hides the real reason why the FBC wasn't
>
> I think this can be reworded a bit like " Although, if the FBC setup failed
> in the previous commit, if the current commit doesnt include new plane update,
> it tries to overwrite no_fbc_reason to "no suitable CRTC for FBC".
>
>
>> initialized.  For that scenario, it is better that we simply keep the
>> old message in-place to make debugging easier.
>> 
>> A scenario where this happens is with the
>> igt@kms_frontbuffer_tracking@fbc-suspend testcase when executed on a
>> Haswell system with not enough stolen memory.  When enabling the CRTC,
>> the FBC setup will be correctly initialized to a specific CRTC, but
>> won't be enabled, since there is not enough memory.  The testcase will
>> then enable CRC checking, which requires a quirk for Haswell, which
>> issues a new atomic commit that doesn't update the planes.  Since that
>> update doesn't include any new planes (and the FBC wasn't enabled),
>> intel_fbc_choose_crtc() will not find any suitable CRTC, but update the
>> error message, hiding the lack of memory information, which is the
>> actual cause of the initialization failure.  As a result, this causes
>> that test to fail on Haswell.
>
> So the problem here is just a wrong error message.
> How does a wrong error message cause the IGT test to fail?

igt is prepared to skip the test on boxes where there isn't enough
stolen memory, but since we overwrite that message, the test will
execute and fail.  We discussed earlier on the list about adding a new
check to igt for the "no suitable CRTC for FBC" message, but that could
end up hiding other real error conditions.

-- 
Gabriel Krisman Bertazi
___
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: Disable decoupled mmio for GEN9LP (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Disable decoupled mmio for GEN9LP (rev2)
URL   : https://patchwork.freedesktop.org/series/24470/
State : success

== Summary ==

Series 24470v2 drm/i915: Disable decoupled mmio for GEN9LP
https://patchwork.freedesktop.org/api/1.0/series/24470/revisions/2/mbox/

fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:494s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:487s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:429s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
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:409s
fi-skl-6700k failed to connect after reboot

713f8ec675d5a793326b94d9a0cc484608eff75e drm-tip: 2017y-05m-16d-15h-22m-08s UTC 
integration manifest
60cfda0 drm/i915: Disable decoupled mmio for GEN9LP

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4714/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Disable decoupled mmio for GEN9LP

[kai . chen]

From: Kai Chen 

The decoupled mmio feature doesn't work as intended by HW team. Enabling
it with forcewake will only make debugging efforts more difficult, so
let's just simply remove it.

v2:
- Remove dead code related to GEN9LP decoupled mmio.
- Change backgrounds: In theory, decoupled mmio should require less cycles
  for single read/write operation by avoiding frequent software forcewake.
  However, it turns out this design not to be true on HW practice and not to
  provide any decoupling benefit. It also introduces problems which cause
  failures in intel-gpu-tools (gem), and also cause driver code and debugging
  more complex.
- This change therefore reverts:

  commit 85ee17ebeedd1af0dccd98f82ab4e644e29d84c0
  Author: Praveen Paneri 
  Date: Tue, 15 Nov 2016 22:49:20 +0530

  drm/i915/bxt: Broxton decoupled MMIO

  coomit a3f79ca63b9bcf5a527b886953092bfd65e78940
  Author: Ander Conselvan de Oliveira 
  Date: Thu, 24 Nov 2016 15:23:27 +0200

  drm/i915: Don't sanitize has_decoupled_mmio if platform is not broxton

Signed-off-by: Kai Chen 
---
 drivers/gpu/drm/i915/i915_pci.c |   1 -
 drivers/gpu/drm/i915/i915_reg.h |   7 --
 drivers/gpu/drm/i915/intel_uncore.c | 126 
 3 files changed, 134 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index f80db2c..cf43dc1 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -385,7 +385,6 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
.has_gmbus_irq = 1, \
.has_logical_ring_contexts = 1, \
.has_guc = 1, \
-   .has_decoupled_mmio = 1, \
.has_aliasing_ppgtt = 1, \
.has_full_ppgtt = 1, \
.has_full_48bit_ppgtt = 1, \
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee144ec..78872f9 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -7792,13 +7792,6 @@ enum {
 #define  SKL_FUSE_PG1_DIST_STATUS  (1<<26)
 #define  SKL_FUSE_PG2_DIST_STATUS  (1<<25)
 
-/* Decoupled MMIO register pair for kernel driver */
-#define GEN9_DECOUPLED_REG0_DW0_MMIO(0xF00)
-#define GEN9_DECOUPLED_REG0_DW1_MMIO(0xF04)
-#define GEN9_DECOUPLED_DW1_GO  (1<<31)
-#define GEN9_DECOUPLED_PD_SHIFT28
-#define GEN9_DECOUPLED_OP_SHIFT24
-
 /* Per-pipe DDI Function Control */
 #define _TRANS_DDI_FUNC_CTL_A  0x60400
 #define _TRANS_DDI_FUNC_CTL_B  0x61400
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index a9a6933..3901800 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -400,8 +400,6 @@ check_for_unclaimed_mmio(struct drm_i915_private *dev_priv)
 static void __intel_uncore_early_sanitize(struct drm_i915_private *dev_priv,
  bool restore_forcewake)
 {
-   struct intel_device_info *info = mkwrite_device_info(dev_priv);
-
/* clear out unclaimed reg detection bit */
if (check_for_unclaimed_mmio(dev_priv))
DRM_DEBUG("unclaimed mmio detected on uncore init, clearing\n");
@@ -414,9 +412,6 @@ static void __intel_uncore_early_sanitize(struct 
drm_i915_private *dev_priv,
   GT_FIFO_CTL_RC6_POLICY_STALL);
}
 
-   if (IS_BXT_REVID(dev_priv, 0, BXT_REVID_B_LAST))
-   info->has_decoupled_mmio = false;
-
intel_uncore_forcewake_reset(dev_priv, restore_forcewake);
 }
 
@@ -801,78 +796,6 @@ unclaimed_reg_debug(struct drm_i915_private *dev_priv,
__unclaimed_reg_debug(dev_priv, reg, read, before);
 }
 
-enum decoupled_power_domain {
-   GEN9_DECOUPLED_PD_BLITTER = 0,
-   GEN9_DECOUPLED_PD_RENDER,
-   GEN9_DECOUPLED_PD_MEDIA,
-   GEN9_DECOUPLED_PD_ALL
-};
-
-enum decoupled_ops {
-   GEN9_DECOUPLED_OP_WRITE = 0,
-   GEN9_DECOUPLED_OP_READ
-};
-
-static const enum decoupled_power_domain fw2dpd_domain[] = {
-   GEN9_DECOUPLED_PD_RENDER,
-   GEN9_DECOUPLED_PD_BLITTER,
-   GEN9_DECOUPLED_PD_ALL,
-   GEN9_DECOUPLED_PD_MEDIA,
-   GEN9_DECOUPLED_PD_ALL,
-   GEN9_DECOUPLED_PD_ALL,
-   GEN9_DECOUPLED_PD_ALL
-};
-
-/*
- * Decoupled MMIO access for only 1 DWORD
- */
-static void __gen9_decoupled_mmio_access(struct drm_i915_private *dev_priv,
-u32 reg,
-enum forcewake_domains fw_domain,
-enum decoupled_ops operation)
-{
-   enum decoupled_power_domain dp_domain;
-   u32 ctrl_reg_data = 0;
-
-   dp_domain = fw2dpd_domain[fw_domain - 1];
-
-   ctrl_reg_data |= reg;
-   ctrl_reg_data |= (operation << GEN9_DECOUPLED_OP_SHIFT);
-   ctrl_reg_data |= (dp_domain << GEN9_DECOUPLED_PD_SHIFT);
-   ctrl_reg_da

[Intel-gfx] ✓ Fi.CI.BAT: success for Enhancement to intel_dp_aux_backlight driver (rev7)

[Patchwork]

== Series Details ==

Series: Enhancement to intel_dp_aux_backlight driver (rev7)
URL   : https://patchwork.freedesktop.org/series/21086/
State : success

== Summary ==

Series 21086v7 Enhancement to intel_dp_aux_backlight driver
https://patchwork.freedesktop.org/api/1.0/series/21086/revisions/7/mbox/

fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:441s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:499s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:487s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:443s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:533s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:398s
fi-skl-6700k failed to connect after reboot

713f8ec675d5a793326b94d9a0cc484608eff75e drm-tip: 2017y-05m-16d-15h-22m-08s UTC 
integration manifest
22b9473 drm/i915: Set PWM divider to match desired frequency in vbt
703055d drm: Add definition for eDP backlight frequency
140048b drm/i915: Add option to support dynamic backlight via DPCD
d712cd7 drm/i915: Allow choosing how to adjust brightness if both supported
aba9f34 drm/i915: Drop AUX backlight enable check for backlight control

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4713/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

On Tue, May 16, 2017 at 2:21 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Tue, 2017-05-16 at 13:56 -0700, Puthikorn Voravootivat wrote:
> >
> >
> > On Tue, May 16, 2017 at 1:29 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat
> > wrote:
> > >
> > >
> > > On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
> > >  wrote:
> > > On Mon, 2017-05-15 at 17:43 -0700, Puthikorn
> > Voravootivat
> > > wrote:
> > > >
> > > >
> > > > On Mon, May 15, 2017 at 4:07 PM, Pandiyan,
> > Dhinakaran
> > > >  wrote:
> > > > On Fri, 2017-05-12 at 17:31 -0700,
> > Puthikorn
> > > Voravootivat
> > > > wrote:
> > > > >
> > > > >
> > > > >
> > > > > On Fri, May 12, 2017 at 5:12 PM,
> > Pandiyan,
> > > Dhinakaran
> > > > >  wrote:
> > > > > On Thu, 2017-05-11 at 16:02
> > -0700,
> > > Puthikorn
> > > > Voravootivat
> > > > > wrote:
> > > > > > Read desired PWM frequency
> > from panel
> > > vbt and
> > > > calculate the
> > > > > > value for divider in DPCD
> > address 0x724
> > > and 0x728
> > > > to have
> > > > > > as many bits as possible for
> > PWM duty
> > > cyle for
> > > > granularity
> > > > > of
> > > > > > brightness adjustment while
> > the
> > > frequency is still
> > > > within
> > > > > 25%
> > > > > > of the desired frequency.
> > > > >
> > > > > I read a few eDP panel data
> > sheets, the
> > > PWM
> > > > frequencies all
> > > > > start from
> > > > > ~200Hz. If the VBT chooses this
> > lowest
> > > value to
> > > > allow for more
> > > > > brightness control, and then
> > this patch
> > > lowers the
> > > > value by
> > > > > another 25%,
> > > > > we'll end up below the panel
> > allowed PWM
> > > frequency.
> > > > >
> > > > > In fact, one of the systems I
> > checked had
> > > PWM
> > > > frequency as
> > > > > 200Hz in VBT
> > > > > and the panel datasheet also had
> > PWM
> > > frequency range
> > > > starting
> > > > > from
> > > > > 200Hz. Have you considered this
> > case?
> > > > >
> > > > > The spec said "A given LCD panel
> > typically has a
> > > limited
> > > > range of
> > > > > backlight frequency capability.
> > > > > To limit the programmable frequency
> > range,
> > > limitations are
> > > > placed on
> > > > > the allowable total divider ratio with
> > the Sink
> > > device"
> > > > >  So I think it should be auto cap to
> > 200Hz in this
> > > case.
> > > > >
> > > > > -DK
> > > > > >
> > > > > > Signed-off-by: Puthikorn
> > Voravootivat
> > > > 
> > > > > > ---
> > > > > >
> > > drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > > > 81
> > > > > +++
> > > > > >  1 file changed, 81
> > insertions(+)
> > > > > >
> > > > > > diff --git
> > > >
> >  a/drivers/

[Intel-gfx] [PATCH v8 1/5] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

There are some panel that
(1) does not support display backlight enable via AUX
(2) support display backlight adjustment via AUX
(3) support display backlight enable via eDP BL_ENABLE pin

The current driver required that (1) must be support to enable (2).
This patch drops that requirement.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index b87c5a381d6a..d32c06583e0b 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -165,7 +165,6 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 * the panel can support backlight control over the aux channel
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
-- 
2.13.0.303.g4ebf302169-goog

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v8 3/5] drm/i915: Add option to support dynamic backlight via DPCD

[Puthikorn Voravootivat]

This patch adds option to enable dynamic backlight for eDP
panel that supports this feature via DPCD register and
set minimum / maximum brightness to 0% and 100% of the
normal brightness.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  5 
 drivers/gpu/drm/i915/i915_params.h|  3 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 40 +++
 3 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index 13cf3f1572ab..6eaf660e74da 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -65,6 +65,7 @@ struct i915_params i915 __read_mostly = {
.inject_load_failure = 0,
.enable_dpcd_backlight = -1,
.enable_gvt = false,
+   .enable_dbc = false,
 };
 
 module_param_named(modeset, i915.modeset, int, 0400);
@@ -255,3 +256,7 @@ MODULE_PARM_DESC(enable_dpcd_backlight,
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
"Enable support for Intel GVT-g graphics virtualization host 
support(default:false)");
+
+module_param_named(enable_dbc, i915.enable_dbc, bool, 0600);
+MODULE_PARM_DESC(enable_dbc,
+   "Enable support for dynamic backlight control (default:false)");
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index ac02efce6e22..2de3e2850b54 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -67,7 +67,8 @@
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
func(int, enable_dpcd_backlight); \
-   func(bool, enable_gvt)
+   func(bool, enable_gvt); \
+   func(bool, enable_dbc)
 
 #define MEMBER(T, member) T member
 struct i915_params {
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 16ba1924308d..c0eeb8fc2013 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -100,10 +100,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
*connector, u32 level)
}
 }
 
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+  u32 min, u32 max)
+{
+   u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+   if (drm_dp_dpcd_write(&intel_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc) < 0)) {
+   DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
if (drm_dp_dpcd_readb(&intel_dp->aux,
@@ -113,18 +130,15 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
return;
}
 
+   new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
 
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
-   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
-   if (drm_dp_dpcd_writeb(&intel_dp->aux,
-   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
-   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
-   }
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
 
/* Do nothing when it is already DPCD mode */
@@ -133,6 +147,20 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
break;
}
 
+   if (i915.enable_dbc &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP)) {
+   new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+   DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+   }
+
+   if (new_dpcd_buf != dpcd_buf) {
+   if (drm_dp_dpcd_writeb(&intel_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   }
+
set_aux_backlight_enable(intel_dp, true);
intel_dp_aux_set_backlight(connector, connector->panel.backligh

[Intel-gfx] [PATCH v8 5/5] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

Read desired PWM frequency from panel vbt and calculate the
value for divider in DPCD address 0x724 and 0x728 to have
as many bits as possible for PWM duty cyle for granularity of
brightness adjustment while the frequency divisor is still
within 25% of the desired value.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 82 +++
 1 file changed, 82 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index c0eeb8fc2013..a01cbf3db1c2 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -116,12 +116,87 @@ intel_dp_aux_set_dynamic_backlight_percent(struct 
intel_dp *intel_dp,
}
 }
 
+/*
+ * Set PWM Frequency divider to match desired frequency in vbt.
+ * The PWM Frequency is calculated as 27Mhz / (F x P).
+ * - Where F = PWM Frequency Pre-Divider value programmed by field 7:0 of the
+ * EDP_BACKLIGHT_FREQ_SET register (DPCD Address 00728h)
+ * - Where P = 2^Pn, where Pn is the value programmed by field 4:0 of the
+ * EDP_PWMGEN_BIT_COUNT register (DPCD Address 00724h)
+ */
+static void intel_dp_aux_set_pwm_freq(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
+   int freq, fxp, fxp_min, fxp_max, fxp_actual, f = 1;
+   u8 pn, pn_min, pn_max;
+
+   /* Find desired value of (F x P)
+* Note that, if F x P is out of supported range, the maximum value or
+* minimum value will applied automatically. So no need to check that.
+*/
+   freq = dev_priv->vbt.backlight.pwm_freq_hz;
+   DRM_DEBUG_KMS("VBT defined backlight frequency %u Hz\n", freq);
+   if (!freq) {
+   DRM_DEBUG_KMS("Use panel default backlight frequency\n");
+   return;
+   }
+
+   fxp = DIV_ROUND_CLOSEST(KHz(DP_EDP_BACKLIGHT_FREQ_BASE_KHZ), freq);
+
+   /* Use highest possible value of Pn for more granularity of brightness
+* adjustment while satifying the conditions below.
+* - Pn is in the range of Pn_min and Pn_max
+* - F is in the range of 1 and 255
+* - FxP is within 25% of desired value.
+*   Note: 25% is arbitrary value and may need some tweak.
+*/
+   if (drm_dp_dpcd_readb(&intel_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN, &pn_min) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap min\n");
+   return;
+   }
+   if (drm_dp_dpcd_readb(&intel_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX, &pn_max) != 1) {
+   DRM_DEBUG_KMS("Failed to read pwmgen bit count cap max\n");
+   return;
+   }
+   pn_min &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+   pn_max &= DP_EDP_PWMGEN_BIT_COUNT_MASK;
+
+   fxp_min = DIV_ROUND_CLOSEST(fxp * 3, 4);
+   fxp_max = DIV_ROUND_CLOSEST(fxp * 5, 4);
+   if (fxp_min < (1 << pn_min) || (255 << pn_max) < fxp_max) {
+   DRM_DEBUG_KMS("VBT defined backlight frequency out of range\n");
+   return;
+   }
+
+   for (pn = pn_max; pn >= pn_min; pn--) {
+   f = clamp(DIV_ROUND_CLOSEST(fxp , 1 << pn), 1, 255);
+   fxp_actual = f << pn;
+   if (fxp_min <= fxp_actual && fxp_actual <= fxp_max)
+   break;
+   }
+
+   if (drm_dp_dpcd_writeb(&intel_dp->aux,
+  DP_EDP_PWMGEN_BIT_COUNT, pn) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux pwmgen bit count\n");
+   return;
+   }
+   if (drm_dp_dpcd_writeb(&intel_dp->aux,
+  DP_EDP_BACKLIGHT_FREQ_SET, (u8) f) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight freq\n");
+   return;
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
uint8_t dpcd_buf = 0;
uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
+   bool freq_cap;
 
if (drm_dp_dpcd_readb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, &dpcd_buf) != 1) {
@@ -154,6 +229,10 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
DRM_DEBUG_KMS("Enable dynamic brightness.\n");
}
 
+   freq_cap = intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_FREQ_AUX_SET_CAP;
+   if (freq_cap)
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_FREQ_AUX_SET_ENABLE;
+
if (new_dpcd_buf != dpcd_buf) {
if (drm_dp_dpcd_writeb(&intel_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
@@ -161,6 +240,9 @@ static void intel_dp_aux_

[Intel-gfx] [PATCH v8 4/5] drm: Add definition for eDP backlight frequency

[Puthikorn Voravootivat]

This patch adds the following definition
- Bit mask for EDP_PWMGEN_BIT_COUNT and min/max cap
  register which only use bit 0:4
- Base frequency (27 MHz) for backlight PWM frequency
  generator.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 include/drm/drm_dp_helper.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..eaa307f6ae8c 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -572,10 +572,12 @@
 #define DP_EDP_PWMGEN_BIT_COUNT 0x724
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
+# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (0x1f << 0)
 
 #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
 
 #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
+# define DP_EDP_BACKLIGHT_FREQ_BASE_KHZ 27000
 
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b
-- 
2.13.0.303.g4ebf302169-goog

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v8 2/5] drm/i915: Allow choosing how to adjust brightness if both supported

[Puthikorn Voravootivat]

Add option to allow choosing how to adjust brightness if
panel supports both PWM pin and AUX channel.

Signed-off-by: Puthikorn Voravootivat 
---
 drivers/gpu/drm/i915/i915_params.c|  8 ---
 drivers/gpu/drm/i915/i915_params.h|  2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 31 ++-
 3 files changed, 32 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_dpcd_backlight = false,
+   .enable_dpcd_backlight = -1,
.enable_gvt = false,
 };
 
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
0600);
 MODULE_PARM_DESC(enable_dpcd_backlight,
-   "Enable support for DPCD backlight control (default:false)");
+   "Enable support for DPCD backlight control "
+   "(-1:disable (default), 0:Use PWM pin if both supported, "
+   "1:Use DPCD if both supported");
 
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
-   func(bool, enable_dpcd_backlight); \
+   func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
 #define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index d32c06583e0b..16ba1924308d 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
 {
uint8_t reg_val = 0;
 
+   /* Early return when display use other mechanism to enable backlight. */
+   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+   return;
+
if (drm_dp_dpcd_readb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
  ®_val) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -39,6 +43,9 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
else
reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
 
+   /* TODO: If the panel also support enabling backlight via BL_ENABLE pin,
+* the backlight will be enabled again in _intel_edp_backlight_on()
+*/
if (drm_dp_dpcd_writeb(&intel_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
   reg_val) != 1) {
DRM_DEBUG_KMS("Failed to %s aux backlight\n",
@@ -164,21 +171,35 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
/* Check the  eDP Display control capabilities registers to determine if
 * the panel can support backlight control over the aux channel
 */
-   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
-   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
- (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
+   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
 }
 
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(&connector->encoder->base);
+
+   /* Check the  eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+   return (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP);
+}
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_pan

[Intel-gfx] [PATCH v8 0/5] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

This patch set contain 5 patches. Another 4 patches in previous version
was already merged.
- First two patches allow choosing which way to adjust brightness
  if both PWM pin and AUX are supported
- Next patch adds support for dynamic brightness.
- Last two patches set the PWM freqency to match data in panel vbt.

Change log:
v8:
- Drop 4 patches that was already merged
- Move DP_EDP_BACKLIGHT_AUX_ENABLE_CAP check to patch #2 to avoid
  behavior change if only apply patch #1
- Add TODO to warn about enable backlight twice in patch #2
- Use DIV_ROUND_CLOSEST instead of just "/" in patch #5
- Fix bug calculate pn in patch #5
- Clarify commit  message / code comment in patch #5

v7:
- Add check in intel_dp_pwm_pin_display_control_capable in patch #4
- Add option in patch #6 to enable DPCD or not
- Change definition in patch #8 and implementation in #9 to use Khz
- Fix compiler warning from build bot in patch #9

v6:
- Address review from Dhinakaran
- Make PWM frequency to have highest value of Pn that make the
  frequency still within 25% of desired frequency.

v5:
- Split first patch in v4 to 3 patches
- Bump priority for "Correctly enable backlight brightness adjustment via DPCD"
- Make logic clearer for the case that both PWM pin and AUX are supported
- Add more log when write to register fail
- Add log when enable DBC

v4:
- Rebase / minor typo fix.

v3:
- Add new implementation of PWM frequency patch

v2:
- Drop PWM frequency patch
- Address suggestion from Jani Nikula

Puthikorn Voravootivat (5):
  drm/i915: Drop AUX backlight enable check for backlight control
  drm/i915: Allow choosing how to adjust brightness if both supported
  drm/i915: Add option to support dynamic backlight via DPCD
  drm: Add definition for eDP backlight frequency
  drm/i915: Set PWM divider to match desired frequency in vbt

 drivers/gpu/drm/i915/i915_params.c|  13 ++-
 drivers/gpu/drm/i915/i915_params.h|   5 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 154 --
 include/drm/drm_dp_helper.h   |   2 +
 4 files changed, 157 insertions(+), 17 deletions(-)

-- 
2.13.0.303.g4ebf302169-goog

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v5 3/3] drm/i915: Add format modifiers for Intel

[Emil Velikov]

Hi Ben,

A couple of small questions/suggestions that I hope you find useful.
Please don't block any of this work based on my comments.

On 16 May 2017 at 22:31, Ben Widawsky  wrote:

> +static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> +   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> +   return false;
> +
> +   if (INTEL_GEN(dev_priv) >= 9)
> +   return skl_mod_supported(format, modifier);
> +   else if (INTEL_GEN(dev_priv) >= 4)
> +   return i965_mod_supported(format, modifier);
> +   else
> +   return i8xx_mod_supported(format, modifier);
> +
Nit: if you rewrite this as below, the control flow should be clearer.
Thus the 'return false;' at the end, will be [more] obvious that it's
unreachable ;-)

   if (INTEL_GEN(dev_priv) >= 9)
   return skl_mod_supported(format, modifier);

   if (INTEL_GEN(dev_priv) >= 4)
   return i965_mod_supported(format, modifier);

   return i8xx_mod_supported(format, modifier);


> +   return false;
> +}
> +


> --- a/drivers/gpu/drm/i915/intel_sprite.c
> +++ b/drivers/gpu/drm/i915/intel_sprite.c

> +static bool intel_sprite_plane_format_mod_supported(struct drm_plane *plane,
> +uint32_t format,
> +uint64_t modifier)
> +{
> +   struct drm_i915_private *dev_priv = to_i915(plane->dev);
> +
> +   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
> +   return false;
> +
> +   BUG_ON(plane->base.type != DRM_PLANE_TYPE_OVERLAY);
> +
> +   switch (format) {
> +   case DRM_FORMAT_XBGR2101010:
> +   case DRM_FORMAT_ABGR2101010:
> +   if (IS_VALLEYVIEW(dev_priv) || 
> IS_CHERRYVIEW(dev_priv))
> +   return true;
> +   break;
> +   case DRM_FORMAT_RGB565:
> +   case DRM_FORMAT_ABGR:
> +   case DRM_FORMAT_ARGB:
> +   if (INTEL_GEN(dev_priv) >= 9 || 
> IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> +   return true;
> +   break;
> +   case DRM_FORMAT_XBGR:
> +   if (INTEL_GEN(dev_priv) >= 6)
> +   return true;
> +   break;
> +   case DRM_FORMAT_XRGB:
> +   case DRM_FORMAT_YUYV:
> +   case DRM_FORMAT_YVYU:
> +   case DRM_FORMAT_UYVY:
> +   case DRM_FORMAT_VYUY:
> +   return true;
> +   }
> +
> +   return false;
> +}
> +
> +const struct drm_plane_funcs intel_sprite_plane_funcs = {
> +.update_plane = drm_atomic_helper_update_plane,
> +.disable_plane = drm_atomic_helper_disable_plane,
> +.destroy = intel_plane_destroy,
> +.set_property = drm_atomic_helper_plane_set_property,
> +.atomic_get_property = intel_plane_atomic_get_property,
> +.atomic_set_property = intel_plane_atomic_set_property,
> +.atomic_duplicate_state = intel_plane_duplicate_state,
> +.atomic_destroy_state = intel_plane_destroy_state,
> +.format_mod_supported = intel_sprite_plane_format_mod_supported,
> +};
> +
Having a dull moment - is intel_sprite_plane_funcs (+
intel_sprite_plane_format_mod_supported) unused or I'm seeing things?
If one is to keep it, for future work, perhaps it's worth adding a 2-3
word comment,

Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

[Michel Thierry]

On 16/05/17 00:54, Chris Wilson wrote:

On Mon, May 15, 2017 at 03:25:27PM -0700, Michel Thierry wrote:

On 5/15/2017 2:47 PM, Chris Wilson wrote:

On Mon, May 15, 2017 at 10:31:58PM +0100, Chris Wilson wrote:

On Mon, May 15, 2017 at 02:20:01PM -0700, Michel Thierry wrote:

@@ -2827,21 +2830,34 @@ int i915_gem_reset_prepare_engine(struct 
intel_engine_cs *engine)

if (engine_stalled(engine)) {
request = i915_gem_find_active_request(engine);
-   if (request && request->fence.error == -EIO)
-   err = -EIO; /* Previous reset failed! */
+
+   if (request) {
+   if (request->fence.error == -EIO)
+   return ERR_PTR(-EIO); /* Previous reset failed! 
*/
+
+   if (__i915_gem_request_completed(request,
+
engine->hangcheck.seqno))


This is not the seqno for the request, so this is incorrect. It will
judge that the request was preempted (as hangcheck.seqno must be less
thn request->global_seqno) and so conclude that the request was never
completed.

You just want if (i915_gem_request_completed(request))


Thanks, I'll change the function.



Also not here. This pardon check should be deferred to the caller just
before commiting to thre reset. In the case of global reset, we want to
gather up all the engines' active requests first, complete our
preparations and then double check the engine was hung.


i915_reset_engine calls this directly, but 'full reset' [from
i915_gem_reset_prepare()] would not be affected and it won't pardon
anything... i915_gem_reset_engine is doing the double check you
mention.


Aye, but in the long run I was thinking of capturing this request in
engine->hangcheck.active_request and then we reuse that info in the later
phases.


Capture hangcheck.active_request during hangcheck_declare_hang? Or still 
here in reset_prepare?


Thanks
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

[Emil Velikov]

Hi Ben,

On 16 May 2017 at 22:31, Ben Widawsky  wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
>
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifier (Liviu)
> * Remove arguments to blob creation, use plane instead (Liviu)
> * Fix data types (Ben)
> * Make the blob part of uapi (Daniel)
>
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Cc: Liviu Dudau 
> Signed-off-by: Ben Widawsky 
> Reviewed-by: Daniel Stone 

I think this is almost perfect, barring the UAPI nitpick.
The rest is somewhat of a bikeshedding.

With the UAPI resolved, regardless of the rest
Reviewed-by: Emil Velikov 


> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c

> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane)
> +{
> +   const struct drm_mode_config *config = &dev->mode_config;
> +   const uint64_t *temp_modifiers = plane->modifiers;
> +   unsigned int format_modifier_count = 0;
> +   struct drm_property_blob *blob = NULL;
> +   struct drm_format_modifier *mod;
> +   size_t blob_size = 0, formats_size, modifiers_size;
There's no need to initialize blob and blob_size here.

> +   struct drm_format_modifier_blob *blob_data;
> +   int i, j, ret = 0;
Make i and j unsigned to match format_modifier_count and
plane->format_count respectively.
Then expand ret in the only place where it's used?

> +
> +   if (plane->modifiers)
> +   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> +   format_modifier_count++;
> +
> +   formats_size = sizeof(*plane->format_types) * plane->format_count;
> +   if (WARN_ON(!formats_size)) {
> +   /* 0 formats are never expected */
> +   return 0;
> +   }
> +
> +   modifiers_size =
> +   sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> +   blob_size = sizeof(struct drm_format_modifier_blob);
> +   blob_size += ALIGN(formats_size, 8);
Worth having the "Modifiers offset is a pointer..." comment moved/copied here?

> +   blob_size += modifiers_size;
> +
> +   blob = drm_property_create_blob(dev, blob_size, NULL);
> +   if (IS_ERR(blob))
> +   return -1;
> +
Maybe propagate the exact error... Hmm we don't seem to check if
create_in_format_blob fails either so perhaps it's not worth it.


> --- a/include/uapi/drm/drm_mode.h
> +++ b/include/uapi/drm/drm_mode.h
> @@ -665,6 +665,56 @@ struct drm_mode_atomic {
> __u64 user_data;
>  };
>
> +struct drm_format_modifier_blob {
> +#define FORMAT_BLOB_CURRENT 1
> +   /* Version of this blob format */
> +   u32 version;
> +
> +   /* Flags */
> +   u32 flags;
> +
> +   /* Number of fourcc formats supported */
> +   u32 count_formats;
> +
> +   /* Where in this blob the formats exist (in bytes) */
> +   u32 formats_offset;
> +
> +   /* Number of drm_format_modifiers */
> +   u32 count_modifiers;
> +
> +   /* Where in this blob the modifiers exist (in bytes) */
> +   u32 modifiers_offset;
> +
> +   /* u32 formats[] */
> +   /* struct drm_format_modifier modifiers[] */
> +};
> +
> +struct drm_format_modifier {
> +   /* Bitmask of formats in get_plane format list this info applies to. 
> The
> +* offset allows a sliding window of which 64 formats (bits).
> +*
> +* Some examples:
> +* In today's world with < 65 formats, and formats 0, and 2 are
> +* supported
> +* 0x0005
> +*^-offset = 0, formats = 5
> +*
> +* If the number formats grew to 128, and formats 98-102 are
> +* supported with the modifier:
> +*
> +* 0x003c 
> +*^
> +*|__offset = 64, formats = 0x3c
> +*
> +*/
> +   __u64 formats;
> +   __u32 offset;
> +   __u32 pad;
> +
> +   /* The modifier that applies to the >get_plane format list bitmask. */
> +   __u64 modifier;
Please drop the leading __ from the type names in UAPI headers.

Regards,
Emil
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm: i915: Preserve old FBC status if update with no new planes

[Manasi Navare]

Hi Gabriel,

So the purpose of this patch is to avoid overwriting the no_fbc_reason
field during atomic_check in case there is no plane update so that
it retains the actual failure message from previous atomic commit operation
failure where it failed to enable fbc in intel_fbc_can_enable() during
the post plane update right?

On Mon, May 15, 2017 at 09:33:04PM -0300, Gabriel Krisman Bertazi wrote:
> If the atomic commit doesn't include any new plane, there is no need to
> choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out
> early.  Although, if the FBC setup failed beforehand for whatever reason,
> we don't bail early, but we change the no_fbc_reason to "no suitable
> CRTC for FBC", which simply hides the real reason why the FBC wasn't

I think this can be reworded a bit like " Although, if the FBC setup failed
in the previous commit, if the current commit doesnt include new plane update,
it tries to overwrite no_fbc_reason to "no suitable CRTC for FBC".


> initialized.  For that scenario, it is better that we simply keep the
> old message in-place to make debugging easier.
> 
> A scenario where this happens is with the
> igt@kms_frontbuffer_tracking@fbc-suspend testcase when executed on a
> Haswell system with not enough stolen memory.  When enabling the CRTC,
> the FBC setup will be correctly initialized to a specific CRTC, but
> won't be enabled, since there is not enough memory.  The testcase will
> then enable CRC checking, which requires a quirk for Haswell, which
> issues a new atomic commit that doesn't update the planes.  Since that
> update doesn't include any new planes (and the FBC wasn't enabled),
> intel_fbc_choose_crtc() will not find any suitable CRTC, but update the
> error message, hiding the lack of memory information, which is the
> actual cause of the initialization failure.  As a result, this causes
> that test to fail on Haswell.

So the problem here is just a wrong error message.
How does a wrong error message cause the IGT test to fail?

Manasi

> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100020
> Fixes: f7e9b004b8a3 ("drm/i915/fbc: inline intel_fbc_can_choose()")
> Reported-by: Dorota Czaplejewicz 
> Signed-off-by: Gabriel Krisman Bertazi 
> Cc: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/intel_fbc.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_fbc.c 
> b/drivers/gpu/drm/i915/intel_fbc.c
> index ded2add18b26..0c99c9b731ee 100644
> --- a/drivers/gpu/drm/i915/intel_fbc.c
> +++ b/drivers/gpu/drm/i915/intel_fbc.c
> @@ -1045,6 +1045,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>   struct drm_plane *plane;
>   struct drm_plane_state *plane_state;
>   bool crtc_chosen = false;
> + bool new_planes = false;
>   int i;
>  
>   mutex_lock(&fbc->lock);
> @@ -1066,6 +1067,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>   to_intel_plane_state(plane_state);
>   struct intel_crtc_state *intel_crtc_state;
>   struct intel_crtc *crtc = to_intel_crtc(plane_state->crtc);
> + new_planes = true;
>  
>   if (!intel_plane_state->base.visible)
>   continue;
> @@ -1084,7 +1086,7 @@ void intel_fbc_choose_crtc(struct drm_i915_private 
> *dev_priv,
>   break;
>   }
>  
> - if (!crtc_chosen)
> + if (new_planes && !crtc_chosen)
>   fbc->no_fbc_reason = "no suitable CRTC for FBC";
>  
>  out:
> -- 
> 2.11.0
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

[Liviu Dudau]

On Tue, May 16, 2017 at 02:31:25PM -0700, Ben Widawsky wrote:
> Updated blob layout (Rob, Daniel, Kristian, xerpi)
> 
> v2:
> * Removed __packed, and alignment (.+)
> * Fix indent in drm_format_modifier fields (Liviu)
> * Remove duplicated modifier > 64 check (Liviu)
> * Change comment about modifier (Liviu)
> * Remove arguments to blob creation, use plane instead (Liviu)
> * Fix data types (Ben)
> * Make the blob part of uapi (Daniel)

Thanks for updating the patch!

> 
> Cc: Rob Clark 
> Cc: Daniel Stone 
> Cc: Kristian H. Kristensen 
> Cc: Liviu Dudau 
> Signed-off-by: Ben Widawsky 
> Reviewed-by: Daniel Stone 

Looks good to me!
Reviewed-by: Liviu Dudau 

Best regards,
Liviu

> ---
>  drivers/gpu/drm/drm_mode_config.c |  7 +++
>  drivers/gpu/drm/drm_plane.c   | 89 
> +++
>  include/drm/drm_mode_config.h |  6 +++
>  include/uapi/drm/drm_mode.h   | 50 ++
>  4 files changed, 152 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_mode_config.c 
> b/drivers/gpu/drm/drm_mode_config.c
> index d9862259a2a7..6bfbc3839df5 100644
> --- a/drivers/gpu/drm/drm_mode_config.c
> +++ b/drivers/gpu/drm/drm_mode_config.c
> @@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
> drm_device *dev)
>   return -ENOMEM;
>   dev->mode_config.gamma_lut_size_property = prop;
>  
> + prop = drm_property_create(dev,
> +DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
> +"IN_FORMATS", 0);
> + if (!prop)
> + return -ENOMEM;
> + dev->mode_config.modifiers = prop;
> +
>   return 0;
>  }
>  
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 20203871e06d..f5b032b5f761 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -62,6 +62,92 @@ static unsigned int drm_num_planes(struct drm_device *dev)
>   return num;
>  }
>  
> +static inline u32 *
> +formats_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (u32 *)(((char *)blob) + blob->formats_offset);
> +}
> +
> +static inline struct drm_format_modifier *
> +modifiers_ptr(struct drm_format_modifier_blob *blob)
> +{
> + return (struct drm_format_modifier *)(((char *)blob) + 
> blob->modifiers_offset);
> +}
> +
> +static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
> *plane)
> +{
> + const struct drm_mode_config *config = &dev->mode_config;
> + const uint64_t *temp_modifiers = plane->modifiers;
> + unsigned int format_modifier_count = 0;
> + struct drm_property_blob *blob = NULL;
> + struct drm_format_modifier *mod;
> + size_t blob_size = 0, formats_size, modifiers_size;
> + struct drm_format_modifier_blob *blob_data;
> + int i, j, ret = 0;
> +
> + if (plane->modifiers)
> + while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
> + format_modifier_count++;
> +
> + formats_size = sizeof(*plane->format_types) * plane->format_count;
> + if (WARN_ON(!formats_size)) {
> + /* 0 formats are never expected */
> + return 0;
> + }
> +
> + modifiers_size =
> + sizeof(struct drm_format_modifier) * format_modifier_count;
> +
> + blob_size = sizeof(struct drm_format_modifier_blob);
> + blob_size += ALIGN(formats_size, 8);
> + blob_size += modifiers_size;
> +
> + blob = drm_property_create_blob(dev, blob_size, NULL);
> + if (IS_ERR(blob))
> + return -1;
> +
> + blob_data = (struct drm_format_modifier_blob *)blob->data;
> + blob_data->version = FORMAT_BLOB_CURRENT;
> + blob_data->count_formats = plane->format_count;
> + blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
> + blob_data->count_modifiers = format_modifier_count;
> +
> + /* Modifiers offset is a pointer to a struct with a 64 bit field so it
> +  * should be naturally aligned to 8B.
> +  */
> + blob_data->modifiers_offset =
> + ALIGN(blob_data->formats_offset + formats_size, 8);
> +
> + memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
> +
> + /* If we can't determine support, just bail */
> + if (!plane->funcs->format_mod_supported)
> + goto done;
> +
> + mod = modifiers_ptr(blob_data);
> + for (i = 0; i < format_modifier_count; i++) {
> + for (j = 0; j < plane->format_count; j++) {
> + if (plane->funcs->format_mod_supported(plane,
> +
> plane->format_types[j],
> +
> plane->modifiers[i])) {
> +
> + mod->formats |= 1 << j;
> + }
> + }
> +
> + mod->modifier = plane->modifiers[i];
> + mod->offset = 0;
> + mod->pad = 0;
> + mod++;
> + }
>

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev5)

[Patchwork]

== Series Details ==

Series: drm/i915/guc: capture GuC logs if FW fails to load (rev5)
URL   : https://patchwork.freedesktop.org/series/23982/
State : success

== Summary ==

Series 23982v5 drm/i915/guc: capture GuC logs if FW fails to load
https://patchwork.freedesktop.org/api/1.0/series/23982/revisions/5/mbox/

fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:485s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:424s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:415s
fi-bsw-n3050 failed to connect after reboot
fi-bxt-j4205 failed to connect after reboot
fi-ivb-3520m failed to connect after reboot
fi-skl-6700k failed to connect after reboot

713f8ec675d5a793326b94d9a0cc484608eff75e drm-tip: 2017y-05m-16d-15h-22m-08s UTC 
integration manifest
909d83e drm/i915/guc: capture GuC logs if FW fails to load

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4712/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v5] drm/i915/guc: capture GuC logs if FW fails to load

[Daniele Ceraolo Spurio]

We're currently deleting the GuC logs if the FW fails to load, but those
are still useful to understand why the loading failed. Keeping the
object around allows us to access them after driver load is completed.

v2: keep the object around instead of using kernel memory (chris)
don't store the logs in the gpu_error struct (Chris)
add a check on guc_log_level to avoid snapshotting empty logs

v3: use separate debugfs for error log (Chris)

v4: rebased

v5: clean up obj selection, move err_load inside guc_log, move err_load
cleanup, rename functions (Michal)

Cc: Chris Wilson 
Cc: Oscar Mateo 
Cc: Michal Wajdeczko 
Signed-off-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/i915_debugfs.c  | 38 +++-
 drivers/gpu/drm/i915/intel_guc_log.c | 17 
 drivers/gpu/drm/i915/intel_uc.c  | 14 +++--
 drivers/gpu/drm/i915/intel_uc.h  |  5 +
 4 files changed, 58 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef..740395c 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2607,27 +2607,36 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
*data)
 
 static int i915_guc_log_dump(struct seq_file *m, void *data)
 {
-   struct drm_i915_private *dev_priv = node_to_i915(m->private);
-   struct drm_i915_gem_object *obj;
-   int i = 0, pg;
-
-   if (!dev_priv->guc.log.vma)
-   return 0;
+   struct drm_info_node *node = m->private;
+   struct drm_i915_private *dev_priv = node_to_i915(node);
+   bool dump_load_err = !!node->info_ent->data;
+   struct drm_i915_gem_object *obj = NULL;
+   u32 *log;
+   int i = 0;
 
-   obj = dev_priv->guc.log.vma->obj;
-   for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
-   u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
+   if (dump_load_err)
+   obj = dev_priv->guc.log.load_err;
+   else if (dev_priv->guc.log.vma)
+   obj = dev_priv->guc.log.vma->obj;
 
-   for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
-   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
-  *(log + i), *(log + i + 1),
-  *(log + i + 2), *(log + i + 3));
+   if (!obj)
+   return 0;
 
-   kunmap_atomic(log);
+   log = i915_gem_object_pin_map(obj, I915_MAP_WC);
+   if (IS_ERR(log)) {
+   seq_puts(m, "Failed to pin object\n");
+   return PTR_ERR(log);
}
 
+   for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
+   seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
+  *(log + i), *(log + i + 1),
+  *(log + i + 2), *(log + i + 3));
+
seq_putc(m, '\n');
 
+   i915_gem_object_unpin_map(obj);
+
return 0;
 }
 
@@ -4811,6 +4820,7 @@ static int i915_hpd_storm_ctl_open(struct inode *inode, 
struct file *file)
{"i915_guc_info", i915_guc_info, 0},
{"i915_guc_load_status", i915_guc_load_status_info, 0},
{"i915_guc_log_dump", i915_guc_log_dump, 0},
+   {"i915_guc_load_err_log_dump", i915_guc_log_dump, 0, (void *)1},
{"i915_guc_stage_pool", i915_guc_stage_pool, 0},
{"i915_huc_load_status", i915_huc_load_status_info, 0},
{"i915_frequency_info", i915_frequency_info, 0},
diff --git a/drivers/gpu/drm/i915/intel_guc_log.c 
b/drivers/gpu/drm/i915/intel_guc_log.c
index 16d3b87..31e7bec 100644
--- a/drivers/gpu/drm/i915/intel_guc_log.c
+++ b/drivers/gpu/drm/i915/intel_guc_log.c
@@ -660,3 +660,20 @@ void i915_guc_log_unregister(struct drm_i915_private 
*dev_priv)
guc_log_runtime_destroy(&dev_priv->guc);
mutex_unlock(&dev_priv->drm.struct_mutex);
 }
+
+void intel_guc_log_capture_load_err(struct intel_guc *guc)
+{
+   if (!guc->log.vma || i915.guc_log_level < 0)
+   return;
+
+   if (!guc->log.load_err)
+   guc->log.load_err = i915_gem_object_get(guc->log.vma->obj);
+
+   return;
+}
+
+void intel_guc_log_free_load_err(struct intel_guc *guc)
+{
+   if (guc->log.load_err)
+   i915_gem_object_put(guc->log.load_err);
+}
diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 07c5658..dfea7d0 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -309,6 +309,7 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 
guc_disable_communication(guc);
gen9_reset_guc_interrupts(dev_priv);
+   intel_guc_log_free_load_err(guc);
 
/* We need to notify the guc whenever we change the GGTT */
i915_ggtt_enable_guc(dev_priv);
@@ -355,11 +356,11 @@ int intel_uc_init_hw(struct drm_i915_private *dev_priv)
 
/* Did we succeded or run out of retries? */
if (ret)
-  

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [v3,1/3] drm: Plumb modifiers through plane init

[Patchwork]

== Series Details ==

Series: series starting with [v3,1/3] drm: Plumb modifiers through plane init
URL   : https://patchwork.freedesktop.org/series/24528/
State : failure

== Summary ==

Series 24528v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24528/revisions/1/mbox/

Test core_auth:
Subgroup basic-auth:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test core_prop_blob:
Subgroup basic:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_getparams_basic:
Subgroup basic-eu-total:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup basic-subslice-total:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test drv_hangman:
Subgroup error-state-basic:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Test gem_basic:
Subgroup bad-close:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-close:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-gvtdvm)
pass   -> SKIP   (fi-bsw-n3050)
pass   -> SKIP   (fi-skl-gvtdvm)
Subgroup create-fd-close:
pass   -> SKIP   (fi-ilk-650)
pass   -> SKIP   (fi-snb-2520m)
pass   -> SKIP   (fi-snb-2600)
pass   -> SKIP   (fi-ivb-3520m)
pass   -> SKIP   (fi-byt-j1900)
pass   -> SKIP   (fi-byt-n2820)
pass   -> SKIP   (fi-hsw-4770)
pass   -> SKIP   (fi-bdw-

[Intel-gfx] [PATCH v5 3/3] drm/i915: Add format modifiers for Intel

[Ben Widawsky]

This was based on a patch originally by Kristian. It has been modified
pretty heavily to use the new callbacks from the previous patch.

v2:
  - Add LINEAR and Yf modifiers to list (Ville)
  - Combine i8xx and i965 into one list of formats (Ville)
  - Allow 1010102 formats for Y/Yf tiled (Ville)

v3:
  - Handle cursor formats (Ville)
  - Put handling for LINEAR in the mod_support functions (Ville)

v4:
  - List each modifier explicitly in supported modifiers (Ville)
  - Handle the CURSOR plane (Ville)

v5:
  - Split out cursor and sprite handling (Ville)

Cc: Ville Syrjälä 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/i915/intel_display.c | 131 +--
 drivers/gpu/drm/i915/intel_sprite.c  |  76 +++-
 2 files changed, 201 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 9dd67d51e7c9..3519c10abcc3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -72,6 +72,12 @@ static const uint32_t i965_primary_formats[] = {
DRM_FORMAT_XBGR2101010,
 };
 
+static const uint64_t i9xx_format_modifiers[] = {
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_C8,
DRM_FORMAT_RGB565,
@@ -87,6 +93,14 @@ static const uint32_t skl_primary_formats[] = {
DRM_FORMAT_VYUY,
 };
 
+static const uint64_t skl_format_modifiers[] = {
+   I915_FORMAT_MOD_Yf_TILED,
+   I915_FORMAT_MOD_Y_TILED,
+   I915_FORMAT_MOD_X_TILED,
+   DRM_FORMAT_MOD_LINEAR,
+   DRM_FORMAT_MOD_INVALID
+};
+
 /* Cursor formats */
 static const uint32_t intel_cursor_formats[] = {
DRM_FORMAT_ARGB,
@@ -13381,6 +13395,103 @@ void intel_plane_destroy(struct drm_plane *plane)
kfree(to_intel_plane(plane));
 }
 
+static bool i8xx_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB1555:
+   case DRM_FORMAT_XRGB:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool i965_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   return modifier == DRM_FORMAT_MOD_LINEAR ||
+   modifier == I915_FORMAT_MOD_X_TILED;
+   default:
+   return false;
+   }
+}
+
+static bool skl_mod_supported(uint32_t format, uint64_t modifier)
+{
+   switch (format) {
+   case DRM_FORMAT_C8:
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   return true;
+   default:
+   return false;
+   }
+   case DRM_FORMAT_RGB565:
+   case DRM_FORMAT_XRGB:
+   case DRM_FORMAT_XBGR:
+   case DRM_FORMAT_ARGB:
+   case DRM_FORMAT_ABGR:
+   case DRM_FORMAT_XRGB2101010:
+   case DRM_FORMAT_XBGR2101010:
+   case DRM_FORMAT_YUYV:
+   case DRM_FORMAT_YVYU:
+   case DRM_FORMAT_UYVY:
+   case DRM_FORMAT_VYUY:
+   /* All i915 modifiers are fine */
+   switch (modifier) {
+   case DRM_FORMAT_MOD_LINEAR:
+   case I915_FORMAT_MOD_X_TILED:
+   case I915_FORMAT_MOD_Y_TILED:
+   case I915_FORMAT_MOD_Yf_TILED:
+   return true;
+   default:
+   return false;
+   }
+   default:
+   return false;
+   }
+}
+
+static bool intel_primary_plane_format_mod_supported(struct drm_plane *plane,
+uint32_t format,
+uint64_t modifier)
+{
+   struct drm_i915_private *dev_priv = to_i915(plane->dev);
+
+   if (WARN_ON(modifier == DRM_FORMAT_MOD_INVALID))
+   return false;
+
+   if (INTEL_GEN(dev_priv) >= 9)
+   return skl_mod_supported(format, modifier);
+   else if (INTEL_GEN(dev_priv) >= 4)
+   return i965_mod_supported(format, modifier);
+   else
+   return i8xx_mod_supported(format, modifier);
+
+   return false;
+}
+
+static bool intel_cursor_plane_format_mod_supported(struct drm_plane *plane,
+   uint32_t format,
+   uint64_t modifier)
+{
+   if (WARN_ON(modifier 

[Intel-gfx] [PATCH v3 1/3] drm: Plumb modifiers through plane init

[Ben Widawsky]

This is the plumbing for supporting fb modifiers on planes. Modifiers
have already been introduced to some extent, but this series will extend
this to allow querying modifiers per plane. Based on this, the client to
enable optimal modifications for framebuffers.

This patch simply allows the DRM drivers to initialize their list of
supported modifiers upon initializing the plane.

v2: A minor addition from Daniel

v3: Updated commit message
s/INVALID/DRM_FORMAT_MOD_INVALID (Liviu)
Remove some excess newlines (Liviu)
Update comment for > 64 modifiers (Liviu)

Cc: Liviu Dudau 
Reviewed-by: Daniel Stone  (v2)
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  1 +
 drivers/gpu/drm/arm/hdlcd_crtc.c|  1 +
 drivers/gpu/drm/arm/malidp_planes.c |  2 +-
 drivers/gpu/drm/armada/armada_crtc.c|  1 +
 drivers/gpu/drm/armada/armada_overlay.c |  1 +
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c |  4 ++-
 drivers/gpu/drm/drm_modeset_helper.c|  1 +
 drivers/gpu/drm/drm_plane.c | 35 -
 drivers/gpu/drm/drm_simple_kms_helper.c |  3 +++
 drivers/gpu/drm/exynos/exynos_drm_plane.c   |  2 +-
 drivers/gpu/drm/fsl-dcu/fsl_dcu_drm_plane.c |  2 +-
 drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_de.c  |  1 +
 drivers/gpu/drm/hisilicon/kirin/kirin_drm_ade.c |  2 +-
 drivers/gpu/drm/i915/intel_display.c|  5 +++-
 drivers/gpu/drm/i915/intel_sprite.c |  4 +--
 drivers/gpu/drm/imx/ipuv3-plane.c   |  4 +--
 drivers/gpu/drm/mediatek/mtk_drm_plane.c|  2 +-
 drivers/gpu/drm/meson/meson_plane.c |  1 +
 drivers/gpu/drm/msm/mdp/mdp4/mdp4_plane.c   |  2 +-
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_plane.c   |  4 +--
 drivers/gpu/drm/mxsfb/mxsfb_drv.c   |  2 +-
 drivers/gpu/drm/nouveau/nv50_display.c  |  5 ++--
 drivers/gpu/drm/omapdrm/omap_plane.c|  3 ++-
 drivers/gpu/drm/qxl/qxl_display.c   |  2 +-
 drivers/gpu/drm/rcar-du/rcar_du_plane.c |  4 +--
 drivers/gpu/drm/rcar-du/rcar_du_vsp.c   |  4 +--
 drivers/gpu/drm/rockchip/rockchip_drm_vop.c |  4 +--
 drivers/gpu/drm/sti/sti_cursor.c|  2 +-
 drivers/gpu/drm/sti/sti_gdp.c   |  2 +-
 drivers/gpu/drm/sti/sti_hqvdp.c |  2 +-
 drivers/gpu/drm/sun4i/sun4i_layer.c |  2 +-
 drivers/gpu/drm/tegra/dc.c  | 12 -
 drivers/gpu/drm/vc4/vc4_plane.c |  2 +-
 drivers/gpu/drm/virtio/virtgpu_plane.c  |  2 +-
 drivers/gpu/drm/vmwgfx/vmwgfx_ldu.c |  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c|  4 +--
 drivers/gpu/drm/vmwgfx/vmwgfx_stdu.c|  4 +--
 drivers/gpu/drm/zte/zx_plane.c  |  2 +-
 include/drm/drm_plane.h | 20 +-
 include/drm/drm_simple_kms_helper.h |  1 +
 include/uapi/drm/drm_fourcc.h   | 11 
 41 files changed, 126 insertions(+), 46 deletions(-)

diff --git a/drivers/gpu/drm/arc/arcpgu_crtc.c 
b/drivers/gpu/drm/arc/arcpgu_crtc.c
index ad9a95916f1f..cd8a24c7c67d 100644
--- a/drivers/gpu/drm/arc/arcpgu_crtc.c
+++ b/drivers/gpu/drm/arc/arcpgu_crtc.c
@@ -218,6 +218,7 @@ static struct drm_plane *arc_pgu_plane_init(struct 
drm_device *drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, &arc_pgu_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret)
return ERR_PTR(ret);
diff --git a/drivers/gpu/drm/arm/hdlcd_crtc.c b/drivers/gpu/drm/arm/hdlcd_crtc.c
index 798a3cc480a2..0caa03ae8708 100644
--- a/drivers/gpu/drm/arm/hdlcd_crtc.c
+++ b/drivers/gpu/drm/arm/hdlcd_crtc.c
@@ -303,6 +303,7 @@ static struct drm_plane *hdlcd_plane_init(struct drm_device 
*drm)
 
ret = drm_universal_plane_init(drm, plane, 0xff, &hdlcd_plane_funcs,
   formats, ARRAY_SIZE(formats),
+  NULL,
   DRM_PLANE_TYPE_PRIMARY, NULL);
if (ret) {
devm_kfree(drm->dev, plane);
diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 814fda23cead..b156610c68a5 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -400,7 +400,7 @@ int malidp_de_planes_init(struct drm_device *drm)
DRM_PLANE_TYPE_OVERLAY;
ret = drm_universal_plane_init(drm, &plane->base, crtcs,
   &malidp_de_plane_funcs, formats,
-  n, plane_type, NULL);
+  n, NULL, plane_type, NULL);
if (ret < 0)

[Intel-gfx] [PATCH v2 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

Updated blob layout (Rob, Daniel, Kristian, xerpi)

v2:
* Removed __packed, and alignment (.+)
* Fix indent in drm_format_modifier fields (Liviu)
* Remove duplicated modifier > 64 check (Liviu)
* Change comment about modifier (Liviu)
* Remove arguments to blob creation, use plane instead (Liviu)
* Fix data types (Ben)
* Make the blob part of uapi (Daniel)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Cc: Liviu Dudau 
Signed-off-by: Ben Widawsky 
Reviewed-by: Daniel Stone 
---
 drivers/gpu/drm/drm_mode_config.c |  7 +++
 drivers/gpu/drm/drm_plane.c   | 89 +++
 include/drm/drm_mode_config.h |  6 +++
 include/uapi/drm/drm_mode.h   | 50 ++
 4 files changed, 152 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;
 
+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 20203871e06d..f5b032b5f761 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,92 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }
 
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane)
+{
+   const struct drm_mode_config *config = &dev->mode_config;
+   const uint64_t *temp_modifiers = plane->modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (plane->modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(*plane->format_types) * plane->format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = sizeof(struct drm_format_modifier_blob);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = plane->format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), plane->format_types, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!plane->funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   for (j = 0; j < plane->format_count; j++) {
+   if (plane->funcs->format_mod_supported(plane,
+  
plane->format_types[j],
+  
plane->modifiers[i])) {
+
+   mod->formats |= 1 << j;
+   }
+   }
+
+   mod->modifier = plane->modifiers[i];
+   mod->offset = 0;
+   mod->pad = 0;
+   mod++;
+   }
+
+done:
+   drm_object_attach_property(&plane->base, config->modifiers,
+  blob->base.id);
+
+   return ret;
+}
+
 /**
  * drm_universal_plane_init - Initialize a new universal plane object
  * @dev: DRM device
@@ -180,6 +266,9 @@ int drm_universal_plane_init(struc

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Tue, 2017-05-16 at 13:56 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Tue, May 16, 2017 at 1:29 PM, Pandiyan, Dhinakaran
>  wrote:
> On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat
> wrote:
> >
> >
> > On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Mon, 2017-05-15 at 17:43 -0700, Puthikorn
> Voravootivat
> > wrote:
> > >
> > >
> > > On Mon, May 15, 2017 at 4:07 PM, Pandiyan,
> Dhinakaran
> > >  wrote:
> > > On Fri, 2017-05-12 at 17:31 -0700,
> Puthikorn
> > Voravootivat
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Fri, May 12, 2017 at 5:12 PM,
> Pandiyan,
> > Dhinakaran
> > > >  wrote:
> > > > On Thu, 2017-05-11 at 16:02
> -0700,
> > Puthikorn
> > > Voravootivat
> > > > wrote:
> > > > > Read desired PWM frequency
> from panel
> > vbt and
> > > calculate the
> > > > > value for divider in DPCD
> address 0x724
> > and 0x728
> > > to have
> > > > > as many bits as possible for
> PWM duty
> > cyle for
> > > granularity
> > > > of
> > > > > brightness adjustment while
> the
> > frequency is still
> > > within
> > > > 25%
> > > > > of the desired frequency.
> > > >
> > > > I read a few eDP panel data
> sheets, the
> > PWM
> > > frequencies all
> > > > start from
> > > > ~200Hz. If the VBT chooses this
> lowest
> > value to
> > > allow for more
> > > > brightness control, and then
> this patch
> > lowers the
> > > value by
> > > > another 25%,
> > > > we'll end up below the panel
> allowed PWM
> > frequency.
> > > >
> > > > In fact, one of the systems I
> checked had
> > PWM
> > > frequency as
> > > > 200Hz in VBT
> > > > and the panel datasheet also had
> PWM
> > frequency range
> > > starting
> > > > from
> > > > 200Hz. Have you considered this
> case?
> > > >
> > > > The spec said "A given LCD panel
> typically has a
> > limited
> > > range of
> > > > backlight frequency capability.
> > > > To limit the programmable frequency
> range,
> > limitations are
> > > placed on
> > > > the allowable total divider ratio with
> the Sink
> > device"
> > > >  So I think it should be auto cap to
> 200Hz in this
> > case.
> > > >
> > > > -DK
> > > > >
> > > > > Signed-off-by: Puthikorn
> Voravootivat
> > > 
> > > > > ---
> > > > >
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > > 81
> > > > +++
> > > > >  1 file changed, 81
> insertions(+)
> > > > >
> > > > > diff --git
> > >
>  a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > >
> >  b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > index
> 0b48851013cc..6f10a2f1ab76 100644
> > > > > ---
> > >
>  a/drivers/gpu/drm/i

Re: [Intel-gfx] [PATCH 2/3] drm: Create a format/modifier blob

[Ben Widawsky]

On 17-05-03 17:08:27, Daniel Vetter wrote:

On Tue, May 02, 2017 at 10:14:27PM -0700, Ben Widawsky wrote:

Updated blob layout (Rob, Daniel, Kristian, xerpi)

Cc: Rob Clark 
Cc: Daniel Stone 
Cc: Kristian H. Kristensen 
Signed-off-by: Ben Widawsky 
---
 drivers/gpu/drm/drm_mode_config.c |   7 +++
 drivers/gpu/drm/drm_plane.c   | 119 ++
 include/drm/drm_mode_config.h |   6 ++
 include/uapi/drm/drm_mode.h   |  26 +
 4 files changed, 158 insertions(+)

diff --git a/drivers/gpu/drm/drm_mode_config.c 
b/drivers/gpu/drm/drm_mode_config.c
index d9862259a2a7..6bfbc3839df5 100644
--- a/drivers/gpu/drm/drm_mode_config.c
+++ b/drivers/gpu/drm/drm_mode_config.c
@@ -337,6 +337,13 @@ static int drm_mode_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.gamma_lut_size_property = prop;

+   prop = drm_property_create(dev,
+  DRM_MODE_PROP_IMMUTABLE | DRM_MODE_PROP_BLOB,
+  "IN_FORMATS", 0);
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.modifiers = prop;
+
return 0;
 }

diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
index 286e183891e5..2e89e0e73435 100644
--- a/drivers/gpu/drm/drm_plane.c
+++ b/drivers/gpu/drm/drm_plane.c
@@ -62,6 +62,117 @@ static unsigned int drm_num_planes(struct drm_device *dev)
return num;
 }

+struct drm_format_modifier_blob {
+#define FORMAT_BLOB_CURRENT 1
+   /* Version of this blob format */
+   u32 version;
+
+   /* Flags */
+   u32 flags;
+
+   /* Number of fourcc formats supported */
+   u32 count_formats;
+
+   /* Where in this blob the formats exist (in bytes) */
+   u32 formats_offset;
+
+   /* Number of drm_format_modifiers */
+   u32 count_modifiers;
+
+   /* Where in this blob the modifiers exist (in bytes) */
+   u32 modifiers_offset;
+
+   /* u32 formats[] */
+   /* struct drm_format_modifier modifiers[] */
+} __packed;


The struct should be in the uapi header. Otherwise it won't show up in
libdrm headers when following the proper process.
-Daniel



I don't agree that blobs are ever really part of the API, but it doesn't hurt to
move it... in other words, done.


+
+static inline u32 *
+formats_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (u32 *)(((char *)blob) + blob->formats_offset);
+}
+
+static inline struct drm_format_modifier *
+modifiers_ptr(struct drm_format_modifier_blob *blob)
+{
+   return (struct drm_format_modifier *)(((char *)blob) + 
blob->modifiers_offset);
+}
+
+static int create_in_format_blob(struct drm_device *dev, struct drm_plane 
*plane,
+const struct drm_plane_funcs *funcs,
+const uint32_t *formats, unsigned int 
format_count,
+const uint64_t *format_modifiers)
+{
+   const struct drm_mode_config *config = &dev->mode_config;
+   const uint64_t *temp_modifiers = format_modifiers;
+   unsigned int format_modifier_count = 0;
+   struct drm_property_blob *blob = NULL;
+   struct drm_format_modifier *mod;
+   size_t blob_size = 0, formats_size, modifiers_size;
+   struct drm_format_modifier_blob *blob_data;
+   int i, j, ret = 0;
+
+   if (format_modifiers)
+   while (*temp_modifiers++ != DRM_FORMAT_MOD_INVALID)
+   format_modifier_count++;
+
+   formats_size = sizeof(__u32) * format_count;
+   if (WARN_ON(!formats_size)) {
+   /* 0 formats are never expected */
+   return 0;
+   }
+
+   modifiers_size =
+   sizeof(struct drm_format_modifier) * format_modifier_count;
+
+   blob_size = ALIGN(sizeof(struct drm_format_modifier_blob), 8);
+   blob_size += ALIGN(formats_size, 8);
+   blob_size += modifiers_size;
+
+   blob = drm_property_create_blob(dev, blob_size, NULL);
+   if (IS_ERR(blob))
+   return -1;
+
+   blob_data = (struct drm_format_modifier_blob *)blob->data;
+   blob_data->version = FORMAT_BLOB_CURRENT;
+   blob_data->count_formats = format_count;
+   blob_data->formats_offset = sizeof(struct drm_format_modifier_blob);
+   blob_data->count_modifiers = format_modifier_count;
+
+   /* Modifiers offset is a pointer to a struct with a 64 bit field so it
+* should be naturally aligned to 8B.
+*/
+   blob_data->modifiers_offset =
+   ALIGN(blob_data->formats_offset + formats_size, 8);
+
+   memcpy(formats_ptr(blob_data), formats, formats_size);
+
+   /* If we can't determine support, just bail */
+   if (!funcs->format_mod_supported)
+   goto done;
+
+   mod = modifiers_ptr(blob_data);
+   for (i = 0; i < format_modifier_count; i++) {
+   for (j = 0; j < format_count; j++) {
+  

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

On Tue, May 16, 2017 at 1:29 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat wrote:
> >
> >
> > On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat
> > wrote:
> > >
> > >
> > > On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
> > >  wrote:
> > > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn
> > Voravootivat
> > > wrote:
> > > >
> > > >
> > > >
> > > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan,
> > Dhinakaran
> > > >  wrote:
> > > > On Thu, 2017-05-11 at 16:02 -0700,
> > Puthikorn
> > > Voravootivat
> > > > wrote:
> > > > > Read desired PWM frequency from panel
> > vbt and
> > > calculate the
> > > > > value for divider in DPCD address 0x724
> > and 0x728
> > > to have
> > > > > as many bits as possible for PWM duty
> > cyle for
> > > granularity
> > > > of
> > > > > brightness adjustment while the
> > frequency is still
> > > within
> > > > 25%
> > > > > of the desired frequency.
> > > >
> > > > I read a few eDP panel data sheets, the
> > PWM
> > > frequencies all
> > > > start from
> > > > ~200Hz. If the VBT chooses this lowest
> > value to
> > > allow for more
> > > > brightness control, and then this patch
> > lowers the
> > > value by
> > > > another 25%,
> > > > we'll end up below the panel allowed PWM
> > frequency.
> > > >
> > > > In fact, one of the systems I checked had
> > PWM
> > > frequency as
> > > > 200Hz in VBT
> > > > and the panel datasheet also had PWM
> > frequency range
> > > starting
> > > > from
> > > > 200Hz. Have you considered this case?
> > > >
> > > > The spec said "A given LCD panel typically has a
> > limited
> > > range of
> > > > backlight frequency capability.
> > > > To limit the programmable frequency range,
> > limitations are
> > > placed on
> > > > the allowable total divider ratio with the Sink
> > device"
> > > >  So I think it should be auto cap to 200Hz in this
> > case.
> > > >
> > > > -DK
> > > > >
> > > > > Signed-off-by: Puthikorn Voravootivat
> > > 
> > > > > ---
> > > > >
> > drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > > 81
> > > > +++
> > > > >  1 file changed, 81 insertions(+)
> > > > >
> > > > > diff --git
> > > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > >
> >  b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > index 0b48851013cc..6f10a2f1ab76 100644
> > > > > ---
> > > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > +++
> > > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > > @@ -113,12 +113,86 @@
> > > >
> >  intel_dp_aux_set_dynamic_backlight_percent(struct
> > > intel_dp
> > > > *intel_dp,
> > > > >   }
> > > > >  }
> > > > >
> > > > > +/*
> > > > > + * Set PWM Frequency divider to match
> > desired
> > > frequency in
> > > > vbt.
> > > > > + * The PWM Frequency is calculated as
> > 27Mhz / (F
> > > x P).
> > > > > + * - Where F = PWM Frequency
> > Pre-Divider value
> > > programmed
> > > > by field 7:0 of the
> > > > > + * EDP_BACKLIGHT_FRE

Re: [Intel-gfx] Call trace on 4.12.0-rc1

[Hans de Goede]

Hi,

On 05/16/2017 09:55 PM, FKr wrote:

Hi,
I'm using 4.12.0-rc1 from https://github.com/jwrdegoede/linux-sunxi and got
the following weird trace yesterday. Previously I've been getting output
similar to https://www.spinics.net/lists/intel-gfx/msg127638.html, some boots
on 4.12.0-rc1  I don't get any trace at all.


This is really weird, we are getting the error while we are trying to
acquire the wakelock ... ? Or do we need some other lock before we can
take the wakelock ?

Any input from one of the Intel developers would be appreciated.

Regards,

Hans




[ 2383.844192] perf: interrupt took too long (2522 > 2500), lowering
kernel.perf_event_max_sample_rate to 79200
[ 2634.863978] [drm:intel_pipe_update_end] *ERROR* Atomic update failure on
pipe A (start=157909 end=157910) time 322 us, min 1073, max 1079, scanline
start 1063, end 1084
[ 2647.881794] perf: interrupt took too long (3193 > 3152), lowering
kernel.perf_event_max_sample_rate to 62400
[ 3297.857921] perf: interrupt took too long (4020 > 3991), lowering
kernel.perf_event_max_sample_rate to 49500
[ 4670.977136] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 4671.436604] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 4680.756302] mmc0: Tuning timeout, falling back to fixed sampling clock
[ 4707.846872] perf: interrupt took too long (5046 > 5025), lowering
kernel.perf_event_max_sample_rate to 39600
[ 4846.672969] RPM wakelock ref not held during HW access
[ 4846.673050] [ cut here ]
[ 4846.673084] WARNING: CPU: 0 PID: 5227 at drivers/gpu/drm/i915/intel_drv.h:
1780 intel_uncore_forcewake_get+0xa0/0xb0
[ 4846.673088] Modules linked in: snd_soc_sst_cht_bsw_nau8824 btusb btintel
bluetooth axp288_fuel_gauge ecdh_generic axp288_charger extcon_axp288
axp288_adc snd_hdmi_lpe_audio snd_intel_sst_acpi extcon_intel_int3496
snd_intel_sst_core extcon_core snd_soc_nau8824 snd_soc_sst_atom_hifi2_platform
snd_soc_core snd_compress snd_soc_sst_match snd_pcm snd_timer kxcjk_1013
industrialio_triggered_buffer intel_cht_int33fe snd soundcore intel_int0002
[ 4846.673201] CPU: 0 PID: 5227 Comm: kworker/0:1 Not tainted 4.12.0-rc1+ #3
[ 4846.673206] Hardware name: MEDION E2228T MD60250/NT16H, BIOS 5.11
02/27/2017
[ 4846.673224] Workqueue: events fuel_gauge_status_monitor [axp288_fuel_gauge]
[ 4846.673235] task: 8800a85be800 task.stack: c9000261
[ 4846.673248] RIP: 0010:intel_uncore_forcewake_get+0xa0/0xb0
[ 4846.673255] RSP: 0018:c90002613aa0 EFLAGS: 00010286
[ 4846.673265] RAX: 002a RBX: 880136cc8000 RCX:
82063e88
[ 4846.673272] RDX:  RSI: 0082 RDI:
0247
[ 4846.673278] RBP: c90002613ac0 R08: 002a R09:
02ac
[ 4846.673284] R10: 0001 R11:  R12:
0007
[ 4846.673289] R13: 0001 R14:  R15:

[ 4846.673298] FS:  () GS:88013fc0() knlGS:

[ 4846.673305] CS:  0010 DS:  ES:  CR0: 80050033
[ 4846.673311] CR2: 0758c709c000 CR3: 02009000 CR4:
001006f0
[ 4846.673317] Call Trace:
[ 4846.673340]  i915_pmic_bus_access_notifier+0x37/0x40
[ 4846.673354]  notifier_call_chain+0x4a/0x70
[ 4846.673368]  __blocking_notifier_call_chain+0x47/0x60
[ 4846.673380]  blocking_notifier_call_chain+0x16/0x20
[ 4846.673393]  iosf_mbi_call_pmic_bus_access_notifier_chain+0x1b/0x20
[ 4846.673406]  baytrail_i2c_acquire+0x64/0x220
[ 4846.673420]  i2c_dw_acquire_lock+0x21/0x50
[ 4846.673431]  i2c_dw_xfer+0xa3/0x4a0
[ 4846.673444]  __i2c_transfer+0x115/0x430
[ 4846.673456]  i2c_transfer+0x5c/0xc0
[ 4846.673469]  regmap_i2c_read+0x6d/0xa0
[ 4846.673482]  _regmap_raw_read+0xda/0x210
[ 4846.673491]  ? _regmap_raw_read+0xda/0x210
[ 4846.673503]  ? __update_load_avg_se.isra.5+0x15b/0x180
[ 4846.673514]  _regmap_bus_read+0x2a/0x60
[ 4846.673524]  _regmap_read+0x6c/0x130
[ 4846.673535]  regmap_read+0x3f/0x60
[ 4846.673549]  fuel_gauge_reg_readb.isra.5+0x40/0x90 [axp288_fuel_gauge]
[ 4846.673564]  fuel_gauge_get_status+0x2d/0x100 [axp288_fuel_gauge]
[ 4846.673577]  ? __schedule+0x2e3/0x840
[ 4846.673590]  fuel_gauge_status_monitor+0x16/0x40 [axp288_fuel_gauge]
[ 4846.673603]  process_one_work+0x1e0/0x420
[ 4846.673616]  worker_thread+0x48/0x3f0
[ 4846.673629]  kthread+0x108/0x140
[ 4846.673640]  ? process_one_work+0x420/0x420
[ 4846.673650]  ? kthread_create_on_node+0x70/0x70
[ 4846.673662]  ret_from_fork+0x2c/0x40
[ 4846.673673] Code: 05 51 79 a1 00 01 e8 84 3c ae ff 0f ff eb a5 80 3d 40 79
a1 00 00 75 a6 48 c7 c7 98 fe e9 81 c6 05 30 79 a1 00 01 e8 64 3c ae ff <0f>
ff eb 8f 66 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
[ 4846.673896] ---[ end trace 4f0b6934a8fd8068 ]---

Regards,
FKr


___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Pandiyan, Dhinakaran]

On Tue, 2017-05-16 at 11:07 -0700, Puthikorn Voravootivat wrote:
> 
> 
> On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran
>  wrote:
> On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat
> wrote:
> >
> >
> > On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn
> Voravootivat
> > wrote:
> > >
> > >
> > >
> > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan,
> Dhinakaran
> > >  wrote:
> > > On Thu, 2017-05-11 at 16:02 -0700,
> Puthikorn
> > Voravootivat
> > > wrote:
> > > > Read desired PWM frequency from panel
> vbt and
> > calculate the
> > > > value for divider in DPCD address 0x724
> and 0x728
> > to have
> > > > as many bits as possible for PWM duty
> cyle for
> > granularity
> > > of
> > > > brightness adjustment while the
> frequency is still
> > within
> > > 25%
> > > > of the desired frequency.
> > >
> > > I read a few eDP panel data sheets, the
> PWM
> > frequencies all
> > > start from
> > > ~200Hz. If the VBT chooses this lowest
> value to
> > allow for more
> > > brightness control, and then this patch
> lowers the
> > value by
> > > another 25%,
> > > we'll end up below the panel allowed PWM
> frequency.
> > >
> > > In fact, one of the systems I checked had
> PWM
> > frequency as
> > > 200Hz in VBT
> > > and the panel datasheet also had PWM
> frequency range
> > starting
> > > from
> > > 200Hz. Have you considered this case?
> > >
> > > The spec said "A given LCD panel typically has a
> limited
> > range of
> > > backlight frequency capability.
> > > To limit the programmable frequency range,
> limitations are
> > placed on
> > > the allowable total divider ratio with the Sink
> device"
> > >  So I think it should be auto cap to 200Hz in this
> case.
> > >
> > > -DK
> > > >
> > > > Signed-off-by: Puthikorn Voravootivat
> > 
> > > > ---
> > > >
> drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > 81
> > > +++
> > > >  1 file changed, 81 insertions(+)
> > > >
> > > > diff --git
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > >
>  b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > index 0b48851013cc..6f10a2f1ab76 100644
> > > > ---
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > +++
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > @@ -113,12 +113,86 @@
> > >
>  intel_dp_aux_set_dynamic_backlight_percent(struct
> > intel_dp
> > > *intel_dp,
> > > >   }
> > > >  }
> > > >
> > > > +/*
> > > > + * Set PWM Frequency divider to match
> desired
> > frequency in
> > > vbt.
> > > > + * The PWM Frequency is calculated as
> 27Mhz / (F
> > x P).
> > > > + * - Where F = PWM Frequency
> Pre-Divider value
> > programmed
> > > by field 7:0 of the
> > > > + * EDP_BACKLIGHT_FREQ_SET
> register
> > (DPCD
> > > Address 00728h)
> > > > + * - Where P = 2^Pn, where Pn is the
> value
> > programmed by
> > > field 4:0 of the
> > > > + * EDP_PWMGEN_BIT_

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

[Puthikorn Voravootivat]

On Mon, May 15, 2017 at 11:21 PM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Mon, 2017-05-15 at 17:43 -0700, Puthikorn Voravootivat wrote:
> >
> >
> > On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran
> >  wrote:
> > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn Voravootivat
> > wrote:
> > >
> > >
> > >
> > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran
> > >  wrote:
> > > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn
> > Voravootivat
> > > wrote:
> > > > Read desired PWM frequency from panel vbt and
> > calculate the
> > > > value for divider in DPCD address 0x724 and 0x728
> > to have
> > > > as many bits as possible for PWM duty cyle for
> > granularity
> > > of
> > > > brightness adjustment while the frequency is still
> > within
> > > 25%
> > > > of the desired frequency.
> > >
> > > I read a few eDP panel data sheets, the PWM
> > frequencies all
> > > start from
> > > ~200Hz. If the VBT chooses this lowest value to
> > allow for more
> > > brightness control, and then this patch lowers the
> > value by
> > > another 25%,
> > > we'll end up below the panel allowed PWM frequency.
> > >
> > > In fact, one of the systems I checked had PWM
> > frequency as
> > > 200Hz in VBT
> > > and the panel datasheet also had PWM frequency range
> > starting
> > > from
> > > 200Hz. Have you considered this case?
> > >
> > > The spec said "A given LCD panel typically has a limited
> > range of
> > > backlight frequency capability.
> > > To limit the programmable frequency range, limitations are
> > placed on
> > > the allowable total divider ratio with the Sink device"
> > >  So I think it should be auto cap to 200Hz in this case.
> > >
> > > -DK
> > > >
> > > > Signed-off-by: Puthikorn Voravootivat
> > 
> > > > ---
> > > >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c |
> > 81
> > > +++
> > > >  1 file changed, 81 insertions(+)
> > > >
> > > > diff --git
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > index 0b48851013cc..6f10a2f1ab76 100644
> > > > ---
> > a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > +++
> > b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > > > @@ -113,12 +113,86 @@
> > > intel_dp_aux_set_dynamic_backlight_percent(struct
> > intel_dp
> > > *intel_dp,
> > > >   }
> > > >  }
> > > >
> > > > +/*
> > > > + * Set PWM Frequency divider to match desired
> > frequency in
> > > vbt.
> > > > + * The PWM Frequency is calculated as 27Mhz / (F
> > x P).
> > > > + * - Where F = PWM Frequency Pre-Divider value
> > programmed
> > > by field 7:0 of the
> > > > + * EDP_BACKLIGHT_FREQ_SET register
> > (DPCD
> > > Address 00728h)
> > > > + * - Where P = 2^Pn, where Pn is the value
> > programmed by
> > > field 4:0 of the
> > > > + * EDP_PWMGEN_BIT_COUNT register
> > (DPCD Address
> > > 00724h)
> > > > + */
> > > > +static void intel_dp_aux_set_pwm_freq(struct
> > > intel_connector *connector)
> > > > +{
> > > > + struct drm_i915_private *dev_priv =
> > > to_i915(connector->base.dev);
> > > > + struct intel_dp *intel_dp =
> > > enc_to_intel_dp(&connector->encoder->base);
> > > > + int freq, fxp, fxp_min, fxp_max, fxp_actual,
> > f = 1;
> > > > + u8 pn, pn_min, pn_max;
> > > > +
> > > > + /* Find desired value of (F x P)
> > > > +  * Note that, if F x P is out of supported
> > range, the
> > > maximum value or
> > > > +  * minimum value will applied automatically.
> > So no
> > > need to check that.
> > > > +  */
> >   

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

[Michal Wajdeczko]

On Mon, May 15, 2017 at 04:47:16PM -0700, Daniele Ceraolo Spurio wrote:
> 
> 
> On 15/05/17 10:41, Michal Wajdeczko wrote:
> > On Mon, May 15, 2017 at 09:35:30AM -0700, Daniele Ceraolo Spurio wrote:
> > > We're currently deleting the GuC logs if the FW fails to load, but those
> > > are still useful to understand why the loading failed. Keeping the
> > > object around allows us to access them after driver load is completed.
> > > 
> > > v2: keep the object around instead of using kernel memory (chris)
> > > don't store the logs in the gpu_error struct (Chris)
> > > add a check on guc_log_level to avoid snapshotting empty logs
> > > 
> > > v3: use separate debugfs for error log (Chris)
> > > 
> > > v4: rebased
> > > 
> > > Reviewed-by: Chris Wilson  (v3)
> > > Cc: Chris Wilson 
> > > Cc: Oscar Mateo 
> > > Cc: Michal Wajdeczko 
> > > Signed-off-by: Daniele Ceraolo Spurio 
> > > ---
> > >  drivers/gpu/drm/i915/i915_debugfs.c  | 35 
> > > ++-
> > >  drivers/gpu/drm/i915/i915_drv.c  |  3 +++
> > >  drivers/gpu/drm/i915/intel_guc_log.c | 17 +
> > >  drivers/gpu/drm/i915/intel_uc.c  |  7 +--
> > >  drivers/gpu/drm/i915/intel_uc.h  |  5 +
> > >  5 files changed, 52 insertions(+), 15 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> > > b/drivers/gpu/drm/i915/i915_debugfs.c
> > > index bd9abef..d9a5bd8 100644
> > > --- a/drivers/gpu/drm/i915/i915_debugfs.c
> > > +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> > > @@ -2607,27 +2607,35 @@ static int i915_guc_stage_pool(struct seq_file 
> > > *m, void *data)
> > > 
> > >  static int i915_guc_log_dump(struct seq_file *m, void *data)
> > >  {
> > > - struct drm_i915_private *dev_priv = node_to_i915(m->private);
> > > + struct drm_info_node *node = m->private;
> > > + struct drm_i915_private *dev_priv = node_to_i915(node);
> > > + bool dump_err_log = !!node->info_ent->data;
> > >   struct drm_i915_gem_object *obj;
> > > - int i = 0, pg;
> > > + u32 *log;
> > > + int i = 0;
> > > 
> > > - if (!dev_priv->guc.log.vma)
> > > + if (!dump_err_log && dev_priv->guc.log.vma)
> > > + obj = dev_priv->guc.log.vma->obj;
> > > + else if (dump_err_log && dev_priv->guc.err_load_log)
> > > + obj = dev_priv->guc.err_load_log;
> > > + else
> > >   return 0;
> > 
> > Maybe we can move actual printfs into separate generic function that
> > will just take desired obj? It will simplify this function and possibly
> > allow more reuse of that new funcion in the future.
> > 
> 
> The problem here would be that each debugfs function has its own desired
> formatting and might only be interested in a section of an object (e.g.
> i915_dump_lrc_obj), not sure how much we can reuse. I'd prefer to wait for
> an actual use case before splitting it out.
> 
> > We can even try define two separate small functions with names that
> > corresponds to the debugfs entry, to follow all other functions
> > 
> 
> We already have a case where 2 debugfs entries are pointing to the same
> function (i915_gem_gtt and i915_gem_pin_display) and it feels cleaner to me
> compared to having 2 one-liner function just to pick between the different
> objects. If you're ok with it I'd prefer to instead clean up the if
> statement the following way to make the obj selection more evident:
> 
>   if (dump_err_log)
>   obj = dev_priv->guc.log.err_load;
>   else
>   obj = dev_priv->guc.log.vma->obj;
> 
>   if (!obj)
>   return 0;
> 

Ok, we start with this.

> > > 
> > > - obj = dev_priv->guc.log.vma->obj;
> > > - for (pg = 0; pg < obj->base.size / PAGE_SIZE; pg++) {
> > > - u32 *log = kmap_atomic(i915_gem_object_get_page(obj, pg));
> > > -
> > > - for (i = 0; i < PAGE_SIZE / sizeof(u32); i += 4)
> > > - seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> > > -*(log + i), *(log + i + 1),
> > > -*(log + i + 2), *(log + i + 3));
> > > -
> > > - kunmap_atomic(log);
> > > + log = i915_gem_object_pin_map(obj, I915_MAP_WC);
> > > + if (IS_ERR(log)) {
> > > + DRM_ERROR("Failed to pin guc_log object\n");
> > > + return PTR_ERR(log);
> > >   }
> > > 
> > > + for (i = 0; i < obj->base.size / sizeof(u32); i += 4)
> > > + seq_printf(m, "0x%08x 0x%08x 0x%08x 0x%08x\n",
> > > +*(log + i), *(log + i + 1),
> > > +*(log + i + 2), *(log + i + 3));
> > > +
> > >   seq_putc(m, '\n');
> > > 
> > > + i915_gem_object_unpin_map(obj);
> > > +
> > >   return 0;
> > >  }
> > > 
> > > @@ -4811,6 +4819,7 @@ static int i915_hpd_storm_ctl_open(struct inode 
> > > *inode, struct file *file)
> > >   {"i915_guc_info", i915_guc_info, 0},
> > >   {"i915_guc_load_status", i915_guc_load_status_info, 0},
> > >   {"i915_guc_log_dump", i915_guc_log_dump, 0},
> > > + {"i915_guc_err_load_log_dump", i915_guc_log_dump, 0, (void *)1},
> > >   {"i915_guc_s

Re: [Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

[Maarten Lankhorst]

Op 15-05-17 om 10:34 schreef Mahesh Kumar:
> From: "Kumar, Mahesh" 
>
> This patch implements new DDB allocation algorithm as per HW team
> recommendation. This algo takecare of scenario where we allocate less DDB
> for the planes with lower relative pixel rate, but they require more DDB
> to work.
> It also takes care of enabling same watermark level for each
> plane in crtc, for efficient power saving.
>
> Changes since v1:
>  - Rebase on top of Paulo's patch series
>
> Changes since v2:
>  - Fix the for loop condition to enable WM
>
> Changes since v3:
>  - Fix crash in cursor i-g-t reported by Maarten
>  - Rebase after addressing Paulo's comments
>  - Few other ULT fixes
> Changes since v4:
>  - Rebase on drm-tip
>  - Added separate function to enable WM levels
> Changes since v5:
>  - Fix a crash identified in skl-6770HQ system
My main fear is that we may now add crtc's that were not part of the state 
before, so anything that may change watermarks may cause a pageflip on a 
unrelated crtc to return -EBUSY.
However this only happens during atomic commit and might also happen on 
nonblocking modesets, so it's probably harmless for now.

Reviewed-by: Maarten Lankhorst 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PULL] drm-misc-next

[Sean Paul]

Hi Dave,
Apologies for the previous early pull request. This one, hopefully, is more
appropriately timed. I've rolled the previous PR into this one, so you might
notice a couple familiar summaries.

As with the previous pull, I've Cc'd all of the summary-line contributors so
they can keep me honest in my summarization.


drm-misc-next-2017-05-16:
UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)
- Add aspect ratio and custom scaling propertis to connector state (Maarten)

Cross-subsystem Changes:
- None

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)
- Add driver-private objects to atomic state (Dhinakaran)
- Deprecate preclose hook in modern drivers (use postclose) (Daniel)
- Add hwmode to vblank struct. This fixes mode access in irq context and reduced
  a bunch of boilerplate (Daniel)

Driver Changes:
- vc4: Add out-fence support to vc4 V3D rendering (Eric)
- stm: Add stm32f429 display hw and am-480272h3tmqw-t01h panel support (Yannick)
- vc4: Remove 256MB cma limit from vc4 (Eric)
- dw-hdmi: Disable audio when inactive, instead of always enabled (Romain)
- zte: Add support for VGA to the ZTE driver (Shawn)
- i915: Track DP MST bandwidth and check it in atomic_check (Dhinakaran)
- vgem: Enable gem dmabuf import iface to facilitate ion testing (Laura)
- vc4: Add support for Cygnus (new dt compat string + couple bug fixes) (Eric)
- pl111: Add driver for pl111 CLCD display controller (Eric/Tom)
- vgem: Subclass drm_device instead of standalone platform device (Chris)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 
Cc: Dhinakaran Pandiyan 
Cc: Laura Abbott 
Cc: Maarten Lankhorst 
Cc: Tom Cooksey 
Cc: Daniel Vetter 
Cc: Chris Wilson 

Thanks,

Sean


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-misc tags/drm-misc-next-2017-05-16

for you to fetch changes up to 9cf8f5802f39d9991158b29033c852bccfc3a4d4:

  drm: add missing declaration to drm_blend.h (2017-05-16 15:09:56 +0200)


UAPI Changes:
- Return -ENODEV instead of -ENXIO when creating cma fb w/o valid gem (Daniel)
- Add aspect ratio and custom scaling propertis to connector state (Maarten)

Cross-subsystem Changes:
- None

Core Changes:
- Add Laurent as bridge reviewer and Andrzej as bridge maintainer (Archit)
- Maintain new STM driver through -misc (Yannick)
- Misc doc improvements (as is tradition) (Daniel)
- Add driver-private objects to atomic state (Dhinakaran)
- Deprecate preclose hook in modern drivers (use postclose) (Daniel)
- Add hwmode to vblank struct. This fixes mode access in irq context and reduced
  a bunch of boilerplate (Daniel)

Driver Changes:
- vc4: Add out-fence support to vc4 V3D rendering (Eric)
- stm: Add stm32f429 display hw and am-480272h3tmqw-t01h panel support (Yannick)
- vc4: Remove 256MB cma limit from vc4 (Eric)
- dw-hdmi: Disable audio when inactive, instead of always enabled (Romain)
- zte: Add support for VGA to the ZTE driver (Shawn)
- i915: Track DP MST bandwidth and check it in atomic_check (Dhinakaran)
- vgem: Enable gem dmabuf import iface to facilitate ion testing (Laura)
- vc4: Add support for Cygnus (new dt compat string + couple bug fixes) (Eric)
- pl111: Add driver for pl111 CLCD display controller (Eric/Tom)
- vgem: Subclass drm_device instead of standalone platform device (Chris)

Cc: Archit Taneja 
Cc: Eric Anholt 
Cc: Yannick Fertre 
Cc: Romain Perier 
Cc: Navare, Manasi D 
Cc: Shawn Guo 
Cc: Dhinakaran Pandiyan 
Cc: Laura Abbott 
Cc: Maarten Lankhorst 
Cc: Tom Cooksey 
Cc: Daniel Vetter 
Cc: Chris Wilson 


Andres Rodriguez (1):
  dma-buf: avoid scheduling on fence status query v2

Archit Taneja (1):
  MAINTAINERS: Update maintainers/reviewers for bridge drivers

Boris Brezillon (1):
  drm/vc4: Add runtime PM support to the HDMI encoder driver

Chris Wilson (4):
  drm/mm: Split up long running selftests with cond_resched()
  drm/vgem: Convert to a struct drm_device subclass
  drm/dp: Read the tx msg state once after checking for an event
  drm/dp: Wait up all outstanding tx waiters

Clint Taylor (1):
  drm/cec: Add CEC over Aux register definitions

Colin Ian King (1):
  drm: fix spelling mistake: "committing"

Daniel Vetter (12):
  drm/doc: Fix missing @ctx documentation
  drm/doc: Interlink color manager docs better
  drm/cma-helper: Return ENOENT for "no such gem obj"
  drm/nouveau: Merge pre/postclose hooks
  drm/tegra: switch to postclose
  drm/exynos: M

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Try harder to reset the GPU

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Try harder to reset the GPU
URL   : https://patchwork.freedesktop.org/series/24505/
State : success

== Summary ==

Series 24505v1 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24505/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:452s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:433s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:589s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:491s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:492s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:413s
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:498s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:462s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:582s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:578s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:502s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:442s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:543s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:409s

1ccfa1579c1dd3e45e4d9d5ef44329f04a77910e drm-tip: 2017y-05m-16d-13h-14m-11s UTC 
integration manifest
82bf9db drm/i915: Reorder media/render reset on g4x

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4710/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

[Michal Wajdeczko]

On Tue, May 16, 2017 at 03:24:54PM +0200, Arkadiusz Hiler wrote:
> Makefile.sources are included 1:1 in Android.mk files, and are not
> parsed by automake. And yet those had some automake conditional logic.
> Moving it to .am file is enough for now.

Hmm, all sources shall be listed only in Makefile.sources, which in turn,
shall not have any logic.

> 
> Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
> guard, and the file itself was included unconditionally.
> 
> Signed-off-by: Arkadiusz Hiler 
> ---
>  lib/Makefile.am| 7 +++
>  lib/Makefile.sources   | 7 ---
>  lib/igt.h  | 2 ++
>  lib/igt_chamelium.h| 3 +++
>  tests/Makefile.am  | 6 ++
>  tests/Makefile.sources | 6 --
>  6 files changed, 18 insertions(+), 13 deletions(-)
> 
> diff --git a/lib/Makefile.am b/lib/Makefile.am
> index c0ddf29..91e72c4 100644
> --- a/lib/Makefile.am
> +++ b/lib/Makefile.am
> @@ -22,6 +22,13 @@ if !HAVE_LIBDRM_INTEL
>  stubs/drm/intel_bufmgr.h
>  endif
>  
> +if HAVE_CHAMELIUM
> +lib_source_list +=   \
> + igt_chamelium.h \
> + igt_chamelium.c \
> + $(NULL)
> +endif
> +

Try this:

if HAVE_CHAMELIUM
lib_source_list += $(chamelium_lib_source_list)
endif


>  AM_CPPFLAGS = -I$(top_srcdir)
>  AM_CFLAGS = \
>   $(CWARNFLAGS) \
> diff --git a/lib/Makefile.sources b/lib/Makefile.sources
> index 6348487..53fdb54 100644
> --- a/lib/Makefile.sources
> +++ b/lib/Makefile.sources
> @@ -85,13 +85,6 @@ lib_source_list =  \
>   igt_kmod.h  \
>   $(NULL)
>  
> -if HAVE_CHAMELIUM
> -lib_source_list +=   \
> - igt_chamelium.h \
> - igt_chamelium.c \
> - $(NULL)
> -endif

Try this:

chamelium_lib_source_list +=\
igt_chamelium.h \
igt_chamelium.c \
$(NULL)

> -
>  .PHONY: version.h.tmp
>  
>  # leaving a space here to work around automake's conditionals
> diff --git a/lib/igt.h b/lib/igt.h
> index a97923e..a069deb 100644
> --- a/lib/igt.h
> +++ b/lib/igt.h
> @@ -38,7 +38,9 @@
>  #include "igt_kms.h"
>  #include "igt_pm.h"
>  #include "igt_stats.h"
> +#ifdef HAVE_CHAMELIUM
>  #include "igt_chamelium.h"
> +#endif
>  #include "instdone.h"
>  #include "intel_batchbuffer.h"
>  #include "intel_chipset.h"
> diff --git a/lib/igt_chamelium.h b/lib/igt_chamelium.h
> index f421d83..15f6024 100644
> --- a/lib/igt_chamelium.h
> +++ b/lib/igt_chamelium.h
> @@ -26,7 +26,10 @@
>  #ifndef IGT_CHAMELIUM_H
>  #define IGT_CHAMELIUM_H
>  
> +#ifdef HAVE_CONFIG_H
>  #include "config.h"
> +#endif
> +
>  #include "igt.h"
>  #include 
>  
> diff --git a/tests/Makefile.am b/tests/Makefile.am
> index 05681d5..61c7a15 100644
> --- a/tests/Makefile.am
> +++ b/tests/Makefile.am
> @@ -12,6 +12,12 @@ if HAVE_LIBDRM_VC4
>  TESTS_progs_M += $(VC4_TESTS_M)
>  endif
>  
> +if HAVE_CHAMELIUM
> +TESTS_progs_M += \
> + chamelium \
> + $(NULL)
> +endif
> +
>  if BUILD_TESTS
>  test-list.txt: Makefile.sources
>   @echo TESTLIST > $@
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 9553e4d..df1fee5 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -154,12 +154,6 @@ TESTS_progs_M = \
>   meta_test \
>   $(NULL)
>  
> -if HAVE_CHAMELIUM
> -TESTS_progs_M += \
> - chamelium \
> - $(NULL)
> -endif
> -

Maybe instead of removing this from .sources, try this:

CHAMELIUM_TESTS_progs_M += \
chamelium \
$(NULL)

and then use it in .am under HAVE_CHAMELIUM 

Michal

>  TESTS_progs_XM = \
>  gem_concurrent_all \
>  $(NULL)
> -- 
> 2.9.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 07/13] tests/Android.mk: Add perf to skip list

[Chris Wilson]

On Tue, May 16, 2017 at 03:24:56PM +0200, Arkadiusz Hiler wrote:
> It does not build on Android with top libdrm.

Ah, libdrm strikes back. I was thinking that Android is definitely a
target for the kernel interface so wondered how much work it will be to
fix.
-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 04/13] lib/igt_aux: Make procps optional

[Chris Wilson]

On Tue, May 16, 2017 at 03:24:53PM +0200, Arkadiusz Hiler wrote:
> Android does not have procps and it's not easy to compile it as a
> dependency.
> 
> We can provide alternative, "naive" implementation that just shells out
> to external commands (i.e. pkill and lsof) in case we do not have the
> library.

This patch should carry a health warning: do not mix with kasan. :-p
-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 13/13] tests/gem_exec_nop: Rename signal() to fence_signal()

[Chris Wilson]

On Tue, May 16, 2017 at 03:25:02PM +0200, Arkadiusz Hiler wrote:
> Unfortunately  is included through some obscure dependencies
> when using bionic, so we have a name clash on signal().
> 
> Changed the test function name to fence_signal() to avoid this, but left
> the test cases names unchanged.

Ack.
-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 i-g-t 07/13] tests/Android.mk: Add perf to skip list

[Arkadiusz Hiler]

It does not build on Android with top libdrm.

Temporary hax.

Signed-off-by: Arkadiusz Hiler 
---
 tests/Android.mk | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/Android.mk b/tests/Android.mk
index 3186a2a..c67ddbd 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -59,6 +59,7 @@ else
 pm_lpsp \
drm_read \
gem_exec_blt \
+   perf \
prime_mmap_kms
 
 # All kms tests depend on cairo
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 12/13] tests/gem_exec_nop: Disable headless subtest on cairoless Android

[Arkadiusz Hiler]

Currently whole igt_kms.c is disabled while compiling on Android without
cairo, so this tests does not compile.

There should be cleaner a way to disable only cairo dependant parts
which should allow us to enable at least some of the KMS tests, but
that's a bigger rework for another time.

v2: simplified #ifs on CAIRO/ANDROID (P. Latvala)

Cc: Petri Latvala 
Signed-off-by: Arkadiusz Hiler 
---
 tests/gem_exec_nop.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index 440e357..d96f068 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -139,6 +139,7 @@ stable_nop_on_ring(int fd, uint32_t handle, unsigned int 
engine,
return n;
 }
 
+#if !defined(ANDROID) || ANDROID_HAS_CAIRO
 #define assert_within_epsilon(x, ref, tolerance) \
 igt_assert_f((x) <= (1.0 + tolerance) * ref && \
  (x) >= (1.0 - tolerance) * ref, \
@@ -183,6 +184,7 @@ static void headless(int fd, uint32_t handle)
/* check that the two execution speeds are roughly the same */
assert_within_epsilon(n_headless, n_display, 0.1f);
 }
+#endif
 
 static bool ignore_engine(int fd, unsigned engine)
 {
@@ -681,8 +683,10 @@ igt_main
igt_subtest("context-sequential")
sequential(device, handle, FORKED | CONTEXT, 150);
 
+#if !defined(ANDROID) || ANDROID_HAS_CAIRO
igt_subtest("headless")
headless(device, handle);
+#endif
 
igt_fixture {
igt_stop_hang_detector();
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 13/13] tests/gem_exec_nop: Rename signal() to fence_signal()

[Arkadiusz Hiler]

Unfortunately  is included through some obscure dependencies
when using bionic, so we have a name clash on signal().

Changed the test function name to fence_signal() to avoid this, but left
the test cases names unchanged.

Signed-off-by: Arkadiusz Hiler 
---
 tests/gem_exec_nop.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/tests/gem_exec_nop.c b/tests/gem_exec_nop.c
index d96f068..d61e120 100644
--- a/tests/gem_exec_nop.c
+++ b/tests/gem_exec_nop.c
@@ -517,9 +517,9 @@ static bool fence_wait(int fence)
return poll(&(struct pollfd){fence, POLLIN}, 1, -1) == 1;
 }
 
-static void signal(int fd, uint32_t handle,
-  unsigned ring_id, const char *ring_name,
-  int timeout)
+static void fence_signal(int fd, uint32_t handle,
+unsigned ring_id, const char *ring_name,
+int timeout)
 {
 #define NFENCES 512
struct drm_i915_gem_execbuffer2 execbuf;
@@ -659,11 +659,11 @@ igt_main
igt_subtest_f("%s", e->name)
single(device, handle, e->exec_id | e->flags, e->name);
igt_subtest_f("signal-%s", e->name)
-   signal(device, handle, e->exec_id | e->flags, e->name, 
5);
+   fence_signal(device, handle, e->exec_id | e->flags, 
e->name, 5);
}
 
igt_subtest("signal-all")
-   signal(device, handle, -1, "all", 150);
+   fence_signal(device, handle, -1, "all", 150);
 
igt_subtest("series")
series(device, handle, 150);
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 11/13] tools/Android.mk: Fix zlib inclusion

[Arkadiusz Hiler]

Add dependency on libz instead of doing path magic.

Signed-off-by: Arkadiusz Hiler 
---
 tools/Android.mk | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/Android.mk b/tools/Android.mk
index 5653572..96075c9 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -29,9 +29,8 @@ define add_tool
 LOCAL_LDFLAGS += $($(1)_LDFLAGS)
 endif
 
-LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-LOCAL_C_INCLUDES += $(LOCAL_PATH)/../lib/stubs/drm/
-LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/zlib
+LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 LOCAL_MODULE := $1_tool
 LOCAL_MODULE_TAGS := optional
@@ -41,7 +40,8 @@ define add_tool
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
   libkmod   \
   libdrm\
-  libdrm_intel
+  libdrm_intel \
+  libz
 
 # Tools dir on host
 LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/$(LOCAL_TOOLS_DIR)
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 10/13] Android.mk: Use drm stubs

[Arkadiusz Hiler]

Use drm stubs that sit under lib/stubs.

Also drop strange, nonexistent additions to LOCAL_C_INCLUDES.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 3 ++-
 demos/Android.mk  | 3 ++-
 lib/Android.mk| 4 ++--
 lib/tests/Android.mk  | 4 ++--
 tests/Android.mk  | 4 ++--
 tools/Android.mk  | 2 +-
 6 files changed, 11 insertions(+), 9 deletions(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index faa73b7..4ea275c 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -10,7 +10,8 @@ define add_benchmark
 
 LOCAL_SRC_FILES := $1.c
 
-LOCAL_C_INCLUDES = ${IGT_LOCAL_C_INCLUDES}
+LOCAL_C_INCLUDES = ${IGT_LOCAL_C_INCLUDES} \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 LOCAL_CFLAGS += -DHAVE_STRUCT_SYSINFO_TOTALRAM
 LOCAL_CFLAGS += -DANDROID -UNDEBUG -include "check-ndebug.h"
 LOCAL_CFLAGS += -std=gnu99
diff --git a/demos/Android.mk b/demos/Android.mk
index 90d8b37..1f50fdc 100644
--- a/demos/Android.mk
+++ b/demos/Android.mk
@@ -16,7 +16,8 @@ LOCAL_CFLAGS += -std=gnu99
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
 
-LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
+LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 LOCAL_MODULE := intel_sprite_on
 
diff --git a/lib/Android.mk b/lib/Android.mk
index 003ade5..31f88be 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -17,8 +17,8 @@ LOCAL_GENERATED_SOURCES :=   \
$(IGT_LIB_PATH)/version.h  \
$(GPU_TOOLS_PATH)/config.h
 
-LOCAL_C_INCLUDES +=  \
-   $(LOCAL_PATH)/..
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/.. \
+$(LOCAL_PATH)/stubs/drm/
 
 LOCAL_EXPORT_C_INCLUDE_DIRS := $(LOCAL_PATH)
 
diff --git a/lib/tests/Android.mk b/lib/tests/Android.mk
index 026f17f..bbbd4d8 100644
--- a/lib/tests/Android.mk
+++ b/lib/tests/Android.mk
@@ -30,8 +30,8 @@ IGT_LOCAL_CFLAGS += -std=gnu99
 IGT_LOCAL_CFLAGS += -Wno-error=return-type
 
 # set local includes
-IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-IGT_LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
diff --git a/tests/Android.mk b/tests/Android.mk
index b664dff..c6e966f 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -40,8 +40,8 @@ IGT_LOCAL_CFLAGS += -Wno-error=return-type
 IGT_LOCAL_CFLAGS += -Wno-sign-compare
 
 # set local includes
-IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-IGT_LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+IGT_LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib \
+   $(LOCAL_PATH)/../lib/stubs/drm/
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
diff --git a/tools/Android.mk b/tools/Android.mk
index 0bad29c..5653572 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -30,7 +30,7 @@ define add_tool
 endif
 
 LOCAL_C_INCLUDES = $(LOCAL_PATH)/../lib
-LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
+LOCAL_C_INCLUDES += $(LOCAL_PATH)/../lib/stubs/drm/
 LOCAL_C_INCLUDES += ${ANDROID_BUILD_TOP}/external/zlib
 
 LOCAL_MODULE := $1_tool
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 03/13] lib/igt_aux: Include unistd.h for gettid() on Android

[Arkadiusz Hiler]

We define gettid() using syscall() because glibc does not provide a
wrapper.

Android's bionic got the syscall covered though.

Signed-off-by: Arkadiusz Hiler 
---
 lib/igt_aux.h | 5 +
 1 file changed, 5 insertions(+)

diff --git a/lib/igt_aux.h b/lib/igt_aux.h
index e62858e..54b9716 100644
--- a/lib/igt_aux.h
+++ b/lib/igt_aux.h
@@ -43,7 +43,12 @@ extern int num_trash_bos;
 #define NSEC_PER_SEC (1000*USEC_PER_SEC)
 
 /* signal interrupt helpers */
+#ifdef ANDROID
+#include  /* on Android bionic has this implemented */
+#else
 #define gettid() syscall(__NR_gettid)
+#endif
+
 #define sigev_notify_thread_id _sigev_un._tid
 
 /* auxialiary igt helpers from igt_aux.c */
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 09/13] Android.mk: Filter out *.h from src files

[Arkadiusz Hiler]

Newer Android's build system complains about unused files if we leave
those there.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Android.mk   | 2 +-
 tools/Android.mk | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/lib/Android.mk b/lib/Android.mk
index 0596e4a..003ade5 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -45,7 +45,7 @@ skip_lib_list := \
 -DANDROID_HAS_CAIRO=0
 endif
 
-LOCAL_SRC_FILES := $(filter-out $(skip_lib_list),$(lib_source_list))
+LOCAL_SRC_FILES := $(filter-out %.h $(skip_lib_list),$(lib_source_list))
 
 include $(BUILD_STATIC_LIBRARY)
 
diff --git a/tools/Android.mk b/tools/Android.mk
index a8e649b..0bad29c 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -12,7 +12,7 @@ define add_tool
 ifeq ($($(1)_SOURCES),)
 LOCAL_SRC_FILES := $1.c
 else
-LOCAL_SRC_FILES := $($(1)_SOURCES)
+LOCAL_SRC_FILES := $(filter-out %.h,$($(1)_SOURCES))
 endif
 
 LOCAL_CFLAGS += -DHAVE_TERMIOS_H
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 08/13] Android.mk: Fix libkmod use

[Arkadiusz Hiler]

On Android libkmod.h is nested under libkmod directory, so we should
include appropriately.

Also we need to link with it.

Signed-off-by: Arkadiusz Hiler 
---
 benchmarks/Android.mk | 2 ++
 lib/Android.mk| 1 +
 lib/igt_kmod.h| 4 
 tests/Android.mk  | 4 ++--
 tools/Android.mk  | 2 ++
 5 files changed, 11 insertions(+), 2 deletions(-)

diff --git a/benchmarks/Android.mk b/benchmarks/Android.mk
index c0fa09f..faa73b7 100644
--- a/benchmarks/Android.mk
+++ b/benchmarks/Android.mk
@@ -18,6 +18,7 @@ define add_benchmark
 LOCAL_CFLAGS += -Wno-error=return-type
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
+LOCAL_LDFLAGS += -lkmod
 
 LOCAL_MODULE := $1_benchmark
 LOCAL_MODULE_TAGS := optional
@@ -26,6 +27,7 @@ define add_benchmark
 LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+  libkmod   \
   libdrm\
   libdrm_intel
 
diff --git a/lib/Android.mk b/lib/Android.mk
index eb72f84..0596e4a 100644
--- a/lib/Android.mk
+++ b/lib/Android.mk
@@ -29,6 +29,7 @@ LOCAL_CFLAGS += -std=gnu99 -UNDEBUG
 LOCAL_MODULE:= libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+ libkmod   \
  libdrm\
  libdrm_intel
 
diff --git a/lib/igt_kmod.h b/lib/igt_kmod.h
index fd307a4..6a7584f 100644
--- a/lib/igt_kmod.h
+++ b/lib/igt_kmod.h
@@ -24,7 +24,11 @@
 #ifndef IGT_KMOD_H
 #define IGT_KMOD_H
 
+#ifdef ANDROID
+#include 
+#else
 #include 
+#endif
 
 #include "igt_aux.h"
 
diff --git a/tests/Android.mk b/tests/Android.mk
index c67ddbd..b664dff 100644
--- a/tests/Android.mk
+++ b/tests/Android.mk
@@ -19,7 +19,7 @@ define add_test
 
 LOCAL_MODULE_TAGS := optional
 # ask linker to define a specific symbol; we use this to identify IGT tests
-LOCAL_LDFLAGS := -Wl,--defsym=$2=0
+LOCAL_LDFLAGS := -Wl,--defsym=$2=0 -lkmod
 LOCAL_MODULE_PATH := $(TARGET_OUT_VENDOR)/intel/validation/core/igt
 
 include $(BUILD_EXECUTABLE)
@@ -45,7 +45,7 @@ IGT_LOCAL_C_INCLUDES += 
${ANDROID_BUILD_TOP}/external/PRIVATE/drm/include/drm
 
 # set local libraries
 IGT_LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
-IGT_LOCAL_SHARED_LIBRARIES := libpciaccess libdrm libdrm_intel
+IGT_LOCAL_SHARED_LIBRARIES := libpciaccess libkmod libdrm libdrm_intel
 
 # handle cairo requirements if it is enabled
 ifeq ("${ANDROID_HAS_CAIRO}", "1")
diff --git a/tools/Android.mk b/tools/Android.mk
index 0602e8c..a8e649b 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -23,6 +23,7 @@ define add_tool
 LOCAL_CFLAGS += -Wno-error=return-type
 # Excessive complaining for established cases. Rely on the Linux version 
warnings.
 LOCAL_CFLAGS += -Wno-sign-compare
+LOCAL_LDFLAGS += -lkmod
 ifeq ($($(1)_LDFLAGS),)
 else
 LOCAL_LDFLAGS += $($(1)_LDFLAGS)
@@ -38,6 +39,7 @@ define add_tool
 LOCAL_STATIC_LIBRARIES := libintel_gpu_tools
 
 LOCAL_SHARED_LIBRARIES := libpciaccess  \
+  libkmod   \
   libdrm\
   libdrm_intel
 
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 06/13] tools/Android.mk: Add guc_logger and l3_parity skip list

[Arkadiusz Hiler]

Those tools does not build on Android due to "Linux-only" dependencies.

Let's blacklist them for now.

Signed-off-by: Arkadiusz Hiler 
---
 tools/Android.mk | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/tools/Android.mk b/tools/Android.mk
index 6cdedeb..0602e8c 100644
--- a/tools/Android.mk
+++ b/tools/Android.mk
@@ -59,6 +59,8 @@ bin_PROGRAMS := $(tools_prog_lists)
 
 skip_tools_list := \
 intel_framebuffer_dump \
+intel_guc_logger \
+intel_l3_parity \
 intel_reg_dumper \
 intel_vga_read \
 intel_vga_write
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 05/13] chamelium: Fix build issues on Android

[Arkadiusz Hiler]

Makefile.sources are included 1:1 in Android.mk files, and are not
parsed by automake. And yet those had some automake conditional logic.
Moving it to .am file is enough for now.

Also igt_chamelium.h included config.h without proper "HAVE_CONFIG_H"
guard, and the file itself was included unconditionally.

Signed-off-by: Arkadiusz Hiler 
---
 lib/Makefile.am| 7 +++
 lib/Makefile.sources   | 7 ---
 lib/igt.h  | 2 ++
 lib/igt_chamelium.h| 3 +++
 tests/Makefile.am  | 6 ++
 tests/Makefile.sources | 6 --
 6 files changed, 18 insertions(+), 13 deletions(-)

diff --git a/lib/Makefile.am b/lib/Makefile.am
index c0ddf29..91e72c4 100644
--- a/lib/Makefile.am
+++ b/lib/Makefile.am
@@ -22,6 +22,13 @@ if !HAVE_LIBDRM_INTEL
 stubs/drm/intel_bufmgr.h
 endif
 
+if HAVE_CHAMELIUM
+lib_source_list += \
+   igt_chamelium.h \
+   igt_chamelium.c \
+   $(NULL)
+endif
+
 AM_CPPFLAGS = -I$(top_srcdir)
 AM_CFLAGS = \
$(CWARNFLAGS) \
diff --git a/lib/Makefile.sources b/lib/Makefile.sources
index 6348487..53fdb54 100644
--- a/lib/Makefile.sources
+++ b/lib/Makefile.sources
@@ -85,13 +85,6 @@ lib_source_list =\
igt_kmod.h  \
$(NULL)
 
-if HAVE_CHAMELIUM
-lib_source_list += \
-   igt_chamelium.h \
-   igt_chamelium.c \
-   $(NULL)
-endif
-
 .PHONY: version.h.tmp
 
 # leaving a space here to work around automake's conditionals
diff --git a/lib/igt.h b/lib/igt.h
index a97923e..a069deb 100644
--- a/lib/igt.h
+++ b/lib/igt.h
@@ -38,7 +38,9 @@
 #include "igt_kms.h"
 #include "igt_pm.h"
 #include "igt_stats.h"
+#ifdef HAVE_CHAMELIUM
 #include "igt_chamelium.h"
+#endif
 #include "instdone.h"
 #include "intel_batchbuffer.h"
 #include "intel_chipset.h"
diff --git a/lib/igt_chamelium.h b/lib/igt_chamelium.h
index f421d83..15f6024 100644
--- a/lib/igt_chamelium.h
+++ b/lib/igt_chamelium.h
@@ -26,7 +26,10 @@
 #ifndef IGT_CHAMELIUM_H
 #define IGT_CHAMELIUM_H
 
+#ifdef HAVE_CONFIG_H
 #include "config.h"
+#endif
+
 #include "igt.h"
 #include 
 
diff --git a/tests/Makefile.am b/tests/Makefile.am
index 05681d5..61c7a15 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -12,6 +12,12 @@ if HAVE_LIBDRM_VC4
 TESTS_progs_M += $(VC4_TESTS_M)
 endif
 
+if HAVE_CHAMELIUM
+TESTS_progs_M += \
+   chamelium \
+   $(NULL)
+endif
+
 if BUILD_TESTS
 test-list.txt: Makefile.sources
@echo TESTLIST > $@
diff --git a/tests/Makefile.sources b/tests/Makefile.sources
index 9553e4d..df1fee5 100644
--- a/tests/Makefile.sources
+++ b/tests/Makefile.sources
@@ -154,12 +154,6 @@ TESTS_progs_M = \
meta_test \
$(NULL)
 
-if HAVE_CHAMELIUM
-TESTS_progs_M += \
-   chamelium \
-   $(NULL)
-endif
-
 TESTS_progs_XM = \
 gem_concurrent_all \
 $(NULL)
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t v2 00/13] Fix IGTs for Android

[Arkadiusz Hiler]

IGTs are broken for Android since the introduction of dependency on procps. Over
time other incompatibilities built up.

I took the liberty to fix some of the issues, workaround couple of others and
blacklist heavily incompatible tools/tests.

It builds on (almost) vanilla AOSP now.

Github: 
Howto:  
now including docker exmaple / script for your convenience

DEP1:  - just builds Google's one
DEP2: 

We should include a note on Android compatibility in the README and do
"continuous compilation" of the patches as they arrive on the mailing list,
otherwise this **will get broken again soon**.

This is long as it is, but not complete yet.

Here are some of more obvious TODOs:
 * introduce something like IGT_HAS_CAIRO define for convenience
 * revise igt_kms dependency on cairo and enable everything what is independent
 * revise kms tests and do the above
 * review all things that are disabled on Android and try to enable them
 * do something less ugly with config.h generation on Android

v2: couple of suggested fixed + everything that was not compatible since last
patch

Cc: Petri Latvala 
Cc: Antonio Argenziano 
Cc: Vinay Belgaumkar 
Cc: Chris Wilson 
Cc: Robert Foss 


Arkadiusz Hiler (13):
  tests/drm_import_export: Include {i915_,}drm.h properly
  Make conditions on HAVE_UDEV consistent
  lib/igt_aux: Include unistd.h for gettid() on Android
  lib/igt_aux: Make procps optional
  chamelium: Fix build issues on Android
  tools/Android.mk: Add guc_logger and l3_parity skip list
  tests/Android.mk: Add perf to skip list
  Android.mk: Fix libkmod use
  Android.mk: Filter out *.h from src files
  Android.mk: Use drm stubs
  tools/Android.mk: Fix zlib inclusion
  tests/gem_exec_nop: Disable headless subtest on cairoless Android
  tests/gem_exec_nop: Rename signal() to fence_signal()

 benchmarks/Android.mk  |  5 -
 configure.ac   |  6 +-
 demos/Android.mk   |  3 ++-
 lib/Android.mk |  7 ---
 lib/Makefile.am|  7 +++
 lib/Makefile.sources   |  7 ---
 lib/igt.h  |  2 ++
 lib/igt_aux.c  | 37 +
 lib/igt_aux.h  |  5 +
 lib/igt_chamelium.h|  3 +++
 lib/igt_kmod.h |  4 
 lib/tests/Android.mk   |  4 ++--
 tests/Android.mk   |  9 +
 tests/Makefile.am  |  6 ++
 tests/Makefile.sources |  6 --
 tests/drm_import_export.c  |  4 ++--
 tests/gem_exec_nop.c   | 14 +-
 tests/testdisplay_hotplug.c|  2 +-
 tools/Android.mk   | 14 +-
 tools/intel_l3_parity.c|  2 +-
 tools/intel_l3_parity.h|  2 +-
 tools/intel_l3_udev_listener.c |  2 +-
 22 files changed, 106 insertions(+), 45 deletions(-)

-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 04/13] lib/igt_aux: Make procps optional

[Arkadiusz Hiler]

Android does not have procps and it's not easy to compile it as a
dependency.

We can provide alternative, "naive" implementation that just shells out
to external commands (i.e. pkill and lsof) in case we do not have the
library.

v2: have separate functions for naive impls (J. Nikula)

Cc: Jani Nikula 
Signed-off-by: Arkadiusz Hiler 
---
 configure.ac  |  6 +-
 lib/igt_aux.c | 35 ---
 2 files changed, 37 insertions(+), 4 deletions(-)

diff --git a/configure.ac b/configure.ac
index 5342e33..72cb32f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -123,7 +123,11 @@ AC_SUBST(ASSEMBLER_WARN_CFLAGS)
 PKG_CHECK_MODULES(DRM, [libdrm])
 PKG_CHECK_MODULES(PCIACCESS, [pciaccess >= 0.10])
 PKG_CHECK_MODULES(KMOD, [libkmod])
-PKG_CHECK_MODULES(PROCPS, [libprocps])
+PKG_CHECK_MODULES(PROCPS, [libprocps], [procps=yes], [procps=no])
+AM_CONDITIONAL(HAVE_PROCPS, [test "x$procps" = xyes])
+if test x"$procps" = xyes; then
+   AC_DEFINE(HAVE_PROCPS,1,[Enable process managment without shelling out])
+fi
 PKG_CHECK_MODULES(VALGRIND, [valgrind], [have_valgrind=yes], 
[have_valgrind=no])
 
 if test x$have_valgrind = xyes; then
diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 2ec6b78..f76e55d 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -50,9 +50,7 @@
 #include 
 #include 
 #include 
-
-#include 
-
+#include 
 #include "drmtest.h"
 #include "i915_drm.h"
 #include "intel_chipset.h"
@@ -71,6 +69,10 @@
 #include/* for dirname() */
 #endif
 
+#ifdef HAVE_PROCPS
+#include 
+#endif
+
 /**
  * SECTION:igt_aux
  * @short_description: Auxiliary libraries and support functions
@@ -1293,6 +1295,7 @@ void igt_set_module_param_int(const char *name, int val)
  * This function sends the signal @sig for a process found in process table
  * with name @comm.
  */
+#ifdef HAVE_PROCPS
 int igt_terminate_process(int sig, const char *comm)
 {
PROCTAB *proc;
@@ -1317,7 +1320,19 @@ int igt_terminate_process(int sig, const char *comm)
closeproc(proc);
return err;
 }
+#else
+#warning "No procps, using naive implementation of igt_terminate_process"
 
+int igt_terminate_process(int sig, const char *comm)
+{
+   char pkill_cmd[NAME_MAX];
+
+   snprintf(pkill_cmd, sizeof(pkill_cmd), "pkill -x -%d %s", sig, comm);
+   return system(pkill_cmd);
+}
+#endif
+
+#ifdef HAVE_PROCPS
 struct pinfo {
pid_t pid;
const char *comm;
@@ -1499,6 +1514,7 @@ __igt_lsof(const char *dir)
 
closeproc(proc);
 }
+#endif
 
 /**
  * igt_lsof: Lists information about files opened by processes.
@@ -1507,6 +1523,7 @@ __igt_lsof(const char *dir)
  * This function mimics (a restrictive form of) lsof(8), but also shows
  * information about opened fds.
  */
+#ifdef HAVE_PROCPS
 void
 igt_lsof(const char *dpath)
 {
@@ -1531,6 +1548,18 @@ igt_lsof(const char *dpath)
 
free(sanitized);
 }
+#else
+#warning "No procps, using naive implementation of igt_lsof"
+
+void
+igt_lsof(const char *dpath)
+{
+   char lsof_cmd[NAME_MAX];
+
+   snprintf(lsof_cmd, sizeof(lsof_cmd), "lsof +d %s", dpath);
+   system(lsof_cmd);
+}
+#endif
 
 static struct igt_siglatency {
timer_t timer;
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 02/13] Make conditions on HAVE_UDEV consistent

[Arkadiusz Hiler]

We have a lot of `#ifdef HAVE_UDEV` and ` #if HAVE_UDEV` all over the
place, but ifdef and if have a slightly different semantics.

Let make it consistent by using #ifdefs only.

Signed-off-by: Arkadiusz Hiler 
---
 lib/igt_aux.c  | 2 +-
 tests/testdisplay_hotplug.c| 2 +-
 tools/intel_l3_parity.c| 2 +-
 tools/intel_l3_parity.h| 2 +-
 tools/intel_l3_udev_listener.c | 2 +-
 5 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/lib/igt_aux.c b/lib/igt_aux.c
index 1222806..2ec6b78 100644
--- a/lib/igt_aux.c
+++ b/lib/igt_aux.c
@@ -388,7 +388,7 @@ void igt_stop_shrink_helper(void)
igt_stop_helper(&shrink_helper);
 }
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 
 static struct igt_helper_process hang_detector;
diff --git a/tests/testdisplay_hotplug.c b/tests/testdisplay_hotplug.c
index 3b900ca..cf15511 100644
--- a/tests/testdisplay_hotplug.c
+++ b/tests/testdisplay_hotplug.c
@@ -34,7 +34,7 @@
 #endif
 
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 static struct udev_monitor *uevent_monitor;
 static struct udev *udev;
diff --git a/tools/intel_l3_parity.c b/tools/intel_l3_parity.c
index dce7f32..eb00c50 100644
--- a/tools/intel_l3_parity.c
+++ b/tools/intel_l3_parity.c
@@ -42,7 +42,7 @@
 #ifdef HAVE_CONFIG_H
 #include "config.h"
 #endif
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 #include 
 #endif
diff --git a/tools/intel_l3_parity.h b/tools/intel_l3_parity.h
index 65697c4..759c4f4 100644
--- a/tools/intel_l3_parity.h
+++ b/tools/intel_l3_parity.h
@@ -18,7 +18,7 @@ struct l3_location {
uint8_t subbank;
 };
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 int l3_uevent_setup(struct l3_parity *par);
 /* Listens (blocks) for an l3 parity event. Returns the location of the error. 
*/
 int l3_listen(struct l3_parity *par, bool daemon, struct l3_location *loc);
diff --git a/tools/intel_l3_udev_listener.c b/tools/intel_l3_udev_listener.c
index 0b94c1c..270bfff 100644
--- a/tools/intel_l3_udev_listener.c
+++ b/tools/intel_l3_udev_listener.c
@@ -25,7 +25,7 @@
 #include "config.h"
 #endif
 
-#if HAVE_UDEV
+#ifdef HAVE_UDEV
 #include 
 #ifndef _GNU_SOURCE
 #define _GNU_SOURCE
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH i-g-t 01/13] tests/drm_import_export: Include {i915_, }drm.h properly

[Arkadiusz Hiler]

Using `libdrm/` impairs compatibility with android build system and
pkg-config manages -I for us on regular distros.

Signed-off-by: Arkadiusz Hiler 
---
 tests/drm_import_export.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/drm_import_export.c b/tests/drm_import_export.c
index cfe5f6d..f1234bd 100644
--- a/tests/drm_import_export.c
+++ b/tests/drm_import_export.c
@@ -32,8 +32,8 @@
 #include 
 #include 
 #include 
-#include 
-#include 
+#include 
+#include 
 #include 
 #include 
 #include 
-- 
2.9.3

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Try harder to reset the GPU

[Chris Wilson]

Repeat the reset a couple of times if at first we do not succeed.

Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/20170513083726.502-1-ch...@chris-wilson.co.uk
---
 drivers/gpu/drm/i915/intel_uncore.c | 44 +
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 71b9b387ad04..fc3da0a6fdbb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1463,9 +1463,10 @@ int i915_reg_read_ioctl(struct drm_device *dev,
return ret;
 }
 
-static int i915_reset_complete(struct pci_dev *pdev)
+static bool i915_reset_complete(struct pci_dev *pdev)
 {
u8 gdrst;
+
pci_read_config_byte(pdev, I915_GDRST, &gdrst);
return (gdrst & GRDOM_RESET_STATUS) == 0;
 }
@@ -1476,15 +1477,16 @@ static int i915_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask
 
/* assert reset for at least 20 usec */
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
-   udelay(20);
+   usleep_range(50, 200);
pci_write_config_byte(pdev, I915_GDRST, 0);
 
return wait_for(i915_reset_complete(pdev), 500);
 }
 
-static int g4x_reset_complete(struct pci_dev *pdev)
+static bool g4x_reset_complete(struct pci_dev *pdev)
 {
u8 gdrst;
+
pci_read_config_byte(pdev, I915_GDRST, &gdrst);
return (gdrst & GRDOM_RESET_ENABLE) == 0;
 }
@@ -1492,6 +1494,7 @@ static int g4x_reset_complete(struct pci_dev *pdev)
 static int g33_do_reset(struct drm_i915_private *dev_priv, unsigned 
engine_mask)
 {
struct pci_dev *pdev = dev_priv->drm.pdev;
+
pci_write_config_byte(pdev, I915_GDRST, GRDOM_RESET_ENABLE);
return wait_for(g4x_reset_complete(pdev), 500);
 }
@@ -1505,7 +1508,7 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
  GRDOM_RENDER | GRDOM_RESET_ENABLE);
ret =  wait_for(g4x_reset_complete(pdev), 500);
if (ret)
-   return ret;
+   goto out;
 
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) | 
VCP_UNIT_CLOCK_GATE_DISABLE);
@@ -1514,16 +1517,14 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
pci_write_config_byte(pdev, I915_GDRST,
  GRDOM_MEDIA | GRDOM_RESET_ENABLE);
ret =  wait_for(g4x_reset_complete(pdev), 500);
-   if (ret)
-   return ret;
 
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) & 
~VCP_UNIT_CLOCK_GATE_DISABLE);
POSTING_READ(VDECCLK_GATE_D);
 
+out:
pci_write_config_byte(pdev, I915_GDRST, 0);
-
-   return 0;
+   return ret;
 }
 
 static int ironlake_do_reset(struct drm_i915_private *dev_priv,
@@ -1531,25 +1532,21 @@ static int ironlake_do_reset(struct drm_i915_private 
*dev_priv,
 {
int ret;
 
-   I915_WRITE(ILK_GDSR,
-  ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
+   I915_WRITE(ILK_GDSR, ILK_GRDOM_RENDER | ILK_GRDOM_RESET_ENABLE);
ret = intel_wait_for_register(dev_priv,
  ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
  500);
if (ret)
-   return ret;
+   goto out;
 
-   I915_WRITE(ILK_GDSR,
-  ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
+   I915_WRITE(ILK_GDSR, ILK_GRDOM_MEDIA | ILK_GRDOM_RESET_ENABLE);
ret = intel_wait_for_register(dev_priv,
  ILK_GDSR, ILK_GRDOM_RESET_ENABLE, 0,
  500);
-   if (ret)
-   return ret;
-
+out:
I915_WRITE(ILK_GDSR, 0);
-
-   return 0;
+   POSTING_READ(ILK_GDSR);
+   return ret;
 }
 
 /* Reset the hardware domains (GENX_GRDOM_*) specified by mask */
@@ -1758,8 +1755,11 @@ static reset_func intel_get_gpu_reset(struct 
drm_i915_private *dev_priv)
 int intel_gpu_reset(struct drm_i915_private *dev_priv, unsigned engine_mask)
 {
reset_func reset;
+   int retry;
int ret;
 
+   might_sleep();
+
reset = intel_get_gpu_reset(dev_priv);
if (reset == NULL)
return -ENODEV;
@@ -1768,7 +1768,13 @@ int intel_gpu_reset(struct drm_i915_private *dev_priv, 
unsigned engine_mask)
 * request may be dropped and never completes (causing -EIO).
 */
intel_uncore_forcewake_get(dev_priv, FORCEWAKE_ALL);
-   ret = reset(dev_priv, engine_mask);
+   for (retry = 0; retry < 3; retry++) {
+   ret = reset(dev_priv, engine_mask);
+   if (ret != -ETIMEDOUT)
+   break;
+
+   cond_resched();
+   }
intel_uncore_forcewake_put(dev_priv, FORCEWAKE_ALL);
 

[Intel-gfx] [PATCH 2/2] drm/i915: Reorder media/render reset on g4x

[Chris Wilson]

Ville found a reference to WaMediaResetBeforeFullReset which we presume
means that we should simply do the media reset first.

References: https://bugs.freedesktop.org/show_bug.cgi?id=100942
Suggested-by: Ville Syrjälä 
Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_uncore.c | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index fc3da0a6fdbb..c3d0d81b50e4 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -1504,12 +1504,6 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
struct pci_dev *pdev = dev_priv->drm.pdev;
int ret;
 
-   pci_write_config_byte(pdev, I915_GDRST,
- GRDOM_RENDER | GRDOM_RESET_ENABLE);
-   ret =  wait_for(g4x_reset_complete(pdev), 500);
-   if (ret)
-   goto out;
-
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) | 
VCP_UNIT_CLOCK_GATE_DISABLE);
POSTING_READ(VDECCLK_GATE_D);
@@ -1517,11 +1511,17 @@ static int g4x_do_reset(struct drm_i915_private 
*dev_priv, unsigned engine_mask)
pci_write_config_byte(pdev, I915_GDRST,
  GRDOM_MEDIA | GRDOM_RESET_ENABLE);
ret =  wait_for(g4x_reset_complete(pdev), 500);
+   if (ret)
+   goto out;
 
/* WaVcpClkGateDisableForMediaReset:ctg,elk */
I915_WRITE(VDECCLK_GATE_D, I915_READ(VDECCLK_GATE_D) & 
~VCP_UNIT_CLOCK_GATE_DISABLE);
POSTING_READ(VDECCLK_GATE_D);
 
+   pci_write_config_byte(pdev, I915_GDRST,
+ GRDOM_RENDER | GRDOM_RESET_ENABLE);
+   ret =  wait_for(g4x_reset_complete(pdev), 500);
+
 out:
pci_write_config_byte(pdev, I915_GDRST, 0);
return ret;
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

[Mahesh Kumar]

Hi,


On Tuesday 16 May 2017 04:08 AM, Matt Roper wrote:

On Mon, May 15, 2017 at 02:04:36PM +0530, Mahesh Kumar wrote:

From: "Kumar, Mahesh" 

This patch implements new DDB allocation algorithm as per HW team
recommendation. This algo takecare of scenario where we allocate less DDB
for the planes with lower relative pixel rate, but they require more DDB
to work.
It also takes care of enabling same watermark level for each
plane in crtc, for efficient power saving.

Changes since v1:
  - Rebase on top of Paulo's patch series

Changes since v2:
  - Fix the for loop condition to enable WM

Changes since v3:
  - Fix crash in cursor i-g-t reported by Maarten
  - Rebase after addressing Paulo's comments
  - Few other ULT fixes
Changes since v4:
  - Rebase on drm-tip
  - Added separate function to enable WM levels
Changes since v5:
  - Fix a crash identified in skl-6770HQ system

Signed-off-by: Mahesh Kumar 
---
  drivers/gpu/drm/i915/intel_pm.c | 253 
  1 file changed, 152 insertions(+), 101 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index d73369c2c2d9..d6b0ae0ef7a2 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4039,13 +4039,41 @@ skl_ddb_calc_min(const struct intel_crtc_state *cstate, 
int num_active,
minimum[PLANE_CURSOR] = skl_cursor_allocation(num_active);
  }
  
+static void

+skl_enable_plane_wm_levels(const struct drm_i915_private *dev_priv,
+  uint16_t plane_ddb,
+  uint16_t max_level,
+  struct skl_plane_wm *wm)
+{
+   int level;
+   /*
+* Now enable all levels in WM structure which can be enabled
+* using current DDB allocation
+*/
+   for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {
+   struct skl_wm_level *level_wm = &wm->wm[level];
+
+   if (level > max_level || level_wm->plane_res_b == 0
+ || level_wm->plane_res_l >= 31
+ || level_wm->plane_res_b >= plane_ddb) {

Is it possible to hit level_wm->plane_res_b >= plane_ddb without hitting
level > max_level given our new logic?
Yes, this is possible for cursor plane, in multi-display scenario we 
allocate fixed 8 blocks to cursor.
In some cases this may not be sufficient to enable all the WM levels 
which can be enabled for other planes.





+   level_wm->plane_en = false;
+   level_wm->plane_res_b = 0;
+   level_wm->plane_res_l = 0;
+   } else {
+   level_wm->plane_en = true;
+   }
+   }
+}
+
  static int
  skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
- struct skl_ddb_allocation *ddb /* out */)
+ struct skl_ddb_allocation *ddb /* out */,
+ struct skl_pipe_wm *pipe_wm)

Not a huge deal, but it's a bit confusing to have the 'out' parameter in
the middle of 'in' parameters.  Maybe move the pipe_wm before the ddb
just to make this a little cleaner?

sure, will fix this.



  {
struct drm_atomic_state *state = cstate->base.state;
struct drm_crtc *crtc = cstate->base.crtc;
struct drm_device *dev = crtc->dev;
+   struct drm_i915_private *dev_priv = to_i915(dev);
struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
enum pipe pipe = intel_crtc->pipe;
struct skl_ddb_entry *alloc = &cstate->wm.skl.ddb;
@@ -4058,6 +4086,8 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
unsigned plane_data_rate[I915_MAX_PLANES] = {};
unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
uint16_t total_min_blocks = 0;
+   uint16_t total_level_ddb;
+   int max_level, level;
  
  	/* Clear the partitioning for disabled planes. */

memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -4096,10 +4126,43 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
return -EINVAL;
}
  
-	alloc_size -= total_min_blocks;

-   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
minimum[PLANE_CURSOR];
+   alloc_size -= minimum[PLANE_CURSOR];
+   ddb->plane[pipe][PLANE_CURSOR].start = alloc->end -
+   minimum[PLANE_CURSOR];
ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
  
+	for (level = ilk_wm_max_level(dev_priv); level >= 0; level--) {

+   total_level_ddb = 0;
+   for_each_plane_id_on_crtc(intel_crtc, plane_id) {
+   /*
+* TODO: We should calculate watermark values for Y/UV
+* plane both in case of NV12 format and use both values
+* for ddb calculation. NV12 is disabled as of now, So
+* using only single/UV plane value here.
+   

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/sync-file: Defer creation of sync_file->name (rev4)

[Patchwork]

== Series Details ==

Series: dma-buf/sync-file: Defer creation of sync_file->name (rev4)
URL   : https://patchwork.freedesktop.org/series/24353/
State : success

== Summary ==

Series 24353v4 dma-buf/sync-file: Defer creation of sync_file->name
https://patchwork.freedesktop.org/api/1.0/series/24353/revisions/4/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215

fdo#17 https://bugs.freedesktop.org/show_bug.cgi?id=17
fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:447s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:582s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:512s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:495s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:493s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:423s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:506s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:467s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:579s
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:582s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:500s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:442s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-snb-2600  total:278  pass:247  dwarn:0   dfail:0   fail:2   skip:29  
time:404s

fb5cb398a048f8e0fd9dab5686caba61961131be drm-tip: 2017y-05m-16d-11h-13m-20s UTC 
integration manifest
d559328 dma-buf/sync-file: Defer creation of sync_file->name

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4709/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 12/12] drm/i915/skl+: consider max supported plane pixel rate while scaling

[Maarten Lankhorst]

Op 15-05-17 om 10:34 schreef Mahesh Kumar:
> From: "Kumar, Mahesh" 
>
> A display resolution is only supported if it meets all the restrictions
> below for Maximum Pipe Pixel Rate.
>
> The display resolution must fit within the maximum pixel rate output
> from the pipe. Make sure that the display pipe is able to feed pixels at
> a rate required to support the desired resolution.
> For each enabled plane on the pipe {
> If plane scaling enabled {
>   Horizontal down scale amount = Maximum[1, plane horizontal size /
>   scaler horizontal window size]
>   Vertical down scale amount = Maximum[1, plane vertical size /
>   scaler vertical window size]
>   Plane down scale amount = Horizontal down scale amount *
>   Vertical down scale amount
>   Plane Ratio = 1 / Plane down scale amount
> }
> Else {
>   Plane Ratio = 1
> }
> If plane source pixel format is 64 bits per pixel {
>   Plane Ratio = Plane Ratio * 8/9
> }
> }
>
> Pipe Ratio = Minimum Plane Ratio of all enabled planes on the pipe
>
> If pipe scaling is enabled {
> Horizontal down scale amount = Maximum[1, pipe horizontal source size /
>   scaler horizontal window size]
> Vertical down scale amount = Maximum[1, pipe vertical source size /
>   scaler vertical window size]
> Note: The progressive fetch - interlace display mode is equivalent to a
>   2.0 vertical down scale
> Pipe down scale amount = Horizontal down scale amount *
>   Vertical down scale amount
> Pipe Ratio = Pipe Ratio / Pipe down scale amount
> }
>
> Pipe maximum pixel rate = CDCLK frequency * Pipe Ratio
>
> Changes since V1:
>  - separate out fixed_16_16 wrapper API definition
> Changes since V2:
>  - Fix buggy crtc !active condition (Maarten)
>  - use intel_wm_plane_visible wrapper as per Maarten's suggestion
> Changes since V3:
>  - Change failure return from ERANGE to EINVAL
> Changes since V3:
>  - Rebase based on previous patch changes
>
> Signed-off-by: Mahesh Kumar 
> ---
>  drivers/gpu/drm/i915/intel_display.c |  3 ++
>  drivers/gpu/drm/i915/intel_drv.h |  2 +
>  drivers/gpu/drm/i915/intel_pm.c  | 87 
> 
>  3 files changed, 92 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index c1cbfcef1f89..2cc1d11d9e6c 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11186,6 +11186,9 @@ static int intel_crtc_atomic_check(struct drm_crtc 
> *crtc,
>   ret = skl_update_scaler_crtc(pipe_config);
>  
>   if (!ret)
> + ret = skl_check_pipe_max_pixel_rate(intel_crtc,
> + pipe_config);
> + if (!ret)
>   ret = intel_atomic_setup_scalers(dev_priv, intel_crtc,
>pipe_config);
>   }
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index bd500977b3fc..93afac4a83fa 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1885,6 +1885,8 @@ bool skl_ddb_allocation_overlaps(const struct 
> skl_ddb_entry **entries,
>int ignore);
>  bool ilk_disable_lp_wm(struct drm_device *dev);
>  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int enable_rc6);
> +int skl_check_pipe_max_pixel_rate(struct intel_crtc *intel_crtc,
> +   struct intel_crtc_state *cstate);
>  static inline int intel_enable_rc6(void)
>  {
>   return i915.enable_rc6;
> diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
> index d6b0ae0ef7a2..5a3d3398ae19 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -3863,6 +3863,93 @@ skl_plane_downscale_amount(const struct 
> intel_crtc_state *cstate,
>   return mul_fixed16(downscale_w, downscale_h);
>  }
>  
> +static uint_fixed_16_16_t
> +skl_pipe_downscale_amount(const struct intel_crtc_state *config)
> +{
> + uint_fixed_16_16_t pipe_downscale = u32_to_fixed_16_16(1);
> +
> + if (!config->base.active)
> + return pipe_downscale;
> +
> + if (config->pch_pfit.enabled) {
> + uint32_t src_w, src_h, dst_w, dst_h;
> + uint32_t pfit_size = config->pch_pfit.size;
> + uint_fixed_16_16_t fp_w_ratio, fp_h_ratio;
> + uint_fixed_16_16_t downscale_h, downscale_w;
> +
> + src_w = config->pipe_src_w;
> + src_h = config->pipe_src_h;
> + dst_w = pfit_size >> 16;
> + dst_h = pfit_size & 0x;
> +
> + if (!dst_w || !dst_h)
> + return pipe_downscale;
> +
> + fp_w_ratio = fixed_16_16_div(src_w, dst_w);
> + fp_h_ratio = 

[Intel-gfx] [PATCH v5] dma-buf/sync-file: Defer creation of sync_file->name

[Chris Wilson]

Constructing the name takes the majority of the time for allocating a
sync_file to wrap a fence, and the name is very rarely used (only via
the sync_file status user interface). To reduce the impact on the common
path (that of creating sync_file to pass around), defer the construction
of the name until it is first used.

v2: Update kerneldoc (kbuild test robot)
v3: sync_debug.c was peeking at the name
v4: Comment upon the potential race between two users of
sync_file_get_name() and claim that such a race is below the level of
notice. However, to prevent any future nuisance, use a global spinlock
to serialize the assignment of the name.
v5: Completely avoid the read/write race by only storing the name passed
in from the user inside sync_file->user_name and passing in a buffer to
dynamically construct the name otherwise.

Signed-off-by: Chris Wilson 
Cc: Sumit Semwal 
Cc: Gustavo Padovan 
Cc: Daniel Vetter 
Cc: David Herrmann 
---
 drivers/dma-buf/sync_debug.c |  4 +++-
 drivers/dma-buf/sync_file.c  | 39 ---
 include/linux/sync_file.h|  5 +++--
 3 files changed, 38 insertions(+), 10 deletions(-)

diff --git a/drivers/dma-buf/sync_debug.c b/drivers/dma-buf/sync_debug.c
index 4b1731ee7458..59a3b2f8ee91 100644
--- a/drivers/dma-buf/sync_debug.c
+++ b/drivers/dma-buf/sync_debug.c
@@ -132,9 +132,11 @@ static void sync_print_obj(struct seq_file *s, struct 
sync_timeline *obj)
 static void sync_print_sync_file(struct seq_file *s,
  struct sync_file *sync_file)
 {
+   char buf[128];
int i;
 
-   seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
+   seq_printf(s, "[%p] %s: %s\n", sync_file,
+  sync_file_get_name(sync_file, buf, sizeof(buf)),
   sync_status_str(dma_fence_get_status(sync_file->fence)));
 
if (dma_fence_is_array(sync_file->fence)) {
diff --git a/drivers/dma-buf/sync_file.c b/drivers/dma-buf/sync_file.c
index c9eb4997cfcc..d7e219d2669d 100644
--- a/drivers/dma-buf/sync_file.c
+++ b/drivers/dma-buf/sync_file.c
@@ -80,11 +80,6 @@ struct sync_file *sync_file_create(struct dma_fence *fence)
 
sync_file->fence = dma_fence_get(fence);
 
-   snprintf(sync_file->name, sizeof(sync_file->name), "%s-%s%llu-%d",
-fence->ops->get_driver_name(fence),
-fence->ops->get_timeline_name(fence), fence->context,
-fence->seqno);
-
return sync_file;
 }
 EXPORT_SYMBOL(sync_file_create);
@@ -129,6 +124,36 @@ struct dma_fence *sync_file_get_fence(int fd)
 }
 EXPORT_SYMBOL(sync_file_get_fence);
 
+/**
+ * sync_file_get_name - get the name of the sync_file
+ * @sync_file: sync_file to get the fence from
+ * @buf:   destination buffer to copy sync_file name into
+ * @len:   available size of destination buffer.
+ *
+ * Each sync_file may have a name assigned either by the user (when merging
+ * sync_files together) or created from the fence it contains. In the latter
+ * case construction of the name is deferred until use, and so requires
+ * sync_file_get_name().
+ *
+ * Returns: a string representing the name.
+ */
+char *sync_file_get_name(struct sync_file *sync_file, char *buf, int len)
+{
+   if (sync_file->user_name[0]) {
+   strlcpy(buf, sync_file->user_name, len);
+   } else {
+   struct dma_fence *fence = sync_file->fence;
+
+   snprintf(buf, len, "%s-%s%llu-%d",
+fence->ops->get_driver_name(fence),
+fence->ops->get_timeline_name(fence),
+fence->context,
+fence->seqno);
+   }
+
+   return buf;
+}
+
 static int sync_file_set_fence(struct sync_file *sync_file,
   struct dma_fence **fences, int num_fences)
 {
@@ -266,7 +291,7 @@ static struct sync_file *sync_file_merge(const char *name, 
struct sync_file *a,
goto err;
}
 
-   strlcpy(sync_file->name, name, sizeof(sync_file->name));
+   strlcpy(sync_file->user_name, name, sizeof(sync_file->user_name));
return sync_file;
 
 err:
@@ -419,7 +444,7 @@ static long sync_file_ioctl_fence_info(struct sync_file 
*sync_file,
}
 
 no_fences:
-   strlcpy(info.name, sync_file->name, sizeof(info.name));
+   sync_file_get_name(sync_file, info.name, sizeof(info.name));
info.status = dma_fence_is_signaled(sync_file->fence);
info.num_fences = num_fences;
 
diff --git a/include/linux/sync_file.h b/include/linux/sync_file.h
index d37beefdfbd5..5226d62ae91b 100644
--- a/include/linux/sync_file.h
+++ b/include/linux/sync_file.h
@@ -23,7 +23,7 @@
 /**
  * struct sync_file - sync file to export to the userspace
  * @file:  file representing this fence
- * @name:  name of sync_file.  Useful for debugging
+ * @user_name: name of sync_file.  Useful for debugging
  * @sync_file_list:membersh

[Intel-gfx] ✓ Fi.CI.BAT: success for Revert "Revert "sched/clock: Fix broken stable to unstable transfer""

[Patchwork]

== Series Details ==

Series: Revert "Revert "sched/clock: Fix broken stable to unstable transfer""
URL   : https://patchwork.freedesktop.org/series/24489/
State : success

== Summary ==

Series 24489v1 Revert "Revert "sched/clock: Fix broken stable to unstable 
transfer""
https://patchwork.freedesktop.org/api/1.0/series/24489/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-snb-2600) fdo#100125

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:457s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:435s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:583s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:515s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:419s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
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:491s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:472s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:570s
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:580s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:466s
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:538s
fi-snb-2600  total:278  pass:248  dwarn:1   dfail:0   fail:0   skip:29  
time:407s

eb4cff1ea4032532931b804ecae4f29b1c9a8e6e drm-tip: 2017y-05m-16d-09h-32m-03s UTC 
integration manifest
c544214 Revert "Revert "sched/clock: Fix broken stable to unstable transfer""

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4708/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 10:07:41AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 12:48 PM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 09:43:52AM +, Lofstedt, Marta wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > Sent: Tuesday, May 16, 2017 12:04 PM
> > > > To: Lofstedt, Marta 
> > > > Cc: Daniel Vetter ; Martin Peres
> > > > ; intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > > test to capture the state of the GPU
> > > >
> > > > On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> > > > >
> > > > >
> > > > > > -Original Message-
> > > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > > > > To: Lofstedt, Marta 
> > > > > > Cc: Daniel Vetter ; Martin Peres
> > > > > > ; intel-gfx@lists.freedesktop.org
> > > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add
> > > > > > a test to capture the state of the GPU
> > > > > >
> > > > > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > > > > I hereby pull-out this patch.
> > > > > > > The idea of it was to know if we were already wedged at the
> > > > > > > beginning of
> > > > > > testing, that would give us information on how to interpret
> > > > > > silly results; such that test starting to get skipped and/or we
> > > > > > got dmesg-warns/incomplete on tests that usually should be skipped.
> > > > > > > Also, we are planning to soon deploy a piglit.conf solution
> > > > > > > where testing
> > > > > > will be terminated on wedged, so I agree that my test isn't really
> > needed.
> > > > > >
> > > > > > Not everything is broken by wedged; internally we just use that
> > > > > > as an indicator that GEM is hosed. KMS should still work, we
> > > > > > must still be able to drive the displays to show the error and
> > > > > > keep the servers alive until the data is saved (and hopefully
> > > > > > gracefully degrade that we don't have to interrupt their immediate
> > session).
> > > > >
> > > > > It doesn't matter if it is broken or not, if we are terminally
> > > > > wedged the rest
> > > > of the result may be silly. Look for example at CI_DRM_2612, the
> > > > fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all
> > > > test are skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where
> > > > the machine hangs, but it is a gem test so it should have been
> > > > skipped, right. My conclusion from seeing this pattern multiple
> > > > times is that after terminally wedged, silly things can happen, i.e.
> > > > we can't trust the results, and since we don't want silly bugs, the CI
> > testing should be stopped.
> > > >
> > > > The machine didn't hang, it was remotely killed because the run timed
> > out.
> > > How do you know that?
> > 
> > The dmesg is a stream of flip timeouts until we run out of total BAT runtime
> > (12 minutes + some startup slack).
> > -Chris
> 
> Then look at CI_DRM_2602, wedged at igt@gem_busy@basic-hang-default, after a 
> lot of skipping, we get incomplete result for another test, this time 
> gem_exec_reloc@basic-gtt-cpu-noreloc
> 
> So, gem_exec_reloc@basic-cpu-gtt-noreloc and 
> gem_exec_reloc@basic-gtt-cpu-noreloc are falsely getting blamed and my 
> conclusion is that this is due to the permanent wedging started at 
> gem_busy@basic-hang-default. So, to avoid bug reports for 
> gem_exec_reloc@basic-cpu-gtt-noreloc and gem_exec_reloc@basic-gtt-cpu- 
> noreloc the suggestion is to stop testing after we are terminally wedged. 

The conclusion is still wrong though, it doesn't derive from the wedged
state itself but from another bug that can be triggered by a recovered
gpu hang. The issue is that post-processing isn't yet smart enough to
determine the real cause and picks on the victim. We are always going to
have that problem in some form, the question is what can be done to make
the process smart to avoid false positives or rather just say this is a
general bug and be careful not to be precise on the blame.
-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] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

[Jani Nikula]

On Tue, 16 May 2017, Ville Syrjälä  wrote:
> mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
>> On Mon, 15 May 2017, Hans de Goede  wrote:
>> > Hi,
>> >
>> > I'm seeing this on suspend/resume on a GPD-win,
>> > cherrytrail z8700 device:
>> 
>> Ville, does
>> 
>> commit 668e3b014afb66ab29e134bca7c258527273ac75
>> Author: Ville Syrjälä 
>> Date:   Thu Apr 27 19:02:20 2017 +0300
>> 
>> drm/i915: Fix runtime PM for LPE audio
>> 
>> in drm-intel-fixes address this?
>
> ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
> interrupts") is a more likely candidate.

Is that applicable to v4.12-rc1?

BR,
Jani.


>
>> 
>> BR,
>> Jani.
>> 
>> 
>> 
>> >
>> > [   75.514651] RPM wakelock ref not held during HW access
>> > [   75.514827] [ cut here ]
>> > [   75.515025] WARNING: CPU: 2 PID: 1832 at 
>> > drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
>> > ...
>> > [   75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
>> > ...
>> > [   75.515767] Call Trace:
>> > [   75.515952]  lpe_audio_irq_unmask+0x6a/0xc0 [i915]
>> > [   75.515972]  irq_enable+0x3a/0x50
>> > [   75.515984]  __enable_irq+0x34/0x60
>> > [   75.515996]  resume_irqs+0x8f/0xd0
>> > [   75.516007]  resume_device_irqs+0x10/0x20
>> > [   75.516021]  dpm_resume_noirq+0x23e/0x310
>> > [   75.516041]  suspend_devices_and_enter+0x2f3/0x7f0
>> > [   75.516055]  ? finish_wait+0x80/0x80
>> > [   75.516067]  pm_suspend+0x335/0x3a0
>> > [   75.516078]  state_store+0x85/0xf0
>> > [   75.516095]  kobj_attr_store+0xf/0x20
>> > [   75.516108]  sysfs_kf_write+0x37/0x40
>> > [   75.516117]  kernfs_fop_write+0x11c/0x1a0
>> > [   75.516132]  __vfs_write+0x37/0x160
>> > [   75.516145]  ? selinux_file_permission+0xfb/0x120
>> > [   75.516158]  ? security_file_permission+0x3b/0xc0
>> > [   75.516169]  vfs_write+0xb1/0x1a0
>> > [   75.516180]  SyS_write+0x55/0xc0
>> > [   75.516197]  entry_SYSCALL_64_fastpath+0x1a/0xa5
>> > ...
>> > [   76.584235] PM: early resume of devices complete after 1067.477 msecs
>> >
>> > If someone has a fix for this they want me to try, let me know.
>> >
>> > Regards,
>> >
>> > Hans
>> > ___
>> > Intel-gfx mailing list
>> > Intel-gfx@lists.freedesktop.org
>> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
>> 
>> -- 
>> Jani Nikula, Intel Open Source Technology Center

-- 
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] ✓ Fi.CI.BAT: success for drm/i915: use vma->size for appgtt allocate_va_range

[Chris Wilson]

On Tue, May 16, 2017 at 10:19:42AM -, Patchwork wrote:
> == Series Details ==
> 
> Series: drm/i915: use vma->size for appgtt allocate_va_range
> URL   : https://patchwork.freedesktop.org/series/24485/
> State : success
> 
> == Summary ==
> 
> Series 24485v1 drm/i915: use vma->size for appgtt allocate_va_range
> https://patchwork.freedesktop.org/api/1.0/series/24485/revisions/1/mbox/
> 
> Test kms_cursor_legacy:
> Subgroup basic-busy-flip-before-cursor-atomic:
> pass   -> FAIL   (fi-snb-2600) fdo#100215
> 
> fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

Applied, thanks for yet another bugfix.
-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] dma-buf/sync-file: Defer creation of sync_file->name

[kbuild test robot]

Hi Chris,

[auto build test ERROR on linus/master]
[also build test ERROR on v4.12-rc1 next-20170516]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Chris-Wilson/dma-buf-sync-file-Defer-creation-of-sync_file-name/20170512-193751
config: x86_64-rhel (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers//dma-buf/sync_debug.c: In function 'sync_print_sync_file':
>> drivers//dma-buf/sync_debug.c:137:53: error: 'struct sync_file' has no 
>> member named 'name'
 seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
^~

vim +137 drivers//dma-buf/sync_debug.c

0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  131 
 
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21  132 
 static void sync_print_sync_file(struct seq_file *s,
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21  133 
  struct sync_file *sync_file)
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  134 
 {
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  135 
int i;
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  136 
 
d7fdb0ae drivers/staging/android/sync_debug.c Gustavo Padovan   2016-01-21 @137 
seq_printf(s, "[%p] %s: %s\n", sync_file, sync_file->name,
d6c99f4b drivers/dma-buf/sync_debug.c Chris Wilson  2017-01-04  138 
   sync_status_str(dma_fence_get_status(sync_file->fence)));
0f0d8406 drivers/staging/android/sync_debug.c Maarten Lankhorst 2014-07-01  139 
 
f54d1867 drivers/dma-buf/sync_debug.c Chris Wilson  2016-10-25  140 
if (dma_fence_is_array(sync_file->fence)) {

:: The code at line 137 was first introduced by commit
:: d7fdb0ae9d115fa14ff3a5382c8a62de41c7786a staging/android: rename 
sync_fence to sync_file

:: TO: Gustavo Padovan 
:: CC: Greg Kroah-Hartman 

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: use vma->size for appgtt allocate_va_range

[Patchwork]

== Series Details ==

Series: drm/i915: use vma->size for appgtt allocate_va_range
URL   : https://patchwork.freedesktop.org/series/24485/
State : success

== Summary ==

Series 24485v1 drm/i915: use vma->size for appgtt allocate_va_range
https://patchwork.freedesktop.org/api/1.0/series/24485/revisions/1/mbox/

Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-atomic:
pass   -> FAIL   (fi-snb-2600) fdo#100215

fdo#100215 https://bugs.freedesktop.org/show_bug.cgi?id=100215

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:448s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:439s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:585s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:517s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:489s
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:409s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:426s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:502s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:579s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:584s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
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:544s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:400s

eb4cff1ea4032532931b804ecae4f29b1c9a8e6e drm-tip: 2017y-05m-16d-09h-32m-03s UTC 
integration manifest
d0f205e drm/i915: use vma->size for appgtt allocate_va_range

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4706/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 11/17] drm/i915: disable GTT cache for 2M/1G pages

[Chris Wilson]

On Tue, May 16, 2017 at 01:04:38PM +0300, Ville Syrjälä wrote:
> On Tue, May 16, 2017 at 09:29:42AM +0100, Matthew Auld wrote:
> > When SW enables the use of 2M/1G pages, it must disable the GTT cache.
> > 
> > Signed-off-by: Matthew Auld 
> > Cc: Joonas Lahtinen 
> > ---
> >  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 ef0e9f8d4dbd..b39b8d394179 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -8178,10 +8178,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)
> > @@ -8457,10 +8457,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);
> >  }
> 
> Should we perhaps have a modparam to make it easier to evaluate
> whether big pages are actually beneficial or not? If so, it should also
> affect whether we enable the the GTT cache or not.

If we are sticking to only using it on bdw 48b, then ppgtt=4? It doesn't
seem a good idea for a long term modparam, but who wants to keep a
modparam around where users might find it?
-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] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 16, 2017 12:48 PM
> To: Lofstedt, Marta 
> Cc: Daniel Vetter ; Martin Peres
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Tue, May 16, 2017 at 09:43:52AM +, Lofstedt, Marta wrote:
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Tuesday, May 16, 2017 12:04 PM
> > > To: Lofstedt, Marta 
> > > Cc: Daniel Vetter ; Martin Peres
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > test to capture the state of the GPU
> > >
> > > On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> > > >
> > > >
> > > > > -Original Message-
> > > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > > > To: Lofstedt, Marta 
> > > > > Cc: Daniel Vetter ; Martin Peres
> > > > > ; intel-gfx@lists.freedesktop.org
> > > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add
> > > > > a test to capture the state of the GPU
> > > > >
> > > > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > > > I hereby pull-out this patch.
> > > > > > The idea of it was to know if we were already wedged at the
> > > > > > beginning of
> > > > > testing, that would give us information on how to interpret
> > > > > silly results; such that test starting to get skipped and/or we
> > > > > got dmesg-warns/incomplete on tests that usually should be skipped.
> > > > > > Also, we are planning to soon deploy a piglit.conf solution
> > > > > > where testing
> > > > > will be terminated on wedged, so I agree that my test isn't really
> needed.
> > > > >
> > > > > Not everything is broken by wedged; internally we just use that
> > > > > as an indicator that GEM is hosed. KMS should still work, we
> > > > > must still be able to drive the displays to show the error and
> > > > > keep the servers alive until the data is saved (and hopefully
> > > > > gracefully degrade that we don't have to interrupt their immediate
> session).
> > > >
> > > > It doesn't matter if it is broken or not, if we are terminally
> > > > wedged the rest
> > > of the result may be silly. Look for example at CI_DRM_2612, the
> > > fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all
> > > test are skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where
> > > the machine hangs, but it is a gem test so it should have been
> > > skipped, right. My conclusion from seeing this pattern multiple
> > > times is that after terminally wedged, silly things can happen, i.e.
> > > we can't trust the results, and since we don't want silly bugs, the CI
> testing should be stopped.
> > >
> > > The machine didn't hang, it was remotely killed because the run timed
> out.
> > How do you know that?
> 
> The dmesg is a stream of flip timeouts until we run out of total BAT runtime
> (12 minutes + some startup slack).
> -Chris

Then look at CI_DRM_2602, wedged at igt@gem_busy@basic-hang-default, after a 
lot of skipping, we get incomplete result for another test, this time 
gem_exec_reloc@basic-gtt-cpu-noreloc

So, gem_exec_reloc@basic-cpu-gtt-noreloc and 
gem_exec_reloc@basic-gtt-cpu-noreloc are falsely getting blamed and my 
conclusion is that this is due to the permanent wedging started at 
gem_busy@basic-hang-default. So, to avoid bug reports for 
gem_exec_reloc@basic-cpu-gtt-noreloc and gem_exec_reloc@basic-gtt-cpu- noreloc 
the suggestion is to stop testing after we are terminally wedged. 

> 
> --
> 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 11/17] drm/i915: disable GTT cache for 2M/1G pages

[Ville Syrjälä]

On Tue, May 16, 2017 at 09:29:42AM +0100, Matthew Auld wrote:
> When SW enables the use of 2M/1G pages, it must disable the GTT cache.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> ---
>  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 ef0e9f8d4dbd..b39b8d394179 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -8178,10 +8178,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)
> @@ -8457,10 +8457,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);
>  }

Should we perhaps have a modparam to make it easier to evaluate
whether big pages are actually beneficial or not? If so, it should also
affect whether we enable the the GTT cache or not.

>  
>  static void g4x_init_clock_gating(struct drm_i915_private *dev_priv)
> -- 
> 2.9.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
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 06/17] mm/shmem: expose driver overridable huge option

[Kirill A. Shutemov]

On Tue, May 16, 2017 at 09:29:37AM +0100, Matthew Auld wrote:
> In i915 we are aiming to support huge GTT pages for the GPU, and to
> complement this we also want to enable THP for our shmem backed objects.
> Even though THP is supported in shmemfs it can only be enabled through
> the huge= mount option, but for users of the kernel mounted shm_mnt like
> i915, we are a little stuck. There is the sysfs knob shmem_enabled to
> either forcefully enable/disable the feature, but that seems to only be
> useful for testing purposes. What we propose is to expose a driver
> overridable huge option as part of shmem_inode_info to control the use
> of THP for a given mapping.

I don't like this. It's kinda hacky.

Is there a reason why i915 cannot mount a new tmpfs for own use?

Or other option would be to change default to SHMEM_HUGE_ADVISE and wire
up fadvise handle to control per-file allocation policy.

-- 
 Kirill A. Shutemov
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> a gtt_page_size member for gem objects.  We fill in the gtt page size by
> scanning the sg table to determine the max page size which satisfies the
> alignment for each sg entry.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 ++
>  drivers/gpu/drm/i915/i915_gem.c| 23 +++
>  drivers/gpu/drm/i915/i915_gem_object.h |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e18f11f77f35..a7a108d18a2d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2843,6 +2843,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 HAS_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.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0c1cbe98c994..6a5e864d7710 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct 
> drm_i915_gem_object *obj,
>   if (!IS_ERR(pages))
>   obj->ops->put_pages(obj, pages);
>  
> + obj->gtt_page_size = 0;
> +
>  unlock:
>   mutex_unlock(&obj->mm.lock);
>  }
> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>  void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
>struct sg_table *pages)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
> + struct scatterlist *sg;
> + unsigned int sg_mask = 0;
> + unsigned int i;
> + unsigned int bit;
> +
>   lockdep_assert_held(&obj->mm.lock);
>  
>   obj->mm.get_page.sg_pos = pages->sgl;
> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct 
> drm_i915_gem_object *obj,
>   __i915_gem_object_pin_pages(obj);
>   obj->mm.quirked = true;
>   }
> +
> + for_each_sg(pages->sgl, sg, pages->nents, i)
> + sg_mask |= sg->length;
> +
> + GEM_BUG_ON(!sg_mask);
> +

This should just be obj->gtt_page_sizes = sg_mask & supported_sizes;

And it should be obj->mm.gtt_page_sizes.

Then latter steps can make decisions based on the most strict
requirements, or least strict etc.
-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] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

[Ville Syrjälä]

mn Tue, May 16, 2017 at 10:47:48AM +0300, Jani Nikula wrote:
> On Mon, 15 May 2017, Hans de Goede  wrote:
> > Hi,
> >
> > I'm seeing this on suspend/resume on a GPD-win,
> > cherrytrail z8700 device:
> 
> Ville, does
> 
> commit 668e3b014afb66ab29e134bca7c258527273ac75
> Author: Ville Syrjälä 
> Date:   Thu Apr 27 19:02:20 2017 +0300
> 
> drm/i915: Fix runtime PM for LPE audio
> 
> in drm-intel-fixes address this?

ebf5f921478b ("drm/i915: Stop pretending to mask/unmask LPE audio
interrupts") is a more likely candidate.

> 
> BR,
> Jani.
> 
> 
> 
> >
> > [   75.514651] RPM wakelock ref not held during HW access
> > [   75.514827] [ cut here ]
> > [   75.515025] WARNING: CPU: 2 PID: 1832 at 
> > drivers/gpu/drm/i915/intel_drv.h:1780 fwtable_write32+0x1d3/0x240 [i915]
> > ...
> > [   75.515704] RIP: 0010:fwtable_write32+0x1d3/0x240 [i915]
> > ...
> > [   75.515767] Call Trace:
> > [   75.515952]  lpe_audio_irq_unmask+0x6a/0xc0 [i915]
> > [   75.515972]  irq_enable+0x3a/0x50
> > [   75.515984]  __enable_irq+0x34/0x60
> > [   75.515996]  resume_irqs+0x8f/0xd0
> > [   75.516007]  resume_device_irqs+0x10/0x20
> > [   75.516021]  dpm_resume_noirq+0x23e/0x310
> > [   75.516041]  suspend_devices_and_enter+0x2f3/0x7f0
> > [   75.516055]  ? finish_wait+0x80/0x80
> > [   75.516067]  pm_suspend+0x335/0x3a0
> > [   75.516078]  state_store+0x85/0xf0
> > [   75.516095]  kobj_attr_store+0xf/0x20
> > [   75.516108]  sysfs_kf_write+0x37/0x40
> > [   75.516117]  kernfs_fop_write+0x11c/0x1a0
> > [   75.516132]  __vfs_write+0x37/0x160
> > [   75.516145]  ? selinux_file_permission+0xfb/0x120
> > [   75.516158]  ? security_file_permission+0x3b/0xc0
> > [   75.516169]  vfs_write+0xb1/0x1a0
> > [   75.516180]  SyS_write+0x55/0xc0
> > [   75.516197]  entry_SYSCALL_64_fastpath+0x1a/0xa5
> > ...
> > [   76.584235] PM: early resume of devices complete after 1067.477 msecs
> >
> > If someone has a fix for this they want me to try, let me know.
> >
> > Regards,
> >
> > Hans
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center

-- 
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] drm/i915: Disable decoupled mmio for GEN9LP

[Chris Wilson]

On Mon, May 15, 2017 at 04:18:27PM -0700, kai.c...@intel.com wrote:
> From: Kai Chen 
> 
> The decoupled mmio feature doesn't work as intended by HW team. Enabling
> it with forcewake will only make debugging efforts more difficult, so
> let's just simply remove it.

Is the code going to be reused in the near future, i.e. why not remove
the dead code as well?
-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] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 09:43:52AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 12:04 PM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> > >
> > >
> > > > -Original Message-
> > > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > > To: Lofstedt, Marta 
> > > > Cc: Daniel Vetter ; Martin Peres
> > > > ; intel-gfx@lists.freedesktop.org
> > > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > > test to capture the state of the GPU
> > > >
> > > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > > I hereby pull-out this patch.
> > > > > The idea of it was to know if we were already wedged at the
> > > > > beginning of
> > > > testing, that would give us information on how to interpret silly
> > > > results; such that test starting to get skipped and/or we got
> > > > dmesg-warns/incomplete on tests that usually should be skipped.
> > > > > Also, we are planning to soon deploy a piglit.conf solution where
> > > > > testing
> > > > will be terminated on wedged, so I agree that my test isn't really 
> > > > needed.
> > > >
> > > > Not everything is broken by wedged; internally we just use that as
> > > > an indicator that GEM is hosed. KMS should still work, we must still
> > > > be able to drive the displays to show the error and keep the servers
> > > > alive until the data is saved (and hopefully gracefully degrade that
> > > > we don't have to interrupt their immediate session).
> > >
> > > It doesn't matter if it is broken or not, if we are terminally wedged the 
> > > rest
> > of the result may be silly. Look for example at CI_DRM_2612, the 
> > fi-elk-e7500
> > is wedged at igt@gem_busy@basic-hang-default, then all test are skipped
> > until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, but
> > it is a gem test so it should have been skipped, right. My conclusion from
> > seeing this pattern multiple times is that after terminally wedged, silly 
> > things
> > can happen, i.e. we can't trust the results, and since we don't want silly 
> > bugs,
> > the CI testing should be stopped.
> > 
> > The machine didn't hang, it was remotely killed because the run timed out.
> How do you know that?

The dmesg is a stream of flip timeouts until we run out of total BAT
runtime (12 minutes + some startup slack).
-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] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 16, 2017 12:04 PM
> To: Lofstedt, Marta 
> Cc: Daniel Vetter ; Martin Peres
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> >
> >
> > > -Original Message-
> > > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > > Sent: Tuesday, May 16, 2017 11:21 AM
> > > To: Lofstedt, Marta 
> > > Cc: Daniel Vetter ; Martin Peres
> > > ; intel-gfx@lists.freedesktop.org
> > > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a
> > > test to capture the state of the GPU
> > >
> > > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > > I hereby pull-out this patch.
> > > > The idea of it was to know if we were already wedged at the
> > > > beginning of
> > > testing, that would give us information on how to interpret silly
> > > results; such that test starting to get skipped and/or we got
> > > dmesg-warns/incomplete on tests that usually should be skipped.
> > > > Also, we are planning to soon deploy a piglit.conf solution where
> > > > testing
> > > will be terminated on wedged, so I agree that my test isn't really needed.
> > >
> > > Not everything is broken by wedged; internally we just use that as
> > > an indicator that GEM is hosed. KMS should still work, we must still
> > > be able to drive the displays to show the error and keep the servers
> > > alive until the data is saved (and hopefully gracefully degrade that
> > > we don't have to interrupt their immediate session).
> >
> > It doesn't matter if it is broken or not, if we are terminally wedged the 
> > rest
> of the result may be silly. Look for example at CI_DRM_2612, the fi-elk-e7500
> is wedged at igt@gem_busy@basic-hang-default, then all test are skipped
> until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, but
> it is a gem test so it should have been skipped, right. My conclusion from
> seeing this pattern multiple times is that after terminally wedged, silly 
> things
> can happen, i.e. we can't trust the results, and since we don't want silly 
> bugs,
> the CI testing should be stopped.
> 
> The machine didn't hang, it was remotely killed because the run timed out.
How do you know that?
> -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 10/12] drm/i915/skl+: use linetime latency if ddb size is not available

[Mahesh Kumar]

Hi,


On Tuesday 16 May 2017 04:08 AM, Matt Roper wrote:

On Mon, May 15, 2017 at 02:04:35PM +0530, Mahesh Kumar wrote:

From: "Kumar, Mahesh" 

This patch make changes to use linetime latency if allocated
DDB size during plane watermark calculation is not available,
This is required to implement new DDB allocation algorithm.

In New Algorithm DDB is allocated based on WM values, because of which
number of DDB blocks will not be available during WM calculation,
So this "linetime latency" is suggested by SV/HW team to be used during
switch-case for WM blocks selection.

(Just realized I never actually sent my review of this patch on the
previous series review; sorry for the delay.)

I'm not sure if the term "linetime" is completely self-explanatory.  You
might want to explicitly clarify that it's the time it takes to fill a
single row at a given clock rate.  So "linetime latency" here is defined
as "line time in microseconds = pipe horizontal total number of pixels /
pixel rate in MHz."

Will update commit message.



Changes since v1:
  - Rebase on top of Paulo's patch series
Changes since v2:
  - Fix if-else condition (pointed by Maarten)
Changes since v3:
  - Use common function for timetime_us calculation (Paulo)
  - rebase on drm-tip
Changes since v4:
  - Use consistent name for fixed_point operation

Signed-off-by: "Mahesh Kumar" 
---
  drivers/gpu/drm/i915/i915_drv.h |  7 +++
  drivers/gpu/drm/i915/intel_pm.c | 42 -
  2 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a1858c3eb33a..84052990e695 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -115,6 +115,13 @@ typedef struct {
fp; \
  })
  
+static inline bool is_fixed16_zero(uint_fixed_16_16_t val)

+{
+   if (val.val == 0)
+   return true;
+   return false;
+}
+
  static inline uint_fixed_16_16_t u32_to_fixed_16_16(uint32_t val)
  {
uint_fixed_16_16_t fp;
diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 0f1d9f672e83..d73369c2c2d9 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4197,6 +4197,27 @@ static uint_fixed_16_16_t skl_wm_method2(uint32_t 
pixel_rate,
return ret;
  }
  
+static uint_fixed_16_16_t

+skl_get_linetime_us(struct intel_crtc_state *cstate)

We use the same definition of linetime for all platforms that use the
concept of 'linetime' (hsw+).  So maybe the skl_ prefix here isn't
really appropriate?

will make it intel_get_linetime_us.

For consistency, should we also call this new function when calculating
the HSW/BDW watermarks in hsw_compute_linetime_wm()?  Or consolidate
skl_compute_linetime_wm() with hsw_compute_linetime_wm()?  Potentially
something we could do as a follow-up patch if we don't want to deal with
it while getting this series in.
sounds good :), will create a new patch to use intel_get_linetime_us in 
hsw_compute_linetime_wm.
hsw & skl require bunch of other calculations/WA in linetime_wm, so will 
keep them separate function only.



+{
+   uint32_t pixel_rate;
+   uint32_t crtc_htotal;
+   uint_fixed_16_16_t linetime_us;
+
+   if (!cstate->base.active)
+   return u32_to_fixed_16_16(0);
+
+   pixel_rate = cstate->pixel_rate;
+
+   if (WARN_ON(pixel_rate == 0))
+   return u32_to_fixed_16_16(0);
+
+   crtc_htotal = cstate->base.adjusted_mode.crtc_htotal;
+   linetime_us = fixed_16_16_div_u64(crtc_htotal * 1000, pixel_rate);
+
+   return linetime_us;
+}
+
  static uint32_t
  skl_adjusted_plane_pixel_rate(const struct intel_crtc_state *cstate,
  const struct intel_plane_state *pstate)
@@ -4331,12 +4352,18 @@ static int skl_compute_plane_wm(const struct 
drm_i915_private *dev_priv,
if (y_tiled) {
selected_result = max_fixed_16_16(method2, y_tile_minimum);
} else {
+   uint32_t linetime_us;
+
+   linetime_us = fixed_16_16_to_u32_round_up(
+   skl_get_linetime_us(cstate));
if ((cpp * cstate->base.adjusted_mode.crtc_htotal / 512 < 1) &&
(plane_bytes_per_line / 512 < 1))
selected_result = method2;
-   else if ((ddb_allocation /
+   else if ((ddb_allocation && ddb_allocation /
fixed_16_16_to_u32_round_up(plane_blocks_per_line)) >= 
1)
selected_result = min_fixed_16_16(method1, method2);
+   else if (latency >= linetime_us)
+   selected_result = method2;

Based on the commit message, I'm a little bit confused.  The plan is to
switch to the new algorithm where we calculate watermarks first and then
partition DDB second.  So at the end, ddb_allocation should never be
available here, right?  In that case, can we just rem

Re: [Intel-gfx] [PATCH 2/2] gpu: drm: i915: compress logic into one line

[Daniel Vetter]

On Mon, May 15, 2017 at 05:00:28PM -0500, Gustavo A. R. Silva wrote:
> Simplify logic to avoid unnecessary variable declaration and assignment.
> 
> Signed-off-by: Gustavo A. R. Silva 

Both applied, thanks.
-Daniel

> ---
>  drivers/gpu/drm/i915/intel_display.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index b13b53b..ca6479a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -9565,7 +9565,6 @@ static int ironlake_crtc_compute_clock(struct 
> intel_crtc *crtc,
>  {
>   struct drm_device *dev = crtc->base.dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> - struct intel_shared_dpll *pll;
>   const struct intel_limit *limit;
>   int refclk = 12;
>  
> @@ -9609,8 +9608,7 @@ static int ironlake_crtc_compute_clock(struct 
> intel_crtc *crtc,
>  
>   ironlake_compute_dpll(crtc, crtc_state, NULL);
>  
> - pll = intel_get_shared_dpll(crtc, crtc_state, NULL);
> - if (pll == NULL) {
> + if (!intel_get_shared_dpll(crtc, crtc_state, NULL)) {
>   DRM_DEBUG_DRIVER("failed to find PLL for pipe %c\n",
>pipe_name(crtc->pipe));
>   return -EINVAL;
> -- 
> 2.5.0
> 
> ___
> dri-devel mailing list
> dri-de...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915/guc:fix spelling mistake: "adddress" -> "address"

[Daniel Vetter]

On Tue, May 16, 2017 at 10:22:35AM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> Trivial fix to spelling mistake in seq_printf message.
> 
> Fixes: a8b9370fc79c1 ("drm/i915/guc: Dump the GuC stage descriptor pool in 
> debugfs")
> Signed-off-by: Colin Ian King 

Applied, thanks.
-Daniel
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index bd9abef40c66..76abff186d01 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2582,7 +2582,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
> *data)
>  desc->db_trigger_uk);
>   seq_printf(m, "\tProcess descriptor: 0x%x\n",
>  desc->process_desc);
> - seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
> + seq_printf(m, "\tWorkqueue address: 0x%x, size: 0x%x\n",
>  desc->wq_addr, desc->wq_size);
>   seq_putc(m, '\n');
>  
> -- 
> 2.11.0
> 
> ___
> 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

[Intel-gfx] [PATCH] Revert "Revert "sched/clock: Fix broken stable to unstable transfer""

[Daniel Vetter]

This reverts commit 471199349134ed612e15deec17c95fafe6b07231.

For CI testing only, before I drop the patch from our CI hacks pile.
-Daniel
---
 kernel/sched/clock.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/kernel/sched/clock.c b/kernel/sched/clock.c
index 24a3e01bf8cb..00a45c45beca 100644
--- a/kernel/sched/clock.c
+++ b/kernel/sched/clock.c
@@ -221,7 +221,7 @@ static inline u64 wrap_max(u64 x, u64 y)
  */
 static u64 sched_clock_local(struct sched_clock_data *scd)
 {
-   u64 now, clock, old_clock, min_clock, max_clock;
+   u64 now, clock, old_clock, min_clock, max_clock, gtod;
s64 delta;
 
 again:
@@ -238,9 +238,10 @@ static u64 sched_clock_local(struct sched_clock_data *scd)
 *scd->tick_gtod + TICK_NSEC);
 */
 
-   clock = scd->tick_gtod + __gtod_offset + delta;
-   min_clock = wrap_max(scd->tick_gtod, old_clock);
-   max_clock = wrap_max(old_clock, scd->tick_gtod + TICK_NSEC);
+   gtod = scd->tick_gtod + __gtod_offset;
+   clock = gtod + delta;
+   min_clock = wrap_max(gtod, old_clock);
+   max_clock = wrap_max(old_clock, gtod + TICK_NSEC);
 
clock = wrap_max(clock, min_clock);
clock = wrap_min(clock, max_clock);
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/guc:fix spelling mistake: "adddress" -> "address"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in seq_printf message.

Fixes: a8b9370fc79c1 ("drm/i915/guc: Dump the GuC stage descriptor pool in 
debugfs")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef40c66..76abff186d01 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2582,7 +2582,7 @@ static int i915_guc_stage_pool(struct seq_file *m, void 
*data)
   desc->db_trigger_uk);
seq_printf(m, "\tProcess descriptor: 0x%x\n",
   desc->process_desc);
-   seq_printf(m, "\tWorkqueue adddress: 0x%x, size: 0x%x\n",
+   seq_printf(m, "\tWorkqueue address: 0x%x, size: 0x%x\n",
   desc->wq_addr, desc->wq_size);
seq_putc(m, '\n');
 
-- 
2.11.0

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: use vma->size for appgtt allocate_va_range

[Chris Wilson]

On Tue, May 16, 2017 at 09:55:14AM +0100, Matthew Auld wrote:
> For the aliasing ppgtt we clear the va range up to vma->size, but seem
> to allocate up to vma->node.size, which is a little inconsistent given
> that vma->node.size >= vma->size. Not that is really matters all that
> much since we preallocate anyway, but for consistency just use
> vma->size.

We clear vma->size, so we have better allocate vma->size as well.
 
> Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
> Signed-off-by: Matthew Auld 
> Cc: Chris Wilson 
Reviewed-by: Chris Wilson 
-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] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 11:21 AM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > I hereby pull-out this patch.
> > > The idea of it was to know if we were already wedged at the beginning of
> > testing, that would give us information on how to interpret silly results; 
> > such
> > that test starting to get skipped and/or we got dmesg-warns/incomplete on
> > tests that usually should be skipped.
> > > Also, we are planning to soon deploy a piglit.conf solution where testing
> > will be terminated on wedged, so I agree that my test isn't really needed.
> > 
> > Not everything is broken by wedged; internally we just use that as an
> > indicator that GEM is hosed. KMS should still work, we must still be able to
> > drive the displays to show the error and keep the servers alive until the 
> > data
> > is saved (and hopefully gracefully degrade that we don't have to interrupt
> > their immediate session).
> 
> It doesn't matter if it is broken or not, if we are terminally wedged the 
> rest of the result may be silly. Look for example at CI_DRM_2612, the 
> fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all test are 
> skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, 
> but it is a gem test so it should have been skipped, right. My conclusion 
> from seeing this pattern multiple times is that after terminally wedged, 
> silly things can happen, i.e. we can't trust the results, and since we don't 
> want silly bugs, the CI testing should be stopped.

Oh, and note it was running so slowly because of a KMS bug that is quite
common.
-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] [PULL] drm-intel-next

[Daniel Vetter]

Hi Dave,

Three tags in total. I also just realized that in the last one I've
forgotten to mention the LPE audio fixes from Ville, which also touch
sound/. Those patches are all reviewed by Takashi.

drm-intel-next-2017-05-15:
Another pile of stuff for 4.12:

- OA improvements and fixes from Robert Bragg
- fixes for the dp aux backlight driver (Puthikorn Voravootivat)
- no RCU during shrinking (unfortunately), from Joonas
- small atomic leftovers (better unpin, statified hw verifier), from
  Maarten
- g4x wm fixes (Ville)
- piles of cursor fixes/improvements (Ville)
- g4x overlay plane support (Ville)
- prep for new guc logging/notification (Michal Wajdeczko)
- pile of static checker appeasement from Imre
- implement dma_buf->kmap, good for testing (Chris)
- fine-tune ring handling (Chris)
drm-intel-next-2017-05-02:
Somehow not much these 2 weeks ...

- (hopefully) stability fixes for byt/bsw gt wake (Chris)
- tighten up requests (especially restarts) checks and debug tracking
  (Chris)
- unify context handling more for gen5+ (Chris+Joonas)
- oddball bugfixes as usual
drm-intel-next-2017-04-18:
First slice of 4.13 features:

new uabi:
- extend error state dumping to include non-batch buffers requested by
  userspace (Chris), so that mesa gets more useful error state dumps
- reapply the link status patch, for handlig dp link failures
  (Manasi). This needs updated -modesetting to work correctly.
- Add new _WC cache domain, our assumption that wc can be subsumed by
  the existing cache domains didn't pan out (Chris)

feature work:
- first pile of conversion to atomic properties for connectors
  (Maarten)
- refactor dp link rate handling code and related areas (Jani)
- split engine info into class and runtime stuff (Oscar Mateo)
- more robust wait_for_register code (Chris, Michal Wajdeczko)
- fix rcu issues in the shrinker and simplify locking (Joonas)
- guc/huc for glk (Anusha)
- enable atomic modesetting for vlv/chv (Ville), plus final fixes for
  that

I chatted with Sean, and the plan is that he'll send you the drm-misc-next
pull for opening 4.13 drm-next later today. We need to backmerge the
entire thing into drm-intel afterwards, Maarten needs the connector state
hooks for landing the remaining connector atomicification patches for
i915.

Cheers, Daniel


The following changes since commit 8b03d1ed2c43a2ba5ef3381322ee4515b97381bf:

  Merge branch 'linux-4.12' of git://github.com/skeggsb/linux into drm-next 
(2017-05-02 04:46:01 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel tags/drm-intel-next-2017-05-15

for you to fetch changes up to 2388cd9c5056b10c8e461ca2ab075f49d6f1b25d:

  drm/i915: Update DRIVER_DATE to 20170515 (2017-05-15 09:11:48 +0200)


Another pile of stuff for 4.12:

- OA improvements and fixes from Robert Bragg
- fixes for the dp aux backlight driver (Puthikorn Voravootivat)
- no RCU during shrinking (unfortunately), from Joonas
- small atomic leftovers (better unpin, statified hw verifier), from
  Maarten
- g4x wm fixes (Ville)
- piles of cursor fixes/improvements (Ville)
- g4x overlay plane support (Ville)
- prep for new guc logging/notification (Michal Wajdeczko)
- pile of static checker appeasement from Imre
- implement dma_buf->kmap, good for testing (Chris)
- fine-tune ring handling (Chris)


Ander Conselvan de Oliveira (2):
  drm/i915/glk: Don't allow 12 bpc when htotal is too big
  drm/i915/glk: Fix DSI "*ERROR* ULPS is still active" messages

Andrea Arcangeli (1):
  i915: initialize the free_list of the fencing atomic_helper

Anusha Srivatsa (2):
  drm/i915/GuC/GLK: Load GuC on GLK
  drm/i915/GLK/HuC: Load HuC on GLK

Chris Wilson (51):
  drm/i915: intel_ring.engine is unused
  drm/i915: Onion unwind for intel_init_ring_common()
  drm/i915: Park the signaler before sleeping
  drm/i915: Apply a cond_resched() to the saturated signaler
  drm/i915: Use the right mapping_gfp_mask for final shmem allocation
  drm/i915: Assert the engine is idle before overwiting the HWS
  drm/i915: Advance ring->head fully when idle
  drm/i915: The shrinker already acquires struct_mutex, so call it unlocked
  drm/i915: Drain any freed objects prior to hibernation
  drm/i915: Break up long runs of freeing objects
  drm/i915: Insert cond_resched() into i915_gem_free_objects
  drm/i915: Use drm_i915_private directly from debugfs
  drm/i915: Stop second guessing the caller for 
intel_uncore_wait_for_register()
  drm/i915: Stop sleeping from inside gen6_bsd_submit_request()
  drm/i915: Acquire uncore.lock over intel_uncore_wait_for_register()
  drm/i915: Use __intel_uncore_wait_for_register_fw for 
sandybride_pcode_read
  drm/i915: Use safer intel_uncore_wait_for_register in ring-init
  drm/i915: Rename intel_engine_cs.exec_id to uabi_id

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

[Chris Wilson]

On Tue, May 16, 2017 at 08:54:51AM +, Lofstedt, Marta wrote:
> 
> 
> > -Original Message-
> > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> > Sent: Tuesday, May 16, 2017 11:21 AM
> > To: Lofstedt, Marta 
> > Cc: Daniel Vetter ; Martin Peres
> > ; intel-gfx@lists.freedesktop.org
> > Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> > capture
> > the state of the GPU
> > 
> > On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > > I hereby pull-out this patch.
> > > The idea of it was to know if we were already wedged at the beginning of
> > testing, that would give us information on how to interpret silly results; 
> > such
> > that test starting to get skipped and/or we got dmesg-warns/incomplete on
> > tests that usually should be skipped.
> > > Also, we are planning to soon deploy a piglit.conf solution where testing
> > will be terminated on wedged, so I agree that my test isn't really needed.
> > 
> > Not everything is broken by wedged; internally we just use that as an
> > indicator that GEM is hosed. KMS should still work, we must still be able to
> > drive the displays to show the error and keep the servers alive until the 
> > data
> > is saved (and hopefully gracefully degrade that we don't have to interrupt
> > their immediate session).
> 
> It doesn't matter if it is broken or not, if we are terminally wedged the 
> rest of the result may be silly. Look for example at CI_DRM_2612, the 
> fi-elk-e7500 is wedged at igt@gem_busy@basic-hang-default, then all test are 
> skipped until gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, 
> but it is a gem test so it should have been skipped, right. My conclusion 
> from seeing this pattern multiple times is that after terminally wedged, 
> silly things can happen, i.e. we can't trust the results, and since we don't 
> want silly bugs, the CI testing should be stopped.

The machine didn't hang, it was remotely killed because the run timed out.
-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: Import the kfence selftests for i915_sw_fence

[Chris Wilson]

On Mon, May 15, 2017 at 11:52:55AM +0100, Chris Wilson wrote:
> A long time ago, I wrote some selftests for the struct kfence idea. Now
> that we have infrastructure in i915/igt for running kselftests, include
> some for i915_sw_fence.
> 
> Signed-off-by: Chris Wilson 

Anyone want to stamp these?
-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] tests/initial_state: Add a test to capture the state of the GPU

[Lofstedt, Marta]

> -Original Message-
> From: Chris Wilson [mailto:ch...@chris-wilson.co.uk]
> Sent: Tuesday, May 16, 2017 11:21 AM
> To: Lofstedt, Marta 
> Cc: Daniel Vetter ; Martin Peres
> ; intel-gfx@lists.freedesktop.org
> Subject: Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to 
> capture
> the state of the GPU
> 
> On Tue, May 16, 2017 at 07:42:51AM +, Lofstedt, Marta wrote:
> > I hereby pull-out this patch.
> > The idea of it was to know if we were already wedged at the beginning of
> testing, that would give us information on how to interpret silly results; 
> such
> that test starting to get skipped and/or we got dmesg-warns/incomplete on
> tests that usually should be skipped.
> > Also, we are planning to soon deploy a piglit.conf solution where testing
> will be terminated on wedged, so I agree that my test isn't really needed.
> 
> Not everything is broken by wedged; internally we just use that as an
> indicator that GEM is hosed. KMS should still work, we must still be able to
> drive the displays to show the error and keep the servers alive until the data
> is saved (and hopefully gracefully degrade that we don't have to interrupt
> their immediate session).

It doesn't matter if it is broken or not, if we are terminally wedged the rest 
of the result may be silly. Look for example at CI_DRM_2612, the fi-elk-e7500 
is wedged at igt@gem_busy@basic-hang-default, then all test are skipped until 
gem_exec_reloc@basic-cpu-gtt-noreloc where the machine hangs, but it is a gem 
test so it should have been skipped, right. My conclusion from seeing this 
pattern multiple times is that after terminally wedged, silly things can 
happen, i.e. we can't trust the results, and since we don't want silly bugs, 
the CI testing should be stopped.

> 
> Whilst that may be out of scope for BAT, it should not be completely beyond
> us for robustness testing.
> -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] drm/i915: use vma->size for appgtt allocate_va_range

[Matthew Auld]

For the aliasing ppgtt we clear the va range up to vma->size, but seem
to allocate up to vma->node.size, which is a little inconsistent given
that vma->node.size >= vma->size. Not that is really matters all that
much since we preallocate anyway, but for consistency just use
vma->size.

Fixes: ff685975d97f ("drm/i915: Move allocate_va_range to GTT")
Signed-off-by: Matthew Auld 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bc3c63e92c16..a9d78ebcabfe 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2313,7 +2313,7 @@ static int aliasing_gtt_bind_vma(struct i915_vma *vma,
appgtt->base.allocate_va_range) {
ret = appgtt->base.allocate_va_range(&appgtt->base,
 vma->node.start,
-vma->node.size);
+vma->size);
if (ret)
goto err_pages;
}
-- 
2.9.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 add support for huge-gtt-pages

[Patchwork]

== Series Details ==

Series: add support for huge-gtt-pages
URL   : https://patchwork.freedesktop.org/series/24481/
State : success

== Summary ==

Series 24481v1 add support for huge-gtt-pages
https://patchwork.freedesktop.org/api/1.0/series/24481/revisions/1/mbox/

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:442s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:509s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:507s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:422s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:420s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:505s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7500u total:278  pass:255  dwarn:5   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7560u total:278  pass:263  dwarn:5   dfail:0   fail:0   skip:10  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:456s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:588s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:470s
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:433s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:555s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:409s

9b25870f9fa4548ec2bb40e42fa28f35db2189e1 drm-tip: 2017y-05m-15d-15h-47m-31s UTC 
integration manifest
cf035b2 drm/i915: enable platform support for 1G pages
ead918b drm/i915: enable platform support for 2M pages
ee0e57d drm/i915: enable platform support for 64K pages
d0bfa76 drm/i915/debugfs: include some gtt_page_size metrics
c6fb01e drm/i915: support inserting 1G pages into the 48b PPGTT
2dc2ed8 drm/i915: support inserting 2M pages into the 48b PPGTT
f06788c drm/i915: disable GTT cache for 2M/1G pages
86ce13d drm/i915: support inserting 64K pages into the 48b PPGTT
fcc9241 drm/i915: enable IPS bit for 64K pages
34b66cf drm/i915: pass gtt page size to insert_entries
61d5eb7 drm/i915: request THP for shmem backed objects
34a823b mm/shmem: expose driver overridable huge option
9b38f26 drm/i915: fallback to normal pages on vma insert failure
1fa7ce3 drm/i915: align 64K objects to 2M
d357c27 drm/i915: align the vma start to the gtt page size
0ecfdaa drm/i915: introduce gtt page size
176907c drm/i915: introduce page_size_mask to dev_info

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_4705/
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/17] drm/i915: introduce gtt page size

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:33AM +0100, Matthew Auld wrote:
> In preparation for supporting huge gtt pages for the ppgtt, we introduce
> a gtt_page_size member for gem objects.  We fill in the gtt page size by
> scanning the sg table to determine the max page size which satisfies the
> alignment for each sg entry.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> Cc: Daniel Vetter 
> ---
>  drivers/gpu/drm/i915/i915_drv.h|  2 ++
>  drivers/gpu/drm/i915/i915_gem.c| 23 +++
>  drivers/gpu/drm/i915/i915_gem_object.h |  2 ++
>  3 files changed, 27 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index e18f11f77f35..a7a108d18a2d 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2843,6 +2843,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 HAS_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.c b/drivers/gpu/drm/i915/i915_gem.c
> index 0c1cbe98c994..6a5e864d7710 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -2294,6 +2294,8 @@ void __i915_gem_object_put_pages(struct 
> drm_i915_gem_object *obj,
>   if (!IS_ERR(pages))
>   obj->ops->put_pages(obj, pages);
>  
> + obj->gtt_page_size = 0;
> +
>  unlock:
>   mutex_unlock(&obj->mm.lock);
>  }
> @@ -2473,6 +2475,13 @@ i915_gem_object_get_pages_gtt(struct 
> drm_i915_gem_object *obj)
>  void __i915_gem_object_set_pages(struct drm_i915_gem_object *obj,
>struct sg_table *pages)
>  {
> + struct drm_i915_private *i915 = to_i915(obj->base.dev);
> + unsigned long supported_page_sizes = INTEL_INFO(i915)->page_size_mask;
> + struct scatterlist *sg;
> + unsigned int sg_mask = 0;
> + unsigned int i;
> + unsigned int bit;
> +
>   lockdep_assert_held(&obj->mm.lock);
>  
>   obj->mm.get_page.sg_pos = pages->sgl;
> @@ -2486,6 +2495,20 @@ void __i915_gem_object_set_pages(struct 
> drm_i915_gem_object *obj,
>   __i915_gem_object_pin_pages(obj);
>   obj->mm.quirked = true;
>   }
> +
> + for_each_sg(pages->sgl, sg, pages->nents, i)
> + sg_mask |= sg->length;
> +
> + GEM_BUG_ON(!sg_mask);
> +
> + for_each_set_bit(bit, &supported_page_sizes, BITS_PER_LONG) {
> + if (!IS_ALIGNED(sg_mask, 1 << bit))
> + break;
> +
> + obj->gtt_page_size = 1 << bit;
> + }

Not here. This is the synchronous part, and we really do not want to
loop again. However, we have just looped over and can compute this mask
inline in the asynchronous portion of get_pages.
-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 03/17] drm/i915: align the vma start to the gtt page size

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:34AM +0100, Matthew Auld wrote:
> When inserting into a 48bit PPGTT we need to align the vma start address
> to the required page size boundary. The size will already be aligned so
> no padding is needed.
> 
> Signed-off-by: Matthew Auld 
> Cc: Joonas Lahtinen 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_vma.c | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 1aba47024656..53f6c94b2ee6 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -471,6 +471,14 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
> alignment, u64 flags)
>   if (ret)
>   return ret;
>  
> + if (i915_vm_is_48bit(vma->vm) &&
> + obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
> + unsigned int page_alignment = obj->gtt_page_size;
> +
> + alignment = max_t(typeof(alignment), alignment, page_alignment);
> + GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
> + }
> +
>   if (flags & PIN_OFFSET_FIXED) {

We should only increase the minimum alignment for !FIXED. Otherwise the
softpin user will not know what games we are playing and be able to
compensate.
-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 05/17] drm/i915: fallback to normal pages on vma insert failure

[Chris Wilson]

On Tue, May 16, 2017 at 09:29:36AM +0100, Matthew Auld wrote:
> Part of the cost in choosing huge-gtt-pages is potentially using a
> larger alignment and/or size. Therefore if our vma insert fails either
> because of the insert/reserve or the pin-offset-fixed we should fallback
> to normal pages and retry before giving up.

Too late. By the point you do this, we will already have been evicting
from the GTT. We need a larger shakeup to take this trial-and-error
approach into consideration, though perhaps with just including NOEVICT,
it may make more sense.
-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 16/17] drm/i915: enable platform support for 2M pages

[Matthew Auld]

For gen8+ enable platform level support for 2M pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 9 ++---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 0a6940c3841d..452f061fd7b3 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -319,7 +319,8 @@ static const struct intel_device_info intel_haswell_info = {
 #define BDW_FEATURES \
HSW_FEATURES, \
BDW_COLORS, \
-   GEN_DEFAULT_PAGE_SIZES, \
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K | \
+ I915_GTT_PAGE_SIZE_2M, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -355,7 +356,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
.page_size_mask = I915_GTT_PAGE_SIZE_4K |
- I915_GTT_PAGE_SIZE_64K,
+ I915_GTT_PAGE_SIZE_64K |
+ I915_GTT_PAGE_SIZE_2M,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
@@ -363,7 +365,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 
 #define GEN9_DEFAULT_PAGE_SIZES \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
- I915_GTT_PAGE_SIZE_64K
+ I915_GTT_PAGE_SIZE_64K | \
+ I915_GTT_PAGE_SIZE_2M
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index d41ed2178e3e..23f0db2dbb5d 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -145,7 +145,8 @@ struct drm_i915_private *mock_gem_device(void)
 
mkwrite_device_info(i915)->page_size_mask =
I915_GTT_PAGE_SIZE_4K |
-   I915_GTT_PAGE_SIZE_64K;
+   I915_GTT_PAGE_SIZE_64K |
+   I915_GTT_PAGE_SIZE_2M;
 
spin_lock_init(&i915->mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 14/17] drm/i915/debugfs: include some gtt_page_size metrics

[Matthew Auld]

Good to know, mostly for debugging purposes.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 37 ++---
 1 file changed, 34 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index bd9abef40c66..dd36baa47667 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(&obj->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 %02x %02x %s%s%s",
   &obj->base,
   get_active_flag(obj),
   get_pin_flag(obj),
@@ -136,6 +153,7 @@ 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->gtt_page_size),
   obj->base.read_domains,
   obj->base.write_domain,
   i915_cache_level_str(dev_priv, obj->cache_level),
@@ -399,8 +417,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 = &dev_priv->drm;
struct i915_ggtt *ggtt = &dev_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 +434,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, &dev_priv->mm.unbound_list, global_link) {
size += obj->base.size;
++count;
@@ -429,6 +448,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
mapped_count++;
mapped_size += obj->base.size;
}
+
+   if (obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
+   huge_count++;
+   huge_size += obj->base.size;
+   }
}
seq_printf(m, "%u unbound objects, %llu bytes\n", count, size);
 
@@ -451,6 +475,11 @@ static int i915_gem_object_info(struct seq_file *m, void 
*data)
mapped_count++;
mapped_size += obj->base.size;
}
+
+   if (obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
+   huge_count++;
+   huge_size += obj->base.size;
+   }
}
seq_printf(m, "%u bound objects, %llu bytes\n",
   count, size);
@@ -458,6 +487,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.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 15/17] drm/i915: enable platform support for 64K pages

[Matthew Auld]

For gen9+ enable platform level support for 64K pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 6 --
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 7caccb5bf963..0a6940c3841d 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -354,14 +354,16 @@ static const struct intel_device_info 
intel_cherryview_info = {
.has_aliasing_ppgtt = 1,
.has_full_ppgtt = 1,
.display_mmio_offset = VLV_DISPLAY_BASE,
-   GEN_DEFAULT_PAGE_SIZES,
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K |
+ I915_GTT_PAGE_SIZE_64K,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
 };
 
 #define GEN9_DEFAULT_PAGE_SIZES \
-   .page_size_mask = I915_GTT_PAGE_SIZE_4K
+   .page_size_mask = I915_GTT_PAGE_SIZE_4K | \
+ I915_GTT_PAGE_SIZE_64K
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index b7e4ba03e3bc..d41ed2178e3e 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -144,7 +144,8 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->gen = -1;
 
mkwrite_device_info(i915)->page_size_mask =
-   I915_GTT_PAGE_SIZE_4K;
+   I915_GTT_PAGE_SIZE_4K |
+   I915_GTT_PAGE_SIZE_64K;
 
spin_lock_init(&i915->mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 17/17] drm/i915: enable platform support for 1G pages

[Matthew Auld]

For gen8+ enable platform level support for 1G pages. Also enable for
mock testing.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_pci.c  | 9 ++---
 drivers/gpu/drm/i915/selftests/mock_gem_device.c | 3 ++-
 2 files changed, 8 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_pci.c b/drivers/gpu/drm/i915/i915_pci.c
index 452f061fd7b3..68baefe6566c 100644
--- a/drivers/gpu/drm/i915/i915_pci.c
+++ b/drivers/gpu/drm/i915/i915_pci.c
@@ -320,7 +320,8 @@ static const struct intel_device_info intel_haswell_info = {
HSW_FEATURES, \
BDW_COLORS, \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
- I915_GTT_PAGE_SIZE_2M, \
+ I915_GTT_PAGE_SIZE_2M | \
+ I915_GTT_PAGE_SIZE_1G, \
.has_logical_ring_contexts = 1, \
.has_full_48bit_ppgtt = 1, \
.has_64bit_reloc = 1
@@ -357,7 +358,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
.display_mmio_offset = VLV_DISPLAY_BASE,
.page_size_mask = I915_GTT_PAGE_SIZE_4K |
  I915_GTT_PAGE_SIZE_64K |
- I915_GTT_PAGE_SIZE_2M,
+ I915_GTT_PAGE_SIZE_2M |
+ I915_GTT_PAGE_SIZE_1G,
GEN_CHV_PIPEOFFSETS,
CURSOR_OFFSETS,
CHV_COLORS,
@@ -366,7 +368,8 @@ static const struct intel_device_info intel_cherryview_info 
= {
 #define GEN9_DEFAULT_PAGE_SIZES \
.page_size_mask = I915_GTT_PAGE_SIZE_4K | \
  I915_GTT_PAGE_SIZE_64K | \
- I915_GTT_PAGE_SIZE_2M
+ I915_GTT_PAGE_SIZE_2M | \
+ I915_GTT_PAGE_SIZE_1G
 
 static const struct intel_device_info intel_skylake_info = {
BDW_FEATURES,
diff --git a/drivers/gpu/drm/i915/selftests/mock_gem_device.c 
b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
index 23f0db2dbb5d..2535e211650c 100644
--- a/drivers/gpu/drm/i915/selftests/mock_gem_device.c
+++ b/drivers/gpu/drm/i915/selftests/mock_gem_device.c
@@ -146,7 +146,8 @@ struct drm_i915_private *mock_gem_device(void)
mkwrite_device_info(i915)->page_size_mask =
I915_GTT_PAGE_SIZE_4K |
I915_GTT_PAGE_SIZE_64K |
-   I915_GTT_PAGE_SIZE_2M;
+   I915_GTT_PAGE_SIZE_2M |
+   I915_GTT_PAGE_SIZE_1G;
 
spin_lock_init(&i915->mm.object_stat_lock);
mock_uncore_init(i915);
-- 
2.9.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 12/17] drm/i915: support inserting 2M pages into the 48b PPGTT

[Matthew Auld]

To enable 2M pages we set the PS bit of PDE, aka PDE[7] to indicate a 2M
page and not a page-table.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 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 874854e77247..3dadb501daa6 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -854,6 +854,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(&ppgtt->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,
@@ -1028,6 +1078,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 04d37c62c3ef..840d08be8fa3 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -150,6 +150,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.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 09/17] drm/i915: enable IPS bit for 64K pages

[Matthew Auld]

Before we can enable 64K pages through the IPS bit, we must first enable
it through MMIO, otherwise the page-walker will simply ignore it.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem.c | 11 +++
 drivers/gpu/drm/i915/i915_reg.h |  3 +++
 2 files changed, 14 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index e4ee54f0f55f..fa133aa61261 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4717,6 +4717,17 @@ int i915_gem_init_hw(struct drm_i915_private *dev_priv)
}
}
 
+   /* To support 64K PTE's we need to first enable the use of the
+* Intermediate-Page-Size(IPS) bit of the PDE field via some magical
+* mmio, otherwise the page-walker will simply ignore the IPS bit. This
+* shouldn't be needed after GEN10.
+*/
+   if (HAS_PAGE_SIZE(dev_priv, I915_GTT_PAGE_SIZE_64K) &&
+   INTEL_GEN(dev_priv) <= 10)
+   I915_WRITE(GEN8_GAMW_ECO_DEV_RW_IA,
+  I915_READ(GEN8_GAMW_ECO_DEV_RW_IA) |
+  GAMW_ECO_ENABLE_64K_IPS_FIELD);
+
i915_gem_init_swizzling(dev_priv);
 
/*
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index ee144ec57935..7416e7d7d472 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -1993,6 +1993,9 @@ enum skl_disp_power_wells {
 #define GEN9_GAMT_ECO_REG_RW_IA _MMIO(0x4ab0)
 #define   GAMT_ECO_ENABLE_IN_PLACE_DECOMPRESS  (1<<18)
 
+#define GEN8_GAMW_ECO_DEV_RW_IA _MMIO(0x4080)
+#define   GAMW_ECO_ENABLE_64K_IPS_FIELD 0xF
+
 #define GAMT_CHKN_BIT_REG  _MMIO(0x4ab8)
 #define   GAMT_CHKN_DISABLE_DYNAMIC_CREDIT_SHARING (1<<28)
 
-- 
2.9.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 03/17] drm/i915: align the vma start to the gtt page size

[Matthew Auld]

When inserting into a 48bit PPGTT we need to align the vma start address
to the required page size boundary. The size will already be aligned so
no padding is needed.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_vma.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 1aba47024656..53f6c94b2ee6 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -471,6 +471,14 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
if (ret)
return ret;
 
+   if (i915_vm_is_48bit(vma->vm) &&
+   obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
+   unsigned int page_alignment = obj->gtt_page_size;
+
+   alignment = max_t(typeof(alignment), alignment, page_alignment);
+   GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
+   }
+
if (flags & PIN_OFFSET_FIXED) {
u64 offset = flags & PIN_OFFSET_MASK;
if (!IS_ALIGNED(offset, alignment) ||
-- 
2.9.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 13/17] drm/i915: support inserting 1G pages into the 48b PPGTT

[Matthew Auld]

To enable 1G pages we set the PS bit in the PDPE, aka PDPE[7] to
indicate a 1G page, and not a PD.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 47 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 ++
 2 files changed, 49 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3dadb501daa6..e81c78ffbea5 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -854,6 +854,50 @@ 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(&ppgtt->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);
+
+   mark_tlbs_dirty(ppgtt);
+
+   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,
@@ -1081,6 +1125,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 840d08be8fa3..1517cfdbd5ce 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -152,6 +152,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.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 10/17] drm/i915: support inserting 64K pages into the 48b PPGTT

[Matthew Auld]

If we set the IPS bit, aka PDE[11] then every 16th entry should be used
to index, the HW makes no assumptions for any other PTEs.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 74 +
 drivers/gpu/drm/i915/i915_gem_gtt.h |  2 +
 2 files changed, 76 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 3be3cbfb6d28..874854e77247 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -854,6 +854,77 @@ 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;
+
+   /* Currently 64K objects should be aligned to 2M to prevent mixing 4K
+* and 64K pte's in the same page-table.
+*/
+   GEM_BUG_ON(idx->pte);
+   GEM_BUG_ON(idx->pdpe >= i915_pdpes_per_pdp(&ppgtt->base));
+   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;
+
+   if (++idx->pdpe == GEN8_PML4ES_PER_PML4) {
+   idx->pdpe = 0;
+   ret = true;
+   break;
+   }
+
+   GEM_BUG_ON(idx->pdpe >= 
i915_pdpes_per_pdp(&ppgtt->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);
+
+   mark_tlbs_dirty(ppgtt);
+
+   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,
@@ -954,6 +1025,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 5a2a3907d266..04d37c62c3ef 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -149,6 +149,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.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 04/17] drm/i915: align 64K objects to 2M

[Matthew Auld]

We can't mix 64K and 4K pte's in the same page-table, so for now we
align 64K objects to 2M to avoid any potential mixing. This is
potentially wasteful but in reality shouldn't be too bad since this only
applies to the virtual address space of a 48b PPGTT.

Suggested-by: Chris Wilson 
Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_vma.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
index 53f6c94b2ee6..d2e8edd351cf 100644
--- a/drivers/gpu/drm/i915/i915_vma.c
+++ b/drivers/gpu/drm/i915/i915_vma.c
@@ -475,6 +475,15 @@ i915_vma_insert(struct i915_vma *vma, u64 size, u64 
alignment, u64 flags)
obj->gtt_page_size > I915_GTT_PAGE_SIZE) {
unsigned int page_alignment = obj->gtt_page_size;
 
+   /* We can't mix 64K and 4K pte's in the same page-table (2M
+* block), and so to avoid the ugliness and complexity of
+* coloring we opt for just aligning 64K objects to 2M.
+*/
+   if (page_alignment == I915_GTT_PAGE_SIZE_64K) {
+   page_alignment = I915_GTT_PAGE_SIZE_2M;
+   size = roundup(size, page_alignment);
+   }
+
alignment = max_t(typeof(alignment), alignment, page_alignment);
GEM_BUG_ON(!IS_ALIGNED(vma->size, obj->gtt_page_size));
}
-- 
2.9.4

___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 08/17] drm/i915: pass gtt page size to insert_entries

[Matthew Auld]

Expose a page size parameter for insert_entries, this is only relevant
for inserting into the 4lvl ppgtt where we pass the gtt_page_size of the
object.

Signed-off-by: Matthew Auld 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c   | 32 +++
 drivers/gpu/drm/i915/i915_gem_gtt.h   |  1 +
 drivers/gpu/drm/i915/selftests/i915_gem_gtt.c |  3 ++-
 drivers/gpu/drm/i915/selftests/mock_gtt.c |  1 +
 4 files changed, 32 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index bc3c63e92c16..3be3cbfb6d28 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -210,7 +210,8 @@ 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;
 }
@@ -911,6 +912,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)
 {
@@ -929,6 +931,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)
 {
@@ -940,9 +943,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++], &iter,
-&idx, cache_level))
+   while (insert_entries(ppgtt, pdps[idx.pml4e++], &iter, &idx,
+ cache_level))
GEM_BUG_ON(idx.pml4e >= GEN8_PML4ES_PER_PML4);
 }
 
@@ -1625,6 +1643,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)
 {
@@ -2098,6 +2117,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)
 {
@@ -2145,6 +2165,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)
 {
@@ -2229,6 +2250,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)
 {
@@ -2265,7 +2287,7 @@ static int ggtt_bind_vma(struct i915_vma *vma,
 
intel_runtime