Re: [PATCH 1/9] drm/ast: Handle configuration without P2A bridge

[Benjamin Herrenschmidt]

On Fri, 2017-02-17 at 16:32 +1100, Benjamin Herrenschmidt wrote:

Make this

From: Russell Currey 

Git ate it when I amended (citool bug) and I forgot to fix it up.

> The ast driver configures a window to enable access into BMC
> memory space in order to read some configuration registers.
> 
> If this window is disabled, which it can be from the BMC side,
> the ast driver can't function.
> 
> Closing this window is a necessity for security if a machine's
> host side and BMC side are controlled by different parties;
> i.e. a cloud provider offering machines "bare metal".
> 
> A recent patch went in to try to check if that window is open
> but it does so by trying to access the registers in question
> and testing if the result is 0x.
> 
> This method will trigger a PCIe error when the window is closed
> which on some systems will be fatal (it will trigger an EEH
> for example on POWER which will take out the device).
> 
> This patch improves this in two ways:
> 
>  - First, if the firmware has put properties in the device-tree
> containing the relevant configuration information, we use these.
> 
>  - Otherwise, a bit in one of the SCU scratch registers (which
> are readable via the VGA register space and writeable by the BMC)
> will indicate if the BMC has closed the window. This bit has been
> defined by Y.C Chen from Aspeed.
> 
> If the window is closed and the configuration isn't available from
> the device-tree, some sane defaults are used. Those defaults are
> hopefully sufficient for standard video modes used on a server.
> 
> Signed-off-by: Russell Currey 
> Signed-off-by: Benjamin Herrenschmidt 
> --
> 
> v2. [BenH]
> - Reworked on top of Aspeed P2A patch
> - Cleanup overall detection via a "config_mode" and log the
>   selected mode for diagnostics purposes
> - Add a property for the SCU straps
> 
> v3. [BenH]
> - Moved the config mode detection to a separate functionn
> - Add reading of SCU 0x40 D[12] to detect the window is
>   closed as to not trigger a bus error by just "trying".
>   (change provided by Y.C. Chen)
> ---
>  drivers/gpu/drm/ast/ast_drv.h  |   6 +-
>  drivers/gpu/drm/ast/ast_main.c | 223 +
> 
>  drivers/gpu/drm/ast/ast_post.c |   7 +-
>  3 files changed, 141 insertions(+), 95 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.h
> b/drivers/gpu/drm/ast/ast_drv.h
> index 7abda94..3bedcf7 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -113,7 +113,11 @@ struct ast_private {
>   struct ttm_bo_kmap_obj cache_kmap;
>   int next_cursor;
>   bool support_wide_screen;
> - bool DisableP2A;
> + enum {
> + ast_use_p2a,
> + ast_use_dt,
> + ast_use_defaults
> + } config_mode;
>  
>   enum ast_tx_chip tx_chip_type;
>   u8 dp501_maxclk;
> diff --git a/drivers/gpu/drm/ast/ast_main.c
> b/drivers/gpu/drm/ast/ast_main.c
> index 533e762..823c68f 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -62,13 +62,58 @@ uint8_t ast_get_index_reg_mask(struct ast_private
> *ast,
>   return ret;
>  }
>  
> +static void ast_detect_config_mode(struct drm_device *dev, u32
> *scu_rev)
> +{
> + struct device_node *np = dev->pdev->dev.of_node;
> + struct ast_private *ast = dev->dev_private;
> + uint32_t data, jreg;
> +
> + /* Check if we have device-tree properties */
> + if (np && !of_property_read_u32(np, "ast,scu-revision-id",
> scu_rev)) {
> + /* We do, disable P2A access */
> + ast->config_mode = ast_use_dt;
> + DRM_INFO("Using device-tree for configuration\n");
> + return;
> + }
> +
> + /*
> +  * The BMC will set SCU 0x40 D[12] to 1 if the P2 bridge
> +  * is disabled
> +  */
> + jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd1,
> 0xff);
> + if (!(jreg & 0x10)) {
> + /* Double check it's actually working */
> + data = ast_read32(ast, 0xf004);
> + if (data != 0x) {
> + /* P2A works, grab silicon revision */
> + ast->config_mode = ast_use_p2a;
> +
> + DRM_INFO("Using P2A bridge for
> configuration\n");
> +
> + /* Read SCU7c (silicon revision register) */
> + ast_write32(ast, 0xf004, 0x1e6e);
> + ast_write32(ast, 0xf000, 0x1);
> + *scu_rev = ast_read32(ast, 0x1207c);
> + return;
> + }
> + }
> +
> + DRM_INFO("P2A bridge disabled, using default
> configuration\n");
> + ast->config_mode = ast_use_defaults;
> + *scu_rev = 0x;
> +}
>  
>  static int ast_detect_chip(struct drm_device *dev, bool *need_post)
>  {
>   struct ast_private *ast = dev->dev_private;
> - uint32_t 

[PATCH 17/35] drivers/gpu: Convert remaining uses of pr_warning to pr_warn

[Joe Perches]

To enable eventual removal of pr_warning

This makes pr_warn use consistent for drivers/gpu

Prior to this patch, there were 15 uses of pr_warning and
20 uses of pr_warn in drivers/gpu

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c |  2 +-
 drivers/gpu/drm/amd/powerplay/inc/pp_debug.h |  2 +-
 drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c  |  4 ++--
 drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c   | 14 +++---
 drivers/gpu/drm/amd/powerplay/smumgr/polaris10_smc.c |  4 ++--
 drivers/gpu/drm/amd/powerplay/smumgr/tonga_smc.c |  4 ++--
 6 files changed, 15 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c 
b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
index b1de9e8ccdbc..83266408634e 100644
--- a/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
+++ b/drivers/gpu/drm/amd/powerplay/hwmgr/smu7_hwmgr.c
@@ -1535,7 +1535,7 @@ static int smu7_get_evv_voltages(struct pp_hwmgr *hwmgr)
if (vddc >= 2000 || vddc == 0)
return -EINVAL;
} else {
-   pr_warning("failed to retrieving EVV 
voltage!\n");
+   pr_warn("failed to retrieving EVV 
voltage!\n");
continue;
}
 
diff --git a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h 
b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
index 072880130cfb..f3f9ebb631a5 100644
--- a/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
+++ b/drivers/gpu/drm/amd/powerplay/inc/pp_debug.h
@@ -37,7 +37,7 @@
 #define PP_ASSERT_WITH_CODE(cond, msg, code)   \
do {\
if (!(cond)) {  \
-   pr_warning("%s\n", msg);\
+   pr_warn("%s\n", msg);   \
code;   \
}   \
} while (0)
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
index 0f7a77b7312e..5450f5ef8e89 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/fiji_smc.c
@@ -2131,7 +2131,7 @@ uint32_t fiji_get_offsetof(uint32_t type, uint32_t member)
return offsetof(SMU73_Discrete_DpmTable, 
LowSclkInterruptThreshold);
}
}
-   pr_warning("can't get the offset of type %x member %x\n", type, member);
+   pr_warn("can't get the offset of type %x member %x\n", type, member);
return 0;
 }
 
@@ -2156,7 +2156,7 @@ uint32_t fiji_get_mac_definition(uint32_t value)
return SMU73_MAX_LEVELS_MVDD;
}
 
-   pr_warning("can't get the mac of %x\n", value);
+   pr_warn("can't get the mac of %x\n", value);
return 0;
 }
 
diff --git a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c 
b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
index ad82161df831..51adf04ab4b3 100644
--- a/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
+++ b/drivers/gpu/drm/amd/powerplay/smumgr/iceland_smc.c
@@ -122,7 +122,7 @@ static void iceland_initialize_power_tune_defaults(struct 
pp_hwmgr *hwmgr)
break;
default:
smu_data->power_tune_defaults = _iceland;
-   pr_warning("Unknown V.I. Device ID.\n");
+   pr_warn("Unknown V.I. Device ID.\n");
break;
}
return;
@@ -378,7 +378,7 @@ static int iceland_get_std_voltage_value_sidd(struct 
pp_hwmgr *hwmgr,
return -EINVAL);
 
if (NULL == hwmgr->dyn_state.cac_leakage_table) {
-   pr_warning("CAC Leakage Table does not exist, using vddc.\n");
+   pr_warn("CAC Leakage Table does not exist, using vddc.\n");
return 0;
}
 
@@ -394,7 +394,7 @@ static int iceland_get_std_voltage_value_sidd(struct 
pp_hwmgr *hwmgr,
*lo = 
hwmgr->dyn_state.cac_leakage_table->entries[v_index].Vddc * VOLTAGE_SCALE;
*hi = 
(uint16_t)(hwmgr->dyn_state.cac_leakage_table->entries[v_index].Leakage * 
VOLTAGE_SCALE);
} else {
-   pr_warning("Index from SCLK/VDDC Dependency 
Table exceeds the CAC Leakage Table index, using maximum index from CAC 
table.\n");
+   pr_warn("Index from SCLK/VDDC Dependency Table 
exceeds the CAC Leakage Table index, using maximum index from CAC table.\n");
*lo = 
hwmgr->dyn_state.cac_leakage_table->entries[hwmgr->dyn_state.cac_leakage_table->count
 - 1].Vddc * VOLTAGE_SCALE;
*hi = 

[PATCH 7/9] drm/ast: Rename ast_init_dram_2300 to ast_post_chip_2300

[Benjamin Herrenschmidt]

The function does more than initializing the DRAM and in turns
calls other functions to do the actual init. This will keeping
things more consistent with the upcoming AST2500 POST code.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/gpu/drm/ast/ast_post.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 33ea1ea..a36a544 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -31,7 +31,7 @@
 
 #include "ast_dram_tables.h"
 
-static void ast_init_dram_2300(struct drm_device *dev);
+static void ast_post_chip_2300(struct drm_device *dev);
 
 void ast_enable_vga(struct drm_device *dev)
 {
@@ -381,7 +381,7 @@ void ast_post_gpu(struct drm_device *dev)
 
if (ast->config_mode == ast_use_p2a) {
if (ast->chip == AST2300 || ast->chip == AST2400)
-   ast_init_dram_2300(dev);
+   ast_post_chip_2300(dev);
else
ast_init_dram_reg(dev);
 
@@ -1577,7 +1577,7 @@ static void ddr2_init(struct ast_private *ast, struct 
ast2300_dram_param *param)
 
 }
 
-static void ast_init_dram_2300(struct drm_device *dev)
+static void ast_post_chip_2300(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
struct ast2300_dram_param param;
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 9/9] drm/ast: Fixed vram size incorrect issue on POWER

[Benjamin Herrenschmidt]

From: "Y.C. Chen" 

The default value of VGA scratch may incorrect.
Should initial h/w before get vram info.

Signed-off-by: Y.C. Chen 
---
 drivers/gpu/drm/ast/ast_main.c | 6 +++---
 drivers/gpu/drm/ast/ast_post.c | 2 +-
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index f9128b9..839e456 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -502,6 +502,9 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
 
ast_detect_chip(dev, _post);
 
+   if (need_post)
+   ast_post_gpu(dev);
+
if (ast->chip != AST1180) {
ret = ast_get_dram_info(dev);
if (ret)
@@ -512,9 +515,6 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
 ast->dram_bus_width, ast->vram_size);
}
 
-   if (need_post)
-   ast_post_gpu(dev);
-
ret = ast_mm_init(ast);
if (ret)
goto out_free;
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 484138b..9f9 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -80,7 +80,7 @@ ast_set_def_ext_reg(struct drm_device *dev)
const u8 *ext_reg_info;
 
/* reset scratch */
-   for (i = 0x81; i <= 0x8f; i++)
+   for (i = 0x81; i <= 0x9f; i++)
ast_set_index_reg(ast, AST_IO_CRTC_PORT, i, 0x00);
 
if (ast->chip == AST2300 || ast->chip == AST2400 ||
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 6/9] drm/ast: Factor mmc_test code in POST code

[Benjamin Herrenschmidt]

There's a lot of duplication for what's essentially N copies of
the same loop, so factor it. The upcoming AST2500 POST code adds
more of this.

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/gpu/drm/ast/ast_post.c | 76 --
 1 file changed, 22 insertions(+), 54 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index 7197635..33ea1ea 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -445,85 +445,53 @@ static const u32 pattern[8] = {
0x7C61D253
 };
 
-static int mmc_test_burst(struct ast_private *ast, u32 datagen)
+static int mmc_test(struct ast_private *ast, u32 datagen, u8 test_ctl)
 {
u32 data, timeout;
 
ast_moutdwm(ast, 0x1e6e0070, 0x);
-   ast_moutdwm(ast, 0x1e6e0070, 0x00c1 | (datagen << 3));
+   ast_moutdwm(ast, 0x1e6e0070, (datagen << 3) | test_ctl);
timeout = 0;
do {
data = ast_mindwm(ast, 0x1e6e0070) & 0x3000;
if (data & 0x2000) {
-   return 0;
+   return -1;
}
if (++timeout > TIMEOUT) {
ast_moutdwm(ast, 0x1e6e0070, 0x);
-   return 0;
+   return -1;
}
} while (!data);
+   data = ast_mindwm(ast, 0x1e6e0078);
+   data = (data | (data >> 16)) & 0x;
ast_moutdwm(ast, 0x1e6e0070, 0x);
-   return 1;
+   return data;
 }
 
-static int mmc_test_burst2(struct ast_private *ast, u32 datagen)
+
+static int mmc_test_burst(struct ast_private *ast, u32 datagen)
 {
-   u32 data, timeout;
+   return mmc_test(ast, datagen, 0xc1);
+}
 
-   ast_moutdwm(ast, 0x1e6e0070, 0x);
-   ast_moutdwm(ast, 0x1e6e0070, 0x0041 | (datagen << 3));
-   timeout = 0;
-   do {
-   data = ast_mindwm(ast, 0x1e6e0070) & 0x1000;
-   if (++timeout > TIMEOUT) {
-   ast_moutdwm(ast, 0x1e6e0070, 0x0);
-   return -1;
-   }
-   } while (!data);
-   data = ast_mindwm(ast, 0x1e6e0078);
-   data = (data | (data >> 16)) & 0x;
-   ast_moutdwm(ast, 0x1e6e0070, 0x0);
-   return data;
+static int mmc_test_burst2(struct ast_private *ast, u32 datagen)
+{
+   return mmc_test(ast, datagen, 0x41);
 }
 
 static int mmc_test_single(struct ast_private *ast, u32 datagen)
 {
-   u32 data, timeout;
-
-   ast_moutdwm(ast, 0x1e6e0070, 0x);
-   ast_moutdwm(ast, 0x1e6e0070, 0x00c5 | (datagen << 3));
-   timeout = 0;
-   do {
-   data = ast_mindwm(ast, 0x1e6e0070) & 0x3000;
-   if (data & 0x2000)
-   return 0;
-   if (++timeout > TIMEOUT) {
-   ast_moutdwm(ast, 0x1e6e0070, 0x0);
-   return 0;
-   }
-   } while (!data);
-   ast_moutdwm(ast, 0x1e6e0070, 0x0);
-   return 1;
+   return mmc_test(ast, datagen, 0xc5);
 }
 
 static int mmc_test_single2(struct ast_private *ast, u32 datagen)
 {
-   u32 data, timeout;
+   return mmc_test(ast, datagen, 0x05);
+}
 
-   ast_moutdwm(ast, 0x1e6e0070, 0x);
-   ast_moutdwm(ast, 0x1e6e0070, 0x0005 | (datagen << 3));
-   timeout = 0;
-   do {
-   data = ast_mindwm(ast, 0x1e6e0070) & 0x1000;
-   if (++timeout > TIMEOUT) {
-   ast_moutdwm(ast, 0x1e6e0070, 0x0);
-   return -1;
-   }
-   } while (!data);
-   data = ast_mindwm(ast, 0x1e6e0078);
-   data = (data | (data >> 16)) & 0x;
-   ast_moutdwm(ast, 0x1e6e0070, 0x0);
-   return data;
+static int mmc_test_single_2500(struct ast_private *ast, u32 datagen)
+{
+   return mmc_test(ast, datagen, 0x85);
 }
 
 static int cbr_test(struct ast_private *ast)
@@ -603,9 +571,9 @@ static u32 cbr_scan2(struct ast_private *ast)
 
 static u32 cbr_test3(struct ast_private *ast)
 {
-   if (!mmc_test_burst(ast, 0))
+   if (mmc_test_burst(ast, 0) < 0)
return 0;
-   if (!mmc_test_single(ast, 0))
+   if (mmc_test_single(ast, 0) < 0)
return 0;
return 1;
 }
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 5/9] drm/ast: Base support for AST2500

[Benjamin Herrenschmidt]

From: "Y.C. Chen" 

Add detection and mode setting updates for AST2500 generation chip,
code originally from Aspeed and slightly reworked for coding style
mostly by Ben. This doesn't contain the BMC DRAM POST code which
is in a separate patch.

Signed-off-by: Y.C. Chen 
Signed-off-by: Benjamin Herrenschmidt 
---
---
 drivers/gpu/drm/ast/ast_drv.h|  2 ++
 drivers/gpu/drm/ast/ast_main.c   | 27 +--
 drivers/gpu/drm/ast/ast_mode.c   | 30 -
 drivers/gpu/drm/ast/ast_tables.h | 58 +---
 4 files changed, 99 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 3fd9d6e..d1c1d53 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -64,6 +64,7 @@ enum ast_chip {
AST2150,
AST2300,
AST2400,
+   AST2500,
AST1180,
 };
 
@@ -80,6 +81,7 @@ enum ast_tx_chip {
 #define AST_DRAM_1Gx32   3
 #define AST_DRAM_2Gx16   6
 #define AST_DRAM_4Gx16   7
+#define AST_DRAM_8Gx16   8
 
 struct ast_fbdev;
 
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index eb6ba3e..f9128b9 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -116,7 +116,10 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
ast->chip = AST1100;
DRM_INFO("AST 1180 detected\n");
} else {
-   if (dev->pdev->revision >= 0x30) {
+   if (dev->pdev->revision >= 0x40) {
+   ast->chip = AST2500;
+   DRM_INFO("AST 2500 detected\n");
+   } else if (dev->pdev->revision >= 0x30) {
ast->chip = AST2400;
DRM_INFO("AST 2400 detected\n");
} else if (dev->pdev->revision >= 0x20) {
@@ -184,6 +187,9 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
if (ast->chip == AST2400 &&
(scu_rev & 0x300) == 0x100) /* ast1400 */
ast->support_wide_screen = true;
+   if (ast->chip == AST2500 &&
+   scu_rev == 0x100)   /* ast2510 */
+   ast->support_wide_screen = true;
}
break;
}
@@ -287,7 +293,23 @@ static int ast_get_dram_info(struct drm_device *dev)
else
ast->dram_bus_width = 32;
 
-   if (ast->chip == AST2300 || ast->chip == AST2400) {
+   if (ast->chip == AST2500) {
+   switch (mcr_cfg & 0x03) {
+   case 0:
+   ast->dram_type = AST_DRAM_1Gx16;
+   break;
+   default:
+   case 1:
+   ast->dram_type = AST_DRAM_2Gx16;
+   break;
+   case 2:
+   ast->dram_type = AST_DRAM_4Gx16;
+   break;
+   case 3:
+   ast->dram_type = AST_DRAM_8Gx16;
+   break;
+   }
+   } else if (ast->chip == AST2300 || ast->chip == AST2400) {
switch (mcr_cfg & 0x03) {
case 0:
ast->dram_type = AST_DRAM_512Mx16;
@@ -510,6 +532,7 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
ast->chip == AST2200 ||
ast->chip == AST2300 ||
ast->chip == AST2400 ||
+   ast->chip == AST2500 ||
ast->chip == AST1180) {
dev->mode_config.max_width = 1920;
dev->mode_config.max_height = 2048;
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 1ff596e..e4db1c72 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -271,7 +271,11 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, struct 
drm_display_mode *mod
 {
struct ast_private *ast = crtc->dev->dev_private;
u8 jreg05 = 0, jreg07 = 0, jreg09 = 0, jregAC = 0, jregAD = 0, jregAE = 
0;
-   u16 temp;
+   u16 temp, precache = 0;
+
+   if ((ast->chip == AST2500) &&
+   (vbios_mode->enh_table->flags & AST2500PreCatchCRT))
+   precache = 40;
 
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x11, 0x7f, 0x00);
 
@@ -297,12 +301,12 @@ static void ast_set_crtc_reg(struct drm_crtc *crtc, 
struct drm_display_mode *mod
jregAD |= 0x01;  /* HBE D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x03, 0xE0, (temp & 
0x1f));
 
-   temp = (mode->crtc_hsync_start >> 3) - 1;
+   temp = ((mode->crtc_hsync_start-precache) >> 3) - 1;
if (temp & 0x100)
jregAC |= 0x40; /* HRS D[5] */
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0x04, 0x00, temp);
 
-   temp = 

[PATCH 2/9] drm/ast: const'ify mode setting tables

[Benjamin Herrenschmidt]

And fix some comment alignment & space/tabs while at it

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/gpu/drm/ast/ast_drv.h|   4 +-
 drivers/gpu/drm/ast/ast_mode.c   |   8 +--
 drivers/gpu/drm/ast/ast_tables.h | 106 +++
 3 files changed, 59 insertions(+), 59 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 3bedcf7..3fd9d6e 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -304,8 +304,8 @@ struct ast_vbios_dclk_info {
 };
 
 struct ast_vbios_mode_info {
-   struct ast_vbios_stdtable *std_table;
-   struct ast_vbios_enhtable *enh_table;
+   const struct ast_vbios_stdtable *std_table;
+   const struct ast_vbios_enhtable *enh_table;
 };
 
 extern int ast_mode_init(struct drm_device *dev);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index e26c98f..1ff596e 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -80,9 +80,9 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, 
struct drm_display_mo
 {
struct ast_private *ast = crtc->dev->dev_private;
u32 refresh_rate_index = 0, mode_id, color_index, refresh_rate;
+   const struct ast_vbios_enhtable *best = NULL;
u32 hborder, vborder;
bool check_sync;
-   struct ast_vbios_enhtable *best = NULL;
 
switch (crtc->primary->fb->bits_per_pixel) {
case 8:
@@ -146,7 +146,7 @@ static bool ast_get_vbios_mode_info(struct drm_crtc *crtc, 
struct drm_display_mo
refresh_rate = drm_mode_vrefresh(mode);
check_sync = vbios_mode->enh_table->flags & WideScreenMode;
do {
-   struct ast_vbios_enhtable *loop = vbios_mode->enh_table;
+   const struct ast_vbios_enhtable *loop = vbios_mode->enh_table;
 
while (loop->refresh_rate != 0xff) {
if ((check_sync) &&
@@ -225,7 +225,7 @@ static void ast_set_std_reg(struct drm_crtc *crtc, struct 
drm_display_mode *mode
struct ast_vbios_mode_info *vbios_mode)
 {
struct ast_private *ast = crtc->dev->dev_private;
-   struct ast_vbios_stdtable *stdtable;
+   const struct ast_vbios_stdtable *stdtable;
u32 i;
u8 jreg;
 
@@ -381,7 +381,7 @@ static void ast_set_dclk_reg(struct drm_device *dev, struct 
drm_display_mode *mo
 struct ast_vbios_mode_info *vbios_mode)
 {
struct ast_private *ast = dev->dev_private;
-   struct ast_vbios_dclk_info *clk_info;
+   const struct ast_vbios_dclk_info *clk_info;
 
clk_info = _table[vbios_mode->enh_table->dclk_index];
 
diff --git a/drivers/gpu/drm/ast/ast_tables.h b/drivers/gpu/drm/ast/ast_tables.h
index 3608d5a..a4ddf90 100644
--- a/drivers/gpu/drm/ast/ast_tables.h
+++ b/drivers/gpu/drm/ast/ast_tables.h
@@ -78,37 +78,37 @@
 #define VCLK97_75  0x19
 #define VCLK118_25 0x1A
 
-static struct ast_vbios_dclk_info dclk_table[] = {
-   {0x2C, 0xE7, 0x03}, /* 00: 
VCLK25_175   */
-   {0x95, 0x62, 0x03}, /* 01: 
VCLK28_322   */
-   {0x67, 0x63, 0x01}, /* 02: VCLK31_5 
*/
-   {0x76, 0x63, 0x01}, /* 03: VCLK36   
*/
-   {0xEE, 0x67, 0x01}, /* 04: VCLK40   
*/
-   {0x82, 0x62, 0x01}, /* 05: VCLK49_5 
*/
-   {0xC6, 0x64, 0x01}, /* 06: VCLK50   
*/
-   {0x94, 0x62, 0x01}, /* 07: 
VCLK56_25*/
-   {0x80, 0x64, 0x00}, /* 08: VCLK65   
*/
-   {0x7B, 0x63, 0x00}, /* 09: VCLK75   
*/
-   {0x67, 0x62, 0x00}, /* 0A: 
VCLK78_75*/
-   {0x7C, 0x62, 0x00}, /* 0B: VCLK94_5 
*/
-   {0x8E, 0x62, 0x00}, /* 0C: VCLK108  
*/
-   {0x85, 0x24, 0x00}, /* 0D: VCLK135  
*/
-   {0x67, 0x22, 0x00}, /* 0E: 
VCLK157_5*/
-   {0x6A, 0x22, 0x00}, /* 0F: VCLK162  
*/
-   {0x4d, 0x4c, 0x80}, /* 10: VCLK154  
*/
-   {0xa7, 0x78, 0x80}, /* 11: VCLK83.5 
*/
-   {0x28, 0x49, 0x80}, /* 12: 
VCLK106.5*/
-   {0x37, 0x49, 0x80}, /* 13: 
VCLK146.25   */
-   {0x1f, 0x45, 0x80}, /* 14: 
VCLK148.5 

[PATCH 1/9] drm/ast: Handle configuration without P2A bridge

[Benjamin Herrenschmidt]

The ast driver configures a window to enable access into BMC
memory space in order to read some configuration registers.

If this window is disabled, which it can be from the BMC side,
the ast driver can't function.

Closing this window is a necessity for security if a machine's
host side and BMC side are controlled by different parties;
i.e. a cloud provider offering machines "bare metal".

A recent patch went in to try to check if that window is open
but it does so by trying to access the registers in question
and testing if the result is 0x.

This method will trigger a PCIe error when the window is closed
which on some systems will be fatal (it will trigger an EEH
for example on POWER which will take out the device).

This patch improves this in two ways:

 - First, if the firmware has put properties in the device-tree
containing the relevant configuration information, we use these.

 - Otherwise, a bit in one of the SCU scratch registers (which
are readable via the VGA register space and writeable by the BMC)
will indicate if the BMC has closed the window. This bit has been
defined by Y.C Chen from Aspeed.

If the window is closed and the configuration isn't available from
the device-tree, some sane defaults are used. Those defaults are
hopefully sufficient for standard video modes used on a server.

Signed-off-by: Russell Currey 
Signed-off-by: Benjamin Herrenschmidt 
--

v2. [BenH]
- Reworked on top of Aspeed P2A patch
- Cleanup overall detection via a "config_mode" and log the
  selected mode for diagnostics purposes
- Add a property for the SCU straps

v3. [BenH]
- Moved the config mode detection to a separate functionn
- Add reading of SCU 0x40 D[12] to detect the window is
  closed as to not trigger a bus error by just "trying".
  (change provided by Y.C. Chen)
---
 drivers/gpu/drm/ast/ast_drv.h  |   6 +-
 drivers/gpu/drm/ast/ast_main.c | 223 +
 drivers/gpu/drm/ast/ast_post.c |   7 +-
 3 files changed, 141 insertions(+), 95 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_drv.h b/drivers/gpu/drm/ast/ast_drv.h
index 7abda94..3bedcf7 100644
--- a/drivers/gpu/drm/ast/ast_drv.h
+++ b/drivers/gpu/drm/ast/ast_drv.h
@@ -113,7 +113,11 @@ struct ast_private {
struct ttm_bo_kmap_obj cache_kmap;
int next_cursor;
bool support_wide_screen;
-   bool DisableP2A;
+   enum {
+   ast_use_p2a,
+   ast_use_dt,
+   ast_use_defaults
+   } config_mode;
 
enum ast_tx_chip tx_chip_type;
u8 dp501_maxclk;
diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 533e762..823c68f 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -62,13 +62,58 @@ uint8_t ast_get_index_reg_mask(struct ast_private *ast,
return ret;
 }
 
+static void ast_detect_config_mode(struct drm_device *dev, u32 *scu_rev)
+{
+   struct device_node *np = dev->pdev->dev.of_node;
+   struct ast_private *ast = dev->dev_private;
+   uint32_t data, jreg;
+
+   /* Check if we have device-tree properties */
+   if (np && !of_property_read_u32(np, "ast,scu-revision-id", scu_rev)) {
+   /* We do, disable P2A access */
+   ast->config_mode = ast_use_dt;
+   DRM_INFO("Using device-tree for configuration\n");
+   return;
+   }
+
+   /*
+* The BMC will set SCU 0x40 D[12] to 1 if the P2 bridge
+* is disabled
+*/
+   jreg = ast_get_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xd1, 0xff);
+   if (!(jreg & 0x10)) {
+   /* Double check it's actually working */
+   data = ast_read32(ast, 0xf004);
+   if (data != 0x) {
+   /* P2A works, grab silicon revision */
+   ast->config_mode = ast_use_p2a;
+
+   DRM_INFO("Using P2A bridge for configuration\n");
+
+   /* Read SCU7c (silicon revision register) */
+   ast_write32(ast, 0xf004, 0x1e6e);
+   ast_write32(ast, 0xf000, 0x1);
+   *scu_rev = ast_read32(ast, 0x1207c);
+   return;
+   }
+   }
+
+   DRM_INFO("P2A bridge disabled, using default configuration\n");
+   ast->config_mode = ast_use_defaults;
+   *scu_rev = 0x;
+}
 
 static int ast_detect_chip(struct drm_device *dev, bool *need_post)
 {
struct ast_private *ast = dev->dev_private;
-   uint32_t data, jreg;
+   uint32_t jreg, scu_rev;
+
ast_open_key(ast);
 
+   /* Find out whether P2A works or whether to use device-tree */
+   ast_detect_config_mode(dev, _rev);
+
+   /* Identify chipset */
if (dev->pdev->device == PCI_CHIP_AST1180) {
ast->chip = AST1100;
DRM_INFO("AST 1180 

[PATCH 8/9] drm/ast: POST code for the new AST2500

[Benjamin Herrenschmidt]

From: "Y.C. Chen" 

This is used when the BMC isn't running any code and thus has
to be initialized by the host.

The code originates from Aspeed (Y.C. Chen) and has been cleaned
up for coding style purposes by BenH.

Signed-off-by: Y.C. Chen 
Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/gpu/drm/ast/ast_dram_tables.h |  62 +
 drivers/gpu/drm/ast/ast_post.c| 410 +-
 2 files changed, 470 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_dram_tables.h 
b/drivers/gpu/drm/ast/ast_dram_tables.h
index cc04539..1d9c4e7 100644
--- a/drivers/gpu/drm/ast/ast_dram_tables.h
+++ b/drivers/gpu/drm/ast/ast_dram_tables.h
@@ -141,4 +141,66 @@ static const struct ast_dramstruct 
ast2100_dram_table_data[] = {
{ 0x, 0x },
 };
 
+/*
+ * AST2500 DRAM settings modules
+ */
+#define REGTBL_NUM   17
+#define REGIDX_010   0
+#define REGIDX_014   1
+#define REGIDX_018   2
+#define REGIDX_020   3
+#define REGIDX_024   4
+#define REGIDX_02C   5
+#define REGIDX_030   6
+#define REGIDX_214   7
+#define REGIDX_2E0   8
+#define REGIDX_2E4   9
+#define REGIDX_2E8   10
+#define REGIDX_2EC   11
+#define REGIDX_2F0   12
+#define REGIDX_2F4   13
+#define REGIDX_2F8   14
+#define REGIDX_RFC   15
+#define REGIDX_PLL   16
+
+static const u32 ast2500_ddr3_1600_timing_table[REGTBL_NUM] = {
+   0x64604D38,  /* 0x010 */
+   0x29690599,  /* 0x014 */
+   0x0300,  /* 0x018 */
+   0x,  /* 0x020 */
+   0x,  /* 0x024 */
+   0x02181E70,  /* 0x02C */
+   0x0040,  /* 0x030 */
+   0x0024,  /* 0x214 */
+   0x02001300,  /* 0x2E0 */
+   0x0EA0,  /* 0x2E4 */
+   0x000E001B,  /* 0x2E8 */
+   0x35B8C105,  /* 0x2EC */
+   0x08090408,  /* 0x2F0 */
+   0x9B000800,  /* 0x2F4 */
+   0x0E400A00,  /* 0x2F8 */
+   0x9971452F,  /* tRFC  */
+   0x71C1   /* PLL   */
+};
+
+static const u32 ast2500_ddr4_1600_timing_table[REGTBL_NUM] = {
+   0x63604E37,  /* 0x010 */
+   0xE97AFA99,  /* 0x014 */
+   0x00019000,  /* 0x018 */
+   0x0800,  /* 0x020 */
+   0x0400,  /* 0x024 */
+   0x0410,  /* 0x02C */
+   0x0101,  /* 0x030 */
+   0x0024,  /* 0x214 */
+   0x03002900,  /* 0x2E0 */
+   0x0EA0,  /* 0x2E4 */
+   0x000E001C,  /* 0x2E8 */
+   0x35B8C106,  /* 0x2EC */
+   0x08080607,  /* 0x2F0 */
+   0x9B000900,  /* 0x2F4 */
+   0x0E400A00,  /* 0x2F8 */
+   0x99714545,  /* tRFC  */
+   0x71C1   /* PLL   */
+};
+
 #endif
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index a36a544..484138b 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -32,6 +32,7 @@
 #include "ast_dram_tables.h"
 
 static void ast_post_chip_2300(struct drm_device *dev);
+static void ast_post_chip_2500(struct drm_device *dev);
 
 void ast_enable_vga(struct drm_device *dev)
 {
@@ -82,7 +83,8 @@ ast_set_def_ext_reg(struct drm_device *dev)
for (i = 0x81; i <= 0x8f; i++)
ast_set_index_reg(ast, AST_IO_CRTC_PORT, i, 0x00);
 
-   if (ast->chip == AST2300 || ast->chip == AST2400) {
+   if (ast->chip == AST2300 || ast->chip == AST2400 ||
+   ast->chip == AST2500) {
if (dev->pdev->revision >= 0x20)
ext_reg_info = extreginfo_ast2300;
else
@@ -106,7 +108,8 @@ ast_set_def_ext_reg(struct drm_device *dev)
 
/* Enable RAMDAC for A1 */
reg = 0x04;
-   if (ast->chip == AST2300 || ast->chip == AST2400)
+   if (ast->chip == AST2300 || ast->chip == AST2400 ||
+   ast->chip == AST2500)
reg |= 0x20;
ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xb6, 0xff, reg);
 }
@@ -380,6 +383,8 @@ void ast_post_gpu(struct drm_device *dev)
ast_set_def_ext_reg(dev);
 
if (ast->config_mode == ast_use_p2a) {
+   if (ast->chip == AST2500)
+   ast_post_chip_2500(dev);
if (ast->chip == AST2300 || ast->chip == AST2400)
ast_post_chip_2300(dev);
else
@@ -1628,3 +1633,404 @@ static void ast_post_chip_2300(struct drm_device 

[PATCH 4/9] drm/ast: Fix calculation of MCLK

[Benjamin Herrenschmidt]

Some braces were missing causing an incorrect calculation.

Y.C. Chen from Aspeed provided me with the right formula
which I tested on AST2400 and 2500.

The MCLK isn't currently used by the driver (it will eventually
to filter modes) so the issue isn't catastrophic.

Also make the printed value a bit more meaningful

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/gpu/drm/ast/ast_main.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index b593a53..eb6ba3e 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -341,7 +341,7 @@ static int ast_get_dram_info(struct drm_device *dev)
div = 0x1;
break;
}
-   ast->mclk = ref_pll * (num + 2) / (denum + 2) * (div * 1000);
+   ast->mclk = ref_pll * (num + 2) / ((denum + 2) * (div * 1000));
return 0;
 }
 
@@ -485,7 +485,9 @@ int ast_driver_load(struct drm_device *dev, unsigned long 
flags)
if (ret)
goto out_free;
ast->vram_size = ast_get_vram_info(dev);
-   DRM_INFO("dram %d %d %d %08x\n", ast->mclk, ast->dram_type, 
ast->dram_bus_width, ast->vram_size);
+   DRM_INFO("dram MCLK=%u Mhz type=%d bus_width=%d size=%08x\n",
+ast->mclk, ast->dram_type,
+ast->dram_bus_width, ast->vram_size);
}
 
if (need_post)
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/9] drm/ast: Remove spurrious include

[Benjamin Herrenschmidt]

Signed-off-by: Benjamin Herrenschmidt 
---
 drivers/gpu/drm/ast/ast_main.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index 823c68f..b593a53 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -32,8 +32,6 @@
 #include 
 #include 
 
-#include "ast_dram_tables.h"
-
 void ast_set_index_reg_mask(struct ast_private *ast,
uint32_t base, uint8_t index,
uint8_t mask, uint8_t val)
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99484] Crusader Kings 2 - Loading bars, siege bars, morale bars, etc. do not render correctly

[bugzilla-daemon]

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

--- Comment #7 from Timothy Arceri  ---
Bisected the llvm regression to a change in llvm 4.0

  commit f991e38d156c4c10c609ca8425a7c31b951ecbed
  Author: James Molloy 
  Date:   Thu Sep 1 10:44:35 2016 +

[SimplifyCFG] Change the algorithm in SinkThenElseCodeToEnd

However the output from R600_DEBUG=vs,fs is identical apart from the value of
code_size reported for one of the shaders.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/amdgpu: simplify reservation handling during buffer creation

[zhoucm1]

On 2017年02月16日 20:08, Christian König wrote:

Am 16.02.2017 um 12:39 schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initialization fails.

Actual deadlocks caused by the missing unlock should have been fixed
by "drm/ttm: never add BO that failed to validate to the LRU list",
superseding the flawed fix in commit 38fc4856ad98 ("drm/amdgpu: fix
a potential deadlock in amdgpu_bo_create_restricted()").

This change fixes remaining recursive locking errors that can be seen
with lock debugging enabled, and avoids the error of freeing a locked
mutex.

As an additional minor bonus, buffers created with resv == NULL and
the AMDGPU_GEM_CREATE_VRAM_CLEARED flag are now only added to the
global LRU list after the fill commands have been issued.

Fixes: 12a852219583 ("drm/amdgpu: improve 
AMDGPU_GEM_CREATE_VRAM_CLEARED handling (v2)")

Signed-off-by: Nicolai Hähnle 

Reviewed-by: Chunming Zhou  as well


---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 -
  1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c

index c2e57f7..4d0536d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -395,19 +395,10 @@ int amdgpu_bo_create_restricted(struct 
amdgpu_device *adev,

  amdgpu_fill_placement_to_bo(bo, placement);
  /* Kernel allocation are uninterruptible */
  -if (!resv) {
-bool locked;
-
-reservation_object_init(>tbo.ttm_resv);
-locked = ww_mutex_trylock(>tbo.ttm_resv.lock);
-WARN_ON(!locked);
-}
-
  initial_bytes_moved = atomic64_read(>num_bytes_moved);
-r = ttm_bo_init(>mman.bdev, >tbo, size, type,
->placement, page_align, !kernel, NULL,
-acc_size, sg, resv ? resv : >tbo.ttm_resv,
-_ttm_bo_destroy);
+r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+ >placement, page_align, !kernel, NULL,
+ acc_size, sg, resv, _ttm_bo_destroy);
  amdgpu_cs_report_moved_bytes(adev,
  atomic64_read(>num_bytes_moved) - initial_bytes_moved);
  @@ -433,7 +424,7 @@ int amdgpu_bo_create_restricted(struct 
amdgpu_device *adev,

  fence_put(fence);
  }
  if (!resv)
-ww_mutex_unlock(>tbo.resv->lock);
+ttm_bo_unreserve(>tbo);


You can just use amdgpu_bo_unreserve() here. With that fixed the whole 
set is Reviewed-by: Christian König .


Regards,
Christian.


  *bo_ptr = bo;
trace_amdgpu_bo_create(bo);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[git pull] drm fixes for v4.10-final

[Dave Airlie]

Hi Linus,

Just two last minute fixes, one for DP MST oopses and one for a radeon
regression.

Dave.

The following changes since commit 7089db84e356562f8ba737c29e472cc42d530dbc:

  Linux 4.10-rc8 (2017-02-12 13:03:20 -0800)

are available in the git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.10-final

for you to fetch changes up to 18a0de8816766a0da7537ef82156b5418ba5cd6e:

  Merge branch 'drm-fixes-4.10' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes (2017-02-17
11:13:17 +1000)


one i915, one radeon regression fix.


Dave Airlie (2):
  Merge tag 'drm-misc-fixes-2017-02-15' of
git://anongit.freedesktop.org/git/drm-misc into drm-fixes
  Merge branch 'drm-fixes-4.10' of
git://people.freedesktop.org/~agd5f/linux into drm-fixes

Michel Dänzer (1):
  drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor

Pierre-Louis Bossart (1):
  drm/dp/mst: fix kernel oops when turning off secondary monitor

 drivers/gpu/drm/drm_dp_mst_topology.c  | 2 +-
 drivers/gpu/drm/radeon/radeon_cursor.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] mxsfb fixes

[Dave Airlie]

On 16 February 2017 at 08:16, Marek Vasut  wrote:
> Hi,
>
> I collected the MXSFB fixes, based on top of airlied/drm-fixes:

At this stage I'd rather not give these to Linus, can you rebase them onto
drm-next, and resend, feel free to add stable cc's.

Fixes like this should really be getting to me sooner than rc8.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PULL] drm-misc-next-fixes, take 2

[Dave Airlie]

On 16 February 2017 at 19:49, Jani Nikula  wrote:
>
> Hi Dave, this one superseeds [1]. Better to flush out the single uapi
> fix for v4.11 now so it's not forgotten.

Looks like I had already pulled, I just reverted Maarten's patch on
top of drm-next.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #129669|0   |1
is obsolete||

--- Comment #29 from Michel Dänzer  ---
Comment on attachment 129669
  --> https://bugs.freedesktop.org/attachment.cgi?id=129669
apitrace of TW warhammer

That's just the apitrace terminal output. "The trace" refers to the
"/home/siyia/Native/Total War WARHAMMER/bin/TotalWarhammer.2.trace" file
generated by it. Note that it's likely too large to be attached here directly.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: ipu-v3: export ipu_csi_set_downsize

[Steve Longerbeam]

On 02/16/2017 03:40 AM, Philipp Zabel wrote:

This function will be used by the media drivers and needs to be exported
to allow them to be built as modules.

Reported-by: Russell King 
Fixes: 867341b95891 ("gpu: ipu-v3: add ipu_csi_set_downsize")
Signed-off-by: Philipp Zabel 
---
  drivers/gpu/ipu-v3/ipu-csi.c | 1 +
  1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 63c7292f427a2..24e12b87a0cbe 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -544,6 +544,7 @@ void ipu_csi_set_downsize(struct ipu_csi *csi, bool horiz, 
bool vert)
  
  	spin_unlock_irqrestore(>lock, flags);

  }
+EXPORT_SYMBOL_GPL(ipu_csi_set_downsize);
  
  void ipu_csi_set_test_generator(struct ipu_csi *csi, bool active,

u32 r_value, u32 g_value, u32 b_value,


Acked-by: Steve Longerbeam 

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] gpu: ipu-v3: Stop overwriting pdev->dev.of_node of child devices

[Steve Longerbeam]

On 02/16/2017 07:42 AM, Philipp Zabel wrote:

Setting dev->of_node changes the modalias and breaks module autoloading.
Since there is an of_node field in the platform data passed to child
devices, we don't even need this anymore.

Suggested-by: Russell King 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 97218af4fe75c..8368e6f766ee5 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1238,12 +1238,6 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
platform_device_put(pdev);
goto err_register;
}
-
-   /*
-* Set of_node only after calling platform_device_add. Otherwise
-* the platform:imx-ipuv3-crtc modalias won't be used.
-*/
-   pdev->dev.of_node = of_node;
}

return 0;




Acked-by: Steve Longerbeam 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ast: Fixed system hanged if disable P2A

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 06:34 +, YC Chen wrote:
> Hi Ben,
> This solution had been proved on x86 platform but I'm not sure if it
> works or not on POWER system .

It will only work on x86 platforms that haven't configured their
PCI Express in "hardened" mode where PCIe errors cause machine checks
or worse.

That said there isn't much I can do about it for now. So for POWER
platforms (and other platforms using device-tree), I have a patch
that will get the data from there.

>  If we added a definition in SOC scratch register to info drm driver
> the P2A is disabled by BMC fw, then drm driver will no need to check
> it by reading 0xf00x. Is it acceptable?

It would be better yes. Please send me a patch as I've reworked yours
already (see what i'll post tomorrow). Additionally, for future
silicon, please make all those info necessary to detect the VRAM
and the PLL available via the VGA registers so the backdoor isn't
needed.

For a full POST we can still require it of course but for the normal
case we should be able to get all the info needed via the normal VGA
register space.

> Here are the flow:
> If disable P2A in SOC scratch then ast->DisableP2A = true;
> Else if the value of 0xf00x is not 0x_ then ast->DisableP2A =
> false;

Cheers,
Ben.

> Regards,
> 
> Y.C. Chen
> 
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@au1.ibm.com] 
> Sent: Thursday, February 16, 2017 11:58 AM
> To: YC Chen ; dri-devel@lists.freedesktop.org
> Cc: airl...@redhat.com; e...@suse.com; Russell Currey  .com>
> Subject: Re: [PATCH] drm/ast: Fixed system hanged if disable P2A
> 
> On Thu, 2017-01-26 at 09:45 +0800, Y.C. Chen wrote:
> > From: "Y.C. Chen" 
> > 
> > The original ast driver will access some BMC configuration through
> > P2A 
> > bridge that can be disabled since AST2300 and after.
> > It will cause system hanged if P2A bridge is disabled.
> > Here is the update to fix it.
> 
> Will this work for us on POWER ? The problem we observed is that if
> P2A is disabled, the read from f00x seems to not respond, ie, we get
> a PCIe target abort on the MMIO, not 0x_. That trips our HW
> error detection mechanism "EEH" which will take out the entire
> device.
> 
> Russell (CC) proposed a patch a while ago that seems to have gone
> nowhere that allows the driver to retrieve all the information it
> needs from the device-tree on platforms that support it.
> 
> That allows us to grab the necessary info from firmware before the
> bridge is closed (or via some specific BMC interface we have if we
> close the bridge) and pass it to Linux.
> 
> Any reason that patch hasn't been merged ? Dave ?
> 
> Cheers,
> Ben.
> 
> 
> > Signed-off-by: Y.C. Chen 
> > ---
> >  drivers/gpu/drm/ast/ast_drv.h  |   1 +
> >  drivers/gpu/drm/ast/ast_main.c | 156 ++---
> > --
> > --
> >  drivers/gpu/drm/ast/ast_post.c |  18 +++--
> >  3 files changed, 96 insertions(+), 79 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ast/ast_drv.h 
> > b/drivers/gpu/drm/ast/ast_drv.h index 908011d..7abda94 100644
> > --- a/drivers/gpu/drm/ast/ast_drv.h
> > +++ b/drivers/gpu/drm/ast/ast_drv.h
> > @@ -113,6 +113,7 @@ struct ast_private {
> >     struct ttm_bo_kmap_obj cache_kmap;
> >     int next_cursor;
> >     bool support_wide_screen;
> > +   bool DisableP2A;
> >  
> >     enum ast_tx_chip tx_chip_type;
> >     u8 dp501_maxclk;
> > diff --git a/drivers/gpu/drm/ast/ast_main.c 
> > b/drivers/gpu/drm/ast/ast_main.c index f75c642..c374685 100644
> > --- a/drivers/gpu/drm/ast/ast_main.c
> > +++ b/drivers/gpu/drm/ast/ast_main.c
> > @@ -124,6 +124,11 @@ static int ast_detect_chip(struct drm_device 
> > *dev, bool *need_post)
> >     } else
> >     *need_post = false;
> >  
> > +   /* Check P2A Access */
> > +   ast->DisableP2A = true;
> > +   data = ast_read32(ast, 0xf004);
> > +   if (data != 0x) ast->DisableP2A = false;
> > +
> >     /* Check if we support wide screen */
> >     switch (ast->chip) {
> >     case AST1180:
> > @@ -140,15 +145,17 @@ static int ast_detect_chip(struct drm_device 
> > *dev, bool *need_post)
> >     ast->support_wide_screen = true;
> >     else {
> >     ast->support_wide_screen = false;
> > -   /* Read SCU7c (silicon revision register)
> > */
> > -   ast_write32(ast, 0xf004, 0x1e6e);
> > -   ast_write32(ast, 0xf000, 0x1);
> > -   data = ast_read32(ast, 0x1207c);
> > -   data &= 0x300;
> > -   if (ast->chip == AST2300 && data == 0x0)
> > /*
> > ast1300 */
> > -   ast->support_wide_screen = true;
> > -   if (ast->chip == AST2400 && data == 0x100)
> > /* ast1400 */
> > -   ast->support_wide_screen = true;
> > +   if (ast->DisableP2A == false) {
> > +  

Re: [Intel-gfx] [PATCH v3 7/8] drm: Connector helper function to release resources

[Lankhorst, Maarten]

Daniel Vetter schreef op di 14-02-2017 om 20:51 [+0100]:
> On Mon, Feb 13, 2017 at 10:26 PM, Pandiyan, Dhinakaran
>  wrote:
> > On Mon, 2017-02-13 at 09:05 +, Lankhorst, Maarten wrote:
> > > Pandiyan, Dhinakaran schreef op do 09-02-2017 om 18:55 [+]:
> > > > On Thu, 2017-02-09 at 09:01 +, Lankhorst, Maarten wrote:
> > > > > 
> > > > > Dhinakaran Pandiyan schreef op wo 08-02-2017 om 22:38 [-
> > > > > 0800]:
> > > > > > 
> > > > > > Having a ->atomic_release callback is useful to release
> > > > > > shared
> > > > > > resources
> > > > > > that get allocated in compute_config(). This function is
> > > > > > expected
> > > > > > to
> > > > > > be
> > > > > > called in the atomic_check() phase before new resources are
> > > > > > acquired.
> > > > > > 
> > > > > > v2: Moved the caller hunk to this patch (Daniel)
> > > > > > 
> > > > > > Suggested-by: Daniel Vetter 
> > > > > > Signed-off-by: Dhinakaran Pandiyan  > > > > > el.com
> > > > > > > 
> > > > > > 
> > > > > > ---
> > > > > >  drivers/gpu/drm/drm_atomic_helper.c  | 19
> > > > > > +++
> > > > > >  include/drm/drm_modeset_helper_vtables.h | 13
> > > > > > +
> > > > > >  2 files changed, 32 insertions(+)
> > > > > > 
> > > > > > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > index 8795088..92bd741 100644
> > > > > > --- a/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > +++ b/drivers/gpu/drm/drm_atomic_helper.c
> > > > > > @@ -576,6 +576,25 @@ drm_atomic_helper_check_modeset(struct
> > > > > > drm_device *dev,
> > > > > > }
> > > > > > }
> > > > > > 
> > > > > > +   for_each_connector_in_state(state, connector,
> > > > > > connector_state, i) {
> > > > > > +   const struct drm_connector_helper_funcs
> > > > > > *conn_funcs;
> > > > > > +   struct drm_crtc_state *crtc_state;
> > > > > > +
> > > > > > +   conn_funcs = connector->helper_private;
> > > > > > +   if (!conn_funcs->atomic_release)
> > > > > > +   continue;
> > > > > > +
> > > > > > +   if (!connector->state->crtc)
> > > > > > +   continue;
> > > > > > +
> > > > > > +   crtc_state =
> > > > > > drm_atomic_get_existing_crtc_state(state, connector->state-
> > > > > > > crtc);
> > > > > > 
> > > > > > +
> > > > > > +   if (crtc_state->connectors_changed ||
> > > > > > +   crtc_state->mode_changed ||
> > > > > > +   (crtc_state->active_changed &&
> > > > > > !crtc_state-
> > > > > > > 
> > > > > > > active))
> > > > > > 
> > > > > > +   conn_funcs-
> > > > > > >atomic_release(connector,
> > > > > > connector_state);
> > > > > > +   }
> > > > > 
> > > > > Could we deal with the VCPI state separately in
> > > > > intel_modeset_checks,
> > > > > like we do with dpll?
> > > > 
> > > > We'd want to release the VCPI slots before they are acquired in
> > > > ->compute_config(). intel_modeset_checks() will be too late to
> > > > release
> > > > them. Are you suggesting both acquiring and releasing slots
> > > > should be
> > > > done in intel_modeset_checks()?
> > > 
> > > That makes things a bit more nasty. Maybe add a
> > > conn_funcs->atomic_check that always gets called, something like
> > > I did
> > > below?
> > > 
> > > I'd love to use it for some atomic connector properties too.
> > 
> > 
> > Adding and unconditionally calling conn_funcs->atomic_check()
> > should be
> > doable. It also follows the pattern we have for encoders and CRTCs.
> > But
> > I'll have to move the connector->state->crtc state checks inside
> > the
> > function.
> 
> Adding ->atomic_check that's unconditionally called sounds troubling,
> because all the other ->atomic_check functions are _only_ called when
> enabling stuff. ->atomic_release sounds much better to me, and from a
> helper pov DK's patch above is the right place.

Having an atomic check would be nice for implementing connector
properties. Some of them may need to be validated regardless of crtc.

I would really like to be able to do the validation in atomic_check
instead of during the set_property callback. The state is not
completely valid at that point yet, so this would be a logical place.

> If that place doesn't work for i915.ko, then we need our own callback
> (like we already have with e.g. ->compute_config, we could do a
> ->release_config). But if it's just cosmetics, then I don't see the
> reason why we need to change this. On that issue: How exactly does
> our
> compute_config work if we haven't updated the routing (using the
> above
> helper) yet? That sounds like a pretty big misdesign on our side ...
> -Daniel
> 
> 
> > 
> > -DK
> > > > > 
> > > > > 
> > > > > Maybe implementing the relevant VCPI state could be done as
> > > > > an
> > > > > atomic
> > > > > 

Re: [PATCH] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 14:24 +1000, Dave Airlie wrote:
> On 11 January 2017 at 12:57, Y.C. Chen 
> wrote:
> > From: "Y.C. Chen" 
> 
> Please run checkpatch over this patch, it's got a lot of bad
> whitespace issues
> (4 space and 2 space indents, indent the timing tables , remove start
> of line whitespace.).

It's also misdetecting VRAM on my 2500 based POWER9 boxes. I'll take
over the patch, make it work and clean it up. Along with fixing the
P2A business properly.

New patch tomorrow hopefully.

Cheers,
Ben.

> 
> Dave.
> 
> > 
> > Signed-off-by: Y.C. Chen 
> > ---
> >  drivers/gpu/drm/ast/ast_drv.h|   2 +
> >  drivers/gpu/drm/ast/ast_main.c   |  27 ++-
> >  drivers/gpu/drm/ast/ast_mode.c   |  25 +-
> >  drivers/gpu/drm/ast/ast_post.c   | 510
> > ++-
> >  drivers/gpu/drm/ast/ast_tables.h |  57 -
> >  5 files changed, 596 insertions(+), 25 deletions(-)
> > 
> > diff --git a/drivers/gpu/drm/ast/ast_drv.h
> > b/drivers/gpu/drm/ast/ast_drv.h
> > index 908011d..7e406ce 100644
> > --- a/drivers/gpu/drm/ast/ast_drv.h
> > +++ b/drivers/gpu/drm/ast/ast_drv.h
> > @@ -64,6 +64,7 @@ enum ast_chip {
> > AST2150,
> > AST2300,
> > AST2400,
> > +   AST2500,
> > AST1180,
> >  };
> > 
> > @@ -80,6 +81,7 @@ enum ast_tx_chip {
> >  #define AST_DRAM_1Gx32   3
> >  #define AST_DRAM_2Gx16   6
> >  #define AST_DRAM_4Gx16   7
> > +#define AST_DRAM_8Gx16   8
> > 
> >  struct ast_fbdev;
> > 
> > diff --git a/drivers/gpu/drm/ast/ast_main.c
> > b/drivers/gpu/drm/ast/ast_main.c
> > index f75c642..40460ce 100644
> > --- a/drivers/gpu/drm/ast/ast_main.c
> > +++ b/drivers/gpu/drm/ast/ast_main.c
> > @@ -73,7 +73,10 @@ static int ast_detect_chip(struct drm_device
> > *dev, bool *need_post)
> > ast->chip = AST1100;
> > DRM_INFO("AST 1180 detected\n");
> > } else {
> > -   if (dev->pdev->revision >= 0x30) {
> > +   if (dev->pdev->revision >= 0x40) {
> > +   ast->chip = AST2500;
> > +   DRM_INFO("AST 2500 detected\n");
> > +   } else if (dev->pdev->revision >= 0x30) {
> > ast->chip = AST2400;
> > DRM_INFO("AST 2400 detected\n");
> > } else if (dev->pdev->revision >= 0x20) {
> > @@ -149,6 +152,8 @@ static int ast_detect_chip(struct drm_device
> > *dev, bool *need_post)
> > ast->support_wide_screen = true;
> > if (ast->chip == AST2400 && data == 0x100)
> > /* ast1400 */
> > ast->support_wide_screen = true;
> > +   if (ast->chip == AST2500 && data == 0x100)
> > /* ast2510 */
> > +   ast->support_wide_screen = true;
> > }
> > break;
> > }
> > @@ -233,7 +238,24 @@ static int ast_get_dram_info(struct drm_device
> > *dev)
> > else
> > ast->dram_bus_width = 32;
> > 
> > -   if (ast->chip == AST2300 || ast->chip == AST2400) {
> > +   if (ast->chip == AST2500) {
> > +   switch (data & 0x03) {
> > +   case 0:
> > +   ast->dram_type = AST_DRAM_1Gx16;
> > +   break;
> > +   default:
> > +   case 1:
> > +   ast->dram_type = AST_DRAM_2Gx16;
> > +   break;
> > +   case 2:
> > +   ast->dram_type = AST_DRAM_4Gx16;
> > +   break;
> > +   case 3:
> > +   ast->dram_type = AST_DRAM_8Gx16;
> > +   break;
> > +   }
> > +   }
> > +   else if (ast->chip == AST2300 || ast->chip == AST2400) {
> > switch (data & 0x03) {
> > case 0:
> > ast->dram_type = AST_DRAM_512Mx16;
> > @@ -456,6 +478,7 @@ int ast_driver_load(struct drm_device *dev,
> > unsigned long flags)
> > ast->chip == AST2200 ||
> > ast->chip == AST2300 ||
> > ast->chip == AST2400 ||
> > +   ast->chip == AST2500 ||
> > ast->chip == AST1180) {
> > dev->mode_config.max_width = 1920;
> > dev->mode_config.max_height = 2048;
> > diff --git a/drivers/gpu/drm/ast/ast_mode.c
> > b/drivers/gpu/drm/ast/ast_mode.c
> > index e26c98f..242ca7f 100644
> > --- a/drivers/gpu/drm/ast/ast_mode.c
> > +++ b/drivers/gpu/drm/ast/ast_mode.c
> > @@ -271,7 +271,10 @@ static void ast_set_crtc_reg(struct drm_crtc
> > *crtc, struct drm_display_mode *mod
> >  {
> > struct ast_private *ast = crtc->dev->dev_private;
> > u8 jreg05 = 0, jreg07 = 0, jreg09 = 0, jregAC = 0, jregAD =
> > 0, jregAE = 0;
> > -   u16 temp;
> > +   u16 temp, precache = 0;
> > +
> > +if ((ast->chip == AST2500) && 

Re: [PATCH] drm/ast: Fixed system hanged if disable P2A

[Benjamin Herrenschmidt]

On Thu, 2017-01-26 at 09:45 +0800, Y.C. Chen wrote:
> From: "Y.C. Chen" 
> 
> The original ast driver will access some BMC configuration through
> P2A bridge
> that can be disabled since AST2300 and after.
> It will cause system hanged if P2A bridge is disabled.
> Here is the update to fix it.

Will this work for us on POWER ? The problem we observed is that if P2A
is disabled, the read from f00x seems to not respond, ie, we get a PCIe
target abort on the MMIO, not 0x_. That trips our HW error
detection mechanism "EEH" which will take out the entire device.

Russell (CC) proposed a patch a while ago that seems to have gone
nowhere that allows the driver to retrieve all the information it
needs from the device-tree on platforms that support it.

That allows us to grab the necessary info from firmware before the
bridge is closed (or via some specific BMC interface we have if we
close the bridge) and pass it to Linux.

Any reason that patch hasn't been merged ? Dave ?

Cheers,
Ben.


> Signed-off-by: Y.C. Chen 
> ---
>  drivers/gpu/drm/ast/ast_drv.h  |   1 +
>  drivers/gpu/drm/ast/ast_main.c | 156 ++-
> --
>  drivers/gpu/drm/ast/ast_post.c |  18 +++--
>  3 files changed, 96 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_drv.h
> b/drivers/gpu/drm/ast/ast_drv.h
> index 908011d..7abda94 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -113,6 +113,7 @@ struct ast_private {
>   struct ttm_bo_kmap_obj cache_kmap;
>   int next_cursor;
>   bool support_wide_screen;
> + bool DisableP2A;
>  
>   enum ast_tx_chip tx_chip_type;
>   u8 dp501_maxclk;
> diff --git a/drivers/gpu/drm/ast/ast_main.c
> b/drivers/gpu/drm/ast/ast_main.c
> index f75c642..c374685 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -124,6 +124,11 @@ static int ast_detect_chip(struct drm_device
> *dev, bool *need_post)
>   } else
>   *need_post = false;
>  
> + /* Check P2A Access */
> + ast->DisableP2A = true;
> + data = ast_read32(ast, 0xf004);
> + if (data != 0x) ast->DisableP2A = false;
> +
>   /* Check if we support wide screen */
>   switch (ast->chip) {
>   case AST1180:
> @@ -140,15 +145,17 @@ static int ast_detect_chip(struct drm_device
> *dev, bool *need_post)
>   ast->support_wide_screen = true;
>   else {
>   ast->support_wide_screen = false;
> - /* Read SCU7c (silicon revision register) */
> - ast_write32(ast, 0xf004, 0x1e6e);
> - ast_write32(ast, 0xf000, 0x1);
> - data = ast_read32(ast, 0x1207c);
> - data &= 0x300;
> - if (ast->chip == AST2300 && data == 0x0) /*
> ast1300 */
> - ast->support_wide_screen = true;
> - if (ast->chip == AST2400 && data == 0x100)
> /* ast1400 */
> - ast->support_wide_screen = true;
> + if (ast->DisableP2A == false) {
> + /* Read SCU7c (silicon revision
> register) */
> + ast_write32(ast, 0xf004,
> 0x1e6e);
> + ast_write32(ast, 0xf000, 0x1);
> + data = ast_read32(ast, 0x1207c);
> + data &= 0x300;
> + if (ast->chip == AST2300 && data ==
> 0x0) /* ast1300 */
> + ast->support_wide_screen =
> true;
> + if (ast->chip == AST2400 && data ==
> 0x100) /* ast1400 */
> + ast->support_wide_screen =
> true;
> + }
>   }
>   break;
>   }
> @@ -216,80 +223,81 @@ static int ast_get_dram_info(struct drm_device
> *dev)
>   uint32_t data, data2;
>   uint32_t denum, num, div, ref_pll;
>  
> - ast_write32(ast, 0xf004, 0x1e6e);
> - ast_write32(ast, 0xf000, 0x1);
> -
> -
> - ast_write32(ast, 0x1, 0xfc600309);
> -
> - do {
> - if (pci_channel_offline(dev->pdev))
> - return -EIO;
> - } while (ast_read32(ast, 0x1) != 0x01);
> - data = ast_read32(ast, 0x10004);
> -
> - if (data & 0x40)
> + if (ast->DisableP2A)
> + {
>   ast->dram_bus_width = 16;
> + ast->dram_type = AST_DRAM_1Gx16;
> + ast->mclk = 396;
> + }
>   else
> - ast->dram_bus_width = 32;
> + {
> + ast_write32(ast, 0xf004, 0x1e6e);
> + ast_write32(ast, 0xf000, 0x1);
> + data = ast_read32(ast, 0x10004);
> +
> + if (data & 0x40)
> + ast->dram_bus_width = 16;
> + else
> + 

Re: [PATCH] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Wed, 2017-01-11 at 10:57 +0800, Y.C. Chen wrote:
> From: "Y.C. Chen" 
> 
> Signed-off-by: Y.C. Chen 
> ---
>  drivers/gpu/drm/ast/ast_drv.h|   2 +
>  drivers/gpu/drm/ast/ast_main.c   |  27 ++-
>  drivers/gpu/drm/ast/ast_mode.c   |  25 +-
>  drivers/gpu/drm/ast/ast_post.c   | 510
> ++-
>  drivers/gpu/drm/ast/ast_tables.h |  57 -
>  5 files changed, 596 insertions(+), 25 deletions(-)

Dave, Daniel, is that going upstream ? We need that for POWER9
machines, it needs to hit the distros ASAP.

We also need the one Russell Currey sent a while ago

"[PATCH] drivers/gpu/drm/ast: Support reading configuration values from
device tree"

Cheers,
Ben.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2] drm: Add DPCD definitions for DP 1.4 DSC feature

[Manasi Navare]

Display stream compression is supported on DP 1.4 DP
devices. This patch adds the corersponding DPCD
register definitions for DSC.

v2:
* Rebased on drm-tip

Signed-off-by: Manasi Navare 
Cc: Jani Nikula 
Cc: Paulo Zanoni 
Cc: dri-devel@lists.freedesktop.org
---
 include/drm/drm_dp_helper.h | 102 
 1 file changed, 102 insertions(+)

diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
index ba89295..4c1fc26 100644
--- a/include/drm/drm_dp_helper.h
+++ b/include/drm/drm_dp_helper.h
@@ -179,6 +179,108 @@
 
 #define DP_GUID0x030   /* 1.2 */
 
+#define DP_DSC_SUPPORT  0x060   /* DP 1.4 */
+# define DP_DSC_DECOMPRESSION_IS_SUPPORTED  (1 << 0)
+
+#define DP_DSC_REV  0x061
+# define DP_DSC_MAJOR_MASK  (15 << 0)
+# define DP_DSC_MINOR_MASK  (15 << 4)
+# define DP_DSC_MINOR_SHIFT 4
+
+#define DP_DSC_RC_BUF_BLK_SIZE  0x062
+# define DP_DSC_RC_BUF_BLK_SIZE_1   0x0
+# define DP_DSC_RC_BUF_BLK_SIZE_4   0x1
+# define DP_DSC_RC_BUF_BLK_SIZE_16  0x2
+# define DP_DSC_RC_BUF_BLK_SIZE_64  0x3
+
+#define DP_DSC_RC_BUF_SIZE  0x063
+
+#define DP_DSC_SLICE_CAP_1  0x064
+# define DP_DSC_1_PER_DP_DSC_SINK   (1 << 0)
+# define DP_DSC_2_PER_DP_DSC_SINK   (1 << 1)
+# define DP_DSC_4_PER_DP_DSC_SINK   (1 << 3)
+# define DP_DSC_6_PER_DP_DSC_SINK   (1 << 4)
+# define DP_DSC_8_PER_DP_DSC_SINK   (1 << 5)
+# define DP_DSC_10_PER_DP_DSC_SINK  (1 << 6)
+# define DP_DSC_12_PER_DP_DSC_SINK  (1 << 7)
+
+#define DP_DSC_LINE_BUF_BIT_DEPTH   0x065
+# define DP_DSC_LINE_BUF_BIT_DEPTH_MASK (15 << 0)
+# define DP_DSC_LINE_BUF_BIT_DEPTH_90x0
+# define DP_DSC_LINE_BUF_BIT_DEPTH_10   0x1
+# define DP_DSC_LINE_BUF_BIT_DEPTH_11   0x2
+# define DP_DSC_LINE_BUF_BIT_DEPTH_12   0x3
+# define DP_DSC_LINE_BUF_BIT_DEPTH_13   0x4
+# define DP_DSC_LINE_BUF_BIT_DEPTH_14   0x5
+# define DP_DSC_LINE_BUF_BIT_DEPTH_15   0x6
+# define DP_DSC_LINE_BUF_BIT_DEPTH_16   0x7
+# define DP_DSC_LINE_BUF_BIT_DEPTH_80x8
+
+#define DP_DSC_BLK_PREDICTION_SUPPORT   0x066
+# define DP_DSC_BLK_PREDICTION_IS_SUPPORTED (1 << 0)
+
+#define DP_DSC_MAX_BITS_PER_PIXEL_LOW   0x067   /* eDP 1.4 */
+
+#define DP_DSC_MAX_BITS_PER_PIXEL_HI0x068   /* eDP 1.4 */
+
+#define DP_DSC_DEC_COLOR_FORMAT_CAP 0x069
+# define DP_DSC_RGB (1 << 0)
+# define DP_DSC_YCbCr444(1 << 1)
+# define DP_DSC_YCbCr422_Simple (1 << 2)
+# define DP_DSC_YCbCr422_Native (1 << 3)
+# define DP_DSC_YCbCr420_Native (1 << 4)
+
+#define DP_DSC_DEC_COLOR_DEPTH_CAP  0x06A
+# define DP_DSC_8_BPC   (1 << 1)
+# define DP_DSC_10_BPC  (1 << 2)
+# define DP_DSC_12_BPC  (1 >> 3)
+
+#define DP_DSC_PEAK_THROUGHPUT  0x06B
+# define DP_DSC_THROUGHPUT_MODE_0_340   0x1
+# define DP_DSC_THROUGHPUT_MODE_0_400   0x2
+# define DP_DSC_THROUGHPUT_MODE_0_450   0x3
+# define DP_DSC_THROUGHPUT_MODE_0_500   0x4
+# define DP_DSC_THROUGHPUT_MODE_0_550   0x5
+# define DP_DSC_THROUGHPUT_MODE_0_600   0x6
+# define DP_DSC_THROUGHPUT_MODE_0_650   0x7
+# define DP_DSC_THROUGHPUT_MODE_0_700   0x8
+# define DP_DSC_THROUGHPUT_MODE_0_750   0x9
+# define DP_DSC_THROUGHPUT_MODE_0_800   0xA
+# define DP_DSC_THROUGHPUT_MODE_0_850   0xB
+# define DP_DSC_THROUGHPUT_MODE_0_900   0xC
+# define DP_DSC_THROUGHPUT_MODE_0_950   0xD
+# define DP_DSC_THROUGHPUT_MODE_0_1000  0xE
+# define DP_DSC_THROUGHPUT_MODE_1_MASK  (15 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_SHIFT 4
+# define DP_DSC_THROUGHPUT_MODE_1_340   (1 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_400   (2 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_450   (3 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_500   (4 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_550   (5 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_600   (6 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_650   (7 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_700   (8 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_750   (9 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_800   (10 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_850   (11 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_900   (12 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_950   (13 << 4)
+# define DP_DSC_THROUGHPUT_MODE_1_1000  (14 << 4)
+
+#define DP_DSC_MAX_SLICE_WIDTH  0x06C
+
+#define DP_DSC_SLICE_CAP_2  0x06D
+# define DP_DSC_16_PER_DP_DSC_SINK  (1 << 0)
+# define DP_DSC_20_PER_DP_DSC_SINK  (1 << 1)
+# define DP_DSC_24_PER_DP_DSC_SINK  (1 << 2)
+

[Bug 194533] Invalid PCI ROM header signature: expecting 0xaa55, got 0x9125

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194533

nuc...@hotmail.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from nuc...@hotmail.com ---
Ok thanks for the insight.
Just out of cutiosity, why does the core pci rom code print this?

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 194579] AMDGPU: Possible size overflow detected by PaX in ttm_bo_handle_move_mem (drivers/gpu/drm/ttm/ttm_bo.c:388)

[bugzilla-daemon]

https://bugzilla.kernel.org/show_bug.cgi?id=194579

Nicolai Hähnle (nhaeh...@gmail.com) changed:

   What|Removed |Added

 CC||nhaeh...@gmail.com

--- Comment #7 from Nicolai Hähnle (nhaeh...@gmail.com) ---
VRAM buffers can get split into multiple underlying memory chunks; in this
case, bo->mem.start == AMDGPU_BO_INVALID_OFFSET; it's not a logic bug.

bo->offset is only used via amdgpu_bo_gpu_offset, which has a WARN_ON_ONCE to
guard against accidental use of the field in this particular case.

Therefore, I'm inclined to say that this is probably not an actual bug.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #3 from Ilia Mirkin  ---
https://github.com/apitrace/apitrace

This can be used to record (and replay) all the GL commands sent down to the
driver.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #2 from d...@jerber.co.uk ---
I've just tried with multiple draw calls using the same VBO and it appears this
does also cause the error. However, it appears there has to be 3 or more calls
to cause the error (1 and 2 calls produce the expected output).

Apologies for that. It was the way my application works that led me down that
path.

I currently do not have a simple program that demonstrates the error. I have
amended the application I've been writing to call the test shaders as I was
trying to work out what was wrong with my application. I could probably create
something. What is the usual format to provide this in?

Thanks.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
> > +static bool ast_dram_init_2500(struct ast_private *ast)
> > +{
> > +   u32 data;
> > +   u32 max_tries = 5;
> > +
> > +   do {
> > +   if (max_tries-- == 0)
> > +   return false;
> > +   set_mpll_2500(ast);
> > +   reset_mmc_2500(ast);
> > +   ddr_init_common_2500(ast);
> > +
> > +   data = ast_mindwm(ast, 0x1E6E2070);
> > +   if (data & 0x0100)
> > +   ddr4_init_2500(ast, ast2500_ddr4_1600_timing_table);
> > +   else
> > +   ddr3_init_2500(ast, ast2500_ddr3_1600_timing_table);
> > +   } while (!ddr_test_2500(ast));
> > +
> > +   ast_moutdwm(ast, 0x1E6E2040, ast_mindwm(ast, 0x1E6E2040) | 0x41);
> > +
> > +   /* Patch code */
> > +   data = ast_mindwm(ast, 0x1E6E200C) & 0xF9FF;
> > +   ast_moutdwm(ast, 0x1E6E200C, data | 0x1000);
> > +
> > +   return true;
> 
> Drop the return type - function always returns true ?
> I think there were a few other functions that could do the same.

It's not. I added a timeout with a return false ;-)

Cheers,
Ben.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
> "Water is wet" type of comment. Worth mentioning why it's so large -
> mentioned in the documentation, experimental result, other ?
> Same suggestion goes for the other mdelay(100) instances.

Ah I removed most of those useless comments, I must have missed
that one. As for why 100ms, that's aspeed code. The init sequence
per-se isn't documented well, so I assume they know what they are doing
:-)

Keep in mind that this code is almost never used. It's only used
if the BMC is running no code at all, to "remotely" initialize its
memory controller.

Cheers,
Ben.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
> I realise that there's likely no documentation, yet repeating the
> same
> magic numbers multiple times is a bit meh.

This is all Aspeed original code. I merely fixed the coding style ;-)

The other POST functions for the other chip gens are the same in that
regard.

That said I do have the doc, I could create constants for everything
but I really don't have that much time and we are in an emergency toget that 
into distros...

What I might do is do a separate patch later that replaces a bunch
of the hard coded values with properly defined constants.

Cheers,
Ben.


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

--- Comment #1 from Nicolai Hähnle  ---
Interesting, thanks for the report.

Is this really an issue of having separate VBOs, or does the issue also occur
when you use separate draw calls with a single VBO? Or a single draw call?

Do you have a simple program that reproduces this? Alternatively, an apitrace
is likely to help.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
> The above seems like a _lot_ of unrelated rework. Keep the
> refactoring
> separate ?
> New code seems to assume that only(?) -1 is returned on error, yet we
> do < 0.
> This will come to bite you/others as the tests are extended/reworked.

Not sure what you mean.

I made the error return consistent yes, using -1.

< 0 is a reasonable way to test this (and probably marginally more
efficient than comparing against -1) , the "good" values are always
in the range 0.. .

I did the refactoring in that patch because we have 4 functions doing
roughly the same thing and the 2500 patch was adding 2 more.

I could do a first patch just changing the existing code I suppose...

Ben.

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 17:33 +, Emil Velikov wrote:
> On 16 February 2017 at 09:09, Benjamin Herrenschmidt
>  wrote:
> > From: "Y.C. Chen" 
> > 
> > Add detection and POST code for AST2500 generation chip,
> > code originally from Aspeed and slightly reworked for
> > coding style mostly by Ben.
> > 
> > Signed-off-by: Y.C. Chen 
> > Signed-off-by: Benjamin Herrenschmidt 
> > ---
> > v2. [BenH]
> >   - Coding style fixes
> >   - Add timeout to main DRAM init loop
> >   - Improve boot time display of RAM info
> > 
> > Y.C. Please check that I didn't break POST as I haven't manage to
> > test
> > that (we can't boot our machines if the BMC isn't already POSTed).
> > 
> 
> Hi Ben,
> 
> Barring the checkpatch.pl warnings/errors that you've spotted there's
> a few other comments below.
> I'm not familiar with the hardware, so it's just things that strike
> me
> as odd ;-)

Heh ok. I don't want to change that POST code too much as I'm not
equipped to test it, but I'll have a look later today.

Thanks,
Ben.

> 
> > +/*
> > + * AST2500 DRAM settings modules
> > + */
> > +#define REGTBL_NUM   17
> > +#define REGIDX_010   0
> > +#define REGIDX_014   1
> > +#define REGIDX_018   2
> > +#define REGIDX_020   3
> > +#define REGIDX_024   4
> > +#define REGIDX_02C   5
> > +#define REGIDX_030   6
> > +#define REGIDX_214   7
> > +#define REGIDX_2E0   8
> > +#define REGIDX_2E4   9
> > +#define REGIDX_2E8   10
> > +#define REGIDX_2EC   11
> > +#define REGIDX_2F0   12
> > +#define REGIDX_2F4   13
> > +#define REGIDX_2F8   14
> > +#define REGIDX_RFC   15
> > +#define REGIDX_PLL   16
> 
> These are used to address the correct value in the array, Worth using
> C99 initailizer to ensure that things end in the right place ?
> IIRC there was some security related GCC plugin which can fuzz the
> order of array(?) and/or struct members ?
> 
> > +
> > +static u32 ast2500_ddr3_1600_timing_table[REGTBL_NUM] = {
> > +static u32 ast2500_ddr4_1600_timing_table[REGTBL_NUM] = {
> 
> These two are constant data, although you'll need to annotate the
> users as well.
> 
> 
> > --- a/drivers/gpu/drm/ast/ast_main.c
> > +++ b/drivers/gpu/drm/ast/ast_main.c
> > @@ -32,8 +32,6 @@
> >  #include 
> >  #include 
> > 
> > -#include "ast_dram_tables.h"
> > -
> 
> Unrelated change ?
> 
> 
> > -   DRM_INFO("dram %d %d %d %08x\n", ast->mclk, ast-
> > >dram_type, ast->dram_bus_width, ast->vram_size);
> > +   DRM_INFO("dram MCLK=%u type=%d bus_width=%d
> > size=%08x\n",
> > +ast->mclk, ast->dram_type, ast-
> > >dram_bus_width, ast->vram_size);
> 
> Unrelated change ?
> 
> 
> >  static void ast_set_ext_reg(struct drm_crtc *crtc, struct
> > drm_display_mode *mode,
> > @@ -421,7 +432,7 @@ static void ast_set_ext_reg(struct drm_crtc
> > *crtc, struct drm_display_mode *mode
> > ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa8, 0xfd,
> > jregA8);
> > 
> > /* Set Threshold */
> > -   if (ast->chip == AST2300 || ast->chip == AST2400) {
> > +   if (ast->chip == AST2300 || ast->chip == AST2400 || ast-
> > >chip == AST2500) {
> > ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa7,
> > 0x78);
> > ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa6,
> > 0x60);
> > } else if (ast->chip == AST2100 ||
> > @@ -794,7 +805,7 @@ static int ast_mode_valid(struct drm_connector
> > *connector,
> > if ((mode->hdisplay == 1600) && (mode->vdisplay ==
> > 900))
> > return MODE_OK;
> > 
> > -   if ((ast->chip == AST2100) || (ast->chip ==
> > AST2200) || (ast->chip == AST2300) || (ast->chip == AST2400) ||
> > (ast->chip == AST1180)) {
> > +   if ((ast->chip == AST2100) || (ast->chip ==
> > AST2200) || (ast->chip == AST2300) || (ast->chip == AST2400) ||
> > (ast->chip == AST2500) || (ast->chip == AST1180)) {
> 
> 178 columns is getting a bit too much.
> 
> 
> > -static int mmc_test_burst(struct ast_private *ast, u32 datagen)
> > +static int mmc_test(struct ast_private *ast, u32 datagen, u8
> > test_ctl)
> >  {
> > u32 data, timeout;
> > 
> > ast_moutdwm(ast, 0x1e6e0070, 0x);
> > -   ast_moutdwm(ast, 0x1e6e0070, 0x00c1 | (datagen << 3));
> > +   ast_moutdwm(ast, 0x1e6e0070, (datagen << 3) | test_ctl);
> > timeout = 0;
> > do {
> > data = ast_mindwm(ast, 0x1e6e0070) & 0x3000;
> > if (data & 0x2000) {
> > -   return 0;
> > +   return -1;
> > }
> > if (++timeout > TIMEOUT) {
> > ast_moutdwm(ast, 0x1e6e0070, 0x);
> > -   return 0;
> > +   return -1;
> >  

[Bug 97879] [amdgpu] Rocket League: long hangs (several seconds) when loading assets (models/textures/shaders?)

[bugzilla-daemon]

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

--- Comment #92 from libgra...@gmail.com ---
Working great here now guys - latest RL build and Mesa git.

Thanks to all involved - great cooperation :)

-- 
You are receiving this mail because:
You are the assignee for the bug.
You are on the CC list for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99843] Geometry Shader - Incorrect Output

[bugzilla-daemon]

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

Bug ID: 99843
   Summary: Geometry Shader - Incorrect Output
   Product: Mesa
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: d...@jerber.co.uk
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 129684
  --> https://bugs.freedesktop.org/attachment.cgi?id=129684=edit
Typical output

Hi,

I am developing a cross-platform application. I have recently found an issue
that is only present when it is tested on a Ubuntu machine. I have managed to
find a minimal example that shows the issue as follows:

The vertex shader:

#version 150
in vec2 pos;

void main(void)
{
gl_Position = vec4(pos, 0.0, 1.0);
}


The fragment shader:

#version 150
out vec4 outColour;

void main(void)
{
outColour = vec4(1.0f, 1.0f, 1.0f, 1.0f);
}


The geometry shader:

#version 150
layout(points) in;
layout(line_strip, max_vertices = 13) out;
uniform mat4 vpMatrix;

void main()
{
for(int i = 0; i < 13; i++)
{
float polygonAngle = (i * 30) + 90.0f;
vec4 vertexPosition = vec4((sin(radians(polygonAngle)) * 0.5f) +
gl_in[0].gl_Position.x, (cos(radians(polygonAngle)) * 0.5f) +
gl_in[0].gl_Position.y, 0.0f, 1.0f);
gl_Position = vpMatrix * vertexPosition;
EmitVertex();
}
EndPrimitive();
}

The problem occurs when the shader program is used with multiple VBO's. For
example:

3 separate VBO's are created with {-1.0f, 1.0f}, {1.0f, 1.0f}, {1.0f, -1.0f} as
the data. Then, for each repaint:

for(int i = 0; i < 3; i++)
{
Bind array buffer i.
glDrawArrays(GL_POINTS, 0, 1);
}

This produces strange results for the third polygon (shown in the attached
image Output.JPG).

If tested on a Windows 10 machine (exactly the same hardware) or an OSX
machine, the results are as expected (3 regular polygons with 12 sides).

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

On Thu, Feb 16, 2017 at 08:59:13PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
> >> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> >> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> >> >> Handle debugfs override edid and firmware edid at the low level to
> >> >> transparently and completely replace the real edid. Previously, we
> >> >> practically only used the modes from the override EDID, and none of the
> >> >> other data. This also prevents actual EDID reads when the EDID is to be
> >> >> overridden, but retains the DDC probe.
> >> >
> >> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
> >> > somethign then the override EDID wouldn't be returned by drm_get_edid().
> >> 
> >> Isn't this in line with how this currently works?
> >
> > Not really. If connector->force is used and an override EDID is
> > provided, then drm_get_edid() likely never gets called, and the modes
> > come directly from the overide EDID. With your change forcing the
> > connector state wouldn't because we still wouldn't get any modes
> > from the override EDID due to the DDC check.
> 
> Right.
> 
> > I guess one way around this would be to skip the DDC check if the
> > connector state has been forced.
> 
> I guess I'm asking if you think the whole approach here is
> workable. What we currently have is so flaky.

I'm 100% with you on that. So yes, I do like the idea.

I think the last time the override EDIDs were discussed someone was
suggesting that the EDID override itself should force the connector
state. IIRC Daniel didn't agree. I don't have a particularly strong
opinion either way, but I guess trying to preserve the current
semantics (ie. EDID override and connector status forcing are mostly
separate) would be the thing to aim for, at least initially.

> 
> BR,
> Jani.
> 
> >
> >> 
> >> BR,
> >> Jani.
> >> 
> >> 
> >> >
> >> >> 
> >> >> FIXME: validate override edid, deduplicate firmware edid validation.
> >> >> 
> >> >> Signed-off-by: Jani Nikula 
> >> >> ---
> >> >>  drivers/gpu/drm/drm_edid.c | 15 +++
> >> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> >> >>  2 files changed, 16 insertions(+), 18 deletions(-)
> >> >> 
> >> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> >> index 362036360724..054e2d74eafc 100644
> >> >> --- a/drivers/gpu/drm/drm_edid.c
> >> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
> >> >> drm_connector *connector,
> >> >>   * level, drivers must make all reasonable efforts to expose it as an 
> >> >> I2C
> >> >>   * adapter and use drm_get_edid() instead of abusing this function.
> >> >>   *
> >> >> + * The EDID may be overridden using debugfs override_edid or firmare 
> >> >> EDID
> >> >> + * (drm_load_edid_firmware()), in this priority order. Having either 
> >> >> of them
> >> >> + * bypasses actual EDID reads.
> >> >> + *
> >> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> >> >>   */
> >> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct 
> >> >> drm_connector *connector,
> >> >>  {
> >> >> int i, j = 0, valid_extensions = 0;
> >> >> u8 *edid, *new;
> >> >> +   struct edid *override = NULL;
> >> >> +
> >> >> +   if (connector->override_edid)
> >> >> +   override = drm_edid_duplicate((const struct edid *)
> >> >> + 
> >> >> connector->edid_blob_ptr->data);
> >> >> +
> >> >> +   if (!override)
> >> >> +   override = drm_load_edid_firmware(connector);
> >> >> +
> >> >> +   if (!IS_ERR_OR_NULL(override))
> >> >> +   return override;
> >> >>  
> >> >> if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> >> >> return NULL;
> >> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> >> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> >> index 358957118ca9..871326cbc465 100644
> >> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> >> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector 
> >> >> *connector, bool force)
> >> >>   *drm_mode_probed_add(). New modes start their life with status as 
> >> >> OK.
> >> >>   *Modes are added from a single source using the following 
> >> >> priority order.
> >> >>   *
> >> >> - *- debugfs 'override_edid' (used for testing only)
> >> >> - *- firmware EDID (drm_load_edid_firmware())
> >> >>   *- _connector_helper_funcs.get_modes vfunc
> >> >>   *- if the connector status is connector_status_connected, standard
> >> >>   *  VESA DMT modes up to 1024x768 are automatically added
> >> >> @@ -305,22 +303,7 @@ 

Re: [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications

[Jani Nikula]

On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
>> Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
>> the bus is accessed to avoid needing to do any forcewakes, which need
>> PMIC bus access, while the PMIC bus is busy:
>> 
>> This fixes errors like these showing up in dmesg, usually followed
>> by a gfx or system freeze:
>> 
>> [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake 
>> ack request.
>> [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake 
>> ack request.
>> i2c_designware 808622C1:06: punit semaphore timed out, resetting
>> i2c_designware 808622C1:06: PUNIT SEM: 2
>> i2c_designware 808622C1:06: couldn't acquire bus ownership
>> 
>> Downside of this approach is that it causes wakeups whenever the PMIC
>> bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
>> to go idle when we hit a race, as forcewakes may be done from interrupt
>> handlers where we cannot sleep to wait for the i2c PMIC bus access to
>> finish.
>> 
>> Note that the notifications and thus the wakeups will only happen on
>> baytrail / cherrytrail devices using PMICs with a shared i2c bus for
>> P-Unit and host PMIC access (i2c busses with a _SEM method in their
>> APCI node), e.g. an axp288 PMIC.
>> 
>> I plan to write some patches for drivers accessing the PMIC bus to
>> limit their bus accesses to a bare minimum (e.g. cache registers, do not
>> update battery level more often then 4 times a minute), to limit the
>> amount of wakeups.
>> 
>> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
>> Signed-off-by: Hans de Goede 
>> Tested-by: tagorereddy 
>
> I gave the previous versions a quick whirl on a few machines here, but
> them not being CR versions I guess this stuff doesn't kick in at all.
> And I don't see any _SEM stuff in the DSDT/SSDT, so I guess that
> confirms it. Which is fine since I've not seem any stability issues
> on those machines. So at least nothing seemed to break :)
>
> Anyways the changes look all right to me, so for both i915 patches
> Reviewed-by: Ville Syrjälä 

Acked-by: Jani Nikula 

for merging the i915 patches through some other tree if that makes
managing the pile easier.


>
>> ---
>> Changes in v2:
>> -Spelling: P-Unit, PMIC
>> Changes in v3:
>> -Improve comment explaining why we call intel_uncore_forcewake_get(ALL) on
>>  MBI_PMIC_BUS_ACCESS_BEGIN notification
>> ---
>>  drivers/gpu/drm/i915/Kconfig|  1 +
>>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>>  drivers/gpu/drm/i915/intel_uncore.c | 39 
>> +
>>  3 files changed, 41 insertions(+)
>> 
>> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
>> index 1ae0bb9..a5cd5da 100644
>> --- a/drivers/gpu/drm/i915/Kconfig
>> +++ b/drivers/gpu/drm/i915/Kconfig
>> @@ -20,6 +20,7 @@ config DRM_I915
>>  select ACPI_VIDEO if ACPI
>>  select ACPI_BUTTON if ACPI
>>  select SYNC_FILE
>> +select IOSF_MBI
>>  help
>>Choose this option if you have a system that has "Intel Graphics
>>Media Accelerator" or "HD Graphics" integrated graphics,
>> diff --git a/drivers/gpu/drm/i915/i915_drv.h 
>> b/drivers/gpu/drm/i915/i915_drv.h
>> index 998239f..4e405d0 100644
>> --- a/drivers/gpu/drm/i915/i915_drv.h
>> +++ b/drivers/gpu/drm/i915/i915_drv.h
>> @@ -725,6 +725,7 @@ struct intel_uncore {
>>  const struct intel_forcewake_range *fw_domains_table;
>>  unsigned int fw_domains_table_entries;
>>  
>> +struct notifier_block pmic_bus_access_nb;
>>  struct intel_uncore_funcs funcs;
>>  
>>  unsigned fifo_count;
>> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
>> b/drivers/gpu/drm/i915/intel_uncore.c
>> index b6d726b..1be3cdc 100644
>> --- a/drivers/gpu/drm/i915/intel_uncore.c
>> +++ b/drivers/gpu/drm/i915/intel_uncore.c
>> @@ -25,6 +25,7 @@
>>  #include "intel_drv.h"
>>  #include "i915_vgpu.h"
>>  
>> +#include 
>>  #include 
>>  
>>  #define FORCEWAKE_ACK_TIMEOUT_MS 50
>> @@ -436,12 +437,16 @@ static void __intel_uncore_early_sanitize(struct 
>> drm_i915_private *dev_priv,
>>  
>>  void intel_uncore_suspend(struct drm_i915_private *dev_priv)
>>  {
>> +iosf_mbi_unregister_pmic_bus_access_notifier(
>> +_priv->uncore.pmic_bus_access_nb);
>>  intel_uncore_forcewake_reset(dev_priv, false);
>>  }
>>  
>>  void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
>>  {
>>  __intel_uncore_early_sanitize(dev_priv, true);
>> +iosf_mbi_register_pmic_bus_access_notifier(
>> +_priv->uncore.pmic_bus_access_nb);
>>  i915_check_and_clear_faults(dev_priv);
>>  }
>>  
>> @@ -1329,6 +1334,32 @@ static void intel_uncore_fw_domains_init(struct 
>> drm_i915_private *dev_priv)
>>  dev_priv->uncore.fw_domains_table_entries = 

Re: [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Jani Nikula]

On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
>> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
>> >> Handle debugfs override edid and firmware edid at the low level to
>> >> transparently and completely replace the real edid. Previously, we
>> >> practically only used the modes from the override EDID, and none of the
>> >> other data. This also prevents actual EDID reads when the EDID is to be
>> >> overridden, but retains the DDC probe.
>> >
>> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
>> > somethign then the override EDID wouldn't be returned by drm_get_edid().
>> 
>> Isn't this in line with how this currently works?
>
> Not really. If connector->force is used and an override EDID is
> provided, then drm_get_edid() likely never gets called, and the modes
> come directly from the overide EDID. With your change forcing the
> connector state wouldn't because we still wouldn't get any modes
> from the override EDID due to the DDC check.

Right.

> I guess one way around this would be to skip the DDC check if the
> connector state has been forced.

I guess I'm asking if you think the whole approach here is
workable. What we currently have is so flaky.

BR,
Jani.

>
>> 
>> BR,
>> Jani.
>> 
>> 
>> >
>> >> 
>> >> FIXME: validate override edid, deduplicate firmware edid validation.
>> >> 
>> >> Signed-off-by: Jani Nikula 
>> >> ---
>> >>  drivers/gpu/drm/drm_edid.c | 15 +++
>> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>> >>  2 files changed, 16 insertions(+), 18 deletions(-)
>> >> 
>> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> >> index 362036360724..054e2d74eafc 100644
>> >> --- a/drivers/gpu/drm/drm_edid.c
>> >> +++ b/drivers/gpu/drm/drm_edid.c
>> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct 
>> >> drm_connector *connector,
>> >>   * level, drivers must make all reasonable efforts to expose it as an I2C
>> >>   * adapter and use drm_get_edid() instead of abusing this function.
>> >>   *
>> >> + * The EDID may be overridden using debugfs override_edid or firmare EDID
>> >> + * (drm_load_edid_firmware()), in this priority order. Having either of 
>> >> them
>> >> + * bypasses actual EDID reads.
>> >> + *
>> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>> >>   */
>> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
>> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
>> >> *connector,
>> >>  {
>> >>   int i, j = 0, valid_extensions = 0;
>> >>   u8 *edid, *new;
>> >> + struct edid *override = NULL;
>> >> +
>> >> + if (connector->override_edid)
>> >> + override = drm_edid_duplicate((const struct edid *)
>> >> +   connector->edid_blob_ptr->data);
>> >> +
>> >> + if (!override)
>> >> + override = drm_load_edid_firmware(connector);
>> >> +
>> >> + if (!IS_ERR_OR_NULL(override))
>> >> + return override;
>> >>  
>> >>   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>> >>   return NULL;
>> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> >> b/drivers/gpu/drm/drm_probe_helper.c
>> >> index 358957118ca9..871326cbc465 100644
>> >> --- a/drivers/gpu/drm/drm_probe_helper.c
>> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> >> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
>> >> bool force)
>> >>   *drm_mode_probed_add(). New modes start their life with status as 
>> >> OK.
>> >>   *Modes are added from a single source using the following priority 
>> >> order.
>> >>   *
>> >> - *- debugfs 'override_edid' (used for testing only)
>> >> - *- firmware EDID (drm_load_edid_firmware())
>> >>   *- _connector_helper_funcs.get_modes vfunc
>> >>   *- if the connector status is connector_status_connected, standard
>> >>   *  VESA DMT modes up to 1024x768 are automatically added
>> >> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
>> >> drm_connector *connector,
>> >>   goto prune;
>> >>   }
>> >>  
>> >> - if (connector->override_edid) {
>> >> - struct edid *edid = (struct edid *) 
>> >> connector->edid_blob_ptr->data;
>> >> -
>> >> - count = drm_add_edid_modes(connector, edid);
>> >> - drm_edid_to_eld(connector, edid);
>> >> - } else {
>> >> - struct edid *edid = drm_load_edid_firmware(connector);
>> >> - if (!IS_ERR_OR_NULL(edid)) {
>> >> - drm_mode_connector_update_edid_property(connector, 
>> >> edid);
>> >> - count = drm_add_edid_modes(connector, edid);
>> >> - drm_edid_to_eld(connector, edid);
>> >> - kfree(edid);
>> >> - }
>> >> - if (count == 0)
>> 

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #12 from Matias N. Goldberg  ---
I can confirm applying the patch you uploaded (plus LLVM's patch of course)
fixes the problem.

Thank you.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 12/12] drm/i915: Listen for PMIC bus access notifications

[Ville Syrjälä]

On Fri, Feb 10, 2017 at 11:28:02AM +0100, Hans de Goede wrote:
> Listen for PMIC bus access notifications and get FORCEWAKE_ALL while
> the bus is accessed to avoid needing to do any forcewakes, which need
> PMIC bus access, while the PMIC bus is busy:
> 
> This fixes errors like these showing up in dmesg, usually followed
> by a gfx or system freeze:
> 
> [drm:fw_domains_get [i915]] *ERROR* render: timed out waiting for forcewake 
> ack request.
> [drm:fw_domains_get [i915]] *MEDIA* render: timed out waiting for forcewake 
> ack request.
> i2c_designware 808622C1:06: punit semaphore timed out, resetting
> i2c_designware 808622C1:06: PUNIT SEM: 2
> i2c_designware 808622C1:06: couldn't acquire bus ownership
> 
> Downside of this approach is that it causes wakeups whenever the PMIC
> bus is accessed. Unfortunately we cannot simply wait for the PMIC bus
> to go idle when we hit a race, as forcewakes may be done from interrupt
> handlers where we cannot sleep to wait for the i2c PMIC bus access to
> finish.
> 
> Note that the notifications and thus the wakeups will only happen on
> baytrail / cherrytrail devices using PMICs with a shared i2c bus for
> P-Unit and host PMIC access (i2c busses with a _SEM method in their
> APCI node), e.g. an axp288 PMIC.
> 
> I plan to write some patches for drivers accessing the PMIC bus to
> limit their bus accesses to a bare minimum (e.g. cache registers, do not
> update battery level more often then 4 times a minute), to limit the
> amount of wakeups.
> 
> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=155241
> Signed-off-by: Hans de Goede 
> Tested-by: tagorereddy 

I gave the previous versions a quick whirl on a few machines here, but
them not being CR versions I guess this stuff doesn't kick in at all.
And I don't see any _SEM stuff in the DSDT/SSDT, so I guess that
confirms it. Which is fine since I've not seem any stability issues
on those machines. So at least nothing seemed to break :)

Anyways the changes look all right to me, so for both i915 patches
Reviewed-by: Ville Syrjälä 

> ---
> Changes in v2:
> -Spelling: P-Unit, PMIC
> Changes in v3:
> -Improve comment explaining why we call intel_uncore_forcewake_get(ALL) on
>  MBI_PMIC_BUS_ACCESS_BEGIN notification
> ---
>  drivers/gpu/drm/i915/Kconfig|  1 +
>  drivers/gpu/drm/i915/i915_drv.h |  1 +
>  drivers/gpu/drm/i915/intel_uncore.c | 39 
> +
>  3 files changed, 41 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/Kconfig b/drivers/gpu/drm/i915/Kconfig
> index 1ae0bb9..a5cd5da 100644
> --- a/drivers/gpu/drm/i915/Kconfig
> +++ b/drivers/gpu/drm/i915/Kconfig
> @@ -20,6 +20,7 @@ config DRM_I915
>   select ACPI_VIDEO if ACPI
>   select ACPI_BUTTON if ACPI
>   select SYNC_FILE
> + select IOSF_MBI
>   help
> Choose this option if you have a system that has "Intel Graphics
> Media Accelerator" or "HD Graphics" integrated graphics,
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 998239f..4e405d0 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -725,6 +725,7 @@ struct intel_uncore {
>   const struct intel_forcewake_range *fw_domains_table;
>   unsigned int fw_domains_table_entries;
>  
> + struct notifier_block pmic_bus_access_nb;
>   struct intel_uncore_funcs funcs;
>  
>   unsigned fifo_count;
> diff --git a/drivers/gpu/drm/i915/intel_uncore.c 
> b/drivers/gpu/drm/i915/intel_uncore.c
> index b6d726b..1be3cdc 100644
> --- a/drivers/gpu/drm/i915/intel_uncore.c
> +++ b/drivers/gpu/drm/i915/intel_uncore.c
> @@ -25,6 +25,7 @@
>  #include "intel_drv.h"
>  #include "i915_vgpu.h"
>  
> +#include 
>  #include 
>  
>  #define FORCEWAKE_ACK_TIMEOUT_MS 50
> @@ -436,12 +437,16 @@ static void __intel_uncore_early_sanitize(struct 
> drm_i915_private *dev_priv,
>  
>  void intel_uncore_suspend(struct drm_i915_private *dev_priv)
>  {
> + iosf_mbi_unregister_pmic_bus_access_notifier(
> + _priv->uncore.pmic_bus_access_nb);
>   intel_uncore_forcewake_reset(dev_priv, false);
>  }
>  
>  void intel_uncore_resume_early(struct drm_i915_private *dev_priv)
>  {
>   __intel_uncore_early_sanitize(dev_priv, true);
> + iosf_mbi_register_pmic_bus_access_notifier(
> + _priv->uncore.pmic_bus_access_nb);
>   i915_check_and_clear_faults(dev_priv);
>  }
>  
> @@ -1329,6 +1334,32 @@ static void intel_uncore_fw_domains_init(struct 
> drm_i915_private *dev_priv)
>   dev_priv->uncore.fw_domains_table_entries = ARRAY_SIZE((d)); \
>  }
>  
> +static int i915_pmic_bus_access_notifier(struct notifier_block *nb,
> +  unsigned long action, void *data)
> +{
> + struct drm_i915_private *dev_priv = container_of(nb,
> + struct drm_i915_private, uncore.pmic_bus_access_nb);
> +
> + switch 

Re: [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

On Thu, Feb 16, 2017 at 07:54:00PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> > On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> >> Handle debugfs override edid and firmware edid at the low level to
> >> transparently and completely replace the real edid. Previously, we
> >> practically only used the modes from the override EDID, and none of the
> >> other data. This also prevents actual EDID reads when the EDID is to be
> >> overridden, but retains the DDC probe.
> >
> > Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
> > somethign then the override EDID wouldn't be returned by drm_get_edid().
> 
> Isn't this in line with how this currently works?

Not really. If connector->force is used and an override EDID is
provided, then drm_get_edid() likely never gets called, and the modes
come directly from the overide EDID. With your change forcing the
connector state wouldn't because we still wouldn't get any modes
from the override EDID due to the DDC check.

I guess one way around this would be to skip the DDC check if the
connector state has been forced.

> 
> BR,
> Jani.
> 
> 
> >
> >> 
> >> FIXME: validate override edid, deduplicate firmware edid validation.
> >> 
> >> Signed-off-by: Jani Nikula 
> >> ---
> >>  drivers/gpu/drm/drm_edid.c | 15 +++
> >>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
> >>  2 files changed, 16 insertions(+), 18 deletions(-)
> >> 
> >> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> >> index 362036360724..054e2d74eafc 100644
> >> --- a/drivers/gpu/drm/drm_edid.c
> >> +++ b/drivers/gpu/drm/drm_edid.c
> >> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
> >> *connector,
> >>   * level, drivers must make all reasonable efforts to expose it as an I2C
> >>   * adapter and use drm_get_edid() instead of abusing this function.
> >>   *
> >> + * The EDID may be overridden using debugfs override_edid or firmare EDID
> >> + * (drm_load_edid_firmware()), in this priority order. Having either of 
> >> them
> >> + * bypasses actual EDID reads.
> >> + *
> >>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
> >>   */
> >>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> >> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> >> *connector,
> >>  {
> >>int i, j = 0, valid_extensions = 0;
> >>u8 *edid, *new;
> >> +  struct edid *override = NULL;
> >> +
> >> +  if (connector->override_edid)
> >> +  override = drm_edid_duplicate((const struct edid *)
> >> +connector->edid_blob_ptr->data);
> >> +
> >> +  if (!override)
> >> +  override = drm_load_edid_firmware(connector);
> >> +
> >> +  if (!IS_ERR_OR_NULL(override))
> >> +  return override;
> >>  
> >>if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
> >>return NULL;
> >> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> >> b/drivers/gpu/drm/drm_probe_helper.c
> >> index 358957118ca9..871326cbc465 100644
> >> --- a/drivers/gpu/drm/drm_probe_helper.c
> >> +++ b/drivers/gpu/drm/drm_probe_helper.c
> >> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> >> bool force)
> >>   *drm_mode_probed_add(). New modes start their life with status as OK.
> >>   *Modes are added from a single source using the following priority 
> >> order.
> >>   *
> >> - *- debugfs 'override_edid' (used for testing only)
> >> - *- firmware EDID (drm_load_edid_firmware())
> >>   *- _connector_helper_funcs.get_modes vfunc
> >>   *- if the connector status is connector_status_connected, standard
> >>   *  VESA DMT modes up to 1024x768 are automatically added
> >> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
> >> drm_connector *connector,
> >>goto prune;
> >>}
> >>  
> >> -  if (connector->override_edid) {
> >> -  struct edid *edid = (struct edid *) 
> >> connector->edid_blob_ptr->data;
> >> -
> >> -  count = drm_add_edid_modes(connector, edid);
> >> -  drm_edid_to_eld(connector, edid);
> >> -  } else {
> >> -  struct edid *edid = drm_load_edid_firmware(connector);
> >> -  if (!IS_ERR_OR_NULL(edid)) {
> >> -  drm_mode_connector_update_edid_property(connector, 
> >> edid);
> >> -  count = drm_add_edid_modes(connector, edid);
> >> -  drm_edid_to_eld(connector, edid);
> >> -  kfree(edid);
> >> -  }
> >> -  if (count == 0)
> >> -  count = (*connector_funcs->get_modes)(connector);
> >> -  }
> >> +  count = (*connector_funcs->get_modes)(connector);
> >>  
> >>if (count == 0 && connector->status == connector_status_connected)
> >>count = drm_add_modes_noedid(connector, 1024, 768);
> >> -- 
> 

Re: [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Jani Nikula]

On Thu, 16 Feb 2017, Ville Syrjälä  wrote:
> On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
>> Handle debugfs override edid and firmware edid at the low level to
>> transparently and completely replace the real edid. Previously, we
>> practically only used the modes from the override EDID, and none of the
>> other data. This also prevents actual EDID reads when the EDID is to be
>> overridden, but retains the DDC probe.
>
> Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
> somethign then the override EDID wouldn't be returned by drm_get_edid().

Isn't this in line with how this currently works?

BR,
Jani.


>
>> 
>> FIXME: validate override edid, deduplicate firmware edid validation.
>> 
>> Signed-off-by: Jani Nikula 
>> ---
>>  drivers/gpu/drm/drm_edid.c | 15 +++
>>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>>  2 files changed, 16 insertions(+), 18 deletions(-)
>> 
>> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
>> index 362036360724..054e2d74eafc 100644
>> --- a/drivers/gpu/drm/drm_edid.c
>> +++ b/drivers/gpu/drm/drm_edid.c
>> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
>> *connector,
>>   * level, drivers must make all reasonable efforts to expose it as an I2C
>>   * adapter and use drm_get_edid() instead of abusing this function.
>>   *
>> + * The EDID may be overridden using debugfs override_edid or firmare EDID
>> + * (drm_load_edid_firmware()), in this priority order. Having either of them
>> + * bypasses actual EDID reads.
>> + *
>>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>>   */
>>  struct edid *drm_do_get_edid(struct drm_connector *connector,
>> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
>> *connector,
>>  {
>>  int i, j = 0, valid_extensions = 0;
>>  u8 *edid, *new;
>> +struct edid *override = NULL;
>> +
>> +if (connector->override_edid)
>> +override = drm_edid_duplicate((const struct edid *)
>> +  connector->edid_blob_ptr->data);
>> +
>> +if (!override)
>> +override = drm_load_edid_firmware(connector);
>> +
>> +if (!IS_ERR_OR_NULL(override))
>> +return override;
>>  
>>  if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>>  return NULL;
>> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
>> b/drivers/gpu/drm/drm_probe_helper.c
>> index 358957118ca9..871326cbc465 100644
>> --- a/drivers/gpu/drm/drm_probe_helper.c
>> +++ b/drivers/gpu/drm/drm_probe_helper.c
>> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
>> bool force)
>>   *drm_mode_probed_add(). New modes start their life with status as OK.
>>   *Modes are added from a single source using the following priority 
>> order.
>>   *
>> - *- debugfs 'override_edid' (used for testing only)
>> - *- firmware EDID (drm_load_edid_firmware())
>>   *- _connector_helper_funcs.get_modes vfunc
>>   *- if the connector status is connector_status_connected, standard
>>   *  VESA DMT modes up to 1024x768 are automatically added
>> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
>> drm_connector *connector,
>>  goto prune;
>>  }
>>  
>> -if (connector->override_edid) {
>> -struct edid *edid = (struct edid *) 
>> connector->edid_blob_ptr->data;
>> -
>> -count = drm_add_edid_modes(connector, edid);
>> -drm_edid_to_eld(connector, edid);
>> -} else {
>> -struct edid *edid = drm_load_edid_firmware(connector);
>> -if (!IS_ERR_OR_NULL(edid)) {
>> -drm_mode_connector_update_edid_property(connector, 
>> edid);
>> -count = drm_add_edid_modes(connector, edid);
>> -drm_edid_to_eld(connector, edid);
>> -kfree(edid);
>> -}
>> -if (count == 0)
>> -count = (*connector_funcs->get_modes)(connector);
>> -}
>> +count = (*connector_funcs->get_modes)(connector);
>>  
>>  if (count == 0 && connector->status == connector_status_connected)
>>  count = drm_add_modes_noedid(connector, 1024, 768);
>> -- 
>> 2.1.4

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] amdgpu drm-next-4.11

[Alex Deucher]

Hi Dave,

Fixes for 4.11. Highlights:
- fix >2 displays on asics with 3 or 5 crtcs
- fix SI headless asics
- powerplay fixes for new polaris variants
- misc fixes

The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:

  Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-02-10 10:13:30 +1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-next-4.11

for you to fetch changes up to e8411302b44b844b4f619e8064735c70b7490ee8:

  drm/amdgpu: fix warning on older gcc releases (2017-02-16 12:19:52 -0500)


Alan Harrison (1):
  drm/amdgpu: Add to initialization of mmVCE_VCPU_CNTL register

Alex Deucher (2):
  drm/amdgpu: add more cases to DCE11 possible crtc mask setup
  drm/amdgpu/pm: check for headless before calling compute_clocks

Arnd Bergmann (1):
  drm/amdgpu: fix warning on older gcc releases

Huang Rui (3):
  drm/amd/powerplay: add kicker flag into smumgr
  drm/amd/powerplay: modify VddcPhase value for polaris kicker
  drm/amd/powerplay: add didt config table for polaris kicker

Nicolai Hähnle (1):
  drm/ttm: make TTM_MAX_BO_PRIORITY unsigned

Rex Zhu (1):
  drm/amdgpu: read hw register to check pg status.

Samuel Pitoiset (1):
  drm/amdgpu: use amdgpu_gem_va_check() in amdgpu_gem_va_update_vm()

Tom St Denis (1):
  drm/amd/amdgpu: Fix flow control in uvd_v4_2_stop()

ozeng (1):
  drm/amdgpu: Initialize pipe priority order on graphic initialization

 drivers/gpu/drm/amd/amdgpu/amdgpu.h|   2 -
 drivers/gpu/drm/amd/amdgpu/amdgpu_cgs.c|  20 +--
 drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c|   8 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_pm.c |   3 +-
 drivers/gpu/drm/amd/amdgpu/dce_v11_0.c |   6 +
 drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c  |   8 ++
 drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c  |  12 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v4_2.c  |  15 ++-
 drivers/gpu/drm/amd/amdgpu/uvd_v5_0.c  |   5 +-
 drivers/gpu/drm/amd/amdgpu/uvd_v6_0.c  |   5 +-
 drivers/gpu/drm/amd/amdgpu/vce_v3_0.c  |   7 +-
 .../amd/include/asic_reg/smu/smu_7_0_1_sh_mask.h   |   2 +
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_1_d.h |   1 +
 .../amd/include/asic_reg/smu/smu_7_1_1_sh_mask.h   |   2 +
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_2_d.h |   1 +
 .../amd/include/asic_reg/smu/smu_7_1_2_sh_mask.h   |   2 +
 .../gpu/drm/amd/include/asic_reg/smu/smu_7_1_3_d.h |   2 +-
 .../amd/include/asic_reg/smu/smu_7_1_3_sh_mask.h   |   3 +
 drivers/gpu/drm/amd/include/cgs_common.h   |   1 +
 .../gpu/drm/amd/powerplay/hwmgr/smu7_powertune.c   | 150 -
 drivers/gpu/drm/amd/powerplay/inc/smumgr.h |   1 +
 .../gpu/drm/amd/powerplay/smumgr/polaris10_smc.c   |   6 +-
 drivers/gpu/drm/amd/powerplay/smumgr/smu7_smumgr.c |   2 +
 include/drm/ttm/ttm_bo_driver.h|   2 +-
 24 files changed, 228 insertions(+), 38 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Emil Velikov]

On 16 February 2017 at 09:09, Benjamin Herrenschmidt
 wrote:
> From: "Y.C. Chen" 
>
> Add detection and POST code for AST2500 generation chip,
> code originally from Aspeed and slightly reworked for
> coding style mostly by Ben.
>
> Signed-off-by: Y.C. Chen 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
> v2. [BenH]
>   - Coding style fixes
>   - Add timeout to main DRAM init loop
>   - Improve boot time display of RAM info
>
> Y.C. Please check that I didn't break POST as I haven't manage to test
> that (we can't boot our machines if the BMC isn't already POSTed).
>
Hi Ben,

Barring the checkpatch.pl warnings/errors that you've spotted there's
a few other comments below.
I'm not familiar with the hardware, so it's just things that strike me
as odd ;-)


> +/*
> + * AST2500 DRAM settings modules
> + */
> +#define REGTBL_NUM   17
> +#define REGIDX_010   0
> +#define REGIDX_014   1
> +#define REGIDX_018   2
> +#define REGIDX_020   3
> +#define REGIDX_024   4
> +#define REGIDX_02C   5
> +#define REGIDX_030   6
> +#define REGIDX_214   7
> +#define REGIDX_2E0   8
> +#define REGIDX_2E4   9
> +#define REGIDX_2E8   10
> +#define REGIDX_2EC   11
> +#define REGIDX_2F0   12
> +#define REGIDX_2F4   13
> +#define REGIDX_2F8   14
> +#define REGIDX_RFC   15
> +#define REGIDX_PLL   16
These are used to address the correct value in the array, Worth using
C99 initailizer to ensure that things end in the right place ?
IIRC there was some security related GCC plugin which can fuzz the
order of array(?) and/or struct members ?

> +
> +static u32 ast2500_ddr3_1600_timing_table[REGTBL_NUM] = {

> +static u32 ast2500_ddr4_1600_timing_table[REGTBL_NUM] = {
These two are constant data, although you'll need to annotate the users as well.


> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -32,8 +32,6 @@
>  #include 
>  #include 
>
> -#include "ast_dram_tables.h"
> -
Unrelated change ?


> -   DRM_INFO("dram %d %d %d %08x\n", ast->mclk, ast->dram_type, 
> ast->dram_bus_width, ast->vram_size);
> +   DRM_INFO("dram MCLK=%u type=%d bus_width=%d size=%08x\n",
> +ast->mclk, ast->dram_type, ast->dram_bus_width, 
> ast->vram_size);
Unrelated change ?


>  static void ast_set_ext_reg(struct drm_crtc *crtc, struct drm_display_mode 
> *mode,
> @@ -421,7 +432,7 @@ static void ast_set_ext_reg(struct drm_crtc *crtc, struct 
> drm_display_mode *mode
> ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa8, 0xfd, jregA8);
>
> /* Set Threshold */
> -   if (ast->chip == AST2300 || ast->chip == AST2400) {
> +   if (ast->chip == AST2300 || ast->chip == AST2400 || ast->chip == 
> AST2500) {
> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa7, 0x78);
> ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa6, 0x60);
> } else if (ast->chip == AST2100 ||
> @@ -794,7 +805,7 @@ static int ast_mode_valid(struct drm_connector *connector,
> if ((mode->hdisplay == 1600) && (mode->vdisplay == 900))
> return MODE_OK;
>
> -   if ((ast->chip == AST2100) || (ast->chip == AST2200) || 
> (ast->chip == AST2300) || (ast->chip == AST2400) || (ast->chip == AST1180)) {
> +   if ((ast->chip == AST2100) || (ast->chip == AST2200) || 
> (ast->chip == AST2300) || (ast->chip == AST2400) || (ast->chip == AST2500) || 
> (ast->chip == AST1180)) {
178 columns is getting a bit too much.


> -static int mmc_test_burst(struct ast_private *ast, u32 datagen)
> +static int mmc_test(struct ast_private *ast, u32 datagen, u8 test_ctl)
>  {
> u32 data, timeout;
>
> ast_moutdwm(ast, 0x1e6e0070, 0x);
> -   ast_moutdwm(ast, 0x1e6e0070, 0x00c1 | (datagen << 3));
> +   ast_moutdwm(ast, 0x1e6e0070, (datagen << 3) | test_ctl);
> timeout = 0;
> do {
> data = ast_mindwm(ast, 0x1e6e0070) & 0x3000;
> if (data & 0x2000) {
> -   return 0;
> +   return -1;
> }
> if (++timeout > TIMEOUT) {
> ast_moutdwm(ast, 0x1e6e0070, 0x);
> -   return 0;
> +   return -1;
> }
> } while (!data);
> +   data = ast_mindwm(ast, 0x1e6e0078);
> +   data = (data | (data >> 16)) & 0x;
> ast_moutdwm(ast, 0x1e6e0070, 0x);
> -   return 1;
> +   return data;
>  }
>
> -static int mmc_test_burst2(struct ast_private *ast, u32 datagen)
> +
> +static int mmc_test_burst(struct ast_private *ast, u32 datagen)
>  {
> -   u32 data, timeout;
> +   return mmc_test(ast, datagen, 0xc1);
> +}
>
> -   ast_moutdwm(ast, 0x1e6e0070, 

Re: [PATCH] drm/amdgpu: fix warning on older gcc releases

[Alex Deucher]

On Fri, Feb 3, 2017 at 11:47 AM, Arnd Bergmann  wrote:
> gcc-4.8 warns about '{0}' being used an an initializer for nested structures:
>
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 
> ‘gfx_v8_0_ring_emit_ce_meta_init’:
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:7263:2: warning: missing braces around 
> initializer [-Wmissing-braces]
>   } ce_payload = {0};
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c: In function 
> ‘gfx_v8_0_ring_emit_de_meta_init’:
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c:7290:2: warning: missing braces around 
> initializer [-Wmissing-braces]
>   } de_payload = {0};
>
> Using an empty {} initializer however has the same effect and works on all 
> versions.
>
> Fixes: acad2b2a7b70 ("drm/amdgpu:implement CE/DE meta-init routines")
> Signed-off-by: Arnd Bergmann 

Applied.  thanks!

Alex

> ---
>  drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c 
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index 35f9cd83b821..cf1cb406b5ed 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -7260,7 +7260,7 @@ static void gfx_v8_0_ring_emit_ce_meta_init(struct 
> amdgpu_ring *ring, uint64_t c
> static union {
> struct amdgpu_ce_ib_state regular;
> struct amdgpu_ce_ib_state_chained_ib chained;
> -   } ce_payload = {0};
> +   } ce_payload = {};
>
> if (ring->adev->virt.chained_ib_support) {
> ce_payload_addr = csa_addr + offsetof(struct 
> amdgpu_gfx_meta_data_chained_ib, ce_payload);
> @@ -7287,7 +7287,7 @@ static void gfx_v8_0_ring_emit_de_meta_init(struct 
> amdgpu_ring *ring, uint64_t c
> static union {
> struct amdgpu_de_ib_state regular;
> struct amdgpu_de_ib_state_chained_ib chained;
> -   } de_payload = {0};
> +   } de_payload = {};
>
> gds_addr = csa_addr + 4096;
> if (ring->adev->virt.chained_ib_support) {
> --
> 2.9.0
>
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: Dealing with 90° rotated display ?

[Ville Syrjälä]

On Thu, Feb 16, 2017 at 11:01:29AM +0100, Hans de Goede wrote:
> Hi,
> 
> On 15-02-17 15:59, Ville Syrjälä wrote:
> > On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:
> >> Hi Jani,
> >>
> >> As discussed here:
> >>
> >> https://bugs.freedesktop.org/show_bug.cgi?id=94894
> >>
> >> I've a mini-laptop which uses a phone-screen,
> >> so the native orientation of the screen is portrait,
> >> where as for a clam-shell device one wants it to
> >> be landscape. Ideally there would be a flag somewhere
> >> to tell the i915 driver that the panel is mounted
> >> 90° rotated in its bezel and have the i915 driver
> >> apply that rotation on top of whatever rotation
> >> userspace requests.
> >>
> >> So question is there already a place (variable) in
> >> the i915 driver where one can set such a rotation
> >> offset to apply on top of what userspace requests ?
> >>
> >> If not do you have any idea how feasible adding one
> >> would be and can you give me a few pointers / hints
> >> where to start with such a thing ?
> >
> > You could have a look at my branch (which I pointed out in the bug).
> 
> Ok, so the patch that actually is relevant to this
> discussion (and not just a cleanup / bug-fix) seems to be:
> 
> https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e
> 
> Right ?

Looks that way, yes.

> 
> AFAICT that will make fbcon inherit the rotation setting of
> the primary plan on the primary crt. That may solve the
> original bug as reported, but not the case / device I'm
> talking about. What I would like to see is a "rotation offset"
> field somewhere to be applied to all rotations in a way which
> is hidden from userspace. Specifically the device I've has a
> screen which is 720x1280 in resolution, but I want userspace
> to see it as a 1280x720 screen because that is how it is used
> in the hardware. So I want a 90° rotation to be applied which
> is completely hidden from userspace.

That's not necessarily the best way since rotation may impose
additional restrictions on what the hardware can do. Which would
mean that your 0 degree setting would no longer be the setting
that should give the highest chance of success. That doesn't leave
much chance of userspace being able to work out a fallback strategy
when things don't succeed.

Oh, and the cursor plane can't even do 90/270 degree rotation, so
there's just no way to hide this fully.

That said, I did once implement a "full pipe rotation" thing, and even
added a knob into debugfs that allowed me to flip it without userspace
being involved. That's just something I used for testing the rotation
code initially. I just pushed some version of it here [1]. Obviously
90/270 effective rotation for the cursor still won't work.

[1] git://github.com/vsyrjala/linux.git full_pipe_rotation

> So when userspace
> (e.g. the Xorg server + modesetting driver) asks for 0° degree
> rotation under the hood they get 90 applied, when they aks for
> the panel resolution they get 1280x720 instead of 720x1280.

The idea was that userspace will inherit the initial rotation.
That does work correctly at least with the intel ddx. Given that our
rotation properties are per-plane, that would mean userspace would have
to deduce that the entire screen is rotation by simply looking at the
rotation of the primary plane. Or I suppose we could make the kernel
use the same default rotation for all planes, even the disabled ines.

> 
> Basically the idea is that the kernel as the HAL it is supposed
> to be (amongst other things) hide the hardware weirdness / quirk
> of using a portrait panel in a landscape bezel.

As said we can't really hide without causing additional grief to
userspace in the form of potential failures in configuring the
planes/crtcs.

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

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Emil Velikov]

On 16 February 2017 at 12:43, Tobias Jakobi
 wrote:
> Hello,
>
> I was wondering about the following. Wasn't there some strict
> requirement about code going upstream, which also included that there
> was a full open-source driver stack for it?
>
> I don't see how this is the case for Mali, neither in the kernel, nor in
> userspace. I'm aware that the Mali kernel driver is open-source. But it
> is not upstream, maintained out of tree, and won't land upstream in its
> current form (no resemblence to a DRM driver at all). And let's not talk
> about the userspace part.
>
> So, why should this be here?
>
Have to agree with Tobias, here.

I can see the annoyance that Maxime and others have to go through to
their systems working.
At the same time, changing upstream kernel to suit out of tree
module(s) is not how things work. Right ?

Not to mention that the series adds stable ABI exclusively(?) used by
a module which does not seem to be in the process of getting merged.

Maxime, you're a great guy but I don't think this is suitable for
upstream... yet.

Regards,
Emil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm: Always prepare null framebuffer in transitional helper

[Gabriel Krisman Bertazi]

Despite the documentation claim that cleanup_fb will match prior calls
to prepare_fb, in case of NULL framebuffers in the transitional helpers,
the code will skip the call to prepare_fb but not the corresponding
cleanup_fb call.  This asymmetry in semantics is unnecessarily surprising
for developers transitioning drivers to atomic model, specially because
the final atomic handlers don't have the issue - the prepare_fb is
always called, despite the new state framebuffer being null.

The only current user of the transitional helper that doesn't take care
of null framebuffers explicitly inside the prepare_fb hook is
atmel_hlcdc, so we take special care to make sure we don't break
anything there.

Signed-off-by: Gabriel Krisman Bertazi 
---
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c | 3 +++
 drivers/gpu/drm/drm_plane_helper.c  | 3 +--
 2 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c 
b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
index bd2791c4b002..886ed5d8e304 100644
--- a/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
+++ b/drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_plane.c
@@ -772,6 +772,9 @@ static int atmel_hlcdc_plane_prepare_fb(struct drm_plane *p,
drm_plane_state_to_atmel_hlcdc_plane_state(s);
int ret;
 
+   if (!new_state->fb)
+   return 0;
+
ret = atmel_hlcdc_layer_update_start(>layer);
if (!ret)
state->prepared = true;
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 148688fb920a..d8639e46bd2b 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -450,8 +450,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
goto out;
}
 
-   if (plane_funcs->prepare_fb && plane_state->fb &&
-   plane_state->fb != old_fb) {
+   if (plane_funcs->prepare_fb && plane_state->fb != old_fb) {
ret = plane_funcs->prepare_fb(plane,
  plane_state);
if (ret)
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 0/2] drm: Support framebuffer panning

[Neil Armstrong]

On 02/15/2017 05:19 PM, Maxime Ripard wrote:
> Hi,
> 
> This is a respin of the previous serie called "Support fast framebuffer
> panning for i.MX6" made by Stefan 6 monthes ago. The imx6 bits have been
> removed, and the comments that were made at that time fixed (hopefully).
> 
> Let me know what you think,
> Maxime
> 
> Changes from v2:
>   - Renamed the CONFIG_DRM_CMA_FBDEV_BUFFER_NUM to
> CONFIG_DRM_FBDEV_OVERALLOC, and changed it for a percentage
>   - Moved the overallocation code into the core fbdev helpers to not rely
> on CMA anymore
>   - Changed the locks taken by drm_fb_helper_ioctl to the mode_config mutex
> intead of calling drm_modeset_lock_all
>   - Don't test against drm_crtc's enabled anymore, but rely on the error
> code of drm_crtc_vblank_get instead
>   - Defined drm_fb_helper_ioctl when DRM_FBDEV_EMULATION is not set in
> order to fix a compilation error
>   - Don't wait for all CRTC's vblank but only the one given in the ioctl
> argument
> 
> Changes from v1:
>   - Added drm_fb_helper_ioctl to DRM_FB_HELPER_DEFAULT_OPS
>   - Expanded a bit the kerneldoc for drm_fb_helper_ioctl
>   - Added some locking to drm_fb_helper_ioctl
>   - Checked that the framebuffer is indeed attached before allowing ioctl
>   - Added a module parameter to specify the number of framebuffers to
> allocate
> 
> Initial cover letter: Support fast framebuffer panning for i.MX6
> 
> im currently working on supporting double/tripple buffering for the
> framebuffer emulation on the i.MX6.  While working on it I noticed that the
> mainline kernel does not support some features in the generic drm
> framebuffer emulation for framebuffer panning and vsync synchronisation.
> They are needed for simple framebuffer applications and some OpenGL
> libraries using double buffering with FBIOPUT_VSCREENINFO,
> FBIO_WAITFORVSYNC and FBIOPAN_DISPLAY.
> 
> Stefan Christ (1):
>   drm/fb-helper: implement ioctl FBIO_WAITFORVSYNC
> 
> Xinliang Liu (1):
>   drm/fb-helper: Add multi buffer support for cma fbdev
> 
>  drivers/gpu/drm/Kconfig |  9 -
>  drivers/gpu/drm/drm_fb_helper.c | 73 ++-
>  include/drm/drm_fb_helper.h | 12 +-
>  3 files changed, 93 insertions(+), 1 deletion(-)
> 
> base-commit: 0879b944c95d65f7523d178d3addaebe84e510ec
> 
Hi Maxime,

Just tested these patches on Amlogic GXBB to provide 3D Mali acceleration on 
framebuffer.

Tested-by: Neil Armstrong 

Thanks,
Neil
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[pull] radeon drm-fixes-4.10

[Alex Deucher]

Hi Dave,

Just one regression fix interlaced modes on radeon.

The following changes since commit 697d3a21615672b2bf7724a65755799260325dda:

  Merge tag 'drm-intel-fixes-2017-02-09' of 
git://anongit.freedesktop.org/git/drm-intel into drm-fixes (2017-02-10 10:14:24 
+1000)

are available in the git repository at:

  git://people.freedesktop.org/~agd5f/linux drm-fixes-4.10

for you to fetch changes up to d74c67dd7800fc7aae381f272875c337f268806c:

  drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor 
(2017-02-16 11:03:03 -0500)


Michel Dänzer (1):
  drm/radeon: Use mode h/vdisplay fields to hide out of bounds HW cursor

 drivers/gpu/drm/radeon/radeon_cursor.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99780] Flickering artifacts in radeonsi driver with divergent texture reads.

[bugzilla-daemon]

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

--- Comment #11 from Nicolai Hähnle  ---
Created attachment 129675
  --> https://bugs.freedesktop.org/attachment.cgi?id=129675=edit
Mesa patch

Yes, you need this patch for Mesa as well.

I'm going to pick up the LLVM patch again as well these days.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] gpu: ipu-v3: Stop overwriting pdev->dev.of_node of child devices

[Philipp Zabel]

Setting dev->of_node changes the modalias and breaks module autoloading.
Since there is an of_node field in the platform data passed to child
devices, we don't even need this anymore.

Suggested-by: Russell King 
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-common.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/gpu/ipu-v3/ipu-common.c b/drivers/gpu/ipu-v3/ipu-common.c
index 97218af4fe75c..8368e6f766ee5 100644
--- a/drivers/gpu/ipu-v3/ipu-common.c
+++ b/drivers/gpu/ipu-v3/ipu-common.c
@@ -1238,12 +1238,6 @@ static int ipu_add_client_devices(struct ipu_soc *ipu, 
unsigned long ipu_base)
platform_device_put(pdev);
goto err_register;
}
-
-   /*
-* Set of_node only after calling platform_device_add. Otherwise
-* the platform:imx-ipuv3-crtc modalias won't be used.
-*/
-   pdev->dev.of_node = of_node;
}
 
return 0;
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Ville Syrjälä]

On Thu, Feb 16, 2017 at 12:36:45PM +0200, Jani Nikula wrote:
> Handle debugfs override edid and firmware edid at the low level to
> transparently and completely replace the real edid. Previously, we
> practically only used the modes from the override EDID, and none of the
> other data. This also prevents actual EDID reads when the EDID is to be
> overridden, but retains the DDC probe.

Hmm. Isn't that a bad thing? If someone has broken DDC on their cable or
somethign then the override EDID wouldn't be returned by drm_get_edid().

> 
> FIXME: validate override edid, deduplicate firmware edid validation.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 15 +++
>  drivers/gpu/drm/drm_probe_helper.c | 19 +--
>  2 files changed, 16 insertions(+), 18 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 362036360724..054e2d74eafc 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
> *connector,
>   * level, drivers must make all reasonable efforts to expose it as an I2C
>   * adapter and use drm_get_edid() instead of abusing this function.
>   *
> + * The EDID may be overridden using debugfs override_edid or firmare EDID
> + * (drm_load_edid_firmware()), in this priority order. Having either of them
> + * bypasses actual EDID reads.
> + *
>   * Return: Pointer to valid EDID or NULL if we couldn't find any.
>   */
>  struct edid *drm_do_get_edid(struct drm_connector *connector,
> @@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
> *connector,
>  {
>   int i, j = 0, valid_extensions = 0;
>   u8 *edid, *new;
> + struct edid *override = NULL;
> +
> + if (connector->override_edid)
> + override = drm_edid_duplicate((const struct edid *)
> +   connector->edid_blob_ptr->data);
> +
> + if (!override)
> + override = drm_load_edid_firmware(connector);
> +
> + if (!IS_ERR_OR_NULL(override))
> + return override;
>  
>   if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
>   return NULL;
> diff --git a/drivers/gpu/drm/drm_probe_helper.c 
> b/drivers/gpu/drm/drm_probe_helper.c
> index 358957118ca9..871326cbc465 100644
> --- a/drivers/gpu/drm/drm_probe_helper.c
> +++ b/drivers/gpu/drm/drm_probe_helper.c
> @@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, 
> bool force)
>   *drm_mode_probed_add(). New modes start their life with status as OK.
>   *Modes are added from a single source using the following priority 
> order.
>   *
> - *- debugfs 'override_edid' (used for testing only)
> - *- firmware EDID (drm_load_edid_firmware())
>   *- _connector_helper_funcs.get_modes vfunc
>   *- if the connector status is connector_status_connected, standard
>   *  VESA DMT modes up to 1024x768 are automatically added
> @@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
> drm_connector *connector,
>   goto prune;
>   }
>  
> - if (connector->override_edid) {
> - struct edid *edid = (struct edid *) 
> connector->edid_blob_ptr->data;
> -
> - count = drm_add_edid_modes(connector, edid);
> - drm_edid_to_eld(connector, edid);
> - } else {
> - struct edid *edid = drm_load_edid_firmware(connector);
> - if (!IS_ERR_OR_NULL(edid)) {
> - drm_mode_connector_update_edid_property(connector, 
> edid);
> - count = drm_add_edid_modes(connector, edid);
> - drm_edid_to_eld(connector, edid);
> - kfree(edid);
> - }
> - if (count == 0)
> - count = (*connector_funcs->get_modes)(connector);
> - }
> + count = (*connector_funcs->get_modes)(connector);
>  
>   if (count == 0 && connector->status == connector_status_connected)
>   count = drm_add_modes_noedid(connector, 1024, 768);
> -- 
> 2.1.4

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

Re: [PATCH] drm/virtio: call drm_plane_cleanup() at destroy phase

[Gerd Hoffmann]

On Mi, 2017-02-15 at 16:00 -0200, Gustavo Padovan wrote:
> From: Gustavo Padovan 
> 
> virtio was missing this call to clean up core plane usage.
> 
> Signed-off-by: Gustavo Padovan 
> ---
>  drivers/gpu/drm/virtio/virtgpu_plane.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/virtio/virtgpu_plane.c 
> b/drivers/gpu/drm/virtio/virtgpu_plane.c
> index 11288ff..1ff9c64 100644
> --- a/drivers/gpu/drm/virtio/virtgpu_plane.c
> +++ b/drivers/gpu/drm/virtio/virtgpu_plane.c
> @@ -44,6 +44,7 @@ static const uint32_t virtio_gpu_cursor_formats[] = {
>  
>  static void virtio_gpu_plane_destroy(struct drm_plane *plane)
>  {
> + drm_plane_cleanup(plane);
>   kfree(plane);
>  }
>  

Applied to drm-misc-next

thanks,
  Gerd

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

[Ville Syrjälä]

On Thu, Feb 16, 2017 at 12:36:43PM +0200, Jani Nikula wrote:
> Make the function useful for resetting, not just setting, the ELD.
> 
> Signed-off-by: Jani Nikula 
> ---
>  drivers/gpu/drm/drm_edid.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
> index 24e7b282f16c..362036360724 100644
> --- a/drivers/gpu/drm/drm_edid.c
> +++ b/drivers/gpu/drm/drm_edid.c
> @@ -3430,6 +3430,9 @@ void drm_edid_to_eld(struct drm_connector *connector, 
> struct edid *edid)
>  
>   memset(eld, 0, sizeof(connector->eld));
>  
> + if (!edid)
> + return;
> +
>   connector->latency_present[0] = false;
>   connector->latency_present[1] = false;
>   connector->video_latency[0] = 0;

/me thinks the check should be after all these.

Hmm. Actually the cea ext block check below should be safe wrt.
edid==NULL, so not sure we need this at all.

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

[PATCH v4 5/5] drm/blend: Use new atomic iterator macros.

[Maarten Lankhorst]

There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_blend.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/drivers/gpu/drm/drm_blend.c b/drivers/gpu/drm/drm_blend.c
index d7053bb67db6..a0d0d6843288 100644
--- a/drivers/gpu/drm/drm_blend.c
+++ b/drivers/gpu/drm/drm_blend.c
@@ -377,26 +377,26 @@ int drm_atomic_normalize_zpos(struct drm_device *dev,
  struct drm_atomic_state *state)
 {
struct drm_crtc *crtc;
-   struct drm_crtc_state *crtc_state;
+   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
struct drm_plane *plane;
-   struct drm_plane_state *plane_state;
+   struct drm_plane_state *old_plane_state, *new_plane_state;
int i, ret = 0;
 
-   for_each_plane_in_state(state, plane, plane_state, i) {
-   crtc = plane_state->crtc;
+   for_each_oldnew_plane_in_state(state, plane, old_plane_state, 
new_plane_state, i) {
+   crtc = new_plane_state->crtc;
if (!crtc)
continue;
-   if (plane->state->zpos != plane_state->zpos) {
-   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
-   crtc_state->zpos_changed = true;
+   if (old_plane_state->zpos != new_plane_state->zpos) {
+   new_crtc_state = drm_atomic_get_new_crtc_state(state, 
crtc);
+   new_crtc_state->zpos_changed = true;
}
}
 
-   for_each_crtc_in_state(state, crtc, crtc_state, i) {
-   if (crtc_state->plane_mask != crtc->state->plane_mask ||
-   crtc_state->zpos_changed) {
+   for_each_oldnew_crtc_in_state(state, crtc, old_crtc_state, 
new_crtc_state, i) {
+   if (old_crtc_state->plane_mask != new_crtc_state->plane_mask ||
+   new_crtc_state->zpos_changed) {
ret = drm_atomic_helper_crtc_normalize_zpos(crtc,
-   crtc_state);
+   
new_crtc_state);
if (ret)
return ret;
}
-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 0/5] drm/atomic: Add accessor macros for all atomic state.

[Maarten Lankhorst]

Fifth iteration. Instead of trying to convert all drivers straight away,
implement all macros that are required to get state working.

Old situation:
Use obj->state, which can refer to old or new state.
Use drm_atomic_get_(existing_)obj_state, which can refer to new or old state.
Use for_each_obj_in_state, which refers to new or old state.

New situation:

During atomic check:
- Use drm_atomic_get_obj_state to add a object to the atomic state,
  or get the new state.
- Use drm_atomic_get_(old/new)_obj_state to peek at the new/old state,
  without adding the object. This will return NULL if the object is
  not part of the state. For planes and connectors the relevant crtc_state
  is added, so this will work to get the crtc_state from obj_state->crtc
  too, this means not having to write some error handling. 

During atomic commit:
- Do not use drm_atomic_get_obj_state, obj->state or 
drm_atomic_get_(existing_)obj_state
  any more, replace with drm_atomic_get_old/new_obj_state calls as required.

During both:
- Use for_each_(new,old,oldnew)_obj_in_state to get the old or new state as 
needed.
  oldnew will be renamed to for_each_obj_in_state after all callers are 
converted
  to the new api.

When not doing atomic updates:
Look at obj->state for now. I have some patches to fix this but I was asked to
make it return a const state. This breaks a lot of users though so I skipped 
that
patch in this iteration.

This series will return the correct state regardless of swapping.

Maarten Lankhorst (5):
  drm/atomic: Fix atomic helpers to use the new iterator macros, v2.
  drm/atomic: Make drm_atomic_plane_disabling easier to understand.
  drm/atomic: Add macros to access existing old/new state, v2.
  drm/atomic: Convert get_existing_state callers to get_old/new_state,
v3.
  drm/blend: Use new atomic iterator macros.

 drivers/gpu/drm/drm_atomic.c|   6 +-
 drivers/gpu/drm/drm_atomic_helper.c | 469 
 drivers/gpu/drm/drm_blend.c |  23 +-
 drivers/gpu/drm/drm_plane_helper.c  |   2 +-
 drivers/gpu/drm/drm_simple_kms_helper.c |   4 +-
 include/drm/drm_atomic.h| 108 
 include/drm/drm_atomic_helper.h |  26 +-
 7 files changed, 375 insertions(+), 263 deletions(-)

-- 
2.7.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v4 3/5] drm/atomic: Add macros to access existing old/new state, v2.

[Maarten Lankhorst]

After atomic commit, these macros should be used in place of
get_existing_state. Also after commit get_xx_state should no longer
be used because it may not have the required locks.

The calls to drm_atomic_get_existing_$obj_state should no longer be
used, and converted over to these new calls.

Changes since v1:
- Expand commit message.
- Deprecate get_existing_*_state functions in the documentation.

Signed-off-by: Maarten Lankhorst 
---
 include/drm/drm_atomic.h | 108 +++
 1 file changed, 108 insertions(+)

diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
index c6f355a970d2..0147a047878d 100644
--- a/include/drm/drm_atomic.h
+++ b/include/drm/drm_atomic.h
@@ -277,6 +277,9 @@ int drm_atomic_connector_set_property(struct drm_connector 
*connector,
  *
  * This function returns the crtc state for the given crtc, or NULL
  * if the crtc is not part of the global atomic state.
+ *
+ * This function is deprecated, @drm_atomic_get_old_crtc_state or
+ * @drm_atomic_get_new_crtc_state should be used instead.
  */
 static inline struct drm_crtc_state *
 drm_atomic_get_existing_crtc_state(struct drm_atomic_state *state,
@@ -286,12 +289,44 @@ drm_atomic_get_existing_crtc_state(struct 
drm_atomic_state *state,
 }
 
 /**
+ * drm_atomic_get_old_crtc_state - get old crtc state, if it exists
+ * @state: global atomic state object
+ * @crtc: crtc to grab
+ *
+ * This function returns the old crtc state for the given crtc, or
+ * NULL if the crtc is not part of the global atomic state.
+ */
+static inline struct drm_crtc_state *
+drm_atomic_get_old_crtc_state(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+   return state->crtcs[drm_crtc_index(crtc)].old_state;
+}
+/**
+ * drm_atomic_get_new_crtc_state - get new crtc state, if it exists
+ * @state: global atomic state object
+ * @crtc: crtc to grab
+ *
+ * This function returns the new crtc state for the given crtc, or
+ * NULL if the crtc is not part of the global atomic state.
+ */
+static inline struct drm_crtc_state *
+drm_atomic_get_new_crtc_state(struct drm_atomic_state *state,
+ struct drm_crtc *crtc)
+{
+   return state->crtcs[drm_crtc_index(crtc)].new_state;
+}
+
+/**
  * drm_atomic_get_existing_plane_state - get plane state, if it exists
  * @state: global atomic state object
  * @plane: plane to grab
  *
  * This function returns the plane state for the given plane, or NULL
  * if the plane is not part of the global atomic state.
+ *
+ * This function is deprecated, @drm_atomic_get_old_plane_state or
+ * @drm_atomic_get_new_plane_state should be used instead.
  */
 static inline struct drm_plane_state *
 drm_atomic_get_existing_plane_state(struct drm_atomic_state *state,
@@ -301,12 +336,45 @@ drm_atomic_get_existing_plane_state(struct 
drm_atomic_state *state,
 }
 
 /**
+ * drm_atomic_get_old_plane_state - get plane state, if it exists
+ * @state: global atomic state object
+ * @plane: plane to grab
+ *
+ * This function returns the old plane state for the given plane, or
+ * NULL if the plane is not part of the global atomic state.
+ */
+static inline struct drm_plane_state *
+drm_atomic_get_old_plane_state(struct drm_atomic_state *state,
+  struct drm_plane *plane)
+{
+   return state->planes[drm_plane_index(plane)].old_state;
+}
+
+/**
+ * drm_atomic_get_new_plane_state - get plane state, if it exists
+ * @state: global atomic state object
+ * @plane: plane to grab
+ *
+ * This function returns the new plane state for the given plane, or
+ * NULL if the plane is not part of the global atomic state.
+ */
+static inline struct drm_plane_state *
+drm_atomic_get_new_plane_state(struct drm_atomic_state *state,
+  struct drm_plane *plane)
+{
+   return state->planes[drm_plane_index(plane)].new_state;
+}
+
+/**
  * drm_atomic_get_existing_connector_state - get connector state, if it exists
  * @state: global atomic state object
  * @connector: connector to grab
  *
  * This function returns the connector state for the given connector,
  * or NULL if the connector is not part of the global atomic state.
+ *
+ * This function is deprecated, @drm_atomic_get_old_connector_state or
+ * @drm_atomic_get_new_connector_state should be used instead.
  */
 static inline struct drm_connector_state *
 drm_atomic_get_existing_connector_state(struct drm_atomic_state *state,
@@ -321,6 +389,46 @@ drm_atomic_get_existing_connector_state(struct 
drm_atomic_state *state,
 }
 
 /**
+ * drm_atomic_get_old_connector_state - get connector state, if it exists
+ * @state: global atomic state object
+ * @connector: connector to grab
+ *
+ * This function returns the old connector state for the given connector,
+ * or NULL if the connector is not part of the global atomic state.
+ */
+static inline struct drm_connector_state *

[PATCH v4 1/5] drm/atomic: Fix atomic helpers to use the new iterator macros, v2.

[Maarten Lankhorst]

There are new iterator macros that annotate whether the new or old
state should be used. This is better than using a state that depends on
whether it's called before or after swap. For clarity, also rename the
variables from $obj_state to (old,new)_$obj_state as well.

Changes since v1:
- Use old/new_*_state for variable names as much as possible. (pinchartl)
- Expand commit message.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c | 431 +++-
 1 file changed, 222 insertions(+), 209 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 9203f3e933f7..7d432d9a18cf 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -63,14 +63,15 @@
  */
 static void
 drm_atomic_helper_plane_changed(struct drm_atomic_state *state,
+   struct drm_plane_state *old_plane_state,
struct drm_plane_state *plane_state,
struct drm_plane *plane)
 {
struct drm_crtc_state *crtc_state;
 
-   if (plane->state->crtc) {
+   if (old_plane_state->crtc) {
crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane->state->crtc);
+   
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -92,7 +93,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
 static int handle_conflicting_encoders(struct drm_atomic_state *state,
   bool disable_conflicting_encoders)
 {
-   struct drm_connector_state *conn_state;
+   struct drm_connector_state *new_conn_state;
struct drm_connector *connector;
struct drm_connector_list_iter conn_iter;
struct drm_encoder *encoder;
@@ -104,15 +105,15 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 * part of the state. If the same encoder is assigned to multiple
 * connectors bail out.
 */
-   for_each_connector_in_state(state, connector, conn_state, i) {
+   for_each_new_connector_in_state(state, connector, new_conn_state, i) {
const struct drm_connector_helper_funcs *funcs = 
connector->helper_private;
struct drm_encoder *new_encoder;
 
-   if (!conn_state->crtc)
+   if (!new_conn_state->crtc)
continue;
 
if (funcs->atomic_best_encoder)
-   new_encoder = funcs->atomic_best_encoder(connector, 
conn_state);
+   new_encoder = funcs->atomic_best_encoder(connector, 
new_conn_state);
else if (funcs->best_encoder)
new_encoder = funcs->best_encoder(connector);
else
@@ -166,20 +167,20 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
goto out;
}
 
-   conn_state = drm_atomic_get_connector_state(state, connector);
-   if (IS_ERR(conn_state)) {
-   ret = PTR_ERR(conn_state);
+   new_conn_state = drm_atomic_get_connector_state(state, 
connector);
+   if (IS_ERR(new_conn_state)) {
+   ret = PTR_ERR(new_conn_state);
goto out;
}
 
DRM_DEBUG_ATOMIC("[ENCODER:%d:%s] in use on [CRTC:%d:%s], 
disabling [CONNECTOR:%d:%s]\n",
 encoder->base.id, encoder->name,
-conn_state->crtc->base.id, 
conn_state->crtc->name,
+new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
conn_state->crtc);
+   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_conn_state->crtc);
 
-   ret = drm_atomic_set_crtc_for_connector(conn_state, NULL);
+   ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
if (ret)
goto out;
 
@@ -245,22 +246,22 @@ steal_encoder(struct drm_atomic_state *state,
 {
struct drm_crtc_state *crtc_state;
struct drm_connector *connector;
-   struct drm_connector_state *connector_state;
+   struct drm_connector_state *old_connector_state, *new_connector_state;
int i;
 
-   for_each_connector_in_state(state, connector, connector_state, i) {
+   for_each_oldnew_connector_in_state(state, connector, 
old_connector_state, new_connector_state, i) {
struct drm_crtc *encoder_crtc;
 
-   if (connector_state->best_encoder != encoder)
+ 

[PATCH v4 4/5] drm/atomic: Convert get_existing_state callers to get_old/new_state, v3.

[Maarten Lankhorst]

This is a straightforward conversion that converts all the users of
get_existing_state in atomic core to use get_old_state or get_new_state

Changes since v1:
- Fix using the wrong state in drm_atomic_helper_update_legacy_modeset_state.
Changes since v2:
- Use the correct state in disable_outputs()

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic.c|  6 ++---
 drivers/gpu/drm/drm_atomic_helper.c | 43 +
 drivers/gpu/drm/drm_blend.c |  3 +--
 drivers/gpu/drm/drm_simple_kms_helper.c |  4 +--
 4 files changed, 28 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
index afec53832145..c9aac9cbf111 100644
--- a/drivers/gpu/drm/drm_atomic.c
+++ b/drivers/gpu/drm/drm_atomic.c
@@ -1358,8 +1358,8 @@ drm_atomic_set_crtc_for_connector(struct 
drm_connector_state *conn_state,
return 0;
 
if (conn_state->crtc) {
-   crtc_state = 
drm_atomic_get_existing_crtc_state(conn_state->state,
-   
conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(conn_state->state,
+  conn_state->crtc);
 
crtc_state->connector_mask &=
~(1 << drm_connector_index(conn_state->connector));
@@ -1476,7 +1476,7 @@ drm_atomic_add_affected_planes(struct drm_atomic_state 
*state,
 {
struct drm_plane *plane;
 
-   WARN_ON(!drm_atomic_get_existing_crtc_state(state, crtc));
+   WARN_ON(!drm_atomic_get_new_crtc_state(state, crtc));
 
drm_for_each_plane_mask(plane, state->dev, crtc->state->plane_mask) {
struct drm_plane_state *plane_state =
diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index ea544bddc29b..6296ae6e6aff 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -70,8 +70,8 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
struct drm_crtc_state *crtc_state;
 
if (old_plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
old_plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state,
+  
old_plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -80,8 +80,7 @@ drm_atomic_helper_plane_changed(struct drm_atomic_state 
*state,
}
 
if (plane_state->crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state,
-   
plane_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
plane_state->crtc);
 
if (WARN_ON(!crtc_state))
return;
@@ -150,7 +149,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
drm_for_each_connector_iter(connector, _iter) {
struct drm_crtc_state *crtc_state;
 
-   if (drm_atomic_get_existing_connector_state(state, connector))
+   if (drm_atomic_get_new_connector_state(state, connector))
continue;
 
encoder = connector->state->best_encoder;
@@ -178,7 +177,7 @@ static int handle_conflicting_encoders(struct 
drm_atomic_state *state,
 new_conn_state->crtc->base.id, 
new_conn_state->crtc->name,
 connector->base.id, connector->name);
 
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
new_conn_state->crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, 
new_conn_state->crtc);
 
ret = drm_atomic_set_crtc_for_connector(new_conn_state, NULL);
if (ret)
@@ -219,7 +218,7 @@ set_best_encoder(struct drm_atomic_state *state,
 */
WARN_ON(!crtc && encoder != conn_state->best_encoder);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask &=
~(1 << 
drm_encoder_index(conn_state->best_encoder));
@@ -230,7 +229,7 @@ set_best_encoder(struct drm_atomic_state *state,
crtc = conn_state->crtc;
WARN_ON(!crtc);
if (crtc) {
-   crtc_state = drm_atomic_get_existing_crtc_state(state, 
crtc);
+   crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
 
crtc_state->encoder_mask |=
1 << drm_encoder_index(encoder);
@@ 

[PATCH v4 2/5] drm/atomic: Make drm_atomic_plane_disabling easier to understand.

[Maarten Lankhorst]

This function becomes a lot simpler when having passed both the old and
new state to it. Looking at all callers, it seems that old_plane_state
is never NULL so the check can be dropped.

Signed-off-by: Maarten Lankhorst 
---
 drivers/gpu/drm/drm_atomic_helper.c |  7 ---
 drivers/gpu/drm/drm_plane_helper.c  |  2 +-
 include/drm/drm_atomic_helper.h | 26 --
 3 files changed, 13 insertions(+), 22 deletions(-)

diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
b/drivers/gpu/drm/drm_atomic_helper.c
index 7d432d9a18cf..ea544bddc29b 100644
--- a/drivers/gpu/drm/drm_atomic_helper.c
+++ b/drivers/gpu/drm/drm_atomic_helper.c
@@ -1757,7 +1757,8 @@ void drm_atomic_helper_commit_planes(struct drm_device 
*dev,
if (!funcs)
continue;
 
-   disabling = drm_atomic_plane_disabling(plane, old_plane_state);
+   disabling = drm_atomic_plane_disabling(old_plane_state,
+  new_plane_state);
 
if (active_only) {
/*
@@ -1852,11 +1853,11 @@ drm_atomic_helper_commit_planes_on_crtc(struct 
drm_crtc_state *old_crtc_state)
 
WARN_ON(plane->state->crtc && plane->state->crtc != crtc);
 
-   if (drm_atomic_plane_disabling(plane, old_plane_state) &&
+   if (drm_atomic_plane_disabling(old_plane_state, plane->state) &&
plane_funcs->atomic_disable)
plane_funcs->atomic_disable(plane, old_plane_state);
else if (plane->state->crtc ||
-drm_atomic_plane_disabling(plane, old_plane_state))
+drm_atomic_plane_disabling(old_plane_state, 
plane->state))
plane_funcs->atomic_update(plane, old_plane_state);
}
 
diff --git a/drivers/gpu/drm/drm_plane_helper.c 
b/drivers/gpu/drm/drm_plane_helper.c
index 148688fb920a..f4d70dd5e3e4 100644
--- a/drivers/gpu/drm/drm_plane_helper.c
+++ b/drivers/gpu/drm/drm_plane_helper.c
@@ -470,7 +470,7 @@ int drm_plane_helper_commit(struct drm_plane *plane,
 * Drivers may optionally implement the ->atomic_disable callback, so
 * special-case that here.
 */
-   if (drm_atomic_plane_disabling(plane, plane_state) &&
+   if (drm_atomic_plane_disabling(plane_state, plane->state) &&
plane_funcs->atomic_disable)
plane_funcs->atomic_disable(plane, plane_state);
else
diff --git a/include/drm/drm_atomic_helper.h b/include/drm/drm_atomic_helper.h
index 9ceda379ce58..dc16274987c7 100644
--- a/include/drm/drm_atomic_helper.h
+++ b/include/drm/drm_atomic_helper.h
@@ -220,10 +220,10 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
  
__drm_atomic_get_current_plane_state((crtc_state)->state, \
   plane)))
 
-/*
+/**
  * drm_atomic_plane_disabling - check whether a plane is being disabled
- * @plane: plane object
- * @old_state: previous atomic state
+ * @old_plane_state: old atomic plane state
+ * @new_plane_state: new atomic plane state
  *
  * Checks the atomic state of a plane to determine whether it's being disabled
  * or not. This also WARNs if it detects an invalid state (both CRTC and FB
@@ -233,28 +233,18 @@ int drm_atomic_helper_legacy_gamma_set(struct drm_crtc 
*crtc,
  * True if the plane is being disabled, false otherwise.
  */
 static inline bool
-drm_atomic_plane_disabling(struct drm_plane *plane,
-  struct drm_plane_state *old_state)
+drm_atomic_plane_disabling(struct drm_plane_state *old_plane_state,
+  struct drm_plane_state *new_plane_state)
 {
/*
 * When disabling a plane, CRTC and FB should always be NULL together.
 * Anything else should be considered a bug in the atomic core, so we
 * gently warn about it.
 */
-   WARN_ON((plane->state->crtc == NULL && plane->state->fb != NULL) ||
-   (plane->state->crtc != NULL && plane->state->fb == NULL));
+   WARN_ON((new_plane_state->crtc == NULL && new_plane_state->fb != NULL) 
||
+   (new_plane_state->crtc != NULL && new_plane_state->fb == NULL));
 
-   /*
-* When using the transitional helpers, old_state may be NULL. If so,
-* we know nothing about the current state and have to assume that it
-* might be enabled.
-*
-* When using the atomic helpers, old_state won't be NULL. Therefore
-* this check assumes that either the driver will have reconstructed
-* the correct state in ->reset() or that the driver will have taken
-* appropriate measures to disable all planes.
-*/
-   return (!old_state || old_state->crtc) && !plane->state->crtc;
+   return old_plane_state->crtc && !new_plane_state->crtc;
 }
 
 #endif /* 

Re: [PATCH v3 6/7] drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.

[Maarten Lankhorst]

Op 17-01-17 om 02:12 schreef Laurent Pinchart:
> Hi Maarten,
>
> Thank you for the patch.
>
> I don't think you need the "v2" at the end of the subject line.
>
> On Monday 16 Jan 2017 10:37:43 Maarten Lankhorst wrote:
>> This is a straightforward conversion that converts all the users of
>> get_existing_state in atomic core to use get_old_state or get_new_state
>>
>> Changes since v1:
>> - Fix using the wrong state in
>> drm_atomic_helper_update_legacy_modeset_state.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic.c|  6 +++---
>>  drivers/gpu/drm/drm_atomic_helper.c | 39 +++--
>>  drivers/gpu/drm/drm_blend.c |  3 +--
>>  3 files changed, 22 insertions(+), 26 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 7b61e0da9ace..6428e9469607 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
> [snip]
>
>> @@ -1835,7 +1832,7 @@ drm_atomic_helper_commit_planes_on_crtc(struct
>> drm_crtc_state *old_crtc_state)
>>
>>  drm_for_each_plane_mask(plane, crtc->dev, plane_mask) {
>>  struct drm_plane_state *old_plane_state =
>> -drm_atomic_get_existing_plane_state(old_state, plane);
>> +drm_atomic_get_old_plane_state(old_state, plane);
> I believe this change to be correct, but given that the function is called 
> after state swap, didn't it use the new state before this patch ?
get_existing_state returns the old state after swap.

But the call to drm_atomic_plane_disabling is confusing to me. I'm changing
the function to pass old and new plane state, which should make it easier to 
understand.

Cheers,
~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 6/7] drm/atomic: Convert get_existing_state callers to get_old/new_state, v2.

[Maarten Lankhorst]

Op 17-01-17 om 02:27 schreef Laurent Pinchart:
> Hi Maarten,
>
> One more thing.
>
> On Monday 16 Jan 2017 10:37:43 Maarten Lankhorst wrote:
>> This is a straightforward conversion that converts all the users of
>> get_existing_state in atomic core to use get_old_state or get_new_state
>>
>> Changes since v1:
>> - Fix using the wrong state in
>> drm_atomic_helper_update_legacy_modeset_state.
>>
>> Signed-off-by: Maarten Lankhorst 
>> ---
>>  drivers/gpu/drm/drm_atomic.c|  6 +++---
>>  drivers/gpu/drm/drm_atomic_helper.c | 39 ++
>>  drivers/gpu/drm/drm_blend.c |  3 +--
>>  3 files changed, 22 insertions(+), 26 deletions(-)
> [snip]
>
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c
>> b/drivers/gpu/drm/drm_atomic_helper.c index b26cf786ce12..1de8d5fbc8d3
>> 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> [snip]
>
>> @@ -698,8 +695,7 @@ disable_outputs(struct drm_device *dev, struct
>> drm_atomic_state *old_state) if (!old_conn_state->crtc)
>>  continue;
>>
>> -old_crtc_state = drm_atomic_get_existing_crtc_state(old_state,
>> -
> old_conn_state->crtc);
>> +old_crtc_state = drm_atomic_get_new_crtc_state(old_state,
>> old_conn_state->crtc);
> This looks wrong. I believe you should call drm_atomic_get_old_crtc_state() 
> here. If I'm not mistaken drm_atomic_get_existing_crtc_state() did the right 
> thing as old_state->crtcs[*].state was set to the old state by the state swap 
> operation.
This is wrong, even. Fixed in next version. At least looking at the code made 
it obvious. :)
> On the other hand, drm_atomic_helper_update_legacy_modeset_state() uses 
> drm_atomic_get_new_plane_state() the same way you do here, even though it 
> operates after state swap, and your changelog specifically mentions that 
> you've fixed that in v2. It's getting too late to properly wrap my head 
> around 
> this, I'll let you check which option is correct (but I reserve the right to 
> challenge it if your explanation isn't convincing enough ;-)).
update_legacy_modeset_state was looking at primary->state (new state) before,
but was using get_existing_state to check whether it's part of the commit, so 
it's
valid to look at plane->state.

This was fixed to get the new state, so it makes sense there.
>>  if (!old_crtc_state->active ||
>>  !drm_atomic_crtc_needs_modeset(old_conn_state->crtc-
>> state))


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 22/24] drm/rockchip: dw-mipi-dsi: support non-burst modes

[John Keeping]

On Thu, 16 Feb 2017 11:01:46 +0800, Chris Zhong wrote:

> On 02/01/2017 03:22 AM, Sean Paul wrote:
> > On Sun, Jan 29, 2017 at 01:24:42PM +, John Keeping wrote:
> >
> > Reviewed-by: Sean Paul 
> >  
> >> Signed-off-by: John Keeping 
> >> Reviewed-by: Chris Zhong 
> >> ---
> >> v3:
> >> - Add Chris' Reviewed-by
> >> Unchanged in v2
> >>
> >>   drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 16 +---
> >>   1 file changed, 9 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> >> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> index 5bad92e2370e..58cb8ace2fe8 100644
> >> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >> @@ -82,6 +82,7 @@
> >>   #define FRAME_BTA_ACKBIT(14)
> >>   #define ENABLE_LOW_POWER (0x3f << 8)
> >>   #define ENABLE_LOW_POWER_MASK(0x3f << 8)
> >> +#define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS   0x1
> >>   #define VID_MODE_TYPE_BURST_SYNC_PULSES  0x2  
> This field indicates the video mode transmission type as follows:
> 00: Non-burst with sync pulses
> 01: Non-burst with sync events
> 10 and 11: Burst mode
> 
> So, I think define the macro like this is better:
> 
> #define VID_MODE_TYPE_NON_BURST_SYNC_PULSES0x0
> #define VID_MODE_TYPE_NON_BURST_SYNC_EVENTS0x1
> #define VID_MODE_TYPE_BURST0x2
> 
> 
> >>   #define VID_MODE_TYPE_MASK   0x3
> >>   
> >> @@ -286,6 +287,7 @@ struct dw_mipi_dsi {
> >>u32 format;
> >>u16 input_div;
> >>u16 feedback_div;
> >> +  unsigned long mode_flags;
> >>   
> >>const struct dw_mipi_dsi_plat_data *pdata;
> >>   };
> >> @@ -551,15 +553,10 @@ static int dw_mipi_dsi_host_attach(struct 
> >> mipi_dsi_host *host,
> >>return -EINVAL;
> >>}
> >>   
> >> -  if (!(device->mode_flags & MIPI_DSI_MODE_VIDEO_BURST) ||
> >> -  !(device->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)) {
> >> -  dev_err(dsi->dev, "device mode is unsupported\n");
> >> -  return -EINVAL;
> >> -  }
> >> -
> >>dsi->lanes = device->lanes;
> >>dsi->channel = device->channel;
> >>dsi->format = device->format;
> >> +  dsi->mode_flags = device->mode_flags;
> >>dsi->panel = of_drm_find_panel(device->dev.of_node);
> >>if (dsi->panel)
> >>return drm_panel_attach(dsi->panel, >connector);
> >> @@ -716,7 +713,12 @@ static void dw_mipi_dsi_video_mode_config(struct 
> >> dw_mipi_dsi *dsi)
> >>   {
> >>u32 val;
> >>   
> >> -  val = VID_MODE_TYPE_BURST_SYNC_PULSES | ENABLE_LOW_POWER;
> >> +  val = ENABLE_LOW_POWER;
> >> +
> >> +  if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
> >> +  val |= VID_MODE_TYPE_BURST_SYNC_PULSES;
> >> +  else if (!(dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE))
> >> +  val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;  
> 
> if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_BURST)
>   val |= VID_MODE_TYPE_BURST;
> else if (dsi->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
>   val |= VID_MODE_TYPE_NON_BURST_SYNC_PULSES;
> else
>   val |= VID_MODE_TYPE_NON_BURST_SYNC_EVENTS;

OK, this is definitely clearer now that I've forgotten most of the
datasheet; without your definitions at the top it's not clear that
VID_MODE_TYPE_BURST_SYNC_PULSES is zero.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 23/24] drm/rockchip: dw-mipi-dsi: add reset control

[John Keeping]

On Thu, 16 Feb 2017 10:12:33 +0800, Chris Zhong wrote:

> On 02/15/2017 08:39 PM, John Keeping wrote:
> > On Wed, 15 Feb 2017 11:38:45 +0800, Chris Zhong wrote:
> >  
> >> On 01/29/2017 09:24 PM, John Keeping wrote:  
> >>> In order to fully reset the state of the MIPI controller we must assert
> >>> this reset.
> >>>
> >>> This is slightly more complicated than it could be in order to maintain
> >>> compatibility with device trees that do not specify the reset property.
> >>>
> >>> Signed-off-by: John Keeping 
> >>> Reviewed-by: Chris Zhong 
> >>> ---
> >>> v3:
> >>> - Add Chris' Reviewed-by
> >>> Unchanged in v2
> >>>
> >>>drivers/gpu/drm/rockchip/dw-mipi-dsi.c | 30 
> >>> ++
> >>>1 file changed, 30 insertions(+)
> >>>
> >>> diff --git a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c 
> >>> b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >>> index 58cb8ace2fe8..cf3ca6b0cbdb 100644
> >>> --- a/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >>> +++ b/drivers/gpu/drm/rockchip/dw-mipi-dsi.c
> >>> @@ -13,6 +13,7 @@
> >>>#include 
> >>>#include 
> >>>#include 
> >>> +#include 
> >>>#include 
> >>>#include 
> >>>#include 
> >>> @@ -1124,6 +1125,7 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> >>> struct device *master,
> >>>   of_match_device(dw_mipi_dsi_dt_ids, dev);
> >>>   const struct dw_mipi_dsi_plat_data *pdata = of_id->data;
> >>>   struct platform_device *pdev = to_platform_device(dev);
> >>> + struct reset_control *apb_rst;
> >>>   struct drm_device *drm = data;
> >>>   struct dw_mipi_dsi *dsi;
> >>>   struct resource *res;
> >>> @@ -1162,6 +1164,34 @@ static int dw_mipi_dsi_bind(struct device *dev, 
> >>> struct device *master,
> >>>   return ret;
> >>>   }
> >>>
> >>> + /*
> >>> +  * Note that the reset was not defined in the initial device tree, so
> >>> +  * we have to be prepared for it not being found.
> >>> +  */
> >>> + apb_rst = devm_reset_control_get(dev, "apb");
> >>> + if (IS_ERR(apb_rst)) {
> >>> + if (PTR_ERR(apb_rst) == -ENODEV) {  
> >> According to [0], I think it should be -ENOENT here.  
> > Nice catch, I'll fix this.
> >  
> >> [0]
> >> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git/commit/?id=3d81216fde465e76c5eae98f61d3666163634395
> >>
> >> commit 3d81216fde465e76c5eae98f61d3666163634395
> >> Author: Alban Bedel 
> >> Date:   Tue Sep 1 17:28:31 2015 +0200
> >>
> >>   reset: Fix of_reset_control_get() for consistent return values
> >>
> >>   When of_reset_control_get() is called without connection ID it 
> >> returns
> >>   -ENOENT when the 'resets' property doesn't exists or is an empty 
> >> entry.
> >>   However when a connection ID is given it returns -EINVAL when the
> >> 'resets'
> >>   property doesn't exists or the requested name can't be found. This is
> >>   because the error code returned by of_property_match_string() is just
> >>   passed down as an index to of_parse_phandle_with_args(), which then
> >>   returns -EINVAL.
> >>
> >>   To get a consistent return value with both code paths we must return
> >>   -ENOENT when of_property_match_string() fails.
> >>
> >>   Signed-off-by: Alban Bedel 
> >>   Signed-off-by: Philipp Zabel 
> >>
> >>  
> >>> + apb_rst = NULL;
> >>> + } else {
> >>> + dev_err(dev, "Unable to get reset control: %d\n", ret); 
> >>>  
> Also, we can not get error number from "ret" here.

Good point, I'll fix this.


John
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

siyia  changed:

   What|Removed |Added

Version|13.0|17.0

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

--- Comment #28 from siyia  ---
Created attachment 129669
  --> https://bugs.freedesktop.org/attachment.cgi?id=129669=edit
apitrace of TW warhammer

bug happens also with latest mesa stable independently of llvm version.

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 99136] Blood Effects Total War: Warhammer

[bugzilla-daemon]

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

--- Comment #27 from siyia  ---
(In reply to Samuel Pitoiset from comment #26)
> Can you upload the trace somewhere?

will try

-- 
You are receiving this mail because:
You are the assignee for the bug.___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 0/8] ARM: sun8i: a33: Mali improvements

[Tobias Jakobi]

Hello,

I was wondering about the following. Wasn't there some strict
requirement about code going upstream, which also included that there
was a full open-source driver stack for it?

I don't see how this is the case for Mali, neither in the kernel, nor in
userspace. I'm aware that the Mali kernel driver is open-source. But it
is not upstream, maintained out of tree, and won't land upstream in its
current form (no resemblence to a DRM driver at all). And let's not talk
about the userspace part.

So, why should this be here?

With best wishes,
Tobias

P.S.: I'm signed up to dri-devel in digest mode, so sorry if this mail
doesn't properly show up in the corresponding ml thread.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[GIT PULL] omapdrm fixes for v4.11

[Tomi Valkeinen]

Hi Dave,

Please pull these omapdrm fixes for v4.11.

 Tomi

The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:

  Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-02-10 10:13:30 +1000)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tomba/linux.git 
tags/omapdrm-4.11-fixes

for you to fetch changes up to 1b30ab0c40a99da347c1ab83c30b485e03fe9f64:

  drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats 
(2017-02-16 14:11:08 +0200)


omapdrm fixes for v4.11

Fix regressions:
- Planes might have been left enabled
- Scaling checks did not use the new config

Also limit downscaling decimation to prevent HW underflows.


Jyri Sarha (3):
  Revert "drm: omapdrm: Let the DRM core skip plane commit on inactive 
CRTCs"
  drm/omapdrm: Move commit_modeset_enables() before commit_planes()
  drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

 drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
 drivers/gpu/drm/omapdrm/omap_crtc.c |  8 +---
 drivers/gpu/drm/omapdrm/omap_drv.c  | 17 +++--
 3 files changed, 35 insertions(+), 9 deletions(-)



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] drm/cma-helper: Add multi buffer support for cma fbdev

[Tobias Jakobi]

Hello,

I'm not sure if I'm missing something here, but I don't see how this is
supposed to work.

This just multiplies the height of the drm_mode_fb_cmd2 object with the
number of buffers. Let's say I have width=1024, height=768, then now I
have a framebuffer which has height=2304 (in the num_buffers=3 case). At
some point this FB is set as the primary plane, giving us a 1024x2304
mode. I don't think that this is intended.

In my opinion this multi-buffer thing should touch drm_mode_fb_cmd2 at
all. The underlying BO should be larger, but not the FB itself. If this
is supposed to work, then the fbdev helpers should create as many FBs as
there are buffers, and then offset each of these FB into the BO.

What I'm also not seeing is code that handles the fbdev's virtual
resolutions. After all num_buffers should only increase those. Same for
the panning ioctl().

So, is this just a part of a larger series?

I remember seeing such a hack in the Hardkernel vendor kernel. But there
it only worked because of some bug in the crtc (mixer) code.

With best wishes,
Tobias


P.S.: I'm signed up to dri-devel in digest mode, so sorry if this mail
doesn't properly show up in the corresponding ml thread.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch v2] drm/msm/dsi: free first element on error

[Jani Nikula]

On Thu, 16 Feb 2017, Rob Clark  wrote:
> On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter  
> wrote:
>> We're off by one here.  We free something that wasn't allocated and we
>> don't free msm_host->bus_clks[].
>>
>> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
>> Signed-off-by: Dan Carpenter 
>
> Thanks
>
> Reviewed-by: Rob Clark 

And for good measure,

Reviewed-by: Jani Nikula 


>
>>
>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
>> b/drivers/gpu/drm/msm/dsi/dsi_host.c
>> index 1fc07ce24686..4fa32296162e 100644
>> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
>> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
>> @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
>> *msm_host)
>>
>> return 0;
>>  err:
>> -   for (; i > 0; i--)
>> +   while (i--)
>> clk_disable_unprepare(msm_host->bus_clks[i]);
>>
>> return ret;

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/msm/dsi: free first element on error

[Jani Nikula]

On Thu, 16 Feb 2017, walter harms  wrote:
> Am 16.02.2017 12:53, schrieb Dan Carpenter:
>> On Thu, Feb 16, 2017 at 01:27:47PM +0200, Jani Nikula wrote:
>>> On Thu, 16 Feb 2017, Dan Carpenter  wrote:
 We want to free msm_host->bus_clks[0] so the > should be >=.

 Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
 Signed-off-by: Dan Carpenter 

 diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
 b/drivers/gpu/drm/msm/dsi/dsi_host.c
 index 1fc07ce24686..239e79b39a45 100644
 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
 +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
 @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
 *msm_host)
  
return 0;
  err:
 -  for (; i > 0; i--)
 +  for (; i >= 0; i--)
clk_disable_unprepare(msm_host->bus_clks[i]);
>>>
>>> By the looks of it this is also wrong. I didn't look at the functions,
>>> but you probably don't want to unprepare something where prepare failed,
>>> i.e. you want to -1 both the start and end offsets. Perhaps the right
>>> fix is
>>>
>>> while (i--)
>>> clk_disable_unprepare(msm_host->bus_clks[i]);
>>>
>>> which also seems to be widely used on error paths.
>>>
>> 
>
> We already know that programmers are bad in counting backwards ...
>
> any chance to make that into a forward loop ?

In most cases I'd agree with you. But I see that this while (i--) is
becoming somewhat of a pattern for error paths (grep for it), and I
think following patterns like this is more important. After a while, you
don't have to think about counting when you see it.

Besides, it's generally preferred to cleanup in the reverse order of
init, so a forward counting loop would require two variables here.

BR,
Jani.



>
> re,
>  wh
>
>

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/msm/dsi: Fix bug in dsi_mgr_phy_enable

[Rob Clark]

On Thu, Feb 16, 2017 at 5:59 AM, Archit Taneja  wrote:
> A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
> dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
> since master and slave DSI exist only in dual DSI mode. For the normal
> mode of operation, we should simply reset the PHY of the DSI device
> (i.e. msm_dsi) corresponding to the current bridge.
>
> Usage of the wrong DSI pointer also resulted in a static checker
> warning. That too is resolved with this fix.
>
> Fixes: b62aa70a98c5 (drm/msm/dsi: Move PHY operations out of host)
>
> Reported-by: Dan Carpenter 
> Signed-off-by: Archit Taneja 

Reviewed-by: Rob Clark 

> ---
>  drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
> b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> index 921270ea6059..a879ffa534b4 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
> @@ -171,7 +171,7 @@ dsi_mgr_phy_enable(int id,
> }
> }
> } else {
> -   msm_dsi_host_reset_phy(mdsi->host);
> +   msm_dsi_host_reset_phy(msm_dsi->host);
> ret = enable_phy(msm_dsi, src_pll_id, _timings[id]);
> if (ret)
> return ret;
> --
> The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
> hosted by The Linux Foundation
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/msm/dsi: free first element on error

[Rob Clark]

On Thu, Feb 16, 2017 at 7:03 AM, walter harms  wrote:
>
>
> Am 16.02.2017 12:53, schrieb Dan Carpenter:
>> On Thu, Feb 16, 2017 at 01:27:47PM +0200, Jani Nikula wrote:
>>> On Thu, 16 Feb 2017, Dan Carpenter  wrote:
 We want to free msm_host->bus_clks[0] so the > should be >=.

 Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
 Signed-off-by: Dan Carpenter 

 diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
 b/drivers/gpu/drm/msm/dsi/dsi_host.c
 index 1fc07ce24686..239e79b39a45 100644
 --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
 +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
 @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
 *msm_host)

 return 0;
  err:
 -   for (; i > 0; i--)
 +   for (; i >= 0; i--)
 clk_disable_unprepare(msm_host->bus_clks[i]);
>>>
>>> By the looks of it this is also wrong. I didn't look at the functions,
>>> but you probably don't want to unprepare something where prepare failed,
>>> i.e. you want to -1 both the start and end offsets. Perhaps the right
>>> fix is
>>>
>>>  while (i--)
>>>  clk_disable_unprepare(msm_host->bus_clks[i]);
>>>
>>> which also seems to be widely used on error paths.
>>>
>>
>
> We already know that programmers are bad in counting backwards ...
>
> any chance to make that into a forward loop ?
>

well, this *is* a common pattern.  And in some cases you actually do
need to disable clks in reverse order.  So meh, I think while (i--)
approach is fine

BR,
-R
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch v2] drm/msm/dsi: free first element on error

[Rob Clark]

On Thu, Feb 16, 2017 at 7:00 AM, Dan Carpenter  wrote:
> We're off by one here.  We free something that wasn't allocated and we
> don't free msm_host->bus_clks[].
>
> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
> Signed-off-by: Dan Carpenter 

Thanks

Reviewed-by: Rob Clark 

>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce24686..4fa32296162e 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> *msm_host)
>
> return 0;
>  err:
> -   for (; i > 0; i--)
> +   while (i--)
> clk_disable_unprepare(msm_host->bus_clks[i]);
>
> return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2] drm/omapdrm: dispc: Refuse x-decimation above 4 for all but 8-bit formats

[Tomi Valkeinen]

On 08/02/17 16:08, Jyri Sarha wrote:
> Let's disable all scaling that requires horizontal decimation with
> higher factor than 4, until we have better estimates of what we can
> and can not do. However, NV12 color format appears to work Ok with
> all decimation factors.
> 
> When decimating horizontally by more that 4 the dss is not able to
> fetch the data in burst mode. When this happens it is hard to tell if
> there enough bandwidth. Despite what theory says this appears to be
> true also for 16-bit color formats.
> 
> Signed-off-by: Jyri Sarha 
> ---
> Chnages since first version:
> - "color_mode_to_bpp(color_mode) > 8" -> "color_mode != OMAP_DSS_COLOR_NV12"
>   - commit message and comment updated too
> - improve error print
> 
>  drivers/gpu/drm/omapdrm/dss/dispc.c | 19 +++
>  1 file changed, 19 insertions(+)

Thanks, I've picked this up.

 Tomi



signature.asc
Description: OpenPGP digital signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v3 3/3] drm/amdgpu: simplify reservation handling during buffer creation

[Christian König]

Am 16.02.2017 um 12:39 schrieb Nicolai Hähnle:

From: Nicolai Hähnle 

By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initialization fails.

Actual deadlocks caused by the missing unlock should have been fixed
by "drm/ttm: never add BO that failed to validate to the LRU list",
superseding the flawed fix in commit 38fc4856ad98 ("drm/amdgpu: fix
a potential deadlock in amdgpu_bo_create_restricted()").

This change fixes remaining recursive locking errors that can be seen
with lock debugging enabled, and avoids the error of freeing a locked
mutex.

As an additional minor bonus, buffers created with resv == NULL and
the AMDGPU_GEM_CREATE_VRAM_CLEARED flag are now only added to the
global LRU list after the fill commands have been issued.

Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED handling 
(v2)")
Signed-off-by: Nicolai Hähnle 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 -
  1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c2e57f7..4d0536d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -395,19 +395,10 @@ int amdgpu_bo_create_restricted(struct amdgpu_device 
*adev,
amdgpu_fill_placement_to_bo(bo, placement);
/* Kernel allocation are uninterruptible */
  
-	if (!resv) {

-   bool locked;
-
-   reservation_object_init(>tbo.ttm_resv);
-   locked = ww_mutex_trylock(>tbo.ttm_resv.lock);
-   WARN_ON(!locked);
-   }
-
initial_bytes_moved = atomic64_read(>num_bytes_moved);
-   r = ttm_bo_init(>mman.bdev, >tbo, size, type,
-   >placement, page_align, !kernel, NULL,
-   acc_size, sg, resv ? resv : >tbo.ttm_resv,
-   _ttm_bo_destroy);
+   r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+>placement, page_align, !kernel, NULL,
+acc_size, sg, resv, _ttm_bo_destroy);
amdgpu_cs_report_moved_bytes(adev,
atomic64_read(>num_bytes_moved) - initial_bytes_moved);
  
@@ -433,7 +424,7 @@ int amdgpu_bo_create_restricted(struct amdgpu_device *adev,

fence_put(fence);
}
if (!resv)
-   ww_mutex_unlock(>tbo.resv->lock);
+   ttm_bo_unreserve(>tbo);


You can just use amdgpu_bo_unreserve() here. With that fixed the whole 
set is Reviewed-by: Christian König .


Regards,
Christian.


*bo_ptr = bo;
  
  	trace_amdgpu_bo_create(bo);



___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/msm/dsi: free first element on error

[walter harms]

Am 16.02.2017 12:53, schrieb Dan Carpenter:
> On Thu, Feb 16, 2017 at 01:27:47PM +0200, Jani Nikula wrote:
>> On Thu, 16 Feb 2017, Dan Carpenter  wrote:
>>> We want to free msm_host->bus_clks[0] so the > should be >=.
>>>
>>> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
>>> Signed-off-by: Dan Carpenter 
>>>
>>> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
>>> b/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> index 1fc07ce24686..239e79b39a45 100644
>>> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
>>> @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
>>> *msm_host)
>>>  
>>> return 0;
>>>  err:
>>> -   for (; i > 0; i--)
>>> +   for (; i >= 0; i--)
>>> clk_disable_unprepare(msm_host->bus_clks[i]);
>>
>> By the looks of it this is also wrong. I didn't look at the functions,
>> but you probably don't want to unprepare something where prepare failed,
>> i.e. you want to -1 both the start and end offsets. Perhaps the right
>> fix is
>>
>>  while (i--)
>>  clk_disable_unprepare(msm_host->bus_clks[i]);
>>
>> which also seems to be widely used on error paths.
>>
> 

We already know that programmers are bad in counting backwards ...

any chance to make that into a forward loop ?

re,
 wh


___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch v2] drm/msm/dsi: free first element on error

[Dan Carpenter]

We're off by one here.  We free something that wasn't allocated and we
don't free msm_host->bus_clks[].

Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1fc07ce24686..4fa32296162e 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
 
return 0;
 err:
-   for (; i > 0; i--)
+   while (i--)
clk_disable_unprepare(msm_host->bus_clks[i]);
 
return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [patch] drm/msm/dsi: free first element on error

[Dan Carpenter]

On Thu, Feb 16, 2017 at 01:27:47PM +0200, Jani Nikula wrote:
> On Thu, 16 Feb 2017, Dan Carpenter  wrote:
> > We want to free msm_host->bus_clks[0] so the > should be >=.
> >
> > Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
> > Signed-off-by: Dan Carpenter 
> >
> > diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> > b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > index 1fc07ce24686..239e79b39a45 100644
> > --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> > +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> > @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> > *msm_host)
> >  
> > return 0;
> >  err:
> > -   for (; i > 0; i--)
> > +   for (; i >= 0; i--)
> > clk_disable_unprepare(msm_host->bus_clks[i]);
> 
> By the looks of it this is also wrong. I didn't look at the functions,
> but you probably don't want to unprepare something where prepare failed,
> i.e. you want to -1 both the start and end offsets. Perhaps the right
> fix is
> 
>   while (i--)
>   clk_disable_unprepare(msm_host->bus_clks[i]);
> 
> which also seems to be widely used on error paths.
> 

Ah yeah.  You're right.  I'll resend.

regards,
dan carpenter

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] drm/ast: Support AST2500

[Benjamin Herrenschmidt]

On Thu, 2017-02-16 at 20:09 +1100, Benjamin Herrenschmidt wrote:
> From: "Y.C. Chen" 
> 
> Add detection and POST code for AST2500 generation chip,
> code originally from Aspeed and slightly reworked for
> coding style mostly by Ben.

I just noticed there's still a bunch of minor checkpatch warnings,
I'll do a new spin tomorrow but without code changes.

Y.C. Can you still test this one please to make sure I didn't break
POST ? :-)

Cheers,
Ben.

> Signed-off-by: Y.C. Chen 
> Signed-off-by: Benjamin Herrenschmidt 
> ---
> v2. [BenH]
>   - Coding style fixes
>   - Add timeout to main DRAM init loop
>   - Improve boot time display of RAM info
> 
> Y.C. Please check that I didn't break POST as I haven't manage to
> test
> that (we can't boot our machines if the BMC isn't already POSTed).
> 
> ---
>  drivers/gpu/drm/ast/ast_dram_tables.h |  62 +
>  drivers/gpu/drm/ast/ast_drv.h |   3 +
>  drivers/gpu/drm/ast/ast_main.c|  32 ++-
>  drivers/gpu/drm/ast/ast_mode.c|  25 +-
>  drivers/gpu/drm/ast/ast_post.c| 491
> ++
>  drivers/gpu/drm/ast/ast_tables.h  |  57 +++-
>  6 files changed, 586 insertions(+), 84 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_dram_tables.h
> b/drivers/gpu/drm/ast/ast_dram_tables.h
> index cc04539..02265b5 100644
> --- a/drivers/gpu/drm/ast/ast_dram_tables.h
> +++ b/drivers/gpu/drm/ast/ast_dram_tables.h
> @@ -141,4 +141,66 @@ static const struct ast_dramstruct
> ast2100_dram_table_data[] = {
>   { 0x, 0x },
>  };
>  
> +/*
> + * AST2500 DRAM settings modules
> + */
> +#define REGTBL_NUM   17
> +#define REGIDX_010   0
> +#define REGIDX_014   1
> +#define REGIDX_018   2
> +#define REGIDX_020   3
> +#define REGIDX_024   4
> +#define REGIDX_02C   5
> +#define REGIDX_030   6
> +#define REGIDX_214   7
> +#define REGIDX_2E0   8
> +#define REGIDX_2E4   9
> +#define REGIDX_2E8   10
> +#define REGIDX_2EC   11
> +#define REGIDX_2F0   12
> +#define REGIDX_2F4   13
> +#define REGIDX_2F8   14
> +#define REGIDX_RFC   15
> +#define REGIDX_PLL   16
> +
> +static u32 ast2500_ddr3_1600_timing_table[REGTBL_NUM] = {
> + 0x64604D38,  /* 0x010 */
> + 0x29690599,  /* 0x014 */
> + 0x0300,  /* 0x018 */
> + 0x,  /* 0x020 */
> + 0x,  /* 0x024 */
> + 0x02181E70,  /* 0x02C */
> + 0x0040,  /* 0x030 */
> + 0x0024,  /* 0x214 */
> + 0x02001300,  /* 0x2E0 */
> + 0x0EA0,  /* 0x2E4 */
> + 0x000E001B,  /* 0x2E8 */
> + 0x35B8C105,  /* 0x2EC */
> + 0x08090408,  /* 0x2F0 */
> + 0x9B000800,  /* 0x2F4 */
> + 0x0E400A00,  /* 0x2F8 */
> + 0x9971452F,  /* tRFC  */
> + 0x71C1   /* PLL   */
> +};
> +
> +static u32 ast2500_ddr4_1600_timing_table[REGTBL_NUM] = {
> + 0x63604E37,  /* 0x010 */
> + 0xE97AFA99,  /* 0x014 */
> + 0x00019000,  /* 0x018 */
> + 0x0800,  /* 0x020 */
> + 0x0400,  /* 0x024 */
> + 0x0410,  /* 0x02C */
> + 0x0101,  /* 0x030 */
> + 0x0024,  /* 0x214 */
> + 0x03002900,  /* 0x2E0 */
> + 0x0EA0,  /* 0x2E4 */
> + 0x000E001C,  /* 0x2E8 */
> + 0x35B8C106,  /* 0x2EC */
> + 0x08080607,  /* 0x2F0 */
> + 0x9B000900,  /* 0x2F4 */
> + 0x0E400A00,  /* 0x2F8 */
> + 0x99714545,  /* tRFC  */
> + 0x71C1   /* PLL   */
> +};
> +
>  #endif
> diff --git a/drivers/gpu/drm/ast/ast_drv.h
> b/drivers/gpu/drm/ast/ast_drv.h
> index 3bedcf7..2db97e2 100644
> --- a/drivers/gpu/drm/ast/ast_drv.h
> +++ b/drivers/gpu/drm/ast/ast_drv.h
> @@ -64,6 +64,7 @@ enum ast_chip {
>   AST2150,
>   AST2300,
>   AST2400,
> + AST2500,
>   AST1180,
>  };
>  
> @@ -80,6 +81,7 @@ enum ast_tx_chip {
>  #define AST_DRAM_1Gx32   3
>  #define AST_DRAM_2Gx16   6
>  #define AST_DRAM_4Gx16   7
> +#define AST_DRAM_8Gx16   8
>  
>  struct ast_fbdev;
>  
> @@ -397,6 +399,7 @@ bool ast_is_vga_enabled(struct drm_device *dev);
>  void ast_post_gpu(struct drm_device *dev);
>  u32 ast_mindwm(struct ast_private *ast, u32 r);
>  void ast_moutdwm(struct ast_private *ast, u32 r, u32 v);
> +
>  /* ast dp501 */
>  int ast_load_dp501_microcode(struct drm_device *dev);
>  void ast_set_dp501_video_output(struct drm_device *dev, u8 

[PATCH] gpu: ipu-v3: export ipu_csi_set_downsize

[Philipp Zabel]

This function will be used by the media drivers and needs to be exported
to allow them to be built as modules.

Reported-by: Russell King 
Fixes: 867341b95891 ("gpu: ipu-v3: add ipu_csi_set_downsize")
Signed-off-by: Philipp Zabel 
---
 drivers/gpu/ipu-v3/ipu-csi.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/ipu-v3/ipu-csi.c b/drivers/gpu/ipu-v3/ipu-csi.c
index 63c7292f427a2..24e12b87a0cbe 100644
--- a/drivers/gpu/ipu-v3/ipu-csi.c
+++ b/drivers/gpu/ipu-v3/ipu-csi.c
@@ -544,6 +544,7 @@ void ipu_csi_set_downsize(struct ipu_csi *csi, bool horiz, 
bool vert)
 
spin_unlock_irqrestore(>lock, flags);
 }
+EXPORT_SYMBOL_GPL(ipu_csi_set_downsize);
 
 void ipu_csi_set_test_generator(struct ipu_csi *csi, bool active,
u32 r_value, u32 g_value, u32 b_value,
-- 
2.11.0

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 3/3] drm/amdgpu: simplify reservation handling during buffer creation

[Nicolai Hähnle]

From: Nicolai Hähnle 

By using ttm_bo_init_reserved instead of the manual initialization of
the reservation object, the reservation lock will be properly unlocked
and destroyed when the TTM BO initialization fails.

Actual deadlocks caused by the missing unlock should have been fixed
by "drm/ttm: never add BO that failed to validate to the LRU list",
superseding the flawed fix in commit 38fc4856ad98 ("drm/amdgpu: fix
a potential deadlock in amdgpu_bo_create_restricted()").

This change fixes remaining recursive locking errors that can be seen
with lock debugging enabled, and avoids the error of freeing a locked
mutex.

As an additional minor bonus, buffers created with resv == NULL and
the AMDGPU_GEM_CREATE_VRAM_CLEARED flag are now only added to the
global LRU list after the fill commands have been issued.

Fixes: 12a852219583 ("drm/amdgpu: improve AMDGPU_GEM_CREATE_VRAM_CLEARED 
handling (v2)")
Signed-off-by: Nicolai Hähnle 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 17 -
 1 file changed, 4 insertions(+), 13 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
index c2e57f7..4d0536d 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
@@ -395,19 +395,10 @@ int amdgpu_bo_create_restricted(struct amdgpu_device 
*adev,
amdgpu_fill_placement_to_bo(bo, placement);
/* Kernel allocation are uninterruptible */
 
-   if (!resv) {
-   bool locked;
-
-   reservation_object_init(>tbo.ttm_resv);
-   locked = ww_mutex_trylock(>tbo.ttm_resv.lock);
-   WARN_ON(!locked);
-   }
-
initial_bytes_moved = atomic64_read(>num_bytes_moved);
-   r = ttm_bo_init(>mman.bdev, >tbo, size, type,
-   >placement, page_align, !kernel, NULL,
-   acc_size, sg, resv ? resv : >tbo.ttm_resv,
-   _ttm_bo_destroy);
+   r = ttm_bo_init_reserved(>mman.bdev, >tbo, size, type,
+>placement, page_align, !kernel, NULL,
+acc_size, sg, resv, _ttm_bo_destroy);
amdgpu_cs_report_moved_bytes(adev,
atomic64_read(>num_bytes_moved) - initial_bytes_moved);
 
@@ -433,7 +424,7 @@ int amdgpu_bo_create_restricted(struct amdgpu_device *adev,
fence_put(fence);
}
if (!resv)
-   ww_mutex_unlock(>tbo.resv->lock);
+   ttm_bo_unreserve(>tbo);
*bo_ptr = bo;
 
trace_amdgpu_bo_create(bo);
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 1/3] drm/ttm: fix the documentation of ttm_bo_init

[Nicolai Hähnle]

From: Nicolai Hähnle 

As the comment says: callers of ttm_bo_init cannot rely on having the
only reference to the BO when the function returns successfully.

Signed-off-by: Nicolai Hähnle 
---
 include/drm/ttm/ttm_bo_api.h | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index f195899..c0ebbd6 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -476,7 +476,11 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
  * As this object may be part of a larger structure, this function,
  * together with the @destroy function,
  * enables driver-specific objects derived from a ttm_buffer_object.
- * On successful return, the object kref and list_kref are set to 1.
+ *
+ * On successful return, the caller owns an object kref to @bo. The kref and
+ * list_kref are usually set to 1, but note that in some situations, other
+ * tasks may already be holding references to @bo as well.
+ *
  * If a failure occurs, the function will call the @destroy function, or
  * kfree() if @destroy is NULL. Thus, after a failure, dereferencing @bo is
  * illegal and will likely cause memory corruption.
-- 
2.9.3

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v3 2/3] drm/ttm: add ttm_bo_init_reserved

[Nicolai Hähnle]

From: Nicolai Hähnle 

This variant of ttm_bo_init returns the validated buffer object with
the reservation lock held when resv == NULL. This is convenient for
callers that want to use the BO immediately, e.g. for initializing its
contents.

Signed-off-by: Nicolai Hähnle 
---
 drivers/gpu/drm/ttm/ttm_bo.c | 59 +---
 include/drm/ttm/ttm_bo_api.h | 54 
 2 files changed, 98 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index c438b04..989b98b 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -1119,18 +1119,18 @@ int ttm_bo_validate(struct ttm_buffer_object *bo,
 }
 EXPORT_SYMBOL(ttm_bo_validate);
 
-int ttm_bo_init(struct ttm_bo_device *bdev,
-   struct ttm_buffer_object *bo,
-   unsigned long size,
-   enum ttm_bo_type type,
-   struct ttm_placement *placement,
-   uint32_t page_alignment,
-   bool interruptible,
-   struct file *persistent_swap_storage,
-   size_t acc_size,
-   struct sg_table *sg,
-   struct reservation_object *resv,
-   void (*destroy) (struct ttm_buffer_object *))
+int ttm_bo_init_reserved(struct ttm_bo_device *bdev,
+struct ttm_buffer_object *bo,
+unsigned long size,
+enum ttm_bo_type type,
+struct ttm_placement *placement,
+uint32_t page_alignment,
+bool interruptible,
+struct file *persistent_swap_storage,
+size_t acc_size,
+struct sg_table *sg,
+struct reservation_object *resv,
+void (*destroy) (struct ttm_buffer_object *))
 {
int ret = 0;
unsigned long num_pages;
@@ -1214,10 +1214,10 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
if (likely(!ret))
ret = ttm_bo_validate(bo, placement, interruptible, false);
 
-   if (!resv)
-   ttm_bo_unreserve(bo);
-
if (unlikely(ret)) {
+   if (!resv)
+   ttm_bo_unreserve(bo);
+
ttm_bo_unref();
return ret;
}
@@ -1230,6 +1230,35 @@ int ttm_bo_init(struct ttm_bo_device *bdev,
 
return ret;
 }
+EXPORT_SYMBOL(ttm_bo_init_reserved);
+
+int ttm_bo_init(struct ttm_bo_device *bdev,
+   struct ttm_buffer_object *bo,
+   unsigned long size,
+   enum ttm_bo_type type,
+   struct ttm_placement *placement,
+   uint32_t page_alignment,
+   bool interruptible,
+   struct file *persistent_swap_storage,
+   size_t acc_size,
+   struct sg_table *sg,
+   struct reservation_object *resv,
+   void (*destroy) (struct ttm_buffer_object *))
+{
+   int ret;
+
+   ret = ttm_bo_init_reserved(bdev, bo, size, type, placement,
+  page_alignment, interruptible,
+  persistent_swap_storage, acc_size,
+  sg, resv, destroy);
+   if (ret)
+   return ret;
+
+   if (!resv)
+   ttm_bo_unreserve(bo);
+
+   return 0;
+}
 EXPORT_SYMBOL(ttm_bo_init);
 
 size_t ttm_bo_acc_size(struct ttm_bo_device *bdev,
diff --git a/include/drm/ttm/ttm_bo_api.h b/include/drm/ttm/ttm_bo_api.h
index c0ebbd6..2d0f63e 100644
--- a/include/drm/ttm/ttm_bo_api.h
+++ b/include/drm/ttm/ttm_bo_api.h
@@ -453,6 +453,60 @@ size_t ttm_bo_dma_acc_size(struct ttm_bo_device *bdev,
   unsigned struct_size);
 
 /**
+ * ttm_bo_init_reserved
+ *
+ * @bdev: Pointer to a ttm_bo_device struct.
+ * @bo: Pointer to a ttm_buffer_object to be initialized.
+ * @size: Requested size of buffer object.
+ * @type: Requested type of buffer object.
+ * @flags: Initial placement flags.
+ * @page_alignment: Data alignment in pages.
+ * @interruptible: If needing to sleep to wait for GPU resources,
+ * sleep interruptible.
+ * @persistent_swap_storage: Usually the swap storage is deleted for buffers
+ * pinned in physical memory. If this behaviour is not desired, this member
+ * holds a pointer to a persistent shmem object. Typically, this would
+ * point to the shmem object backing a GEM object if TTM is used to back a
+ * GEM user interface.
+ * @acc_size: Accounted size for this object.
+ * @resv: Pointer to a reservation_object, or NULL to let ttm allocate one.
+ * @destroy: Destroy function. Use NULL for kfree().
+ *
+ * This function initializes a pre-allocated struct ttm_buffer_object.
+ * As this object may be part of a larger structure, this function,
+ * together with the @destroy function,
+ * 

Re: [patch] drm/msm/dsi: free first element on error

[Jani Nikula]

On Thu, 16 Feb 2017, Dan Carpenter  wrote:
> We want to free msm_host->bus_clks[0] so the > should be >=.
>
> Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
> Signed-off-by: Dan Carpenter 
>
> diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
> b/drivers/gpu/drm/msm/dsi/dsi_host.c
> index 1fc07ce24686..239e79b39a45 100644
> --- a/drivers/gpu/drm/msm/dsi/dsi_host.c
> +++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
> @@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host 
> *msm_host)
>  
>   return 0;
>  err:
> - for (; i > 0; i--)
> + for (; i >= 0; i--)
>   clk_disable_unprepare(msm_host->bus_clks[i]);

By the looks of it this is also wrong. I didn't look at the functions,
but you probably don't want to unprepare something where prepare failed,
i.e. you want to -1 both the start and end offsets. Perhaps the right
fix is

while (i--)
clk_disable_unprepare(msm_host->bus_clks[i]);

which also seems to be widely used on error paths.

BR,
Jani.


>  
>   return ret;
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [Intel-gfx] [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3

[Maarten Lankhorst]

Op 16-02-17 om 10:45 schreef Jani Nikula:
> On Wed, 15 Feb 2017, Sinclair Yeh  wrote:
>> On Wed, Feb 15, 2017 at 03:56:09PM +0200, Jani Nikula wrote:
>>> On Wed, 25 Jan 2017, Maarten Lankhorst  
>>> wrote:
 This was somehow lost between v3 and the merged version in Maarten's
 patch merged as:

 commit f2d580b9a8149735cbc4b59c4a8df60173658140
 Author: Maarten Lankhorst 
 Date:   Wed May 4 14:38:26 2016 +0200

 drm/core: Do not preserve framebuffer on rmfb, v4.

 This introduces a slight behavioral change to rmfb. Instead of
 disabling a crtc when the primary plane is disabled, we try to
 preserve it.

 Apart from old versions of the vmwgfx xorg driver, there is
 nothing depending on rmfb disabling a crtc. Since vmwgfx is
 a legacy driver we can safely only disable the plane with atomic.

 If this commit is rejected by the driver then we will still fall
 back to the old behavior and turn off the crtc.

 v2:
 - Remove plane->fb assignment, done by drm_atomic_clean_old_fb.
 - Add WARN_ON when atomic_remove_fb fails.
 - Always call drm_atomic_state_put.
 v3:
 - Use drm_drv_uses_atomic_modeset
 - Handle the case where the first plane-disable-only commit fails
   with -EINVAL. Some drivers do not support this, fall back to
   disabling all crtc's in this case.

 Signed-off-by: Daniel Vetter 
 Signed-off-by: Daniel Vetter 
 Signed-off-by: Maarten Lankhorst 
>>> Pushed to drm-misc-next-fixes, and sent the pull request to Dave. Thanks
>>> for the patch.
>> I verified yesterday that this patch will cause a regression for vmwgfx
>> multi-mon.  Can we hold off on this?
> Turns out it fails some of our tests too. Maybe three weeks old CI
> results are not to be trusted, the base moves too fast. *shrug*.
>
> I've dropped the patch, and asked Dave not to pull. Let's go back to the
> drawing board...
Yeah it's unfortunate. We tend to trigger a lot of bugs in other parts of the 
code with this change. The reload tests are fixed by fixing 
drm_atomic_helper_disable_all.
I haven't seen the crc bugs before, would be interesting to know why other 
tests a're suddenly failing.

~Maarten
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH] drm/msm/dsi: Fix bug in dsi_mgr_phy_enable

[Archit Taneja]

A recent commit introduces a bug in dsi_mgr_phy_enable. In the non
dual DSI mode, we reset the mdsi (master DSI) PHY. This isn't right
since master and slave DSI exist only in dual DSI mode. For the normal
mode of operation, we should simply reset the PHY of the DSI device
(i.e. msm_dsi) corresponding to the current bridge.

Usage of the wrong DSI pointer also resulted in a static checker
warning. That too is resolved with this fix.

Fixes: b62aa70a98c5 (drm/msm/dsi: Move PHY operations out of host)

Reported-by: Dan Carpenter 
Signed-off-by: Archit Taneja 
---
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 921270ea6059..a879ffa534b4 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -171,7 +171,7 @@ dsi_mgr_phy_enable(int id,
}
}
} else {
-   msm_dsi_host_reset_phy(mdsi->host);
+   msm_dsi_host_reset_phy(msm_dsi->host);
ret = enable_phy(msm_dsi, src_pll_id, _timings[id]);
if (ret)
return ret;
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
hosted by The Linux Foundation

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[patch] drm/msm/dsi: free first element on error

[Dan Carpenter]

We want to free msm_host->bus_clks[0] so the > should be >=.

Fixes: 6e0eb52eba9e ("drm/msm/dsi: Parse bus clocks from a list")
Signed-off-by: Dan Carpenter 

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 1fc07ce24686..239e79b39a45 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -437,7 +437,7 @@ static int dsi_bus_clk_enable(struct msm_dsi_host *msm_host)
 
return 0;
 err:
-   for (; i > 0; i--)
+   for (; i >= 0; i--)
clk_disable_unprepare(msm_host->bus_clks[i]);
 
return ret;
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/3] drm: handle override edid and firmware adid at drm_do_get_edid()

[Jani Nikula]

On Thu, 16 Feb 2017, Jani Nikula  wrote:
> Handle override edid and firmware edid at the low level to transparently
> and completely replace the real edid. This also prevents actual edid
> reads for them, but retains ddc probe.

Please ignore this stray patch, and look at the series at 
https://patchwork.freedesktop.org/series/19764/

Sorry for the noise,
Jani.

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm: handle override edid and firmware adid at drm_do_get_edid()

[Jani Nikula]

Handle override edid and firmware edid at the low level to transparently
and completely replace the real edid. This also prevents actual edid
reads for them, but retains ddc probe.

FIXME: validate override edid, deduplicate firmware edid validation.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 15 +++
 drivers/gpu/drm/drm_probe_helper.c | 19 +--
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 362036360724..054e2d74eafc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
*connector,
  * level, drivers must make all reasonable efforts to expose it as an I2C
  * adapter and use drm_get_edid() instead of abusing this function.
  *
+ * The EDID may be overridden using debugfs override_edid or firmare EDID
+ * (drm_load_edid_firmware()), in this priority order. Having either of them
+ * bypasses actual EDID reads.
+ *
  * Return: Pointer to valid EDID or NULL if we couldn't find any.
  */
 struct edid *drm_do_get_edid(struct drm_connector *connector,
@@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
+   struct edid *override = NULL;
+
+   if (connector->override_edid)
+   override = drm_edid_duplicate((const struct edid *)
+ connector->edid_blob_ptr->data);
+
+   if (!override)
+   override = drm_load_edid_firmware(connector);
+
+   if (!IS_ERR_OR_NULL(override))
+   return override;
 
if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 358957118ca9..871326cbc465 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, bool 
force)
  *drm_mode_probed_add(). New modes start their life with status as OK.
  *Modes are added from a single source using the following priority order.
  *
- *- debugfs 'override_edid' (used for testing only)
- *- firmware EDID (drm_load_edid_firmware())
  *- _connector_helper_funcs.get_modes vfunc
  *- if the connector status is connector_status_connected, standard
  *  VESA DMT modes up to 1024x768 are automatically added
@@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
goto prune;
}
 
-   if (connector->override_edid) {
-   struct edid *edid = (struct edid *) 
connector->edid_blob_ptr->data;
-
-   count = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   } else {
-   struct edid *edid = drm_load_edid_firmware(connector);
-   if (!IS_ERR_OR_NULL(edid)) {
-   drm_mode_connector_update_edid_property(connector, 
edid);
-   count = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   kfree(edid);
-   }
-   if (count == 0)
-   count = (*connector_funcs->get_modes)(connector);
-   }
+   count = (*connector_funcs->get_modes)(connector);
 
if (count == 0 && connector->status == connector_status_connected)
count = drm_add_modes_noedid(connector, 1024, 768);
-- 
2.1.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 2/3] drm: reset ELD if NULL edid is passed to drm_edid_to_eld

[Jani Nikula]

Make the function useful for resetting, not just setting, the ELD.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 24e7b282f16c..362036360724 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -3430,6 +3430,9 @@ void drm_edid_to_eld(struct drm_connector *connector, 
struct edid *edid)
 
memset(eld, 0, sizeof(connector->eld));
 
+   if (!edid)
+   return;
+
connector->latency_present[0] = false;
connector->latency_present[1] = false;
connector->video_latency[0] = 0;
-- 
2.1.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 0/3] drm: handle override/firmware edid at the lowest level

[Jani Nikula]

This is a simplified version of the perhaps too ambitious RFC [1].

Here we simply handle debugfs override edid and the firmware edid at the
drm_do_get_edid() level, not at the probe helper level. With this, everything
from EDID gets transparently overridden.

BR,
Jani.


[1] http://mid.mail-archive.com/cover.1482854862.git.jani.nikula@intel.com


Jani Nikula (3):
  drm: move edid property update and add modes out of edid firmware
loader
  drm: reset ELD if NULL edid is passed to drm_edid_to_eld
  drm: handle override edid and firmware EDID at drm_do_get_edid() level

 drivers/gpu/drm/drm_edid.c | 18 ++
 drivers/gpu/drm/drm_edid_load.c| 17 -
 drivers/gpu/drm/drm_probe_helper.c | 13 +
 include/drm/drm_edid.h |  7 ---
 4 files changed, 27 insertions(+), 28 deletions(-)

-- 
2.1.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 3/3] drm: handle override edid and firmware EDID at drm_do_get_edid() level

[Jani Nikula]

Handle debugfs override edid and firmware edid at the low level to
transparently and completely replace the real edid. Previously, we
practically only used the modes from the override EDID, and none of the
other data. This also prevents actual EDID reads when the EDID is to be
overridden, but retains the DDC probe.

FIXME: validate override edid, deduplicate firmware edid validation.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid.c | 15 +++
 drivers/gpu/drm/drm_probe_helper.c | 19 +--
 2 files changed, 16 insertions(+), 18 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index 362036360724..054e2d74eafc 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1309,6 +1309,10 @@ static void connector_bad_edid(struct drm_connector 
*connector,
  * level, drivers must make all reasonable efforts to expose it as an I2C
  * adapter and use drm_get_edid() instead of abusing this function.
  *
+ * The EDID may be overridden using debugfs override_edid or firmare EDID
+ * (drm_load_edid_firmware()), in this priority order. Having either of them
+ * bypasses actual EDID reads.
+ *
  * Return: Pointer to valid EDID or NULL if we couldn't find any.
  */
 struct edid *drm_do_get_edid(struct drm_connector *connector,
@@ -1318,6 +1322,17 @@ struct edid *drm_do_get_edid(struct drm_connector 
*connector,
 {
int i, j = 0, valid_extensions = 0;
u8 *edid, *new;
+   struct edid *override = NULL;
+
+   if (connector->override_edid)
+   override = drm_edid_duplicate((const struct edid *)
+ connector->edid_blob_ptr->data);
+
+   if (!override)
+   override = drm_load_edid_firmware(connector);
+
+   if (!IS_ERR_OR_NULL(override))
+   return override;
 
if ((edid = kmalloc(EDID_LENGTH, GFP_KERNEL)) == NULL)
return NULL;
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 358957118ca9..871326cbc465 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -199,8 +199,6 @@ drm_connector_detect(struct drm_connector *connector, bool 
force)
  *drm_mode_probed_add(). New modes start their life with status as OK.
  *Modes are added from a single source using the following priority order.
  *
- *- debugfs 'override_edid' (used for testing only)
- *- firmware EDID (drm_load_edid_firmware())
  *- _connector_helper_funcs.get_modes vfunc
  *- if the connector status is connector_status_connected, standard
  *  VESA DMT modes up to 1024x768 are automatically added
@@ -305,22 +303,7 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
goto prune;
}
 
-   if (connector->override_edid) {
-   struct edid *edid = (struct edid *) 
connector->edid_blob_ptr->data;
-
-   count = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   } else {
-   struct edid *edid = drm_load_edid_firmware(connector);
-   if (!IS_ERR_OR_NULL(edid)) {
-   drm_mode_connector_update_edid_property(connector, 
edid);
-   count = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   kfree(edid);
-   }
-   if (count == 0)
-   count = (*connector_funcs->get_modes)(connector);
-   }
+   count = (*connector_funcs->get_modes)(connector);
 
if (count == 0 && connector->status == connector_status_connected)
count = drm_add_modes_noedid(connector, 1024, 768);
-- 
2.1.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH 1/3] drm: move edid property update and add modes out of edid firmware loader

[Jani Nikula]

Make the firmware loader more generic and generally useful.

Signed-off-by: Jani Nikula 
---
 drivers/gpu/drm/drm_edid_load.c| 17 -
 drivers/gpu/drm/drm_probe_helper.c |  8 +++-
 include/drm/drm_edid.h |  7 ---
 3 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/drivers/gpu/drm/drm_edid_load.c b/drivers/gpu/drm/drm_edid_load.c
index 622f788bff46..1c0495acf341 100644
--- a/drivers/gpu/drm/drm_edid_load.c
+++ b/drivers/gpu/drm/drm_edid_load.c
@@ -256,15 +256,14 @@ static void *edid_load(struct drm_connector *connector, 
const char *name,
return edid;
 }
 
-int drm_load_edid_firmware(struct drm_connector *connector)
+struct edid *drm_load_edid_firmware(struct drm_connector *connector)
 {
const char *connector_name = connector->name;
char *edidname, *last, *colon, *fwstr, *edidstr, *fallback = NULL;
-   int ret;
struct edid *edid;
 
if (edid_firmware[0] == '\0')
-   return 0;
+   return ERR_PTR(-ENOENT);
 
/*
 * If there are multiple edid files specified and separated
@@ -293,7 +292,7 @@ int drm_load_edid_firmware(struct drm_connector *connector)
if (!edidname) {
if (!fallback) {
kfree(fwstr);
-   return 0;
+   return ERR_PTR(-ENOENT);
}
edidname = fallback;
}
@@ -305,13 +304,5 @@ int drm_load_edid_firmware(struct drm_connector *connector)
edid = edid_load(connector, edidname, connector_name);
kfree(fwstr);
 
-   if (IS_ERR_OR_NULL(edid))
-   return 0;
-
-   drm_mode_connector_update_edid_property(connector, edid);
-   ret = drm_add_edid_modes(connector, edid);
-   drm_edid_to_eld(connector, edid);
-   kfree(edid);
-
-   return ret;
+   return edid;
 }
diff --git a/drivers/gpu/drm/drm_probe_helper.c 
b/drivers/gpu/drm/drm_probe_helper.c
index 93381454bdf7..358957118ca9 100644
--- a/drivers/gpu/drm/drm_probe_helper.c
+++ b/drivers/gpu/drm/drm_probe_helper.c
@@ -311,7 +311,13 @@ int drm_helper_probe_single_connector_modes(struct 
drm_connector *connector,
count = drm_add_edid_modes(connector, edid);
drm_edid_to_eld(connector, edid);
} else {
-   count = drm_load_edid_firmware(connector);
+   struct edid *edid = drm_load_edid_firmware(connector);
+   if (!IS_ERR_OR_NULL(edid)) {
+   drm_mode_connector_update_edid_property(connector, 
edid);
+   count = drm_add_edid_modes(connector, edid);
+   drm_edid_to_eld(connector, edid);
+   kfree(edid);
+   }
if (count == 0)
count = (*connector_funcs->get_modes)(connector);
}
diff --git a/include/drm/drm_edid.h b/include/drm/drm_edid.h
index 43fb0ac5eb9c..a55eea4afb61 100644
--- a/include/drm/drm_edid.h
+++ b/include/drm/drm_edid.h
@@ -331,11 +331,12 @@ int drm_av_sync_delay(struct drm_connector *connector,
  const struct drm_display_mode *mode);
 
 #ifdef CONFIG_DRM_LOAD_EDID_FIRMWARE
-int drm_load_edid_firmware(struct drm_connector *connector);
+struct edid *drm_load_edid_firmware(struct drm_connector *connector);
 #else
-static inline int drm_load_edid_firmware(struct drm_connector *connector)
+static inline struct edid *
+drm_load_edid_firmware(struct drm_connector *connector)
 {
-   return 0;
+   return ERR_PTR(-ENOENT);
 }
 #endif
 
-- 
2.1.4

___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: i915: Dealing with 90° rotated display ?

[Hans de Goede]

Hi,

On 15-02-17 15:59, Ville Syrjälä wrote:

On Wed, Feb 15, 2017 at 03:54:17PM +0100, Hans de Goede wrote:

Hi Jani,

As discussed here:

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

I've a mini-laptop which uses a phone-screen,
so the native orientation of the screen is portrait,
where as for a clam-shell device one wants it to
be landscape. Ideally there would be a flag somewhere
to tell the i915 driver that the panel is mounted
90° rotated in its bezel and have the i915 driver
apply that rotation on top of whatever rotation
userspace requests.

So question is there already a place (variable) in
the i915 driver where one can set such a rotation
offset to apply on top of what userspace requests ?

If not do you have any idea how feasible adding one
would be and can you give me a few pointers / hints
where to start with such a thing ?


You could have a look at my branch (which I pointed out in the bug).


Ok, so the patch that actually is relevant to this
discussion (and not just a cleanup / bug-fix) seems to be:

https://github.com/vsyrjala/linux/commit/86485710a2891a43b593008dfc11f2a101a07a9e

Right ?

AFAICT that will make fbcon inherit the rotation setting of
the primary plan on the primary crt. That may solve the
original bug as reported, but not the case / device I'm
talking about. What I would like to see is a "rotation offset"
field somewhere to be applied to all rotations in a way which
is hidden from userspace. Specifically the device I've has a
screen which is 720x1280 in resolution, but I want userspace
to see it as a 1280x720 screen because that is how it is used
in the hardware. So I want a 90° rotation to be applied which
is completely hidden from userspace. So when userspace
(e.g. the Xorg server + modesetting driver) asks for 0° degree
rotation under the hood they get 90 applied, when they aks for
the panel resolution they get 1280x720 instead of 720x1280.

Basically the idea is that the kernel as the HAL it is supposed
to be (amongst other things) hide the hardware weirdness / quirk
of using a portrait panel in a landscape bezel.

I hope this clarifies what I want to achieve and yes of course
fbcon should follow suite and also pick up the rotation offset.


But note that 90/270 degree rotation is a little busted currently.
You'll need at least
https://patchwork.freedesktop.org/patch/120208/


Ok.

Regards,

Hans
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PULL] drm-misc-next-fixes, take 2

[Jani Nikula]

Hi Dave, this one superseeds [1]. Better to flush out the single uapi
fix for v4.11 now so it's not forgotten.

BR,
Jani.

[1] 87mvdnpnix.fsf@intel.com">http://mid.mail-archive.com/87mvdnpnix.fsf@intel.com


The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442:

  Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux 
into drm-next (2017-02-10 10:13:30 +1000)

are available in the git repository at:

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

for you to fetch changes up to 2220fc1ab363e6fab1f321430d69be17a8b92bd7:

  uapi: add missing install of dma-buf.h (2017-02-14 22:45:16 +0100)


A single uapi fix.


Denys Dmytriyenko (1):
  uapi: add missing install of dma-buf.h

 include/uapi/linux/Kbuild | 1 +
 1 file changed, 1 insertion(+)

-- 
Jani Nikula, Intel Open Source Technology Center
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel