Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

[Dmitry Rogozhkin]

On 5/9/2017 8:51 AM, Tvrtko Ursulin wrote:


On 09/05/2017 16:29, Chris Wilson wrote:

On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote:


On 09/05/2017 15:26, Chris Wilson wrote:

On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

By popular customer demand here is the prototype for cheap engine 
utilization

tracking.


customer and debugfs?


Well I did write in one of the following paragraphs on this topic.
Perhaps I should have put it in procfs. :) Sysfs API looks
restrictive or perhaps I missed a way to get low level (fops) access
to it.

It uses static branches so in the default off case it really 
should be cheap.


Not as cheap (for the off case) as simply sampling RING_HEAD/RING_TAIL


Off case are three no-op instructions in three places in the irq
tasklet. And a little bit of object size growth, if you worry about
that aspect?


It's just how the snowball begins.


We should be able to control it. We also have to consider which one is 
lighter for this particular use case.



which looks to be the same level of detail. I wrapped all this up in a
perf interface once up a time...


How does that work? Via periodic sampling? Accuracy sounds like it
would be proportionate to the sampling frequency, no?


Right, and the sampling frequency is under user control (via perf) with
a default of around 1000, gives a small systematic error when dealing 
with %


I included power, interrupts, rc6, frequency (and the statistics but I
never used those and dropped them once oa landed), as well as
utilisation, just for the convenience of having sane interface :)


Can you resurrect those patches? Don't have to rebase and all but I 
would like to see them at least.
Mind that the idea behind the requested kind of stats is primary usage 
by the customers in the _product_ environment to track GPU occupancy and 
predict based on this stats whether they can execute something else. 
Which means that 1) debugfs and any kind of debug-like infrastructure is 
really a no-option, 2) any kind of restrictions are no-option (like 
disable RC6 states). Also, there is no need to expose low-level detailed 
information like how many EUs and VMEs were in use - this belongs to the 
debug things. As for now i915 driver exposes only single required 
metric: gt_act_freq_mhz.



Regards,

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


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

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

[Tvrtko Ursulin]

On 09/05/2017 16:29, Chris Wilson wrote:

On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote:


On 09/05/2017 15:26, Chris Wilson wrote:

On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

By popular customer demand here is the prototype for cheap engine utilization
tracking.


customer and debugfs?


Well I did write in one of the following paragraphs on this topic.
Perhaps I should have put it in procfs. :) Sysfs API looks
restrictive or perhaps I missed a way to get low level (fops) access
to it.


It uses static branches so in the default off case it really should be cheap.


Not as cheap (for the off case) as simply sampling RING_HEAD/RING_TAIL


Off case are three no-op instructions in three places in the irq
tasklet. And a little bit of object size growth, if you worry about
that aspect?


It's just how the snowball begins.


We should be able to control it. We also have to consider which one is 
lighter for this particular use case.



which looks to be the same level of detail. I wrapped all this up in a
perf interface once up a time...


How does that work? Via periodic sampling? Accuracy sounds like it
would be proportionate to the sampling frequency, no?


Right, and the sampling frequency is under user control (via perf) with
a default of around 1000, gives a small systematic error when dealing with %

I included power, interrupts, rc6, frequency (and the statistics but I
never used those and dropped them once oa landed), as well as
utilisation, just for the convenience of having sane interface :)


Can you resurrect those patches? Don't have to rebase and all but I 
would like to see them at least.


Regards,

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

Re: [Intel-gfx] [RFC 3/3] drm/i915: Export engine busy stats in debugfs

[Dmitry Rogozhkin]

On 5/9/2017 7:09 AM, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

Export the stats added in the previous patch in debugfs.

Number of active clients reading this data is tracked and the
static key is only enabled whilst there are some.

Userspace is intended to keep the file descriptor open, seeking
to the beginning of the file periodically, and re-reading the
stats.

This is because the underlying implementation is costly on every
first open/last close transition, and also, because the stats
exported mostly make sense when they are considered relative to
the previous sample.

File lists nanoseconds each engine was active since the tracking
has started.

Signed-off-by: Tvrtko Ursulin 
---
  drivers/gpu/drm/i915/i915_debugfs.c | 120 
  1 file changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1003511f28cc..db588ef858cb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4752,6 +4752,120 @@ static const struct file_operations 
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
  };
  
+DECLARE_STATIC_KEY_FALSE(i915_engine_stats_key);

+static DEFINE_MUTEX(i915_engine_stats_mutex);
+static int i915_engine_stats_ref;
+
+struct i915_engine_stats_buf {
+   unsigned int len;
+   size_t available;
+   char buf[0];
+};
+
+static int i915_engine_stats_open(struct inode *inode, struct file *file)
+{
+   const unsigned int engine_name_len =
+   sizeof(((struct intel_engine_cs *)0)->name);
+   struct i915_engine_stats_buf *buf;
+   const unsigned int buf_size =
+   (engine_name_len + 2 + 19 + 1) * I915_NUM_ENGINES + 1 +
+   sizeof(*buf);
+   int ret;
+
+   buf = kzalloc(buf_size, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   buf->len = buf_size;
+   file->private_data = buf;
+
+   ret = mutex_lock_interruptible(_engine_stats_mutex);
+   if (ret)
+   return ret;
+
+   if (i915_engine_stats_ref++ == 0) {
+   struct drm_i915_private *dev_priv = file->f_inode->i_private;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, dev_priv, id) {
+   memset(>stats, 0, sizeof(engine->stats));
+   spin_lock_init(>stats.lock);
+   }
+
+   static_branch_enable(_engine_stats_key);
+   }
+
+   mutex_unlock(_engine_stats_mutex);
+
+   return 0;
+}
+
+static int i915_engine_stats_release(struct inode *inode, struct file *file)
+{
+   mutex_lock(_engine_stats_mutex);
+   if (--i915_engine_stats_ref == 0)
+   static_branch_disable(_engine_stats_key);
+   mutex_unlock(_engine_stats_mutex);
+
+   kfree(file->private_data);
+
+   return 0;
+}
+
+static ssize_t i915_engine_stats_read(struct file *file, char __user *ubuf,
+ size_t count, loff_t *pos)
+{
+   struct i915_engine_stats_buf *buf =
+   (struct i915_engine_stats_buf *)file->private_data;
+
+   if (*pos == 0) {
+   struct drm_i915_private *dev_priv = file->f_inode->i_private;
+   char *ptr = >buf[0];
+   int left = buf->len;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   buf->available = 0;
+
+   for_each_engine(engine, dev_priv, id) {
+   u64 total;
+   int len;
+
+   spin_lock_irq(>stats.lock);
+   total = engine->stats.total;
+   /*
+* If the engine is executing something at the moment
+* add it to the total.
+*/
+   if (engine->stats.ref)
+   total += ktime_get_real_ns() -
+engine->stats.start;
+   spin_unlock_irq(>stats.lock);
+
+   len = snprintf(ptr, left, "%s: %llu\n",
+  engine->name, total);

If I caught it right, file format is:
  render ring: 12345
  bsd ring: 12345
  ...
where numbers are busy clocks (ns) from the system boot time. Is that 
right? What if we will want to expose some other statistics information 
later, not only busy clocks? For example, engines i915 queues depths is 
a next interest. Maybe later we will find something else interesting. 
So, do we want to consider this file to contain all kind of statistics 
in the future, and hence it should be of somewhat different format, or 
it will have only busy clocks, and maybe we need other file name then?

+   buf->available += len;
+   left -= len;

[Intel-gfx] ✗ Fi.CI.BAT: failure for Cannonpoint Enabling Patches

[Patchwork]

== Series Details ==

Series: Cannonpoint Enabling Patches
URL   : https://patchwork.freedesktop.org/series/24151/
State : failure

== Summary ==

  CHK include/config/kernel.release
  CHK include/generated/uapi/linux/version.h
  CHK include/generated/utsrelease.h
  CHK include/generated/bounds.h
  CHK include/generated/timeconst.h
  CHK include/generated/asm-offsets.h
  CALLscripts/checksyscalls.sh
  CHK include/generated/compile.h
  CHK kernel/config_data.h
  CC [M]  drivers/gpu/drm/i915/intel_panel.o
drivers/gpu/drm/i915/intel_panel.c: In function ‘cnp_enable_backlight’:
drivers/gpu/drm/i915/intel_panel.c:1096:12: error: unused variable ‘pipe’ 
[-Werror=unused-variable]
  enum pipe pipe = intel_get_pipe_from_connector(connector);
^
cc1: all warnings being treated as errors
scripts/Makefile.build:294: recipe for target 
'drivers/gpu/drm/i915/intel_panel.o' failed
make[4]: *** [drivers/gpu/drm/i915/intel_panel.o] Error 1
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm/i915' failed
make[3]: *** [drivers/gpu/drm/i915] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu/drm' failed
make[2]: *** [drivers/gpu/drm] Error 2
scripts/Makefile.build:553: recipe for target 'drivers/gpu' failed
make[1]: *** [drivers/gpu] Error 2
Makefile:1002: recipe for target 'drivers' failed
make: *** [drivers] Error 2

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

[Intel-gfx] [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations

[Lv Zheng]

Since notification side has been changed to always notify kernel listeners
using _LID returning value. Now listeners needn't invoke acpi_lid_open(),
it should use a spec suggested control method lid device usage model:
register lid notification and use the notified value instead, which is the
only way to ensure the value is correct for "button.lid_init_state=ignore"
mode or other modes with "button.lid_fake_events=N" specified.

This patch fixes i915 driver to drop acpi_lid_open() user. It's not
possible to change nouveau_connector.c user using a simple way now. So this
patch only marks acpi_lid_open() as deprecated to accelerate this process
by indicating this change to the nouveau developers.

Cc: 
Cc: 
Signed-off-by: Lv Zheng 
---
 drivers/acpi/button.c | 7 ++-
 drivers/gpu/drm/i915/intel_lvds.c | 2 +-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/acpi/button.c b/drivers/acpi/button.c
index 7ff3a75..50d7898 100644
--- a/drivers/acpi/button.c
+++ b/drivers/acpi/button.c
@@ -348,7 +348,12 @@ int acpi_lid_notifier_unregister(struct notifier_block *nb)
 }
 EXPORT_SYMBOL(acpi_lid_notifier_unregister);
 
-int acpi_lid_open(void)
+/*
+ * The intentional usage model is to register a lid notifier and use the
+ * notified value instead. Directly evaluating _LID without seeing a
+ * Notify(lid, 0x80) is not reliable.
+ */
+int __deprecated acpi_lid_open(void)
 {
if (!lid_device)
return -ENODEV;
diff --git a/drivers/gpu/drm/i915/intel_lvds.c 
b/drivers/gpu/drm/i915/intel_lvds.c
index 9ca4dc4..8ca9080 100644
--- a/drivers/gpu/drm/i915/intel_lvds.c
+++ b/drivers/gpu/drm/i915/intel_lvds.c
@@ -548,7 +548,7 @@ static int intel_lid_notify(struct notifier_block *nb, 
unsigned long val,
/* Don't force modeset on machines where it causes a GPU lockup */
if (dmi_check_system(intel_no_modeset_on_lid))
goto exit;
-   if (!acpi_lid_open()) {
+   if (!val) {
/* do modeset on next lid open event */
dev_priv->modeset_restore = MODESET_ON_LID_OPEN;
goto exit;
-- 
2.7.4

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

[Intel-gfx] [PATCH 2/6] drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

[Anusha Srivatsa]

From: Dhinakaran Pandiyan 

The first two bytes of PCI ID for CNP_LP PCH are the same as that of
SPT_LP. We should really be looking at the first 9 bits instead of the
first 8 to identify platforms, although this seems to have not caused any
problems on earlier platforms. Introduce a 9 bit extended mask for SPT and
CNP while not touching the code for any of the other platforms.

v2: (Rodrigo) Make platform agnostic and fix commit message.

v3: rebased.

Signed-off-by: Dhinakaran Pandiyan 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 8 +++-
 drivers/gpu/drm/i915/i915_drv.h | 4 
 2 files changed, 11 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 23d6a5b..3698968 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -170,6 +170,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
while ((pch = pci_get_class(PCI_CLASS_BRIDGE_ISA << 8, pch))) {
if (pch->vendor == PCI_VENDOR_ID_INTEL) {
unsigned short id = pch->device & 
INTEL_PCH_DEVICE_ID_MASK;
+   unsigned short id_ext = pch->device &
+   INTEL_PCH_DEVICE_ID_MASK_EXT;
+
dev_priv->pch_id = id;
 
if (id == INTEL_PCH_IBX_DEVICE_ID_TYPE) {
@@ -206,7 +209,7 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found SunrisePoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
-   } else if (id == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
+   } else if (id_ext == INTEL_PCH_SPT_LP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_SPT;
DRM_DEBUG_KMS("Found SunrisePoint LP PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
@@ -219,6 +222,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
} else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
dev_priv->pch_type = PCH_CNP;
DRM_DEBUG_KMS("Found CannonPoint PCH\n");
+   } else if (id_ext == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint LP PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 8104e33..17ecefb 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -2828,6 +2828,7 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define HAS_POOLED_EU(dev_priv)((dev_priv)->info.has_pooled_eu)
 
 #define INTEL_PCH_DEVICE_ID_MASK   0xff00
+#define INTEL_PCH_DEVICE_ID_MASK_EXT   0xff80
 #define INTEL_PCH_IBX_DEVICE_ID_TYPE   0x3b00
 #define INTEL_PCH_CPT_DEVICE_ID_TYPE   0x1c00
 #define INTEL_PCH_PPT_DEVICE_ID_TYPE   0x1e00
@@ -2837,12 +2838,15 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
 #define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
+#define INTEL_PCH_CNP_LP_DEVICE_ID_TYPE0x9D80
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
 #define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
+#define HAS_PCH_CNP_LP(dev_priv) \
+   ((dev_priv)->pch_id == INTEL_PCH_CNP_LP_DEVICE_ID_TYPE)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
-- 
2.7.4

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

[Intel-gfx] [PATCH 0/6] Cannonpoint Enabling Patches

[Anusha Srivatsa]

Rebased Rodrigo's patche series that enabled Cannonpoint 
support.
https://patchwork.freedesktop.org/project/intel-gfx/patches/?submitter=13413==cnl=

v2: rebased. fix compilation issues.

Dhinakaran Pandiyan (1):
  drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH

Rodrigo Vivi (5):
  drm/i915/cnp: Introduce Cannonpoint PCH.
  drm/i915/cnp: Get/set proper Raw clock frequency on CNP.
  drm/i915/cnp: Backlight support for CNP.
  drm/i915/cnp: add CNP gmbus support
  drm/i915/cnp: Panel Power sequence changes for CNP PCH.

 drivers/gpu/drm/i915/i915_drv.c| 10 +++-
 drivers/gpu/drm/i915/i915_drv.h|  7 +++
 drivers/gpu/drm/i915/i915_irq.c|  6 ++-
 drivers/gpu/drm/i915/i915_reg.h|  8 +++-
 drivers/gpu/drm/i915/intel_cdclk.c | 29 +++-
 drivers/gpu/drm/i915/intel_dp.c| 10 ++--
 drivers/gpu/drm/i915/intel_hdmi.c  |  8 ++--
 drivers/gpu/drm/i915/intel_i2c.c   | 20 +++-
 drivers/gpu/drm/i915/intel_panel.c | 94 ++
 9 files changed, 177 insertions(+), 15 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 5/6] drm/i915/cnp: add CNP gmbus support

[Anusha Srivatsa]

From: Rodrigo Vivi 

On CNP PCH based platforms the gmbus is on the south display that
is on PCH. The existing implementation for previous platforms
already covers the need for CNP expect for the pin pair configuration
that follows similar definitions that we had on BXT.

v2: Don't drop "_BXT" as the indicator of the first platform
supporting this pin numbers. Suggested by Daniel.
v3: Add missing else and fix register table since CNP GPIO_CTL
starts on 0xC5014.
v4: Fix pin number and map according to the current available VBT.
Re-add pin 4 for port D. Lost during some rebase.
v5: rebased.

Cc: Daniel Vetter 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_reg.h   |  3 ++-
 drivers/gpu/drm/i915/intel_hdmi.c |  8 +---
 drivers/gpu/drm/i915/intel_i2c.c  | 20 ++--
 3 files changed, 25 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 9310d43..18fc7d3 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -2626,9 +2626,10 @@ enum skl_disp_power_wells {
 #define   GMBUS_PIN_DPB5 /* SDVO, HDMIB */
 #define   GMBUS_PIN_DPD6 /* HDMID */
 #define   GMBUS_PIN_RESERVED   7 /* 7 reserved */
-#define   GMBUS_PIN_1_BXT  1
+#define   GMBUS_PIN_1_BXT  1 /* BXT+ (atom) and CNP+ (big core) */
 #define   GMBUS_PIN_2_BXT  2
 #define   GMBUS_PIN_3_BXT  3
+#define   GMBUS_PIN_4_CNP  4
 #define   GMBUS_NUM_PINS   7 /* including 0 */
 #define GMBUS1 _MMIO(dev_priv->gpio_mmio_base + 0x5104) /* 
command/status */
 #define   GMBUS_SW_CLR_INT (1<<31)
diff --git a/drivers/gpu/drm/i915/intel_hdmi.c 
b/drivers/gpu/drm/i915/intel_hdmi.c
index 58d6903..2789681 100644
--- a/drivers/gpu/drm/i915/intel_hdmi.c
+++ b/drivers/gpu/drm/i915/intel_hdmi.c
@@ -1885,19 +1885,21 @@ static u8 intel_hdmi_ddc_pin(struct drm_i915_private 
*dev_priv,
 
switch (port) {
case PORT_B:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_1_BXT;
else
ddc_pin = GMBUS_PIN_DPB;
break;
case PORT_C:
-   if (IS_GEN9_LP(dev_priv))
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv))
ddc_pin = GMBUS_PIN_2_BXT;
else
ddc_pin = GMBUS_PIN_DPC;
break;
case PORT_D:
-   if (IS_CHERRYVIEW(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   ddc_pin = GMBUS_PIN_4_CNP;
+   else if (IS_CHERRYVIEW(dev_priv))
ddc_pin = GMBUS_PIN_DPD_CHV;
else
ddc_pin = GMBUS_PIN_DPD;
diff --git a/drivers/gpu/drm/i915/intel_i2c.c b/drivers/gpu/drm/i915/intel_i2c.c
index b6401e8..3eb4a91 100644
--- a/drivers/gpu/drm/i915/intel_i2c.c
+++ b/drivers/gpu/drm/i915/intel_i2c.c
@@ -68,11 +68,25 @@ static const struct gmbus_pin gmbus_pins_bxt[] = {
[GMBUS_PIN_3_BXT] = { "misc", GPIOD },
 };
 
+/*
+ * FIXME: Spec maps 3-misc-0xc541c and 4-portd-0xc5420.
+ * However, current available pre-prod VBT maps:
+ * portD to pin 3 using 0xc5420.
+ */
+static const struct gmbus_pin gmbus_pins_cnp[] = {
+   [GMBUS_PIN_1_BXT] = { "dpb", GPIOB },
+   [GMBUS_PIN_2_BXT] = { "dpc", GPIOC },
+   [GMBUS_PIN_3_BXT] = { "misc", GPIOE },
+   [GMBUS_PIN_4_CNP] = { "dpd", GPIOD },
+};
+
 /* pin is expected to be valid */
 static const struct gmbus_pin *get_gmbus_pin(struct drm_i915_private *dev_priv,
 unsigned int pin)
 {
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   return _pins_cnp[pin];
+   else if (IS_GEN9_LP(dev_priv))
return _pins_bxt[pin];
else if (IS_GEN9_BC(dev_priv))
return _pins_skl[pin];
@@ -87,7 +101,9 @@ bool intel_gmbus_is_valid_pin(struct drm_i915_private 
*dev_priv,
 {
unsigned int size;
 
-   if (IS_GEN9_LP(dev_priv))
+   if (HAS_PCH_CNP(dev_priv))
+   size = ARRAY_SIZE(gmbus_pins_cnp);
+   else if (IS_GEN9_LP(dev_priv))
size = ARRAY_SIZE(gmbus_pins_bxt);
else if (IS_GEN9_BC(dev_priv))
size = ARRAY_SIZE(gmbus_pins_skl);
-- 
2.7.4

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

[Intel-gfx] [PATCH 1/6] drm/i915/cnp: Introduce Cannonpoint PCH.

[Anusha Srivatsa]

From: Rodrigo Vivi 

Most of south engine display that is in PCH is still the
same as SPT and KBP, except for this key differences:

- Backlight: Backlight programming changed in CNP PCH.
- Panel Power: Sligh programming changed in CNP PCH.
- GMBUS and GPIO: The pin mapping has changed in CNP PCH.

All of these changes follow more the BXT style.

v2: Update definition to use dev_priv isntead of dev (Tvrtko).

v3: rebased.

Cc: Tvrtko Ursulin 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Anusha Srivatsa 
---
 drivers/gpu/drm/i915/i915_drv.c | 3 +++
 drivers/gpu/drm/i915/i915_drv.h | 3 +++
 drivers/gpu/drm/i915/i915_irq.c | 6 --
 3 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 72fb47a..23d6a5b 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -216,6 +216,9 @@ static void intel_detect_pch(struct drm_i915_private 
*dev_priv)
DRM_DEBUG_KMS("Found KabyPoint PCH\n");
WARN_ON(!IS_SKYLAKE(dev_priv) &&
!IS_KABYLAKE(dev_priv));
+   } else if (id == INTEL_PCH_CNP_DEVICE_ID_TYPE) {
+   dev_priv->pch_type = PCH_CNP;
+   DRM_DEBUG_KMS("Found CannonPoint PCH\n");
} else if ((id == INTEL_PCH_P2X_DEVICE_ID_TYPE) ||
   (id == INTEL_PCH_P3X_DEVICE_ID_TYPE) ||
   ((id == INTEL_PCH_QEMU_DEVICE_ID_TYPE) &&
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 29a6966..8104e33 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1102,6 +1102,7 @@ enum intel_pch {
PCH_LPT,/* Lynxpoint PCH */
PCH_SPT,/* Sunrisepoint PCH */
PCH_KBP,/* Kabypoint PCH */
+   PCH_CNP,/* Cannonpoint PCH */
PCH_NOP,
 };
 
@@ -2835,11 +2836,13 @@ intel_info(const struct drm_i915_private *dev_priv)
 #define INTEL_PCH_SPT_DEVICE_ID_TYPE   0xA100
 #define INTEL_PCH_SPT_LP_DEVICE_ID_TYPE0x9D00
 #define INTEL_PCH_KBP_DEVICE_ID_TYPE   0xA200
+#define INTEL_PCH_CNP_DEVICE_ID_TYPE   0xA300
 #define INTEL_PCH_P2X_DEVICE_ID_TYPE   0x7100
 #define INTEL_PCH_P3X_DEVICE_ID_TYPE   0x7000
 #define INTEL_PCH_QEMU_DEVICE_ID_TYPE  0x2900 /* qemu q35 has 2918 */
 
 #define INTEL_PCH_TYPE(dev_priv) ((dev_priv)->pch_type)
+#define HAS_PCH_CNP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_CNP)
 #define HAS_PCH_KBP(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_KBP)
 #define HAS_PCH_SPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_SPT)
 #define HAS_PCH_LPT(dev_priv) (INTEL_PCH_TYPE(dev_priv) == PCH_LPT)
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index c99f51c..625e965 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -2582,7 +2582,8 @@ gen8_de_irq_handler(struct drm_i915_private *dev_priv, 
u32 master_ctl)
I915_WRITE(SDEIIR, iir);
ret = IRQ_HANDLED;
 
-   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+   HAS_PCH_CNP(dev_priv))
spt_irq_handler(dev_priv, iir);
else
cpt_irq_handler(dev_priv, iir);
@@ -4323,7 +4324,8 @@ void intel_irq_init(struct drm_i915_private *dev_priv)
dev->driver->disable_vblank = gen8_disable_vblank;
if (IS_GEN9_LP(dev_priv))
dev_priv->display.hpd_irq_setup = bxt_hpd_irq_setup;
-   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv))
+   else if (HAS_PCH_SPT(dev_priv) || HAS_PCH_KBP(dev_priv) ||
+HAS_PCH_CNP(dev_priv))
dev_priv->display.hpd_irq_setup = spt_hpd_irq_setup;
else
dev_priv->display.hpd_irq_setup = ilk_hpd_irq_setup;
-- 
2.7.4

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

[Intel-gfx] [PATCH 4/6] drm/i915/cnp: Backlight support for CNP.

[Anusha Srivatsa]

From: Rodrigo Vivi 

Split out BXT and CNP's setup_backlight(),enable_backlight(),
disable_backlight() and hz_to_pwm() into
two separate functions instead of reusing BXT function.

Reuse set_backlight() and get_backlight() since they have
no reference to the utility pin.

v2: Reuse BXT functions with controller 0 instead of
redefining it. (Jani).
Use dev_priv->rawclk_freq instead of getting the value
from SFUSE_STRAP.
v3: Avoid setup backligh controller along with hooks and
fully reuse hooks setup as suggested by Jani.
v4: Clean up commit message.
v5: Implement per PCH instead per platform.

v6: Introduce a new function for CNP.(Jani and Ville)

v7: Squash the all CNP Backlight support patches into a
single patch. (Jani)

v8: Correct indentation, remove unneeded blank lines and
correct mail address (Jani).

v9: rebased.

Reviewed-by: Jani Nikula 
Suggested-by: Jani Nikula 
Suggested-by: Ville Syrjala 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Signed-off-by: Anusha Srivatsa 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_panel.c | 92 ++
 1 file changed, 92 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_panel.c 
b/drivers/gpu/drm/i915/intel_panel.c
index cb50c52..4830ec2 100644
--- a/drivers/gpu/drm/i915/intel_panel.c
+++ b/drivers/gpu/drm/i915/intel_panel.c
@@ -796,6 +796,19 @@ static void bxt_disable_backlight(struct intel_connector 
*connector)
}
 }
 
+static void cnp_disable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 tmp;
+
+   intel_panel_actually_set_backlight(connector, 0);
+
+   tmp = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  tmp & ~BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_disable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
@@ -1076,6 +1089,35 @@ static void bxt_enable_backlight(struct intel_connector 
*connector)
pwm_ctl | BXT_BLC_PWM_ENABLE);
 }
 
+static void cnp_enable_backlight(struct intel_connector *connector)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 pwm_ctl;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   if (pwm_ctl & BXT_BLC_PWM_ENABLE) {
+   DRM_DEBUG_KMS("backlight already enabled\n");
+   pwm_ctl &= ~BXT_BLC_PWM_ENABLE;
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl);
+   }
+
+   I915_WRITE(BXT_BLC_PWM_FREQ(panel->backlight.controller),
+  panel->backlight.max);
+
+   intel_panel_actually_set_backlight(connector, panel->backlight.level);
+
+   pwm_ctl = 0;
+   if (panel->backlight.active_low_pwm)
+   pwm_ctl |= BXT_BLC_PWM_POLARITY;
+
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller), pwm_ctl);
+   POSTING_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+   I915_WRITE(BXT_BLC_PWM_CTL(panel->backlight.controller),
+  pwm_ctl | BXT_BLC_PWM_ENABLE);
+}
+
 static void pwm_enable_backlight(struct intel_connector *connector)
 {
struct intel_panel *panel = >panel;
@@ -1239,6 +1281,18 @@ void intel_backlight_device_unregister(struct 
intel_connector *connector)
 #endif /* CONFIG_BACKLIGHT_CLASS_DEVICE */
 
 /*
+ * CNP: PWM clock frequency is 19.2 MHz or 24 MHz.
+ *  Value is found in SFUSE_STRAP.
+ *  PWM increment = 1
+ */
+static u32 cnp_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+
+   return DIV_ROUND_CLOSEST(KHz(dev_priv->rawclk_freq), pwm_freq_hz);
+}
+
+/*
  * BXT: PWM clock frequency = 19.2 MHz.
  */
 static u32 bxt_hz_to_pwm(struct intel_connector *connector, u32 pwm_freq_hz)
@@ -1633,6 +1687,37 @@ bxt_setup_backlight(struct intel_connector *connector, 
enum pipe unused)
return 0;
 }
 
+static int
+cnp_setup_backlight(struct intel_connector *connector, enum pipe unused)
+{
+   struct drm_i915_private *dev_priv = to_i915(connector->base.dev);
+   struct intel_panel *panel = >panel;
+   u32 pwm_ctl, val;
+
+   panel->backlight.controller = dev_priv->vbt.backlight.controller;
+
+   pwm_ctl = I915_READ(BXT_BLC_PWM_CTL(panel->backlight.controller));
+
+   panel->backlight.active_low_pwm = pwm_ctl & BXT_BLC_PWM_POLARITY;
+   panel->backlight.max =
+   I915_READ(BXT_BLC_PWM_FREQ(panel->backlight.controller));
+
+   if (!panel->backlight.max)
+

[Intel-gfx] [PATCH 3/6] drm/i915/cnp: Get/set proper Raw clock frequency on CNP.

[Anusha Srivatsa]

From: Rodrigo Vivi 

RAWCLK_FREQ register has changed for platforms with CNP+.

[29:26] This field provides the denominator for the fractional
part of the microsecond counter divider.  The numerator
is fixed at 1. Program this field to the denominator of
the fractional portion of reference frequency minus one.
If the fraction is 0, program to 0.
0100b = Fraction .2 MHz = Fraction 1/5.
b = Fraction .0 MHz.

[25:16] This field provides the integer part of the microsecond
counter divider. Program this field to the integer portion
of the reference frequenct minus one.

Also this register tells us that proper raw clock should be read
from SFUSE_STRAP and programmed to this register. Up to this point
on other platforms we are reading instead of programming it so
probably relying on whatever BIOS had configured here.

Now on let's follow the spec and also program this register
fetching the right value from SFUSE_STRAP as Spec tells us to do.

v2: Read from SFUSE_STRAP and Program RAWCLK_FREQ instead of
reading the value relying someone else will program that
for us.
v3: Add missing else. (Jani)
v4: Addressing all Ville's catches:
Use macro for shift bits instead of defining shift.
Remove shift from the cleaning bits with mask that already
has it.
Add missing I915_WRITE to actually write the reg.
Stop using useless DIV_ROUND_* on divider that is exact
dividion and use DIV_ROUND_CLOSEST for the fraction part.
v5: Remove useless Read-Modify-Write on raclk_freq reg. (Ville).
v6: Change is per PCH instead of per platform.
v7: rebased.

Cc: Ville Syrjälä 
Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
Reviewed-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_reg.h|  5 +
 drivers/gpu/drm/i915/intel_cdclk.c | 29 -
 2 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_reg.h b/drivers/gpu/drm/i915/i915_reg.h
index 524fdfd..9310d43 100644
--- a/drivers/gpu/drm/i915/i915_reg.h
+++ b/drivers/gpu/drm/i915/i915_reg.h
@@ -6838,6 +6838,10 @@ enum {
 #define  FDL_TP2_TIMER_SHIFT10
 #define  FDL_TP2_TIMER_MASK (3<<10)
 #define  RAWCLK_FREQ_MASK   0x3ff
+#define  CNP_RAWCLK_DIV_MASK   (0x3ff << 16)
+#define  CNP_RAWCLK_DIV(div)   ((div) << 16)
+#define  CNP_RAWCLK_FRAC_MASK  (0xf << 26)
+#define  CNP_RAWCLK_FRAC(frac) ((frac) << 26)
 
 #define PCH_DPLL_TMR_CFG_MMIO(0xc6208)
 
@@ -8148,6 +8152,7 @@ enum {
 /* SFUSE_STRAP */
 #define SFUSE_STRAP_MMIO(0xc2014)
 #define  SFUSE_STRAP_FUSE_LOCK (1<<13)
+#define  SFUSE_STRAP_RAW_FREQUENCY (1<<8)
 #define  SFUSE_STRAP_DISPLAY_DISABLED  (1<<7)
 #define  SFUSE_STRAP_CRT_DISABLED  (1<<6)
 #define  SFUSE_STRAP_DDIB_DETECTED (1<<2)
diff --git a/drivers/gpu/drm/i915/intel_cdclk.c 
b/drivers/gpu/drm/i915/intel_cdclk.c
index 2979297..634c89f 100644
--- a/drivers/gpu/drm/i915/intel_cdclk.c
+++ b/drivers/gpu/drm/i915/intel_cdclk.c
@@ -1780,6 +1780,30 @@ void intel_update_cdclk(struct drm_i915_private 
*dev_priv)
   DIV_ROUND_UP(dev_priv->cdclk.hw.cdclk, 1000));
 }
 
+static int cnp_rawclk(struct drm_i915_private *dev_priv)
+{
+   u32 rawclk;
+   int divider, fraction;
+
+   if (I915_READ(SFUSE_STRAP) & SFUSE_STRAP_RAW_FREQUENCY) {
+   /* 24 MHz */
+   divider = 24000;
+   fraction = 0;
+   } else {
+   /* 19.2 MHz */
+   divider = 19000;
+   fraction = 200;
+   }
+
+   rawclk = CNP_RAWCLK_DIV((divider / 1000) - 1);
+   if (fraction)
+   rawclk |= CNP_RAWCLK_FRAC(DIV_ROUND_CLOSEST(1000,
+   fraction) - 1);
+
+   I915_WRITE(PCH_RAWCLK_FREQ, rawclk);
+   return divider + fraction;
+}
+
 static int pch_rawclk(struct drm_i915_private *dev_priv)
 {
return (I915_READ(PCH_RAWCLK_FREQ) & RAWCLK_FREQ_MASK) * 1000;
@@ -1827,7 +1851,10 @@ static int g4x_hrawclk(struct drm_i915_private *dev_priv)
  */
 void intel_update_rawclk(struct drm_i915_private *dev_priv)
 {
-   if (HAS_PCH_SPLIT(dev_priv))
+
+   if (HAS_PCH_CNP(dev_priv))
+   dev_priv->rawclk_freq = cnp_rawclk(dev_priv);
+   else if (HAS_PCH_SPLIT(dev_priv))
dev_priv->rawclk_freq = pch_rawclk(dev_priv);
else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
dev_priv->rawclk_freq = vlv_hrawclk(dev_priv);
-- 
2.7.4

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

[Intel-gfx] [PATCH 6/6] drm/i915/cnp: Panel Power sequence changes for CNP PCH.

[Anusha Srivatsa]

From: Rodrigo Vivi 

As for BXT, PP_DIVISOR was removed from CNP PCH and power
cycle delay has been moved to PP_CONTROL.

v2: rebased.

Cc: Jani Nikula 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dp.c | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 08834f7..6563e93 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -798,7 +798,7 @@ static void intel_pps_get_registers(struct drm_i915_private 
*dev_priv,
regs->pp_stat = PP_STATUS(pps_idx);
regs->pp_on = PP_ON_DELAYS(pps_idx);
regs->pp_off = PP_OFF_DELAYS(pps_idx);
-   if (!IS_GEN9_LP(dev_priv))
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv))
regs->pp_div = PP_DIVISOR(pps_idx);
 }
 
@@ -5217,7 +5217,7 @@ intel_pps_readout_hw_state(struct drm_i915_private 
*dev_priv,
 
pp_on = I915_READ(regs.pp_on);
pp_off = I915_READ(regs.pp_off);
-   if (!IS_GEN9_LP(dev_priv)) {
+   if (!IS_GEN9_LP(dev_priv) && !HAS_PCH_CNP(dev_priv)) {
I915_WRITE(regs.pp_ctrl, pp_ctl);
pp_div = I915_READ(regs.pp_div);
}
@@ -5235,7 +5235,7 @@ intel_pps_readout_hw_state(struct drm_i915_private 
*dev_priv,
seq->t10 = (pp_off & PANEL_POWER_DOWN_DELAY_MASK) >>
   PANEL_POWER_DOWN_DELAY_SHIFT;
 
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
u16 tmp = (pp_ctl & BXT_POWER_CYCLE_DELAY_MASK) >>
BXT_POWER_CYCLE_DELAY_SHIFT;
if (tmp > 0)
@@ -5392,7 +5392,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
drm_device *dev,
 (seq->t10 << PANEL_POWER_DOWN_DELAY_SHIFT);
/* Compute the divisor for the pp clock, simply match the Bspec
 * formula. */
-   if (IS_GEN9_LP(dev_priv)) {
+   if (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) {
pp_div = I915_READ(regs.pp_ctrl);
pp_div &= ~BXT_POWER_CYCLE_DELAY_MASK;
pp_div |= (DIV_ROUND_UP((seq->t11_t12 + 1), 1000)
@@ -5426,7 +5426,7 @@ intel_dp_init_panel_power_sequencer_registers(struct 
drm_device *dev,
DRM_DEBUG_KMS("panel power sequencer register settings: PP_ON %#x, 
PP_OFF %#x, PP_DIV %#x\n",
  I915_READ(regs.pp_on),
  I915_READ(regs.pp_off),
- IS_GEN9_LP(dev_priv) ?
+ (IS_GEN9_LP(dev_priv) || HAS_PCH_CNP(dev_priv)) ?
  (I915_READ(regs.pp_ctrl) & BXT_POWER_CYCLE_DELAY_MASK) :
  I915_READ(regs.pp_div));
 }
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Cannonpoint Enabling Patches (rev2)

[Patchwork]

== Series Details ==

Series: Cannonpoint Enabling Patches (rev2)
URL   : https://patchwork.freedesktop.org/series/24151/
State : success

== Summary ==

Series 24151v2 Cannonpoint Enabling Patches
https://patchwork.freedesktop.org/api/1.0/series/24151/revisions/2/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> SKIP   (fi-elk-e7500) fdo#100942
Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test kms_cursor_legacy:
Subgroup basic-busy-flip-before-cursor-legacy:
pass   -> FAIL   (fi-snb-2600) fdo#100215

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:447s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:435s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:577s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:520s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:538s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-elk-e7500 total:278  pass:9dwarn:1   dfail:0   fail:0   skip:73 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:414s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:409s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:427s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:490s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:474s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:576s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:462s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:575s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:495s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:438s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:541s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:423s

417babaa12ad98dad2c39f361612f1afe6894816 drm-tip: 2017y-05m-09d-13h-13m-23s UTC 
integration manifest
554fd4b drm/i915/cnp: Panel Power sequence changes for CNP PCH.
52af94e drm/i915/cnp: add CNP gmbus support
27d4117 drm/i915/cnp: Backlight support for CNP.
caecb8f drm/i915/cnp: Get/set proper Raw clock frequency on CNP.
230ebdc drm/i915/cnp: Add PCI ID for Cannonpoint LP PCH
cd21ac4 drm/i915/cnp: Introduce Cannonpoint PCH.

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/vgem: Convert to a struct drm_device subclass

[Laura Abbott]

On 05/08/2017 06:22 AM, Chris Wilson wrote:

With Laura's introduction of the fake platform device for importing
dmabuf, we add a second static that is logically tied to the vgem_device.
Convert vgem over to using the struct drm_device subclassing, so that
the platform device is stored inside its owner.

Signed-off-by: Chris Wilson 
Cc: Laura Abbott 
Cc: Daniel Vetter 
---
  drivers/gpu/drm/vgem/vgem_drv.c | 63 +++--
  1 file changed, 41 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/vgem/vgem_drv.c b/drivers/gpu/drm/vgem/vgem_drv.c
index c9381d457a03..4b23ba049632 100644
--- a/drivers/gpu/drm/vgem/vgem_drv.c
+++ b/drivers/gpu/drm/vgem/vgem_drv.c
@@ -42,7 +42,10 @@
  #define DRIVER_MAJOR  1
  #define DRIVER_MINOR  0
  
-static struct platform_device *vgem_platform;

+static struct vgem_device {
+   struct drm_device drm;
+   struct platform_device *platform;
+} *vgem_device;
  
  static void vgem_gem_free_object(struct drm_gem_object *obj)

  {
@@ -307,7 +310,9 @@ static struct sg_table *vgem_prime_get_sg_table(struct 
drm_gem_object *obj)
  static struct drm_gem_object* vgem_prime_import(struct drm_device *dev,
struct dma_buf *dma_buf)
  {
-   return drm_gem_prime_import_dev(dev, dma_buf, _platform->dev);
+   struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+   return drm_gem_prime_import_dev(dev, dma_buf, >platform->dev);
  }
  
  static struct drm_gem_object *vgem_prime_import_sg_table(struct drm_device *dev,

@@ -377,8 +382,19 @@ static int vgem_prime_mmap(struct drm_gem_object *obj,
return 0;
  }
  
+static void vgem_release(struct drm_device *dev)

+{
+   struct vgem_device *vgem = container_of(dev, typeof(*vgem), drm);
+
+   platform_device_unregister(vgem->platform);
+   drm_dev_fini(>drm);
+
+   kfree(vgem);
+}
+
  static struct drm_driver vgem_driver = {
.driver_features= DRIVER_GEM | DRIVER_PRIME,
+   .release= vgem_release,
.open   = vgem_open,
.postclose  = vgem_postclose,
.gem_free_object_unlocked   = vgem_gem_free_object,
@@ -408,45 +424,48 @@ static struct drm_driver vgem_driver = {
.minor  = DRIVER_MINOR,
  };
  
-static struct drm_device *vgem_device;

-
  static int __init vgem_init(void)
  {
int ret;
  
-	vgem_device = drm_dev_alloc(_driver, NULL);

-   if (IS_ERR(vgem_device))
-   return PTR_ERR(vgem_device);
+   vgem_device = kzalloc(sizeof(*vgem_device), GFP_KERNEL);
+   if (!vgem_device)
+   return -ENOMEM;
  
-	vgem_platform = platform_device_register_simple("vgem",

-   -1, NULL, 0);
+   ret = drm_dev_init(_device->drm, _driver, NULL);
+   if (ret)
+   goto out_free;
  
-	if (!vgem_platform) {

+   vgem_device->platform =
+   platform_device_register_simple("vgem", -1, NULL, 0);
+   if (!vgem_device->platform) {
ret = -ENODEV;
-   goto out;
+   goto out_fini;
}
  
-	dma_coerce_mask_and_coherent(_platform->dev,

-   DMA_BIT_MASK(64));
+   dma_coerce_mask_and_coherent(_device->platform->dev,
+DMA_BIT_MASK(64));
  
-	ret  = drm_dev_register(vgem_device, 0);

+   /* Final step: expose the device/driver to userspace */
+   ret  = drm_dev_register(_device->drm, 0);
if (ret)
-   goto out_unref;
+   goto out_unregister;
  
  	return 0;
  
-out_unref:

-   platform_device_unregister(vgem_platform);
-out:
-   drm_dev_unref(vgem_device);
+out_unregister:
+   platform_device_unregister(vgem_device->platform);
+out_fini:
+   drm_dev_fini(_device->drm > +out_free:
+   kfree(vgem_device);
return ret;
  }
  
  static void __exit vgem_exit(void)

  {
-   platform_device_unregister(vgem_platform);
-   drm_dev_unregister(vgem_device);
-   drm_dev_unref(vgem_device);
+   drm_dev_unregister(_device->drm);
+   drm_dev_unref(_device->drm);
  }
  
  module_init(vgem_init);




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

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Mark CPU cache as dirty on every transition for CPU writes

[Dongwon Kim]

Chris,

In set_cache_level, we change obj->cache_level then
update obj->cache_coherent but I think this order
has to be reversed because coherency needs to be
determined based on the previous cache_level, not
the new one. 

After chaning code as shown below:

obj->cache_coherent = i915_gem_object_is_coherent(obj);
obj->cache_level = cache level;

, I see all tests are passing..

-DW

On Sat, Apr 29, 2017 at 09:43:52AM +0100, Chris Wilson wrote:
> On Fri, Apr 28, 2017 at 03:55:56PM -0700, Dongwon Kim wrote:
> > Hi Chris,
> > 
> > I tried this but I still see tests are failing. 
> > I wanted to debug it little further to find a specific
> > condition where clflush is missing but didn't have 
> > enough time. I will look into this early next week.
> 
> Did you check this patch separately?
> 
> So we are still missing a transition where we need to flag the cache as
> becoming dirty. And I still believe you have a
> "set-cache-level(snooped); gpu write; set-cache-level(none); gpu access"
> sequence. 
> 
> This patch should be marking as any write to a snooped bo as making the
> cache-dirty. So we should be caching any and all transitions from snoop
> to none, as that cache_dirty flag will not go away until we clflush.
> 
> And the real active ingredient of this patch is to always flush the
> dirty_cache before rendering, not just if the object was in the CPU
> write domain at that time.
> 
> Hmm, one thing to check is that if your userspace is not declaring some
> domain access that is dirtying the cache. Or if you are using mocs that
> override the cache tracking, without adjusting the PTE. If you are doing
> the latter, there isn't much the kernel can do to help.
> -Chris
> 
> -- 
> Chris Wilson, Intel Open Source Technology Centre
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH 1/2] drm/i915: Move uncore definitions into a separate header

[Michal Wajdeczko]

In order to allow use of e.g. forcewake_domains in a other feature headers
included from the top of i915_drv.h, move all uncore related definitions
into their own header.

Signed-off-by: Michal Wajdeczko 
Suggested-by: Joonas Lahtinen 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.h | 157 +---
 drivers/gpu/drm/i915/intel_uncore.c |  12 +++
 drivers/gpu/drm/i915/intel_uncore.h | 175 
 3 files changed, 188 insertions(+), 156 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_uncore.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b20ed16..29a6966 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include "i915_reg.h"
 #include "i915_utils.h"
 
+#include "intel_uncore.h"
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_uc.h"
@@ -676,116 +677,6 @@ struct drm_i915_display_funcs {
void (*load_luts)(struct drm_crtc_state *crtc_state);
 };
 
-enum forcewake_domain_id {
-   FW_DOMAIN_ID_RENDER = 0,
-   FW_DOMAIN_ID_BLITTER,
-   FW_DOMAIN_ID_MEDIA,
-
-   FW_DOMAIN_ID_COUNT
-};
-
-enum forcewake_domains {
-   FORCEWAKE_RENDER = BIT(FW_DOMAIN_ID_RENDER),
-   FORCEWAKE_BLITTER = BIT(FW_DOMAIN_ID_BLITTER),
-   FORCEWAKE_MEDIA = BIT(FW_DOMAIN_ID_MEDIA),
-   FORCEWAKE_ALL = (FORCEWAKE_RENDER |
-FORCEWAKE_BLITTER |
-FORCEWAKE_MEDIA)
-};
-
-#define FW_REG_READ  (1)
-#define FW_REG_WRITE (2)
-
-enum decoupled_power_domain {
-   GEN9_DECOUPLED_PD_BLITTER = 0,
-   GEN9_DECOUPLED_PD_RENDER,
-   GEN9_DECOUPLED_PD_MEDIA,
-   GEN9_DECOUPLED_PD_ALL
-};
-
-enum decoupled_ops {
-   GEN9_DECOUPLED_OP_WRITE = 0,
-   GEN9_DECOUPLED_OP_READ
-};
-
-enum forcewake_domains
-intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
-  i915_reg_t reg, unsigned int op);
-
-struct intel_uncore_funcs {
-   void (*force_wake_get)(struct drm_i915_private *dev_priv,
-  enum forcewake_domains domains);
-   void (*force_wake_put)(struct drm_i915_private *dev_priv,
-  enum forcewake_domains domains);
-
-   uint8_t  (*mmio_readb)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-   uint16_t (*mmio_readw)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-   uint32_t (*mmio_readl)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-   uint64_t (*mmio_readq)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-
-   void (*mmio_writeb)(struct drm_i915_private *dev_priv,
-   i915_reg_t r, uint8_t val, bool trace);
-   void (*mmio_writew)(struct drm_i915_private *dev_priv,
-   i915_reg_t r, uint16_t val, bool trace);
-   void (*mmio_writel)(struct drm_i915_private *dev_priv,
-   i915_reg_t r, uint32_t val, bool trace);
-};
-
-struct intel_forcewake_range {
-   u32 start;
-   u32 end;
-
-   enum forcewake_domains domains;
-};
-
-struct intel_uncore {
-   spinlock_t lock; /** lock is also taken in irq contexts. */
-
-   const struct intel_forcewake_range *fw_domains_table;
-   unsigned int fw_domains_table_entries;
-
-   struct notifier_block pmic_bus_access_nb;
-   struct intel_uncore_funcs funcs;
-
-   unsigned fifo_count;
-
-   enum forcewake_domains fw_domains;
-   enum forcewake_domains fw_domains_active;
-
-   u32 fw_set;
-   u32 fw_clear;
-   u32 fw_reset;
-
-   struct intel_uncore_forcewake_domain {
-   enum forcewake_domain_id id;
-   enum forcewake_domains mask;
-   unsigned wake_count;
-   struct hrtimer timer;
-   i915_reg_t reg_set;
-   i915_reg_t reg_ack;
-   } fw_domain[FW_DOMAIN_ID_COUNT];
-
-   int unclaimed_mmio_check;
-};
-
-#define __mask_next_bit(mask) ({   \
-   int __idx = ffs(mask) - 1;  \
-   mask &= ~BIT(__idx);\
-   __idx;  \
-})
-
-/* Iterate over initialised fw domains */
-#define for_each_fw_domain_masked(domain__, mask__, dev_priv__, tmp__) \
-   for (tmp__ = (mask__); \
-tmp__ ? (domain__ = 
&(dev_priv__)->uncore.fw_domain[__mask_next_bit(tmp__)]), 1 : 0;)
-
-#define for_each_fw_domain(domain__, dev_priv__, tmp__) \
-   for_each_fw_domain_masked(domain__, (dev_priv__)->uncore.fw_domains, 
dev_priv__, tmp__)
-
 #define 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move uncore definitions into a separate header

[Michal Wajdeczko]

On Tue, May 09, 2017 at 12:00:58PM +0300, Mika Kuoppala wrote:
> Michal Wajdeczko  writes:
> 
> > In order to allow use of e.g. forcewake_domains in a other feature headers
> > included from the top of i915_drv.h, move all uncore related definitions
> > into their own header.
> >
> > Signed-off-by: Michal Wajdeczko 
> > Suggested-by: Joonas Lahtinen 
> > Cc: Joonas Lahtinen 
> > ---



> > -
> > -#define __mask_next_bit(mask) ({   \
> > -   int __idx = ffs(mask) - 1;  \
> > -   mask &= ~BIT(__idx);\
> > -   __idx;  \
> > -})
> > -
> 
> for_each_engine_masked needs this macro too, so we should leave it to
>  top level or i915_utils.h?

Sure, I'll move it to the i915_utils.h, but at the same time I'm
wondering how did I missed that.

Thanks,
Michal 

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

[Mika Kuoppala]

Michal Wajdeczko  writes:

> All other functions related to uncore start with intel_uncore prefix.
> Follow that pattern.
>
> Signed-off-by: Michal Wajdeczko 
> Cc: Joonas Lahtinen 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_drv.c | 2 +-
>  drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
>  drivers/gpu/drm/i915/intel_uncore.h | 2 +-
>  3 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
> index 72fb47a..4a3cb11 100644
> --- a/drivers/gpu/drm/i915/i915_drv.c
> +++ b/drivers/gpu/drm/i915/i915_drv.c
> @@ -2432,7 +2432,7 @@ static int intel_runtime_suspend(struct device *kdev)
>   intel_opregion_notify_adapter(dev_priv, PCI_D1);
>   }
>  
> - assert_forcewakes_inactive(dev_priv);
> + intel_uncore_assert_forcewakes_inactive(dev_priv);
>  
>   if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
>   intel_hpd_poll_init(dev_priv);
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index 2c628df..b5ded2c 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -287,7 +287,7 @@ static void intel_uncore_forcewake_reset(struct 
> drm_i915_private *dev_priv,
>   }
>  
>   if (!restore)
> - assert_forcewakes_inactive(dev_priv);
> + intel_uncore_assert_forcewakes_inactive(dev_priv);
>  
>   spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
>  }
> @@ -565,7 +565,7 @@ void intel_uncore_forcewake_put__locked(struct 
> drm_i915_private *dev_priv,
>   __intel_uncore_forcewake_put(dev_priv, fw_domains);
>  }
>  
> -void assert_forcewakes_inactive(struct drm_i915_private *dev_priv)
> +void intel_uncore_assert_forcewakes_inactive(struct drm_i915_private 
> *dev_priv)
>  {
>   if (!dev_priv->uncore.funcs.force_wake_get)
>   return;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
> b/drivers/gpu/drm/i915/intel_uncore.h
> index cced6b7..35fcdfb 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.h
> +++ b/drivers/gpu/drm/i915/intel_uncore.h
> @@ -128,7 +128,7 @@ void intel_uncore_suspend(struct drm_i915_private 
> *dev_priv);
>  void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
>  
>  u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
> -void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
> +void intel_uncore_assert_forcewakes_inactive(struct drm_i915_private 
> *dev_priv);
>  const char *intel_uncore_forcewake_domain_to_str(const enum 
> forcewake_domain_id id);
>  
>  enum forcewake_domains
> -- 
> 2.7.4
>
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v2 1/2] drm/i915: Move uncore definitions into a separate header

[Michal Wajdeczko]

In order to allow use of e.g. forcewake_domains in a other feature headers
included from the top of i915_drv.h, move all uncore related definitions
into their own header.

v2: move __mask_next_bit macro to utils header (Mika)

Signed-off-by: Michal Wajdeczko 
Suggested-by: Joonas Lahtinen 
Cc: Joonas Lahtinen 
Cc: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_drv.h | 157 +
 drivers/gpu/drm/i915/i915_utils.h   |   6 ++
 drivers/gpu/drm/i915/intel_uncore.c |  12 +++
 drivers/gpu/drm/i915/intel_uncore.h | 169 
 4 files changed, 188 insertions(+), 156 deletions(-)
 create mode 100644 drivers/gpu/drm/i915/intel_uncore.h

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index b20ed16..29a6966 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -55,6 +55,7 @@
 #include "i915_reg.h"
 #include "i915_utils.h"
 
+#include "intel_uncore.h"
 #include "intel_bios.h"
 #include "intel_dpll_mgr.h"
 #include "intel_uc.h"
@@ -676,116 +677,6 @@ struct drm_i915_display_funcs {
void (*load_luts)(struct drm_crtc_state *crtc_state);
 };
 
-enum forcewake_domain_id {
-   FW_DOMAIN_ID_RENDER = 0,
-   FW_DOMAIN_ID_BLITTER,
-   FW_DOMAIN_ID_MEDIA,
-
-   FW_DOMAIN_ID_COUNT
-};
-
-enum forcewake_domains {
-   FORCEWAKE_RENDER = BIT(FW_DOMAIN_ID_RENDER),
-   FORCEWAKE_BLITTER = BIT(FW_DOMAIN_ID_BLITTER),
-   FORCEWAKE_MEDIA = BIT(FW_DOMAIN_ID_MEDIA),
-   FORCEWAKE_ALL = (FORCEWAKE_RENDER |
-FORCEWAKE_BLITTER |
-FORCEWAKE_MEDIA)
-};
-
-#define FW_REG_READ  (1)
-#define FW_REG_WRITE (2)
-
-enum decoupled_power_domain {
-   GEN9_DECOUPLED_PD_BLITTER = 0,
-   GEN9_DECOUPLED_PD_RENDER,
-   GEN9_DECOUPLED_PD_MEDIA,
-   GEN9_DECOUPLED_PD_ALL
-};
-
-enum decoupled_ops {
-   GEN9_DECOUPLED_OP_WRITE = 0,
-   GEN9_DECOUPLED_OP_READ
-};
-
-enum forcewake_domains
-intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
-  i915_reg_t reg, unsigned int op);
-
-struct intel_uncore_funcs {
-   void (*force_wake_get)(struct drm_i915_private *dev_priv,
-  enum forcewake_domains domains);
-   void (*force_wake_put)(struct drm_i915_private *dev_priv,
-  enum forcewake_domains domains);
-
-   uint8_t  (*mmio_readb)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-   uint16_t (*mmio_readw)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-   uint32_t (*mmio_readl)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-   uint64_t (*mmio_readq)(struct drm_i915_private *dev_priv,
-  i915_reg_t r, bool trace);
-
-   void (*mmio_writeb)(struct drm_i915_private *dev_priv,
-   i915_reg_t r, uint8_t val, bool trace);
-   void (*mmio_writew)(struct drm_i915_private *dev_priv,
-   i915_reg_t r, uint16_t val, bool trace);
-   void (*mmio_writel)(struct drm_i915_private *dev_priv,
-   i915_reg_t r, uint32_t val, bool trace);
-};
-
-struct intel_forcewake_range {
-   u32 start;
-   u32 end;
-
-   enum forcewake_domains domains;
-};
-
-struct intel_uncore {
-   spinlock_t lock; /** lock is also taken in irq contexts. */
-
-   const struct intel_forcewake_range *fw_domains_table;
-   unsigned int fw_domains_table_entries;
-
-   struct notifier_block pmic_bus_access_nb;
-   struct intel_uncore_funcs funcs;
-
-   unsigned fifo_count;
-
-   enum forcewake_domains fw_domains;
-   enum forcewake_domains fw_domains_active;
-
-   u32 fw_set;
-   u32 fw_clear;
-   u32 fw_reset;
-
-   struct intel_uncore_forcewake_domain {
-   enum forcewake_domain_id id;
-   enum forcewake_domains mask;
-   unsigned wake_count;
-   struct hrtimer timer;
-   i915_reg_t reg_set;
-   i915_reg_t reg_ack;
-   } fw_domain[FW_DOMAIN_ID_COUNT];
-
-   int unclaimed_mmio_check;
-};
-
-#define __mask_next_bit(mask) ({   \
-   int __idx = ffs(mask) - 1;  \
-   mask &= ~BIT(__idx);\
-   __idx;  \
-})
-
-/* Iterate over initialised fw domains */
-#define for_each_fw_domain_masked(domain__, mask__, dev_priv__, tmp__) \
-   for (tmp__ = (mask__); \
-tmp__ ? (domain__ = 
&(dev_priv__)->uncore.fw_domain[__mask_next_bit(tmp__)]), 1 : 0;)
-
-#define 

[Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

[Mahesh Kumar]

DDB minimum requirement of crtc configuration (cumulative of all the
enabled planes in crtc) may exceed the allocated DDB for crtc/pipe.
This patch make changes to fail the flip/ioctl if minimum requirement
for pipe exceeds the total ddb allocated to the pipe.
Previously it succeeded but making alloc_size a negative value. Which
will make subsequent calculations for plane ddb allocation bogus & may
lead to screen corruption or system hang.

Changes from V1:
 - Improve commit message as per Ander's comment
 - Remove extra parentheses (Ander)

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2a4e9d89cd6f..c0f6aeab0390 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3591,6 +3591,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
int num_active;
unsigned plane_data_rate[I915_MAX_PLANES] = {};
unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
+   uint16_t total_min_blocks = 0;
 
/* Clear the partitioning for disabled planes. */
memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -3618,10 +3619,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
 */
 
for_each_plane_id_on_crtc(intel_crtc, plane_id) {
-   alloc_size -= minimum[plane_id];
-   alloc_size -= y_minimum[plane_id];
+   total_min_blocks += minimum[plane_id];
+   total_min_blocks += y_minimum[plane_id];
}
 
+   if (total_min_blocks > alloc_size) {
+   DRM_DEBUG_KMS("Requested display configuration exceeds system 
DDB limitations");
+   DRM_DEBUG_KMS("minimum required %d/%d\n", total_min_blocks,
+   alloc_size);
+   return -EINVAL;
+   }
+
+   alloc_size -= total_min_blocks;
ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
minimum[PLANE_CURSOR];
ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
 
-- 
2.11.0

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Move uncore definitions into a separate header

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915: Move uncore definitions into a 
separate header
URL   : https://patchwork.freedesktop.org/series/24161/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
pass   -> FAIL   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#100652

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:433s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:425s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:580s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:504s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:530s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:485s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:482s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:418s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:402s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:417s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:482s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:464s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:567s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:566s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:455s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:530s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:400s

f558b185c57202d90bdb9059f3d446956cbae133 drm-tip: 2017y-05m-08d-16h-35m-28s UTC 
integration manifest
0eb5a84 drm/i915: Rename assert_forcewakes_inactive
7ccebe5 drm/i915: Move uncore definitions into a separate header

== Logs ==

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

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

[Sharma, Shashank]

Regards

Shashank


On 5/8/2017 10:39 PM, Ville Syrjälä wrote:

On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/8/2017 9:54 PM, Ville Syrjälä wrote:

On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:

From: Jose Abreu 

HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.

These new blocks are:
- ycbcr420 video data (vdb) block: video modes which can be supported
only in ycbcr420 output mode.
- ycbcr420 video capability data (vcb) block: video modes which can be
support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 etc)

This patch adds parsing and handling of ycbcr420-vdb in the DRM
layer.

This patch is a modified version of Jose's RFC patch:
https://patchwork.kernel.org/patch/9492327/
so the authorship is maintained.

Cc: Ville Syrjala 
Signed-off-by: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
   drivers/gpu/drm/drm_edid.c  | 54 
+++--
   drivers/gpu/drm/drm_modes.c | 10 +++--
   include/drm/drm_connector.h |  1 +
   include/uapi/drm/drm_mode.h |  6 +
   4 files changed, 67 insertions(+), 4 deletions(-)



diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4eeda12..cef76b2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -199,6 +199,7 @@ struct drm_display_info {
   #define DRM_COLOR_FORMAT_RGB444  (1<<0)
   #define DRM_COLOR_FORMAT_YCRCB444(1<<1)
   #define DRM_COLOR_FORMAT_YCRCB422(1<<2)
+#define DRM_COLOR_FORMAT_YCRCB420  (1<<2)
   
   	/**

 * @color_formats: HDMI Color formats, selects between RGB and YCrCb
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8c67fc0..1e74d8e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -84,6 +84,12 @@ extern "C" {
   #define  DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH  (6<<14)
   #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM (7<<14)
   #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF  (8<<14)
+/*
+ * HDMI 2.0
+ */
+#define DRM_MODE_FLAG_420_MASK (0x03<<23)
+#define  DRM_MODE_FLAG_420 (1<<23)
+#define  DRM_MODE_FLAG_420_ONLY(1<<24)

Adding those would again break the uabi. We can't add new mode flags
without some kind of client cap.
But I think we agreed that new user
space visible mode flags aren't needed, and instad we can keep it all
internal?

Yep you are right, we had decided to keep it internal, and this whole
patch series is implemented in such a way only, to control everything
through the HDMI output property itself.
But may be I slightly misunderstood that we shouldn't add the flags bits
all together, and I added this flag to differentiate between YCBCR420
and notmal modes.
Can you please suggest me on:
- how to differentiate a YCBCR420 mode with normal mode ? I still need
to add a flag, but not expose it into uapi layer.

I guess we can just tack on a few new bools to the end of
drm_display_mode. And then when we get the mode passed in by the user
we'll have to check whether that mode matches any CEA mode and
then look up the correct YCbCr 4:2:0 mode for it.
seems good to me, I can add a is_ycbcr420 flag, and we need not to 
bother about converting it to drm_mode_modeinfo as we are keeping it 
internal.


Hmm. Actually, that probably means that it isn't sufficient to
actually store this information on the modes we have on the connector's
mode list, because that list has been filtered and so may not actually
have all the modes that were declared in the EDID.
I dint get this point,  Why do you think its not sufficient ? Do we need 
to care about the modes which are getting rejected from the driver ?
I guess they cant be applied anyways.  Do you think we will miss some of 
the YCBCR modes due to mode filtering ?

So I'm thinking we
should perhaps make the bitmap parsed from the Y402CMDB index the
full CEA mode list. That we can just lookup the matching VIC for
the user provided mode and check whether the bit for that VIC
indicates 4:2:0 support. And maybe we can handle Y420VDB in exactly
the same way (ie. just a second bitmap). That would have the additional
nice feature that the maximum length of those bitmaps is well defined
(at most 256 VICs).

We can do this, but do we really need 2 bitmaps ? A YCBCR420 support is 
same whether its coming from VCB or VDB, we just need a ORing of these 
supports.
Even in the current implementation, I have been using only the 
YCBCR420_MASK to identify support.


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

[Intel-gfx] [PATCH 07/11] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

[Mahesh Kumar]

DDB minimum requirement of crtc configuration (cumulative of all the
enabled planes in crtc) may exceed the allocated DDB for crtc/pipe.
This patch make changes to fail the flip/ioctl if minimum requirement
for pipe exceeds the total ddb allocated to the pipe.
Previously it succeeded but making alloc_size a negative value. Which
will make subsequent calculations for plane ddb allocation bogus & may
lead to screen corruption or system hang.

Changes from V1:
 - Improve commit message as per Ander's comment
 - Remove extra parentheses (Ander)

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

diff --git a/drivers/gpu/drm/i915/intel_pm.c b/drivers/gpu/drm/i915/intel_pm.c
index 2a4e9d89cd6f..c0f6aeab0390 100644
--- a/drivers/gpu/drm/i915/intel_pm.c
+++ b/drivers/gpu/drm/i915/intel_pm.c
@@ -3591,6 +3591,7 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
int num_active;
unsigned plane_data_rate[I915_MAX_PLANES] = {};
unsigned plane_y_data_rate[I915_MAX_PLANES] = {};
+   uint16_t total_min_blocks = 0;
 
/* Clear the partitioning for disabled planes. */
memset(ddb->plane[pipe], 0, sizeof(ddb->plane[pipe]));
@@ -3618,10 +3619,18 @@ skl_allocate_pipe_ddb(struct intel_crtc_state *cstate,
 */
 
for_each_plane_id_on_crtc(intel_crtc, plane_id) {
-   alloc_size -= minimum[plane_id];
-   alloc_size -= y_minimum[plane_id];
+   total_min_blocks += minimum[plane_id];
+   total_min_blocks += y_minimum[plane_id];
}
 
+   if (total_min_blocks > alloc_size) {
+   DRM_DEBUG_KMS("Requested display configuration exceeds system 
DDB limitations");
+   DRM_DEBUG_KMS("minimum required %d/%d\n", total_min_blocks,
+   alloc_size);
+   return-EINVAL;
+   }
+
+   alloc_size -= total_min_blocks;
ddb->plane[pipe][PLANE_CURSOR].start = alloc->end - 
minimum[PLANE_CURSOR];
ddb->plane[pipe][PLANE_CURSOR].end = alloc->end;
 
-- 
2.11.0

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

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[Mathias Nyman]

diff --git a/drivers/usb/host/xhci-pci.c b/drivers/usb/host/xhci-pci.c
index 7b86508ac8cf..93b4f0de9418 100644
--- a/drivers/usb/host/xhci-pci.c
+++ b/drivers/usb/host/xhci-pci.c
@@ -210,13 +210,12 @@ static void xhci_pci_quirks(struct device *dev, struct 
xhci_hcd *xhci)
  #ifdef CONFIG_ACPI
  static void xhci_pme_acpi_rtd3_enable(struct pci_dev *dev)
  {
-   static const u8 intel_dsm_uuid[] = {
-   0xb7, 0x0c, 0x34, 0xac, 0x01, 0xe9, 0xbf, 0x45,
-   0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23,
-   };
+   static const uuid_le intel_dsm_uuid =
+   UUID_LE(0xac340cb7, 0xe901, 0x45bf,
+   0xb7, 0xe6, 0x2b, 0x34, 0xec, 0x93, 0x1e, 0x23);
union acpi_object *obj;

-   obj = acpi_evaluate_dsm(ACPI_HANDLE(>dev), intel_dsm_uuid, 3, 1,
+   obj = acpi_evaluate_dsm(ACPI_HANDLE(>dev), _dsm_uuid, 3, 1,
NULL);
ACPI_FREE(obj);
  }


For the xhci part above:

Acked-by: Mathias Nyman 


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

[Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

[Michal Wajdeczko]

All other functions related to uncore start with intel_uncore prefix.
Follow that pattern.

Signed-off-by: Michal Wajdeczko 
Cc: Joonas Lahtinen 
---
 drivers/gpu/drm/i915/i915_drv.c | 2 +-
 drivers/gpu/drm/i915/intel_uncore.c | 4 ++--
 drivers/gpu/drm/i915/intel_uncore.h | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 72fb47a..4a3cb11 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -2432,7 +2432,7 @@ static int intel_runtime_suspend(struct device *kdev)
intel_opregion_notify_adapter(dev_priv, PCI_D1);
}
 
-   assert_forcewakes_inactive(dev_priv);
+   intel_uncore_assert_forcewakes_inactive(dev_priv);
 
if (!IS_VALLEYVIEW(dev_priv) && !IS_CHERRYVIEW(dev_priv))
intel_hpd_poll_init(dev_priv);
diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
b/drivers/gpu/drm/i915/intel_uncore.c
index 2c628df..b5ded2c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -287,7 +287,7 @@ static void intel_uncore_forcewake_reset(struct 
drm_i915_private *dev_priv,
}
 
if (!restore)
-   assert_forcewakes_inactive(dev_priv);
+   intel_uncore_assert_forcewakes_inactive(dev_priv);
 
spin_unlock_irqrestore(_priv->uncore.lock, irqflags);
 }
@@ -565,7 +565,7 @@ void intel_uncore_forcewake_put__locked(struct 
drm_i915_private *dev_priv,
__intel_uncore_forcewake_put(dev_priv, fw_domains);
 }
 
-void assert_forcewakes_inactive(struct drm_i915_private *dev_priv)
+void intel_uncore_assert_forcewakes_inactive(struct drm_i915_private *dev_priv)
 {
if (!dev_priv->uncore.funcs.force_wake_get)
return;
diff --git a/drivers/gpu/drm/i915/intel_uncore.h 
b/drivers/gpu/drm/i915/intel_uncore.h
index cced6b7..35fcdfb 100644
--- a/drivers/gpu/drm/i915/intel_uncore.h
+++ b/drivers/gpu/drm/i915/intel_uncore.h
@@ -128,7 +128,7 @@ void intel_uncore_suspend(struct drm_i915_private 
*dev_priv);
 void intel_uncore_resume_early(struct drm_i915_private *dev_priv);
 
 u64 intel_uncore_edram_size(struct drm_i915_private *dev_priv);
-void assert_forcewakes_inactive(struct drm_i915_private *dev_priv);
+void intel_uncore_assert_forcewakes_inactive(struct drm_i915_private 
*dev_priv);
 const char *intel_uncore_forcewake_domain_to_str(const enum 
forcewake_domain_id id);
 
 enum forcewake_domains
-- 
2.7.4

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

[Intel-gfx] ✓ Fi.CI.BAT: success for Implement DDB algorithm and WM cleanup (rev4)

[Patchwork]

== Series Details ==

Series: Implement DDB algorithm and WM cleanup (rev4)
URL   : https://patchwork.freedesktop.org/series/20376/
State : success

== Summary ==

Series 20376v4 Implement DDB algorithm and WM cleanup
https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/4/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#100652

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:432s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:507s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:546s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:484s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:417s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:403s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:470s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:576s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:452s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:576s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:468s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:489s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:430s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:410s

f558b185c57202d90bdb9059f3d446956cbae133 drm-tip: 2017y-05m-08d-16h-35m-28s UTC 
integration manifest
cb76814 drm/i915/skl+: consider max supported plane pixel rate while scaling
11009bc drm/i915/skl: New ddb allocation algorithm
6ef345e drm/i915/skl+: use linetime latency if ddb size is not available
df85039 drm/i915/skl+: Watermark calculation cleanup
1696606 drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe 
allocation
8545cbe drm/i915/skl+: no need to memset again
077ca5b drm/i915/skl: Fail the flip if no FB for WM calculation
d071301 drm/i915/skl+: calculate pixel_rate & relative_data_rate in fixed point
79b852b drm/i915: Use fixed_16_16 wrapper for division operation
66a693f drm/i915: Add more wrapper for fixed_point_16_16 operations
7775207 drm/i915: fix naming of fixed_16_16 wrapper.

== Logs ==

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

Re: [Intel-gfx] [PATCH 04/11] drm: parse ycbcr420 vcb block

[Sharma, Shashank]

Regards

Shashank


On 5/8/2017 10:28 PM, Ville Syrjälä wrote:

On Fri, Apr 07, 2017 at 07:39:21PM +0300, Shashank Sharma wrote:

HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.

One of these new blocks is: ycbcr420 vcb
- ycbcr420 video capability data (vcb) block: video modes which can be
   support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 etc)

This patch adds parsing and handling of ycbcr420-vcb in the DRM layer.
This block contains a bitmap about which mode, from among the list of
normal svd videomodes, can support ycbcr420 output too.

So if bit 0 from first vcb byte is set, means first video mode in the
svd list, can be supported in ycbcr420 output too. Bit 2 means second
video mode from svd list, and so on.

Cc: Ville Syrjala 
Cc: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
  drivers/gpu/drm/drm_edid.c  | 80 +++--
  include/drm/drm_connector.h |  1 +
  2 files changed, 79 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 64d8e2e..d01b7df 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -2778,6 +2778,7 @@ add_detailed_modes(struct drm_connector *connector, 
struct edid *edid,
  #define SPEAKER_BLOCK 0x04
  #define VIDEO_CAPABILITY_BLOCK0x07
  #define VIDEO_DATA_BLOCK_420  0x0E
+#define VIDEO_CAP_BLOCK_4200x0F
  #define EDID_BASIC_AUDIO  (1 << 6)
  #define EDID_CEA_YCRCB444 (1 << 5)
  #define EDID_CEA_YCRCB422 (1 << 4)
@@ -3143,11 +3144,21 @@ static int
  do_cea_modes(struct drm_connector *connector, const u8 *db, u8 len)
  {
int i, modes = 0;
+   u64 hdmi_420_cap_map = connector->display_info.hdmi.ycbcr420_vcb_map;
  
  	for (i = 0; i < len; i++) {

struct drm_display_mode *mode;
mode = drm_display_mode_from_vic_index(connector, db, len, i);
if (mode) {
+   /*
+* ycbcr420 capability block contains a bitmap which
+* gives the index of such CEA modes in VDB, which can
+* support ycbcr420 sampling output also.
+* For example, if the bit 0 in bitmap is set,
+* first mode in VDB can support ycbcr420 output too.
+*/
+   if (hdmi_420_cap_map & (1 << i))

We'd need to make sure 'len' is <=64. Not sure if there's any point in
making it possible to have more than 64 VDBs. If there is, then the standard
bitops.h stuff could be used to make the map longer quite trivially.
I know, among the monitors I have tested with (ACER and SAMSUNG) I have 
found only 1 or 2 modes in the capability map.
But as there is no limit of a 420_VBD block length from the spec, so 
thought it would be good to assume some safe limit.


Whatever limit we choose I think we should print some kind of warning
to indicate that we've exceeded whatever arbitrary limit we chose. And
I definitely think it should be a warning level at least to make sure
we get a bug report about it.

Sure, I can add a warning, for the cases where we cross 64 modes.

+   mode->flags |= DRM_MODE_FLAG_420;
drm_mode_probed_add(connector, mode);
modes++;
}
@@ -3526,9 +3537,64 @@ static bool cea_db_is_hdmi_vdb420(const u8 *db)
return true;
  }
  
+static bool cea_db_is_hdmi_vcb420(const u8 *db)

To keep with the spec terminology this should probably be called
cea_db_is_y420cmdb(). Same for the define and other functions dealing
witrh this block.

Got it.

+{
+   if (cea_db_tag(db) != VIDEO_CAPABILITY_BLOCK)
+   return false;
+

We need to make sure the payload is long enough to actuall contain the
extended tag.
Dint I check that in the caller ? anyways, I will make sure there is a 
check.

+   if (cea_db_extended_tag(db) != VIDEO_CAP_BLOCK_420)
+   return false;
+
+   return true;
+}
+
  #define for_each_cea_db(cea, i, start, end) \
for ((i) = (start); (i) < (end) && (i) + cea_db_payload_len(&(cea)[(i)]) < 
(end); (i) += cea_db_payload_len(&(cea)[(i)]) + 1)
  
+static void drm_parse_vcb_420_bitmap(struct drm_connector *connector,

+const u8 *db)
+{
+   struct drm_display_info *info = >display_info;
+   struct drm_hdmi_info *hdmi = >hdmi;
+   u8 map_len = cea_db_payload_len(db) - 1;
+   u8 count;
+   u64 map = 0;
+
+   if (!db)
+   return;

Is that possible somehow?

Bad, corrupt EDID extension from a bad monitor ;-) ?



+
+   if (map_len == 0) {
+   /* All CEA modes support ycbcr420 sampling also.*/
+   hdmi->ycbcr420_vcb_map = 

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Move uncore definitions into a separate header

[Mika Kuoppala]

Michal Wajdeczko  writes:

> In order to allow use of e.g. forcewake_domains in a other feature headers
> included from the top of i915_drv.h, move all uncore related definitions
> into their own header.
>
> Signed-off-by: Michal Wajdeczko 
> Suggested-by: Joonas Lahtinen 
> Cc: Joonas Lahtinen 
> ---
>  drivers/gpu/drm/i915/i915_drv.h | 157 +---
>  drivers/gpu/drm/i915/intel_uncore.c |  12 +++
>  drivers/gpu/drm/i915/intel_uncore.h | 175 
> 
>  3 files changed, 188 insertions(+), 156 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_uncore.h
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b20ed16..29a6966 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
>  #include "i915_reg.h"
>  #include "i915_utils.h"
>  
> +#include "intel_uncore.h"
>  #include "intel_bios.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_uc.h"
> @@ -676,116 +677,6 @@ struct drm_i915_display_funcs {
>   void (*load_luts)(struct drm_crtc_state *crtc_state);
>  };
>  
> -enum forcewake_domain_id {
> - FW_DOMAIN_ID_RENDER = 0,
> - FW_DOMAIN_ID_BLITTER,
> - FW_DOMAIN_ID_MEDIA,
> -
> - FW_DOMAIN_ID_COUNT
> -};
> -
> -enum forcewake_domains {
> - FORCEWAKE_RENDER = BIT(FW_DOMAIN_ID_RENDER),
> - FORCEWAKE_BLITTER = BIT(FW_DOMAIN_ID_BLITTER),
> - FORCEWAKE_MEDIA = BIT(FW_DOMAIN_ID_MEDIA),
> - FORCEWAKE_ALL = (FORCEWAKE_RENDER |
> -  FORCEWAKE_BLITTER |
> -  FORCEWAKE_MEDIA)
> -};
> -
> -#define FW_REG_READ  (1)
> -#define FW_REG_WRITE (2)
> -
> -enum decoupled_power_domain {
> - GEN9_DECOUPLED_PD_BLITTER = 0,
> - GEN9_DECOUPLED_PD_RENDER,
> - GEN9_DECOUPLED_PD_MEDIA,
> - GEN9_DECOUPLED_PD_ALL
> -};
> -
> -enum decoupled_ops {
> - GEN9_DECOUPLED_OP_WRITE = 0,
> - GEN9_DECOUPLED_OP_READ
> -};
> -
> -enum forcewake_domains
> -intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
> -i915_reg_t reg, unsigned int op);
> -
> -struct intel_uncore_funcs {
> - void (*force_wake_get)(struct drm_i915_private *dev_priv,
> -enum forcewake_domains domains);
> - void (*force_wake_put)(struct drm_i915_private *dev_priv,
> -enum forcewake_domains domains);
> -
> - uint8_t  (*mmio_readb)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint16_t (*mmio_readw)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint32_t (*mmio_readl)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint64_t (*mmio_readq)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> -
> - void (*mmio_writeb)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint8_t val, bool trace);
> - void (*mmio_writew)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint16_t val, bool trace);
> - void (*mmio_writel)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint32_t val, bool trace);
> -};
> -
> -struct intel_forcewake_range {
> - u32 start;
> - u32 end;
> -
> - enum forcewake_domains domains;
> -};
> -
> -struct intel_uncore {
> - spinlock_t lock; /** lock is also taken in irq contexts. */
> -
> - const struct intel_forcewake_range *fw_domains_table;
> - unsigned int fw_domains_table_entries;
> -
> - struct notifier_block pmic_bus_access_nb;
> - struct intel_uncore_funcs funcs;
> -
> - unsigned fifo_count;
> -
> - enum forcewake_domains fw_domains;
> - enum forcewake_domains fw_domains_active;
> -
> - u32 fw_set;
> - u32 fw_clear;
> - u32 fw_reset;
> -
> - struct intel_uncore_forcewake_domain {
> - enum forcewake_domain_id id;
> - enum forcewake_domains mask;
> - unsigned wake_count;
> - struct hrtimer timer;
> - i915_reg_t reg_set;
> - i915_reg_t reg_ack;
> - } fw_domain[FW_DOMAIN_ID_COUNT];
> -
> - int unclaimed_mmio_check;
> -};
> -
> -#define __mask_next_bit(mask) ({ \
> - int __idx = ffs(mask) - 1;  \
> - mask &= ~BIT(__idx);\
> - __idx;  \
> -})
> -

for_each_engine_masked needs this macro too, so we should leave it to
 top level or i915_utils.h?
-Mika

> -/* Iterate over initialised fw domains */
> -#define for_each_fw_domain_masked(domain__, mask__, dev_priv__, tmp__) \
> - 

Re: [Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[Li, Weinan Z]

Really sorry, please ignore this mail with wrong patch. Will send the correct 
one then.

Thanks.
Best Regards.
Weinan, LI


> -Original Message-
> From: Li, Weinan Z
> Sent: Wednesday, May 10, 2017 10:48 AM
> To: intel-gfx@lists.freedesktop.org; intel-gvt-...@lists.freedesktop.org
> Cc: Li, Weinan Z ; Chris Wilson  wilson.co.uk>; Joonas Lahtinen 
> Subject: [PATCH v4] drm/i915/gvt: return the correct usable aperture size
> under gvt environment
> 
> I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
> In gvt environment, each vm only use the ballooned part of aperture, so we
> should return the correct available aperture size exclude the reserved part by
> balloon.
> 
> v2: add 'reserved' in struct i915_address_space to record the reserved size in
> ggtt.
> 
> v3: remain aper_size as total, adjust aper_available_size exclude reserved and
> pinned. UMD driver need to adjust the max allocation size according to the
> available aperture size but not total size. KMD return the correct usable
> aperture size any time.
> 
> v4: add onion teardown to balloon and deballoon to make sure the reserved
> stays correct. Code style refine.
> 
> Cc: Chris Wilson 
> Cc: Joonas Lahtinen 
> Signed-off-by: Weinan Li 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 4 ++--
>  drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
>  drivers/gpu/drm/i915/i915_vgpu.c| 8 +++-
>  3 files changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c
> b/drivers/gpu/drm/i915/i915_gem.c index 33fb11c..8d8d9c0 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -156,8 +156,8 @@ int i915_mutex_lock_interruptible(struct drm_device
> *dev)
>   mutex_unlock(>struct_mutex);
> 
>   args->aper_size = ggtt->base.total;
> - args->aper_available_size = args->aper_size - pinned;
> -
> + args->aper_available_size = args->aper_size -
> + ggtt->base.reserved - pinned;
>   return 0;
>  }
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h
> b/drivers/gpu/drm/i915/i915_gem_gtt.h
> index fb15684..da9aa9f 100644
> --- a/drivers/gpu/drm/i915/i915_gem_gtt.h
> +++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
> @@ -255,6 +255,7 @@ struct i915_address_space {
>   struct drm_i915_file_private *file;
>   struct list_head global_link;
>   u64 total;  /* size addr space maps (ex. 2GB for ggtt) */
> + u64 reserved;   /* size addr space reserved */
> 
>   bool closed;
> 
> diff --git a/drivers/gpu/drm/i915/i915_vgpu.c
> b/drivers/gpu/drm/i915/i915_vgpu.c
> index 4ab8a97..b144cf6 100644
> --- a/drivers/gpu/drm/i915/i915_vgpu.c
> +++ b/drivers/gpu/drm/i915/i915_vgpu.c
> @@ -109,8 +109,10 @@ void intel_vgt_deballoon(struct drm_i915_private
> *dev_priv)
>   DRM_DEBUG("VGT deballoon.\n");
> 
>   for (i = 0; i < 4; i++) {
> - if (bl_info.space[i].allocated)
> + if (bl_info.space[i].allocated) {
> + dev_priv->ggtt->base.reserved -= bl_info.space[i].size;
>   drm_mm_remove_node(_info.space[i]);
> + }
>   }
> 
>   memset(_info, 0, sizeof(bl_info));
> @@ -216,6 +218,7 @@ int intel_vgt_balloon(struct drm_i915_private
> *dev_priv)
> 
>   if (ret)
>   goto err;
> + ggtt->base.reserved += bl_info.space[2].size;
>   }
> 
>   if (unmappable_end < ggtt_end) {
> @@ -223,6 +226,7 @@ int intel_vgt_balloon(struct drm_i915_private
> *dev_priv)
>   unmappable_end, ggtt_end);
>   if (ret)
>   goto err;
> + ggtt->base.reserved += bl_info.space[3].size;
>   }
> 
>   /* Mappable graphic memory ballooning */ @@ -232,6 +236,7 @@ int
> intel_vgt_balloon(struct drm_i915_private *dev_priv)
> 
>   if (ret)
>   goto err;
> + ggtt->base.reserved += bl_info.space[0].size;
>   }
> 
>   if (mappable_end < ggtt->mappable_end) { @@ -240,6 +245,7 @@ int
> intel_vgt_balloon(struct drm_i915_private *dev_priv)
> 
>   if (ret)
>   goto err;
> + ggtt->base.reserved += bl_info.space[1].size;
>   }
> 
>   DRM_INFO("VGT balloon successfully\n");
> --
> 1.9.1

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: return the correct usable aperture size under gvt environment (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: return the correct usable aperture size under gvt 
environment (rev2)
URL   : https://patchwork.freedesktop.org/series/24206/
State : success

== Summary ==

Series 24206v2 drm/i915/gvt: return the correct usable aperture size under gvt 
environment
https://patchwork.freedesktop.org/api/1.0/series/24206/revisions/2/mbox/

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:436s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:437s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:594s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:523s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:535s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:497s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:500s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:426s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:417s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:419s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:498s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:572s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:583s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:469s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:498s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:535s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:410s

417babaa12ad98dad2c39f361612f1afe6894816 drm-tip: 2017y-05m-09d-13h-13m-23s UTC 
integration manifest
25b4a18 drm/i915/gvt: return the correct usable aperture size under gvt 
environment

== Logs ==

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

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

[Li, Weinan Z]

> -Original Message-
> From: Joonas Lahtinen [mailto:joonas.lahti...@linux.intel.com]
> Sent: Tuesday, May 9, 2017 8:36 PM
> To: Li, Weinan Z ; intel-gfx@lists.freedesktop.org; 
> intel-
> gvt-...@lists.freedesktop.org
> Cc: Chris Wilson 
> Subject: Re: [PATCH v3] drm/i915/gvt: return the actual aperture size under 
> gvt
> environment
> 
> On ti, 2017-05-09 at 03:10 +, Li, Weinan Z wrote:
> 
> > > > > @@ -242,6 +242,9 @@ int intel_vgt_balloon(struct
> > > > > drm_i915_private
> > > > > *dev_priv)
> > > > >   goto err;
> > > > >   }
> > > > >
> > > > > + for (i = 0; i < ARRAY_SIZE(bl_info.space); i++)
> > > > > + ggtt->base.reserved += bl_info.space[i].size;
> > > > > +
> > >
> > > There should be an equal decrease when deballooning is done. And for
> > > that to be correct, you need to add proper onion teardown to this
> > > function to make sure the count stays correct (can't call deballoon
> > > on failure or the count will become negative which will result in huge
> number marked as reserved).
> > Oh, that's my fault. Should add clean up in intel_vgt_deballoon().
> > @@ -114,6 +114,7 @@ void intel_vgt_deballoon(struct drm_i915_private
> > *dev_priv)
> > }
> >
> > memset(_info, 0, sizeof(bl_info));
> > +   dev_priv->ggtt.reserved = 0;
> > }
> > Since if any steps in intel_vgt_balloon() fail, it will deal as error
> > and run
> > intel_vgt_deballoon() for clean up, no partial success happen.
> > So we only calculate the reserved when balloon success, it can ensure it's
> correct.
> 
> Onion teardown should be used according to kernel coding style, there's really
> no excuse not to.
> 
> Just add to the ggtt->base.reserved in increments, and remove in increments
> during teardown or in the deballoon function. ggtt.reserved is not exclusively
> for GVT-g to use, so you can't simply zero it. There needs to be incremental
> additions and substractions as objects are added and removed for the variable
> to stay general.
Got it, I will refine it and send as patch v4.
> 
> Regards, Joonas
> --
> Joonas Lahtinen
> Open Source Technology Center
> Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[Weinan Li]

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
In gvt environment, each vm only use the ballooned part of aperture, so we
should return the correct available aperture size exclude the reserved part
by balloon.

v2: add 'reserved' in struct i915_address_space to record the reserved size
in ggtt.

v3: remain aper_size as total, adjust aper_available_size exclude reserved
and pinned. UMD driver need to adjust the max allocation size according to
the available aperture size but not total size. KMD return the correct
usable aperture size any time.

v4: add onion teardown to balloon and deballoon to make sure the reserved
stays correct. Code style refine.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Weinan Li 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
 drivers/gpu/drm/i915/i915_vgpu.c| 8 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33fb11c..8d8d9c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -156,8 +156,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
mutex_unlock(>struct_mutex);
 
args->aper_size = ggtt->base.total;
-   args->aper_available_size = args->aper_size - pinned;
-
+   args->aper_available_size = args->aper_size -
+   ggtt->base.reserved - pinned;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684..da9aa9f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -255,6 +255,7 @@ struct i915_address_space {
struct drm_i915_file_private *file;
struct list_head global_link;
u64 total;  /* size addr space maps (ex. 2GB for ggtt) */
+   u64 reserved;   /* size addr space reserved */
 
bool closed;
 
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 4ab8a97..b144cf6 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -109,8 +109,10 @@ void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
DRM_DEBUG("VGT deballoon.\n");
 
for (i = 0; i < 4; i++) {
-   if (bl_info.space[i].allocated)
+   if (bl_info.space[i].allocated) {
+   dev_priv->ggtt->base.reserved -= bl_info.space[i].size;
drm_mm_remove_node(_info.space[i]);
+   }
}
 
memset(_info, 0, sizeof(bl_info));
@@ -216,6 +218,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[2].size;
}
 
if (unmappable_end < ggtt_end) {
@@ -223,6 +226,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
unmappable_end, ggtt_end);
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[3].size;
}
 
/* Mappable graphic memory ballooning */
@@ -232,6 +236,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[0].size;
}
 
if (mappable_end < ggtt->mappable_end) {
@@ -240,6 +245,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[1].size;
}
 
DRM_INFO("VGT balloon successfully\n");
-- 
1.9.1

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

[Intel-gfx] [PATCH v4] drm/i915/gvt: return the correct usable aperture size under gvt environment

[Weinan Li]

I915_GEM_GET_APERTURE ioctl is used to probe aperture size from userspace.
In gvt environment, each vm only use the ballooned part of aperture, so we
should return the correct available aperture size exclude the reserved part
by balloon.

v2: add 'reserved' in struct i915_address_space to record the reserved size
in ggtt.

v3: remain aper_size as total, adjust aper_available_size exclude reserved
and pinned. UMD driver need to adjust the max allocation size according to
the available aperture size but not total size. KMD return the correct
usable aperture size any time.

v4: add onion teardown to balloon and deballoon to make sure the reserved
stays correct. Code style refine.

Cc: Chris Wilson 
Cc: Joonas Lahtinen 
Signed-off-by: Weinan Li 
---
 drivers/gpu/drm/i915/i915_gem.c | 4 ++--
 drivers/gpu/drm/i915/i915_gem_gtt.h | 1 +
 drivers/gpu/drm/i915/i915_vgpu.c| 8 +++-
 3 files changed, 10 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 33fb11c..8d8d9c0 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -156,8 +156,8 @@ int i915_mutex_lock_interruptible(struct drm_device *dev)
mutex_unlock(>struct_mutex);
 
args->aper_size = ggtt->base.total;
-   args->aper_available_size = args->aper_size - pinned;
-
+   args->aper_available_size = args->aper_size -
+   ggtt->base.reserved - pinned;
return 0;
 }
 
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h 
b/drivers/gpu/drm/i915/i915_gem_gtt.h
index fb15684..da9aa9f 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.h
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.h
@@ -255,6 +255,7 @@ struct i915_address_space {
struct drm_i915_file_private *file;
struct list_head global_link;
u64 total;  /* size addr space maps (ex. 2GB for ggtt) */
+   u64 reserved;   /* size addr space reserved */
 
bool closed;
 
diff --git a/drivers/gpu/drm/i915/i915_vgpu.c b/drivers/gpu/drm/i915/i915_vgpu.c
index 4ab8a97..25bed9b 100644
--- a/drivers/gpu/drm/i915/i915_vgpu.c
+++ b/drivers/gpu/drm/i915/i915_vgpu.c
@@ -109,8 +109,10 @@ void intel_vgt_deballoon(struct drm_i915_private *dev_priv)
DRM_DEBUG("VGT deballoon.\n");
 
for (i = 0; i < 4; i++) {
-   if (bl_info.space[i].allocated)
+   if (bl_info.space[i].allocated) {
+   dev_priv->ggtt.base.reserved -= bl_info.space[i].size;
drm_mm_remove_node(_info.space[i]);
+   }
}
 
memset(_info, 0, sizeof(bl_info));
@@ -216,6 +218,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[2].size;
}
 
if (unmappable_end < ggtt_end) {
@@ -223,6 +226,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
unmappable_end, ggtt_end);
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[3].size;
}
 
/* Mappable graphic memory ballooning */
@@ -232,6 +236,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[0].size;
}
 
if (mappable_end < ggtt->mappable_end) {
@@ -240,6 +245,7 @@ int intel_vgt_balloon(struct drm_i915_private *dev_priv)
 
if (ret)
goto err;
+   ggtt->base.reserved += bl_info.space[1].size;
}
 
DRM_INFO("VGT balloon successfully\n");
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Move uncore definitions into a separate header

[Mika Kuoppala]

Michal Wajdeczko  writes:

> In order to allow use of e.g. forcewake_domains in a other feature headers
> included from the top of i915_drv.h, move all uncore related definitions
> into their own header.
>
> v2: move __mask_next_bit macro to utils header (Mika)
>
> Signed-off-by: Michal Wajdeczko 
> Suggested-by: Joonas Lahtinen 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 

Reviewed-by: Mika Kuoppala 

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 157 +
>  drivers/gpu/drm/i915/i915_utils.h   |   6 ++
>  drivers/gpu/drm/i915/intel_uncore.c |  12 +++
>  drivers/gpu/drm/i915/intel_uncore.h | 169 
> 
>  4 files changed, 188 insertions(+), 156 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_uncore.h
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b20ed16..29a6966 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
>  #include "i915_reg.h"
>  #include "i915_utils.h"
>  
> +#include "intel_uncore.h"
>  #include "intel_bios.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_uc.h"
> @@ -676,116 +677,6 @@ struct drm_i915_display_funcs {
>   void (*load_luts)(struct drm_crtc_state *crtc_state);
>  };
>  
> -enum forcewake_domain_id {
> - FW_DOMAIN_ID_RENDER = 0,
> - FW_DOMAIN_ID_BLITTER,
> - FW_DOMAIN_ID_MEDIA,
> -
> - FW_DOMAIN_ID_COUNT
> -};
> -
> -enum forcewake_domains {
> - FORCEWAKE_RENDER = BIT(FW_DOMAIN_ID_RENDER),
> - FORCEWAKE_BLITTER = BIT(FW_DOMAIN_ID_BLITTER),
> - FORCEWAKE_MEDIA = BIT(FW_DOMAIN_ID_MEDIA),
> - FORCEWAKE_ALL = (FORCEWAKE_RENDER |
> -  FORCEWAKE_BLITTER |
> -  FORCEWAKE_MEDIA)
> -};
> -
> -#define FW_REG_READ  (1)
> -#define FW_REG_WRITE (2)
> -
> -enum decoupled_power_domain {
> - GEN9_DECOUPLED_PD_BLITTER = 0,
> - GEN9_DECOUPLED_PD_RENDER,
> - GEN9_DECOUPLED_PD_MEDIA,
> - GEN9_DECOUPLED_PD_ALL
> -};
> -
> -enum decoupled_ops {
> - GEN9_DECOUPLED_OP_WRITE = 0,
> - GEN9_DECOUPLED_OP_READ
> -};
> -
> -enum forcewake_domains
> -intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
> -i915_reg_t reg, unsigned int op);
> -
> -struct intel_uncore_funcs {
> - void (*force_wake_get)(struct drm_i915_private *dev_priv,
> -enum forcewake_domains domains);
> - void (*force_wake_put)(struct drm_i915_private *dev_priv,
> -enum forcewake_domains domains);
> -
> - uint8_t  (*mmio_readb)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint16_t (*mmio_readw)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint32_t (*mmio_readl)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint64_t (*mmio_readq)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> -
> - void (*mmio_writeb)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint8_t val, bool trace);
> - void (*mmio_writew)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint16_t val, bool trace);
> - void (*mmio_writel)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint32_t val, bool trace);
> -};
> -
> -struct intel_forcewake_range {
> - u32 start;
> - u32 end;
> -
> - enum forcewake_domains domains;
> -};
> -
> -struct intel_uncore {
> - spinlock_t lock; /** lock is also taken in irq contexts. */
> -
> - const struct intel_forcewake_range *fw_domains_table;
> - unsigned int fw_domains_table_entries;
> -
> - struct notifier_block pmic_bus_access_nb;
> - struct intel_uncore_funcs funcs;
> -
> - unsigned fifo_count;
> -
> - enum forcewake_domains fw_domains;
> - enum forcewake_domains fw_domains_active;
> -
> - u32 fw_set;
> - u32 fw_clear;
> - u32 fw_reset;
> -
> - struct intel_uncore_forcewake_domain {
> - enum forcewake_domain_id id;
> - enum forcewake_domains mask;
> - unsigned wake_count;
> - struct hrtimer timer;
> - i915_reg_t reg_set;
> - i915_reg_t reg_ack;
> - } fw_domain[FW_DOMAIN_ID_COUNT];
> -
> - int unclaimed_mmio_check;
> -};
> -
> -#define __mask_next_bit(mask) ({ \
> - int __idx = ffs(mask) - 1;  \
> - mask &= ~BIT(__idx);\
> - __idx;  \
> -})
> -
> -/* Iterate over 

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Show dmc debug registers on Kabylake

[Patchwork]

== Series Details ==

Series: drm/i915: Show dmc debug registers on Kabylake
URL   : https://patchwork.freedesktop.org/series/24171/
State : success

== Summary ==

Series 24171v1 drm/i915: Show dmc debug registers on Kabylake
https://patchwork.freedesktop.org/api/1.0/series/24171/revisions/1/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#100652

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:429s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:576s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:543s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:487s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:409s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:480s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:469s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:456s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:577s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:462s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:572s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:457s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:497s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:434s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:524s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:401s
fi-bxt-j4205 failed to collect. IGT log at Patchwork_4646/fi-bxt-j4205/igt.log

f558b185c57202d90bdb9059f3d446956cbae133 drm-tip: 2017y-05m-08d-16h-35m-28s UTC 
integration manifest
c085756 drm/i915: Show dmc debug registers on Kabylake

== Logs ==

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v2,1/2] drm/i915: Move uncore definitions into a separate header (rev2)

[Patchwork]

== Series Details ==

Series: series starting with [v2,1/2] drm/i915: Move uncore definitions into a 
separate header (rev2)
URL   : https://patchwork.freedesktop.org/series/24161/
State : success

== Summary ==

Series 24161v2 Series without cover letter
https://patchwork.freedesktop.org/api/1.0/series/24161/revisions/2/mbox/

Test gem_exec_suspend:
Subgroup basic-s4-devices:
pass   -> DMESG-WARN (fi-kbl-7560u) fdo#100125
Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#100652

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:429s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:578s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:510s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:481s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:480s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:412s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:416s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:473s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:572s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:568s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:454s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:492s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:531s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:401s
fi-bxt-t5700 failed to collect. IGT log at Patchwork_4645/fi-bxt-t5700/igt.log

f558b185c57202d90bdb9059f3d446956cbae133 drm-tip: 2017y-05m-08d-16h-35m-28s UTC 
integration manifest
ca02128 drm/i915: Rename assert_forcewakes_inactive
389c197 drm/i915: Move uncore definitions into a separate header

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

[Chris Wilson]

On Tue, May 09, 2017 at 07:36:09AM +, Michal Wajdeczko wrote:
> All other functions related to uncore start with intel_uncore prefix.
> Follow that pattern.

Debatable. Fwiw, we use the assert_*() pattern frequently because that
"it's a debug only function" is important to make it the first word.
-Chris

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

Re: [Intel-gfx] [i-g-t PATCH 3/4] lib/igt_debugfs: Add helper to return path to device.

[Petri Latvala]

On Thu, Apr 20, 2017 at 11:13:47AM +0300, Abdiel Janulgue wrote:
> Signed-off-by: Abdiel Janulgue 
> ---
>  lib/igt_debugfs.c | 26 ++
>  lib/igt_debugfs.h |  1 +
>  2 files changed, 27 insertions(+)
> 
> diff --git a/lib/igt_debugfs.c b/lib/igt_debugfs.c
> index 7584be5..b019c3b 100644
> --- a/lib/igt_debugfs.c
> +++ b/lib/igt_debugfs.c
> @@ -22,6 +22,9 @@
>   *
>   */
>  
> +#ifndef ANDROID
> +#define _GNU_SOURCE
> +#endif
>  #include 
>  #include 
>  #include 
> @@ -198,6 +201,29 @@ int igt_debugfs_dir(int device)
>   igt_debug("Opening debugfs directory '%s'\n", path);
>   return open(path, O_RDONLY);
>  }
> +\
> +/**
> + * igt_debugfs_path:
> + * @device: fd of the device
> + *
> + * Returns:
> + * The path to the debugfs directory corresponding to device
> + */
> +const char *igt_debugfs_path(int device)
> +{





> + char *path = 0;
> +
> + if (!path) {


??




--
Petri Latvala





> + char *linkname;
> + int debugfs;
> + igt_assert((debugfs = igt_debugfs_dir(device)) != -1);
> + igt_assert(path = calloc(PATH_MAX, sizeof(char)));
> + igt_assert(asprintf(, "/proc/self/fd/%d", debugfs) != 
> -1);
> + igt_assert(readlink(linkname, path, PATH_MAX * sizeof(char)) != 
> -1);
> + }
> +
> + return path;
> +}
>  
>  /**
>   * igt_debugfs_open:
> diff --git a/lib/igt_debugfs.h b/lib/igt_debugfs.h
> index 7b846a8..76cf409 100644
> --- a/lib/igt_debugfs.h
> +++ b/lib/igt_debugfs.h
> @@ -204,5 +204,6 @@ void igt_enable_prefault(void);
>   */
>  int igt_get_stable_obj_count(int driver);
>  void igt_debugfs_dump(int device, const char *filename);
> +const char *igt_debugfs_path(int device);
>  
>  #endif /* __IGT_DEBUGFS_H__ */
> -- 
> 2.7.4
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH i-g-t v3] lib/igt_kms: Force outputs to use full range RGB

[Mika Kahola]

On Tue, 2017-04-18 at 16:04 +0300, Ander Conselvan de Oliveira wrote:
> In at least SKL and GLK (possibly other devices too), using a cursor
> plane to scan out an fb might result in a different pipe crc than
> when
> using a regular plane at the same position with the same fb while
> using
> the CSC logic to limit the color range. The differences could be
> caused
> by the cursor plane being limited to 8 bpc while the regular planes
> support higher bit depths, leading to slightly different values to be
> used internally. This is evidenced by the failures happening with
> specific color values, 0.5 for example, but that's mostly
> speculation.
> 
> To avoid misterious failures caused by limited range rgb, force all
> tests to use full range. It is still possible for tests to override
> this
> if necessary.
By this way, we know for sure what is the color range in use.

Reviewed-by: Mika Kahola 

> 
> v2: Add more details to the commit message.
> v3: Force all tests to use full range.
> Cc: Ville Syrjälä 
> Signed-off-by: Ander Conselvan de Oliveira
> 
> ---
>  lib/igt_kms.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/igt_kms.c b/lib/igt_kms.c
> index 5811414..9f72913 100644
> --- a/lib/igt_kms.c
> +++ b/lib/igt_kms.c
> @@ -1455,10 +1455,15 @@ static void igt_output_refresh(igt_output_t
> *output)
>      -1);
>   }
>  
> - if (output->config.connector)
> + if (output->config.connector) {
>   igt_atomic_fill_connector_props(display, output,
>   IGT_NUM_CONNECTOR_PROPS,
> igt_connector_prop_names);
>  
> + kmstest_set_connector_broadcast_rgb(display->drm_fd,
> + output-
> >config.connector,
> + BROADCAST_RGB_FU
> LL);
> + }
> +
>   if (output->use_override_mode)
>   output->config.default_mode = output->override_mode;
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [i-g-t PATCH 4/4] Convert shell script tests to C version

[Petri Latvala]

On Thu, Apr 20, 2017 at 11:13:48AM +0300, Abdiel Janulgue wrote:
> Converted:
>  - check_drm_clients (ensures no other clients are running.
>functionality provided by drm_open_driver_master).
>  - debugfs_emon_crash
>  - debugfs_wedged
>  - drv_debugfs_reader
>  - sysfs_l3_parity
>  - test_rte_check  (same as check_drm_clients)
>  - tools_test
>  - ZZ_check_dmesg
> 
> Cc: Daniel Vetter 
> Cc: Petri Latvala 
> Signed-off-by: Abdiel Janulgue 
> ---
>  tests/Makefile.sources   |   9 +---
>  tests/ZZ_check_dmesg |  11 -
>  tests/check_drm_clients  |   6 ---
>  tests/debugfs.c  |  75 
>  tests/debugfs_emon_crash |  16 ---
>  tests/debugfs_wedged |  10 -
>  tests/drv_debugfs_reader |   9 
>  tests/sysfs_l3_parity|  22 --
>  tests/test_rte_check |   6 ---
>  tests/tools.c| 111 
> +++
>  tests/tools_test |  16 ---
>  11 files changed, 188 insertions(+), 103 deletions(-)
>  delete mode 100755 tests/ZZ_check_dmesg
>  delete mode 100755 tests/check_drm_clients
>  create mode 100644 tests/debugfs.c
>  delete mode 100755 tests/debugfs_emon_crash
>  delete mode 100755 tests/debugfs_wedged
>  delete mode 100755 tests/drv_debugfs_reader
>  delete mode 100755 tests/sysfs_l3_parity
>  delete mode 100755 tests/test_rte_check
>  create mode 100644 tests/tools.c
>  delete mode 100755 tests/tools_test
> 
> diff --git a/tests/Makefile.sources b/tests/Makefile.sources
> index 7fa9b8f..089428d 100644
> --- a/tests/Makefile.sources
> +++ b/tests/Makefile.sources
> @@ -234,6 +234,8 @@ TESTS_progs = \
>   drv_module_reload \
>   kms_sysfs_edid_timing \
>   perf \
> + debugfs \
> + tools \
>   $(NULL)
>  
>  # IMPORTANT: The ZZ_ tests need to be run last!
> @@ -242,11 +244,6 @@ TESTS_scripts_M = \
>   $(NULL)
>  
>  TESTS_scripts = \
> - debugfs_emon_crash \
> - drv_debugfs_reader \
> - sysfs_l3_parity \
> - test_rte_check \
> - tools_test \
>   $(NULL)
>  
>  # This target contains testcases which support automagic subtest enumeration
> @@ -308,9 +305,7 @@ HANG = \
>   $(NULL)
>  
>  scripts = \
> - check_drm_clients \
>   ddx_intel_after_fbdev \
> - debugfs_wedged \
>   drm_lib.sh \
>   drm_getopt.sh \
>   $(NULL)
> diff --git a/tests/ZZ_check_dmesg b/tests/ZZ_check_dmesg
> deleted file mode 100755
> index e28ba35..000
> --- a/tests/ZZ_check_dmesg
> +++ /dev/null
> @@ -1,11 +0,0 @@
> -#!/bin/sh
> -
> -if dmesg | grep '\*ERROR\*'  > /dev/null ; then
> - echo "DRM_ERROR dirt in dmesg"
> - exit 1
> -fi
> -
> -if dmesg | grep -- '--\[ cut here \]' > /dev/null  ; then
> - echo "found a backtrace in dmesg"
> - exit 1
> -fi
> diff --git a/tests/check_drm_clients b/tests/check_drm_clients
> deleted file mode 100755
> index 2a891b8..000
> --- a/tests/check_drm_clients
> +++ /dev/null
> @@ -1,6 +0,0 @@
> -#!/bin/bash
> -
> -SOURCE_DIR="$( dirname "${BASH_SOURCE[0]}" )"
> -. $SOURCE_DIR/drm_lib.sh
> -
> -exit $IGT_EXIT_SUCCESS
> diff --git a/tests/debugfs.c b/tests/debugfs.c
> new file mode 100644
> index 000..2e2f9bb
> --- /dev/null
> +++ b/tests/debugfs.c
> @@ -0,0 +1,75 @@
> +/*
> + * Copyright © 2017 Intel Corporation
> + *
> + * Permission is hereby granted, free of charge, to any person obtaining a
> + * copy of this software and associated documentation files (the "Software"),
> + * to deal in the Software without restriction, including without limitation
> + * the rights to use, copy, modify, merge, publish, distribute, sublicense,
> + * and/or sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following conditions:
> + *
> + * The above copyright notice and this permission notice (including the next
> + * paragraph) shall be included in all copies or substantial portions of the
> + * Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
> + * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
> + * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
> + * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
> + * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER 
> DEALINGS
> + * IN THE SOFTWARE.
> + */
> +#ifdef HAVE_CONFIG_H
> +#include "config.h"
> +#endif
> +#include "igt.h"
> +
> +igt_main
> +{
> + int fd = -1;
> + igt_skip_on_simulation();
> +
> + igt_fixture {
> + fd = drm_open_driver_master(DRIVER_INTEL);
> + igt_require_gem(fd);
> + }
> +
> + igt_subtest_group {
> + igt_subtest("debugfs_emon_crash") {


These subtest names lead to redundant naming. This one for 

[Intel-gfx] [PATCH v2] drm/i915/gvt: disable GVT-g if host GuC submission is enabled

[Chuanxiao Dong]

Currently GVT-g cannot work properly when host GuC submission
is enabled, so disable GVT in this case.

v2: update the user message (Joonas)

Cc: Zhenyu Wang 
Signed-off-by: Chuanxiao Dong 
---
 drivers/gpu/drm/i915/intel_gvt.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_gvt.c b/drivers/gpu/drm/i915/intel_gvt.c
index e1ab643..d85742c 100644
--- a/drivers/gpu/drm/i915/intel_gvt.c
+++ b/drivers/gpu/drm/i915/intel_gvt.c
@@ -84,6 +84,11 @@ int intel_gvt_init(struct drm_i915_private *dev_priv)
goto bail;
}
 
+   if (i915.enable_guc_submission) {
+   DRM_INFO("GPU guest virtualisation [GVT-g] disabled as Graphics 
virtualization is not yet supported with GuC submission 
[i915.enable_guc_submission module parameter]\n");
+   goto bail;
+   }
+
/*
 * We're not in host or fail to find a MPT module, disable GVT-g
 */
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on Kabylake

[Imre Deak]

On Tue, May 09, 2017 at 01:05:22PM +0300, Mika Kuoppala wrote:
> The assumption is that the registers offsets are
> identical as with skl. Also all the published
> kbl firmwares support the debug registers. So
> let kbl show the debug counts.
> 
> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100975
> Cc: Imre Deak 
> Signed-off-by: Mika Kuoppala 

Reviewed-by: Imre Deak 

> ---
>  drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
> b/drivers/gpu/drm/i915/i915_debugfs.c
> index 1003511..34785fb 100644
> --- a/drivers/gpu/drm/i915/i915_debugfs.c
> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
> @@ -2853,7 +2853,8 @@ 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_priv) && csr->version >= CSR_VERSION(1, 6)) {
> + if (IS_KABYLAKE(dev_priv) ||
> + (IS_SKYLAKE(dev_priv) && 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",
> -- 
> 2.7.4
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Rename assert_forcewakes_inactive

[Michal Wajdeczko]

On Tue, May 09, 2017 at 11:09:58AM +0100, Chris Wilson wrote:
> On Tue, May 09, 2017 at 07:36:09AM +, Michal Wajdeczko wrote:
> > All other functions related to uncore start with intel_uncore prefix.
> > Follow that pattern.
> 
> Debatable. Fwiw, we use the assert_*() pattern frequently because that
> "it's a debug only function" is important to make it the first word.

But most of our assert_*() functions are declared as static, so they don't 
count.
I think in case of public functions, we should follow object/verb pattern.
Note that there is lockdep_assert_held() not assert_lockdep_held().

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

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/gvt: disable GVT-g if host GuC submission is enabled (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915/gvt: disable GVT-g if host GuC submission is enabled (rev2)
URL   : https://patchwork.freedesktop.org/series/23796/
State : success

== Summary ==

Series 23796v2 drm/i915/gvt: disable GVT-g if host GuC submission is enabled
https://patchwork.freedesktop.org/api/1.0/series/23796/revisions/2/mbox/

Test kms_flip:
Subgroup basic-flip-vs-modeset:
dmesg-warn -> PASS   (fi-byt-j1900) fdo#100652

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:431s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:427s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:584s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:509s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:539s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:490s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:487s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:417s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:410s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:407s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:413s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:493s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:457s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:563s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:450s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:571s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:457s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:498s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:429s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:529s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:398s

f558b185c57202d90bdb9059f3d446956cbae133 drm-tip: 2017y-05m-08d-16h-35m-28s UTC 
integration manifest
b8e1220 drm/i915/gvt: disable GVT-g if host GuC submission is enabled

== Logs ==

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

Re: [Intel-gfx] [RFC 4/4] drm/i915: Expose RPCS (SSEU) configuration to userspace

[Lionel Landwerlin]

On 02/05/17 12:49, Chris Wilson wrote:

diff --git a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
index 34ee011f08ac..106d9140d65e 100644
--- a/include/uapi/drm/i915_drm.h
+++ b/include/uapi/drm/i915_drm.h
@@ -1327,6 +1327,17 @@ struct drm_i915_gem_context_param {
  #define   I915_CONTEXT_MAX_USER_PRIORITY  1023 /* inclusive */
  #define   I915_CONTEXT_DEFAULT_PRIORITY   0
  #define   I915_CONTEXT_MIN_USER_PRIORITY  -1023 /* inclusive */
+#define I915_CONTEXT_PARAM_SSEU0x7
+   __u64 value;
+};
+
+union drm_i915_gem_context_param_sseu {
+   struct {
+   u8 slice_mask;
+   u8 subslice_mask;
+   u8 min_eu_per_subslice;
+   u8 max_eu_per_subslice;
+   } packed;
__u64 value;
  };
  
Would it make sense to expose this as a query through 
DRM_IOCTL_I915_GETPARAM as well?

So the userspace could get the max values rather than just the last setup.

Cheers,

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

[Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on Kabylake

[Mika Kuoppala]

The assumption is that the registers offsets are
identical as with skl. Also all the published
kbl firmwares support the debug registers. So
let kbl show the debug counts.

Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100975
Cc: Imre Deak 
Signed-off-by: Mika Kuoppala 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1003511..34785fb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -2853,7 +2853,8 @@ 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_priv) && csr->version >= CSR_VERSION(1, 6)) {
+   if (IS_KABYLAKE(dev_priv) ||
+   (IS_SKYLAKE(dev_priv) && 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",
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 8/8] drm: Remove redundant NULL check during atomic plane commit

[Ville Syrjälä]

On Wed, Apr 26, 2017 at 06:44:53PM +0300, Ville Syrjälä wrote:
> On Wed, Apr 26, 2017 at 04:40:13PM +0300, Imre Deak wrote:
> > plane_state can't be NULL anywhere in this function, so the NULL check
> > at the end is redundant, remove it.
> > 
> > Cc: dri-de...@lists.freedesktop.org
> > Signed-off-by: Imre Deak 
> > ---
> >  drivers/gpu/drm/drm_plane_helper.c | 10 --
> >  1 file changed, 4 insertions(+), 6 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/drm_plane_helper.c 
> > b/drivers/gpu/drm/drm_plane_helper.c
> > index 9854a50..2c27f6f 100644
> > --- a/drivers/gpu/drm/drm_plane_helper.c
> > +++ b/drivers/gpu/drm/drm_plane_helper.c
> > @@ -511,12 +511,10 @@ int drm_plane_helper_commit(struct drm_plane *plane,
> > if (plane_funcs->cleanup_fb)
> > plane_funcs->cleanup_fb(plane, plane_state);
> >  out:
> > -   if (plane_state) {
> > -   if (plane->funcs->atomic_destroy_state)
> > -   plane->funcs->atomic_destroy_state(plane, plane_state);
> > -   else
> > -   drm_atomic_helper_plane_destroy_state(plane, 
> > plane_state);
> > -   }
> > +   if (plane->funcs->atomic_destroy_state)
> > +   plane->funcs->atomic_destroy_state(plane, plane_state);
> > +   else
> > +   drm_atomic_helper_plane_destroy_state(plane, plane_state);
> 
> Hmm. If plane->state was NULL, then we could swap that with plane_state,
> and thus plane_state could become NULL. But that would actually oops in
> drm_atomic_plane_disabling() already, so yeah, no way this could work.
> 
> My only concern is the buggy drm_atomic_helper_plane_reset() which can't
> fail gracefully if the kmalloc fails. But failure that would probably
> lead to explosions all over anyway.
> 
> Reviewed-by: Ville Syrjälä 

I pushed this one to drm-misc-next. Thanks for the patch.

> 
> 
> >  
> > return ret;
> >  }
> > -- 
> > 2.5.0
> > 
> > ___
> > Intel-gfx mailing list
> > Intel-gfx@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/intel-gfx
> 
> -- 
> Ville Syrjälä
> Intel OTC
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

Re: [Intel-gfx] [i-g-t PATCH 1/4] lib/igt_core: Add igt_exec helpers

[Petri Latvala]

On Thu, Apr 20, 2017 at 11:13:45AM +0300, Abdiel Janulgue wrote:
> Support executing external processes with the goal of capturing its
> standard streams to the igt logging infrastructure in addition to its
> exit status.
> 
> Cc: Daniel Vetter 
> Cc: Petri Latvala 
> Signed-off-by: Abdiel Janulgue 
> ---
>  lib/igt_core.c | 151 
> +
>  lib/igt_core.h |   3 ++
>  2 files changed, 154 insertions(+)
> 
> diff --git a/lib/igt_core.c b/lib/igt_core.c
> index 403b942..8a7ba0d 100644
> --- a/lib/igt_core.c
> +++ b/lib/igt_core.c
> @@ -2073,3 +2073,154 @@ FILE *__igt_fopen_data(const char* igt_srcdir, const 
> char* igt_datadir,
>  
>   return fp;
>  }
> +
> +struct output_pipe {
> + int output_fd;
> + int save_fd;
> + int read_fd;
> + int write_fd;
> + bool redirected;
> + enum igt_log_level log_level;
> +};
> +
> +static bool redirect_output(struct output_pipe *p, int output_fd,
> + enum igt_log_level level)
> +{
> + int fds[2], flags;
> +
> + if (pipe(fds) == -1)
> + return false;


If this succeeds


> +
> + if ((flags = fcntl(fds[0], F_GETFL) == -1))
> + return false;
> +
> + flags |= O_NONBLOCK;
> + if (fcntl(fds[0], F_SETFL, flags) == -1)
> + return false;
> +
> + /* save output */
> + if ((p->save_fd = dup(output_fd)) == -1)
> + return false;
> +
> + /* Redirect output to our buffer */
> + if (dup2(fds[1], output_fd) == -1)
> + return false;

 and these don't, the pipe fds are never closed.

Same for the save_fd if the dup2 fails, if the caller of this function
doesn't call unredirect_output, as the return value might direct it.


> +
> + p->output_fd = output_fd;
> + p->read_fd = fds[0];
> + p->write_fd = fds[1];
> + p->redirected = true;
> + p->log_level = level;
> +
> + return true;
> +}
> +
> +static bool unredirect_output(struct output_pipe *p)
> +{
> + close(p->write_fd);
> + if (dup2(p->save_fd, p->output_fd) == -1)
> + return false;
> + close(p->save_fd);
> +
> + p->redirected = false;
> +
> + return true;
> +}
> +
> +/**
> + * igt_exec:
> + *
> + * Executes the shell command specified in @command and capture its stdout 
> and
> + * stderr to igt_log or igt_warn respectively.
> + *
> + * Returns: The exit status of the executed process. -1 for failure.
> + */
> +int igt_exec(const char *command)
> +{
> +#define OUT 0
> +#define ERR 1
> + struct output_pipe op[2];
> + int i, sel_fd, status;
> + fd_set fds;
> + struct timeval timeout = { .tv_sec = 0, .tv_usec = 0 };
> + char buf[PIPE_BUF];
> +
> + if (!redirect_output([OUT], STDOUT_FILENO, IGT_LOG_INFO))
> + return -1;
> + if (!redirect_output([ERR], STDERR_FILENO, IGT_LOG_WARN))
> + return -1;


If redirect_output for stderr returns false, unredirect_output for
stdout will not get called.

> +
> + if ((status = system(command)) == -1)
> + return -1;
> +
> + FD_ZERO();
> + FD_SET(op[OUT].read_fd, );
> + FD_SET(op[ERR].read_fd, );
> +
> + sel_fd = max(op[OUT].read_fd, op[ERR].read_fd);
> + if (select(sel_fd + 1, , NULL, NULL, ) == -1)
> + return -1;
> +
> + for (i = 0; i < ARRAY_SIZE(op); i++) {
> + struct output_pipe *current = [i];
> +
> + if (!FD_ISSET(current->read_fd, )) {
> + close(current->read_fd);
> + if (!unredirect_output(current))
> + return -1;
> + continue;
> + }
> +
> + memset(buf, 0, sizeof(buf));
> + while (read(current->read_fd, buf, sizeof(buf)) > 0) {
> + if (current->redirected) {
> + if (!unredirect_output(current))
> + return -1;
> + }
> + igt_log(IGT_LOG_DOMAIN, current->log_level,
> + "[cmd] %s", buf);
> + memset(buf, 0, sizeof(buf));
> + }
> + close(current->read_fd);
> + }


Unredirect_output calls for both pipes need to be called on all exit
paths.

In redirect_output you set only the read fd of the pipe() pair to
O_NONBLOCK. That will make the executed command block on its writes
indefinitely if it prints more than whatsitnow, 64kB?



> +
> + return WEXITSTATUS(status);
> +}
> +
> +/**
> + * igt_exec_quiet:
> + * Similar to igt_exec(), except redirect output to /dev/null
> + *
> + * Returns: The exit status of the executed process. -1 for failure.
> + */
> +int igt_exec_quiet(const char *command)
> +{
> + int stderr_fd_copy, stdout_fd_copy, status, nullfd;
> +
> + /* redirect */
> + if ((nullfd = open("/dev/null", 

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

[Sharma, Shashank]

Regards

Shashank


On 5/9/2017 8:58 PM, Ville Syrjälä wrote:

On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/8/2017 10:39 PM, Ville Syrjälä wrote:

On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote:

Regards

Shashank


On 5/8/2017 9:54 PM, Ville Syrjälä wrote:

On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:

From: Jose Abreu 

HDMI 2.0 spec adds support for ycbcr420 subsampled output.
CEA-861-F adds two new blocks in EDID, to provide information about
sink's support for ycbcr420 output.

These new blocks are:
- ycbcr420 video data (vdb) block: video modes which can be supported
 only in ycbcr420 output mode.
- ycbcr420 video capability data (vcb) block: video modes which can be
 support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 etc)

This patch adds parsing and handling of ycbcr420-vdb in the DRM
layer.

This patch is a modified version of Jose's RFC patch:
https://patchwork.kernel.org/patch/9492327/
so the authorship is maintained.

Cc: Ville Syrjala 
Signed-off-by: Jose Abreu 
Signed-off-by: Shashank Sharma 
---
drivers/gpu/drm/drm_edid.c  | 54 
+++--
drivers/gpu/drm/drm_modes.c | 10 +++--
include/drm/drm_connector.h |  1 +
include/uapi/drm/drm_mode.h |  6 +
4 files changed, 67 insertions(+), 4 deletions(-)



diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index 4eeda12..cef76b2 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -199,6 +199,7 @@ struct drm_display_info {
#define DRM_COLOR_FORMAT_RGB444 (1<<0)
#define DRM_COLOR_FORMAT_YCRCB444   (1<<1)
#define DRM_COLOR_FORMAT_YCRCB422   (1<<2)
+#define DRM_COLOR_FORMAT_YCRCB420  (1<<2)

	/**

 * @color_formats: HDMI Color formats, selects between RGB and YCrCb
diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index 8c67fc0..1e74d8e 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -84,6 +84,12 @@ extern "C" {
#define  DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH (6<<14)
#define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM(7<<14)
#define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF (8<<14)
+/*
+ * HDMI 2.0
+ */
+#define DRM_MODE_FLAG_420_MASK (0x03<<23)
+#define  DRM_MODE_FLAG_420 (1<<23)
+#define  DRM_MODE_FLAG_420_ONLY(1<<24)

Adding those would again break the uabi. We can't add new mode flags
without some kind of client cap.
But I think we agreed that new user
space visible mode flags aren't needed, and instad we can keep it all
internal?

Yep you are right, we had decided to keep it internal, and this whole
patch series is implemented in such a way only, to control everything
through the HDMI output property itself.
But may be I slightly misunderstood that we shouldn't add the flags bits
all together, and I added this flag to differentiate between YCBCR420
and notmal modes.
Can you please suggest me on:
- how to differentiate a YCBCR420 mode with normal mode ? I still need
to add a flag, but not expose it into uapi layer.

I guess we can just tack on a few new bools to the end of
drm_display_mode. And then when we get the mode passed in by the user
we'll have to check whether that mode matches any CEA mode and
then look up the correct YCbCr 4:2:0 mode for it.

seems good to me, I can add a is_ycbcr420 flag, and we need not to
bother about converting it to drm_mode_modeinfo as we are keeping it
internal.

Hmm. Actually, that probably means that it isn't sufficient to
actually store this information on the modes we have on the connector's
mode list, because that list has been filtered and so may not actually
have all the modes that were declared in the EDID.

I dint get this point,  Why do you think its not sufficient ? Do we need
to care about the modes which are getting rejected from the driver ?

Yes, that was my worry. In general I don't think connector->modes should
ever be used for mode validation or state computation. Eg. if fbdev
handled the previus hotplug connector->modes will have been filtered
based on the size of the fb_helper framebuffer, and then a new master
might just blindly come in and blindly set a new mode without doing a
full connector probe.
Its very valid point when it comes to resolution, but do you think fbdev 
will reject based on the flags (YCBCR420_only/also) .
I mean if I add YCBCR420 info as bools (like in your previous 
suggestion), would that alter fbdev selection ?
Nevertheless, a YCBCR420 bitmap seems to be a good idea already, just as 
soon as we can map it clearly with the hdmi_output property.

I guess they cant be applied anyways.  Do you think we will miss some of
the YCBCR modes due to mode filtering ?

So I'm thinking we
should perhaps make 

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Pandiyan, Dhinakaran]

On Tue, 2017-05-09 at 16:39 -0700, Puthikorn Voravootivat wrote:
> > How is backlight enabled in this case?
> Using eDP BL_ENABLE pin


Sure, but I am not seeing how this falls back to one of the
[bxt,lpt]_enable_backlight() functions in intel_panel.c. Apologies if I
am missing something very obvious.

If intel_dp_aux_init_backlight_funcs() returned -ENODEV, then one of the
platform specific PWM enable callbacks would be called. But in this
case, dp_aux_enable_backlight() just returns without doing anything.


-DK
> 
> 
> On Sat, May 6, 2017 at 1:59 AM, Pandiyan, Dhinakaran
>  wrote:
> On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat
> wrote:
> > There are some panel that
> > (1) does not support display backlight enable via AUX
> > (2) support display backlight adjustment via AUX
> > (3) support display backlight enable via eDP BL_ENABLE pin
> >
> > The current driver required that (1) must be support to
> enable (2).
> > This patch drops that requirement.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index ad8560c5f689..5b83c9737644 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -28,6 +28,10 @@ static void
> set_aux_backlight_enable(struct intel_dp *intel_dp, bool
> enable)
> >  {
> >   uint8_t reg_val = 0;
> >
> > +   /* Early return when display use other mechanism to
> enable backlight. */
> > + if (!(intel_dp->edp_dpcd[1] &
> DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> > + return;
> > +
> 
> How is backlight enabled in this case?
> 
> -DK
> 
> >   if (drm_dp_dpcd_readb(_dp->aux,
> DP_EDP_DISPLAY_CONTROL_REGISTER,
> > _val) < 0) {
> >   DRM_DEBUG_KMS("Failed to read DPCD register 0x
> %x\n",
> > @@ -164,7 +168,6 @@
> intel_dp_aux_display_control_capable(struct intel_connector
> *connector)
> >* the panel can support backlight control over the
> aux channel
> >*/
> >   if ((intel_dp->edp_dpcd[1] &
> DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
> > - (intel_dp->edp_dpcd[1] &
> DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >   (intel_dp->edp_dpcd[2] &
> DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
> >   DRM_DEBUG_KMS("AUX Backlight Control
> Supported!\n");
> >   return true;
> 
> 
> 
> 
> ___
> Intel-gfx mailing list
> Intel-gfx@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/intel-gfx

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

[Intel-gfx] [PATCH v4 2/3] drm/i915/guc: Make scratch register base and count flexible

[Michal Wajdeczko]

We are using some scratch registers in MMIO based send function.
Make their base and count flexible in preparation of upcoming
GuC firmware/hardware changes. While around, change cmd len
parameter verification from WARN_ON to GEM_BUG_ON as we don't
need this all the time.

v2: call out WARN/GEM_BUG change in the commit msg (Daniele)
v3: don't overqualify the ints (Chris)
v4: rebase and use proper enum

Signed-off-by: Michal Wajdeczko 
Suggested-by: Daniele Ceraolo Spurio 
Cc: Daniele Ceraolo Spurio 
Cc: Joonas Lahtinen 
Cc: Chris Wilson 
Cc: Jani Nikula 
Reviewed-by: Daniele Ceraolo Spurio 
---
 drivers/gpu/drm/i915/intel_uc.c | 41 ++---
 drivers/gpu/drm/i915/intel_uc.h |  7 +++
 2 files changed, 41 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_uc.c b/drivers/gpu/drm/i915/intel_uc.c
index 72f49e6..07c5658 100644
--- a/drivers/gpu/drm/i915/intel_uc.c
+++ b/drivers/gpu/drm/i915/intel_uc.c
@@ -260,9 +260,36 @@ void intel_uc_fini_fw(struct drm_i915_private *dev_priv)
__intel_uc_fw_fini(_priv->huc.fw);
 }
 
+static inline i915_reg_t guc_send_reg(struct intel_guc *guc, u32 i)
+{
+   GEM_BUG_ON(!guc->send_regs.base);
+   GEM_BUG_ON(!guc->send_regs.count);
+   GEM_BUG_ON(i >= guc->send_regs.count);
+
+   return _MMIO(guc->send_regs.base + 4 * i);
+}
+
+static void guc_init_send_regs(struct intel_guc *guc)
+{
+   struct drm_i915_private *dev_priv = guc_to_i915(guc);
+   enum forcewake_domains fw_domains = 0;
+   unsigned int i;
+
+   guc->send_regs.base = i915_mmio_reg_offset(SOFT_SCRATCH(0));
+   guc->send_regs.count = SOFT_SCRATCH_COUNT - 1;
+
+   for (i = 0; i < guc->send_regs.count; i++) {
+   fw_domains |= intel_uncore_forcewake_for_reg(dev_priv,
+   guc_send_reg(guc, i),
+   FW_REG_READ | FW_REG_WRITE);
+   }
+   guc->send_regs.fw_domains = fw_domains;
+}
+
 static int guc_enable_communication(struct intel_guc *guc)
 {
/* XXX: placeholder for alternate setup */
+   guc_init_send_regs(guc);
guc->send = intel_guc_send_mmio;
return 0;
 }
@@ -407,19 +434,19 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
int i;
int ret;
 
-   if (WARN_ON(len < 1 || len > 15))
-   return -EINVAL;
+   GEM_BUG_ON(!len);
+   GEM_BUG_ON(len > guc->send_regs.count);
 
mutex_lock(>send_mutex);
-   intel_uncore_forcewake_get(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_get(dev_priv, guc->send_regs.fw_domains);
 
dev_priv->guc.action_count += 1;
dev_priv->guc.action_cmd = action[0];
 
for (i = 0; i < len; i++)
-   I915_WRITE(SOFT_SCRATCH(i), action[i]);
+   I915_WRITE(guc_send_reg(guc, i), action[i]);
 
-   POSTING_READ(SOFT_SCRATCH(i - 1));
+   POSTING_READ(guc_send_reg(guc, i - 1));
 
intel_guc_notify(guc);
 
@@ -428,7 +455,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
 * Fast commands should still complete in 10us.
 */
ret = __intel_wait_for_register_fw(dev_priv,
-  SOFT_SCRATCH(0),
+  guc_send_reg(guc, 0),
   INTEL_GUC_RECV_MASK,
   INTEL_GUC_RECV_MASK,
   10, 10, );
@@ -450,7 +477,7 @@ int intel_guc_send_mmio(struct intel_guc *guc, const u32 
*action, u32 len)
}
dev_priv->guc.action_status = status;
 
-   intel_uncore_forcewake_put(dev_priv, FORCEWAKE_BLITTER);
+   intel_uncore_forcewake_put(dev_priv, guc->send_regs.fw_domains);
mutex_unlock(>send_mutex);
 
return ret;
diff --git a/drivers/gpu/drm/i915/intel_uc.h b/drivers/gpu/drm/i915/intel_uc.h
index 097289b..53a3388 100644
--- a/drivers/gpu/drm/i915/intel_uc.h
+++ b/drivers/gpu/drm/i915/intel_uc.h
@@ -205,6 +205,13 @@ struct intel_guc {
uint64_t submissions[I915_NUM_ENGINES];
uint32_t last_seqno[I915_NUM_ENGINES];
 
+   /* GuC's FW specific registers used in MMIO send */
+   struct {
+   u32 base;
+   unsigned int count;
+   enum forcewake_domains fw_domains;
+   } send_regs;
+
/* To serialize the intel_guc_send actions */
struct mutex send_mutex;
 
-- 
2.7.4

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

Re: [Intel-gfx] vlv_disable_backlight causing warnings with i915 @ Xorg start

[Ville Syrjälä]

On Mon, May 08, 2017 at 09:27:36AM -0400, Andrew Siplas wrote:
> At Xorg startup after a fresh compile of the mainline kernel, WARN_ON is
> truthy and throws a warning into the kernel's dmesg buffer.
> 
> I'm still trying to understand the driver, but it originates here:
> 
> --
> 
> static void vlv_disable_backlight(struct intel_connector *connector)
> {
> struct drm_i915_private *dev_priv =
> to_i915(connector->base.dev);
> enum pipe pipe = intel_get_pipe_from_connector(connector);

Not sure why that's not working anymore. Did we stop updating the legacy
connector<->crtc linkage or something?

Anyway we would need to eliminate that guy and instead pass down the
correct atomic state from higher up. Maarten, did you have patches
for that already?

> u32 tmp;
> 
> if (WARN_ON(pipe != PIPE_A && pipe != PIPE_B))
> return;
> 
> intel_panel_actually_set_backlight(connector, 0);
> 
> tmp = I915_READ(VLV_BLC_PWM_CTL2(pipe));
> I915_WRITE(VLV_BLC_PWM_CTL2(pipe), tmp & ~BLM_PWM_ENABLE);
> }
> 
> --
> 
> Don't know yet what this means and so taking a chance this warning is
> something someone here might have some insight into / want to know about
> especially given the "...[ cut here ]...".
> 
> The last two lines are from 5+ minutes after the warning but seem related:
> 
> 
> [   67.896233] [ cut here ]
> [   67.896259] WARNING: CPU: 1 PID: 4276 at 
> drivers/gpu/drm/i915/intel_panel.c:771 vlv_disable_backlight+0x86/0x90
> [   67.896261] Modules linked in: iptable_nat nf_nat_ipv4 nf_nat uvcvideo 
> videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
> [   67.896299] CPU: 1 PID: 4276 Comm: Xorg Not tainted 4.11.0+ #2
> [   67.896303] Hardware name: HP HP Notebook/80C5, BIOS F.1E 12/25/2015
> [   67.896308] task: 8d6e75d79800 task.stack: 9a06c1218000
> [   67.896318] RIP: 0010:vlv_disable_backlight+0x86/0x90
> [   67.896323] RSP: 0018:9a06c121b998 EFLAGS: 00010286
> [   67.896330] RAX: 0029 RBX: 8d6e76018000 RCX: 
> 8ea56a78
> [   67.896335] RDX: 0001 RSI: 0092 RDI: 
> 8ece6bcc
> [   67.896339] RBP: 9a06c121b9b0 R08: 0029 R09: 
> 02d8
> [   67.896344] R10:  R11: 0320 R12: 
> 8d6e723c5000
> [   67.896348] R13:  R14: 8d6e7423e800 R15: 
> 8d6e74ab9830
> [   67.896355] FS:  7fb8d7e00a40() GS:8d6e7fc8() 
> knlGS:
> [   67.896359] CS:  0010 DS:  ES:  CR0: 80050033
> [   67.896364] CR2: 557bfe77dfd0 CR3: 000274d31000 CR4: 
> 001006e0
> [   67.896368] Call Trace:
> [   67.896383]  intel_panel_disable_backlight+0x51/0x80
> [   67.896391]  intel_edp_backlight_off+0x42/0x50
> [   67.896397]  intel_disable_dp+0x70/0xf0
> [   67.896407]  intel_encoders_disable.isra.103+0x82/0x90
> [   67.896416]  i9xx_crtc_disable+0x51/0x3b0
> [   67.896424]  ? intel_crtc_disable_planes+0xd4/0xf0
> [   67.896434]  intel_atomic_commit_tail+0x892/0xfb0
> [   67.896444]  ? insert_work+0x52/0x70
> [   67.896453]  ? __queue_work+0x12e/0x390
> [   67.896461]  ? intel_atomic_commit_ready+0x70/0x80
> [   67.896470]  intel_atomic_commit+0x3e6/0x4b0
> [   67.896479]  ? handle_conflicting_encoders+0x279/0x290
> [   67.896489]  drm_atomic_commit+0x46/0x50
> [   67.896497]  drm_atomic_helper_set_config+0x6b/0xa0
> [   67.896507]  __drm_mode_set_config_internal+0x62/0x110
> [   67.896514]  drm_mode_setcrtc+0x4ba/0x5a0
> [   67.896524]  drm_ioctl+0x326/0x430
> [   67.896532]  ? drm_mode_getcrtc+0x170/0x170
> [   67.896543]  do_vfs_ioctl+0x8f/0x5a0
> [   67.896552]  ? getnstimeofday64+0x9/0x20
> [   67.896561]  SyS_ioctl+0x74/0x80
> [   67.896569]  do_syscall_64+0x48/0xb0
> [   67.896580]  entry_SYSCALL64_slow_path+0x25/0x25
> [   67.896586] RIP: 0033:0x7fb8d5932507
> [   67.896590] RSP: 002b:7ffe8bf43018 EFLAGS: 3246 ORIG_RAX: 
> 0010
> [   67.896598] RAX: ffda RBX: 561b92c11210 RCX: 
> 7fb8d5932507
> [   67.896602] RDX: 7ffe8bf43140 RSI: c06864a2 RDI: 
> 0009
> [   67.896607] RBP: 7ffe8bf43140 R08: 561b92c11050 R09: 
> 0001
> [   67.896611] R10: 0001 R11: 3246 R12: 
> c06864a2
> [   67.896615] R13: 0009 R14: 561b92c13f70 R15: 
> 7fb8d7d67000
> [   67.896620] Code: df 41 8d b4 05 50 12 06 00 ff 93 f8 06 00 00 5b 41 5c 41 
> 5d 5d c3 48 c7 c6 18 bc 88 8e 48 c7 c7 22 e8 82 8e 31 c0 e8 47 70 b6 ff <0f> 
> ff eb e0 66 0f 1f 44 00 00 55 8b b7 f4 03 00 00 48 89 e5 e8 
> [   67.896771] ---[ end trace 528f42628325fc1b ]---
> [  490.370803] [drm] Atomic update on pipe (A) took 102 us, max time under 
> evasion is 100 us
> [ 2623.216311] [drm] Atomic update on pipe (A) took 415 us, max time under 
> evasion is 100 us
> 



> ___
> Intel-gfx mailing list

[Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

[Madhav Chauhan]

As per BSEPC, if device ready bit is '0' in enable IO sequence
then its a cold boot/reset scenario eg: S3/S4 resume. In these
conditions we need to program certain registers and prepare port
from the middle of DSI enable sequence otherwise feature like S3/S4
doesn't work.

Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi.c | 79 
 1 file changed, 48 insertions(+), 31 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi.c b/drivers/gpu/drm/i915/intel_dsi.c
index fc0ef49..6b68864 100644
--- a/drivers/gpu/drm/i915/intel_dsi.c
+++ b/drivers/gpu/drm/i915/intel_dsi.c
@@ -346,12 +346,17 @@ static bool intel_dsi_compute_config(struct intel_encoder 
*encoder,
return true;
 }
 
-static void glk_dsi_device_ready(struct intel_encoder *encoder)
+static void intel_dsi_prepare(struct intel_encoder *intel_encoder,
+ struct intel_crtc_state *pipe_config);
+
+static void glk_dsi_device_ready(struct intel_encoder *encoder,
+struct intel_crtc_state *pipe_config)
 {
struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
enum port port;
u32 tmp, val;
+   bool cold_boot = false;
 
/* Set the MIPI mode
 * If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
@@ -370,7 +375,10 @@ static void glk_dsi_device_ready(struct intel_encoder 
*encoder)
/* Program LP Wake */
for_each_dsi_port(port, intel_dsi->ports) {
tmp = I915_READ(MIPI_CTRL(port));
-   tmp |= GLK_LP_WAKE;
+   if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
+   tmp &= ~GLK_LP_WAKE;
+   else
+   tmp |= GLK_LP_WAKE;
I915_WRITE(MIPI_CTRL(port), tmp);
}
 
@@ -382,6 +390,15 @@ static void glk_dsi_device_ready(struct intel_encoder 
*encoder)
DRM_ERROR("MIPIO port is powergated\n");
}
 
+   /* Check if cold boot scenario */
+   for_each_dsi_port(port, intel_dsi->ports) {
+   cold_boot |= !(I915_READ(MIPI_DEVICE_READY(port)) &
+   DEVICE_READY);
+   }
+
+   if (cold_boot)
+   intel_dsi_prepare(encoder, pipe_config);
+
/* Wait for MIPI PHY status bit to set */
for_each_dsi_port(port, intel_dsi->ports) {
if (intel_wait_for_register(dev_priv,
@@ -402,34 +419,34 @@ static void glk_dsi_device_ready(struct intel_encoder 
*encoder)
val |= DEVICE_READY;
I915_WRITE(MIPI_DEVICE_READY(port), val);
usleep_range(10, 15);
-   }
-
-   /* Enter ULPS */
-   val = I915_READ(MIPI_DEVICE_READY(port));
-   val &= ~ULPS_STATE_MASK;
-   val |= (ULPS_STATE_ENTER | DEVICE_READY);
-   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   } else {
+   /* Enter ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_ENTER | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
 
-   /* Wait for ULPS active */
-   if (intel_wait_for_register(dev_priv,
+   /* Wait for ULPS active */
+   if (intel_wait_for_register(dev_priv,
MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0, 20))
-   DRM_ERROR("ULPS not active\n");
+   DRM_ERROR("ULPS not active\n");
 
-   /* Exit ULPS */
-   val = I915_READ(MIPI_DEVICE_READY(port));
-   val &= ~ULPS_STATE_MASK;
-   val |= (ULPS_STATE_EXIT | DEVICE_READY);
-   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   /* Exit ULPS */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_EXIT | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
 
-   /* Enter Normal Mode */
-   val = I915_READ(MIPI_DEVICE_READY(port));
-   val &= ~ULPS_STATE_MASK;
-   val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
-   I915_WRITE(MIPI_DEVICE_READY(port), val);
+   /* Enter Normal Mode */
+   val = I915_READ(MIPI_DEVICE_READY(port));
+   val &= ~ULPS_STATE_MASK;
+   val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
+   I915_WRITE(MIPI_DEVICE_READY(port), val);
 
-   tmp = I915_READ(MIPI_CTRL(port));
-   

[Intel-gfx] [PATCH 1/2] drm/i915/glk: Calculate high/low switch count for GLK

[Madhav Chauhan]

As per BSPEC, high/low switch count to be programmed in
terms of byteclock using exit_zero_count and prep_count.
For Geminilake exit/prep counts are already calculated
in terms of byteclock. This patch calculates high/low
switch count using counts value in byteclock, old calculation
leads to screen flicker/shift issue while resuming from S3/S4.

Signed-off-by: Madhav Chauhan 
---
 drivers/gpu/drm/i915/intel_dsi_vbt.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_vbt.c
index 0dce779..7158c7c 100644
--- a/drivers/gpu/drm/i915/intel_dsi_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_vbt.c
@@ -694,8 +694,8 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
clk_zero_cnt << 8 | prepare_cnt;
 
/*
-* LP to HS switch count = 4TLPX + PREP_COUNT * 2 + EXIT_ZERO_COUNT * 2
-*  + 10UI + Extra Byte Count
+* LP to HS switch count = 4TLPX + PREP_COUNT * mul + EXIT_ZERO_COUNT *
+*  mul + 10UI + Extra Byte Count
 *
 * HS to LP switch count = THS-TRAIL + 2TLPX + Extra Byte Count
 * Extra Byte Count is calculated according to number of lanes.
@@ -708,8 +708,8 @@ bool intel_dsi_vbt_init(struct intel_dsi *intel_dsi, u16 
panel_id)
/* B044 */
/* FIXME:
 * The comment above does not match with the code */
-   lp_to_hs_switch = DIV_ROUND_UP(4 * tlpx_ui + prepare_cnt * 2 +
-   exit_zero_cnt * 2 + 10, 8);
+   lp_to_hs_switch = DIV_ROUND_UP(4 * tlpx_ui + prepare_cnt * mul +
+   exit_zero_cnt * mul + 10, 8);
 
hs_to_lp_switch = DIV_ROUND_UP(mipi_config->ths_trail + 2 * tlpx_ui, 8);
 
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

[Ville Syrjälä]

On Tue, May 09, 2017 at 06:59:25PM +0530, Madhav Chauhan wrote:
> As per BSEPC, if device ready bit is '0' in enable IO sequence
> then its a cold boot/reset scenario eg: S3/S4 resume. In these
> conditions we need to program certain registers and prepare port
> from the middle of DSI enable sequence otherwise feature like S3/S4
> doesn't work.

Can't we just always follow the "cold boot" sequence? Less codepaths
means less bugs.

> 
> Signed-off-by: Madhav Chauhan 
> ---
>  drivers/gpu/drm/i915/intel_dsi.c | 79 
> 
>  1 file changed, 48 insertions(+), 31 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_dsi.c 
> b/drivers/gpu/drm/i915/intel_dsi.c
> index fc0ef49..6b68864 100644
> --- a/drivers/gpu/drm/i915/intel_dsi.c
> +++ b/drivers/gpu/drm/i915/intel_dsi.c
> @@ -346,12 +346,17 @@ static bool intel_dsi_compute_config(struct 
> intel_encoder *encoder,
>   return true;
>  }
>  
> -static void glk_dsi_device_ready(struct intel_encoder *encoder)
> +static void intel_dsi_prepare(struct intel_encoder *intel_encoder,
> +   struct intel_crtc_state *pipe_config);
> +
> +static void glk_dsi_device_ready(struct intel_encoder *encoder,
> +  struct intel_crtc_state *pipe_config)
>  {
>   struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
>   struct intel_dsi *intel_dsi = enc_to_intel_dsi(>base);
>   enum port port;
>   u32 tmp, val;
> + bool cold_boot = false;
>  
>   /* Set the MIPI mode
>* If MIPI_Mode is off, then writing to LP_Wake bit is not reflecting.
> @@ -370,7 +375,10 @@ static void glk_dsi_device_ready(struct intel_encoder 
> *encoder)
>   /* Program LP Wake */
>   for_each_dsi_port(port, intel_dsi->ports) {
>   tmp = I915_READ(MIPI_CTRL(port));
> - tmp |= GLK_LP_WAKE;
> + if (!(I915_READ(MIPI_DEVICE_READY(port)) & DEVICE_READY))
> + tmp &= ~GLK_LP_WAKE;
> + else
> + tmp |= GLK_LP_WAKE;
>   I915_WRITE(MIPI_CTRL(port), tmp);
>   }
>  
> @@ -382,6 +390,15 @@ static void glk_dsi_device_ready(struct intel_encoder 
> *encoder)
>   DRM_ERROR("MIPIO port is powergated\n");
>   }
>  
> + /* Check if cold boot scenario */
> + for_each_dsi_port(port, intel_dsi->ports) {
> + cold_boot |= !(I915_READ(MIPI_DEVICE_READY(port)) &
> + DEVICE_READY);
> + }
> +
> + if (cold_boot)
> + intel_dsi_prepare(encoder, pipe_config);
> +
>   /* Wait for MIPI PHY status bit to set */
>   for_each_dsi_port(port, intel_dsi->ports) {
>   if (intel_wait_for_register(dev_priv,
> @@ -402,34 +419,34 @@ static void glk_dsi_device_ready(struct intel_encoder 
> *encoder)
>   val |= DEVICE_READY;
>   I915_WRITE(MIPI_DEVICE_READY(port), val);
>   usleep_range(10, 15);
> - }
> -
> - /* Enter ULPS */
> - val = I915_READ(MIPI_DEVICE_READY(port));
> - val &= ~ULPS_STATE_MASK;
> - val |= (ULPS_STATE_ENTER | DEVICE_READY);
> - I915_WRITE(MIPI_DEVICE_READY(port), val);
> + } else {
> + /* Enter ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_ENTER | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
>  
> - /* Wait for ULPS active */
> - if (intel_wait_for_register(dev_priv,
> + /* Wait for ULPS active */
> + if (intel_wait_for_register(dev_priv,
>   MIPI_CTRL(port), GLK_ULPS_NOT_ACTIVE, 0, 20))
> - DRM_ERROR("ULPS not active\n");
> + DRM_ERROR("ULPS not active\n");
>  
> - /* Exit ULPS */
> - val = I915_READ(MIPI_DEVICE_READY(port));
> - val &= ~ULPS_STATE_MASK;
> - val |= (ULPS_STATE_EXIT | DEVICE_READY);
> - I915_WRITE(MIPI_DEVICE_READY(port), val);
> + /* Exit ULPS */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + val &= ~ULPS_STATE_MASK;
> + val |= (ULPS_STATE_EXIT | DEVICE_READY);
> + I915_WRITE(MIPI_DEVICE_READY(port), val);
>  
> - /* Enter Normal Mode */
> - val = I915_READ(MIPI_DEVICE_READY(port));
> - val &= ~ULPS_STATE_MASK;
> - val |= (ULPS_STATE_NORMAL_OPERATION | DEVICE_READY);
> - I915_WRITE(MIPI_DEVICE_READY(port), val);
> + /* Enter Normal Mode */
> + val = I915_READ(MIPI_DEVICE_READY(port));
> + 

[Intel-gfx] [PATCH 1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

[Daniel Vetter]

There's really no reason for anything more:
- Calling this while the crtc vblank stuff isn't set up is a driver
  bug. Those places alrready DRM_ERROR.
- Calling this when the crtc is off is either a driver bug (calling
  drm_crtc_handle_vblank at the wrong time) or a core bug (for
  anything else). Again, we DRM_ERROR.
- EINVAL is checked at higher levels already, and if we'd use struct
  drm_crtc * instead of (dev, pipe) it would be real obvious that
  those are again core bugs.

The only valid failure mode is crap hardware that couldn't sample a
useful timestamp, to ask the core to just grab a not-so-accurate
timestamp. Bool is perfectly fine for that.

v2: Also fix up the one caller, I lost that in the shuffling (Jani).

v3: Fixup commit message (Neil).

Cc: Jani Nikula 
Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Neil Armstrong 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  8 ++---
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 14 -
 drivers/gpu/drm/drm_irq.c | 49 ---
 drivers/gpu/drm/i915/i915_irq.c   |  8 ++---
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 12 
 drivers/gpu/drm/nouveau/nouveau_display.c |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.h |  4 +--
 drivers/gpu/drm/radeon/radeon_drv.c   |  8 ++---
 drivers/gpu/drm/radeon/radeon_kms.c   | 14 -
 drivers/gpu/drm/vc4/vc4_crtc.c|  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drmP.h|  1 -
 include/drm/drm_drv.h |  7 ++---
 include/drm/drm_irq.h | 10 +++
 14 files changed, 64 insertions(+), 79 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 6a8129949333..7b4f808afff9 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1910,10 +1910,10 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags);
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index 832be632478f..a1b97809305e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -945,19 +945,19 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
- * Returns postive status flags on success, negative error on failure.
+ * Returns true on success, false on failure.
  */
-int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-   int *max_error,
-   struct timeval *vblank_time,
-   unsigned flags)
+bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
+int *max_error,
+struct timeval *vblank_time,
+unsigned flags)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
 
if (pipe >= dev->num_crtcs) {
DRM_ERROR("Invalid crtc %u\n", pipe);
-   return -EINVAL;
+   return false;
}
 
/* Get associated drm_crtc: */
@@ -966,7 +966,7 @@ int amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, 
unsigned int pipe,
/* This can occur on driver load if some component fails to
 * initialize completely and driver is unloaded */
DRM_ERROR("Uninitialized crtc %d\n", pipe);
-   return -EINVAL;
+   

[Intel-gfx] [PATCH 4/5] drm/vblank: drop the mode argument from drm_calc_vbltimestamp_from_scanoutpos

[Daniel Vetter]

If we restrict this helper to only kms drivers (which is the case) we
can look up the correct mode easily ourselves. But it's a bit tricky:

- All legacy drivers look at crtc->hwmode. But that is updated already
  at the beginning of the modeset helper, which means when we disable
  a pipe. Hence the final timestamps might be a bit off. But since
  this is an existing bug I'm not going to change it, but just try to
  be bug-for-bug compatible with the current code. This only applies
  to radeon

- i915 tries to get it perfect by updating crtc->hwmode when the pipe
  is off (i.e. vblank->enabled = false).

- All other atomic drivers look at crtc->state->adjusted_mode. Those
  that look at state->requested_mode simply don't adjust their mode,
  so it's the same. That has two problems: Accessing crtc->state from
  interrupt handling code is unsafe, and it's updated before we shut
  down the pipe. For nonblocking modesets it's even worse.

For atomic drivers try to implement what i915 does. To do that we add
a new hwmode field to the vblank structure, and update it from
drm_calc_timestamping_constants(). For atomic drivers that's called
from the right spot by the helper library already, so all fine. But
for safety let's enforce that.

For legacy driver this function is only called at the end (oh the
fun), which is broken, so again let's not bother and just stay
bug-for-bug compatible.

The  benefit is that we can use drm_calc_vbltimestamp_from_scanoutpos
directly to implement ->get_vblank_timestamp in every driver, deleting
a lot of code.

v2: Completely new approach, trying to mimick the i915 solution.

v3: Fixup kerneldoc.

v4: Drop the WARN_ON to check that the vblank is off, atomic helpers
currently unconditionally call this. Recomputing the same stuff should
be harmless.

v5: Fix typos and move misplaced hunks to the right patches (Neil).

v6: Undo hunk movement (kbuild).

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Neil Armstrong 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  4 ---
 drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c   | 14 +++--
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   | 41 
 drivers/gpu/drm/amd/amdgpu/amdgpu_mode.h  |  3 ++
 drivers/gpu/drm/drm_irq.c | 43 ++---
 drivers/gpu/drm/i915/i915_irq.c   | 52 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   | 45 +-
 drivers/gpu/drm/nouveau/nouveau_display.c | 38 +-
 drivers/gpu/drm/nouveau/nouveau_display.h |  8 ++---
 drivers/gpu/drm/nouveau/nouveau_drm.c |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   | 18 +++
 drivers/gpu/drm/radeon/radeon_kms.c   | 37 --
 drivers/gpu/drm/radeon/radeon_mode.h  |  3 ++
 drivers/gpu/drm/vc4/vc4_crtc.c| 34 ++--
 drivers/gpu/drm/vc4/vc4_drv.c |  2 +-
 drivers/gpu/drm/vc4/vc4_drv.h | 11 +++
 include/drm/drmP.h|  8 -
 include/drm/drm_drv.h | 20 
 include/drm/drm_irq.h | 15 +++--
 19 files changed, 121 insertions(+), 277 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 0ce8292d97c0..9de615bb0c2e 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1910,10 +1910,6 @@ int amdgpu_device_resume(struct drm_device *dev, bool 
resume, bool fbcon);
 u32 amdgpu_get_vblank_counter_kms(struct drm_device *dev, unsigned int pipe);
 int amdgpu_enable_vblank_kms(struct drm_device *dev, unsigned int pipe);
 void amdgpu_disable_vblank_kms(struct drm_device *dev, unsigned int pipe);
-bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
-int *max_error,
-struct timeval *vblank_time,
-bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
index 4e0f7d2d87f1..73e982cd6136 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
@@ -711,6 +711,16 @@ static const struct file_operations amdgpu_driver_kms_fops 
= {
 #endif
 };
 
+static bool
+amdgpu_get_crtc_scanout_position(struct drm_device *dev, unsigned int pipe,
+bool 

[Intel-gfx] [PATCH 2/5] drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp

[Daniel Vetter]

It's overkill to have a flag parameter which is essentially used just
as a boolean. This takes care of core + adjusting drivers.

Adjusting the scanout position callback is a bit harder, since radeon
also supplies it's own driver-private flags in there.

v2: Fixup misplaced hunks (Neil).

v3: kbuild says v1 was better ...

Cc: Mario Kleiner 
Cc: Eric Anholt 
Cc: Rob Clark 
Cc: linux-arm-...@vger.kernel.org
Cc: freedr...@lists.freedesktop.org
Cc: Alex Deucher 
Cc: Christian König 
Cc: Ben Skeggs 
Reviewed-by: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu.h   |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c   |  6 ++---
 drivers/gpu/drm/drm_irq.c | 41 +--
 drivers/gpu/drm/i915/i915_irq.c   |  4 +--
 drivers/gpu/drm/msm/mdp/mdp5/mdp5_kms.c   |  4 +--
 drivers/gpu/drm/nouveau/nouveau_display.c |  5 ++--
 drivers/gpu/drm/nouveau/nouveau_display.h |  2 +-
 drivers/gpu/drm/radeon/radeon_drv.c   |  2 +-
 drivers/gpu/drm/radeon/radeon_kms.c   |  4 +--
 drivers/gpu/drm/vc4/vc4_crtc.c|  4 +--
 drivers/gpu/drm/vc4/vc4_drv.h |  2 +-
 include/drm/drm_drv.h | 17 +++--
 include/drm/drm_irq.h |  2 +-
 13 files changed, 50 insertions(+), 45 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
index 7b4f808afff9..0ce8292d97c0 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu.h
@@ -1913,7 +1913,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe);
 bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
 int *max_error,
 struct timeval *vblank_time,
-unsigned flags);
+bool in_vblank_irq);
 long amdgpu_kms_compat_ioctl(struct file *filp, unsigned int cmd,
 unsigned long arg);
 
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
index a1b97809305e..babd969a63d1 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c
@@ -941,7 +941,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
  * @crtc: crtc to get the timestamp for
  * @max_error: max error
  * @vblank_time: time value
- * @flags: flags passed to the driver
+ * @in_vblank_irq: called from drm_handle_vblank()
  *
  * Gets the timestamp on the requested crtc based on the
  * scanout position.  (all asics).
@@ -950,7 +950,7 @@ void amdgpu_disable_vblank_kms(struct drm_device *dev, 
unsigned int pipe)
 bool amdgpu_get_vblank_timestamp_kms(struct drm_device *dev, unsigned int pipe,
 int *max_error,
 struct timeval *vblank_time,
-unsigned flags)
+bool in_vblank_irq)
 {
struct drm_crtc *crtc;
struct amdgpu_device *adev = dev->dev_private;
@@ -971,7 +971,7 @@ bool amdgpu_get_vblank_timestamp_kms(struct drm_device 
*dev, unsigned int pipe,
 
/* Helper routine in DRM core does all the work: */
return drm_calc_vbltimestamp_from_scanoutpos(dev, pipe, max_error,
-vblank_time, flags,
+vblank_time, in_vblank_irq,
 >hwmode);
 }
 
diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 677b37b0372b..fba6a842f4cd 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -54,7 +54,7 @@
 
 static bool
 drm_get_last_vbltimestamp(struct drm_device *dev, unsigned int pipe,
- struct timeval *tvblank, unsigned flags);
+ struct timeval *tvblank, bool in_vblank_irq);
 
 static unsigned int drm_timestamp_precision = 20;  /* Default to 20 usecs. */
 
@@ -138,7 +138,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
 */
do {
cur_vblank = __get_vblank_counter(dev, pipe);
-   rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, 0);
+   rc = drm_get_last_vbltimestamp(dev, pipe, _vblank, false);
} while (cur_vblank != __get_vblank_counter(dev, pipe) && --count > 0);
 
/*
@@ -171,7 +171,7 @@ static void drm_reset_vblank_timestamp(struct drm_device 
*dev, unsigned int pipe
  * device vblank fields.
  */
 static void drm_update_vblank_count(struct drm_device 

[Intel-gfx] [PATCH 3/5] drm/vblank: Add FIXME comments about moving the vblank ts hooks

[Daniel Vetter]

This is going to be a bit too much, but good to have at least a small
note about where this should all head towards.

Acked-by: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Signed-off-by: Daniel Vetter 
---
 include/drm/drm_drv.h | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index a97dbc1eeccd..619da98533cd 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -276,6 +276,11 @@ struct drm_driver {
 * constant but unknown small number of scanlines wrt. real scanout
 * position.
 *
+* FIXME:
+*
+* Since this is a helper to implement @get_vblank_timestamp, we should
+* move it to  drm_crtc_helper_funcs, like all the other
+* helper-internal hooks.
 */
int (*get_scanout_position) (struct drm_device *dev, unsigned int pipe,
 unsigned int flags, int *vpos, int *hpos,
@@ -319,6 +324,11 @@ struct drm_driver {
 *
 * True on success, false on failure, which means the core should
 * fallback to a simple timestamp taken in drm_crtc_handle_vblank().
+*
+* FIXME:
+*
+* We should move this hook to  drm_crtc_funcs like all the other
+* vblank hooks.
 */
bool (*get_vblank_timestamp) (struct drm_device *dev, unsigned int pipe,
 int *max_error,
-- 
2.11.0

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

[Intel-gfx] [PATCH 5/5] drm/vblank: Lock down vblank->hwmode more

[Daniel Vetter]

In the previous patch we've implemented hwmode tracking a la i915 for
the vblank timestamp calculations. But that was just the basic
semantics, i915 has some nice sanity checks to make sure we keep
getting this right. Move them over too.

v2:
- WARN_ON_ONCE to avoid excessive spam (Ville)
- Really only WARN on atomic drivers.

Cc: Ville Syrjälä 
Reviewed-by: Neil Armstrong 
Acked-by: Ville Syrjälä 
Signed-off-by: Daniel Vetter 
---
 drivers/gpu/drm/drm_irq.c|  6 ++
 drivers/gpu/drm/i915/i915_irq.c  | 10 ++
 drivers/gpu/drm/i915/intel_display.c | 11 ++-
 3 files changed, 14 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/drm_irq.c b/drivers/gpu/drm/drm_irq.c
index 89f0928b042a..c7debaad67f8 100644
--- a/drivers/gpu/drm/drm_irq.c
+++ b/drivers/gpu/drm/drm_irq.c
@@ -777,6 +777,8 @@ bool drm_calc_vbltimestamp_from_scanoutpos(struct 
drm_device *dev,
 */
if (mode->crtc_clock == 0) {
DRM_DEBUG("crtc %u: Noop due to uninitialized mode.\n", pipe);
+   WARN_ON_ONCE(drm_drv_uses_atomic_modeset(dev));
+
return false;
}
 
@@ -1338,6 +1340,10 @@ void drm_crtc_vblank_off(struct drm_crtc *crtc)
send_vblank_event(dev, e, seq, );
}
spin_unlock_irqrestore(>event_lock, irqflags);
+
+   /* Will be reset by the modeset helpers when re-enabling the crtc by
+* calling drm_calc_timestamping_constants(). */
+   vblank->hwmode.crtc_clock = 0;
 }
 EXPORT_SYMBOL(drm_crtc_vblank_off);
 
diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c
index 34b09edc18e4..5292fb1e5c53 100644
--- a/drivers/gpu/drm/i915/i915_irq.c
+++ b/drivers/gpu/drm/i915/i915_irq.c
@@ -720,9 +720,7 @@ static u32 i915_get_vblank_counter(struct drm_device *dev, 
unsigned int pipe)
struct drm_i915_private *dev_priv = to_i915(dev);
i915_reg_t high_frame, low_frame;
u32 high1, high2, low, pixel, vbl_start, hsync_start, htotal;
-   struct intel_crtc *intel_crtc = intel_get_crtc_for_pipe(dev_priv,
-   pipe);
-   const struct drm_display_mode *mode = _crtc->base.hwmode;
+   const struct drm_display_mode *mode = >vblank[pipe].hwmode;
unsigned long irqflags;
 
htotal = mode->crtc_htotal;
@@ -779,13 +777,17 @@ static int __intel_get_crtc_scanline(struct intel_crtc 
*crtc)
 {
struct drm_device *dev = crtc->base.dev;
struct drm_i915_private *dev_priv = to_i915(dev);
-   const struct drm_display_mode *mode = >base.hwmode;
+   const struct drm_display_mode *mode;
+   struct drm_vblank_crtc *vblank;
enum pipe pipe = crtc->pipe;
int position, vtotal;
 
if (!crtc->active)
return -1;
 
+   vblank = >base.dev->vblank[drm_crtc_index(>base)];
+   mode = >hwmode;
+
vtotal = mode->crtc_vtotal;
if (mode->flags & DRM_MODE_FLAG_INTERLACE)
vtotal /= 2;
diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 85b9e2f521a0..a190973daeee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -11443,12 +11443,6 @@ intel_modeset_update_crtc_state(struct 
drm_atomic_state *state)
for_each_new_crtc_in_state(state, crtc, new_crtc_state, i) {
to_intel_crtc(crtc)->config = 
to_intel_crtc_state(new_crtc_state);
 
-   /* Update hwmode for vblank functions */
-   if (new_crtc_state->active)
-   crtc->hwmode = new_crtc_state->adjusted_mode;
-   else
-   crtc->hwmode.crtc_clock = 0;
-
/*
 * Update legacy state to satisfy fbc code. This can
 * be removed when fbc uses the atomic state.
@@ -15425,8 +15419,6 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
to_intel_crtc_state(crtc->base.state);
int pixclk = 0;
 
-   crtc->base.hwmode = crtc_state->base.adjusted_mode;
-
memset(>base.mode, 0, sizeof(crtc->base.mode));
if (crtc_state->base.active) {
intel_mode_from_pipe_config(>base.mode, 
crtc_state);
@@ -15456,7 +15448,8 @@ static void intel_modeset_readout_hw_state(struct 
drm_device *dev)
if (IS_BROADWELL(dev_priv) && crtc_state->ips_enabled)
pixclk = DIV_ROUND_UP(pixclk * 100, 95);
 
-   drm_calc_timestamping_constants(>base, 
>base.hwmode);
+   drm_calc_timestamping_constants(>base,
+   
_state->base.adjusted_mode);
update_scanline_offset(crtc);
}
 
-- 

[Intel-gfx] [RFC 1/3] drm/i915: Wrap context schedule notification

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

No functional change just something which will be handy in the
following patch.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_lrc.c | 22 +++---
 1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 319d9a8f37ca..4c37e94c4d3d 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -306,6 +306,18 @@ execlists_context_status_change(struct 
drm_i915_gem_request *rq,
   status, rq);
 }
 
+static inline void
+execlists_context_schedule_in(struct drm_i915_gem_request *rq)
+{
+   execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
+}
+
+static inline void
+execlists_context_schedule_out(struct drm_i915_gem_request *rq)
+{
+   execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
+}
+
 static void
 execlists_update_context_pdps(struct i915_hw_ppgtt *ppgtt, u32 *reg_state)
 {
@@ -345,16 +357,14 @@ static void execlists_submit_ports(struct intel_engine_cs 
*engine)
 
GEM_BUG_ON(port[0].count > 1);
if (!port[0].count)
-   execlists_context_status_change(port[0].request,
-   INTEL_CONTEXT_SCHEDULE_IN);
+   execlists_context_schedule_in(port[0].request);
desc[0] = execlists_update_context(port[0].request);
GEM_DEBUG_EXEC(port[0].context_id = upper_32_bits(desc[0]));
port[0].count++;
 
if (port[1].request) {
GEM_BUG_ON(port[1].count);
-   execlists_context_status_change(port[1].request,
-   INTEL_CONTEXT_SCHEDULE_IN);
+   execlists_context_schedule_in(port[1].request);
desc[1] = execlists_update_context(port[1].request);
GEM_DEBUG_EXEC(port[1].context_id = upper_32_bits(desc[1]));
port[1].count = 1;
@@ -581,9 +591,7 @@ static void intel_lrc_irq_handler(unsigned long data)
if (--port[0].count == 0) {
GEM_BUG_ON(status & GEN8_CTX_STATUS_PREEMPTED);

GEM_BUG_ON(!i915_gem_request_completed(port[0].request));
-   execlists_context_status_change(port[0].request,
-   
INTEL_CONTEXT_SCHEDULE_OUT);
-
+   execlists_context_schedule_out(port[0].request);
trace_i915_gem_request_out(port[0].request);
i915_gem_request_put(port[0].request);
port[0] = port[1];
-- 
2.9.3

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

[Intel-gfx] [RFC 0/3] Engine utilization tracking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

By popular customer demand here is the prototype for cheap engine utilization
tracking.

It uses static branches so in the default off case it really should be cheap.

It exports the per engine total time something has been executing (in nano-
seconds) in debugfs/i915_engine_stats.

This is a problem for something which would preferrably be a stable ABI but I
needed all of the open, release and read hooks for it to work as I imagined it.
So far I did not come up with a different location which would support that.

Userspace is supposed to open the file and keep re-reading it by seeking to its
beginning. This is because first open and last close are a costly operations,
and also because the most interesting is the relative change between two
sampling periods.

Example code which does this looks like this:

#include 
#include 
#include 
#include 
#include 

#include "drmtest.h"
#include "igt_debugfs.h"

int main(void)
{
int drm_fd, fd;

drm_fd = drm_open_driver(DRIVER_INTEL);

fd = igt_debugfs_open(drm_fd, "i915_engine_stats", O_RDONLY);
igt_assert(fd >= 0);

for (;;) {
char buf[4096];
ssize_t ret;
off_t off;

ret = read(fd, buf, sizeof(buf));
igt_assert(ret > 0);

ret = write(1, buf, ret);
printf("\n");

off = lseek(fd, 0, SEEK_SET);
igt_assert_eq(off, 0);

sleep(1);
}

close(fd);
close(drm_fd);

return 0;
}

Comments, flames, ideas welcome!

Tvrtko Ursulin (3):
  drm/i915: Wrap context schedule notification
  drm/i915: Engine busy time tracking
  drm/i915: Export engine busy stats in debugfs

 drivers/gpu/drm/i915/i915_debugfs.c | 120 
 drivers/gpu/drm/i915/intel_engine_cs.c  |   6 ++
 drivers/gpu/drm/i915/intel_lrc.c|  24 +--
 drivers/gpu/drm/i915/intel_ringbuffer.h |  39 +++
 4 files changed, 182 insertions(+), 7 deletions(-)

-- 
2.9.3

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

[Intel-gfx] [RFC 3/3] drm/i915: Export engine busy stats in debugfs

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Export the stats added in the previous patch in debugfs.

Number of active clients reading this data is tracked and the
static key is only enabled whilst there are some.

Userspace is intended to keep the file descriptor open, seeking
to the beginning of the file periodically, and re-reading the
stats.

This is because the underlying implementation is costly on every
first open/last close transition, and also, because the stats
exported mostly make sense when they are considered relative to
the previous sample.

File lists nanoseconds each engine was active since the tracking
has started.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_debugfs.c | 120 
 1 file changed, 120 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
b/drivers/gpu/drm/i915/i915_debugfs.c
index 1003511f28cc..db588ef858cb 100644
--- a/drivers/gpu/drm/i915/i915_debugfs.c
+++ b/drivers/gpu/drm/i915/i915_debugfs.c
@@ -4752,6 +4752,120 @@ static const struct file_operations 
i915_hpd_storm_ctl_fops = {
.write = i915_hpd_storm_ctl_write
 };
 
+DECLARE_STATIC_KEY_FALSE(i915_engine_stats_key);
+static DEFINE_MUTEX(i915_engine_stats_mutex);
+static int i915_engine_stats_ref;
+
+struct i915_engine_stats_buf {
+   unsigned int len;
+   size_t available;
+   char buf[0];
+};
+
+static int i915_engine_stats_open(struct inode *inode, struct file *file)
+{
+   const unsigned int engine_name_len =
+   sizeof(((struct intel_engine_cs *)0)->name);
+   struct i915_engine_stats_buf *buf;
+   const unsigned int buf_size =
+   (engine_name_len + 2 + 19 + 1) * I915_NUM_ENGINES + 1 +
+   sizeof(*buf);
+   int ret;
+
+   buf = kzalloc(buf_size, GFP_KERNEL);
+   if (!buf)
+   return -ENOMEM;
+
+   buf->len = buf_size;
+   file->private_data = buf;
+
+   ret = mutex_lock_interruptible(_engine_stats_mutex);
+   if (ret)
+   return ret;
+
+   if (i915_engine_stats_ref++ == 0) {
+   struct drm_i915_private *dev_priv = file->f_inode->i_private;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   for_each_engine(engine, dev_priv, id) {
+   memset(>stats, 0, sizeof(engine->stats));
+   spin_lock_init(>stats.lock);
+   }
+
+   static_branch_enable(_engine_stats_key);
+   }
+
+   mutex_unlock(_engine_stats_mutex);
+
+   return 0;
+}
+
+static int i915_engine_stats_release(struct inode *inode, struct file *file)
+{
+   mutex_lock(_engine_stats_mutex);
+   if (--i915_engine_stats_ref == 0)
+   static_branch_disable(_engine_stats_key);
+   mutex_unlock(_engine_stats_mutex);
+
+   kfree(file->private_data);
+
+   return 0;
+}
+
+static ssize_t i915_engine_stats_read(struct file *file, char __user *ubuf,
+ size_t count, loff_t *pos)
+{
+   struct i915_engine_stats_buf *buf =
+   (struct i915_engine_stats_buf *)file->private_data;
+
+   if (*pos == 0) {
+   struct drm_i915_private *dev_priv = file->f_inode->i_private;
+   char *ptr = >buf[0];
+   int left = buf->len;
+   struct intel_engine_cs *engine;
+   enum intel_engine_id id;
+
+   buf->available = 0;
+
+   for_each_engine(engine, dev_priv, id) {
+   u64 total;
+   int len;
+
+   spin_lock_irq(>stats.lock);
+   total = engine->stats.total;
+   /*
+* If the engine is executing something at the moment
+* add it to the total.
+*/
+   if (engine->stats.ref)
+   total += ktime_get_real_ns() -
+engine->stats.start;
+   spin_unlock_irq(>stats.lock);
+
+   len = snprintf(ptr, left, "%s: %llu\n",
+  engine->name, total);
+   buf->available += len;
+   left -= len;
+   ptr += len;
+
+   if (len == 0)
+   return -EFBIG;
+   }
+   }
+
+   return simple_read_from_buffer(ubuf, count, pos, >buf[0],
+  buf->available);
+}
+
+static const struct file_operations i915_engine_stats_fops = {
+   .owner = THIS_MODULE,
+   .open = i915_engine_stats_open,
+   .release = i915_engine_stats_release,
+   .read = i915_engine_stats_read,
+   .llseek = default_llseek,
+};
+
 static const struct drm_info_list i915_debugfs_list[] = {
{"i915_capabilities", 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/glk: Calculate high/low switch count for GLK

[Patchwork]

== Series Details ==

Series: series starting with [1/2] drm/i915/glk: Calculate high/low switch 
count for GLK
URL   : https://patchwork.freedesktop.org/series/24173/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:439s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:431s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:587s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:518s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:546s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:488s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:488s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:423s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:411s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:408s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:424s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:488s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:477s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:468s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:575s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:463s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:575s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:464s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:510s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:439s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:539s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:412s

417babaa12ad98dad2c39f361612f1afe6894816 drm-tip: 2017y-05m-09d-13h-13m-23s UTC 
integration manifest
eda9051 drm/i915/glk: Enable cold boot for GLK DSI
0f29175 drm/i915/glk: Calculate high/low switch count for GLK

== Logs ==

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

[Intel-gfx] [RFC 2/3] drm/i915: Engine busy time tracking

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Track total time requests have been executing on the hardware.

To make this cheap it is hidden behind a static branch with the
intention that it is only enabled when there is a consumer
listening. This means that in the default off case the total
cost of the tracking is just a few no-op instructions on the
fast paths.

Signed-off-by: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/intel_engine_cs.c  |  6 +
 drivers/gpu/drm/i915/intel_lrc.c|  2 ++
 drivers/gpu/drm/i915/intel_ringbuffer.h | 39 +
 3 files changed, 47 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_engine_cs.c 
b/drivers/gpu/drm/i915/intel_engine_cs.c
index 483ed7635692..4d42e86ad5de 100644
--- a/drivers/gpu/drm/i915/intel_engine_cs.c
+++ b/drivers/gpu/drm/i915/intel_engine_cs.c
@@ -22,10 +22,14 @@
  *
  */
 
+#include 
+
 #include "i915_drv.h"
 #include "intel_ringbuffer.h"
 #include "intel_lrc.h"
 
+DEFINE_STATIC_KEY_FALSE(i915_engine_stats_key);
+
 /* Haswell does have the CXT_SIZE register however it does not appear to be
  * valid. Now, docs explain in dwords what is in the context object. The full
  * size is 70720 bytes, however, the power context and execlist context will
@@ -222,6 +226,8 @@ intel_engine_setup(struct drm_i915_private *dev_priv,
/* Nothing to do here, execute in order of dependencies */
engine->schedule = NULL;
 
+   spin_lock_init(>stats.lock);
+
ATOMIC_INIT_NOTIFIER_HEAD(>context_status_notifier);
 
dev_priv->engine[id] = engine;
diff --git a/drivers/gpu/drm/i915/intel_lrc.c b/drivers/gpu/drm/i915/intel_lrc.c
index 4c37e94c4d3d..92da6d1676ce 100644
--- a/drivers/gpu/drm/i915/intel_lrc.c
+++ b/drivers/gpu/drm/i915/intel_lrc.c
@@ -309,12 +309,14 @@ execlists_context_status_change(struct 
drm_i915_gem_request *rq,
 static inline void
 execlists_context_schedule_in(struct drm_i915_gem_request *rq)
 {
+   intel_engine_context_in(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_IN);
 }
 
 static inline void
 execlists_context_schedule_out(struct drm_i915_gem_request *rq)
 {
+   intel_engine_context_out(rq->engine);
execlists_context_status_change(rq, INTEL_CONTEXT_SCHEDULE_OUT);
 }
 
diff --git a/drivers/gpu/drm/i915/intel_ringbuffer.h 
b/drivers/gpu/drm/i915/intel_ringbuffer.h
index ec16fb6fde62..dd007dae6533 100644
--- a/drivers/gpu/drm/i915/intel_ringbuffer.h
+++ b/drivers/gpu/drm/i915/intel_ringbuffer.h
@@ -425,6 +425,13 @@ struct intel_engine_cs {
 * certain bits to encode the command length in the header).
 */
u32 (*get_cmd_length_mask)(u32 cmd_header);
+
+   struct {
+   spinlock_t lock;
+   unsigned int ref;
+   u64 start; /* Timestamp of the last idle to active transition. 
*/
+   u64 total; /* Total time engined was busy. */
+   } stats;
 };
 
 static inline unsigned int
@@ -718,4 +725,36 @@ bool intel_engines_are_idle(struct drm_i915_private 
*dev_priv);
 
 void intel_engines_reset_default_submission(struct drm_i915_private *i915);
 
+DECLARE_STATIC_KEY_FALSE(i915_engine_stats_key);
+
+static inline void intel_engine_context_in(struct intel_engine_cs *engine)
+{
+   if (static_branch_unlikely(_engine_stats_key)) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>stats.lock, flags);
+   if (engine->stats.ref++ == 0)
+   engine->stats.start = ktime_get_real_ns();
+   GEM_BUG_ON(engine->stats.ref == 0);
+   spin_unlock_irqrestore(>stats.lock, flags);
+   }
+}
+
+static inline void intel_engine_context_out(struct intel_engine_cs *engine)
+{
+   if (static_branch_unlikely(_engine_stats_key)) {
+   unsigned long flags;
+
+   spin_lock_irqsave(>stats.lock, flags);
+   /*
+* After turning on the static key context out might be the
+* first event which then needs to be ignored (ref == 0).
+*/
+   if (engine->stats.ref && --engine->stats.ref == 0)
+   engine->stats.total += ktime_get_real_ns() -
+  engine->stats.start;
+   spin_unlock_irqrestore(>stats.lock, flags);
+   }
+}
+
 #endif /* _INTEL_RINGBUFFER_H_ */
-- 
2.9.3

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

Re: [Intel-gfx] [PATCH v3] drm/i915/gvt: return the actual aperture size under gvt environment

[Joonas Lahtinen]

On ti, 2017-05-09 at 03:10 +, Li, Weinan Z wrote:

> > > > @@ -242,6 +242,9 @@ int intel_vgt_balloon(struct drm_i915_private
> > > > *dev_priv)
> > > >     goto err;
> > > >     }
> > > > 
> > > > +   for (i = 0; i < ARRAY_SIZE(bl_info.space); i++)
> > > > +   ggtt->base.reserved += bl_info.space[i].size;
> > > > +
> > 
> > There should be an equal decrease when deballooning is done. And for that to
> > be correct, you need to add proper onion teardown to this function to make
> > sure the count stays correct (can't call deballoon on failure or the count 
> > will
> > become negative which will result in huge number marked as reserved).
> Oh, that's my fault. Should add clean up in intel_vgt_deballoon().
> @@ -114,6 +114,7 @@ void intel_vgt_deballoon(struct drm_i915_private 
> *dev_priv)
> }
> 
> memset(_info, 0, sizeof(bl_info));
> +   dev_priv->ggtt.reserved = 0;
> }
> Since if any steps in intel_vgt_balloon() fail, it will deal as error and run
> intel_vgt_deballoon() for clean up, no partial success happen.
> So we only calculate the reserved when balloon success, it can ensure it's 
> correct.

Onion teardown should be used according to kernel coding style, there's
really no excuse not to.

Just add to the ggtt->base.reserved in increments, and remove in
increments during teardown or in the deballoon function. ggtt.reserved
is not exclusively for GVT-g to use, so you can't simply zero it. There
needs to be incremental additions and substractions as objects are
added and removed for the variable to stay general.

Regards, Joonas
-- 
Joonas Lahtinen
Open Source Technology Center
Intel Corporation
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[Felipe Balbi]

Hi,

Andy Shevchenko  writes:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time we
> convert current users.
>
> acpi_str_to_uuid() becomes useless after the conversion and it's safe to
> get rid of it.
>
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
>
> Cc: Rafael J. Wysocki 
> Cc: Mika Westerberg 
> Cc: Borislav Petkov 
> Cc: Dan Williams 
> Cc: Amir Goldstein 
> Cc: Jarkko Sakkinen 
> Cc: Jani Nikula 
> Cc: Ben Skeggs 
> Cc: Benjamin Tissoires 
> Cc: Joerg Roedel 
> Cc: Adrian Hunter 
> Cc: Yisen Zhuang 
> Cc: Bjorn Helgaas 
> Cc: Zhang Rui 
> Cc: Felipe Balbi 
> Cc: Mathias Nyman 
> Cc: Heikki Krogerus 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Signed-off-by: Andy Shevchenko 
> diff --git a/drivers/usb/dwc3/dwc3-pci.c b/drivers/usb/dwc3/dwc3-pci.c
> index a15ec71d0423..6b5284ec76df 100644
> --- a/drivers/usb/dwc3/dwc3-pci.c
> +++ b/drivers/usb/dwc3/dwc3-pci.c
> @@ -56,7 +56,7 @@ struct dwc3_pci {
>   struct platform_device *dwc3;
>   struct pci_dev *pci;
>  
> - u8 uuid[16];
> + uuid_le uuid;
>  
>   unsigned int has_dsm_for_pm:1;
>  };
> @@ -118,7 +118,7 @@ static int dwc3_pci_quirks(struct dwc3_pci *dwc)
>  
>   if (pdev->device == PCI_DEVICE_ID_INTEL_BXT ||
>   pdev->device == PCI_DEVICE_ID_INTEL_BXT_M) {
> - acpi_str_to_uuid(PCI_INTEL_BXT_DSM_UUID, dwc->uuid);
> + uuid_le_to_bin(PCI_INTEL_BXT_DSM_UUID, >uuid);
>   dwc->has_dsm_for_pm = true;
>   }
>  
> @@ -288,7 +288,7 @@ static int dwc3_pci_dsm(struct dwc3_pci *dwc, int param)
>   tmp.type = ACPI_TYPE_INTEGER;
>   tmp.integer.value = param;
>  
> - obj = acpi_evaluate_dsm(ACPI_HANDLE(>pci->dev), dwc->uuid,
> + obj = acpi_evaluate_dsm(ACPI_HANDLE(>pci->dev), >uuid,
>   1, PCI_INTEL_BXT_FUNC_PMU_PWR, );
>   if (!obj) {
>   dev_err(>pci->dev, "failed to evaluate _DSM\n");

Acked-by: Felipe Balbi 

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

Re: [Intel-gfx] [PATCH V6] drm/i915: Disable stolen memory when i915 runs in guest vm

[Alex Williamson]

On Mon, 08 May 2017 13:07:10 +0300
Joonas Lahtinen  wrote:

> On la, 2017-05-06 at 02:58 +, Zhang, Xiong Y wrote:
> > > 
> > > On ke, 2017-05-03 at 09:22 +, Zhang, Xiong Y wrote:  
> > > >   
> > > > > 
> > > > >   
> > > > > > 
> > > > > > 
> > > > > > + David and Jon
> > > > > > 
> > > > > > On ti, 2017-04-25 at 18:34 +0800, Xiong Zhang wrote:
> > > > > > 
> > > > > > The blocking issue I see is that bisecting is still not pointing at
> > > > > > relevant commits. Both bisected commits from Bugzilla are not 
> > > > > > related
> > > > > > to changes in stolen memory usage behavior. I'd assume a successful
> > > > > > bisect to land at the patches where we start creating kernel 
> > > > > > internal
> > > > > > objects from stolen memory. Otherwise we could be ignoring a bug
> > > > > > elsewhere. If it consistently lands on those patches, then there 
> > > > > > might
> > > > > > be something wrong with them, in addition to stolen memory 
> > > > > > problems.  
> > > > > [Zhang, Xiong Y] I only try kernel 4.8 and 4.9 above, as the bugzilla 
> > > > >  
> > > descripted,  
> > > >   
> > > > > 
> > > > > guest 4.8 kernel doesn't see gpu hang in guest dmesg, 4.9 kernel has 
> > > > > gpu  
> > > hang  
> > > >   
> > > > > 
> > > > > in guest dmesg. From this point, we could do git bisect.
> > > > > But tons of IOMMU DMA R/W exception to stolen memory exist in host  
> > > dmesg  
> > > >   
> > > > > 
> > > > > when guest kernel is 4.8 and 4.9. This means guest domain iommu table
> > > > > doesn't
> > > > > have mapping for stolen memory and IGD fail in accessing stolen memory
> > > > > from guest kernel 4.8 and 4.9. From this point, this issue isn't a 
> > > > > regression  
> > > and  
> > > >   
> > > > > 
> > > > > shouldn't go git bisect. You could check this host error message from 
> > > > > the
> > > > > bugzilla
> > > > > attachment. And this should be fixed first.
> > > > > Anyway, I will try my best to get the ideal commit through git 
> > > > > bisect, but  
> > > I'm  
> > > >   
> > > > > 
> > > > > afraid
> > > > > the result is the same as past because we don't have a stable good 
> > > > > point to
> > > > > start git
> > > > > bisect.  
> > > > [Zhang, Xiong Y] hi, Joonas:
> > > > As you said, the gpu hang exist because i915 create ring buffer from 
> > > > stolen  
> > > memory.  
> > > > 
> > > > I did git bisect again, and the following commit is the first bad 
> > > > commit:
> > > > commit c58b735fc762e891481e92af7124b85cb0a51fce  
> > > > > > > Author: Chris Wilson   
> > > > Date:   Thu Aug 18 17:16:57 2016 +0100
> > > > 
> > > > drm/i915: Allocate rings from stolen
> > > > 
> > > > If we have stolen available, make use of it for ringbuffer 
> > > > allocation.
> > > > Previously this was restricted to !llc platforms, as writing to 
> > > > stolen
> > > > requires a GGTT mapping - but now that we have partial mappable  
> > > support,  
> > > > 
> > > > the mappable aperture isn't quite so precious so we can use it more
> > > > freely and ringbuffers are a good user for the otherwise wasted 
> > > > stolen.
> > > > 
> > > > After reverting this patch from drm-intel-nightly, I didn't see gpu 
> > > > hang during  
> > > guest boot process.  
> > > > 
> > > > So what's our next step ?  
> > > 
> > > An appropriate next step would be to evaluate how much work it is to
> > > support the RMRR passthrough David mentioned about in his commit.  
> > [Zhang, Xiong Y] As Kevin explained, KVM community found the disadvantage
> > Of RMRR and have decided to not support RMRR passthrough, so it is really 
> > hard
> > for us to push such solution and isn't related to the workload.
> > Except usb and graphic card, all other devices with RMRR couldn't 
> > passthrough
> > to guest. But the driver of usb and graphic card couldn't access RMRR in 
> > such
> > environment.
> > https://access.redhat.com/sites/default/files/attachments/rmrr-wp1.pdf  
> 
> Does this patch have the right Cc's from KVM team? I'd like to hear
> directly from them that even the usage of RMRRs that follow the
> intention of VT-d spec are not going to be supported. That document
> predates the patches to add the exclusion for graphics.

I'm the QEMU and kernel vfio maintainer and co-author of the above
whitepaper.  Even the VT-d spec suggests that usage of RMRRs should be
limited (rev 2.3, 8.4):

  Platform designers should avoid or limit use of reserved memory
  regions since these require system software to create holes in the
  DMA virtual address range available to system software and its
  drivers.

Also, if you read the entire thread which added the graphics exception
for RMRR, you'll see that it went in under some degree of protest and
ultimately under the conclusion that we should just ignore the RMRR
anyway:

https://lists.linuxfoundation.org/pipermail/iommu/2015-April/012790.html

At least for the case of IGD RMRRs, we 

[Intel-gfx] vlv_disable_backlight causing warnings with i915 @ Xorg start

[Andrew Siplas]

At Xorg startup after a fresh compile of the mainline kernel, WARN_ON is
truthy and throws a warning into the kernel's dmesg buffer.

I'm still trying to understand the driver, but it originates here:

--

static void vlv_disable_backlight(struct intel_connector *connector)
{
struct drm_i915_private *dev_priv =
to_i915(connector->base.dev);
enum pipe pipe = intel_get_pipe_from_connector(connector);
u32 tmp;

if (WARN_ON(pipe != PIPE_A && pipe != PIPE_B))
return;

intel_panel_actually_set_backlight(connector, 0);

tmp = I915_READ(VLV_BLC_PWM_CTL2(pipe));
I915_WRITE(VLV_BLC_PWM_CTL2(pipe), tmp & ~BLM_PWM_ENABLE);
}

--

Don't know yet what this means and so taking a chance this warning is
something someone here might have some insight into / want to know about
especially given the "...[ cut here ]...".

The last two lines are from 5+ minutes after the warning but seem related:


[   67.896233] [ cut here ]
[   67.896259] WARNING: CPU: 1 PID: 4276 at 
drivers/gpu/drm/i915/intel_panel.c:771 vlv_disable_backlight+0x86/0x90
[   67.896261] Modules linked in: iptable_nat nf_nat_ipv4 nf_nat uvcvideo 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
[   67.896299] CPU: 1 PID: 4276 Comm: Xorg Not tainted 4.11.0+ #2
[   67.896303] Hardware name: HP HP Notebook/80C5, BIOS F.1E 12/25/2015
[   67.896308] task: 8d6e75d79800 task.stack: 9a06c1218000
[   67.896318] RIP: 0010:vlv_disable_backlight+0x86/0x90
[   67.896323] RSP: 0018:9a06c121b998 EFLAGS: 00010286
[   67.896330] RAX: 0029 RBX: 8d6e76018000 RCX: 8ea56a78
[   67.896335] RDX: 0001 RSI: 0092 RDI: 8ece6bcc
[   67.896339] RBP: 9a06c121b9b0 R08: 0029 R09: 02d8
[   67.896344] R10:  R11: 0320 R12: 8d6e723c5000
[   67.896348] R13:  R14: 8d6e7423e800 R15: 8d6e74ab9830
[   67.896355] FS:  7fb8d7e00a40() GS:8d6e7fc8() 
knlGS:
[   67.896359] CS:  0010 DS:  ES:  CR0: 80050033
[   67.896364] CR2: 557bfe77dfd0 CR3: 000274d31000 CR4: 001006e0
[   67.896368] Call Trace:
[   67.896383]  intel_panel_disable_backlight+0x51/0x80
[   67.896391]  intel_edp_backlight_off+0x42/0x50
[   67.896397]  intel_disable_dp+0x70/0xf0
[   67.896407]  intel_encoders_disable.isra.103+0x82/0x90
[   67.896416]  i9xx_crtc_disable+0x51/0x3b0
[   67.896424]  ? intel_crtc_disable_planes+0xd4/0xf0
[   67.896434]  intel_atomic_commit_tail+0x892/0xfb0
[   67.896444]  ? insert_work+0x52/0x70
[   67.896453]  ? __queue_work+0x12e/0x390
[   67.896461]  ? intel_atomic_commit_ready+0x70/0x80
[   67.896470]  intel_atomic_commit+0x3e6/0x4b0
[   67.896479]  ? handle_conflicting_encoders+0x279/0x290
[   67.896489]  drm_atomic_commit+0x46/0x50
[   67.896497]  drm_atomic_helper_set_config+0x6b/0xa0
[   67.896507]  __drm_mode_set_config_internal+0x62/0x110
[   67.896514]  drm_mode_setcrtc+0x4ba/0x5a0
[   67.896524]  drm_ioctl+0x326/0x430
[   67.896532]  ? drm_mode_getcrtc+0x170/0x170
[   67.896543]  do_vfs_ioctl+0x8f/0x5a0
[   67.896552]  ? getnstimeofday64+0x9/0x20
[   67.896561]  SyS_ioctl+0x74/0x80
[   67.896569]  do_syscall_64+0x48/0xb0
[   67.896580]  entry_SYSCALL64_slow_path+0x25/0x25
[   67.896586] RIP: 0033:0x7fb8d5932507
[   67.896590] RSP: 002b:7ffe8bf43018 EFLAGS: 3246 ORIG_RAX: 
0010
[   67.896598] RAX: ffda RBX: 561b92c11210 RCX: 7fb8d5932507
[   67.896602] RDX: 7ffe8bf43140 RSI: c06864a2 RDI: 0009
[   67.896607] RBP: 7ffe8bf43140 R08: 561b92c11050 R09: 0001
[   67.896611] R10: 0001 R11: 3246 R12: c06864a2
[   67.896615] R13: 0009 R14: 561b92c13f70 R15: 7fb8d7d67000
[   67.896620] Code: df 41 8d b4 05 50 12 06 00 ff 93 f8 06 00 00 5b 41 5c 41 
5d 5d c3 48 c7 c6 18 bc 88 8e 48 c7 c7 22 e8 82 8e 31 c0 e8 47 70 b6 ff <0f> ff 
eb e0 66 0f 1f 44 00 00 55 8b b7 f4 03 00 00 48 89 e5 e8 
[   67.896771] ---[ end trace 528f42628325fc1b ]---
[  490.370803] [drm] Atomic update on pipe (A) took 102 us, max time under 
evasion is 100 us
[ 2623.216311] [drm] Atomic update on pipe (A) took 415 us, max time under 
evasion is 100 us



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

[Intel-gfx] [PATCH v6 2/9] drm/i915: Correctly enable backlight brightness adjustment via DPCD

[Puthikorn Voravootivat]

intel_dp_aux_enable_backlight() assumed that the register
BACKLIGHT_BRIGHTNESS_CONTROL_MODE can only has value 01
(DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET) when initialize.

This patch fixed that by handling all cases of that register.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 33 ++-
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 341bf2cb0c25..870c03fc0f3a 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,15 +97,36 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t edp_backlight_mode = 0;
 
set_aux_backlight_enable(intel_dp, true);
 
-   if ((drm_dp_dpcd_readb(_dp->aux,
-  DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) 
== 1) &&
-   ((dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK) ==
-DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET))
-   drm_dp_dpcd_writeb(_dp->aux, 
DP_EDP_BACKLIGHT_MODE_SET_REGISTER,
-  (dpcd_buf | 
DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD));
+   if (drm_dp_dpcd_readb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
+   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
+ DP_EDP_BACKLIGHT_MODE_SET_REGISTER);
+   return;
+   }
+
+   edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+
+   switch (edp_backlight_mode) {
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
+   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   break;
+
+   /* Do nothing when it is already DPCD mode */
+   case DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD:
+   default:
+   break;
+   }
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 6/9] drm/i915: Support dynamic backlight via DPCD register

[Puthikorn Voravootivat]

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

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

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 5ef3ade7c40e..7d323af96636 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -97,10 +97,27 @@ intel_dp_aux_set_backlight(struct intel_connector 
*connector, u32 level)
}
 }
 
+/*
+ * Set minimum / maximum dynamic brightness percentage. This value is expressed
+ * as the percentage of normal brightness in 5% increments.
+ */
+static void
+intel_dp_aux_set_dynamic_backlight_percent(struct intel_dp *intel_dp,
+  u32 min, u32 max)
+{
+   u8 dbc[] = { DIV_ROUND_CLOSEST(min, 5), DIV_ROUND_CLOSEST(max, 5) };
+
+   if (drm_dp_dpcd_write(_dp->aux, DP_EDP_DBC_MINIMUM_BRIGHTNESS_SET,
+ dbc, sizeof(dbc) < 0)) {
+   DRM_DEBUG_KMS("Failed to write aux DBC brightness level\n");
+   }
+}
+
 static void intel_dp_aux_enable_backlight(struct intel_connector *connector)
 {
struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
uint8_t dpcd_buf = 0;
+   uint8_t new_dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
if (drm_dp_dpcd_readb(_dp->aux,
@@ -110,18 +127,15 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
return;
}
 
+   new_dpcd_buf = dpcd_buf;
edp_backlight_mode = dpcd_buf & DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
 
switch (edp_backlight_mode) {
case DP_EDP_BACKLIGHT_CONTROL_MODE_PWM:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRESET:
case DP_EDP_BACKLIGHT_CONTROL_MODE_PRODUCT:
-   dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
-   dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
-   if (drm_dp_dpcd_writeb(_dp->aux,
-   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, dpcd_buf) < 0) {
-   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
-   }
+   new_dpcd_buf &= ~DP_EDP_BACKLIGHT_CONTROL_MODE_MASK;
+   new_dpcd_buf |= DP_EDP_BACKLIGHT_CONTROL_MODE_DPCD;
break;
 
/* Do nothing when it is already DPCD mode */
@@ -130,6 +144,19 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
break;
}
 
+   if (intel_dp->edp_dpcd[2] & DP_EDP_DYNAMIC_BACKLIGHT_CAP) {
+   new_dpcd_buf |= DP_EDP_DYNAMIC_BACKLIGHT_ENABLE;
+   intel_dp_aux_set_dynamic_backlight_percent(intel_dp, 0, 100);
+   DRM_DEBUG_KMS("Enable dynamic brightness.\n");
+   }
+
+   if (new_dpcd_buf != dpcd_buf) {
+   if (drm_dp_dpcd_writeb(_dp->aux,
+   DP_EDP_BACKLIGHT_MODE_SET_REGISTER, new_dpcd_buf) < 0) {
+   DRM_DEBUG_KMS("Failed to write aux backlight mode\n");
+   }
+   }
+
set_aux_backlight_enable(intel_dp, true);
 }
 
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 0/9] Enhancement to intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

This patch set contain 9 patches.
- First five patches fix bug in the driver and allow choosing which
  way to adjust brightness if both PWM pin and AUX are supported
- Next patch adds enable DBC by default
- Next patch makes the driver restore last brightness level after
  turning display off and on.
- Last two patches set the PWM freqency to match data in panel vbt.

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

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

v4:
- Rebase / minor typo fix.

v3:
- Add new implementation of PWM frequency patch

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

Puthikorn Voravootivat (9):
  drm/i915: Fix cap check for intel_dp_aux_backlight driver
  drm/i915: Correctly enable backlight brightness adjustment via DPCD
  drm/i915: Drop AUX backlight enable check for backlight control
  drm/i915: Allow choosing how to adjust brightness if both supported
  drm/i915: Set backlight mode before enable backlight
  drm/i915: Support dynamic backlight via DPCD register
  drm/i915: Restore brightness level in aux backlight driver
  drm: Add definition for eDP backlight frequency
  drm/i915: Set PWM divider to match desired frequency in vbt

 drivers/gpu/drm/i915/i915_params.c|   8 +-
 drivers/gpu/drm/i915/i915_params.h|   2 +-
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 171 --
 include/drm/drm_dp_helper.h   |   2 +
 4 files changed, 167 insertions(+), 16 deletions(-)

-- 
2.13.0.rc2.291.g57267f2277-goog

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

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

[Puthikorn Voravootivat]

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

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

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

[Intel-gfx] [PATCH v6 7/9] drm/i915: Restore brightness level in aux backlight driver

[Puthikorn Voravootivat]

Some panel will default to zero brightness when turning the
panel off and on again. This patch restores last brightness
level back when panel is turning back on.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 7d323af96636..fc26fea94fd4 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -158,6 +158,7 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
}
 
set_aux_backlight_enable(intel_dp, true);
+   intel_dp_aux_set_backlight(connector, connector->panel.backlight.level);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 4/9] drm/i915: Allow choosing how to adjust brightness if both supported

[Puthikorn Voravootivat]

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

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

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index b6a7e363d076..13cf3f1572ab 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -63,7 +63,7 @@ struct i915_params i915 __read_mostly = {
.huc_firmware_path = NULL,
.enable_dp_mst = true,
.inject_load_failure = 0,
-   .enable_dpcd_backlight = false,
+   .enable_dpcd_backlight = -1,
.enable_gvt = false,
 };
 
@@ -246,9 +246,11 @@ MODULE_PARM_DESC(enable_dp_mst,
 module_param_named_unsafe(inject_load_failure, i915.inject_load_failure, uint, 
0400);
 MODULE_PARM_DESC(inject_load_failure,
"Force an error after a number of failure check points (0:disabled 
(default), N:force failure at the Nth failure check point)");
-module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, bool, 
0600);
+module_param_named(enable_dpcd_backlight, i915.enable_dpcd_backlight, int, 
0600);
 MODULE_PARM_DESC(enable_dpcd_backlight,
-   "Enable support for DPCD backlight control (default:false)");
+   "Enable support for DPCD backlight control "
+   "(-1:disable (default), 0:Use PWM pin if both supported, "
+   "1:Use DPCD if both supported");
 
 module_param_named(enable_gvt, i915.enable_gvt, bool, 0400);
 MODULE_PARM_DESC(enable_gvt,
diff --git a/drivers/gpu/drm/i915/i915_params.h 
b/drivers/gpu/drm/i915/i915_params.h
index 34148cc8637c..ac02efce6e22 100644
--- a/drivers/gpu/drm/i915/i915_params.h
+++ b/drivers/gpu/drm/i915/i915_params.h
@@ -66,7 +66,7 @@
func(bool, verbose_state_checks); \
func(bool, nuclear_pageflip); \
func(bool, enable_dp_mst); \
-   func(bool, enable_dpcd_backlight); \
+   func(int, enable_dpcd_backlight); \
func(bool, enable_gvt)
 
 #define MEMBER(T, member) T member
diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index c22712762957..e82f7cb9a7af 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -167,21 +167,34 @@ intel_dp_aux_display_control_capable(struct 
intel_connector *connector)
/* Check the  eDP Display control capabilities registers to determine if
 * the panel can support backlight control over the aux channel
 */
-   if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
-   !((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
- (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
+   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP)) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
return true;
}
return false;
 }
 
+static bool
+intel_dp_pwm_pin_display_control_capable(struct intel_connector *connector)
+{
+   struct intel_dp *intel_dp = enc_to_intel_dp(>encoder->base);
+
+   /* Check the  eDP Display control capabilities registers to determine if
+* the panel can support backlight control via BL_PWM_DIM eDP pin
+*/
+   return intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP;
+}
+
 int intel_dp_aux_init_backlight_funcs(struct intel_connector *intel_connector)
 {
struct intel_panel *panel = _connector->panel;
 
-   if (!i915.enable_dpcd_backlight)
+   if (i915.enable_dpcd_backlight == -1)
+   return -ENODEV;
+
+   if (i915.enable_dpcd_backlight == 0 &&
+   intel_dp_pwm_pin_display_control_capable(intel_connector))
return -ENODEV;
 
if (!intel_dp_aux_display_control_capable(intel_connector))
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 1/9] drm/i915: Fix cap check for intel_dp_aux_backlight driver

[Puthikorn Voravootivat]

intel_dp_aux_backlight driver should check for the
DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP before enable the driver.

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

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 6532e226db29..341bf2cb0c25 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -144,6 +144,7 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
+   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

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

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

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

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index 870c03fc0f3a..c22712762957 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp 
*intel_dp, bool enable)
 {
uint8_t reg_val = 0;
 
+   /* Early return when display use other mechanism to enable backlight. */
+   if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
+   return;
+
if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_REGISTER,
  _val) < 0) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct intel_connector 
*connector)
 * the panel can support backlight control over the aux channel
 */
if (intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP &&
-   (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
(intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP) &&
!((intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_PIN_ENABLE_CAP) ||
  (intel_dp->edp_dpcd[2] & 
DP_EDP_BACKLIGHT_BRIGHTNESS_PWM_PIN_CAP))) {
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 8/9] drm: Add definition for eDP backlight frequency

[Puthikorn Voravootivat]

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

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

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index c0bd0d7651a9..810b7d5d9f2b 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -572,10 +572,12 @@
 #define DP_EDP_PWMGEN_BIT_COUNT 0x724
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MIN 0x725
 #define DP_EDP_PWMGEN_BIT_COUNT_CAP_MAX 0x726
+# define  DP_EDP_PWMGEN_BIT_COUNT_MASK  (0x1f << 0)
 
 #define DP_EDP_BACKLIGHT_CONTROL_STATUS 0x727
 
 #define DP_EDP_BACKLIGHT_FREQ_SET   0x728
+# define DP_EDP_BACKLIGHT_FREQ_BASE 2700
 
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MSB   0x72a
 #define DP_EDP_BACKLIGHT_FREQ_CAP_MIN_MID   0x72b
-- 
2.13.0.rc2.291.g57267f2277-goog

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

[Intel-gfx] [PATCH v6 5/9] drm/i915: Set backlight mode before enable backlight

[Puthikorn Voravootivat]

We should set backlight mode register before set register to
enable the backlight.

Signed-off-by: Puthikorn Voravootivat 
Reviewed-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c 
b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
index e82f7cb9a7af..5ef3ade7c40e 100644
--- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
+++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
@@ -103,8 +103,6 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
uint8_t dpcd_buf = 0;
uint8_t edp_backlight_mode = 0;
 
-   set_aux_backlight_enable(intel_dp, true);
-
if (drm_dp_dpcd_readb(_dp->aux,
DP_EDP_BACKLIGHT_MODE_SET_REGISTER, _buf) != 1) {
DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
@@ -131,6 +129,8 @@ static void intel_dp_aux_enable_backlight(struct 
intel_connector *connector)
default:
break;
}
+
+   set_aux_backlight_enable(intel_dp, true);
 }
 
 static void intel_dp_aux_disable_backlight(struct intel_connector *connector)
-- 
2.13.0.rc2.291.g57267f2277-goog

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

Re: [Intel-gfx] [PATCH v1] ACPI: Switch to use generic UUID API

[Zhang Rui]

On Thu, 2017-05-04 at 12:21 +0300, Andy Shevchenko wrote:
> acpi_evaluate_dsm() and friends take a pointer to a raw buffer of 16
> bytes. Instead we convert them to use uuid_le type. At the same time
> we
> convert current users.
> 
> acpi_str_to_uuid() becomes useless after the conversion and it's safe
> to
> get rid of it.
> 
> The conversion fixes a potential bug in int340x_thermal as well since
> we have to use memcmp() on binary data.
> 
> Cc: Rafael J. Wysocki 
> Cc: Mika Westerberg 
> Cc: Borislav Petkov 
> Cc: Dan Williams 
> Cc: Amir Goldstein 
> Cc: Jarkko Sakkinen 
> Cc: Jani Nikula 
> Cc: Ben Skeggs 
> Cc: Benjamin Tissoires 
> Cc: Joerg Roedel 
> Cc: Adrian Hunter 
> Cc: Yisen Zhuang 
> Cc: Bjorn Helgaas 
> Cc: Zhang Rui 
> Cc: Felipe Balbi 
> Cc: Mathias Nyman 
> Cc: Heikki Krogerus 
> Cc: Liam Girdwood 
> Cc: Mark Brown 
> Signed-off-by: Andy Shevchenko 
> ---
> 
> diff --git a/drivers/thermal/int340x_thermal/int3400_thermal.c
> b/drivers/thermal/int340x_thermal/int3400_thermal.c
> index 9413c4abf0b9..c0eb3bb19b23 100644
> --- a/drivers/thermal/int340x_thermal/int3400_thermal.c
> +++ b/drivers/thermal/int340x_thermal/int3400_thermal.c
> @@ -23,7 +23,7 @@ enum int3400_thermal_uuid {
>   INT3400_THERMAL_MAXIMUM_UUID,
>  };
>  
> -static u8 *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
> +static const char
> *int3400_thermal_uuids[INT3400_THERMAL_MAXIMUM_UUID] = {
>   "42A441D6-AE6A-462b-A84B-4A8CE79027D3",
>   "3A95C389-E4B8-4629-A526-C52C88626BAE",
>   "97C68AE7-15FA-499c-B8C9-5DA81D606E0A",
> @@ -141,10 +141,10 @@ static int int3400_thermal_get_uuids(struct
> int3400_thermal_priv *priv)
>   }
>  
>   for (j = 0; j < INT3400_THERMAL_MAXIMUM_UUID; j++) {
> - u8 uuid[16];
> + uuid_le u;
>  
> - acpi_str_to_uuid(int3400_thermal_uuids[j],
> uuid);
> - if (!strncmp(uuid, objb->buffer.pointer,
> 16)) {
> + uuid_le_to_bin(int3400_thermal_uuids[j],
> );
> + if (!uuid_le_cmp(*(uuid_le *)objb-
> >buffer.pointer), u) {
>   priv->uuid_bitmap |= (1 << j);
>   break;
>   }
thanks for the fix.

Acked-by: Zhang Rui 

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

Re: [Intel-gfx] [PATCH v5 3/9] drm/i915: Drop AUX backlight enable check for backlight control

[Puthikorn Voravootivat]

> How is backlight enabled in this case?
Using eDP BL_ENABLE pin

On Sat, May 6, 2017 at 1:59 AM, Pandiyan, Dhinakaran <
dhinakaran.pandi...@intel.com> wrote:

> On Wed, 2017-05-03 at 17:28 -0700, Puthikorn Voravootivat wrote:
> > There are some panel that
> > (1) does not support display backlight enable via AUX
> > (2) support display backlight adjustment via AUX
> > (3) support display backlight enable via eDP BL_ENABLE pin
> >
> > The current driver required that (1) must be support to enable (2).
> > This patch drops that requirement.
> >
> > Signed-off-by: Puthikorn Voravootivat 
> > ---
> >  drivers/gpu/drm/i915/intel_dp_aux_backlight.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > index ad8560c5f689..5b83c9737644 100644
> > --- a/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > +++ b/drivers/gpu/drm/i915/intel_dp_aux_backlight.c
> > @@ -28,6 +28,10 @@ static void set_aux_backlight_enable(struct intel_dp
> *intel_dp, bool enable)
> >  {
> >   uint8_t reg_val = 0;
> >
> > +   /* Early return when display use other mechanism to enable
> backlight. */
> > + if (!(intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP))
> > + return;
> > +
>
> How is backlight enabled in this case?
>
> -DK
>
> >   if (drm_dp_dpcd_readb(_dp->aux, DP_EDP_DISPLAY_CONTROL_
> REGISTER,
> > _val) < 0) {
> >   DRM_DEBUG_KMS("Failed to read DPCD register 0x%x\n",
> > @@ -164,7 +168,6 @@ intel_dp_aux_display_control_capable(struct
> intel_connector *connector)
> >* the panel can support backlight control over the aux channel
> >*/
> >   if ((intel_dp->edp_dpcd[1] & DP_EDP_TCON_BACKLIGHT_ADJUSTMENT_CAP)
> &&
> > - (intel_dp->edp_dpcd[1] & DP_EDP_BACKLIGHT_AUX_ENABLE_CAP) &&
> >   (intel_dp->edp_dpcd[2] & DP_EDP_BACKLIGHT_BRIGHTNESS_AUX_SET_CAP))
> {
> >   DRM_DEBUG_KMS("AUX Backlight Control Supported!\n");
> >   return true;
>
>
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Move uncore definitions into a separate header

[Mika Kuoppala]

Michal Wajdeczko  writes:

> In order to allow use of e.g. forcewake_domains in a other feature headers
> included from the top of i915_drv.h, move all uncore related definitions
> into their own header.
>
> v2: move __mask_next_bit macro to utils header (Mika)
>
> Signed-off-by: Michal Wajdeczko 
> Suggested-by: Joonas Lahtinen 
> Cc: Joonas Lahtinen 
> Cc: Mika Kuoppala 

Pushed 1/2. 2/2 needs more tasting. Thanks for patch!
-Mika

> ---
>  drivers/gpu/drm/i915/i915_drv.h | 157 +
>  drivers/gpu/drm/i915/i915_utils.h   |   6 ++
>  drivers/gpu/drm/i915/intel_uncore.c |  12 +++
>  drivers/gpu/drm/i915/intel_uncore.h | 169 
> 
>  4 files changed, 188 insertions(+), 156 deletions(-)
>  create mode 100644 drivers/gpu/drm/i915/intel_uncore.h
>
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index b20ed16..29a6966 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -55,6 +55,7 @@
>  #include "i915_reg.h"
>  #include "i915_utils.h"
>  
> +#include "intel_uncore.h"
>  #include "intel_bios.h"
>  #include "intel_dpll_mgr.h"
>  #include "intel_uc.h"
> @@ -676,116 +677,6 @@ struct drm_i915_display_funcs {
>   void (*load_luts)(struct drm_crtc_state *crtc_state);
>  };
>  
> -enum forcewake_domain_id {
> - FW_DOMAIN_ID_RENDER = 0,
> - FW_DOMAIN_ID_BLITTER,
> - FW_DOMAIN_ID_MEDIA,
> -
> - FW_DOMAIN_ID_COUNT
> -};
> -
> -enum forcewake_domains {
> - FORCEWAKE_RENDER = BIT(FW_DOMAIN_ID_RENDER),
> - FORCEWAKE_BLITTER = BIT(FW_DOMAIN_ID_BLITTER),
> - FORCEWAKE_MEDIA = BIT(FW_DOMAIN_ID_MEDIA),
> - FORCEWAKE_ALL = (FORCEWAKE_RENDER |
> -  FORCEWAKE_BLITTER |
> -  FORCEWAKE_MEDIA)
> -};
> -
> -#define FW_REG_READ  (1)
> -#define FW_REG_WRITE (2)
> -
> -enum decoupled_power_domain {
> - GEN9_DECOUPLED_PD_BLITTER = 0,
> - GEN9_DECOUPLED_PD_RENDER,
> - GEN9_DECOUPLED_PD_MEDIA,
> - GEN9_DECOUPLED_PD_ALL
> -};
> -
> -enum decoupled_ops {
> - GEN9_DECOUPLED_OP_WRITE = 0,
> - GEN9_DECOUPLED_OP_READ
> -};
> -
> -enum forcewake_domains
> -intel_uncore_forcewake_for_reg(struct drm_i915_private *dev_priv,
> -i915_reg_t reg, unsigned int op);
> -
> -struct intel_uncore_funcs {
> - void (*force_wake_get)(struct drm_i915_private *dev_priv,
> -enum forcewake_domains domains);
> - void (*force_wake_put)(struct drm_i915_private *dev_priv,
> -enum forcewake_domains domains);
> -
> - uint8_t  (*mmio_readb)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint16_t (*mmio_readw)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint32_t (*mmio_readl)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> - uint64_t (*mmio_readq)(struct drm_i915_private *dev_priv,
> -i915_reg_t r, bool trace);
> -
> - void (*mmio_writeb)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint8_t val, bool trace);
> - void (*mmio_writew)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint16_t val, bool trace);
> - void (*mmio_writel)(struct drm_i915_private *dev_priv,
> - i915_reg_t r, uint32_t val, bool trace);
> -};
> -
> -struct intel_forcewake_range {
> - u32 start;
> - u32 end;
> -
> - enum forcewake_domains domains;
> -};
> -
> -struct intel_uncore {
> - spinlock_t lock; /** lock is also taken in irq contexts. */
> -
> - const struct intel_forcewake_range *fw_domains_table;
> - unsigned int fw_domains_table_entries;
> -
> - struct notifier_block pmic_bus_access_nb;
> - struct intel_uncore_funcs funcs;
> -
> - unsigned fifo_count;
> -
> - enum forcewake_domains fw_domains;
> - enum forcewake_domains fw_domains_active;
> -
> - u32 fw_set;
> - u32 fw_clear;
> - u32 fw_reset;
> -
> - struct intel_uncore_forcewake_domain {
> - enum forcewake_domain_id id;
> - enum forcewake_domains mask;
> - unsigned wake_count;
> - struct hrtimer timer;
> - i915_reg_t reg_set;
> - i915_reg_t reg_ack;
> - } fw_domain[FW_DOMAIN_ID_COUNT];
> -
> - int unclaimed_mmio_check;
> -};
> -
> -#define __mask_next_bit(mask) ({ \
> - int __idx = ffs(mask) - 1;  \
> - mask &= ~BIT(__idx);\
> - __idx;  \
> -})
> -
> -/* Iterate over 

Re: [Intel-gfx] [PATCH] drm/i915: Show dmc debug registers on Kabylake

[Mika Kuoppala]

Imre Deak  writes:

> On Tue, May 09, 2017 at 01:05:22PM +0300, Mika Kuoppala wrote:
>> The assumption is that the registers offsets are
>> identical as with skl. Also all the published
>> kbl firmwares support the debug registers. So
>> let kbl show the debug counts.
>> 
>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100975
>> Cc: Imre Deak 
>> Signed-off-by: Mika Kuoppala 
>
> Reviewed-by: Imre Deak 

Pushed. Thanks for review!
-Mika


>
>> ---
>>  drivers/gpu/drm/i915/i915_debugfs.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>> 
>> diff --git a/drivers/gpu/drm/i915/i915_debugfs.c 
>> b/drivers/gpu/drm/i915/i915_debugfs.c
>> index 1003511..34785fb 100644
>> --- a/drivers/gpu/drm/i915/i915_debugfs.c
>> +++ b/drivers/gpu/drm/i915/i915_debugfs.c
>> @@ -2853,7 +2853,8 @@ 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_priv) && csr->version >= CSR_VERSION(1, 6)) {
>> +if (IS_KABYLAKE(dev_priv) ||
>> +(IS_SKYLAKE(dev_priv) && 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",
>> -- 
>> 2.7.4
>> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

[Chris Wilson]

On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote:
> From: Tvrtko Ursulin 
> 
> By popular customer demand here is the prototype for cheap engine utilization
> tracking.

customer and debugfs?

> It uses static branches so in the default off case it really should be cheap.

Not as cheap (for the off case) as simply sampling RING_HEAD/RING_TAIL
which looks to be the same level of detail. I wrapped all this up in a
perf interface once up a time...
-Chris

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

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

[Patchwork]

== Series Details ==

Series: series starting with [1/5] drm/vblank: Switch 
drm_driver->get_vblank_timestamp to return a bool
URL   : https://patchwork.freedesktop.org/series/24175/
State : success

== Summary ==

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

Test gem_exec_flush:
Subgroup basic-batch-kernel-default-uc:
fail   -> PASS   (fi-snb-2600) fdo#17

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:442s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:439s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:581s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:515s
fi-bxt-t5700 total:278  pass:258  dwarn:0   dfail:0   fail:0   skip:20  
time:554s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:493s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:494s
fi-elk-e7500 total:278  pass:229  dwarn:0   dfail:0   fail:0   skip:49  
time:429s
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:415s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:416s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:430s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:500s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:471s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:465s
fi-kbl-7560u total:278  pass:267  dwarn:1   dfail:0   fail:0   skip:10  
time:578s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:460s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:577s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:473s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:494s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:437s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:538s
fi-snb-2600  total:278  pass:249  dwarn:0   dfail:0   fail:0   skip:29  
time:412s

417babaa12ad98dad2c39f361612f1afe6894816 drm-tip: 2017y-05m-09d-13h-13m-23s UTC 
integration manifest
98cae38 drm/vblank: Lock down vblank->hwmode more
1aa840a8 drm/vblank: drop the mode argument from 
drm_calc_vbltimestamp_from_scanoutpos
9a888d8 drm/vblank: Add FIXME comments about moving the vblank ts hooks
97f3ff6 drm/vblank: Switch to bool in_vblank_irq in get_vblank_timestamp
1cee7b4 drm/vblank: Switch drm_driver->get_vblank_timestamp to return a bool

== Logs ==

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

Re: [Intel-gfx] vlv_disable_backlight causing warnings with i915 @ Xorg start

[Andrew Siplas]

FWIW the HDMI connector was in use at the time--plugged in and mirroring
from boot, then (auto-)switching over to extending desktop at X start--
backlight possibly flicks off/on briefly while starting X/expanding to
HDMI.


On May  9 16:34:10, Ville Syrjälä wrote:
> On Mon, May 08, 2017 at 09:27:36AM -0400, Andrew Siplas wrote:
> > At Xorg startup after a fresh compile of the mainline kernel, WARN_ON is
> > truthy and throws a warning into the kernel's dmesg buffer.
> > 
> > I'm still trying to understand the driver, but it originates here:
> > 
> > --
> > 
> > static void vlv_disable_backlight(struct intel_connector *connector)
> > {
> > struct drm_i915_private *dev_priv =
> > to_i915(connector->base.dev);
> > enum pipe pipe = intel_get_pipe_from_connector(connector);
> 
> Not sure why that's not working anymore. Did we stop updating the legacy
> connector<->crtc linkage or something?
> 
> Anyway we would need to eliminate that guy and instead pass down the
> correct atomic state from higher up. Maarten, did you have patches
> for that already?
> 
> > u32 tmp;
> > 
> > if (WARN_ON(pipe != PIPE_A && pipe != PIPE_B))
> > return;
> > 
> > intel_panel_actually_set_backlight(connector, 0);
> > 
> > tmp = I915_READ(VLV_BLC_PWM_CTL2(pipe));
> > I915_WRITE(VLV_BLC_PWM_CTL2(pipe), tmp & ~BLM_PWM_ENABLE);
> > }
> > 
> > --
> > 
> > Don't know yet what this means and so taking a chance this warning is
> > something someone here might have some insight into / want to know about
> > especially given the "...[ cut here ]...".
> > 
> > The last two lines are from 5+ minutes after the warning but seem related:
> > 
> > 
> > [   67.896233] [ cut here ]
> > [   67.896259] WARNING: CPU: 1 PID: 4276 at 
> > drivers/gpu/drm/i915/intel_panel.c:771 vlv_disable_backlight+0x86/0x90
> > [   67.896261] Modules linked in: iptable_nat nf_nat_ipv4 nf_nat uvcvideo 
> > videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev
> > [   67.896299] CPU: 1 PID: 4276 Comm: Xorg Not tainted 4.11.0+ #2
> > [   67.896303] Hardware name: HP HP Notebook/80C5, BIOS F.1E 12/25/2015
> > [   67.896308] task: 8d6e75d79800 task.stack: 9a06c1218000
> > [   67.896318] RIP: 0010:vlv_disable_backlight+0x86/0x90
> > [   67.896323] RSP: 0018:9a06c121b998 EFLAGS: 00010286
> > [   67.896330] RAX: 0029 RBX: 8d6e76018000 RCX: 
> > 8ea56a78
> > [   67.896335] RDX: 0001 RSI: 0092 RDI: 
> > 8ece6bcc
> > [   67.896339] RBP: 9a06c121b9b0 R08: 0029 R09: 
> > 02d8
> > [   67.896344] R10:  R11: 0320 R12: 
> > 8d6e723c5000
> > [   67.896348] R13:  R14: 8d6e7423e800 R15: 
> > 8d6e74ab9830
> > [   67.896355] FS:  7fb8d7e00a40() GS:8d6e7fc8() 
> > knlGS:
> > [   67.896359] CS:  0010 DS:  ES:  CR0: 80050033
> > [   67.896364] CR2: 557bfe77dfd0 CR3: 000274d31000 CR4: 
> > 001006e0
> > [   67.896368] Call Trace:
> > [   67.896383]  intel_panel_disable_backlight+0x51/0x80
> > [   67.896391]  intel_edp_backlight_off+0x42/0x50
> > [   67.896397]  intel_disable_dp+0x70/0xf0
> > [   67.896407]  intel_encoders_disable.isra.103+0x82/0x90
> > [   67.896416]  i9xx_crtc_disable+0x51/0x3b0
> > [   67.896424]  ? intel_crtc_disable_planes+0xd4/0xf0
> > [   67.896434]  intel_atomic_commit_tail+0x892/0xfb0
> > [   67.896444]  ? insert_work+0x52/0x70
> > [   67.896453]  ? __queue_work+0x12e/0x390
> > [   67.896461]  ? intel_atomic_commit_ready+0x70/0x80
> > [   67.896470]  intel_atomic_commit+0x3e6/0x4b0
> > [   67.896479]  ? handle_conflicting_encoders+0x279/0x290
> > [   67.896489]  drm_atomic_commit+0x46/0x50
> > [   67.896497]  drm_atomic_helper_set_config+0x6b/0xa0
> > [   67.896507]  __drm_mode_set_config_internal+0x62/0x110
> > [   67.896514]  drm_mode_setcrtc+0x4ba/0x5a0
> > [   67.896524]  drm_ioctl+0x326/0x430
> > [   67.896532]  ? drm_mode_getcrtc+0x170/0x170
> > [   67.896543]  do_vfs_ioctl+0x8f/0x5a0
> > [   67.896552]  ? getnstimeofday64+0x9/0x20
> > [   67.896561]  SyS_ioctl+0x74/0x80
> > [   67.896569]  do_syscall_64+0x48/0xb0
> > [   67.896580]  entry_SYSCALL64_slow_path+0x25/0x25
> > [   67.896586] RIP: 0033:0x7fb8d5932507
> > [   67.896590] RSP: 002b:7ffe8bf43018 EFLAGS: 3246 ORIG_RAX: 
> > 0010
> > [   67.896598] RAX: ffda RBX: 561b92c11210 RCX: 
> > 7fb8d5932507
> > [   67.896602] RDX: 7ffe8bf43140 RSI: c06864a2 RDI: 
> > 0009
> > [   67.896607] RBP: 7ffe8bf43140 R08: 561b92c11050 R09: 
> > 0001
> > [   67.896611] R10: 0001 R11: 3246 R12: 
> > c06864a2
> > [   67.896615] R13: 0009 R14: 561b92c13f70 R15: 
> > 7fb8d7d67000
> > [   67.896620] Code: df 41 8d b4 05 50 12 06 00 ff 93 f8 06 00 00 5b 41 5c 
> > 

[Intel-gfx] ✓ Fi.CI.BAT: success for Engine utilization tracking

[Patchwork]

== Series Details ==

Series: Engine utilization tracking
URL   : https://patchwork.freedesktop.org/series/24177/
State : success

== Summary ==

Series 24177v1 Engine utilization tracking
https://patchwork.freedesktop.org/api/1.0/series/24177/revisions/1/mbox/

Test gem_exec_fence:
Subgroup await-hang-default:
pass   -> SKIP   (fi-elk-e7500) fdo#100942
Test gem_exec_suspend:
Subgroup basic-s4-devices:
dmesg-warn -> PASS   (fi-kbl-7560u) fdo#100125

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

fi-bdw-5557u total:278  pass:267  dwarn:0   dfail:0   fail:0   skip:11  
time:444s
fi-bdw-gvtdvmtotal:278  pass:256  dwarn:8   dfail:0   fail:0   skip:14  
time:432s
fi-bsw-n3050 total:278  pass:242  dwarn:0   dfail:0   fail:0   skip:36  
time:573s
fi-bxt-j4205 total:278  pass:259  dwarn:0   dfail:0   fail:0   skip:19  
time:520s
fi-byt-j1900 total:278  pass:254  dwarn:0   dfail:0   fail:0   skip:24  
time:492s
fi-byt-n2820 total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:486s
fi-elk-e7500 total:278  pass:9dwarn:1   dfail:0   fail:0   skip:72 
fi-hsw-4770  total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:418s
fi-hsw-4770r total:278  pass:262  dwarn:0   dfail:0   fail:0   skip:16  
time:406s
fi-ilk-650   total:278  pass:228  dwarn:0   dfail:0   fail:0   skip:50  
time:421s
fi-ivb-3520m total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:494s
fi-ivb-3770  total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:466s
fi-kbl-7500u total:278  pass:260  dwarn:0   dfail:0   fail:0   skip:18  
time:461s
fi-kbl-7560u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:574s
fi-skl-6260u total:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:457s
fi-skl-6700hqtotal:278  pass:261  dwarn:0   dfail:0   fail:0   skip:17  
time:579s
fi-skl-6700k total:278  pass:256  dwarn:4   dfail:0   fail:0   skip:18  
time:465s
fi-skl-6770hqtotal:278  pass:268  dwarn:0   dfail:0   fail:0   skip:10  
time:499s
fi-skl-gvtdvmtotal:278  pass:265  dwarn:0   dfail:0   fail:0   skip:13  
time:436s
fi-snb-2520m total:278  pass:250  dwarn:0   dfail:0   fail:0   skip:28  
time:537s
fi-snb-2600  total:278  pass:248  dwarn:0   dfail:0   fail:1   skip:29  
time:410s
fi-bxt-t5700 failed to collect. IGT log at Patchwork_4650/fi-bxt-t5700/igt.log

417babaa12ad98dad2c39f361612f1afe6894816 drm-tip: 2017y-05m-09d-13h-13m-23s UTC 
integration manifest
f561414 drm/i915: Export engine busy stats in debugfs
3a7db31 drm/i915: Engine busy time tracking
fa5b8d0 drm/i915: Wrap context schedule notification

== Logs ==

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

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

[Tvrtko Ursulin]

On 09/05/2017 15:26, Chris Wilson wrote:

On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote:

From: Tvrtko Ursulin 

By popular customer demand here is the prototype for cheap engine utilization
tracking.


customer and debugfs?


Well I did write in one of the following paragraphs on this topic. 
Perhaps I should have put it in procfs. :) Sysfs API looks restrictive 
or perhaps I missed a way to get low level (fops) access to it.



It uses static branches so in the default off case it really should be cheap.


Not as cheap (for the off case) as simply sampling RING_HEAD/RING_TAIL


Off case are three no-op instructions in three places in the irq 
tasklet. And a little bit of object size growth, if you worry about that 
aspect?



which looks to be the same level of detail. I wrapped all this up in a
perf interface once up a time...


How does that work? Via periodic sampling? Accuracy sounds like it would 
be proportionate to the sampling frequency, no?


Regards,

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

Re: [Intel-gfx] [PATCH 03/11] drm: parse ycbcr 420 vdb block

[Ville Syrjälä]

On Tue, May 09, 2017 at 02:04:55PM +0530, Sharma, Shashank wrote:
> Regards
> 
> Shashank
> 
> 
> On 5/8/2017 10:39 PM, Ville Syrjälä wrote:
> > On Mon, May 08, 2017 at 10:11:53PM +0530, Sharma, Shashank wrote:
> >> Regards
> >>
> >> Shashank
> >>
> >>
> >> On 5/8/2017 9:54 PM, Ville Syrjälä wrote:
> >>> On Fri, Apr 07, 2017 at 07:39:20PM +0300, Shashank Sharma wrote:
>  From: Jose Abreu 
> 
>  HDMI 2.0 spec adds support for ycbcr420 subsampled output.
>  CEA-861-F adds two new blocks in EDID, to provide information about
>  sink's support for ycbcr420 output.
> 
>  These new blocks are:
>  - ycbcr420 video data (vdb) block: video modes which can be supported
>  only in ycbcr420 output mode.
>  - ycbcr420 video capability data (vcb) block: video modes which can be
>  support in ycbcr420 output mode also (along with RGB, YCBCR 444/422 
>  etc)
> 
>  This patch adds parsing and handling of ycbcr420-vdb in the DRM
>  layer.
> 
>  This patch is a modified version of Jose's RFC patch:
>  https://patchwork.kernel.org/patch/9492327/
>  so the authorship is maintained.
> 
>  Cc: Ville Syrjala 
>  Signed-off-by: Jose Abreu 
>  Signed-off-by: Shashank Sharma 
>  ---
> drivers/gpu/drm/drm_edid.c  | 54 
>  +++--
> drivers/gpu/drm/drm_modes.c | 10 +++--
> include/drm/drm_connector.h |  1 +
> include/uapi/drm/drm_mode.h |  6 +
> 4 files changed, 67 insertions(+), 4 deletions(-)
> >>> 
>  diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
>  index 4eeda12..cef76b2 100644
>  --- a/include/drm/drm_connector.h
>  +++ b/include/drm/drm_connector.h
>  @@ -199,6 +199,7 @@ struct drm_display_info {
> #define DRM_COLOR_FORMAT_RGB444   (1<<0)
> #define DRM_COLOR_FORMAT_YCRCB444 (1<<1)
> #define DRM_COLOR_FORMAT_YCRCB422 (1<<2)
>  +#define DRM_COLOR_FORMAT_YCRCB420   (1<<2)
> 
>   /**
>    * @color_formats: HDMI Color formats, selects between RGB and 
>  YCrCb
>  diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
>  index 8c67fc0..1e74d8e 100644
>  --- a/include/uapi/drm/drm_mode.h
>  +++ b/include/uapi/drm/drm_mode.h
>  @@ -84,6 +84,12 @@ extern "C" {
> #define  DRM_MODE_FLAG_3D_L_DEPTH_GFX_GFX_DEPTH   (6<<14)
> #define  DRM_MODE_FLAG_3D_TOP_AND_BOTTOM  (7<<14)
> #define  DRM_MODE_FLAG_3D_SIDE_BY_SIDE_HALF   (8<<14)
>  +/*
>  + * HDMI 2.0
>  + */
>  +#define DRM_MODE_FLAG_420_MASK  (0x03<<23)
>  +#define  DRM_MODE_FLAG_420  (1<<23)
>  +#define  DRM_MODE_FLAG_420_ONLY (1<<24)
> >>> Adding those would again break the uabi. We can't add new mode flags
> >>> without some kind of client cap.
> >>> But I think we agreed that new user
> >>> space visible mode flags aren't needed, and instad we can keep it all
> >>> internal?
> >> Yep you are right, we had decided to keep it internal, and this whole
> >> patch series is implemented in such a way only, to control everything
> >> through the HDMI output property itself.
> >> But may be I slightly misunderstood that we shouldn't add the flags bits
> >> all together, and I added this flag to differentiate between YCBCR420
> >> and notmal modes.
> >> Can you please suggest me on:
> >> - how to differentiate a YCBCR420 mode with normal mode ? I still need
> >> to add a flag, but not expose it into uapi layer.
> > I guess we can just tack on a few new bools to the end of
> > drm_display_mode. And then when we get the mode passed in by the user
> > we'll have to check whether that mode matches any CEA mode and
> > then look up the correct YCbCr 4:2:0 mode for it.
> seems good to me, I can add a is_ycbcr420 flag, and we need not to 
> bother about converting it to drm_mode_modeinfo as we are keeping it 
> internal.
> >
> > Hmm. Actually, that probably means that it isn't sufficient to
> > actually store this information on the modes we have on the connector's
> > mode list, because that list has been filtered and so may not actually
> > have all the modes that were declared in the EDID.
> I dint get this point,  Why do you think its not sufficient ? Do we need 
> to care about the modes which are getting rejected from the driver ?

Yes, that was my worry. In general I don't think connector->modes should
ever be used for mode validation or state computation. Eg. if fbdev
handled the previus hotplug connector->modes will have been filtered
based on the size of the fb_helper framebuffer, and then a new master
might just blindly come in and blindly set a new mode without doing a
full connector probe.

> I guess they cant be applied 

Re: [Intel-gfx] [RFC 0/3] Engine utilization tracking

[Chris Wilson]

On Tue, May 09, 2017 at 04:16:41PM +0100, Tvrtko Ursulin wrote:
> 
> On 09/05/2017 15:26, Chris Wilson wrote:
> >On Tue, May 09, 2017 at 03:09:33PM +0100, Tvrtko Ursulin wrote:
> >>From: Tvrtko Ursulin 
> >>
> >>By popular customer demand here is the prototype for cheap engine 
> >>utilization
> >>tracking.
> >
> >customer and debugfs?
> 
> Well I did write in one of the following paragraphs on this topic.
> Perhaps I should have put it in procfs. :) Sysfs API looks
> restrictive or perhaps I missed a way to get low level (fops) access
> to it.
> 
> >>It uses static branches so in the default off case it really should be 
> >>cheap.
> >
> >Not as cheap (for the off case) as simply sampling RING_HEAD/RING_TAIL
> 
> Off case are three no-op instructions in three places in the irq
> tasklet. And a little bit of object size growth, if you worry about
> that aspect?

It's just how the snowball begins.
 
> >which looks to be the same level of detail. I wrapped all this up in a
> >perf interface once up a time...
> 
> How does that work? Via periodic sampling? Accuracy sounds like it
> would be proportionate to the sampling frequency, no?

Right, and the sampling frequency is under user control (via perf) with
a default of around 1000, gives a small systematic error when dealing with %

I included power, interrupts, rc6, frequency (and the statistics but I
never used those and dropped them once oa landed), as well as
utilisation, just for the convenience of having sane interface :)
-Chris

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