[Intel-gfx] [PATCH CI run 3/3] drm/i915: Adding the parsing logic for the i2c element

[Mika Kahola]

New sequence element for i2c is been added in the
mipi sequence block of the VBT. This patch parses
and executes the i2c sequence.

v2: Add i2c_put_adapter call(Jani), rebase

v3: corrected the retry loop(Jani), rebase

v4 by Jani:
 - don't put the adapter if get fails
  - print an error message if all retries exhausted
   - use a for loop
- fix warnings for unused variables

v5 by Jani:
 - rebase on the skip i2c element patch

v6: by Jani:
 - ignore the gmbus i2c elements (Ville)

v7: by Deepak
 - Use the i2c port number which is read from ACPI
based on the resource id.

v8: by Mika
 - rebase

Cc: Ville Syrjälä 
Signed-off-by: vkorjani 
Signed-off-by: Deepak M 
Signed-off-by: Jani Nikula 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 78 +-
 1 file changed, 76 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index a4cbe68..7fe57c2 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -1004,9 +1004,83 @@ static const u8 *mipi_exec_gpio(struct intel_dsi 
*intel_dsi, const u8 *data)
 
 static const u8 *mipi_exec_i2c(struct intel_dsi *intel_dsi, const u8 *data)
 {
-   DRM_DEBUG_KMS("Skipping I2C element execution\n");
+   struct drm_i915_private *dev_priv = 
intel_dsi->base.base.dev->dev_private;
+   struct i2c_adapter *adapter;
+   int ret, i;
+   u8 reg_offset, payload_size;
+   struct i2c_msg msg;
+   struct acpi_i2c_data_node *i2c_entry = NULL;
+   u8 *transmit_buffer;
+   u8 flag, resource_id, bus_number;
+   u16 slave_add;
+   u8 count = 0;
+
+   flag = *data++;
+   resource_id = *data++;
+   bus_number = *data++;
+   slave_add = *(u16 *)(data);
+   data += 2;
+   reg_offset = *data++;
+   payload_size = *data++;
+
+   if (resource_id == 0xff || bus_number == 0xff) {
+   DRM_DEBUG_KMS("ignoring gmbus (resource id %02x, bus %02x)\n",
+ resource_id, bus_number);
+   goto out;
+   }
+
+   /* Parse the list and get the required i2c bus number */
+   list_for_each_entry(i2c_entry, _priv->acpi_i2c_list,
+   head) {
+   if (count == resource_id) {
+   /* override the busnumber */
+   bus_number = i2c_entry->i2c_bus_number;
+   break;
+   }
+   count++;
+   }
+
+   /*
+* Since the i2c bus number indexing in BIOS starts from 1
+* decrementing the bus number which we are reading.
+*/
+   bus_number--;
 
-   return data + *(data + 6) + 7;
+   adapter = i2c_get_adapter(bus_number);
+   if (!adapter) {
+   DRM_ERROR("i2c_get_adapter(%u)\n", bus_number);
+   goto out;
+   }
+
+   transmit_buffer = kmalloc(1 + payload_size, GFP_TEMPORARY);
+   if (!transmit_buffer)
+   goto out_put;
+
+   transmit_buffer[0] = reg_offset;
+   memcpy(_buffer[1], data, payload_size);
+
+   msg.addr = slave_add;
+   msg.flags = 0;
+   msg.len = payload_size + 1;
+   msg.buf = _buffer[0];
+
+   for (i = 0; i < 6; i++) {
+   ret = i2c_transfer(adapter, , 1);
+   if (ret == 1)
+   goto out_free;
+   else if (ret == -EAGAIN)
+   usleep_range(1000, 2500);
+   else
+   break;
+   }
+
+   DRM_ERROR("i2c transfer failed: %d\n", ret);
+out_free:
+   kfree(transmit_buffer);
+out_put:
+   i2c_put_adapter(adapter);
+out:
+   return data + payload_size;
 }
 
 static const u8 *mipi_exec_spi(struct intel_dsi *intel_dsi, const u8 *data)
-- 
2.7.4

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

[Intel-gfx] [PATCH CI run 0/3] MIPI/DSI display support for APL

[Mika Kahola]

Test MIPI/DSI display suspend/resume cycle on Apollolake.

Jani Nikula (1):
  drm/i915/bxt: add bxt dsi gpio element support

Mika Kahola (2):
  drm/i915: Get the i2c bus number from the ACPI
  drm/i915: Adding the parsing logic for the i2c element

 drivers/gpu/drm/i915/i915_drv.c|   2 +
 drivers/gpu/drm/i915/i915_drv.h|  10 +
 drivers/gpu/drm/i915/intel_acpi.c  |  59 +++
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 745 -
 4 files changed, 813 insertions(+), 3 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH CI run 2/3] drm/i915: Get the i2c bus number from the ACPI

[Mika Kahola]

Currently for executing the i2c MIPI sequence, we are
relaying on the i2c bus bunmber which is specified in the
VBT. But there are cases where different Fab versions of
the board will drive the same chip with different i2c port,
in which case the i2c bus number from the VBT cant be relied
on. To overcome this the i2c bus number is read from the
BIOS acpi table; BIOS can detect the Fab version in runtime
and will store the correct i2c bus number in the ACPI table.

v2 by Deepak:
 - Reading the i2c from the ACPI and storing them in list

v3 by Mika:
 - rebase

Cc: Jani Nikula 
Cc: Ville Syrjälä 
Signed-off-by: Deepak M 
Signed-off-by: Mika Kahola 
---
 drivers/gpu/drm/i915/i915_drv.c   |  2 ++
 drivers/gpu/drm/i915/i915_drv.h   | 10 +++
 drivers/gpu/drm/i915/intel_acpi.c | 59 +++
 3 files changed, 71 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_drv.c b/drivers/gpu/drm/i915/i915_drv.c
index 4f0e56d..563756e 100644
--- a/drivers/gpu/drm/i915/i915_drv.c
+++ b/drivers/gpu/drm/i915/i915_drv.c
@@ -580,6 +580,8 @@ static int i915_load_modeset_init(struct drm_device *dev)
 
intel_register_dsm_handler();
 
+   intel_acpi_find_i2c(dev_priv);
+
ret = vga_switcheroo_register_client(pdev, _switcheroo_ops, false);
if (ret)
goto cleanup_vga_client;
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 006914c..0a6ad9f 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -33,6 +33,7 @@
 #include 
 #include 
 
+#include 
 #include 
 #include 
 #include 
@@ -1778,6 +1779,12 @@ struct intel_wm_config {
bool sprites_scaled;
 };
 
+struct acpi_i2c_data_node {
+   struct list_head head;
+   int i2c_bus_number;
+   int i2c_slave_address;
+};
+
 struct drm_i915_private {
struct drm_device drm;
 
@@ -1870,6 +1877,8 @@ struct drm_i915_private {
/* backlight registers and fields in struct intel_panel */
struct mutex backlight_lock;
 
+   struct list_head acpi_i2c_list;
+
/* LVDS info */
bool no_aux_handshake;
 
@@ -3444,6 +3453,7 @@ static inline int intel_opregion_get_panel_type(struct 
drm_i915_private *dev)
 #ifdef CONFIG_ACPI
 extern void intel_register_dsm_handler(void);
 extern void intel_unregister_dsm_handler(void);
+extern acpi_status intel_acpi_find_i2c(struct drm_i915_private *dev_priv);
 #else
 static inline void intel_register_dsm_handler(void) { return; }
 static inline void intel_unregister_dsm_handler(void) { return; }
diff --git a/drivers/gpu/drm/i915/intel_acpi.c 
b/drivers/gpu/drm/i915/intel_acpi.c
index eb638a1..1b18c89 100644
--- a/drivers/gpu/drm/i915/intel_acpi.c
+++ b/drivers/gpu/drm/i915/intel_acpi.c
@@ -110,6 +110,65 @@ static void intel_dsm_platform_mux_info(void)
ACPI_FREE(pkg);
 }
 
+static int i2c_acpi_get_name(struct acpi_resource *ares, void *data)
+{
+   struct drm_i915_private *dev_priv = data;
+   struct acpi_resource_i2c_serialbus *sb;
+   unsigned int val;
+   char *resource;
+   int error;
+
+
+   if (ares->type == ACPI_RESOURCE_TYPE_SERIAL_BUS) {
+   sb = >data.i2c_serial_bus;
+
+   if (sb->type == ACPI_RESOURCE_SERIAL_TYPE_I2C) {
+   struct acpi_i2c_data_node *i2c_entry = NULL;
+
+   resource = sb->resource_source.string_ptr;
+   resource = strstr(resource, "I2C");
+   error = kstrtouint(resource+3, 0, );
+   if (error)
+   return error;
+
+   i2c_entry = kzalloc(sizeof(struct acpi_i2c_data_node),
+   GFP_NOWAIT);
+   i2c_entry->i2c_bus_number = val;
+   i2c_entry->i2c_slave_address = sb->slave_address;
+
+   list_add_tail(_entry->head,
+   _priv->acpi_i2c_list);
+   }
+   }
+
+   return 1;
+}
+
+acpi_status intel_acpi_find_i2c(struct drm_i915_private *dev_priv)
+{
+   struct pci_dev *pdev = dev_priv->drm.pdev;
+   struct list_head resource_list;
+   struct acpi_device *adev;
+   acpi_handle dhandle;
+
+   dhandle = ACPI_HANDLE(>dev);
+   if (!dhandle)
+   return false;
+
+   if (acpi_bus_get_device(dhandle, ))
+   return AE_OK;
+   if (acpi_bus_get_status(adev) || !adev->status.present)
+   return AE_OK;
+
+   INIT_LIST_HEAD(_list);
+   INIT_LIST_HEAD(_priv->acpi_i2c_list);
+   acpi_dev_get_resources(adev, _list,
+   i2c_acpi_get_name, dev_priv);
+   acpi_dev_free_resource_list(_list);
+
+   return AE_OK;
+}
+
 static bool intel_dsm_pci_probe(struct pci_dev *pdev)
 {
acpi_handle dhandle;
-- 
2.7.4

[Intel-gfx] [PATCH CI run 1/3] drm/i915/bxt: add bxt dsi gpio element support

[Mika Kahola]

From: Jani Nikula 

Use a table similar to vlv to check for accepted gpio indexes. For now,
add all, but this list should be trimmed down. Use managed gpio request,
which will be automatically released when the driver is detached.

Cc: Mika Kahola 
Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/i915/intel_dsi_panel_vbt.c | 667 -
 1 file changed, 666 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c 
b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
index 9f279a3..a4cbe68 100644
--- a/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
+++ b/drivers/gpu/drm/i915/intel_dsi_panel_vbt.c
@@ -29,6 +29,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -113,6 +114,636 @@ static struct gpio_map vlv_gpio_table[] = {
 #define CHV_GPIO_PAD_CFG1(f, i)(0x4400 + (f) * 0x400 + (i) * 8 
+ 4)
 #define  CHV_GPIO_CFGLOCK  (1 << 31)
 
+#define BXT_HV_DDI0_DDC_SDA_PIN187
+#define BXT_HV_DDI0_DDC_SCL_PIN188
+#define BXT_HV_DDI1_DDC_SDA_PIN189
+#define BXT_HV_DDI1_DDC_SCL_PIN190
+#define BXT_DBI_SDA_PIN191
+#define BXT_DBI_SCL_PIN192
+#define BXT_PANEL0_VDDEN_PIN   193
+#define BXT_PANEL0_BKLTEN_PIN  194
+#define BXT_PANEL0_BKLTCTL_PIN 195
+#define BXT_PANEL1_VDDEN_PIN   196
+#define BXT_PANEL1_BKLTEN_PIN  197
+#define BXT_PANEL1_BKLTCTL_PIN 198
+#define BXT_DBI_CSX_PIN199
+#define BXT_DBI_RESX_PIN   200
+#define BXT_GP_INTD_DSI_TE1_PIN201
+#define BXT_GP_INTD_DSI_TE2_PIN202
+#define BXT_USB_OC0_B_PIN  203
+#define BXT_USB_OC1_B_PIN  204
+#define BXT_MEX_WAKE0_B_PIN205
+#define BXT_MEX_WAKE1_B_PIN206
+#define BXT_EMMC0_CLK_PIN  156
+#define BXT_EMMC0_D0_PIN   157
+#define BXT_EMMC0_D1_PIN   158
+#define BXT_EMMC0_D2_PIN   159
+#define BXT_EMMC0_D3_PIN   160
+#define BXT_EMMC0_D4_PIN   161
+#define BXT_EMMC0_D5_PIN   162
+#define BXT_EMMC0_D6_PIN   163
+#define BXT_EMMC0_D7_PIN   164
+#define BXT_EMMC0_CMD_PIN  165
+#define BXT_SDIO_CLK_PIN   166
+#define BXT_SDIO_D0_PIN167
+#define BXT_SDIO_D1_PIN168
+#define BXT_SDIO_D2_PIN169
+#define BXT_SDIO_D3_PIN170
+#define BXT_SDIO_CMD_PIN   171
+#define BXT_SDCARD_CLK_PIN 172
+#define BXT_SDCARD_D0_PIN  173
+#define BXT_SDCARD_D1_PIN  174
+#define BXT_SDCARD_D2_PIN  175
+#define BXT_SDCARD_D3_PIN  176
+#define BXT_SDCARD_CD_B_PIN177
+#define BXT_SDCARD_CMD_PIN 178
+#define BXT_SDCARD_LVL_CLK_FB_PIN  179
+#define BXT_SDCARD_LVL_CMD_DIR_PIN 180
+#define BXT_SDCARD_LVL_DAT_DIR_PIN 181
+#define BXT_EMMC0_STROBE_PIN   182
+#define BXT_SDIO_PWR_DOWN_B_PIN183
+#define BXT_SDCARD_PWR_DOWN_B_PIN  184
+#define BXT_SDCARD_LVL_SEL_PIN 185
+#define BXT_SDCARD_LVL_WP_PIN  186
+#define BXT_LPSS_I2C0_SDA_PIN  124
+#define BXT_LPSS_I2C0_SCL_PIN  125
+#define BXT_LPSS_I2C1_SDA_PIN  126
+#define BXT_LPSS_I2C1_SCL_PIN  127
+#define BXT_LPSS_I2C2_SDA_PIN  128
+#define BXT_LPSS_I2C2_SCL_PIN  129
+#define BXT_LPSS_I2C3_SDA_PIN  130
+#define BXT_LPSS_I2C3_SCL_PIN  131
+#define BXT_LPSS_I2C4_SDA_PIN  132
+#define BXT_LPSS_I2C4_SCL_PIN  133
+#define BXT_LPSS_I2C5_SDA_PIN  134
+#define BXT_LPSS_I2C5_SCL_PIN  135
+#define BXT_LPSS_I2C6_SDA_PIN  136
+#define BXT_LPSS_I2C6_SCL_PIN  137
+#define BXT_LPSS_I2C7_SDA_PIN  138
+#define BXT_LPSS_I2C7_SCL_PIN  139
+#define BXT_ISH_I2C0_SDA_PIN   140
+#define BXT_ISH_I2C0_SCL_PIN   141
+#define BXT_ISH_I2C1_SDA_PIN   142
+#define BXT_ISH_I2C1_SCL_PIN   143
+#define BXT_ISH_I2C2_SDA_PIN   144
+#define BXT_ISH_I2C2_SCL_PIN   145
+#define BXT_ISH_GPIO_0_PIN 146
+#define BXT_ISH_GPIO_1_PIN 147
+#define BXT_ISH_GPIO_2_PIN 148
+#define BXT_ISH_GPIO_3_PIN 149
+#define BXT_ISH_GPIO_4_PIN 150
+#define BXT_ISH_GPIO_5_PIN 151
+#define BXT_ISH_GPIO_6_PIN 152
+#define BXT_ISH_GPIO_7_PIN 153
+#define BXT_ISH_GPIO_8_PIN 154
+#define BXT_ISH_GPIO_9_PIN 155
+#define BXT_AVS_I2S1_MCLK_PIN  74
+#define BXT_AVS_I2S1_BCLK_PIN  75
+#define BXT_AVS_I2S1_WS_SYNC_PIN   76
+#define BXT_AVS_I2S1_SDI_PIN   77
+#define BXT_AVS_I2S1_SDO_PIN   78
+#define 

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v4:
* Remove the redundant variable link_train_failed
v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 40 
 drivers/gpu/drm/i915/intel_drv.h |  4 
 2 files changed, 44 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90283ed..4fb89e1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+   int *common_rates, int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count)
+{
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+   int common_len;
+   int link_rate_index = -1;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  link_rate);
+   if (link_rate_index > 0) {
+   intel_dp->fallback_link_rate = common_rates[link_rate_index - 
1];
+   intel_dp->fallback_lane_count = 
intel_dp_max_lane_count(intel_dp);
+   } else if (lane_count > 1) {
+   intel_dp->fallback_link_rate = common_rates[common_len - 1];
+   intel_dp->fallback_lane_count = lane_count >> 1;
+   } else {
+   DRM_ERROR("Link Training Unsuccessful\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..e1c43a9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,8 @@ struct intel_dp {
uint32_t DP;
int link_rate;
uint8_t lane_count;
+   int fallback_link_rate;
+   uint8_t fallback_lane_count;
uint8_t sink_count;
bool link_mst;
bool has_audio;
@@ -1383,6 +1385,8 @@ bool intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  int link_rate, uint8_t lane_count,
  bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

v7:
Remove the redundant variable in previous patch itself
v6:
* Obtain link rate index from fallback_link_rate using
the helper intel_dp_link_rate_index (Jani Nikula)
* Include fallback within intel_dp_start_link_train (Jani Nikula)
v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c   | 63 ++-
 drivers/gpu/drm/i915/intel_dp_link_training.c | 28 +++-
 drivers/gpu/drm/i915/intel_drv.h  |  3 ++
 3 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4fb89e1..a56a34d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -351,8 +351,14 @@ int intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
target_clock = fixed_mode->clock;
}
 
-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes using the fallback link rate/lane count */
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+   max_link_clock = intel_dp->fallback_link_rate;
+   max_lanes = intel_dp->fallback_lane_count;
+   } else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }
 
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1588,6 +1594,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1635,6 +1642,14 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
 
+   /* Fall back to lower link rate in case of failure in previous modeset 
*/
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+   min_lane_count = max_lane_count = intel_dp->fallback_lane_count;
+   min_clock = max_clock = intel_dp_link_rate_index(intel_dp,
+common_rates,
+
intel_dp->fallback_link_rate);
+   }
+
DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %d pixel clock %iKHz\n",
  max_lane_count, common_rates[max_clock],
@@ -4415,6 +4430,10 @@ static bool intel_digital_port_connected(struct 
drm_i915_private *dev_priv,
intel_dp->compliance_test_active = 0;
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
+   intel_dp->fallback_link_rate = 0;
+   intel_dp->fallback_lane_count = 0;
+   drm_mode_connector_set_link_status_property(connector,
+   
DRM_MODE_LINK_STATUS_GOOD);
 
if (intel_dp->is_mst) {
DRM_DEBUG_KMS("MST device may have disappeared %d vs 
%d\n",
@@ -4506,6 +4525,11 @@ static bool intel_digital_port_connected(struct 
drm_i915_private *dev_priv,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
 
+   /* If this is a retry due to link 

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,1/2] drm/i915: add i915_address_space_fini

[Patchwork]

== Series Details ==

Series: series starting with [CI,1/2] drm/i915: add i915_address_space_fini
URL   : https://patchwork.freedesktop.org/series/15520/
State : success

== Summary ==

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


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

7fc9e0c9ebb67261bc86264eb7592a9e8d12e7fe drm-intel-nightly: 
2016y-11m-17d-20h-31m-28s UTC integration manifest
3c3f8c3 drm/i915: don't leak global_timeline
645c467 drm/i915: add i915_address_space_fini

== Logs ==

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

[Intel-gfx] [PATCH 0/5] Link Training failure handling during modeset

[Manasi Navare]

Submitting this series again since it had to be rebased dur to changes
in drm that got merged.

The idea presented in these patches is to address link training failure
in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.

The solution is to add a "link status" connector property. In the usual
happy day scenario, this is always "good". If something fails during or
after a mode set, the kernel driver can set the link status to "bad",
prune the mode list based on new information as necessary, and send a
hotplug uevent for userspace to have it re-check the valid modes through
getconnector, and try again. If the theoretical capabilities of the link
can't be reached, the mode list is trimmed based on that.

If the userspace is not aware of the property, the user experience is
the same as it currently is. If the userspace is aware of the property,
it has a chance to improve user experience. If a drm driver does not
modify the property (it stays "good"), the user experience is the same
as it currently is. A drm driver can also choose to try to handle more
of the failures in kernel, hardware not limiting, or it can choose to
involve userspace more. Up to the drivers.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

Finally, while DP CTS compliance is advertized (which is great, and
could be made to work similarly for all drm drivers), this can be used
for the more important goal of improving user experience on link
training failures, by avoiding black screens.

Manasi Navare (5):
  drm: Add a new connector property for link status
  drm: Set DRM connector link status property
  drm/i915: Update CRTC state if connector link status property changed
  drm/i915: Find fallback link rate/lane count
  drm/i915: Implement Link Rate fallback on Link training failure

 drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
 drivers/gpu/drm/drm_connector.c   |  54 ++
 drivers/gpu/drm/i915/intel_dp.c   | 103 +-
 drivers/gpu/drm/i915/intel_dp_link_training.c |  28 ++-
 drivers/gpu/drm/i915/intel_drv.h  |   7 ++
 include/drm/drm_connector.h   |   9 ++-
 include/drm/drm_mode_config.h |   5 ++
 include/uapi/drm/drm_mode.h   |   4 +
 8 files changed, 212 insertions(+), 5 deletions(-)

-- 
1.9.1

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

[Intel-gfx] [PATCH 3/5] drm/i915: Update CRTC state if connector link status property changed

[Manasi Navare]

CRTC state connector_changed needs to be set to true
if connector link status property has changed. This will tell the
driver to do a complete modeset due to change in connector property.

Acked-by: Harry Wentland 
Acked-by: Tony Cheng 
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_atomic_helper.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 0b16587..2125fd1 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -519,6 +519,13 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
   connector_state);
if (ret)
return ret;
+
+   if (connector->state->crtc) {
+   crtc_state = drm_atomic_get_existing_crtc_state(state,
+   
connector->state->crtc);
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD)
+   crtc_state->connectors_changed = true;
+   }
}
 
/*
-- 
1.9.1

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

[Intel-gfx] [PATCH 2/5] drm: Set DRM connector link status property

[Manasi Navare]

In the usual working scenarios, this property is "Good".
If something fails during modeset, the DRM driver can
set the link status to "Bad", prune the mode list based on the
link rate/lane count fallback values and send  hotplug uevent
so that userspace that is aware of this property can take an
appropriate action by reprobing connectors and re triggering
a modeset to improve user experience and avoid black screens.
In case of userspace that is not aware of this link status
property, the user experience will be unchanged.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

v3:
* Updated kernel doc even more (Daniel Vetter)
v2:
* Update kernel doc, add lockdep_assert_held (Daniel Vetter)
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 37 +
 include/drm/drm_connector.h |  2 ++
 2 files changed, 39 insertions(+)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index 2b6ee0e..f3f09b8 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -968,6 +968,43 @@ int drm_mode_connector_update_edid_property(struct 
drm_connector *connector,
 }
 EXPORT_SYMBOL(drm_mode_connector_update_edid_property);
 
+/**
+ * drm_mode_connector_set_link_status_property - Set link status property of a 
connector
+ * @connector: drm connector
+ * @link_status: new value of link status property (0: Good, 1: Bad)
+ *
+ * In usual working scenario, this link status property will always be set to
+ * "GOOD". If something fails during or after a mode set, the kernel driver 
should
+ * prune the mode list based on new information, set this link status property 
to
+ * "BAD". The caller then needs to send a hotplug uevent for userspace to 
re-check
+ * the valid modes through GET_CONNECTOR_IOCTL and retry modeset.
+ *
+ * Note that a lot of existing userspace do not handle this property.
+ * Drivers can therefore not rely on userspace to fix up everything and
+ * should try to handle issues (like just re-training a link) without
+ * userspace's intervention. This should only be used when the current mode
+ * fails and userspace must select a different display mode.
+ * The DRM driver can chose to not modify property and keep link status
+ * as "GOOD" always to keep the user experience same as it currently is.
+ *
+ * The reason for adding this property is to handle link training failures, but
+ * it is not limited to DP or link training. For example, if we implement
+ * asynchronous setcrtc, this property can be used to report any failures in 
that.
+ */
+void drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+uint64_t link_status)
+{
+   struct drm_device *dev = connector->dev;
+
+   /* Make sure the mutex is grabbed */
+   lockdep_assert_held(>mode_config.mutex);
+   connector->link_status = link_status;
+   drm_object_property_set_value(>base,
+ dev->mode_config.link_status_property,
+ link_status);
+}
+EXPORT_SYMBOL(drm_mode_connector_set_link_status_property);
+
 int drm_mode_connector_set_obj_prop(struct drm_mode_object *obj,
struct drm_property *property,
uint64_t value)
diff --git a/include/drm/drm_connector.h b/include/drm/drm_connector.h
index ab564e6..f47b345 100644
--- a/include/drm/drm_connector.h
+++ b/include/drm/drm_connector.h
@@ -778,6 +778,8 @@ int drm_mode_connector_set_path_property(struct 
drm_connector *connector,
 int drm_mode_connector_set_tile_property(struct drm_connector *connector);
 int drm_mode_connector_update_edid_property(struct drm_connector *connector,
const struct edid *edid);
+void drm_mode_connector_set_link_status_property(struct drm_connector 
*connector,
+uint64_t link_status);
 
 /**
  * struct drm_tile_group - Tile group metadata
-- 
1.9.1

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

[Intel-gfx] [PATCH 1/5] drm: Add a new connector property for link status

[Manasi Navare]

At the time userspace does setcrtc, we've already promised the mode
would work. The promise is based on the theoretical capabilities of the
link, but it's possible we can't reach this in practice. The DP spec
describes how the link should be reduced, but we can't reduce the link
below the requirements of the mode. Black screen follows.

One idea would be to have setcrtc return a failure. However, it
already should not fail as the atomic checks have passed. It would also
conflict with the idea of making setcrtc asynchronous in the future,
returning before the actual mode setting and link training.

Another idea is to train the link "upfront" at hotplug time, before
pruning the mode list, so that we can do the pruning based on practical
not theoretical capabilities. However, the changes for link training are
pretty drastic, all for the sake of error handling and DP compliance,
when the most common happy day scenario is the current approach of link
training at mode setting time, using the optimal parameters for the
mode. It is also not certain all hardware could do this without the pipe
on; not even all our hardware can do this. Some of this can be solved,
but not trivially.

Both of the above ideas also fail to address link degradation *during*
operation.

The solution is to add a new "link-status" connector property in order
to address link training failure in a way that:
a) changes the current happy day scenario as little as possible, to avoid
regressions, b) can be implemented the same way by all drm drivers, c)
is still opt-in for the drivers and userspace, and opting out doesn't
regress the user experience, d) doesn't prevent drivers from
implementing better or alternate approaches, possibly without userspace
involvement. And, of course, handles all the issues presented.
In the usual happy day scenario, this is always "good". If something fails
during or after a mode set, the kernel driver can prune the mode list based
on new information as necessary, set the link status to "bad",
and send a hotplug uevent for userspace to have it re-check the valid modes
through getconnector, and try again. If the theoretical capabilities of the
link can't be reached, the mode list is trimmed based on that.

The reason for adding the property is to handle link training failures,
but it is not limited to DP or link training. For example, if we
implement asynchronous setcrtc, we can use this to report any failures
in that.

v4:
* Rebase on drm-nightly
* Add a detailed commit message (Jani Nikula)
v3:
* Drop "link training" from description since this is
not specific to DP (Jani Nikula)
* Add link status member to store property value locally
(Ville Syrjala)
v2:
* Make this a default connector property (Daniel Vetter)

Reviewed-by: Harry Wentland 
Cc: dri-de...@lists.freedesktop.org
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Cc: Chris Wilson 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/drm_connector.c | 17 +
 include/drm/drm_connector.h |  7 ++-
 include/drm/drm_mode_config.h   |  5 +
 include/uapi/drm/drm_mode.h |  4 
 4 files changed, 32 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_connector.c b/drivers/gpu/drm/drm_connector.c
index b5c6a8e..2b6ee0e 100644
--- a/drivers/gpu/drm/drm_connector.c
+++ b/drivers/gpu/drm/drm_connector.c
@@ -243,6 +243,10 @@ int drm_connector_init(struct drm_device *dev,
drm_object_attach_property(>base,
  config->dpms_property, 0);
 
+   drm_object_attach_property(>base,
+  config->link_status_property,
+  0);
+
if (drm_core_check_feature(dev, DRIVER_ATOMIC)) {
drm_object_attach_property(>base, 
config->prop_crtc_id, 0);
}
@@ -506,6 +510,12 @@ const char *drm_get_subpixel_order_name(enum 
subpixel_order order)
 };
 DRM_ENUM_NAME_FN(drm_get_dpms_name, drm_dpms_enum_list)
 
+static const struct drm_prop_enum_list drm_link_status_enum_list[] = {
+   { DRM_MODE_LINK_STATUS_GOOD, "Good" },
+   { DRM_MODE_LINK_STATUS_BAD, "Bad" },
+};
+DRM_ENUM_NAME_FN(drm_get_link_status_name, drm_link_status_enum_list)
+
 /**
  * drm_display_info_set_bus_formats - set the supported bus formats
  * @info: display info to store bus formats in
@@ -622,6 +632,13 @@ int drm_connector_create_standard_properties(struct 
drm_device *dev)
return -ENOMEM;
dev->mode_config.tile_property = prop;
 
+   prop = drm_property_create_enum(dev, 0, "link-status",
+   drm_link_status_enum_list,
+   ARRAY_SIZE(drm_link_status_enum_list));
+   if (!prop)
+   return -ENOMEM;
+   dev->mode_config.link_status_property = prop;
+

[Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

If link training at a link rate optimal for a particular
mode fails during modeset's atomic commit phase, then we
let the modeset complete and then retry. We save the link rate
value at which link training failed, update the link status property
to "BAD" and use a lower link rate to prune the modes. It will redo
the modeset on the current mode at lower link rate or if the current
mode gets pruned due to lower link constraints then, it will send a
hotplug uevent for userspace to handle it.

This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
4.3.1.6.

v6:
* Obtain link rate index from fallback_link_rate using
the helper intel_dp_link_rate_index (Jani Nikula)
* Include fallback within intel_dp_start_link_train (Jani Nikula)
v5:
* Move set link status to drm core (Daniel Vetter, Jani Nikula)
v4:
* Add fallback support for non DDI platforms too
* Set connector->link status inside set_link_status function
(Jani Nikula)
v3:
* Set link status property to BAd unconditionally (Jani Nikula)
* Dont use two separate variables link_train_failed and link_status
to indicate same thing (Jani Nikula)
v2:
* Squashed a few patches (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Cc: Ville Syrjala 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c   | 63 ++-
 drivers/gpu/drm/i915/intel_dp_link_training.c | 28 +++-
 drivers/gpu/drm/i915/intel_drv.h  |  4 +-
 3 files changed, 90 insertions(+), 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 4fb89e1..a56a34d 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -351,8 +351,14 @@ int intel_dp_get_link_train_fallback_values(struct 
intel_dp *intel_dp,
target_clock = fixed_mode->clock;
}
 
-   max_link_clock = intel_dp_max_link_rate(intel_dp);
-   max_lanes = intel_dp_max_lane_count(intel_dp);
+   /* Prune the modes using the fallback link rate/lane count */
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+   max_link_clock = intel_dp->fallback_link_rate;
+   max_lanes = intel_dp->fallback_lane_count;
+   } else {
+   max_link_clock = intel_dp_max_link_rate(intel_dp);
+   max_lanes = intel_dp_max_lane_count(intel_dp);
+   }
 
max_rate = intel_dp_max_data_rate(max_link_clock, max_lanes);
mode_rate = intel_dp_link_required(target_clock, 18);
@@ -1588,6 +1594,7 @@ static int intel_dp_compute_bpp(struct intel_dp *intel_dp,
enum port port = dp_to_dig_port(intel_dp)->port;
struct intel_crtc *intel_crtc = to_intel_crtc(pipe_config->base.crtc);
struct intel_connector *intel_connector = intel_dp->attached_connector;
+   struct drm_connector *connector = _connector->base;
int lane_count, clock;
int min_lane_count = 1;
int max_lane_count = intel_dp_max_lane_count(intel_dp);
@@ -1635,6 +1642,14 @@ static int intel_dp_compute_bpp(struct intel_dp 
*intel_dp,
if (adjusted_mode->flags & DRM_MODE_FLAG_DBLCLK)
return false;
 
+   /* Fall back to lower link rate in case of failure in previous modeset 
*/
+   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
+   min_lane_count = max_lane_count = intel_dp->fallback_lane_count;
+   min_clock = max_clock = intel_dp_link_rate_index(intel_dp,
+common_rates,
+
intel_dp->fallback_link_rate);
+   }
+
DRM_DEBUG_KMS("DP link computation with max lane count %i "
  "max bw %d pixel clock %iKHz\n",
  max_lane_count, common_rates[max_clock],
@@ -4415,6 +4430,10 @@ static bool intel_digital_port_connected(struct 
drm_i915_private *dev_priv,
intel_dp->compliance_test_active = 0;
intel_dp->compliance_test_type = 0;
intel_dp->compliance_test_data = 0;
+   intel_dp->fallback_link_rate = 0;
+   intel_dp->fallback_lane_count = 0;
+   drm_mode_connector_set_link_status_property(connector,
+   
DRM_MODE_LINK_STATUS_GOOD);
 
if (intel_dp->is_mst) {
DRM_DEBUG_KMS("MST device may have disappeared %d vs 
%d\n",
@@ -4506,6 +4525,11 @@ static bool intel_digital_port_connected(struct 
drm_i915_private *dev_priv,
DRM_DEBUG_KMS("[CONNECTOR:%d:%s]\n",
  connector->base.id, connector->name);
 
+   /* If this is a retry due to link trianing failure */
+   if (status == 

[Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

If link training fails, then we need to fallback to lower
link rate first and if link training fails at RBR, then
fallback to lower lane count.
This function finds the next lower link rate/lane count
value after link training failure.

v3:
* Remove fallback_link_rate_index variable, just obtain
that using the helper intel_dp_link_rate_index (Jani Nikula)
v2:
Squash the patch that returns the link rate index (Jani Nikula)

Acked-by: Tony Cheng 
Acked-by: Harry Wentland 
Cc: Ville Syrjala 
Cc: Jani Nikula 
Cc: Daniel Vetter 
Signed-off-by: Manasi Navare 
---
 drivers/gpu/drm/i915/intel_dp.c  | 40 
 drivers/gpu/drm/i915/intel_drv.h |  5 +
 2 files changed, 45 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp.c b/drivers/gpu/drm/i915/intel_dp.c
index 90283ed..4fb89e1 100644
--- a/drivers/gpu/drm/i915/intel_dp.c
+++ b/drivers/gpu/drm/i915/intel_dp.c
@@ -288,6 +288,46 @@ static int intel_dp_common_rates(struct intel_dp *intel_dp,
   common_rates);
 }
 
+static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
+   int *common_rates, int link_rate)
+{
+   int common_len;
+   int index;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   for (index = 0; index < common_len; index++) {
+   if (link_rate == common_rates[common_len - index - 1])
+   return common_len - index - 1;
+   }
+
+   return -1;
+}
+
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count)
+{
+   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
+   int common_len;
+   int link_rate_index = -1;
+
+   common_len = intel_dp_common_rates(intel_dp, common_rates);
+   link_rate_index = intel_dp_link_rate_index(intel_dp,
+  common_rates,
+  link_rate);
+   if (link_rate_index > 0) {
+   intel_dp->fallback_link_rate = common_rates[link_rate_index - 
1];
+   intel_dp->fallback_lane_count = 
intel_dp_max_lane_count(intel_dp);
+   } else if (lane_count > 1) {
+   intel_dp->fallback_link_rate = common_rates[common_len - 1];
+   intel_dp->fallback_lane_count = lane_count >> 1;
+   } else {
+   DRM_ERROR("Link Training Unsuccessful\n");
+   return -1;
+   }
+
+   return 0;
+}
+
 static enum drm_mode_status
 intel_dp_mode_valid(struct drm_connector *connector,
struct drm_display_mode *mode)
diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
index cd132c2..3f6b4c9 100644
--- a/drivers/gpu/drm/i915/intel_drv.h
+++ b/drivers/gpu/drm/i915/intel_drv.h
@@ -887,6 +887,9 @@ struct intel_dp {
uint32_t DP;
int link_rate;
uint8_t lane_count;
+   int fallback_link_rate;
+   uint8_t fallback_lane_count;
+   bool link_train_failed;
uint8_t sink_count;
bool link_mst;
bool has_audio;
@@ -1383,6 +1386,8 @@ bool intel_dp_init_connector(struct intel_digital_port 
*intel_dig_port,
 void intel_dp_set_link_params(struct intel_dp *intel_dp,
  int link_rate, uint8_t lane_count,
  bool link_mst);
+int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
+   int link_rate, uint8_t lane_count);
 void intel_dp_start_link_train(struct intel_dp *intel_dp);
 void intel_dp_stop_link_train(struct intel_dp *intel_dp);
 void intel_dp_sink_dpms(struct intel_dp *intel_dp, int mode);
-- 
1.9.1

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

Re: [Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

[Chris Wilson]

On Thu, Nov 17, 2016 at 06:03:48PM -0800, Dhinakaran Pandiyan wrote:
>  static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr,
>   struct drm_dp_vcpi *vcpi, int pbn)
>  {
> - int num_slots;
> + int req_slots;
>   int ret;
>  
> - num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> + req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
>  
> - if (num_slots > mgr->avail_slots)
> - return -ENOSPC;
> + mutex_lock(>lock);
> + if (req_slots > mgr->avail_slots) {
> + ret = -ENOSPC;
> + goto out;
> + }

You are not atomically reducing the mgr->avail_slots, leading to
possible overallocation of multiple streams?
-Chris

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

Re: [Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

[Manasi Navare]

On Thu, Nov 17, 2016 at 06:03:48PM -0800, Dhinakaran Pandiyan wrote:
> The avail_slots member in struct drm_dp_mst_topology_mgr does not really
> track the available time slots in a MTP(Multi-Stream Transport Packet). It
> is assigned an initial value when the topology manager is setup but not
> updated after that.
> 
> So, let's use avail_slots to store the number of unallocated slots out of
> the total 64. The value will be updated when vcpi allocation or reset
> happens. Since vcpi allocation and deallocation can happen simultaneously,
> the struct drm_dp_mst_topology_mgr.lock mutex is used to protect
> it from concurrent accesses.
> 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 55 
> ++-
>  drivers/gpu/drm/i915/intel_dp_mst.c   |  5 +++-
>  include/drm/drm_dp_mst_helper.h   |  2 +-
>  3 files changed, 47 insertions(+), 15 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 26dfd99..19e2250 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -2040,7 +2040,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
> drm_dp_mst_topology_mgr *mgr, bool ms
>   }
>   mgr->total_pbn = 64 * mgr->pbn_div;
>   mgr->total_slots = 64;
> - mgr->avail_slots = mgr->total_slots;
> +
> + /* 1 slot out of the 64 time slots is used for MTP header */
> + mgr->avail_slots = mgr->total_slots - 1;
>  
>   /* add initial branch device at LCT 1 */
>   mstb = drm_dp_add_mst_branch_device(1, NULL);
> @@ -2465,34 +2467,52 @@ EXPORT_SYMBOL(drm_dp_mst_get_edid);
>   * @pbn: payload bandwidth to convert into slots.
>   */
>  int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr,
> -int pbn)
> +struct drm_dp_mst_port *port, int pbn)
>  {
> - int num_slots;
> + int req_slots, curr_slots, new_slots, ret;
> +
> + req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> + curr_slots = drm_dp_mst_get_vcpi_slots(mgr, port);
>  
> - num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> + if (req_slots <= curr_slots)
> + return req_slots;

Are you sure you want to return from the function at this
or should this just be ret = req_slots as you are returning ret at the end of 
the function.

Manasi
>  
> - if (num_slots > mgr->avail_slots)
> - return -ENOSPC;
> - return num_slots;
> + new_slots = req_slots - curr_slots;
> + mutex_lock(>lock);
> + if (new_slots <= mgr->avail_slots) {
> + ret = req_slots;
> + } else {
> + DRM_DEBUG_KMS("not enough vcpi slots, req=%d avail=%d\n", 
> req_slots, mgr->avail_slots);
> + ret =  -ENOSPC;
> + }
> + mutex_unlock(>lock);
> +
> + return ret;
>  }
>  EXPORT_SYMBOL(drm_dp_find_vcpi_slots);
>  
>  static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr,
>   struct drm_dp_vcpi *vcpi, int pbn)
>  {
> - int num_slots;
> + int req_slots;
>   int ret;
>  
> - num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
> + req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
>  
> - if (num_slots > mgr->avail_slots)
> - return -ENOSPC;
> + mutex_lock(>lock);
> + if (req_slots > mgr->avail_slots) {
> + ret = -ENOSPC;
> + goto out;
> + }
>  
>   vcpi->pbn = pbn;
> - vcpi->aligned_pbn = num_slots * mgr->pbn_div;
> - vcpi->num_slots = num_slots;
> + vcpi->aligned_pbn = req_slots * mgr->pbn_div;
> + vcpi->num_slots = req_slots;
>  
>   ret = drm_dp_mst_assign_payload_id(mgr, vcpi);
> +
> +out:
> + mutex_unlock(>lock);
>   if (ret < 0)
>   return ret;
>   return 0;
> @@ -2530,6 +2550,10 @@ bool drm_dp_mst_allocate_vcpi(struct 
> drm_dp_mst_topology_mgr *mgr, struct drm_dp
>   DRM_DEBUG_KMS("initing vcpi for %d %d\n", pbn, port->vcpi.num_slots);
>   *slots = port->vcpi.num_slots;
>  
> + mutex_lock(>lock);
> + mgr->avail_slots -= port->vcpi.num_slots;
> + mutex_unlock(>lock);
> +
>   drm_dp_put_port(port);
>   return true;
>  out:
> @@ -2562,6 +2586,11 @@ void drm_dp_mst_reset_vcpi_slots(struct 
> drm_dp_mst_topology_mgr *mgr, struct drm
>   port = drm_dp_get_validated_port_ref(mgr, port);
>   if (!port)
>   return;
> +
> + mutex_lock(>lock);
> + mgr->avail_slots += port->vcpi.num_slots;
> + mutex_unlock(>lock);
> +
>   port->vcpi.num_slots = 0;
>   drm_dp_put_port(port);
>  }
> diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
> b/drivers/gpu/drm/i915/intel_dp_mst.c
> index 4280a83..bad9300 100644
> --- a/drivers/gpu/drm/i915/intel_dp_mst.c
> +++ b/drivers/gpu/drm/i915/intel_dp_mst.c
> @@ -42,6 +42,8 @@ static bool intel_dp_mst_compute_config(struct 
> 

[Intel-gfx] GTT memory allocation on E3800

[Мамонов Алексей Александрович]

Hi! First of all, I want to apologize for possible offtopic, I don't work with 
the Linux drivers, but I'm trying to figure out some details of e3800 graphics 
initialization process, and guys on Intel Embedded Community forum told me that 
maybe someone on this mail list could help me.

I cannot understand whether to allocate memory for Graphics Translation Table. 
The documentation (#IHD-OS-VLV-Vol5-04.14, page 19) says: "The base address (MM 
offset) of the GTT and the PPGTT are programmed via the PGTBL_CTL and 
PGTBL_CTL2 MI registers, respectively." But I can't find the description of the 
register PGTBL_CTL in the E3800 Datasheet (and in other docs). Also, I looked 
at the Linux driver source code and it seems like it doesn't allocate memory 
for GTT. Hence the question: Do I have to allocate memory for GTT, and if so, 
how to do it correctly?

Thanks in advance.
Best Regards, Alex.
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

[kbuild test robot]

Hi Dhinakaran,

[auto build test WARNING on drm/drm-next]
[also build test WARNING on v4.9-rc5 next-20161117]
[cannot apply to drm-intel/for-linux-next]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Dhinakaran-Pandiyan/Track-available-link-bandwidth-for-DP-MST/20161118-101200
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
reproduce: make htmldocs; make DOCBOOKS='' pdfdocs

All warnings (new ones prefixed by >>):

   make[3]: warning: jobserver unavailable: using -j1.  Add '+' to parent make 
rule.
   include/linux/init.h:1: warning: no structured comments found
   include/linux/workqueue.h:392: warning: No description found for parameter 
'...'
   include/linux/workqueue.h:392: warning: Excess function parameter 'args' 
description in 'alloc_workqueue'
   include/linux/workqueue.h:413: warning: No description found for parameter 
'...'
   include/linux/workqueue.h:413: warning: Excess function parameter 'args' 
description in 'alloc_ordered_workqueue'
   include/linux/kthread.h:26: warning: No description found for parameter '...'
   kernel/sys.c:1: warning: no structured comments found
   drivers/dma-buf/seqno-fence.c:1: warning: no structured comments found
   include/sound/core.h:324: warning: No description found for parameter '...'
   include/sound/core.h:335: warning: No description found for parameter '...'
   include/sound/core.h:388: warning: No description found for parameter '...'
   include/drm/drm_drv.h:295: warning: Incorrect use of kernel-doc format:  
 * Hook for allocating the GEM object struct, for use by core
   include/drm/drm_drv.h:407: warning: No description found for parameter 'load'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'firstopen'
   include/drm/drm_drv.h:407: warning: No description found for parameter 'open'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'preclose'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'postclose'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'lastclose'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'unload'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'dma_ioctl'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'dma_quiescent'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'context_dtor'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'set_busid'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_handler'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_preinstall'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_postinstall'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'irq_uninstall'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'debugfs_init'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'debugfs_cleanup'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_open_object'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_close_object'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_create_object'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'prime_handle_to_fd'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'prime_fd_to_handle'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_export'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_import'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_pin'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_unpin'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_res_obj'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_get_sg_table'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_import_sg_table'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_vmap'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_vunmap'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_prime_mmap'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'vgaarb_irq'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'gem_vm_ops'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'major'
   include/drm/drm_drv.h:407: warning: No description found for parameter 
'minor'
   include/drm/drm_drv.h:407: warning: No descr

[Intel-gfx] [PATCH 2/3] drm/dp/mst: Calculate total link bandwidth instead of hardcoding it

[Dhinakaran Pandiyan]

The total or the nominal link bandwidth, which we save in terms of PBN, is
a factor of link rate and lane count. But, currently we hardcode it to
2560 PBN. This results in incorrect computation of total slots.

E.g, 2 lane HBR2 configuration and 4k@60Hz, 24bpp mode
  nominal link bw = 1080 MBps = 1280PBN = 64 slots
  required bw 533.25 MHz*3 = 1599.75 MBps or 1896 PBN
 with +0.6% margin = 1907.376 PBN = 96 slots
  This is greater than the max. possible value of 64 slots. But, we
  incorrectly compute available slots as 2560 PBN = 128 slots and don't
  return error.

So, let's fix this by calculating the total link bandwidth as
link bw (PBN) = BW per time slot(PBN) * max. time slots , where max. time
slots is 64

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 04e4571..26dfd99 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2038,9 +2038,8 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
ret = -EINVAL;
goto out_unlock;
}
-
-   mgr->total_pbn = 2560;
-   mgr->total_slots = DIV_ROUND_UP(mgr->total_pbn, mgr->pbn_div);
+   mgr->total_pbn = 64 * mgr->pbn_div;
+   mgr->total_slots = 64;
mgr->avail_slots = mgr->total_slots;
 
/* add initial branch device at LCT 1 */
-- 
2.7.4

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

[Intel-gfx] [PATCH 3/3] drm/dp/mst: Track available time slots in DP Multi-Stream Transport Packet

[Dhinakaran Pandiyan]

The avail_slots member in struct drm_dp_mst_topology_mgr does not really
track the available time slots in a MTP(Multi-Stream Transport Packet). It
is assigned an initial value when the topology manager is setup but not
updated after that.

So, let's use avail_slots to store the number of unallocated slots out of
the total 64. The value will be updated when vcpi allocation or reset
happens. Since vcpi allocation and deallocation can happen simultaneously,
the struct drm_dp_mst_topology_mgr.lock mutex is used to protect
it from concurrent accesses.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/drm_dp_mst_topology.c | 55 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c   |  5 +++-
 include/drm/drm_dp_mst_helper.h   |  2 +-
 3 files changed, 47 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c 
b/drivers/gpu/drm/drm_dp_mst_topology.c
index 26dfd99..19e2250 100644
--- a/drivers/gpu/drm/drm_dp_mst_topology.c
+++ b/drivers/gpu/drm/drm_dp_mst_topology.c
@@ -2040,7 +2040,9 @@ int drm_dp_mst_topology_mgr_set_mst(struct 
drm_dp_mst_topology_mgr *mgr, bool ms
}
mgr->total_pbn = 64 * mgr->pbn_div;
mgr->total_slots = 64;
-   mgr->avail_slots = mgr->total_slots;
+
+   /* 1 slot out of the 64 time slots is used for MTP header */
+   mgr->avail_slots = mgr->total_slots - 1;
 
/* add initial branch device at LCT 1 */
mstb = drm_dp_add_mst_branch_device(1, NULL);
@@ -2465,34 +2467,52 @@ EXPORT_SYMBOL(drm_dp_mst_get_edid);
  * @pbn: payload bandwidth to convert into slots.
  */
 int drm_dp_find_vcpi_slots(struct drm_dp_mst_topology_mgr *mgr,
-  int pbn)
+  struct drm_dp_mst_port *port, int pbn)
 {
-   int num_slots;
+   int req_slots, curr_slots, new_slots, ret;
+
+   req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+   curr_slots = drm_dp_mst_get_vcpi_slots(mgr, port);
 
-   num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+   if (req_slots <= curr_slots)
+   return req_slots;
 
-   if (num_slots > mgr->avail_slots)
-   return -ENOSPC;
-   return num_slots;
+   new_slots = req_slots - curr_slots;
+   mutex_lock(>lock);
+   if (new_slots <= mgr->avail_slots) {
+   ret = req_slots;
+   } else {
+   DRM_DEBUG_KMS("not enough vcpi slots, req=%d avail=%d\n", 
req_slots, mgr->avail_slots);
+   ret =  -ENOSPC;
+   }
+   mutex_unlock(>lock);
+
+   return ret;
 }
 EXPORT_SYMBOL(drm_dp_find_vcpi_slots);
 
 static int drm_dp_init_vcpi(struct drm_dp_mst_topology_mgr *mgr,
struct drm_dp_vcpi *vcpi, int pbn)
 {
-   int num_slots;
+   int req_slots;
int ret;
 
-   num_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
+   req_slots = DIV_ROUND_UP(pbn, mgr->pbn_div);
 
-   if (num_slots > mgr->avail_slots)
-   return -ENOSPC;
+   mutex_lock(>lock);
+   if (req_slots > mgr->avail_slots) {
+   ret = -ENOSPC;
+   goto out;
+   }
 
vcpi->pbn = pbn;
-   vcpi->aligned_pbn = num_slots * mgr->pbn_div;
-   vcpi->num_slots = num_slots;
+   vcpi->aligned_pbn = req_slots * mgr->pbn_div;
+   vcpi->num_slots = req_slots;
 
ret = drm_dp_mst_assign_payload_id(mgr, vcpi);
+
+out:
+   mutex_unlock(>lock);
if (ret < 0)
return ret;
return 0;
@@ -2530,6 +2550,10 @@ bool drm_dp_mst_allocate_vcpi(struct 
drm_dp_mst_topology_mgr *mgr, struct drm_dp
DRM_DEBUG_KMS("initing vcpi for %d %d\n", pbn, port->vcpi.num_slots);
*slots = port->vcpi.num_slots;
 
+   mutex_lock(>lock);
+   mgr->avail_slots -= port->vcpi.num_slots;
+   mutex_unlock(>lock);
+
drm_dp_put_port(port);
return true;
 out:
@@ -2562,6 +2586,11 @@ void drm_dp_mst_reset_vcpi_slots(struct 
drm_dp_mst_topology_mgr *mgr, struct drm
port = drm_dp_get_validated_port_ref(mgr, port);
if (!port)
return;
+
+   mutex_lock(>lock);
+   mgr->avail_slots += port->vcpi.num_slots;
+   mutex_unlock(>lock);
+
port->vcpi.num_slots = 0;
drm_dp_put_port(port);
 }
diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index 4280a83..bad9300 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -42,6 +42,8 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
int lane_count, slots;
const struct drm_display_mode *adjusted_mode = 
_config->base.adjusted_mode;
int mst_pbn;
+   struct intel_connector *connector =
+   to_intel_connector(conn_state->connector);
 
pipe_config->dp_encoder_is_mst = true;
pipe_config->has_pch_encoder = false;
@@ -62,7 

[Intel-gfx] [PATCH 0/3] Track available link bandwidth for DP MST

[Dhinakaran Pandiyan]

The number of available time slots in a MTP should be updated when a new
vcpi is added or an existing one is removed. Keeping this updated will be
useful to reject modes for which there is not enough link bandwidth early.

Dhinakaran Pandiyan (3):
  drm/i915/dp: Fail DP MST config when there are not enough vcpi slots
  drm/dp/mst: Calculate total link bandwidth instead of hardcoding it
  drm/dp/mst: Track available time slots in DP Multi-Stream Transport
Packet

 drivers/gpu/drm/drm_dp_mst_topology.c | 58 ++-
 drivers/gpu/drm/i915/intel_dp_mst.c   |  9 +-
 include/drm/drm_dp_mst_helper.h   |  2 +-
 3 files changed, 52 insertions(+), 17 deletions(-)

-- 
2.7.4

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

[Intel-gfx] [PATCH 1/3] drm/i915/dp: Fail DP MST config when there are not enough vcpi slots

[Dhinakaran Pandiyan]

drm_dp_find_vcpi_slots() returns an error when there is not enough
available bandwidth on a link to support a mode. This error should make
compute_config() to fail. Not returning false could end up in a modeset
which will not work.

Signed-off-by: Dhinakaran Pandiyan 
---
 drivers/gpu/drm/i915/intel_dp_mst.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_dp_mst.c 
b/drivers/gpu/drm/i915/intel_dp_mst.c
index e21cf08..4280a83 100644
--- a/drivers/gpu/drm/i915/intel_dp_mst.c
+++ b/drivers/gpu/drm/i915/intel_dp_mst.c
@@ -63,6 +63,10 @@ static bool intel_dp_mst_compute_config(struct intel_encoder 
*encoder,
 
pipe_config->pbn = mst_pbn;
slots = drm_dp_find_vcpi_slots(_dp->mst_mgr, mst_pbn);
+   if (slots < 0) {
+   DRM_ERROR("not enough available time slots for pbn=%d", 
mst_pbn);
+   return false;
+   }
 
intel_link_compute_m_n(bpp, lane_count,
   adjusted_mode->crtc_clock,
-- 
2.7.4

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

[Intel-gfx] [PATCH ddx 1/2] intel: Simplify new platform names.

[Rodrigo Vivi]

Modern Intel (R) platforms with integrated graphics comes with common
names varying the range numbers. So instead of listing all supported
platforms let's start using the generic marketing strings without
the numbers.

And for the specific board we list it's actual marketing name if
available on detection.

Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
 README | 6 +++---
 man/intel.man  | 6 +++---
 src/intel_module.c | 6 +++---
 3 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/README b/README
index cf4d88d..348983b 100644
--- a/README
+++ b/README
@@ -15,9 +15,9 @@ Intel graphics chipsets including:
G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
PineView-M (Atom N400 series)
PineView-D (Atom D400/D500 series)
-   Intel(R) HD Graphics: 2000-6000,
-   Intel(R) Iris(TM) Graphics: 5100/6100, and
-   Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
+   Intel(R) HD Graphics,
+   Intel(R) Iris(TM) Graphics,
+   Intel(R) Iris(TM) Pro Graphics.
 
 Where to get more information about the driver
 --
diff --git a/man/intel.man b/man/intel.man
index 8da496e..be398fb 100644
--- a/man/intel.man
+++ b/man/intel.man
@@ -27,9 +27,9 @@ supports the i810, i810-DC100, i810e, i815, i830M, 845G, 
852GM, 855GM,
 865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME,
 G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in
 Atom N400 series, Pineview-D in Atom D400/D500 series,
-Intel(R) HD Graphics: 2000-6000,
-Intel(R) Iris(TM) Graphics: 5100/6100, and
-Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
+Intel(R) HD Graphics,
+Intel(R) Iris(TM) Graphics,
+Intel(R) Iris(TM) Pro Graphics.
 
 .SH CONFIGURATION DETAILS
 Please refer to __xconfigfile__(__filemansuffix__) for general configuration
diff --git a/src/intel_module.c b/src/intel_module.c
index e443c9e..aeec685 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -465,9 +465,9 @@ static void intel_identify(int flags)
if (unique != stack)
free(unique);
 
-   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
2000-6000\n");
-   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Graphics: 
5100, 6100\n");
-   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
Graphics: 5200, 6200, P6300\n");
+   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics\n");
+   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Graphics\n");
+   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
Graphics\n");
 }
 
 static Bool intel_driver_func(ScrnInfoPtr pScrn,
-- 
1.9.1

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

[Intel-gfx] [PATCH ddx 2/2] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

[Rodrigo Vivi]

This commit adding all known marketing names for latest gen9 platforms.

v2: On top of simplified generic string names.

Cc: Chris Wilson 
Signed-off-by: Rodrigo Vivi 
---
 src/intel_module.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/src/intel_module.c b/src/intel_module.c
index aeec685..f15a4c0 100644
--- a/src/intel_module.c
+++ b/src/intel_module.c
@@ -272,6 +272,33 @@ static const SymTabRec intel_chipsets[] = {
{0x22b2, "HD Graphics"},
{0x22b3, "HD Graphics"},
 
+   /* Skylake */
+   {0x1902, "HD Graphics 510"},
+   {0x1906, "HD Graphics 510"},
+   {0x190B, "HD Graphics 510"},
+   {0x1912, "HD Graphics 530"},
+   {0x1916, "HD Graphics 520"},
+   {0x191B, "HD Graphics 530"},
+   {0x191D, "HD Graphics P530"},
+   {0x191E, "HD Graphics 515"},
+   {0x1921, "HD Graphics 520"},
+   {0x1926, "Iris Graphics 540"},
+   {0x1927, "Iris Graphics 550"},
+   {0x192B, "Iris Graphics 555"},
+   {0x192D, "Iris Graphics P555"},
+   {0x1932, "Iris Pro Graphics 580"},
+   {0x193A, "Iris Pro Graphics P580"},
+   {0x193B, "Iris Pro Graphics 580"},
+   {0x193D, "Iris Pro Graphics P580"},
+
+   /* Broxton (Apollolake) */
+   {0x5A84, "HD Graphics 505"},
+   {0x5A85, "HD Graphics 500"},
+
+   /* Kabylake */
+   {0x5916, "HD Graphics 620"},
+   {0x591E, "HD Graphics 615"},
+
/* When adding new identifiers, also update:
 * 1. intel_identify()
 * 2. man/intel.man
-- 
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/5] drm/i915: Cleaning up intel_dp_hpd_pulse

[Chris Wilson]

On Mon, Feb 01, 2016 at 11:13:08AM +0200, Ander Conselvan De Oliveira wrote:
> On Mon, 2016-02-01 at 11:50 +0530, Thulasimani, Sivakumar wrote:
> > 
> > On 1/29/2016 5:33 PM, Ander Conselvan De Oliveira wrote:
> > > On Fri, 2016-01-29 at 14:31 +0530, Shubhangi Shrivastava wrote:
> > > > On Tuesday 26 January 2016 06:52 PM, Ander Conselvan De Oliveira wrote:
> > > > > On Tue, 2016-01-19 at 16:07 +0530, Shubhangi Shrivastava wrote:
> > > > > > Current DP detection has DPCD operations split across
> > > > > > intel_dp_hpd_pulse and intel_dp_detect which contains
> > > > > > duplicates as well. Also intel_dp_detect is called
> > > > > > during modes enumeration as well which will result
> > > > > > in multiple dpcd operations. So this patch tries
> > > > > > to solve both these by bringing all DPCD operations
> > > > > > in one single function and make intel_dp_detect
> > > > > > use existing values instead of repeating same steps.
> > > > > > 
> > > > > > v2: Pulled in a hunk from last patch of the series to
> > > > > >   this patch. (Ander)
> > > > > > v3: Added MST hotplug handling. (Ander)
> > > > > > 
> > > > > > Tested-by: Nathan D Ciobanu 
> > > > > > Signed-off-by: Sivakumar Thulasimani 
> > > > > > 
> > > > > > Signed-off-by: Shubhangi Shrivastava 
> > > > > > 
> > > > > > ---
> > > > > >drivers/gpu/drm/i915/intel_dp.c | 71 
> > > > > > +-
> > > > > > -
> > > > > > -
> > > > > > -
> > > > > >1 file changed, 44 insertions(+), 27 deletions(-)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > b/drivers/gpu/drm/i915/intel_dp.c
> > > > > > index 8969ff9..82ee18d 100644
> > > > > > --- a/drivers/gpu/drm/i915/intel_dp.c
> > > > > > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > > > > [...]
> > > > > 
> > > > > > @@ -4693,7 +4717,8 @@ intel_dp_detect(struct drm_connector 
> > > > > > *connector,
> > > > > > bool
> > > > > > force)
> > > > > > return connector_status_disconnected;
> > > > > > }
> > > > > >
> > > > > > -   intel_dp_long_pulse(intel_dp->attached_connector);
> > > > > > +   if (force)
> > > > > > +   intel_dp_long_pulse(intel_dp->attached_connector);
> > > > > I didn't notice this at first, but force is not the right thing to 
> > > > > check
> > > > > for
> > > > > here. It is basically intended to avoid doing load detection (see
> > > > > intel_get_load_detect_pipe()) on automated polling. But we still have 
> > > > > to
> > > > > try
> > > > > detection here when force = false, otherwise this will cause a
> > > > > regression.
> > > > > 
> > > > > If you plug in a DP device while suspended, that device won't get
> > > > > detected,
> > > > > since we don't get an HPD for it. Previously, the call do
> > > > > intel_dp_detect()
> > > > > with
> > > > > force = false from intel_drm_resume() (via drm_helper_hpd_irq_event())
> > > > > would
> > > > > cause a full detection.
> > > > > 
> > > > > To avoid the repeated DPCD operations, I think we need a more explicit
> > > > > mechanism
> > > > > to signal that we already handled the long pulse via the HPD handler. 
> > > > > In
> > > > > intel_dp_hpd_pulse() we could set a flag that tells we just handled a
> > > > > long
> > > > > pulse
> > > > > for the given port. The call to intel_dp_long_pulse() in
> > > > > intel_dp_detect()
> > > > > would
> > > > > then be dependent on that flag.
> > > > > 
> > > > > For that reason I have to retract my R-b from this patch.
> > > > > 
> > > > > Ander
> > > > Call to intel_dp_detect() from get_modes is with force set to true while
> > > > from resume the call is with force set to false.. It should be in the
> > > > opposite manner as get_modes should not require full detection whereas
> > > > resume should. So, this needs to be cleaned up there. After merge of
> > > > these patches, will look into cleaning up that part of the code.
> > > That really depends on what the force parameter is supposed to mean. The
> > > documentation states that "force is set to false whilst polling, true when
> > > checking the connector due to a user request". A look through git history
> > > shows
> > > the parameter was added to reduce time wasted doing load detection (doing 
> > > a
> > > mode
> > > set in order to check if there is a device connected) for hardware that
> > > needs it
> > > (commit 7b334fcb45b7).
> > > 
> > > As far as I can tell, across all the drm drivers, that parameter is only
> > > used to
> > > avoid doing load detection.
> > > 
> > > Another thing to consider is that the driver may switch to polling if it
> > > detects
> > > an HPD storm. When the detect calls come from polling, the code in this
> > > patch
> > > will simply avoid any detection.
> > > 
> > hmm i think this discussion will prolong for a while :)
> > how about we call intel_dp_long_pulse() always for now.
> > this will be a compromise to not 

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

[ch...@chris-wilson.co.uk]

On Thu, Nov 17, 2016 at 09:03:42PM +, Vivi, Rodrigo wrote:
> On Thu, 2016-11-17 at 19:35 +, Chris Wilson wrote:
> > On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote:
> > > On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote:
> > > > On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote:
> > > > > This commit adding all known marketing names for latest gen9 
> > > > > platforms.
> > > > > 
> > > > > Cc: Chris Wilson 
> > > > > Signed-off-by: Rodrigo Vivi 
> > > > > ---
> > > > >  README |  2 +-
> > > > >  man/intel.man  |  2 +-
> > > > >  src/intel_module.c | 29 -
> > > > >  3 files changed, 30 insertions(+), 3 deletions(-)
> > > > > 
> > > > > diff --git a/README b/README
> > > > > index cf4d88d..e58477d 100644
> > > > > --- a/README
> > > > > +++ b/README
> > > > > @@ -15,7 +15,7 @@ Intel graphics chipsets including:
> > > > >   G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
> > > > >   PineView-M (Atom N400 series)
> > > > >   PineView-D (Atom D400/D500 series)
> > > > > - Intel(R) HD Graphics: 2000-6000,
> > > > > + Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > > > >   Intel(R) Iris(TM) Graphics: 5100/6100, and
> > > > >   Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> > > > >  
> > > > > diff --git a/man/intel.man b/man/intel.man
> > > > > index 8da496e..16cc5d9 100644
> > > > > --- a/man/intel.man
> > > > > +++ b/man/intel.man
> > > > > @@ -27,7 +27,7 @@ supports the i810, i810-DC100, i810e, i815, i830M, 
> > > > > 845G, 852GM, 855GM,
> > > > >  865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME,
> > > > >  G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in
> > > > >  Atom N400 series, Pineview-D in Atom D400/D500 series,
> > > > > -Intel(R) HD Graphics: 2000-6000,
> > > > > +Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > > > >  Intel(R) Iris(TM) Graphics: 5100/6100, and
> > > > >  Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> > > > >  
> > > > > diff --git a/src/intel_module.c b/src/intel_module.c
> > > > > index e443c9e..86b4aae 100644
> > > > > --- a/src/intel_module.c
> > > > > +++ b/src/intel_module.c
> > > > > @@ -272,6 +272,33 @@ static const SymTabRec intel_chipsets[] = {
> > > > >   {0x22b2, "HD Graphics"},
> > > > >   {0x22b3, "HD Graphics"},
> > > > >  
> > > > > + /* Skylake */
> > > > > + {0x1902, "HD Graphics 510"},
> > > > > + {0x1906, "HD Graphics 510"},
> > > > > + {0x190B, "HD Graphics 510"},
> > > > > + {0x1912, "HD Graphics 530"},
> > > > > + {0x1916, "HD Graphics 520"},
> > > > > + {0x191B, "HD Graphics 530"},
> > > > > + {0x191D, "HD Graphics P530"},
> > > > > + {0x191E, "HD Graphics 515"},
> > > > > + {0x1921, "HD Graphics 520"},
> > > > > + {0x1926, "Iris Graphics 540"},
> > > > > + {0x1927, "Iris Graphics 550"},
> > > > > + {0x192B, "Iris Graphics 555"},
> > > > > + {0x192D, "Iris Graphics P555"},
> > > > > + {0x1932, "Iris Pro Graphics 580"},
> > > > > + {0x193A, "Iris Pro Graphics P580"},
> > > > > + {0x193B, "Iris Pro Graphics 580"},
> > > > > + {0x193D, "Iris Pro Graphics P580"},
> > > > > +
> > > > > + /* Broxton (Apollolake) */
> > > > > + {0x5A84, "HD Graphics 505"},
> > > > > + {0x5A85, "HD Graphics 500"},
> > > > > +
> > > > > + /* Kabylake */
> > > > > + {0x5916, "HD Graphics 620"},
> > > > > + {0x591E, "HD Graphics 615"},
> > > > > +
> > > > >   /* When adding new identifiers, also update:
> > > > >* 1. intel_identify()
> > > > >* 2. man/intel.man
> > > > > @@ -465,7 +492,7 @@ static void intel_identify(int flags)
> > > > >   if (unique != stack)
> > > > >   free(unique);
> > > > >  
> > > > > - xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > > > > 2000-6000\n");
> > > > > + xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > > > > 500-6000/P530/P555/P580\n");
> > > > >   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) 
> > > > > Graphics: 5100, 6100\n");
> > > > >   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
> > > > > Graphics: 5200, 6200, P6300\n");
> > > > 
> > > > You missed the Iris & Iris Pro models.
> > > 
> > > Thanks
> > > 
> > > > 
> > > > Also, might it make sense to use 5xx, P5xx instead?
> > > 
> > > What about ont those generic lists we just kill all numbers and let just:
> > > "
> > >Intel(R) HD Graphics.
> > >Intel(R) Iris(TM) Graphics.
> > >Intel(R) Iris(TM) Pro Graphics.
> > > '
> > > ?
> > > 
> > > Chris?
> > 
> > Seems reasonable, and as demonstrated in the past simply listing
> > everything becomes unwieldy, if not unfathomable, quickly.
> > 
> > I honestly don't think the listing here is the primary source for
> > compatibility info
> 
> agree
> 
> >  (since to get here means that the driver recognised
> > the chipset 

[Intel-gfx] [CI 1/2] drm/i915: add i915_address_space_fini

[Chris Wilson]

From: Matthew Auld 

We already have an i915_address_space_init, so for symmetry we should
also have a _fini, plus we already open code it twice. This then also
fixes a bug where we leak the timeline for the ggtt vm.

v2: don't forget about the struct_mutex for the ggtt path.

Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 75a0f2d4e62f..b4bde1452f2a 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2196,6 +2196,13 @@ static void i915_address_space_init(struct 
i915_address_space *vm,
list_add_tail(>global_link, _priv->vm_list);
 }
 
+static void i915_address_space_fini(struct i915_address_space *vm)
+{
+   i915_gem_timeline_fini(>timeline);
+   drm_mm_takedown(>mm);
+   list_del(>global_link);
+}
+
 static void gtt_write_workarounds(struct drm_i915_private *dev_priv)
 {
/* This function is for gtt related workarounds. This function is
@@ -2278,7 +2285,7 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
return ppgtt;
 }
 
-void  i915_ppgtt_release(struct kref *kref)
+void i915_ppgtt_release(struct kref *kref)
 {
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
@@ -2290,9 +2297,7 @@ void  i915_ppgtt_release(struct kref *kref)
WARN_ON(!list_empty(>base.inactive_list));
WARN_ON(!list_empty(>base.unbound_list));
 
-   i915_gem_timeline_fini(>base.timeline);
-   list_del(>base.global_link);
-   drm_mm_takedown(>base.mm);
+   i915_address_space_fini(>base);
 
ppgtt->base.cleanup(>base);
kfree(ppgtt);
@@ -2833,8 +2838,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private 
*dev_priv)
if (drm_mm_initialized(>base.mm)) {
intel_vgt_deballoon(dev_priv);
 
-   drm_mm_takedown(>base.mm);
-   list_del(>base.global_link);
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_address_space_fini(>base);
+   mutex_unlock(_priv->drm.struct_mutex);
}
 
ggtt->base.cleanup(>base);
-- 
2.10.2

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

[Intel-gfx] [CI 2/2] drm/i915: don't leak global_timeline

[Chris Wilson]

From: Matthew Auld 

We need to clean up the global_timeline in i915_gem_load_cleanup.

v2: don't forget about the struct_mutex, and also WARN_ON if we have any
remaining timelines before purging the global_timeline.

v3: it might be a good idea to first remove the global_timeline...duh!

Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline 
struct")
Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
Reviewed-by: Chris Wilson 
Signed-off-by: Chris Wilson 
Link: 
http://patchwork.freedesktop.org/patch/msgid/1479415087-13216-1-git-send-email-matthew.a...@intel.com
---
 drivers/gpu/drm/i915/i915_gem.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 1fa3813976e5..7b9f5b99b0f3 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4554,6 +4554,11 @@ void i915_gem_load_cleanup(struct drm_device *dev)
 
WARN_ON(!llist_empty(_priv->mm.free_list));
 
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   WARN_ON(!list_empty(_priv->gt.timelines));
+   mutex_unlock(_priv->drm.struct_mutex);
+
kmem_cache_destroy(dev_priv->dependencies);
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
-- 
2.10.2

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

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

[Vivi, Rodrigo]

On Thu, 2016-11-17 at 19:35 +, Chris Wilson wrote:
> On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote:
> > On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote:
> > > On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote:
> > > > This commit adding all known marketing names for latest gen9 platforms.
> > > > 
> > > > Cc: Chris Wilson 
> > > > Signed-off-by: Rodrigo Vivi 
> > > > ---
> > > >  README |  2 +-
> > > >  man/intel.man  |  2 +-
> > > >  src/intel_module.c | 29 -
> > > >  3 files changed, 30 insertions(+), 3 deletions(-)
> > > > 
> > > > diff --git a/README b/README
> > > > index cf4d88d..e58477d 100644
> > > > --- a/README
> > > > +++ b/README
> > > > @@ -15,7 +15,7 @@ Intel graphics chipsets including:
> > > > G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
> > > > PineView-M (Atom N400 series)
> > > > PineView-D (Atom D400/D500 series)
> > > > -   Intel(R) HD Graphics: 2000-6000,
> > > > +   Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > > > Intel(R) Iris(TM) Graphics: 5100/6100, and
> > > > Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> > > >  
> > > > diff --git a/man/intel.man b/man/intel.man
> > > > index 8da496e..16cc5d9 100644
> > > > --- a/man/intel.man
> > > > +++ b/man/intel.man
> > > > @@ -27,7 +27,7 @@ supports the i810, i810-DC100, i810e, i815, i830M, 
> > > > 845G, 852GM, 855GM,
> > > >  865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME,
> > > >  G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in
> > > >  Atom N400 series, Pineview-D in Atom D400/D500 series,
> > > > -Intel(R) HD Graphics: 2000-6000,
> > > > +Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > > >  Intel(R) Iris(TM) Graphics: 5100/6100, and
> > > >  Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> > > >  
> > > > diff --git a/src/intel_module.c b/src/intel_module.c
> > > > index e443c9e..86b4aae 100644
> > > > --- a/src/intel_module.c
> > > > +++ b/src/intel_module.c
> > > > @@ -272,6 +272,33 @@ static const SymTabRec intel_chipsets[] = {
> > > > {0x22b2, "HD Graphics"},
> > > > {0x22b3, "HD Graphics"},
> > > >  
> > > > +   /* Skylake */
> > > > +   {0x1902, "HD Graphics 510"},
> > > > +   {0x1906, "HD Graphics 510"},
> > > > +   {0x190B, "HD Graphics 510"},
> > > > +   {0x1912, "HD Graphics 530"},
> > > > +   {0x1916, "HD Graphics 520"},
> > > > +   {0x191B, "HD Graphics 530"},
> > > > +   {0x191D, "HD Graphics P530"},
> > > > +   {0x191E, "HD Graphics 515"},
> > > > +   {0x1921, "HD Graphics 520"},
> > > > +   {0x1926, "Iris Graphics 540"},
> > > > +   {0x1927, "Iris Graphics 550"},
> > > > +   {0x192B, "Iris Graphics 555"},
> > > > +   {0x192D, "Iris Graphics P555"},
> > > > +   {0x1932, "Iris Pro Graphics 580"},
> > > > +   {0x193A, "Iris Pro Graphics P580"},
> > > > +   {0x193B, "Iris Pro Graphics 580"},
> > > > +   {0x193D, "Iris Pro Graphics P580"},
> > > > +
> > > > +   /* Broxton (Apollolake) */
> > > > +   {0x5A84, "HD Graphics 505"},
> > > > +   {0x5A85, "HD Graphics 500"},
> > > > +
> > > > +   /* Kabylake */
> > > > +   {0x5916, "HD Graphics 620"},
> > > > +   {0x591E, "HD Graphics 615"},
> > > > +
> > > > /* When adding new identifiers, also update:
> > > >  * 1. intel_identify()
> > > >  * 2. man/intel.man
> > > > @@ -465,7 +492,7 @@ static void intel_identify(int flags)
> > > > if (unique != stack)
> > > > free(unique);
> > > >  
> > > > -   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > > > 2000-6000\n");
> > > > +   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > > > 500-6000/P530/P555/P580\n");
> > > > xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) 
> > > > Graphics: 5100, 6100\n");
> > > > xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
> > > > Graphics: 5200, 6200, P6300\n");
> > > 
> > > You missed the Iris & Iris Pro models.
> > 
> > Thanks
> > 
> > > 
> > > Also, might it make sense to use 5xx, P5xx instead?
> > 
> > What about ont those generic lists we just kill all numbers and let just:
> > "
> >Intel(R) HD Graphics.
> >Intel(R) Iris(TM) Graphics.
> >Intel(R) Iris(TM) Pro Graphics.
> > '
> > ?
> > 
> > Chris?
> 
> Seems reasonable, and as demonstrated in the past simply listing
> everything becomes unwieldy, if not unfathomable, quickly.
> 
> I honestly don't think the listing here is the primary source for
> compatibility info

agree

>  (since to get here means that the driver recognised
> the chipset anyway).

If it is already recognized at this intel_identify point, is it possible
to grab the device id and than run on that list and only print the know
market name?
or that is better to let there on detect function?


>  For 

Re: [Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

[Chris Wilson]

On Thu, Nov 17, 2016 at 08:38:07PM +, Matthew Auld wrote:
> We need to clean up the global_timeline in i915_gem_load_cleanup.
> 
> v2: don't forget about the struct_mutex, and also WARN_ON if we have any
> remaining timelines before purging the global_timeline.
> 
> v3: it might be a good idea to first remove the global_timeline...duh!
> 
> Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global 
> timeline struct")
> Cc: Chris Wilson 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3fb5e66e4d65..b7a8c8349ccb 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4557,6 +4557,12 @@ void i915_gem_load_cleanup(struct drm_device *dev)
>  
>   WARN_ON(!llist_empty(_priv->mm.free_list));
>  
> + mutex_lock(_priv->drm.struct_mutex);
> + i915_gem_timeline_fini(_priv->gt.global_timeline);
> + mutex_unlock(_priv->drm.struct_mutex);
> +
> + WARN_ON(!list_empty(_priv->gt.timelines));

I would have plonked this under the mutex, then it mirrors the 

mutex_lock()
INIT_LIST_HEAD()
i915_gem_timeline_init(_priv->gt.global_timeline);
mutex_unlock()

we do at the start.

Reviewed-by: Chris Wilson 

I'll surreptiously do that, and send this pair to CI together since the
order is important to avoid adding this WARN before the fix.
-Chris

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

Re: [Intel-gfx] [PATCH] drm/i915: add i915_address_space_fini

[Chris Wilson]

On Thu, Nov 17, 2016 at 08:53:15PM +, Matthew Auld wrote:
> We already have an i915_address_space_init, so for symmetry we should
> also have a _fini, plus we already open code it twice. This then also
> fixes a bug where we leak the timeline for the ggtt vm.
> 
> v2: don't forget about the struct_mutex for the ggtt path.
> 
> Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
> Cc: Chris Wilson 
> Signed-off-by: Matthew Auld 

> @@ -2279,7 +2286,7 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
>   return ppgtt;
>  }
>  
> -void  i915_ppgtt_release(struct kref *kref)
> +void i915_ppgtt_release(struct kref *kref)

Finally!
Reviewed-by: Chris Wilson 

I'm sure the rest of the patch is just as good ;)
-Chris

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

[Intel-gfx] [PATCH] drm/i915: add i915_address_space_fini

[Matthew Auld]

We already have an i915_address_space_init, so for symmetry we should
also have a _fini, plus we already open code it twice. This then also
fixes a bug where we leak the timeline for the ggtt vm.

v2: don't forget about the struct_mutex for the ggtt path.

Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem_gtt.c | 18 --
 1 file changed, 12 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c 
b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 01f238adfb67..b259f3de2502 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -2193,6 +2193,13 @@ static void i915_address_space_init(struct 
i915_address_space *vm,
list_add_tail(>global_link, _priv->vm_list);
 }
 
+static void i915_address_space_fini(struct i915_address_space *vm)
+{
+   i915_gem_timeline_fini(>timeline);
+   drm_mm_takedown(>mm);
+   list_del(>global_link);
+}
+
 static void gtt_write_workarounds(struct drm_device *dev)
 {
struct drm_i915_private *dev_priv = to_i915(dev);
@@ -2279,7 +2286,7 @@ i915_ppgtt_create(struct drm_i915_private *dev_priv,
return ppgtt;
 }
 
-void  i915_ppgtt_release(struct kref *kref)
+void i915_ppgtt_release(struct kref *kref)
 {
struct i915_hw_ppgtt *ppgtt =
container_of(kref, struct i915_hw_ppgtt, ref);
@@ -2291,9 +2298,7 @@ void  i915_ppgtt_release(struct kref *kref)
WARN_ON(!list_empty(>base.inactive_list));
WARN_ON(!list_empty(>base.unbound_list));
 
-   i915_gem_timeline_fini(>base.timeline);
-   list_del(>base.global_link);
-   drm_mm_takedown(>base.mm);
+   i915_address_space_fini(>base);
 
ppgtt->base.cleanup(>base);
kfree(ppgtt);
@@ -2835,8 +2840,9 @@ void i915_ggtt_cleanup_hw(struct drm_i915_private 
*dev_priv)
if (drm_mm_initialized(>base.mm)) {
intel_vgt_deballoon(dev_priv);
 
-   drm_mm_takedown(>base.mm);
-   list_del(>base.global_link);
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_address_space_fini(>base);
+   mutex_unlock(_priv->drm.struct_mutex);
}
 
ggtt->base.cleanup(>base);
-- 
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: warning for drm/i915: don't leak global_timeline (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: don't leak global_timeline (rev2)
URL   : https://patchwork.freedesktop.org/series/15439/
State : warning

== Summary ==

Series 15439v2 drm/i915: don't leak global_timeline
https://patchwork.freedesktop.org/api/1.0/series/15439/revisions/2/mbox/

Test drv_module_reload_basic:
pass   -> DMESG-WARN (fi-ivb-3770)
pass   -> DMESG-WARN (fi-hsw-4770r)
pass   -> DMESG-WARN (fi-byt-n2820)
pass   -> DMESG-WARN (fi-skl-6700hq)
pass   -> DMESG-WARN (fi-hsw-4770)
pass   -> DMESG-WARN (fi-byt-j1900)
pass   -> DMESG-WARN (fi-bsw-n3050)
pass   -> DMESG-WARN (fi-ilk-650)
pass   -> DMESG-WARN (fi-kbl-7200u)
pass   -> DMESG-WARN (fi-snb-2600)
pass   -> DMESG-WARN (fi-skl-6260u)
pass   -> DMESG-WARN (fi-snb-2520m)
pass   -> DMESG-WARN (fi-ivb-3520m)
pass   -> DMESG-WARN (fi-bdw-5557u)

fi-bdw-5557u total:244  pass:228  dwarn:1   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:203  dwarn:1   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:215  dwarn:1   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:215  dwarn:1   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:223  dwarn:1   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:223  dwarn:1   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:190  dwarn:1   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:221  dwarn:1   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:210  dwarn:1   dfail:0   fail:0   skip:33 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
d113c2a drm/i915: don't leak global_timeline

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

[Matthew Auld]

We need to clean up the global_timeline in i915_gem_load_cleanup.

v2: don't forget about the struct_mutex, and also WARN_ON if we have any
remaining timelines before purging the global_timeline.

v3: it might be a good idea to first remove the global_timeline...duh!

Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline 
struct")
Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3fb5e66e4d65..b7a8c8349ccb 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4557,6 +4557,12 @@ void i915_gem_load_cleanup(struct drm_device *dev)
 
WARN_ON(!llist_empty(_priv->mm.free_list));
 
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   mutex_unlock(_priv->drm.struct_mutex);
+
+   WARN_ON(!list_empty(_priv->gt.timelines));
+
kmem_cache_destroy(dev_priv->dependencies);
kmem_cache_destroy(dev_priv->requests);
kmem_cache_destroy(dev_priv->vmas);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

[Ville Syrjälä]

On Thu, Nov 17, 2016 at 06:29:45PM -0200, Paulo Zanoni wrote:
> Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > Let's try not to abuse plane->plane for sprites on VLV/CHV and
> > instead
> > use plane->id. Since out watermark structures aren't entirely plane
> > type
> > agnostic (for now) and start indexing sprites from 0  we'll add a
> > small
> > helper to convert between the two bases.
> 
> I'm not sure I like this one. We've been using plane_id for the actual
> prim/spr/cur IDs, and now we use plane_id for something that's supposed
> to mean A/B/C. I really think we should have different words to refer
> to the two things. I think this goes back to Matt's renaming discussion
> we've been having in patch 2. Let's solve it there first before we
> revisit this patch. I'm still not sure what would be the ideal solution
> here, I'll spend some time thinking.

Replied to the wrong patch?

> 
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_pm.c | 73 ---
> > --
> >  1 file changed, 36 insertions(+), 37 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index fd8cbc224b07..b1ad09e458ca 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -371,12 +371,15 @@ static const int pessimal_latency_ns = 5000;
> >  #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
> >     dsparb) >> (lo_shift)) & 0xff) | dsparb2) >>
> > (hi_shift)) & 0x1) << 8))
> >  
> > -static int vlv_get_fifo_size(struct drm_i915_private *dev_priv,
> > -     enum pipe pipe, int plane)
> > +static int vlv_get_fifo_size(struct intel_plane *plane)
> >  {
> > +   struct drm_i915_private *dev_priv = to_i915(plane-
> > >base.dev);
> >     int sprite0_start, sprite1_start, size;
> >  
> > -   switch (pipe) {
> > +   if (plane->id == PLANE_CURSOR)
> > +   return 63;
> > +
> > +   switch (plane->pipe) {
> >     uint32_t dsparb, dsparb2, dsparb3;
> >     case PIPE_A:
> >     dsparb = I915_READ(DSPARB);
> > @@ -400,24 +403,21 @@ static int vlv_get_fifo_size(struct
> > drm_i915_private *dev_priv,
> >     return 0;
> >     }
> >  
> > -   switch (plane) {
> > -   case 0:
> > +   switch (plane->id) {
> > +   case PLANE_PRIMARY:
> >     size = sprite0_start;
> >     break;
> > -   case 1:
> > +   case PLANE_SPRITE0:
> >     size = sprite1_start - sprite0_start;
> >     break;
> > -   case 2:
> > +   case PLANE_SPRITE1:
> >     size = 512 - 1 - sprite1_start;
> >     break;
> >     default:
> >     return 0;
> >     }
> >  
> > -   DRM_DEBUG_KMS("Pipe %c %s %c FIFO size: %d\n",
> > -     pipe_name(pipe), plane == 0 ? "primary" :
> > "sprite",
> > -     plane == 0 ? plane_name(pipe) :
> > sprite_name(pipe, plane - 1),
> > -     size);
> > +   DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
> >  
> >     return size;
> >  }
> > @@ -1054,6 +1054,12 @@ static void vlv_compute_fifo(struct intel_crtc
> > *crtc)
> >     WARN_ON(fifo_left != 0);
> >  }
> >  
> > +/* FIXME kill me */
> > +static inline int vlv_sprite_id(enum plane_id plane_id)
> > +{
> > +   return plane_id - PLANE_SPRITE0;
> > +}
> > +
> >  static void vlv_invert_wms(struct intel_crtc *crtc)
> >  {
> >     struct vlv_wm_state *wm_state = >wm_state;
> > @@ -1079,7 +1085,7 @@ static void vlv_invert_wms(struct intel_crtc
> > *crtc)
> >     wm_state->wm[level].primary;
> >     break;
> >     case DRM_PLANE_TYPE_OVERLAY:
> > -   sprite = plane->plane;
> > +   sprite = vlv_sprite_id(plane->id);
> >     wm_state->wm[level].sprite[sprite] =
> > plane->wm.fifo_size -
> >     wm_state-
> > >wm[level].sprite[sprite];
> >     break;
> > @@ -1143,7 +1149,7 @@ static void vlv_compute_wm(struct intel_crtc
> > *crtc)
> >     wm_state->wm[level].primary = wm;
> >     break;
> >     case DRM_PLANE_TYPE_OVERLAY:
> > -   sprite = plane->plane;
> > +   sprite = vlv_sprite_id(plane->id);
> >     wm_state->wm[level].sprite[sprite] =
> > wm;
> >     break;
> >     }
> > @@ -1169,7 +1175,7 @@ static void vlv_compute_wm(struct intel_crtc
> > *crtc)
> >     wm_state-
> > >wm[level].primary);
> >     break;
> >     case DRM_PLANE_TYPE_OVERLAY:
> > -   sprite = plane->plane;
> > +   sprite = 

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

[Paulo Zanoni]

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Let's try not to abuse plane->plane for sprites on VLV/CHV and
> instead
> use plane->id. Since out watermark structures aren't entirely plane
> type
> agnostic (for now) and start indexing sprites from 0  we'll add a
> small
> helper to convert between the two bases.

I'm not sure I like this one. We've been using plane_id for the actual
prim/spr/cur IDs, and now we use plane_id for something that's supposed
to mean A/B/C. I really think we should have different words to refer
to the two things. I think this goes back to Matt's renaming discussion
we've been having in patch 2. Let's solve it there first before we
revisit this patch. I'm still not sure what would be the ideal solution
here, I'll spend some time thinking.

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 73 ---
> --
>  1 file changed, 36 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index fd8cbc224b07..b1ad09e458ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -371,12 +371,15 @@ static const int pessimal_latency_ns = 5000;
>  #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
>   dsparb) >> (lo_shift)) & 0xff) | dsparb2) >>
> (hi_shift)) & 0x1) << 8))
>  
> -static int vlv_get_fifo_size(struct drm_i915_private *dev_priv,
> -   enum pipe pipe, int plane)
> +static int vlv_get_fifo_size(struct intel_plane *plane)
>  {
> + struct drm_i915_private *dev_priv = to_i915(plane-
> >base.dev);
>   int sprite0_start, sprite1_start, size;
>  
> - switch (pipe) {
> + if (plane->id == PLANE_CURSOR)
> + return 63;
> +
> + switch (plane->pipe) {
>   uint32_t dsparb, dsparb2, dsparb3;
>   case PIPE_A:
>   dsparb = I915_READ(DSPARB);
> @@ -400,24 +403,21 @@ static int vlv_get_fifo_size(struct
> drm_i915_private *dev_priv,
>   return 0;
>   }
>  
> - switch (plane) {
> - case 0:
> + switch (plane->id) {
> + case PLANE_PRIMARY:
>   size = sprite0_start;
>   break;
> - case 1:
> + case PLANE_SPRITE0:
>   size = sprite1_start - sprite0_start;
>   break;
> - case 2:
> + case PLANE_SPRITE1:
>   size = 512 - 1 - sprite1_start;
>   break;
>   default:
>   return 0;
>   }
>  
> - DRM_DEBUG_KMS("Pipe %c %s %c FIFO size: %d\n",
> -   pipe_name(pipe), plane == 0 ? "primary" :
> "sprite",
> -   plane == 0 ? plane_name(pipe) :
> sprite_name(pipe, plane - 1),
> -   size);
> + DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
>  
>   return size;
>  }
> @@ -1054,6 +1054,12 @@ static void vlv_compute_fifo(struct intel_crtc
> *crtc)
>   WARN_ON(fifo_left != 0);
>  }
>  
> +/* FIXME kill me */
> +static inline int vlv_sprite_id(enum plane_id plane_id)
> +{
> + return plane_id - PLANE_SPRITE0;
> +}
> +
>  static void vlv_invert_wms(struct intel_crtc *crtc)
>  {
>   struct vlv_wm_state *wm_state = >wm_state;
> @@ -1079,7 +1085,7 @@ static void vlv_invert_wms(struct intel_crtc
> *crtc)
>   wm_state->wm[level].primary;
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - sprite = plane->plane;
> + sprite = vlv_sprite_id(plane->id);
>   wm_state->wm[level].sprite[sprite] =
> plane->wm.fifo_size -
>   wm_state-
> >wm[level].sprite[sprite];
>   break;
> @@ -1143,7 +1149,7 @@ static void vlv_compute_wm(struct intel_crtc
> *crtc)
>   wm_state->wm[level].primary = wm;
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - sprite = plane->plane;
> + sprite = vlv_sprite_id(plane->id);
>   wm_state->wm[level].sprite[sprite] =
> wm;
>   break;
>   }
> @@ -1169,7 +1175,7 @@ static void vlv_compute_wm(struct intel_crtc
> *crtc)
>   wm_state-
> >wm[level].primary);
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - sprite = plane->plane;
> + sprite = vlv_sprite_id(plane->id);
>   for (level = 0; level < wm_state-
> >num_levels; level++)
>   wm_state->sr[level].plane =
>   min(wm_state-
> >sr[level].plane,
> @@ 

Re: [Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

[Chris Wilson]

On Thu, Nov 17, 2016 at 08:20:05PM +, Matthew Auld wrote:
> We need to clean up the global_timeline in i915_gem_load_cleanup.
> 
> v2: don't forget about the struct_mutex, and also WARN_ON if we have any
> remaining timelines before purging the global_timeline.
> 
> Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global 
> timeline struct")
> Cc: Chris Wilson 
> Signed-off-by: Matthew Auld 
> ---
>  drivers/gpu/drm/i915/i915_gem.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
> index 3fb5e66e4d65..f507e14d6231 100644
> --- a/drivers/gpu/drm/i915/i915_gem.c
> +++ b/drivers/gpu/drm/i915/i915_gem.c
> @@ -4556,6 +4556,11 @@ void i915_gem_load_cleanup(struct drm_device *dev)
>   struct drm_i915_private *dev_priv = to_i915(dev);
>  
>   WARN_ON(!llist_empty(_priv->mm.free_list));
> + WARN_ON(!list_empty(_priv->gt.timelines));
> +
> + mutex_lock(_priv->drm.struct_mutex);
> + i915_gem_timeline_fini(_priv->gt.global_timeline);
> + mutex_unlock(_priv->drm.struct_mutex);

Remove the global timeline from the list then warn... :)
-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: failure for series starting with [1/3] HAX drm/i915: Enable guc submission

[Patchwork]

== Series Details ==

Series: series starting with [1/3] HAX drm/i915: Enable guc submission
URL   : https://patchwork.freedesktop.org/series/15516/
State : failure

== Summary ==

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

Test core_auth:
Subgroup basic-auth:
pass   -> INCOMPLETE (fi-ilk-650)
Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
pass   -> DMESG-WARN (fi-skl-6260u)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-ilk-650   total:1pass:0dwarn:0   dfail:0   fail:0   skip:0  
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
5dee6e6 drm/i915/guc: Split hw submission for replay after GPU reset
74a14fb drm/i915/guc: Keep the execbuf client allocated across reset
27acff7 HAX drm/i915: Enable guc submission

== Logs ==

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

[Intel-gfx] [PATCH] drm/i915: don't leak global_timeline

[Matthew Auld]

We need to clean up the global_timeline in i915_gem_load_cleanup.

v2: don't forget about the struct_mutex, and also WARN_ON if we have any
remaining timelines before purging the global_timeline.

Fixes: 73cb97010d4f ("drm/i915: Combine seqno + tracking into a global timeline 
struct")
Cc: Chris Wilson 
Signed-off-by: Matthew Auld 
---
 drivers/gpu/drm/i915/i915_gem.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 3fb5e66e4d65..f507e14d6231 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -4556,6 +4556,11 @@ void i915_gem_load_cleanup(struct drm_device *dev)
struct drm_i915_private *dev_priv = to_i915(dev);
 
WARN_ON(!llist_empty(_priv->mm.free_list));
+   WARN_ON(!list_empty(_priv->gt.timelines));
+
+   mutex_lock(_priv->drm.struct_mutex);
+   i915_gem_timeline_fini(_priv->gt.global_timeline);
+   mutex_unlock(_priv->drm.struct_mutex);
 
kmem_cache_destroy(dev_priv->dependencies);
kmem_cache_destroy(dev_priv->requests);
-- 
2.7.4

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

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

[Ville Syrjälä]

On Thu, Nov 17, 2016 at 06:07:36PM -0200, Paulo Zanoni wrote:
> Em Ter, 2016-11-08 às 19:09 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > Use intel_plane->id to derive the VLV/CHV sprite register offsets
> > instead of abusing plane->plane which is really meant to for
> > primary planes only.
> 
> I think this patch is kinda an argument against the series due to the
> new SPRITE0 subtractions, but I still think we're better with the
> series applied.

I really don't want to have two different kinds of per-pipe plane
identifiers. So the subtractions are IMO an accpeptable tradeoff for
that.

> 
> A little more below:
> 
> > 
> > v2: Convert assert_sprites_disabled() over as well
> > 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_reg.h  | 58 +++---
> > --
> >  drivers/gpu/drm/i915/intel_display.c |  2 +-
> >  drivers/gpu/drm/i915/intel_sprite.c  | 74 ++--
> > 
> >  3 files changed, 70 insertions(+), 64 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_reg.h
> > b/drivers/gpu/drm/i915/i915_reg.h
> > index 3361d7ffc63e..9739e97c6263 100644
> > --- a/drivers/gpu/drm/i915/i915_reg.h
> > +++ b/drivers/gpu/drm/i915/i915_reg.h
> > @@ -5374,18 +5374,21 @@ enum {
> >  #define _SPBCONSTALPHA (VLV_DISPLAY_BASE + 0x722a8)
> >  #define _SPBGAMC   (VLV_DISPLAY_BASE + 0x722f4)
> >  
> > -#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPACNTR, _SPBCNTR)
> > -#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPALINOFF, _SPBLINOFF)
> > -#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPASTRIDE, _SPBSTRIDE)
> > -#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS,
> > _SPBPOS)
> > -#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPASIZE, _SPBSIZE)
> > -#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPAKEYMINVAL, _SPBKEYMINVAL)
> > -#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPAKEYMSK, _SPBKEYMSK)
> > -#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPASURF, _SPBSURF)
> > -#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> > -#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPATILEOFF, _SPBTILEOFF)
> > -#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPACONSTALPHA, _SPBCONSTALPHA)
> > -#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> > _SPAGAMC, _SPBGAMC)
> > +#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) \
> > +   _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a),
> > (reg_b))
> 
> But but but you nicely renamed everything to plane_id and now you
> create a macro with plane instead of plane_id?

Rather I kept the 'plane' naming here because, well, I'm lazy :)

> I'll have to call Ville
> to fix this inconsistency.

I can re-sed it a bit.

> 
> (this applies to all changes in this file)
> 
> > +
> > +#define SPCNTR(pipe, plane)_MMIO_VLV_SPR((pipe),
> > (plane), _SPACNTR, _SPBCNTR)
> > +#define SPLINOFF(pipe, plane)  _MMIO_VLV_SPR((pipe),
> > (plane), _SPALINOFF, _SPBLINOFF)
> > +#define SPSTRIDE(pipe, plane)  _MMIO_VLV_SPR((pipe),
> > (plane), _SPASTRIDE, _SPBSTRIDE)
> > +#define SPPOS(pipe, plane) _MMIO_VLV_SPR((pipe),
> > (plane), _SPAPOS, _SPBPOS)
> > +#define SPSIZE(pipe, plane)_MMIO_VLV_SPR((pipe),
> > (plane), _SPASIZE, _SPBSIZE)
> > +#define SPKEYMINVAL(pipe, plane)   _MMIO_VLV_SPR((pipe),
> > (plane), _SPAKEYMINVAL, _SPBKEYMINVAL)
> > +#define SPKEYMSK(pipe, plane)  _MMIO_VLV_SPR((pipe),
> > (plane), _SPAKEYMSK, _SPBKEYMSK)
> > +#define SPSURF(pipe, plane)_MMIO_VLV_SPR((pipe),
> > (plane), _SPASURF, _SPBSURF)
> > +#define SPKEYMAXVAL(pipe, plane)   _MMIO_VLV_SPR((pipe),
> > (plane), _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> > +#define SPTILEOFF(pipe, plane) _MMIO_VLV_SPR((pipe),
> > (plane), _SPATILEOFF, _SPBTILEOFF)
> > +#define SPCONSTALPHA(pipe, plane)  _MMIO_VLV_SPR((pipe),
> > (plane), _SPACONSTALPHA, _SPBCONSTALPHA)
> > +#define SPGAMC(pipe, plane)_MMIO_VLV_SPR((pipe),
> > (plane), _SPAGAMC, _SPBGAMC)
> >  
> >  /*
> >   * CHV pipe B sprite CSC
> > @@ -5394,29 +5397,32 @@ enum {
> >   * |yg| = |c3 c4 c5| x |yg + yg_ioff| + |yg_ooff|
> >   * |cb|   |c6 c7 c8|   |cb + cr_ioff|   |cb_ooff|
> >   */
> > -#define SPCSCYGOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d900 +
> > (sprite) * 0x1000)
> > -#define SPCSCCBOFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d904 +
> > (sprite) * 0x1000)
> > -#define SPCSCCROFF(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d908 +
> > (sprite) * 0x1000)
> > +#define _MMIO_CHV_SPCSC(plane, reg) \
> > +   _MMIO(VLV_DISPLAY_BASE + ((plane) - PLANE_SPRITE0) * 0x1000
> > + (reg))
> > +
> > +#define SPCSCYGOFF(plane)  

Re: [Intel-gfx] [PATCH 7/9] drm/i915: Use enum plane_id in VLV/CHV wm code

[Paulo Zanoni]

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Let's try not to abuse plane->plane for sprites on VLV/CHV and
> instead
> use plane->id. Since out watermark structures aren't entirely plane
> type
> agnostic (for now) and start indexing sprites from 0  we'll add a
> small
> helper to convert between the two bases.

Reviewed-by: Paulo Zanoni 

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_pm.c | 73 ---
> --
>  1 file changed, 36 insertions(+), 37 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index fd8cbc224b07..b1ad09e458ca 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -371,12 +371,15 @@ static const int pessimal_latency_ns = 5000;
>  #define VLV_FIFO_START(dsparb, dsparb2, lo_shift, hi_shift) \
>   dsparb) >> (lo_shift)) & 0xff) | dsparb2) >>
> (hi_shift)) & 0x1) << 8))
>  
> -static int vlv_get_fifo_size(struct drm_i915_private *dev_priv,
> -   enum pipe pipe, int plane)
> +static int vlv_get_fifo_size(struct intel_plane *plane)
>  {
> + struct drm_i915_private *dev_priv = to_i915(plane-
> >base.dev);
>   int sprite0_start, sprite1_start, size;
>  
> - switch (pipe) {
> + if (plane->id == PLANE_CURSOR)
> + return 63;
> +
> + switch (plane->pipe) {
>   uint32_t dsparb, dsparb2, dsparb3;
>   case PIPE_A:
>   dsparb = I915_READ(DSPARB);
> @@ -400,24 +403,21 @@ static int vlv_get_fifo_size(struct
> drm_i915_private *dev_priv,
>   return 0;
>   }
>  
> - switch (plane) {
> - case 0:
> + switch (plane->id) {
> + case PLANE_PRIMARY:
>   size = sprite0_start;
>   break;
> - case 1:
> + case PLANE_SPRITE0:
>   size = sprite1_start - sprite0_start;
>   break;
> - case 2:
> + case PLANE_SPRITE1:
>   size = 512 - 1 - sprite1_start;
>   break;
>   default:
>   return 0;
>   }
>  
> - DRM_DEBUG_KMS("Pipe %c %s %c FIFO size: %d\n",
> -   pipe_name(pipe), plane == 0 ? "primary" :
> "sprite",
> -   plane == 0 ? plane_name(pipe) :
> sprite_name(pipe, plane - 1),
> -   size);
> + DRM_DEBUG_KMS("%s FIFO size: %d\n", plane->base.name, size);
>  
>   return size;
>  }
> @@ -1054,6 +1054,12 @@ static void vlv_compute_fifo(struct intel_crtc
> *crtc)
>   WARN_ON(fifo_left != 0);
>  }
>  
> +/* FIXME kill me */
> +static inline int vlv_sprite_id(enum plane_id plane_id)
> +{
> + return plane_id - PLANE_SPRITE0;
> +}
> +
>  static void vlv_invert_wms(struct intel_crtc *crtc)
>  {
>   struct vlv_wm_state *wm_state = >wm_state;
> @@ -1079,7 +1085,7 @@ static void vlv_invert_wms(struct intel_crtc
> *crtc)
>   wm_state->wm[level].primary;
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - sprite = plane->plane;
> + sprite = vlv_sprite_id(plane->id);
>   wm_state->wm[level].sprite[sprite] =
> plane->wm.fifo_size -
>   wm_state-
> >wm[level].sprite[sprite];
>   break;
> @@ -1143,7 +1149,7 @@ static void vlv_compute_wm(struct intel_crtc
> *crtc)
>   wm_state->wm[level].primary = wm;
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - sprite = plane->plane;
> + sprite = vlv_sprite_id(plane->id);
>   wm_state->wm[level].sprite[sprite] =
> wm;
>   break;
>   }
> @@ -1169,7 +1175,7 @@ static void vlv_compute_wm(struct intel_crtc
> *crtc)
>   wm_state-
> >wm[level].primary);
>   break;
>   case DRM_PLANE_TYPE_OVERLAY:
> - sprite = plane->plane;
> + sprite = vlv_sprite_id(plane->id);
>   for (level = 0; level < wm_state-
> >num_levels; level++)
>   wm_state->sr[level].plane =
>   min(wm_state-
> >sr[level].plane,
> @@ -1198,17 +1204,23 @@ static void vlv_pipe_set_fifo_size(struct
> intel_crtc *crtc)
>   int sprite0_start = 0, sprite1_start = 0, fifo_size = 0;
>  
>   for_each_intel_plane_on_crtc(dev, crtc, plane) {
> - if (plane->base.type == DRM_PLANE_TYPE_CURSOR) {
> - WARN_ON(plane->wm.fifo_size != 63);
> - continue;
> - }
> -
> - if 

Re: [Intel-gfx] [PATCH v2 6/9] drm/i915: Use enum plane_id in VLV/CHV sprite code

[Paulo Zanoni]

Em Ter, 2016-11-08 às 19:09 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Use intel_plane->id to derive the VLV/CHV sprite register offsets
> instead of abusing plane->plane which is really meant to for
> primary planes only.

I think this patch is kinda an argument against the series due to the
new SPRITE0 subtractions, but I still think we're better with the
series applied.

A little more below:

> 
> v2: Convert assert_sprites_disabled() over as well
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_reg.h  | 58 +++---
> --
>  drivers/gpu/drm/i915/intel_display.c |  2 +-
>  drivers/gpu/drm/i915/intel_sprite.c  | 74 ++--
> 
>  3 files changed, 70 insertions(+), 64 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_reg.h
> b/drivers/gpu/drm/i915/i915_reg.h
> index 3361d7ffc63e..9739e97c6263 100644
> --- a/drivers/gpu/drm/i915/i915_reg.h
> +++ b/drivers/gpu/drm/i915/i915_reg.h
> @@ -5374,18 +5374,21 @@ enum {
>  #define _SPBCONSTALPHA   (VLV_DISPLAY_BASE + 0x722a8)
>  #define _SPBGAMC (VLV_DISPLAY_BASE + 0x722f4)
>  
> -#define SPCNTR(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPACNTR, _SPBCNTR)
> -#define SPLINOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPALINOFF, _SPBLINOFF)
> -#define SPSTRIDE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPASTRIDE, _SPBSTRIDE)
> -#define SPPOS(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane), _SPAPOS,
> _SPBPOS)
> -#define SPSIZE(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPASIZE, _SPBSIZE)
> -#define SPKEYMINVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPAKEYMINVAL, _SPBKEYMINVAL)
> -#define SPKEYMSK(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPAKEYMSK, _SPBKEYMSK)
> -#define SPSURF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPASURF, _SPBSURF)
> -#define SPKEYMAXVAL(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> -#define SPTILEOFF(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPATILEOFF, _SPBTILEOFF)
> -#define SPCONSTALPHA(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPACONSTALPHA, _SPBCONSTALPHA)
> -#define SPGAMC(pipe, plane) _MMIO_PIPE((pipe) * 2 + (plane),
> _SPAGAMC, _SPBGAMC)
> +#define _MMIO_VLV_SPR(pipe, plane, reg_a, reg_b) \
> + _MMIO_PIPE((pipe) * 2 + (plane) - PLANE_SPRITE0, (reg_a),
> (reg_b))

But but but you nicely renamed everything to plane_id and now you
create a macro with plane instead of plane_id? I'll have to call Ville
to fix this inconsistency.

(this applies to all changes in this file)

> +
> +#define SPCNTR(pipe, plane)  _MMIO_VLV_SPR((pipe),
> (plane), _SPACNTR, _SPBCNTR)
> +#define SPLINOFF(pipe, plane)_MMIO_VLV_SPR((pipe),
> (plane), _SPALINOFF, _SPBLINOFF)
> +#define SPSTRIDE(pipe, plane)_MMIO_VLV_SPR((pipe),
> (plane), _SPASTRIDE, _SPBSTRIDE)
> +#define SPPOS(pipe, plane)   _MMIO_VLV_SPR((pipe),
> (plane), _SPAPOS, _SPBPOS)
> +#define SPSIZE(pipe, plane)  _MMIO_VLV_SPR((pipe),
> (plane), _SPASIZE, _SPBSIZE)
> +#define SPKEYMINVAL(pipe, plane) _MMIO_VLV_SPR((pipe),
> (plane), _SPAKEYMINVAL, _SPBKEYMINVAL)
> +#define SPKEYMSK(pipe, plane)_MMIO_VLV_SPR((pipe),
> (plane), _SPAKEYMSK, _SPBKEYMSK)
> +#define SPSURF(pipe, plane)  _MMIO_VLV_SPR((pipe),
> (plane), _SPASURF, _SPBSURF)
> +#define SPKEYMAXVAL(pipe, plane) _MMIO_VLV_SPR((pipe),
> (plane), _SPAKEYMAXVAL, _SPBKEYMAXVAL)
> +#define SPTILEOFF(pipe, plane)   _MMIO_VLV_SPR((pipe),
> (plane), _SPATILEOFF, _SPBTILEOFF)
> +#define SPCONSTALPHA(pipe, plane)_MMIO_VLV_SPR((pipe),
> (plane), _SPACONSTALPHA, _SPBCONSTALPHA)
> +#define SPGAMC(pipe, plane)  _MMIO_VLV_SPR((pipe),
> (plane), _SPAGAMC, _SPBGAMC)
>  
>  /*
>   * CHV pipe B sprite CSC
> @@ -5394,29 +5397,32 @@ enum {
>   * |yg| = |c3 c4 c5| x |yg + yg_ioff| + |yg_ooff|
>   * |cb|   |c6 c7 c8|   |cb + cr_ioff|   |cb_ooff|
>   */
> -#define SPCSCYGOFF(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d900 +
> (sprite) * 0x1000)
> -#define SPCSCCBOFF(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d904 +
> (sprite) * 0x1000)
> -#define SPCSCCROFF(sprite)   _MMIO(VLV_DISPLAY_BASE + 0x6d908 +
> (sprite) * 0x1000)
> +#define _MMIO_CHV_SPCSC(plane, reg) \
> + _MMIO(VLV_DISPLAY_BASE + ((plane) - PLANE_SPRITE0) * 0x1000
> + (reg))
> +
> +#define SPCSCYGOFF(plane)_MMIO_CHV_SPCSC(plane, 0x6d900)
> +#define SPCSCCBOFF(plane)_MMIO_CHV_SPCSC(plane, 0x6d904)
> +#define SPCSCCROFF(plane)_MMIO_CHV_SPCSC(plane, 0x6d908)
>  #define  SPCSC_OOFF(x)   (((x) & 0x7ff) << 16) /* s11
> */
>  #define  SPCSC_IOFF(x)   (((x) & 0x7ff) << 0) /* s11 */
>  
> -#define SPCSCC01(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d90c +
> (sprite) * 0x1000)
> -#define SPCSCC23(sprite) _MMIO(VLV_DISPLAY_BASE + 0x6d910 +
> (sprite) * 0x1000)
> -#define SPCSCC45(sprite) 

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Use enum plane_id in SKL wm code

[Ville Syrjälä]

On Thu, Nov 17, 2016 at 05:12:13PM -0200, Paulo Zanoni wrote:
> Em Qua, 2016-11-09 às 17:03 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > Nuke skl_wm_plane_id() and just use the new intel_plane->id.
> > 
> > v2: Convert skl_write_plane_wm() as well
> > v3: Convert skl_pipe_wm_get_hw_state() correctly
> 
> In general, I really like the fact that we unified plane/id/i into just
> plane_id.
> 
> In general, I dislike the fact that many new lines go past 80 columns
> now :).
> 
> A few comments follow:
> 
> > 
> > Cc: Matt Roper 
> > Cc: Paulo Zanoni 
> > Cc: Maarten Lankhorst 
> > Cc: Lyude 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/intel_drv.h |   2 +-
> >  drivers/gpu/drm/i915/intel_pm.c  | 180 -
> > --
> >  2 files changed, 76 insertions(+), 106 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index a3c696d8bf93..6a4cd6edafa5 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -1751,7 +1751,7 @@ void skl_write_cursor_wm(struct intel_crtc
> > *intel_crtc,
> >  void skl_write_plane_wm(struct intel_crtc *intel_crtc,
> >     const struct skl_plane_wm *wm,
> >     const struct skl_ddb_allocation *ddb,
> > -   int plane);
> > +   enum plane_id plane_id);
> >  uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state
> > *pipe_config);
> >  bool ilk_disable_lp_wm(struct drm_device *dev);
> >  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int
> > enable_rc6);
> > diff --git a/drivers/gpu/drm/i915/intel_pm.c
> > b/drivers/gpu/drm/i915/intel_pm.c
> > index 88e28c989b9c..bae7eea6de16 100644
> > --- a/drivers/gpu/drm/i915/intel_pm.c
> > +++ b/drivers/gpu/drm/i915/intel_pm.c
> > @@ -2863,28 +2863,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
> >  #define SKL_SAGV_BLOCK_TIME30 /* µs */
> >  
> >  /*
> > - * Return the index of a plane in the SKL DDB and wm result
> > arrays.  Primary
> > - * plane is always in slot 0, cursor is always in slot
> > I915_MAX_PLANES-1, and
> > - * other universal planes are in indices 1..n.  Note that this may
> > leave unused
> > - * indices between the top "sprite" plane and the cursor.
> > - */
> > -static int
> > -skl_wm_plane_id(const struct intel_plane *plane)
> > -{
> > -   switch (plane->base.type) {
> > -   case DRM_PLANE_TYPE_PRIMARY:
> > -   return 0;
> > -   case DRM_PLANE_TYPE_CURSOR:
> > -   return PLANE_CURSOR;
> > -   case DRM_PLANE_TYPE_OVERLAY:
> > -   return plane->plane + 1;
> > -   default:
> > -   MISSING_CASE(plane->base.type);
> > -   return plane->plane;
> > -   }
> > -}
> > -
> > -/*
> >   * FIXME: We still don't have the proper code detect if we need to
> > apply the WA,
> >   * so assume we'll always need it in order to avoid underruns.
> >   */
> > @@ -3022,7 +3000,6 @@ bool intel_can_enable_sagv(struct
> > drm_atomic_state *state)
> >     struct intel_crtc *crtc;
> >     struct intel_plane *plane;
> >     struct intel_crtc_state *cstate;
> > -   struct skl_plane_wm *wm;
> >     enum pipe pipe;
> >     int level, latency;
> >  
> > @@ -3049,7 +3026,8 @@ bool intel_can_enable_sagv(struct
> > drm_atomic_state *state)
> >     return false;
> >  
> >     for_each_intel_plane_on_crtc(dev, crtc, plane) {
> > -   wm = 
> > >wm.skl.optimal.planes[skl_wm_plane_id(plane)];
> > +   struct skl_plane_wm *wm =
> > +   >wm.skl.optimal.planes[plane->id];
> >  
> >     /* Skip this plane if it's not enabled */
> >     if (!wm->wm[0].plane_en)
> > @@ -3148,28 +3126,28 @@ static void skl_ddb_entry_init_from_hw(struct
> > skl_ddb_entry *entry, u32 reg)
> >  void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
> >       struct skl_ddb_allocation *ddb /* out */)
> >  {
> > -   enum pipe pipe;
> > -   int plane;
> > +   struct intel_crtc *crtc;
> >     u32 val;
> >  
> >     memset(ddb, 0, sizeof(*ddb));
> >  
> > -   for_each_pipe(dev_priv, pipe) {
> > +   for_each_intel_crtc(_priv->drm, crtc) {
> >     enum intel_display_power_domain power_domain;
> > +   enum plane_id plane_id;
> > +   enum pipe pipe = crtc->pipe;
> >  
> >     power_domain = POWER_DOMAIN_PIPE(pipe);
> >     if (!intel_display_power_get_if_enabled(dev_priv,
> > power_domain))
> >     continue;
> >  
> > -   for_each_universal_plane(dev_priv, pipe, plane) {
> > -   val = I915_READ(PLANE_BUF_CFG(pipe, plane));
> > -   skl_ddb_entry_init_from_hw(
> > >plane[pipe][plane],
> > -      val);
> > -   }

Re: [Intel-gfx] [PATCH 5/5] drm/i915: Implement Link Rate fallback on Link training failure

[Manasi Navare]

On Thu, Nov 17, 2016 at 02:49:02PM +0200, Jani Nikula wrote:
> On Tue, 15 Nov 2016, Manasi Navare  wrote:
> > If link training at a link rate optimal for a particular
> > mode fails during modeset's atomic commit phase, then we
> > let the modeset complete and then retry. We save the link rate
> > value at which link training failed, update the link status property
> > to "BAD" and use a lower link rate to prune the modes. It will redo
> > the modeset on the current mode at lower link rate or if the current
> > mode gets pruned due to lower link constraints then, it will send a
> > hotplug uevent for userspace to handle it.
> >
> > This is also required to pass DP CTS tests 4.3.1.3, 4.3.1.4,
> > 4.3.1.6.
> >
> > v5:
> > * Move set link status to drm core (Daniel Vetter, Jani Nikula)
> > v4:
> > * Add fallback support for non DDI platforms too
> > * Set connector->link status inside set_link_status function
> > (Jani Nikula)
> > v3:
> > * Set link status property to BAd unconditionally (Jani Nikula)
> > * Dont use two separate variables link_train_failed and link_status
> > to indicate same thing (Jani Nikula)
> > v2:
> > * Squashed a few patches (Jani Nikula)
> >
> > Acked-by: Tony Cheng 
> > Acked-by: Harry Wentland 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Cc: Ville Syrjala 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_ddi.c  |  21 +-
> >  drivers/gpu/drm/i915/intel_dp.c   | 102 
> > +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |   6 +-
> >  4 files changed, 131 insertions(+), 10 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_ddi.c 
> > b/drivers/gpu/drm/i915/intel_ddi.c
> > index 0ad4e16..57b7ee9 100644
> > --- a/drivers/gpu/drm/i915/intel_ddi.c
> > +++ b/drivers/gpu/drm/i915/intel_ddi.c
> > @@ -1684,6 +1684,8 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > struct intel_dp *intel_dp = enc_to_intel_dp(>base);
> > struct drm_i915_private *dev_priv = to_i915(encoder->base.dev);
> > enum port port = intel_ddi_get_encoder_port(encoder);
> > +   struct intel_connector *intel_connector = intel_dp->attached_connector;
> > +   struct drm_connector *connector = _connector->base;
> >  
> > intel_dp_set_link_params(intel_dp, link_rate, lane_count,
> >  link_mst);
> > @@ -1694,7 +1696,24 @@ static void intel_ddi_pre_enable_dp(struct 
> > intel_encoder *encoder,
> > intel_prepare_dp_ddi_buffers(encoder);
> > intel_ddi_init_dp_buf_reg(encoder);
> > intel_dp_sink_dpms(intel_dp, DRM_MODE_DPMS_ON);
> > -   intel_dp_start_link_train(intel_dp);
> > +   if (!intel_dp_start_link_train(intel_dp)) {
> > +   DRM_DEBUG_KMS("Link Training failed at link rate = %d, lane 
> > count = %d",
> > + link_rate, lane_count);
> > +   if (!intel_dp_get_link_train_fallback_values(intel_dp,
> > +link_rate,
> > +lane_count))
> > +   /* Schedule a Hotplug Uevent to userspace to start 
> > modeset */
> > +   schedule_work(_connector->modeset_retry_work);
> > +   } else {
> > +   DRM_DEBUG_KMS("Link Training Passed at Link Rate = %d, Lane 
> > count = %d",
> > + link_rate, lane_count);
> > +   intel_dp->fallback_link_rate_index = -1;
> > +   intel_dp->fallback_link_rate = 0;
> > +   intel_dp->fallback_lane_count = 0;
> > +   drm_mode_connector_set_link_status_property(connector,
> > +   
> > DRM_MODE_LINK_STATUS_GOOD);
> > +   }
> 
> Code block with intel_dp_start_link_train() failure handling. Okay.
> 
> > +
> > if (port != PORT_A || INTEL_GEN(dev_priv) >= 9)
> > intel_dp_stop_link_train(intel_dp);
> >  }
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index e87b451..af2f8b2 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -353,8 +353,14 @@ int intel_dp_get_link_train_fallback_values(struct 
> > intel_dp *intel_dp,
> > target_clock = fixed_mode->clock;
> > }
> >  
> > -   max_link_clock = intel_dp_max_link_rate(intel_dp);
> > -   max_lanes = intel_dp_max_lane_count(intel_dp);
> > +   /* Prune the modes using the fallback link rate/lane count */
> > +   if (connector->link_status == DRM_MODE_LINK_STATUS_BAD) {
> > +   max_link_clock = intel_dp->fallback_link_rate;
> > +   max_lanes = intel_dp->fallback_lane_count;
> > +   } else {
> > +   max_link_clock = 

Re: [Intel-gfx] [PATCH 0/5] Handle link training failure during modeset

[Manasi Navare]

On Thu, Nov 17, 2016 at 02:29:30PM +0200, Jani Nikula wrote:
> On Tue, 15 Nov 2016, Manasi Navare  wrote:
> > Submitting new series that adds proper commit messages/cover letter
> > and kernel documentation. It also moved the set_link_status function
> > to drm core so other kernel drivers can make use of it.
> >
> > The idea presented in these patches is to address link training failure
> > in a way that:
> > a) changes the current happy day scenario as little as possible, to avoid
> > regressions, b) can be implemented the same way by all drm drivers, c)
> > is still opt-in for the drivers and userspace, and opting out doesn't
> > regress the user experience, d) doesn't prevent drivers from
> > implementing better or alternate approaches, possibly without userspace
> > involvement. And, of course, handles all the issues presented.
> >
> > The solution is to add a "link status" connector property. In the usual
> > happy day scenario, this is always "good". If something fails during or
> > after a mode set, the kernel driver can set the link status to "bad",
> > prune the mode list based on new information as necessary, and send a
> > hotplug uevent for userspace to have it re-check the valid modes through
> > getconnector, and try again. If the theoretical capabilities of the link
> > can't be reached, the mode list is trimmed based on that.
> >
> > If the userspace is not aware of the property, the user experience is
> > the same as it currently is. If the userspace is aware of the property,
> > it has a chance to improve user experience. If a drm driver does not
> > modify the property (it stays "good"), the user experience is the same
> > as it currently is. A drm driver can also choose to try to handle more
> > of the failures in kernel, hardware not limiting, or it can choose to
> > involve userspace more. Up to the drivers.
> >
> > The reason for adding the property is to handle link training failures,
> > but it is not limited to DP or link training. For example, if we
> > implement asynchronous setcrtc, we can use this to report any failures
> > in that.
> >
> > Finally, while DP CTS compliance is advertized (which is great, and
> > could be made to work similarly for all drm drivers), this can be used
> > for the more important goal of improving user experience on link
> > training failures, by avoiding black screens.
> 
> Since I went through the trouble of writing this, you might as well add
> it to patch 1/5 commit message so it benefits the posterity.
>

Yes, I have also added most of this to the kernel documentation
for the link status property. But I will also add this to Patch 1/5 commit 
message.
Should we explain the alternative approaches as well over there?

Manasi

 
> > Acked-by: Tony Cheng 
> > Acked-by: Harry Wentland 
> 
> These must go to patch 1/5 commit message.
> 
> BR,
> Jani.
> 
> 
> 
> >
> > Manasi Navare (5):
> >   drm: Add a new connector property for link status
> >   drm: Set DRM connector link status property
> >   drm/i915: Update CRTC state if connector link status property changed
> >   drm/i915: Find fallback link rate/lane count
> >   drm/i915: Implement Link Rate fallback on Link training failure
> >
> >  drivers/gpu/drm/drm_atomic_helper.c   |   7 ++
> >  drivers/gpu/drm/drm_connector.c   |  55 ++
> >  drivers/gpu/drm/i915/intel_ddi.c  |  21 +++-
> >  drivers/gpu/drm/i915/intel_dp.c   | 144 
> > +-
> >  drivers/gpu/drm/i915/intel_dp_link_training.c |  12 ++-
> >  drivers/gpu/drm/i915/intel_drv.h  |  10 +-
> >  include/drm/drm_connector.h   |   9 +-
> >  include/drm/drm_crtc.h|   5 +
> >  include/uapi/drm/drm_mode.h   |   4 +
> >  9 files changed, 257 insertions(+), 10 deletions(-)
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only poll DW3_A when init DDI PHY for ports B and C. (rev2)

[Patchwork]

== Series Details ==

Series: drm/i915: Only poll DW3_A when init DDI PHY for ports B and C. (rev2)
URL   : https://patchwork.freedesktop.org/series/15139/
State : success

== Summary ==

Series 15139v2 drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.
https://patchwork.freedesktop.org/api/1.0/series/15139/revisions/2/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
f3e8782 drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

== Logs ==

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

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

[Ville Syrjälä]

On Thu, Nov 17, 2016 at 05:09:38PM -0200, Paulo Zanoni wrote:
> Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
> escreveu:
> > From: Ville Syrjälä 
> > 
> > As I told people in [1] we really should not be confusing enum plane
> > as a per-pipe plane identifier. Looks like that happened nonetheless,
> > so
> > let's fix it up by splitting the two into two enums.
> > 
> > We'll also want something we just directly pass to various register
> > offset macros and whatnot on SKL+. So let's make this new thing work
> > for that.
> > Currently we pass intel_plane->plane for the "sprites" and just a
> > hardcoded zero for the "primary" planes. We want to get rid of that
> > hardocoding so that we can share the same code for all planes (apart
> > from the legacy cursor of course).
> > 
> > [1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/0
> > 76082.html
> > 
> > Cc: Matt Roper 
> > Cc: Daniel Vetter 
> > Signed-off-by: Ville Syrjälä 
> > ---
> >  drivers/gpu/drm/i915/i915_drv.h  | 28 +-
> > --
> >  drivers/gpu/drm/i915/intel_display.c |  2 ++
> >  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
> >  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
> >  4 files changed, 26 insertions(+), 8 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/i915/i915_drv.h
> > b/drivers/gpu/drm/i915/i915_drv.h
> > index 30777dee3f9c..2451b88b1e82 100644
> > --- a/drivers/gpu/drm/i915/i915_drv.h
> > +++ b/drivers/gpu/drm/i915/i915_drv.h
> > @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum
> > transcoder transcoder)
> >  }
> >  
> >  /*
> > - * I915_MAX_PLANES in the enum below is the maximum (across all
> > platforms)
> > - * number of planes per CRTC.  Not all platforms really have this
> > many planes,
> > - * which means some arrays of size I915_MAX_PLANES may have unused
> > entries
> > - * between the topmost sprite plane and the cursor plane.
> > + * Global legacy plane identifier. Valid only for primary/sprite
> > + * planes on pre-g4x, and only for primary planes on g4x+.
> >   */
> >  enum plane {
> > -   PLANE_A = 0,
> > +   PLANE_A,
> >     PLANE_B,
> >     PLANE_C,
> > -   PLANE_CURSOR,
> > -   I915_MAX_PLANES,
> >  };
> >  #define plane_name(p) ((p) + 'A')
> >  
> >  #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)-
> > >num_sprites[(p)] + (s) + 'A')
> >  
> > +/*
> > + * Per-pipe plane identifier.
> > + * I915_MAX_PLANES in the enum below is the maximum (across all
> > platforms)
> > + * number of planes per CRTC.  Not all platforms really have this
> > many planes,
> > + * which means some arrays of size I915_MAX_PLANES may have unused
> > entries
> > + * between the topmost sprite plane and the cursor plane.
> > + *
> > + * This is expected to be passed to various register macros
> > + * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
> > + */
> > +enum plane_id {
> > +   PLANE_PRIMARY,
> > +   PLANE_SPRITE0,
> > +   PLANE_SPRITE1,
> > +   PLANE_CURSOR,
> > +   I915_MAX_PLANES,
> > +};
> 
> We now have two different enums defining PLANE_SOMETHING, and we even
> moved some stuff from one to the other. I think this adds more
> confusion to the code, so we would probably be saner with:
> 
> enum plane_id {
>   PLANE_ID_PRIMARY,
>   PLANE_ID_SPRITE0,
>   PLANE_ID_SPRITE1,
>   PLANE_ID_CURSOR,
>   PLANE_ID_{MAX,NUM,TOTAL,SOMETHINGELSE},
> };

I did have _ID_ in there originally, but then decided it was just wasted
space. Weren't you complaining about me exceeding 80cols already too
much? ;)

I915_MAX_PLANES I wanted to leave be since it was already in use, and it
does match our weird naming convention for these things. So if we change
it we should change all other similar things.

> 
> Otherwise, the patch does what it says, so:
> Reviewed-by: Paulo Zanoni 
> 
> But please get Matt's ack before merging the series since he's been
> touching this area of the code for his work on changing how we treat
> the plane cursor.

Nod.

> 
> Also, please consider the renames :).

Which ones? The _ID_ thing, or just renaming the entire enum plane to
something else? For the latter my best idea was legacy_plane_id, but
not sure anyone else likes it. I guess we could also make it
primary_plane_id, but like I said that might complicate my long term
plan of restoring its use for cursor planes.

> 
> > +
> >  enum port {
> >     PORT_NONE = -1,
> >     PORT_A = 0,
> > diff --git a/drivers/gpu/drm/i915/intel_display.c
> > b/drivers/gpu/drm/i915/intel_display.c
> > index 10869360cfdc..b318119330e8 100644
> > --- a/drivers/gpu/drm/i915/intel_display.c
> > +++ b/drivers/gpu/drm/i915/intel_display.c
> > @@ -15008,6 +15008,7 @@ intel_primary_plane_create(struct
> > drm_i915_private *dev_priv, enum pipe pipe)
> >     primary->plane = (enum plane) !pipe;
> >     else
> >     primary->plane = 

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Find fallback link rate/lane count

[Manasi Navare]

On Thu, Nov 17, 2016 at 02:58:46PM +0200, Jani Nikula wrote:
> On Tue, 15 Nov 2016, Manasi Navare  wrote:
> > If link training fails, then we need to fallback to lower
> > link rate first and if link training fails at RBR, then
> > fallback to lower lane count.
> > This function finds the next lower link rate/lane count
> > value after link training failure.
> >
> > v2:
> > Squash the patch that returns the link rate index (Jani Nikula)
> >
> > Acked-by: Tony Cheng 
> > Acked-by: Harry Wentland 
> > Cc: Ville Syrjala 
> > Cc: Jani Nikula 
> > Cc: Daniel Vetter 
> > Signed-off-by: Manasi Navare 
> > ---
> >  drivers/gpu/drm/i915/intel_dp.c  | 42 
> > 
> >  drivers/gpu/drm/i915/intel_drv.h |  6 ++
> >  2 files changed, 48 insertions(+)
> >
> > diff --git a/drivers/gpu/drm/i915/intel_dp.c 
> > b/drivers/gpu/drm/i915/intel_dp.c
> > index a1b0181..e87b451 100644
> > --- a/drivers/gpu/drm/i915/intel_dp.c
> > +++ b/drivers/gpu/drm/i915/intel_dp.c
> > @@ -288,6 +288,48 @@ static int intel_dp_common_rates(struct intel_dp 
> > *intel_dp,
> >common_rates);
> >  }
> >  
> > +static int intel_dp_link_rate_index(struct intel_dp *intel_dp,
> > +   int *common_rates, int link_rate)
> > +{
> > +   int common_len;
> > +   int index;
> > +
> > +   common_len = intel_dp_common_rates(intel_dp, common_rates);
> > +   for (index = 0; index < common_len; index++) {
> > +   if (link_rate == common_rates[common_len - index - 1])
> > +   return common_len - index - 1;
> > +   }
> > +
> > +   return -1;
> > +}
> > +
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > +   int link_rate, uint8_t lane_count)
> > +{
> > +   int common_rates[DP_MAX_SUPPORTED_RATES] = {};
> > +   int common_len;
> > +   int link_rate_index = -1;
> > +
> > +   common_len = intel_dp_common_rates(intel_dp, common_rates);
> > +   link_rate_index = intel_dp_link_rate_index(intel_dp,
> > +  common_rates,
> > +  link_rate);
> > +   if (link_rate_index > 0) {
> > +   intel_dp->fallback_link_rate_index = link_rate_index - 1;
> > +   intel_dp->fallback_link_rate = 
> > common_rates[intel_dp->fallback_link_rate_index];
> 
> fallback_link_rate_index and fallback_link_rate are two ways to express
> the same thing, and you can derive one from the other. When you have
> two, you run the risk of having them out of sync. I thought I'd
> mentioned this in earlier review.
> 
> Please do not store fallback_link_rate_index in intel_dp. Only store
> fallback_link_rate. You can use your intel_dp_link_rate_index() function
> when you need to convert rate to index.
> 
> Moreover, resetting the state becomes more clear when all can be set to
> 0.
> 
> BR,
> Jani.
>

Thanks Jani.
From the previous feedback, I removed the redundant link_train_failed variable
stored in intel_dp, but retained the link_rate_index. I will look at this and 
see
if this can be optimized. 

Manasi

 
> > +   intel_dp->fallback_lane_count = 
> > intel_dp_max_lane_count(intel_dp);
> > +   } else if (lane_count > 1) {
> > +   intel_dp->fallback_link_rate_index = common_len - 1;
> > +   intel_dp->fallback_link_rate = 
> > common_rates[intel_dp->fallback_link_rate_index];
> > +   intel_dp->fallback_lane_count = lane_count >> 1;
> > +   } else {
> > +   DRM_ERROR("Link Training Unsuccessful\n");
> > +   return -1;
> > +   }
> > +
> > +   return 0;
> > +}
> > +
> >  static enum drm_mode_status
> >  intel_dp_mode_valid(struct drm_connector *connector,
> > struct drm_display_mode *mode)
> > diff --git a/drivers/gpu/drm/i915/intel_drv.h 
> > b/drivers/gpu/drm/i915/intel_drv.h
> > index 75252ec..55ceb44 100644
> > --- a/drivers/gpu/drm/i915/intel_drv.h
> > +++ b/drivers/gpu/drm/i915/intel_drv.h
> > @@ -887,6 +887,10 @@ struct intel_dp {
> > uint32_t DP;
> > int link_rate;
> > uint8_t lane_count;
> > +   int fallback_link_rate;
> > +   uint8_t fallback_lane_count;
> > +   int fallback_link_rate_index;
> > +   bool link_train_failed;
> > uint8_t sink_count;
> > bool link_mst;
> > bool has_audio;
> > @@ -1383,6 +1387,8 @@ bool intel_dp_init_connector(struct 
> > intel_digital_port *intel_dig_port,
> >  void intel_dp_set_link_params(struct intel_dp *intel_dp,
> >   int link_rate, uint8_t lane_count,
> >   bool link_mst);
> > +int intel_dp_get_link_train_fallback_values(struct intel_dp *intel_dp,
> > +   int link_rate, uint8_t lane_count);
> >  void intel_dp_start_link_train(struct 

[Intel-gfx] [PATCH 1/3] HAX drm/i915: Enable guc submission

[Chris Wilson]

---
 drivers/gpu/drm/i915/i915_params.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_params.c 
b/drivers/gpu/drm/i915/i915_params.c
index d46ffe7086bc..599b913d8906 100644
--- a/drivers/gpu/drm/i915/i915_params.c
+++ b/drivers/gpu/drm/i915/i915_params.c
@@ -56,8 +56,8 @@ struct i915_params i915 __read_mostly = {
.verbose_state_checks = 1,
.nuclear_pageflip = 0,
.edp_vswing = 0,
-   .enable_guc_loading = 0,
-   .enable_guc_submission = 0,
+   .enable_guc_loading = -1,
+   .enable_guc_submission = -1,
.guc_log_level = -1,
.enable_dp_mst = true,
.inject_load_failure = 0,
-- 
2.10.2

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

[Intel-gfx] [PATCH 3/3] drm/i915/guc: Split hw submission for replay after GPU reset

[Chris Wilson]

Something I missed before sending off the partial series was that the
non-scheduler guc reset path was broken (in the full series, this is
pushed to the execlists reset handler). The issue is that after a reset,
we have to refill the GuC workqueues, which we do by resubmitting the
requests. However, if we already have submitted them, the fences within
them have already been used and triggering them again is an error.
Instead, just repopulate the guc workqueue.

[  115.858560] [IGT] gem_busy: starting subtest hang-render
[  135.839867] [drm] GPU HANG: ecode 9:0:0xe757fefe, in gem_busy [1716], 
reason: Hang on render ring, action: reset
[  135.839902] drm/i915: Resetting chip after gpu hang
[  135.839957] [drm] RC6 on
[  135.858351] [ cut here ]
[  135.858357] WARNING: CPU: 2 PID: 45 at 
drivers/gpu/drm/i915/i915_sw_fence.c:108 i915_sw_fence_complete+0x25/0x30
[  135.858357] Modules linked in: rfcomm bnep binfmt_misc nls_iso8859_1 
input_leds snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic 
snd_hda_intel snd_hda_codec snd_hda_core btusb btrtl snd_hwdep snd_pcm 8250_dw 
snd_seq_midi hid_lenovo snd_seq_midi_event snd_rawmidi iwlwifi 
x86_pkg_temp_thermal coretemp snd_seq crct10dif_pclmul snd_seq_device hci_uart 
snd_timer crc32_pclmul ghash_clmulni_intel idma64 aesni_intel virt_dma btbcm 
snd btqca aes_x86_64 btintel lrw cfg80211 bluetooth gf128mul glue_helper 
ablk_helper cryptd soundcore intel_lpss_pci intel_pch_thermal intel_lpss_acpi 
intel_lpss acpi_als mfd_core kfifo_buf acpi_pad industrialio autofs4 
hid_plantronics usbhid dm_mirror dm_region_hash dm_log sdhci_pci ahci sdhci 
libahci i2c_hid hid
[  135.858389] CPU: 2 PID: 45 Comm: kworker/2:1 Tainted: GW   
4.9.0-rc4+ #238
[  135.858389] Hardware name:  /NUC6i3SYB, BIOS 
SYSKLi35.86A.0024.2015.1027.2142 10/27/2015
[  135.858392] Workqueue: events_long i915_hangcheck_elapsed
[  135.858394]  c91bf9b8 812bb238  

[  135.858396]  c91bf9f8 8104f621 006c 
8808296137f8
[  135.858398]  0a00 8808457a 880845764e60 
88084576
[  135.858399] Call Trace:
[  135.858403]  [] dump_stack+0x4d/0x65
[  135.858405]  [] __warn+0xc1/0xe0
[  135.858406]  [] warn_slowpath_null+0x18/0x20
[  135.858408]  [] i915_sw_fence_complete+0x25/0x30
[  135.858410]  [] i915_sw_fence_commit+0xd/0x30
[  135.858412]  [] __i915_gem_request_submit+0xe1/0xf0
[  135.858413]  [] i915_gem_request_submit+0x28/0x40
[  135.858415]  [] i915_guc_submit+0x47/0x210
[  135.858417]  [] i915_guc_submission_enable+0x468/0x540
[  135.858419]  [] intel_guc_setup+0x715/0x810
[  135.858421]  [] i915_gem_init_hw+0x114/0x2a0
[  135.858423]  [] i915_reset+0xe8/0x120
[  135.858424]  [] i915_reset_and_wakeup+0x157/0x180
[  135.858426]  [] i915_handle_error+0x1ab/0x230
[  135.858428]  [] ? scnprintf+0x4d/0x90
[  135.858430]  [] i915_hangcheck_elapsed+0x275/0x3d0
[  135.858432]  [] process_one_work+0x12f/0x410
[  135.858433]  [] worker_thread+0x43/0x4d0
[  135.858435]  [] ? process_one_work+0x410/0x410
[  135.858436]  [] ? process_one_work+0x410/0x410
[  135.858438]  [] kthread+0xd4/0xf0
[  135.858440]  [] ? kthread_park+0x60/0x60

v2: Only resubmit submitted requests
v3: Don't forget the pending requests have reserved space.

Fixes: d55ac5bf97c6 ("drm/i915: Defer transfer onto execution timeline to 
actual hw submission")
Signed-off-by: Chris Wilson 
Cc: Tvrtko Ursulin 
---
 drivers/gpu/drm/i915/i915_guc_submission.c | 37 --
 1 file changed, 20 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_guc_submission.c 
b/drivers/gpu/drm/i915/i915_guc_submission.c
index a42c27ec4bb1..032f1d6fb8bf 100644
--- a/drivers/gpu/drm/i915/i915_guc_submission.c
+++ b/drivers/gpu/drm/i915/i915_guc_submission.c
@@ -602,12 +602,9 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
 }
 
 /**
- * i915_guc_submit() - Submit commands through GuC
+ * __i915_guc_submit() - Submit commands through GuC
  * @rq:request associated with the commands
  *
- * Return: 0 on success, otherwise an errno.
- * (Note: nonzero really shouldn't happen!)
- *
  * The caller must have already called i915_guc_wq_reserve() above with
  * a result of 0 (success), guaranteeing that there is space in the work
  * queue for the new request, so enqueuing the item cannot fail.
@@ -619,7 +616,7 @@ static int guc_ring_doorbell(struct i915_guc_client *gc)
  * The only error here arises if the doorbell hardware isn't functioning
  * as expected, which really shouln't happen.
  */
-static void i915_guc_submit(struct drm_i915_gem_request *rq)
+static void __i915_guc_submit(struct drm_i915_gem_request *rq)
 {
struct drm_i915_private *dev_priv = rq->i915;
struct intel_engine_cs *engine = rq->engine;
@@ -628,17 +625,6 @@ static void 

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

[Chris Wilson]

On Thu, Nov 17, 2016 at 11:06:54AM -0800, Rodrigo Vivi wrote:
> On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote:
> > On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote:
> > > This commit adding all known marketing names for latest gen9 platforms.
> > > 
> > > Cc: Chris Wilson 
> > > Signed-off-by: Rodrigo Vivi 
> > > ---
> > >  README |  2 +-
> > >  man/intel.man  |  2 +-
> > >  src/intel_module.c | 29 -
> > >  3 files changed, 30 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/README b/README
> > > index cf4d88d..e58477d 100644
> > > --- a/README
> > > +++ b/README
> > > @@ -15,7 +15,7 @@ Intel graphics chipsets including:
> > >   G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
> > >   PineView-M (Atom N400 series)
> > >   PineView-D (Atom D400/D500 series)
> > > - Intel(R) HD Graphics: 2000-6000,
> > > + Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > >   Intel(R) Iris(TM) Graphics: 5100/6100, and
> > >   Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> > >  
> > > diff --git a/man/intel.man b/man/intel.man
> > > index 8da496e..16cc5d9 100644
> > > --- a/man/intel.man
> > > +++ b/man/intel.man
> > > @@ -27,7 +27,7 @@ supports the i810, i810-DC100, i810e, i815, i830M, 
> > > 845G, 852GM, 855GM,
> > >  865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME,
> > >  G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in
> > >  Atom N400 series, Pineview-D in Atom D400/D500 series,
> > > -Intel(R) HD Graphics: 2000-6000,
> > > +Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > >  Intel(R) Iris(TM) Graphics: 5100/6100, and
> > >  Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> > >  
> > > diff --git a/src/intel_module.c b/src/intel_module.c
> > > index e443c9e..86b4aae 100644
> > > --- a/src/intel_module.c
> > > +++ b/src/intel_module.c
> > > @@ -272,6 +272,33 @@ static const SymTabRec intel_chipsets[] = {
> > >   {0x22b2, "HD Graphics"},
> > >   {0x22b3, "HD Graphics"},
> > >  
> > > + /* Skylake */
> > > + {0x1902, "HD Graphics 510"},
> > > + {0x1906, "HD Graphics 510"},
> > > + {0x190B, "HD Graphics 510"},
> > > + {0x1912, "HD Graphics 530"},
> > > + {0x1916, "HD Graphics 520"},
> > > + {0x191B, "HD Graphics 530"},
> > > + {0x191D, "HD Graphics P530"},
> > > + {0x191E, "HD Graphics 515"},
> > > + {0x1921, "HD Graphics 520"},
> > > + {0x1926, "Iris Graphics 540"},
> > > + {0x1927, "Iris Graphics 550"},
> > > + {0x192B, "Iris Graphics 555"},
> > > + {0x192D, "Iris Graphics P555"},
> > > + {0x1932, "Iris Pro Graphics 580"},
> > > + {0x193A, "Iris Pro Graphics P580"},
> > > + {0x193B, "Iris Pro Graphics 580"},
> > > + {0x193D, "Iris Pro Graphics P580"},
> > > +
> > > + /* Broxton (Apollolake) */
> > > + {0x5A84, "HD Graphics 505"},
> > > + {0x5A85, "HD Graphics 500"},
> > > +
> > > + /* Kabylake */
> > > + {0x5916, "HD Graphics 620"},
> > > + {0x591E, "HD Graphics 615"},
> > > +
> > >   /* When adding new identifiers, also update:
> > >* 1. intel_identify()
> > >* 2. man/intel.man
> > > @@ -465,7 +492,7 @@ static void intel_identify(int flags)
> > >   if (unique != stack)
> > >   free(unique);
> > >  
> > > - xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > > 2000-6000\n");
> > > + xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > > 500-6000/P530/P555/P580\n");
> > >   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Graphics: 
> > > 5100, 6100\n");
> > >   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
> > > Graphics: 5200, 6200, P6300\n");
> > 
> > You missed the Iris & Iris Pro models.
> 
> Thanks
> 
> > 
> > Also, might it make sense to use 5xx, P5xx instead?
> 
> What about ont those generic lists we just kill all numbers and let just:
> "
>Intel(R) HD Graphics.
>Intel(R) Iris(TM) Graphics.
>Intel(R) Iris(TM) Pro Graphics.
> '
> ?
> 
> Chris?

Seems reasonable, and as demonstrated in the past simply listing
everything becomes unwieldy, if not unfathomable, quickly.

I honestly don't think the listing here is the primary source for
compatibility info (since to get here means that the driver recognised
the chipset anyway). For that we can throw into the catch all case in
intel_identify().
-Chris

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

Re: [Intel-gfx] [PATCH 5/9] drm/i915: Use enum plane_id in SKL plane code

[Paulo Zanoni]

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Replace the intel_plane->plane and hardcoded 0 usage in the SKL plane
> code with intel_plane->id.
> 
> This should make the SKL "primary" and "sprite" code virtually
> identical, so the next logical step would likely be dropping one
> of the copies.

Something something 80 columns something something. Also, this will
need a rebase, but the idea is sane, so with a bug-free rebase:

Reviewed-by: Paulo Zanoni .

> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_display.c | 34 
>  drivers/gpu/drm/i915/intel_sprite.c  | 50 ++--
> 
>  2 files changed, 43 insertions(+), 41 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index e3ed5d1fcf0d..95644c8cc568 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -3384,9 +3384,10 @@ static void
> skylake_update_primary_plane(struct drm_plane *plane,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc_state-
> >base.crtc);
>   struct drm_framebuffer *fb = plane_state->base.fb;
> + enum plane_id plane_id = to_intel_plane(plane)->id;
>   const struct skl_wm_values *wm = _priv->wm.skl_results;
>   const struct skl_plane_wm *p_wm =
> - _state->wm.skl.optimal.planes[0];
> + _state->wm.skl.optimal.planes[plane_id];
>   int pipe = intel_crtc->pipe;
>   u32 plane_ctl;
>   unsigned int rotation = plane_state->base.rotation;
> @@ -3423,32 +3424,32 @@ static void
> skylake_update_primary_plane(struct drm_plane *plane,
>   intel_crtc->adjusted_y = src_y;
>  
>   if (wm->dirty_pipes & drm_crtc_mask(_crtc->base))
> - skl_write_plane_wm(intel_crtc, p_wm, >ddb, 0);
> + skl_write_plane_wm(intel_crtc, p_wm, >ddb,
> plane_id);
>  
> - I915_WRITE(PLANE_CTL(pipe, 0), plane_ctl);
> - I915_WRITE(PLANE_OFFSET(pipe, 0), (src_y << 16) | src_x);
> - I915_WRITE(PLANE_STRIDE(pipe, 0), stride);
> - I915_WRITE(PLANE_SIZE(pipe, 0), (src_h << 16) | src_w);
> + I915_WRITE(PLANE_CTL(pipe, plane_id), plane_ctl);
> + I915_WRITE(PLANE_OFFSET(pipe, plane_id), (src_y << 16) |
> src_x);
> + I915_WRITE(PLANE_STRIDE(pipe, plane_id), stride);
> + I915_WRITE(PLANE_SIZE(pipe, plane_id), (src_h << 16) |
> src_w);
>  
>   if (scaler_id >= 0) {
>   uint32_t ps_ctrl = 0;
>  
>   WARN_ON(!dst_w || !dst_h);
> - ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(0) |
> + ps_ctrl = PS_SCALER_EN | PS_PLANE_SEL(plane_id) |
>   crtc_state-
> >scaler_state.scalers[scaler_id].mode;
>   I915_WRITE(SKL_PS_CTRL(pipe, scaler_id), ps_ctrl);
>   I915_WRITE(SKL_PS_PWR_GATE(pipe, scaler_id), 0);
>   I915_WRITE(SKL_PS_WIN_POS(pipe, scaler_id), (dst_x
> << 16) | dst_y);
>   I915_WRITE(SKL_PS_WIN_SZ(pipe, scaler_id), (dst_w <<
> 16) | dst_h);
> - I915_WRITE(PLANE_POS(pipe, 0), 0);
> + I915_WRITE(PLANE_POS(pipe, plane_id), 0);
>   } else {
> - I915_WRITE(PLANE_POS(pipe, 0), (dst_y << 16) |
> dst_x);
> + I915_WRITE(PLANE_POS(pipe, plane_id), (dst_y << 16)
> | dst_x);
>   }
>  
> - I915_WRITE(PLANE_SURF(pipe, 0),
> + I915_WRITE(PLANE_SURF(pipe, plane_id),
>      intel_fb_gtt_offset(fb, rotation) + surf_addr);
>  
> - POSTING_READ(PLANE_SURF(pipe, 0));
> + POSTING_READ(PLANE_SURF(pipe, plane_id));
>  }
>  
>  static void skylake_disable_primary_plane(struct drm_plane *primary,
> @@ -3458,7 +3459,8 @@ static void
> skylake_disable_primary_plane(struct drm_plane *primary,
>   struct drm_i915_private *dev_priv = to_i915(dev);
>   struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
>   struct intel_crtc_state *cstate = to_intel_crtc_state(crtc-
> >state);
> - const struct skl_plane_wm *p_wm = 
> >wm.skl.optimal.planes[0];
> + enum plane_id plane_id = to_intel_plane(primary)->id;
> + const struct skl_plane_wm *p_wm = 
> >wm.skl.optimal.planes[plane_id];
>   int pipe = intel_crtc->pipe;
>  
>   /*
> @@ -3467,11 +3469,11 @@ static void
> skylake_disable_primary_plane(struct drm_plane *primary,
>    */
>   if (!crtc->primary->state->visible)
>   skl_write_plane_wm(intel_crtc, p_wm,
> -    _priv->wm.skl_results.ddb,
> 0);
> +    _priv->wm.skl_results.ddb,
> plane_id);
>  
> - I915_WRITE(PLANE_CTL(pipe, 0), 0);
> - I915_WRITE(PLANE_SURF(pipe, 0), 0);
> - POSTING_READ(PLANE_SURF(pipe, 0));
> + I915_WRITE(PLANE_CTL(pipe, plane_id), 0);
> + I915_WRITE(PLANE_SURF(pipe, plane_id), 0);
> + 

Re: [Intel-gfx] [PATCH 3/9] drm/i915: Add crtc->plane_ids_mask

[Paulo Zanoni]

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Add a mask of which planes are available for each pipe. This doesn't
> quite work for old platforms with dynamic plane<->pipe assignment,
> but
> as we don't support that sort of stuff (yet) we can get away with it.
> 
> The main use I have for this is the for_each_plane_id_on_crtc() macro
> for iterating over all possible planes on the crtc. I suppose we
> could
> not add the mask, and instead iterate by comparing intel_plane->pipe
> but then we'd need a local intel_plane variable which is just
> unnecessary clutter in some cases. But I'm not hung up on this, so if
> people prefer the other option I could be convinced to use it.
> 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 4 
>  drivers/gpu/drm/i915/intel_display.c | 3 +++
>  drivers/gpu/drm/i915/intel_drv.h | 3 ++-
>  3 files changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 2451b88b1e82..2325efacbd5c 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -201,6 +201,10 @@ enum plane_id {
>   I915_MAX_PLANES,
>  };
>  
> +#define for_each_plane_id_on_crtc(__crtc, __p) \
> + for ((__p) = PLANE_PRIMARY; (__p) < I915_MAX_PLANES;
> (__p)++) \
> + for_each_if ((__crtc)->plane_ids_mask & (1 <<
> (__p)))
> +

Let's be consistent: either use BIT() everywhere or use (1 << bit)
everywhere :).

Reviewed-by: Paulo Zanoni .


>  enum port {
>   PORT_NONE = -1,
>   PORT_A = 0,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index b318119330e8..e3ed5d1fcf0d 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15293,6 +15293,7 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
>   ret = PTR_ERR(primary);
>   goto fail;
>   }
> + intel_crtc->plane_ids_mask |= BIT(primary->id);
>  
>   for_each_sprite(dev_priv, pipe, sprite) {
>   struct intel_plane *plane;
> @@ -15302,6 +15303,7 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
>   ret = PTR_ERR(plane);
>   goto fail;
>   }
> + intel_crtc->plane_ids_mask |= BIT(plane->id);
>   }
>  
>   cursor = intel_cursor_plane_create(dev_priv, pipe);
> @@ -15309,6 +15311,7 @@ static int intel_crtc_init(struct
> drm_i915_private *dev_priv, enum pipe pipe)
>   ret = PTR_ERR(cursor);
>   goto fail;
>   }
> + intel_crtc->plane_ids_mask |= BIT(cursor->id);
>  
>   ret = drm_crtc_init_with_planes(_priv->drm, _crtc-
> >base,
>   >base, 
> >base,
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 58fc8e1d2aa8..a3c696d8bf93 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -689,8 +689,9 @@ struct intel_crtc {
>    * some outputs connected to this crtc.
>    */
>   bool active;
> - unsigned long enabled_power_domains;
>   bool lowfreq_avail;
> + u8 plane_ids_mask;
> + unsigned long enabled_power_domains;
>   struct intel_overlay *overlay;
>   struct intel_flip_work *flip_work;
>  
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

[Rodrigo Vivi]

According to Bspec we need to
"Poll for PORT_REF_DW3_A grc_done == 1b"
only on ports B and C initialization sequence when
copying rcomp from port A.

So let's follow the spec and only poll for that case
and not on every port A initialization.

v2: Also remove the grc_done check from bxt_ddi_phy_is_enabled()
otherwise it might believe it is disabled and force it to re program.

Cc: Imre Deak 
Cc: Ander Conselvan de Oliveira 
Signed-off-by: Rodrigo Vivi 
---
 drivers/gpu/drm/i915/intel_dpio_phy.c | 15 +++
 1 file changed, 3 insertions(+), 12 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c 
b/drivers/gpu/drm/i915/intel_dpio_phy.c
index 7a8e82d..321a2ee 100644
--- a/drivers/gpu/drm/i915/intel_dpio_phy.c
+++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
@@ -255,14 +255,6 @@ bool bxt_ddi_phy_is_enabled(struct drm_i915_private 
*dev_priv,
return false;
}
 
-   if (phy_info->rcomp_phy == -1 &&
-   !(I915_READ(BXT_PORT_REF_DW3(phy)) & GRC_DONE)) {
-   DRM_DEBUG_DRIVER("DDI PHY %d powered, but GRC isn't done\n",
-phy);
-
-   return false;
-   }
-
if (!(I915_READ(BXT_PHY_CTL_FAMILY(phy)) & COMMON_RESET_DIS)) {
DRM_DEBUG_DRIVER("DDI PHY %d powered, but still in reset\n",
 phy);
@@ -367,6 +359,9 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
 
if (phy_info->rcomp_phy != -1) {
uint32_t grc_code;
+
+   bxt_phy_wait_grc_done(dev_priv, phy_info->rcomp_phy);
+
/*
 * PHY0 isn't connected to an RCOMP resistor so copy over
 * the corresponding calibrated value from PHY1, and disable
@@ -387,10 +382,6 @@ static void _bxt_ddi_phy_init(struct drm_i915_private 
*dev_priv,
val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
val |= COMMON_RESET_DIS;
I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
-
-   if (phy_info->rcomp_phy == -1)
-   bxt_phy_wait_grc_done(dev_priv, phy);
-
 }
 
 void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum dpio_phy phy)
-- 
1.9.1

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

[Intel-gfx] [drm-intel:drm-intel-next-queued 2/2] drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: error: unused variable 'ggtt'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   95a2e2be952c3c3a643b8e0504f2ceef15294d4d
commit: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d [2/2] drm/i915: Remove stolen 
object spam
config: x86_64-randconfig-in0-11180217 (attached as .config)
compiler: gcc-4.6 (Debian 4.6.4-7) 4.6.4
reproduce:
git checkout 95a2e2be952c3c3a643b8e0504f2ceef15294d4d
# save the attached .config to linux build tree
make ARCH=x86_64 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_stolen.c: In function 
'i915_pages_create_for_stolen':
>> drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: error: unused variable 'ggtt' 
>> [-Werror=unused-variable]
   cc1: all warnings being treated as errors

vim +/ggtt +516 drivers/gpu/drm/i915/i915_gem_stolen.c

0104fdbb8 Chris Wilson2012-11-15  510  
0104fdbb8 Chris Wilson2012-11-15  511  static struct sg_table *
0104fdbb8 Chris Wilson2012-11-15  512  i915_pages_create_for_stolen(struct 
drm_device *dev,
0104fdbb8 Chris Wilson2012-11-15  513u32 
offset, u32 size)
0104fdbb8 Chris Wilson2012-11-15  514  {
72e96d645 Joonas Lahtinen 2016-03-30  515   struct drm_i915_private 
*dev_priv = to_i915(dev);
72e96d645 Joonas Lahtinen 2016-03-30 @516   struct i915_ggtt *ggtt = 
_priv->ggtt;
0104fdbb8 Chris Wilson2012-11-15  517   struct sg_table *st;
0104fdbb8 Chris Wilson2012-11-15  518   struct scatterlist *sg;
0104fdbb8 Chris Wilson2012-11-15  519  

:: The code at line 516 was first introduced by commit
:: 72e96d6450c067f58b65224bb5e73914e2cc43ab drm/i915: Refer to GGTT {,VM} 
consistently

:: TO: Joonas Lahtinen 
:: CC: Joonas Lahtinen 

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


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

Re: [Intel-gfx] [PATCH 2/9] drm/i915: Add per-pipe plane identifier

[Paulo Zanoni]

Em Ter, 2016-11-08 às 16:47 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> As I told people in [1] we really should not be confusing enum plane
> as a per-pipe plane identifier. Looks like that happened nonetheless,
> so
> let's fix it up by splitting the two into two enums.
> 
> We'll also want something we just directly pass to various register
> offset macros and whatnot on SKL+. So let's make this new thing work
> for that.
> Currently we pass intel_plane->plane for the "sprites" and just a
> hardcoded zero for the "primary" planes. We want to get rid of that
> hardocoding so that we can share the same code for all planes (apart
> from the legacy cursor of course).
> 
> [1] https://lists.freedesktop.org/archives/intel-gfx/2015-September/0
> 76082.html
> 
> Cc: Matt Roper 
> Cc: Daniel Vetter 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  | 28 +-
> --
>  drivers/gpu/drm/i915/intel_display.c |  2 ++
>  drivers/gpu/drm/i915/intel_drv.h |  3 ++-
>  drivers/gpu/drm/i915/intel_sprite.c  |  1 +
>  4 files changed, 26 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h
> b/drivers/gpu/drm/i915/i915_drv.h
> index 30777dee3f9c..2451b88b1e82 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -171,22 +171,36 @@ static inline bool transcoder_is_dsi(enum
> transcoder transcoder)
>  }
>  
>  /*
> - * I915_MAX_PLANES in the enum below is the maximum (across all
> platforms)
> - * number of planes per CRTC.  Not all platforms really have this
> many planes,
> - * which means some arrays of size I915_MAX_PLANES may have unused
> entries
> - * between the topmost sprite plane and the cursor plane.
> + * Global legacy plane identifier. Valid only for primary/sprite
> + * planes on pre-g4x, and only for primary planes on g4x+.
>   */
>  enum plane {
> - PLANE_A = 0,
> + PLANE_A,
>   PLANE_B,
>   PLANE_C,
> - PLANE_CURSOR,
> - I915_MAX_PLANES,
>  };
>  #define plane_name(p) ((p) + 'A')
>  
>  #define sprite_name(p, s) ((p) * INTEL_INFO(dev_priv)-
> >num_sprites[(p)] + (s) + 'A')
>  
> +/*
> + * Per-pipe plane identifier.
> + * I915_MAX_PLANES in the enum below is the maximum (across all
> platforms)
> + * number of planes per CRTC.  Not all platforms really have this
> many planes,
> + * which means some arrays of size I915_MAX_PLANES may have unused
> entries
> + * between the topmost sprite plane and the cursor plane.
> + *
> + * This is expected to be passed to various register macros
> + * (eg. PLANE_CTL(), PS_PLANE_SEL(), etc.) so adjust with care.
> + */
> +enum plane_id {
> + PLANE_PRIMARY,
> + PLANE_SPRITE0,
> + PLANE_SPRITE1,
> + PLANE_CURSOR,
> + I915_MAX_PLANES,
> +};

We now have two different enums defining PLANE_SOMETHING, and we even
moved some stuff from one to the other. I think this adds more
confusion to the code, so we would probably be saner with:

enum plane_id {
PLANE_ID_PRIMARY,
PLANE_ID_SPRITE0,
PLANE_ID_SPRITE1,
PLANE_ID_CURSOR,
PLANE_ID_{MAX,NUM,TOTAL,SOMETHINGELSE},
};

Otherwise, the patch does what it says, so:
Reviewed-by: Paulo Zanoni 

But please get Matt's ack before merging the series since he's been
touching this area of the code for his work on changing how we treat
the plane cursor.

Also, please consider the renames :).

> +
>  enum port {
>   PORT_NONE = -1,
>   PORT_A = 0,
> diff --git a/drivers/gpu/drm/i915/intel_display.c
> b/drivers/gpu/drm/i915/intel_display.c
> index 10869360cfdc..b318119330e8 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -15008,6 +15008,7 @@ intel_primary_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
>   primary->plane = (enum plane) !pipe;
>   else
>   primary->plane = (enum plane) pipe;
> + primary->id = PLANE_PRIMARY;
>   primary->frontbuffer_bit = INTEL_FRONTBUFFER_PRIMARY(pipe);
>   primary->check_plane = intel_check_primary_plane;
>  
> @@ -15203,6 +15204,7 @@ intel_cursor_plane_create(struct
> drm_i915_private *dev_priv, enum pipe pipe)
>   cursor->max_downscale = 1;
>   cursor->pipe = pipe;
>   cursor->plane = pipe;
> + cursor->id = PLANE_CURSOR;
>   cursor->frontbuffer_bit = INTEL_FRONTBUFFER_CURSOR(pipe);
>   cursor->check_plane = intel_check_cursor_plane;
>   cursor->update_plane = intel_update_cursor_plane;
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index 398195bf6dd1..58fc8e1d2aa8 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -767,7 +767,8 @@ struct intel_plane_wm_parameters {
>  
>  struct intel_plane {
>   struct drm_plane base;
> - 

Re: [Intel-gfx] [PATCH v3 4/9] drm/i915: Use enum plane_id in SKL wm code

[Paulo Zanoni]

Em Qua, 2016-11-09 às 17:03 +0200, ville.syrj...@linux.intel.com
escreveu:
> From: Ville Syrjälä 
> 
> Nuke skl_wm_plane_id() and just use the new intel_plane->id.
> 
> v2: Convert skl_write_plane_wm() as well
> v3: Convert skl_pipe_wm_get_hw_state() correctly

In general, I really like the fact that we unified plane/id/i into just
plane_id.

In general, I dislike the fact that many new lines go past 80 columns
now :).

A few comments follow:

> 
> Cc: Matt Roper 
> Cc: Paulo Zanoni 
> Cc: Maarten Lankhorst 
> Cc: Lyude 
> Signed-off-by: Ville Syrjälä 
> ---
>  drivers/gpu/drm/i915/intel_drv.h |   2 +-
>  drivers/gpu/drm/i915/intel_pm.c  | 180 -
> --
>  2 files changed, 76 insertions(+), 106 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/intel_drv.h
> b/drivers/gpu/drm/i915/intel_drv.h
> index a3c696d8bf93..6a4cd6edafa5 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1751,7 +1751,7 @@ void skl_write_cursor_wm(struct intel_crtc
> *intel_crtc,
>  void skl_write_plane_wm(struct intel_crtc *intel_crtc,
>   const struct skl_plane_wm *wm,
>   const struct skl_ddb_allocation *ddb,
> - int plane);
> + enum plane_id plane_id);
>  uint32_t ilk_pipe_pixel_rate(const struct intel_crtc_state
> *pipe_config);
>  bool ilk_disable_lp_wm(struct drm_device *dev);
>  int sanitize_rc6_option(struct drm_i915_private *dev_priv, int
> enable_rc6);
> diff --git a/drivers/gpu/drm/i915/intel_pm.c
> b/drivers/gpu/drm/i915/intel_pm.c
> index 88e28c989b9c..bae7eea6de16 100644
> --- a/drivers/gpu/drm/i915/intel_pm.c
> +++ b/drivers/gpu/drm/i915/intel_pm.c
> @@ -2863,28 +2863,6 @@ bool ilk_disable_lp_wm(struct drm_device *dev)
>  #define SKL_SAGV_BLOCK_TIME  30 /* µs */
>  
>  /*
> - * Return the index of a plane in the SKL DDB and wm result
> arrays.  Primary
> - * plane is always in slot 0, cursor is always in slot
> I915_MAX_PLANES-1, and
> - * other universal planes are in indices 1..n.  Note that this may
> leave unused
> - * indices between the top "sprite" plane and the cursor.
> - */
> -static int
> -skl_wm_plane_id(const struct intel_plane *plane)
> -{
> - switch (plane->base.type) {
> - case DRM_PLANE_TYPE_PRIMARY:
> - return 0;
> - case DRM_PLANE_TYPE_CURSOR:
> - return PLANE_CURSOR;
> - case DRM_PLANE_TYPE_OVERLAY:
> - return plane->plane + 1;
> - default:
> - MISSING_CASE(plane->base.type);
> - return plane->plane;
> - }
> -}
> -
> -/*
>   * FIXME: We still don't have the proper code detect if we need to
> apply the WA,
>   * so assume we'll always need it in order to avoid underruns.
>   */
> @@ -3022,7 +3000,6 @@ bool intel_can_enable_sagv(struct
> drm_atomic_state *state)
>   struct intel_crtc *crtc;
>   struct intel_plane *plane;
>   struct intel_crtc_state *cstate;
> - struct skl_plane_wm *wm;
>   enum pipe pipe;
>   int level, latency;
>  
> @@ -3049,7 +3026,8 @@ bool intel_can_enable_sagv(struct
> drm_atomic_state *state)
>   return false;
>  
>   for_each_intel_plane_on_crtc(dev, crtc, plane) {
> - wm = 
> >wm.skl.optimal.planes[skl_wm_plane_id(plane)];
> + struct skl_plane_wm *wm =
> + >wm.skl.optimal.planes[plane->id];
>  
>   /* Skip this plane if it's not enabled */
>   if (!wm->wm[0].plane_en)
> @@ -3148,28 +3126,28 @@ static void skl_ddb_entry_init_from_hw(struct
> skl_ddb_entry *entry, u32 reg)
>  void skl_ddb_get_hw_state(struct drm_i915_private *dev_priv,
>     struct skl_ddb_allocation *ddb /* out */)
>  {
> - enum pipe pipe;
> - int plane;
> + struct intel_crtc *crtc;
>   u32 val;
>  
>   memset(ddb, 0, sizeof(*ddb));
>  
> - for_each_pipe(dev_priv, pipe) {
> + for_each_intel_crtc(_priv->drm, crtc) {
>   enum intel_display_power_domain power_domain;
> + enum plane_id plane_id;
> + enum pipe pipe = crtc->pipe;
>  
>   power_domain = POWER_DOMAIN_PIPE(pipe);
>   if (!intel_display_power_get_if_enabled(dev_priv,
> power_domain))
>   continue;
>  
> - for_each_universal_plane(dev_priv, pipe, plane) {
> - val = I915_READ(PLANE_BUF_CFG(pipe, plane));
> - skl_ddb_entry_init_from_hw(
> >plane[pipe][plane],
> -    val);
> - }
> + for_each_plane_id_on_crtc(crtc, plane_id) {
> + if (plane_id != PLANE_CURSOR)
> + val = I915_READ(PLANE_BUF_CFG(pipe,
> plane_id));
> + else
> +   

Re: [Intel-gfx] [[PATCH ddx]] intel: Adding Marketing names for Skylake, Kabylake and Apollolake/Broxton.

[Rodrigo Vivi]

On Thu, Nov 17, 2016 at 10:53:04AM +0200, David Weinehall wrote:
> On Tue, Nov 15, 2016 at 02:21:01PM -0800, Rodrigo Vivi wrote:
> > This commit adding all known marketing names for latest gen9 platforms.
> > 
> > Cc: Chris Wilson 
> > Signed-off-by: Rodrigo Vivi 
> > ---
> >  README |  2 +-
> >  man/intel.man  |  2 +-
> >  src/intel_module.c | 29 -
> >  3 files changed, 30 insertions(+), 3 deletions(-)
> > 
> > diff --git a/README b/README
> > index cf4d88d..e58477d 100644
> > --- a/README
> > +++ b/README
> > @@ -15,7 +15,7 @@ Intel graphics chipsets including:
> > G/Q33,G/Q35,G41,G/Q43,G/GM/Q45
> > PineView-M (Atom N400 series)
> > PineView-D (Atom D400/D500 series)
> > -   Intel(R) HD Graphics: 2000-6000,
> > +   Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> > Intel(R) Iris(TM) Graphics: 5100/6100, and
> > Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> >  
> > diff --git a/man/intel.man b/man/intel.man
> > index 8da496e..16cc5d9 100644
> > --- a/man/intel.man
> > +++ b/man/intel.man
> > @@ -27,7 +27,7 @@ supports the i810, i810-DC100, i810e, i815, i830M, 845G, 
> > 852GM, 855GM,
> >  865G, 915G, 915GM, 945G, 945GM, 965G, 965Q, 946GZ, 965GM, 945GME,
> >  G33, Q33, Q35, G35, GM45, G45, Q45, G43, G41 chipsets, Pineview-M in
> >  Atom N400 series, Pineview-D in Atom D400/D500 series,
> > -Intel(R) HD Graphics: 2000-6000,
> > +Intel(R) HD Graphics: 500-6000/P530/P555/P580,
> >  Intel(R) Iris(TM) Graphics: 5100/6100, and
> >  Intel(R) Iris(TM) Pro Graphics: 5200/6200/P6300.
> >  
> > diff --git a/src/intel_module.c b/src/intel_module.c
> > index e443c9e..86b4aae 100644
> > --- a/src/intel_module.c
> > +++ b/src/intel_module.c
> > @@ -272,6 +272,33 @@ static const SymTabRec intel_chipsets[] = {
> > {0x22b2, "HD Graphics"},
> > {0x22b3, "HD Graphics"},
> >  
> > +   /* Skylake */
> > +   {0x1902, "HD Graphics 510"},
> > +   {0x1906, "HD Graphics 510"},
> > +   {0x190B, "HD Graphics 510"},
> > +   {0x1912, "HD Graphics 530"},
> > +   {0x1916, "HD Graphics 520"},
> > +   {0x191B, "HD Graphics 530"},
> > +   {0x191D, "HD Graphics P530"},
> > +   {0x191E, "HD Graphics 515"},
> > +   {0x1921, "HD Graphics 520"},
> > +   {0x1926, "Iris Graphics 540"},
> > +   {0x1927, "Iris Graphics 550"},
> > +   {0x192B, "Iris Graphics 555"},
> > +   {0x192D, "Iris Graphics P555"},
> > +   {0x1932, "Iris Pro Graphics 580"},
> > +   {0x193A, "Iris Pro Graphics P580"},
> > +   {0x193B, "Iris Pro Graphics 580"},
> > +   {0x193D, "Iris Pro Graphics P580"},
> > +
> > +   /* Broxton (Apollolake) */
> > +   {0x5A84, "HD Graphics 505"},
> > +   {0x5A85, "HD Graphics 500"},
> > +
> > +   /* Kabylake */
> > +   {0x5916, "HD Graphics 620"},
> > +   {0x591E, "HD Graphics 615"},
> > +
> > /* When adding new identifiers, also update:
> >  * 1. intel_identify()
> >  * 2. man/intel.man
> > @@ -465,7 +492,7 @@ static void intel_identify(int flags)
> > if (unique != stack)
> > free(unique);
> >  
> > -   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > 2000-6000\n");
> > +   xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) HD Graphics: 
> > 500-6000/P530/P555/P580\n");
> > xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Graphics: 
> > 5100, 6100\n");
> > xf86Msg(X_INFO, INTEL_NAME ": Driver for Intel(R) Iris(TM) Pro 
> > Graphics: 5200, 6200, P6300\n");
> 
> You missed the Iris & Iris Pro models.

Thanks

> 
> Also, might it make sense to use 5xx, P5xx instead?

What about ont those generic lists we just kill all numbers and let just:
"
   Intel(R) HD Graphics.
   Intel(R) Iris(TM) Graphics.
   Intel(R) Iris(TM) Pro Graphics.
'
?

Chris?

> 
> 
> Kind regards, David
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 0/3] drm/i915/opregion: proper handling of DIDL, and some hacks on CADL

[Paolo Stivanin]

Hello,
I can confirm that patch 3 is not needed.
I applied only patch 1 and 2 and everything works super fine!

Thanks again!

BR

Paolo

-- 
  Paolo Stivanin
  paolostiva...@fastmail.fm
  Public Key ID: E71B7545

On Thu, Nov 17, 2016, at 12:01 PM, Jani Nikula wrote:
> On Thu, 17 Nov 2016, Rainer Koenig  wrote:
> > Hi Jani,
> >
> > applied those patches to the 4.9.0-rc4 from
> > http://anongit.freedesktop.org/git/drm-intel.git
> > and tested it on the Fujitsu LIFEBOOK E736.
> >
> > Works perfectly, even after suspend and resume.
> >
> > Adding my hopes that this will be merged into the mainline soon.
> 
> Pushed patches 1-2 to drm-intel-next-queued, with Daniel's review on
> patch 2. He observed that patch 3 should not be needed, as we already
> sort the connector list to have internal panels in front.
> 
> I presume this will make it to v4.10-rc1. I'm thinking we could do a
> stable backport request once this has had more exposure.
> 
> Thanks for the review and testing. And patience!
> 
> BR,
> Jani.
> 
> 
> 
> -- 
> Jani Nikula, Intel Open Source Technology Center
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH] drm/i915: Add a few more sanity checks for stolen handling

[Matthew Auld]

On 17 November 2016 at 15:58, Chris Wilson  wrote:
> We should never be called via obj->ops->release() on anything other than
> a fully formed stolen object, so raise that to an assert. In the process
> tidy up a comment and variable no longer used outside of a conditional
> BUG.
>
> Signed-off-by: Chris Wilson 
Reviewed-by: Matthew Auld 
___
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: Add a few more sanity checks for stolen handling

[Patchwork]

== Series Details ==

Series: drm/i915: Add a few more sanity checks for stolen handling
URL   : https://patchwork.freedesktop.org/series/15507/
State : success

== Summary ==

Series 15507v1 drm/i915: Add a few more sanity checks for stolen handling
https://patchwork.freedesktop.org/api/1.0/series/15507/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
18c4faf drm/i915: Add a few more sanity checks for stolen handling

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3040/
___
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: Only dump dp_m2_n2 configuration when drrs is used

[Patchwork]

== Series Details ==

Series: drm/i915: Only dump dp_m2_n2 configuration when drrs is used
URL   : https://patchwork.freedesktop.org/series/15505/
State : success

== Summary ==

Series 15505v1 drm/i915: Only dump dp_m2_n2 configuration when drrs is used
https://patchwork.freedesktop.org/api/1.0/series/15505/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
3186dfe drm/i915: Only dump dp_m2_n2 configuration when drrs is used

== Logs ==

For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_3039/
___
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: Remove misinformation about mark_busy/mark_idle

[Patchwork]

== Series Details ==

Series: drm/i915: Remove misinformation about mark_busy/mark_idle
URL   : https://patchwork.freedesktop.org/series/15504/
State : success

== Summary ==

Series 15504v1 drm/i915: Remove misinformation about mark_busy/mark_idle
https://patchwork.freedesktop.org/api/1.0/series/15504/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
aa23781 drm/i915: Remove misinformation about mark_busy/mark_idle

== Logs ==

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

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with drm: Define drm_mm_for_each_node_in_range() (rev2)

[Patchwork]

== Series Details ==

Series: series starting with drm: Define drm_mm_for_each_node_in_range() (rev2)
URL   : https://patchwork.freedesktop.org/series/15489/
State : failure

== Summary ==

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

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_flip:
Subgroup basic-flip-vs-modeset:
pass   -> DMESG-WARN (fi-skl-6770hq)
Test kms_pipe_crc_basic:
Subgroup suspend-read-crc-pipe-a:
pass   -> INCOMPLETE (fi-skl-6260u)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:206  pass:193  dwarn:0   dfail:0   fail:0   skip:12 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:229  dwarn:1   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

4f5493e90cc50f1c6391c4f389f7a79c8fe52355 drm-intel-nightly: 
2016y-11m-17d-15h-37m-59s UTC integration manifest
371dcd0 drm/i915: Fix i915_gem_evict_for_vma (soft-pinning)
94abd0b drm/i915: Mark all non-vma being inserted into the address spaces
d8da7bf drm: Check against color expansion in drm_mm_reserve_node()
92a81c3 drm: Define drm_mm_for_each_node_in_range()

== Logs ==

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

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Pipe config debug dump diet

[Ville Syrjälä]

On Thu, Nov 17, 2016 at 03:13:55PM +, Tvrtko Ursulin wrote:
> 
> On 17/11/2016 13:16, Patchwork wrote:
> > == Series Details ==
> >
> > Series: Pipe config debug dump diet
> > URL   : https://patchwork.freedesktop.org/series/15493/
> > State : success
> >
> > == Summary ==
> >
> > Series 15493v1 Pipe config debug dump diet
> > https://patchwork.freedesktop.org/api/1.0/series/15493/revisions/1/mbox/
> >
> >
> > fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15
> > fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40
> > fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28
> > fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28
> > fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32
> > fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20
> > fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20
> > fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53
> > fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
> > fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
> > fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
> > fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14
> > fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21
> > fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21
> > fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14
> > fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32
> > fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33
> >
> > ccd01198820ab7286f0b98f7b28dbf6ad29fa861 drm-intel-nightly: 
> > 2016y-11m-17d-10h-54m-57s UTC integration manifest
> > a9bf7b7 drm/i915: Introduce enableddisabled helper
> > 1cd61af drm/i915: Only dump possible panel fitter config for the platform
> > e5069f1 drm/i915: Only dump scaler config where supported
> > 5d6948f drm/i915: Compact a few pipe config debug lines
> > 63a49f1 drm/i915: Don't log pipe config kernel pointer and duplicated pipe 
> > name
> > f711717 drm/i915: Dump FDI config only where applicable
> > 2a89809 drm/i915: Extract intel_link_m_n config printing into a helper
> 
> Merged to dinq and thanks Maarten for the review. Unfortunately I forgot 
> to apply his r-b's manually before pushing. :(

I'm not a big fan of this series. It merged some totally unrelated stuff
to the same line, and I don't really like making the dump look different
depending on the output_types either. Just makes life more confusing to
look at the thing, and potentually we might fail to notice some
discrepancies.

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

[Intel-gfx] [PATCH 29/32] drm/i915: Use drm_framebuffer_plane_{width, height}() where possible

[ville . syrjala]

From: Ville Syrjälä 

Replace drm_format_plane_{width,height}() usage with
drm_framebuffer_plane_{width,height}() to avoid the lookup of the format
info.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 8f63fd38deee..5d8db436c557 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2496,7 +2496,6 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
struct intel_rotation_info *rot_info = _fb->rot_info;
u32 gtt_offset_rotated = 0;
unsigned int max_size = 0;
-   uint32_t format = fb->pixel_format;
int i, num_planes = fb->format->num_planes;
unsigned int tile_size = intel_tile_size(dev_priv);
 
@@ -2507,8 +2506,8 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
int x, y;
 
cpp = fb->format->cpp[i];
-   width = drm_format_plane_width(fb->width, format, i);
-   height = drm_format_plane_height(fb->height, format, i);
+   width = drm_framebuffer_plane_width(fb->width, fb, i);
+   height = drm_framebuffer_plane_height(fb->height, fb, i);
 
intel_fb_offset_to_xy(, , fb, i);
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 27/32] drm/i915: Replace drm_format_num_planes() with fb->format->num_planes

[ville . syrjala]

From: Ville Syrjälä 

No need to look up the format info to get the number of planes, just
use fb->format->num_planes directly.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 6565e5cd0ada..8f63fd38deee 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -2497,7 +2497,7 @@ intel_fill_fb_info(struct drm_i915_private *dev_priv,
u32 gtt_offset_rotated = 0;
unsigned int max_size = 0;
uint32_t format = fb->pixel_format;
-   int i, num_planes = drm_format_num_planes(format);
+   int i, num_planes = fb->format->num_planes;
unsigned int tile_size = intel_tile_size(dev_priv);
 
for (i = 0; i < num_planes; i++) {
-- 
2.7.4

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

[Intel-gfx] [PATCH 25/32] drm/i915: Store a pointer to the pixel format info for fbc

[ville . syrjala]

From: Ville Syrjälä 

Rather than store the pixel format and look up the format info as
needed,  let's just store a pointer to the format info directly
and speed up our lookups.

Cc: Paulo Zanoni 
Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/i915_drv.h  |  4 ++--
 drivers/gpu/drm/i915/intel_fbc.c | 14 +++---
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index be67aeece749..692b79e056be 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1026,7 +1026,7 @@ struct intel_fbc {
 
struct {
u64 ilk_ggtt_offset;
-   uint32_t pixel_format;
+   const struct drm_format_info *format;
unsigned int stride;
int fence_reg;
unsigned int tiling_mode;
@@ -1042,7 +1042,7 @@ struct intel_fbc {
 
struct {
u64 ggtt_offset;
-   uint32_t pixel_format;
+   const struct drm_format_info *format;
unsigned int stride;
int fence_reg;
} fb;
diff --git a/drivers/gpu/drm/i915/intel_fbc.c b/drivers/gpu/drm/i915/intel_fbc.c
index 62f215b12eb5..659cebc3bfd2 100644
--- a/drivers/gpu/drm/i915/intel_fbc.c
+++ b/drivers/gpu/drm/i915/intel_fbc.c
@@ -188,7 +188,7 @@ static void g4x_fbc_activate(struct drm_i915_private 
*dev_priv)
u32 dpfc_ctl;
 
dpfc_ctl = DPFC_CTL_PLANE(params->crtc.plane) | DPFC_SR_EN;
-   if (drm_format_plane_cpp(params->fb.pixel_format, 0) == 2)
+   if (params->fb.format->cpp[0] == 2)
dpfc_ctl |= DPFC_CTL_LIMIT_2X;
else
dpfc_ctl |= DPFC_CTL_LIMIT_1X;
@@ -235,7 +235,7 @@ static void ilk_fbc_activate(struct drm_i915_private 
*dev_priv)
int threshold = dev_priv->fbc.threshold;
 
dpfc_ctl = DPFC_CTL_PLANE(params->crtc.plane);
-   if (drm_format_plane_cpp(params->fb.pixel_format, 0) == 2)
+   if (params->fb.format->cpp[0] == 2)
threshold++;
 
switch (threshold) {
@@ -303,7 +303,7 @@ static void gen7_fbc_activate(struct drm_i915_private 
*dev_priv)
if (IS_IVYBRIDGE(dev_priv))
dpfc_ctl |= IVB_DPFC_CTL_PLANE(params->crtc.plane);
 
-   if (drm_format_plane_cpp(params->fb.pixel_format, 0) == 2)
+   if (params->fb.format->cpp[0] == 2)
threshold++;
 
switch (threshold) {
@@ -581,7 +581,7 @@ static int intel_fbc_alloc_cfb(struct intel_crtc *crtc)
WARN_ON(drm_mm_node_allocated(>compressed_fb));
 
size = intel_fbc_calculate_cfb_size(dev_priv, >state_cache);
-   fb_cpp = drm_format_plane_cpp(fbc->state_cache.fb.pixel_format, 0);
+   fb_cpp = fbc->state_cache.fb.format->cpp[0];
 
ret = find_compression_threshold(dev_priv, >compressed_fb,
 size, fb_cpp);
@@ -764,7 +764,7 @@ static void intel_fbc_update_state_cache(struct intel_crtc 
*crtc,
 * platforms that need. */
if (IS_GEN(dev_priv, 5, 6))
cache->fb.ilk_ggtt_offset = i915_gem_object_ggtt_offset(obj, 
NULL);
-   cache->fb.pixel_format = fb->pixel_format;
+   cache->fb.format = fb->format;
cache->fb.stride = fb->pitches[0];
cache->fb.fence_reg = get_fence_id(fb);
cache->fb.tiling_mode = i915_gem_object_get_tiling(obj);
@@ -823,7 +823,7 @@ static bool intel_fbc_can_activate(struct intel_crtc *crtc)
return false;
}
 
-   if (!pixel_format_is_valid(dev_priv, cache->fb.pixel_format)) {
+   if (!pixel_format_is_valid(dev_priv, cache->fb.format->format)) {
fbc->no_fbc_reason = "pixel format is invalid";
return false;
}
@@ -892,7 +892,7 @@ static void intel_fbc_get_reg_params(struct intel_crtc 
*crtc,
params->crtc.plane = crtc->plane;
params->crtc.fence_y_offset = get_crtc_fence_y_offset(crtc);
 
-   params->fb.pixel_format = cache->fb.pixel_format;
+   params->fb.format = cache->fb.format;
params->fb.stride = cache->fb.stride;
params->fb.fence_reg = cache->fb.fence_reg;
 
-- 
2.7.4

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

[Intel-gfx] [PATCH 17/32] drm/i915: Set fb->dev early on for inherited fbs

[ville . syrjala]

From: Ville Syrjälä 

We want the fbs inherited from the BIOS to be more or less fully working
prior to actually registering them. This will allow us to just pass the
fb to various helper function instead of having to pass all the
different parameters separately.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 12af936a402d..74a638c8de61 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8704,6 +8704,8 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
 
fb = _fb->base;
 
+   fb->dev = dev;
+
if (INTEL_GEN(dev_priv) >= 4) {
if (val & DISPPLANE_TILED) {
plane_config->tiling = I915_TILING_X;
@@ -9734,6 +9736,8 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
 
fb = _fb->base;
 
+   fb->dev = dev;
+
val = I915_READ(PLANE_CTL(pipe, 0));
if (!(val & PLANE_CTL_ENABLE))
goto error;
@@ -9846,6 +9850,8 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc,
 
fb = _fb->base;
 
+   fb->dev = dev;
+
if (INTEL_GEN(dev_priv) >= 4) {
if (val & DISPPLANE_TILED) {
plane_config->tiling = I915_TILING_X;
-- 
2.7.4

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

[Intel-gfx] [PATCH 21/32] drm/i915: Populate fb->format early for inherited fbs

[ville . syrjala]

From: Ville Syrjälä 

MAke sure the framebuffer format info is available as early as possible
for fbs we inherit from the BIOS. This will allow us to use the fb as
if it was fully formed before we register it.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_display.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index 74a638c8de61..c45da6766fff 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -8717,6 +8717,7 @@ i9xx_get_initial_plane_config(struct intel_crtc *crtc,
fourcc = i9xx_format_to_fourcc(pixel_format);
fb->pixel_format = fourcc;
fb->bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
+   fb->format = drm_format_info(fourcc);
 
if (INTEL_GEN(dev_priv) >= 4) {
if (plane_config->tiling)
@@ -9748,6 +9749,7 @@ skylake_get_initial_plane_config(struct intel_crtc *crtc,
  val & PLANE_CTL_ALPHA_MASK);
fb->pixel_format = fourcc;
fb->bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
+   fb->format = drm_format_info(fourcc);
 
tiling = val & PLANE_CTL_TILED_MASK;
switch (tiling) {
@@ -9863,6 +9865,7 @@ ironlake_get_initial_plane_config(struct intel_crtc *crtc,
fourcc = i9xx_format_to_fourcc(pixel_format);
fb->pixel_format = fourcc;
fb->bits_per_pixel = drm_format_plane_cpp(fourcc, 0) * 8;
+   fb->format = drm_format_info(fourcc);
 
base = I915_READ(DSPSURF(pipe)) & 0xf000;
if (IS_HASWELL(dev_priv) || IS_BROADWELL(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 01/32] drm/i915: Add local 'fb' variables

[ville . syrjala]

From: Ville Syrjälä 

Add a local 'fb' variable to a few places to get rid of the
'crtc->primary->fb' stuff. Looks neater and helps me with my poor
coccinelle skills later.

While at it switch over to using the pixel format rather than
depth+bpp.

Cc: intel-gfx@lists.freedesktop.org
Signed-off-by: Ville Syrjälä 
---
 drivers/gpu/drm/i915/intel_overlay.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_overlay.c 
b/drivers/gpu/drm/i915/intel_overlay.c
index fd0e4dac7cc1..ce3667c18e18 100644
--- a/drivers/gpu/drm/i915/intel_overlay.c
+++ b/drivers/gpu/drm/i915/intel_overlay.c
@@ -658,6 +658,8 @@ static bool update_scaling_factors(struct intel_overlay 
*overlay,
 static void update_colorkey(struct intel_overlay *overlay,
struct overlay_registers __iomem *regs)
 {
+   const struct drm_framebuffer *fb =
+   overlay->crtc->base.primary->fb;
u32 key = overlay->color_key;
u32 flags;
 
@@ -665,24 +667,20 @@ static void update_colorkey(struct intel_overlay *overlay,
if (overlay->color_key_enabled)
flags |= DST_KEY_ENABLE;
 
-   switch (overlay->crtc->base.primary->fb->bits_per_pixel) {
-   case 8:
+   switch (fb->pixel_format) {
+   case DRM_FORMAT_C8:
key = 0;
flags |= CLK_RGB8I_MASK;
break;
-
-   case 16:
-   if (overlay->crtc->base.primary->fb->depth == 15) {
-   key = RGB15_TO_COLORKEY(key);
-   flags |= CLK_RGB15_MASK;
-   } else {
-   key = RGB16_TO_COLORKEY(key);
-   flags |= CLK_RGB16_MASK;
-   }
+   case DRM_FORMAT_XRGB1555:
+   key = RGB15_TO_COLORKEY(key);
+   flags |= CLK_RGB15_MASK;
break;
-
-   case 24:
-   case 32:
+   case DRM_FORMAT_RGB565:
+   key = RGB16_TO_COLORKEY(key);
+   flags |= CLK_RGB16_MASK;
+   break;
+   default:
flags |= CLK_RGB24_MASK;
break;
}
-- 
2.7.4

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

[Intel-gfx] [PATCH 00/32] drm: Deduplicate fb format information

[ville . syrjala]

From: Ville Syrjälä 

This series aims to remove the duplicated format information stored under
drm_framebuffer (depth,bits_per_pixel,pixel_format), and instead we just
use the drm_format_info structure. And we store a pointer to the approriate
drm_format_info under drm_framebuffer so that we don't have to do expensive
linear searches through the big array.

Quite of bit of this was cocci magic, and I've tried to keep the cocci
patches pure of manual tinkering in case someone needs to rerun them.
I had some issues with cocci behaving like an idiot, so I've included
a bunch of hand rolled patches up front to make life easier for it.

I've smoke tested this on i915, and compile tested on everything else
(I hope).

Entire series available here:
git://github.com/vsyrjala/linux.git fb_format_dedup

Cc: Alex Deucher 
Cc: Alexey Brodkin 
Cc: Ben Skeggs 
Cc: Brian Starkey 
Cc: "Christian König" 
Cc: Dave Airlie 
Cc: Gerd Hoffmann 
Cc: intel-gfx@lists.freedesktop.org
Cc: linux-graphics-maintai...@vmware.com
Cc: Liviu Dudau 
Cc: Mali DP Maintainers 
Cc: Patrik Jakobsson 
Cc: Paulo Zanoni 
Cc: Sinclair Yeh 
Cc: Thomas Hellstrom 

Ville Syrjälä (32):
  drm/i915: Add local 'fb' variables
  drm/radeon: Add local 'fb' variables
  drm/radeon: Use DIV_ROUND_UP()
  drm/mgag200: Add local 'fb' variable
  drm/ast: Add local 'fb' variables
  drm/gma500: Add some local 'fb' variables
  drm/cirrus: Add some local 'fb' variables
  drm/arcpgu: Add local 'fb' variables
  drm/arm: Add local 'fb' variables
  drm/nouveau: Fix crtc->primary->fb vs. drm_fb fail
  drm/nouveau: Add local 'fb' variables
  drm/vmwgfx: Populate fb->dev before drm_framebuffer_init()
  drm: Pass 'dev' to drm_helper_mode_fill_fb_struct()
  drm/vmwgfx: Populate fb->pixel_format
  drm/qxl: Call drm_helper_mode_fill_fb_struct() before
drm_framebuffer_init()
  drm/virtio: Call drm_helper_mode_fill_fb_struct() before
drm_framebuffer_init()
  drm/i915: Set fb->dev early on for inherited fbs
  drm: Populate fb->dev from drm_helper_mode_fill_fb_struct()
  drm: Store a pointer to drm_format_info under drm_framebuffer
  drm/vmwgfx: Populate fb->format correctly
  drm/i915: Populate fb->format early for inherited fbs
  drm/atomic: Replace drm_format_num_planes() with
fb->format->num_planes
  drm/fb_cma_helper: Replace drm_format_info() with fb->format
  drm/nouveau: Use fb->format rather than drm_format_info()
  drm/i915: Store a pointer to the pixel format info for fbc
  drm/i915: Replace drm_format_plane_cpp() with fb->format->cpp[]
  drm/i915: Replace drm_format_num_planes() with fb->format->num_planes
  drm: Add drm_framebuffer_plane_{width,height}()
  drm/i915: Use drm_framebuffer_plane_{width,height}() where possible
  drm: Nuke fb->depth
  drm: Nuke fb->bits_per_pixel
  drm: Nuke fb->pixel_format

 drivers/gpu/drm/amd/amdgpu/amdgpu_display.c |  2 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_fb.c  |  4 +-
 drivers/gpu/drm/amd/amdgpu/dce_v10_0.c  |  6 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c  |  6 +-
 drivers/gpu/drm/amd/amdgpu/dce_v6_0.c   |  6 +-
 drivers/gpu/drm/amd/amdgpu/dce_v8_0.c   |  6 +-
 drivers/gpu/drm/arc/arcpgu_crtc.c   |  3 +-
 drivers/gpu/drm/arm/hdlcd_crtc.c| 18 +++---
 drivers/gpu/drm/arm/malidp_planes.c | 10 ++--
 drivers/gpu/drm/armada/armada_crtc.c|  6 +-
 drivers/gpu/drm/armada/armada_fb.c  |  2 +-
 drivers/gpu/drm/armada/armada_fbdev.c   |  5 +-
 drivers/gpu/drm/armada/armada_overlay.c |  2 +-
 drivers/gpu/drm/ast/ast_fb.c|  4 +-
 drivers/gpu/drm/ast/ast_main.c  |  2 +-
 drivers/gpu/drm/ast/ast_mode.c  | 16 +++--
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_layer.c |  2 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 22 +++
 drivers/gpu/drm/bochs/bochs_fbdev.c |  2 +-
 drivers/gpu/drm/bochs/bochs_mm.c|  2 +-
 drivers/gpu/drm/cirrus/cirrus_fbdev.c   |  6 +-
 drivers/gpu/drm/cirrus/cirrus_main.c|  2 +-
 drivers/gpu/drm/cirrus/cirrus_mode.c|  9 +--
 drivers/gpu/drm/drm_atomic.c|  8 +--
 drivers/gpu/drm/drm_crtc.c  |  4 +-
 drivers/gpu/drm/drm_crtc_helper.c   |  4 +-
 drivers/gpu/drm/drm_fb_cma_helper.c | 11 ++--
 drivers/gpu/drm/drm_fb_helper.c | 10 ++--
 drivers/gpu/drm/drm_framebuffer.c   | 53 -
 drivers/gpu/drm/drm_modeset_helper.c| 11 ++--
 drivers/gpu/drm/drm_plane.c |  6 +-
 drivers/gpu/drm/exynos/exynos5433_drm_decon.c   |  6 +-
 

Re: [Intel-gfx] [PATCH i-g-t v6 08/21] tests/sw_sync: Add subtest test_sync_merge_same

[Chris Wilson]

On Thu, Nov 17, 2016 at 10:01:56AM -0500, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> This subtest verifies merging a fence with itself does not fail.
> 
> Signed-off-by: Robert Foss 
> Reviewed-by: Eric Engestrom 
> ---
>  tests/sw_sync.c | 27 +++
>  1 file changed, 27 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index 528be4d..51aa025 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -179,6 +179,30 @@ static void test_sync_merge(void)
>   close(timeline);
>  }
>  
> +static void test_sync_merge_same(void)
> +{
> + int in_fence[2];
> + int timeline;
> + int signaled;
> +
> + timeline = sw_sync_timeline_create();
> + in_fence[0] = sw_sync_fence_create(timeline, 1);
> + in_fence[1] = sync_merge(in_fence[0], in_fence[0]);
> +
> + signaled = sync_fence_count_status(in_fence[0],
> +   SW_SYNC_FENCE_STATUS_SIGNALED);
> + igt_assert_f(signaled == 0, "fence signaled too early\n");
> +
> + sw_sync_timeline_inc(timeline, 1);
> + signaled = sync_fence_count_status(in_fence[0],
> +   SW_SYNC_FENCE_STATUS_SIGNALED);
> + igt_assert_f(signaled == 1, "fence did not signal\n");

But what in_fence[1]? How does the lifetime of in_fence[1] relate to
in_fence[0]?
-Chris

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

Re: [Intel-gfx] [PATCH i-g-t v6 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid

[Chris Wilson]

On Thu, Nov 17, 2016 at 10:02:07AM -0500, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Add subtest test_sync_merge_invalid that tests merging invalid fences.
> 
> Signed-off-by: Robert Foss 
> ---
>  tests/sw_sync.c | 41 +
>  1 file changed, 41 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index 0aae4dc..d60fb32 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -155,6 +155,44 @@ static void test_sync_busy(void)
>   close(timeline);
>  }
>  
> +static void test_sync_merge_invalid(void)
> +{
> + int in_fence;
> + int fence_invalid;
> + int fence_merge;
> + int timeline;
> + char tmppath[] = "/tmp/igt-XX";
> + int skip = 0;
> +
> + timeline = sw_sync_timeline_create();
> + in_fence = sw_sync_fence_create(timeline, 1);
> +
> + fence_invalid = -1;
> + fence_merge = sync_merge(in_fence, fence_invalid);
> + igt_assert_f(fence_merge < 0, "Verify invalid fd (-1) handling");

For these you probably want:

int __sync_merge(int acc, int fd)
{
int out;

out = sync_merge(acc, fd);
if (out < 0)
out = -errno;
return out;
}

then igt_assert_eq(__sync_merge(in_fence, -1), -EINVAL);

Or at least assert the errno is EINVAL.
-Chris

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

Re: [Intel-gfx] [PATCH i-g-t v6 02/21] tests/sw_sync: Add sw_sync test

[Chris Wilson]

On Thu, Nov 17, 2016 at 10:01:50AM -0500, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Add initial tests for sw_sync.
> 
> Signed-off-by: Robert Foss 
> Signed-off-by: Gustavo Padovan 
> Reviewed-by: Eric Engestrom 
> ---
>  .settings/language.settings.xml |   25 +
>  lib/sw_sync.c   |   12 +-
>  lib/sw_sync.h   |8 +-
>  tests/Makefile.sources  |1 +
>  tests/drm_fence |  Bin 0 -> 901032 bytes
>  tests/kms_atomic.c.orig | 1803 
> +++
>  tests/kms_atomic.c.rej  |   15 +
>  tests/kms_fence |  Bin 0 -> 1798632 bytes
>  tests/sw_sync.c |   52 ++
>  tests/sw_sync.c.orig|  694 +++

Awooga.
-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] [drm-intel:drm-intel-next-queued 2/2] drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: warning: unused variable 'ggtt'

[kbuild test robot]

tree:   git://anongit.freedesktop.org/drm-intel drm-intel-next-queued
head:   95a2e2be952c3c3a643b8e0504f2ceef15294d4d
commit: 95a2e2be952c3c3a643b8e0504f2ceef15294d4d [2/2] drm/i915: Remove stolen 
object spam
config: i386-defconfig (attached as .config)
compiler: gcc-6 (Debian 6.2.0-3) 6.2.0 20160901
reproduce:
git checkout 95a2e2be952c3c3a643b8e0504f2ceef15294d4d
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/i915/i915_gem_stolen.c: In function 
'i915_pages_create_for_stolen':
>> drivers/gpu/drm/i915/i915_gem_stolen.c:516:20: warning: unused variable 
>> 'ggtt' [-Wunused-variable]
 struct i915_ggtt *ggtt = _priv->ggtt;
   ^~~~

vim +/ggtt +516 drivers/gpu/drm/i915/i915_gem_stolen.c

1ca36d4cb Paulo Zanoni2015-09-23  500* on the first page. So we 
don't reserve this page for now because of
1ca36d4cb Paulo Zanoni2015-09-23  501* that. Our current solution 
is to just prevent new nodes from being
1ca36d4cb Paulo Zanoni2015-09-23  502* inserted on the first page - 
see the check we have at
1ca36d4cb Paulo Zanoni2015-09-23  503* 
i915_gem_stolen_insert_node_in_range(). We may want to fix the fbcon
1ca36d4cb Paulo Zanoni2015-09-23  504* problem later.
1ca36d4cb Paulo Zanoni2015-09-23  505*/
72e96d645 Joonas Lahtinen 2016-03-30  506   
drm_mm_init(_priv->mm.stolen, 0, ggtt->stolen_usable_size);
9797fbfbc Chris Wilson2012-04-24  507  
9797fbfbc Chris Wilson2012-04-24  508   return 0;
9797fbfbc Chris Wilson2012-04-24  509  }
0104fdbb8 Chris Wilson2012-11-15  510  
0104fdbb8 Chris Wilson2012-11-15  511  static struct sg_table *
0104fdbb8 Chris Wilson2012-11-15  512  i915_pages_create_for_stolen(struct 
drm_device *dev,
0104fdbb8 Chris Wilson2012-11-15  513u32 
offset, u32 size)
0104fdbb8 Chris Wilson2012-11-15  514  {
72e96d645 Joonas Lahtinen 2016-03-30  515   struct drm_i915_private 
*dev_priv = to_i915(dev);
72e96d645 Joonas Lahtinen 2016-03-30 @516   struct i915_ggtt *ggtt = 
_priv->ggtt;
0104fdbb8 Chris Wilson2012-11-15  517   struct sg_table *st;
0104fdbb8 Chris Wilson2012-11-15  518   struct scatterlist *sg;
0104fdbb8 Chris Wilson2012-11-15  519  
95a2e2be9 Chris Wilson2016-11-16  520   GEM_BUG_ON(offset > 
ggtt->stolen_size - size);
0104fdbb8 Chris Wilson2012-11-15  521  
0104fdbb8 Chris Wilson2012-11-15  522   /* We hide that we have no 
struct page backing our stolen object
0104fdbb8 Chris Wilson2012-11-15  523* by wrapping the contiguous 
physical allocation with a fake
0104fdbb8 Chris Wilson2012-11-15  524* dma mapping in a single 
scatterlist.

:: The code at line 516 was first introduced by commit
:: 72e96d6450c067f58b65224bb5e73914e2cc43ab drm/i915: Refer to GGTT {,VM} 
consistently

:: TO: Joonas Lahtinen 
:: CC: Joonas Lahtinen 

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


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

Re: [Intel-gfx] [PATCH i-g-t v6 07/21] tests/sw_sync: Add subtest test_sync_merge

[Chris Wilson]

On Thu, Nov 17, 2016 at 10:01:55AM -0500, robert.f...@collabora.com wrote:
> From: Robert Foss 
> 
> Add subtest test_sync_merge that tests merging fences and the validity of the
> resulting merged fence.
> 
> Signed-off-by: Robert Foss 
> Reviewed-by: Eric Engestrom 
> ---
>  tests/sw_sync.c | 67 
> +
>  1 file changed, 67 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index 9667b93..528be4d 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -115,6 +115,70 @@ static void test_sync_busy(void)
>   close(timeline);
>  }
>  
> +static void test_sync_merge(void)
> +{
> + int in_fence[3];
> + int fence_merge;
> + int timeline;
> + int active, signaled;
> +
> + timeline = sw_sync_timeline_create();
> + in_fence[0] = sw_sync_fence_create(timeline, 1);
> + in_fence[1] = sw_sync_fence_create(timeline, 2);
> + in_fence[2] = sw_sync_fence_create(timeline, 3);
> +
> + fence_merge = sync_merge(in_fence[0], in_fence[1]);
> + fence_merge = sync_merge(in_fence[2], fence_merge);

Can I suggest the pattern:

fence_merge = -1;
for (i = 0; i < ARRAY_SIZE(in_fence); i++) {
in_fence[i] = sw_sync_fence_create(timeline, i + 1);
fence_merge = sync_merge(fence_merge, in_fence[i]);

active = sync_fence_count_status(in_fence[i],
 SW_SYNC_FENCE_STATUS_ACTIVE);
igt_assert_f(active == 1, "in_fence[%d] has too many active fences\n", 
i);

igt_assert(!sync_fence_count_status(in_fence[i],
SW_SYNC_FENCE_STATUS_SIGNALED));
igt_assert(!sync_fence_count_status(fence_merge,
SW_SYNC_FENCE_STATUS_SIGNALED));
}

> + /* confirm that fence_merge is not signaled until the max of fence 
> 0,1,2 */
for (i = 0; i < ARRAY_SIZE(in_fence); i++) {
sw_sync_timeline_inc(timeline, 1);

signaled = sync_fence_count_status(in_fence[i],
   SW_SYNC_FENCE_STATUS_SIGNALED);
igt_assert_f(signaled == 1, "in_fence[%d] did not signal\n", i);

signaled = sync_fence_count_status(fence_merge,
   SW_SYNC_FENCE_STATUS_SIGNALED);
active = sync_fence_count_status(fence_merge,
 SW_SYNC_FENCE_STATUS_ACTIVE);
if (i + 1 == ARRAY_SIZE(in_fence)) { /* all signaled -> merge complete 
*/
igt_assert_f(active == 0 && signaled == 1,
 "fence_merge did not signal\n");
} else {
igt_assert_f(active == 1 && signaled == 0,
 "fence_merge signaled too early\n");
}

close(in_fence[1]);
}

> + close(fence_merge);
> + close(timeline);
> +}
> +
>  igt_main
>  {
>   igt_subtest("alloc_timeline")
> @@ -131,5 +195,8 @@ igt_main
>  
>   igt_subtest("sync_busy")
>   test_sync_busy();
> +
> + igt_subtest("sync_merge")
> + test_sync_merge();
>  }
>  
> -- 
> 2.10.2
> 

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

Re: [Intel-gfx] [PATCH i-g-t v6 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

[Robert Foss]

On Thu, 2016-11-17 at 15:39 +, Chris Wilson wrote:
> On Thu, Nov 17, 2016 at 10:02:02AM -0500, robert.f...@collabora.com
> wrote:
> > 
> > From: Rafael Antognolli 
> > 
> > This test creates an already expired fence, then creates a merged
> > fence
> > out of that expired one (passed twice to the merge operation), and
> > finally closes the merged fence. It shows that if the refcounts are
> > wrong on the original expired fence, it might get freed while still
> > in
> > use. Usually a kernel panick will follow.
> > 
> > Signed-off-by: Rafael Antognolli 
> > Signed-off-by: Robert Foss 
> > ---
> >  tests/sw_sync.c | 28 
> >  1 file changed, 28 insertions(+)
> > 
> > diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> > index 4e52f48..65416ad 100644
> > --- a/tests/sw_sync.c
> > +++ b/tests/sw_sync.c
> > @@ -582,6 +582,31 @@ static void
> > test_sync_multi_producer_single_consumer(void)
> >     pthread_join(threads[i], NULL);
> >  }
> >  
> > +static void test_sync_expired_merge(void)
> > +{
> > +   int iterations = 1 << 20;
> > +   int timeline;
> > +   int i;
> > +   int fence_expired, fence_merged;
> > +
> > +   timeline = sw_sync_timeline_create();
> > +
> > +   sw_sync_timeline_inc(timeline, 100);
> > +   fence_expired = sw_sync_fence_create(timeline, 1);
> igt_assert(sync_wait(fence_expired, 0) == 1);
> or
> igt_assert(fence_signaled(fence_expired));
> 
> Both illustrative of the setup, and tests them.

Agreed, I'll add it for v7.

> 
> > 
> > +   fence_merged = sync_merge(fence_expired, fence_expired);
> > +   close(fence_merged);
> > +
> > +   for (i = 0; i < iterations; i++) {
> > +   int fence = sync_merge(fence_expired,
> > fence_expired);
> > +
> > +   igt_assert_f(sync_wait(fence, -1) == 0,
> > +    "Failure waiting on
> > fence\n");
> > +   close(fence);
> Is the millionth iteration more likely to fail than iteration 0?
> 
> There's no change in code coverage, so is it worth the extra
> iterations?

I don't know if it is more likely to fail or not, which is why multiple
iterations are tested.

If you can tell me with certainty that multiple iterations always will
behave the same way I would be happy to remove the multiple iterations.

Granted, there are a few other tests that also do stress testing as a
part of what they test. So maybe this is redundant either way?
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH] drm/i915: Only dump dp_m2_n2 configuration when drrs is used

[Tvrtko Ursulin]

From: Tvrtko Ursulin 

Otherwise it is just an useless empty line.

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

diff --git a/drivers/gpu/drm/i915/intel_display.c 
b/drivers/gpu/drm/i915/intel_display.c
index bd2c99e2e523..200f09778776 100644
--- a/drivers/gpu/drm/i915/intel_display.c
+++ b/drivers/gpu/drm/i915/intel_display.c
@@ -12751,9 +12751,10 @@ static void intel_dump_pipe_config(struct intel_crtc 
*crtc,
if (intel_crtc_has_dp_encoder(pipe_config)) {
intel_dump_m_n_config(pipe_config, "dp m_n",
pipe_config->lane_count, _config->dp_m_n);
-   intel_dump_m_n_config(pipe_config, "dp m2_n2",
-   pipe_config->lane_count,
-   _config->dp_m2_n2);
+   if (pipe_config->has_drrs)
+   intel_dump_m_n_config(pipe_config, "dp m2_n2",
+ pipe_config->lane_count,
+ _config->dp_m2_n2);
}
 
DRM_DEBUG_KMS("audio: %i, infoframes: %i\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 i-g-t v6 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

[Chris Wilson]

On Thu, Nov 17, 2016 at 10:02:02AM -0500, robert.f...@collabora.com wrote:
> From: Rafael Antognolli 
> 
> This test creates an already expired fence, then creates a merged fence
> out of that expired one (passed twice to the merge operation), and
> finally closes the merged fence. It shows that if the refcounts are
> wrong on the original expired fence, it might get freed while still in
> use. Usually a kernel panick will follow.
> 
> Signed-off-by: Rafael Antognolli 
> Signed-off-by: Robert Foss 
> ---
>  tests/sw_sync.c | 28 
>  1 file changed, 28 insertions(+)
> 
> diff --git a/tests/sw_sync.c b/tests/sw_sync.c
> index 4e52f48..65416ad 100644
> --- a/tests/sw_sync.c
> +++ b/tests/sw_sync.c
> @@ -582,6 +582,31 @@ static void 
> test_sync_multi_producer_single_consumer(void)
>   pthread_join(threads[i], NULL);
>  }
>  
> +static void test_sync_expired_merge(void)
> +{
> + int iterations = 1 << 20;
> + int timeline;
> + int i;
> + int fence_expired, fence_merged;
> +
> + timeline = sw_sync_timeline_create();
> +
> + sw_sync_timeline_inc(timeline, 100);
> + fence_expired = sw_sync_fence_create(timeline, 1);

igt_assert(sync_wait(fence_expired, 0) == 1);
or
igt_assert(fence_signaled(fence_expired));

Both illustrative of the setup, and tests them.

> + fence_merged = sync_merge(fence_expired, fence_expired);
> + close(fence_merged);
> +
> + for (i = 0; i < iterations; i++) {
> + int fence = sync_merge(fence_expired, fence_expired);
> +
> + igt_assert_f(sync_wait(fence, -1) == 0,
> +  "Failure waiting on fence\n");
> + close(fence);

Is the millionth iteration more likely to fail than iteration 0?

There's no change in code coverage, so is it worth the extra iterations?
-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] ✗ Fi.CI.BAT: warning for drm/i915: Waterproof verification of gen9 forcewake table ranges

[Tvrtko Ursulin]

On 17/11/2016 15:16, Patchwork wrote:

== Series Details ==

Series: drm/i915: Waterproof verification of gen9 forcewake table ranges
URL   : https://patchwork.freedesktop.org/series/15496/
State : warning

== Summary ==

Series 15496v1 drm/i915: Waterproof verification of gen9 forcewake table ranges
https://patchwork.freedesktop.org/api/1.0/series/15496/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> DMESG-WARN (fi-snb-2520m)


Just the EDID checksum issue:

https://bugs.freedesktop.org/show_bug.cgi?id=98625


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14
fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33

0edb25a37b8f30bf40c9db5625b7401f7fc890e9 drm-intel-nightly: 
2016y-11m-17d-14h-26m-31s UTC integration manifest
e4fe914 drm/i915: Waterproof verification of gen9 forcewake table ranges


Merged to dinq, thanks for the review.

Regards,

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

[Intel-gfx] [PATCH] drm/i915: Remove misinformation about mark_busy/mark_idle

[Chris Wilson]

Nowadays these are solely for managing the GT wakelock. Don't confuse
the reader by referring to how they used to work, nor suggest they are
deprecated simply because they are no longer relevant for frontbuffer
tracking.

Signed-off-by: Chris Wilson 
Cc: Daniel Vetter 
---
 drivers/gpu/drm/i915/intel_frontbuffer.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_frontbuffer.c 
b/drivers/gpu/drm/i915/intel_frontbuffer.c
index 966de4c7c7a2..5c0778a61a2a 100644
--- a/drivers/gpu/drm/i915/intel_frontbuffer.c
+++ b/drivers/gpu/drm/i915/intel_frontbuffer.c
@@ -53,11 +53,6 @@
  * busyness. There is no direct way to detect idleness. Instead an idle timer
  * work delayed work should be started from the flush and flip functions and
  * cancelled as soon as busyness is detected.
- *
- * Note that there's also an older frontbuffer activity tracking scheme which
- * just tracks general activity. This is done by the various mark_busy and
- * mark_idle functions. For display power management features using these
- * functions is deprecated and should be avoided.
  */
 
 #include 
-- 
2.10.2

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Waterproof verification of gen9 forcewake table ranges

[Patchwork]

== Series Details ==

Series: drm/i915: Waterproof verification of gen9 forcewake table ranges
URL   : https://patchwork.freedesktop.org/series/15496/
State : warning

== Summary ==

Series 15496v1 drm/i915: Waterproof verification of gen9 forcewake table ranges
https://patchwork.freedesktop.org/api/1.0/series/15496/revisions/1/mbox/

Test drv_module_reload_basic:
dmesg-warn -> PASS   (fi-skl-6770hq)
Test kms_force_connector_basic:
Subgroup force-load-detect:
pass   -> DMESG-WARN (fi-snb-2520m)

fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15 
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40 
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28 
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32 
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20 
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53 
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22 
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21 
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21 
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14 
fi-snb-2520m total:244  pass:211  dwarn:1   dfail:0   fail:0   skip:32 
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33 

0edb25a37b8f30bf40c9db5625b7401f7fc890e9 drm-intel-nightly: 
2016y-11m-17d-14h-26m-31s UTC integration manifest
e4fe914 drm/i915: Waterproof verification of gen9 forcewake table ranges

== Logs ==

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

Re: [Intel-gfx] [PATCH] drm/i915: Only poll DW3_A when init DDI PHY for ports B and C.

[Imre Deak]

On ma, 2016-11-14 at 21:51 +0200, Vivi, Rodrigo wrote:
> On Fri, 2016-11-11 at 15:09 +0200, Imre Deak wrote:
> > On to, 2016-11-10 at 17:03 -0800, Rodrigo Vivi wrote:
> > > According to Bspec we need to
> > > "Poll for PORT_REF_DW3_A grc_done == 1b"
> > > only on ports B and C initialization sequence when
> > > copying rcomp from port A.
> > > 
> > > So let's follow the spec and only poll for that case
> > > and not on every port A initialization.
> > > 
> > > Cc: Imre Deak 
> > > Cc: Ander Conselvan de Oliveira 
> > > Signed-off-by: Rodrigo Vivi 
> > 
> > The current code isn't against the spec, we just wait for the
> > calibration to complete earlier. This way we also wait in case only
> > port A is enabled which is imo safer to do before a subsequent
> > modeset
> > on port A. But yes, the spec suggests the HW will handle the wait
> > for
> > this - only port A - case internally, so we can move the wait later
> > to
> > reduce somewhat the init time:
> > 
> > Reviewed-by: Imre Deak 
> 
> Ops, actually I noticed later that I need to remove the warning block
> with return false from is_phy_enabled if grc isn't done. otherwise it
> will force a reprograming without this line there.

Yea, missed that too.

> 
> So, do you believe it is worth to do a v2 removing that block or
> better
> to just ignore this patch?

The calibration takes ~2ms on my APL, so I think it's worth reducing
that delay.

> 
> > 
> > > ---
> > >  drivers/gpu/drm/i915/intel_dpio_phy.c | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > > 
> > > diff --git a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > index 7a8e82d..277b1aa 100644
> > > --- a/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > +++ b/drivers/gpu/drm/i915/intel_dpio_phy.c
> > > @@ -367,6 +367,9 @@ static void _bxt_ddi_phy_init(struct
> > > drm_i915_private *dev_priv,
> > >  
> > >   if (phy_info->rcomp_phy != -1) {
> > >   uint32_t grc_code;
> > > +
> > > + bxt_phy_wait_grc_done(dev_priv, phy_info-
> > > >rcomp_phy);
> > > +
> > >   /*
> > >    * PHY0 isn't connected to an RCOMP resistor so
> > > copy over
> > >    * the corresponding calibrated value from PHY1,
> > > and disable
> > > @@ -387,10 +390,6 @@ static void _bxt_ddi_phy_init(struct
> > > drm_i915_private *dev_priv,
> > >   val = I915_READ(BXT_PHY_CTL_FAMILY(phy));
> > >   val |= COMMON_RESET_DIS;
> > >   I915_WRITE(BXT_PHY_CTL_FAMILY(phy), val);
> > > -
> > > - if (phy_info->rcomp_phy == -1)
> > > - bxt_phy_wait_grc_done(dev_priv, phy);
> > > -
> > >  }
> > >  
> > >  void bxt_ddi_phy_uninit(struct drm_i915_private *dev_priv, enum
> > > dpio_phy phy)
> 
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for Pipe config debug dump diet

[Tvrtko Ursulin]

On 17/11/2016 13:16, Patchwork wrote:

== Series Details ==

Series: Pipe config debug dump diet
URL   : https://patchwork.freedesktop.org/series/15493/
State : success

== Summary ==

Series 15493v1 Pipe config debug dump diet
https://patchwork.freedesktop.org/api/1.0/series/15493/revisions/1/mbox/


fi-bdw-5557u total:244  pass:229  dwarn:0   dfail:0   fail:0   skip:15
fi-bsw-n3050 total:244  pass:204  dwarn:0   dfail:0   fail:0   skip:40
fi-bxt-t5700 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-j1900 total:244  pass:216  dwarn:0   dfail:0   fail:0   skip:28
fi-byt-n2820 total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32
fi-hsw-4770  total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20
fi-hsw-4770r total:244  pass:224  dwarn:0   dfail:0   fail:0   skip:20
fi-ilk-650   total:244  pass:191  dwarn:0   dfail:0   fail:0   skip:53
fi-ivb-3520m total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-ivb-3770  total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-kbl-7200u total:244  pass:222  dwarn:0   dfail:0   fail:0   skip:22
fi-skl-6260u total:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14
fi-skl-6700hqtotal:244  pass:223  dwarn:0   dfail:0   fail:0   skip:21
fi-skl-6700k total:244  pass:222  dwarn:1   dfail:0   fail:0   skip:21
fi-skl-6770hqtotal:244  pass:230  dwarn:0   dfail:0   fail:0   skip:14
fi-snb-2520m total:244  pass:212  dwarn:0   dfail:0   fail:0   skip:32
fi-snb-2600  total:244  pass:211  dwarn:0   dfail:0   fail:0   skip:33

ccd01198820ab7286f0b98f7b28dbf6ad29fa861 drm-intel-nightly: 
2016y-11m-17d-10h-54m-57s UTC integration manifest
a9bf7b7 drm/i915: Introduce enableddisabled helper
1cd61af drm/i915: Only dump possible panel fitter config for the platform
e5069f1 drm/i915: Only dump scaler config where supported
5d6948f drm/i915: Compact a few pipe config debug lines
63a49f1 drm/i915: Don't log pipe config kernel pointer and duplicated pipe name
f711717 drm/i915: Dump FDI config only where applicable
2a89809 drm/i915: Extract intel_link_m_n config printing into a helper


Merged to dinq and thanks Maarten for the review. Unfortunately I forgot 
to apply his r-b's manually before pushing. :(


Regards,

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

Re: [Intel-gfx] [PATCH 2/3] drm/i915: Protect dev_priv->atomic_cdclk_freq with all the crtc locks

[Ville Syrjälä]

On Tue, Nov 15, 2016 at 02:53:00PM +0100, Maarten Lankhorst wrote:
> Op 15-11-16 om 14:41 schreef Ville Syrjälä:
> > On Tue, Nov 15, 2016 at 11:14:29AM +0100, Maarten Lankhorst wrote:
> >> Op 14-11-16 om 17:35 schreef ville.syrj...@linux.intel.com:
> >>> From: Ville Syrjälä 
> >>>
> >>> A modeset on one pipe can update dev_priv->atomic_cdclk_freq without
> >>> actually touching the hardware, in which case we won't force a modeset
> >>> on all the pipes, and thus won't lock any of the other pipes either.
> >>> That means a parallel plane update on another pipe could be looking at
> >>> a stale dev_priv->atomic_cdcdlk_freq and thus fail to notice when the
> >>> plane configuration is invalid, or potentially reject a valid update.
> >>>
> >>> To overcome this we must protect writes to atomic_cdclk_freq with
> >>> all the crtc locks, and thus for reads any single crtc lock will
> >>> be sufficient protection.
> >>>
> >>> Cc: Maarten Lankhorst 
> >>> Signed-off-by: Ville Syrjälä 
> >>> ---
> >>>  drivers/gpu/drm/i915/i915_drv.h  |  9 +++-
> >>>  drivers/gpu/drm/i915/intel_display.c | 41 
> >>> +++-
> >>>  2 files changed, 44 insertions(+), 6 deletions(-)
> >>>
> >>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
> >>> b/drivers/gpu/drm/i915/i915_drv.h
> >>> index c0f1dfc7119e..66d2950dc657 100644
> >>> --- a/drivers/gpu/drm/i915/i915_drv.h
> >>> +++ b/drivers/gpu/drm/i915/i915_drv.h
> >>> @@ -1874,7 +1874,14 @@ struct drm_i915_private {
> >>>  
> >>>   unsigned int fsb_freq, mem_freq, is_ddr3;
> >>>   unsigned int skl_preferred_vco_freq;
> >>> - unsigned int cdclk_freq, max_cdclk_freq, atomic_cdclk_freq;
> >>> + unsigned int cdclk_freq, max_cdclk_freq;
> >>> +
> >>> + /*
> >>> +  * For reading holding any crtc lock is sufficient,
> >>> +  * for writing must hold all of them.
> >>> +  */
> >>> + unsigned int atomic_cdclk_freq;
> >>> +
> >>>   unsigned int max_dotclk_freq;
> >>>   unsigned int rawclk_freq;
> >>>   unsigned int hpll_freq;
> >>> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> >>> b/drivers/gpu/drm/i915/intel_display.c
> >>> index 70f3f0b70263..d7a4bc63b05b 100644
> >>> --- a/drivers/gpu/drm/i915/intel_display.c
> >>> +++ b/drivers/gpu/drm/i915/intel_display.c
> >>> @@ -13946,13 +13946,32 @@ static int 
> >>> haswell_mode_set_planes_workaround(struct drm_atomic_state *state)
> >>>   return 0;
> >>>  }
> >>>  
> >>> +static int intel_lock_all_pipes(struct drm_atomic_state *state)
> >>> +{
> >>> + struct drm_crtc *crtc;
> >>> +
> >>> + /* Add all pipes to the state */
> >>> + for_each_crtc(state->dev, crtc) {
> >>> + struct drm_crtc_state *crtc_state;
> >>> +
> >>> + crtc_state = drm_atomic_get_crtc_state(state, crtc);
> >>> + if (IS_ERR(crtc_state))
> >>> + return PTR_ERR(crtc_state);
> >>> + }
> >>> +
> >>> + return 0;
> >>> +}
> >>> +
> >>>  static int intel_modeset_all_pipes(struct drm_atomic_state *state)
> >>>  {
> >>>   struct drm_crtc *crtc;
> >>>   struct drm_crtc_state *crtc_state;
> >>>   int ret = 0;
> >>>  
> >>> - /* add all active pipes to the state */
> >>> + /*
> >>> +  * Add all pipes to the state, and force
> >>> +  * a modeset on all the active ones.
> >>> +  */
> >>>   for_each_crtc(state->dev, crtc) {
> >>>   crtc_state = drm_atomic_get_crtc_state(state, crtc);
> >>>   if (IS_ERR(crtc_state))
> >>> @@ -14018,12 +14037,24 @@ static int intel_modeset_checks(struct 
> >>> drm_atomic_state *state)
> >>>   if (ret < 0)
> >>>   return ret;
> >>>  
> >>> + /*
> >>> +  * Writes to dev_priv->atomic_cdclk_freq must protected by
> >>> +  * holding all the crtc locks, even if we don't end up
> >>> +  * touching the hardware
> >>> +  */
> >>> + if (intel_state->cdclk != dev_priv->atomic_cdclk_freq) {
> >>> + ret = intel_lock_all_pipes(state);
> >>> + if (ret < 0)
> >>> + return ret;
> >>> + }
> >>> +
> >> Would it be terrible to just use intel_modeset_all_pipes here? Since this 
> >> can only be different in the all crtc's disabled case
> >> it won't matter much.
> > Is there any benefit in doing that? A bit confusing IMO to force a
> > modeset when you don't have to.
> >
> The case where atomic cdclk changes, but dev_cdclk stays the same can only 
> happen
> if you configure a crtc, but all crtc's stay !active. In all other cases 
> dev_cdclk
> will change too.
> 
> intel_modeset_all_pipes will only set mode_changed on active crtc's, but it 
> will
> add all crtc's to the atomic state regardless to make sure the cdclk stays 
> consistent.

I still don't see what the benefit is. IMO it's just confusing to say
that we're going to force a modeset on a disabled pipe.

-- 
Ville Syrjälä
Intel OTC
___
Intel-gfx mailing list

[Intel-gfx] [PATCH i-g-t v6 13/21] tests/sw_sync: Add subtest test_sync_multi_producer_single_consumer

[robert . foss]

From: Robert Foss 

This subtest runs a single consumer thread and multiple producer thread that
are synchronized using multiple timelines.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 139 
 1 file changed, 139 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 99bd3d9..4e52f48 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -446,6 +446,142 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static int test_mspc_wait_on_fence(int fence)
+{
+   int error, active;
+
+   do {
+   error = sync_fence_count_status(fence,
+  SW_SYNC_FENCE_STATUS_ERROR);
+   igt_assert_f(error == 0, "Error occurred on fence\n");
+   active = sync_fence_count_status(fence,
+   
SW_SYNC_FENCE_STATUS_ACTIVE);
+   } while (active);
+
+   return 0;
+}
+
+static struct {
+   int iterations;
+   int threads;
+   int counter;
+   int cons_timeline;
+   int *prod_timeline;
+   pthread_mutex_t lock;
+} test_mpsc_data;
+
+static int mpsc_producer_thread(void *d)
+{
+   int id = (long)d;
+   int fence, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+
+   for (i = 0; i < iterations; i++) {
+   fence = sw_sync_fence_create(cons_timeline, i);
+
+   /* Wait for the consumer to finish. Use alternate
+* means of waiting on the fence
+*/
+   if ((iterations + id) % 8 != 0) {
+   igt_assert_f(sync_wait(fence, -1) == 0,
+"Failure waiting on fence\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   /* Every producer increments the counter, the consumer
+* checks and erases it
+*/
+   pthread_mutex_lock(_mpsc_data.lock);
+   test_mpsc_data.counter++;
+   pthread_mutex_unlock(_mpsc_data.lock);
+
+   sw_sync_timeline_inc(prod_timeline[id], 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+static int mpsc_consumer_thread(void)
+{
+   int fence, merged, tmp, it, i;
+   int *prod_timeline = test_mpsc_data.prod_timeline;
+   int cons_timeline = test_mpsc_data.cons_timeline;
+   int iterations = test_mpsc_data.iterations;
+   int n = test_mpsc_data.threads;
+
+   for (it = 1; it <= iterations; it++) {
+   fence = sw_sync_fence_create(prod_timeline[0], it);
+   for (i = 1; i < n; i++) {
+   tmp = sw_sync_fence_create(prod_timeline[i], it);
+   merged = sync_merge(tmp, fence);
+   close(tmp);
+   close(fence);
+   fence = merged;
+   }
+
+   /* Make sure we see an increment from every producer thread.
+* Vary the means by which we wait.
+*/
+   if (iterations % 8 != 0) {
+   igt_assert_f(sync_wait(fence, -1) == 0,
+   "Producers did not increment as 
expected\n");
+   } else {
+   igt_assert_f(test_mspc_wait_on_fence(fence) == 0,
+"Failure waiting on fence\n");
+   }
+
+   igt_assert_f(test_mpsc_data.counter == n * it,
+"Counter value mismatch\n");
+
+   /* Release the producer threads */
+   sw_sync_timeline_inc(cons_timeline, 1);
+   close(fence);
+   }
+
+   return 0;
+}
+
+/* IMPORTANT NOTE: if you see this test failing on your system, it may be
+ * due to a shortage of file descriptors. Please ensure your system has
+ * a sensible limit for this test to finish correctly.
+ */
+static void test_sync_multi_producer_single_consumer(void)
+{
+   int iterations = 1 << 12;
+   int n = 5;
+   int prod_timeline[n];
+   int cons_timeline;
+   pthread_t threads[n];
+   long i;
+
+   cons_timeline = sw_sync_timeline_create();
+   for (i = 0; i < n; i++)
+   prod_timeline[i] = sw_sync_timeline_create();
+
+   test_mpsc_data.prod_timeline = prod_timeline;
+   test_mpsc_data.cons_timeline = cons_timeline;
+   test_mpsc_data.iterations = iterations;
+   test_mpsc_data.threads = n;
+   test_mpsc_data.counter = 0;
+   

[Intel-gfx] [PATCH i-g-t v6 20/21] tests/sw_sync: Add subtest test_sync_busy_fork

[robert . foss]

From: Robert Foss 

Add subtest test_sync_busy_fork which increments the timeline in a forked child
process.

Signed-off-by: Robert Foss 
---
 tests/sw_sync.c | 39 +++
 1 file changed, 39 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index d60fb32..440c1bf 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -155,6 +155,42 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_busy_fork(void)
+{
+   int fence, ret;
+   int timeline;
+   int skip = 0;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   switch (fork()) {
+   case 0:
+   /* Child process */
+   usleep(1*1000*1000);
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(timeline, 1);
+   _Exit(0);
+   break;
+   case -1:
+   /* Failed fork */
+   skip = 1;
+   break;
+   default:
+   /* Parent process */
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it 
should not have been signalled yet)\n");
+
+   ret = sync_wait(fence, 2*1000);
+   igt_assert_f(ret == 0, "Fence not signaled (timeline value 1 
fence seqno 1)\n");
+   break;
+   }
+
+   close(fence);
+   close(timeline);
+   igt_require(!skip);
+}
+
 static void test_sync_merge_invalid(void)
 {
int in_fence;
@@ -770,6 +806,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
 
+   igt_subtest("sync_busy_fork")
+   test_sync_busy_fork();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 19/21] tests/sw_sync: Add subtest test_sync_merge_invalid

[robert . foss]

From: Robert Foss 

Add subtest test_sync_merge_invalid that tests merging invalid fences.

Signed-off-by: Robert Foss 
---
 tests/sw_sync.c | 41 +
 1 file changed, 41 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 0aae4dc..d60fb32 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -155,6 +155,44 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_merge_invalid(void)
+{
+   int in_fence;
+   int fence_invalid;
+   int fence_merge;
+   int timeline;
+   char tmppath[] = "/tmp/igt-XX";
+   int skip = 0;
+
+   timeline = sw_sync_timeline_create();
+   in_fence = sw_sync_fence_create(timeline, 1);
+
+   fence_invalid = -1;
+   fence_merge = sync_merge(in_fence, fence_invalid);
+   igt_assert_f(fence_merge < 0, "Verify invalid fd (-1) handling");
+
+   fence_invalid = drm_open_driver(DRIVER_ANY);
+   fence_merge = sync_merge(in_fence, fence_invalid);
+   igt_assert_f(fence_merge < 0, "Verify invalid fd (device fd) handling");
+
+   fence_invalid = mkstemp(tmppath);
+   if (fence_invalid == -1) {
+   skip = 1;
+   goto out;
+   }
+   unlink(tmppath);
+   fence_invalid = drm_open_driver(DRIVER_ANY);
+   fence_merge = sync_merge(in_fence, fence_invalid);
+   close(fence_invalid);
+   igt_assert_f(fence_merge < 0, "Verify invalid fd (file fd) handling");
+
+out:
+   close(in_fence);
+   close(fence_merge);
+   close(timeline);
+   igt_require(skip == 0);
+}
+
 static void test_sync_merge(void)
 {
int in_fence[3];
@@ -732,6 +770,9 @@ igt_main
igt_subtest("sync_busy")
test_sync_busy();
 
+   igt_subtest("sync_merge_invalid")
+   test_sync_merge_invalid();
+
igt_subtest("sync_merge")
test_sync_merge();
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 08/21] tests/sw_sync: Add subtest test_sync_merge_same

[robert . foss]

From: Robert Foss 

This subtest verifies merging a fence with itself does not fail.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 27 +++
 1 file changed, 27 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 528be4d..51aa025 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -179,6 +179,30 @@ static void test_sync_merge(void)
close(timeline);
 }
 
+static void test_sync_merge_same(void)
+{
+   int in_fence[2];
+   int timeline;
+   int signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sync_merge(in_fence[0], in_fence[0]);
+
+   signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 0, "fence signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "fence did not signal\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -198,5 +222,8 @@ igt_main
 
igt_subtest("sync_merge")
test_sync_merge();
+
+   igt_subtest("sync_merge_same")
+   test_sync_merge_same();
 }
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 18/21] tests/sw_sync: Add igt_require check for sw_sync feature

[robert . foss]

From: Robert Foss 

Make sure that this test is skipped if the sw_sync feature is missing from
the host system.

Signed-off-by: Robert Foss 
---
 lib/sw_sync.c   | 1 +
 tests/sw_sync.c | 3 +++
 2 files changed, 4 insertions(+)

diff --git a/lib/sw_sync.c b/lib/sw_sync.c
index 38fe670..ac793ad 100644
--- a/lib/sw_sync.c
+++ b/lib/sw_sync.c
@@ -38,6 +38,7 @@
 #include 
 #include 
 
+#include "igt_debugfs.h"
 #include "sw_sync.h"
 #include "drmtest.h"
 #include "ioctl_wrappers.h"
diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index c885199..0aae4dc 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -708,6 +708,9 @@ static void test_sync_random_merge(void)
 
 igt_main
 {
+   igt_fixture
+   igt_require_sw_sync();
+
igt_subtest("alloc_timeline")
test_alloc_timeline();
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 16/21] tests/sw_sync: Add subtest test_timeline_closed_signaled

[robert . foss]

From: Robert Foss 

Add subtest test_timeline_closed_signaled that verifies that a signaled fence
stays signaled after its timeline has been closed.

Signed-off-by: Robert Foss 
---
 tests/sw_sync.c | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index f19eaa8..c885199 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -86,6 +86,21 @@ static void test_timeline_closed(void)
 "Failure waiting on unsignaled fence on closed 
timeline\n");
 }
 
+static void test_timeline_closed_signaled(void)
+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   sw_sync_timeline_inc(timeline, 1);
+   close(timeline);
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == 0,
+"Failure waiting on signaled fence for closed timeline\n");
+}
+
 static void test_alloc_merge_fence(void)
 {
int in_fence[2];
@@ -705,6 +720,9 @@ igt_main
igt_subtest("timeline_closed")
test_timeline_closed();
 
+   igt_subtest("timeline_closed_signaled")
+   test_timeline_closed_signaled();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 14/21] tests/sw_sync: Add subtest test_sync_expired_merge

[robert . foss]

From: Rafael Antognolli 

This test creates an already expired fence, then creates a merged fence
out of that expired one (passed twice to the merge operation), and
finally closes the merged fence. It shows that if the refcounts are
wrong on the original expired fence, it might get freed while still in
use. Usually a kernel panick will follow.

Signed-off-by: Rafael Antognolli 
Signed-off-by: Robert Foss 
---
 tests/sw_sync.c | 28 
 1 file changed, 28 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 4e52f48..65416ad 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -582,6 +582,31 @@ static void test_sync_multi_producer_single_consumer(void)
pthread_join(threads[i], NULL);
 }
 
+static void test_sync_expired_merge(void)
+{
+   int iterations = 1 << 20;
+   int timeline;
+   int i;
+   int fence_expired, fence_merged;
+
+   timeline = sw_sync_timeline_create();
+
+   sw_sync_timeline_inc(timeline, 100);
+   fence_expired = sw_sync_fence_create(timeline, 1);
+   fence_merged = sync_merge(fence_expired, fence_expired);
+   close(fence_merged);
+
+   for (i = 0; i < iterations; i++) {
+   int fence = sync_merge(fence_expired, fence_expired);
+
+   igt_assert_f(sync_wait(fence, -1) == 0,
+"Failure waiting on fence\n");
+   close(fence);
+   }
+
+   close(fence_expired);
+}
+
 static void test_sync_random_merge(void)
 {
int i, size, ret;
@@ -687,6 +712,9 @@ igt_main
igt_subtest("sync_multi_producer_single_consumer")
test_sync_multi_producer_single_consumer();
 
+   igt_subtest("sync_expired_merge")
+   test_sync_expired_merge();
+
igt_subtest("sync_random_merge")
test_sync_random_merge();
 }
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 17/21] lib/sw_sync: Add igt_require_sw_sync to enable skipping on no sw_sync support

[robert . foss]

From: Robert Foss 

Add igt_require_sw_sync to provide tests to skip if sw_sync support isn't
available on the host machine.

Signed-off-by: Robert Foss 
---
 lib/sw_sync.c | 22 ++
 lib/sw_sync.h |  1 +
 2 files changed, 23 insertions(+)

diff --git a/lib/sw_sync.c b/lib/sw_sync.c
index 862f8c4..38fe670 100644
--- a/lib/sw_sync.c
+++ b/lib/sw_sync.c
@@ -197,3 +197,25 @@ int sync_fence_count_status(int fd, int status)
igt_assert(count >= 0);
return count;
 }
+
+static bool kernel_has_sw_sync(void)
+{
+   bool err;
+
+   igt_ignore_warn(system("/sbin/modprobe -s r sw_sync"));
+
+   err = false;
+   if (access(DEVFS_SW_SYNC, R_OK | W_OK) < 0) {
+   char buf[128];
+
+   snprintf(buf, sizeof(buf), "%s/sw_sync", igt_debugfs_mount());
+   err = access(DEBUGFS_SW_SYNC, R_OK | W_OK) < 0;
+   }
+
+   return !err;
+}
+
+void igt_require_sw_sync(void)
+{
+   igt_require(kernel_has_sw_sync());
+}
diff --git a/lib/sw_sync.h b/lib/sw_sync.h
index 1f47b29..0bbe73c 100644
--- a/lib/sw_sync.h
+++ b/lib/sw_sync.h
@@ -43,6 +43,7 @@ int sync_merge(int fd1, int fd2);
 int sync_wait(int fence, int timeout);
 int sync_fence_count(int fd);
 int sync_fence_count_status(int fd, int status);
+void igt_require_sw_sync(void);
 
 #endif
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 21/21] tests/sw_sync: Add subtest test_sync_busy_unixsocket

[robert . foss]

From: Robert Foss 

Add subtest test_sync_busy_fork which increments the timeline in a forked child
process, where the timeline fd has been sent through a UNIX socket.

Signed-off-by: Robert Foss 
---
 tests/sw_sync.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 440c1bf..f7c51c4 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -30,6 +30,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 #include 
 
 #include "sw_sync.h"
@@ -155,6 +157,104 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_busy_fork_unixsocket(void)
+{
+   int fence, ret;
+   int timeline;
+   int skip = 0;
+   int sv[2];
+
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   if (socketpair(AF_UNIX, SOCK_DGRAM, 0, sv) != 0) {
+   skip = 1;
+   goto out;
+   }
+
+   switch (fork()) {
+   case 0:
+   {
+   /* Child process */
+   int socket = sv[1];
+   int socket_timeline;
+   struct msghdr msg = {0};
+   struct cmsghdr *cmsg;
+   unsigned char *data;
+   char m_buffer[256];
+   char c_buffer[256];
+   struct iovec io = { .iov_base = m_buffer, .iov_len = 
sizeof(m_buffer) };
+   close(sv[0]);
+
+   msg.msg_iov = 
+   msg.msg_iovlen = 1;
+   msg.msg_control = c_buffer;
+   msg.msg_controllen = sizeof(c_buffer);
+
+   if (recvmsg(socket, , 0) < 0)
+   _Exit(1);
+
+   cmsg = CMSG_FIRSTHDR();
+   data = CMSG_DATA(cmsg);
+   socket_timeline = *((int *) data);
+
+   /* Advance timeline from 0 -> 1 */
+   sw_sync_timeline_inc(socket_timeline, 1);
+
+   _Exit(0);
+   break;
+   }
+   case -1:
+   {
+   /* Failed fork */
+   skip = 1;
+   break;
+   }
+   default:
+   {
+   /* Parent process */
+   int socket = sv[0];
+   struct cmsghdr *cmsg;
+   struct iovec io = { .iov_base = (char *)"ABC", .iov_len = 3 };
+   struct msghdr msg = { 0 };
+   char buf[CMSG_SPACE(sizeof(timeline))];
+   memset(buf, '\0', sizeof(buf));
+   close(sv[1]);
+
+   msg.msg_iov = 
+   msg.msg_iovlen = 1;
+   msg.msg_control = buf;
+   msg.msg_controllen = sizeof(buf);
+
+   cmsg = CMSG_FIRSTHDR();
+   cmsg->cmsg_level = SOL_SOCKET;
+   cmsg->cmsg_type = SCM_RIGHTS;
+   cmsg->cmsg_len = CMSG_LEN(sizeof(timeline));
+
+   *((int *) CMSG_DATA(cmsg)) = timeline;
+   msg.msg_controllen = cmsg->cmsg_len;
+
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Fence signaled (it 
should not have been signalled yet)\n");
+
+   if (sendmsg(socket, , 0) < 0) {
+   skip = 1;
+   goto out;
+   }
+
+   ret = sync_wait(fence, 2*1000);
+   igt_assert_f(ret == 0, "Fence not signaled (timeline value 1 
fence seqno 1)\n");
+   break;
+   }
+   }
+
+out:
+   close(fence);
+   close(timeline);
+   igt_require(!skip);
+}
+
 static void test_sync_busy_fork(void)
 {
int fence, ret;
@@ -809,6 +909,9 @@ igt_main
igt_subtest("sync_busy_fork")
test_sync_busy_fork();
 
+   igt_subtest("sync_busy_fork_unixsocket")
+   test_sync_busy_fork_unixsocket();
+
igt_subtest("sync_merge_invalid")
test_sync_merge_invalid();
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 11/21] tests/sw_sync: Add subtest test_sync_random_merge

[robert . foss]

From: Robert Foss 

This subtest verifies that creating many timelines and merging random fences
from each timeline with eachother results in merged fences that are fully
functional.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 73 +
 1 file changed, 73 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index db182eb..d59adb4 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -383,6 +383,76 @@ static void test_sync_multi_consumer_producer(void)
igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
 }
 
+static void test_sync_random_merge(void)
+{
+   int i, size, ret;
+   const int nbr_timeline = 32;
+   const int nbr_merge = 1024;
+   int fence_map[nbr_timeline];
+   int timeline_arr[nbr_timeline];
+   int fence, tmpfence, merged;
+   int timeline, timeline_offset, sync_pt;
+
+   srand(time(NULL));
+
+   for (i = 0; i < nbr_timeline; i++) {
+   timeline_arr[i] = sw_sync_timeline_create();
+   fence_map[i] = -1;
+   }
+
+   sync_pt = rand();
+   fence = sw_sync_fence_create(timeline_arr[0], sync_pt);
+
+   fence_map[0] = sync_pt;
+
+   /* Randomly create syncpoints out of a fixed set of timelines,
+* and merge them together.
+*/
+   for (i = 0; i < nbr_merge; i++) {
+   /* Generate syncpoint. */
+   timeline_offset = rand() % nbr_timeline;
+   timeline = timeline_arr[timeline_offset];
+   sync_pt = rand();
+
+   /* Keep track of the latest sync_pt in each timeline. */
+   if (fence_map[timeline_offset] == -1)
+   fence_map[timeline_offset] = sync_pt;
+   else if (fence_map[timeline_offset] < sync_pt)
+   fence_map[timeline_offset] = sync_pt;
+
+   /* Merge. */
+   tmpfence = sw_sync_fence_create(timeline, sync_pt);
+   merged = sync_merge(tmpfence, fence);
+   close(tmpfence);
+   close(fence);
+   fence = merged;
+   }
+
+   size = 0;
+   for (i = 0; i < nbr_timeline; i++)
+   if (fence_map[i] != -1)
+   size++;
+
+   /* Trigger the merged fence. */
+   for (i = 0; i < nbr_timeline; i++) {
+   if (fence_map[i] != -1) {
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME,
+   "Failure waiting on fence until timeout\n");
+   /* Increment the timeline to the last sync_pt */
+   sw_sync_timeline_inc(timeline_arr[i], fence_map[i]);
+   }
+   }
+
+   /* Check that the fence is triggered. */
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == 0, "Failure triggering fence\n");
+
+   close(fence);
+   for (i = 0; i < nbr_timeline; i++)
+   close(timeline_arr[i]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -411,5 +481,8 @@ igt_main
 
igt_subtest("sync_multi_consumer_producer")
test_sync_multi_consumer_producer();
+
+   igt_subtest("sync_random_merge")
+   test_sync_random_merge();
 }
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 05/21] tests/sw_sync: Add subtest test_alloc_merge_fence

[robert . foss]

From: Robert Foss 

This subtest verifies that merging two fences works in the simples possible
case.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 23 +++
 1 file changed, 23 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 75bd471..ecc75ca 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -61,6 +61,26 @@ static void test_alloc_fence_invalid_timeline(void)
igt_assert(__sw_sync_fence_create(-1, 0) < 0);
 }
 
+static void test_alloc_merge_fence(void)
+{
+   int in_fence[2];
+   int fence_merge;
+   int timeline[2];
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 1);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 1);
+   fence_merge = sync_merge(in_fence[1], in_fence[0]);
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -71,5 +91,8 @@ igt_main
 
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
+
+   igt_subtest("alloc_merge_fence")
+   test_alloc_merge_fence();
 }
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 15/21] tests/sw_sync: Add subtest test_timeline_closed

[robert . foss]

From: Robert Foss 

This subtest verifies that the fences of a timeline are not signalled when
a timelne is closed.

Signed-off-by: Robert Foss 
---
 tests/sw_sync.c | 17 +
 1 file changed, 17 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 65416ad..f19eaa8 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -72,6 +72,20 @@ static void test_alloc_fence_invalid_timeline(void)
igt_assert(__sw_sync_fence_create(-1, 0) < 0);
 }
 
+static void test_timeline_closed(void)
+{
+   int fence, ret;
+   int timeline;
+
+   timeline = sw_sync_timeline_create();
+   fence = sw_sync_fence_create(timeline, 1);
+
+   close(timeline);
+   ret = sync_wait(fence, 0);
+   igt_assert_f(ret == -1 && errno == ETIME,
+"Failure waiting on unsignaled fence on closed 
timeline\n");
+}
+
 static void test_alloc_merge_fence(void)
 {
int in_fence[2];
@@ -688,6 +702,9 @@ igt_main
igt_subtest("alloc_fence_invalid_timeline")
test_alloc_fence_invalid_timeline();
 
+   igt_subtest("timeline_closed")
+   test_timeline_closed();
+
igt_subtest("alloc_merge_fence")
test_alloc_merge_fence();
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 07/21] tests/sw_sync: Add subtest test_sync_merge

[robert . foss]

From: Robert Foss 

Add subtest test_sync_merge that tests merging fences and the validity of the
resulting merged fence.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 67 +
 1 file changed, 67 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 9667b93..528be4d 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -115,6 +115,70 @@ static void test_sync_busy(void)
close(timeline);
 }
 
+static void test_sync_merge(void)
+{
+   int in_fence[3];
+   int fence_merge;
+   int timeline;
+   int active, signaled;
+
+   timeline = sw_sync_timeline_create();
+   in_fence[0] = sw_sync_fence_create(timeline, 1);
+   in_fence[1] = sw_sync_fence_create(timeline, 2);
+   in_fence[2] = sw_sync_fence_create(timeline, 3);
+
+   fence_merge = sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sync_merge(in_fence[2], fence_merge);
+
+   /* confirm all fences have one active point (even d) */
+   active = sync_fence_count_status(in_fence[0],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[0] has too many active fences\n");
+   active = sync_fence_count_status(in_fence[1],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[1] has too many active fences\n");
+   active = sync_fence_count_status(in_fence[2],
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "in_fence[2] has too many active fences\n");
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 1, "fence_merge has too many active fences\n");
+
+   /* confirm that fence_merge is not signaled until the max of fence 
0,1,2 */
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[0],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[0] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[1],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(signaled == 1, "in_fence[1] did not signal\n");
+   igt_assert_f(active == 1, "fence_merge signaled too early\n");
+
+   sw_sync_timeline_inc(timeline, 1);
+   signaled = sync_fence_count_status(in_fence[2],
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(signaled == 1, "in_fence[2] did not signal\n");
+   signaled = sync_fence_count_status(fence_merge,
+  SW_SYNC_FENCE_STATUS_SIGNALED);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 0 && signaled == 1,
+"fence_merge did not signal\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline);
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -131,5 +195,8 @@ igt_main
 
igt_subtest("sync_busy")
test_sync_busy();
+
+   igt_subtest("sync_merge")
+   test_sync_merge();
 }
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 09/21] tests/sw_sync: Add subtest test_sync_multi_consumer

[robert . foss]

From: Robert Foss 

This subtest verifies the access ordering of multiple consumer threads.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 103 
 1 file changed, 103 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index 51aa025..833ee07 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -27,6 +27,8 @@
  *Robert Foss 
  */
 
+#include 
+#include 
 #include 
 #include 
 
@@ -36,6 +38,15 @@
 
 IGT_TEST_DESCRIPTION("Test SW Sync Framework");
 
+typedef struct {
+   int timeline;
+   uint32_t thread_id;
+   uint32_t nbr_threads;
+   uint32_t nbr_iterations;
+   volatile uint32_t * volatile counter;
+   sem_t *sem;
+} data_t;
+
 static void test_alloc_timeline(void)
 {
int timeline;
@@ -203,6 +214,95 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void * test_sync_multi_consumer_thread(void *arg)
+{
+   data_t *data = arg;
+   int thread_id = data->thread_id;
+   int nbr_threads = data->nbr_threads;
+   int timeline = data->timeline;
+   int iterations = data->nbr_iterations;
+   int ret, i;
+
+   for (i = 0; i < iterations; i++) {
+   int next_point = i * nbr_threads + thread_id;
+   int fence = sw_sync_fence_create(timeline, next_point);
+
+   ret = sync_wait(fence, 1000);
+   if (ret == -1)
+   {
+   return (void *) 1;
+   }
+
+   if (*(data->counter) != next_point)
+   {
+   return (void *) 1;
+   }
+
+   sem_post(data->sem);
+   close(fence);
+   }
+   return NULL;
+}
+
+static void test_sync_multi_consumer(void)
+{
+   const uint32_t nbr_threads = 8;
+   const uint32_t nbr_iterations = 1 << 14;
+   data_t data_arr[nbr_threads];
+   pthread_t thread_arr[nbr_threads];
+   sem_t sem;
+   int timeline;
+   volatile uint32_t counter = 0;
+   uintptr_t thread_ret = 0;
+   data_t data;
+   int i, ret;
+
+   sem_init(, 0, 0);
+   timeline = sw_sync_timeline_create();
+
+   data.nbr_iterations = nbr_iterations;
+   data.nbr_threads = nbr_threads;
+   data.counter = 
+   data.timeline = timeline;
+   data.sem = 
+
+   /* Start sync threads. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   data_arr[i] = data;
+   data_arr[i].thread_id = i;
+   ret = pthread_create(_arr[i], NULL,
+test_sync_multi_consumer_thread,
+(void *) &(data_arr[i]));
+   igt_assert_eq(ret, 0);
+   }
+
+   /* Produce 'content'. */
+   for (i = 0; i < nbr_threads * nbr_iterations; i++)
+   {
+   sem_wait();
+
+   counter++;
+   sw_sync_timeline_inc(timeline, 1);
+   }
+
+   /* Wait for threads to complete. */
+   for (i = 0; i < nbr_threads; i++)
+   {
+   uintptr_t local_thread_ret;
+   pthread_join(thread_arr[i], (void **)_thread_ret);
+   thread_ret |= local_thread_ret;
+   }
+
+   close(timeline);
+   sem_destroy();
+
+   igt_assert_f(counter == nbr_threads * nbr_iterations,
+"Counter has unexpected value.\n");
+
+   igt_assert_f(thread_ret == 0, "A sync thread reported failure.\n");
+}
+
 igt_main
 {
igt_subtest("alloc_timeline")
@@ -225,5 +325,8 @@ igt_main
 
igt_subtest("sync_merge_same")
test_sync_merge_same();
+
+   igt_subtest("sync_multi_consumer")
+   test_sync_multi_consumer();
 }
 
-- 
2.10.2

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

[Intel-gfx] [PATCH i-g-t v6 12/21] tests/sw_sync: Add subtest test_sync_multi_timeline_wait

[robert . foss]

From: Robert Foss 

This subtest verifies that waiting, timing out on a wait and that counting
fences in various states works.

Signed-off-by: Robert Foss 
Reviewed-by: Eric Engestrom 
---
 tests/sw_sync.c | 66 +
 1 file changed, 66 insertions(+)

diff --git a/tests/sw_sync.c b/tests/sw_sync.c
index d59adb4..99bd3d9 100644
--- a/tests/sw_sync.c
+++ b/tests/sw_sync.c
@@ -214,6 +214,69 @@ static void test_sync_merge_same(void)
close(timeline);
 }
 
+static void test_sync_multi_timeline_wait(void)
+{
+   int timeline[3];
+   int in_fence[3];
+   int fence_merge;
+   int active, signaled, ret;
+
+   timeline[0] = sw_sync_timeline_create();
+   timeline[1] = sw_sync_timeline_create();
+   timeline[2] = sw_sync_timeline_create();
+
+   in_fence[0] = sw_sync_fence_create(timeline[0], 5);
+   in_fence[1] = sw_sync_fence_create(timeline[1], 5);
+   in_fence[2] = sw_sync_fence_create(timeline[2], 5);
+
+   fence_merge = sync_merge(in_fence[0], in_fence[1]);
+   fence_merge = sync_merge(in_fence[2], fence_merge);
+
+   /* Confirm fence isn't signaled */
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   igt_assert_f(active == 3, "Fence signaled too early\n");
+
+   ret = sync_wait(fence_merge, 0);
+   igt_assert_f(ret == -1 && errno == ETIME, "Failure waiting on fence 
until timeout\n");
+
+   sw_sync_timeline_inc(timeline[0], 5);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 2 && signaled == 1,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[1], 5);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 1 && signaled == 2,
+   "Fence did not signal properly\n");
+
+   sw_sync_timeline_inc(timeline[2], 5);
+   active = sync_fence_count_status(fence_merge,
+   SW_SYNC_FENCE_STATUS_ACTIVE);
+   signaled = sync_fence_count_status(fence_merge,
+ SW_SYNC_FENCE_STATUS_SIGNALED);
+   igt_assert_f(active == 0 && signaled == 3,
+"Fence did not signal properly\n");
+
+   /* confirm you can successfully wait */
+   ret = sync_wait(fence_merge, 100);
+   igt_assert_f(ret == 0, "Failure waiting on signaled fence\n");
+
+   close(in_fence[0]);
+   close(in_fence[1]);
+   close(in_fence[2]);
+   close(fence_merge);
+   close(timeline[0]);
+   close(timeline[1]);
+   close(timeline[2]);
+}
+
 static void * test_sync_multi_consumer_thread(void *arg)
 {
data_t *data = arg;
@@ -476,6 +539,9 @@ igt_main
igt_subtest("sync_merge_same")
test_sync_merge_same();
 
+   igt_subtest("sync_multi_timeline_wait")
+   test_sync_multi_timeline_wait();
+
igt_subtest("sync_multi_consumer")
test_sync_multi_consumer();
 
-- 
2.10.2

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