[Intel-gfx] [RFC PATCH] cgroup: cgroup_idr_lock can be static

2018-03-18 Thread kbuild test robot

Fixes: d6de4e7e9e60 ("cgroup: Allow registration and lookup of cgroup private 
data (v2)")
Signed-off-by: Fengguang Wu 
---
 cgroup.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/cgroup/cgroup.c b/kernel/cgroup/cgroup.c
index c778830..9af6086 100644
--- a/kernel/cgroup/cgroup.c
+++ b/kernel/cgroup/cgroup.c
@@ -91,7 +91,7 @@ static DEFINE_IDR(cgroup_priv_idr);
  * Protects cgroup_idr, css_idr, and cgroup_priv_idr so that IDs can be
  * released without grabbing cgroup_mutex.
  */
-DEFINE_SPINLOCK(cgroup_idr_lock);
+static DEFINE_SPINLOCK(cgroup_idr_lock);
 
 /*
  * Protects cgroup_file->kn for !self csses.  It synchronizes notifications
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH v4 1/8] cgroup: Allow registration and lookup of cgroup private data (v2)

2018-03-18 Thread kbuild test robot
Hi Matt,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on next-20180309]
[also build test WARNING on v4.16-rc6]
[cannot apply to v4.16-rc4 v4.16-rc3 v4.16-rc2]
[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/Matt-Roper/cgroup-private-data-and-DRM-i915-integration/20180319-071752
reproduce:
# apt-get install sparse
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

>> kernel/cgroup/cgroup.c:94:1: sparse: symbol 'cgroup_idr_lock' was not 
>> declared. Should it be static?
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in assignment 
>> (different address spaces) @@expected void **slot @@got void 
>> [noderef] **
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in assignment 
>> (different address spaces) @@expected void **slot @@got void 
>> [noderef] **
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in argument 1 
>> (different address spaces) @@expected void [noderef] **slot @@
>> got sn:4>**slot @@
   kernel/cgroup/cgroup.c:4655:17:expected void [noderef] **slot
   kernel/cgroup/cgroup.c:4655:17:got void **slot
>> kernel/cgroup/cgroup.c:4655:17: sparse: incorrect type in assignment 
>> (different address spaces) @@expected void **slot @@got void 
>> [noderef] **
   kernel/cgroup/cgroup.c:2648:20: sparse: context imbalance in 
'cgroup_procs_write_start' - wrong count at exit
   kernel/cgroup/cgroup.c:2704:9: sparse: context imbalance in 
'cgroup_procs_write_finish' - wrong count at exit
   kernel/cgroup/cgroup.c:2815:9: sparse: context imbalance in 
'cgroup_lock_and_drain_offline' - wrong count at exit
   kernel/cgroup/cgroup.c:4375:16: sparse: context imbalance in 
'cgroup_procs_write' - wrong count at exit
   kernel/cgroup/cgroup.c:4416:16: sparse: context imbalance in 
'cgroup_threads_write' - wrong count at exit

Please review and possibly fold the followup patch.

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH 33/36] drm/i915: Pull IPS into RPS

2018-03-18 Thread Sagar Arun Kamble



On 3/14/2018 3:07 PM, Chris Wilson wrote:

IPS was the precursor to RPS on Ironlake. It serves the same function,
and so should be pulled under the intel_gt_pm umbrella.

Signed-off-by: Chris Wilson 
Looks good except subject should be "Pull IPS into GT PM". It seems IPS 
and RPS merge is happening in next patch.

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_drv.h| 37 -
  drivers/gpu/drm/i915/i915_irq.c| 21 +-
  drivers/gpu/drm/i915/intel_gt_pm.c | 83 +-
  drivers/gpu/drm/i915/intel_pm.c|  8 ++--
  4 files changed, 80 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index cd92d0295b63..cfbcaa8556e0 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -784,23 +784,10 @@ struct intel_rps {
struct intel_rps_ei ei;
  };
  
-struct intel_rc6 {

-   u64 prev_hw_residency[4];
-   u64 cur_residency[4];
-};
-
-struct intel_gt_pm {
-   struct intel_rc6 rc6;
-   struct intel_rps rps;
-
-   u32 imr;
-   u32 ier;
-};
-
  /* defined intel_pm.c */
  extern spinlock_t mchdev_lock;
  
-struct intel_ilk_power_mgmt {

+struct intel_ips {
u8 cur_delay;
u8 min_delay;
u8 max_delay;
@@ -819,6 +806,24 @@ struct intel_ilk_power_mgmt {
int r_t;
  };
  
+struct intel_rc6 {

+   u64 prev_hw_residency[4];
+   u64 cur_residency[4];
+};
+
+struct intel_gt_pm {
+   struct intel_rc6 rc6;
+   struct intel_rps rps;
+   /*
+* ilk-only ips/rps state. Everything in here is protected by the
+* global mchdev_lock in intel_gt_pm.c
+*/
+   struct intel_ips ips;
+
+   u32 imr;
+   u32 ier;
+};
+
  struct drm_i915_private;
  struct i915_power_well;
  
@@ -1780,10 +1785,6 @@ struct drm_i915_private {
  
  	struct intel_gt_pm gt_pm;
  
-	/* ilk-only ips/rps state. Everything in here is protected by the global

-* mchdev_lock in intel_pm.c */
-   struct intel_ilk_power_mgmt ips;
-
struct i915_power_domains power_domains;
  
  	struct i915_psr psr;

diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index dfb711ca4d27..9a52692395f2 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -852,6 +852,7 @@ int intel_get_crtc_scanline(struct intel_crtc *crtc)
  
  static void ironlake_rps_change_irq_handler(struct drm_i915_private *dev_priv)

  {
+   struct intel_ips *ips = _priv->gt_pm.ips;
u32 busy_up, busy_down, max_avg, min_avg;
u8 new_delay;
  
@@ -859,7 +860,7 @@ static void ironlake_rps_change_irq_handler(struct drm_i915_private *dev_priv)
  
  	I915_WRITE16(MEMINTRSTS, I915_READ(MEMINTRSTS));
  
-	new_delay = dev_priv->ips.cur_delay;

+   new_delay = ips->cur_delay;
  
  	I915_WRITE16(MEMINTRSTS, MEMINT_EVAL_CHG);

busy_up = I915_READ(RCPREVBSYTUPAVG);
@@ -869,19 +870,19 @@ static void ironlake_rps_change_irq_handler(struct 
drm_i915_private *dev_priv)
  
  	/* Handle RCS change request from hw */

if (busy_up > max_avg) {
-   if (dev_priv->ips.cur_delay != dev_priv->ips.max_delay)
-   new_delay = dev_priv->ips.cur_delay - 1;
-   if (new_delay < dev_priv->ips.max_delay)
-   new_delay = dev_priv->ips.max_delay;
+   if (ips->cur_delay != ips->max_delay)
+   new_delay = ips->cur_delay - 1;
+   if (new_delay < ips->max_delay)
+   new_delay = ips->max_delay;
} else if (busy_down < min_avg) {
-   if (dev_priv->ips.cur_delay != dev_priv->ips.min_delay)
-   new_delay = dev_priv->ips.cur_delay + 1;
-   if (new_delay > dev_priv->ips.min_delay)
-   new_delay = dev_priv->ips.min_delay;
+   if (ips->cur_delay != ips->min_delay)
+   new_delay = ips->cur_delay + 1;
+   if (new_delay > ips->min_delay)
+   new_delay = ips->min_delay;
}
  
  	if (ironlake_set_drps(dev_priv, new_delay))

-   dev_priv->ips.cur_delay = new_delay;
+   ips->cur_delay = new_delay;
  
  	spin_unlock(_lock);
  
diff --git a/drivers/gpu/drm/i915/intel_gt_pm.c b/drivers/gpu/drm/i915/intel_gt_pm.c

index 18ab1b3a2945..def292cfd181 100644
--- a/drivers/gpu/drm/i915/intel_gt_pm.c
+++ b/drivers/gpu/drm/i915/intel_gt_pm.c
@@ -65,6 +65,7 @@ bool ironlake_set_drps(struct drm_i915_private *dev_priv, u8 
val)
  
  static void ironlake_enable_drps(struct drm_i915_private *dev_priv)

  {
+   struct intel_ips *ips = _priv->gt_pm.ips;
u32 rgvmodectl;
u8 fmax, fmin, fstart, vstart;
  
@@ -95,12 +96,12 @@ static void ironlake_enable_drps(struct drm_i915_private *dev_priv)

vstart = (I915_READ(PXVFREQ(fstart)) & 

[Intel-gfx] linux-next: manual merge of the drm-misc tree with the drm tree

2018-03-18 Thread Stephen Rothwell
Hi all,

Today's linux-next merge of the drm-misc tree got a conflict in:

  drivers/gpu/drm/i915/intel_color.c

between commit:

  db61d160b3ed ("drm/i915: Remove the pointless 1:1 matrix copy")

from the drm tree and commit:

  d5517a39dce4 ("drm/i915: Remove the blob->data casts")

from the drm-misc tree.

I fixed it up (see below) and can carry the fix as necessary. This
is now fixed as far as linux-next is concerned, but any non trivial
conflicts should be mentioned to your upstream maintainer when your tree
is submitted for merging.  You may also want to consider cooperating
with the maintainer of the conflicting tree to minimise any particularly
complex conflicts.

-- 
Cheers,
Stephen Rothwell

diff --cc drivers/gpu/drm/i915/intel_color.c
index 89ab0f70aa22,768f1c26080e..
--- a/drivers/gpu/drm/i915/intel_color.c
+++ b/drivers/gpu/drm/i915/intel_color.c
@@@ -140,28 -140,20 +140,27 @@@ static void ilk_load_csc_matrix(struct 
int i, pipe = intel_crtc->pipe;
uint16_t coeffs[9] = { 0, };
struct intel_crtc_state *intel_crtc_state = 
to_intel_crtc_state(crtc_state);
 +  bool limited_color_range = false;
 +
 +  /*
 +   * FIXME if there's a gamma LUT after the CSC, we should
 +   * do the range compression using the gamma LUT instead.
 +   */
 +  if (INTEL_GEN(dev_priv) >= 8 || IS_HASWELL(dev_priv))
 +  limited_color_range = intel_crtc_state->limited_color_range;
  
if (intel_crtc_state->ycbcr420) {
 -  i9xx_load_ycbcr_conversion_matrix(intel_crtc);
 +  ilk_load_ycbcr_conversion_matrix(intel_crtc);
return;
} else if (crtc_state->ctm) {
-   struct drm_color_ctm *ctm =
-   (struct drm_color_ctm *)crtc_state->ctm->data;
+   struct drm_color_ctm *ctm = crtc_state->ctm->data;
 -  uint64_t input[9] = { 0, };
 +  const u64 *input;
 +  u64 temp[9];
  
 -  if (intel_crtc_state->limited_color_range) {
 -  ctm_mult_by_limited(input, ctm->matrix);
 -  } else {
 -  for (i = 0; i < ARRAY_SIZE(input); i++)
 -  input[i] = ctm->matrix[i];
 -  }
 +  if (limited_color_range)
 +  input = ctm_mult_by_limited(temp, ctm->matrix);
 +  else
 +  input = ctm->matrix;
  
/*
 * Convert fixed point S31.32 input to format supported by the


pgpVBrcIZtUL5.pgp
Description: OpenPGP digital signature
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx


Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

2018-03-18 Thread kbuild test robot
Hi Matt,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[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/matthew-s-atwood-intel-com/drm-i915-make-edp-optimize-config/20180319-065307
config: i386-randconfig-a1-201811 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.4-2) 4.9.4
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_compute_config':
>> drivers/gpu/drm/i915/intel_dp.c:1729:6: error: 'dpcd' undeclared (first use 
>> in this function)
  if(dpcd[DP_DPCD_REV] < DPCD_REV_14){
 ^
   drivers/gpu/drm/i915/intel_dp.c:1729:6: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/gpu/drm/i915/intel_dp.c:1729:26: error: 'DPCD_REV_14' undeclared 
>> (first use in this function)
  if(dpcd[DP_DPCD_REV] < DPCD_REV_14){
 ^

vim +/dpcd +1729 drivers/gpu/drm/i915/intel_dp.c

  1607  
  1608  bool
  1609  intel_dp_compute_config(struct intel_encoder *encoder,
  1610  struct intel_crtc_state *pipe_config,
  1611  struct drm_connector_state *conn_state)
  1612  {
  1613  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
  1614  struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
  1615  struct intel_dp *intel_dp = enc_to_intel_dp(>base);
  1616  enum port port = encoder->port;
  1617  struct intel_crtc *intel_crtc = 
to_intel_crtc(pipe_config->base.crtc);
  1618  struct intel_connector *intel_connector = 
intel_dp->attached_connector;
  1619  struct intel_digital_connector_state *intel_conn_state =
  1620  to_intel_digital_connector_state(conn_state);
  1621  int lane_count, clock;
  1622  int min_lane_count = 1;
  1623  int max_lane_count = intel_dp_max_lane_count(intel_dp);
  1624  /* Conveniently, the link BW constants become indices with a 
shift...*/
  1625  int min_clock = 0;
  1626  int max_clock;
  1627  int bpp, mode_rate;
  1628  int link_avail, link_clock;
  1629  int common_len;
  1630  uint8_t link_bw, rate_select;
  1631  bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
  1632 DP_DPCD_QUIRK_LIMITED_M_N);
  1633  
  1634  common_len = intel_dp_common_len_rate_limit(intel_dp,
  1635  
intel_dp->max_link_rate);
  1636  
  1637  /* No common link rates between source and sink */
  1638  WARN_ON(common_len <= 0);
  1639  
  1640  max_clock = common_len - 1;
  1641  
  1642  if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != 
PORT_A)
  1643  pipe_config->has_pch_encoder = true;
  1644  
  1645  pipe_config->has_drrs = false;
  1646  if (IS_G4X(dev_priv) || port == PORT_A)
  1647  pipe_config->has_audio = false;
  1648  else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
  1649  pipe_config->has_audio = intel_dp->has_audio;
  1650  else
  1651  pipe_config->has_audio = intel_conn_state->force_audio 
== HDMI_AUDIO_ON;
  1652  
  1653  if (intel_dp_is_edp(intel_dp) && 
intel_connector->panel.fixed_mode) {
  1654  struct drm_display_mode *panel_mode =
  1655  intel_connector->panel.alt_fixed_mode;
  1656  struct drm_display_mode *req_mode = 
_config->base.mode;
  1657  
  1658  if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
  1659  panel_mode = intel_connector->panel.fixed_mode;
  1660  
  1661  drm_mode_debug_printmodeline(panel_mode);
  1662  
  1663  intel_fixed_panel_mode(panel_mode, adjusted_mode);
  1664  
  1665  if (INTEL_GEN(dev_priv) >= 9) {
  1666  int ret;
  1667  ret = skl_update_scaler_crtc(pipe_config);
  1668  if (ret)
  1669  return ret;
  1670  }
  1671  
  1672  if (HAS_GMCH_DISPLAY(dev_priv))
  1673  intel_gmch_panel_fitting(intel_crtc, 
pipe_config,
  1674   
conn_state->scaling_mode);
  1675  else
  1676  intel_pch_panel_fitting(intel_crtc, pipe_config,
  1677  
conn_state->scaling_mode);
  1678  }
  1679  
  1680  if ((IS_VALLEYVIEW(dev_priv) 

Re: [Intel-gfx] [PATCH] drm/i915: make edp optimize config

2018-03-18 Thread kbuild test robot
Hi Matt,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on v4.16-rc4]
[also build test ERROR on next-20180316]
[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/matthew-s-atwood-intel-com/drm-i915-make-edp-optimize-config/20180319-065307
config: x86_64-randconfig-x002-201811 (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_dp.c: In function 'intel_dp_compute_config':
>> drivers/gpu/drm/i915/intel_dp.c:1729:6: error: 'dpcd' undeclared (first use 
>> in this function); did you mean 'dpll'?
  if(dpcd[DP_DPCD_REV] < DPCD_REV_14){
 ^~~~
 dpll
   drivers/gpu/drm/i915/intel_dp.c:1729:6: note: each undeclared identifier is 
reported only once for each function it appears in
>> drivers/gpu/drm/i915/intel_dp.c:1729:26: error: 'DPCD_REV_14' undeclared 
>> (first use in this function); did you mean 'BPF_REG_10'?
  if(dpcd[DP_DPCD_REV] < DPCD_REV_14){
 ^~~
 BPF_REG_10

vim +1729 drivers/gpu/drm/i915/intel_dp.c

  1607  
  1608  bool
  1609  intel_dp_compute_config(struct intel_encoder *encoder,
  1610  struct intel_crtc_state *pipe_config,
  1611  struct drm_connector_state *conn_state)
  1612  {
  1613  struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
  1614  struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
  1615  struct intel_dp *intel_dp = enc_to_intel_dp(>base);
  1616  enum port port = encoder->port;
  1617  struct intel_crtc *intel_crtc = 
to_intel_crtc(pipe_config->base.crtc);
  1618  struct intel_connector *intel_connector = 
intel_dp->attached_connector;
  1619  struct intel_digital_connector_state *intel_conn_state =
  1620  to_intel_digital_connector_state(conn_state);
  1621  int lane_count, clock;
  1622  int min_lane_count = 1;
  1623  int max_lane_count = intel_dp_max_lane_count(intel_dp);
  1624  /* Conveniently, the link BW constants become indices with a 
shift...*/
  1625  int min_clock = 0;
  1626  int max_clock;
  1627  int bpp, mode_rate;
  1628  int link_avail, link_clock;
  1629  int common_len;
  1630  uint8_t link_bw, rate_select;
  1631  bool reduce_m_n = drm_dp_has_quirk(_dp->desc,
  1632 DP_DPCD_QUIRK_LIMITED_M_N);
  1633  
  1634  common_len = intel_dp_common_len_rate_limit(intel_dp,
  1635  
intel_dp->max_link_rate);
  1636  
  1637  /* No common link rates between source and sink */
  1638  WARN_ON(common_len <= 0);
  1639  
  1640  max_clock = common_len - 1;
  1641  
  1642  if (HAS_PCH_SPLIT(dev_priv) && !HAS_DDI(dev_priv) && port != 
PORT_A)
  1643  pipe_config->has_pch_encoder = true;
  1644  
  1645  pipe_config->has_drrs = false;
  1646  if (IS_G4X(dev_priv) || port == PORT_A)
  1647  pipe_config->has_audio = false;
  1648  else if (intel_conn_state->force_audio == HDMI_AUDIO_AUTO)
  1649  pipe_config->has_audio = intel_dp->has_audio;
  1650  else
  1651  pipe_config->has_audio = intel_conn_state->force_audio 
== HDMI_AUDIO_ON;
  1652  
  1653  if (intel_dp_is_edp(intel_dp) && 
intel_connector->panel.fixed_mode) {
  1654  struct drm_display_mode *panel_mode =
  1655  intel_connector->panel.alt_fixed_mode;
  1656  struct drm_display_mode *req_mode = 
_config->base.mode;
  1657  
  1658  if (!intel_edp_compare_alt_mode(req_mode, panel_mode))
  1659  panel_mode = intel_connector->panel.fixed_mode;
  1660  
  1661  drm_mode_debug_printmodeline(panel_mode);
  1662  
  1663  intel_fixed_panel_mode(panel_mode, adjusted_mode);
  1664  
  1665  if (INTEL_GEN(dev_priv) >= 9) {
  1666  int ret;
  1667  ret = skl_update_scaler_crtc(pipe_config);
  1668  if (ret)
  1669  return ret;
  1670  }
  1671  
  1672  if (HAS_GMCH_DISPLAY(dev_priv))
  1673  intel_gmch_panel_fitting(intel_crtc, 
pipe_config,
  1674   
conn_state->scaling_mode);
  1675  else
  1676  intel_pch_panel_fitting(intel_crtc, pipe_config,
  1677  

Re: [Intel-gfx] [PATCH 0/3] PSR lag fixes

2018-03-18 Thread Hans de Goede

Hi,

On 16-03-18 01:16, Rodrigo Vivi wrote:

On Wed, Mar 14, 2018 at 04:35:55PM -0700, Pandiyan, Dhinakaran wrote:




On Wed, 2018-03-14 at 23:09 +0100, Hans de Goede wrote:

Hi,

On 14-03-18 21:49, Pandiyan, Dhinakaran wrote:


On Wed, 2018-02-14 at 09:25 +0100, Hans de Goede wrote:

Hi,

On 12-02-18 18:42, Pandiyan, Dhinakaran wrote:

On Mon, 2018-02-12 at 09:45 +0100, Hans de Goede wrote:

Hi,

On 12-02-18 07:08, Dhinakaran Pandiyan wrote:

PSR currently when enabled results in semi-permanent freezes or noticeable
cursor lags.

https://patchwork.freedesktop.org/series/37598/ will fix long freezes due
to frame counter resets.

This series has three more fixes -
Patch 1 eliminates PSR exit for flips and makes us rely on the HW to do it.
Patch 2 fixes cusor move lag by relying on HW to exit PSR.
Patch 3 fixes temporary freeze seen with fbdev.

With both the series applied, PSR on my SKL ThinkPad feels pretty good.


Thank you for your great work on this.

Are there any more PSR fixes in the pipeline?


Yeah, there are a few more fixes that I hope will appear on the list in
the next two weeks or so.


Ok, can you send a mail when you're done (in sofar any software is ever
"done") and you would like me to ask all people who have been kind enough
to test PSR to retest ?



Hi Hans,

Thanks for your patience and help. I believe the current drm-tip is in a
decent shape to retest PSR. Booting with i915.enable_psr = 1 is still
needed. The fixes have been mostly developed/tested on gen-9 hardware
but they apply to other platforms too.


Cool, thank you. Current drm-tip will all be merged into 4.17-rc1, right?


Unfortunately no. All changes current in dinq and not on drm-intel-next are only
going to 4.18-rc1.


Bummer.

Pandiyan, can you make a list of commits or patch-work series links
which contain the PSR related fixes? Then I will try to backport those
to 4.16 (when I find time for this).

Regards,

Hans









Rodrigo,

Can you help me answer that?




Then I think I will just wait for that, most distros already provide rc builds
for testing, so that way it will be easy for people to test.

Regards,

Hans






-DK


If not I think I should do
a custom Fedora kernel build based on 4.15 + recent fixes and ask all my
testers to retest with that.

I do have some questions before I do this:

1) I believe that only testers with skylake (normal or LP) or newer should
re-test, correct?


These fixes do apply for HSW/BDW, so essentially all the big cores
supporting PSR. But, HSW/BDW need fixes for AUX channel-PSR interaction
also. I haven't looked into CHV/VLV.



2) I know there are 2 series (including this one), can someone provide a link
to the latest patchwork version of those 2 series, or even better a git
branch with 4.15 + those patches? Any patches I'm missing if I pick up these
2 series?


https://patchwork.freedesktop.org/series/37598/
https://patchwork.freedesktop.org/series/38067/



3) I'm thinking 4.15 atm, but I could also do a 4.16-rc1 test kernel instead
if that would be better, would that be better ?


I can't think of any diff that would affect PSR, but the latest is
better I suppose.


Ok.

Regards,

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

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

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


Re: [Intel-gfx] [PATCH 32/36] drm/i915: Rename rps min/max frequencies

2018-03-18 Thread Sagar Arun Kamble



On 3/14/2018 3:07 PM, Chris Wilson wrote:

In preparation for more layers of limits, rename the existing limits to
hw and user.

Signed-off-by: Chris Wilson 

Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_debugfs.c |  34 
  drivers/gpu/drm/i915/i915_drv.h |  21 +++--
  drivers/gpu/drm/i915/i915_pmu.c |   4 +-
  drivers/gpu/drm/i915/i915_sysfs.c   |  23 +++---
  drivers/gpu/drm/i915/intel_gt_pm.c  | 149 ++--
  5 files changed, 119 insertions(+), 112 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index cfecc2509224..ccb01244e616 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1097,13 +1097,13 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
   intel_gpu_freq(dev_priv, (freq_sts >> 8) & 0xff));
  
  		seq_printf(m, "current GPU freq: %d MHz\n",

-  intel_gpu_freq(dev_priv, rps->cur_freq));
+  intel_gpu_freq(dev_priv, rps->freq));
  
  		seq_printf(m, "max GPU freq: %d MHz\n",

-  intel_gpu_freq(dev_priv, rps->max_freq));
+  intel_gpu_freq(dev_priv, rps->max_freq_hw));
  
  		seq_printf(m, "min GPU freq: %d MHz\n",

-  intel_gpu_freq(dev_priv, rps->min_freq));
+  intel_gpu_freq(dev_priv, rps->min_freq_hw));
  
  		seq_printf(m, "idle GPU freq: %d MHz\n",

   intel_gpu_freq(dev_priv, rps->idle_freq));
@@ -1235,19 +1235,19 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
seq_printf(m, "Max non-overclocked (RP0) frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, max_freq));
seq_printf(m, "Max overclocked frequency: %dMHz\n",
-  intel_gpu_freq(dev_priv, rps->max_freq));
+  intel_gpu_freq(dev_priv, rps->max_freq_hw));
  
  		seq_printf(m, "Current freq: %d MHz\n",

-  intel_gpu_freq(dev_priv, rps->cur_freq));
+  intel_gpu_freq(dev_priv, rps->freq));
seq_printf(m, "Actual freq: %d MHz\n", cagf);
seq_printf(m, "Idle freq: %d MHz\n",
   intel_gpu_freq(dev_priv, rps->idle_freq));
seq_printf(m, "Min freq: %d MHz\n",
-  intel_gpu_freq(dev_priv, rps->min_freq));
+  intel_gpu_freq(dev_priv, rps->min_freq_hw));
seq_printf(m, "Boost freq: %d MHz\n",
   intel_gpu_freq(dev_priv, rps->boost_freq));
seq_printf(m, "Max freq: %d MHz\n",
-  intel_gpu_freq(dev_priv, rps->max_freq));
+  intel_gpu_freq(dev_priv, rps->max_freq_hw));
seq_printf(m,
   "efficient (RPe) frequency: %d MHz\n",
   intel_gpu_freq(dev_priv, rps->efficient_freq));
@@ -1802,8 +1802,8 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
if (!HAS_LLC(dev_priv))
return -ENODEV;
  
-	min_gpu_freq = rps->min_freq;

-   max_gpu_freq = rps->max_freq;
+   min_gpu_freq = rps->min_freq_hw;
+   max_gpu_freq = rps->max_freq_hw;
if (IS_GEN9_BC(dev_priv) || IS_CANNONLAKE(dev_priv)) {
/* Convert GT frequency to 50 HZ units */
min_gpu_freq /= GEN9_FREQ_SCALER;
@@ -2197,13 +2197,15 @@ static int i915_rps_boost_info(struct seq_file *m, void 
*data)
seq_printf(m, "CPU waiting? %d\n", count_irq_waiters(dev_priv));
seq_printf(m, "Boosts outstanding? %d\n",
   atomic_read(>num_waiters));
-   seq_printf(m, "Frequency requested %d\n",
-  intel_gpu_freq(dev_priv, rps->cur_freq));
-   seq_printf(m, "  min hard:%d, soft:%d; max soft:%d, hard:%d\n",
-  intel_gpu_freq(dev_priv, rps->min_freq),
-  intel_gpu_freq(dev_priv, rps->min_freq_softlimit),
-  intel_gpu_freq(dev_priv, rps->max_freq_softlimit),
-  intel_gpu_freq(dev_priv, rps->max_freq));
+   seq_printf(m, "Frequency requested %d [%d, %d]\n",
+  intel_gpu_freq(dev_priv, rps->freq),
+  intel_gpu_freq(dev_priv, rps->min),
+  intel_gpu_freq(dev_priv, rps->max));
+   seq_printf(m, "  min hard:%d, user:%d; max user:%d, hard:%d\n",
+  intel_gpu_freq(dev_priv, rps->min_freq_hw),
+  intel_gpu_freq(dev_priv, rps->min_freq_user),
+  intel_gpu_freq(dev_priv, rps->max_freq_user),
+  intel_gpu_freq(dev_priv, rps->max_freq_hw));
seq_printf(m, "  idle:%d, efficient:%d, boost:%d\n",
   intel_gpu_freq(dev_priv, 

Re: [Intel-gfx] [PATCH 31/36] drm/i915: Don't fiddle with rps/rc6 across GPU reset

2018-03-18 Thread Sagar Arun Kamble



On 3/14/2018 3:07 PM, Chris Wilson wrote:

Resetting the GPU doesn't affect the RPS/RC6 state, so we can stop
forcibly reloading the registers.

Signed-off-by: Chris Wilson 
Cc: Ville Syrjälä 

Changes look good to me.
Reviewed-by: Sagar Arun Kamble 

---
  drivers/gpu/drm/i915/i915_gem.c | 4 
  1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 9f5b3a2a8b61..9443464cebbb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -3162,10 +3162,6 @@ void i915_gem_reset(struct drm_i915_private *dev_priv)
}
  
  	i915_gem_restore_fences(dev_priv);

-
-   intel_gt_pm_enable_rc6(dev_priv);
-   if (dev_priv->gt.awake)
-   intel_gt_pm_busy(dev_priv);
  }
  
  void i915_gem_reset_finish_engine(struct intel_engine_cs *engine)


--
Thanks,
Sagar

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


Re: [Intel-gfx] [PATCH] drm/i915: prefer vma->size for vma iomap

2018-03-18 Thread Chris Wilson
Quoting Matthew Auld (2018-03-17 17:42:07)
> It makes more sense to use vma->size, since this determines the number
> of entries we inserted into the vm, while the vma->node.size is the size
> of the vm window we reserved, which may also include padding. At the
> very least this keeps things consistent with the GTT routines.

"Being consistent with the other GTT routines"? Name them, we're talking
about how many pages does the caller expect to be able to access, is the
padding (that they established for the vma) part of the iomap?

So the padding exists to ensure that random tiling beneath the pointer
maps to real pages, but it was established during vma pinning by the
caller.  Being the kernel maybe they do want to access those pages, but
equally what can they do? It's just one page that they could access
directly if so required. I don't see a reason and can't think of an
instance where we do.

> Signed-off-by: Matthew Auld 
> Cc: Chris Wilson 
> ---
>  drivers/gpu/drm/i915/i915_gem_shrinker.c | 2 +-
>  drivers/gpu/drm/i915/i915_vma.c  | 2 +-
>  drivers/gpu/drm/i915/intel_fbdev.c   | 4 ++--
>  3 files changed, 4 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c 
> b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> index 5757fb7c4b5a..e71e999169cc 100644
> --- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
> +++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
> @@ -481,7 +481,7 @@ i915_gem_shrinker_vmap(struct notifier_block *nb, 
> unsigned long event, void *ptr
> /* We also want to clear any cached iomaps as they wrap vmap */
> list_for_each_entry_safe(vma, next,
>  >ggtt.base.inactive_list, vm_link) {
> -   unsigned long count = vma->node.size >> PAGE_SHIFT;
> +   unsigned long count = vma->size >> PAGE_SHIFT;
> if (vma->iomap && i915_vma_unbind(vma) == 0)
> freed_pages += count;
> }

Ok, as the size the vmap() is obj->base.size.

> diff --git a/drivers/gpu/drm/i915/i915_vma.c b/drivers/gpu/drm/i915/i915_vma.c
> index 4bda3bd29bf5..00fb1e5ea495 100644
> --- a/drivers/gpu/drm/i915/i915_vma.c
> +++ b/drivers/gpu/drm/i915/i915_vma.c
> @@ -312,7 +312,7 @@ void __iomem *i915_vma_pin_iomap(struct i915_vma *vma)
> if (ptr == NULL) {
> ptr = io_mapping_map_wc(_vm_to_ggtt(vma->vm)->iomap,
> vma->node.start,
> -   vma->node.size);
> +   vma->size);

Debatable. Even though I can't think of a reason why, I don't see if we
need to be overly restrictive either.

> if (ptr == NULL) {
> err = -ENOMEM;
> goto err;
> diff --git a/drivers/gpu/drm/i915/intel_fbdev.c 
> b/drivers/gpu/drm/i915/intel_fbdev.c
> index 65a3313723c9..424800c16dec 100644
> --- a/drivers/gpu/drm/i915/intel_fbdev.c
> +++ b/drivers/gpu/drm/i915/intel_fbdev.c
> @@ -244,7 +244,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> info->apertures->ranges[0].size = ggtt->mappable_end;
>  
> info->fix.smem_start = dev->mode_config.fb_base + 
> i915_ggtt_offset(vma);
> -   info->fix.smem_len = vma->node.size;
> +   info->fix.smem_len = vma->size;

I think this has to be node.size for the overlaps to be checked.

> vaddr = i915_vma_pin_iomap(vma);
> if (IS_ERR(vaddr)) {
> @@ -253,7 +253,7 @@ static int intelfb_create(struct drm_fb_helper *helper,
> goto out_unpin;
> }
> info->screen_base = vaddr;
> -   info->screen_size = vma->node.size;
> +   info->screen_size = vma->size;

I don't what this is used for; vma->size is probably correct.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx