date:20151027

Kabylake is a Intel® Processor containing Intel® HD Graphics
following Skylake.

It is Gen9p5, so it inherits everything from Skylake.

First version adding PCI IDs was also defining the platform
with is_skylake=1. But this was bringing even more confusion
to the platform definitions.

So let's start by adding the platform separated from Skylake
but reusing most of all features, functions etc. Later we
rebase the PCI-ID patch so we don't replace what original
Author did there.

Few IS_SKYLAKEs if statements are not being covered by this patch
on purpose:
   - Workarounds: Kabylake is derivated from Skylake H0 so no
  W/As apply here. Also Jani already reworked
  the REVID in a way that they will be only
  applied to the right platform and stepping
  without any extra work required here.
   - GuC: A following patch removes Kabylake support with an
  explanation: No firmware available yet.
   - DMC/CSR: Done in a separated patch since we need to be carefull
  and load the version for revision 7 since
  Kabylake is Skylake H0.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 16 +++-
 drivers/gpu/drm/i915/i915_dma.c |  3 ++-
 drivers/gpu/drm/i915/i915_drv.c | 44 -
 drivers/gpu/drm/i915/i915_drv.h |  6 +++--
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  3 ++-
 drivers/gpu/drm/i915/intel_audio.c  |  9 ---
 drivers/gpu/drm/i915/intel_ddi.c| 16 ++--
 drivers/gpu/drm/i915/intel_display.c| 12 -
 drivers/gpu/drm/i915/intel_dp.c |  6 ++---
 drivers/gpu/drm/i915/intel_fbc.c|  3 ++-
 drivers/gpu/drm/i915/intel_mocs.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c | 11 +
 drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +-
 13 files changed, 88 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index eca94d0..5125aa5 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1252,18 +1252,21 @@ static int i915_frequency_info(struct seq_file *m, void 
*unused)
 
max_freq = (IS_BROXTON(dev) ? rp_state_cap >> 0 :
rp_state_cap >> 16) & 0xff;
-   max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
+   max_freq *= (IS_SKYLAKE(dev) || IS_KABYLAKE(dev) ?
+GEN9_FREQ_SCALER : 1);
seq_printf(m, "Lowest (RPN) frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, max_freq));
 
max_freq = (rp_state_cap & 0xff00) >> 8;
-   max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
+   max_freq *= (IS_SKYLAKE(dev) || IS_KABYLAKE(dev) ?
+GEN9_FREQ_SCALER : 1);
seq_printf(m, "Nominal (RP1) frequency: %dMHz\n",
   intel_gpu_freq(dev_priv, max_freq));
 
max_freq = (IS_BROXTON(dev) ? rp_state_cap >> 16 :
rp_state_cap >> 0) & 0xff;
-   max_freq *= (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1);
+   max_freq *= (IS_SKYLAKE(dev) || IS_KABYLAKE(dev) ?
+GEN9_FREQ_SCALER : 1);
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",
@@ -1801,7 +1804,7 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
if (ret)
goto out;
 
-   if (IS_SKYLAKE(dev)) {
+   if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev)) {
/* Convert GT frequency to 50 HZ units */
min_gpu_freq =
dev_priv->rps.min_freq_softlimit / GEN9_FREQ_SCALER;
@@ -1821,7 +1824,8 @@ static int i915_ring_freq_table(struct seq_file *m, void 
*unused)
   &ia_freq);
seq_printf(m, "%d\t\t%d\t\t\t\t%d\n",
   intel_gpu_freq(dev_priv, (gpu_freq *
-   (IS_SKYLAKE(dev) ? GEN9_FREQ_SCALER : 1))),
+   (IS_SKYLAKE(dev) || IS_KABYLAKE(dev) ?
+GEN9_FREQ_SCALER : 1))),
   ((ia_freq >> 0) & 0xff) * 100,
   ((ia_freq >> 8) & 0xff) * 100);
}
@@ -5029,7 +5033,7 @@ static void gen9_sseu_device_status(struct drm_device 
*dev,
 
stat->slice_total++;
 
-   if (IS_SKYLAKE(dev))
+   if (IS_SKYLAKE(dev) || IS_KABYLAKE(dev))
ss_cnt = INTEL_INFO(dev)->subslice_per_slice;
 
for (ss = 0; ss < ss_max; ss++) {
diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
index 2336af9..ddd1d46 100644
---

[Intel-gfx] [PATCH 5/6] drm/i915/kbl: Use propper ddi buffer translation table for Kabylake ULT and ULX.

Let's introduce ULT and ULX Kabylake definitions and start
using it for a propper DDI buffer translation.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.h  |  8 
 drivers/gpu/drm/i915/intel_ddi.c | 10 +-
 2 files changed, 13 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 3982d1a..e0b84c8 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2506,6 +2506,14 @@ struct drm_i915_cmd_table {
 #define IS_SKL_ULX(dev)(INTEL_DEVID(dev) == 0x190E || \
 INTEL_DEVID(dev) == 0x1915 || \
 INTEL_DEVID(dev) == 0x191E)
+#define IS_KBL_ULT(dev)(INTEL_DEVID(dev) == 0x5906 || \
+INTEL_DEVID(dev) == 0x5913 || \
+INTEL_DEVID(dev) == 0x5916 || \
+INTEL_DEVID(dev) == 0x5921 || \
+INTEL_DEVID(dev) == 0x5926)
+#define IS_KBL_ULX(dev)(INTEL_DEVID(dev) == 0x590E || \
+INTEL_DEVID(dev) == 0x5915 || \
+INTEL_DEVID(dev) == 0x591E)
 #define IS_SKL_GT3(dev)(IS_SKYLAKE(dev) && \
 (INTEL_DEVID(dev) & 0x00F0) == 0x0020)
 #define IS_SKL_GT4(dev)(IS_SKYLAKE(dev) && \
diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index 8dd9fae..424bccc 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -353,10 +353,10 @@ static const struct ddi_buf_trans 
*skl_get_buf_trans_dp(struct drm_device *dev,
 {
const struct ddi_buf_trans *ddi_translations;
 
-   if (IS_SKL_ULX(dev)) {
+   if (IS_SKL_ULX(dev) || IS_KBL_ULX(dev)) {
ddi_translations = skl_y_ddi_translations_dp;
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
-   } else if (IS_SKL_ULT(dev)) {
+   } else if (IS_SKL_ULT(dev) || IS_KBL_ULT(dev)) {
ddi_translations = skl_u_ddi_translations_dp;
*n_entries = ARRAY_SIZE(skl_u_ddi_translations_dp);
} else {
@@ -373,7 +373,7 @@ static const struct ddi_buf_trans 
*skl_get_buf_trans_edp(struct drm_device *dev,
struct drm_i915_private *dev_priv = dev->dev_private;
const struct ddi_buf_trans *ddi_translations;
 
-   if (IS_SKL_ULX(dev)) {
+   if (IS_SKL_ULX(dev)  || IS_KBL_ULX(dev)) {
if (dev_priv->edp_low_vswing) {
ddi_translations = skl_y_ddi_translations_edp;
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_edp);
@@ -381,7 +381,7 @@ static const struct ddi_buf_trans 
*skl_get_buf_trans_edp(struct drm_device *dev,
ddi_translations = skl_y_ddi_translations_dp;
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_dp);
}
-   } else if (IS_SKL_ULT(dev)) {
+   } else if (IS_SKL_ULT(dev) || IS_KBL_ULT(dev)) {
if (dev_priv->edp_low_vswing) {
ddi_translations = skl_u_ddi_translations_edp;
*n_entries = ARRAY_SIZE(skl_u_ddi_translations_edp);
@@ -408,7 +408,7 @@ skl_get_buf_trans_hdmi(struct drm_device *dev,
 {
const struct ddi_buf_trans *ddi_translations;
 
-   if (IS_SKL_ULX(dev)) {
+   if (IS_SKL_ULX(dev) || IS_KBL_ULX(dev)) {
ddi_translations = skl_y_ddi_translations_hdmi;
*n_entries = ARRAY_SIZE(skl_y_ddi_translations_hdmi);
} else {
-- 
2.4.3

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

[Intel-gfx] [PATCH 1/6] drm/i915: Define IS_BROXTON properly.

Kabylake will also be defined as gen9 and !is_skylake.
So we need start by creating a proper Broxton
definition, otherwise we will break broxton with the
introduction of Kabylake.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.c | 1 +
 drivers/gpu/drm/i915/i915_drv.h | 3 ++-
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index b1f1dec..70f9d3d 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -383,6 +383,7 @@ static const struct intel_device_info 
intel_skylake_gt3_info = {
 
 static const struct intel_device_info intel_broxton_info = {
.is_preliminary = 1,
+   .is_broxton = 1,
.gen = 9,
.need_gfx_hws = 1, .has_hotplug = 1,
.ring_mask = RENDER_RING | BSD_RING | BLT_RING | VEBOX_RING,
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 9a15ebe..565e63a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -765,6 +765,7 @@ struct intel_csr {
func(is_valleyview) sep \
func(is_haswell) sep \
func(is_skylake) sep \
+   func(is_broxton) sep \
func(is_preliminary) sep \
func(has_fbc) sep \
func(has_pipe_cxsr) sep \
@@ -2475,7 +2476,7 @@ struct drm_i915_cmd_table {
 #define IS_HASWELL(dev)(INTEL_INFO(dev)->is_haswell)
 #define IS_BROADWELL(dev)  (!INTEL_INFO(dev)->is_valleyview && 
IS_GEN8(dev))
 #define IS_SKYLAKE(dev)(INTEL_INFO(dev)->is_skylake)
-#define IS_BROXTON(dev)(!INTEL_INFO(dev)->is_skylake && IS_GEN9(dev))
+#define IS_BROXTON(dev)(INTEL_INFO(dev)->is_broxton)
 #define IS_MOBILE(dev) (INTEL_INFO(dev)->is_mobile)
 #define IS_HSW_EARLY_SDV(dev)  (IS_HASWELL(dev) && \
 (INTEL_DEVID(dev) & 0xFF00) == 0x0C00)
-- 
2.4.3

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

[Intel-gfx] [PATCH 6/6] drm/i915/kbl: Fix DMC load on Kabylake.

Kabylake A0 is based on Skylake H0.

v2: Don't assume revid+7 and only load the one we are sure about.

Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_csr.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9e530a7..e4020ae 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -190,9 +190,21 @@ static struct stepping_info bxt_stepping_info[] = {
 
 static char intel_get_stepping(struct drm_device *dev)
 {
-   if (IS_SKYLAKE(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(skl_stepping_info)))
-   return skl_stepping_info[dev->pdev->revision].stepping;
+   int revid = INTEL_REVID(dev);
+
+   /*
+* FIXME: Kabylake derivated from Skylake H0, so SKL H0
+* is the right firmware for KBL A0 (revid 0).
+* We have no visibility yet how next KBL steppings will
+* be handled by firmware, so let's just add support for
+* the only current available KBL.
+*/
+   if (IS_KABYLAKE(dev) && revid == 0)
+   return skl_stepping_info[7].stepping;
+
+   if (IS_SKYLAKE(dev) &&
+   revid < ARRAY_SIZE(skl_stepping_info))
+   return skl_stepping_info[revid].stepping;
else if (IS_BROXTON(dev) && (dev->pdev->revision <
ARRAY_SIZE(bxt_stepping_info)))
return bxt_stepping_info[dev->pdev->revision].stepping;
@@ -202,9 +214,21 @@ static char intel_get_stepping(struct drm_device *dev)
 
 static char intel_get_substepping(struct drm_device *dev)
 {
-   if (IS_SKYLAKE(dev) && (dev->pdev->revision <
-   ARRAY_SIZE(skl_stepping_info)))
-   return skl_stepping_info[dev->pdev->revision].substepping;
+   int revid = INTEL_REVID(dev);
+
+   /*
+* FIXME: Kabylake derivated from Skylake H0, so SKL H0
+* is the right firmware for KBL A0 (revid 0).
+* We have no visibility yet how next KBL steppings will
+* be handled by firmware, so let's just add support for
+* the only current available KBL.
+*/
+   if (IS_KABYLAKE(dev) && revid == 0)
+   return skl_stepping_info[7].substepping;
+
+   if (IS_SKYLAKE(dev) &&
+   revid < ARRAY_SIZE(skl_stepping_info))
+   return skl_stepping_info[revid].substepping;
else if (IS_BROXTON(dev) && (dev->pdev->revision <
ARRAY_SIZE(bxt_stepping_info)))
return bxt_stepping_info[dev->pdev->revision].substepping;
-- 
2.4.3

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

[Intel-gfx] [PATCH 4/6] drm/i915/kbl: Add Kabylake GT4 PCI ID

From: Deepak S 

Reviewed-by: Damien Lespiau 
Signed-off-by: Deepak S 
Signed-off-by: Damien Lespiau 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 ++-
 include/drm/i915_pciids.h   | 9 -
 2 files changed, 10 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index a3247e6..fd2f9a2 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -468,7 +468,8 @@ static const struct intel_device_info 
intel_kabylake_gt3_info = {
INTEL_BXT_IDS(&intel_broxton_info), \
INTEL_KBL_GT1_IDS(&intel_kabylake_info),\
INTEL_KBL_GT2_IDS(&intel_kabylake_info),\
-   INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info)
+   INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info),\
+   INTEL_KBL_GT4_IDS(&intel_kabylake_gt3_info)
 
 static const struct pci_device_id pciidlist[] = {  /* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 2e7a159..f1a113e 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -315,9 +315,16 @@
INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
 
+#define INTEL_KBL_GT4_IDS(info) \
+   INTEL_VGA_DEVICE(0x5932, info), /* DT  GT4 */ \
+   INTEL_VGA_DEVICE(0x593B, info), /* Halo GT4 */ \
+   INTEL_VGA_DEVICE(0x593A, info), /* SRV GT4 */ \
+   INTEL_VGA_DEVICE(0x593D, info)  /* WKS GT4 */
+
 #define INTEL_KBL_IDS(info) \
INTEL_KBL_GT1_IDS(info), \
INTEL_KBL_GT2_IDS(info), \
-   INTEL_KBL_GT3_IDS(info)
+   INTEL_KBL_GT3_IDS(info), \
+   INTEL_KBL_GT4_IDS(info)
 
 #endif /* _I915_PCIIDS_H */
-- 
2.4.3

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

[Intel-gfx] [PATCH 3/6] drm/i915/kbl: Add Kabylake PCI ID

From: Deepak S 

v2: separate out device info into different GT (Damien)
v3: Add is_kabylake to the KBL gt3 structuer (Damien)
Sort the platforms in older -> newer order (Damien)

v4: Split platform definition since is_skylake=1 on
kabylake structure was Nacked. (Rodrigo)

Reviewed-by: Damien Lespiau 
Signed-off-by: Deepak S 
Signed-off-by: Damien Lespiau 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/i915_drv.c |  5 -
 include/drm/i915_pciids.h   | 29 +
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index c9e80fb..a3247e6 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -465,7 +465,10 @@ static const struct intel_device_info 
intel_kabylake_gt3_info = {
INTEL_SKL_GT1_IDS(&intel_skylake_info), \
INTEL_SKL_GT2_IDS(&intel_skylake_info), \
INTEL_SKL_GT3_IDS(&intel_skylake_gt3_info), \
-   INTEL_BXT_IDS(&intel_broxton_info)
+   INTEL_BXT_IDS(&intel_broxton_info), \
+   INTEL_KBL_GT1_IDS(&intel_kabylake_info),\
+   INTEL_KBL_GT2_IDS(&intel_kabylake_info),\
+   INTEL_KBL_GT3_IDS(&intel_kabylake_gt3_info)
 
 static const struct pci_device_id pciidlist[] = {  /* aka */
INTEL_PCI_IDS,
diff --git a/include/drm/i915_pciids.h b/include/drm/i915_pciids.h
index 17c4456..2e7a159 100644
--- a/include/drm/i915_pciids.h
+++ b/include/drm/i915_pciids.h
@@ -291,4 +291,33 @@
INTEL_VGA_DEVICE(0x1A84, info), \
INTEL_VGA_DEVICE(0x5A84, info)
 
+#define INTEL_KBL_GT1_IDS(info)\
+   INTEL_VGA_DEVICE(0x5913, info), /* ULT GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5915, info), /* ULX GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5917, info), /* DT  GT1.5 */ \
+   INTEL_VGA_DEVICE(0x5906, info), /* ULT GT1 */ \
+   INTEL_VGA_DEVICE(0x590E, info), /* ULX GT1 */ \
+   INTEL_VGA_DEVICE(0x5902, info), /* DT  GT1 */ \
+   INTEL_VGA_DEVICE(0x590B, info), /* Halo GT1 */ \
+   INTEL_VGA_DEVICE(0x590A, info) /* SRV GT1 */
+
+#define INTEL_KBL_GT2_IDS(info)\
+   INTEL_VGA_DEVICE(0x5916, info), /* ULT GT2 */ \
+   INTEL_VGA_DEVICE(0x5921, info), /* ULT GT2F */ \
+   INTEL_VGA_DEVICE(0x591E, info), /* ULX GT2 */ \
+   INTEL_VGA_DEVICE(0x5912, info), /* DT  GT2 */ \
+   INTEL_VGA_DEVICE(0x591B, info), /* Halo GT2 */ \
+   INTEL_VGA_DEVICE(0x591A, info), /* SRV GT2 */ \
+   INTEL_VGA_DEVICE(0x591D, info) /* WKS GT2 */
+
+#define INTEL_KBL_GT3_IDS(info) \
+   INTEL_VGA_DEVICE(0x5926, info), /* ULT GT3 */ \
+   INTEL_VGA_DEVICE(0x592B, info), /* Halo GT3 */ \
+   INTEL_VGA_DEVICE(0x592A, info) /* SRV GT3 */
+
+#define INTEL_KBL_IDS(info) \
+   INTEL_KBL_GT1_IDS(info), \
+   INTEL_KBL_GT2_IDS(info), \
+   INTEL_KBL_GT3_IDS(info)
+
 #endif /* _I915_PCIIDS_H */
-- 
2.4.3

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

[Intel-gfx] [PATCH 0/6] Kabylake patches V2

MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

This is the second version of the Kabylake enabling patches.

This new version Kabylake is defined totally independent from Skylake
and without doing the revid+7 hack.

An special thanks to Jani that did a great job on redefining the REVID
macros used for Workarounds. That made my life here when creating
a Kabylake separated from Skylake. Thanks!

I also brings new PCI IDs for GT4.

Deepak S (2):
  drm/i915/kbl: Add Kabylake PCI ID
  drm/i915/kbl: Add Kabylake GT4 PCI ID

Rodrigo Vivi (4):
  drm/i915: Define IS_BROXTON properly.
  drm/i915/kbl: Introduce Kabylake platform defition.
  drm/i915/kbl: Use propper ddi buffer translation table for Kabylake
ULT and ULX.
  drm/i915/kbl: Fix DMC load on Kabylake.

 drivers/gpu/drm/i915/i915_debugfs.c | 16 +++
 drivers/gpu/drm/i915/i915_dma.c |  3 +-
 drivers/gpu/drm/i915/i915_drv.c | 51 -
 drivers/gpu/drm/i915/i915_drv.h | 17 +--
 drivers/gpu/drm/i915/i915_gem_stolen.c  |  3 +-
 drivers/gpu/drm/i915/intel_audio.c  |  9 +++---
 drivers/gpu/drm/i915/intel_csr.c| 36 +++
 drivers/gpu/drm/i915/intel_ddi.c| 26 -
 drivers/gpu/drm/i915/intel_display.c| 12 
 drivers/gpu/drm/i915/intel_dp.c |  6 ++--
 drivers/gpu/drm/i915/intel_fbc.c|  3 +-
 drivers/gpu/drm/i915/intel_mocs.c   |  2 +-
 drivers/gpu/drm/i915/intel_pm.c | 11 +++
 drivers/gpu/drm/i915/intel_runtime_pm.c |  2 +-
 include/drm/i915_pciids.h   | 36 +++
 15 files changed, 175 insertions(+), 58 deletions(-)

-- 
2.4.3

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

Re: [Intel-gfx] [PATCH 23/26] drm/i915: use a single intel_fbc_work struct

On Tue, Oct 27, 2015 at 02:50:25PM -0200, Paulo Zanoni wrote:
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a9434d1..fdbe068 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -917,9 +917,11 @@ struct i915_fbc {
>   bool active;
>  
>   struct intel_fbc_work {
> - struct delayed_work work;
> + bool scheduled;

Ah, I found this confusingly named. scheduled implied to me that you
wanted work_pending(), but you just want to asynchronously cancel the
fbc worker. Just bool cancel? Or bool active? Though now I've come full
circle and suggest bool scheduled. So

/* Track whether the FBC worker has already been queued,
 * or asynchronously cancel the worker whilst it waits
 * before activation.
 */

What happens then if we quickly queue, cancel and want to requeue? The
schedule_work() fails as the task is already pending, but the scheduled
flag gets reset, so it just works. Perfect.

> + struct work_struct work;
>   struct drm_framebuffer *fb;

Hmm, don't we actually need to take references on the fb we schedule for
activation? Since we already account for that the crtc->fb may be
changed between queuing the work and executing it, for extra paranoia we
should ensure that we have a reference in work->fb. (long standing bug,
might as well fix it before we see it in the wild, time for another
kms-flip race!)

I think I've covered the basic issues with changing the type of worker
and it looks fine,
Reviewed-by: Chris Wilson 
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/26] drm/i915: don't stop+start FBC at every flip

On Tue, Oct 27, 2015 at 02:50:04PM -0200, Paulo Zanoni wrote:
> @@ -1021,13 +1078,48 @@ void intel_fbc_flush(struct drm_i915_private 
> *dev_priv,
>   if (origin == ORIGIN_GTT)
>   return;
>  
> + /* Hardware tracking already recompresses the CFB (nuke) for us if FBC
> +  * is enabled and we do a page flip, so we can safely ignore it here.
> +  * FBC may be disabled in case we got an invalidate() before the
> +  * flush(), so we'll still have to check that case below. */

I feel like I understand what is going on a bit better now, thanks!

> + if (origin == ORIGIN_FLIP && dev_priv->fbc.enabled)
> + return;
> +
>   mutex_lock(&dev_priv->fbc.lock);
>  
>   dev_priv->fbc.busy_bits &= ~frontbuffer_bits;
>  
>   if (!dev_priv->fbc.busy_bits) {
> - __intel_fbc_disable(dev_priv);
> - __intel_fbc_update(dev_priv);
> + if (origin == ORIGIN_FLIP) {

Note this test here is redundant.

We know that for an origin == FLIP to be here, FBC is disabled and
calling intel_fbc_disable() is then a no-op.

So it turns out that the origin two lines of disable(); update() works
just as well. Or is there some later patch that tweaks this branch
further?
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)

On Tue, Oct 27, 2015 at 06:47:19PM +, Chris Wilson wrote:
> On Tue, Oct 27, 2015 at 08:35:36PM +0200, Ville Syrjälä wrote:
> > On Tue, Oct 27, 2015 at 06:03:52PM +, Chris Wilson wrote:
> > > On Tue, Oct 27, 2015 at 02:26:55PM +, Tvrtko Ursulin wrote:
> > > > 
> > > > On 27/10/15 13:48, Ville Syrjälä wrote:
> > > > >On Tue, Oct 27, 2015 at 01:34:44PM +, Tvrtko Ursulin wrote:
> > > > >>
> > > > >>On 27/10/15 12:51, Ville Syrjälä wrote:
> > > > >>>On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:
> > > > While pinning a fb object to the display plane, only install a fence
> > > > if the object is using a normal view. This corresponds with the
> > > > behavior found in i915_gem_object_do_pin() where the fencability
> > > > criteria is determined only for objects with normal views.
> > > > 
> > > > v2:
> > > > Look at the object's map_and_fenceable flag to determine whether to
> > > > install a fence or not (Chris).
> > > > 
> > > > Cc: Chris Wilson 
> > > > Cc: Tvrtko Ursulin 
> > > > Cc: Daniel Vetter 
> > > > Signed-off-by: Vivek Kasireddy 
> > > > ---
> > > >    drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > > >    1 file changed, 2 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > > b/drivers/gpu/drm/i915/intel_display.c
> > > > index 52fb3f2..108c000 100644
> > > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > > @@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane 
> > > > *plane,
> > > >  * framebuffer compression.  For simplicity, we always install
> > > >  * a fence as the cost is not that onerous.
> > > >  */
> > > > -   ret = i915_gem_object_get_fence(obj);
> > > > +   if (obj->map_and_fenceable)
> > > > >>>
> > > > >>>This will now get the fence and pin it for the 90/270 view as well,
> > > > >>>even though the fence doesn't even cover that particualr gtt mapping.
> > > > >>
> > > > >>I don't follow. obj->map_and_fenceable will be true only when normal
> > > > >>view exists, so this avoids setting up the fence when no normal view
> > > > >>exists and so avoids the WARN_ON in i915_gem_object_get_fence.
> > > > >
> > > > >Sure, but it's pointless to use up a fence if all we care about
> > > > >is the 90/270 mapping.
> > > > 
> > > > After a brief IRC discussion we agreed that the patch doesn't
> > > > introduce any new negative behaviours.
> > > 
> > > Urm, consider
> > > 
> > > intel_unpin_fb_obj():
> > >   ...
> > >   i915_gem_object_unpin_fence(intel_fb_obj(obj));
> > 
> > We'll have (pointlessly) pinned the fence too, so I think it'll end up
> > working. I would have just put in view==NORMAL checks myself as an
> > interim solution to avoid that, but whatever.
> 
> No, it didn't. If we rotated first, we don't get a fence and so don't
> pin it. Then we attach an unrotated, grab a fence and pin it. Then we
> end up unpinning twice vs a single pin.

Oh, map_and_fenceable on the _object_ depends whether the normal view is
bound, and yeah it could get bound only after the rotated view got used
for scanout. So view==NORMAL for now seems like good enough solution for
now to me. Anything else means a bigger rework of the code, and I for
one don't want to got there until I've managed to land my already pending
stuff.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)

On Tue, Oct 27, 2015 at 08:35:36PM +0200, Ville Syrjälä wrote:
> On Tue, Oct 27, 2015 at 06:03:52PM +, Chris Wilson wrote:
> > On Tue, Oct 27, 2015 at 02:26:55PM +, Tvrtko Ursulin wrote:
> > > 
> > > On 27/10/15 13:48, Ville Syrjälä wrote:
> > > >On Tue, Oct 27, 2015 at 01:34:44PM +, Tvrtko Ursulin wrote:
> > > >>
> > > >>On 27/10/15 12:51, Ville Syrjälä wrote:
> > > >>>On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:
> > > While pinning a fb object to the display plane, only install a fence
> > > if the object is using a normal view. This corresponds with the
> > > behavior found in i915_gem_object_do_pin() where the fencability
> > > criteria is determined only for objects with normal views.
> > > 
> > > v2:
> > > Look at the object's map_and_fenceable flag to determine whether to
> > > install a fence or not (Chris).
> > > 
> > > Cc: Chris Wilson 
> > > Cc: Tvrtko Ursulin 
> > > Cc: Daniel Vetter 
> > > Signed-off-by: Vivek Kasireddy 
> > > ---
> > >    drivers/gpu/drm/i915/intel_display.c | 3 ++-
> > >    1 file changed, 2 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > > b/drivers/gpu/drm/i915/intel_display.c
> > > index 52fb3f2..108c000 100644
> > > --- a/drivers/gpu/drm/i915/intel_display.c
> > > +++ b/drivers/gpu/drm/i915/intel_display.c
> > > @@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane 
> > > *plane,
> > >    * framebuffer compression.  For simplicity, we always install
> > >    * a fence as the cost is not that onerous.
> > >    */
> > > - ret = i915_gem_object_get_fence(obj);
> > > + if (obj->map_and_fenceable)
> > > >>>
> > > >>>This will now get the fence and pin it for the 90/270 view as well,
> > > >>>even though the fence doesn't even cover that particualr gtt mapping.
> > > >>
> > > >>I don't follow. obj->map_and_fenceable will be true only when normal
> > > >>view exists, so this avoids setting up the fence when no normal view
> > > >>exists and so avoids the WARN_ON in i915_gem_object_get_fence.
> > > >
> > > >Sure, but it's pointless to use up a fence if all we care about
> > > >is the 90/270 mapping.
> > > 
> > > After a brief IRC discussion we agreed that the patch doesn't
> > > introduce any new negative behaviours.
> > 
> > Urm, consider
> > 
> > intel_unpin_fb_obj():
> > ...
> > i915_gem_object_unpin_fence(intel_fb_obj(obj));
> 
> We'll have (pointlessly) pinned the fence too, so I think it'll end up
> working. I would have just put in view==NORMAL checks myself as an
> interim solution to avoid that, but whatever.

No, it didn't. If we rotated first, we don't get a fence and so don't
pin it. Then we attach an unrotated, grab a fence and pin it. Then we
end up unpinning twice vs a single pin.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Always program CSR if CSR is uninitialized

2015-10-27 Thread Imre Deak

On pe, 2015-10-23 at 11:41 +0200, Patrik Jakobsson wrote:
> The current CSR loading code depends on the CSR program memory to be
> cleared after boot. This is unfortunately not true on all hardware.
> Instead make use of the FW_UNINITIALIZED state in init and check for
> FW_LOADED to prevent init path from skipping the actual programming.
> 
> v2: Move initialization of state to after HAS_CSR() check
> 
> Signed-off-by: Patrik Jakobsson 
> Tested-by: Rodrigo Vivi 
> Reviewed-by: Rodrigo Vivi 
> ---
>  drivers/gpu/drm/i915/intel_csr.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_csr.c 
> b/drivers/gpu/drm/i915/intel_csr.c
> index 9e530a7..e74c09e 100644
> --- a/drivers/gpu/drm/i915/intel_csr.c
> +++ b/drivers/gpu/drm/i915/intel_csr.c
> @@ -271,7 +271,7 @@ void intel_csr_load_program(struct drm_device *dev)
>* Unfortunately the ACPI subsystem doesn't yet give us a way to
>* differentiate this, hence figure it out with this hack.
>*/
> - if (I915_READ(CSR_PROGRAM(0)))
> + if (I915_READ(CSR_PROGRAM(0)) && dev_priv->csr.state == FW_LOADED)
>   return;

As Animesh said csr->state is being removed, so I'd prefer if we didn't
add new users for it.

I think the proper solution for this would be to reprogram the firmware
only when we know we have to and not have here either of the above
checks. The points we need to reprogram the firmware:

S3/S4 both on SKL.
S3/S4/DC9 (runtime suspend) on BXT.

To fix this particular bug you could also just add an
intel_csr_reprogram() that would check for CSR_PROGRAM(0) as now, while
during driver loading you would program the firmware unconditionally.

--Imre


>  
>   mutex_lock(&dev_priv->csr_lock);
> @@ -428,6 +428,8 @@ void intel_csr_ucode_init(struct drm_device *dev)
>   if (!HAS_CSR(dev))
>   return;
>  
> + intel_csr_load_status_set(dev_priv, FW_UNINITIALIZED);
> +
>   if (IS_SKYLAKE(dev))
>   csr->fw_path = I915_CSR_SKL;
>   else if (IS_BROXTON(dev_priv))



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

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)

On Tue, Oct 27, 2015 at 06:03:52PM +, Chris Wilson wrote:
> On Tue, Oct 27, 2015 at 02:26:55PM +, Tvrtko Ursulin wrote:
> > 
> > On 27/10/15 13:48, Ville Syrjälä wrote:
> > >On Tue, Oct 27, 2015 at 01:34:44PM +, Tvrtko Ursulin wrote:
> > >>
> > >>On 27/10/15 12:51, Ville Syrjälä wrote:
> > >>>On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:
> > While pinning a fb object to the display plane, only install a fence
> > if the object is using a normal view. This corresponds with the
> > behavior found in i915_gem_object_do_pin() where the fencability
> > criteria is determined only for objects with normal views.
> > 
> > v2:
> > Look at the object's map_and_fenceable flag to determine whether to
> > install a fence or not (Chris).
> > 
> > Cc: Chris Wilson 
> > Cc: Tvrtko Ursulin 
> > Cc: Daniel Vetter 
> > Signed-off-by: Vivek Kasireddy 
> > ---
> >    drivers/gpu/drm/i915/intel_display.c | 3 ++-
> >    1 file changed, 2 insertions(+), 1 deletion(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 52fb3f2..108c000 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane 
> > *plane,
> >  * framebuffer compression.  For simplicity, we always install
> >  * a fence as the cost is not that onerous.
> >  */
> > -   ret = i915_gem_object_get_fence(obj);
> > +   if (obj->map_and_fenceable)
> > >>>
> > >>>This will now get the fence and pin it for the 90/270 view as well,
> > >>>even though the fence doesn't even cover that particualr gtt mapping.
> > >>
> > >>I don't follow. obj->map_and_fenceable will be true only when normal
> > >>view exists, so this avoids setting up the fence when no normal view
> > >>exists and so avoids the WARN_ON in i915_gem_object_get_fence.
> > >
> > >Sure, but it's pointless to use up a fence if all we care about
> > >is the 90/270 mapping.
> > 
> > After a brief IRC discussion we agreed that the patch doesn't
> > introduce any new negative behaviours.
> 
> Urm, consider
> 
> intel_unpin_fb_obj():
>   ...
>   i915_gem_object_unpin_fence(intel_fb_obj(obj));

We'll have (pointlessly) pinned the fence too, so I think it'll end up
working. I would have just put in view==NORMAL checks myself as an
interim solution to avoid that, but whatever.

> 
> 
> So if the fb is bound both in rotated and non-rotated modes, we will
> have a fence for the object and try to unpin it twice => WARN (Daniel is
> being too nice, once upon a time that was rightfully a BUG for a major
> screwup).
> 
> We want to track the fence state on the vma and associated that vma with
> the plane_state so that the tracking doesn't get so easily confused.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 02/26] drm/i915: don't stop+start FBC at every flip

On Tue, Oct 27, 2015 at 02:50:04PM -0200, Paulo Zanoni wrote:
> The hardware already takes care of disabling and recompressing FBC
> when we do a page flip, so all we need to do is to update the fence
> registers and move on.
> 
> One of the important things to notice is that on the pre-gen6
> platforms the fence is programmed on the FBC control register and the
> documentation says we can't update the control register while FBC is
> enabled. This would basically mean we'd have to to disable+enable FBC
> at every flip in order to make sure the hardware tracking still works,
> which doesn't seem to make too much sense. So I sent an email to the
> hardware team requesting some clarification. The information I got was
> this:
> 
> "I don't think any hardware is latching on to 0x100100, 0x100104, or
> the old fence number in FBC_CTL. Instructions against changing on the
> fly would be to simplify testing and ensure you don't miss any
> invalidation that happened right at that time."
> 
> So I guess we're fine for flips. But I can't really say I tested FBC
> on these ancient platforms - nor that I'll ever propose enabling FBC
> by default on them exactly because of problems like these.

Yeah, I did this in my patches too, and IIRC it seemed to work just fine
back then.

> 
> v2: Add comment at flush() (Chris).
> 
> Testcase: igt/kms_frontbuffer_tracking/fbc*-fliptrack
> Signed-off-by: Paulo Zanoni 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   1 +
>  drivers/gpu/drm/i915/i915_reg.h  |   3 +
>  drivers/gpu/drm/i915/intel_display.c |   1 -
>  drivers/gpu/drm/i915/intel_drv.h |   2 +
>  drivers/gpu/drm/i915/intel_fbc.c | 103 
> ++-
>  drivers/gpu/drm/i915/intel_frontbuffer.c |   1 +
>  6 files changed, 108 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index ee14962..77da500 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -928,6 +928,7 @@ struct i915_fbc {
>   bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
>   void (*enable_fbc)(struct intel_crtc *crtc);
>   void (*disable_fbc)(struct drm_i915_private *dev_priv);
> + void (*flip_prepare)(struct drm_i915_private *dev_priv);
>  };
>  
>  /**
> diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
> index 8942532..3d598a2 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -2028,6 +2028,7 @@ enum skl_disp_power_wells {
>  #define   FBC_CTL_C3_IDLE(1<<13)
>  #define   FBC_CTL_STRIDE_SHIFT   (5)
>  #define   FBC_CTL_FENCENO_SHIFT  (0)
> +#define   FBC_CTL_FENCENO_MASK   0xF

It's only three bits on gen2. But bit 3 is MBZ and there are only 8
fence registers on those platforms, so this is OK.

>  #define FBC_COMMAND  0x0320c
>  #define   FBC_CMD_COMPRESS   (1<<0)
>  #define FBC_STATUS   0x03210
> @@ -2064,6 +2065,7 @@ enum skl_disp_power_wells {
>  #define   DPFC_CTL_LIMIT_1X  (0<<6)
>  #define   DPFC_CTL_LIMIT_2X  (1<<6)
>  #define   DPFC_CTL_LIMIT_4X  (2<<6)
> +#define   DPFC_CTL_FENCE_MASK0xF
>  #define DPFC_RECOMP_CTL  0x320c
>  #define   DPFC_RECOMP_STALL_EN   (1<<27)
>  #define   DPFC_RECOMP_STALL_WM_SHIFT (16)
> @@ -2086,6 +2088,7 @@ enum skl_disp_power_wells {
>  #define   FBC_CTL_FALSE_COLOR(1<<10)
>  /* The bit 28-8 is reserved */
>  #define   DPFC_RESERVED  (0x1F00)
> +#define   ILK_DPFC_FENCE_MASK0xF
>  #define ILK_DPFC_RECOMP_CTL  0x4320c
>  #define ILK_DPFC_STATUS  0x43210
>  #define ILK_DPFC_FENCE_YOFF  0x43218
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index bc1907e..d9378c3 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -11502,7 +11502,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
> to_intel_plane(primary)->frontbuffer_bit);
>   mutex_unlock(&dev->struct_mutex);
>  
> - intel_fbc_disable_crtc(intel_crtc);
>   intel_frontbuffer_flip_prepare(dev,
>  
> to_intel_plane(primary)->frontbuffer_bit);
>  
> diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> b/drivers/gpu/drm/i915/intel_drv.h
> index 08847d0..9065a8f 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1305,6 +1305,8 @@ void intel_fbc_invalidate(struct drm_i915_private 
> *dev_priv,
> enum fb_op_origin origin);
>  void intel_fbc_flush(struct drm_i915_private *dev_priv,
>unsigned int frontbuffer_bits, enum fb_op_origin origin);
> +void intel_fbc_flip_prepare(struct drm_i915_private *dev_priv,
> + unsigned int frontbuffer_bits);
>  void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
>  
>  /* intel_hdmi.c */
> diff --git a/drivers/

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)

On Tue, Oct 27, 2015 at 02:26:55PM +, Tvrtko Ursulin wrote:
> 
> On 27/10/15 13:48, Ville Syrjälä wrote:
> >On Tue, Oct 27, 2015 at 01:34:44PM +, Tvrtko Ursulin wrote:
> >>
> >>On 27/10/15 12:51, Ville Syrjälä wrote:
> >>>On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:
> While pinning a fb object to the display plane, only install a fence
> if the object is using a normal view. This corresponds with the
> behavior found in i915_gem_object_do_pin() where the fencability
> criteria is determined only for objects with normal views.
> 
> v2:
> Look at the object's map_and_fenceable flag to determine whether to
> install a fence or not (Chris).
> 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Signed-off-by: Vivek Kasireddy 
> ---
>    drivers/gpu/drm/i915/intel_display.c | 3 ++-
>    1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 52fb3f2..108c000 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
>    * framebuffer compression.  For simplicity, we always install
>    * a fence as the cost is not that onerous.
>    */
> - ret = i915_gem_object_get_fence(obj);
> + if (obj->map_and_fenceable)
> >>>
> >>>This will now get the fence and pin it for the 90/270 view as well,
> >>>even though the fence doesn't even cover that particualr gtt mapping.
> >>
> >>I don't follow. obj->map_and_fenceable will be true only when normal
> >>view exists, so this avoids setting up the fence when no normal view
> >>exists and so avoids the WARN_ON in i915_gem_object_get_fence.
> >
> >Sure, but it's pointless to use up a fence if all we care about
> >is the 90/270 mapping.
> 
> After a brief IRC discussion we agreed that the patch doesn't
> introduce any new negative behaviours.

Urm, consider

intel_unpin_fb_obj():
...
i915_gem_object_unpin_fence(intel_fb_obj(obj));


So if the fb is bound both in rotated and non-rotated modes, we will
have a fence for the object and try to unpin it twice => WARN (Daniel is
being too nice, once upon a time that was rightfully a BUG for a major
screwup).

We want to track the fence state on the vma and associated that vma with
the plane_state so that the tracking doesn't get so easily confused.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2] drm/i915: Add extra plane information in debugfs.

On Tue, Oct 27, 2015 at 04:49:49PM +0100, Robert Fekete wrote:
> +static const char *plane_rotation(unsigned int rotation)
> +{
> + static char buf[48];
> + /*
> +  * According to doc only one DRM_ROTATE_ is allowed but this
> +  * will print them all to visualize if the values are misused
> +  */
> + snprintf(buf, sizeof(buf),
> +  "%s%s%s%s%s%s(0x%08x)",
> +  (rotation & BIT(DRM_ROTATE_0)) ? "0 " : "",
> +  (rotation & BIT(DRM_ROTATE_90)) ? "90 " : "",
> +  (rotation & BIT(DRM_ROTATE_180)) ? "180 " : "",
> +  (rotation & BIT(DRM_ROTATE_270)) ? "270 " : "",
> +  (rotation & BIT(DRM_REFLECT_X)) ? "FLIPX " : "",
> +  (rotation & BIT(DRM_REFLECT_Y)) ? "FLIPY " : "",
> +  rotation);

I'd do it the other away around "%x (%s...%s)", the number is the one we
all know and love, and the human readable translation second.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: Skip suspend/hibernate tests if the system doesn't support them

On Tue, Oct 27, 2015 at 08:58:17AM +0200, David Weinehall wrote:
> On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote:
> > On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
> > > From: Ville Syrjälä 
> > > 
> > > Do a dry run with rtcwake first to determine if the system even supports
> > > the intended suspend state. If not, skip the test.
> > > 
> > > Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3.
> > > 
> > > Signed-off-by: Ville Syrjälä 
> > > ---
> > >  lib/igt_aux.c | 6 ++
> > >  1 file changed, 6 insertions(+)
> > > 
> > > diff --git a/lib/igt_aux.c b/lib/igt_aux.c
> > > index 04ca25b..f3c76ae 100644
> > > --- a/lib/igt_aux.c
> > > +++ b/lib/igt_aux.c
> > > @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void)
> > >* seems to fare better. We need to investigate what's going on. */
> > >   igt_skip_on_simulation();
> > >  
> > > + /* skip if system doesn't support suspend-to-mem */
> > > + igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0);
> > > +
> > >   ret = system("rtcwake -s 30 -m mem");
> > >   igt_assert_f(ret == 0,
> > >"This failure means that something is wrong with the "
> > > @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void)
> > >* seems to fare better. We need to investigate what's going on. */
> > >   igt_skip_on_simulation();
> > >  
> > > + /* skip if system doesn't support suspend-to-disk */
> > > + igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0);
> > > +
> > >   /* The timeout might need to be adjusted if hibernation takes too long
> > >* or if we have to wait excessively long before resume
> > >*/
> > > 
> > 
> > Are there reliable alternatives to the rtcwake alarm?
> > Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty 
> > hard here)?
> 
> Depending on what the hardware supports, for hibernate to disk there's ipmi 
> power-on.
> 
> ipmi-power -h $hostname --stat will show the status of the machine,
> ipmi-power -h $hostname --on will power it on.

I would have expected to see IPMI only on server platforms. Has it
become more widespread at some point?

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t 2/4] lib: Skip suspend/hibernate tests if the system doesn't support them

2015-10-27 Thread Jesse Barnes

On 10/26/2015 11:58 PM, David Weinehall wrote:
> On Fri, Oct 23, 2015 at 12:39:31PM -0700, Jesse Barnes wrote:
>> On 10/22/2015 01:35 PM, ville.syrj...@linux.intel.com wrote:
>>> From: Ville Syrjälä 
>>>
>>> Do a dry run with rtcwake first to determine if the system even supports
>>> the intended suspend state. If not, skip the test.
>>>
>>> Fixes a bunch of stuff on my BYT FFRD8 that doesn't support S3.
>>>
>>> Signed-off-by: Ville Syrjälä 
>>> ---
>>>  lib/igt_aux.c | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/lib/igt_aux.c b/lib/igt_aux.c
>>> index 04ca25b..f3c76ae 100644
>>> --- a/lib/igt_aux.c
>>> +++ b/lib/igt_aux.c
>>> @@ -357,6 +357,9 @@ void igt_system_suspend_autoresume(void)
>>>  * seems to fare better. We need to investigate what's going on. */
>>> igt_skip_on_simulation();
>>>  
>>> +   /* skip if system doesn't support suspend-to-mem */
>>> +   igt_skip_on(system("rtcwake -n -s 30 -m mem") != 0);
>>> +
>>> ret = system("rtcwake -s 30 -m mem");
>>> igt_assert_f(ret == 0,
>>>  "This failure means that something is wrong with the "
>>> @@ -384,6 +387,9 @@ void igt_system_hibernate_autoresume(void)
>>>  * seems to fare better. We need to investigate what's going on. */
>>> igt_skip_on_simulation();
>>>  
>>> +   /* skip if system doesn't support suspend-to-disk */
>>> +   igt_skip_on(system("rtcwake -n -s 90 -m disk") != 0);
>>> +
>>> /* The timeout might need to be adjusted if hibernation takes too long
>>>  * or if we have to wait excessively long before resume
>>>  */
>>>
>>
>> Are there reliable alternatives to the rtcwake alarm?
>> Maybe some AMT/MEI wakeup event or some ACPI clock thing (handwaving pretty 
>> hard here)?
> 
> Depending on what the hardware supports, for hibernate to disk there's ipmi 
> power-on.
> 
> ipmi-power -h $hostname --stat will show the status of the machine,
> ipmi-power -h $hostname --on will power it on.
> 
> Maybe wake-on-lan could be an option too?

If there's some way to automate these into the tests, that would be
ideal, otherwise including them in the Jenkins setup for platforms that
don't have RTC wake would be good so we can get full test coverage.

Jesse

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

[Intel-gfx] [PATCH 19/26] drm/i915: move adjusted_mode checks from fbc_update to fbc_enable

These things can't change without a full modeset.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 0ba25b9..6aa9af8 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -825,7 +825,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
-   const struct drm_display_mode *adjusted_mode;
 
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
@@ -844,13 +843,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
 
fb = crtc->base.primary->fb;
obj = intel_fb_obj(fb);
-   adjusted_mode = &crtc->config->base.adjusted_mode;
-
-   if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
-   (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
-   set_no_fbc_reason(dev_priv, "incompatible mode");
-   goto out_disable;
-   }
 
if (!intel_fbc_hw_tracking_covers_screen(crtc)) {
set_no_fbc_reason(dev_priv, "mode too large for compression");
@@ -1076,6 +1068,8 @@ void intel_fbc_flip_prepare(struct drm_i915_private 
*dev_priv,
 void intel_fbc_enable(struct intel_crtc *crtc)
 {
struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   const struct drm_display_mode *adjusted_mode =
+   &crtc->config->base.adjusted_mode;
 
if (!fbc_supported(dev_priv))
return;
@@ -1110,6 +1104,12 @@ void intel_fbc_enable(struct intel_crtc *crtc)
goto out;
}
 
+   if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
+   (adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
+   set_no_fbc_reason(dev_priv, "incompatible mode");
+   goto out;
+   }
+
if (intel_fbc_alloc_cfb(crtc)) {
set_no_fbc_reason(dev_priv, "not enough stolen memory");
goto out;
-- 
2.6.1

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

[Intel-gfx] [PATCH 26/26] drm/i915: kill fbc.uncompressed_size

Directly call intel_fbc_calculate_cfb_size() in the only place that
actually needs it, and use the proper check before removing the stolen
node. IMHO, this change makes our code easier to understand.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_fbc.c | 13 -
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 784ce2e..0acc090 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -900,7 +900,6 @@ struct i915_fbc {
/* This is always the inner lock when overlapping with struct_mutex and
 * it's the outer lock when overlapping with stolen_lock. */
struct mutex lock;
-   unsigned long uncompressed_size;
unsigned threshold;
unsigned int fb_id;
unsigned int possible_framebuffer_bits;
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index ba31359..27c42e7 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -155,7 +155,7 @@ static void i8xx_fbc_activate(struct intel_crtc *crtc)
dev_priv->fbc.active = true;
 
/* Note: fbc.threshold == 1 for i8xx */
-   cfb_pitch = dev_priv->fbc.uncompressed_size / FBC_LL_SIZE;
+   cfb_pitch = intel_fbc_calculate_cfb_size(crtc, fb) / FBC_LL_SIZE;
if (fb->pitches[0] < cfb_pitch)
cfb_pitch = fb->pitches[0];
 
@@ -682,8 +682,6 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
   dev_priv->mm.stolen_base + compressed_llb->start);
}
 
-   dev_priv->fbc.uncompressed_size = size;
-
DRM_DEBUG_KMS("reserved %llu bytes of contiguous stolen space for FBC, 
threshold: %d\n",
  dev_priv->fbc.compressed_fb.size,
  dev_priv->fbc.threshold);
@@ -700,18 +698,15 @@ err_llb:
 
 static void __intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv)
 {
-   if (dev_priv->fbc.uncompressed_size == 0)
-   return;
-
-   i915_gem_stolen_remove_node(dev_priv, &dev_priv->fbc.compressed_fb);
+   if (dev_priv->fbc.compressed_fb.allocated)
+   i915_gem_stolen_remove_node(dev_priv,
+   &dev_priv->fbc.compressed_fb);
 
if (dev_priv->fbc.compressed_llb) {
i915_gem_stolen_remove_node(dev_priv,
dev_priv->fbc.compressed_llb);
kfree(dev_priv->fbc.compressed_llb);
}
-
-   dev_priv->fbc.uncompressed_size = 0;
 }
 
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv)
-- 
2.6.1

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

[Intel-gfx] [PATCH 12/26] drm/i915: don't disable_fbc() if FBC is already disabled

If FBC is disabled we will still call intel_fbc_invalidate(), and as a
result we may call intel_fbc_deactivate(), which will try to touch
registers.

I'm pretty sure I saw this happen on a runtime suspended device, and
I'm almost sure I was running igt/pm_rpm. It produced the "you touched
registers while the device is suspended" WARNs. But this was some time
ago and I can't remember exactly which conditions were necessary to
reproduce the problem.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 6b952ee..80d881f 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -494,7 +494,8 @@ static void intel_fbc_deactivate(struct drm_i915_private 
*dev_priv)
 
intel_fbc_cancel_work(dev_priv);
 
-   dev_priv->fbc.disable_fbc(dev_priv);
+   if (dev_priv->fbc.enabled)
+   dev_priv->fbc.disable_fbc(dev_priv);
 }
 
 static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
-- 
2.6.1

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

[Intel-gfx] [PATCH 17/26] drm/i915: fix the CFB size check

In function find_compression_threshold() we try to over-allocate CFB
space in order to reudce reallocations and fragmentation, and we're
not considering that at the CFB size check. Consider it.

There is also a longer-term plan to kill
dev_priv->fbc.uncompressed_size, but this will come later.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 17f098d..29d61d1 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -743,7 +743,8 @@ static int intel_fbc_setup_cfb(struct intel_crtc *crtc)
size = intel_fbc_calculate_cfb_size(crtc);
cpp = drm_format_plane_cpp(fb->pixel_format, 0);
 
-   if (size <= dev_priv->fbc.uncompressed_size)
+   if (dev_priv->fbc.compressed_fb.allocated &&
+   size <= dev_priv->fbc.compressed_fb.size * dev_priv->fbc.threshold)
return 0;
 
/* Release any current block */
-- 
2.6.1

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

[Intel-gfx] [PATCH 15/26] drm/i915: introduce intel_fbc_{enable, disable}

The goal is to call FBC enable/disable only once per modeset, while
activate/deactivate/update will be called multiple times.

The enable() function will be responsible for deciding if a CRTC will
have FBC on it and then it will "lock" FBC on this CRTC: it won't be
possible to change FBC's CRTC until disable(). With this, all checks
and resource acquisition that only need to be done once per modeset
can be moved from update() to enable(). And then the update(),
activate() and deactivate() code will also get simpler since they
won't need to worry about the CRTC being changed.

The disable() function will do the reverse operation of enable(). One
of its features is that it should only be called while the pipe is
already off. This guarantees that FBC is stopped and nothing is
using the CFB.

With this, the activate() and deactivate() functions just start and
temporarily stop FBC. They are the ones touching the hardware enable
bit, so HW state reflects dev_priv->crtc.active.

The last function remaining is update(). A lot of times I thought
about renaming update() to activate() or try_to_activate() since it's
called when we want to activate FBC. The thing is that update() may
not only decide to activate FBC, but also deactivate or keep it on the
same state, so I'll leave this name for now.

Moving code to enable() and disable() will also help in case we decide
to move FBC to pipe_config or something else later.

THe current patch only puts the very basic code on enable() and
disable(). The next commits will take care of moving more stuff from
update() to the new functions.

v2:
  - Rebase.
  - Improve commit message (Chris).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/intel_display.c |  14 ++-
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_fbc.c | 196 +--
 4 files changed, 156 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index d4326e3..a9434d1 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -913,6 +913,7 @@ struct i915_fbc {
 
bool false_color;
 
+   bool enabled;
bool active;
 
struct intel_fbc_work {
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d1a5648..5f95531 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4809,7 +4809,7 @@ static void intel_pre_plane_update(struct intel_crtc 
*crtc)
intel_crtc_wait_for_pending_flips(&crtc->base);
 
if (atomic->disable_fbc)
-   intel_fbc_disable_crtc(crtc);
+   intel_fbc_deactivate(crtc);
 
if (crtc->atomic.disable_ips)
hsw_disable_ips(crtc);
@@ -4910,6 +4910,8 @@ static void ironlake_crtc_enable(struct drm_crtc *crtc)
 
if (HAS_PCH_CPT(dev))
cpt_verify_modeset(dev, intel_crtc->pipe);
+
+   intel_fbc_enable(intel_crtc);
 }
 
 /* IPS only exists on ULT machines and is tied to pipe A. */
@@ -5012,6 +5014,8 @@ static void haswell_crtc_enable(struct drm_crtc *crtc)
intel_wait_for_vblank(dev, hsw_workaround_pipe);
intel_wait_for_vblank(dev, hsw_workaround_pipe);
}
+
+   intel_fbc_enable(intel_crtc);
 }
 
 static void ironlake_pfit_disable(struct intel_crtc *crtc, bool force)
@@ -5078,6 +5082,8 @@ static void ironlake_crtc_disable(struct drm_crtc *crtc)
 
ironlake_fdi_pll_disable(intel_crtc);
}
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void haswell_crtc_disable(struct drm_crtc *crtc)
@@ -5124,6 +5130,8 @@ static void haswell_crtc_disable(struct drm_crtc *crtc)
for_each_encoder_on_crtc(dev, crtc, encoder)
if (encoder->post_disable)
encoder->post_disable(encoder);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void i9xx_pfit_enable(struct intel_crtc *crtc)
@@ -6183,6 +6191,8 @@ static void i9xx_crtc_enable(struct drm_crtc *crtc)
 
for_each_encoder_on_crtc(dev, crtc, encoder)
encoder->enable(encoder);
+
+   intel_fbc_enable(intel_crtc);
 }
 
 static void i9xx_pfit_disable(struct intel_crtc *crtc)
@@ -6245,6 +6255,8 @@ static void i9xx_crtc_disable(struct drm_crtc *crtc)
 
if (!IS_GEN2(dev))
intel_set_cpu_fifo_underrun_reporting(dev_priv, pipe, false);
+
+   intel_fbc_disable_crtc(intel_crtc);
 }
 
 static void intel_crtc_disable_noatomic(struct drm_crtc *crtc)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 0debbe9..eef98a2 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1296,8 +1296,10 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 
 /* intel_fbc.c */
 bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
+void intel_fbc_deactiv

[Intel-gfx] [PATCH 09/26] drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()

This change was part of the commit that makes intel_fbc_update()
receive an intel_crtc as argument instead of dev_priv, but since it
was polluting the diff with too many chunks I decided to move it to
its own commit.

It seems that our developers are favoring having this instead of the
old combination drm_crtc *crtc + intel_crtc *intel_crtc, and on the
mentioned commit we'll get rid of the drm_crtc variable, so let's do
an intermediate commit with the rename, so on the next commit we'll
have just struct intel_crtc *crtc.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 30 +++---
 1 file changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 96d502e..06bdc27 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -878,8 +878,8 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
  */
 static void __intel_fbc_update(struct drm_i915_private *dev_priv)
 {
-   struct drm_crtc *crtc = NULL;
-   struct intel_crtc *intel_crtc;
+   struct drm_crtc *drm_crtc = NULL;
+   struct intel_crtc *crtc;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
const struct drm_display_mode *adjusted_mode;
@@ -909,8 +909,8 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 *   - new fb is too large to fit in compressed buffer
 *   - going to an unsupported config (interlace, pixel multiply, etc.)
 */
-   crtc = intel_fbc_find_crtc(dev_priv);
-   if (!crtc) {
+   drm_crtc = intel_fbc_find_crtc(dev_priv);
+   if (!drm_crtc) {
set_no_fbc_reason(dev_priv, "no output");
goto out_disable;
}
@@ -920,10 +920,10 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   intel_crtc = to_intel_crtc(crtc);
-   fb = crtc->primary->fb;
+   crtc = to_intel_crtc(drm_crtc);
+   fb = crtc->base.primary->fb;
obj = intel_fb_obj(fb);
-   adjusted_mode = &intel_crtc->config->base.adjusted_mode;
+   adjusted_mode = &crtc->config->base.adjusted_mode;
 
if ((adjusted_mode->flags & DRM_MODE_FLAG_INTERLACE) ||
(adjusted_mode->flags & DRM_MODE_FLAG_DBLSCAN)) {
@@ -931,13 +931,13 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   if (!intel_fbc_hw_tracking_covers_screen(intel_crtc)) {
+   if (!intel_fbc_hw_tracking_covers_screen(crtc)) {
set_no_fbc_reason(dev_priv, "mode too large for compression");
goto out_disable;
}
 
if ((INTEL_INFO(dev_priv)->gen < 4 || HAS_DDI(dev_priv)) &&
-   intel_crtc->plane != PLANE_A) {
+   crtc->plane != PLANE_A) {
set_no_fbc_reason(dev_priv, "FBC unsupported on plane");
goto out_disable;
}
@@ -951,7 +951,7 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
if (INTEL_INFO(dev_priv)->gen <= 4 && !IS_G4X(dev_priv) &&
-   crtc->primary->state->rotation != BIT(DRM_ROTATE_0)) {
+   crtc->base.primary->state->rotation != BIT(DRM_ROTATE_0)) {
set_no_fbc_reason(dev_priv, "rotation unsupported");
goto out_disable;
}
@@ -974,13 +974,13 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 
/* WaFbcExceedCdClockThreshold:hsw,bdw */
if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
-   ilk_pipe_pixel_rate(intel_crtc->config) >=
+   ilk_pipe_pixel_rate(crtc->config) >=
dev_priv->cdclk_freq * 95 / 100) {
set_no_fbc_reason(dev_priv, "pixel rate is too big");
goto out_disable;
}
 
-   if (intel_fbc_setup_cfb(intel_crtc)) {
+   if (intel_fbc_setup_cfb(crtc)) {
set_no_fbc_reason(dev_priv, "not enough stolen memory");
goto out_disable;
}
@@ -990,9 +990,9 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 * cannot be unpinned (and have its GTT offset and fence revoked)
 * without first being decoupled from the scanout and FBC disabled.
 */
-   if (dev_priv->fbc.crtc == intel_crtc &&
+   if (dev_priv->fbc.crtc == crtc &&
dev_priv->fbc.fb_id == fb->base.id &&
-   dev_priv->fbc.y == crtc->y)
+   dev_priv->fbc.y == crtc->base.y)
return;
 
if (intel_fbc_enabled(dev_priv)) {
@@ -1023,7 +1023,7 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
__intel_fbc_disable(dev_priv);
}
 
-   intel_fbc_schedule_enable(intel_crtc);
+   intel_fbc_schedule_enable(crtc);
dev_priv->fbc.no_fbc_reason = "FBC enabled (not necessar

[Intel-gfx] [PATCH 18/26] drm/i915: alloc/free the FBC CFB during enable/disable

One of the problems with the current code is that it frees the CFB and
releases its drm_mm node as soon as we flip FBC's enable bit. This is
bad because after we disbale FBC the hardware may still use the CFB
for the rest of the frame, so in theory we should only release the
drm_mm node one frame after we disable FBC. Otherwise, a stolen memory
allocation done right after an FBC disable may result in either
corrupted memory for the new owner of that memory region or corrupted
screen/underruns in case the new owner changes it while the hardware
is still reading it. This case is not exactly easy to reproduce since
we currently don't do a lot of stolen memory allocations, but I see
patches on the mailing list trying to expose stolen memory to user
space, so races will be possible.

I thought about three different approaches to solve this, and they all
have downsides.

The first approach would be to simply use multiple drm_mm nodes and
freeing the unused ones only after a frame has passed. The problem
with this approach is that since stolen memory is rather small,
there's a risk we just won't be able to allocate a new CFB from stolen
if the previous one was not freed yet. This could happen in case we
quickly disable FBC from pipe A and decide to enable it on pipe B, or
just if we change pipe A's fb stride while FBC is enabled.

The second approach would be similar to the first one, but maintaining
a single drm_mm node and keeping track of when it can be reused. This
would remove the disadvantage of not having enough space for two
nodes, but would create the new problem where we may not be able to
enable FBC at the point intel_fbc_update() is called, so we would have
to add more code to retry updating FBC after the time has passed. And
that can quickly get too complex since we can get invalidate, flush,
flip_prepare, disable and other calls in the middle of the wait.

Both solutions above - and also the current code - have the problem
that we unnecessarily free+realloc FBC during invalidate+flush
operations even if the CFB size doesn't change.

The third option would be to move the allocation/deallocation to
enable/disable. This makes sure that the pipe is always disabled when
we allocate/deallocate the CFB, so there's no risk that the FBC
hardware may read or write to the memory right after it is freed from
drm_mm. The downside is that it is possible for user space to change
the buffer stride without triggering a disable/enable - only
deactivate/activate -, so we'll have to handle this case somehow, even
though it is uncommon - see igt's kms_frontbuffer_tracking test,
fbc-stridechange subtest. It could be possible to implement a way to
free+alloc the CFB during said stride change, but it would involve a
lot of book-keeping - exactly as mentioned above - just for a rare
case, so for now I'll keep it simple and just deactivate FBC. Besides,
we may not even need to disable FBC since we do CFB over-allocation.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 132 ---
 1 file changed, 68 insertions(+), 64 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 29d61d1..0ba25b9 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -64,6 +64,45 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
return crtc->base.y - crtc->adjusted_y;
 }
 
+/*
+ * For SKL+, the plane source size used by the hardware is based on the value 
we
+ * write to the PLANE_SIZE register. For BDW-, the hardware looks at the value
+ * we wrote to PIPESRC.
+ */
+static void intel_fbc_get_plane_source_size(struct intel_crtc *crtc,
+   int *width, int *height)
+{
+   struct intel_plane_state *plane_state =
+   to_intel_plane_state(crtc->base.primary->state);
+   int w, h;
+
+   if (intel_rotation_90_or_270(plane_state->base.rotation)) {
+   w = drm_rect_height(&plane_state->src) >> 16;
+   h = drm_rect_width(&plane_state->src) >> 16;
+   } else {
+   w = drm_rect_width(&plane_state->src) >> 16;
+   h = drm_rect_height(&plane_state->src) >> 16;
+   }
+
+   if (width)
+   *width = w;
+   if (height)
+   *height = h;
+}
+
+static int intel_fbc_calculate_cfb_size(struct intel_crtc *crtc,
+   struct drm_framebuffer *fb)
+{
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   int lines;
+
+   intel_fbc_get_plane_source_size(crtc, NULL, &lines);
+   if (INTEL_INFO(dev_priv)->gen >= 7)
+   lines = min(lines, 2048);
+
+   return lines * fb->pitches[0];
+}
+
 static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
u32 fbc_ctl;
@@ -614,11 +653,17 @@ again:
}
 }
 
-static int intel_fbc_alloc_cfb(struct drm_i915_private *dev_p

[Intel-gfx] [PATCH 20/26] drm/i915: move clock frequency checks from fbc_update to fbc_enable

These also can't change without a full modeset.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 16 
 1 file changed, 8 insertions(+), 8 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 6aa9af8..a9f133a 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -885,14 +885,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
goto out_disable;
}
 
-   /* WaFbcExceedCdClockThreshold:hsw,bdw */
-   if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
-   ilk_pipe_pixel_rate(crtc->config) >=
-   dev_priv->cdclk_freq * 95 / 100) {
-   set_no_fbc_reason(dev_priv, "pixel rate is too big");
-   goto out_disable;
-   }
-
/* It is possible for the required CFB size change without a
 * crtc->disable + crtc->enable since it is possible to change the
 * stride without triggering a full modeset. Since we try to
@@ -1110,6 +1102,14 @@ void intel_fbc_enable(struct intel_crtc *crtc)
goto out;
}
 
+   /* WaFbcExceedCdClockThreshold:hsw,bdw */
+   if ((IS_HASWELL(dev_priv) || IS_BROADWELL(dev_priv)) &&
+   ilk_pipe_pixel_rate(crtc->config) >=
+   dev_priv->cdclk_freq * 95 / 100) {
+   set_no_fbc_reason(dev_priv, "pixel rate is too big");
+   goto out;
+   }
+
if (intel_fbc_alloc_cfb(crtc)) {
set_no_fbc_reason(dev_priv, "not enough stolen memory");
goto out;
-- 
2.6.1

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

[Intel-gfx] [PATCH 23/26] drm/i915: use a single intel_fbc_work struct

This was already on my TODO list, and was requested both by Chris and
Ville, for different reasons. The advantages are avoiding a frequent
malloc/free pair, and the locality of having the work structure
embedded in dev_priv. The maximum used memory is also smaller since
previously we could have multiple allocated intel_fbc_work structs at
the same time, and now we'll always have a single one - the one
embedded on dev_priv. Of course, we're now using a little more memory
on the cases where there's nothing scheduled.

The biggest challenge here is to keep everything synchronized the way
it was before.

Currently, when we try to activate FBC, we allocate a new
intel_fbc_work structure. Then later when we conclude we must delay
the FBC activation a little more, we allocate a new intel_fbc_work
struct, and then adjust dev_priv->fbc.fbc_work to point to the new
struct. So when the old work runs - at intel_fbc_work_fn() - it will
check that dev_priv->fbc.fbc_work points to something else, so it does
nothing. Everything is also protected by fbc.lock.

Just cancelling the old delayed work doesn't work because we might
just cancel it after the work function already started to run, but
while it is still waiting to grab fbc.lock. That's why we use the
"dev_priv->fbc.fbc_work == work" check described in the paragraph
above.

So now that we have a single work struct we have to introduce a new
way to synchronize everything. So we're making the work function a
normal work instead of a delayed work, and it will be responsible for
sleeping the appropriate amount of time itself. This way, after it
wakes up it can grab the lock, ask "were we delayed or cancelled?" and
then go back to sleep, enable FBC or give up.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   6 ++-
 drivers/gpu/drm/i915/intel_fbc.c | 108 +--
 2 files changed, 52 insertions(+), 62 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index a9434d1..fdbe068 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -917,9 +917,11 @@ struct i915_fbc {
bool active;
 
struct intel_fbc_work {
-   struct delayed_work work;
+   bool scheduled;
+   struct work_struct work;
struct drm_framebuffer *fb;
-   } *fbc_work;
+   unsigned long enable_jiffies;
+   } work;
 
const char *no_fbc_reason;
 
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 4bb2323..a7192dd 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -444,85 +444,71 @@ static void intel_fbc_activate(const struct 
drm_framebuffer *fb)
 
 static void intel_fbc_work_fn(struct work_struct *__work)
 {
-   struct intel_fbc_work *work =
-   container_of(to_delayed_work(__work),
-struct intel_fbc_work, work);
-   struct drm_i915_private *dev_priv = work->fb->dev->dev_private;
-   struct drm_framebuffer *crtc_fb = dev_priv->fbc.crtc->base.primary->fb;
+   struct drm_i915_private *dev_priv =
+   container_of(__work, struct drm_i915_private, fbc.work.work);
+   struct intel_fbc_work *work = &dev_priv->fbc.work;
+   struct intel_crtc *crtc = dev_priv->fbc.crtc;
+   unsigned long delay_jiffies = msecs_to_jiffies(50);
+
+retry:
+   /* Delay the actual enabling to let pageflipping cease and the
+* display to settle before starting the compression. Note that
+* this delay also serves a second purpose: it allows for a
+* vblank to pass after disabling the FBC before we attempt
+* to modify the control registers.
+*
+* A more complicated solution would involve tracking vblanks
+* following the termination of the page-flipping sequence
+* and indeed performing the enable as a co-routine and not
+* waiting synchronously upon the vblank.
+*
+* WaFbcWaitForVBlankBeforeEnable:ilk,snb
+*/
+   wait_remaining_ms_from_jiffies(work->enable_jiffies, delay_jiffies);
 
mutex_lock(&dev_priv->fbc.lock);
-   if (work == dev_priv->fbc.fbc_work) {
-   /* Double check that we haven't switched fb without cancelling
-* the prior work.
-*/
-   if (crtc_fb == work->fb)
-   intel_fbc_activate(work->fb);
 
-   dev_priv->fbc.fbc_work = NULL;
+   /* Were we cancelled? */
+   if (!work->scheduled)
+   goto out;
+
+   /* Were we delayed again while this function was sleeping? */
+   if (time_after(work->enable_jiffies + delay_jiffies, jiffies)) {
+   mutex_unlock(&dev_priv->fbc.lock);
+   goto retry;
}
-   mutex_unlock(&dev_priv->fbc.lock);
 
-   kfree(work);
+   if (crtc->base.primary->fb == work->fb)
+

[Intel-gfx] [PATCH 25/26] drm/i915: remove in_dbg_master check from intel_fbc.c

From our maintainer Daniel Vetter a few days ago:
  "Oh dear this is dead code. kdbg uses the fbcon, which always uses
  untiled, which means fbc will never be enabled. Also we have 0 users
  and 0 test coverage for kdbg on top of i915 (Jesse implemented it
  for fun years back). Imo just remove all this code."

Adding to what Daniel said: for kgdboc's KMS support,
intel_pipe_set_base_atomic() already manually disables FBC, so we
won't do the in_dbg_master() check there. This is essentially a revert
of:

commit c924b934d0cd14a4559611da91f28f59acebe32a
Author: Jason Wessel 
Date:   Thu Aug 5 09:22:32 2010 -0500
i915: when kgdb is active display compression should be off

Besides, it is not clear what is the exact problem caused by FBC, and
why other features such as PSR, DRRS, IPS and RPM are not also
checking for in_dbg_master(). IMHO we should either remove the code as
suggested by Daniel or we add some nice comments explaining why is FBC
so special.

Cc: Jason Wessel 
Cc: Jesse Barnes 
Cc: Daniel Vetter 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index cbdf2f3..ba31359 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -857,12 +857,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
goto out_disable;
}
 
-   /* If the kernel debugger is active, always disable compression */
-   if (in_dbg_master()) {
-   set_no_fbc_reason(dev_priv, "Kernel debugger is active");
-   goto out_disable;
-   }
-
/* It is possible for the required CFB size change without a
 * crtc->disable + crtc->enable since it is possible to change the
 * stride without triggering a full modeset. Since we try to
-- 
2.6.1

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

[Intel-gfx] [PATCH 10/26] drm/i915: fix the __intel_fbc_update() comments

Don't try to list in comments the cases where we should enable or
disable FBC: it varies a lot with the hardware generations and the
code should be the documentation. Also notice that there's already a
huge gap between the comments and what's in the code.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 26 ++
 1 file changed, 2 insertions(+), 24 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 06bdc27..1b39037 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -861,20 +861,8 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
  * @dev_priv: i915 device instance
  *
- * Set up the framebuffer compression hardware at mode set time.  We
- * enable it if possible:
- *   - plane A only (on pre-965)
- *   - no pixel mulitply/line duplication
- *   - no alpha buffer discard
- *   - no dual wide
- *   - framebuffer <= max_hdisplay in width, max_vdisplay in height
- *
- * We can't assume that any compression will take place (worst case),
- * so the compressed buffer has to be the same size as the uncompressed
- * one.  It also must reside (along with the line length buffer) in
- * stolen memory.
- *
- * We need to enable/disable FBC on a global basis.
+ * This function completely reevaluates the status of FBC, then enables,
+ * disables or maintains it on the same state.
  */
 static void __intel_fbc_update(struct drm_i915_private *dev_priv)
 {
@@ -886,7 +874,6 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
 
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
-   /* disable framebuffer compression in vGPU */
if (intel_vgpu_active(dev_priv->dev))
i915.enable_fbc = 0;
 
@@ -900,15 +887,6 @@ static void __intel_fbc_update(struct drm_i915_private 
*dev_priv)
goto out_disable;
}
 
-   /*
-* If FBC is already on, we just have to verify that we can
-* keep it that way...
-* Need to disable if:
-*   - more than one pipe is active
-*   - changing FBC params (stride, fence, mode)
-*   - new fb is too large to fit in compressed buffer
-*   - going to an unsupported config (interlace, pixel multiply, etc.)
-*/
drm_crtc = intel_fbc_find_crtc(dev_priv);
if (!drm_crtc) {
set_no_fbc_reason(dev_priv, "no output");
-- 
2.6.1

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

[Intel-gfx] [PATCH 21/26] drm/i915: check for FBC planes in the same place as the pipes

This moves the pre-gen4 check from update() to enable(). The HAS_DDI
in the original code is not needed since only gen 2/3 have the plane
swapping code.

v2: Rebase.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index a9f133a..01807c5 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -570,6 +570,9 @@ static bool crtc_can_fbc(struct intel_crtc *crtc)
if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
return false;
 
+   if (INTEL_INFO(dev_priv)->gen < 4 && crtc->plane != PLANE_A)
+   return false;
+
return true;
 }
 
@@ -849,12 +852,6 @@ static void __intel_fbc_update(struct intel_crtc *crtc)
goto out_disable;
}
 
-   if ((INTEL_INFO(dev_priv)->gen < 4 || HAS_DDI(dev_priv)) &&
-   crtc->plane != PLANE_A) {
-   set_no_fbc_reason(dev_priv, "FBC unsupported on plane");
-   goto out_disable;
-   }
-
/* The use of a CPU fence is mandatory in order to detect writes
 * by the CPU to the scanout and trigger updates to the FBC.
 */
-- 
2.6.1

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

[Intel-gfx] [PATCH 13/26] drm/i915: introduce is_active/activate/deactivate to the FBC terminology

The long term goal is to have enable/disable as the higher level
functions and activate/deactivate as the lower level functions, just
like we do for PSR and for the CRTC. This way, we'll run enable and
disable once per modeset, while update, activate and deactivate will
be run many times. With this, we can move the checks and code that
need to run only once per modeset to enable(), making the code simpler
and possibly a little faster.

This patch is just the first step on the conversion: it starts by
converting the current low level functions from enable/disable to
activate/deactivate. This patch by itself has no benefits other than
making review and rebase easier. Please see the next patches for more
details on the conversion.

v2:
  - Rebase.
  - Improve commit message (Chris).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_debugfs.c  |   2 +-
 drivers/gpu/drm/i915/i915_drv.h  |  10 ++-
 drivers/gpu/drm/i915/intel_display.c |   4 +-
 drivers/gpu/drm/i915/intel_drv.h |   2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 116 +--
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 6 files changed, 67 insertions(+), 69 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index fbde0a4..1d6bb95 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1636,7 +1636,7 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
intel_runtime_pm_get(dev_priv);
mutex_lock(&dev_priv->fbc.lock);
 
-   if (intel_fbc_enabled(dev_priv))
+   if (intel_fbc_is_active(dev_priv))
seq_puts(m, "FBC enabled\n");
else
seq_printf(m, "FBC disabled: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 6d7b42d..d4326e3 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -913,9 +913,7 @@ struct i915_fbc {
 
bool false_color;
 
-   /* Tracks whether the HW is actually enabled, not whether the feature is
-* possible. */
-   bool enabled;
+   bool active;
 
struct intel_fbc_work {
struct delayed_work work;
@@ -924,9 +922,9 @@ struct i915_fbc {
 
const char *no_fbc_reason;
 
-   bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
-   void (*enable_fbc)(struct intel_crtc *crtc);
-   void (*disable_fbc)(struct drm_i915_private *dev_priv);
+   bool (*is_active)(struct drm_i915_private *dev_priv);
+   void (*activate)(struct intel_crtc *crtc);
+   void (*deactivate)(struct drm_i915_private *dev_priv);
void (*flip_prepare)(struct drm_i915_private *dev_priv);
 };
 
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 820ad1e..2392f47 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -3173,8 +3173,8 @@ intel_pipe_set_base_atomic(struct drm_crtc *crtc, struct 
drm_framebuffer *fb,
struct drm_device *dev = crtc->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
 
-   if (dev_priv->fbc.disable_fbc)
-   dev_priv->fbc.disable_fbc(dev_priv);
+   if (dev_priv->fbc.deactivate)
+   dev_priv->fbc.deactivate(dev_priv);
 
dev_priv->display.update_primary_plane(crtc, fb, x, y);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index b463bae..0debbe9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1295,7 +1295,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 #endif
 
 /* intel_fbc.c */
-bool intel_fbc_enabled(struct drm_i915_private *dev_priv);
+bool intel_fbc_is_active(struct drm_i915_private *dev_priv);
 void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 80d881f..6f020fc 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -43,7 +43,7 @@
 
 static inline bool fbc_supported(struct drm_i915_private *dev_priv)
 {
-   return dev_priv->fbc.enable_fbc != NULL;
+   return dev_priv->fbc.activate != NULL;
 }
 
 static inline bool fbc_on_pipe_a_only(struct drm_i915_private *dev_priv)
@@ -64,11 +64,11 @@ static unsigned int get_crtc_fence_y_offset(struct 
intel_crtc *crtc)
return crtc->base.y - crtc->adjusted_y;
 }
 
-static void i8xx_fbc_disable(struct drm_i915_private *dev_priv)
+static void i8xx_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
u32 fbc_ctl;
 
-   dev_priv->fbc.enabled = false;
+   dev_priv->fbc.active = false;
 
/* Disable compression */
fbc_ctl = I915_READ(FBC_CONTROL);
@@ -84,7 +84,7 @@ static void i8xx_fbc_disable(struct drm_i915_private 
*dev_priv)

[Intel-gfx] [PATCH 22/26] drm/i915: clarify that checking the FB stride for CFB is intentional

Daniel was looking at this code and asked about whether fb->pitches[0]
is correct, then he suggested we should a comment to make sure it is
actually intentional.

For more information on the CFB size calculation, please see the
commit message of:

commit c4ffd40908c30a33291227920e921f6b45b9e8f7
Author: Paulo Zanoni 
Date:   Thu Oct 1 19:55:57 2015 -0300
drm/i915: fix CFB size calculation

Requested-by: Daniel Vetter 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 01807c5..4bb2323 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -100,6 +100,7 @@ static int intel_fbc_calculate_cfb_size(struct intel_crtc 
*crtc,
if (INTEL_INFO(dev_priv)->gen >= 7)
lines = min(lines, 2048);
 
+   /* Hardware needs the full buffer stride, not just the active area. */
return lines * fb->pitches[0];
 }
 
-- 
2.6.1

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

[Intel-gfx] [PATCH 07/26] drm/i915: extract crtc_is_valid() on the FBC code

We're going to kill intel_fbc_find_crtc(), that's why a big part of
the logic moved from intel_fbc_find_crtc() to crtc_is_valid().

v2:
  - Rebase due to pipe_a_only change.
  - Split the multiline conditional (Chris).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 18479bc..c513e4d 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -544,6 +544,22 @@ static void set_no_fbc_reason(struct drm_i915_private 
*dev_priv,
DRM_DEBUG_KMS("Disabling FBC: %s\n", reason);
 }
 
+static bool crtc_is_valid(struct intel_crtc *crtc)
+{
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+
+   if (fbc_on_pipe_a_only(dev_priv) && crtc->pipe != PIPE_A)
+   return false;
+
+   if (!intel_crtc_active(&crtc->base))
+   return false;
+
+   if (!to_intel_plane_state(crtc->base.primary->state)->visible)
+   return false;
+
+   return true;
+}
+
 static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
 {
struct drm_crtc *crtc = NULL, *tmp_crtc;
@@ -552,12 +568,8 @@ static struct drm_crtc *intel_fbc_find_crtc(struct 
drm_i915_private *dev_priv)
for_each_pipe(dev_priv, pipe) {
tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
 
-   if (intel_crtc_active(tmp_crtc) &&
-   to_intel_plane_state(tmp_crtc->primary->state)->visible)
+   if (crtc_is_valid(to_intel_crtc(tmp_crtc)))
crtc = tmp_crtc;
-
-   if (fbc_on_pipe_a_only(dev_priv))
-   break;
}
 
if (!crtc)
-- 
2.6.1

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

[Intel-gfx] [PATCH 24/26] drm/i915: wait for a vblank instead of 50ms when enabling FBC

Instead of waiting for 50ms, just wait until the next vblank, since
it's the minimum requirement.

This moves PC7 residency on my specific BDW machine running Cinnamon
from 60-70% to 84-89%. Without FBC, I get 20-25%. I'm using a
3200x1800 eDP panel.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 12 +++-
 2 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index fdbe068..784ce2e 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -918,9 +918,9 @@ struct i915_fbc {
 
struct intel_fbc_work {
bool scheduled;
+   u32 scheduled_vblank;
struct work_struct work;
struct drm_framebuffer *fb;
-   unsigned long enable_jiffies;
} work;
 
const char *no_fbc_reason;
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index a7192dd..cbdf2f3 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -448,7 +448,6 @@ static void intel_fbc_work_fn(struct work_struct *__work)
container_of(__work, struct drm_i915_private, fbc.work.work);
struct intel_fbc_work *work = &dev_priv->fbc.work;
struct intel_crtc *crtc = dev_priv->fbc.crtc;
-   unsigned long delay_jiffies = msecs_to_jiffies(50);
 
 retry:
/* Delay the actual enabling to let pageflipping cease and the
@@ -457,14 +456,9 @@ retry:
 * vblank to pass after disabling the FBC before we attempt
 * to modify the control registers.
 *
-* A more complicated solution would involve tracking vblanks
-* following the termination of the page-flipping sequence
-* and indeed performing the enable as a co-routine and not
-* waiting synchronously upon the vblank.
-*
 * WaFbcWaitForVBlankBeforeEnable:ilk,snb
 */
-   wait_remaining_ms_from_jiffies(work->enable_jiffies, delay_jiffies);
+   intel_wait_for_vblank(dev_priv->dev, crtc->pipe);
 
mutex_lock(&dev_priv->fbc.lock);
 
@@ -473,7 +467,7 @@ retry:
goto out;
 
/* Were we delayed again while this function was sleeping? */
-   if (time_after(work->enable_jiffies + delay_jiffies, jiffies)) {
+   if (drm_crtc_vblank_get(&crtc->base) == work->scheduled_vblank) {
mutex_unlock(&dev_priv->fbc.lock);
goto retry;
}
@@ -506,7 +500,7 @@ static void intel_fbc_schedule_activation(struct intel_crtc 
*crtc)
 * jiffy count. */
work->fb = crtc->base.primary->fb;
work->scheduled = true;
-   work->enable_jiffies = jiffies;
+   work->scheduled_vblank = drm_crtc_vblank_count(&crtc->base);
 
schedule_work(&work->work);
 }
-- 
2.6.1

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

[Intel-gfx] [PATCH 11/26] drm/i915: pass the crtc as an argument to intel_fbc_update()

There's no need to reevaluate the status of every single crtc when a
single crtc changes its state.

With this, we're cutting the case where due to a change in pipe B,
intel_fbc_update() is called, then intel_fbc_find_crtc() concludes FBC
should be enabled on pipe A, then it completely rechecks the state of
pipe A only to conclude FBC should remain enabled on pipe A. If any
change on pipe A triggers a need to recompute whether FBC is valid on
pipe A, then at some point someone is going to call
intel_fbc_update(PIPE_A).

The addition of intel_fbc_deactivate() is necessary so we keep track
of the previously selected CRTC when we do invalidate/flush. We're
also going to continue the enable/disable/activate/deactivate concept
in the next patches.

v2: Rebase.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c |  3 +-
 drivers/gpu/drm/i915/intel_drv.h |  2 +-
 drivers/gpu/drm/i915/intel_fbc.c | 68 +++-
 3 files changed, 31 insertions(+), 42 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index d9378c3..820ad1e 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -4778,7 +4778,6 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
 {
struct intel_crtc_atomic_commit *atomic = &crtc->atomic;
struct drm_device *dev = crtc->base.dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
 
if (atomic->wait_vblank)
intel_wait_for_vblank(dev, crtc->pipe);
@@ -4792,7 +4791,7 @@ static void intel_post_plane_update(struct intel_crtc 
*crtc)
intel_update_watermarks(&crtc->base);
 
if (atomic->update_fbc)
-   intel_fbc_update(dev_priv);
+   intel_fbc_update(crtc);
 
if (atomic->post_enable_primary)
intel_post_enable_primary(&crtc->base);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 9065a8f..b463bae 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1296,7 +1296,7 @@ static inline void intel_fbdev_restore_mode(struct 
drm_device *dev)
 
 /* intel_fbc.c */
 bool intel_fbc_enabled(struct drm_i915_private *dev_priv);
-void intel_fbc_update(struct drm_i915_private *dev_priv);
+void intel_fbc_update(struct intel_crtc *crtc);
 void intel_fbc_init(struct drm_i915_private *dev_priv);
 void intel_fbc_disable(struct drm_i915_private *dev_priv);
 void intel_fbc_disable_crtc(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 1b39037..6b952ee 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -488,13 +488,18 @@ static void intel_fbc_schedule_enable(struct intel_crtc 
*crtc)
schedule_delayed_work(&work->work, msecs_to_jiffies(50));
 }
 
-static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
+static void intel_fbc_deactivate(struct drm_i915_private *dev_priv)
 {
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
intel_fbc_cancel_work(dev_priv);
 
dev_priv->fbc.disable_fbc(dev_priv);
+}
+
+static void __intel_fbc_disable(struct drm_i915_private *dev_priv)
+{
+   intel_fbc_deactivate(dev_priv);
dev_priv->fbc.crtc = NULL;
 }
 
@@ -559,24 +564,6 @@ static bool crtc_is_valid(struct intel_crtc *crtc)
return true;
 }
 
-static struct drm_crtc *intel_fbc_find_crtc(struct drm_i915_private *dev_priv)
-{
-   struct drm_crtc *crtc = NULL, *tmp_crtc;
-   enum pipe pipe;
-
-   for_each_pipe(dev_priv, pipe) {
-   tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
-
-   if (crtc_is_valid(to_intel_crtc(tmp_crtc)))
-   crtc = tmp_crtc;
-   }
-
-   if (!crtc)
-   return NULL;
-
-   return crtc;
-}
-
 static bool multiple_pipes_ok(struct drm_i915_private *dev_priv)
 {
enum pipe pipe;
@@ -859,21 +846,28 @@ static bool intel_fbc_hw_tracking_covers_screen(struct 
intel_crtc *crtc)
 
 /**
  * __intel_fbc_update - enable/disable FBC as needed, unlocked
- * @dev_priv: i915 device instance
+ * @crtc: the CRTC that triggered the update
  *
  * This function completely reevaluates the status of FBC, then enables,
  * disables or maintains it on the same state.
  */
-static void __intel_fbc_update(struct drm_i915_private *dev_priv)
+static void __intel_fbc_update(struct intel_crtc *crtc)
 {
-   struct drm_crtc *drm_crtc = NULL;
-   struct intel_crtc *crtc;
+   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
struct drm_framebuffer *fb;
struct drm_i915_gem_object *obj;
const struct drm_display_mode *adjusted_mode;
 
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
+   if (!multiple_pipes_ok(dev_priv)) {
+   set_no_fbc_reason(dev_priv, "more than one pipe active");
+   goto

[Intel-gfx] [PATCH 01/26] drm/i915: change no_fbc_reason from enum to string

I wanted to add yet another check to intel_fbc_update() and realized
I would need to create yet another enum no_fbc_reason case. So I
remembered this patch series that Damien wrote a long time ago and
nobody ever reviewed, so I decided to reimplement it since the code
changed a lot since then.

Credits-to: Damien Lespiau 
Cc: Damien Lespiau 
Reviewed-by: Daniel Vetter 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  2 +-
 drivers/gpu/drm/i915/i915_drv.h | 19 +
 drivers/gpu/drm/i915/intel_drv.h|  1 -
 drivers/gpu/drm/i915/intel_fbc.c| 77 +
 4 files changed, 20 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 89ba549..fbde0a4 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -1640,7 +1640,7 @@ static int i915_fbc_status(struct seq_file *m, void 
*unused)
seq_puts(m, "FBC enabled\n");
else
seq_printf(m, "FBC disabled: %s\n",
- intel_no_fbc_reason_str(dev_priv->fbc.no_fbc_reason));
+  dev_priv->fbc.no_fbc_reason);
 
if (INTEL_INFO(dev_priv)->gen >= 7)
seq_printf(m, "Compressing: %s\n",
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b408ebf..ee14962 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -923,24 +923,7 @@ struct i915_fbc {
struct drm_framebuffer *fb;
} *fbc_work;
 
-   enum no_fbc_reason {
-   FBC_OK, /* FBC is enabled */
-   FBC_UNSUPPORTED, /* FBC is not supported by this chipset */
-   FBC_NO_OUTPUT, /* no outputs enabled to compress */
-   FBC_STOLEN_TOO_SMALL, /* not enough space for buffers */
-   FBC_UNSUPPORTED_MODE, /* interlace or doublescanned mode */
-   FBC_MODE_TOO_LARGE, /* mode too large for compression */
-   FBC_BAD_PLANE, /* fbc not supported on plane */
-   FBC_NOT_TILED, /* buffer not tiled */
-   FBC_MULTIPLE_PIPES, /* more than one pipe active */
-   FBC_MODULE_PARAM,
-   FBC_CHIP_DEFAULT, /* disabled by default on this chip */
-   FBC_ROTATION, /* rotation is not supported */
-   FBC_IN_DBG_MASTER, /* kernel debugger is active */
-   FBC_BAD_STRIDE, /* stride is not supported */
-   FBC_PIXEL_RATE, /* pixel rate is too big */
-   FBC_PIXEL_FORMAT /* pixel format is invalid */
-   } no_fbc_reason;
+   const char *no_fbc_reason;
 
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
void (*enable_fbc)(struct intel_crtc *crtc);
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 1a3bbdc..08847d0 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1305,7 +1305,6 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
  enum fb_op_origin origin);
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
-const char *intel_no_fbc_reason_str(enum no_fbc_reason reason);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index cf47352..d9d7e54 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -471,55 +471,14 @@ void intel_fbc_disable_crtc(struct intel_crtc *crtc)
mutex_unlock(&dev_priv->fbc.lock);
 }
 
-const char *intel_no_fbc_reason_str(enum no_fbc_reason reason)
-{
-   switch (reason) {
-   case FBC_OK:
-   return "FBC enabled but currently disabled in hardware";
-   case FBC_UNSUPPORTED:
-   return "unsupported by this chipset";
-   case FBC_NO_OUTPUT:
-   return "no output";
-   case FBC_STOLEN_TOO_SMALL:
-   return "not enough stolen memory";
-   case FBC_UNSUPPORTED_MODE:
-   return "mode incompatible with compression";
-   case FBC_MODE_TOO_LARGE:
-   return "mode too large for compression";
-   case FBC_BAD_PLANE:
-   return "FBC unsupported on plane";
-   case FBC_NOT_TILED:
-   return "framebuffer not tiled or fenced";
-   case FBC_MULTIPLE_PIPES:
-   return "more than one pipe active";
-   case FBC_MODULE_PARAM:
-   return "disabled per module param";
-   case FBC_CHIP_DEFAULT:
-   return "disabled per chip default";
-   case FBC_ROTATION:
-   return "rotation unsupported";
-   case FBC_IN_DBG_MASTER:
-   return "Kernel debugger is active";
-   case FBC_BAD_STRIDE:
-   return "framebuffer

[Intel-gfx] [PATCH 00/26] Yet another FBC series, v2

Hi

This series contains the 18 patches I sent last week + some new ones requested
by the reviewers. Many of those 18 patches changed due to rebasing and the
requested changes to the commit messages, so I figured it would be better to
just create a new email thread for the new stuff. As far as I know, every review
request is implemented here.

Thanks Chris for the reviews so far!
Paulo

Paulo Zanoni (26):
  drm/i915: change no_fbc_reason from enum to string
  drm/i915: don't stop+start FBC at every flip
  drm/i915: rename intel_fbc_nuke to intel_fbc_recompress
  drm/i915: only nuke FBC when a drawing operation triggers a flush
  drm/i915: extract fbc_on_pipe_a_only()
  drm/i915: remove unnecessary check for crtc->primary->fb
  drm/i915: extract crtc_is_valid() on the FBC code
  drm/i915: set dev_priv->fbc.crtc before scheduling the enable work
  drm/i915: use struct intel_crtc *crtc at __intel_fbc_update()
  drm/i915: fix the __intel_fbc_update() comments
  drm/i915: pass the crtc as an argument to intel_fbc_update()
  drm/i915: don't disable_fbc() if FBC is already disabled
  drm/i915: introduce is_active/activate/deactivate to the FBC
terminology
  drm/i915: refactor FBC deactivation at init
  drm/i915: introduce intel_fbc_{enable,disable}
  drm/i915: remove too-frequent FBC debug message
  drm/i915: fix the CFB size check
  drm/i915: alloc/free the FBC CFB during enable/disable
  drm/i915: move adjusted_mode checks from fbc_update to fbc_enable
  drm/i915: move clock frequency checks from fbc_update to fbc_enable
  drm/i915: check for FBC planes in the same place as the pipes
  drm/i915: clarify that checking the FB stride for CFB is intentional
  drm/i915: use a single intel_fbc_work struct
  drm/i915: wait for a vblank instead of 50ms when enabling FBC
  drm/i915: remove in_dbg_master check from intel_fbc.c
  drm/i915: kill fbc.uncompressed_size

 drivers/gpu/drm/i915/i915_debugfs.c  |   4 +-
 drivers/gpu/drm/i915/i915_drv.h  |  41 +-
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_display.c |  25 +-
 drivers/gpu/drm/i915/intel_drv.h |   9 +-
 drivers/gpu/drm/i915/intel_fbc.c | 842 +--
 drivers/gpu/drm/i915/intel_frontbuffer.c |   1 +
 drivers/gpu/drm/i915/intel_pm.c  |   2 +-
 8 files changed, 509 insertions(+), 418 deletions(-)

-- 
2.6.1

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

[Intel-gfx] [PATCH 08/26] drm/i915: set dev_priv->fbc.crtc before scheduling the enable work

This thing where we need to get the crtc either from the work
structure or the fbc structure itself is confusing and unnecessary.
Set fbc.crtc right when scheduling the enable work so we can always
use it.

The problem is not what gets passed and how to retrieve it. The
problem is that when we're in the other parts of the code we always
have to keep in mind that if FBC is already enabled we have to get the
CRTC from place A, if FBC is scheduled we have to get the CRTC from
place B, and if it's disabled there's no CRTC. Having a single place
to retrieve the CRTC from allows us to treat the "is enabled" and "is
scheduled" cases as the same case, reducing the mistake surface. I
guess I should add this to the commit message.

Besides the immediate advantages, this is also going to make one of
the next commits much simpler. And even later, when we introduce
enable/disable + activate/deactivate, this will be even simpler as
we'll set the CRTC at enable time. So all the
activate/deactivate/update code can just look at the single CRTC
variable regardless of the current state.

v2: Improve commit message (Chris).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |  1 -
 drivers/gpu/drm/i915/intel_fbc.c | 25 ++---
 2 files changed, 10 insertions(+), 16 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 77da500..6d7b42d 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -919,7 +919,6 @@ struct i915_fbc {
 
struct intel_fbc_work {
struct delayed_work work;
-   struct intel_crtc *crtc;
struct drm_framebuffer *fb;
} *fbc_work;
 
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index c513e4d..96d502e 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -391,14 +391,13 @@ bool intel_fbc_enabled(struct drm_i915_private *dev_priv)
return dev_priv->fbc.enabled;
 }
 
-static void intel_fbc_enable(struct intel_crtc *crtc,
-const struct drm_framebuffer *fb)
+static void intel_fbc_enable(const struct drm_framebuffer *fb)
 {
-   struct drm_i915_private *dev_priv = crtc->base.dev->dev_private;
+   struct drm_i915_private *dev_priv = fb->dev->dev_private;
+   struct intel_crtc *crtc = dev_priv->fbc.crtc;
 
dev_priv->fbc.enable_fbc(crtc);
 
-   dev_priv->fbc.crtc = crtc;
dev_priv->fbc.fb_id = fb->base.id;
dev_priv->fbc.y = crtc->base.y;
 }
@@ -408,8 +407,8 @@ static void intel_fbc_work_fn(struct work_struct *__work)
struct intel_fbc_work *work =
container_of(to_delayed_work(__work),
 struct intel_fbc_work, work);
-   struct drm_i915_private *dev_priv = work->crtc->base.dev->dev_private;
-   struct drm_framebuffer *crtc_fb = work->crtc->base.primary->fb;
+   struct drm_i915_private *dev_priv = work->fb->dev->dev_private;
+   struct drm_framebuffer *crtc_fb = dev_priv->fbc.crtc->base.primary->fb;
 
mutex_lock(&dev_priv->fbc.lock);
if (work == dev_priv->fbc.fbc_work) {
@@ -417,7 +416,7 @@ static void intel_fbc_work_fn(struct work_struct *__work)
 * the prior work.
 */
if (crtc_fb == work->fb)
-   intel_fbc_enable(work->crtc, work->fb);
+   intel_fbc_enable(work->fb);
 
dev_priv->fbc.fbc_work = NULL;
}
@@ -459,15 +458,15 @@ static void intel_fbc_schedule_enable(struct intel_crtc 
*crtc)
WARN_ON(!mutex_is_locked(&dev_priv->fbc.lock));
 
intel_fbc_cancel_work(dev_priv);
+   dev_priv->fbc.crtc = crtc;
 
work = kzalloc(sizeof(*work), GFP_KERNEL);
if (work == NULL) {
DRM_ERROR("Failed to allocate FBC work structure\n");
-   intel_fbc_enable(crtc, crtc->base.primary->fb);
+   intel_fbc_enable(crtc->base.primary->fb);
return;
}
 
-   work->crtc = crtc;
work->fb = crtc->base.primary->fb;
INIT_DELAYED_WORK(&work->work, intel_fbc_work_fn);
 
@@ -1067,11 +1066,8 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
 
mutex_lock(&dev_priv->fbc.lock);
 
-   if (dev_priv->fbc.enabled)
+   if (dev_priv->fbc.enabled || dev_priv->fbc.fbc_work)
fbc_bits = INTEL_FRONTBUFFER_PRIMARY(dev_priv->fbc.crtc->pipe);
-   else if (dev_priv->fbc.fbc_work)
-   fbc_bits = INTEL_FRONTBUFFER_PRIMARY(
-   dev_priv->fbc.fbc_work->crtc->pipe);
else
fbc_bits = dev_priv->fbc.possible_framebuffer_bits;
 
@@ -1128,8 +1124,7 @@ void intel_fbc_flip_prepare(struct drm_i915_private 
*dev_priv,
if (fbc_bits & frontbuffer_bits)
dev_priv->fbc.flip_prepare(dev_priv);
} else if (dev_priv->fbc.f

[Intel-gfx] [PATCH 03/26] drm/i915: rename intel_fbc_nuke to intel_fbc_recompress

Although the term "nuke" is part of the FBC spec, it's not very
intuitive, so let's rename it to make it easier for people that are
not familiar with the spec.

Requested-by: Chris Wilson 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 62f158b..ac87136 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -214,7 +214,8 @@ static bool g4x_fbc_enabled(struct drm_i915_private 
*dev_priv)
return I915_READ(DPFC_CONTROL) & DPFC_CTL_EN;
 }
 
-static void intel_fbc_nuke(struct drm_i915_private *dev_priv)
+/* This funcion forces a CFB recompression through the nuke operation. */
+static void intel_fbc_recompress(struct drm_i915_private *dev_priv)
 {
I915_WRITE(MSG_FBC_REND_STATE, FBC_REND_NUKE);
POSTING_READ(MSG_FBC_REND_STATE);
@@ -263,7 +264,7 @@ static void ilk_fbc_enable(struct intel_crtc *crtc)
I915_WRITE(DPFC_CPU_FENCE_OFFSET, y_offset);
}
 
-   intel_fbc_nuke(dev_priv);
+   intel_fbc_recompress(dev_priv);
 
DRM_DEBUG_KMS("enabled fbc on plane %c\n", plane_name(crtc->plane));
 }
@@ -367,7 +368,7 @@ static void gen7_fbc_enable(struct intel_crtc *crtc)
   SNB_CPU_FENCE_ENABLE | obj->fence_reg);
I915_WRITE(DPFC_CPU_FENCE_OFFSET, get_crtc_fence_y_offset(crtc));
 
-   intel_fbc_nuke(dev_priv);
+   intel_fbc_recompress(dev_priv);
 
DRM_DEBUG_KMS("enabled fbc on plane %c\n", plane_name(crtc->plane));
 }
-- 
2.6.1

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

[Intel-gfx] [PATCH 06/26] drm/i915: remove unnecessary check for crtc->primary->fb

We already check if the CRTC is visible, and it shouldn't be possible
to have a visible CRTC without an FB.

This was noticed by both Chris and Ville on different ocasions.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 4d6ebc7..18479bc 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -560,7 +560,7 @@ static struct drm_crtc *intel_fbc_find_crtc(struct 
drm_i915_private *dev_priv)
break;
}
 
-   if (!crtc || crtc->primary->fb == NULL)
+   if (!crtc)
return NULL;
 
return crtc;
-- 
2.6.1

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

[Intel-gfx] [PATCH 04/26] drm/i915: only nuke FBC when a drawing operation triggers a flush

There's no need to stop and restart FBC: a nuke should be fine. The
specific check for ORIGIN_FLIP is not needed anymore since we have an
early return for the ORIGIN_FLIP && dev_priv->fbc.enabled case.

v2: Make it simpler (Chris).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 8 +++-
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index ac87136..7d8e996 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1091,12 +1091,10 @@ void intel_fbc_flush(struct drm_i915_private *dev_priv,
dev_priv->fbc.busy_bits &= ~frontbuffer_bits;
 
if (!dev_priv->fbc.busy_bits) {
-   if (origin == ORIGIN_FLIP) {
-   __intel_fbc_update(dev_priv);
-   } else {
-   __intel_fbc_disable(dev_priv);
+   if (dev_priv->fbc.enabled)
+   intel_fbc_recompress(dev_priv);
+   else
__intel_fbc_update(dev_priv);
-   }
}
 
mutex_unlock(&dev_priv->fbc.lock);
-- 
2.6.1

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

[Intel-gfx] [PATCH 14/26] drm/i915: refactor FBC deactivation at init

Make sure we deactivate FBC at intel_fbc_init(), so we can remove the
call from intel_display.c.

v2: Keep/improve the comment (Chris).

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_display.c | 3 ---
 drivers/gpu/drm/i915/intel_fbc.c | 8 ++--
 2 files changed, 6 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 2392f47..d1a5648 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14948,9 +14948,6 @@ void intel_modeset_init(struct drm_device *dev)
i915_disable_vga(dev);
intel_setup_outputs(dev);
 
-   /* Just in case the BIOS is doing something questionable. */
-   intel_fbc_disable(dev_priv);
-
drm_modeset_lock_all(dev);
intel_modeset_setup_hw_state(dev);
drm_modeset_unlock_all(dev);
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 6f020fc..643871d 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -1112,9 +1112,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
enum pipe pipe;
 
mutex_init(&dev_priv->fbc.lock);
+   dev_priv->fbc.active = false;
 
if (!HAS_FBC(dev_priv)) {
-   dev_priv->fbc.active = false;
dev_priv->fbc.no_fbc_reason = "unsupported by this chipset";
return;
}
@@ -1155,5 +1155,9 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
I915_WRITE(FBC_CONTROL, 500 << FBC_CTL_INTERVAL_SHIFT);
}
 
-   dev_priv->fbc.active = dev_priv->fbc.is_active(dev_priv);
+   /* We still don't have any sort of hardware state readout for FBC, so
+* disable it in case the BIOS enabled it to make sure software matches
+* the hardware state. */
+   if (dev_priv->fbc.is_active(dev_priv))
+   dev_priv->fbc.deactivate(dev_priv);
 }
-- 
2.6.1

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

[Intel-gfx] [PATCH 02/26] drm/i915: don't stop+start FBC at every flip

The hardware already takes care of disabling and recompressing FBC
when we do a page flip, so all we need to do is to update the fence
registers and move on.

One of the important things to notice is that on the pre-gen6
platforms the fence is programmed on the FBC control register and the
documentation says we can't update the control register while FBC is
enabled. This would basically mean we'd have to to disable+enable FBC
at every flip in order to make sure the hardware tracking still works,
which doesn't seem to make too much sense. So I sent an email to the
hardware team requesting some clarification. The information I got was
this:

"I don't think any hardware is latching on to 0x100100, 0x100104, or
the old fence number in FBC_CTL. Instructions against changing on the
fly would be to simplify testing and ensure you don't miss any
invalidation that happened right at that time."

So I guess we're fine for flips. But I can't really say I tested FBC
on these ancient platforms - nor that I'll ever propose enabling FBC
by default on them exactly because of problems like these.

v2: Add comment at flush() (Chris).

Testcase: igt/kms_frontbuffer_tracking/fbc*-fliptrack
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/i915_drv.h  |   1 +
 drivers/gpu/drm/i915/i915_reg.h  |   3 +
 drivers/gpu/drm/i915/intel_display.c |   1 -
 drivers/gpu/drm/i915/intel_drv.h |   2 +
 drivers/gpu/drm/i915/intel_fbc.c | 103 ++-
 drivers/gpu/drm/i915/intel_frontbuffer.c |   1 +
 6 files changed, 108 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index ee14962..77da500 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -928,6 +928,7 @@ struct i915_fbc {
bool (*fbc_enabled)(struct drm_i915_private *dev_priv);
void (*enable_fbc)(struct intel_crtc *crtc);
void (*disable_fbc)(struct drm_i915_private *dev_priv);
+   void (*flip_prepare)(struct drm_i915_private *dev_priv);
 };
 
 /**
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8942532..3d598a2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2028,6 +2028,7 @@ enum skl_disp_power_wells {
 #define   FBC_CTL_C3_IDLE  (1<<13)
 #define   FBC_CTL_STRIDE_SHIFT (5)
 #define   FBC_CTL_FENCENO_SHIFT(0)
+#define   FBC_CTL_FENCENO_MASK 0xF
 #define FBC_COMMAND0x0320c
 #define   FBC_CMD_COMPRESS (1<<0)
 #define FBC_STATUS 0x03210
@@ -2064,6 +2065,7 @@ enum skl_disp_power_wells {
 #define   DPFC_CTL_LIMIT_1X(0<<6)
 #define   DPFC_CTL_LIMIT_2X(1<<6)
 #define   DPFC_CTL_LIMIT_4X(2<<6)
+#define   DPFC_CTL_FENCE_MASK  0xF
 #define DPFC_RECOMP_CTL0x320c
 #define   DPFC_RECOMP_STALL_EN (1<<27)
 #define   DPFC_RECOMP_STALL_WM_SHIFT (16)
@@ -2086,6 +2088,7 @@ enum skl_disp_power_wells {
 #define   FBC_CTL_FALSE_COLOR  (1<<10)
 /* The bit 28-8 is reserved */
 #define   DPFC_RESERVED(0x1F00)
+#define   ILK_DPFC_FENCE_MASK  0xF
 #define ILK_DPFC_RECOMP_CTL0x4320c
 #define ILK_DPFC_STATUS0x43210
 #define ILK_DPFC_FENCE_YOFF0x43218
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bc1907e..d9378c3 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11502,7 +11502,6 @@ static int intel_crtc_page_flip(struct drm_crtc *crtc,
  to_intel_plane(primary)->frontbuffer_bit);
mutex_unlock(&dev->struct_mutex);
 
-   intel_fbc_disable_crtc(intel_crtc);
intel_frontbuffer_flip_prepare(dev,
   
to_intel_plane(primary)->frontbuffer_bit);
 
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index 08847d0..9065a8f 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -1305,6 +1305,8 @@ void intel_fbc_invalidate(struct drm_i915_private 
*dev_priv,
  enum fb_op_origin origin);
 void intel_fbc_flush(struct drm_i915_private *dev_priv,
 unsigned int frontbuffer_bits, enum fb_op_origin origin);
+void intel_fbc_flip_prepare(struct drm_i915_private *dev_priv,
+   unsigned int frontbuffer_bits);
 void intel_fbc_cleanup_cfb(struct drm_i915_private *dev_priv);
 
 /* intel_hdmi.c */
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index d9d7e54..62f158b 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -82,6 +82,22 @@ static void i8xx_fbc_disable(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("disabled FBC\n");
 }
 
+static void i8xx_fbc_flip_prepare(struct drm_i915_private *dev_priv)
+{
+   struct intel_crtc *crtc = dev_priv->fbc.crtc;
+   struct drm_framebuffer *fb = crtc->b

[Intel-gfx] [PATCH 16/26] drm/i915: remove too-frequent FBC debug message

If we run igt/kms_frontbuffer_tracking, this message will appear
thousands of times, eating a significant part of our dmesg buffer.
It's part of the expected FBC behavior, so let's just silence it.

Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 53ca151..17f098d 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -432,8 +432,6 @@ static void intel_fbc_cancel_work(struct drm_i915_private 
*dev_priv)
if (dev_priv->fbc.fbc_work == NULL)
return;
 
-   DRM_DEBUG_KMS("cancelling pending FBC activation\n");
-
/* Synchronisation is provided by struct_mutex and checking of
 * dev_priv->fbc.fbc_work, so we can perform the cancellation
 * entirely asynchronously.
-- 
2.6.1

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

[Intel-gfx] [PATCH 05/26] drm/i915: extract fbc_on_pipe_a_only()

Make the code easier to read.

Suggested-by: Chris Wilson 
Signed-off-by: Paulo Zanoni 
---
 drivers/gpu/drm/i915/intel_fbc.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 7d8e996..4d6ebc7 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -46,6 +46,11 @@ static inline bool fbc_supported(struct drm_i915_private 
*dev_priv)
return dev_priv->fbc.enable_fbc != NULL;
 }
 
+static inline bool fbc_on_pipe_a_only(struct drm_i915_private *dev_priv)
+{
+   return IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8;
+}
+
 /*
  * In some platforms where the CRTC's x:0/y:0 coordinates doesn't match the
  * frontbuffer's x:0/y:0 coordinates we lie to the hardware about the plane's
@@ -543,10 +548,6 @@ static struct drm_crtc *intel_fbc_find_crtc(struct 
drm_i915_private *dev_priv)
 {
struct drm_crtc *crtc = NULL, *tmp_crtc;
enum pipe pipe;
-   bool pipe_a_only = false;
-
-   if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
-   pipe_a_only = true;
 
for_each_pipe(dev_priv, pipe) {
tmp_crtc = dev_priv->pipe_to_crtc_mapping[pipe];
@@ -555,7 +556,7 @@ static struct drm_crtc *intel_fbc_find_crtc(struct 
drm_i915_private *dev_priv)
to_intel_plane_state(tmp_crtc->primary->state)->visible)
crtc = tmp_crtc;
 
-   if (pipe_a_only)
+   if (fbc_on_pipe_a_only(dev_priv))
break;
}
 
@@ -1146,7 +1147,7 @@ void intel_fbc_init(struct drm_i915_private *dev_priv)
dev_priv->fbc.possible_framebuffer_bits |=
INTEL_FRONTBUFFER_PRIMARY(pipe);
 
-   if (IS_HASWELL(dev_priv) || INTEL_INFO(dev_priv)->gen >= 8)
+   if (fbc_on_pipe_a_only(dev_priv))
break;
}
 
-- 
2.6.1

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

Re: [Intel-gfx] Call trace on SKL with 4.3.0-rc3+ kernel

2015-10-27 Thread John Doe

On 27/10/2015 10:40, Jani Nikula wrote:
> On Tue, 27 Oct 2015, Kai Huang  wrote:
>> I got below Call Trace when booting my 4.3.0-rc3+ kernel on my SKL DT 
>> machine. Although my machine boots up despite this call trace, I think 
>> it's better to report it (and hopefully this is the right mailing list 
>> to report).
> 
> Please try v4.3-rc7. If that doesn't help, please file a bug at
> https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel
> 
> BR,
> Jani.
> 
Hi,
I'm testing 4.3-rc7 and got a similar crash (i7-6700k on z170), the
machine fails to boot.

[5.063912] [ cut here ]
[5.063941] WARNING: CPU: 1 PID: 6 at
/home/user/n/qubes-builder/qubes-src/linux-kernel/kernel-4.3.0/linux-4.3.0/drivers/gpu/drm/i915/intel_pm.c:3668
skl_update_other_pipe_wm+0x1f3/0x200)
[5.063942] WARN_ON(!wm_changed)
[5.063950] Modules linked in: crct10dif_pclmul crc32_pclmul
crc32c_intel nouveau(+) mxm_wmi radeon(+) i915 intel_gtt i2c_algo_bit
drm_kms_helper ttm drm agpgart wmi video xen_pciback xek
[5.063951] CPU: 1 PID: 6 Comm: kworker/u4:0 Not tainted
4.3.0-1.pvops.qubes.x86_64 #1
[5.063952] Hardware name: To Be Filled By O.E.M. To Be Filled By
O.E.M./Z170 Extreme4, BIOS P2.10 10/14/2015
[5.063958] Workqueue: events_unbound async_run_entry_fn
[5.063960]   624b15e0 88086bb67400
81394b54
[5.063964]  88086bb67448 88086bb67438 8109ced2
8808677f8000
[5.063965]  88086bb67594 88086bb674e0 8808677fb000

[5.063965] Call Trace:
[5.063972]  [] dump_stack+0x44/0x60
[5.063975]  [] warn_slowpath_common+0x82/0xc0
[5.063976]  [] warn_slowpath_fmt+0x5c/0x80
[5.063997]  []
skl_update_other_pipe_wm+0x1f3/0x200 [i915]
[5.064013]  [] skl_update_wm+0x1bb/0x700 [i915]
[5.064028]  [] ? error_exit+0x9/0x20
[5.064044]  [] intel_update_watermarks+0x1e/0x30
[i915]
[5.064073]  [] haswell_crtc_enable+0x476/0xbd0 [i915]
[5.064098]  [] intel_atomic_commit+0x36f/0x630 [i915]
[5.064114]  [] ? drm_atomic_check_only+0x1d4/0x570
[drm]
[5.064128]  [] drm_atomic_commit+0x37/0x60 [drm]
[5.064135]  []
drm_atomic_helper_set_config+0x1c4/0x430 [drm_kms_helper]
[5.064144]  []
drm_mode_set_config_internal+0x62/0x100 [drm]
[5.064151]  [] restore_fbdev_mode+0xab/0x110
[drm_kms_helper]
[5.064157]  []
drm_fb_helper_restore_fbdev_mode_unlocked+0x25/0x70 [drm_kms_helper]
[5.064159]  [] drm_fb_helper_set_par+0x2d/0x50
[drm_kms_helper]
[5.064188]  [] intel_fbdev_set_par+0x1a/0x60 [i915]
[5.064190]  [] fbcon_init+0x533/0x5a0
[5.064195]  [] visual_init+0xca/0x130
[5.064196]  [] do_bind_con_driver+0x168/0x390
[5.064197]  [] do_take_over_console+0xac/0x1a0
[5.064198]  [] do_fbcon_takeover+0x57/0xb0
[5.064199]  [] fbcon_event_notify+0x646/0x740
[5.064204]  [] notifier_call_chain+0x4a/0x70
[5.064205]  []
__blocking_notifier_call_chain+0x47/0x60
[5.064206]  [] blocking_notifier_call_chain+0x16/0x20
[5.064211]  [] fb_notifier_call_chain+0x1b/0x20
[5.064211]  [] register_framebuffer+0x209/0x340
[5.064214]  []
drm_fb_helper_initial_config+0x239/0x3c0 [drm_kms_helper]
[5.064241]  []
intel_fbdev_initial_config+0x1b/0x20 [i915]
[5.064242]  [] async_run_entry_fn+0x4a/0x140
[5.064243]  [] process_one_work+0x150/0x3f0
[5.064244]  [] worker_thread+0x4e/0x460
[5.064248]  [] ? rescuer_thread+0x300/0x300
[5.064249]  [] kthread+0xd8/0xf0
[5.064250]  [] ? kthread_park+0x60/0x60
[5.064251]  [] ret_from_fork+0x3f/0x70
[5.064256]  [] ? kthread_park+0x60/0x60
[5.064256] ---[ end trace 18eaeb20a49fdf89 ]---

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

[Intel-gfx] [PATCH v3] drm/i915: Add extra plane information in debugfs.

Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a commit.

V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
16.16 fixpoint, better rotation bitmask management and some minor fixes

V3: Corrected state->src_x & 0x00ff to state->src_x & 0x...

Signed-off-by: Robert Fekete 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 109 +++-
 1 file changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 89ba549e92be..0474c6557bbd 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2950,6 +2950,107 @@ static bool cursor_position(struct drm_device *dev, int 
pipe, int *x, int *y)
return cursor_active(dev, pipe);
 }
 
+static const char *plane_type(enum drm_plane_type type)
+{
+   switch (type) {
+   case DRM_PLANE_TYPE_OVERLAY:
+   return "OVL";
+   case DRM_PLANE_TYPE_PRIMARY:
+   return "PRI";
+   case DRM_PLANE_TYPE_CURSOR:
+   return "CUR";
+   /*
+* Deliberately omitting default: to generate compiler warnings
+* when a new drm_plane_type gets added.
+*/
+   }
+
+   return "unknown";
+}
+
+static const char *plane_rotation(unsigned int rotation)
+{
+   static char buf[48];
+   /*
+* According to doc only one DRM_ROTATE_ is allowed but this
+* will print them all to visualize if the values are misused
+*/
+   snprintf(buf, sizeof(buf),
+"%s%s%s%s%s%s(0x%08x)",
+(rotation & BIT(DRM_ROTATE_0)) ? "0 " : "",
+(rotation & BIT(DRM_ROTATE_90)) ? "90 " : "",
+(rotation & BIT(DRM_ROTATE_180)) ? "180 " : "",
+(rotation & BIT(DRM_ROTATE_270)) ? "270 " : "",
+(rotation & BIT(DRM_REFLECT_X)) ? "FLIPX " : "",
+(rotation & BIT(DRM_REFLECT_Y)) ? "FLIPY " : "",
+rotation);
+
+   return buf;
+}
+
+static void intel_plane_info(struct seq_file *m, struct intel_crtc *intel_crtc)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct intel_plane *intel_plane;
+
+   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
+   struct drm_plane_state *state;
+   struct drm_plane *plane = &intel_plane->base;
+
+   if (!plane->state) {
+   seq_puts(m, "plane->state is NULL!\n");
+   continue;
+   }
+
+   state = plane->state;
+
+   seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d, 
crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u, 
format=%s, rotation=%s\n",
+  plane->base.id,
+  plane_type(intel_plane->base.type),
+  state->crtc_x, state->crtc_y,
+  state->crtc_w, state->crtc_h,
+  (state->src_x >> 16),
+  ((state->src_x & 0x) * 15625) >> 10,
+  (state->src_y >> 16),
+  ((state->src_y & 0x) * 15625) >> 10,
+  (state->src_w >> 16),
+  ((state->src_w & 0x) * 15625) >> 10,
+  (state->src_h >> 16),
+  ((state->src_h & 0x) * 15625) >> 10,
+  state->fb ? 
drm_get_format_name(state->fb->pixel_format) : "N/A",
+  plane_rotation(state->rotation));
+   }
+}
+
+static void intel_scaler_info(struct seq_file *m, struct intel_crtc 
*intel_crtc)
+{
+   struct intel_crtc_state *pipe_config;
+   int num_scalers = intel_crtc->num_scalers;
+   int i;
+
+   pipe_config = to_intel_crtc_state(intel_crtc->base.state);
+
+   /* Not all platformas have a scaler */
+   if (num_scalers) {
+   seq_printf(m, "\tnum_scalers=%d, scaler_users=%x scaler_id=%d",
+  num_scalers,
+  pipe_config->scaler_state.scaler_users,
+  pipe_config->scaler_state.scaler_id);
+
+   for (i = 0; i < SKL_NUM_SCALERS; i++) {
+   struct intel_scaler *sc =
+   &pipe_config->scaler_state.scalers[i];
+
+   seq_printf(m, ", scalers[%d]: use=%s, mode=%x",
+  i, yesno(sc->in_use), sc->mode);
+   }
+   seq_puts(m, "\n");
+   } else {
+   seq_puts(m, "\tNo scalers available on this platform\n");
+   }
+}
+

Re: [Intel-gfx] [PATCH 1/1] drm/i915: Add Backlight Control using DPCD for eDP connectors

2015-10-27 Thread Adebisi, YetundeX

Hi All,

Can someone please review this patch from September.

Thank you.

Yetunde

> -Original Message-
> From: Adebisi, YetundeX
> Sent: Wednesday, September 30, 2015 3:36 PM
> To: intel-gfx@lists.freedesktop.org
> Cc: Adebisi, YetundeX; Paauwe, Bob J; Nikula, Jani; Deepak, M
> Subject: [PATCH 1/1] drm/i915: Add Backlight Control using DPCD for eDP
> connectors
> 
> This patch adds support for eDP backlight control using DPCD registers to
> backlight hooks in intel_panel.
> 
> It checks for backlight control over AUX channel capability and sets up
> function pointers to get and set the backlight brightness level if supported.
> 
> Cc: Bob Paauwe 
> Cc: Jani Nikula 
> Cc: Deepak M 
> Signed-off-by: Yetunde Adebisi 
> ---
>  drivers/gpu/drm/i915/intel_dp.c| 185
> +
>  drivers/gpu/drm/i915/intel_drv.h   |   3 +
>  drivers/gpu/drm/i915/intel_panel.c |   5 +-
>  include/drm/drm_dp_helper.h|   6 ++
>  4 files changed, 198 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dp.c
> b/drivers/gpu/drm/i915/intel_dp.c index fa1a524..fc4b896 100644
> --- a/drivers/gpu/drm/i915/intel_dp.c
> +++ b/drivers/gpu/drm/i915/intel_dp.c
> @@ -6259,3 +6259,188 @@ void intel_dp_mst_resume(struct drm_device
> *dev)
>   }
>   }
>  }
> +
> +static uint8_t read_aux_backlight_mode_set_reg(struct intel_dp
> +*intel_dp) {
> + uint8_t dpcd_buf = 0;
> +
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux,
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
> + &dpcd_buf, sizeof(dpcd_buf)) < 0)
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
> +
> + return dpcd_buf;
> +}
> +
> +static bool get_aux_backlight_enable(struct drm_dp_aux *aux) {
> + uint8_t read_val = 0;
> +
> + if (intel_dp_dpcd_read_wake(aux,
> DP_EDP_DISPLAY_CONTROL_REGISTER,
> + &read_val, sizeof(read_val)) < 0) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_DISPLAY_CONTROL_REGISTER);
> + }
> + return read_val & DP_EDP_BACKLIGHT_ENABLE; }
> +
> +static void set_aux_backlight_enable(struct intel_dp *intel_dp, bool
> +enable) {
> + uint8_t reg_val = 0;
> +
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux,
> + DP_EDP_DISPLAY_CONTROL_REGISTER,
> + ®_val, sizeof(reg_val)) < 0) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_DISPLAY_CONTROL_REGISTER);
> + return;
> + }
> + if (enable)
> + reg_val |= DP_EDP_BACKLIGHT_ENABLE;
> + else
> + reg_val &= ~(DP_EDP_BACKLIGHT_ENABLE);
> +
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
> DP_EDP_DISPLAY_CONTROL_REGISTER,
> + reg_val) < 0) {
> + DRM_DEBUG_KMS("Failed to %s aux backlight\n",
> + enable ? "enable" : "disable");
> + }
> +}
> +
> +/**
> + * Read the current backlight value from DPCD register(s) based
> + * on if 8-bit(MSB) or 16-bit(MSB and LSB) values are supported  */
> +static uint32_t intel_dp_aux_get_backlight(struct intel_connector
> +*connector) {
> + struct intel_dp *intel_dp = intel_attached_dp(&connector->base);
> + uint16_t read_val = 0;
> +
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux,
> + DP_EDP_BACKLIGHT_BRIGHTNESS_MSB,
> + &read_val, sizeof(read_val)) < 0) {
> + DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> + DP_EDP_BACKLIGHT_BRIGHTNESS_MSB);
> + return 0;
> + }
> + if (intel_dp->aux_blc_use_lsb) {
> + uint8_t val_lsb = 0;
> +
> + if (intel_dp_dpcd_read_wake(&intel_dp->aux,
> + DP_EDP_BACKLIGHT_BRIGHTNESS_LSB,
> + &val_lsb, sizeof(val_lsb)) < 0) {
> + DRM_DEBUG_KMS("Failed to read DPCD register
> 0x%x\n",
> +
>   DP_EDP_BACKLIGHT_BRIGHTNESS_LSB);
> + return 0;
> + }
> + read_val = (read_val << 8 | val_lsb);
> + }
> +
> + return read_val;
> +}
> +
> +/**
> + * Sends the current backlight level over the aux channel, checking if
> +its using
> + * 8-bit or 16 bit value (MSB and LSB)
> + */
> +static void
> +intel_dp_aux_set_backlight(struct intel_connector *connector, u32
> +level) {
> + struct intel_dp *intel_dp = intel_attached_dp(&connector->base);
> + uint8_t vals[2] = { 0x0 };
> +
> + vals[0] = level;
> + DRM_DEBUG_KMS("Level 0x%x\n", level);
> +
> + /* Write the MSB and/or LSB */
> +  if (intel_dp->aux_blc_use_lsb) {
> + vals[0] = (level & 0xFF00) >> 8;
> + vals[1] = (level & 0xFF);
> + if (drm_dp_dpcd_writeb(&intel_dp->aux,
>

Re: [Intel-gfx] [PATCH v2] drm/i915: Add extra plane information in debugfs.

Do not review this one!

I just found that I forgot to and(&) state->src_x with 0x.

V3 coming in a sec or two.

BR
/Robert F

On tis, 2015-10-27 at 16:49 +0100, Robert Fekete wrote:
> Extends i915_display_info so that for each active crtc also print
> all planes associated with the pipe. This patch shows information
> about each plane wrt format, size, position, rotation, and scaling.
> This is very useful when debugging user space compositors that try
> to utilize several planes for a commit.
> 
> V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
> 16.16 fixpoint, better rotation bitmask management and some minor fixes
> 
> Signed-off-by: Robert Fekete 
> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 109 
> +++-
>  1 file changed, 107 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index eca94d0e4d99..9a2265e1139a 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2950,6 +2950,107 @@ static bool cursor_position(struct drm_device *dev, 
> int pipe, int *x, int *y)
>   return cursor_active(dev, pipe);
>  }
>  
> +static const char *plane_type(enum drm_plane_type type)
> +{
> + switch (type) {
> + case DRM_PLANE_TYPE_OVERLAY:
> + return "OVL";
> + case DRM_PLANE_TYPE_PRIMARY:
> + return "PRI";
> + case DRM_PLANE_TYPE_CURSOR:
> + return "CUR";
> + /*
> +  * Deliberately omitting default: to generate compiler warnings
> +  * when a new drm_plane_type gets added.
> +  */
> + }
> +
> + return "unknown";
> +}
> +
> +static const char *plane_rotation(unsigned int rotation)
> +{
> + static char buf[48];
> + /*
> +  * According to doc only one DRM_ROTATE_ is allowed but this
> +  * will print them all to visualize if the values are misused
> +  */
> + snprintf(buf, sizeof(buf),
> +  "%s%s%s%s%s%s(0x%08x)",
> +  (rotation & BIT(DRM_ROTATE_0)) ? "0 " : "",
> +  (rotation & BIT(DRM_ROTATE_90)) ? "90 " : "",
> +  (rotation & BIT(DRM_ROTATE_180)) ? "180 " : "",
> +  (rotation & BIT(DRM_ROTATE_270)) ? "270 " : "",
> +  (rotation & BIT(DRM_REFLECT_X)) ? "FLIPX " : "",
> +  (rotation & BIT(DRM_REFLECT_Y)) ? "FLIPY " : "",
> +  rotation);
> +
> + return buf;
> +}
> +
> +static void intel_plane_info(struct seq_file *m, struct intel_crtc 
> *intel_crtc)
> +{
> + struct drm_info_node *node = m->private;
> + struct drm_device *dev = node->minor->dev;
> + struct intel_plane *intel_plane;
> +
> + for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
> + struct drm_plane_state *state;
> + struct drm_plane *plane = &intel_plane->base;
> +
> + if (!plane->state) {
> + seq_puts(m, "plane->state is NULL!\n");
> + continue;
> + }
> +
> + state = plane->state;
> +
> + seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d, 
> crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u, 
> format=%s, rotation=%s\n",
> +plane->base.id,
> +plane_type(intel_plane->base.type),
> +state->crtc_x, state->crtc_y,
> +state->crtc_w, state->crtc_h,
> +(state->src_x >> 16),
> +((state->src_x & 0x00ff) * 15625) >> 10,
> +(state->src_y >> 16),
> +((state->src_y & 0x00ff) * 15625) >> 10,
> +(state->src_w >> 16),
> +((state->src_w & 0x00ff) * 15625) >> 10,
> +(state->src_h >> 16),
> +((state->src_h & 0x00ff) * 15625) >> 10,
> +state->fb ? 
> drm_get_format_name(state->fb->pixel_format) : "N/A",
> +plane_rotation(state->rotation));
> + }
> +}
> +
> +static void intel_scaler_info(struct seq_file *m, struct intel_crtc 
> *intel_crtc)
> +{
> + struct intel_crtc_state *pipe_config;
> + int num_scalers = intel_crtc->num_scalers;
> + int i;
> +
> + pipe_config = to_intel_crtc_state(intel_crtc->base.state);
> +
> + /* Not all platformas have a scaler */
> + if (num_scalers) {
> + seq_printf(m, "\tnum_scalers=%d, scaler_users=%x scaler_id=%d",
> +num_scalers,
> +pipe_config->scaler_state.scaler_users,
> +pipe_config->scaler_state.scaler_id);
> +
> + for (i = 0; i < SKL_NUM_SCALERS; i++) {
> + struct intel_scaler *sc =
> + &pipe_config->scaler_state.scalers[i];
> +
> + seq_printf(m, ", scalers[%d]: use=%s, mode=%x

[Intel-gfx] [PATCH v2] drm/i915: Add extra plane information in debugfs.

Extends i915_display_info so that for each active crtc also print
all planes associated with the pipe. This patch shows information
about each plane wrt format, size, position, rotation, and scaling.
This is very useful when debugging user space compositors that try
to utilize several planes for a commit.

V2: Fixed comments from Maarten, Ville, and Chris. Fixed printing of
16.16 fixpoint, better rotation bitmask management and some minor fixes

Signed-off-by: Robert Fekete 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 109 +++-
 1 file changed, 107 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index eca94d0e4d99..9a2265e1139a 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2950,6 +2950,107 @@ static bool cursor_position(struct drm_device *dev, int 
pipe, int *x, int *y)
return cursor_active(dev, pipe);
 }
 
+static const char *plane_type(enum drm_plane_type type)
+{
+   switch (type) {
+   case DRM_PLANE_TYPE_OVERLAY:
+   return "OVL";
+   case DRM_PLANE_TYPE_PRIMARY:
+   return "PRI";
+   case DRM_PLANE_TYPE_CURSOR:
+   return "CUR";
+   /*
+* Deliberately omitting default: to generate compiler warnings
+* when a new drm_plane_type gets added.
+*/
+   }
+
+   return "unknown";
+}
+
+static const char *plane_rotation(unsigned int rotation)
+{
+   static char buf[48];
+   /*
+* According to doc only one DRM_ROTATE_ is allowed but this
+* will print them all to visualize if the values are misused
+*/
+   snprintf(buf, sizeof(buf),
+"%s%s%s%s%s%s(0x%08x)",
+(rotation & BIT(DRM_ROTATE_0)) ? "0 " : "",
+(rotation & BIT(DRM_ROTATE_90)) ? "90 " : "",
+(rotation & BIT(DRM_ROTATE_180)) ? "180 " : "",
+(rotation & BIT(DRM_ROTATE_270)) ? "270 " : "",
+(rotation & BIT(DRM_REFLECT_X)) ? "FLIPX " : "",
+(rotation & BIT(DRM_REFLECT_Y)) ? "FLIPY " : "",
+rotation);
+
+   return buf;
+}
+
+static void intel_plane_info(struct seq_file *m, struct intel_crtc *intel_crtc)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct intel_plane *intel_plane;
+
+   for_each_intel_plane_on_crtc(dev, intel_crtc, intel_plane) {
+   struct drm_plane_state *state;
+   struct drm_plane *plane = &intel_plane->base;
+
+   if (!plane->state) {
+   seq_puts(m, "plane->state is NULL!\n");
+   continue;
+   }
+
+   state = plane->state;
+
+   seq_printf(m, "\t--Plane id %d: type=%s, crtc_pos=%4dx%4d, 
crtc_size=%4dx%4d, src_pos=%d.%04ux%d.%04u, src_size=%d.%04ux%d.%04u, 
format=%s, rotation=%s\n",
+  plane->base.id,
+  plane_type(intel_plane->base.type),
+  state->crtc_x, state->crtc_y,
+  state->crtc_w, state->crtc_h,
+  (state->src_x >> 16),
+  ((state->src_x & 0x00ff) * 15625) >> 10,
+  (state->src_y >> 16),
+  ((state->src_y & 0x00ff) * 15625) >> 10,
+  (state->src_w >> 16),
+  ((state->src_w & 0x00ff) * 15625) >> 10,
+  (state->src_h >> 16),
+  ((state->src_h & 0x00ff) * 15625) >> 10,
+  state->fb ? 
drm_get_format_name(state->fb->pixel_format) : "N/A",
+  plane_rotation(state->rotation));
+   }
+}
+
+static void intel_scaler_info(struct seq_file *m, struct intel_crtc 
*intel_crtc)
+{
+   struct intel_crtc_state *pipe_config;
+   int num_scalers = intel_crtc->num_scalers;
+   int i;
+
+   pipe_config = to_intel_crtc_state(intel_crtc->base.state);
+
+   /* Not all platformas have a scaler */
+   if (num_scalers) {
+   seq_printf(m, "\tnum_scalers=%d, scaler_users=%x scaler_id=%d",
+  num_scalers,
+  pipe_config->scaler_state.scaler_users,
+  pipe_config->scaler_state.scaler_id);
+
+   for (i = 0; i < SKL_NUM_SCALERS; i++) {
+   struct intel_scaler *sc =
+   &pipe_config->scaler_state.scalers[i];
+
+   seq_printf(m, ", scalers[%d]: use=%s, mode=%x",
+  i, yesno(sc->in_use), sc->mode);
+   }
+   seq_puts(m, "\n");
+   } else {
+   seq_puts(m, "\tNo scalers available on this platform\n");
+   }
+}
+
 static int i915_display_info(struct seq_file *m, void *unused)

[Intel-gfx] Fwd: Re: (XEN) Fatal machine check

2015-10-27 Thread John Doe

Hi,
this looks to be related to intel HD Graphics 530, if I disable the
integrated GPU the machine boots properly.

Any ideas?
John.


On 26/10/2015 13:04, John Doe wrote:
> Hi, i'm getting this problem with linux 4.3.0-rcX branch.
> Full log is attached. My hardware is based on intel skylake i7-6700k on
> z170 chipset and it is working properly. It does boot correctly with
> older kernels (3.12).
> With mce=off on xen parameters it does boot unti during pci detection
> where it hangs (see attached log).
> 
> I tried with both xen 4.4.2 and 4.6.0 with the same effect
> 
> [2.957615] VFS: Disk quotas d(XEN) Fatal machine check: MCE: Fatal
> error happened on CPUs ff
> (XEN)
> (XEN) 
> (XEN)
> (XEN)The processor has reported a hardware error which cannot
> (XEN)be recovered from.  Xen will now reboot the machine.
> (XEN) mce.c:1533: Begin dump mc_info
> (XEN) CPU0: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU0: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU1: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU1: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU2: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU2: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU3: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) CPU3: Machine Check Exception:5
> (XEN) Bank 4: ba0011000402[   0]
> (XEN) mce.c:1536: End dump mc_info, 8 mcinfo dumped
> (XEN)
> (XEN) 
> (XEN) Panic on CPU 0:
> (XEN) HARDWARE ERROR
> (XEN) 
> (XEN)
> (XEN) Reboot in five seconds...
> 
> Any help?
> 
> Thanks,
> John.
> 



Loading Xen 4.4.2 ...
Loading Linux 4.3.0-1.pvops.qubes.x86_64 ...
Loading initial ramdisk ...
 Xen 4.4.2-7.fc21
(XEN) Xen version 4.4.2 (user@) (gcc (GCC) 4.9.2 20150212 (Red Hat 4.9.2-6)) debug=n Tue Oct 20 14:48:15 CEST 2015
(XEN) Latest ChangeSet: 
(XEN) Bootloader: GRUB 2.00
(XEN) Command line: placeholder iommu=pt iommu=1 unrestricted_guest=1 msi=1 swiotlb=force console=ttyS0 com1=115200,8n1 console=com1 dom0_mem=min:1024Mi loglvl=all apic_verbosity=debug e820t
(XEN) Video information:
(XEN)  VGA is text mode 80x25, font 8x16
(XEN)  VBE/DDC methods: V2; EDID transfer time: 1 seconds
(XEN) Disc information:
(XEN)  Found 1 MBR signatures
(XEN)  Found 1 EDD information structures
(XEN) Initial Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 63911000 (usable)
(XEN)  63911000 - 63912000 (ACPI NVS)
(XEN)  63912000 - 6395c000 (reserved)
(XEN)  6395c000 - 639af000 (usable)
(XEN)  639af000 - 640b4000 (reserved)
(XEN)  640b4000 - 66b99000 (usable)
(XEN)  66b99000 - 677ab000 (reserved)
(XEN)  677ab000 - 67f9a000 (ACPI NVS)
(XEN)  67f9a000 - 67fff000 (ACPI data)
(XEN)  67fff000 - 6800 (usable)
(XEN)  0001 - 00089200 (usable)
(XEN)  6800 - 6810 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN) Checking MTRR ranges...
(XEN)  MTRR cap: 1d0a type: c06
(XEN) Xen-e820 RAM map:
(XEN)   - 0009c800 (usable)
(XEN)  0009c800 - 000a (reserved)
(XEN)  000e - 0010 (reserved)
(XEN)  0010 - 63911000 (usable)
(XEN)  63911000 - 63912000 (ACPI NVS)
(XEN)  63912000 - 6395c000 (reserved)
(XEN)  6395c000 - 639af000 (usable)
(XEN)  639af000 - 640b4000 (reserved)
(XEN)  640b4000 - 66b99000 (usable)
(XEN)  66b99000 - 677ab000 (reserved)
(XEN)  677ab000 - 67f9a000 (ACPI NVS)
(XEN)  67f9a000 - 67fff000 (ACPI data)
(XEN)  67fff000 - 6800 (usable)
(XEN)  6800 - 6810 (reserved)
(XEN)  e000 - f000 (reserved)
(XEN)  fe00 - fe011000 (reserved)
(XEN)  fec0 - fec01000 (reserved)
(XEN)  fee0 - fee01000 (reserved)
(XEN)  ff00 - 0001 (reserved)
(XEN)  0001 - 00089200

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Share cdclk code for BDW and BXT

On Tue, Oct 27, 2015 at 03:43:03PM +0200, Jani Nikula wrote:
> On Tue, 27 Oct 2015, ville.syrj...@linux.intel.com wrote:
> > From: Ville Syrjälä 
> >
> > The difference betwen the BXT and BDW cdclk code boils down to two
> > things: claming the cdclk to the maximum supported, and panel fitter
> > downscaling ratio
> >
> > Unifying the the max cdclk clamping is easy, just do it.
> >
> > And as far as the panel fitter is concerned, SKL+ already (ab)use the
> > pch pfit state for its pipe scaler information, so it will compute the
> > adjusted pixel rate correctly.
> >
> > So we can just use the BDW code for BXT, as long as we lift the BXT
> > pixel rate -> cdclk selection into the correct place.
> 
> I don't like the direction taken by this patch.
> 
> We have the platform specific functions to keep stuff platform
> specific. Now you claim bdw and bxt are almost the same, yet the
> functions are filled with conditionals on the platform. I value having
> straightforward and readable platform specific hooks much higher than
> the slight reduction in line count.

I agree that it's not all that nice. The real problem is that the current
cdclk  function pointers are just too high level. They really should
be at the calc_cdclk and set_cdclk level. But fixing that would require
actually dealing with the gmch pfit, and stuffing the power domain
hack (assuming we still need it) and the pfi programming for vlv/chv
into the lower level functions. And looks like no one has bothered to do
any of that.

> 
> BR,
> Jani.
> 
> >
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_display.c | 87 
> > +---
> >  1 file changed, 30 insertions(+), 57 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_display.c 
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 978f543..0c782c7 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -5932,25 +5932,6 @@ static int valleyview_calc_cdclk(struct 
> > drm_i915_private *dev_priv,
> > return 20;
> >  }
> >  
> > -static int broxton_calc_cdclk(struct drm_i915_private *dev_priv,
> > - int max_pixclk)
> > -{
> > -   /*
> > -* FIXME:
> > -* - set 19.2MHz bypass frequency if there are no active pipes
> > -*/
> > -   if (max_pixclk > 576000)
> > -   return 624000;
> > -   else if (max_pixclk > 384000)
> > -   return 576000;
> > -   else if (max_pixclk > 288000)
> > -   return 384000;
> > -   else if (max_pixclk > 144000)
> > -   return 288000;
> > -   else
> > -   return 144000;
> > -}
> > -
> >  /* Compute the max pixel clock for new configuration. Uses atomic state if
> >   * that's non-NULL, look at current state otherwise. */
> >  static int intel_mode_max_pixclk(struct drm_device *dev,
> > @@ -5990,21 +5971,6 @@ static int valleyview_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> > return 0;
> >  }
> >  
> > -static int broxton_modeset_calc_cdclk(struct drm_atomic_state *state)
> > -{
> > -   struct drm_device *dev = state->dev;
> > -   struct drm_i915_private *dev_priv = dev->dev_private;
> > -   int max_pixclk = intel_mode_max_pixclk(dev, state);
> > -
> > -   if (max_pixclk < 0)
> > -   return max_pixclk;
> > -
> > -   to_intel_atomic_state(state)->cdclk =
> > -   broxton_calc_cdclk(dev_priv, max_pixclk);
> > -
> > -   return 0;
> > -}
> > -
> >  static void vlv_program_pfi_credits(struct drm_i915_private *dev_priv)
> >  {
> > unsigned int credits, default_credits;
> > @@ -9497,14 +9463,6 @@ void hsw_disable_pc8(struct drm_i915_private 
> > *dev_priv)
> > intel_prepare_ddi(dev);
> >  }
> >  
> > -static void broxton_modeset_commit_cdclk(struct drm_atomic_state 
> > *old_state)
> > -{
> > -   struct drm_device *dev = old_state->dev;
> > -   unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
> > -
> > -   broxton_set_cdclk(dev, req_cdclk);
> > -}
> > -
> >  /* compute the max rate for new configuration */
> >  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
> >  {
> > @@ -9621,14 +9579,31 @@ static int broadwell_modeset_calc_cdclk(struct 
> > drm_atomic_state *state)
> >  * FIXME should also account for plane ratio
> >  * once 64bpp pixel formats are supported.
> >  */
> > -   if (max_pixclk > 54)
> > -   cdclk = 675000;
> > -   else if (max_pixclk > 45)
> > -   cdclk = 54;
> > -   else if (max_pixclk > 337500)
> > -   cdclk = 45;
> > -   else
> > -   cdclk = 337500;
> > +   if (IS_BROXTON(dev_priv)) {
> > +   /*
> > +* FIXME:
> > +* - set 19.2MHz bypass frequency if there are no active pipes
> > +*/
> > +   if (max_pixclk > 576000)
> > +   cdclk = 624000;
> > +   else if (max_pixclk > 384000)
> > +   cdclk = 576000;
> > +   else if (max_pixclk > 288000)
>

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Do not acquire crtc state to check clock during modeset, v2.

On Tue, Oct 27, 2015 at 02:51:16PM +0100, Maarten Lankhorst wrote:
> Op 27-10-15 om 14:49 schreef Ville Syrjälä:
> > On Tue, Oct 27, 2015 at 02:41:16PM +0100, Maarten Lankhorst wrote:
> >> Op 27-10-15 om 14:29 schreef Ville Syrjälä:
> >>> On Tue, Oct 27, 2015 at 02:26:31PM +0100, Maarten Lankhorst wrote:
>  Parallel modesets are still not allowed, but this will allow updating
>  a different crtc during a modeset if the clock is not changed.
> 
>  Additionally when all pipes are DPMS off the cdclk will be lowered
>  to the minimum allowed.
> 
>  Changes since v1:
>  - Add dev_priv->active_crtcs for tracking which crtcs are active.
>  - Rename min_cdclk to min_pixclk and move to dev_priv.
>  - Add a active_crtcs mask which is updated atomically.
>  - Add intel_atomic_state->modeset which is set on modesets.
>  - Commit new pixclk/active_crtcs right after state swap.
> 
>  Signed-off-by: Maarten Lankhorst 
>  ---
>   drivers/gpu/drm/i915/i915_drv.h  |   5 ++
>   drivers/gpu/drm/i915/intel_atomic.c  |   2 +-
>   drivers/gpu/drm/i915/intel_display.c | 160 
>  +--
>   drivers/gpu/drm/i915/intel_drv.h |   7 +-
>   4 files changed, 125 insertions(+), 49 deletions(-)
> 
>  diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>  b/drivers/gpu/drm/i915/i915_drv.h
>  index 59c94929f25b..37eef86e4a0a 100644
>  --- a/drivers/gpu/drm/i915/i915_drv.h
>  +++ b/drivers/gpu/drm/i915/i915_drv.h
>  @@ -1837,8 +1837,13 @@ struct drm_i915_private {
>   struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
>   #endif
>   
>  +/* dpll and cdclk state is protected by connection_mutex */
>   int num_shared_dpll;
>   struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
>  +
>  +unsigned int active_crtcs;
>  +unsigned int min_pixclk[I915_MAX_PIPES];
>  +
>   int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>   
>   struct i915_workarounds workarounds;
>  diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
>  b/drivers/gpu/drm/i915/intel_atomic.c
>  index 25a891aa3824..cb8fcf4fe7f2 100644
>  --- a/drivers/gpu/drm/i915/intel_atomic.c
>  +++ b/drivers/gpu/drm/i915/intel_atomic.c
>  @@ -305,5 +305,5 @@ void intel_atomic_state_clear(struct 
>  drm_atomic_state *s)
>   {
>   struct intel_atomic_state *state = to_intel_atomic_state(s);
>   drm_atomic_state_default_clear(&state->base);
>  -state->dpll_set = false;
>  +state->dpll_set = state->modeset = false;
>   }
>  diff --git a/drivers/gpu/drm/i915/intel_display.c 
>  b/drivers/gpu/drm/i915/intel_display.c
>  index 022e628b8520..a0508d5e9e13 100644
>  --- a/drivers/gpu/drm/i915/intel_display.c
>  +++ b/drivers/gpu/drm/i915/intel_display.c
>  @@ -5237,6 +5237,7 @@ static void modeset_put_power_domains(struct 
>  drm_i915_private *dev_priv,
>   
>   static void modeset_update_crtc_power_domains(struct drm_atomic_state 
>  *state)
>   {
>  +struct intel_atomic_state *intel_state = 
>  to_intel_atomic_state(state);
>   struct drm_device *dev = state->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   unsigned long put_domains[I915_MAX_PIPES] = {};
>  @@ -5245,13 +5246,18 @@ static void 
>  modeset_update_crtc_power_domains(struct drm_atomic_state *state)
>   int i;
>   
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
>  -if (needs_modeset(crtc->state))
>  -put_domains[to_intel_crtc(crtc)->pipe] =
>  -modeset_get_crtc_power_domains(crtc);
>  +struct intel_crtc *intel_crtc =
>  +to_intel_crtc(crtc);
>  +enum pipe pipe = intel_crtc->pipe;
>  +
>  +if (!needs_modeset(crtc->state))
>  +continue;
>  +
>  +put_domains[pipe] = 
>  modeset_get_crtc_power_domains(crtc);
>   }
>   
>   if (dev_priv->display.modeset_commit_cdclk) {
>  -unsigned int cdclk = 
>  to_intel_atomic_state(state)->cdclk;
>  +unsigned int cdclk = intel_state->cdclk;
>   
>   if (cdclk != dev_priv->cdclk_freq &&
>   !WARN_ON(!state->allow_modeset))
>  @@ -5938,23 +5944,32 @@ static int broxton_calc_cdclk(struct 
>  drm_i915_private *dev_priv,
>   static int intel_mode_max_pixclk(struct drm_device *dev,
>    struct drm_atomic_state *state)
>   {
>  -struct intel_crtc *intel_crtc;
>  -struct intel_crtc_state *crtc_state;
>  -

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)



On 27/10/15 13:48, Ville Syrjälä wrote:

On Tue, Oct 27, 2015 at 01:34:44PM +, Tvrtko Ursulin wrote:


On 27/10/15 12:51, Ville Syrjälä wrote:

On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:

While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.

v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).

Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Signed-off-by: Vivek Kasireddy 
---
   drivers/gpu/drm/i915/intel_display.c | 3 ++-
   1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 52fb3f2..108c000 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
 * framebuffer compression.  For simplicity, we always install
 * a fence as the cost is not that onerous.
 */
-   ret = i915_gem_object_get_fence(obj);
+   if (obj->map_and_fenceable)


This will now get the fence and pin it for the 90/270 view as well,
even though the fence doesn't even cover that particualr gtt mapping.


I don't follow. obj->map_and_fenceable will be true only when normal
view exists, so this avoids setting up the fence when no normal view
exists and so avoids the WARN_ON in i915_gem_object_get_fence.


Sure, but it's pointless to use up a fence if all we care about
is the 90/270 mapping.


After a brief IRC discussion we agreed that the patch doesn't introduce 
any new negative behaviours.


But in general it may be beneficial to revisit the approach of always 
installing fences. Especially as the number of pipes and planes grows 
and if number of fences remains static.


Regards,

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

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Do not acquire crtc state to check clock during modeset, v2.

On Tue, Oct 27, 2015 at 02:41:16PM +0100, Maarten Lankhorst wrote:
> Op 27-10-15 om 14:29 schreef Ville Syrjälä:
> > On Tue, Oct 27, 2015 at 02:26:31PM +0100, Maarten Lankhorst wrote:
> >> Parallel modesets are still not allowed, but this will allow updating
> >> a different crtc during a modeset if the clock is not changed.
> >>
> >> Additionally when all pipes are DPMS off the cdclk will be lowered
> >> to the minimum allowed.
> >>
> >> Changes since v1:
> >> - Add dev_priv->active_crtcs for tracking which crtcs are active.
> >> - Rename min_cdclk to min_pixclk and move to dev_priv.
> >> - Add a active_crtcs mask which is updated atomically.
> >> - Add intel_atomic_state->modeset which is set on modesets.
> >> - Commit new pixclk/active_crtcs right after state swap.
> >>
> >> Signed-off-by: Maarten Lankhorst 
> >> ---
> >>  drivers/gpu/drm/i915/i915_drv.h  |   5 ++
> >>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +-
> >>  drivers/gpu/drm/i915/intel_display.c | 160 
> >> +--
> >>  drivers/gpu/drm/i915/intel_drv.h |   7 +-
> >>  4 files changed, 125 insertions(+), 49 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >> b/drivers/gpu/drm/i915/i915_drv.h
> >> index 59c94929f25b..37eef86e4a0a 100644
> >> --- a/drivers/gpu/drm/i915/i915_drv.h
> >> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >> @@ -1837,8 +1837,13 @@ struct drm_i915_private {
> >>struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
> >>  #endif
> >>  
> >> +  /* dpll and cdclk state is protected by connection_mutex */
> >>int num_shared_dpll;
> >>struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
> >> +
> >> +  unsigned int active_crtcs;
> >> +  unsigned int min_pixclk[I915_MAX_PIPES];
> >> +
> >>int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
> >>  
> >>struct i915_workarounds workarounds;
> >> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> >> b/drivers/gpu/drm/i915/intel_atomic.c
> >> index 25a891aa3824..cb8fcf4fe7f2 100644
> >> --- a/drivers/gpu/drm/i915/intel_atomic.c
> >> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> >> @@ -305,5 +305,5 @@ void intel_atomic_state_clear(struct drm_atomic_state 
> >> *s)
> >>  {
> >>struct intel_atomic_state *state = to_intel_atomic_state(s);
> >>drm_atomic_state_default_clear(&state->base);
> >> -  state->dpll_set = false;
> >> +  state->dpll_set = state->modeset = false;
> >>  }
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 022e628b8520..a0508d5e9e13 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -5237,6 +5237,7 @@ static void modeset_put_power_domains(struct 
> >> drm_i915_private *dev_priv,
> >>  
> >>  static void modeset_update_crtc_power_domains(struct drm_atomic_state 
> >> *state)
> >>  {
> >> +  struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> >>struct drm_device *dev = state->dev;
> >>struct drm_i915_private *dev_priv = dev->dev_private;
> >>unsigned long put_domains[I915_MAX_PIPES] = {};
> >> @@ -5245,13 +5246,18 @@ static void 
> >> modeset_update_crtc_power_domains(struct drm_atomic_state *state)
> >>int i;
> >>  
> >>for_each_crtc_in_state(state, crtc, crtc_state, i) {
> >> -  if (needs_modeset(crtc->state))
> >> -  put_domains[to_intel_crtc(crtc)->pipe] =
> >> -  modeset_get_crtc_power_domains(crtc);
> >> +  struct intel_crtc *intel_crtc =
> >> +  to_intel_crtc(crtc);
> >> +  enum pipe pipe = intel_crtc->pipe;
> >> +
> >> +  if (!needs_modeset(crtc->state))
> >> +  continue;
> >> +
> >> +  put_domains[pipe] = modeset_get_crtc_power_domains(crtc);
> >>}
> >>  
> >>if (dev_priv->display.modeset_commit_cdclk) {
> >> -  unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
> >> +  unsigned int cdclk = intel_state->cdclk;
> >>  
> >>if (cdclk != dev_priv->cdclk_freq &&
> >>!WARN_ON(!state->allow_modeset))
> >> @@ -5938,23 +5944,32 @@ static int broxton_calc_cdclk(struct 
> >> drm_i915_private *dev_priv,
> >>  static int intel_mode_max_pixclk(struct drm_device *dev,
> >> struct drm_atomic_state *state)
> >>  {
> >> -  struct intel_crtc *intel_crtc;
> >> -  struct intel_crtc_state *crtc_state;
> >> -  int max_pixclk = 0;
> >> +  struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> >> +  struct drm_i915_private *dev_priv = dev->dev_private;
> >> +  struct drm_crtc *crtc;
> >> +  struct drm_crtc_state *crtc_state;
> >> +  unsigned max_pixel_rate = 0, i;
> >> +  enum pipe pipe;
> >>  
> >> -  for_each_intel_crtc(dev, intel_crtc) {
> >> -  crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
> >> -  if (IS_ERR(crtc_state))
> >> -  return PTR_ERR(crtc_state);
> >> +  memcpy(intel_state->min_pixclk, dev_p

Re: [Intel-gfx] [PATCH] drm/i915: Fix maxfifo watermark calc on vlv cursor planes

On Fri, 23 Oct 2015, Ville Syrjälä  wrote:
> On Fri, Oct 23, 2015 at 02:55:38PM +0100, Thomas Daniel wrote:
>> A typo resulted in the watermarks for cursor planes not being calculated
>> correctly.  Fixed the typo.
>> 
>> Cc: Ville Syrjälä 
>> Signed-off-by: Thomas Daniel 
>> ---
>>  drivers/gpu/drm/i915/intel_pm.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/intel_pm.c 
>> b/drivers/gpu/drm/i915/intel_pm.c
>> index 0fb0459..c01dd2b 100644
>> --- a/drivers/gpu/drm/i915/intel_pm.c
>> +++ b/drivers/gpu/drm/i915/intel_pm.c
>> @@ -1135,7 +1135,7 @@ static void vlv_compute_wm(struct intel_crtc *crtc)
>>  case DRM_PLANE_TYPE_CURSOR:
>>  for (level = 0; level < wm_state->num_levels; level++)
>>  wm_state->sr[level].cursor =
>> -wm_state->sr[level].cursor;
>> +wm_state->wm[level].cursor;
>
> Yeah, the code is clearly wrong, but due to the fact that we initialize
> the sr wm to the max (63) initially, this shouldn't have actually caused
> any underruns and whatnot.
>
> The patch is correct in any case.
> Reviewed-by: Ville Syrjälä 

Pushed to drm-intel-next-fixes, thanks for the patch and review.

BR,
Jani.

>
>>  break;
>>  case DRM_PLANE_TYPE_PRIMARY:
>>  for (level = 0; level < wm_state->num_levels; level++)
>> -- 
>> 1.9.1

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Do not acquire crtc state to check clock during modeset, v2.

Op 27-10-15 om 14:49 schreef Ville Syrjälä:
> On Tue, Oct 27, 2015 at 02:41:16PM +0100, Maarten Lankhorst wrote:
>> Op 27-10-15 om 14:29 schreef Ville Syrjälä:
>>> On Tue, Oct 27, 2015 at 02:26:31PM +0100, Maarten Lankhorst wrote:
 Parallel modesets are still not allowed, but this will allow updating
 a different crtc during a modeset if the clock is not changed.

 Additionally when all pipes are DPMS off the cdclk will be lowered
 to the minimum allowed.

 Changes since v1:
 - Add dev_priv->active_crtcs for tracking which crtcs are active.
 - Rename min_cdclk to min_pixclk and move to dev_priv.
 - Add a active_crtcs mask which is updated atomically.
 - Add intel_atomic_state->modeset which is set on modesets.
 - Commit new pixclk/active_crtcs right after state swap.

 Signed-off-by: Maarten Lankhorst 
 ---
  drivers/gpu/drm/i915/i915_drv.h  |   5 ++
  drivers/gpu/drm/i915/intel_atomic.c  |   2 +-
  drivers/gpu/drm/i915/intel_display.c | 160 
 +--
  drivers/gpu/drm/i915/intel_drv.h |   7 +-
  4 files changed, 125 insertions(+), 49 deletions(-)

 diff --git a/drivers/gpu/drm/i915/i915_drv.h 
 b/drivers/gpu/drm/i915/i915_drv.h
 index 59c94929f25b..37eef86e4a0a 100644
 --- a/drivers/gpu/drm/i915/i915_drv.h
 +++ b/drivers/gpu/drm/i915/i915_drv.h
 @@ -1837,8 +1837,13 @@ struct drm_i915_private {
struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
  #endif
  
 +  /* dpll and cdclk state is protected by connection_mutex */
int num_shared_dpll;
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
 +
 +  unsigned int active_crtcs;
 +  unsigned int min_pixclk[I915_MAX_PIPES];
 +
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
  
struct i915_workarounds workarounds;
 diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
 b/drivers/gpu/drm/i915/intel_atomic.c
 index 25a891aa3824..cb8fcf4fe7f2 100644
 --- a/drivers/gpu/drm/i915/intel_atomic.c
 +++ b/drivers/gpu/drm/i915/intel_atomic.c
 @@ -305,5 +305,5 @@ void intel_atomic_state_clear(struct drm_atomic_state 
 *s)
  {
struct intel_atomic_state *state = to_intel_atomic_state(s);
drm_atomic_state_default_clear(&state->base);
 -  state->dpll_set = false;
 +  state->dpll_set = state->modeset = false;
  }
 diff --git a/drivers/gpu/drm/i915/intel_display.c 
 b/drivers/gpu/drm/i915/intel_display.c
 index 022e628b8520..a0508d5e9e13 100644
 --- a/drivers/gpu/drm/i915/intel_display.c
 +++ b/drivers/gpu/drm/i915/intel_display.c
 @@ -5237,6 +5237,7 @@ static void modeset_put_power_domains(struct 
 drm_i915_private *dev_priv,
  
  static void modeset_update_crtc_power_domains(struct drm_atomic_state 
 *state)
  {
 +  struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_device *dev = state->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long put_domains[I915_MAX_PIPES] = {};
 @@ -5245,13 +5246,18 @@ static void 
 modeset_update_crtc_power_domains(struct drm_atomic_state *state)
int i;
  
for_each_crtc_in_state(state, crtc, crtc_state, i) {
 -  if (needs_modeset(crtc->state))
 -  put_domains[to_intel_crtc(crtc)->pipe] =
 -  modeset_get_crtc_power_domains(crtc);
 +  struct intel_crtc *intel_crtc =
 +  to_intel_crtc(crtc);
 +  enum pipe pipe = intel_crtc->pipe;
 +
 +  if (!needs_modeset(crtc->state))
 +  continue;
 +
 +  put_domains[pipe] = modeset_get_crtc_power_domains(crtc);
}
  
if (dev_priv->display.modeset_commit_cdclk) {
 -  unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
 +  unsigned int cdclk = intel_state->cdclk;
  
if (cdclk != dev_priv->cdclk_freq &&
!WARN_ON(!state->allow_modeset))
 @@ -5938,23 +5944,32 @@ static int broxton_calc_cdclk(struct 
 drm_i915_private *dev_priv,
  static int intel_mode_max_pixclk(struct drm_device *dev,
 struct drm_atomic_state *state)
  {
 -  struct intel_crtc *intel_crtc;
 -  struct intel_crtc_state *crtc_state;
 -  int max_pixclk = 0;
 +  struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
 +  struct drm_i915_private *dev_priv = dev->dev_private;
 +  struct drm_crtc *crtc;
 +  struct drm_crtc_state *crtc_state;
 +  unsigned max_pixel_rate = 0, i;
 +  enum pipe pipe;
  
 -  for_each_intel_crtc(dev, intel_crtc) {
 -  crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
 -  if (IS_ERR(crtc_state))
 -  return PTR_ERR(crtc_state)

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)

On Tue, Oct 27, 2015 at 01:34:44PM +, Tvrtko Ursulin wrote:
> 
> On 27/10/15 12:51, Ville Syrjälä wrote:
> > On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:
> >> While pinning a fb object to the display plane, only install a fence
> >> if the object is using a normal view. This corresponds with the
> >> behavior found in i915_gem_object_do_pin() where the fencability
> >> criteria is determined only for objects with normal views.
> >>
> >> v2:
> >> Look at the object's map_and_fenceable flag to determine whether to
> >> install a fence or not (Chris).
> >>
> >> Cc: Chris Wilson 
> >> Cc: Tvrtko Ursulin 
> >> Cc: Daniel Vetter 
> >> Signed-off-by: Vivek Kasireddy 
> >> ---
> >>   drivers/gpu/drm/i915/intel_display.c | 3 ++-
> >>   1 file changed, 2 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >> b/drivers/gpu/drm/i915/intel_display.c
> >> index 52fb3f2..108c000 100644
> >> --- a/drivers/gpu/drm/i915/intel_display.c
> >> +++ b/drivers/gpu/drm/i915/intel_display.c
> >> @@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
> >> * framebuffer compression.  For simplicity, we always install
> >> * a fence as the cost is not that onerous.
> >> */
> >> -  ret = i915_gem_object_get_fence(obj);
> >> +  if (obj->map_and_fenceable)
> >
> > This will now get the fence and pin it for the 90/270 view as well,
> > even though the fence doesn't even cover that particualr gtt mapping.
> 
> I don't follow. obj->map_and_fenceable will be true only when normal 
> view exists, so this avoids setting up the fence when no normal view 
> exists and so avoids the WARN_ON in i915_gem_object_get_fence.

Sure, but it's pointless to use up a fence if all we care about
is the 90/270 mapping.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Do not acquire crtc state to check clock during modeset, v2.

Op 27-10-15 om 14:29 schreef Ville Syrjälä:
> On Tue, Oct 27, 2015 at 02:26:31PM +0100, Maarten Lankhorst wrote:
>> Parallel modesets are still not allowed, but this will allow updating
>> a different crtc during a modeset if the clock is not changed.
>>
>> Additionally when all pipes are DPMS off the cdclk will be lowered
>> to the minimum allowed.
>>
>> Changes since v1:
>> - Add dev_priv->active_crtcs for tracking which crtcs are active.
>> - Rename min_cdclk to min_pixclk and move to dev_priv.
>> - Add a active_crtcs mask which is updated atomically.
>> - Add intel_atomic_state->modeset which is set on modesets.
>> - Commit new pixclk/active_crtcs right after state swap.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/i915/i915_drv.h  |   5 ++
>>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +-
>>  drivers/gpu/drm/i915/intel_display.c | 160 
>> +--
>>  drivers/gpu/drm/i915/intel_drv.h |   7 +-
>>  4 files changed, 125 insertions(+), 49 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 59c94929f25b..37eef86e4a0a 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -1837,8 +1837,13 @@ struct drm_i915_private {
>>  struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
>>  #endif
>>  
>> +/* dpll and cdclk state is protected by connection_mutex */
>>  int num_shared_dpll;
>>  struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
>> +
>> +unsigned int active_crtcs;
>> +unsigned int min_pixclk[I915_MAX_PIPES];
>> +
>>  int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>>  
>>  struct i915_workarounds workarounds;
>> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
>> b/drivers/gpu/drm/i915/intel_atomic.c
>> index 25a891aa3824..cb8fcf4fe7f2 100644
>> --- a/drivers/gpu/drm/i915/intel_atomic.c
>> +++ b/drivers/gpu/drm/i915/intel_atomic.c
>> @@ -305,5 +305,5 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
>>  {
>>  struct intel_atomic_state *state = to_intel_atomic_state(s);
>>  drm_atomic_state_default_clear(&state->base);
>> -state->dpll_set = false;
>> +state->dpll_set = state->modeset = false;
>>  }
>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
>> b/drivers/gpu/drm/i915/intel_display.c
>> index 022e628b8520..a0508d5e9e13 100644
>> --- a/drivers/gpu/drm/i915/intel_display.c
>> +++ b/drivers/gpu/drm/i915/intel_display.c
>> @@ -5237,6 +5237,7 @@ static void modeset_put_power_domains(struct 
>> drm_i915_private *dev_priv,
>>  
>>  static void modeset_update_crtc_power_domains(struct drm_atomic_state 
>> *state)
>>  {
>> +struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>>  struct drm_device *dev = state->dev;
>>  struct drm_i915_private *dev_priv = dev->dev_private;
>>  unsigned long put_domains[I915_MAX_PIPES] = {};
>> @@ -5245,13 +5246,18 @@ static void modeset_update_crtc_power_domains(struct 
>> drm_atomic_state *state)
>>  int i;
>>  
>>  for_each_crtc_in_state(state, crtc, crtc_state, i) {
>> -if (needs_modeset(crtc->state))
>> -put_domains[to_intel_crtc(crtc)->pipe] =
>> -modeset_get_crtc_power_domains(crtc);
>> +struct intel_crtc *intel_crtc =
>> +to_intel_crtc(crtc);
>> +enum pipe pipe = intel_crtc->pipe;
>> +
>> +if (!needs_modeset(crtc->state))
>> +continue;
>> +
>> +put_domains[pipe] = modeset_get_crtc_power_domains(crtc);
>>  }
>>  
>>  if (dev_priv->display.modeset_commit_cdclk) {
>> -unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
>> +unsigned int cdclk = intel_state->cdclk;
>>  
>>  if (cdclk != dev_priv->cdclk_freq &&
>>  !WARN_ON(!state->allow_modeset))
>> @@ -5938,23 +5944,32 @@ static int broxton_calc_cdclk(struct 
>> drm_i915_private *dev_priv,
>>  static int intel_mode_max_pixclk(struct drm_device *dev,
>>   struct drm_atomic_state *state)
>>  {
>> -struct intel_crtc *intel_crtc;
>> -struct intel_crtc_state *crtc_state;
>> -int max_pixclk = 0;
>> +struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>> +struct drm_i915_private *dev_priv = dev->dev_private;
>> +struct drm_crtc *crtc;
>> +struct drm_crtc_state *crtc_state;
>> +unsigned max_pixel_rate = 0, i;
>> +enum pipe pipe;
>>  
>> -for_each_intel_crtc(dev, intel_crtc) {
>> -crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
>> -if (IS_ERR(crtc_state))
>> -return PTR_ERR(crtc_state);
>> +memcpy(intel_state->min_pixclk, dev_priv->min_pixclk,
>> +   sizeof(intel_state->min_pixclk));
>>  
>> -if (!crtc_state->base.enable)
>> -continue;
>> +for_each_crtc_in_state(state, crtc, crtc_state

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Share cdclk code for BDW and BXT

On Tue, 27 Oct 2015, ville.syrj...@linux.intel.com wrote:
> From: Ville Syrjälä 
>
> The difference betwen the BXT and BDW cdclk code boils down to two
> things: claming the cdclk to the maximum supported, and panel fitter
> downscaling ratio
>
> Unifying the the max cdclk clamping is easy, just do it.
>
> And as far as the panel fitter is concerned, SKL+ already (ab)use the
> pch pfit state for its pipe scaler information, so it will compute the
> adjusted pixel rate correctly.
>
> So we can just use the BDW code for BXT, as long as we lift the BXT
> pixel rate -> cdclk selection into the correct place.

I don't like the direction taken by this patch.

We have the platform specific functions to keep stuff platform
specific. Now you claim bdw and bxt are almost the same, yet the
functions are filled with conditionals on the platform. I value having
straightforward and readable platform specific hooks much higher than
the slight reduction in line count.

BR,
Jani.

>
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 87 
> +---
>  1 file changed, 30 insertions(+), 57 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 978f543..0c782c7 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5932,25 +5932,6 @@ static int valleyview_calc_cdclk(struct 
> drm_i915_private *dev_priv,
>   return 20;
>  }
>  
> -static int broxton_calc_cdclk(struct drm_i915_private *dev_priv,
> -   int max_pixclk)
> -{
> - /*
> -  * FIXME:
> -  * - set 19.2MHz bypass frequency if there are no active pipes
> -  */
> - if (max_pixclk > 576000)
> - return 624000;
> - else if (max_pixclk > 384000)
> - return 576000;
> - else if (max_pixclk > 288000)
> - return 384000;
> - else if (max_pixclk > 144000)
> - return 288000;
> - else
> - return 144000;
> -}
> -
>  /* Compute the max pixel clock for new configuration. Uses atomic state if
>   * that's non-NULL, look at current state otherwise. */
>  static int intel_mode_max_pixclk(struct drm_device *dev,
> @@ -5990,21 +5971,6 @@ static int valleyview_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>   return 0;
>  }
>  
> -static int broxton_modeset_calc_cdclk(struct drm_atomic_state *state)
> -{
> - struct drm_device *dev = state->dev;
> - struct drm_i915_private *dev_priv = dev->dev_private;
> - int max_pixclk = intel_mode_max_pixclk(dev, state);
> -
> - if (max_pixclk < 0)
> - return max_pixclk;
> -
> - to_intel_atomic_state(state)->cdclk =
> - broxton_calc_cdclk(dev_priv, max_pixclk);
> -
> - return 0;
> -}
> -
>  static void vlv_program_pfi_credits(struct drm_i915_private *dev_priv)
>  {
>   unsigned int credits, default_credits;
> @@ -9497,14 +9463,6 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
>   intel_prepare_ddi(dev);
>  }
>  
> -static void broxton_modeset_commit_cdclk(struct drm_atomic_state *old_state)
> -{
> - struct drm_device *dev = old_state->dev;
> - unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
> -
> - broxton_set_cdclk(dev, req_cdclk);
> -}
> -
>  /* compute the max rate for new configuration */
>  static int ilk_max_pixel_rate(struct drm_atomic_state *state)
>  {
> @@ -9621,14 +9579,31 @@ static int broadwell_modeset_calc_cdclk(struct 
> drm_atomic_state *state)
>* FIXME should also account for plane ratio
>* once 64bpp pixel formats are supported.
>*/
> - if (max_pixclk > 54)
> - cdclk = 675000;
> - else if (max_pixclk > 45)
> - cdclk = 54;
> - else if (max_pixclk > 337500)
> - cdclk = 45;
> - else
> - cdclk = 337500;
> + if (IS_BROXTON(dev_priv)) {
> + /*
> +  * FIXME:
> +  * - set 19.2MHz bypass frequency if there are no active pipes
> +  */
> + if (max_pixclk > 576000)
> + cdclk = 624000;
> + else if (max_pixclk > 384000)
> + cdclk = 576000;
> + else if (max_pixclk > 288000)
> + cdclk = 384000;
> + else if (max_pixclk > 144000)
> + cdclk = 288000;
> + else
> + cdclk = 144000;
> + } else {
> + if (max_pixclk > 54)
> + cdclk = 675000;
> + else if (max_pixclk > 45)
> + cdclk = 54;
> + else if (max_pixclk > 337500)
> + cdclk = 45;
> + else
> + cdclk = 337500;
> + }
>  
>   /*
>* FIXME move the cdclk caclulation to
> @@ -9650,7 +9625,10 @@ static void broadwell_modeset_commit_cdclk(struc

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)



On 27/10/15 12:51, Ville Syrjälä wrote:

On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:

While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.

v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).

Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Signed-off-by: Vivek Kasireddy 
---
  drivers/gpu/drm/i915/intel_display.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 52fb3f2..108c000 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
 * framebuffer compression.  For simplicity, we always install
 * a fence as the cost is not that onerous.
 */
-   ret = i915_gem_object_get_fence(obj);
+   if (obj->map_and_fenceable)


This will now get the fence and pin it for the 90/270 view as well,
even though the fence doesn't even cover that particualr gtt mapping.


I don't follow. obj->map_and_fenceable will be true only when normal 
view exists, so this avoids setting up the fence when no normal view 
exists and so avoids the WARN_ON in i915_gem_object_get_fence.


Regards,

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915/bxt: Use the bypass frequency if there are no active pipes.

On Tue, Oct 27, 2015 at 02:26:33PM +0100, Maarten Lankhorst wrote:
> Now that pixel clock is set to 0 when there are no active pipes it's
> easy to set the bypass frequency for this case.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index e9a94ddcba73..ddac097cd08a 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5925,7 +5925,6 @@ static int broxton_calc_cdclk(struct drm_i915_private 
> *dev_priv,
>   /*
>* FIXME:
>* - remove the guardband, it's not needed on BXT
> -  * - set 19.2MHz bypass frequency if there are no active pipes
>*/
>   if (max_pixclk > 576000*9/10)
>   return 624000;
> @@ -5935,8 +5934,10 @@ static int broxton_calc_cdclk(struct drm_i915_private 
> *dev_priv,
>   return 384000;
>   else if (max_pixclk > 144000*9/10)
>   return 288000;
> - else
> + else if (max_pixclk)
>   return 144000;
> + else
> + return 19200;

I think we want to test this on actual hardware before putting it in.
Also we might want to do something similar on other platforms too.

>  }
>  
>  /* Compute the max pixel clock for new configuration. Uses atomic state if
> -- 
> 2.1.0

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Do not acquire crtc state to check clock during modeset, v2.

On Tue, Oct 27, 2015 at 02:26:31PM +0100, Maarten Lankhorst wrote:
> Parallel modesets are still not allowed, but this will allow updating
> a different crtc during a modeset if the clock is not changed.
> 
> Additionally when all pipes are DPMS off the cdclk will be lowered
> to the minimum allowed.
> 
> Changes since v1:
> - Add dev_priv->active_crtcs for tracking which crtcs are active.
> - Rename min_cdclk to min_pixclk and move to dev_priv.
> - Add a active_crtcs mask which is updated atomically.
> - Add intel_atomic_state->modeset which is set on modesets.
> - Commit new pixclk/active_crtcs right after state swap.
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |   5 ++
>  drivers/gpu/drm/i915/intel_atomic.c  |   2 +-
>  drivers/gpu/drm/i915/intel_display.c | 160 
> +--
>  drivers/gpu/drm/i915/intel_drv.h |   7 +-
>  4 files changed, 125 insertions(+), 49 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 59c94929f25b..37eef86e4a0a 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -1837,8 +1837,13 @@ struct drm_i915_private {
>   struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
>  #endif
>  
> + /* dpll and cdclk state is protected by connection_mutex */
>   int num_shared_dpll;
>   struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
> +
> + unsigned int active_crtcs;
> + unsigned int min_pixclk[I915_MAX_PIPES];
> +
>   int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
>  
>   struct i915_workarounds workarounds;
> diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
> b/drivers/gpu/drm/i915/intel_atomic.c
> index 25a891aa3824..cb8fcf4fe7f2 100644
> --- a/drivers/gpu/drm/i915/intel_atomic.c
> +++ b/drivers/gpu/drm/i915/intel_atomic.c
> @@ -305,5 +305,5 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
>  {
>   struct intel_atomic_state *state = to_intel_atomic_state(s);
>   drm_atomic_state_default_clear(&state->base);
> - state->dpll_set = false;
> + state->dpll_set = state->modeset = false;
>  }
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 022e628b8520..a0508d5e9e13 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -5237,6 +5237,7 @@ static void modeset_put_power_domains(struct 
> drm_i915_private *dev_priv,
>  
>  static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
>  {
> + struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
>   struct drm_device *dev = state->dev;
>   struct drm_i915_private *dev_priv = dev->dev_private;
>   unsigned long put_domains[I915_MAX_PIPES] = {};
> @@ -5245,13 +5246,18 @@ static void modeset_update_crtc_power_domains(struct 
> drm_atomic_state *state)
>   int i;
>  
>   for_each_crtc_in_state(state, crtc, crtc_state, i) {
> - if (needs_modeset(crtc->state))
> - put_domains[to_intel_crtc(crtc)->pipe] =
> - modeset_get_crtc_power_domains(crtc);
> + struct intel_crtc *intel_crtc =
> + to_intel_crtc(crtc);
> + enum pipe pipe = intel_crtc->pipe;
> +
> + if (!needs_modeset(crtc->state))
> + continue;
> +
> + put_domains[pipe] = modeset_get_crtc_power_domains(crtc);
>   }
>  
>   if (dev_priv->display.modeset_commit_cdclk) {
> - unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
> + unsigned int cdclk = intel_state->cdclk;
>  
>   if (cdclk != dev_priv->cdclk_freq &&
>   !WARN_ON(!state->allow_modeset))
> @@ -5938,23 +5944,32 @@ static int broxton_calc_cdclk(struct drm_i915_private 
> *dev_priv,
>  static int intel_mode_max_pixclk(struct drm_device *dev,
>struct drm_atomic_state *state)
>  {
> - struct intel_crtc *intel_crtc;
> - struct intel_crtc_state *crtc_state;
> - int max_pixclk = 0;
> + struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
> + struct drm_i915_private *dev_priv = dev->dev_private;
> + struct drm_crtc *crtc;
> + struct drm_crtc_state *crtc_state;
> + unsigned max_pixel_rate = 0, i;
> + enum pipe pipe;
>  
> - for_each_intel_crtc(dev, intel_crtc) {
> - crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
> - if (IS_ERR(crtc_state))
> - return PTR_ERR(crtc_state);
> + memcpy(intel_state->min_pixclk, dev_priv->min_pixclk,
> +sizeof(intel_state->min_pixclk));
>  
> - if (!crtc_state->base.enable)
> - continue;
> + for_each_crtc_in_state(state, crtc, crtc_state, i) {
> + int pixclk = 0;
>  
> - max_pixclk = max(max_pixclk,
> -

[Intel-gfx] [PATCH 1/3] drm/i915: Do not acquire crtc state to check clock during modeset, v2.

Parallel modesets are still not allowed, but this will allow updating
a different crtc during a modeset if the clock is not changed.

Additionally when all pipes are DPMS off the cdclk will be lowered
to the minimum allowed.

Changes since v1:
- Add dev_priv->active_crtcs for tracking which crtcs are active.
- Rename min_cdclk to min_pixclk and move to dev_priv.
- Add a active_crtcs mask which is updated atomically.
- Add intel_atomic_state->modeset which is set on modesets.
- Commit new pixclk/active_crtcs right after state swap.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/i915_drv.h  |   5 ++
 drivers/gpu/drm/i915/intel_atomic.c  |   2 +-
 drivers/gpu/drm/i915/intel_display.c | 160 +--
 drivers/gpu/drm/i915/intel_drv.h |   7 +-
 4 files changed, 125 insertions(+), 49 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 59c94929f25b..37eef86e4a0a 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1837,8 +1837,13 @@ struct drm_i915_private {
struct intel_pipe_crc pipe_crc[I915_MAX_PIPES];
 #endif
 
+   /* dpll and cdclk state is protected by connection_mutex */
int num_shared_dpll;
struct intel_shared_dpll shared_dplls[I915_NUM_PLLS];
+
+   unsigned int active_crtcs;
+   unsigned int min_pixclk[I915_MAX_PIPES];
+
int dpio_phy_iosf_port[I915_NUM_PHYS_VLV];
 
struct i915_workarounds workarounds;
diff --git a/drivers/gpu/drm/i915/intel_atomic.c 
b/drivers/gpu/drm/i915/intel_atomic.c
index 25a891aa3824..cb8fcf4fe7f2 100644
--- a/drivers/gpu/drm/i915/intel_atomic.c
+++ b/drivers/gpu/drm/i915/intel_atomic.c
@@ -305,5 +305,5 @@ void intel_atomic_state_clear(struct drm_atomic_state *s)
 {
struct intel_atomic_state *state = to_intel_atomic_state(s);
drm_atomic_state_default_clear(&state->base);
-   state->dpll_set = false;
+   state->dpll_set = state->modeset = false;
 }
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 022e628b8520..a0508d5e9e13 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5237,6 +5237,7 @@ static void modeset_put_power_domains(struct 
drm_i915_private *dev_priv,
 
 static void modeset_update_crtc_power_domains(struct drm_atomic_state *state)
 {
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
struct drm_device *dev = state->dev;
struct drm_i915_private *dev_priv = dev->dev_private;
unsigned long put_domains[I915_MAX_PIPES] = {};
@@ -5245,13 +5246,18 @@ static void modeset_update_crtc_power_domains(struct 
drm_atomic_state *state)
int i;
 
for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (needs_modeset(crtc->state))
-   put_domains[to_intel_crtc(crtc)->pipe] =
-   modeset_get_crtc_power_domains(crtc);
+   struct intel_crtc *intel_crtc =
+   to_intel_crtc(crtc);
+   enum pipe pipe = intel_crtc->pipe;
+
+   if (!needs_modeset(crtc->state))
+   continue;
+
+   put_domains[pipe] = modeset_get_crtc_power_domains(crtc);
}
 
if (dev_priv->display.modeset_commit_cdclk) {
-   unsigned int cdclk = to_intel_atomic_state(state)->cdclk;
+   unsigned int cdclk = intel_state->cdclk;
 
if (cdclk != dev_priv->cdclk_freq &&
!WARN_ON(!state->allow_modeset))
@@ -5938,23 +5944,32 @@ static int broxton_calc_cdclk(struct drm_i915_private 
*dev_priv,
 static int intel_mode_max_pixclk(struct drm_device *dev,
 struct drm_atomic_state *state)
 {
-   struct intel_crtc *intel_crtc;
-   struct intel_crtc_state *crtc_state;
-   int max_pixclk = 0;
+   struct intel_atomic_state *intel_state = to_intel_atomic_state(state);
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct drm_crtc *crtc;
+   struct drm_crtc_state *crtc_state;
+   unsigned max_pixel_rate = 0, i;
+   enum pipe pipe;
 
-   for_each_intel_crtc(dev, intel_crtc) {
-   crtc_state = intel_atomic_get_crtc_state(state, intel_crtc);
-   if (IS_ERR(crtc_state))
-   return PTR_ERR(crtc_state);
+   memcpy(intel_state->min_pixclk, dev_priv->min_pixclk,
+  sizeof(intel_state->min_pixclk));
 
-   if (!crtc_state->base.enable)
-   continue;
+   for_each_crtc_in_state(state, crtc, crtc_state, i) {
+   int pixclk = 0;
 
-   max_pixclk = max(max_pixclk,
-crtc_state->base.adjusted_mode.crtc_clock);
+   if (crtc_state->enable)
+   pixclk = crtc_state->adjusted_mode.crtc_clock;
+
+   intel_state->mi

[Intel-gfx] [PATCH 3/3] drm/i915/bxt: Use the bypass frequency if there are no active pipes.

Now that pixel clock is set to 0 when there are no active pipes it's
easy to set the bypass frequency for this case.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index e9a94ddcba73..ddac097cd08a 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5925,7 +5925,6 @@ static int broxton_calc_cdclk(struct drm_i915_private 
*dev_priv,
/*
 * FIXME:
 * - remove the guardband, it's not needed on BXT
-* - set 19.2MHz bypass frequency if there are no active pipes
 */
if (max_pixclk > 576000*9/10)
return 624000;
@@ -5935,8 +5934,10 @@ static int broxton_calc_cdclk(struct drm_i915_private 
*dev_priv,
return 384000;
else if (max_pixclk > 144000*9/10)
return 288000;
-   else
+   else if (max_pixclk)
return 144000;
+   else
+   return 19200;
 }
 
 /* Compute the max pixel clock for new configuration. Uses atomic state if
-- 
2.1.0

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

[Intel-gfx] [PATCH 2/3] drm/i915: Handle cdclk limits on broadwell.

As the comment indicates this can only fail gracefully when
called from compute_config. Fortunately this is now what's happening,
so the fixme can be removed and the DRM_ERROR downgraded.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/i915/intel_display.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index a0508d5e9e13..e9a94ddcba73 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -9640,14 +9640,10 @@ static int broadwell_modeset_calc_cdclk(struct 
drm_atomic_state *state)
else
cdclk = 337500;
 
-   /*
-* FIXME move the cdclk caclulation to
-* compute_config() so we can fail gracegully.
-*/
if (cdclk > dev_priv->max_cdclk_freq) {
-   DRM_ERROR("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
- cdclk, dev_priv->max_cdclk_freq);
-   cdclk = dev_priv->max_cdclk_freq;
+   DRM_INFO("requested cdclk (%d kHz) exceeds max (%d kHz)\n",
+cdclk, dev_priv->max_cdclk_freq);
+   return -EINVAL;
}
 
to_intel_atomic_state(state)->cdclk = cdclk;
-- 
2.1.0

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

[Intel-gfx] [PATCH 3/3] drm/i915: Share cdclk code for BDW and BXT

2015-10-27 Thread ville . syrjala

From: Ville Syrjälä 

The difference betwen the BXT and BDW cdclk code boils down to two
things: claming the cdclk to the maximum supported, and panel fitter
downscaling ratio

Unifying the the max cdclk clamping is easy, just do it.

And as far as the panel fitter is concerned, SKL+ already (ab)use the
pch pfit state for its pipe scaler information, so it will compute the
adjusted pixel rate correctly.

So we can just use the BDW code for BXT, as long as we lift the BXT
pixel rate -> cdclk selection into the correct place.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 87 +---
 1 file changed, 30 insertions(+), 57 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 978f543..0c782c7 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5932,25 +5932,6 @@ static int valleyview_calc_cdclk(struct drm_i915_private 
*dev_priv,
return 20;
 }
 
-static int broxton_calc_cdclk(struct drm_i915_private *dev_priv,
- int max_pixclk)
-{
-   /*
-* FIXME:
-* - set 19.2MHz bypass frequency if there are no active pipes
-*/
-   if (max_pixclk > 576000)
-   return 624000;
-   else if (max_pixclk > 384000)
-   return 576000;
-   else if (max_pixclk > 288000)
-   return 384000;
-   else if (max_pixclk > 144000)
-   return 288000;
-   else
-   return 144000;
-}
-
 /* Compute the max pixel clock for new configuration. Uses atomic state if
  * that's non-NULL, look at current state otherwise. */
 static int intel_mode_max_pixclk(struct drm_device *dev,
@@ -5990,21 +5971,6 @@ static int valleyview_modeset_calc_cdclk(struct 
drm_atomic_state *state)
return 0;
 }
 
-static int broxton_modeset_calc_cdclk(struct drm_atomic_state *state)
-{
-   struct drm_device *dev = state->dev;
-   struct drm_i915_private *dev_priv = dev->dev_private;
-   int max_pixclk = intel_mode_max_pixclk(dev, state);
-
-   if (max_pixclk < 0)
-   return max_pixclk;
-
-   to_intel_atomic_state(state)->cdclk =
-   broxton_calc_cdclk(dev_priv, max_pixclk);
-
-   return 0;
-}
-
 static void vlv_program_pfi_credits(struct drm_i915_private *dev_priv)
 {
unsigned int credits, default_credits;
@@ -9497,14 +9463,6 @@ void hsw_disable_pc8(struct drm_i915_private *dev_priv)
intel_prepare_ddi(dev);
 }
 
-static void broxton_modeset_commit_cdclk(struct drm_atomic_state *old_state)
-{
-   struct drm_device *dev = old_state->dev;
-   unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
-
-   broxton_set_cdclk(dev, req_cdclk);
-}
-
 /* compute the max rate for new configuration */
 static int ilk_max_pixel_rate(struct drm_atomic_state *state)
 {
@@ -9621,14 +9579,31 @@ static int broadwell_modeset_calc_cdclk(struct 
drm_atomic_state *state)
 * FIXME should also account for plane ratio
 * once 64bpp pixel formats are supported.
 */
-   if (max_pixclk > 54)
-   cdclk = 675000;
-   else if (max_pixclk > 45)
-   cdclk = 54;
-   else if (max_pixclk > 337500)
-   cdclk = 45;
-   else
-   cdclk = 337500;
+   if (IS_BROXTON(dev_priv)) {
+   /*
+* FIXME:
+* - set 19.2MHz bypass frequency if there are no active pipes
+*/
+   if (max_pixclk > 576000)
+   cdclk = 624000;
+   else if (max_pixclk > 384000)
+   cdclk = 576000;
+   else if (max_pixclk > 288000)
+   cdclk = 384000;
+   else if (max_pixclk > 144000)
+   cdclk = 288000;
+   else
+   cdclk = 144000;
+   } else {
+   if (max_pixclk > 54)
+   cdclk = 675000;
+   else if (max_pixclk > 45)
+   cdclk = 54;
+   else if (max_pixclk > 337500)
+   cdclk = 45;
+   else
+   cdclk = 337500;
+   }
 
/*
 * FIXME move the cdclk caclulation to
@@ -9650,7 +9625,10 @@ static void broadwell_modeset_commit_cdclk(struct 
drm_atomic_state *old_state)
struct drm_device *dev = old_state->dev;
unsigned int req_cdclk = to_intel_atomic_state(old_state)->cdclk;
 
-   broadwell_set_cdclk(dev, req_cdclk);
+   if (IS_BROXTON(dev))
+   broxton_set_cdclk(dev, req_cdclk);
+   else
+   broadwell_set_cdclk(dev, req_cdclk);
 }
 
 static int haswell_crtc_compute_clock(struct intel_crtc *crtc,
@@ -14619,7 +14597,7 @@ static void intel_init_display(struct drm_device *dev)
dev_priv->display.fdi_link_train = hsw

[Intel-gfx] [PATCH 1/3] drm/i915: Remove 10% cdclk guardband from BXT

2015-10-27 Thread ville . syrjala

From: Ville Syrjälä 

BXT doesn't need any cdclk guardband, so don't use any.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 9 -
 1 file changed, 4 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bc1907e..b8095be 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -5937,16 +5937,15 @@ static int broxton_calc_cdclk(struct drm_i915_private 
*dev_priv,
 {
/*
 * FIXME:
-* - remove the guardband, it's not needed on BXT
 * - set 19.2MHz bypass frequency if there are no active pipes
 */
-   if (max_pixclk > 576000*9/10)
+   if (max_pixclk > 576000)
return 624000;
-   else if (max_pixclk > 384000*9/10)
+   else if (max_pixclk > 384000)
return 576000;
-   else if (max_pixclk > 288000*9/10)
+   else if (max_pixclk > 288000)
return 384000;
-   else if (max_pixclk > 144000*9/10)
+   else if (max_pixclk > 144000)
return 288000;
else
return 144000;
-- 
2.4.10

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

[Intel-gfx] [PATCH 2/3] drm/i915: Untangle .fdi_link_train() and cdclk function pointer assignments

2015-10-27 Thread ville . syrjala

From: Ville Syrjälä 

Clarify the code by doing the .fdi_link_train() and cdclk function
pointer assignments using two separate if-ladders.

Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index b8095be..978f543 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -14617,12 +14617,13 @@ static void intel_init_display(struct drm_device *dev)
dev_priv->display.fdi_link_train = ivb_manual_fdi_link_train;
} else if (IS_HASWELL(dev) || IS_BROADWELL(dev)) {
dev_priv->display.fdi_link_train = hsw_fdi_link_train;
-   if (IS_BROADWELL(dev)) {
-   dev_priv->display.modeset_commit_cdclk =
-   broadwell_modeset_commit_cdclk;
-   dev_priv->display.modeset_calc_cdclk =
-   broadwell_modeset_calc_cdclk;
-   }
+   }
+
+   if (IS_BROADWELL(dev)) {
+   dev_priv->display.modeset_commit_cdclk =
+   broadwell_modeset_commit_cdclk;
+   dev_priv->display.modeset_calc_cdclk =
+   broadwell_modeset_calc_cdclk;
} else if (IS_VALLEYVIEW(dev)) {
dev_priv->display.modeset_commit_cdclk =
valleyview_modeset_commit_cdclk;
-- 
2.4.10

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

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)

On Mon, Oct 26, 2015 at 06:23:26PM -0700, Vivek Kasireddy wrote:
> While pinning a fb object to the display plane, only install a fence
> if the object is using a normal view. This corresponds with the
> behavior found in i915_gem_object_do_pin() where the fencability
> criteria is determined only for objects with normal views.
> 
> v2:
> Look at the object's map_and_fenceable flag to determine whether to
> install a fence or not (Chris).
> 
> Cc: Chris Wilson 
> Cc: Tvrtko Ursulin 
> Cc: Daniel Vetter 
> Signed-off-by: Vivek Kasireddy 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 52fb3f2..108c000 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
>* framebuffer compression.  For simplicity, we always install
>* a fence as the cost is not that onerous.
>*/
> - ret = i915_gem_object_get_fence(obj);
> + if (obj->map_and_fenceable)

This will now get the fence and pin it for the 90/270 view as well,
even though the fence doesn't even cover that particualr gtt mapping.

> + ret = i915_gem_object_get_fence(obj);
>   if (ret == -EDEADLK) {
>   /*
>* -EDEADLK means there are no free fences
> -- 
> 2.4.3
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 7/7] drm/i915: Add dmc firmware load state and version to error state

We have had one case where buggy csr/dmc firmware version influenced
gt side and caused a hang. Add dmc firmware loading state and
version to error state.

v2: - Rebased on top of Damien's patches
- included fw load state
v3: include dmc info only if platform supports it (Chris)
v4: move *csr to branch scope (Chris)

Cc: Chris Wilson 
Signed-off-by: Mika Kuoppala 
Reviewed-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gpu_error.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gpu_error.c 
b/drivers/gpu/drm/i915/i915_gpu_error.c
index 793f2de..aaf4a1f 100644
--- a/drivers/gpu/drm/i915/i915_gpu_error.c
+++ b/drivers/gpu/drm/i915/i915_gpu_error.c
@@ -366,6 +366,16 @@ int i915_error_state_to_str(struct 
drm_i915_error_state_buf *m,
err_printf(m, "Suspend count: %u\n", error->suspend_count);
err_printf(m, "PCI ID: 0x%04x\n", dev->pdev->device);
err_printf(m, "IOMMU enabled?: %d\n", error->iommu);
+
+   if (HAS_CSR(dev)) {
+   struct intel_csr *csr = &dev_priv->csr;
+
+   err_printf(m, "DMC load state: %d\n", csr->state);
+   err_printf(m, "DMC fw version: %d.%d\n",
+  CSR_VERSION_MAJOR(csr->version),
+  CSR_VERSION_MINOR(csr->version));
+   }
+
err_printf(m, "EIR: 0x%08x\n", error->eir);
err_printf(m, "IER: 0x%08x\n", error->ier);
if (INTEL_INFO(dev)->gen >= 8) {
-- 
2.5.0

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

[Intel-gfx] [PATCH 4/7] drm/i915/skl: Expose DC5/DC6 entry counts

From: Damien Lespiau 

The CSR firmware expose two counters, handy to check if we are indeed
entering DC5/DC6.

v2: Rebase

Signed-off-by: Damien Lespiau 
Reviewed-by: Rodrigo Vivi  (v1)
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 7 +++
 drivers/gpu/drm/i915/i915_reg.h | 4 
 2 files changed, 11 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 2f53cb1..d8e9bc8 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2806,6 +2806,13 @@ static int i915_dmc_info(struct seq_file *m, void 
*unused)
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
   CSR_VERSION_MINOR(csr->version));
 
+   if (IS_SKYLAKE(dev) && csr->version >= CSR_VERSION(1, 6)) {
+   seq_printf(m, "DC3 -> DC5 count: %d\n",
+  I915_READ(SKL_CSR_DC3_DC5_COUNT));
+   seq_printf(m, "DC5 -> DC6 count: %d\n",
+  I915_READ(SKL_CSR_DC5_DC6_COUNT));
+   }
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 8942532..bf9bddd 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5696,6 +5696,10 @@ enum skl_disp_power_wells {
 #define GAMMA_MODE_MODE_12BIT  (2 << 0)
 #define GAMMA_MODE_MODE_SPLIT  (3 << 0)
 
+/* DMC/CSR */
+#define SKL_CSR_DC3_DC5_COUNT  0x80030
+#define SKL_CSR_DC5_DC6_COUNT  0x8002C
+
 /* interrupts */
 #define DE_MASTER_IRQ_CONTROL   (1 << 31)
 #define DE_SPRITEB_FLIP_DONE(1 << 29)
-- 
2.5.0

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

[Intel-gfx] [PATCH 3/7] drm/i915/skl: Print the DMC firmware status in debugfs

From: Damien Lespiau 

Create a new debufs file for it, we'll have a few more things to add
there.

v2: Fix checkpatch warning about static const array
v3: use named initializers (Ville)
v4: strip out csr_state as it will be removed in future (Ville, Imre)

Signed-off-by: Damien Lespiau  (v1)
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 89ba549..2f53cb1 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2783,6 +2783,32 @@ static int i915_power_domain_info(struct seq_file *m, 
void *unused)
return 0;
 }
 
+static int i915_dmc_info(struct seq_file *m, void *unused)
+{
+   struct drm_info_node *node = m->private;
+   struct drm_device *dev = node->minor->dev;
+   struct drm_i915_private *dev_priv = dev->dev_private;
+   struct intel_csr *csr;
+
+   if (!HAS_CSR(dev)) {
+   seq_puts(m, "not supported\n");
+   return 0;
+   }
+
+   csr = &dev_priv->csr;
+
+   seq_printf(m, "fw loaded: %s\n", yesno(csr->dmc_payload != NULL));
+   seq_printf(m, "path: %s\n", csr->fw_path);
+
+   if (!csr->dmc_payload)
+   return 0;
+
+   seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
+  CSR_VERSION_MINOR(csr->version));
+
+   return 0;
+}
+
 static void intel_seq_print_mode(struct seq_file *m, int tabs,
 struct drm_display_mode *mode)
 {
@@ -5242,6 +5268,7 @@ static const struct drm_info_list i915_debugfs_list[] = {
{"i915_energy_uJ", i915_energy_uJ, 0},
{"i915_runtime_pm_status", i915_runtime_pm_status, 0},
{"i915_power_domain_info", i915_power_domain_info, 0},
+   {"i915_dmc_info", i915_dmc_info, 0},
{"i915_display_info", i915_display_info, 0},
{"i915_semaphore_status", i915_semaphore_status, 0},
{"i915_shared_dplls_info", i915_shared_dplls_info, 0},
-- 
2.5.0

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

[Intel-gfx] [PATCH 5/7] drm/i915/bxt: Expose DC5 entry count

For bxt CSR firmware exposes a count of dc5 entries. Expose
it through debugs

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 +++
 drivers/gpu/drm/i915/i915_reg.h | 1 +
 2 files changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index d8e9bc8..7a61599 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2811,6 +2811,9 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
   I915_READ(SKL_CSR_DC3_DC5_COUNT));
seq_printf(m, "DC5 -> DC6 count: %d\n",
   I915_READ(SKL_CSR_DC5_DC6_COUNT));
+   } else if (IS_BROXTON(dev) && csr->version >= CSR_VERSION(1, 4)) {
+   seq_printf(m, "DC3 -> DC5 count: %d\n",
+  I915_READ(BXT_CSR_DC3_DC5_COUNT));
}
 
return 0;
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index bf9bddd..c563ead 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5699,6 +5699,7 @@ enum skl_disp_power_wells {
 /* DMC/CSR */
 #define SKL_CSR_DC3_DC5_COUNT  0x80030
 #define SKL_CSR_DC5_DC6_COUNT  0x8002C
+#define BXT_CSR_DC3_DC5_COUNT  0x80038
 
 /* interrupts */
 #define DE_MASTER_IRQ_CONTROL   (1 << 31)
-- 
2.5.0

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

[Intel-gfx] [PATCH 1/7] drm/i915/skl: Store and print the DMC firmware version we load

From: Damien Lespiau 

That can be handy later on to tell which DMC firmware version the user
has, by just looking at the dmesg.

v2: use DRM_DEBUG_DRIVER (Chris)
v3: use DRM_INFO (Marc Herbert)

Cc: Marc Herbert 
Signed-off-by: Damien Lespiau  (v1)
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h  | 5 +
 drivers/gpu/drm/i915/intel_csr.c | 9 -
 2 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b408ebf..0bee438 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -734,6 +734,10 @@ struct intel_uncore {
 #define for_each_fw_domain(domain__, dev_priv__, i__) \
for_each_fw_domain_mask(domain__, FORCEWAKE_ALL, dev_priv__, i__)
 
+#define CSR_VERSION(major, minor)  ((major) << 16 | (minor))
+#define CSR_VERSION_MAJOR(version) ((version) >> 16)
+#define CSR_VERSION_MINOR(version) ((version) & 0x)
+
 enum csr_state {
FW_UNINITIALIZED = 0,
FW_LOADED,
@@ -744,6 +748,7 @@ struct intel_csr {
const char *fw_path;
uint32_t *dmc_payload;
uint32_t dmc_fw_size;
+   uint32_t version;
uint32_t mmio_count;
uint32_t mmioaddr[8];
uint32_t mmiodata[8];
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 9e530a7..e620e85 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -321,6 +321,9 @@ static void finish_csr_load(const struct firmware *fw, void 
*context)
(css_header->header_len * 4));
goto out;
}
+
+   csr->version = css_header->version;
+
readcount += sizeof(struct intel_css_header);
 
/* Extract Package Header information*/
@@ -402,7 +405,11 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
intel_csr_load_program(dev);
fw_loaded = true;
 
-   DRM_DEBUG_KMS("Finished loading %s\n", dev_priv->csr.fw_path);
+   DRM_INFO("Finished loading %s (v%u.%u)\n",
+dev_priv->csr.fw_path,
+CSR_VERSION_MAJOR(csr->version),
+CSR_VERSION_MINOR(csr->version));
+
 out:
if (fw_loaded)
intel_runtime_pm_put(dev_priv);
-- 
2.5.0

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

[Intel-gfx] [PATCH 6/7] drm/i915: Add csr programming registers to dmc debugfs entry

We check these to determine firmware loading status. Include
them to help to debug causes of firmware loading fails.

v2: Move all CSR specific registers to i915_reg.h (Ville)
v3: Rebase

Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c |  7 ++-
 drivers/gpu/drm/i915/i915_reg.h | 10 ++
 drivers/gpu/drm/i915/intel_csr.c| 13 -
 3 files changed, 16 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 7a61599..44b8c326 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2801,7 +2801,7 @@ static int i915_dmc_info(struct seq_file *m, void *unused)
seq_printf(m, "path: %s\n", csr->fw_path);
 
if (!csr->dmc_payload)
-   return 0;
+   goto out;
 
seq_printf(m, "version: %d.%d\n", CSR_VERSION_MAJOR(csr->version),
   CSR_VERSION_MINOR(csr->version));
@@ -2816,6 +2816,11 @@ static int i915_dmc_info(struct seq_file *m, void 
*unused)
   I915_READ(BXT_CSR_DC3_DC5_COUNT));
}
 
+out:
+   seq_printf(m, "program base: 0x%08x\n", I915_READ(CSR_PROGRAM(0)));
+   seq_printf(m, "ssp base: 0x%08x\n", I915_READ(CSR_SSP_BASE));
+   seq_printf(m, "htp: 0x%08x\n", I915_READ(CSR_HTP_SKL));
+
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index c563ead..72bbed2 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -5697,6 +5697,16 @@ enum skl_disp_power_wells {
 #define GAMMA_MODE_MODE_SPLIT  (3 << 0)
 
 /* DMC/CSR */
+#define CSR_PROGRAM(i) (0x8 + (i) * 4)
+#define CSR_SSP_BASE_ADDR_GEN9 0x2FC0
+#define CSR_HTP_ADDR_SKL   0x00500034
+#define CSR_SSP_BASE   0x8F074
+#define CSR_HTP_SKL0x8F004
+#define CSR_LAST_WRITE 0x8F034
+#define CSR_LAST_WRITE_VALUE   0xc003b400
+/* MMIO address range for CSR program (0x8 - 0x82FFF) */
+#define CSR_MMIO_START_RANGE   0x8
+#define CSR_MMIO_END_RANGE 0x8
 #define SKL_CSR_DC3_DC5_COUNT  0x80030
 #define SKL_CSR_DC5_DC6_COUNT  0x8002C
 #define BXT_CSR_DC3_DC5_COUNT  0x80038
diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index 701c685..bd305da 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -50,21 +50,8 @@ MODULE_FIRMWARE(I915_CSR_BXT);
 #define SKL_REQUIRED_FW_MAJOR  1
 #define SKL_REQUIRED_FW_MINOR  23
 
-/*
-* SKL CSR registers for DC5 and DC6
-*/
-#define CSR_PROGRAM(i) (0x8 + (i) * 4)
-#define CSR_SSP_BASE_ADDR_GEN9 0x2FC0
-#define CSR_HTP_ADDR_SKL   0x00500034
-#define CSR_SSP_BASE   0x8F074
-#define CSR_HTP_SKL0x8F004
-#define CSR_LAST_WRITE 0x8F034
-#define CSR_LAST_WRITE_VALUE   0xc003b400
-/* MMIO address range for CSR program (0x8 - 0x82FFF) */
 #define CSR_MAX_FW_SIZE0x2FFF
 #define CSR_DEFAULT_FW_OFFSET  0x
-#define CSR_MMIO_START_RANGE   0x8
-#define CSR_MMIO_END_RANGE 0x8
 
 struct intel_css_header {
/* 0x09 for DMC */
-- 
2.5.0

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

[Intel-gfx] [PATCH 2/7] drm/i915/skl: Refuse to load outdated dmc firmware

There is known issue on GT interrupt delivery with DC6 and
firmwares <1.21. There is a suspicion that this causes
spurious gpu hangs on driver init and with some workloads,
as upgrading the firmware to 1.21 makes these problems
disappear.

As of now the current version included in distribution
firmware packages is very like to be 1.19. Play it safe and
refuse to load a firmware version that may affect gpu
side stability.

With < 1.23 there is a palette and dmc ram corruption issue
so blacklist anything below that.

v2: Refuse to load fw instead of notifying the user
v3: Rebase on header version changes
v4: Refuse to load anything less than 1.23
v5: Give enough information for user for finding correct fw (Chris)
v6: better url and formatting (Chris)
v7: move error log for each fail path (Mika)
bail out earlier in load path (Imre)

Cc: Animesh Manna 
Cc: Jani Nikula 
Cc: Dave Gordon 
Cc: Arun Siluvery 
Cc: Imre Deak 
Cc: Patrik Jakobsson 
Cc: Rodrigo Vivi 
Cc: Chris Wilson 
References: https://01.org/linuxgraphics/downloads/skldmcver121
References: https://01.org/linuxgraphics/downloads/skylake-dmc-1.23
Testcase: igt/gem_exec_nop
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/intel_csr.c | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_csr.c b/drivers/gpu/drm/i915/intel_csr.c
index e620e85..701c685 100644
--- a/drivers/gpu/drm/i915/intel_csr.c
+++ b/drivers/gpu/drm/i915/intel_csr.c
@@ -47,6 +47,9 @@
 MODULE_FIRMWARE(I915_CSR_SKL);
 MODULE_FIRMWARE(I915_CSR_BXT);
 
+#define SKL_REQUIRED_FW_MAJOR  1
+#define SKL_REQUIRED_FW_MINOR  23
+
 /*
 * SKL CSR registers for DC5 and DC6
 */
@@ -303,10 +306,8 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
uint32_t *dmc_payload;
bool fw_loaded = false;
 
-   if (!fw) {
-   i915_firmware_load_error_print(csr->fw_path, 0);
+   if (!fw)
goto out;
-   }
 
if ((stepping == -ENODATA) || (substepping == -ENODATA)) {
DRM_ERROR("Unknown stepping info, firmware loading failed\n");
@@ -324,6 +325,19 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
 
csr->version = css_header->version;
 
+   if (IS_SKYLAKE(dev) &&
+   (CSR_VERSION_MAJOR(csr->version) < SKL_REQUIRED_FW_MAJOR ||
+CSR_VERSION_MINOR(csr->version) < SKL_REQUIRED_FW_MINOR)) {
+   DRM_INFO("Refusing to load old Skylake DMC firmware v%u.%u,"
+" please upgrade to v%u.%u or later"
+" 
[https://01.org/linuxgraphics/intel-linux-graphics-firmwares].\n";,
+CSR_VERSION_MAJOR(csr->version),
+CSR_VERSION_MINOR(csr->version),
+SKL_REQUIRED_FW_MAJOR,
+SKL_REQUIRED_FW_MINOR);
+   goto out;
+   }
+
readcount += sizeof(struct intel_css_header);
 
/* Extract Package Header information*/
@@ -405,17 +419,20 @@ static void finish_csr_load(const struct firmware *fw, 
void *context)
intel_csr_load_program(dev);
fw_loaded = true;
 
-   DRM_INFO("Finished loading %s (v%u.%u)\n",
-dev_priv->csr.fw_path,
-CSR_VERSION_MAJOR(csr->version),
-CSR_VERSION_MINOR(csr->version));
-
 out:
-   if (fw_loaded)
+   if (fw_loaded) {
intel_runtime_pm_put(dev_priv);
-   else
+
+   DRM_INFO("Finished loading %s (v%u.%u)\n",
+dev_priv->csr.fw_path,
+CSR_VERSION_MAJOR(csr->version),
+CSR_VERSION_MINOR(csr->version));
+   } else {
intel_csr_load_status_set(dev_priv, FW_FAILED);
 
+   i915_firmware_load_error_print(csr->fw_path, 0);
+   }
+
release_firmware(fw);
 }
 
-- 
2.5.0

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

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add soft-pinning API for execbuffer

2015-10-27 Thread akash goel

On Tue, Oct 6, 2015 at 4:23 PM, Chris Wilson  wrote:
> Userspace can pass in an offset that it presumes the object is located
> at. The kernel will then do its utmost to fit the object into that
> location. The assumption is that userspace is handling its own object
> locations (for example along with full-ppgtt) and that the kernel will
> rarely have to make space for the user's requests.
>
> v2: Fix i915_gem_evict_range() (now evict_for_vma) to handle ordinary
> and fixed objects within the same batch
>
> Signed-off-by: Chris Wilson 
> Cc: "Daniel, Thomas" 
> ---
>  drivers/gpu/drm/i915/i915_dma.c|  3 ++
>  drivers/gpu/drm/i915/i915_drv.h| 10 +++--
>  drivers/gpu/drm/i915/i915_gem.c| 68 
> +-
>  drivers/gpu/drm/i915/i915_gem_evict.c  | 61 +++
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |  9 +++-
>  drivers/gpu/drm/i915/i915_trace.h  | 23 ++
>  include/uapi/drm/i915_drm.h|  4 +-
>  7 files changed, 151 insertions(+), 27 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_dma.c b/drivers/gpu/drm/i915/i915_dma.c
> index ab37d1121be8..cd79ef114b8e 100644
> --- a/drivers/gpu/drm/i915/i915_dma.c
> +++ b/drivers/gpu/drm/i915/i915_dma.c
> @@ -170,6 +170,9 @@ static int i915_getparam(struct drm_device *dev, void 
> *data,
> case I915_PARAM_HAS_RESOURCE_STREAMER:
> value = HAS_RESOURCE_STREAMER(dev);
> break;
> +   case I915_PARAM_HAS_EXEC_SOFTPIN:
> +   value = 1;
> +   break;
> default:
> DRM_DEBUG("Unknown parameter %d\n", param->param);
> return -EINVAL;
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index a0ce011a5dc0..7d351d991022 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -2778,10 +2778,11 @@ void i915_gem_vma_destroy(struct i915_vma *vma);
>  #define PIN_NONBLOCK   (1<<1)
>  #define PIN_GLOBAL (1<<2)
>  #define PIN_OFFSET_BIAS(1<<3)
> -#define PIN_USER   (1<<4)
> -#define PIN_UPDATE (1<<5)
> -#define PIN_ZONE_4G(1<<6)
> -#define PIN_HIGH   (1<<7)
> +#define PIN_OFFSET_FIXED (1<<4)
> +#define PIN_USER   (1<<5)
> +#define PIN_UPDATE (1<<6)
> +#define PIN_ZONE_4G(1<<7)
> +#define PIN_HIGH   (1<<8)
>  #define PIN_OFFSET_MASK (~4095)
>  int __must_check
>  i915_gem_object_pin(struct drm_i915_gem_object *obj,
> @@ -3127,6 +3128,7 @@ int __must_check i915_gem_evict_something(struct 
> drm_device *dev,
>   unsigned long start,
>   unsigned long end,
>   unsigned flags);
> +int __must_check i915_gem_evict_for_vma(struct i915_vma *vma, unsigned 
> flags);
>  int i915_gem_evict_vm(struct i915_address_space *vm, bool do_idle);
>
>  /* belongs in i915_gem_gtt.h */
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 8fe3df0cdcb8..82efd6a6dee0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -3334,7 +3334,6 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
> *obj,
> struct drm_device *dev = obj->base.dev;
> struct drm_i915_private *dev_priv = dev->dev_private;
> u64 start, end;
> -   u32 search_flag, alloc_flag;
> struct i915_vma *vma;
> int ret;
>
> @@ -3409,30 +3408,53 @@ i915_gem_object_bind_to_vm(struct drm_i915_gem_object 
> *obj,
> if (IS_ERR(vma))
> goto err_unpin;
>
> -   if (flags & PIN_HIGH) {
> -   search_flag = DRM_MM_SEARCH_BELOW;
> -   alloc_flag = DRM_MM_CREATE_TOP;
> +   if (flags & PIN_OFFSET_FIXED) {
> +   uint64_t offset = flags & PIN_OFFSET_MASK;
> +   if (offset & (alignment - 1) || offset + size > end) {
> +   vma = ERR_PTR(-EINVAL);
> +   goto err_free_vma;
> +   }
> +   vma->node.start = offset;
> +   vma->node.size = size;
> +   vma->node.color = obj->cache_level;
> +   ret = drm_mm_reserve_node(&vm->mm, &vma->node);
> +   if (ret) {
> +   ret = i915_gem_evict_for_vma(vma, flags);
> +   if (ret == 0)
> +   ret = drm_mm_reserve_node(&vm->mm, 
> &vma->node);
> +   }
> +   if (ret) {
> +   vma = ERR_PTR(ret);
> +   goto err_free_vma;
> +   }
> } else {
> -   search_flag = DRM_MM_SEARCH_DEFAULT;
> -   alloc_flag = DRM_MM_CREATE_DEFAULT;
> -   }
> +   u32 search_flag, alloc_flag;
> +
> +   if (flags & PIN_HIGH) {
> +   search_flag = DRM_MM_SEARCH_BELOW;
> +   alloc_f

Re: [Intel-gfx] [PATCH 0/7] drm/i915: read out slice/subslice masks

2015-10-27 Thread Robert Bragg

This series looks good to me.

Just to let people know; I have some related changes on my
wip/rib/oa-next branch where I'm defining the subslice mask
differently to this (to reflect the slice mask too)...

In my case for exposing OA unit counters we have a number of metric
sets which have multiple associated MUX configurations and the
appropriate config sometimes depends on which specific subslices are
enabled.

The way this is managed a.t.m is that the XML files maintained by VPG,
that describe the configs, have an RPN 'Availability' expression
associated with each MUX config which is parsed to auto generate
corresponding if() statements to test when trying to select a
particular metric set requested by userspace. These expressions can
refer to a $SubsliceMask variable and in this case the mask is
expected to reflect the slice and subslice mask in one mask, e.g. a
3bit mask per slice packed together on BDW.

Given this, the simplest way for me to work with these availability
checks has been to make the subslice_mask follow the same definition,
something like:

> ss_mask = ss_disable ^ ((1 << ss_max) - 1);
> for (s = 0; s < s_max; s++) {
> if (s_enable & (0x1 << s))
> info->subslice_mask |= ss_mask << (ss_max * s);
> }

Ref: 
https://github.com/rib/linux/blob/wip/rib/oa-next/drivers/gpu/drm/i915/i915_dma.c#L622

(sorry the patches on my  wip/rib/oa-next branch related to this
aren't currently well contained)

For reference my wip/rib/oa-next branch is also exposing the subslice
mask to userspace via GETPARM, as described above, mainly because the
same kinds of RPN expressions are also tested in userspace to
determine how to interpret some metric sets.

Not that the above should affect landing this series; it just seems
relevant to mention.

Reviewed-by: Robert Bragg 

Regards,
- Robert

On Wed, Oct 21, 2015 at 4:40 PM, Imre Deak  wrote:
> The per-slice/subslice INSTDONE patchset from Ben [1] will need the
> subslice/slice masks in addition to the corresponding counts that we
> maintain atm. So I added support to store the masks instead of the
> counts and calculate the counts whenever we need them based on the
> masks. While at it I also noticed that the SSEU readout code could be
> simplified by reusing the data structure storing the SSEU properties.
>
> Tested on BXT/SKL.
>
> [1]
> http://lists.freedesktop.org/archives/intel-gfx/2015-September/077050.html
>
> Imre Deak (7):
>   drm/i915: sseu: move sseu_dev_status to i915_drv.h
>   drm/i915: sseu: use sseu_dev_info in device info
>   drm/i915: sseu: simplify debugfs status/info printing
>   drm/i915: sseu: convert slice count field to mask
>   drm/i915: sseu: convert subslice count fields to subslice mask
>   drm/i915: sseu: add debug printf for slice/subslice masks
>   drm/i915/bdw: sseu: fix sseu status parsing
>
>  drivers/gpu/drm/i915/i915_debugfs.c | 134 
> +++-
>  drivers/gpu/drm/i915/i915_dma.c | 115 +--
>  drivers/gpu/drm/i915/i915_drv.h |  28 ---
>  drivers/gpu/drm/i915/intel_lrc.c|  14 ++--
>  drivers/gpu/drm/i915/intel_pm.c |   2 +-
>  drivers/gpu/drm/i915/intel_ringbuffer.c |   4 +-
>  6 files changed, 150 insertions(+), 147 deletions(-)
>
> --
> 2.1.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] i915 render node discovery buggy?

2015-10-27 Thread Martin Peres


On 27/10/15 12:24, Russell King - ARM Linux wrote:

In passing, while reading the Intel DDX driver code, I've noticed
that the Intel driver contains code which assumes that the master and
render devices are related by minor device number, eg:

 /* Are we a render-node ourselves? */
 if (is_render_node(fd, &master))
 return NULL;

 sprintf(buf, "/dev/dri/renderD%d", (int)((master.st_rdev | 0x80) & 
0xbf));
 if (stat(buf, &render) == 0 &&
 master.st_mode == render.st_mode &&
 render.st_rdev == ((master.st_rdev | 0x80) & 0xbf))
 return strdup(buf);

There's also code doing the reverse as well.

 From my observations, the assumption that this code is built upon is
false.  I have an ARM platform here (non-Intel graphics) which shows
the problem - we have a KMS-only DRM driver (card0) and a GPU-only
DRM driver (card1).  This populates the /dev/dri subdirectory as
follows:

crw-rw+ 1 root video 226,   0 Oct 27 04:59 card0
crw-rw+ 1 root video 226,   1 Oct 26 20:40 card1
crw-rw  1 root video 226,  64 Oct 26 20:40 controlD64
crw-rw  1 root video 226, 128 Oct 26 20:40 renderD128

and if I look at /sys/class/drm, you can then see who owns which devices:

lrwxrwxrwx 1 root root0 Oct 26 20:40 card0 -> 
../../devices/platform/armada-drm/drm/card0
lrwxrwxrwx 1 root root0 Oct 26 20:40 card0-HDMI-A-1 -> 
../../devices/platform/armada-drm/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root0 Oct 26 20:40 card1 -> 
../../devices/platform/etnaviv/drm/card1
lrwxrwxrwx 1 root root0 Oct 26 20:40 controlD64 -> 
../../devices/platform/armada-drm/drm/controlD64
lrwxrwxrwx 1 root root0 Oct 26 20:40 renderD128 -> 
../../devices/platform/etnaviv/drm/renderD128

So, renderD128 is card1's render node, which does not conform to the
assumption which the Intel DDX driver makes - (1 | 0x80) & 0xbf is
not 128.  The same thing can happen if there's ever a case on Intel
hardware where a KMS DRM driver registers prior to the i915 driver.

I think the only way to properly determine which render nodes
correspond with which master node is to actually open the device and
check the device names, or parse sysfs - maybe reading the links of
/sys/class/drm, and checking which link dirname corresponds with the
master node.

Any comments?


libdrm already has the right function for that:|char 
*drmGetRenderDeviceNameFromFd(int fd);



|

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

Re: [Intel-gfx] [PATCH] igt/kms_rotation_crc: Add a subtest to validate Y-tiled obj + Y fb modifier (v3)



On 23/10/15 12:35, Daniel Vetter wrote:

On Fri, Oct 23, 2015 at 09:51:06AM +0100, Tvrtko Ursulin wrote:


Hi,

On 23/10/15 02:34, Vivek Kasireddy wrote:

The main goal of this subtest is to trigger the following warning in
the function i915_gem_object_get_fence():
if (WARN_ON(!obj->map_and_fenceable))

To trigger this warning, the subtest first creates a Y-tiled object and
an associated framebuffer with the Y-fb modifier. Furthermore, to
prevent the map_and_fenceable from being set, we make sure that
the object does not have a normal VMA by refraining from rendering to the
object and by setting the rotation property upfront before calling commit.

v2: Do not call paint_squares and just use one output.

v3: Convert an if condition to igt_require and move the plane rotation
requirement further up before the fb allocation.

Cc: Tvrtko Ursulin 
Signed-off-by: Vivek Kasireddy 
---
  tests/kms_rotation_crc.c | 68 
  1 file changed, 68 insertions(+)

diff --git a/tests/kms_rotation_crc.c b/tests/kms_rotation_crc.c
index cc9847e..b25a949 100644
--- a/tests/kms_rotation_crc.c
+++ b/tests/kms_rotation_crc.c
@@ -264,6 +264,68 @@ static void test_plane_rotation(data_t *data, enum 
igt_plane plane_type)
igt_require_f(valid_tests, "no valid crtc/connector combinations 
found\n");
  }

+static void test_plane_rotation_ytiled_obj(data_t *data, enum igt_plane 
plane_type)
+{
+   igt_display_t *display = &data->display;
+   uint64_t tiling = LOCAL_I915_FORMAT_MOD_Y_TILED;
+   uint32_t format = DRM_FORMAT_XRGB;
+   int bpp = igt_drm_format_to_bpp(format);
+   enum igt_commit_style commit = COMMIT_LEGACY;
+   int fd = data->gfx_fd;
+   igt_output_t *output = &display->outputs[0];
+   igt_plane_t *plane;
+   drmModeModeInfo *mode;
+   unsigned int stride, size, w, h;
+   uint32_t gem_handle;
+   int ret;
+
+   igt_require(output != NULL && output->valid == true);
+
+   plane = igt_output_get_plane(output, plane_type);
+   igt_require(igt_plane_supports_rotation(plane));
+
+   if (plane_type == IGT_PLANE_PRIMARY || plane_type == IGT_PLANE_CURSOR) {
+   igt_require(data->display.has_universal_planes);
+   commit = COMMIT_UNIVERSAL;
+   }
+
+   mode = igt_output_get_mode(output);
+   w = mode->hdisplay;
+   h = mode->vdisplay;
+
+   for (stride = 512; stride < (w * bpp / 8); stride *= 2)
+   ;
+   for (size = 1024*1024; size < stride * h; size *= 2)
+   ;
+
+   gem_handle = gem_create(fd, size);
+   ret = __gem_set_tiling(fd, gem_handle, I915_TILING_Y, stride);
+   igt_assert(ret == 0);
+
+   do_or_die(__kms_addfb(fd, gem_handle, w, h, stride,
+ format, tiling, LOCAL_DRM_MODE_FB_MODIFIERS,
+ &data->fb.fb_id));
+   data->fb.width = w;
+   data->fb.height = h;
+   data->fb.gem_handle = gem_handle;
+
+   igt_plane_set_fb(plane, NULL);
+   igt_display_commit(display);
+
+   igt_plane_set_rotation(plane, data->rotation);
+   igt_plane_set_fb(plane, &data->fb);
+
+   drmModeObjectSetProperty(fd, plane->drm_plane->plane_id,
+DRM_MODE_OBJECT_PLANE,
+plane->rotation_property,
+plane->rotation);
+   ret = igt_display_try_commit2(display, commit);
+
+   kmstest_restore_vt_mode();
+   igt_remove_fb(fd, &data->fb);
+   igt_assert(ret == 0);
+}
+
  igt_main
  {
data_t data = {};
@@ -345,6 +407,12 @@ igt_main
test_plane_rotation(&data, IGT_PLANE_PRIMARY);
}

+   igt_subtest_f("primary-rotation-90-Y-tiled") {
+   igt_require(gen >= 9);
+   data.rotation = IGT_ROTATION_90;
+   test_plane_rotation_ytiled_obj(&data, IGT_PLANE_PRIMARY);
+   }
+
igt_fixture {
igt_display_fini(&data.display);
}



Reviewed-by: Tvrtko Ursulin 


Applied, thanks.


Hasn't hit the repo yet.

Regards,

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

Re: [Intel-gfx] [PATCH] drm/i915: Skip fence installation for objects with rotated views (v2)



On 27/10/15 01:23, Vivek Kasireddy wrote:

While pinning a fb object to the display plane, only install a fence
if the object is using a normal view. This corresponds with the
behavior found in i915_gem_object_do_pin() where the fencability
criteria is determined only for objects with normal views.

v2:
Look at the object's map_and_fenceable flag to determine whether to
install a fence or not (Chris).

Cc: Chris Wilson 
Cc: Tvrtko Ursulin 
Cc: Daniel Vetter 
Signed-off-by: Vivek Kasireddy 
---
  drivers/gpu/drm/i915/intel_display.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 52fb3f2..108c000 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2357,7 +2357,8 @@ intel_pin_and_fence_fb_obj(struct drm_plane *plane,
 * framebuffer compression.  For simplicity, we always install
 * a fence as the cost is not that onerous.
 */
-   ret = i915_gem_object_get_fence(obj);
+   if (obj->map_and_fenceable)
+   ret = i915_gem_object_get_fence(obj);
if (ret == -EDEADLK) {
/*
 * -EDEADLK means there are no free fences



Reviewed-by: Tvrtko Ursulin 

Regards,

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

[Intel-gfx] i915 render node discovery buggy?

2015-10-27 Thread Russell King - ARM Linux

In passing, while reading the Intel DDX driver code, I've noticed
that the Intel driver contains code which assumes that the master and
render devices are related by minor device number, eg:

/* Are we a render-node ourselves? */
if (is_render_node(fd, &master))
return NULL;

sprintf(buf, "/dev/dri/renderD%d", (int)((master.st_rdev | 0x80) & 
0xbf));
if (stat(buf, &render) == 0 &&
master.st_mode == render.st_mode &&
render.st_rdev == ((master.st_rdev | 0x80) & 0xbf))
return strdup(buf);

There's also code doing the reverse as well.

From my observations, the assumption that this code is built upon is
false.  I have an ARM platform here (non-Intel graphics) which shows
the problem - we have a KMS-only DRM driver (card0) and a GPU-only
DRM driver (card1).  This populates the /dev/dri subdirectory as
follows:

crw-rw+ 1 root video 226,   0 Oct 27 04:59 card0
crw-rw+ 1 root video 226,   1 Oct 26 20:40 card1
crw-rw  1 root video 226,  64 Oct 26 20:40 controlD64
crw-rw  1 root video 226, 128 Oct 26 20:40 renderD128

and if I look at /sys/class/drm, you can then see who owns which devices:

lrwxrwxrwx 1 root root0 Oct 26 20:40 card0 -> 
../../devices/platform/armada-drm/drm/card0
lrwxrwxrwx 1 root root0 Oct 26 20:40 card0-HDMI-A-1 -> 
../../devices/platform/armada-drm/drm/card0/card0-HDMI-A-1
lrwxrwxrwx 1 root root0 Oct 26 20:40 card1 -> 
../../devices/platform/etnaviv/drm/card1
lrwxrwxrwx 1 root root0 Oct 26 20:40 controlD64 -> 
../../devices/platform/armada-drm/drm/controlD64
lrwxrwxrwx 1 root root0 Oct 26 20:40 renderD128 -> 
../../devices/platform/etnaviv/drm/renderD128

So, renderD128 is card1's render node, which does not conform to the
assumption which the Intel DDX driver makes - (1 | 0x80) & 0xbf is
not 128.  The same thing can happen if there's ever a case on Intel
hardware where a KMS DRM driver registers prior to the i915 driver.

I think the only way to properly determine which render nodes
correspond with which master node is to actually open the device and
check the device names, or parse sysfs - maybe reading the links of
/sys/class/drm, and checking which link dirname corresponds with the
master node.

Any comments?

-- 
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add extra plane information in debugfs.

2015-10-27 Thread Fekete, Robert

On Friday, October 23, 2015 4:27 PM, Chris Wilson wrote:
> On Fri, Oct 23, 2015 at 04:24:25PM +0200, Robert Fekete wrote:
> > +static const char *plane_rotation(unsigned int rotation) {
> > +   switch (rotation) {
> > +   case DRM_ROTATE_0:
> > +   return "0";
> > +   case DRM_ROTATE_90:
> > +   return "90";
> > +   case DRM_ROTATE_180:
> > +   return "180";
> > +   case DRM_ROTATE_270:
> > +   return "270";
> > +   case DRM_REFLECT_X:
> > +   return "FLIP X";
> > +   case DRM_REFLECT_Y:
> > +   return "FLIP Y";
> > +   default:
> > +   MISSING_CASE(rotation);
> > +   return "unknown";
> > +   }
> 
> Note you can have DRM_ROTATE_foo | DRM_REFLECT_bar.
> -Chris

Yepp, I'll rewrite this one. Thanks.

> --
> Chris Wilson, Intel Open Source Technology Centre
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Intel Sweden AB
Registered Office: Isafjordsgatan 30B, 164 40 Kista, Stockholm, Sweden
Registration Number: 556189-6027

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915/bxt: Update Uninit sequence for DDI PHYs

2015-10-27 Thread Sonika Jindal

Un-initialize DDI PHYs as per the bspec update

Cc: Sivakumar Thulasimani 
Signed-off-by: Sonika Jindal 
---
 drivers/gpu/drm/i915/intel_ddi.c |7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_ddi.c b/drivers/gpu/drm/i915/intel_ddi.c
index a65bf81..ba8327f 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -2723,6 +2723,10 @@ static void broxton_phy_uninit(struct drm_i915_private 
*dev_priv,
val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
val &= ~COMMON_RESET_DIS;
I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
+
+   val = I915_READ(BXT_P_CR_GT_DISP_PWRON);
+   val &= ~GT_DISPLAY_POWER_ON(phy);
+   I915_WRITE(BXT_P_CR_GT_DISP_PWRON, val);
 }
 
 void broxton_ddi_phy_uninit(struct drm_device *dev)
@@ -2731,9 +2735,6 @@ void broxton_ddi_phy_uninit(struct drm_device *dev)
 
broxton_phy_uninit(dev_priv, DPIO_PHY1);
broxton_phy_uninit(dev_priv, DPIO_PHY0);
-
-   /* FIXME: do this in broxton_phy_uninit per phy */
-   I915_WRITE(BXT_P_CR_GT_DISP_PWRON, 0);
 }
 
 static const char * const bxt_ddi_pll_names[] = {
-- 
1.7.10.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Add extra plane information in debugfs.

On mån, 2015-10-26 at 17:40 +0200, Ville Syrjälä wrote:
> On Mon, Oct 26, 2015 at 03:56:33PM +0100, Robert Fekete wrote:
> > Hi, thanks for reviewing Maarten.
> > See comments inline...
> > 
> > On mån, 2015-10-26 at 09:23 +0100, Maarten Lankhorst wrote:
> > > Op 23-10-15 om 16:24 schreef Robert Fekete:
> > > > Extends i915_display_info so that for each active crtc also print
> > > > all planes associated with the pipe. This patch shows information
> > > > about each plane wrt format, size, position, rotation, and scaling.
> > > > This is very useful when debugging user space compositors that try
> > > > to utilize several planes for a commit.
> > > >
> > > > Signed-off-by: Robert Fekete 
...

> > > I'm not sure that this is correct, and doing rotation = 180 + REFLECT_X + 
> > > REFLECT_Y is allowed.
> > > 
> > > This would result in a plane with a normal orientation, but that would 
> > > trigger a MISSING_CASE.
> > 
> > Yepp I misunderstood the value of DRM_ROTATE_xxx. It is a bit-position
> > intended to be used with BIT() macro and bitops. I'll rewrite this
> > function into printing the bits set to see if weird values may enter
> > into the rotation value. Above version is indeed wrong. Thanks for
> > noticing.
> > 
> > 
> > Although I may need an explanation in what is a valid rotation value.
> > This is how I get it.
> > 
> > DRM_ROTATE_0:0001 (1 << 0)
> > DRM_ROTATE_90:   0010 (1 << 1)
> > DRM_ROTATE_180:  0100 (1 << 2)
> > DRM_ROTATE_270:  1000 (1 << 3)
> > DRM_REFLECT_X:   0001 (1 << 4)
> > DRM_REFLECT_Y:   0010 (1 << 5)
> > 
> > DRM_REFLECT_MASK 
> > DRM_ROTATE_MASK  
> > 
> > I assume 00010010 to be a valid rotation (ROTATE_90 and a REFLECT_X)
> > OTOH 0110 (ROTATE_90 and ROTATE_180) is wrong right?
> 
> Yes, only one angle can be specified.

OK,

> > But it could
> > also be interpreted as ROTATE_270 if it is an accumulative rotation.
> > Also with this notion you will have two different rotation values for
> > the same actual rotation value. 
> > 
> > Also what confuses me with this setup (IIUC) is that different values
> > will in fact ultimately mean the same thing.
> > 00110001 (FLIP X and Y and ROTATE_0) is rot_180
> > 0100 (ROTATE_180)
> > 
> > 00110100 (FLIP X and Y and ROTATE_180) is rot_0
> > 0001 (ROTATE_0)
> > plus some more examples
> 
> Yes, all those are valid. drm_rotation_simplify() tries to use such
> identities to eliminate unsupported angles/reflections, but currently
> it's only meant as a helper for drivers.

Ok,

> > 
> > Regarding if rotation is CW or CCW? I cant figure that out in drm_crtc.h
> > where it is defined. OTOH in intel_display.c I can see a comment that
> > DRM_ROTATE_ is indeed CCW in order to be compatible with XRandr. I guess
> > that is one way to documentat things, or would perhaps a clockwise bit
> > be useful
> > DRM_ROTATE_CW:   0100 (1 << 6)
> > AND a comment that default is CCW. Or at least a comment in drm_crtc.h
> > like: /* DRM_ROTATE_ is counter clockwise */
> > 
> > Finally for my better understanding
> > If you for example do a REFLECT_X and a ROT_270 the order in which it is
> > applied matters. Which order is default? quite important for user-space
> > to know when manipulating these bits. I can't find any help in libdrm
> > either.
> > so what I mean.
> > (First REFLECT_X then ROTATE_270) != (First ROTATE_270 then REFLECT_X)
> 
> The rotation property documentation has the details, but repeating it
> next to the DRM_ROTATE bits probably wouldn't hurt.

Yepp, saw that under drm-kms-properties now. 

-- 
BR
/Robert Fekete
Intel Open Source Technology Center

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

[Intel-gfx] [PATCH 1/1] drm/i915/gen9: Check BIOS RC6 setup before enabling RC6

2015-10-27 Thread Sagar Arun Kamble

RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6
configuration registers. If those are not setup Driver should not enable RC6.
For implementing this, driver can check RC_CTRL0 and RC_CTRL1 values
to know if BIOS has enabled HW/SW RC6.
This will also enable user to control RC6 using BIOS settings alone.

Change-Id: If89518708e133be6b3c7c6f90869fb66224b7b87
Signed-off-by: Sagar Arun Kamble 
---
 drivers/gpu/drm/i915/intel_pm.c | 9 +
 1 file changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 9dda3ea..8c595e0 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -4836,6 +4836,15 @@ static void gen8_enable_rps(struct drm_device *dev)
struct intel_engine_cs *ring;
uint32_t rc6_mask = 0;
int unused;
+   bool hw_rc6_enabled, sw_rc6_enabled;
+
+   /* Check if BIOS has enabled HW/SW RC6. Only then enable RC6 */
+   hw_rc6_enabled = I915_READ(GEN6_RC_CONTROL) &
+   (GEN6_RC_CTL_RC6_ENABLE | 
GEN6_RC_CTL_HW_ENABLE);
+   sw_rc6_enabled = !(I915_READ(GEN6_RC_CONTROL) & GEN6_RC_CTL_HW_ENABLE)
+   && (I915_READ(GEN6_RC_STATE) & 0x4);
+   if (!(hw_rc6_enabled || sw_rc6_enabled))
+   i915.enable_rc6 = 0;
 
/* 1a: Software RC state - RC0 */
I915_WRITE(GEN6_RC_STATE, 0);
-- 
1.9.1

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

Re: [Intel-gfx] [ANNOUNCE][RFC] KVMGT - the implementation of Intel GVT-g(full GPU virtualization) for KVM

2015-10-27 Thread Jike Song


Hi all,

We are pleased to announce another update of Intel GVT-g for KVM.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through, 
starting from 4th generation Intel Core(TM) processors with Intel Graphics 
processors. A virtual GPU instance is maintained for each VM, with part of 
performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance among performance, feature, 
and sharing capability. KVM is supported by Intel GVT-g(a.k.a. KVMGT).


Repositories

Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch)
Qemu: https://github.com/01org/igvtg-qemu (kvmgt_public2015q3 branch)


This update consists of:

- KVMGT is now merged with XenGT in unified repositories(kernel and qemu), 
but currently
  different branches for qemu.  KVMGT and XenGT share same iGVT-g core 
logic.
- PPGTT supported, hence the Windows guest support
- KVMGT now supports both 4th generation (Haswell) and 5th generation 
(Broadwell) Intel Core(TM) processors
- 2D/3D/Media decoding have been validated on Ubuntu 14.04 and 
Windows7/Windows 8.1

Next update will be around early Jan, 2016.

Known issues:

- At least 2GB memory is suggested for VM to run most 3D workloads.
- 3Dmark06 running in Windows VM may have some stability issue.
- Using VLC to play .ogg file may cause mosaic or slow response.


Please subscribe the mailing list to report BUGs, discuss, and/or contribute:

https://lists.01.org/mailman/listinfo/igvt-g

More information about Intel GVT-g background, architecture, etc can be found 
at(may not be up-to-date):

https://01.org/igvt-g
http://www.linux-kvm.org/images/f/f3/01x08b-KVMGT-a.pdf
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian


Note:

The KVMGT project should be considered a work in progress. As such it is not a 
complete product nor should it be considered one. Extra care should be taken 
when testing and configuring a system to use the KVMGT project.


--
Thanks,
Jike

On 12/04/2014 10:24 AM, Jike Song wrote:

Hi all,

   We are pleased to announce the first release of KVMGT project. KVMGT is the 
implementation of Intel GVT-g technology, a full GPU virtualization solution. 
Under Intel GVT-g, a virtual GPU instance is maintained for each VM, with part 
of performance critical resources directly assigned. The capability of running 
native graphics driver inside a VM, without hypervisor intervention in 
performance critical paths, achieves a good balance of performance, feature, 
and sharing capability.


   KVMGT is still in the early stage:

- Basic functions of full GPU virtualization works, guest can see a 
full-featured vGPU.
  We ran several 3D workloads such as lightsmark, nexuiz, urbanterror and 
warsow.

- Only Linux guest supported so far, and PPGTT must be disabled in guest 
through a
  kernel parameter(see README.kvmgt in QEMU).

- This drop also includes some Xen specific changes, which will be cleaned 
up later.

- Our end goal is to upstream both XenGT and KVMGT, which shares ~90% logic 
for vGPU
  device model (will be part of i915 driver), with only difference in 
hypervisor
  specific services

- insufficient test coverage, so please bear with stability issues :)



   There are things need to be improved, esp. the KVM interfacing part:

1   a domid was added to each KVMGT guest

An ID is needed for foreground OS switching, e.g.

# echo >
/sys/kernel/vgt/control/foreground_vm

domid 0 is reserved for host OS.


2   SRCU workarounds.

Some KVM functions, such as:

kvm_io_bus_register_dev
install_new_memslots

must be called *without* &kvm->srcu read-locked. Otherwise it 
hangs.

In KVMGT, we need to register an iodev only *after* BAR 
registers are
written by guest. That means, we already have &kvm->srcu hold -
trapping/emulating PIO(BAR registers) makes us in such a 
condition.
That will make kvm_io_bus_register_dev hangs.

Currently we have to disable rcu_assign_pointer() in such 
functions.

These were dirty workarounds, your suggestions are high welcome!


3   syscalls were called to access "/dev/mem" from kernel

An in-kernel memslot was added for aperture, but using syscalls 
like
open and mmap to open and access the character device 
"/dev/mem",
for pass-through.




The source codes(kernel, qemu as well as seabios) are available at github:

git://github.com/01org/KVMGT-kernel
git://github.com/01org/KVMGT-qemu
git://github.com/01org/KVMGT-

Re: [Intel-gfx] Call trace on SKL with 4.3.0-rc3+ kernel

On Tue, 27 Oct 2015, Kai Huang  wrote:
> I got below Call Trace when booting my 4.3.0-rc3+ kernel on my SKL DT 
> machine. Although my machine boots up despite this call trace, I think 
> it's better to report it (and hopefully this is the right mailing list 
> to report).

Please try v4.3-rc7. If that doesn't help, please file a bug at
https://bugs.freedesktop.org/enter_bug.cgi?product=DRI&component=DRM/Intel

BR,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [Announcement] 2015-Q3 release of XenGT - a Mediated Graphics Passthrough Solution from Intel

2015-10-27 Thread Jike Song

Hi all,

We are pleased to announce another update of Intel GVT-g for Xen.

Intel GVT-g is a full GPU virtualization solution with mediated pass-through,
starting from 4th generation Intel Core(TM) processors with Intel Graphics
processors. A virtual GPU instance is maintained for each VM, with part of
performance critical resources directly assigned. The capability of running
native graphics driver inside a VM, without hypervisor intervention in
performance critical paths, achieves a good balance among performance, feature,
and sharing capability. Xen is currently supported on Intel Processor Graphics
(a.k.a. XenGT); and the core logic can be easily ported to other hypervisors.

Repositories

Kernel: https://github.com/01org/igvtg-kernel (2015q3-3.18.0 branch)
Xen: https://github.com/01org/igvtg-xen (2015q3-4.5 branch)
Qemu: https://github.com/01org/igvtg-qemu (xengt_public2015q3 branch)

This update consists of:

- XenGT is now merged with KVMGT in unified repositories(kernel and qemu),
but currently
different branches for qemu. XenGT and KVMGT share same iGVT-g core
logic.
- fix sysfs/debugfs access seldom crash issue
- fix a BUG in XenGT I/O emulation logic
- improve 3d workload stability

Next update will be around early Jan, 2016.

Known issues:

- At least 2GB memory is suggested for VM to run most 3D workloads.
- Keymap might be incorrect in guest. Config file may need to explicitly specify
"keymap='en-us'". Although it looks like the default value, earlier we saw the
problem of wrong keymap code if it is not explicitly set.
- When using three monitors, doing hotplug between Guest pause/unpause may
not be able to lightup all monitors automatically. Some specific monitor issues.
- Cannot move mouse pointer smoothly in guest by default launched by VNC mode. Configuration
file need to explicitly specify "usb=1" to enable a USB bus, and
"usbdevice='tablet'" to add pointer device using absolute coordinates.
- Resume dom0 from S3 may cause some error message.
- i915 unload/reload cannot works well with less than 3 vcpu when upowerd
service was running
- Unigen Tropics running in multiple guests will cause dom0 and guests tdr.

Please subscribe the mailing list to report BUGs, discuss, and/or contribute:

https://lists.01.org/mailman/listinfo/igvt-g

More information about Intel GVT-g background, architecture, etc can be found
at(may not be up-to-date):

https://01.org/igvt-g
https://www.usenix.org/conference/atc14/technical-sessions/presentation/tian

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-v7_0.pdf

http://events.linuxfoundation.org/sites/events/files/slides/XenGT-Xen%20Summit-REWRITE%203RD%20v4.pdf
https://01.org/xen/blogs/srclarkx/2013/graphics-virtualization-xengt

Note:

The XenGT project should be considered a work in progress. As such it is not
a complete product nor should it be considered one. Extra care should be taken
when testing and configuring a system to use the XenGT project.

--
Thanks,
Jike

On 07/07/2015 10:49 AM, Jike Song wrote:

Hi all,

We're pleased to announce a public update to Intel Graphics Virtualization
Technology(Intel GVT-g, formerly known as XenGT).

Tip of repositories
-

Kernel: 5b73653d5ca, Branch: master-2015Q2-3.18.0
Qemu: 2a75bbff62c1, Branch: master
Xen: 38c36f0f511b1, Branch: master-2015Q2-4.5

This update consists of:
- Change time based scheduler timer to be configurable to enhance
stability
- Fix stability issues that VM/Dom0 got tdr when hang up at some specific
instruction on BDW
- Optimize the emulation of el_status register to enhance stability
- 2D/3D performance in linux VMs has been improved about 50% on BDW
- Fix abnormal idle power consumption issue due to wrong forcewake policy
- Fix tdr issue when running 2D/3D/Media workloads in Windows VMs
simultaneously
- KVM support is still in a separate branch as prototype work. We plan to
integrate KVM/Xen support together in the future releases
- Next update will be around early Oct, 2015

Notice that this release can support both Intel 4th ge

Re: [Intel-gfx] [RFC] drm/i915/bxt: Added identifier for MIPI transcoder

2015-10-27 Thread kbuild test robot

Hi Animesh,

[auto build test ERROR on drm-intel/for-linux-next -- if it's inappropriate 
base, please suggest rules for selecting the more suitable base]

url:
https://github.com/0day-ci/linux/commits/Animesh-Manna/drm-i915-bxt-Added-identifier-for-MIPI-transcoder/20151027-160751
config: i386-defconfig (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All error/warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/intel_runtime_pm.c: In function 'lookup_power_well':
   include/linux/bitops.h:6:24: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (1UL << (nr))
   ^
   drivers/gpu/drm/i915/intel_runtime_pm.c:60:32: note: in definition of macro 
'for_each_power_well'
  if ((power_well)->domains & (domain_mask))
   ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:971:28: note: in expansion of macro 
>> 'BIT'
#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
   ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:980:37: note: in expansion of macro 
>> 'POWER_DOMAIN_MASK'
 for_each_power_well(i, power_well, POWER_DOMAIN_MASK, power_domains) {
^
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/pm_runtime.h:12,
from drivers/gpu/drm/i915/intel_runtime_pm.c:29:
   drivers/gpu/drm/i915/intel_runtime_pm.c: At top level:
   include/linux/bitops.h:6:24: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (1UL << (nr))
   ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:971:28: note: in expansion of macro 
>> 'BIT'
#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
   ^
   drivers/gpu/drm/i915/intel_runtime_pm.c:1574:14: note: in expansion of macro 
'POWER_DOMAIN_MASK'
  .domains = POWER_DOMAIN_MASK,
 ^
   include/linux/bitops.h:6:24: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (1UL << (nr))
   ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:971:28: note: in expansion of macro 
>> 'BIT'
#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
   ^
   drivers/gpu/drm/i915/intel_runtime_pm.c:1489:3: note: in expansion of macro 
'POWER_DOMAIN_MASK'
 (POWER_DOMAIN_MASK & ~HSW_ALWAYS_ON_POWER_DOMAINS) | \
  ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:1602:14: note: in expansion of macro 
>> 'HSW_DISPLAY_POWER_DOMAINS'
  .domains = HSW_DISPLAY_POWER_DOMAINS,
 ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:1488:35: error: initializer element 
>> is not constant
#define HSW_DISPLAY_POWER_DOMAINS (\
  ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:1602:14: note: in expansion of macro 
>> 'HSW_DISPLAY_POWER_DOMAINS'
  .domains = HSW_DISPLAY_POWER_DOMAINS,
 ^
   drivers/gpu/drm/i915/intel_runtime_pm.c:1488:35: note: (near initialization 
for 'hsw_power_wells[1].domains')
#define HSW_DISPLAY_POWER_DOMAINS (\
  ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:1602:14: note: in expansion of macro 
>> 'HSW_DISPLAY_POWER_DOMAINS'
  .domains = HSW_DISPLAY_POWER_DOMAINS,
 ^
   In file included from include/linux/kernel.h:10:0,
from include/linux/list.h:8,
from include/linux/kobject.h:20,
from include/linux/device.h:17,
from include/linux/pm_runtime.h:12,
from drivers/gpu/drm/i915/intel_runtime_pm.c:29:
   include/linux/bitops.h:6:24: warning: left shift count >= width of type 
[-Wshift-count-overflow]
#define BIT(nr)   (1UL << (nr))
   ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:971:28: note: in expansion of macro 
>> 'BIT'
#define POWER_DOMAIN_MASK (BIT(POWER_DOMAIN_NUM) - 1)
   ^
   drivers/gpu/drm/i915/intel_runtime_pm.c:1496:3: note: in expansion of macro 
'POWER_DOMAIN_MASK'
 (POWER_DOMAIN_MASK & ~BDW_ALWAYS_ON_POWER_DOMAINS) | \
  ^
>> drivers/gpu/drm/i915/intel_runtime_pm.c:1616:14: note: in expansion of macro 
>> 'BDW_DISPLAY_POWER_DOMAINS'
  .domains = BDW_DISPLAY_POWER_DOMAINS,
 ^

Re: [Intel-gfx] [PATCH 2/2] drm/i915: shut up gen8+ SDE irq dmesg noise