date:20180410

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Timothy Arceri  ---
We now have both an in memory and on disk shader cache so this situation should
be much better now. Closing.

-- 
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 v6 1/2] drm/bridge: Add Cadence DSI driver

2018-04-10 Thread kbuild test robot

Hi Boris,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16 next-20180410]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-bridge-Add-Cadence-DSI-driver/20180411-060845
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: arm-allyesconfig (attached as .config)
compiler: arm-linux-gnueabi-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=arm 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/cdns-dsi.o: In function 
`cdns_dsi_get_dphy_pll_cfg.constprop.0':
>> cdns-dsi.c:(.text+0x139c): undefined reference to `__aeabi_uldivmod'

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


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 87059] [apitrace] Graphical glitches in This war of mine

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

Timothy Arceri  changed:

   What|Removed |Added

Summary|Graphical glitches r9290|[apitrace] Graphical
   ||glitches in This war of
   ||mine

-- 
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 101834] WebGL shaders cause system freeze

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #1 from Timothy Arceri  ---
There has been a series of changes to loop unrolling since this was reported
but this in now working and I believe the final fix was likely the following
patch as this was still crashing when I tested it before working on this fix.
It entirely possible something else fixed it but its working now so closing.

commit 56b867395dee1a48594b27987d3bf68a4e745dda
Author: Timothy Arceri 
Date:   Mon Mar 26 10:31:26 2018 +1100

glsl: fix infinite loop caused by bug in loop unrolling pass

Just checking for 2 jumps is not enough to be sure we can do a
complex loop unroll. We need to make sure we also have also found
2 loop terminators.

Without this we were attempting to unroll a loop where the second
jump was nested inside multiple ifs which loop analysis is unable
to detect as a terminator. We ended up splicing out the first
terminator but failed to actually unroll the loop, this resulted
in the creation of a possible infinite loop.

Fixes: 646621c66da9 "glsl: make loop unrolling more like the nir unrolling
path"

Tested-by: Gert Wollny 
Reviewed-by: Ian Romanick 
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=105670

-- 
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 99994] Unreal Tournament 2016 segfaults with sisched

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

Timothy Arceri  changed:

   What|Removed |Added

   Assignee|dri-devel@lists.freedesktop |davyax...@gmail.com
   |.org|

--- Comment #2 from Timothy Arceri  ---
This continues to crash on LLVM 7-devel and 18.1-devel as of today. Tested with
latests Linux build [1].

[1]
https://www.epicgames.com/unrealtournament/forums/unreal-tournament-discussion/announcements/387158-0-1-11-update-posted-5-16-2017

-- 
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 87059] Graphical glitches r9290

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

--- Comment #11 from Timothy Arceri  ---
The black boxes are gone but there are other rendering issues. I've create an
apitrace [1].

There is a shader that fails to compile due to a shader bug but thats not the
problem as the trace runs fine on the Nvidia blob. 

Running on Nvidia also produces warnings:
"Texture state usage warning: Texture 0 is base level inconsistent. Check
texture size."

[1] https://drive.google.com/open?id=1v94W9c_H9EAF4iWQYUXU9oux5RPt0vw_

-- 
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] drm/ast: Fixed reboot test may cause system hanged

2018-04-10 Thread Benjamin Herrenschmidt

On Wed, 2018-04-11 at 09:27 +0800, Y.C. Chen wrote:
> index dac3558..82a2687 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
> *need_post)
>  
>  
> /* Enable extended register access */
> -   ast_enable_mmio(dev);
> ast_open_key(ast);
> +   ast_enable_mmio(dev);

Why that change ? The documentation doesn't really specify what the
"password" register is about. What does it "open" ?

I'm being a bit paranoid because we had issues with earlier drivers
(before some of the latest changes to that code) where occasionally
on boot, the chip wouldn't respond to an MMIO to one of the VGA
registers, causing an EEH error which crashes on boot.

So I want to make sure I understand what the changes precisely do.

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

Re: [PATCH] drm/ast: Fixed reboot test may cause system hanged

2018-04-10 Thread Benjamin Herrenschmidt

On Wed, 2018-04-11 at 09:27 +0800, Y.C. Chen wrote:
> From: "Y.C. Chen" 
> 
> There is another thread still access standard VGA I/O while loading drm 
> driver.
> Disable standard VGA I/O decode to avoid this issue.

Jeremy, Joel, can we regression test that on our systems ?

> Signed-off-by: Y.C. Chen 
> ---
>  drivers/gpu/drm/ast/ast_main.c | 5 -
>  drivers/gpu/drm/ast/ast_mode.c | 2 +-
>  drivers/gpu/drm/ast/ast_post.c | 2 +-
>  3 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
> index dac3558..82a2687 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
> *need_post)
>  
>  
>   /* Enable extended register access */
> - ast_enable_mmio(dev);
>   ast_open_key(ast);
> + ast_enable_mmio(dev);
>  
>   /* Find out whether P2A works or whether to use device-tree */
>   ast_detect_config_mode(dev, _rev);
> @@ -576,6 +576,9 @@ void ast_driver_unload(struct drm_device *dev)
>  {
>   struct ast_private *ast = dev->dev_private;
>  
> + /* enable standard VGA decode */
> + ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
> +
>   ast_release_firmware(dev);
>   kfree(ast->dp501_fw_addr);
>   ast_mode_fini(dev);
> diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
> index 831b733..9d637b4 100644
> --- a/drivers/gpu/drm/ast/ast_mode.c
> +++ b/drivers/gpu/drm/ast/ast_mode.c
> @@ -599,7 +599,7 @@ static int ast_crtc_mode_set(struct drm_crtc *crtc,
>   return -EINVAL;
>   ast_open_key(ast);
>  
> - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
> + ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
>  
>   ast_set_std_reg(crtc, adjusted_mode, _mode);
>   ast_set_crtc_reg(crtc, adjusted_mode, _mode);
> diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
> index f7d4213..c1d1ac5 100644
> --- a/drivers/gpu/drm/ast/ast_post.c
> +++ b/drivers/gpu/drm/ast/ast_post.c
> @@ -46,7 +46,7 @@ void ast_enable_mmio(struct drm_device *dev)
>  {
>   struct ast_private *ast = dev->dev_private;
>  
> - ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
> + ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
>  }
>  
>  
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/ast: Fixed reboot test may cause system hanged

2018-04-10 Thread Benjamin Herrenschmidt

On Wed, 2018-04-11 at 02:16 +, YC Chen wrote:
> Hi Ben,
> Thanks for your reply. You need to open password register before
> modify extended CRT registers. Extended CRT registers cannot be
> modified if the read back value of password register is 0.
> Allow me to describe this issue more. This issue only happen on Intel
> x86/x86_64 system actually. We found there is a another thread still
> access VGA cursor registers when loading "ast" drm driver. VGA
> register is index I/O register, if two threads access it alternately,
> it may cause the un-expected settings. "ast" drm driver is using
> related IO or MMIO to access register, and the thread is using
> standard VGA IO(0x3d4) to access cursor register, so our solution is
> disabling standard VGA decoding(Set VGACRA1 D[1] to 1) at the entry
> of "ast" driver load to avoid this issue.

Thanks. Pending testing on our systems to make sure it doesn't break
anything (it shouldn't .. hopefully)

Reviewed-by: Benjamin Herrenschmidt 

> Regards,
> 
> Y.C. Chen
> 
> -Original Message-
> From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
> Sent: Wednesday, April 11, 2018 9:54 AM
> To: YC Chen ; dri-devel@lists.freedesktop.org
> Cc: airl...@redhat.com; e...@suse.com
> Subject: Re: [PATCH] drm/ast: Fixed reboot test may cause system
> hanged
> 
> On Wed, 2018-04-11 at 09:27 +0800, Y.C. Chen wrote:
> > index dac3558..82a2687 100644
> > --- a/drivers/gpu/drm/ast/ast_main.c
> > +++ b/drivers/gpu/drm/ast/ast_main.c
> > @@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device
> > *dev, 
> > bool *need_post)
> >  
> >  
> > /* Enable extended register access */
> > -   ast_enable_mmio(dev);
> > ast_open_key(ast);
> > +   ast_enable_mmio(dev);
> 
> Why that change ? The documentation doesn't really specify what the
> "password" register is about. What does it "open" ?
> 
> I'm being a bit paranoid because we had issues with earlier drivers
> (before some of the latest changes to that code) where occasionally
> on boot, the chip wouldn't respond to an MMIO to one of the VGA
> registers, causing an EEH error which crashes on boot.
> 
> So I want to make sure I understand what the changes precisely do.
> 
> Cheers,
> Ben.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v6 1/2] drm/bridge: Add Cadence DSI driver

2018-04-10 Thread kbuild test robot

Hi Boris,

I love your patch! Yet something to improve:

[auto build test ERROR on drm/drm-next]
[also build test ERROR on v4.16 next-20180410]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Boris-Brezillon/drm-bridge-Add-Cadence-DSI-driver/20180411-060845
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: i386-allyesconfig (attached as .config)
compiler: gcc-7 (Debian 7.3.0-1) 7.3.0
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   drivers/gpu/drm/bridge/cdns-dsi.o: In function 
`cdns_dsi_get_dphy_pll_cfg.isra.4':
>> cdns-dsi.c:(.text+0xfdd): undefined reference to `__udivdi3'

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


.config.gz
Description: application/gzip
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: [PATCH] drm/ast: Fixed reboot test may cause system hanged

2018-04-10 Thread YC Chen

Hi Ben,
Thanks for your reply. You need to open password register before modify 
extended CRT registers. Extended CRT registers cannot be modified if the read 
back value of password register is 0.
Allow me to describe this issue more. This issue only happen on Intel 
x86/x86_64 system actually. We found there is a another thread still access VGA 
cursor registers when loading "ast" drm driver. VGA register is index I/O 
register, if two threads access it alternately, it may cause the un-expected 
settings. "ast" drm driver is using related IO or MMIO to access register, and 
the thread is using standard VGA IO(0x3d4) to access cursor register, so our 
solution is disabling standard VGA decoding(Set VGACRA1 D[1] to 1) at the entry 
of "ast" driver load to avoid this issue.

Regards,

Y.C. Chen

-Original Message-
From: Benjamin Herrenschmidt [mailto:b...@kernel.crashing.org] 
Sent: Wednesday, April 11, 2018 9:54 AM
To: YC Chen ; dri-devel@lists.freedesktop.org
Cc: airl...@redhat.com; e...@suse.com
Subject: Re: [PATCH] drm/ast: Fixed reboot test may cause system hanged

On Wed, 2018-04-11 at 09:27 +0800, Y.C. Chen wrote:
> index dac3558..82a2687 100644
> --- a/drivers/gpu/drm/ast/ast_main.c
> +++ b/drivers/gpu/drm/ast/ast_main.c
> @@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, 
> bool *need_post)
>  
>  
> /* Enable extended register access */
> -   ast_enable_mmio(dev);
> ast_open_key(ast);
> +   ast_enable_mmio(dev);

Why that change ? The documentation doesn't really specify what the "password" 
register is about. What does it "open" ?

I'm being a bit paranoid because we had issues with earlier drivers (before 
some of the latest changes to that code) where occasionally on boot, the chip 
wouldn't respond to an MMIO to one of the VGA registers, causing an EEH error 
which crashes on boot.

So I want to make sure I understand what the changes precisely do.

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

[DPU PATCH v2 1/2] drm/msm/dsi: check video mode engine status before waiting

2018-04-10 Thread Abhinav Kumar

Make sure the video mode engine is on before waiting
for the video done interrupt.

Otherwise it leads to silent timeouts increasing display
turn ON time.

Changes in v2:
- Replace pr_err with dev_err
- Changed error message

Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/dsi_host.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..5b7b290 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -173,6 +173,7 @@ struct msm_dsi_host {
 
bool registered;
bool power_on;
+   bool enabled;
int irq;
 };
 
@@ -986,13 +987,19 @@ static void dsi_set_tx_power_mode(int mode, struct 
msm_dsi_host *msm_host)
 
 static void dsi_wait4video_done(struct msm_dsi_host *msm_host)
 {
+   u32 ret = 0;
+   struct device *dev = _host->pdev->dev;
+
dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 1);
 
reinit_completion(_host->video_comp);
 
-   wait_for_completion_timeout(_host->video_comp,
+   ret = wait_for_completion_timeout(_host->video_comp,
msecs_to_jiffies(70));
 
+   if (ret <= 0)
+   dev_err(dev, "wait for video done timed out\n");
+
dsi_intr_ctrl(msm_host, DSI_IRQ_MASK_VIDEO_DONE, 0);
 }
 
@@ -1001,7 +1008,7 @@ static void dsi_wait4video_eng_busy(struct msm_dsi_host 
*msm_host)
if (!(msm_host->mode_flags & MIPI_DSI_MODE_VIDEO))
return;
 
-   if (msm_host->power_on) {
+   if (msm_host->power_on && msm_host->enabled) {
dsi_wait4video_done(msm_host);
/* delay 4 ms to skip BLLP */
usleep_range(2000, 4000);
@@ -2203,7 +2210,7 @@ int msm_dsi_host_enable(struct mipi_dsi_host *host)
 *  pm_runtime_put_autosuspend(_host->pdev->dev);
 * }
 */
-
+   msm_host->enabled = true;
return 0;
 }
 
@@ -2219,7 +2226,7 @@ int msm_dsi_host_disable(struct mipi_dsi_host *host)
 * Reset to disable video engine so that we can send off cmd.
 */
dsi_sw_reset(msm_host);
-
+   msm_host->enabled = false;
return 0;
 }
 
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[DPU PATCH v2 2/2] drm/msm/dsi: implement auto PHY timing calculator for 10nm PHY

2018-04-10 Thread Abhinav Kumar

Currently the DSI PHY timings are hard-coded for a specific panel
for the 10nm PHY.

Replace this with the auto PHY timing calculator which can calculate
the PHY timings for any panel.

Changes in v2:
- None

Reviewed-by: Archit Taneja 
Signed-off-by: Abhinav Kumar 
---
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.c  | 111 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy.h  |   2 +
 drivers/gpu/drm/msm/dsi/phy/dsi_phy_10nm.c |  28 
 3 files changed, 113 insertions(+), 28 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c 
b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
index 8e9d5c2..5b42885 100644
--- a/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
+++ b/drivers/gpu/drm/msm/dsi/phy/dsi_phy.c
@@ -265,6 +265,117 @@ int msm_dsi_dphy_timing_calc_v2(struct 
msm_dsi_dphy_timing *timing,
return 0;
 }
 
+int msm_dsi_dphy_timing_calc_v3(struct msm_dsi_dphy_timing *timing,
+  struct msm_dsi_phy_clk_request *clk_req)
+{
+   const unsigned long bit_rate = clk_req->bitclk_rate;
+   const unsigned long esc_rate = clk_req->escclk_rate;
+   s32 ui, ui_x8, lpx;
+   s32 tmax, tmin;
+   s32 pcnt0 = 50;
+   s32 pcnt1 = 50;
+   s32 pcnt2 = 10;
+   s32 pcnt3 = 30;
+   s32 pcnt4 = 10;
+   s32 pcnt5 = 2;
+   s32 coeff = 1000; /* Precision, should avoid overflow */
+   s32 hb_en, hb_en_ckln;
+   s32 temp;
+
+   if (!bit_rate || !esc_rate)
+   return -EINVAL;
+
+   timing->hs_halfbyte_en = 0;
+   hb_en = 0;
+   timing->hs_halfbyte_en_ckln = 0;
+   hb_en_ckln = 0;
+
+   ui = mult_frac(NSEC_PER_MSEC, coeff, bit_rate / 1000);
+   ui_x8 = ui << 3;
+   lpx = mult_frac(NSEC_PER_MSEC, coeff, esc_rate / 1000);
+
+   temp = S_DIV_ROUND_UP(38 * coeff, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (95 * coeff) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->clk_prepare = linear_inter(tmax, tmin, pcnt0, 0, false);
+
+
+   temp = 300 * coeff - (timing->clk_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = (tmin > 255) ? 511 : 255;
+   timing->clk_zero = linear_inter(tmax, tmin, pcnt5, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 3 * ui, ui_x8);
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp + 3 * ui) / ui_x8;
+   timing->clk_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = S_DIV_ROUND_UP(40 * coeff + 4 * ui, ui_x8);
+   tmin = max_t(s32, temp, 0);
+   temp = (85 * coeff + 6 * ui) / ui_x8;
+   tmax = max_t(s32, temp, 0);
+   timing->hs_prepare = linear_inter(tmax, tmin, pcnt1, 0, false);
+
+   temp = 145 * coeff + 10 * ui - (timing->hs_prepare << 3) * ui;
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_zero = linear_inter(tmax, tmin, pcnt4, 0, false);
+
+   tmin = DIV_ROUND_UP(60 * coeff + 4 * ui, ui_x8) - 1;
+   temp = 105 * coeff + 12 * ui - 20 * coeff;
+   tmax = (temp / ui_x8) - 1;
+   timing->hs_trail = linear_inter(tmax, tmin, pcnt3, 0, false);
+
+   temp = 50 * coeff + ((hb_en << 2) - 8) * ui;
+   timing->hs_rqst = S_DIV_ROUND_UP(temp, ui_x8);
+
+   tmin = DIV_ROUND_UP(100 * coeff, ui_x8) - 1;
+   tmax = 255;
+   timing->hs_exit = linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 50 * coeff + ((hb_en_ckln << 2) - 8) * ui;
+   timing->hs_rqst_ckln = S_DIV_ROUND_UP(temp, ui_x8);
+
+   temp = 60 * coeff + 52 * ui - 43 * ui;
+   tmin = DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   timing->shared_timings.clk_post =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+
+   temp = 8 * ui + (timing->clk_prepare << 3) * ui;
+   temp += (((timing->clk_zero + 3) << 3) + 11) * ui;
+   temp += hb_en_ckln ? (((timing->hs_rqst_ckln << 3) + 4) * ui) :
+   (((timing->hs_rqst_ckln << 3) + 8) * ui);
+   tmin = S_DIV_ROUND_UP(temp, ui_x8) - 1;
+   tmax = 63;
+   if (tmin > tmax) {
+   temp = linear_inter(tmax << 1, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre = temp >> 1;
+   timing->shared_timings.clk_pre_inc_by_2 = 1;
+   } else {
+   timing->shared_timings.clk_pre =
+   linear_inter(tmax, tmin, pcnt2, 0, false);
+   timing->shared_timings.clk_pre_inc_by_2 = 0;
+   }
+
+   timing->ta_go = 3;
+   timing->ta_sure = 0;
+   timing->ta_get = 4;
+
+   DBG("%d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d, %d",
+   timing->shared_timings.clk_pre, timing->shared_timings.clk_post,
+   timing->shared_timings.clk_pre_inc_by_2, timing->clk_zero,
+   timing->clk_trail, timing->clk_prepare, timing->hs_exit,
+   timing->hs_zero, timing->hs_prepare, timing->hs_trail,
+

[PATCH] drm/ast: Fixed reboot test may cause system hanged

2018-04-10 Thread Y.C. Chen

From: "Y.C. Chen" 

There is another thread still access standard VGA I/O while loading drm driver.
Disable standard VGA I/O decode to avoid this issue.

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

diff --git a/drivers/gpu/drm/ast/ast_main.c b/drivers/gpu/drm/ast/ast_main.c
index dac3558..82a2687 100644
--- a/drivers/gpu/drm/ast/ast_main.c
+++ b/drivers/gpu/drm/ast/ast_main.c
@@ -131,8 +131,8 @@ static int ast_detect_chip(struct drm_device *dev, bool 
*need_post)
 
 
/* Enable extended register access */
-   ast_enable_mmio(dev);
ast_open_key(ast);
+   ast_enable_mmio(dev);
 
/* Find out whether P2A works or whether to use device-tree */
ast_detect_config_mode(dev, _rev);
@@ -576,6 +576,9 @@ void ast_driver_unload(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
+   /* enable standard VGA decode */
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x04);
+
ast_release_firmware(dev);
kfree(ast->dp501_fw_addr);
ast_mode_fini(dev);
diff --git a/drivers/gpu/drm/ast/ast_mode.c b/drivers/gpu/drm/ast/ast_mode.c
index 831b733..9d637b4 100644
--- a/drivers/gpu/drm/ast/ast_mode.c
+++ b/drivers/gpu/drm/ast/ast_mode.c
@@ -599,7 +599,7 @@ static int ast_crtc_mode_set(struct drm_crtc *crtc,
return -EINVAL;
ast_open_key(ast);
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 
ast_set_std_reg(crtc, adjusted_mode, _mode);
ast_set_crtc_reg(crtc, adjusted_mode, _mode);
diff --git a/drivers/gpu/drm/ast/ast_post.c b/drivers/gpu/drm/ast/ast_post.c
index f7d4213..c1d1ac5 100644
--- a/drivers/gpu/drm/ast/ast_post.c
+++ b/drivers/gpu/drm/ast/ast_post.c
@@ -46,7 +46,7 @@ void ast_enable_mmio(struct drm_device *dev)
 {
struct ast_private *ast = dev->dev_private;
 
-   ast_set_index_reg_mask(ast, AST_IO_CRTC_PORT, 0xa1, 0xff, 0x04);
+   ast_set_index_reg(ast, AST_IO_CRTC_PORT, 0xa1, 0x06);
 }
 
 
-- 
1.8.3.1

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

[DPU PATCH 1/2] drm/msm/dsi: adjust dsi timing for dual dsi mode

2018-04-10 Thread Chandan Uddaraju

For dual dsi mode, the horizontal timing needs
to be divided by half since both the dsi controllers
will be driving this panel. Adjust the pixel clock and
DSI timing accordingly.

Change-Id: Iee1226b2eef9eea23d9653e3d738ee8cd2a2dd8e
Signed-off-by: Chandan Uddaraju 
---
 drivers/gpu/drm/msm/dsi/dsi.h |  1 +
 drivers/gpu/drm/msm/dsi/dsi_host.c| 17 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 15 +++
 3 files changed, 33 insertions(+)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 70d9a9a..4131b47 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -161,6 +161,7 @@ void msm_dsi_host_cmd_xfer_commit(struct mipi_dsi_host 
*host,
u32 dma_base, u32 len);
 int msm_dsi_host_enable(struct mipi_dsi_host *host);
 int msm_dsi_host_disable(struct mipi_dsi_host *host);
+void msm_dsi_host_adjust_timing_config(struct mipi_dsi_host *host);
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings);
 int msm_dsi_host_power_off(struct mipi_dsi_host *host);
diff --git a/drivers/gpu/drm/msm/dsi/dsi_host.c 
b/drivers/gpu/drm/msm/dsi/dsi_host.c
index 7a03a94..66a21cb 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_host.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_host.c
@@ -2237,6 +2237,23 @@ static void msm_dsi_sfpb_config(struct msm_dsi_host 
*msm_host, bool enable)
SFPB_GPREG_MASTER_PORT_EN(en));
 }
 
+void msm_dsi_host_adjust_timing_config(struct mipi_dsi_host *host)
+{
+   struct msm_dsi_host *msm_host = to_msm_dsi_host(host);
+   struct drm_display_mode *mode = NULL;
+
+   mode = msm_host->mode;
+
+   mutex_lock(_host->dev_mutex);
+   mode->htotal >>= 1;
+   mode->hdisplay >>= 1;
+   mode->hsync_start >>= 1;
+   mode->hsync_end >>= 1;
+
+   mode->clock >>= 1;
+   mutex_unlock(_host->dev_mutex);
+}
+
 int msm_dsi_host_power_on(struct mipi_dsi_host *host,
struct msm_dsi_phy_shared_timings *phy_shared_timings)
 {
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 4cb1cb6..8ef1c3d 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -627,6 +627,21 @@ static void dsi_mgr_bridge_mode_set(struct drm_bridge 
*bridge,
msm_dsi_host_set_display_mode(host, adjusted_mode);
if (is_dual_dsi && other_dsi)
msm_dsi_host_set_display_mode(other_dsi->host, adjusted_mode);
+
+   /*
+* For dual DSI mode, the current DRM mode has
+* the complete width of the panel. Since, the complete
+* panel is driven by two DSI controllers, the
+* horizontal timings and the pixel clock have to be
+* split between the two dsi controllers. Adjust the
+* DSI host timing structures accordingly.
+*/
+   if (is_dual_dsi) {
+   msm_dsi_host_adjust_timing_config(host);
+   if (other_dsi)
+   msm_dsi_host_adjust_timing_config(other_dsi->host);
+   }
+
 }
 
 static const struct drm_connector_funcs dsi_mgr_connector_funcs = {
-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[DPU PATCH 2/2] drm/msm/dsi: Use one connector for dual DSI mode

2018-04-10 Thread Chandan Uddaraju

Current DSI driver uses two connectors for dual DSI case even
though we only have one panel. Fix this by implementing one
connector/bridge for dual DSI use case. Use master DSI
controllers to register one connector/bridge.

Change-Id: I067b39f3b32eb3aa92d4155d4ca703ca7690645b
Signed-off-by: Chandan Uddaraju 
---
 drivers/gpu/drm/msm/dsi/dsi.c |   3 +
 drivers/gpu/drm/msm/dsi/dsi.h |   1 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 110 --
 3 files changed, 29 insertions(+), 85 deletions(-)

diff --git a/drivers/gpu/drm/msm/dsi/dsi.c b/drivers/gpu/drm/msm/dsi/dsi.c
index b744bcc..ff8164c 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.c
+++ b/drivers/gpu/drm/msm/dsi/dsi.c
@@ -208,6 +208,9 @@ int msm_dsi_modeset_init(struct msm_dsi *msm_dsi, struct 
drm_device *dev,
goto fail;
}
 
+   if (!msm_dsi_manager_validate_current_config(msm_dsi->id))
+   goto fail;
+
msm_dsi->encoder = encoder;
 
msm_dsi->bridge = msm_dsi_manager_bridge_init(msm_dsi->id);
diff --git a/drivers/gpu/drm/msm/dsi/dsi.h b/drivers/gpu/drm/msm/dsi/dsi.h
index 4131b47..d487d94 100644
--- a/drivers/gpu/drm/msm/dsi/dsi.h
+++ b/drivers/gpu/drm/msm/dsi/dsi.h
@@ -100,6 +100,7 @@ struct msm_dsi {
 void msm_dsi_manager_attach_dsi_device(int id, u32 device_flags);
 int msm_dsi_manager_register(struct msm_dsi *msm_dsi);
 void msm_dsi_manager_unregister(struct msm_dsi *msm_dsi);
+bool msm_dsi_manager_validate_current_config(u8 id);
 
 /* msm dsi */
 static inline bool msm_dsi_device_connected(struct msm_dsi *msm_dsi)
diff --git a/drivers/gpu/drm/msm/dsi/dsi_manager.c 
b/drivers/gpu/drm/msm/dsi/dsi_manager.c
index 8ef1c3d..5817f59 100644
--- a/drivers/gpu/drm/msm/dsi/dsi_manager.c
+++ b/drivers/gpu/drm/msm/dsi/dsi_manager.c
@@ -305,67 +305,6 @@ static void dsi_mgr_connector_destroy(struct drm_connector 
*connector)
kfree(dsi_connector);
 }
 
-static void dsi_dual_connector_fix_modes(struct drm_connector *connector)
-{
-   struct drm_display_mode *mode, *m;
-
-   /* Only support left-right mode */
-   list_for_each_entry_safe(mode, m, >probed_modes, head) {
-   mode->clock >>= 1;
-   mode->hdisplay >>= 1;
-   mode->hsync_start >>= 1;
-   mode->hsync_end >>= 1;
-   mode->htotal >>= 1;
-   drm_mode_set_name(mode);
-   }
-}
-
-static int dsi_dual_connector_tile_init(
-   struct drm_connector *connector, int id)
-{
-   struct drm_display_mode *mode;
-   /* Fake topology id */
-   char topo_id[8] = {'M', 'S', 'M', 'D', 'U', 'D', 'S', 'I'};
-
-   if (connector->tile_group) {
-   DBG("Tile property has been initialized");
-   return 0;
-   }
-
-   /* Use the first mode only for now */
-   mode = list_first_entry(>probed_modes,
-   struct drm_display_mode,
-   head);
-   if (!mode)
-   return -EINVAL;
-
-   connector->tile_group = drm_mode_get_tile_group(
-   connector->dev, topo_id);
-   if (!connector->tile_group)
-   connector->tile_group = drm_mode_create_tile_group(
-   connector->dev, topo_id);
-   if (!connector->tile_group) {
-   pr_err("%s: failed to create tile group\n", __func__);
-   return -ENOMEM;
-   }
-
-   connector->has_tile = true;
-   connector->tile_is_single_monitor = true;
-
-   /* mode has been fixed */
-   connector->tile_h_size = mode->hdisplay;
-   connector->tile_v_size = mode->vdisplay;
-
-   /* Only support left-right mode */
-   connector->num_h_tile = 2;
-   connector->num_v_tile = 1;
-
-   connector->tile_v_loc = 0;
-   connector->tile_h_loc = (id == DSI_RIGHT) ? 1 : 0;
-
-   return 0;
-}
-
 static int dsi_mgr_connector_get_modes(struct drm_connector *connector)
 {
int id = dsi_mgr_connector_get_id(connector);
@@ -376,31 +315,15 @@ static int dsi_mgr_connector_get_modes(struct 
drm_connector *connector)
if (!panel)
return 0;
 
-   /* Since we have 2 connectors, but only 1 drm_panel in dual DSI mode,
-* panel should not attach to any connector.
-* Only temporarily attach panel to the current connector here,
-* to let panel set mode to this connector.
+   /*
+* In dual DSI mode, we have one connector that can be
+* attached to the drm_panel.
 */
drm_panel_attach(panel, connector);
num = drm_panel_get_modes(panel);
-   drm_panel_detach(panel);
if (!num)
return 0;
 
-   if (IS_DUAL_DSI()) {
-   /* report half resolution to user */
-   dsi_dual_connector_fix_modes(connector);
-   ret = dsi_dual_connector_tile_init(connector, id);
-

[DPU PATCH 0/2] Connector virtualization for Dual-DSI

2018-04-10 Thread Chandan Uddaraju

This patch series adds support to DSI connector
virtualization for Dual-DSI configuration.

These changes have been tested using dual-dsi truly panel on sdm845 platform.

Additional changes that will be needed to have end-to-end functionality:
 --> DSI6G-v2 changes: https://patchwork.kernel.org/patch/10294605/
 --> truly panel patches: https://patchwork.kernel.org/patch/10327749/
 --> DPU changes that will be uploaded soon.


Chandan Uddaraju (2):
  drm/msm/dsi: adjust dsi timing for dual dsi mode
  drm/msm/dsi: Use one connector for dual DSI mode

 drivers/gpu/drm/msm/dsi/dsi.c |   3 +
 drivers/gpu/drm/msm/dsi/dsi.h |   2 +
 drivers/gpu/drm/msm/dsi/dsi_host.c|  17 +
 drivers/gpu/drm/msm/dsi/dsi_manager.c | 125 +++---
 4 files changed, 62 insertions(+), 85 deletions(-)

-- 
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

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

[PATCHv2] drm/i2c: tda998x: Remove VLA usage

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
v2: Switch to make the buffer size more transparent and add a bounds
check.
---
 drivers/gpu/drm/i2c/tda998x_drv.c | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/i2c/tda998x_drv.c 
b/drivers/gpu/drm/i2c/tda998x_drv.c
index 9e67a7b4e3a4..c8b6029b7839 100644
--- a/drivers/gpu/drm/i2c/tda998x_drv.c
+++ b/drivers/gpu/drm/i2c/tda998x_drv.c
@@ -466,13 +466,22 @@ reg_read_range(struct tda998x_priv *priv, u16 reg, char 
*buf, int cnt)
return ret;
 }
 
+#define MAX_WRITE_RANGE_BUF 32
+
 static void
 reg_write_range(struct tda998x_priv *priv, u16 reg, u8 *p, int cnt)
 {
struct i2c_client *client = priv->hdmi;
-   u8 buf[cnt+1];
+   /* This is the maximum size of the buffer passed in */
+   u8 buf[MAX_WRITE_RANGE_BUF + 1];
int ret;
 
+   if (cnt > MAX_WRITE_RANGE_BUF) {
+   dev_err(>dev, "Fixed write buffer too small (%d)\n",
+   MAX_WRITE_RANGE_BUF);
+   return;
+   }
+
buf[0] = REG2ADDR(reg);
memcpy([1], p, cnt);
 
@@ -679,7 +688,7 @@ static void
 tda998x_write_if(struct tda998x_priv *priv, u8 bit, u16 addr,
 union hdmi_infoframe *frame)
 {
-   u8 buf[32];
+   u8 buf[MAX_WRITE_RANGE_BUF];
ssize_t len;
 
len = hdmi_infoframe_pack(frame, buf, sizeof(buf));
-- 
2.14.3

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

[PATCHv2] drm/amdkfd: Remove vla

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. Switch to a constant value that covers all hardware.

[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
v2: Switch to a larger size to account for other hardware
---
 drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index 035c351f47c5..c3a5a80e31ae 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
 {
struct kfd_dev *dev = container_of(work, struct kfd_dev,
interrupt_work);
+   uint32_t ih_ring_entry[8];
 
-   uint32_t ih_ring_entry[DIV_ROUND_UP(
-   dev->device_info->ih_ring_entry_size,
-   sizeof(uint32_t))];
+   if (dev->device_info->ih_ring_entry_size > (8 * sizeof(uint32_t))) {
+   dev_err(kfd_chardev(), "Ring entry too small\n");
+   return;
+   }
 
while (dequeue_ih_ring_entry(dev, ih_ring_entry))
dev->device_info->event_interrupt_class->interrupt_wq(dev,
-- 
2.14.3

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

[Bug 101145] Wine game needs GLSL override for fullscreen

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #4 from Timothy Arceri  ---
This looks like an issue with compat profile which until recently was limited
to OpenGL 3.0 (radeonsi now supports 3.1). You seem to be working around it by
forcing a lower GLSL version. Recent Wine versions now use Core profile when
they detect Mesa, either way I don't think this is a Mesa bug.

Future Mesa version will likely support higher compat versions, but Apps (and
Wine) need to properly check supported features.

-- 
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 103907] [gfx9/Vega] Arma 3 crashes on 17.3.0-rc5 but works on master

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |NEEDINFO

--- Comment #2 from Timothy Arceri  ---
(In reply to Nicolai Hähnle from comment #1)
> Thanks for the report! Could you please provide a backtrace with debug
> symbols?
> 
> Also, could you please check whether the 17.3-branchpoint crashes, and
> depending on the result, use a `git bisect` to find the commit that either
> fixed this on master or broke it on 17.3.

Ping. Is this now working with the current 17.3 release? If not are you able to
bisect as per the request above by Nicola?

-- 
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 105941] Dolphin emulator crashes a few seconds after playing a game

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

--- Comment #1 from Timothy Arceri  ---
(In reply to siyia from comment #0)
> With mesa 18.0.0 and amdgpu module with oland gpu,dolphin-emu crashes.Mesa
> 18 with radeon module and mesa 17.3.8 with amdgpu module do not crash.
> 
> Additional info: tried kernels 4.14 and 4.16,dolphin-emu git and
> stable,opengl backend

Can you get a stack trace of the crash?

-- 
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: RFC for a render API to support adaptive sync and VRR

> From: Manasi Navare [mailto:manasi.d.nav...@intel.com]
> Sent: Tuesday, April 10, 2018 17:37
> To: Wentland, Harry 
> Cc: amd-gfx mailing list ; Daniel Vetter 
> ; Haehnle, Nicolai
> ; Daenzer, Michel ; Deucher, 
> Alexander ;
> Koenig, Christian ; dri-devel 
> ; Cyr, Aric ; Koo,
> Anthony 
> Subject: Re: RFC for a render API to support adaptive sync and VRR
> 
> On Tue, Apr 10, 2018 at 11:03:02AM -0400, Harry Wentland wrote:
> > Adding Anthony and Aric who've been working on Freesync with DC on other 
> > OSes for a while.
> >
> > On 2018-04-09 05:45 PM, Manasi Navare wrote:
> > > Thanks for initiating the discussion. Find my comments below:
> > >
> > > On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> > >> Adding dri-devel, which I should've included from the start.
> > >>
> > >> On 2018-04-09 03:56 PM, Harry Wentland wrote:
> > >>> === What is adaptive sync and VRR? ===
> > >>>
> > >>> Adaptive sync has been part of the DisplayPort spec for a while now and 
> > >>> allows graphics adapters to drive displays with varying
> frame timings. VRR (variable refresh rate) is essentially the same, but 
> defined for HDMI.
> > >>>
> > >>>
> > >>>
> > >>> === Why allow variable frame timings? ===
> > >>>
> > >>> Variable render times don't align with fixed refresh rates, leading to
> > >>> stuttering, tearing, and/or input lag.
> > >>>
> > >>> e.g. (rc = render completion, dr = display refresh)
> > >>>
> > >>> rc   B  CDE  F
> > >>> dr  A   B   C   C   D   E   F
> > >>>
> > >>> ^ ^
> > >>>   frame missed
> > >>>  repeated   display
> > >>>   twice refresh
> > >>>
> > >>>
> > >>>
> > >>> === Other use cases of adaptive sync 
> > >>>
> > >>> Beside the variable render case, adaptive sync also allows adjustment 
> > >>> of refresh rates without a mode change. One such use
> case would be 24 Hz video.
> > >>>
> > >
> > > One of the the advantages here when the render speed is slower than the 
> > > display refresh rate, since we are stretching the vertical
> blanking interval
> > > the display adapters will follow "draw fast and then go idle" approach. 
> > > This gives power savings when render rate is lower than the
> display refresh rate.
> >
> > Are you talking about a use case, such as an idle desktop, where the 
> > renders are quite sporadic?
> >
> 
> I was refering to a case where the render rate is lower say 24Hz but the 
> display rate is fixed 60Hz, that means we are pretty much
> displaying the same frame
> twice. But with Adaptive Sync, the display rate would be lowered to 24hz and 
> the vertical blanking time will be stretched where
> instead of drawing the
> same frame twice, the system is now idle in that extra blanking time thus 
> giving some power savings.

Hi Manasi,

Assuming the panel could go down to 24Hz, this would be possible.  
If it was a game, it'd naturally do this since the refresh rate would track the 
render rate. 

For a video where you have an adaptive sync capable player, it could request a 
fixed duration to achieve the same thing.
Most panels do not support as low as 24Hz however, so usually in the video case 
at least you'd end up with say 48Hz with the driver/HW providing automatic 
frame doubling.

> > >
> > >>>
> > >>>
> > >>> === A DRM render API to support variable refresh rates ===
> > >>>
> > >>> In order to benefit from adaptive sync and VRR userland needs a way to 
> > >>> let us know whether to vary frame timings or to target
> a different frame time. These can be provided as atomic properties on a CRTC:
> > >>>  * bool variable_refresh_compatible
> > >>>  * int  target_frame_duration_ns (nanosecond frame duration)
> > >>>
> > >>> This gives us the following cases:
> > >>>
> > >>> variable_refresh_compatible = 0, target_frame_duration_ns = 0
> > >>>  * drive monitor at timing's normal refresh rate
> > >>>
> > >>> variable_refresh_compatible = 1, target_frame_duration_ns = 0
> > >>>  * send new frame to monitor as soon as it's available, if within 
> > >>> min/max of monitor's reported capabilities
> > >>>
> > >>> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
> > >>>  * send new frame to monitor with the specified target_frame_duration_ns
> > >>>
> > >>> When a target_frame_duration_ns or variable_refresh_compatible cannot 
> > >>> be supported the atomic check will reject the
> commit.
> > >>>
> > >
> > > What I would like is two sets of properties on a CRTC or preferably on a 
> > > connector:
> > >
> > > KMD properties that UMD can query:
> > > * vrr_capable -  This will be an immutable property for exposing 
>

Re: [PATCH] drm/i2c: tda998x: Remove VLA usage


On 04/09/2018 03:21 PM, Russell King - ARM Linux wrote:

On Mon, Apr 09, 2018 at 02:07:03PM -0700, Laura Abbott wrote:

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The vla in reg_write_range is based on the length of data
passed. The one use of a non-constant size for this range is bounded by
the size buffer passed to hdmi_infoframe_pack which is a fixed size.
Switch to this upper bound.


Does this _really_ make it safer?  What if the code is modified to write
more than 32 bytes in the future?

Sorry, I don't think this is safer at all.



Yeah I wasn't 100% sure about this one. Elsewhere, we've added bounds
checks against the new static size buffer so we could do that here
to ensure we don't overrun the stack if we do need to write more
than 32 bytes in the future. Another option is to switch to
a kmalloc buffer. Are either of those options acceptable to you or
do you have a better idea of how to get rid of the VLA?

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

RE: RFC for a render API to support adaptive sync and VRR

> From: Haehnle, Nicolai
> Sent: Tuesday, April 10, 2018 13:48
> On 10.04.2018 19:25, Cyr, Aric wrote:
> >> -Original Message-
> >> From: Michel Dänzer [mailto:mic...@daenzer.net]
> >> Sent: Tuesday, April 10, 2018 13:16
> >>
> >> On 2018-04-10 07:13 PM, Cyr, Aric wrote:
>  -Original Message-
>  From: Michel Dänzer [mailto:mic...@daenzer.net]
>  Sent: Tuesday, April 10, 2018 13:06
>  On 2018-04-10 06:26 PM, Cyr, Aric wrote:
> > From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43
> >
> >> For video games we have a similar situation where a frame is rendered
> >> for a certain world time and in the ideal case we would actually
> >> display the frame at this world time.
> >
> > That seems like it would be a poorly written game that flips like
> > that, unless they are explicitly trying to throttle the framerate for
> > some reason.  When a game presents a completed frame, they’d like
> > that to happen as soon as possible.
> 
>  What you're describing is what most games have been doing traditionally.
>  Croteam's research shows that this results in micro-stuttering, because
>  frames may be presented too early. To avoid that, they want to
>  explicitly time each presentation as described by Christian.
> >>>
> >>> Yes, I agree completely.  However that's only truly relevant for fixed
> >>> refreshed rate displays.
> >>
> >> No, it also affects variable refresh; possibly even more in some cases,
> >> because the presentation time is less predictable.
> >
> > Yes, and that's why you don't want to do it when you have variable refresh. 
> >  The hardware in the monitor and GPU will do it for you,
> so why bother?
> 
> I think Michel's point is that the monitor and GPU hardware *cannot*
> really do this, because there's synchronization with audio to take into
> account, which the GPU or monitor don't know about.

How does it work fine today given that all kernel seems to know is 'current' or 
'current+1' vsyncs.  
Presumably the applications somehow schedule all this just fine.
If this works without variable refresh for 60Hz, will it not work for a 
fixed-rate "48Hz" monitor (assuming a 24Hz video)?

> Also, as I wrote separately, there's the case of synchronizing multiple
> monitors.

For multimonitor to work with VRR, they'll have to be timing and flip 
synchronized.
This is impossible for an application to manage, it needs driver/HW control or 
you end up with one display flipping before the other and it looks terrible.
And definitely forget about multiGPU without professional workstation-type 
support needed to sync the displays across adapters.

> > The input to their algorithms will be noisy causing worst estimations.  If 
> > you just present as fast as you can, it'll just work (within
> reason).
> > The majority of gamers want maximum FPS for their games, and there's quite 
> > frequently outrage at a particular game when they are
> limited to something lower that what their monitor could otherwise support 
> (i.e. I don't want my game limited to 30Hz if I have a shiny
> 144Hz gaming display I paid good money for).   Of course, there's always 
> exceptions... but in our experience those are few and far
> between.
> 
> I agree that games most likely shouldn't try to be smart. I'm curious
> about the Croteam findings, but even if they did a really clever thing
> that works better than just telling the display driver "display ASAP
> please", chances are that *most* developers won't do that. And they'll
> most likely get it wrong, so our guidance should really be "games should
> ask for ASAP presentation, and nothing else".

Right, I think this is the 'easy' case and is covered in Harry's initial 
proposal when target_frame_duration_ns = 0.

> However, there *are* legitimate use cases for requesting a specific
> presentation time, and there *is* precedent of APIs that expose such
> features.
>
> Are there any real problems with exposing an absolute target present time?

Realistically, how far into the future are you requesting a presentation time? 
Won't it almost always be something like current_time+1000/video_frame_rate?
If so, why not just tell the driver to set 1000/video_frame_rate and have the 
GPU/monitor create nicely spaced VSYNCs for you that match the source content?

In fact, you probably wouldn't even need to change your video player at all, 
other than having it pass the target_frame_duration_ns.  You could consider 
this a 'hint' as you suggested, since it's cannot be guaranteed in cases your 
driver or HW doesn't support variable refresh.  If the target_frame_duration_ns 
hint is supported/applied, then the video app should have nothing extra to do 
that it wouldn't already do for any arbitrary fixed-refresh rate display.  If 
not supported (say the drm_atomic_check fails with -EINVAL or something), the 
video app falls can stop requesting a fixed target_frame_duration_ns.

A fundamental problem

Re: [PATCH 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

Le mardi 10 avril 2018 à 23:31 +0200, Paul Kocialkowski a écrit :
> This adds support for the Ainol AW1, an A20-based 7" tablet from
> Ainol.

This version didn't use the dedicated binding for the panel and will be
fixed in v2 and onwards.

> The following board-specific features are supported:
> * LCD panel
> * Backlight
> * USB OTG
> * Buttons
> * Touchscreen (doesn't work without non-free firmware)
> * Accelerometer
> * Battery
> 
> The following are untested:
> * Audio output
> * Audio speakers
> * USB via SPCI connector
> 
> The following are not supported:
> * Wi-Fi
> * Bluetooth
> * NAND
> * Audio via SPCI connector
> 
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm/boot/dts/Makefile|   1 +
>  arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts | 358
> ++
>  2 files changed, 359 insertions(+)
>  create mode 100644 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> 
> diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
> index 9f7133b6fba0..03bfacebfdbd 100644
> --- a/arch/arm/boot/dts/Makefile
> +++ b/arch/arm/boot/dts/Makefile
> @@ -929,6 +929,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
>   sun6i-a31s-sinovoip-bpi-m2.dtb \
>   sun6i-a31s-yones-toptech-bs1078-v2.dtb
>  dtb-$(CONFIG_MACH_SUN7I) += \
> + sun7i-a20-ainol-aw1.dtb \
>   sun7i-a20-bananapi.dtb \
>   sun7i-a20-bananapi-m1-plus.dtb \
>   sun7i-a20-bananapro.dtb \
> diff --git a/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> new file mode 100644
> index ..697586991aea
> --- /dev/null
> +++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
> @@ -0,0 +1,358 @@
> +/*
> + * Copyright 2018 Paul Kocialkowski 
> + *
> + * This file is dual-licensed: you can use it either under the terms
> + * of the GPL or the X11 license, at your option. Note that this dual
> + * licensing only applies to this file, and not this project as a
> + * whole.
> + *
> + *  a) This file is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> the
> + * License, or (at your option) any later version.
> + *
> + * This file is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * Or, alternatively,
> + *
> + *  b) Permission is hereby granted, free of charge, to any person
> + * obtaining a copy of this software and associated documentation
> + * files (the "Software"), to deal in the Software without
> + * restriction, including without limitation the rights to use,
> + * copy, modify, merge, publish, distribute, sublicense, and/or
> + * sell copies of the Software, and to permit persons to whom the
> + * Software is furnished to do so, subject to the following
> + * conditions:
> + *
> + * The above copyright notice and this permission notice shall be
> + * included in all copies or substantial portions of the
> Software.
> + *
> + * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY
> KIND,
> + * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE
> WARRANTIES
> + * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> + * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
> + * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
> + * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
> + * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
> + * OTHER DEALINGS IN THE SOFTWARE.
> + */
> +
> +/dts-v1/;
> +#include "sun7i-a20.dtsi"
> +#include "sunxi-common-regulators.dtsi"
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +/ {
> + model = "Ainol AW1";
> + compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
> +
> + aliases {
> + serial0 = 
> + };
> +
> + chosen {
> + stdout-path = "serial0:115200n8";
> + };
> +
> + backlight: backlight {
> + compatible = "pwm-backlight";
> + pinctrl-names = "default";
> + pinctrl-0 = <_enable_pin>;
> + pwms = < 0 5 PWM_POLARITY_INVERTED>;
> + brightness-levels = <0 10 20 30 40 50 60 70 80 90
> 100>;
> + default-brightness-level = <5>;
> + enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
> + };
> +
> + panel: panel {
> + compatible = "innolux,at070tn92";
> + #address-cells = <1>;
> + #size-cells = <0>;
> + power-supply = <_power>;
> + backlight = <>;
> +
> + port@0 {
> + reg = <0>;
> + #address-cells = <1>;
> + #size-cells = <0>;
> +
>

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Manasi Navare

On Tue, Apr 10, 2018 at 11:03:02AM -0400, Harry Wentland wrote:
> Adding Anthony and Aric who've been working on Freesync with DC on other OSes 
> for a while.
> 
> On 2018-04-09 05:45 PM, Manasi Navare wrote:
> > Thanks for initiating the discussion. Find my comments below:
> > 
> > On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
> >> Adding dri-devel, which I should've included from the start.
> >>
> >> On 2018-04-09 03:56 PM, Harry Wentland wrote:
> >>> === What is adaptive sync and VRR? ===
> >>>
> >>> Adaptive sync has been part of the DisplayPort spec for a while now and 
> >>> allows graphics adapters to drive displays with varying frame timings. 
> >>> VRR (variable refresh rate) is essentially the same, but defined for HDMI.
> >>>
> >>>
> >>>
> >>> === Why allow variable frame timings? ===
> >>>
> >>> Variable render times don't align with fixed refresh rates, leading to
> >>> stuttering, tearing, and/or input lag.
> >>>
> >>> e.g. (rc = render completion, dr = display refresh)
> >>>
> >>> rc   B  CDE  F
> >>> drA   B   C   C   D   E   F
> >>>
> >>> ^ ^
> >>> frame missed 
> >>>repeated   display
> >>> twice refresh   
> >>>
> >>>
> >>>
> >>> === Other use cases of adaptive sync 
> >>>
> >>> Beside the variable render case, adaptive sync also allows adjustment of 
> >>> refresh rates without a mode change. One such use case would be 24 Hz 
> >>> video.
> >>>
> > 
> > One of the the advantages here when the render speed is slower than the 
> > display refresh rate, since we are stretching the vertical blanking interval
> > the display adapters will follow "draw fast and then go idle" approach. 
> > This gives power savings when render rate is lower than the display refresh 
> > rate.
> 
> Are you talking about a use case, such as an idle desktop, where the renders 
> are quite sporadic?
>

I was refering to a case where the render rate is lower say 24Hz but the 
display rate is fixed 60Hz, that means we are pretty much displaying the same 
frame
twice. But with Adaptive Sync, the display rate would be lowered to 24hz and 
the vertical blanking time will be stretched where instead of drawing the
same frame twice, the system is now idle in that extra blanking time thus 
giving some power savings.
 
> >  
> >>>
> >>>
> >>> === A DRM render API to support variable refresh rates ===
> >>>
> >>> In order to benefit from adaptive sync and VRR userland needs a way to 
> >>> let us know whether to vary frame timings or to target a different frame 
> >>> time. These can be provided as atomic properties on a CRTC:
> >>>  * bool   variable_refresh_compatible
> >>>  * inttarget_frame_duration_ns (nanosecond frame duration)
> >>>
> >>> This gives us the following cases:
> >>>
> >>> variable_refresh_compatible = 0, target_frame_duration_ns = 0
> >>>  * drive monitor at timing's normal refresh rate
> >>>
> >>> variable_refresh_compatible = 1, target_frame_duration_ns = 0
> >>>  * send new frame to monitor as soon as it's available, if within min/max 
> >>> of monitor's reported capabilities
> >>>
> >>> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
> >>>  * send new frame to monitor with the specified target_frame_duration_ns
> >>>
> >>> When a target_frame_duration_ns or variable_refresh_compatible cannot be 
> >>> supported the atomic check will reject the commit.
> >>>
> > 
> > What I would like is two sets of properties on a CRTC or preferably on a 
> > connector:
> > 
> > KMD properties that UMD can query:
> > * vrr_capable -  This will be an immutable property for exposing hardware's 
> > capability of supporting VRR. This will be set by the kernel after 
> > reading the EDID mode information and monitor range capabilities.
> > * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max refresh 
> > rates supported.
> > These properties are optional and will be created and attached to the 
> > DP/eDP connector when the connector
> > is getting intialized.
> > 
> 
> If we're talking about the properties from the EDID these might not 
> necessarily align with a currently selected mode, which might have a refresh 
> rate lower than the vrr_refresh_max, requiring us to cap it at that. In some 
> scenarios we also might do low framerate compensation [1] where we do magic 
> to allow the framerate to drop below the supported range.

Actually the way I have coded that currently is span through all the EDID modes 
and for each mode with the same resolution but different refresh rates 
supported, create a VRR field part of drm_mode_config structure that would have
refresh_max and min. So that way we store the max and min per mode as opposed 
to a per crtc/connector property.

> 
> I think if a vrr_refresh_max/min are exposed to UMD these should really be 
> only for informational purposes, in

[PATCH 3/3] ARM: dts: sun7i: Add support for the Ainol AW1 tablet

This adds support for the Ainol AW1, an A20-based 7" tablet from Ainol.

The following board-specific features are supported:
* LCD panel
* Backlight
* USB OTG
* Buttons
* Touchscreen (doesn't work without non-free firmware)
* Accelerometer
* Battery

The following are untested:
* Audio output
* Audio speakers
* USB via SPCI connector

The following are not supported:
* Wi-Fi
* Bluetooth
* NAND
* Audio via SPCI connector

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/Makefile|   1 +
 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts | 358 ++
 2 files changed, 359 insertions(+)
 create mode 100644 arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts

diff --git a/arch/arm/boot/dts/Makefile b/arch/arm/boot/dts/Makefile
index 9f7133b6fba0..03bfacebfdbd 100644
--- a/arch/arm/boot/dts/Makefile
+++ b/arch/arm/boot/dts/Makefile
@@ -929,6 +929,7 @@ dtb-$(CONFIG_MACH_SUN6I) += \
sun6i-a31s-sinovoip-bpi-m2.dtb \
sun6i-a31s-yones-toptech-bs1078-v2.dtb
 dtb-$(CONFIG_MACH_SUN7I) += \
+   sun7i-a20-ainol-aw1.dtb \
sun7i-a20-bananapi.dtb \
sun7i-a20-bananapi-m1-plus.dtb \
sun7i-a20-bananapro.dtb \
diff --git a/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts 
b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
new file mode 100644
index ..697586991aea
--- /dev/null
+++ b/arch/arm/boot/dts/sun7i-a20-ainol-aw1.dts
@@ -0,0 +1,358 @@
+/*
+ * Copyright 2018 Paul Kocialkowski 
+ *
+ * This file is dual-licensed: you can use it either under the terms
+ * of the GPL or the X11 license, at your option. Note that this dual
+ * licensing only applies to this file, and not this project as a
+ * whole.
+ *
+ *  a) This file is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU General Public License as
+ * published by the Free Software Foundation; either version 2 of the
+ * License, or (at your option) any later version.
+ *
+ * This file is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * Or, alternatively,
+ *
+ *  b) Permission is hereby granted, free of charge, to any person
+ * obtaining a copy of this software and associated documentation
+ * files (the "Software"), to deal in the Software without
+ * restriction, including without limitation the rights to use,
+ * copy, modify, merge, publish, distribute, sublicense, and/or
+ * sell copies of the Software, and to permit persons to whom the
+ * Software is furnished to do so, subject to the following
+ * conditions:
+ *
+ * The above copyright notice and this permission notice shall be
+ * included in all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
+ * EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
+ * OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
+ * NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT
+ * HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY,
+ * WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+ * FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR
+ * OTHER DEALINGS IN THE SOFTWARE.
+ */
+
+/dts-v1/;
+#include "sun7i-a20.dtsi"
+#include "sunxi-common-regulators.dtsi"
+
+#include 
+#include 
+#include 
+#include 
+
+/ {
+   model = "Ainol AW1";
+   compatible = "ainol,ainol-aw1", "allwinner,sun7i-a20";
+
+   aliases {
+   serial0 = 
+   };
+
+   chosen {
+   stdout-path = "serial0:115200n8";
+   };
+
+   backlight: backlight {
+   compatible = "pwm-backlight";
+   pinctrl-names = "default";
+   pinctrl-0 = <_enable_pin>;
+   pwms = < 0 5 PWM_POLARITY_INVERTED>;
+   brightness-levels = <0 10 20 30 40 50 60 70 80 90 100>;
+   default-brightness-level = <5>;
+   enable-gpios = < 7 7 GPIO_ACTIVE_HIGH>; /* PH7 */
+   };
+
+   panel: panel {
+   compatible = "innolux,at070tn92";
+   #address-cells = <1>;
+   #size-cells = <0>;
+   power-supply = <_power>;
+   backlight = <>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   panel_input: endpoint@0 {
+   reg = <0>;
+   remote-endpoint = <_out_panel>;
+   };
+   };
+   };
+
+   panel_power: panel_power {
+   compatible = "regulator-fixed";
+   pinctrl-names = "default";
+   pinctrl-0 =

[PATCH 2/3] ARM: dts: sun7i: Add RGB666 pins definition

This adds the pins definition for RGB666 LCD panels on the A20. It was
imported from the A33 definition, that concernes the same set of pins.

Signed-off-by: Paul Kocialkowski 
---
 arch/arm/boot/dts/sun7i-a20.dtsi | 8 
 1 file changed, 8 insertions(+)

diff --git a/arch/arm/boot/dts/sun7i-a20.dtsi b/arch/arm/boot/dts/sun7i-a20.dtsi
index e529e4ff2174..f46af8675cfa 100644
--- a/arch/arm/boot/dts/sun7i-a20.dtsi
+++ b/arch/arm/boot/dts/sun7i-a20.dtsi
@@ -781,6 +781,14 @@
function = "ir1";
};
 
+   lcd_rgb666_pins: lcd_rgb666@0 {
+   pins = "PD2", "PD3", "PD4", "PD5", "PD6", "PD7",
+  "PD10", "PD11", "PD12", "PD13", "PD14", 
"PD15",
+  "PD18", "PD19", "PD20", "PD21", "PD22", 
"PD23",
+  "PD24", "PD25", "PD26", "PD27";
+   function = "lcd0";
+   };
+
mmc0_pins_a: mmc0@0 {
pins = "PF0", "PF1", "PF2",
   "PF3", "PF4", "PF5";
-- 
2.16.3

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

[PATCH 1/3] drm/panel: Add RGB666 variant of Innolux AT070TN92

This adds timings for the RGB666 variant of the Innolux AT070TN92 panel,
as found on the Ainol AW1 tablet.

Signed-off-by: Paul Kocialkowski 
---
 drivers/gpu/drm/panel/panel-simple.c | 26 ++
 1 file changed, 26 insertions(+)

diff --git a/drivers/gpu/drm/panel/panel-simple.c 
b/drivers/gpu/drm/panel/panel-simple.c
index 5591984a392b..efeb2f2162bc 100644
--- a/drivers/gpu/drm/panel/panel-simple.c
+++ b/drivers/gpu/drm/panel/panel-simple.c
@@ -1063,6 +1063,29 @@ static const struct panel_desc innolux_at070tn92 = {
.bus_format = MEDIA_BUS_FMT_RGB888_1X24,
 };
 
+static const struct drm_display_mode innolux_at070tn92_rgb666_mode = {
+   .clock = 4,
+   .hdisplay = 800,
+   .hsync_start = 800 + 112,
+   .hsync_end = 800 + 112 + 1,
+   .htotal = 800 + 112 + 1 + 87,
+   .vdisplay = 480,
+   .vsync_start = 480 + 141,
+   .vsync_end = 480 + 141 + 1,
+   .vtotal = 480 + 141 + 1 + 38,
+   .vrefresh = 60,
+};
+
+static const struct panel_desc innolux_at070tn92_rgb666 = {
+   .modes = _at070tn92_rgb666_mode,
+   .num_modes = 1,
+   .size = {
+   .width = 154,
+   .height = 86,
+   },
+   .bus_format = MEDIA_BUS_FMT_RGB666_1X18,
+};
+
 static const struct display_timing innolux_g101ice_l01_timing = {
.pixelclock = { 6040, 7110, 7470 },
.hactive = { 1280, 1280, 1280 },
@@ -2105,6 +2128,9 @@ static const struct of_device_id platform_of_match[] = {
}, {
.compatible = "innolux,at070tn92",
.data = _at070tn92,
+   }, {
+   .compatible = "innolux,at070tn92-rgb666",
+   .data = _at070tn92_rgb666,
}, {
.compatible ="innolux,g101ice-l01",
.data = _g101ice_l01
-- 
2.16.3

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

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

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

--- Comment #13 from Marek Olšák  ---
Yes. 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

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

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

--- Comment #12 from Ilia Mirkin  ---
Probably meant this change:

https://cgit.freedesktop.org/mesa/mesa/commit/?id=f222cf3c6d6fc5d9dee3742d20aa77cfff9c39f8

-- 
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 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

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

--- Comment #11 from Marek Olšák  ---
If "glsl_correct_derivatives_after_discard=true" fixes it, it's not an
alpha-to-coverage issue. It's a problem with the use of discard in GLSL.

There is no difference in alpha-to-coverage behavior between DX and GL. Make
sure you have this fix:
https://cgit.freedesktop.org/mesa/mesa/commit/?id=f222cfww3c6d6fc5d9dee3742d20aa77cfff9c39f8

If there is a difference between DX and GL, the GL specification can be
corrected or a new GL extension can be added for the DX behavior.

-- 
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 1/3] drm/vc4: Remove the need for the GPU-subsystem DT node.

2018-04-10 Thread Eric Anholt

Stefan Wahren  writes:

> Hi Eric,
>
>> Eric Anholt  hat am 10. April 2018 um 01:00 geschrieben:
>> 
>> 
>> The GPU subsystem node was a workaround to have a central device to
>> bind V3D and display to.  Following the lead of 246774d17fc0
>> ("drm/etnaviv: remove the need for a gpu-subsystem DT node"), remove
>> the subsystem node usage and just create a platform device for the DRM
>> device to attach to if any of the subsystem devices are present.
>
> i didn't test it. Does the code change keep the backward compatibility with 
> older DT?

Yes.


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

Re: [PATCH v3 2/2] drivers: remove force dma flag from buses

2018-04-10 Thread Bjorn Helgaas

On Fri, Mar 30, 2018 at 01:24:45PM +0530, Nipun Gupta wrote:
> With each bus implementing its own DMA configuration callback,
> there is no need for bus to explicitly have force_dma in its
> global structure. This patch modifies of_dma_configure API to
> accept an input parameter which specifies if implicit DMA
> configuration is required even when it is not described by the
> firmware.
> 
> Signed-off-by: Nipun Gupta 

Acked-by: Bjorn Helgaas   # PCI parts

> ---
> Changes in v2:
>   - This is a new change suggested by Robin and Christoph
> and is added to the series.
> 
> Changes in v3:
>   - Rebase and changes corresponding to the changes in patch 1/2
> 
>  drivers/amba/bus.c| 1 -
>  drivers/base/platform.c   | 3 +--
>  drivers/bcma/main.c   | 2 +-
>  drivers/dma/qcom/hidma_mgmt.c | 2 +-
>  drivers/gpu/host1x/bus.c  | 5 ++---
>  drivers/of/device.c   | 6 --
>  drivers/of/of_reserved_mem.c  | 2 +-
>  drivers/pci/pci-driver.c  | 3 +--
>  include/linux/device.h| 4 
>  include/linux/of_device.h | 8 ++--
>  10 files changed, 17 insertions(+), 19 deletions(-)
> 
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 867dc2b..abe73c4 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -199,7 +199,6 @@ struct bus_type amba_bustype = {
>   .uevent = amba_uevent,
>   .dma_configure  = platform_dma_configure,
>   .pm = _pm,
> - .force_dma  = true,
>  };
>  
>  static int __init amba_init(void)
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index 72fdbf6..cfbc569 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1136,7 +1136,7 @@ int platform_dma_configure(struct device *dev)
>   int ret = 0;
>  
>   if (dev->of_node) {
> - ret = of_dma_configure(dev, dev->of_node);
> + ret = of_dma_configure(dev, dev->of_node, true);
>   } else if (has_acpi_companion(dev)) {
>   attr = acpi_get_dma_attr(to_acpi_device_node(dev->fwnode));
>   if (attr != DEV_DMA_NOT_SUPPORTED)
> @@ -1159,7 +1159,6 @@ struct bus_type platform_bus_type = {
>   .uevent = platform_uevent,
>   .dma_configure  = platform_dma_configure,
>   .pm = _dev_pm_ops,
> - .force_dma  = true,
>  };
>  EXPORT_SYMBOL_GPL(platform_bus_type);
>  
> diff --git a/drivers/bcma/main.c b/drivers/bcma/main.c
> index e6986c7..fc1f4ac 100644
> --- a/drivers/bcma/main.c
> +++ b/drivers/bcma/main.c
> @@ -207,7 +207,7 @@ static void bcma_of_fill_device(struct device *parent,
>  
>   core->irq = bcma_of_get_irq(parent, core, 0);
>  
> - of_dma_configure(>dev, node);
> + of_dma_configure(>dev, node, false);
>  }
>  
>  unsigned int bcma_core_irq(struct bcma_device *core, int num)
> diff --git a/drivers/dma/qcom/hidma_mgmt.c b/drivers/dma/qcom/hidma_mgmt.c
> index 000c7019..d64edeb 100644
> --- a/drivers/dma/qcom/hidma_mgmt.c
> +++ b/drivers/dma/qcom/hidma_mgmt.c
> @@ -398,7 +398,7 @@ static int __init hidma_mgmt_of_populate_channels(struct 
> device_node *np)
>   }
>   of_node_get(child);
>   new_pdev->dev.of_node = child;
> - of_dma_configure(_pdev->dev, child);
> + of_dma_configure(_pdev->dev, child, true);
>   /*
>* It is assumed that calling of_msi_configure is safe on
>* platforms with or without MSI support.
> diff --git a/drivers/gpu/host1x/bus.c b/drivers/gpu/host1x/bus.c
> index a9ec99d..b39c1e9 100644
> --- a/drivers/gpu/host1x/bus.c
> +++ b/drivers/gpu/host1x/bus.c
> @@ -317,7 +317,7 @@ static int host1x_device_match(struct device *dev, struct 
> device_driver *drv)
>  static int host1x_dma_configure(struct device *dev)
>  {
>   if (dev->of_node)
> - return of_dma_configure(dev, dev->of_node);
> + return of_dma_configure(dev, dev->of_node, true);
>   return 0;
>  }
>  
> @@ -335,7 +335,6 @@ struct bus_type host1x_bus_type = {
>   .match = host1x_device_match,
>   .dma_configure  = host1x_dma_configure,
>   .pm = _device_pm_ops,
> - .force_dma = true,
>  };
>  
>  static void __host1x_device_del(struct host1x_device *device)
> @@ -424,7 +423,7 @@ static int host1x_device_add(struct host1x *host1x,
>   device->dev.bus = _bus_type;
>   device->dev.parent = host1x->dev;
>  
> - of_dma_configure(>dev, host1x->dev->of_node);
> + of_dma_configure(>dev, host1x->dev->of_node, true);
>  
>   err = host1x_device_parse_dt(device, driver);
>   if (err < 0) {
> diff --git a/drivers/of/device.c b/drivers/of/device.c
> index 064c818..33d8551 100644
> --- a/drivers/of/device.c
> +++ b/drivers/of/device.c
> @@ -76,6 +76,8 @@ int of_device_add(struct platform_device *ofdev)
>   * of_dma_configure - Setup DMA configuration
>   * @dev: Device to apply DMA configuration
>   * @np:

Re: [PATCH v3 1/2] dma-mapping: move dma configuration to bus infrastructure

2018-04-10 Thread Bjorn Helgaas

On Fri, Mar 30, 2018 at 01:24:44PM +0530, Nipun Gupta wrote:
> It is bus specific aspect to map a given device on the bus and
> relevant firmware description of its DMA configuration.
> So, this change introduces 'dma_configure' as bus callback
> giving flexibility to busses for implementing its own dma
> configuration function.
> 
> The change eases the addition of new busses w.r.t. adding the dma
> configuration functionality.
> 
> This patch also updates the PCI, Platform, ACPI and host1x bus to
> use new introduced callbacks.

s/dma/DMA/ consistently above.

> Suggested-by: Christoph Hellwig 
> Signed-off-by: Nipun Gupta 
> Reviewed-by: Greg Kroah-Hartman 

Acked-by: Bjorn Helgaas   # PCI parts

I assume you'll merge this via some non-PCI tree.  Let me know if you
need anything else from me.

> ---
>  - The patches are based on the comments on:
>https://patchwork.kernel.org/patch/10259087/
> 
> Changes in v2:
>   - Do not have dma_deconfigure callback
>   - Have '/dma_common_configure/' API to provide a common DMA
> configuration which can be used by busses if it suits them.
>   - Platform and ACPI bus to use '/dma_common_configure/' in
> '/dma_configure/' callback.
>   - Updated commit message
>   - Updated pci_dma_configure API with changes suggested by Robin
> 
> Changes in v3
>   - Move dma_common_configure() within platform_dma_configure() and
> reuse platofrm_dma_configure() for AMBA bus too
>   - Declare 'attr' in pci_dma_configure() inside the else statement
> where it is used.
> 
>  drivers/amba/bus.c  |  4 
>  drivers/base/dma-mapping.c  | 31 ---
>  drivers/base/platform.c | 17 +
>  drivers/gpu/host1x/bus.c|  8 
>  drivers/pci/pci-driver.c| 32 
>  include/linux/device.h  |  4 
>  include/linux/platform_device.h |  2 ++
>  7 files changed, 71 insertions(+), 27 deletions(-)
> 
> diff --git a/drivers/amba/bus.c b/drivers/amba/bus.c
> index 594c228..867dc2b 100644
> --- a/drivers/amba/bus.c
> +++ b/drivers/amba/bus.c
> @@ -20,6 +20,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  
> @@ -188,12 +189,15 @@ static int amba_pm_runtime_resume(struct device *dev)
>  /*
>   * Primecells are part of the Advanced Microcontroller Bus Architecture,
>   * so we call the bus "amba".
> + * DMA configuration for platform and AMBA bus is same. So here we reuse
> + * platform's DMA config routine.
>   */
>  struct bus_type amba_bustype = {
>   .name   = "amba",
>   .dev_groups = amba_dev_groups,
>   .match  = amba_match,
>   .uevent = amba_uevent,
> + .dma_configure  = platform_dma_configure,
>   .pm = _pm,
>   .force_dma  = true,
>  };
> diff --git a/drivers/base/dma-mapping.c b/drivers/base/dma-mapping.c
> index 3b11835..fdc1502 100644
> --- a/drivers/base/dma-mapping.c
> +++ b/drivers/base/dma-mapping.c
> @@ -331,36 +331,13 @@ void dma_common_free_remap(void *cpu_addr, size_t size, 
> unsigned long vm_flags)
>  #endif
>  
>  /*
> - * Common configuration to enable DMA API use for a device
> + * enables DMA API use for a device
>   */
> -#include 
> -
>  int dma_configure(struct device *dev)
>  {
> - struct device *bridge = NULL, *dma_dev = dev;
> - enum dev_dma_attr attr;
> - int ret = 0;
> -
> - if (dev_is_pci(dev)) {
> - bridge = pci_get_host_bridge_device(to_pci_dev(dev));
> - dma_dev = bridge;
> - if (IS_ENABLED(CONFIG_OF) && dma_dev->parent &&
> - dma_dev->parent->of_node)
> - dma_dev = dma_dev->parent;
> - }
> -
> - if (dma_dev->of_node) {
> - ret = of_dma_configure(dev, dma_dev->of_node);
> - } else if (has_acpi_companion(dma_dev)) {
> - attr = acpi_get_dma_attr(to_acpi_device_node(dma_dev->fwnode));
> - if (attr != DEV_DMA_NOT_SUPPORTED)
> - ret = acpi_dma_configure(dev, attr);
> - }
> -
> - if (bridge)
> - pci_put_host_bridge_device(bridge);
> -
> - return ret;
> + if (dev->bus->dma_configure)
> + return dev->bus->dma_configure(dev);
> + return 0;
>  }
>  
>  void dma_deconfigure(struct device *dev)
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index f1bf7b3..72fdbf6 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -1130,6 +1130,22 @@ int platform_pm_restore(struct device *dev)
>  
>  #endif /* CONFIG_HIBERNATE_CALLBACKS */
>  
> +int platform_dma_configure(struct device *dev)
> +{
> + enum dev_dma_attr attr;
> + int ret = 0;
> +
> + if (dev->of_node) {
> + ret = of_dma_configure(dev, dev->of_node);
> + } else if (has_acpi_companion(dev)) {
> + attr =

[Bug 102553] Venus PRO R9 M265X amdgpu: Kernel OOPS si_dpm_set_power_state unable to handle kernel NULL pointer dereference

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

--- Comment #20 from mercuriete  ---
Status of this patches:

Alex already created a pull request to Dave drm maintainer, so probably this
doesnt take too much time to be merged in linux 4.17:

https://lists.freedesktop.org/archives/dri-devel/2018-April/172022.html

Sorry for the noise, this comment is only for keep track of the status.

Thanks for your amazing work Alex! :)

-- 
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 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

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

--- Comment #14 from har...@gmx.de ---
linux 4.16.1, R9 380X, Mesa 18.1.0-devel (git-d899826733), X11(1.19.6)

with:

amdgpu.dc=0: no flickering, HDMI audio works

amdgpu.dc=1: flickering, HDMI audio not working

-- 
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

RE: [RFC 0/3] drm: page-flip with damage

2018-04-10 Thread Deepak Singh Rawat

>Hi,
>
>Many thanks that you have picked it up.
>Unfortunately I didn't had time to work on it for a while.
>
>I am ok with what you have done, ihmo the review is going in good direction.
>I will try not to miss your update of it.
>From my side I can say that damage rects with frame-buffer coordinates are 
>perfectly fine for DisplayLink case.
>
>Btw I have noticed that there is also a patch from Rob Clark that is supplying 
>helper for legacy dirtyfb callback.
>Maybe we should unify the naming of the rects. Here we have "damage_clips", 
>Clark's patch has 'dirty_rects' notion.
>On other hand existing legacy dirtyfb callback in drm_framebuffer_funcs is 
>also using 'clip_rects' :).

The reason to name it damage is inspired by eglSwapBuffersWithDamageKHR
which user-space will be calling before submitting a page-flip. So it makes 
naming
consistent and in sync with user-space.

>
>Thanks
>
>Łukasz Spintzyk
>
>On 05/04/2018 01:49, Deepak Rawat wrote:
>Hi All,
>
>This is extension to Lukasz Spintzyk earlier draft of damage interface for drm.
>Bascially a new plane property is added called "DAMAGE_CLIPS" which is simply
>an array of drm_rect (exported to userspace as drm_mode_rect). The clips
>represents damage in framebuffer coordinate of attached fb to the plane.
>
>Helper iterator is added to traverse the damage rectangles and get the damage
>clips in framebuffer, plane or crtc coordinates as need by driver
>implementation. Finally a helper to reset damage in case need full update is
>required. Drivers interested in page-flip with damage should call this from
>atomic_check hook.
>
>With the RFC for atomic implementation of dirtyfb ioctl I was thinking
>should we need to consider dirty_fb flags, especially
>DRM_MODE_FB_DIRTY_ANNOTATE_COPY to be passed with atomic
>DAMAGE_CLIPS property blob? I didn't considered that untill now. If no driver
>uses that in my opinion for simplicity this can be ignored?
>
>About overlaping of damage rectangles is also not finalized. This really
>depends on driver specific implementation and can be left open-ended?
>
>My knowledge is limited to vmwgfx so would like to hear about other driver use
>cases and this can be modified in keeping other drivers need.
>
>Going forward driver implementation for vmwgfx and user-space implementation
>of kmscube/weston will be next step to test the changes.
>
>Thanks,
>Deepak
>
>Deepak Rawat (2):
>drm: Add helper iterator functions to iterate over plane damage.
>drm: Add helper to validate damage during modeset_check
>
>Lukasz Spintzyk (1):
>drm: Add DAMAGE_CLIPS property to plane
>
>drivers/gpu/drm/drm_atomic.c | 42 +
>drivers/gpu/drm/drm_atomic_helper.c | 173 
>drivers/gpu/drm/drm_mode_config.c | 5 ++
>drivers/gpu/drm/drm_plane.c | 12 +++
>include/drm/drm_atomic_helper.h | 41 +
>include/drm/drm_mode_config.h | 15 
>include/drm/drm_plane.h | 16 
>include/uapi/drm/drm_mode.h | 15 
>8 files changed, 319 insertions(+)
>
>-- 
>2.7.4
>
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH] drm/amdgpu: limit DMA size to PAGE_SIZE for scatter-gather buffers

2018-04-10 Thread Christian König


Am 10.04.2018 um 20:25 schrieb Sinan Kaya:

Code is expecing to observe the same number of buffers returned from
dma_map_sg() function compared to sg_alloc_table_from_pages(). This
doesn't hold true universally especially for systems with IOMMU.

IOMMU driver tries to combine buffers into a single DMA address as much
as it can. The right thing is to tell the DMA layer how much combining
IOMMU can do.


Good catch, but wrong place to set this.

Please move it into the device initialization functions.

Regards,
Christian.



Signed-off-by: Sinan Kaya 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index e4bb435..02465cd 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
@@ -787,6 +787,8 @@ static int amdgpu_ttm_tt_pin_userptr(struct ttm_tt *ttm)
enum dma_data_direction direction = write ?
DMA_BIDIRECTIONAL : DMA_TO_DEVICE;
  
+	dma_set_max_seg_size(adev->dev, PAGE_SIZE);

+
r = sg_alloc_table_from_pages(ttm->sg, ttm->pages, ttm->num_pages, 0,
  ttm->num_pages << PAGE_SHIFT,
  GFP_KERNEL);


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

Re: [PATCH] drm/amdkfd: Remove vla


On 04/09/2018 11:38 PM, Christian König wrote:

Am 09.04.2018 um 23:06 schrieb Laura Abbott:

There's an ongoing effort to remove VLAs[1] from the kernel to eventually
turn on -Wvla. The single VLA usage in the amdkfd driver is actually
constant across all current platforms.


Actually that isn't correct.

Could be that we haven't upstreamed KFD support for them, but Vega10 have a 
different interrupt ring entry size and so would cause the error message here.


Switch to a constant size array
instead.


I would say to just make make the array bigger.

Regards,
Christian.



What array size would accommodate future chips?



[1] https://lkml.org/lkml/2018/3/7/621

Signed-off-by: Laura Abbott 
---
  drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
  1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c 
b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
index 035c351f47c5..c9863858f343 100644
--- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
+++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
@@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
  {
  struct kfd_dev *dev = container_of(work, struct kfd_dev,
  interrupt_work);
+    uint32_t ih_ring_entry[4];
-    uint32_t ih_ring_entry[DIV_ROUND_UP(
-    dev->device_info->ih_ring_entry_size,
-    sizeof(uint32_t))];
+    if (dev->device_info->ih_ring_entry_size > (4 * sizeof(uint32_t))) {
+    dev_err(kfd_chardev(), "Ring entry too small\n");
+    return;
+    }
  while (dequeue_ih_ring_entry(dev, ih_ring_entry))
  dev->device_info->event_interrupt_class->interrupt_wq(dev,




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

Re: [PATCH] drm/amdkfd: Remove vla

2018-04-10 Thread Felix Kuehling

Thanks Christian for catching that. I'm working on a patch series to
upstream Vega10 support, about 95% done. It will add this ASIC info for
Vega10:

static const struct kfd_device_info vega10_device_info = {
.asic_family = CHIP_VEGA10,
.max_pasid_bits = 16,
.max_no_of_hqd  = 24,
.doorbell_size  = 8,
.ih_ring_entry_size = 8 * sizeof(uint32_t), /* !!! IH ring entry size 
is bigger on Vega10 !!! */
.event_interrupt_class = _interrupt_class_v9,
.num_of_watch_points = 4,
.mqd_size_aligned = MQD_SIZE_ALIGNED,
.supports_cwsr = true,
.needs_iommu_device = false,
.needs_pci_atomics = false,
};

If you change it to uint32_t ih_ring_entry[8] and update the check, it
should be reasonably future proof.

Regards,
  Felix


On 2018-04-10 02:38 AM, Christian König wrote:
> Am 09.04.2018 um 23:06 schrieb Laura Abbott:
>> There's an ongoing effort to remove VLAs[1] from the kernel to
>> eventually
>> turn on -Wvla. The single VLA usage in the amdkfd driver is actually
>> constant across all current platforms.
>
> Actually that isn't correct.
>
> Could be that we haven't upstreamed KFD support for them, but Vega10
> have a different interrupt ring entry size and so would cause the
> error message here.
>
>> Switch to a constant size array
>> instead.
>
> I would say to just make make the array bigger.
>
> Regards,
> Christian.
>
>>
>> [1] https://lkml.org/lkml/2018/3/7/621
>>
>> Signed-off-by: Laura Abbott 
>> ---
>>   drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c | 8 +---
>>   1 file changed, 5 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> index 035c351f47c5..c9863858f343 100644
>> --- a/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> +++ b/drivers/gpu/drm/amd/amdkfd/kfd_interrupt.c
>> @@ -139,10 +139,12 @@ static void interrupt_wq(struct work_struct *work)
>>   {
>>   struct kfd_dev *dev = container_of(work, struct kfd_dev,
>>   interrupt_work);
>> +    uint32_t ih_ring_entry[4];
>>   -    uint32_t ih_ring_entry[DIV_ROUND_UP(
>> -    dev->device_info->ih_ring_entry_size,
>> -    sizeof(uint32_t))];
>> +    if (dev->device_info->ih_ring_entry_size > (4 *
>> sizeof(uint32_t))) {
>> +    dev_err(kfd_chardev(), "Ring entry too small\n");
>> +    return;
>> +    }
>>     while (dequeue_ih_ring_entry(dev, ih_ring_entry))
>>   dev->device_info->event_interrupt_class->interrupt_wq(dev,
>
> ___
> amd-gfx mailing list
> amd-...@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/amd-gfx

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

[PATCH] drm/arm/malidp: Preserve LAYER_FORMAT contents when setting format

2018-04-10 Thread Ayan Kumar Halder

On some Mali-DP processors, the LAYER_FORMAT register contains fields
other than the format. These bits were unconditionally cleared when
setting the pixel format, whereas they should be preserved at their
reset values.

Reported-by: Brian Starkey 
Reported-by: Liviu Dudau 
Signed-off-by: Ayan Kumar halder 
---
 drivers/gpu/drm/arm/malidp_planes.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/arm/malidp_planes.c 
b/drivers/gpu/drm/arm/malidp_planes.c
index 7a44897..4af3c1f 100644
--- a/drivers/gpu/drm/arm/malidp_planes.c
+++ b/drivers/gpu/drm/arm/malidp_planes.c
@@ -23,6 +23,7 @@
 
 /* Layer specific register offsets */
 #define MALIDP_LAYER_FORMAT0x000
+#define   LAYER_FORMAT_MASK0x3f
 #define MALIDP_LAYER_CONTROL   0x004
 #define   LAYER_ENABLE (1 << 0)
 #define   LAYER_FLOWCFG_MASK   7
@@ -337,7 +338,9 @@ static void malidp_de_plane_update(struct drm_plane *plane,
dest_w = plane->state->crtc_w;
dest_h = plane->state->crtc_h;
 
-   malidp_hw_write(mp->hwdev, ms->format, mp->layer->base);
+   val = malidp_hw_read(mp->hwdev, mp->layer->base);
+   val = (val & ~LAYER_FORMAT_MASK) | ms->format;
+   malidp_hw_write(mp->hwdev, val, mp->layer->base);
 
for (i = 0; i < ms->n_planes; i++) {
/* calculate the offset for the layer's plane registers */
-- 
2.7.4

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

[Bug 101739] An issue with alpha-to-coverage handling is causing Arma 3 64-bit Linux port to render trees incorrectly

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

Gregor Münch  changed:

   What|Removed |Added

 CC||mar...@gmail.com

--- Comment #10 from Gregor Münch  ---
Some comments from a VP dev:
https://www.gamingonlinux.com/articles/the-linux-beta-of-arma-3-has-been-updated-to-180-compatible-with-windows-again-for-a-time.11349/comment_id=118838

Seems to be that it's not clear if the bug is on Mesa or VPs side. Maybe some
Mesa dev could comment.

-- 
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: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 07:44 AM, Chris Wilson wrote:
> Quoting Christian König (2018-04-10 07:45:04)
>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>> Properties that you mentioned above that the UMD can set before kernel can 
>>> enable VRR functionality
>>> *bool vrr_enable or vrr_compatible
>>> target_frame_duration_ns
>>
>> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad 
>> name/semantics.
>>
>> We should use an absolute timestamp where the frame should be presented, 
>> otherwise you could run into a bunch of trouble with IOCTL restarts or 
>> missed blanks.
> 
> Hear, hear. I was disappointed not to see this be the starting point of
> the conversation. Imo, the uABI should in terms of absolutes with the
> drivers mapping that onto HW and reporting back the discrepancies.

I think it's just that some of us that work on KMD display drivers have had our 
work primarily guided by different use cases, such as gaming, which has then be 
extended to provide a better experience for video as well. We might not be as 
intimately aware of some of the work that's been done on video APIs and the 
pains involved in it but are always happy to learn and work together toward the 
best solution.

Harry

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

Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 01:52 PM, Harry Wentland wrote:
> On 2018-04-10 12:37 PM, Nicolai Hähnle wrote:
>> On 10.04.2018 18:26, Cyr, Aric wrote:
>>> That presentation time doesn’t need to come to kernel as such and actually 
>>> is fine as-is completely decoupled from adaptive sync.  As long as the 
>>> video player provides the new target_frame_duration_ns on the flip, then 
>>> the driver/HW will target the correct refresh rate to match the source 
>>> content.  This simply means that more often than not the video presents 
>>> will  align very close to the monitor’s refresh rate, resulting in a smooth 
>>> video experience.  For example, if you have 24Hz content, and an adaptive 
>>> sync monitor with a range of 40-60Hz, once the target_frame_duration_ns is 
>>> provided, driver can configure the monitor to a fixed refresh rate of 48Hz 
>>> causing all video presents to be frame-doubled in hardware without further 
>>> application intervention.
>>
>> What about multi-monitor displays, where you want to play an animation that 
>> spans multiple monitors. You really want all monitors to flip at the same 
>> time.
>>
> 
> Syncing two monitors is what we currently do with our timing sync feature 
> where we drive two monitors from the same clock source if they use the same 
> timing. That, along with VSync, guarantees all monitors flip at the same 
> time. I'm not sure if it works with adaptive sync.
> 
> Are you suggesting to use adaptive sync to do an in-SW sync of multiple 
> displays?
> 
>> I understand where you're coming from, but the perspective of refusing a 
>> target presentation time is a rather selfish one of "we're the display, 
>> we're the most important, everybody else has to adjust to us" (e.g. to get 
>> perfect sync between video and audio). I admit I'm phrasing it in a bit of 
>> an extreme way, but perhaps this phrasing helps to see why that's just not a 
>> very good attitude to have.
>>
> 
> I really dislike arguing on an emotional basis and would rather not use words 
> such as "selfish" in this discussion. I believe all of us want to come to the 
> best possible solution based on technical merit.
> 
>> All devices (whether video or audio or whatever) should be able to receive a 
>> target presentation time.
>>
> 
> I'm not sure I understand the full extent of the problem as I'm not really 
> familiar with how this is currently done, but isn't the problem the same 
> without variable refresh rates (or targeted refresh rates)? A Video API would 
> still have to somehow synchronize audio and video to 60Hz on most monitors 
> today. What would change if we gave user mode the ability to suggest we flip 
> at video frame rates (24/48Hz)?
> 

Never mind. Just saw Michel's reply to an earlier message.

Harry

> Harry
> 
>> If the application can make your life a bit easier by providing the 
>> targetted refresh rate as additional *hint-only* parameter (like in your 24 
>> Hz --> 48 Hz doubling example), then maybe we should indeed consider that.
>>
>> Cheers,
>> Nicolai
>>
>>
>>>
>>>
>>> For video games we have a similar situation where a frame is rendered for a 
>>> certain world time and in the ideal case we would actually display the 
>>> frame at this world time.
>>>
>>> That seems like it would be a poorly written game that flips like that, 
>>> unless they are explicitly trying to throttle the framerate for some 
>>> reason.  When a game presents a completed frame, they’d like that to happen 
>>> as soon as possible.  This is why non-VSYNC modes of flipping exist and 
>>> many games leverage this.  Adaptive sync gives you the lower latency of 
>>> immediate flips without the tearing imposed by using non-VSYNC flipping.
>>>
>>>
>>> I mean we have the guys from Valve on this mailing list so I think we 
>>> should just get the feedback from them and see what they prefer.
>>>
>>> We have thousands of Steam games on other OSes that work great already, but 
>>> we’d certainly be interested in any additional feedback.  My guess is they 
>>> prefer to “do nothing” and let driver/HW manage it, otherwise you exempt 
>>> all existing games from supporting adaptive sync without a rewrite or 
>>> update.
>>>
>>>
>>> Regards,
>>> Christian.
>>>
>>>
>>>     -Aric
>>>
>>
> ___
> 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: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 12:37 PM, Nicolai Hähnle wrote:
> On 10.04.2018 18:26, Cyr, Aric wrote:
>> That presentation time doesn’t need to come to kernel as such and actually 
>> is fine as-is completely decoupled from adaptive sync.  As long as the video 
>> player provides the new target_frame_duration_ns on the flip, then the 
>> driver/HW will target the correct refresh rate to match the source content.  
>> This simply means that more often than not the video presents will  align 
>> very close to the monitor’s refresh rate, resulting in a smooth video 
>> experience.  For example, if you have 24Hz content, and an adaptive sync 
>> monitor with a range of 40-60Hz, once the target_frame_duration_ns is 
>> provided, driver can configure the monitor to a fixed refresh rate of 48Hz 
>> causing all video presents to be frame-doubled in hardware without further 
>> application intervention.
> 
> What about multi-monitor displays, where you want to play an animation that 
> spans multiple monitors. You really want all monitors to flip at the same 
> time.
> 

Syncing two monitors is what we currently do with our timing sync feature where 
we drive two monitors from the same clock source if they use the same timing. 
That, along with VSync, guarantees all monitors flip at the same time. I'm not 
sure if it works with adaptive sync.

Are you suggesting to use adaptive sync to do an in-SW sync of multiple 
displays?

> I understand where you're coming from, but the perspective of refusing a 
> target presentation time is a rather selfish one of "we're the display, we're 
> the most important, everybody else has to adjust to us" (e.g. to get perfect 
> sync between video and audio). I admit I'm phrasing it in a bit of an extreme 
> way, but perhaps this phrasing helps to see why that's just not a very good 
> attitude to have.
> 

I really dislike arguing on an emotional basis and would rather not use words 
such as "selfish" in this discussion. I believe all of us want to come to the 
best possible solution based on technical merit.

> All devices (whether video or audio or whatever) should be able to receive a 
> target presentation time.
> 

I'm not sure I understand the full extent of the problem as I'm not really 
familiar with how this is currently done, but isn't the problem the same 
without variable refresh rates (or targeted refresh rates)? A Video API would 
still have to somehow synchronize audio and video to 60Hz on most monitors 
today. What would change if we gave user mode the ability to suggest we flip at 
video frame rates (24/48Hz)?

Harry

> If the application can make your life a bit easier by providing the targetted 
> refresh rate as additional *hint-only* parameter (like in your 24 Hz --> 48 
> Hz doubling example), then maybe we should indeed consider that.
> 
> Cheers,
> Nicolai
> 
> 
>>
>>
>> For video games we have a similar situation where a frame is rendered for a 
>> certain world time and in the ideal case we would actually display the frame 
>> at this world time.
>>
>> That seems like it would be a poorly written game that flips like that, 
>> unless they are explicitly trying to throttle the framerate for some reason. 
>>  When a game presents a completed frame, they’d like that to happen as soon 
>> as possible.  This is why non-VSYNC modes of flipping exist and many games 
>> leverage this.  Adaptive sync gives you the lower latency of immediate flips 
>> without the tearing imposed by using non-VSYNC flipping.
>>
>>
>> I mean we have the guys from Valve on this mailing list so I think we should 
>> just get the feedback from them and see what they prefer.
>>
>> We have thousands of Steam games on other OSes that work great already, but 
>> we’d certainly be interested in any additional feedback.  My guess is they 
>> prefer to “do nothing” and let driver/HW manage it, otherwise you exempt all 
>> existing games from supporting adaptive sync without a rewrite or update.
>>
>>
>> Regards,
>> Christian.
>>
>>
>>     -Aric
>>
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Nicolai Hähnle


On 10.04.2018 19:25, Cyr, Aric wrote:

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, April 10, 2018 13:16

On 2018-04-10 07:13 PM, Cyr, Aric wrote:

-Original Message-
From: Michel Dänzer [mailto:mic...@daenzer.net]
Sent: Tuesday, April 10, 2018 13:06
On 2018-04-10 06:26 PM, Cyr, Aric wrote:

From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43


For video games we have a similar situation where a frame is rendered
for a certain world time and in the ideal case we would actually
display the frame at this world time.


That seems like it would be a poorly written game that flips like
that, unless they are explicitly trying to throttle the framerate for
some reason.  When a game presents a completed frame, they’d like
that to happen as soon as possible.


What you're describing is what most games have been doing traditionally.
Croteam's research shows that this results in micro-stuttering, because
frames may be presented too early. To avoid that, they want to
explicitly time each presentation as described by Christian.


Yes, I agree completely.  However that's only truly relevant for fixed
refreshed rate displays.


No, it also affects variable refresh; possibly even more in some cases,
because the presentation time is less predictable.


Yes, and that's why you don't want to do it when you have variable refresh.  
The hardware in the monitor and GPU will do it for you, so why bother?


I think Michel's point is that the monitor and GPU hardware *cannot* 
really do this, because there's synchronization with audio to take into 
account, which the GPU or monitor don't know about.


Also, as I wrote separately, there's the case of synchronizing multiple 
monitors.




The input to their algorithms will be noisy causing worst estimations.  If you 
just present as fast as you can, it'll just work (within reason).
The majority of gamers want maximum FPS for their games, and there's quite 
frequently outrage at a particular game when they are limited to something 
lower that what their monitor could otherwise support (i.e. I don't want my 
game limited to 30Hz if I have a shiny 144Hz gaming display I paid good money 
for).   Of course, there's always exceptions... but in our experience those are 
few and far between.


I agree that games most likely shouldn't try to be smart. I'm curious 
about the Croteam findings, but even if they did a really clever thing 
that works better than just telling the display driver "display ASAP 
please", chances are that *most* developers won't do that. And they'll 
most likely get it wrong, so our guidance should really be "games should 
ask for ASAP presentation, and nothing else".


However, there *are* legitimate use cases for requesting a specific 
presentation time, and there *is* precedent of APIs that expose such 
features.


Are there any real problems with exposing an absolute target present time?

Cheers,
Nicolai

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

Re: [RfC PATCH] Add udmabuf misc device

2018-04-10 Thread Dongwon Kim

On Tue, Apr 10, 2018 at 09:37:53AM +0300, Oleksandr Andrushchenko wrote:
> On 04/06/2018 09:57 PM, Dongwon Kim wrote:
> >On Fri, Apr 06, 2018 at 03:36:03PM +0300, Oleksandr Andrushchenko wrote:
> >>On 04/06/2018 02:57 PM, Gerd Hoffmann wrote:
> >>>   Hi,
> >>>
> >I fail to see any common ground for xen-zcopy and udmabuf ...
> Does the above mean you can assume that xen-zcopy and udmabuf
> can co-exist as two different solutions?
> >>>Well, udmabuf route isn't fully clear yet, but yes.
> >>>
> >>>See also gvt (intel vgpu), where the hypervisor interface is abstracted
> >>>away into a separate kernel modules even though most of the actual vgpu
> >>>emulation code is common.
> >>Thank you for your input, I'm just trying to figure out
> >>which of the three z-copy solutions intersect and how much
> And what about hyper-dmabuf?
> >xen z-copy solution is pretty similar fundamentally to hyper_dmabuf
> >in terms of these core sharing feature:
> >
> >1. the sharing process - import prime/dmabuf from the producer -> extract
> >underlying pages and get those shared -> return references for shared pages

Another thing is danvet was kind of against to the idea of importing existing
dmabuf/prime buffer and forward it to the other domain due to synchronization
issues. He proposed to make hyper_dmabuf only work as an exporter so that it
can have a full control over the buffer. I think we need to talk about this
further as well.

danvet, can you comment on this topic?

> >
> >2. the page sharing mechanism - it uses Xen-grant-table.
> >
> >And to give you a quick summary of differences as far as I understand
> >between two implementations (please correct me if I am wrong, Oleksandr.)
> >
> >1. xen-zcopy is DRM specific - can import only DRM prime buffer
> >while hyper_dmabuf can export any dmabuf regardless of originator
> Well, this is true. And at the same time this is just a matter
> of extending the API: xen-zcopy is a helper driver designed for
> xen-front/back use-case, so this is why it only has DRM PRIME API
> >
> >2. xen-zcopy doesn't seem to have dma-buf synchronization between two VMs
> >while (as danvet called it as remote dmabuf api sharing) hyper_dmabuf sends
> >out synchronization message to the exporting VM for synchronization.
> This is true. Again, this is because of the use-cases it covers.
> But having synchronization for a generic solution seems to be a good idea.

Yeah, understood xen-zcopy works ok with your use case. But I am just curious
if it is ok not to have any inter-domain synchronization in this sharing model.
The buffer being shared is technically dma-buf and originator needs to be able
to keep track of it.

> >
> >3. 1-level references - when using grant-table for sharing pages, there will
> >be same # of refs (each 8 byte)
> To be precise, grant ref is 4 bytes
You are right. Thanks for correction.;)

> >as # of shared pages, which is passed to
> >the userspace to be shared with importing VM in case of xen-zcopy.
> The reason for that is that xen-zcopy is a helper driver, e.g.
> the grant references come from the display backend [1], which implements
> Xen display protocol [2]. So, effectively the backend extracts references
> from frontend's requests and passes those to xen-zcopy as an array
> of refs.
> >  Compared
> >to this, hyper_dmabuf does multiple level addressing to generate only one
> >reference id that represents all shared pages.
> In the protocol [2] only one reference to the gref directory is passed
> between VMs
> (and the gref directory is a single-linked list of shared pages containing
> all
> of the grefs of the buffer).

ok, good to know. I will look into its implementation in more details but is
this gref directory (chained grefs) something that can be used for any general
memory sharing use case or is it jsut for xen-display (in current code base)?

> 
> >
> >4. inter VM messaging (hype_dmabuf only) - hyper_dmabuf has inter-vm msg
> >communication defined for dmabuf synchronization and private data (meta
> >info that Matt Roper mentioned) exchange.
> This is true, xen-zcopy has no means for inter VM sync and meta-data,
> simply because it doesn't have any code for inter VM exchange in it,
> e.g. the inter VM protocol is handled by the backend [1].
> >
> >5. driver-to-driver notification (hyper_dmabuf only) - importing VM gets
> >notified when newdmabuf is exported from other VM - uevent can be optionally
> >generated when this happens.
> >
> >6. structure - hyper_dmabuf is targetting to provide a generic solution for
> >inter-domain dmabuf sharing for most hypervisors, which is why it has two
> >layers as mattrope mentioned, front-end that contains standard API and 
> >backend
> >that is specific to hypervisor.
> Again, xen-zcopy is decoupled from inter VM communication
> >>>No idea, didn't look at it in detail.
> >>>
> >>>Looks pretty complex from a distant view.  Maybe because it tries to
> >>>build a communication framework using dma-bufs instead of a

RE: RFC for a render API to support adaptive sync and VRR

> -Original Message-
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Tuesday, April 10, 2018 13:16
> 
> On 2018-04-10 07:13 PM, Cyr, Aric wrote:
> >> -Original Message-
> >> From: Michel Dänzer [mailto:mic...@daenzer.net]
> >> Sent: Tuesday, April 10, 2018 13:06
> >> On 2018-04-10 06:26 PM, Cyr, Aric wrote:
> >>> From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43
> >>>
>  For video games we have a similar situation where a frame is rendered
>  for a certain world time and in the ideal case we would actually
>  display the frame at this world time.
> >>>
> >>> That seems like it would be a poorly written game that flips like
> >>> that, unless they are explicitly trying to throttle the framerate for
> >>> some reason.  When a game presents a completed frame, they’d like
> >>> that to happen as soon as possible.
> >>
> >> What you're describing is what most games have been doing traditionally.
> >> Croteam's research shows that this results in micro-stuttering, because
> >> frames may be presented too early. To avoid that, they want to
> >> explicitly time each presentation as described by Christian.
> >
> > Yes, I agree completely.  However that's only truly relevant for fixed
> > refreshed rate displays.
> 
> No, it also affects variable refresh; possibly even more in some cases,
> because the presentation time is less predictable.

Yes, and that's why you don't want to do it when you have variable refresh.  
The hardware in the monitor and GPU will do it for you, so why bother?
The input to their algorithms will be noisy causing worst estimations.  If you 
just present as fast as you can, it'll just work (within reason).
The majority of gamers want maximum FPS for their games, and there's quite 
frequently outrage at a particular game when they are limited to something 
lower that what their monitor could otherwise support (i.e. I don't want my 
game limited to 30Hz if I have a shiny 144Hz gaming display I paid good money 
for).   Of course, there's always exceptions... but in our experience those are 
few and far between.

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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

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

--- Comment #22 from i...@yahoo.com ---
(In reply to MirceaKitsune from comment #21)
> (In reply to iive from comment #20)
> 
> That's some amazing feedback, thank you very much! I'll definitely try those
> out, but I have a few questions about a few of these points:
> 
> 1. My OS (openSUSE Tumbleweed) doesn't have an xorg.conf file. I instead
> have an /etc/X11/xorg.conf.d directory with the following files in it:
> 
> 00-keyboard.conf
> 00-keyboard.conf.backup
> 10-amdgpu.conf
It goes in the Section "Device" of the video driver.
You can see all options with `man amdgpu` or
`man radeon`, etc.

> 5. So before running the program from a console, I do "export GALLIUM_HUD=1"
> or "GALLIUM_HUD=1;./my_program"? I don't suspect filled RAM as the game's
> process doesn't seem to leak memory... I do however suspect filled VRAM.
Do `GALLIUM_HUD=help glxgears` it would print all available graphs and the
syntax.

Here is what I used last time:
export GALLIUM_HUD=\
".dfps+cpu+GPU-load+temperature,.dGTT-usage+VRAM-usage,num-compilations+num-shaders-created;"\
"primitives-generated+draw-calls,samples-passed+ps-invocations+vs-invocations,buffer-wait-time;"\
"CS-thread-busy+gallium-thread-busy,dma-calls+cp-dma-calls,num-bytes-moved;"\
"num-vs-flushes+num-ps-flushes+num-cs-flushes+num-CB-cache-flushes+num-DB-cache-flushes"

> 6. What is the Kernel parameter for CMA please? It doesn't seem to be an
> amdgpu setting so I assume it's separate.
"cma=0 iommu=off"
You can look in linux-source/Documentation/admin-guide/kernel-parameters.txt

-- 
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: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Michel Dänzer

On 2018-04-10 07:13 PM, Cyr, Aric wrote:
>> -Original Message-
>> From: Michel Dänzer [mailto:mic...@daenzer.net]
>> Sent: Tuesday, April 10, 2018 13:06
>> On 2018-04-10 06:26 PM, Cyr, Aric wrote:
>>> From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43
>>>
 For video games we have a similar situation where a frame is rendered
 for a certain world time and in the ideal case we would actually
 display the frame at this world time.
>>>
>>> That seems like it would be a poorly written game that flips like
>>> that, unless they are explicitly trying to throttle the framerate for
>>> some reason.  When a game presents a completed frame, they’d like
>>> that to happen as soon as possible.
>>
>> What you're describing is what most games have been doing traditionally.
>> Croteam's research shows that this results in micro-stuttering, because
>> frames may be presented too early. To avoid that, they want to
>> explicitly time each presentation as described by Christian.
> 
> Yes, I agree completely.  However that's only truly relevant for fixed
> refreshed rate displays.

No, it also affects variable refresh; possibly even more in some cases,
because the presentation time is less predictable.


I have to leave for today, I'll look up the Croteam video on Youtube
explaining this tomorrow if nobody beats me to it.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

RE: RFC for a render API to support adaptive sync and VRR

> -Original Message-
> From: Michel Dänzer [mailto:mic...@daenzer.net]
> Sent: Tuesday, April 10, 2018 13:06
> On 2018-04-10 06:26 PM, Cyr, Aric wrote:
> > From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43
> >
> >> For video games we have a similar situation where a frame is rendered
> >> for a certain world time and in the ideal case we would actually
> >> display the frame at this world time.
> >
> > That seems like it would be a poorly written game that flips like
> > that, unless they are explicitly trying to throttle the framerate for
> > some reason.  When a game presents a completed frame, they’d like
> > that to happen as soon as possible.
> 
> What you're describing is what most games have been doing traditionally.
> Croteam's research shows that this results in micro-stuttering, because
> frames may be presented too early. To avoid that, they want to
> explicitly time each presentation as described by Christian.

Yes, I agree completely.  However that's only truly relevant for fixed 
refreshed rate displays.
This is the primary reason for having Adaptive Sync.  
There is no perfect way to solve this without Adaptive Sync, but yes they can 
come up with better algorithms to improve fixed refresh rate displays.

> 
> Maybe we should try getting the Croteam guys researching this involved
> directly here.

I'd be interested in any research they could share, for sure.  
We also have years of experience and research here, but not distilled into any 
readily available format.

> 
> 
> --
> Earthling Michel Dänzer   |   http://www.amd.com
> Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Michel Dänzer

On 2018-04-10 05:35 PM, Cyr, Aric wrote:
>> On 2018-04-10 03:37 AM, Michel Dänzer wrote:
>>> On 2018-04-10 08:45 AM, Christian König wrote:
 Am 09.04.2018 um 23:45 schrieb Manasi Navare:
> Thanks for initiating the discussion. Find my comments
> below: On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry
> Wentland wrote:
>> On 2018-04-09 03:56 PM, Harry Wentland wrote:
>>> 
>>> === A DRM render API to support variable refresh rates
>>> ===
>>> 
>>> In order to benefit from adaptive sync and VRR userland
>>> needs a way to let us know whether to vary frame timings
>>> or to target a different frame time. These can be
>>> provided as atomic properties on a CRTC: * bool
>>> variable_refresh_compatible * int
>>> target_frame_duration_ns (nanosecond frame duration)
>>> 
>>> This gives us the following cases:
>>> 
>>> variable_refresh_compatible = 0, target_frame_duration_ns
>>> = 0 * drive monitor at timing's normal refresh rate
>>> 
>>> variable_refresh_compatible = 1, target_frame_duration_ns
>>> = 0 * send new frame to monitor as soon as it's
>>> available, if within min/max of monitor's reported
>>> capabilities
>>> 
>>> variable_refresh_compatible = 0/1,
>>> target_frame_duration_ns = > 0 * send new frame to
>>> monitor with the specified target_frame_duration_ns
>>> 
>>> When a target_frame_duration_ns or
>>> variable_refresh_compatible cannot be supported the
>>> atomic check will reject the commit.
>>> 
> What I would like is two sets of properties on a CRTC or
> preferably on a connector:
> 
> KMD properties that UMD can query: * vrr_capable -  This will
> be an immutable property for exposing hardware's capability
> of supporting VRR. This will be set by the kernel after 
> reading the EDID mode information and monitor range
> capabilities. * vrr_vrefresh_max, vrr_vrefresh_min - To
> expose the min and max refresh rates supported. These
> properties are optional and will be created and attached to
> the DP/eDP connector when the connector is getting
> intialized.
 
 Mhm, aren't those properties actually per mode and not per
 CRTC/connector?
 
> Properties that you mentioned above that the UMD can set
> before kernel can enable VRR functionality *bool vrr_enable
> or vrr_compatible target_frame_duration_ns
 
 Yeah, that certainly makes sense. But target_frame_duration_ns
 is a bad name/semantics.
 
 We should use an absolute timestamp where the frame should be
 presented, otherwise you could run into a bunch of trouble with
 IOCTL restarts or missed blanks.
>>> 
>>> Also, a fixed target frame duration isn't suitable even for
>>> video playback, due to drift between the video and audio clocks.
> 
> Why?  Even if they drift, you know you want to show your 24Hz video
> frame for 41.ms and adaptive sync can ensure that with reasonable
> accuracy.

Due to the drift, the video player has to occasionally either skip a
frame or present it twice to prevent audio and video going out of sync,
resulting in visual artifacts.

With time-based presentation and variable refresh rate, audio and video
can stay in sync without occasional visual artifacts.

It would be a pity to create a "variable refresh rate API" which doesn't
allow harnessing this strength of variable refresh rate.


-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Michel Dänzer

On 2018-04-10 06:26 PM, Cyr, Aric wrote:
> From: Koenig, Christian Sent: Tuesday, April 10, 2018 11:43
> 
>> For video games we have a similar situation where a frame is rendered
>> for a certain world time and in the ideal case we would actually
>> display the frame at this world time.
> 
> That seems like it would be a poorly written game that flips like
> that, unless they are explicitly trying to throttle the framerate for
> some reason.  When a game presents a completed frame, they’d like
> that to happen as soon as possible.

What you're describing is what most games have been doing traditionally.
Croteam's research shows that this results in micro-stuttering, because
frames may be presented too early. To avoid that, they want to
explicitly time each presentation as described by Christian.

Maybe we should try getting the Croteam guys researching this involved
directly here.

-- 
Earthling Michel Dänzer   |   http://www.amd.com
Libre software enthusiast | Mesa and X developer
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Nicolai Hähnle


On 10.04.2018 18:26, Cyr, Aric wrote:
That presentation time doesn’t need to come to kernel as such and 
actually is fine as-is completely decoupled from adaptive sync.  As long 
as the video player provides the new target_frame_duration_ns on the 
flip, then the driver/HW will target the correct refresh rate to match 
the source content.  This simply means that more often than not the 
video presents will  align very close to the monitor’s refresh rate, 
resulting in a smooth video experience.  For example, if you have 24Hz 
content, and an adaptive sync monitor with a range of 40-60Hz, once the 
target_frame_duration_ns is provided, driver can configure the monitor 
to a fixed refresh rate of 48Hz causing all video presents to be 
frame-doubled in hardware without further application intervention.


What about multi-monitor displays, where you want to play an animation 
that spans multiple monitors. You really want all monitors to flip at 
the same time.


I understand where you're coming from, but the perspective of refusing a 
target presentation time is a rather selfish one of "we're the display, 
we're the most important, everybody else has to adjust to us" (e.g. to 
get perfect sync between video and audio). I admit I'm phrasing it in a 
bit of an extreme way, but perhaps this phrasing helps to see why that's 
just not a very good attitude to have.


All devices (whether video or audio or whatever) should be able to 
receive a target presentation time.


If the application can make your life a bit easier by providing the 
targetted refresh rate as additional *hint-only* parameter (like in your 
24 Hz --> 48 Hz doubling example), then maybe we should indeed consider 
that.


Cheers,
Nicolai





For video games we have a similar situation where a frame is rendered 
for a certain world time and in the ideal case we would actually display 
the frame at this world time.


That seems like it would be a poorly written game that flips like that, 
unless they are explicitly trying to throttle the framerate for some 
reason.  When a game presents a completed frame, they’d like that to 
happen as soon as possible.  This is why non-VSYNC modes of flipping 
exist and many games leverage this.  Adaptive sync gives you the lower 
latency of immediate flips without the tearing imposed by using 
non-VSYNC flipping.



I mean we have the guys from Valve on this mailing list so I think we 
should just get the feedback from them and see what they prefer.


We have thousands of Steam games on other OSes that work great already, 
but we’d certainly be interested in any additional feedback.  My guess 
is they prefer to “do nothing” and let driver/HW manage it, otherwise 
you exempt all existing games from supporting adaptive sync without a 
rewrite or update.



Regards,
Christian.


-Aric



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

RE: RFC for a render API to support adaptive sync and VRR

From: Koenig, Christian
Sent: Tuesday, April 10, 2018 11:43

Am 10.04.2018 um 17:35 schrieb Cyr, Aric:

-Original Message-

From: Wentland, Harry

Sent: Tuesday, April 10, 2018 11:08

To: Michel Dänzer ; Koenig, 
Christian ; Manasi 
Navare

Cc: Haehnle, Nicolai ; 
Daniel Vetter ; Daenzer, 
Michel

; dri-devel 
; 
amd-gfx mailing list 
;

Deucher, Alexander 
; Cyr, Aric 
; Koo, Anthony 

Subject: Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 03:37 AM, Michel Dänzer wrote:

On 2018-04-10 08:45 AM, Christian König wrote:

Am 09.04.2018 um 23:45 schrieb Manasi Navare:

Thanks for initiating the discussion. Find my comments below:

On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:

On 2018-04-09 03:56 PM, Harry Wentland wrote:

=== A DRM render API to support variable refresh rates ===

In order to benefit from adaptive sync and VRR userland needs a way

to let us know whether to vary frame timings or to target a

different frame time. These can be provided as atomic properties on

a CRTC:

  * boolvariable_refresh_compatible

  * inttarget_frame_duration_ns (nanosecond frame duration)

This gives us the following cases:

variable_refresh_compatible = 0, target_frame_duration_ns = 0

  * drive monitor at timing's normal refresh rate

variable_refresh_compatible = 1, target_frame_duration_ns = 0

  * send new frame to monitor as soon as it's available, if within

min/max of monitor's reported capabilities

variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0

  * send new frame to monitor with the specified

target_frame_duration_ns

When a target_frame_duration_ns or variable_refresh_compatible

cannot be supported the atomic check will reject the commit.

What I would like is two sets of properties on a CRTC or preferably on

a connector:

KMD properties that UMD can query:

* vrr_capable -  This will be an immutable property for exposing

hardware's capability of supporting VRR. This will be set by the

kernel after

reading the EDID mode information and monitor range capabilities.

* vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max

refresh rates supported.

These properties are optional and will be created and attached to the

DP/eDP connector when the connector

is getting intialized.

Mhm, aren't those properties actually per mode and not per CRTC/connector?

Properties that you mentioned above that the UMD can set before kernel

can enable VRR functionality

*bool vrr_enable or vrr_compatible

target_frame_duration_ns

Yeah, that certainly makes sense. But target_frame_duration_ns is a bad

name/semantics.

We should use an absolute timestamp where the frame should be presented,

otherwise you could run into a bunch of trouble with IOCTL restarts or

missed blanks.

Also, a fixed target frame duration isn't suitable even for video

playback, due to drift between the video and audio clocks.

Why?  Even if they drift, you know you want to show your 24Hz video frame for 
41.ms and adaptive sync can ensure that with reasonable accuracy.

All we're doing is eliminating the need for frame rate converters from the 
application and offloading that to hardware.

Time-based presentation seems to be the right approach for preventing

micro-stutter in games as well, Croteam developers have been researching

this.

I'm not sure if the driver can ever give a guarantee of the exact time a flip 
occurs. What we have control over with our HW is frame

duration.

Are Croteam devs trying to predict render times? I'm not sure how that would 
work. We've had bad experience in the past with

games that try to do framepacing as that's usually not accurate and tends to 
lead to more problems than benefits.

For gaming, it doesn't make sense nor is it feasible to know how exactly how 
long a render will take with microsecond precision, very coarse guesses at 
best.  The point of adaptive sync is that it works *transparently* for the 
majority of cases, within the capability of the HW and driver.  We don't want 
to have every game re-write their engine to support this, but we do want the 
majority to "just work".

The only exception is the video case where an application may want to request a 
fixed frame duration aligned to the video content.  This requires an explicit

[Bug 105333] [gallium-nine] missing geometry after commit ac: replace ac_build_kill with ac_build_kill_if_false

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

--- Comment #4 from had...@gmx.de ---
Thanks for the infos!
I will make a apitrace and upload it, but it will take me some days.
I will then also open a report on the github page.

-- 
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: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Christian König

Am 10.04.2018 um 17:35 schrieb Cyr, Aric:

-Original Message-
From: Wentland, Harry
Sent: Tuesday, April 10, 2018 11:08
To: Michel Dänzer ; Koenig, Christian 
; Manasi Navare

Cc: Haehnle, Nicolai ; Daniel Vetter 
; Daenzer, Michel
; dri-devel ; amd-gfx 
mailing list ;
Deucher, Alexander ; Cyr, Aric ; Koo, 
Anthony 
Subject: Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 03:37 AM, Michel Dänzer wrote:

On 2018-04-10 08:45 AM, Christian König wrote:

Am 09.04.2018 um 23:45 schrieb Manasi Navare:

Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:

On 2018-04-09 03:56 PM, Harry Wentland wrote:

=== A DRM render API to support variable refresh rates ===

In order to benefit from adaptive sync and VRR userland needs a way
to let us know whether to vary frame timings or to target a
different frame time. These can be provided as atomic properties on
a CRTC:
   * bool    variable_refresh_compatible
   * int    target_frame_duration_ns (nanosecond frame duration)

This gives us the following cases:

variable_refresh_compatible = 0, target_frame_duration_ns = 0
   * drive monitor at timing's normal refresh rate

variable_refresh_compatible = 1, target_frame_duration_ns = 0
   * send new frame to monitor as soon as it's available, if within
min/max of monitor's reported capabilities

variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
   * send new frame to monitor with the specified
target_frame_duration_ns

When a target_frame_duration_ns or variable_refresh_compatible
cannot be supported the atomic check will reject the commit.

What I would like is two sets of properties on a CRTC or preferably on
a connector:

KMD properties that UMD can query:
* vrr_capable -  This will be an immutable property for exposing
hardware's capability of supporting VRR. This will be set by the
kernel after
reading the EDID mode information and monitor range capabilities.
* vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max
refresh rates supported.
These properties are optional and will be created and attached to the
DP/eDP connector when the connector
is getting intialized.

Mhm, aren't those properties actually per mode and not per CRTC/connector?

Properties that you mentioned above that the UMD can set before kernel
can enable VRR functionality
*bool vrr_enable or vrr_compatible
target_frame_duration_ns

Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
name/semantics.

We should use an absolute timestamp where the frame should be presented,
otherwise you could run into a bunch of trouble with IOCTL restarts or
missed blanks.

Also, a fixed target frame duration isn't suitable even for video
playback, due to drift between the video and audio clocks.

Why?  Even if they drift, you know you want to show your 24Hz video frame for 
41.ms and adaptive sync can ensure that with reasonable accuracy.
All we're doing is eliminating the need for frame rate converters from the 
application and offloading that to hardware.

Time-based presentation seems to be the right approach for preventing
micro-stutter in games as well, Croteam developers have been researching
this.

I'm not sure if the driver can ever give a guarantee of the exact time a flip 
occurs. What we have control over with our HW is frame
duration.

Are Croteam devs trying to predict render times? I'm not sure how that would 
work. We've had bad experience in the past with
games that try to do framepacing as that's usually not accurate and tends to 
lead to more problems than benefits.

For gaming, it doesn't make sense nor is it feasible to know how exactly how long a 
render will take with microsecond precision, very coarse guesses at best.  The point of 
adaptive sync is that it works *transparently* for the majority of cases, within the 
capability of the HW and driver.  We don't want to have every game re-write their engine 
to support this, but we do want the majority to "just work".

The only exception is the video case where an application may want to request a 
fixed frame duration aligned to the video content.  This requires an explicit 
interface for the video app, and our proposal is to keep it simple:  app knows 
how long a frame should be presented for, and we try to honour that.

Well I strongly disagree on that.

See VDPAU for example: 
https://http.download.nvidia.com/XFree86/vdpau/doxygen/html/group___vdp_presentation_queue.html#ga5bd61ca8ef5d1bc54ca6921aa57f835a

[in]

	earliest_presentation_time 	The timestamp associated with the 
surface. The presentation queue will not display the surface until the 
presentation queue's

RE: RFC for a render API to support adaptive sync and VRR

> -Original Message-
> From: Wentland, Harry
> Sent: Tuesday, April 10, 2018 11:08
> To: Michel Dänzer ; Koenig, Christian 
> ; Manasi Navare
> 
> Cc: Haehnle, Nicolai ; Daniel Vetter 
> ; Daenzer, Michel
> ; dri-devel ; 
> amd-gfx mailing list ;
> Deucher, Alexander ; Cyr, Aric ; 
> Koo, Anthony 
> Subject: Re: RFC for a render API to support adaptive sync and VRR
> 
> On 2018-04-10 03:37 AM, Michel Dänzer wrote:
> > On 2018-04-10 08:45 AM, Christian König wrote:
> >> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
> >>> Thanks for initiating the discussion. Find my comments below:
> >>> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
>  On 2018-04-09 03:56 PM, Harry Wentland wrote:
> >
> > === A DRM render API to support variable refresh rates ===
> >
> > In order to benefit from adaptive sync and VRR userland needs a way
> > to let us know whether to vary frame timings or to target a
> > different frame time. These can be provided as atomic properties on
> > a CRTC:
> >   * bool    variable_refresh_compatible
> >   * int    target_frame_duration_ns (nanosecond frame duration)
> >
> > This gives us the following cases:
> >
> > variable_refresh_compatible = 0, target_frame_duration_ns = 0
> >   * drive monitor at timing's normal refresh rate
> >
> > variable_refresh_compatible = 1, target_frame_duration_ns = 0
> >   * send new frame to monitor as soon as it's available, if within
> > min/max of monitor's reported capabilities
> >
> > variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
> >   * send new frame to monitor with the specified
> > target_frame_duration_ns
> >
> > When a target_frame_duration_ns or variable_refresh_compatible
> > cannot be supported the atomic check will reject the commit.
> >
> >>> What I would like is two sets of properties on a CRTC or preferably on
> >>> a connector:
> >>>
> >>> KMD properties that UMD can query:
> >>> * vrr_capable -  This will be an immutable property for exposing
> >>> hardware's capability of supporting VRR. This will be set by the
> >>> kernel after
> >>> reading the EDID mode information and monitor range capabilities.
> >>> * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max
> >>> refresh rates supported.
> >>> These properties are optional and will be created and attached to the
> >>> DP/eDP connector when the connector
> >>> is getting intialized.
> >>
> >> Mhm, aren't those properties actually per mode and not per CRTC/connector?
> >>
> >>> Properties that you mentioned above that the UMD can set before kernel
> >>> can enable VRR functionality
> >>> *bool vrr_enable or vrr_compatible
> >>> target_frame_duration_ns
> >>
> >> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
> >> name/semantics.
> >>
> >> We should use an absolute timestamp where the frame should be presented,
> >> otherwise you could run into a bunch of trouble with IOCTL restarts or
> >> missed blanks.
> >
> > Also, a fixed target frame duration isn't suitable even for video
> > playback, due to drift between the video and audio clocks.

Why?  Even if they drift, you know you want to show your 24Hz video frame for 
41.ms and adaptive sync can ensure that with reasonable accuracy.  
All we're doing is eliminating the need for frame rate converters from the 
application and offloading that to hardware.

> > Time-based presentation seems to be the right approach for preventing
> > micro-stutter in games as well, Croteam developers have been researching
> > this.
> >
> 
> I'm not sure if the driver can ever give a guarantee of the exact time a flip 
> occurs. What we have control over with our HW is frame
> duration.
> 
> Are Croteam devs trying to predict render times? I'm not sure how that would 
> work. We've had bad experience in the past with
> games that try to do framepacing as that's usually not accurate and tends to 
> lead to more problems than benefits.

For gaming, it doesn't make sense nor is it feasible to know how exactly how 
long a render will take with microsecond precision, very coarse guesses at 
best.  The point of adaptive sync is that it works *transparently* for the 
majority of cases, within the capability of the HW and driver.  We don't want 
to have every game re-write their engine to support this, but we do want the 
majority to "just work".

The only exception is the video case where an application may want to request a 
fixed frame duration aligned to the video content.  This requires an explicit 
interface for the video app, and our proposal is to keep it simple:  app knows 
how long a frame should be

Re: RFC for a render API to support adaptive sync and VRR

2018-04-10 Thread Christian König


Am 10.04.2018 um 17:08 schrieb Harry Wentland:

On 2018-04-10 03:37 AM, Michel Dänzer wrote:

On 2018-04-10 08:45 AM, Christian König wrote:

Am 09.04.2018 um 23:45 schrieb Manasi Navare:

Thanks for initiating the discussion. Find my comments below:
On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:

On 2018-04-09 03:56 PM, Harry Wentland wrote:

=== A DRM render API to support variable refresh rates ===

In order to benefit from adaptive sync and VRR userland needs a way
to let us know whether to vary frame timings or to target a
different frame time. These can be provided as atomic properties on
a CRTC:
   * bool    variable_refresh_compatible
   * int    target_frame_duration_ns (nanosecond frame duration)

This gives us the following cases:

variable_refresh_compatible = 0, target_frame_duration_ns = 0
   * drive monitor at timing's normal refresh rate

variable_refresh_compatible = 1, target_frame_duration_ns = 0
   * send new frame to monitor as soon as it's available, if within
min/max of monitor's reported capabilities

variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
   * send new frame to monitor with the specified
target_frame_duration_ns

When a target_frame_duration_ns or variable_refresh_compatible
cannot be supported the atomic check will reject the commit.


What I would like is two sets of properties on a CRTC or preferably on
a connector:

KMD properties that UMD can query:
* vrr_capable -  This will be an immutable property for exposing
hardware's capability of supporting VRR. This will be set by the
kernel after
reading the EDID mode information and monitor range capabilities.
* vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max
refresh rates supported.
These properties are optional and will be created and attached to the
DP/eDP connector when the connector
is getting intialized.

Mhm, aren't those properties actually per mode and not per CRTC/connector?


Properties that you mentioned above that the UMD can set before kernel
can enable VRR functionality
*bool vrr_enable or vrr_compatible
target_frame_duration_ns

Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
name/semantics.

We should use an absolute timestamp where the frame should be presented,
otherwise you could run into a bunch of trouble with IOCTL restarts or
missed blanks.

Also, a fixed target frame duration isn't suitable even for video
playback, due to drift between the video and audio clocks.

Time-based presentation seems to be the right approach for preventing
micro-stutter in games as well, Croteam developers have been researching
this.


I'm not sure if the driver can ever give a guarantee of the exact time a flip 
occurs. What we have control over with our HW is frame duration.


Sounds like you misunderstood what we mean here.

The driver does not need to give an exact guarantee that a flip happens 
at that time. It should just not flip before that specific time.


E.g. when we missed a VBLANK your approach would still wait for the 
specific amount of time, while an absolute timestamp would mean to flip 
as soon as possible after that timestamp passed.


As Michel noted that is also exactly what video players need.



Are Croteam devs trying to predict render times? I'm not sure how that would 
work. We've had bad experience in the past with games that try to do 
framepacing as that's usually not accurate and tends to lead to more problems 
than benefits.


As far as I understand that is just a regulated feedback system, e.g. 
the application records the timestamps of the last three frames (or so) 
and then uses that + margin to as world time for the 3D rendering.


When the application has finished sending all rendering commands it 
sends the frame to be displayed exactly with that timestamp as well.


The timestamp when the frame was actually displayed is then used again 
as input to the algorithm.


Regards,
Christian.



Harry

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


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

Re: [bug report] drm/stm: ltdc: add clut mode support

2018-04-10 Thread Philippe CORNU

Hi Dan,
and many thanks for the bug report.
I sent a patch to fix this issue
https://patchwork.freedesktop.org/patch/216180/
Thank you,
Philippe :-)


On 02/22/2018 08:27 PM, Dan Carpenter wrote:
> Hello Philippe CORNU,
> 
> This is a semi-automatic email about new static checker warnings.
> 
> The patch b706a25eaed0: "drm/stm: ltdc: add clut mode support" from
> Oct 26, 2017, leads to the following Smatch complaint:
> 
>  drivers/gpu/drm/stm/ltdc.c:395 ltdc_crtc_update_clut()
>  warn: variable dereferenced before check 'crtc' (see line 390)
> 
> drivers/gpu/drm/stm/ltdc.c
> 389   {
> 390   struct ltdc_device *ldev = crtc_to_ltdc(crtc);
>  
> Dereferenced inside the function call
> 
> 391   struct drm_color_lut *lut;
> 392   u32 val;
> 393   int i;
> 394   
> 395   if (!crtc || !crtc->state)
>   
> Too late.
> 
> 396   return;
> 397   
> 
> regards,
> dan carpenter
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: RFC for a render API to support adaptive sync and VRR

On 2018-04-10 03:37 AM, Michel Dänzer wrote:
> On 2018-04-10 08:45 AM, Christian König wrote:
>> Am 09.04.2018 um 23:45 schrieb Manasi Navare:
>>> Thanks for initiating the discussion. Find my comments below:
>>> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
 On 2018-04-09 03:56 PM, Harry Wentland wrote:
>
> === A DRM render API to support variable refresh rates ===
>
> In order to benefit from adaptive sync and VRR userland needs a way
> to let us know whether to vary frame timings or to target a
> different frame time. These can be provided as atomic properties on
> a CRTC:
>   * bool    variable_refresh_compatible
>   * int    target_frame_duration_ns (nanosecond frame duration)
>
> This gives us the following cases:
>
> variable_refresh_compatible = 0, target_frame_duration_ns = 0
>   * drive monitor at timing's normal refresh rate
>
> variable_refresh_compatible = 1, target_frame_duration_ns = 0
>   * send new frame to monitor as soon as it's available, if within
> min/max of monitor's reported capabilities
>
> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
>   * send new frame to monitor with the specified
> target_frame_duration_ns
>
> When a target_frame_duration_ns or variable_refresh_compatible
> cannot be supported the atomic check will reject the commit.
>
>>> What I would like is two sets of properties on a CRTC or preferably on
>>> a connector:
>>>
>>> KMD properties that UMD can query:
>>> * vrr_capable -  This will be an immutable property for exposing
>>> hardware's capability of supporting VRR. This will be set by the
>>> kernel after
>>> reading the EDID mode information and monitor range capabilities.
>>> * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max
>>> refresh rates supported.
>>> These properties are optional and will be created and attached to the
>>> DP/eDP connector when the connector
>>> is getting intialized.
>>
>> Mhm, aren't those properties actually per mode and not per CRTC/connector?
>>
>>> Properties that you mentioned above that the UMD can set before kernel
>>> can enable VRR functionality
>>> *bool vrr_enable or vrr_compatible
>>> target_frame_duration_ns
>>
>> Yeah, that certainly makes sense. But target_frame_duration_ns is a bad
>> name/semantics.
>>
>> We should use an absolute timestamp where the frame should be presented,
>> otherwise you could run into a bunch of trouble with IOCTL restarts or
>> missed blanks.
> 
> Also, a fixed target frame duration isn't suitable even for video
> playback, due to drift between the video and audio clocks.
> 
> Time-based presentation seems to be the right approach for preventing
> micro-stutter in games as well, Croteam developers have been researching
> this.
> 

I'm not sure if the driver can ever give a guarantee of the exact time a flip 
occurs. What we have control over with our HW is frame duration.

Are Croteam devs trying to predict render times? I'm not sure how that would 
work. We've had bad experience in the past with games that try to do 
framepacing as that's usually not accurate and tends to lead to more problems 
than benefits.

Harry

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

Re: RFC for a render API to support adaptive sync and VRR

Adding Anthony and Aric who've been working on Freesync with DC on other OSes 
for a while.

On 2018-04-09 05:45 PM, Manasi Navare wrote:
> Thanks for initiating the discussion. Find my comments below:
> 
> On Mon, Apr 09, 2018 at 04:00:21PM -0400, Harry Wentland wrote:
>> Adding dri-devel, which I should've included from the start.
>>
>> On 2018-04-09 03:56 PM, Harry Wentland wrote:
>>> === What is adaptive sync and VRR? ===
>>>
>>> Adaptive sync has been part of the DisplayPort spec for a while now and 
>>> allows graphics adapters to drive displays with varying frame timings. VRR 
>>> (variable refresh rate) is essentially the same, but defined for HDMI.
>>>
>>>
>>>
>>> === Why allow variable frame timings? ===
>>>
>>> Variable render times don't align with fixed refresh rates, leading to
>>> stuttering, tearing, and/or input lag.
>>>
>>> e.g. (rc = render completion, dr = display refresh)
>>>
>>> rc   B  CDE  F
>>> dr  A   B   C   C   D   E   F
>>>
>>> ^ ^
>>>   frame missed 
>>>  repeated   display
>>>   twice refresh   
>>>
>>>
>>>
>>> === Other use cases of adaptive sync 
>>>
>>> Beside the variable render case, adaptive sync also allows adjustment of 
>>> refresh rates without a mode change. One such use case would be 24 Hz video.
>>>
> 
> One of the the advantages here when the render speed is slower than the 
> display refresh rate, since we are stretching the vertical blanking interval
> the display adapters will follow "draw fast and then go idle" approach. This 
> gives power savings when render rate is lower than the display refresh rate.

Are you talking about a use case, such as an idle desktop, where the renders 
are quite sporadic?

>  
>>>
>>>
>>> === A DRM render API to support variable refresh rates ===
>>>
>>> In order to benefit from adaptive sync and VRR userland needs a way to let 
>>> us know whether to vary frame timings or to target a different frame time. 
>>> These can be provided as atomic properties on a CRTC:
>>>  * bool variable_refresh_compatible
>>>  * int  target_frame_duration_ns (nanosecond frame duration)
>>>
>>> This gives us the following cases:
>>>
>>> variable_refresh_compatible = 0, target_frame_duration_ns = 0
>>>  * drive monitor at timing's normal refresh rate
>>>
>>> variable_refresh_compatible = 1, target_frame_duration_ns = 0
>>>  * send new frame to monitor as soon as it's available, if within min/max 
>>> of monitor's reported capabilities
>>>
>>> variable_refresh_compatible = 0/1, target_frame_duration_ns = > 0
>>>  * send new frame to monitor with the specified target_frame_duration_ns
>>>
>>> When a target_frame_duration_ns or variable_refresh_compatible cannot be 
>>> supported the atomic check will reject the commit.
>>>
> 
> What I would like is two sets of properties on a CRTC or preferably on a 
> connector:
> 
> KMD properties that UMD can query:
> * vrr_capable -  This will be an immutable property for exposing hardware's 
> capability of supporting VRR. This will be set by the kernel after 
> reading the EDID mode information and monitor range capabilities.
> * vrr_vrefresh_max, vrr_vrefresh_min - To expose the min and max refresh 
> rates supported.
> These properties are optional and will be created and attached to the DP/eDP 
> connector when the connector
> is getting intialized.
> 

If we're talking about the properties from the EDID these might not necessarily 
align with a currently selected mode, which might have a refresh rate lower 
than the vrr_refresh_max, requiring us to cap it at that. In some scenarios we 
also might do low framerate compensation [1] where we do magic to allow the 
framerate to drop below the supported range.

I think if a vrr_refresh_max/min are exposed to UMD these should really be only 
for informational purposes, in which case it might make more sense to expose 
them through sysfs or even debugfs entries.

[1] https://www.amd.com/Documents/freesync-lfc.pdf

> Properties that you mentioned above that the UMD can set before kernel can 
> enable VRR functionality
> *bool vrr_enable or vrr_compatible
> target_frame_duration_ns
> 
> The monitor only specifies the monitor range through EDID. Apart from this 
> should we also need to scan the modes and check
> if there are modes that have the same pixel clock and horizontal timings but 
> variable vertical totals?
> 

I'm not sure about the VRR spec, but for adaptive sync we should only consider 
the range limits specified in the EDID and allow adaptive sync for modes within 
that range.

> I have RFC patches for all the above mentioned. If we get a 
> concensus/agreement on the above properties and method to check
> monitor's VRR capability, I can submit those patches atleast as RFC.
> 

That sounds great. I wouldn't mind trying those patches and then working 
together to arrive at

[Bug 198883] amdgpu: carrizo: Screen stalls after starting X

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

--- Comment #82 from Ricardo Ribalda (ricardo.riba...@gmail.com) ---
Hi Andrey.

Excellent news, thanks for your effort on 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 198883] amdgpu: carrizo: Screen stalls after starting X

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

--- Comment #81 from Andrey Grodzovsky (andrey.grodzov...@amd.com) ---
With Betong board it seems I reproduced it, I am trying to debug it more +
involving MESA/LLVM people to take a look.

-- 
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

Re: [RfC PATCH] Add udmabuf misc device

2018-04-10 Thread Gerd Hoffmann

  Hi,

> Generally we try to cache mappings as much as possible. And wrt finding a
> slot: Create a sufficiently sized BAR on the virgl device, just for that?

Well.  virtio has no concept of "bars" ...

The most common virtio transport layer happens to be pci, which actually
has bars.  But we also have virtio-mmio (largely unused since arm got
pci) and virtio-ccw (used on s390x).

In any case it would be a layering violation.

Figured meanwhile qemu got memfd support recently, i.e. it can be
configured to back guest memory with memfd.  Which makes the memfd route
quite attractive.  Guess I try switch udmabuf to require memfd storage
as proof-of-concept.

cheers,
  Gerd

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

[PATCH] drm/stm: ltdc: fix warning in ltdc_crtc_update_clut()

2018-04-10 Thread Philippe Cornu

Fix the warning
"warn: variable dereferenced before check 'crtc' (see line 390)"
by removing unnecessary checks as ltdc_crtc_update_clut() is
only called from ltdc_crtc_atomic_flush() where crtc and
crtc->state are not NULL.

Many thanks to Dan Carpenter for the bug report
https://lists.freedesktop.org/archives/dri-devel/2018-February/166918.html

Signed-off-by: Philippe Cornu 
Reported-by: Dan Carpenter 
---
 drivers/gpu/drm/stm/ltdc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/drivers/gpu/drm/stm/ltdc.c b/drivers/gpu/drm/stm/ltdc.c
index 061d2b6e5157..e3121d9e4230 100644
--- a/drivers/gpu/drm/stm/ltdc.c
+++ b/drivers/gpu/drm/stm/ltdc.c
@@ -392,9 +392,6 @@ static void ltdc_crtc_update_clut(struct drm_crtc *crtc)
u32 val;
int i;
 
-   if (!crtc || !crtc->state)
-   return;
-
if (!crtc->state->color_mgmt_changed || !crtc->state->gamma_lut)
return;
 
-- 
2.15.1

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

[Bug 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

Michel Dänzer  changed:

   What|Removed |Added

 Attachment #138731|text/x-log  |text/plain
  mime type||

-- 
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 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #7 from Joel Sass  ---
A note about the Xorg.0.log with amdgpu.dc=0,

I see that the amdgpu module doesn't appear to be loaded. X came up just fine
without the driver being loaded, and GPU desktop acceleration still worked just
fine with compiz in gnome-flashback.

-- 
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] drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path

2018-04-10 Thread Chris Wilson

Quoting Colin King (2018-04-10 13:33:12)
> From: Colin Ian King 
> 
> The error exit path when a duplicate is found does not kfree and cmd_entry
> struct and hence there is a small memory leak.  Fix this by kfree'ing it.
> 
> Detected by CoverityScan, CID#1370198 ("Resource Leak")
> 
> Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
> Signed-off-by: Colin Ian King 
> ---
>  drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
> b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> index d85939bd7b47..3b6d26c44e37 100644
> --- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
> +++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
> @@ -2864,6 +2864,7 @@ static int init_cmd_table(struct intel_gvt *gvt)
> if (info) {
> gvt_err("%s %s duplicated\n", e->info->name,
> info->name);
> +   kfree(e);

e kzalloc'ed moments above, not yet added to any lists, so fine to use
kfree.

Alternatively, the find_cmd_entry_any_ring() could be moved ahead of the
kzalloc as this function must be externally serialised.

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

[Bug 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #5 from Joel Sass  ---
Created attachment 138736
  --> https://bugs.freedesktop.org/attachment.cgi?id=138736=edit
dmesg output with amdgpu.dc=1 switch

-- 
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 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #6 from Joel Sass  ---
Created attachment 138737
  --> https://bugs.freedesktop.org/attachment.cgi?id=138737=edit
xrandr with amdgpu.dc=1 switch

-- 
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 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #4 from Joel Sass  ---
Created attachment 138735
  --> https://bugs.freedesktop.org/attachment.cgi?id=138735=edit
Xorg.0.log with amdgpu.dc=1

-- 
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 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

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

--- Comment #13 from har...@gmx.de ---
... have to add:

This problem doesn't occur too with:

- amdgpu.dc=0

-- 
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

[PATCH v6 1/2] drm/bridge: Add Cadence DSI driver

2018-04-10 Thread Boris Brezillon

From: Boris Brezillon 

Add a driver for Cadence DPI -> DSI bridge.

This driver only support a subset of Cadence DSI bridge capabilities.

This driver has been tested/debugged in a simulated environment which
explains why some of the features are missing.  Here is a
non-exhaustive list of missing features:
 * burst mode
 * DPHY init/configuration steps
 * support for additional input interfaces (SDI input)

DSI commands and non-burst video mode have been tested.

Signed-off-by: Boris Brezillon 
Reviewed-by: Andrzej Hajda 
Acked-by: Eric Anholt 
---
Hello,

This version is still missing DPHY config/init code, mainly because I
don't have a DPHY (either real or emulated) to test with. But I'm
working on a DPHY abstraction layer to help extract common DPHY
operations out of DSI drivers so that DPHY drivers can be used outside
of the DRM world (I know D-PHYs can be used with CSI which belongs in
V4L).

Regards,

Boris

This version is still missing

Changes in v6:
- Use SPDX header
- Do not enable the sys_clk in the probe function
- Remove unneeded udelay()
- Add a function to make sure the PLL and pixel clock are close enough
  to be recoverable if they don't match exactly
- Add the DPHY init sequence used in simulation (likely to be different
  based on each SoC integration)

Changes in v5:
- Add runtime PM support

Changes in v4:
- Fix typos
- Rename clks as suggested by Tomi
- Fix DSI setup done in cdns_dsi_bridge_enable()
- Add a precision about where this bridge is supposed to used to the
  Kconfig entry
- Let DRM_CDNS_DSI select DRM_PANEL_BRIDGE
- Remove the IP version from the DT compatible name
- Adapt register the layout to match the one used in the last revision
  of the IP (hopefully the final version)

Changes in v3:
- replace magic values by real timing calculation. The DPHY PLL clock
  is still hardcoded since we don't have a working DPHY block yet, and
  this is the piece of HW we need to dynamically configure the PLL
  rate based on the display refresh rate and the resolution.
- parse DSI devices represented with the OF-graph. This is needed to
  support DSI devices controlled through an external bus like I2C or
  SPI.
- use the DRM panel-bridge infrastructure to simplify the DRM panel
  logic

Changes in v2:
- rebase on v4.12-rc1 and adapt to driver to the drm_bridge API changes
- return the correct error when devm_clk_get(sysclk) fails
- add missing depends on OF and select DRM_PANEL in the Kconfig entry

DSI runtime PM
---
 drivers/gpu/drm/bridge/Kconfig|   10 +
 drivers/gpu/drm/bridge/Makefile   |1 +
 drivers/gpu/drm/bridge/cdns-dsi.c | 1624 +
 3 files changed, 1635 insertions(+)
 create mode 100644 drivers/gpu/drm/bridge/cdns-dsi.c

diff --git a/drivers/gpu/drm/bridge/Kconfig b/drivers/gpu/drm/bridge/Kconfig
index 3aa65bdecb0e..1cd267880b53 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -25,6 +25,16 @@ config DRM_ANALOGIX_ANX78XX
  the HDMI output of an application processor to MyDP
  or DisplayPort.
 
+config DRM_CDNS_DSI
+   tristate "Cadence DPI/DSI bridge"
+   select DRM_KMS_HELPER
+   select DRM_MIPI_DSI
+   select DRM_PANEL_BRIDGE
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge. This is an internal
+ bridge and is meant to be directly embedded in a SoC.
+
 config DRM_DUMB_VGA_DAC
tristate "Dumb VGA DAC Bridge support"
depends on OF
diff --git a/drivers/gpu/drm/bridge/Makefile b/drivers/gpu/drm/bridge/Makefile
index 373eb28f31ed..aea7cbe9070b 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,5 +1,6 @@
 # SPDX-License-Identifier: GPL-2.0
 obj-$(CONFIG_DRM_ANALOGIX_ANX78XX) += analogix-anx78xx.o
+obj-$(CONFIG_DRM_CDNS_DSI) += cdns-dsi.o
 obj-$(CONFIG_DRM_DUMB_VGA_DAC) += dumb-vga-dac.o
 obj-$(CONFIG_DRM_LVDS_ENCODER) += lvds-encoder.o
 obj-$(CONFIG_DRM_MEGACHIPS_STDP_GE_B850V3_FW) += 
megachips-stdp-ge-b850v3-fw.o
diff --git a/drivers/gpu/drm/bridge/cdns-dsi.c 
b/drivers/gpu/drm/bridge/cdns-dsi.c
new file mode 100644
index ..d4ceb961f475
--- /dev/null
+++ b/drivers/gpu/drm/bridge/cdns-dsi.c
@@ -0,0 +1,1624 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Copyright: 2017 Cadence Design Systems, Inc.
+ *
+ * Author: Boris Brezillon 
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define IP_CONF0x0
+#define SP_HS_FIFO_DEPTH(x)(((x) & GENMASK(30, 26)) >> 26)
+#define SP_LP_FIFO_DEPTH(x)(((x) & GENMASK(25, 21)) >> 21)
+#define VRS_FIFO_DEPTH(x)  (((x) & GENMASK(20, 16)) >> 16)
+#define DIRCMD_FIFO_DEPTH(x)   (((x) & GENMASK(15, 13))

[PATCH v6 2/2] dt-bindings: drm/bridge: Document Cadence DSI bridge bindings

2018-04-10 Thread Boris Brezillon

From: Boris Brezillon 

Document the bindings used for the Cadence DSI bridge.

Signed-off-by: Boris Brezillon 
---
Hello Rob,

I dropped your Acked-by because this version now documents the DPHY
bindings.

Regards,

Boris

Changes in v6:
- Document the DPHY bindings
- Drop Rob's ack because of the addition DPHY bindings doc

Changes in v5:
- Add optional reset line for the peripheral/APB logic

Changes in v4:
- Rename DSI clks (suggested by Tomi)
- Drop the IP version in the compatible since it can be extracted from
  a register (suggested by Andrzej)

Changes in v3:
- Fix clock names in the example
- Document how to represent DSI devices that are controller through
  an external bus like I2C or SPI

Changes in v2:
- None
---
 .../bindings/display/bridge/cdns,dsi.txt   | 133 +
 1 file changed, 133 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt

diff --git a/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt 
b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
new file mode 100644
index ..f5725bb6c61c
--- /dev/null
+++ b/Documentation/devicetree/bindings/display/bridge/cdns,dsi.txt
@@ -0,0 +1,133 @@
+Cadence DSI bridge
+==
+
+The Cadence DSI bridge is a DPI to DSI bridge supporting up to 4 DSI lanes.
+
+Required properties:
+- compatible: should be set to "cdns,dsi".
+- reg: physical base address and length of the controller's registers.
+- interrupts: interrupt line connected to the DSI bridge.
+- clocks: DSI bridge clocks.
+- clock-names: must contain "dsi_p_clk" and "dsi_sys_clk".
+- phys: phandle link to the MIPI D-PHY controller.
+- phy-names: must contain "dphy".
+- #address-cells: must be set to 1.
+- #size-cells: must be set to 0.
+
+Optional properties:
+- resets: DSI reset lines.
+- reset-names: can contain "dsi_p_rst".
+
+Required subnodes:
+- ports: Ports as described in Documentation/devicetree/bindings/graph.txt.
+  2 ports are available:
+  * port 0: this port is only needed if some of your DSI devices are
+   controlled through  an external bus like I2C or SPI. Can have at
+   most 4 endpoints. The endpoint number is directly encoding the
+   DSI virtual channel used by this device.
+  * port 1: represents the DPI input.
+  Other ports will be added later to support the new kind of inputs.
+
+- one subnode per DSI device connected on the DSI bus. Each DSI device should
+  contain a reg property encoding its virtual channel.
+
+Cadence DPHY
+
+
+Cadence DPHY block.
+
+Required properties:
+- compatible: should be set to "cdns,dphy".
+- reg: physical base address and length of the DPHY registers.
+- clocks: DPHY reference clocks.
+- clock-names: must contain "psm" and "pll_ref".
+- #phy-cells: must be set to 0.
+
+
+Example:
+   dphy0: dphy@fd0e{
+   compatible = "cdns,dphy";
+   reg = <0x0 0xfd0e 0x0 0x1000>;
+   clocks = <_clk>, <_ref_clk>;
+   clock-names = "psm", "pll_ref";
+   #phy-cells = <0>;
+   };
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@1 {
+   reg = <1>;
+   dsi0_dpi_input: endpoint {
+   remote-endpoint = <_dpi_output>;
+   };
+   };
+   };
+
+   panel: dsi-dev@0 {
+   compatible = "";
+   reg = <0>;
+   };
+   };
+
+or
+
+   dsi0: dsi@fd0c {
+   compatible = "cdns,dsi";
+   reg = <0x0 0xfd0c 0x0 0x1000>;
+   clocks = <>, <>;
+   clock-names = "dsi_p_clk", "dsi_sys_clk";
+   interrupts = <1>;
+   phys = <>;
+   phy-names = "dphy";
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   ports {
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   port@0 {
+   reg = <0>;
+   #address-cells = <1>;
+   #size-cells = <0>;
+
+   dsi0_output: endpoint@0 {
+   reg = <0>;
+   remote-endpoint =

[Bug 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #3 from Joel Sass  ---
Created attachment 138734
  --> https://bugs.freedesktop.org/attachment.cgi?id=138734=edit
lshw output

-- 
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 103917] [gfx9/Vega] Performance regression in master, 17.3 works fine

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #3 from Timothy Arceri  ---
(In reply to Vedran Miletić from comment #0)
> I'm using Fedora rawhide (to become 28) along with Mesa 17.3.0-rc3, LLVM
> 5.0.0 and Kernel 4.15-git. If I install Mesa 17.3.0-rc5, everything still
> works fine. If I install Mesa git, everything works fine with 17.3-rc3
> running desktop and 17.4 running games.
> 

Using rawhide especially so early into a release you should expect issues all
over the place. This isn't a very good way to be testing Mesa from git and
reporting issues, for example there can be kernel/gcc/x/desktop bugs etc it
makes it hard to narrow things down, on top of that package versions are
constantly changing. It's better to Upgrade Mesa/LLVM/kernel etc on a stable
distro for your testing.

> After rebo a reboot, however, with Mesa git running both the desktop and
> games, performance in games is very bad, rougly 1 fps.
> 

It could be anything but possibly you have fallen back to software rendering. 

Anyway Fedora 28 will be using LLVM 6.0, Linux 4.16. I'm going to close the bug
report as there isn't much to go on here, but feel free to reopen if you still
have issue with the stable Fedora 28 release.

-- 
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 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #2 from Joel Sass  ---
Created attachment 138733
  --> https://bugs.freedesktop.org/attachment.cgi?id=138733=edit
xrandr with amdgpu.dc=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 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

--- Comment #1 from Joel Sass  ---
Created attachment 138732
  --> https://bugs.freedesktop.org/attachment.cgi?id=138732=edit
Xorg.0.log with amdgpu.dc=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 105971] DVI port is not detecting connected monitor with 4.16.0+ kernel and amdgpu.dc=1 set

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

Bug ID: 105971
Summary: DVI port is not detecting connected monitor with
4.16.0+ kernel and amdgpu.dc=1 set
Product: DRI
Version: unspecified
Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
Severity: normal
Priority: medium
Component: DRM/AMDgpu
Assignee: dri-devel@lists.freedesktop.org
Reporter: sass.j...@gmail.com

Created attachment 138731
--> https://bugs.freedesktop.org/attachment.cgi?id=138731=edit
dmesg output from amdgpu.dc=0 switch

Hello. I'm trying to get 4 monitors working on the same desktop. Video card is
a Radeon RX560.

root@nope:/tmp# lsb_release -a
LSB Version:
core-9.20160110ubuntu0.2-amd64:core-9.20160110ubuntu0.2-noarch:security-9.20160110ubuntu0.2-amd64:security-9.20160110ubuntu0.2-noarch
Distributor ID: Ubuntu
Description:Ubuntu 16.04.4 LTS
Release:16.04
Codename: xenial

root@nope:/tmp# uname -a
Linux nope 4.16.0+ #1 SMP Mon Apr 2 15:52:14 CEST 2018 x86_64 x86_64 x86_64
GNU/Linux

With kernel switch amdgpu.dc=1, DVI port doesn't detected connected monitor,
but displayport MST is detected and utilized properly, allowing me to output
video to three monitors from a single displayport.

With kernel switch amdgpu.dc=0, DVI port properly detects connected monitor,
but displayport MST is not detected. Instead, displayport MST acts as a single
output, and video output is mirrored to all three connected monitors.

This appears to be a kernel issue. Kernel was retrieved from git repo
github.com/M-Bab/linux-kernel-amdgpu-binaries

I'm running the AMDGPU.UBUNTU kernel on that repo.

I'll attach dmesg, xrandr and Xorg.0.log output from both kernel switches.

I'm running amdgpu.dc_log=1 kernel switch for verbose logging.

--
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 199319] Flickering screen on AMDGPU and DC with Linux 4.16-2

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

har...@gmx.de changed:

   What|Removed |Added

 CC||har...@gmx.de

--- Comment #12 from har...@gmx.de ---
Same here:

Flickering (as described by 'mail'):
4.16.1, R9 380X, Mesa 18.1.0-devel (git-d899826733), X11(1.19.6)
Tried Gnome and XFCE, similar problems.

This problem doesn't occur with:

- older Kernel (4.15.0)
- 3D Fullscreen (Games)
- older GPU (R9 280X)

Maybe a powerplay related problem, since it only affect newer AMD cards?

-- 
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

Re: [PATCH] drm/rockchip: fix VOP vblank race

2018-04-10 Thread Sandy Huang


Reviewed-by: Sandy huang 

在 2018/3/29 0:03, John Keeping 写道:

We have seen a case of a bad reference count for vblanks with the
Rockchip VOP:

[ cut here ]
WARNING: CPU: 1 PID: 383 at drivers/gpu/drm/drm_irq.c:1198 
drm_vblank_put+0x40/0xcc
Modules linked in: brcmfmac brcmutil
CPU: 1 PID: 383 Comm: kworker/u8:2 Not tainted 4.9.75-rt60 #1
Hardware name: Rockchip (Device Tree)
Workqueue: events_unbound flip_worker
Backtrace:
[] (dump_backtrace) from [] (show_stack+0x18/0x1c)
 r7:c0b1b13c r6:600b0013 r5: r4:c0b1b13c
[] (show_stack) from [] (dump_stack+0x78/0x94)
[] (dump_stack) from [] (__warn+0xe4/0x104)
 r7:0009 r6:c03cf26c r5: r4:
[] (__warn) from [] (warn_slowpath_null+0x28/0x30)
 r9:eeb443a0 r8:eeb443c8 r7:ee8a5ec0 r6:ee8a5ec0 r5:edb47f00 r4:ee096200
[] (warn_slowpath_null) from [] 
(drm_vblank_put+0x40/0xcc)
[] (drm_vblank_put) from [] 
(drm_crtc_vblank_put+0x18/0x1c)
 r5:edb47f00 r4:ee3c8a80
[] (drm_crtc_vblank_put) from [] 
(vop_fb_unref_worker+0x18/0x24)
[] (vop_fb_unref_worker) from [] 
(flip_worker+0x98/0xb4)
 r5:edb47f00 r4:eeb443a8
[] (flip_worker) from [] 
(process_one_work+0x1a8/0x2fc)
 r9: r8:ee807d00 r7: r6:ee809c00 r5:eeb443a8 r4:edfe5f80
[] (process_one_work) from [] 
(worker_thread+0x2ac/0x458)
 r10:0088 r9:edfe5f98 r8:ee809c2c r7:c0b04100 r6:ee809c00 
r5:ee809c00
 r4:edfe5f80
[] (worker_thread) from [] (kthread+0xfc/0x10c)
 r10: r9: r8:c0135640 r7:edfe5f80 r6: 
r5:edf0e240
 r4:ee8a4000 r3:ed194e00
[] (kthread) from [] (ret_from_fork+0x14/0x3c)
 r8: r7: r6: r5:c0139fc0 r4:edf0e240
---[ end trace 0002 ]---

It seems that this is caused by unfortunate timing between
vop_crtc_atomic_flush() and vop_handle_vblank() given the following
ordering:

atomic_flushhandle_vblank
-

drm_flip_work_queue
set_bit
if (test_and_clear_bit(...))
drm_flip_work_commit
drm_vblank_get

This results in vop_fb_unref_worker (called as flip work) decrementing
the vblank refcount before it has been incremented.

Signed-off-by: John Keeping 
---
  drivers/gpu/drm/rockchip/rockchip_drm_vop.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
index 6755a9eea4b2..d4e1400aedf3 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_vop.c
@@ -1017,9 +1017,9 @@ static void vop_crtc_atomic_flush(struct drm_crtc *crtc,
continue;
  
  		drm_framebuffer_get(old_plane_state->fb);

+   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
drm_flip_work_queue(>fb_unref_work, old_plane_state->fb);
set_bit(VOP_PENDING_FB_UNREF, >pending);
-   WARN_ON(drm_crtc_vblank_get(crtc) != 0);
}
  }
  



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

[Bug 103384] [UBUNTU 16.04] Poor performance after update video-driver (HD7790, radeonsi)

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

Timothy Arceri  changed:

   What|Removed |Added

 Resolution|--- |NOTOURBUG
 Status|NEW |RESOLVED

--- Comment #6 from Timothy Arceri  ---
(In reply to Max from comment #5)
> i load Ubuntu via kernel:
> 4.4.0-31-generic - PERFECT PERFORMANCE!!!

4.4.0-31 vs 4.4.0-87-generic indicates that the change whatever it was is due
to ubuntu specific patches. I'd suggest upgrading your Ubuntu 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

[PATCH] drm/i915/gvt: fix memory leak of a cmd_entry struct on error exit path

2018-04-10 Thread Colin King

From: Colin Ian King 

The error exit path when a duplicate is found does not kfree and cmd_entry
struct and hence there is a small memory leak.  Fix this by kfree'ing it.

Detected by CoverityScan, CID#1370198 ("Resource Leak")

Fixes: be1da7070aea ("drm/i915/gvt: vGPU command scanner")
Signed-off-by: Colin Ian King 
---
 drivers/gpu/drm/i915/gvt/cmd_parser.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/gpu/drm/i915/gvt/cmd_parser.c 
b/drivers/gpu/drm/i915/gvt/cmd_parser.c
index d85939bd7b47..3b6d26c44e37 100644
--- a/drivers/gpu/drm/i915/gvt/cmd_parser.c
+++ b/drivers/gpu/drm/i915/gvt/cmd_parser.c
@@ -2864,6 +2864,7 @@ static int init_cmd_table(struct intel_gvt *gvt)
if (info) {
gvt_err("%s %s duplicated\n", e->info->name,
info->name);
+   kfree(e);
return -EEXIST;
}
 
-- 
2.15.1

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

Re: [PATCH v2] display: panel: Add AUO g070vvn01 display support (800x480)

2018-04-10 Thread Rob Herring

On Tue, Apr 10, 2018 at 5:29 AM, Lukasz Majewski  wrote:
> This commit adds support for AUO's 7.0" display.
>
> Signed-off-by: Lukasz Majewski 
>
> ---
> Changes for v2:
> - Add *.txt suffix to the auo,g070wn01 file
> - Remove not needed bus-format-override = "rgb565"; property
> ---
>  .../bindings/display/panel/auo,g070vvn01.txt   | 30 +
>  drivers/gpu/drm/panel/panel-simple.c   | 31 
> ++
>  2 files changed, 61 insertions(+)
>  create mode 100644 
> Documentation/devicetree/bindings/display/panel/auo,g070vvn01.txt

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

[Bug 102414] Hawaii gpu (R9 290) and the troubles with the amd-staging-drm-next branch

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

--- Comment #7 from Timothy Arceri  ---
Is this still a problem?

-- 
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 101185] System hang during piglit tests

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

--- Comment #1 from Timothy Arceri  ---
Unfortunately there are some known kernel issues with some tests. Currently I
run this after building piglit to avoid the tests that cause issues:

rm bin/streaming-texture-leak
rm bin/fbo-maxsize
rm bin/tex3d-maxsize
rm bin/max-texture-size

-- 
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 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 96935, which changed state.

Bug 96935 Summary: Trying to Mine Ethereum on Tahiti OpenCL crashes the whole 
system
https://bugs.freedesktop.org/show_bug.cgi?id=96935

   What|Removed |Added

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

-- 
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 96935] Trying to Mine Ethereum on Tahiti OpenCL crashes the whole system

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

Timothy Arceri  changed:

   What|Removed |Added

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

--- Comment #2 from Timothy Arceri  ---
Requested testing was never done, and probably won't be done considering the
age of the bug. Closing as the stack has since move on as per comment 1.

-- 
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 99553] Tracker bug for runnning OpenCL applications on Clover

https://bugs.freedesktop.org/show_bug.cgi?id=99553
Bug 99553 depends on bug 96934, which changed state.

Bug 96934 Summary: Mining Ethereum on Tahiti OpenCL orders of magnitude slower 
than on proprietary drivers
https://bugs.freedesktop.org/show_bug.cgi?id=96934

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

-- 
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 96934] Mining Ethereum on Tahiti OpenCL orders of magnitude slower than on proprietary drivers

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |NOTABUG

-- 
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 88458] The monitor turns off when playing starcraft 2 in wine

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

Timothy Arceri  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Timothy Arceri  ---
Original problem fixed as per comment 9. Additional information (apitrace) on
VM faults was never supplied so closing bug.

Feel free to reopen if you still have the secondary errors and can provide the
requested apitrace. 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

[Bug 105425] 3D & games produce periodic GPU crashes (Radeon R7 370)

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

--- Comment #21 from MirceaKitsune  ---
(In reply to iive from comment #20)

That's some amazing feedback, thank you very much! I'll definitely try those
out, but I have a few questions about a few of these points:

1. My OS (openSUSE Tumbleweed) doesn't have an xorg.conf file. I instead have
an /etc/X11/xorg.conf.d directory with the following files in it:

00-keyboard.conf
00-keyboard.conf.backup
10-amdgpu.conf
10-evdev.conf
10-libvnc.conf
10-quirks.conf
11-evdev.conf
40-libinput.conf
50-device.conf
50-elotouch.conf
50-extensions.conf
50-monitor.conf
50-screen.conf
70-synaptics.conf
70-vmmouse.conf
70-wacom.conf

5. So before running the program from a console, I do "export GALLIUM_HUD=1" or
"GALLIUM_HUD=1;./my_program"? I don't suspect filled RAM as the game's process
doesn't seem to leak memory... I do however suspect filled VRAM.

6. What is the Kernel parameter for CMA please? It doesn't seem to be an amdgpu
setting so I assume it's separate.

-- 
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 105968] ib test on ring 5 succeeded takes too long

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

--- Comment #2 from Paul Menzel  ---
(In reply to Christian König from comment #1)
> Yeah, UVD clocking on APUs doesn't work correctly.

Interesting. Could you please elaborate? If it does not work correctly anyway,
can it be disabled to avoid the boot time penalty?

> We are just sorting that out for the new APUs, but won't have time to fix
> the old ones as well.

Understood.

-- 
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 70910] [radeonsi] wrong colors on radeonsi screen in some places when radeonsi and r600g gpus are installed