[Bug 99349] Failed to build shader (translation from TGSI)

[bugzilla-daemon]

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

Gert Wollny  changed:

   What|Removed |Added

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

--- Comment #18 from Gert Wollny  ---
Fix applied and consolidated with 
c4741bbb6fb98f78551f9e42ae570dcc924e0031

-- 
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 v8 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Heiko Stuebner]

Am Freitag, 8. September 2017, 09:23:09 CEST schrieb Mark yao:
> On 2017年09月07日 20:09, Heiko Stübner wrote:
> > Hi Mark,
> >
> > Am Donnerstag, 7. September 2017, 18:16:29 CEST schrieb Mark yao:
> >> Looks good for me, so:
> >> Reviewed-by: Mark Yao 
> >>
> >> I'd like to apply these lvds patches tomorrow if there is no more doubts.
> > Rob had some minor comments on v7 of the dt-binding, so you may want
> > to give him a bit more time to Ack the hopefully updated binding.
> 
> Rob already gave a Reviewed-by on v7 dt-binding, but maybe it has some doubts 
> for his Ack.
> 
> Ok, let's wait some more time.

ah, I looked at v6 and found the comments, not v7 and v7 is not in my
archive because I likely accidentially deleted it.
So Sandy just forgot to carry over the Ack/Review tag. So I guess there is
no need to wait anymore and you just need to pick up Rob's tag from v7 then.


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

[Bug 100666] amdgpu coolers never stoping linux

[bugzilla-daemon]

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

--- Comment #5 from Lucas Riutzel  ---
$ ls /sys/class/drm/card*/device/hwmon/hwmon*/pwm*

/sys/class/drm/card0/device/hwmon/hwmon0/pwm1
/sys/class/drm/card0/device/hwmon/hwmon0/pwm1_enable
/sys/class/drm/card0/device/hwmon/hwmon0/pwm1_max
/sys/class/drm/card0/device/hwmon/hwmon0/pwm1_min

-- 
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 100666] amdgpu coolers never stoping linux

[bugzilla-daemon]

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

--- Comment #4 from Denis Denisov  ---
$ ls /sys/class/drm/card*/device/hwmon/hwmon*/pwm*

-- 
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 100666] amdgpu coolers never stoping linux

[bugzilla-daemon]

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

--- Comment #3 from Lucas Riutzel  ---
I believe this is related. Might be a separate issue though.

I have an Asus RX550. With the amdgpu drive my fan is at what I believe is 100%
all the time. Though reporting doesn't work.

I can change the pwm1_enable setting between 1/2 but no difference in the fan.

$ cat /sys/class/drm/card0/device/hwmon/hwmon0/pwm1
cat: pwm1: No such device

Attempting to set pwm1 results in no change.

$ sensors
amdgpu-pci-2400
Adapter: PCI adapter
fan1: N/A
temp1:+45.0°C  (crit =  +0.0°C, hyst =  +0.0°C)


$ lsb_release -drc
Description:Arch Linux
Release:rolling
Codename:   n/a

$ uname -rso
Linux 4.12.10-1-ARCH GNU/Linux

-- 
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/sun4i: tcon: Unconditionally reset the TCON

[Chen-Yu Tsai]

When binding the TCON, we were checking the reset control status and
asserting reset if it wasn't in reset. The check failed to account for
the reset control API returning error codes if the status callback was
not implemented.

Since we want the TCON to be reset in all cases, and re-asserting the
reset control does no harm, just assert the reset unconditionally.

Fixes: 9026e0d122ac ("drm: Add Allwinner A10 Display Engine support")
Signed-off-by: Chen-Yu Tsai 
---
 drivers/gpu/drm/sun4i/sun4i_tcon.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/drivers/gpu/drm/sun4i/sun4i_tcon.c 
b/drivers/gpu/drm/sun4i/sun4i_tcon.c
index d9791292553e..eb32676d5b01 100644
--- a/drivers/gpu/drm/sun4i/sun4i_tcon.c
+++ b/drivers/gpu/drm/sun4i/sun4i_tcon.c
@@ -530,8 +530,7 @@ static int sun4i_tcon_bind(struct device *dev, struct 
device *master,
}
 
/* Make sure our TCON is reset */
-   if (!reset_control_status(tcon->lcd_rst))
-   reset_control_assert(tcon->lcd_rst);
+   reset_control_assert(tcon->lcd_rst);
 
ret = reset_control_deassert(tcon->lcd_rst);
if (ret) {
-- 
2.14.1

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

Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

[Hoegeun Kwon]

On 09/07/2017 08:27 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 11:39, Hoegeun Kwon wrote:

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 


The new values (5250/5420 specific) should replace old exynos5-gsc, 
there is no

point providing both in dts.



Hi Marek,

Thanks for your review.

I used both compatibles to not modify v4l2.
But v4l2 will also be fixed, so 'exynos5-gsc' will be removed.

And also, Thanks for your comment for of_device_get_match_data() of 
patch(3/3).


Best regards,
Hoegeun


---
  arch/arm/boot/dts/exynos5250.dtsi | 8 
  arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi

index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
  };
gsc_0:  gsc@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -647,7 +647,7 @@
  };
gsc_1:  gsc@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -657,7 +657,7 @@
  };
gsc_2:  gsc@13e2 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e2 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
@@ -667,7 +667,7 @@
  };
gsc_3:  gsc@13e3 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";

  reg = <0x13e3 0x1000>;
  interrupts = ;
  power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi

index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
  };
gsc_0: video-scaler@13e0 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e0 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
  };
gsc_1: video-scaler@13e1 {
-compatible = "samsung,exynos5-gsc";
+compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";

  reg = <0x13e1 0x1000>;
  interrupts = ;
  clocks = < CLK_GSCL1>;


Best regards


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

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

[Hoegeun Kwon]

On 09/07/2017 08:25 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-07 07:16, Hoegeun Kwon wrote:

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:
The gscaler has hardware rotation limits that need to be imported 
from

dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +config = >config[EXYNOS_DRM_OPS_DST];
+
+/* check for degree */
+switch (config->degree) {
+case EXYNOS_DRM_DEGREE_90:
+case EXYNOS_DRM_DEGREE_270:
+swap = true;
+break;
+case EXYNOS_DRM_DEGREE_0:
+case EXYNOS_DRM_DEGREE_180:
+swap = false;
+break;
+default:
+DRM_ERROR("invalid degree.\n");
+goto err_property;
+}
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -/* check for degree */
-switch (config->degree) {
-case EXYNOS_DRM_DEGREE_90:
-case EXYNOS_DRM_DEGREE_270:
-swap = true;
-break;
-case EXYNOS_DRM_DEGREE_0:
-case EXYNOS_DRM_DEGREE_180:
-swap = false;
-break;
-default:
-DRM_ERROR("invalid degree.\n");
-goto err_property;
-}
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  goto err_property;
  }
  +/*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related 
to pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-(sz->vsize > pp->crop_max.hsize) ||
+(pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-(sz->hsize > pp->crop_max.vsize)) {
+(pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-(sz->hsize > pp->crop_max.hsize) ||
+(pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-(sz->vsize > pp->crop_max.vsize)) {
+(pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int 
gsc_ippdrv_check_property(struct device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-(sz->vsize > pp->scale_max.hsize) ||
+(pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-(sz->hsize > pp->scale_max.vsize)) {
+(pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-(sz->hsize > pp->scale_max.hsize) ||
+(pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-(sz->vsize > pp->scale_max.vsize)) {
+(pos->h > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
@@ -1676,6 +1684,15 @@ static int gsc_probe(struct platform_device 
*pdev)

  

[Bug 102599] [ShadowPrimary] Window decoration not being painted with DRI3 and Compiz-Reloaded+Emerald

[bugzilla-daemon]

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

Michel Dänzer  changed:

   What|Removed |Added

Summary|Window decoration not being |[ShadowPrimary] Window
   |painted with DRI3 and   |decoration not being
   |Compiz-Reloaded+Emerald |painted with DRI3 and
   ||Compiz-Reloaded+Emerald

-- 
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 102581] 3D texture mipmapping broken

[bugzilla-daemon]

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

--- Comment #1 from Michel Dänzer  ---
Please attach the corresponding glxinfo output.

FWIW, not seeing the problem on Kaveri with recent Git master.

-- 
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 v8 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Mark yao]

On 2017年09月07日 20:09, Heiko Stübner wrote:

Hi Mark,

Am Donnerstag, 7. September 2017, 18:16:29 CEST schrieb Mark yao:

Looks good for me, so:
Reviewed-by: Mark Yao 

I'd like to apply these lvds patches tomorrow if there is no more doubts.

Rob had some minor comments on v7 of the dt-binding, so you may want
to give him a bit more time to Ack the hopefully updated binding.


Rob already gave a Reviewed-by on v7 dt-binding, but maybe it has some doubts 
for his Ack.

Ok, let's wait some more time.


Otherwise no doubts from me, just a reminder that you should take
patches 1+3 and I'll pick patch 2 with the dts changes after that.


Thanks
Heiko






--
Ｍark Yao


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

[Bug 102599] Window decoration not being painted with DRI3 and Compiz-Reloaded+Emerald

[bugzilla-daemon]

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

--- Comment #3 from Julian  ---
Without the "ShadowPrimary" option the windows are rendered correctly :)
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 102595] clpeak

[bugzilla-daemon]

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

--- Comment #3 from Benji Wiebe  ---
Created attachment 134061
  --> https://bugs.freedesktop.org/attachment.cgi?id=134061=edit
Better stack trace

-- 
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 102595] clpeak

[bugzilla-daemon]

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

--- Comment #2 from Benji Wiebe  ---
New backtrace with debugging turned on. It appears that the issue is a NULL
pointer dereference in r600_resource_copy_region (dst). In
compute_memory_promote_item, pool->bo is NULL (which is what 'dst' is for
r600_resource_copy_region).

-- 
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 102599] Window decoration not being painted with DRI3 and Compiz-Reloaded+Emerald

[bugzilla-daemon]

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

--- Comment #2 from Michel Dänzer  ---
Does this happen without Option "ShadowPrimary"?

-- 
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 102599] Window decoration not being painted with DRI3 and Compiz-Reloaded+Emerald

[bugzilla-daemon]

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

--- Comment #1 from Julian  ---
Created attachment 134060
  --> https://bugs.freedesktop.org/attachment.cgi?id=134060=edit
White border instead of actual decoration

-- 
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 102599] Window decoration not being painted with DRI3 and Compiz-Reloaded+Emerald

[bugzilla-daemon]

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

Bug ID: 102599
   Summary: Window decoration not being painted with DRI3 and
Compiz-Reloaded+Emerald
   Product: DRI
   Version: unspecified
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/Radeon
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: freedesktop@styxxx.de

Created attachment 134059
  --> https://bugs.freedesktop.org/attachment.cgi?id=134059=edit
Xorg.0.log with DRI3

Hi,

I originally filed a bug report at the compiz-reloaded project. You can read
about the issue and the original conversation here:
https://github.com/compiz-reloaded/compiz/issues/82


When using Compiz-Reloaded + Emerald and DRI3 the window decoration is not
being painted correctly: It's just a plain white border. You can still click
the insivible buttons or resize the window. So it's an issue with rendering the
window border. No error messages and no log entries are produced. 

The problem doesn't occur after I switched to DRI2.

Thank you :)


Debian testing/stretch, 4.12.0-1-amd64 #1 SMP Debian 4.12.6-1 (2017-08-12)
x86_64 GNU/Linux


glxinfo | grep renderer:

GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
GLX_MESA_multithread_makecurrent, GLX_MESA_query_renderer, 
Extended renderer info (GLX_MESA_query_renderer):
OpenGL renderer string: Gallium 0.4 on AMD PALM (DRM 2.50.0 / 4.12.0-1-amd64,
LLVM 3.9.1)


Installed packages:

$ dpkg -l | grep xserver
ii  x11-xserver-utils7.7+7+b1  
amd64X server utilities
ii  xserver-common   2:1.19.3-2
all  common files used by various X servers
ii  xserver-xephyr   2:1.19.3-2
amd64nested X server
ii  xserver-xorg 1:7.7+19  
amd64X.Org X server
ii  xserver-xorg-core2:1.19.3-2
amd64Xorg X server - core server
ii  xserver-xorg-input-evdev 1:2.10.5-1
amd64X.Org X server -- evdev input driver
ii  xserver-xorg-input-mouse
1:1.9.2-1+b1   amd64X.Org X server -- mouse
input driver
ii  xserver-xorg-input-synaptics 1.9.0-1+b1
amd64Synaptics TouchPad driver for X.Org
server
ii  xserver-xorg-input-wacom
0.34.99.1-1amd64X.Org X server -- Wacom
input driver
ii  xserver-xorg-legacy  2:1.19.3-2
amd64setuid root Xorg server wrapper
ii  xserver-xorg-video-ati   1:7.9.0-1 
amd64X.Org X server -- AMD/ATI display
driver wrapper
ii  xserver-xorg-video-mach646.9.5-1+b2
amd64X.Org X server -- ATI Mach64 display
driver
ii  xserver-xorg-video-r128  6.10.2-1  
amd64X.Org X server -- ATI r128 display
driver
ii  xserver-xorg-video-radeon1:7.9.0-1 
amd64X.Org X server -- AMD/ATI Radeon
display driver

Compiz related:
ii compiz-reloaded 0.8.14-0stretch1 all OpenGL window and compositing manager
ii compiz-reloaded-bcop 0.8.14-0stretch1 all Compiz Reloaded option code
generator
ii compiz-reloaded-core 0.8.14-0stretch1 amd64 OpenGL window and compositing
manager
ii compiz-reloaded-dev 0.8.14-0stretch1 amd64 OpenGL window and compositing
manager - development files
ii compiz-reloaded-gtk 0.8.14-0stretch1 amd64 OpenGL window and compositing
manager - Gtk window decorator
ii compiz-reloaded-mate 0.8.14-0stretch1 amd64 OpenGL window and compositing
manager - MATE window decorator
ii compiz-reloaded-plugins 0.8.14-0stretch1 amd64 OpenGL window and compositing
manager - plugins
ii compiz-reloaded-plugins-experimental 0.8.14-0stretch1 amd64 Compiz Reloaded
plugins - "unsupported" collection
ii compiz-reloaded-plugins-extra 0.8.14-0stretch1 amd64 Compiz Reloaded plugins
- extra collection
ii compiz-reloaded-plugins-main 0.8.14-0stretch1 amd64 Compiz Reloaded plugins
- main collection
ii compizconfig-settings-manager-reloaded 0.8.14-0stretch1 amd64 Compizconfig
Settings Manager
ii emerald 0.8.14-0stretch1 amd64 Decorator for compiz-reloaded
ii libcompizconfig-reloaded-0 0.8.14-0stretch1 

[Bug 102500] [polaris10, vega10][amd-staging-4.12, amd-staging-drm-next] GPU fault detected, somethimes lockup

[bugzilla-daemon]

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

--- Comment #11 from Arek Ruśniak  ---
on mesa side looks like this is it:

214b565bc28bc4419f3eec29ab7bbe34080459fe is the first bad commit
commit 214b565bc28bc4419f3eec29ab7bbe34080459fe
Author: Christian König 
Date:   Tue Aug 29 16:45:46 2017 +0200

winsys/amdgpu: set AMDGPU_GEM_CREATE_VM_ALWAYS_VALID if possible v2

When the kernel supports it set the local flag and
stop adding those BOs to the BO list.

Can probably be optimized much more.

v2: rename new flag to AMDGPU_GEM_CREATE_VM_ALWAYS_VALID

Reviewed-by: Marek Olšák 

:04 04 2e4b2737f37ede2bbdbbe6815fe0fa562177c2b7
3482c86ed92116adff7ab12b2d4de870746a1df6 M  src

-- 
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/tve200: Clean up panel bridging

[Linus Walleij]

This makes use of the drm_simple_display_pipe_attach_bridge()
call and removes the two calls removing the bridge, which were
erroneous: they unregister the bridge which is not what
we want, we just want to unreference it and that is already
handled by the core.

Signed-off-by: Linus Walleij 
---
 drivers/gpu/drm/tve200/tve200_display.c |  3 ---
 drivers/gpu/drm/tve200/tve200_drv.c | 30 +-
 2 files changed, 13 insertions(+), 20 deletions(-)

diff --git a/drivers/gpu/drm/tve200/tve200_display.c 
b/drivers/gpu/drm/tve200/tve200_display.c
index cfdffc15a2ce..fd193377c3c0 100644
--- a/drivers/gpu/drm/tve200/tve200_display.c
+++ b/drivers/gpu/drm/tve200/tve200_display.c
@@ -332,8 +332,5 @@ int tve200_display_init(struct drm_device *drm)
if (ret)
return ret;
 
-   /* We need the encoder to attach the bridge */
-   priv->encoder = >pipe.encoder;
-
return 0;
 }
diff --git a/drivers/gpu/drm/tve200/tve200_drv.c 
b/drivers/gpu/drm/tve200/tve200_drv.c
index c22644692a88..eae38b669f0a 100644
--- a/drivers/gpu/drm/tve200/tve200_drv.c
+++ b/drivers/gpu/drm/tve200/tve200_drv.c
@@ -87,6 +87,14 @@ static int tve200_modeset_init(struct drm_device *dev)
ret = PTR_ERR(bridge);
goto out_bridge;
}
+   } else {
+   /*
+* TODO: when we are using a different bridge than a panel
+* (such as a dumb VGA connector) we need to devise a different
+* method to get the connector out of the bridge.
+*/
+   dev_err(dev->dev, "the bridge is not a panel\n");
+   goto out_bridge;
}
 
ret = tve200_display_init(dev);
@@ -95,21 +103,13 @@ static int tve200_modeset_init(struct drm_device *dev)
goto out_bridge;
}
 
-   if (bridge) {
-   ret = drm_bridge_attach(priv->encoder, bridge, NULL);
-   if (ret)
-   goto out_bridge;
-   }
-
-   /*
-* TODO: when we are using a different bridge than a panel
-* (such as a dumb VGA connector) we need to devise a different
-* method to get the connector out of the bridge.
-*/
-   if (!panel) {
-   dev_err(dev->dev, "the bridge is not a panel\n");
+   ret = drm_simple_display_pipe_attach_bridge(>pipe,
+   bridge);
+   if (ret) {
+   dev_err(dev->dev, "failed to attach bridge\n");
goto out_bridge;
}
+
priv->panel = panel;
priv->connector = panel->connector;
priv->bridge = bridge;
@@ -138,8 +138,6 @@ static int tve200_modeset_init(struct drm_device *dev)
 out_bridge:
if (panel)
drm_panel_bridge_remove(bridge);
-   else
-   drm_bridge_remove(bridge);
drm_mode_config_cleanup(dev);
 finish:
return ret;
@@ -275,8 +273,6 @@ static int tve200_remove(struct platform_device *pdev)
drm_fbdev_cma_fini(priv->fbdev);
if (priv->panel)
drm_panel_bridge_remove(priv->bridge);
-   else
-   drm_bridge_remove(priv->bridge);
drm_mode_config_cleanup(drm);
clk_disable_unprepare(priv->pclk);
drm_dev_unref(drm);
-- 
2.13.5

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

Re: [git pull] drm/i915 fixes for v4.14-rc1

[Dave Airlie]

On 8 September 2017 at 06:03, Rodrigo Vivi  wrote:
> Hi Linus,
>
> Since Dave is on paternity leave we are sending drm/i915 fixes for
> v4.14-rc1 directly to you as he had asked us to do.
>
> The most critical ones are the GPU reset fix for gen2-4 and GVT fix
> for a regression that is blocking gvt init to work on your tree.
>
> The rest is general fixes for patches coming from drm-next.

Acked-by: Dave Airlie 

hopefully be back for a bit next week.

Dave.
___
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

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Depends on||102595


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=102595
[Bug 102595] clpeak
-- 
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 102595] clpeak

[bugzilla-daemon]

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

Jan Vesely  changed:

   What|Removed |Added

 Blocks||99553


Referenced Bugs:

https://bugs.freedesktop.org/show_bug.cgi?id=99553
[Bug 99553] Tracker bug for runnning OpenCL applications on Clover
-- 
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 100387] War Thunder game has visual errors, missing textures

[bugzilla-daemon]

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

--- Comment #10 from aceman  ---
I'd assume "AMD A8-7600 with onchip Radeon R7" uses the separate radeonSI mesa
driver and may not have this problem reported in this bug. Notice the bug is
against R600 driver.

I asked about the radeonSI drive in comment 6 but didn't get a reply. If you
could find out if you are running with it and rendering is fine, I would like
to know.

-- 
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] idr: remove WARN_ON_ONCE() when trying to replace negative ID

[Tejun Heo]

On Wed, Sep 06, 2017 at 04:53:06PM -0700, Eric Biggers wrote:
> From: Eric Biggers 
> 
> IDR only supports non-negative IDs.  There used to be a
> 'WARN_ON_ONCE(id < 0)' in idr_replace(), but it was intentionally
> removed by commit 2e1c9b286765 ("idr: remove WARN_ON_ONCE() on negative
> IDs").  Then it was added back by commit 0a835c4f090a ("Reimplement IDR
> and IDA using the radix tree").  However it seems that adding it back
> was a mistake, given that some users such as drm_gem_handle_delete()
> (DRM_IOCTL_GEM_CLOSE) pass in a value from userspace to idr_replace(),
> allowing the WARN_ON_ONCE to be triggered.  drm_gem_handle_delete()
> actually just wants idr_replace() to return an error code if the ID is
> not allocated, including in the case where the ID is invalid (negative).

Acked-by: Tejun Heo 

Thanks.

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

[Bug 97259] Some gem_shrink subcases return fail instead of pass

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Chris Wilson  ---


*** This bug has been marked as a duplicate of bug 95424 ***

-- 
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 102595] clpeak

[bugzilla-daemon]

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

--- Comment #1 from Benji Wiebe  ---
Created attachment 134057
  --> https://bugs.freedesktop.org/attachment.cgi?id=134057=edit
Stack trace from coredump

-- 
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 102595] clpeak

[bugzilla-daemon]

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

Bug ID: 102595
   Summary: clpeak
   Product: Mesa
   Version: git
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/r600
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: benjiwieb...@gmail.com
QA Contact: dri-devel@lists.freedesktop.org

When I run 'clpeak --global-bandwidth' I get:

[benji@benji-pc clpeak]$ ./clpeak --global-bandwidth

Platform: Clover
  Device: AMD CAYMAN (DRM 2.50.0 / 4.13.0+, LLVM 6.0.0)
Driver version  : 17.3.0-devel (Linux x64)
Compute units   : 12
Clock frequency : 880 MHz

Global memory bandwidth (GBPS)
  float   : radeon: Failed to allocate a buffer:
radeon:size  : 1073741824 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 4
radeon:flags : 4
radeon: Failed to allocate a buffer:
radeon:size  : 1073741824 bytes
radeon:alignment : 4096 bytes
radeon:domains   : 4
radeon:flags : 4
Segmentation fault (core dumped)



And in dmesg:
[55959.960796] clpeak[16731]: segfault at 1c ip 7f3d77e5a42a sp
7fff93152570 error 4 in pipe_r600.so[7f3d77d53000+1c2000]


The clpeak compute-* and kernel-latency tests work fine, and transfer-bandwidth
fails with a (I believe) unrelated error message, seemingly due to me running
Linux-git.

-- 
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 102500] [polaris10, vega10][amd-staging-4.12, amd-staging-drm-next] GPU fault detected, somethimes lockup

[bugzilla-daemon]

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

--- Comment #10 from Arek Ruśniak  ---
additional info:
I try figure out why in my earlier test everything went ok and probably mesa is
the trigger, 

Linux-amd-staging + Mesa-git + LLVM-svn - failure
Linux-amd-staging + Mesa-git + LLVM 4.0.1 - failure
Linux-amd-staging + Mesa 17.1.8 + LLVM 4.0.1 - works ok. 
I try later some bisecting, we will see.

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

[git pull] drm/i915 fixes for v4.14-rc1

[Rodrigo Vivi]

Hi Linus,

Since Dave is on paternity leave we are sending drm/i915 fixes for
v4.14-rc1 directly to you as he had asked us to do.

The most critical ones are the GPU reset fix for gen2-4 and GVT fix
for a regression that is blocking gvt init to work on your tree.

The rest is general fixes for patches coming from drm-next.

Thanks,
Rodrigo.

The following changes since commit 7846b12fe0b5feab5446d892f41b5140c1419109:

  Merge branch 'drm-vmwgfx-next' of 
git://people.freedesktop.org/~syeh/repos_linux into drm-next (2017-08-29 
10:38:14 +1000)

are available in the git repository at:

  git://anongit.freedesktop.org/git/drm-intel 
tags/drm-intel-next-fixes-2017-09-07

for you to fetch changes up to 426ca2cb69cda59f32c251d1f3e111aee8c42814:

  Merge tag 'gvt-fixes-2017-09-06' of https://github.com/01org/gvt-linux into 
drm-intel-next-fixes (2017-09-06 13:34:13 -0700)


drm/i915 fixes for v4.14-rc1


Chris Wilson (6):
  drm/i915: Quietly cancel FBC activation if CRTC is turned off before 
worker
  drm/i915: Recreate vmapping even when the object is pinned
  drm/i915: Always wake the device to flush the GTT
  drm/i915: Ignore duplicate VMA stored within the per-object handle LUT
  drm/i915: Silence sparse by using gfp_t
  drm/i915: Re-enable GTT following a device reset

Jian Jun Chen (1):
  drm/i915/gvt: Remove one duplicated MMIO

Manasi Navare (1):
  drm/i915/edp: Increase T12 panel delay to 900 ms to fix DP AUX CH timeouts

Rodrigo Vivi (1):
  Merge tag 'gvt-fixes-2017-09-06' of https://github.com/01org/gvt-linux 
into drm-intel-next-fixes

Ville Syrjälä (7):
  drm/i915: Treat fb->offsets[] as a raw byte offset instead of a linear 
offset
  drm/i915: Skip fence alignemnt check for the CCS plane
  drm/i915: Make i9xx_load_ycbcr_conversion_matrix() static
  drm/i915: Make i2c lock ops static
  drm/i915: Fix enum pipe vs. enum transcoder for the PCH transcoder
  drm/i915: Add __rcu to radix tree slot pointer
  drm/i915: Annotate user relocs with __user

Zhi Wang (1):
  drm/i915: Fix the missing PPAT cache attributes on CNL

 drivers/gpu/drm/i915/gvt/handlers.c|   1 -
 drivers/gpu/drm/i915/i915_cmd_parser.c |   2 +-
 drivers/gpu/drm/i915/i915_drv.c|  12 +++-
 drivers/gpu/drm/i915/i915_drv.h|   3 +
 drivers/gpu/drm/i915/i915_gem.c|  28 +---
 drivers/gpu/drm/i915/i915_gem_execbuffer.c |   9 ++-
 drivers/gpu/drm/i915/i915_gem_gtt.c|   8 +--
 drivers/gpu/drm/i915/i915_trace.h  |   4 +-
 drivers/gpu/drm/i915/i915_vma.h|   6 ++
 drivers/gpu/drm/i915/intel_color.c |   2 +-
 drivers/gpu/drm/i915/intel_display.c   | 110 +
 drivers/gpu/drm/i915/intel_dp.c|   2 +-
 drivers/gpu/drm/i915/intel_fbc.c   |   4 +-
 drivers/gpu/drm/i915/intel_fifo_underrun.c |  20 +++---
 drivers/gpu/drm/i915/intel_i2c.c   |   2 +-
 drivers/gpu/drm/i915/intel_sdvo.c  |   2 +-
 16 files changed, 130 insertions(+), 85 deletions(-)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 2/2] dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

[Chris Wilson]

Quoting Gustavo Padovan (2017-09-07 20:02:46)
> From: Dominik Behr 
> 
> To avoid hanging userspace components that might have been waiting on the
> active fences of the destroyed timeline we need to signal with error all
> remaining fences on such timeline.
> 
> This restore the default behaviour of the Android sw_sync framework, which
> Android still relies on. It was broken on the dma fence conversion a few
> years ago and never fixed.
> 
> v2: Do not bother with cleanup do the list (Chris Wilson)
> 
> Signed-off-by: Dominik Behr 
> Signed-off-by: Gustavo Padovan 
Reviewed-by: Chris Wilson 

> ---
>  drivers/dma-buf/sw_sync.c | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
> index 38cc7389a6c1..f183eef074fd 100644
> --- a/drivers/dma-buf/sw_sync.c
> +++ b/drivers/dma-buf/sw_sync.c
> @@ -321,9 +321,19 @@ static int sw_sync_debugfs_open(struct inode *inode, 
> struct file *file)
>  static int sw_sync_debugfs_release(struct inode *inode, struct file *file)
>  {
> struct sync_timeline *obj = file->private_data;
> +   struct sync_pt *pt, *next;
>  
> smp_wmb();
>  
> +   spin_lock_irq(>lock);

Given the spinlock, that uncommented barrier (what is it paired with?)
above is redundant.
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/2] selftests: sync: add test that waits on a destroyed timeline

[Chris Wilson]

Quoting Gustavo Padovan (2017-09-07 20:02:45)
> From: Emilio López 
> 
> If a sw_sync_timeline is destroyed the fences associated to it need
> to be signalled. This test checks that.
> 
> Cc: Shuah Khan 
> Cc: linux-kselft...@vger.kernel.org
> Signed-off-by: Emilio López 
> Signed-off-by: Gustavo Padovan 
> ---
>  tools/testing/selftests/sync/sync_test.c |  1 +
>  tools/testing/selftests/sync/sync_wait.c | 58 
> 
>  tools/testing/selftests/sync/synctest.h  |  1 +
>  3 files changed, 60 insertions(+)
> 
> diff --git a/tools/testing/selftests/sync/sync_test.c 
> b/tools/testing/selftests/sync/sync_test.c
> index 62fa666e501a..5d93c9dcc290 100644
> --- a/tools/testing/selftests/sync/sync_test.c
> +++ b/tools/testing/selftests/sync/sync_test.c
> @@ -79,6 +79,7 @@ int main(void)
> err += RUN_TEST(test_fence_one_timeline_merge);
> err += RUN_TEST(test_fence_merge_same_fence);
> err += RUN_TEST(test_fence_multi_timeline_wait);
> +   err += RUN_TEST(test_fence_wait_on_destroyed_timeline);
> err += RUN_TEST(test_stress_two_threads_shared_timeline);
> err += RUN_TEST(test_consumer_stress_multi_producer_single_consumer);
> err += RUN_TEST(test_merge_stress_random_merge);
> diff --git a/tools/testing/selftests/sync/sync_wait.c 
> b/tools/testing/selftests/sync/sync_wait.c
> index d69b752f6550..82ad9f519959 100644
> --- a/tools/testing/selftests/sync/sync_wait.c
> +++ b/tools/testing/selftests/sync/sync_wait.c
> @@ -25,6 +25,7 @@
>   *  OTHER DEALINGS IN THE SOFTWARE.
>   */
>  
> +#include 
>  #include "sync.h"
>  #include "sw_sync.h"
>  #include "synctest.h"
> @@ -89,3 +90,60 @@ int test_fence_multi_timeline_wait(void)
>  
> return 0;
>  }
> +
> +struct fds_test {
> +   int timeline;
> +   int fencesig, fencekill;
> +   int result;
> +};
> +
> +static int test_fence_wait_on_destroyed_timeline_thread(void *d)

A horrible cast later just because you didn't want to use s/int/void */
> +{
> +   struct fds_test *data = d;
> +   int ret;
> +
> +   /* in case of errors */
> +   data->result = 1;
> +
> +   ret = sw_sync_timeline_inc(data->timeline, 100);
> +   ASSERT(ret == 0, "Failure advancing timeline\n");

Just return the error, e.g.  return "err string";
Only allow explosions from the main thread.

> +
> +   ret = sync_wait(data->fencekill, -1);
> +   ASSERT(ret == 1, "Failure waiting on fence\n");
> +
> +   /* no errors occurred */
> +   data->result = 0;
> +   return 0;
> +}
> +
> +int test_fence_wait_on_destroyed_timeline(void)
> +{
> +   struct fds_test data;
> +   pthread_t thread;
> +   int valid;
> +
> +   data.timeline = sw_sync_timeline_create();
> +   valid = sw_sync_timeline_is_valid(data.timeline);
> +   ASSERT(valid, "Failure allocating timeline\n");
> +
> +   data.fencesig = sw_sync_fence_create(data.timeline, "allocFence", 
> 100);
> +   data.fencekill = sw_sync_fence_create(data.timeline, "allocFence", 
> 200);
> +
> +   /* Spawn a thread to wait on a fence when the timeline is killed */
> +   pthread_create(, NULL, (void *(*)(void *))
> +  test_fence_wait_on_destroyed_timeline_thread, );
> +
> +   /* Wait for the thread to spool up */
> +   sync_wait(data.fencesig, -1);
> +
> +   /* Kill the timeline */
> +   sw_sync_timeline_destroy(data.timeline);
> +
> +   /* wait for the thread to clean up */
> +   pthread_join(thread, NULL);

So in case of bug, we block forever. That suggests that you want to use a
timeout, 10s?
-Chris
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[PATCH v2 2/2] dma-buf/sw_sync: force signal all unsignaled fences on dying timeline

[Gustavo Padovan]

From: Dominik Behr 

To avoid hanging userspace components that might have been waiting on the
active fences of the destroyed timeline we need to signal with error all
remaining fences on such timeline.

This restore the default behaviour of the Android sw_sync framework, which
Android still relies on. It was broken on the dma fence conversion a few
years ago and never fixed.

v2: Do not bother with cleanup do the list (Chris Wilson)

Signed-off-by: Dominik Behr 
Signed-off-by: Gustavo Padovan 
---
 drivers/dma-buf/sw_sync.c | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/drivers/dma-buf/sw_sync.c b/drivers/dma-buf/sw_sync.c
index 38cc7389a6c1..f183eef074fd 100644
--- a/drivers/dma-buf/sw_sync.c
+++ b/drivers/dma-buf/sw_sync.c
@@ -321,9 +321,19 @@ static int sw_sync_debugfs_open(struct inode *inode, 
struct file *file)
 static int sw_sync_debugfs_release(struct inode *inode, struct file *file)
 {
struct sync_timeline *obj = file->private_data;
+   struct sync_pt *pt, *next;
 
smp_wmb();
 
+   spin_lock_irq(>lock);
+
+   list_for_each_entry_safe(pt, next, >pt_list, link) {
+   dma_fence_set_error(>base, -ENOENT);
+   dma_fence_signal_locked(>base);
+   }
+
+   spin_unlock_irq(>lock);
+
sync_timeline_put(obj);
return 0;
 }
-- 
2.13.5

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

[PATCH v2 1/2] selftests: sync: add test that waits on a destroyed timeline

[Gustavo Padovan]

From: Emilio López 

If a sw_sync_timeline is destroyed the fences associated to it need
to be signalled. This test checks that.

Cc: Shuah Khan 
Cc: linux-kselft...@vger.kernel.org
Signed-off-by: Emilio López 
Signed-off-by: Gustavo Padovan 
---
 tools/testing/selftests/sync/sync_test.c |  1 +
 tools/testing/selftests/sync/sync_wait.c | 58 
 tools/testing/selftests/sync/synctest.h  |  1 +
 3 files changed, 60 insertions(+)

diff --git a/tools/testing/selftests/sync/sync_test.c 
b/tools/testing/selftests/sync/sync_test.c
index 62fa666e501a..5d93c9dcc290 100644
--- a/tools/testing/selftests/sync/sync_test.c
+++ b/tools/testing/selftests/sync/sync_test.c
@@ -79,6 +79,7 @@ int main(void)
err += RUN_TEST(test_fence_one_timeline_merge);
err += RUN_TEST(test_fence_merge_same_fence);
err += RUN_TEST(test_fence_multi_timeline_wait);
+   err += RUN_TEST(test_fence_wait_on_destroyed_timeline);
err += RUN_TEST(test_stress_two_threads_shared_timeline);
err += RUN_TEST(test_consumer_stress_multi_producer_single_consumer);
err += RUN_TEST(test_merge_stress_random_merge);
diff --git a/tools/testing/selftests/sync/sync_wait.c 
b/tools/testing/selftests/sync/sync_wait.c
index d69b752f6550..82ad9f519959 100644
--- a/tools/testing/selftests/sync/sync_wait.c
+++ b/tools/testing/selftests/sync/sync_wait.c
@@ -25,6 +25,7 @@
  *  OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#include 
 #include "sync.h"
 #include "sw_sync.h"
 #include "synctest.h"
@@ -89,3 +90,60 @@ int test_fence_multi_timeline_wait(void)
 
return 0;
 }
+
+struct fds_test {
+   int timeline;
+   int fencesig, fencekill;
+   int result;
+};
+
+static int test_fence_wait_on_destroyed_timeline_thread(void *d)
+{
+   struct fds_test *data = d;
+   int ret;
+
+   /* in case of errors */
+   data->result = 1;
+
+   ret = sw_sync_timeline_inc(data->timeline, 100);
+   ASSERT(ret == 0, "Failure advancing timeline\n");
+
+   ret = sync_wait(data->fencekill, -1);
+   ASSERT(ret == 1, "Failure waiting on fence\n");
+
+   /* no errors occurred */
+   data->result = 0;
+   return 0;
+}
+
+int test_fence_wait_on_destroyed_timeline(void)
+{
+   struct fds_test data;
+   pthread_t thread;
+   int valid;
+
+   data.timeline = sw_sync_timeline_create();
+   valid = sw_sync_timeline_is_valid(data.timeline);
+   ASSERT(valid, "Failure allocating timeline\n");
+
+   data.fencesig = sw_sync_fence_create(data.timeline, "allocFence", 100);
+   data.fencekill = sw_sync_fence_create(data.timeline, "allocFence", 200);
+
+   /* Spawn a thread to wait on a fence when the timeline is killed */
+   pthread_create(, NULL, (void *(*)(void *))
+  test_fence_wait_on_destroyed_timeline_thread, );
+
+   /* Wait for the thread to spool up */
+   sync_wait(data.fencesig, -1);
+
+   /* Kill the timeline */
+   sw_sync_timeline_destroy(data.timeline);
+
+   /* wait for the thread to clean up */
+   pthread_join(thread, NULL);
+
+   sw_sync_fence_destroy(data.fencesig);
+   sw_sync_fence_destroy(data.fencekill);
+
+   return data.result;
+}
diff --git a/tools/testing/selftests/sync/synctest.h 
b/tools/testing/selftests/sync/synctest.h
index e7d1d57dba7a..1cbe1e3658b3 100644
--- a/tools/testing/selftests/sync/synctest.h
+++ b/tools/testing/selftests/sync/synctest.h
@@ -53,6 +53,7 @@ int test_fence_merge_same_fence(void);
 
 /* Fence wait tests */
 int test_fence_multi_timeline_wait(void);
+int test_fence_wait_on_destroyed_timeline(void);
 
 /* Stress test - parallelism */
 int test_stress_two_threads_shared_timeline(void);
-- 
2.13.5

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

Re: [Intel-gfx] [PATCH v2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Pandiyan, Dhinakaran]

On Thu, 2017-09-07 at 14:04 -0400, Lyude Paul wrote:
> Looks good to me.
> 
> Reviewed-by: Lyude Paul 
> 


Thanks for the review.
-DK


> On Wed, 2017-09-06 at 17:14 -0700, Dhinakaran Pandiyan wrote:
> > The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions
> > allow
> > the source to reqest any node in a mst path or a whole path to be
> > powered down or up. This allows drivers to target a specific sink in
> > the
> > MST topology, an improvement over just power managing the imediate
> > downstream device. Secondly, since the request-reply protocol waits
> > for an
> > ACK, we can be sure that a downstream sink has enough time to respond
> > to a
> > power up/down request.
> > 
> > v2: Fix memory leak (Lyude)
> > Cc: Lyude 
> > Cc: Ville Syrjälä 
> > Cc: Harry Wentland 
> > Signed-off-by: Dhinakaran Pandiyan 
> > ---
> >  drivers/gpu/drm/drm_dp_mst_topology.c | 75
> > +++
> >  include/drm/drm_dp_mst_helper.h   |  2 +
> >  2 files changed, 77 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> > b/drivers/gpu/drm/drm_dp_mst_topology.c
> > index 41b492f99955..9bc5049e7e59 100644
> > --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> > +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> > @@ -294,6 +294,12 @@ static void drm_dp_encode_sideband_req(struct
> > drm_dp_sideband_msg_req_body *req,
> > memcpy([idx], req->u.i2c_write.bytes, req-
> > >u.i2c_write.num_bytes);
> > idx += req->u.i2c_write.num_bytes;
> > break;
> > +
> > +   case DP_POWER_DOWN_PHY:
> > +   case DP_POWER_UP_PHY:
> > +   buf[idx] = (req->u.port_num.port_number & 0xf) << 4;
> > +   idx++;
> > +   break;
> > }
> > raw->cur_len = idx;
> >  }
> > @@ -538,6 +544,22 @@ static bool
> > drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r
> > return false;
> >  }
> >  
> > +
> > +static bool drm_dp_sideband_parse_power_updown_phy_ack(struct
> > drm_dp_sideband_msg_rx *raw,
> > +  struct
> > drm_dp_sideband_msg_reply_body *repmsg)
> > +{
> > +   int idx = 1;
> > +
> > +   repmsg->u.port_number.port_number = (raw->msg[idx] >> 4) &
> > 0xf;
> > +   idx++;
> > +   if (idx > raw->curlen) {
> > +   DRM_DEBUG_KMS("power up/down phy parse length fail
> > %d %d\n",
> > + idx, raw->curlen);
> > +   return false;
> > +   }
> > +   return true;
> > +}
> > +
> >  static bool drm_dp_sideband_parse_reply(struct
> > drm_dp_sideband_msg_rx *raw,
> > struct
> > drm_dp_sideband_msg_reply_body *msg)
> >  {
> > @@ -567,6 +589,9 @@ static bool drm_dp_sideband_parse_reply(struct
> > drm_dp_sideband_msg_rx *raw,
> > return
> > drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
> > case DP_ALLOCATE_PAYLOAD:
> > return
> > drm_dp_sideband_parse_allocate_payload_ack(raw, msg);
> > +   case DP_POWER_DOWN_PHY:
> > +   case DP_POWER_UP_PHY:
> > +   return
> > drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
> > default:
> > DRM_ERROR("Got unknown reply 0x%02x\n", msg-
> > >req_type);
> > return false;
> > @@ -693,6 +718,22 @@ static int build_allocate_payload(struct
> > drm_dp_sideband_msg_tx *msg, int port_n
> > return 0;
> >  }
> >  
> > +static int build_power_updown_phy(struct drm_dp_sideband_msg_tx
> > *msg,
> > + int port_num, bool power_up)
> > +{
> > +   struct drm_dp_sideband_msg_req_body req;
> > +
> > +   if (power_up)
> > +   req.req_type = DP_POWER_UP_PHY;
> > +   else
> > +   req.req_type = DP_POWER_DOWN_PHY;
> > +
> > +   req.u.port_num.port_number = port_num;
> > +   drm_dp_encode_sideband_req(, msg);
> > +   msg->path_msg = true;
> > +   return 0;
> > +}
> > +
> >  static int drm_dp_mst_assign_payload_id(struct
> > drm_dp_mst_topology_mgr *mgr,
> > struct drm_dp_vcpi *vcpi)
> >  {
> > @@ -1724,6 +1765,40 @@ static int drm_dp_payload_send_msg(struct
> > drm_dp_mst_topology_mgr *mgr,
> > return ret;
> >  }
> >  
> > +int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr
> > *mgr,
> > +struct drm_dp_mst_port *port, bool
> > power_up)
> > +{
> > +   struct drm_dp_sideband_msg_tx *txmsg;
> > +   int len, ret;
> > +
> > +   port = drm_dp_get_validated_port_ref(mgr, port);
> > +   if (!port)
> > +   return -EINVAL;
> > +
> > +   txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> > +   if (!txmsg) {
> > +   drm_dp_put_port(port);
> > +   return -ENOMEM;
> > +   }
> > +
> > +   txmsg->dst = port->parent;
> > +   len = build_power_updown_phy(txmsg, port->port_num,
> > power_up);
> > +   drm_dp_queue_down_tx(mgr, txmsg);
> > +
> > +   ret = 

[Bug 102552] Null dereference due to not checking return value of util_format_description

[bugzilla-daemon]

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

Pauk Denis  changed:

   What|Removed |Added

 Attachment #133978|0   |1
is obsolete||

--- Comment #5 from Pauk Denis  ---
Created attachment 134056
  --> https://bugs.freedesktop.org/attachment.cgi?id=134056=edit
Updated version with changes related only to *_supported functions.

I have deleted all changes not realted to *_supported functions.

Change in src/gallium/auxiliary/util/u_format.c:util_format_is_supported -
check that value of format in correct range (

Re: [PATCH 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

[Daniel Vetter]

On Tue, Sep 5, 2017 at 9:43 PM, Eric Anholt  wrote:
> Daniel Vetter  writes:
>
>> On Fri, Sep 01, 2017 at 11:46:29AM +0200, Linus Walleij wrote:
>>> If we cannot find a panel, assume that the output from the
>>> PL111 is connected directly to a "dumb" VGA connector,
>>> so look up the connector from that bridge.
>>>
>>> Signed-off-by: Linus Walleij 
>>> ---
>>> This is how the new API is used in the PL111.
>>> ---
>>>  drivers/gpu/drm/pl111/Kconfig | 1 +
>>>  drivers/gpu/drm/pl111/pl111_drv.c | 3 +++
>>>  2 files changed, 4 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
>>> index e5e2abd66491..82cb3e60ddc8 100644
>>> --- a/drivers/gpu/drm/pl111/Kconfig
>>> +++ b/drivers/gpu/drm/pl111/Kconfig
>>> @@ -8,6 +8,7 @@ config DRM_PL111
>>>  select DRM_GEM_CMA_HELPER
>>>  select DRM_BRIDGE
>>>  select DRM_PANEL_BRIDGE
>>> +select DRM_DUMB_VGA_DAC
>>>  select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
>>>  help
>>>Choose this option for DRM support for the PL111 CLCD controller.
>>> diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
>>> b/drivers/gpu/drm/pl111/pl111_drv.c
>>> index f5bc6f160e60..6db423bbd84e 100644
>>> --- a/drivers/gpu/drm/pl111/pl111_drv.c
>>> +++ b/drivers/gpu/drm/pl111/pl111_drv.c
>>> @@ -67,6 +67,7 @@
>>>  #include 
>>>  #include 
>>>  #include 
>>> +#include 
>>>
>>>  #include "pl111_drm.h"
>>>  #include "pl111_versatile.h"
>>> @@ -128,6 +129,8 @@ static int pl111_modeset_init(struct drm_device *dev)
>>>  if (panel) {
>>>  priv->panel = panel;
>>>  priv->connector = panel->connector;
>>> +} else {
>>> +priv->connector = drm_dumb_vga_get_connector(bridge);
>>
>> Why do you need to set this? The only code I could find tries to set
>> polarity values from bus_flags, and for VGA I'd assume you want to instead
>> key this off the mode?
>>
>> Wrt the more general problem: They way we solve this in the i915 atomic
>> framework is that the various ->fixup calls fill out relevant fields in
>> the drm_crtc_state. I guess we could add an ->atomic_check to bridges, add
>> a bus_flags to drm_crtc_state (or maybe just let everyone patch up
>> adjusted_mode->flags) instead?
>
> It seems to me like the bus_flags/format should be specific to each link
> in the display output chain, rather than global to it.

Yeah that might be the even more general option, to have a
drm_bridge_state for this stuff. Thanks to the driver private state
support recently added you can add state pointers for any void * (and
with a bit of glue even set up type-safe duplicate/get/for_each
wrappers). But I'm not clear whether we really need that much
generality or not. Currently it's used for the intel shared dpll stuff
and the dp mst state, in case someone needs to dig for examples.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

[Daniel Vetter]

On Thu, Sep 7, 2017 at 6:12 PM, Noralf Trønnes  wrote:
>
> Den 07.09.2017 14.59, skrev Linus Walleij:
>>
>> On Mon, Sep 4, 2017 at 9:43 AM, Daniel Vetter  wrote:
>>>
>>> On Fri, Sep 01, 2017 at 11:46:29AM +0200, Linus Walleij wrote:

 If we cannot find a panel, assume that the output from the
 PL111 is connected directly to a "dumb" VGA connector,
 so look up the connector from that bridge.

 Signed-off-by: Linus Walleij 
if (panel) {
priv->panel = panel;
priv->connector = panel->connector;
 + } else {
 + priv->connector = drm_dumb_vga_get_connector(bridge);
>>>
>>> Why do you need to set this?
>>
>> Essentially because drm_simple_display_pipe_init() require that you
>> specify a connector in the last argument, so I have to get it from
>> somewhere.
>
>
> It's optional particularly for the bridge case. From docs:
>
>  * If a connector is supplied, the pipe will be coupled with the provided
>  * connector. You may supply a NULL connector when using drm bridges, that
>  * handle connectors themselves (see
> drm_simple_display_pipe_attach_bridge()).

Yup, this was the flip side of the work to make bridges useful for the
simple pipe helpers. The other one is the helper to set up the bridge
I mentioned earlier in this thread.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

[Bug 102417] [IGT][HSW/APL/GLK] gem_exec_fence subtests fail

[bugzilla-daemon]

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

Chris Wilson  changed:

   What|Removed |Added

   Assignee|intel-gfx-bugs@lists.freede |dri-devel@lists.freedesktop
   |sktop.org   |.org
 QA Contact|intel-gfx-bugs@lists.freede |
   |sktop.org   |
  Component|DRM/Intel   |IGT

-- 
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 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

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

--- Comment #15 from dolohow (dolo...@outlook.com) ---
Sure, it's a Linus tree


> Revert "drm/amdgpu: fix vblank_time when displays are off"
> 
> This reverts commit 2dc1889.
> 
> Fixes a suspend and resume regression.
> 
> bug: https://bugzilla.kernel.org/show_bug.cgi?id=196615
> Signed-off-by: Alex Deucher 
> Signed-off-by: Greg Kroah-Hartman 

-- 
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 v2] drm/dp/mst: Sideband message transaction to power up/down nodes

[Lyude Paul]

Looks good to me.

Reviewed-by: Lyude Paul 

On Wed, 2017-09-06 at 17:14 -0700, Dhinakaran Pandiyan wrote:
> The POWER_DOWN_PHY and POWER_UP_PHY sideband message transactions
> allow
> the source to reqest any node in a mst path or a whole path to be
> powered down or up. This allows drivers to target a specific sink in
> the
> MST topology, an improvement over just power managing the imediate
> downstream device. Secondly, since the request-reply protocol waits
> for an
> ACK, we can be sure that a downstream sink has enough time to respond
> to a
> power up/down request.
> 
> v2: Fix memory leak (Lyude)
> Cc: Lyude 
> Cc: Ville Syrjälä 
> Cc: Harry Wentland 
> Signed-off-by: Dhinakaran Pandiyan 
> ---
>  drivers/gpu/drm/drm_dp_mst_topology.c | 75
> +++
>  include/drm/drm_dp_mst_helper.h   |  2 +
>  2 files changed, 77 insertions(+)
> 
> diff --git a/drivers/gpu/drm/drm_dp_mst_topology.c
> b/drivers/gpu/drm/drm_dp_mst_topology.c
> index 41b492f99955..9bc5049e7e59 100644
> --- a/drivers/gpu/drm/drm_dp_mst_topology.c
> +++ b/drivers/gpu/drm/drm_dp_mst_topology.c
> @@ -294,6 +294,12 @@ static void drm_dp_encode_sideband_req(struct
> drm_dp_sideband_msg_req_body *req,
>   memcpy([idx], req->u.i2c_write.bytes, req-
> >u.i2c_write.num_bytes);
>   idx += req->u.i2c_write.num_bytes;
>   break;
> +
> + case DP_POWER_DOWN_PHY:
> + case DP_POWER_UP_PHY:
> + buf[idx] = (req->u.port_num.port_number & 0xf) << 4;
> + idx++;
> + break;
>   }
>   raw->cur_len = idx;
>  }
> @@ -538,6 +544,22 @@ static bool
> drm_dp_sideband_parse_query_payload_ack(struct drm_dp_sideband_msg_r
>   return false;
>  }
>  
> +
> +static bool drm_dp_sideband_parse_power_updown_phy_ack(struct
> drm_dp_sideband_msg_rx *raw,
> +struct
> drm_dp_sideband_msg_reply_body *repmsg)
> +{
> + int idx = 1;
> +
> + repmsg->u.port_number.port_number = (raw->msg[idx] >> 4) &
> 0xf;
> + idx++;
> + if (idx > raw->curlen) {
> + DRM_DEBUG_KMS("power up/down phy parse length fail
> %d %d\n",
> +   idx, raw->curlen);
> + return false;
> + }
> + return true;
> +}
> +
>  static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
>   struct
> drm_dp_sideband_msg_reply_body *msg)
>  {
> @@ -567,6 +589,9 @@ static bool drm_dp_sideband_parse_reply(struct
> drm_dp_sideband_msg_rx *raw,
>   return
> drm_dp_sideband_parse_enum_path_resources_ack(raw, msg);
>   case DP_ALLOCATE_PAYLOAD:
>   return
> drm_dp_sideband_parse_allocate_payload_ack(raw, msg);
> + case DP_POWER_DOWN_PHY:
> + case DP_POWER_UP_PHY:
> + return
> drm_dp_sideband_parse_power_updown_phy_ack(raw, msg);
>   default:
>   DRM_ERROR("Got unknown reply 0x%02x\n", msg-
> >req_type);
>   return false;
> @@ -693,6 +718,22 @@ static int build_allocate_payload(struct
> drm_dp_sideband_msg_tx *msg, int port_n
>   return 0;
>  }
>  
> +static int build_power_updown_phy(struct drm_dp_sideband_msg_tx
> *msg,
> +   int port_num, bool power_up)
> +{
> + struct drm_dp_sideband_msg_req_body req;
> +
> + if (power_up)
> + req.req_type = DP_POWER_UP_PHY;
> + else
> + req.req_type = DP_POWER_DOWN_PHY;
> +
> + req.u.port_num.port_number = port_num;
> + drm_dp_encode_sideband_req(, msg);
> + msg->path_msg = true;
> + return 0;
> +}
> +
>  static int drm_dp_mst_assign_payload_id(struct
> drm_dp_mst_topology_mgr *mgr,
>   struct drm_dp_vcpi *vcpi)
>  {
> @@ -1724,6 +1765,40 @@ static int drm_dp_payload_send_msg(struct
> drm_dp_mst_topology_mgr *mgr,
>   return ret;
>  }
>  
> +int drm_dp_send_power_updown_phy(struct drm_dp_mst_topology_mgr
> *mgr,
> +  struct drm_dp_mst_port *port, bool
> power_up)
> +{
> + struct drm_dp_sideband_msg_tx *txmsg;
> + int len, ret;
> +
> + port = drm_dp_get_validated_port_ref(mgr, port);
> + if (!port)
> + return -EINVAL;
> +
> + txmsg = kzalloc(sizeof(*txmsg), GFP_KERNEL);
> + if (!txmsg) {
> + drm_dp_put_port(port);
> + return -ENOMEM;
> + }
> +
> + txmsg->dst = port->parent;
> + len = build_power_updown_phy(txmsg, port->port_num,
> power_up);
> + drm_dp_queue_down_tx(mgr, txmsg);
> +
> + ret = drm_dp_mst_wait_tx_reply(port->parent, txmsg);
> + if (ret > 0) {
> + if (txmsg->reply.reply_type == 1)
> + ret = -EINVAL;
> + else
> + ret = 0;
> + }
> + kfree(txmsg);
> + drm_dp_put_port(port);
> +
> +   

[Bug 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

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

Harry Wentland (harry.wentl...@amd.com) changed:

   What|Removed |Added

 CC||harry.wentl...@amd.com

--- Comment #14 from Harry Wentland (harry.wentl...@amd.com) ---
(In reply to dolohow from comment #13)
> After I updated my kernel from 4.12.9 to 4.12.10 I started experiencing
> screen flickering on my RX 480.  I did bisecting and turns out that this
> commit dbe5b2d70cfdc3e1df1ceb3f715c6ef7d17fc566 makes my screen flickers.

Do you mind adding the commit subject and description in addition the the sha?
Which git tree is this from? I'm having trouble finding it.

-- 
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 196615] amdgpu - resume from suspend is no longer working on rx480

[bugzilla-daemon]

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

dolohow (dolo...@outlook.com) changed:

   What|Removed |Added

 CC||dolo...@outlook.com

--- Comment #13 from dolohow (dolo...@outlook.com) ---
After I updated my kernel from 4.12.9 to 4.12.10 I started experiencing screen
flickering on my RX 480.  I did bisecting and turns out that this commit
dbe5b2d70cfdc3e1df1ceb3f715c6ef7d17fc566 makes my screen flickers.

-- 
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: linux-firmware: add Qualcomm Adreno a3xx firmware

[Kyle McMartin]

On Wed, Sep 06, 2017 at 04:36:01PM +0200, Nicolas Dechesne wrote:
> Hi,
> 
> This pull request adds firmware for adreno a3xx GPU found for example
> on the APQ8016 chipset, used on the Dragonboard 410c.
> 
> The following changes since commit 9d40a17beaf271e6ad47a5e714a296100eef4692:
> 
>   rtlwifi: rtl8822be: Add firmware for new driver/device (2017-08-29
> 11:41:47 -0700)
> 
> are available in the git repository at:
> 
>   https://github.com/ndechesne/linux-firmware.git adreno
> 
> for you to fetch changes up to 9a0a0548a7bb02d052318ed8f5333005773878f2:

Pulled. Thanks Nicolas.

regards, Kyle

> 
>   qcom: add firmware files for Adreno A3xx (2017-09-05 22:07:42 +0200)
> 
> 
> Nicolas Dechesne (1):
>   qcom: add firmware files for Adreno A3xx
> 
>  WHENCE   |  14 ++
>  a300_pfp.fw  |   1 +
>  a300_pm4.fw  |   1 +

;-( bummer. oh well.

>  qcom/a300_pfp.fw | Bin 0 -> 1156 bytes
>  qcom/a300_pm4.fw | Bin 0 -> 9220 bytes

appreciate this, though. Thanks!

>  5 files changed, 16 insertions(+)
>  create mode 12 a300_pfp.fw
>  create mode 12 a300_pm4.fw
>  create mode 100644 qcom/a300_pfp.fw
>  create mode 100644 qcom/a300_pm4.fw
> 
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 3/7 v3] drm/pl111: Replace custom connector with panel bridge

[Eric Anholt]

Linus Walleij  writes:

> This replaces the custom connector in the PL111 with the
> panel bridge helper.
>
> This works nicely for all standard panels, but since there
> are several PL11x-based systems that will need to use the dumb
> VGA connector bridge we use drm_of_find_panel_or_bridge()
> and make some headroom for dealing with bridges that are
> not panels as well, and drop a TODO in the code.
>
> Signed-off-by: Linus Walleij 

> +out_bridge:
> + if (panel)
> + drm_panel_bridge_remove(bridge);
> + else
> + drm_bridge_remove(bridge);

Drop the "else drm_bridge_remove(bridge)" here and in the hunk below --
that unregisters the bridge driver entirely, rather than unreferencing
it from your driver (there's no refcounting to be done).

With that change,

Reviewed-by: Eric Anholt 

>  out_config:
>   drm_mode_config_cleanup(dev);
>  finish:
> @@ -236,6 +250,10 @@ static int pl111_amba_remove(struct amba_device 
> *amba_dev)
>   drm_dev_unregister(drm);
>   if (priv->fbdev)
>   drm_fbdev_cma_fini(priv->fbdev);
> + if (priv->panel)
> + drm_panel_bridge_remove(priv->bridge);
> + else
> + drm_bridge_remove(priv->bridge);
>   drm_mode_config_cleanup(drm);
>   drm_dev_unref(drm);
>  
> -- 
> 2.13.5


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

[Bug 102543] [BAT][HSW] igt@tools_test@tools_test - Unclaimed read from register 0x[4c]400c

[bugzilla-daemon]

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

--- Comment #5 from Chris Wilson  ---
commit d7a133d886b45651e36e7065998b1413d379ac1f
Author: Chris Wilson 
Date:   Thu Sep 7 14:44:41 2017 +0100

drm/i915: Disable mmio debugging during user access

If the user bypasses i915 and accesses mmio directly, that easily
confuses our automatic mmio debugging (any error we then detect is
likely to be as a result of the user). Since we expect userspace to open
debugfs/i915_forcewake_user if i915.ko is loaded and they want mmio
access, that makes the opportune time to disable our debugging for
duration of the bypass.

v2: Move the fiddling of uncore internals to uncore.c

The issue in intel_reg_dump is still there, just not triggering a kernel
warning.

-- 
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 97820] [BDW BYT SKL HSW IVB]Regression] [GPU Hang] with gem_reset_stats ban- and reset-stats- subtests

[bugzilla-daemon]

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

--- Comment #10 from Hector Velazquez 
 ---
The following tests FAIL on SKL 

Tests List:

igt@gem_reset_stats@reset-stats-bsd
igt@gem_reset_stats@reset-stats-default
igt@gem_reset_stats@reset-stats-render


==
Output Sample
==
...
(gem_reset_stats:3067) drmtest-DEBUG: Test requirement passed: !(fd<0)
(gem_reset_stats:3067) igt-debugfs-DEBUG: Opening debugfs directory
'/sys/kernel/debug/dri/0'
(gem_reset_stats:3067) CRITICAL: Test assertion failure function test_rs, file
gem_reset_stats.c:229:
(gem_reset_stats:3067) CRITICAL: Failed assertion: noop(fd[i], 0, e) > 0
(gem_reset_stats:3067) igt-core-INFO: Stack trace:
(gem_reset_stats:3067) igt-core-INFO:   #0 [__igt_fail_assert+0x101]
(gem_reset_stats:3067) igt-core-INFO:   #1 [test_rs.constprop.8+0x206]
(gem_reset_stats:3067) igt-core-INFO:   #2 [__real_main773+0x10b]
(gem_reset_stats:3067) igt-core-INFO:   #3 [main+0x23]
(gem_reset_stats:3067) igt-core-INFO:   #4 [__libc_start_main+0xf1]
(gem_reset_stats:3067) igt-core-INFO:   #5 [_start+0x29]
(gem_reset_stats:3067) igt-core-INFO:   #6 [+0x29]
  END  
Stack trace:
  #0 [__igt_fail_assert+0x101]
  #1 [test_rs.constprop.8+0x206]
  #2 [__real_main773+0x10b]
  #3 [main+0x23]
  #4 [__libc_start_main+0xf1]
  #5 [_start+0x29]
  #6 [+0x29]
...

This is my configuration:

==
Graphic stack
==

Component: drm
tag: libdrm-2.4.81-53-gd55d080
commit: d55d0804f9e37637d7510f38f97e07a50c6b7baa

Component: cairo
tag: 1.15.6-30-gc29db4f
commit: c29db4f0de52727406a8b62f4da9a382084b5a79

Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-244-g4a1c8da
commit: 4a1c8daff2005e2cbfe980d63bc0a0fb09cb017d

Component: piglit
tag: piglit-v1
commit: dab15137044c34023b1a843e72e781b03b17548b

==
 Software
==
kernel version  : 4.13.0-drm-tip-ww36-commit-7a827ab+
hostname: gfx-desktop
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 5.6
bios release date   : 09/29/2016
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
libdrm  : 2.4.83
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-234-g490b386
intel-gpu-tools (commit): 490b386

==
 Hardware
==
platform   : Skylake Canyon
motherboard id : NUC6i7KYB
form factor: Desktop
cpu family : Core i7
cpu family id  : 6
cpu information: Intel(R) Core(TM) i7-6770HQ CPU @ 2.60GHz
gpu card   : Intel Corporation Iris Pro Graphics 580 (rev 09)
(prog-if 00 [VGA controller])
memory ram : 31.31 GB
max memory ram : 32 GB
cpu thread : 8
cpu core   : 4
cpu model  : 94
cpu stepping   : 3
socket : Other
signature  : Type 0, Family 6, Model 94, Stepping 3
hard drive : 223GiB (240GB)
current cd clock frequency : 337500 kHz
maximum cd clock frequency : 675000 kHz
displays connected : DP-1 DP-3

==
 Firmware
==
dmc fw loaded : yes
dmc version   : 1.26
guc fw loaded : SUCCESS
guc version wanted: 6.1
guc version found : 6.1
huc fw loaded : yes

==
 kernel parameters
==
quiet splash drm.debug=0x1e i915.enable_guc_submission=2
i915.enable_guc_loading=2 i915.alpha_support=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

Re: [PATCH 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

[Noralf Trønnes]

Den 07.09.2017 14.59, skrev Linus Walleij:

On Mon, Sep 4, 2017 at 9:43 AM, Daniel Vetter  wrote:

On Fri, Sep 01, 2017 at 11:46:29AM +0200, Linus Walleij wrote:

If we cannot find a panel, assume that the output from the
PL111 is connected directly to a "dumb" VGA connector,
so look up the connector from that bridge.

Signed-off-by: Linus Walleij 
   if (panel) {
   priv->panel = panel;
   priv->connector = panel->connector;
+ } else {
+ priv->connector = drm_dumb_vga_get_connector(bridge);

Why do you need to set this?

Essentially because drm_simple_display_pipe_init() require that you
specify a connector in the last argument, so I have to get it from
somewhere.


It's optional particularly for the bridge case. From docs:

 * If a connector is supplied, the pipe will be coupled with the provided
 * connector. You may supply a NULL connector when using drm bridges, that
 * handle connectors themselves (see 
drm_simple_display_pipe_attach_bridge()).


Noralf.


The only code I could find tries to set
polarity values from bus_flags, and for VGA I'd assume you want to instead
key this off the mode?

The usecase is that either a panel or a dumb VGA bridge is used
(not both, luckily).

On *some* dumb VGA bridges, the polarity of the clock signal is
inverted, i.e. it expects data to be clocked out on the negative
edge rather than the positive edge. See:
https://lists.freedesktop.org/archives/dri-devel/2017-September/151603.html

And the PL111 can control this in software, that is why it is inspecting
the flags on the connector to figure out when to clock things out.

It seems logical to check the connector to figure out what clock edge
it wants?


Wrt the more general problem: They way we solve this in the i915 atomic
framework is that the various ->fixup calls fill out relevant fields in
the drm_crtc_state. I guess we could add an ->atomic_check to bridges, add
a bus_flags to drm_crtc_state (or maybe just let everyone patch up
adjusted_mode->flags) instead?

Not quite following... I do need fixups to mask some modes off the
PL111 but that would be on the driver side.

Yours,
Linus Walleij
___
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

[Bug 100596] [BXT/GLK/KBL/BDW/IVB/HSW/BSW/BYT] gem_userptr_blits/map-fixed-invalidate* showing bad address

[bugzilla-daemon]

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

--- Comment #18 from Hector Velazquez 
 ---
Sorry, this test was not executed and is not part of this bug... :
igt@kms_sysfs_edid_timing

-- 
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 100596] [BXT/GLK/KBL/BDW/IVB/HSW/BSW/BYT] gem_userptr_blits/map-fixed-invalidate* showing bad address

[bugzilla-daemon]

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

Hector Velazquez  changed:

   What|Removed |Added

Summary|[BXT/GLK/SKL/KBL/BDW/IVB/HS |[BXT/GLK/KBL/BDW/IVB/HSW/BS
   |W/BSW/BYT]  |W/BYT]
   |gem_userptr_blits/map-fixed |gem_userptr_blits/map-fixed
   |-invalidate* showing bad|-invalidate* showing bad
   |address |address

-- 
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 100596] [BXT/GLK/SKL/KBL/BDW/IVB/HSW/BSW/BYT] gem_userptr_blits/map-fixed-invalidate* showing bad address

[bugzilla-daemon]

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

--- Comment #17 from Hector Velazquez 
 ---
The following tests PASS on SKL 

Tests List:

igt@kms_sysfs_edid_timing

igt@gem_userptr_blits@map-fixed-invalidate-busy-gup
igt@gem_userptr_blits@map-fixed-invalidate-gup
igt@gem_userptr_blits@map-fixed-invalidate-overlap-busy-gup
igt@gem_userptr_blits@map-fixed-invalidate-overlap-gup


==
Output Sample
==
...
IGT-Version: 1.19-g4a1c8da (x86_64) (Linux: 4.13.0-drm-tip-ww36-commit-00f9b49+
x86_64)
(gem_userptr_blits:1522) drmtest-DEBUG: Test requirement passed: !(fd<0)
(gem_userptr_blits:1522) igt-debugfs-DEBUG: Opening debugfs directory
'/sys/kernel/debug/dri/0'
(gem_userptr_blits:1522) drmtest-DEBUG: Test requirement passed:
is_i915_device(fd) && has_known_intel_chipset(fd)
(gem_userptr_blits:1522) ioctl-wrappers-DEBUG: Test requirement passed: err ==
0
Aperture size is 268435456 MiB
Total RAM is 15936 MiB
Not enough RAM to run test, reducing buffer count.
(gem_userptr_blits:1522) DEBUG: Test requirement passed: has_userptr(fd)
(gem_userptr_blits:1522) DEBUG: Test requirement passed: has_userptr(fd)
(gem_userptr_blits:1522) DEBUG: Test requirement passed: has_userptr(fd)
(gem_userptr_blits:1522) igt-core-DEBUG: Starting subtest:
map-fixed-invalidate-busy-gup
Subtest map-fixed-invalidate-busy-gup: SUCCESS (0.537s)
(gem_userptr_blits:1522) igt-core-DEBUG: Exiting with status code 0
...

This is my configuration:

==
Graphic stack
==

Component: drm
tag: libdrm-2.4.81-53-gd55d080
commit: d55d0804f9e37637d7510f38f97e07a50c6b7baa

Component: cairo
tag: 1.15.6-30-gc29db4f
commit: c29db4f0de52727406a8b62f4da9a382084b5a79

Component: intel-gpu-tools
tag: intel-gpu-tools-1.19-244-g4a1c8da
commit: 4a1c8daff2005e2cbfe980d63bc0a0fb09cb017d

Component: piglit
tag: piglit-v1
commit: dab15137044c34023b1a843e72e781b03b17548b



==
 Software
==
kernel version  : 4.13.0-drm-tip-ww36-commit-00f9b49+
hostname: SKL-2-NUC6i5SYB
architecture: x86_64
os version  : Ubuntu 16.10
os codename : yakkety
kernel driver   : i915
bios revision   : 5.6
bios release date   : 05/27/2016
hardware acceleration   : disabled
swap partition  : enabled on (/dev/sda3)

==
Graphic drivers
==
libdrm  : 2.4.83
cairo   : 1.15.9
intel-gpu-tools (tag)   : intel-gpu-tools-1.19-244-g4a1c8da
intel-gpu-tools (commit): 4a1c8da

==
 Hardware
==
platform   : Skylake-Nuc
motherboard id : NUC6i5SYB
form factor: Desktop
cpu family : Core i5
cpu family id  : 6
cpu information: Intel(R) Core(TM) i5-6260U CPU @ 1.80GHz
gpu card   : Intel Corporation Iris Graphics 540 (rev 0a)
(prog-if 00 [VGA controller])
memory ram : 15.56 GB
max memory ram : 32 GB
cpu thread : 4
cpu core   : 2
cpu model  : 78
cpu stepping   : 3
socket : None
signature  : Type 0, Family 6, Model 78, Stepping 3
hard drive : 223GiB (240GB)
current cd clock frequency : 337500 kHz
maximum cd clock frequency : 675000 kHz
displays connected : HDMI-A-1 DP-1

==
 Firmware
==
dmc fw loaded : yes
dmc version   : 1.26
guc fw loaded : SUCCESS
guc version wanted: 6.1
guc version found : 6.1

==
 kernel parameters
==
quiet drm.debug=0x1e pci=pcie_bus_safe intel_iommu=igfx_off auto panic=1
i915.alpha_support=1 i915.enable_guc_loading=2 i915.enable_guc_submission=2
nmi_watchdog=panic resume=/dev/sda3 fastboot


Since the test is PASS, will removed from the list

-- 
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 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

--- Comment #19 from Thomas Hellström  ---
What happens if you run in windowed mode + vsync?

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

Re: [PATCH 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

[Linus Walleij]

On Mon, Sep 4, 2017 at 11:51 AM, Laurent Pinchart
 wrote:
> On Monday, 4 September 2017 10:43:55 EEST Daniel Vetter wrote:
>> On Fri, Sep 01, 2017 at 11:46:29AM +0200, Linus Walleij wrote:

>> Wrt the more general problem: They way we solve this in the i915 atomic
>> framework is that the various ->fixup calls fill out relevant fields in
>> the drm_crtc_state. I guess we could add an ->atomic_check to bridges, add
>> a bus_flags to drm_crtc_state (or maybe just let everyone patch up
>> adjusted_mode->flags) instead?
>
> Furthermore, if we needed to have access to the connector in the display
> controller driver, this would call for creating the connector there, not in
> the bridge driver. I've advocated this for a long time, and still haven't
> given up all hopes of fixing it.

Hm as it is I am trying to adopt to circumstances, so I was just asked
to replace the custom connector with the generic panel bridge.
(bridge/panel.c)

Then we get the connector out of the generic panel bridge by just
dereferencing panel->connector, this is what the PL111 driver
is already doing for panels since its inception.

Maybe that is wrong, I don't know :/

But like Eric says, the core problem is that the display driver
say enable function needs to know the flags of what it should
output. This driver looks at

connector->display_info.bus_flags & DRM_BUS_FLAG_DE_LOW
connector->display_info.bus_flags & DRM_BUS_FLAG_PIXDATA_NEGEDGE

So the bus flags really need to be available somehow.
I am doing it by keeping a local reference to the connector
in the driver state container.

I tried to dereference the connector from from the pipe at one
point, passing NULL to  but it didn't work out, it seems like
struct drm_simple_display_pipe_funcs
.enable() is called before attaching the connector or something
but I guess I should look closer.

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

Re: [PATCH 2/2] RFC: drm/pl111: Support using the VGA bridge as fallback

[Linus Walleij]

On Mon, Sep 4, 2017 at 9:43 AM, Daniel Vetter  wrote:
> On Fri, Sep 01, 2017 at 11:46:29AM +0200, Linus Walleij wrote:
>> If we cannot find a panel, assume that the output from the
>> PL111 is connected directly to a "dumb" VGA connector,
>> so look up the connector from that bridge.
>>
>> Signed-off-by: Linus Walleij 

>>   if (panel) {
>>   priv->panel = panel;
>>   priv->connector = panel->connector;
>> + } else {
>> + priv->connector = drm_dumb_vga_get_connector(bridge);
>
> Why do you need to set this?

Essentially because drm_simple_display_pipe_init() require that you
specify a connector in the last argument, so I have to get it from
somewhere.

> The only code I could find tries to set
> polarity values from bus_flags, and for VGA I'd assume you want to instead
> key this off the mode?

The usecase is that either a panel or a dumb VGA bridge is used
(not both, luckily).

On *some* dumb VGA bridges, the polarity of the clock signal is
inverted, i.e. it expects data to be clocked out on the negative
edge rather than the positive edge. See:
https://lists.freedesktop.org/archives/dri-devel/2017-September/151603.html

And the PL111 can control this in software, that is why it is inspecting
the flags on the connector to figure out when to clock things out.

It seems logical to check the connector to figure out what clock edge
it wants?

> Wrt the more general problem: They way we solve this in the i915 atomic
> framework is that the various ->fixup calls fill out relevant fields in
> the drm_crtc_state. I guess we could add an ->atomic_check to bridges, add
> a bus_flags to drm_crtc_state (or maybe just let everyone patch up
> adjusted_mode->flags) instead?

Not quite following... I do need fixups to mask some modes off the
PL111 but that would be on the driver side.

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

[PATCH 7/7 v3] drm/pl111: Add handling of Versatile platforms

[Linus Walleij]

The ARM reference designs in the Versatile family: Integrator,
Versatile and RealView can make use of the new DRM driver as well.
We just need to create a bit of platform-specific code for them
that we isolate to its own file.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Rebase on the other patches.
- Drop pad note from DOC section.
---
 drivers/gpu/drm/pl111/Makefile  |   1 +
 drivers/gpu/drm/pl111/pl111_display.c   |   7 -
 drivers/gpu/drm/pl111/pl111_drv.c   |   8 +-
 drivers/gpu/drm/pl111/pl111_versatile.c | 270 
 drivers/gpu/drm/pl111/pl111_versatile.h |   9 ++
 5 files changed, 285 insertions(+), 10 deletions(-)
 create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.c
 create mode 100644 drivers/gpu/drm/pl111/pl111_versatile.h

diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index c5f8f9684848..fce1453a93e1 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -1,4 +1,5 @@
 pl111_drm-y += pl111_display.o \
+   pl111_versatile.o \
pl111_drv.o
 
 pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index 68847a074331..cdb042951de0 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -450,13 +450,6 @@ int pl111_display_init(struct drm_device *drm)
}
of_node_put(endpoint);
 
-   if (tft_r0b0g0[0] != 0 ||
-   tft_r0b0g0[1] != 8 ||
-   tft_r0b0g0[2] != 16) {
-   dev_err(dev, "arm,pl11x,tft-r0g0b0-pads != [0,8,16] not yet 
supported\n");
-   return -EINVAL;
-   }
-
ret = pl111_init_clock_divider(drm);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/pl111/pl111_drv.c 
b/drivers/gpu/drm/pl111/pl111_drv.c
index 903e948afea1..b7dcf155bd0f 100644
--- a/drivers/gpu/drm/pl111/pl111_drv.c
+++ b/drivers/gpu/drm/pl111/pl111_drv.c
@@ -41,9 +41,6 @@
  * - Fix race between setting plane base address and getting IRQ for
  *   vsync firing the pageflip completion.
  *
- * - Expose the correct set of formats we can support based on the
- *   "arm,pl11x,tft-r0g0b0-pads" DT property.
- *
  * - Use the "max-memory-bandwidth" DT property to filter the
  *   supported formats.
  *
@@ -73,6 +70,7 @@
 #include 
 
 #include "pl111_drm.h"
+#include "pl111_versatile.h"
 
 #define DRIVER_DESC  "DRM module for PL111"
 
@@ -255,6 +253,10 @@ static int pl111_amba_probe(struct amba_device *amba_dev,
return ret;
}
 
+   ret = pl111_versatile_init(dev, priv);
+   if (ret)
+   goto dev_unref;
+
ret = pl111_modeset_init(drm);
if (ret != 0)
goto dev_unref;
diff --git a/drivers/gpu/drm/pl111/pl111_versatile.c 
b/drivers/gpu/drm/pl111/pl111_versatile.c
new file mode 100644
index ..97d4af6925a3
--- /dev/null
+++ b/drivers/gpu/drm/pl111/pl111_versatile.c
@@ -0,0 +1,270 @@
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "pl111_versatile.h"
+#include "pl111_drm.h"
+
+static struct regmap *versatile_syscon_map;
+
+/*
+ * We detect the different syscon types from the compatible strings.
+ */
+enum versatile_clcd {
+   INTEGRATOR_CLCD_CM,
+   VERSATILE_CLCD,
+   REALVIEW_CLCD_EB,
+   REALVIEW_CLCD_PB1176,
+   REALVIEW_CLCD_PB11MP,
+   REALVIEW_CLCD_PBA8,
+   REALVIEW_CLCD_PBX,
+};
+
+static const struct of_device_id versatile_clcd_of_match[] = {
+   {
+   .compatible = "arm,core-module-integrator",
+   .data = (void *)INTEGRATOR_CLCD_CM,
+   },
+   {
+   .compatible = "arm,versatile-sysreg",
+   .data = (void *)VERSATILE_CLCD,
+   },
+   {
+   .compatible = "arm,realview-eb-syscon",
+   .data = (void *)REALVIEW_CLCD_EB,
+   },
+   {
+   .compatible = "arm,realview-pb1176-syscon",
+   .data = (void *)REALVIEW_CLCD_PB1176,
+   },
+   {
+   .compatible = "arm,realview-pb11mp-syscon",
+   .data = (void *)REALVIEW_CLCD_PB11MP,
+   },
+   {
+   .compatible = "arm,realview-pba8-syscon",
+   .data = (void *)REALVIEW_CLCD_PBA8,
+   },
+   {
+   .compatible = "arm,realview-pbx-syscon",
+   .data = (void *)REALVIEW_CLCD_PBX,
+   },
+   {},
+};
+
+/*
+ * Core module CLCD control on the Integrator/CP, bits
+ * 8 thru 19 of the CM_CONTROL register controls a bunch
+ * of CLCD settings.
+ */
+#define INTEGRATOR_HDR_CTRL_OFFSET 0x0C
+#define INTEGRATOR_CLCD_LCDBIASEN  BIT(8)
+#define INTEGRATOR_CLCD_LCDBIASUP  BIT(9)
+#define INTEGRATOR_CLCD_LCDBIASDN  BIT(10)
+/* Bits 11,12,13 controls the LCD type 

[PATCH 5/7 v3] drm/pl111: Insert delay before powering up PL11x

[Linus Walleij]

The old codebase has a delay between enabling and powering up the
PL11x.

According to the manual for PL110, ARM DDI 0161E page 1-5 and
the PL111 manual ARM DDI 0293C page 1-6, the power sequence should
be such that once Vdd is stable (which we assume it is at boot)
LCDEN is enabled first and then CLPOWER should be enabled
"after the signals have stabilized" and this is said to
be display-dependent. The old codebase uses 20ms.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Fall back to the delay of 20 ms from the old framebuffer
  driver to stabilize Vee in shortage of other alternatives.
---
 drivers/gpu/drm/pl111/pl111_display.c | 31 ---
 1 file changed, 28 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index b104011cea55..b7df9f5df881 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -155,8 +155,8 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
 
writel(0, priv->regs + CLCD_TIM3);
 
-   /* Enable and Power Up */
-   cntl = CNTL_LCDEN | CNTL_LCDTFT | CNTL_LCDPWR | CNTL_LCDVCOMP(1);
+   /* Hard-code TFT panel */
+   cntl = CNTL_LCDEN | CNTL_LCDTFT | CNTL_LCDVCOMP(1);
 
/* Note that the the hardware's format reader takes 'r' from
 * the low bit, while DRM formats list channels from high bit
@@ -199,6 +199,17 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
break;
}
 
+   /* Power sequence: first enable and chill */
+   writel(cntl, priv->regs + priv->ctrl);
+
+   /*
+* We expect this delay to stabilize the contrast
+* voltage Vee as stipulated by the manual
+*/
+   msleep(20);
+
+   /* Power Up */
+   cntl |= CNTL_LCDPWR;
writel(cntl, priv->regs + priv->ctrl);
 
drm_crtc_vblank_on(crtc);
@@ -209,10 +220,24 @@ void pl111_display_disable(struct drm_simple_display_pipe 
*pipe)
struct drm_crtc *crtc = >crtc;
struct drm_device *drm = crtc->dev;
struct pl111_drm_dev_private *priv = drm->dev_private;
+   u32 cntl;
 
drm_crtc_vblank_off(crtc);
 
-   /* Disable and Power Down */
+   /* Power Down */
+   cntl = readl(priv->regs + priv->ctrl);
+   if (cntl & CNTL_LCDPWR) {
+   cntl &= ~CNTL_LCDPWR;
+   writel(cntl, priv->regs + priv->ctrl);
+   }
+
+   /*
+* We expect this delay to stabilize the contrast voltage Vee as
+* stipulated by the manual
+*/
+   msleep(20);
+
+   /* Disable */
writel(0, priv->regs + priv->ctrl);
 
clk_disable_unprepare(priv->clk);
-- 
2.13.5

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

[PATCH 6/7 v3] drm/pl111: Add optional variant display en/disable callbacks

[Linus Walleij]

The silcon and components around the PL111 may require some
variants to perform special set-up of the display. Add two
callbacks to manage this.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Rebase on other display driver changes.
---
 drivers/gpu/drm/pl111/pl111_display.c | 6 ++
 drivers/gpu/drm/pl111/pl111_drm.h | 3 +++
 2 files changed, 9 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index b7df9f5df881..68847a074331 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -208,6 +208,9 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
 */
msleep(20);
 
+   if (priv->variant_display_enable)
+   priv->variant_display_enable(drm, fb->format->format);
+
/* Power Up */
cntl |= CNTL_LCDPWR;
writel(cntl, priv->regs + priv->ctrl);
@@ -237,6 +240,9 @@ void pl111_display_disable(struct drm_simple_display_pipe 
*pipe)
 */
msleep(20);
 
+   if (priv->variant_display_disable)
+   priv->variant_display_disable(drm);
+
/* Disable */
writel(0, priv->regs + priv->ctrl);
 
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index b380a7b4fb58..440f53ebee8c 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -26,6 +26,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #define CLCD_IRQ_NEXTBASE_UPDATE BIT(2)
 
@@ -66,6 +67,8 @@ struct pl111_drm_dev_private {
 */
spinlock_t tim2_lock;
const struct pl111_variant_data *variant;
+   void (*variant_display_enable) (struct drm_device *drm, u32 format);
+   void (*variant_display_disable) (struct drm_device *drm);
 };
 
 int pl111_display_init(struct drm_device *dev);
-- 
2.13.5

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

[PATCH 4/7 v3] drm/pl111: Enable PL110 variant

[Linus Walleij]

We detect and enable the use of the PL110 variant, an earlier
incarnation of PL111. The only real difference is that the
control and interrupt enable registers have swapped place.
The Versatile AB and Versatile PB have a variant inbetween
PL110 and PL111, it is PL110 but they have already swapped the
two registers so those two need a bit of special handling.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Fix static const on the variant struct holders. (Had to
  insert a (void*) cast for this because amba_id is not
  consting this field)
- Collect Eric A's Reviewed-by
---
 drivers/gpu/drm/pl111/pl111_display.c | 30 
 drivers/gpu/drm/pl111/pl111_drm.h | 17 +++
 drivers/gpu/drm/pl111/pl111_drv.c | 86 +--
 3 files changed, 108 insertions(+), 25 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_display.c 
b/drivers/gpu/drm/pl111/pl111_display.c
index e4c692230548..b104011cea55 100644
--- a/drivers/gpu/drm/pl111/pl111_display.c
+++ b/drivers/gpu/drm/pl111/pl111_display.c
@@ -199,7 +199,7 @@ static void pl111_display_enable(struct 
drm_simple_display_pipe *pipe,
break;
}
 
-   writel(cntl, priv->regs + CLCD_PL111_CNTL);
+   writel(cntl, priv->regs + priv->ctrl);
 
drm_crtc_vblank_on(crtc);
 }
@@ -213,7 +213,7 @@ void pl111_display_disable(struct drm_simple_display_pipe 
*pipe)
drm_crtc_vblank_off(crtc);
 
/* Disable and Power Down */
-   writel(0, priv->regs + CLCD_PL111_CNTL);
+   writel(0, priv->regs + priv->ctrl);
 
clk_disable_unprepare(priv->clk);
 }
@@ -251,7 +251,7 @@ int pl111_enable_vblank(struct drm_device *drm, unsigned 
int crtc)
 {
struct pl111_drm_dev_private *priv = drm->dev_private;
 
-   writel(CLCD_IRQ_NEXTBASE_UPDATE, priv->regs + CLCD_PL111_IENB);
+   writel(CLCD_IRQ_NEXTBASE_UPDATE, priv->regs + priv->ienb);
 
return 0;
 }
@@ -260,7 +260,7 @@ void pl111_disable_vblank(struct drm_device *drm, unsigned 
int crtc)
 {
struct pl111_drm_dev_private *priv = drm->dev_private;
 
-   writel(0, priv->regs + CLCD_PL111_IENB);
+   writel(0, priv->regs + priv->ienb);
 }
 
 static int pl111_display_prepare_fb(struct drm_simple_display_pipe *pipe,
@@ -404,22 +404,6 @@ int pl111_display_init(struct drm_device *drm)
struct device_node *endpoint;
u32 tft_r0b0g0[3];
int ret;
-   static const u32 formats[] = {
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XBGR,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_XRGB,
-   DRM_FORMAT_BGR565,
-   DRM_FORMAT_RGB565,
-   DRM_FORMAT_ABGR1555,
-   DRM_FORMAT_XBGR1555,
-   DRM_FORMAT_ARGB1555,
-   DRM_FORMAT_XRGB1555,
-   DRM_FORMAT_ABGR,
-   DRM_FORMAT_XBGR,
-   DRM_FORMAT_ARGB,
-   DRM_FORMAT_XRGB,
-   };
 
endpoint = of_graph_get_next_endpoint(dev->of_node, NULL);
if (!endpoint)
@@ -448,8 +432,10 @@ int pl111_display_init(struct drm_device *drm)
 
ret = drm_simple_display_pipe_init(drm, >pipe,
   _display_funcs,
-  formats, ARRAY_SIZE(formats),
-  NULL, priv->connector);
+  priv->variant->formats,
+  priv->variant->nformats,
+  NULL,
+  priv->connector);
if (ret)
return ret;
 
diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index 000534d85b43..b380a7b4fb58 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -31,6 +31,20 @@
 
 struct drm_minor;
 
+/**
+ * struct pl111_variant_data - encodes IP differences
+ * @name: the name of this variant
+ * @is_pl110: this is the early PL110 variant
+ * @formats: array of supported pixel formats on this variant
+ * @nformats: the length of the array of supported pixel formats
+ */
+struct pl111_variant_data {
+   const char *name;
+   bool is_pl110;
+   const u32 *formats;
+   unsigned int nformats;
+};
+
 struct pl111_drm_dev_private {
struct drm_device *drm;
 
@@ -41,6 +55,8 @@ struct pl111_drm_dev_private {
struct drm_fbdev_cma *fbdev;
 
void *regs;
+   u32 ienb;
+   u32 ctrl;
/* The pixel clock (a reference to our clock divider off of CLCDCLK). */
struct clk *clk;
/* pl111's internal clock divider. */
@@ -49,6 +65,7 @@ struct pl111_drm_dev_private {
 * subsystem and pl111_display_enable().
 */
spinlock_t tim2_lock;
+   const struct 

[PATCH 3/7 v3] drm/pl111: Replace custom connector with panel bridge

[Linus Walleij]

This replaces the custom connector in the PL111 with the
panel bridge helper.

This works nicely for all standard panels, but since there
are several PL11x-based systems that will need to use the dumb
VGA connector bridge we use drm_of_find_panel_or_bridge()
and make some headroom for dealing with bridges that are
not panels as well, and drop a TODO in the code.

Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
- Use drm_simple_display_pipe_attach_bridge() as suggested
  by Daniel Vetter.
ChangeLog v1->v2:
- Remove the panel [un]prepare() and [en|dis]able() calls
  from the display driver, since this is now handled
  by the bridge.
---
 drivers/gpu/drm/pl111/Kconfig   |   3 +-
 drivers/gpu/drm/pl111/Makefile  |   3 +-
 drivers/gpu/drm/pl111/pl111_connector.c | 126 
 drivers/gpu/drm/pl111/pl111_display.c   |  18 ++---
 drivers/gpu/drm/pl111/pl111_drm.h   |  17 ++---
 drivers/gpu/drm/pl111/pl111_drv.c   |  52 -
 6 files changed, 52 insertions(+), 167 deletions(-)
 delete mode 100644 drivers/gpu/drm/pl111/pl111_connector.c

diff --git a/drivers/gpu/drm/pl111/Kconfig b/drivers/gpu/drm/pl111/Kconfig
index bbfba87cd1a8..e5e2abd66491 100644
--- a/drivers/gpu/drm/pl111/Kconfig
+++ b/drivers/gpu/drm/pl111/Kconfig
@@ -6,7 +6,8 @@ config DRM_PL111
select DRM_KMS_HELPER
select DRM_KMS_CMA_HELPER
select DRM_GEM_CMA_HELPER
-   select DRM_PANEL
+   select DRM_BRIDGE
+   select DRM_PANEL_BRIDGE
select VT_HW_CONSOLE_BINDING if FRAMEBUFFER_CONSOLE
help
  Choose this option for DRM support for the PL111 CLCD controller.
diff --git a/drivers/gpu/drm/pl111/Makefile b/drivers/gpu/drm/pl111/Makefile
index 59483d610ef5..c5f8f9684848 100644
--- a/drivers/gpu/drm/pl111/Makefile
+++ b/drivers/gpu/drm/pl111/Makefile
@@ -1,5 +1,4 @@
-pl111_drm-y += pl111_connector.o \
-   pl111_display.o \
+pl111_drm-y += pl111_display.o \
pl111_drv.o
 
 pl111_drm-$(CONFIG_DEBUG_FS) += pl111_debugfs.o
diff --git a/drivers/gpu/drm/pl111/pl111_connector.c 
b/drivers/gpu/drm/pl111/pl111_connector.c
deleted file mode 100644
index d335f9a29ce4..
--- a/drivers/gpu/drm/pl111/pl111_connector.c
+++ /dev/null
@@ -1,126 +0,0 @@
-/*
- * (C) COPYRIGHT 2012-2013 ARM Limited. All rights reserved.
- *
- * Parts of this file were based on sources as follows:
- *
- * Copyright (c) 2006-2008 Intel Corporation
- * Copyright (c) 2007 Dave Airlie 
- * Copyright (C) 2011 Texas Instruments
- *
- * This program is free software and is provided to you under the terms of the
- * GNU General Public License version 2 as published by the Free Software
- * Foundation, and any use by you of this program is subject to the terms of
- * such GNU licence.
- *
- */
-
-/**
- * pl111_drm_connector.c
- * Implementation of the connector functions for PL111 DRM
- */
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include "pl111_drm.h"
-
-static void pl111_connector_destroy(struct drm_connector *connector)
-{
-   struct pl111_drm_connector *pl111_connector =
-   to_pl111_connector(connector);
-
-   if (pl111_connector->panel)
-   drm_panel_detach(pl111_connector->panel);
-
-   drm_connector_unregister(connector);
-   drm_connector_cleanup(connector);
-}
-
-static enum drm_connector_status pl111_connector_detect(struct drm_connector
-   *connector, bool force)
-{
-   struct pl111_drm_connector *pl111_connector =
-   to_pl111_connector(connector);
-
-   return (pl111_connector->panel ?
-   connector_status_connected :
-   connector_status_disconnected);
-}
-
-static int pl111_connector_helper_get_modes(struct drm_connector *connector)
-{
-   struct pl111_drm_connector *pl111_connector =
-   to_pl111_connector(connector);
-
-   if (!pl111_connector->panel)
-   return 0;
-
-   return drm_panel_get_modes(pl111_connector->panel);
-}
-
-const struct drm_connector_funcs connector_funcs = {
-   .fill_modes = drm_helper_probe_single_connector_modes,
-   .destroy = pl111_connector_destroy,
-   .detect = pl111_connector_detect,
-   .reset = drm_atomic_helper_connector_reset,
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
-   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
-};
-
-const struct drm_connector_helper_funcs connector_helper_funcs = {
-   .get_modes = pl111_connector_helper_get_modes,
-};
-
-/* Walks the OF graph to find the panel node and then asks DRM to look
- * up the panel.
- */
-static struct drm_panel *pl111_get_panel(struct device *dev)
-{
-   struct device_node *endpoint, *panel_node;
-   struct device_node *np = dev->of_node;
-   struct 

[PATCH 2/7 v3] drm/pl111: Add all registers to debugfs

[Linus Walleij]

This adds all the main control registers to the debugfs
register file. This was helpful for my debugging so it will
likely help others as well.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Collect Eric's ACK.
---
 drivers/gpu/drm/pl111/pl111_debugfs.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/pl111/pl111_debugfs.c 
b/drivers/gpu/drm/pl111/pl111_debugfs.c
index 0d9dee199b2c..7ddc7e3b9e7d 100644
--- a/drivers/gpu/drm/pl111/pl111_debugfs.c
+++ b/drivers/gpu/drm/pl111/pl111_debugfs.c
@@ -22,8 +22,14 @@ static const struct {
REGDEF(CLCD_TIM2),
REGDEF(CLCD_TIM3),
REGDEF(CLCD_UBAS),
+   REGDEF(CLCD_LBAS),
REGDEF(CLCD_PL111_CNTL),
REGDEF(CLCD_PL111_IENB),
+   REGDEF(CLCD_PL111_RIS),
+   REGDEF(CLCD_PL111_MIS),
+   REGDEF(CLCD_PL111_ICR),
+   REGDEF(CLCD_PL111_UCUR),
+   REGDEF(CLCD_PL111_LCUR),
 };
 
 int pl111_debugfs_regs(struct seq_file *m, void *unused)
-- 
2.13.5

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

[PATCH 1/7 v3] drm/pl111: Cleanup local header file

[Linus Walleij]

The header file contains prototypes for two nonexisting
functions. Get rid of them.

Reviewed-by: Eric Anholt 
Signed-off-by: Linus Walleij 
---
ChangeLog v2->v3:
- Rebase on DRM-TIP
ChangeLog v1->v2:
- Collect Eric's ACK.
---
 drivers/gpu/drm/pl111/pl111_drm.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/gpu/drm/pl111/pl111_drm.h 
b/drivers/gpu/drm/pl111/pl111_drm.h
index 5c685bfc8fdc..a97f303f6833 100644
--- a/drivers/gpu/drm/pl111/pl111_drm.h
+++ b/drivers/gpu/drm/pl111/pl111_drm.h
@@ -58,10 +58,6 @@ int pl111_enable_vblank(struct drm_device *drm, unsigned int 
crtc);
 void pl111_disable_vblank(struct drm_device *drm, unsigned int crtc);
 irqreturn_t pl111_irq(int irq, void *data);
 int pl111_connector_init(struct drm_device *dev);
-int pl111_encoder_init(struct drm_device *dev);
-int pl111_dumb_create(struct drm_file *file_priv,
- struct drm_device *dev,
- struct drm_mode_create_dumb *args);
 int pl111_debugfs_init(struct drm_minor *minor);
 
 #endif /* _PL111_DRM_H_ */
-- 
2.13.5

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

Re: [PATCH 3/3] drm/amdgpu: rework amdgpu_cs_find_mapping

[Leo Liu]

On 09/07/2017 08:08 AM, Christian König wrote:

Am 06.09.2017 um 18:33 schrieb Leo Liu:



On 09/06/2017 11:51 AM, Christian König wrote:

From: Christian König 

Use the VM instead of the BO list to find the BO for a virtual address.

This fixes UVD/VCE in physical mode with VM local BOs.


The series is
Tested-by: Leo Liu 


Can I get an rb or ab as well? Alex is on vacation and I would really 
like to push this patch.

Since we need to fix the legacy UVD/VCE issue ASAP,
The series is
Acked-by: Leo Liu 



Christian.





Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 42 
+++---

  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  2 ++
  4 files changed, 30 insertions(+), 32 deletions(-)

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

index bcb3548..132e17a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1374,46 +1374,24 @@ int amdgpu_cs_find_mapping(struct 
amdgpu_cs_parser *parser,

 uint64_t addr, struct amdgpu_bo **bo,
 struct amdgpu_bo_va_mapping **map)
  {
+struct amdgpu_fpriv *fpriv = parser->filp->driver_priv;
+struct amdgpu_vm *vm = >vm;
  struct amdgpu_bo_va_mapping *mapping;
-unsigned i;
  int r;
  -if (!parser->bo_list)
-return 0;
-
  addr /= AMDGPU_GPU_PAGE_SIZE;
  -for (i = 0; i < parser->bo_list->num_entries; i++) {
-struct amdgpu_bo_list_entry *lobj;
-
-lobj = >bo_list->array[i];
-if (!lobj->bo_va)
-continue;
-
-list_for_each_entry(mapping, >bo_va->valids, list) {
-if (mapping->start > addr ||
-addr > mapping->last)
-continue;
-
-*bo = lobj->bo_va->base.bo;
-*map = mapping;
-goto found;
-}
-
-list_for_each_entry(mapping, >bo_va->invalids, list) {
-if (mapping->start > addr ||
-addr > mapping->last)
-continue;
+mapping = amdgpu_vm_bo_lookup_mapping(vm, addr);
+if (!mapping || !mapping->bo_va || !mapping->bo_va->base.bo)
+return -EINVAL;
  -*bo = lobj->bo_va->base.bo;
-*map = mapping;
-goto found;
-}
-}
+*bo = mapping->bo_va->base.bo;
+*map = mapping;
  -return -EINVAL;
+/* Double check that the BO is reserved by this CS */
+if (READ_ONCE((*bo)->tbo.resv->lock.ctx) != >ticket)
+return -EINVAL;
  -found:
  r = amdgpu_ttm_bind(&(*bo)->tbo, &(*bo)->tbo.mem);
  if (unlikely(r))
  return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

index 42492e6..a4891be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -35,6 +35,7 @@
/* bo virtual addresses in a vm */
  struct amdgpu_bo_va_mapping {
+struct amdgpu_bo_va*bo_va;
  struct list_headlist;
  struct rb_noderb;
  uint64_tstart;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index cfc8de8..ab9dfd7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2083,6 +2083,7 @@ static void amdgpu_vm_bo_insert_map(struct 
amdgpu_device *adev,

  struct amdgpu_vm *vm = bo_va->base.vm;
  struct amdgpu_bo *bo = bo_va->base.bo;
  +mapping->bo_va = bo_va;
  list_add(>list, _va->invalids);
  amdgpu_vm_it_insert(mapping, >va);
  @@ -2260,6 +2261,7 @@ int amdgpu_vm_bo_unmap(struct amdgpu_device 
*adev,

list_del(>list);
  amdgpu_vm_it_remove(mapping, >va);
+mapping->bo_va = NULL;
  trace_amdgpu_vm_bo_unmap(bo_va, mapping);
if (valid)
@@ -2345,6 +2347,7 @@ int amdgpu_vm_bo_clear_mappings(struct 
amdgpu_device *adev,

  if (tmp->last > eaddr)
  tmp->last = eaddr;
  +tmp->bo_va = NULL;
  list_add(>list, >freed);
  trace_amdgpu_vm_bo_unmap(NULL, tmp);
  }
@@ -2371,6 +2374,19 @@ int amdgpu_vm_bo_clear_mappings(struct 
amdgpu_device *adev,

  }
/**
+ * amdgpu_vm_bo_lookup_mapping - find mapping by address
+ *
+ * @vm: the requested VM
+ *
+ * Find a mapping by it's address.
+ */
+struct amdgpu_bo_va_mapping *amdgpu_vm_bo_lookup_mapping(struct 
amdgpu_vm *vm,

+ uint64_t addr)
+{
+return amdgpu_vm_it_iter_first(>va, addr, addr);
+}
+
+/**
   * amdgpu_vm_bo_rmv - remove a bo to a specific vm
   *
   * @adev: amdgpu_device pointer
@@ -2395,6 +2411,7 @@ void amdgpu_vm_bo_rmv(struct amdgpu_device *adev,
  list_for_each_entry_safe(mapping, next, _va->valids, list) {

Re: [PATCH v8 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Heiko Stübner]

Hi Mark,

Am Donnerstag, 7. September 2017, 18:16:29 CEST schrieb Mark yao:
> Looks good for me, so:
> Reviewed-by: Mark Yao 
> 
> I'd like to apply these lvds patches tomorrow if there is no more doubts.

Rob had some minor comments on v7 of the dt-binding, so you may want
to give him a bit more time to Ack the hopefully updated binding.

Otherwise no doubts from me, just a reminder that you should take
patches 1+3 and I'll pick patch 2 with the dts changes after that.


Thanks
Heiko

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

Re: [PATCH 3/3] drm/amdgpu: rework amdgpu_cs_find_mapping

[Christian König]

Am 06.09.2017 um 18:33 schrieb Leo Liu:



On 09/06/2017 11:51 AM, Christian König wrote:

From: Christian König 

Use the VM instead of the BO list to find the BO for a virtual address.

This fixes UVD/VCE in physical mode with VM local BOs.


The series is
Tested-by: Leo Liu 


Can I get an rb or ab as well? Alex is on vacation and I would really 
like to push this patch.


Christian.





Signed-off-by: Christian König 
---
  drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 42 
+++---

  drivers/gpu/drm/amd/amdgpu/amdgpu_object.h |  1 +
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 
  drivers/gpu/drm/amd/amdgpu/amdgpu_vm.h |  2 ++
  4 files changed, 30 insertions(+), 32 deletions(-)

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

index bcb3548..132e17a 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
@@ -1374,46 +1374,24 @@ int amdgpu_cs_find_mapping(struct 
amdgpu_cs_parser *parser,

 uint64_t addr, struct amdgpu_bo **bo,
 struct amdgpu_bo_va_mapping **map)
  {
+struct amdgpu_fpriv *fpriv = parser->filp->driver_priv;
+struct amdgpu_vm *vm = >vm;
  struct amdgpu_bo_va_mapping *mapping;
-unsigned i;
  int r;
  -if (!parser->bo_list)
-return 0;
-
  addr /= AMDGPU_GPU_PAGE_SIZE;
  -for (i = 0; i < parser->bo_list->num_entries; i++) {
-struct amdgpu_bo_list_entry *lobj;
-
-lobj = >bo_list->array[i];
-if (!lobj->bo_va)
-continue;
-
-list_for_each_entry(mapping, >bo_va->valids, list) {
-if (mapping->start > addr ||
-addr > mapping->last)
-continue;
-
-*bo = lobj->bo_va->base.bo;
-*map = mapping;
-goto found;
-}
-
-list_for_each_entry(mapping, >bo_va->invalids, list) {
-if (mapping->start > addr ||
-addr > mapping->last)
-continue;
+mapping = amdgpu_vm_bo_lookup_mapping(vm, addr);
+if (!mapping || !mapping->bo_va || !mapping->bo_va->base.bo)
+return -EINVAL;
  -*bo = lobj->bo_va->base.bo;
-*map = mapping;
-goto found;
-}
-}
+*bo = mapping->bo_va->base.bo;
+*map = mapping;
  -return -EINVAL;
+/* Double check that the BO is reserved by this CS */
+if (READ_ONCE((*bo)->tbo.resv->lock.ctx) != >ticket)
+return -EINVAL;
  -found:
  r = amdgpu_ttm_bind(&(*bo)->tbo, &(*bo)->tbo.mem);
  if (unlikely(r))
  return r;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h

index 42492e6..a4891be 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_object.h
@@ -35,6 +35,7 @@
/* bo virtual addresses in a vm */
  struct amdgpu_bo_va_mapping {
+struct amdgpu_bo_va*bo_va;
  struct list_headlist;
  struct rb_noderb;
  uint64_tstart;
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c

index cfc8de8..ab9dfd7 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c
@@ -2083,6 +2083,7 @@ static void amdgpu_vm_bo_insert_map(struct 
amdgpu_device *adev,

  struct amdgpu_vm *vm = bo_va->base.vm;
  struct amdgpu_bo *bo = bo_va->base.bo;
  +mapping->bo_va = bo_va;
  list_add(>list, _va->invalids);
  amdgpu_vm_it_insert(mapping, >va);
  @@ -2260,6 +2261,7 @@ int amdgpu_vm_bo_unmap(struct amdgpu_device 
*adev,

list_del(>list);
  amdgpu_vm_it_remove(mapping, >va);
+mapping->bo_va = NULL;
  trace_amdgpu_vm_bo_unmap(bo_va, mapping);
if (valid)
@@ -2345,6 +2347,7 @@ int amdgpu_vm_bo_clear_mappings(struct 
amdgpu_device *adev,

  if (tmp->last > eaddr)
  tmp->last = eaddr;
  +tmp->bo_va = NULL;
  list_add(>list, >freed);
  trace_amdgpu_vm_bo_unmap(NULL, tmp);
  }
@@ -2371,6 +2374,19 @@ int amdgpu_vm_bo_clear_mappings(struct 
amdgpu_device *adev,

  }
/**
+ * amdgpu_vm_bo_lookup_mapping - find mapping by address
+ *
+ * @vm: the requested VM
+ *
+ * Find a mapping by it's address.
+ */
+struct amdgpu_bo_va_mapping *amdgpu_vm_bo_lookup_mapping(struct 
amdgpu_vm *vm,

+ uint64_t addr)
+{
+return amdgpu_vm_it_iter_first(>va, addr, addr);
+}
+
+/**
   * amdgpu_vm_bo_rmv - remove a bo to a specific vm
   *
   * @adev: amdgpu_device pointer
@@ -2395,6 +2411,7 @@ void amdgpu_vm_bo_rmv(struct amdgpu_device *adev,
  list_for_each_entry_safe(mapping, next, _va->valids, list) {
  list_del(>list);
  amdgpu_vm_it_remove(mapping, >va);
+mapping->bo_va = NULL;
  trace_amdgpu_vm_bo_unmap(bo_va, mapping);
  

Re: [PATCH v2 3/3] drm/exynos/gsc: Add hardware rotation limits

[Marek Szyprowski]

Hi Hoegeun,

On 2017-09-07 11:39, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 100 +++-
  include/uapi/drm/exynos_drm.h   |   2 +
  2 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..590a645 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -150,6 +150,15 @@ struct gsc_context {
boolsuspended;
  };
  
+/*

+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
  /* 8-tap Filter Coefficient */
  static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1410,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
  
+	config = >config[EXYNOS_DRM_OPS_DST];

+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1442,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
  
-		/* check for degree */

-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1449,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
  
+		/*

+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1480,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (sz->vsize > 

Re: [PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

[Marek Szyprowski]

Hi Hoegeun,

On 2017-09-07 11:39, Hoegeun Kwon wrote:

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 


The new values (5250/5420 specific) should replace old exynos5-gsc, 
there is no

point providing both in dts.


---
  arch/arm/boot/dts/exynos5250.dtsi | 8 
  arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
  2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
  
  		gsc_0:  gsc@13e0 {

-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
  
  		gsc_1:  gsc@13e1 {

-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
  
  		gsc_2:  gsc@13e2 {

-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
  
  		gsc_3:  gsc@13e3 {

-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
  
  		gsc_0: video-scaler@13e0 {

-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
  
  		gsc_1: video-scaler@13e1 {

-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;


Best regards
--
Marek Szyprowski, PhD
Samsung R Institute Poland

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

Re: [PATCH 3/3] drm/exynos/gsc: Add rotation hardware limits of gscaler

[Marek Szyprowski]

Hi Hoegeun,

On 2017-09-07 07:16, Hoegeun Kwon wrote:

On 09/04/2017 03:19 PM, Hoegeun Kwon wrote:

On 09/01/2017 04:31 PM, Marek Szyprowski wrote:

Hi Hoegeun,

On 2017-09-01 03:47, Hoegeun Kwon wrote:

The gscaler has hardware rotation limits that need to be imported from
dts. Parse them and add them to the property list.

The rotation hardware limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to post size, use pos size to
check the limits.

Signed-off-by: Hoegeun Kwon 
---
  drivers/gpu/drm/exynos/exynos_drm_gsc.c | 63 
+

  include/uapi/drm/exynos_drm.h   |  2 ++
  2 files changed, 42 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c

index 0506b2b..dd9b057 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -1401,6 +1401,23 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  bool swap;
  int i;
  +    config = >config[EXYNOS_DRM_OPS_DST];
+
+    /* check for degree */
+    switch (config->degree) {
+    case EXYNOS_DRM_DEGREE_90:
+    case EXYNOS_DRM_DEGREE_270:
+    swap = true;
+    break;
+    case EXYNOS_DRM_DEGREE_0:
+    case EXYNOS_DRM_DEGREE_180:
+    swap = false;
+    break;
+    default:
+    DRM_ERROR("invalid degree.\n");
+    goto err_property;
+    }
+
  for_each_ipp_ops(i) {
  if ((i == EXYNOS_DRM_OPS_SRC) &&
  (property->cmd == IPP_CMD_WB))
@@ -1416,21 +1433,6 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  -    /* check for degree */
-    switch (config->degree) {
-    case EXYNOS_DRM_DEGREE_90:
-    case EXYNOS_DRM_DEGREE_270:
-    swap = true;
-    break;
-    case EXYNOS_DRM_DEGREE_0:
-    case EXYNOS_DRM_DEGREE_180:
-    swap = false;
-    break;
-    default:
-    DRM_ERROR("invalid degree.\n");
-    goto err_property;
-    }
-
  /* check for buffer bound */
  if ((pos->x + pos->w > sz->hsize) ||
  (pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1440,27 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  goto err_property;
  }
  +    /*
+ * The rotation hardware limits are related to the cropped
+ * source size. So use rot_max size to check the limits when
+ * swap happens. And also the scaling limits are related 
to pos

+ * size, use pos size to check the limits.
+ */
  /* check for crop */
  if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
  if (swap) {
  if ((pos->h < pp->crop_min.hsize) ||
-    (sz->vsize > pp->crop_max.hsize) ||
+    (pos->h > pp->rot_max.hsize) ||
  (pos->w < pp->crop_min.vsize) ||
-    (sz->hsize > pp->crop_max.vsize)) {
+    (pos->w > pp->rot_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->crop_min.hsize) ||
-    (sz->hsize > pp->crop_max.hsize) ||
+    (pos->w > pp->crop_max.hsize) ||
  (pos->h < pp->crop_min.vsize) ||
-    (sz->vsize > pp->crop_max.vsize)) {
+    (pos->h > pp->crop_max.vsize)) {
  DRM_ERROR("out of crop size.\n");
  goto err_property;
  }
@@ -1463,17 +1471,17 @@ static int gsc_ippdrv_check_property(struct 
device *dev,

  if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
  if (swap) {
  if ((pos->h < pp->scale_min.hsize) ||
-    (sz->vsize > pp->scale_max.hsize) ||
+    (pos->h > pp->scale_max.hsize) ||
  (pos->w < pp->scale_min.vsize) ||
-    (sz->hsize > pp->scale_max.vsize)) {
+    (pos->w > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
  } else {
  if ((pos->w < pp->scale_min.hsize) ||
-    (sz->hsize > pp->scale_max.hsize) ||
+    (pos->w > pp->scale_max.hsize) ||
  (pos->h < pp->scale_min.vsize) ||
-    (sz->vsize > pp->scale_max.vsize)) {
+    (pos->h > pp->scale_max.vsize)) {
  DRM_ERROR("out of scale size.\n");
  goto err_property;
  }
@@ -1676,6 +1684,15 @@ static int gsc_probe(struct platform_device 
*pdev)

  dev_warn(dev, "failed to get system 

[Bug 102581] 3D texture mipmapping broken

[bugzilla-daemon]

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

Bug ID: 102581
   Summary: 3D texture mipmapping broken
   Product: Mesa
   Version: 17.1
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/Gallium/radeonsi
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: m...@felix-potthast.de
QA Contact: dri-devel@lists.freedesktop.org

Created attachment 134041
  --> https://bugs.freedesktop.org/attachment.cgi?id=134041=edit
Screenshot comparison

When trying to display 
https://www.shadertoy.com/view/4llcR4
i get artifacts near horizon due to mipmapping (artifacts are absent with
mipmapping disabled).
It works as expected with the proprietary driver (under Windows) on the same
machine.
See attached image for Screenshot comparison.

So either mipmap generation or display seems to be erroneous for 3D textures.

My card is AMD Radeon HD 7870.

-- 
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 v2 5/6] drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.

[Maarten Lankhorst]

Op 07-09-17 om 12:05 schreef Daniel Vetter:
> On Mon, Sep 04, 2017 at 12:48:37PM +0200, Maarten Lankhorst wrote:
>> Currently we neatly track the crtc state, but forget to look at
>> plane/connector state.
>>
>> When doing a nonblocking modeset, immediately followed by a setprop
>> before the modeset completes, the setprop will see the modesets new
>> state as the old state and free it.
>>
>> This has to be solved by waiting for hw_done on the connector, even
>> if it's not assigned to a crtc. When a connector is unbound we take
>> the last crtc commit, and when it stays unbound we create a new
>> fake crtc commit for that gets signaled on hw_done for all the
>> planes/connectors.
>>
>> We wait for it the same way as we do for crtc's, which will make
>> sure we never run into a use-after-free situation.
>>
>> Changes since v1:
>> - Only create a single disable commit. (danvet)
>> - Fix leak in intel_legacy_cursor_update.
>> Changes since v2:
>> - Make reference counting in drm_atomic_helper_setup_commit
>>   more obvious. (pinchartl)
>> - Call cleanup_done for fake commit. (danvet)
>> - Add comments to drm_atomic_helper_setup_commit. (danvet, pinchartl)
>> - Add comment to drm_atomic_helper_swap_state. (pinchartl)
>>
>> Signed-off-by: Maarten Lankhorst 
>> Testcase: kms_atomic_transition.plane-use-after-nonblocking-unbind*
>> Cc: Laurent Pinchart 
>> ---
>>  drivers/gpu/drm/drm_atomic.c |   4 +
>>  drivers/gpu/drm/drm_atomic_helper.c  | 172 
>> +--
>>  drivers/gpu/drm/i915/intel_display.c |   2 +
>>  include/drm/drm_atomic.h |  12 +++
>>  include/drm/drm_connector.h  |   7 ++
>>  include/drm/drm_plane.h  |   7 ++
>>  6 files changed, 198 insertions(+), 6 deletions(-)
>>
>> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
>> index 2cce48f203e0..75f5f74de9bf 100644
>> --- a/drivers/gpu/drm/drm_atomic.c
>> +++ b/drivers/gpu/drm/drm_atomic.c
>> @@ -192,6 +192,10 @@ void drm_atomic_state_default_clear(struct 
>> drm_atomic_state *state)
>>  }
>>  state->num_private_objs = 0;
>>  
>> +if (state->fake_commit) {
>> +drm_crtc_commit_put(state->fake_commit);
>> +state->fake_commit = NULL;
>> +}
>>  }
>>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
>>  
>> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
>> b/drivers/gpu/drm/drm_atomic_helper.c
>> index 04629d883114..c81d46927a74 100644
>> --- a/drivers/gpu/drm/drm_atomic_helper.c
>> +++ b/drivers/gpu/drm/drm_atomic_helper.c
>> @@ -1667,6 +1667,38 @@ static void release_crtc_commit(struct completion 
>> *completion)
>>  drm_crtc_commit_put(commit);
>>  }
>>  
>> +static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc 
>> *crtc)
>> +{
>> +init_completion(>flip_done);
>> +init_completion(>hw_done);
>> +init_completion(>cleanup_done);
>> +INIT_LIST_HEAD(>commit_entry);
>> +kref_init(>ref);
>> +commit->crtc = crtc;
>> +}
>> +
>> +static struct drm_crtc_commit *
>> +crtc_or_fake_commit(struct drm_atomic_state *state, struct drm_crtc *crtc)
> Bikeshed: Would be nice if this function directly increases the refcount,
> instead of imposing this on all callers. Would need a rename too like
> crtc_or_fake_commit_get().
>
> But since this bug is randomly killing our hsw CI and causing lots of
> noise better to push as-is and polish later on.
>
> Reviewed-by: Daniel Vetter 
I chose not to, to make it explicit that a extra refcount is used on the state 
object.
But sending one final version to trybot to make sure that things don't blow up 
with the merge conflicts in patch 6. :)
>> +{
>> +if (crtc) {
>> +struct drm_crtc_state *new_crtc_state;
>> +
>> +new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
>> +
>> +return new_crtc_state->commit;
>> +}
>> +
>> +if (!state->fake_commit) {
>> +state->fake_commit = kzalloc(sizeof(*state->fake_commit), 
>> GFP_KERNEL);
>> +if (!state->fake_commit)
>> +return NULL;
>> +
>> +init_commit(state->fake_commit, NULL);
>> +}
>> +
>> +return state->fake_commit;
>> +}
>> +
>>  /**
>>   * drm_atomic_helper_setup_commit - setup possibly nonblocking commit
>>   * @state: new modeset state to be committed
>> @@ -1715,6 +1747,10 @@ int drm_atomic_helper_setup_commit(struct 
>> drm_atomic_state *state,
>>  {
>>  struct drm_crtc *crtc;
>>  struct drm_crtc_state *old_crtc_state, *new_crtc_state;
>> +struct drm_connector *conn;
>> +struct drm_connector_state *old_conn_state, *new_conn_state;
>> +struct drm_plane *plane;
>> +struct drm_plane_state *old_plane_state, *new_plane_state;
>>  struct drm_crtc_commit *commit;
>>  int i, ret;
>>  
>> @@ -1723,12 +1759,7 @@ int drm_atomic_helper_setup_commit(struct 
>> drm_atomic_state *state,

[Bug 102358] WarThunder freezes at start, with activated vsync (vblank_mode=2)

[bugzilla-daemon]

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

--- Comment #18 from Thomas Hellström  ---
FWIW, I got it running under dri3/vsync with the svga driver with no apparent
issue.

It also runs fine with modesetting/svga although there is no true vsync since
the kernel module flips pages instantly.

-- 
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 v8 3/3] drm/rockchip: Add support for Rockchip Soc LVDS

[Mark yao]

Hi Sandy

Looks good for me, so:
Reviewed-by: Mark Yao 

I'd like to apply these lvds patches tomorrow if there is no more doubts.

Best Regards
Mark
On 2017年09月02日 19:28, Sandy Huang wrote:

This adds support for Rockchip soc lvds found on rk3288
Based on the patches from Mark yao and Heiko Stuebner.

Signed-off-by: Mark Yao 
Signed-off-by: Heiko Stuebner 
Signed-off-by: Sandy Huang 
---
Change the Signed-off order

  drivers/gpu/drm/rockchip/Kconfig|   8 +
  drivers/gpu/drm/rockchip/Makefile   |   1 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.c |   2 +
  drivers/gpu/drm/rockchip/rockchip_drm_drv.h |   1 +
  drivers/gpu/drm/rockchip/rockchip_lvds.c| 582 
  drivers/gpu/drm/rockchip/rockchip_lvds.h| 114 ++
  6 files changed, 708 insertions(+)
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.c
  create mode 100644 drivers/gpu/drm/rockchip/rockchip_lvds.h

diff --git a/drivers/gpu/drm/rockchip/Kconfig b/drivers/gpu/drm/rockchip/Kconfig
index dcc539b..0c31f0a 100644
--- a/drivers/gpu/drm/rockchip/Kconfig
+++ b/drivers/gpu/drm/rockchip/Kconfig
@@ -57,4 +57,12 @@ config ROCKCHIP_INNO_HDMI
  for the Innosilicon HDMI driver. If you want to enable
  HDMI on RK3036 based SoC, you should select this option.
  
+config ROCKCHIP_LVDS

+   bool "Rockchip LVDS support"
+   depends on DRM_ROCKCHIP
+   help
+ Choose this option to enable support for Rockchip LVDS controllers.
+ Rockchip rk3288 SoC has LVDS TX Controller can be used, and it
+ support LVDS, rgb, dual LVDS output mode. say Y to enable its
+ driver.
  endif
diff --git a/drivers/gpu/drm/rockchip/Makefile 
b/drivers/gpu/drm/rockchip/Makefile
index fa8dc9d..a881d2c 100644
--- a/drivers/gpu/drm/rockchip/Makefile
+++ b/drivers/gpu/drm/rockchip/Makefile
@@ -12,5 +12,6 @@ rockchipdrm-$(CONFIG_ROCKCHIP_CDN_DP) += cdn-dp-core.o 
cdn-dp-reg.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_HDMI) += dw_hdmi-rockchip.o
  rockchipdrm-$(CONFIG_ROCKCHIP_DW_MIPI_DSI) += dw-mipi-dsi.o
  rockchipdrm-$(CONFIG_ROCKCHIP_INNO_HDMI) += inno_hdmi.o
+rockchipdrm-$(CONFIG_ROCKCHIP_LVDS) += rockchip_lvds.o
  
  obj-$(CONFIG_DRM_ROCKCHIP) += rockchipdrm.o

diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
index c41f48a..082c251 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.c
@@ -445,6 +445,8 @@ static int __init rockchip_drm_init(void)
  
  	num_rockchip_sub_drivers = 0;

ADD_ROCKCHIP_SUB_DRIVER(vop_platform_driver, CONFIG_DRM_ROCKCHIP);
+   ADD_ROCKCHIP_SUB_DRIVER(rockchip_lvds_driver,
+   CONFIG_ROCKCHIP_LVDS);
ADD_ROCKCHIP_SUB_DRIVER(rockchip_dp_driver,
CONFIG_ROCKCHIP_ANALOGIX_DP);
ADD_ROCKCHIP_SUB_DRIVER(cdn_dp_driver, CONFIG_ROCKCHIP_CDN_DP);
diff --git a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h 
b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
index c7e96b8..498dfbc 100644
--- a/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
+++ b/drivers/gpu/drm/rockchip/rockchip_drm_drv.h
@@ -69,5 +69,6 @@ extern struct platform_driver dw_hdmi_rockchip_pltfm_driver;
  extern struct platform_driver dw_mipi_dsi_driver;
  extern struct platform_driver inno_hdmi_driver;
  extern struct platform_driver rockchip_dp_driver;
+extern struct platform_driver rockchip_lvds_driver;
  extern struct platform_driver vop_platform_driver;
  #endif /* _ROCKCHIP_DRM_DRV_H_ */
diff --git a/drivers/gpu/drm/rockchip/rockchip_lvds.c 
b/drivers/gpu/drm/rockchip/rockchip_lvds.c
new file mode 100644
index 000..86d9a8c
--- /dev/null
+++ b/drivers/gpu/drm/rockchip/rockchip_lvds.c
@@ -0,0 +1,582 @@
+/*
+ * Copyright (C) Fuzhou Rockchip Electronics Co.Ltd
+ * Author:
+ *  Mark Yao 
+ *  Sandy Huang 
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program 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.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "rockchip_drm_drv.h"
+#include "rockchip_drm_vop.h"
+#include "rockchip_lvds.h"
+
+#define DISPLAY_OUTPUT_RGB 0
+#define DISPLAY_OUTPUT_LVDS1
+#define DISPLAY_OUTPUT_DUAL_LVDS   2
+
+#define connector_to_lvds(c) \
+   container_of(c, struct rockchip_lvds, connector)
+
+#define encoder_to_lvds(c) \
+   

Re: [PATCH v2 5/6] drm/atomic: Fix freeing connector/plane state too early by tracking commits, v3.

[Daniel Vetter]

On Mon, Sep 04, 2017 at 12:48:37PM +0200, Maarten Lankhorst wrote:
> Currently we neatly track the crtc state, but forget to look at
> plane/connector state.
> 
> When doing a nonblocking modeset, immediately followed by a setprop
> before the modeset completes, the setprop will see the modesets new
> state as the old state and free it.
> 
> This has to be solved by waiting for hw_done on the connector, even
> if it's not assigned to a crtc. When a connector is unbound we take
> the last crtc commit, and when it stays unbound we create a new
> fake crtc commit for that gets signaled on hw_done for all the
> planes/connectors.
> 
> We wait for it the same way as we do for crtc's, which will make
> sure we never run into a use-after-free situation.
> 
> Changes since v1:
> - Only create a single disable commit. (danvet)
> - Fix leak in intel_legacy_cursor_update.
> Changes since v2:
> - Make reference counting in drm_atomic_helper_setup_commit
>   more obvious. (pinchartl)
> - Call cleanup_done for fake commit. (danvet)
> - Add comments to drm_atomic_helper_setup_commit. (danvet, pinchartl)
> - Add comment to drm_atomic_helper_swap_state. (pinchartl)
> 
> Signed-off-by: Maarten Lankhorst 
> Testcase: kms_atomic_transition.plane-use-after-nonblocking-unbind*
> Cc: Laurent Pinchart 
> ---
>  drivers/gpu/drm/drm_atomic.c |   4 +
>  drivers/gpu/drm/drm_atomic_helper.c  | 172 
> +--
>  drivers/gpu/drm/i915/intel_display.c |   2 +
>  include/drm/drm_atomic.h |  12 +++
>  include/drm/drm_connector.h  |   7 ++
>  include/drm/drm_plane.h  |   7 ++
>  6 files changed, 198 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic.c b/drivers/gpu/drm/drm_atomic.c
> index 2cce48f203e0..75f5f74de9bf 100644
> --- a/drivers/gpu/drm/drm_atomic.c
> +++ b/drivers/gpu/drm/drm_atomic.c
> @@ -192,6 +192,10 @@ void drm_atomic_state_default_clear(struct 
> drm_atomic_state *state)
>   }
>   state->num_private_objs = 0;
>  
> + if (state->fake_commit) {
> + drm_crtc_commit_put(state->fake_commit);
> + state->fake_commit = NULL;
> + }
>  }
>  EXPORT_SYMBOL(drm_atomic_state_default_clear);
>  
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 04629d883114..c81d46927a74 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1667,6 +1667,38 @@ static void release_crtc_commit(struct completion 
> *completion)
>   drm_crtc_commit_put(commit);
>  }
>  
> +static void init_commit(struct drm_crtc_commit *commit, struct drm_crtc 
> *crtc)
> +{
> + init_completion(>flip_done);
> + init_completion(>hw_done);
> + init_completion(>cleanup_done);
> + INIT_LIST_HEAD(>commit_entry);
> + kref_init(>ref);
> + commit->crtc = crtc;
> +}
> +
> +static struct drm_crtc_commit *
> +crtc_or_fake_commit(struct drm_atomic_state *state, struct drm_crtc *crtc)

Bikeshed: Would be nice if this function directly increases the refcount,
instead of imposing this on all callers. Would need a rename too like
crtc_or_fake_commit_get().

But since this bug is randomly killing our hsw CI and causing lots of
noise better to push as-is and polish later on.

Reviewed-by: Daniel Vetter 

> +{
> + if (crtc) {
> + struct drm_crtc_state *new_crtc_state;
> +
> + new_crtc_state = drm_atomic_get_new_crtc_state(state, crtc);
> +
> + return new_crtc_state->commit;
> + }
> +
> + if (!state->fake_commit) {
> + state->fake_commit = kzalloc(sizeof(*state->fake_commit), 
> GFP_KERNEL);
> + if (!state->fake_commit)
> + return NULL;
> +
> + init_commit(state->fake_commit, NULL);
> + }
> +
> + return state->fake_commit;
> +}
> +
>  /**
>   * drm_atomic_helper_setup_commit - setup possibly nonblocking commit
>   * @state: new modeset state to be committed
> @@ -1715,6 +1747,10 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>  {
>   struct drm_crtc *crtc;
>   struct drm_crtc_state *old_crtc_state, *new_crtc_state;
> + struct drm_connector *conn;
> + struct drm_connector_state *old_conn_state, *new_conn_state;
> + struct drm_plane *plane;
> + struct drm_plane_state *old_plane_state, *new_plane_state;
>   struct drm_crtc_commit *commit;
>   int i, ret;
>  
> @@ -1723,12 +1759,7 @@ int drm_atomic_helper_setup_commit(struct 
> drm_atomic_state *state,
>   if (!commit)
>   return -ENOMEM;
>  
> - init_completion(>flip_done);
> - init_completion(>hw_done);
> - init_completion(>cleanup_done);
> - INIT_LIST_HEAD(>commit_entry);
> - kref_init(>ref);
> - commit->crtc = crtc;
> + 

Re: [PATCH v2 4/6] drm/atomic: Return commit in drm_crtc_commit_get for better annotation

[Daniel Vetter]

On Mon, Sep 04, 2017 at 12:48:36PM +0200, Maarten Lankhorst wrote:
> This will allow code to do x->commit = drm_crtc_commit_get(commit),
> making it clearer where references are used.
> 
> Signed-off-by: Maarten Lankhorst 

Reviewed-by: Daniel Vetter 

> ---
>  drivers/gpu/drm/drm_atomic_helper.c | 3 +--
>  include/drm/drm_atomic.h| 6 +-
>  2 files changed, 6 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_atomic_helper.c 
> b/drivers/gpu/drm/drm_atomic_helper.c
> index 1f5cdafb050e..04629d883114 100644
> --- a/drivers/gpu/drm/drm_atomic_helper.c
> +++ b/drivers/gpu/drm/drm_atomic_helper.c
> @@ -1633,8 +1633,7 @@ static int stall_checks(struct drm_crtc *crtc, bool 
> nonblock)
>   return -EBUSY;
>   }
>   } else if (i == 1) {
> - stall_commit = commit;
> - drm_crtc_commit_get(stall_commit);
> + stall_commit = drm_crtc_commit_get(commit);
>   break;
>   }
>  
> diff --git a/include/drm/drm_atomic.h b/include/drm/drm_atomic.h
> index 285fbc4ec360..a80a8dadef00 100644
> --- a/include/drm/drm_atomic.h
> +++ b/include/drm/drm_atomic.h
> @@ -251,10 +251,14 @@ void __drm_crtc_commit_free(struct kref *kref);
>   * @commit: CRTC commit
>   *
>   * Increases the reference of @commit.
> + *
> + * Returns:
> + * The pointer to @commit, with reference increased.
>   */
> -static inline void drm_crtc_commit_get(struct drm_crtc_commit *commit)
> +static inline struct drm_crtc_commit *drm_crtc_commit_get(struct 
> drm_crtc_commit *commit)
>  {
>   kref_get(>ref);
> + return commit;
>  }
>  
>  /**
> -- 
> 2.11.0
> 
> ___
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH v2 1/6] drm/i915: Always wait for flip_done, v2.

[Daniel Vetter]

On Mon, Sep 04, 2017 at 12:48:33PM +0200, Maarten Lankhorst wrote:
> The next commit removes the wait for flip_done in in
> drm_atomic_helper_commit_cleanup_done, but we need it for the tests
> to pass. Instead of using complicated vblank tracking which ends
> up being ignored anyway, call the correct atomic helper. :)
> 
> Changes since v1:
> - Always call drm_atomic_helper_wait_for_flip_done,
>   even for legacy cursor updates. (danvet)
> 
> Signed-off-by: Maarten Lankhorst 
> ---
>  drivers/gpu/drm/i915/i915_drv.h  |  3 +-
>  drivers/gpu/drm/i915/intel_display.c | 84 
> +++-
>  2 files changed, 8 insertions(+), 79 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
> index 38bd08f2539b..79533ba6f387 100644
> --- a/drivers/gpu/drm/i915/i915_drv.h
> +++ b/drivers/gpu/drm/i915/i915_drv.h
> @@ -725,8 +725,7 @@ struct drm_i915_display_funcs {
>   struct drm_atomic_state *old_state);
>   void (*crtc_disable)(struct intel_crtc_state *old_crtc_state,
>struct drm_atomic_state *old_state);
> - void (*update_crtcs)(struct drm_atomic_state *state,
> -  unsigned int *crtc_vblank_mask);
> + void (*update_crtcs)(struct drm_atomic_state *state);
>   void (*audio_codec_enable)(struct drm_connector *connector,
>  struct intel_encoder *encoder,
>  const struct drm_display_mode 
> *adjusted_mode);
> diff --git a/drivers/gpu/drm/i915/intel_display.c 
> b/drivers/gpu/drm/i915/intel_display.c
> index 216cd9e0e08f..a6cf1c20c712 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -12136,73 +12136,10 @@ u32 intel_crtc_get_vblank_counter(struct intel_crtc 
> *crtc)
>   return dev->driver->get_vblank_counter(dev, crtc->pipe);
>  }
>  
> -static void intel_atomic_wait_for_vblanks(struct drm_device *dev,
> -   struct drm_i915_private *dev_priv,
> -   unsigned crtc_mask)
> -{
> - unsigned last_vblank_count[I915_MAX_PIPES];
> - enum pipe pipe;
> - int ret;
> -
> - if (!crtc_mask)
> - return;
> -
> - for_each_pipe(dev_priv, pipe) {
> - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> -   pipe);
> -
> - if (!((1 << pipe) & crtc_mask))
> - continue;
> -
> - ret = drm_crtc_vblank_get(>base);
> - if (WARN_ON(ret != 0)) {
> - crtc_mask &= ~(1 << pipe);
> - continue;
> - }
> -
> - last_vblank_count[pipe] = drm_crtc_vblank_count(>base);
> - }
> -
> - for_each_pipe(dev_priv, pipe) {
> - struct intel_crtc *crtc = intel_get_crtc_for_pipe(dev_priv,
> -   pipe);
> - long lret;
> -
> - if (!((1 << pipe) & crtc_mask))
> - continue;
> -
> - lret = wait_event_timeout(dev->vblank[pipe].queue,
> - last_vblank_count[pipe] !=
> - drm_crtc_vblank_count(>base),
> - msecs_to_jiffies(50));
> -
> - WARN(!lret, "pipe %c vblank wait timed out\n", pipe_name(pipe));
> -
> - drm_crtc_vblank_put(>base);
> - }
> -}
> -
> -static bool needs_vblank_wait(struct intel_crtc_state *crtc_state)
> -{
> - /* fb updated, need to unpin old fb */
> - if (crtc_state->fb_changed)
> - return true;
> -
> - /* wm changes, need vblank before final wm's */
> - if (crtc_state->update_wm_post)
> - return true;
> -
> - if (crtc_state->wm.need_postvbl_update)
> - return true;
> -
> - return false;
> -}
> -
>  static void intel_update_crtc(struct drm_crtc *crtc,
> struct drm_atomic_state *state,
> struct drm_crtc_state *old_crtc_state,
> -   struct drm_crtc_state *new_crtc_state,
> -   unsigned int *crtc_vblank_mask)
> +   struct drm_crtc_state *new_crtc_state)
>  {
>   struct drm_device *dev = crtc->dev;
>   struct drm_i915_private *dev_priv = to_i915(dev);
> @@ -12225,13 +12162,9 @@ static void intel_update_crtc(struct drm_crtc *crtc,
>   }
>  
>   drm_atomic_helper_commit_planes_on_crtc(old_crtc_state);
> -
> - if (needs_vblank_wait(pipe_config))
> - *crtc_vblank_mask |= drm_crtc_mask(crtc);
>  }
>  
> -static void intel_update_crtcs(struct drm_atomic_state *state,
> -unsigned int *crtc_vblank_mask)
> +static void intel_update_crtcs(struct drm_atomic_state *state)
>  {

[Bug 102543] [BAT][HSW] igt@tools_test@tools_test - Unclaimed read from register 0x[4c]400c

[bugzilla-daemon]

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

--- Comment #4 from Chris Wilson  ---
E.g. https://patchwork.freedesktop.org/series/29935/

-- 
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 v2 1/3] [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific version

[Hoegeun Kwon]

Exynos 5250 and 5420 have different hardware rotation limits.
Since we have to distinguish between these two, we add different
compatible(samsung,exynos5250-gsc and samsung,exynos5420-gsc).

Signed-off-by: Hoegeun Kwon 
---
 Documentation/devicetree/bindings/media/exynos5-gsc.txt | 1 +
 1 file changed, 1 insertion(+)

diff --git a/Documentation/devicetree/bindings/media/exynos5-gsc.txt 
b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
index 26ca25b..daa56d5 100644
--- a/Documentation/devicetree/bindings/media/exynos5-gsc.txt
+++ b/Documentation/devicetree/bindings/media/exynos5-gsc.txt
@@ -5,6 +5,7 @@ G-Scaler is used for scaling and color space conversion on 
EXYNOS5 SoCs.
 Required properties:
 - compatible: should be "samsung,exynos5-gsc" (for Exynos 5250, 5420 and
  5422 SoCs) or "samsung,exynos5433-gsc" (Exynos 5433)
+ or "samsung,exynos5250-gsc" or "samsung,exynos5420-gsc"
 - reg: should contain G-Scaler physical address location and length.
 - interrupts: should contain G-Scaler interrupt number
 
-- 
1.9.1

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

[PATCH v2 0/3] drm/exynos/gsc: Support the hardware rotation limits

[Hoegeun Kwon]

Hello all,

The gscaler has hardware rotation limits. So this patch set support
the rotate hardware limits of gsc.

Changes for V2:
- Added the interface info in binding document.
- Added clean name of compatible in Exynos dts.
- Added maximum supported picture size hardcoded into driver.

Best regards,
Hoegeun

Hoegeun Kwon (3):
  [media] exynos-gsc: Add compatible for Exynos 5250 and 5420 specific
version
  ARM: dts: exynos: Add clean name of compatible.
  drm/exynos/gsc: Add hardware rotation limits

 .../devicetree/bindings/media/exynos5-gsc.txt  |   1 +
 arch/arm/boot/dts/exynos5250.dtsi  |   8 +-
 arch/arm/boot/dts/exynos5420.dtsi  |   4 +-
 drivers/gpu/drm/exynos/exynos_drm_gsc.c| 100 +++--
 include/uapi/drm/exynos_drm.h  |   2 +
 5 files changed, 80 insertions(+), 35 deletions(-)

-- 
1.9.1

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

[PATCH v2 2/3] ARM: dts: exynos: Add clean name of compatible.

[Hoegeun Kwon]

Exynos 5250 and 5420 have different hardware rotation limits. However,
currently it uses only one compatible - "exynos5-gsc". Since we have
to distinguish between these two, we add different compatible.

Signed-off-by: Hoegeun Kwon 
---
 arch/arm/boot/dts/exynos5250.dtsi | 8 
 arch/arm/boot/dts/exynos5420.dtsi | 4 ++--
 2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/arch/arm/boot/dts/exynos5250.dtsi 
b/arch/arm/boot/dts/exynos5250.dtsi
index 8dbeb87..f795c76 100644
--- a/arch/arm/boot/dts/exynos5250.dtsi
+++ b/arch/arm/boot/dts/exynos5250.dtsi
@@ -637,7 +637,7 @@
};
 
gsc_0:  gsc@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -647,7 +647,7 @@
};
 
gsc_1:  gsc@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -657,7 +657,7 @@
};
 
gsc_2:  gsc@13e2 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e2 0x1000>;
interrupts = ;
power-domains = <_gsc>;
@@ -667,7 +667,7 @@
};
 
gsc_3:  gsc@13e3 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
samsung,exynos5250-gsc";
reg = <0x13e3 0x1000>;
interrupts = ;
power-domains = <_gsc>;
diff --git a/arch/arm/boot/dts/exynos5420.dtsi 
b/arch/arm/boot/dts/exynos5420.dtsi
index 02d2f89..86afe77 100644
--- a/arch/arm/boot/dts/exynos5420.dtsi
+++ b/arch/arm/boot/dts/exynos5420.dtsi
@@ -658,7 +658,7 @@
};
 
gsc_0: video-scaler@13e0 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e0 0x1000>;
interrupts = ;
clocks = < CLK_GSCL0>;
@@ -668,7 +668,7 @@
};
 
gsc_1: video-scaler@13e1 {
-   compatible = "samsung,exynos5-gsc";
+   compatible = "samsung,exynos5-gsc", 
"samsung,exynos5420-gsc";
reg = <0x13e1 0x1000>;
interrupts = ;
clocks = < CLK_GSCL1>;
-- 
1.9.1

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

[PATCH v2 3/3] drm/exynos/gsc: Add hardware rotation limits

[Hoegeun Kwon]

The gscaler has hardware rotation limits that need to be hardcoded
into driver. Distinguish them and add them to the property list.

The hardware rotation limits are related to the cropped source size.
When swap occurs, use rot_max size instead of crop_max size.

Also the scaling limits are related to pos size, use pos size to check
the limits.

Signed-off-by: Hoegeun Kwon 
---
 drivers/gpu/drm/exynos/exynos_drm_gsc.c | 100 +++-
 include/uapi/drm/exynos_drm.h   |   2 +
 2 files changed, 73 insertions(+), 29 deletions(-)

diff --git a/drivers/gpu/drm/exynos/exynos_drm_gsc.c 
b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
index 0506b2b..590a645 100644
--- a/drivers/gpu/drm/exynos/exynos_drm_gsc.c
+++ b/drivers/gpu/drm/exynos/exynos_drm_gsc.c
@@ -150,6 +150,15 @@ struct gsc_context {
boolsuspended;
 };
 
+/*
+ * struct gsc_driverdata - per device type driver data for init time.
+ *
+ * @rot_max: rotation max resolution.
+ */
+struct gsc_driverdata {
+   struct drm_exynos_sz rot_max;
+};
+
 /* 8-tap Filter Coefficient */
 static const int h_coef_8t[GSC_COEF_RATIO][GSC_COEF_ATTR][GSC_COEF_H_8T] = {
{   /* Ratio <= 65536 (~8:8) */
@@ -1401,6 +1410,23 @@ static int gsc_ippdrv_check_property(struct device *dev,
bool swap;
int i;
 
+   config = >config[EXYNOS_DRM_OPS_DST];
+
+   /* check for degree */
+   switch (config->degree) {
+   case EXYNOS_DRM_DEGREE_90:
+   case EXYNOS_DRM_DEGREE_270:
+   swap = true;
+   break;
+   case EXYNOS_DRM_DEGREE_0:
+   case EXYNOS_DRM_DEGREE_180:
+   swap = false;
+   break;
+   default:
+   DRM_ERROR("invalid degree.\n");
+   goto err_property;
+   }
+
for_each_ipp_ops(i) {
if ((i == EXYNOS_DRM_OPS_SRC) &&
(property->cmd == IPP_CMD_WB))
@@ -1416,21 +1442,6 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
-   /* check for degree */
-   switch (config->degree) {
-   case EXYNOS_DRM_DEGREE_90:
-   case EXYNOS_DRM_DEGREE_270:
-   swap = true;
-   break;
-   case EXYNOS_DRM_DEGREE_0:
-   case EXYNOS_DRM_DEGREE_180:
-   swap = false;
-   break;
-   default:
-   DRM_ERROR("invalid degree.\n");
-   goto err_property;
-   }
-
/* check for buffer bound */
if ((pos->x + pos->w > sz->hsize) ||
(pos->y + pos->h > sz->vsize)) {
@@ -1438,21 +1449,27 @@ static int gsc_ippdrv_check_property(struct device *dev,
goto err_property;
}
 
+   /*
+* The rotation hardware limits are related to the cropped
+* source size. So use rot_max size to check the limits when
+* swap happens. And also the scaling limits are related to pos
+* size, use pos size to check the limits.
+*/
/* check for crop */
if ((i == EXYNOS_DRM_OPS_SRC) && (pp->crop)) {
if (swap) {
if ((pos->h < pp->crop_min.hsize) ||
-   (sz->vsize > pp->crop_max.hsize) ||
+   (pos->h > pp->rot_max.hsize) ||
(pos->w < pp->crop_min.vsize) ||
-   (sz->hsize > pp->crop_max.vsize)) {
+   (pos->w > pp->rot_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
} else {
if ((pos->w < pp->crop_min.hsize) ||
-   (sz->hsize > pp->crop_max.hsize) ||
+   (pos->w > pp->crop_max.hsize) ||
(pos->h < pp->crop_min.vsize) ||
-   (sz->vsize > pp->crop_max.vsize)) {
+   (pos->h > pp->crop_max.vsize)) {
DRM_ERROR("out of crop size.\n");
goto err_property;
}
@@ -1463,17 +1480,17 @@ static int gsc_ippdrv_check_property(struct device *dev,
if ((i == EXYNOS_DRM_OPS_DST) && (pp->scale)) {
if (swap) {
if ((pos->h < pp->scale_min.hsize) ||
-   (sz->vsize > pp->scale_max.hsize) ||
+ 

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

[Archit Taneja]

Hi,

On 08/31/2017 09:25 PM, Boris Brezillon wrote:

Add a driver for Cadence DPI -> DSI bridge.

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

Here is a non-exhaustive list of missing features:
  * burst mode
  * dynamic configuration of the DPHY based on the
  * support for additional input interfaces (SDI input)

Signed-off-by: Boris Brezillon 
---
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
---
  drivers/gpu/drm/bridge/Kconfig|9 +
  drivers/gpu/drm/bridge/Makefile   |1 +
  drivers/gpu/drm/bridge/cdns-dsi.c | 1090 +
  3 files changed, 1100 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 adf9ae0e0b7c..88c324b12e16 100644
--- a/drivers/gpu/drm/bridge/Kconfig
+++ b/drivers/gpu/drm/bridge/Kconfig
@@ -25,6 +25,15 @@ 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
+   depends on OF
+   help
+ Support Cadence DPI to DSI bridge.


Maybe we can briefly mention here that it's a internal bridge/IP, and not an 
external chip?


+
  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 defcf1e7ca1c..77b65e8ecf59 100644
--- a/drivers/gpu/drm/bridge/Makefile
+++ b/drivers/gpu/drm/bridge/Makefile
@@ -1,4 +1,5 @@
  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





+
+static void cdns_dsi_bridge_disable(struct drm_bridge *bridge)
+{
+   struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
+   struct cdns_dsi *dsi = input_to_dsi(input);
+   u32 val;
+
+   val = readl(dsi->regs + MCTL_MAIN_DATA_CTL);
+   val &= ~(IF_VID_SELECT_MASK | IF_VID_MODE | VID_EN | HOST_EOT_GEN |
+DISP_EOT_GEN);


I see some truncation related sparse warnings here and a couple of other places
when building against arm32. Those would be nice to fix.


+   writel(val, dsi->regs + MCTL_MAIN_DATA_CTL);
+
+   val = readl(dsi->regs + MCTL_MAIN_EN) & ~IF_EN(input->id);
+   writel(val, dsi->regs + MCTL_MAIN_EN);
+}
+
+#define DSI_HBP_FRAME_OVERHEAD 12
+#define DSI_HSA_FRAME_OVERHEAD 14
+#define DSI_HFP_FRAME_OVERHEAD 6
+#define DSI_HSS_VSS_VSE_FRAME_OVERHEAD 4
+#define DSI_BLANKING_FRAME_OVERHEAD6
+#define DSI_NULL_FRAME_OVERHEAD6
+#define DSI_EOT_PKT_SIZE   4
+
+#define REG_WAKEUP_TIME_NS 800
+#define DPHY_PLL_RATE_HZ   10800
+
+static void cdns_dsi_bridge_enable(struct drm_bridge *bridge)
+{
+   struct cdns_dsi_input *input = bridge_to_cdns_dsi_input(bridge);
+   struct cdns_dsi *dsi = input_to_dsi(input);
+   struct cdns_dsi_output *output = >output;
+   u32 hsize0, hsa, hline, tmp, reg_wakeup, div;
+   unsigned long dphy_pll_period, tx_byte_period;
+   struct drm_display_mode *mode;
+   int bpp, nlanes;
+
+   mode = >encoder->crtc->state->adjusted_mode;
+   bpp = mipi_dsi_pixel_format_to_bpp(output->dev->format);
+   nlanes = output->dev->lanes;
+
+   if (output->dev->mode_flags & MIPI_DSI_MODE_VIDEO_SYNC_PULSE)
+   tmp = mode->crtc_htotal - mode->crtc_hsync_end;
+   else
+   tmp = mode->crtc_htotal - mode->crtc_hsync_start;
+   tmp = (tmp * bpp) / 8;
+   tmp = tmp < DSI_HBP_FRAME_OVERHEAD ? 0 : tmp - DSI_HBP_FRAME_OVERHEAD;
+   hsize0 = HBP_LEN(tmp);
+
+   tmp = mode->crtc_hsync_start - mode->crtc_hdisplay;
+   tmp = (tmp * bpp) / 8;
+   tmp = tmp < DSI_HFP_FRAME_OVERHEAD ? 0 : tmp - DSI_HFP_FRAME_OVERHEAD;
+   hsize0 |= HFP_LEN(tmp);
+
+   if 

[Bug 102543] [BAT][HSW] igt@tools_test@tools_test - Unclaimed read from register 0x[4c]400c

[bugzilla-daemon]

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

--- Comment #3 from Chris Wilson  ---
>From our pov, no. The highlighted commit was just the merge to 4.13. But the
failure does depend upon i915 doing something during the test, but the test
itself bypasses i915 for direct hw access.

What we could do is to disable automatic mmio checking if user forcewake is
taken. Then clear any errors upon 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

Re: [PATCH 1/2] dma-buf: make reservation_object_copy_fences rcu save

[zhoucm1]

On 2017年09月07日 15:13, Christian König wrote:

Ping? David can you take a look?

Alex is on vacation and that is a rather important bug fix.

Thanks,
Christian.

Am 04.09.2017 um 21:02 schrieb Christian König:

From: Christian König 

Stop requiring that the src reservation object is locked for this 
operation.


Signed-off-by: Christian König 
---
  drivers/dma-buf/reservation.c | 56 
---

  1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/reservation.c 
b/drivers/dma-buf/reservation.c

index dec3a81..b44d9d7 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
  * @dst: the destination reservation object
  * @src: the source reservation object
  *
-* Copy all fences from src to dst. Both src->lock as well as 
dst-lock must be

-* held.
+* Copy all fences from src to dst. dst-lock must be held.
  */
  int reservation_object_copy_fences(struct reservation_object *dst,
 struct reservation_object *src)
@@ -277,33 +276,62 @@ int reservation_object_copy_fences(struct 
reservation_object *dst,

  size_t size;
  unsigned i;
  -src_list = reservation_object_get_list(src);
+rcu_read_lock();
+src_list = rcu_dereference(src->fence);
  +retry:
  if (src_list) {
-size = offsetof(typeof(*src_list),
-shared[src_list->shared_count]);
+unsigned shared_count = src_list->shared_count;
+
+size = offsetof(typeof(*src_list), shared[shared_count]);
+rcu_read_unlock();
+
  dst_list = kmalloc(size, GFP_KERNEL);
  if (!dst_list)
  return -ENOMEM;
  -dst_list->shared_count = src_list->shared_count;
-dst_list->shared_max = src_list->shared_count;
-for (i = 0; i < src_list->shared_count; ++i)
-dst_list->shared[i] =
-dma_fence_get(src_list->shared[i]);
+rcu_read_lock();
+src_list = rcu_dereference(src->fence);
+if (!src_list || src_list->shared_count > shared_count) {
+kfree(dst_list);
+goto retry;
+}
+
+dst_list->shared_count = 0;
+dst_list->shared_max = shared_count;
+for (i = 0; i < src_list->shared_count; ++i) {
+struct dma_fence *fence;
+
+fence = rcu_dereference(src_list->shared[i]);
+if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+ >flags))
seems here is duplicated with the below dma_fence_is_signaled, can it be 
removed?


And I'm not sure the locking, but it looks good, so Acked-by: Chunming 
Zhou 

+continue;
+
+if (!dma_fence_get_rcu(fence)) {
+kfree(dst_list);
+src_list = rcu_dereference(src->fence);
+goto retry;
+}
+
+if (dma_fence_is_signaled(fence)) {
+dma_fence_put(fence);
+continue;
+}
+
+dst_list->shared[dst_list->shared_count++] = fence;
+}
  } else {
  dst_list = NULL;
  }
  +new = dma_fence_get_rcu_safe(>fence_excl);
+rcu_read_unlock();
+
  kfree(dst->staged);
  dst->staged = NULL;
src_list = reservation_object_get_list(dst);
-
  old = reservation_object_get_excl(dst);
-new = reservation_object_get_excl(src);
-
-dma_fence_get(new);
preempt_disable();
  write_seqcount_begin(>seq);





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

[Bug 102543] [BAT][HSW] igt@tools_test@tools_test - Unclaimed read from register 0x[4c]400c

[bugzilla-daemon]

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

--- Comment #2 from Martin Peres  ---
The test has been passing recently. Has anything changed?

-- 
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 v2 1/2] drm/bridge: add Silicon Image SiI9234 driver

[Andrzej Hajda]

Hi Laurent,

On 05.09.2017 17:05, Laurent Pinchart wrote:
> Hi Maciej,
>
> On Tuesday, 5 September 2017 16:01:54 EEST Maciej Purski wrote:
>> Hi Laurent,
>>
>> Thank you for your reply. The problem was already discussed when adding
>> sil8620 driver. It can be solved later. I'm CC-ing Andrzej Hajda, as he
>> used to discuss it with you.
> I'm afraid it can't be solved later. DT bindings are supposed to be a stable 
> ABI, we can't merge a binding that we already know isn't correct.

The problem here is that bridge output is connected to micro-USB
connector(not HDMI !!!).
And currently there are no bindings for micro-USB connector. Creating
good bindings can be tricky
because micro-USB connector can be used to multiple functions:
- USB,
- charging,
- UART,
- MHL,
- audio,
- ...
And it can be controlled by different chips (MUICs), with different
capabilities.

I plan to send RFC in near future of such bindings (as I need them for
sii8620), but I guess it would require more review before it will be
accepted.

Returning to SiI9234, solution would be to add output port bindings to
SiI9234, but do not add them to dts. It will make bindings for Sii9234
complete.

Regards
Andrzej


>
>> https://patchwork.freedesktop.org/patch/114224/
>> https://lists.freedesktop.org/archives/dri-devel/2015-December/096756.html
>>
>> Regards,
>>
>>  Maciej
>>
>> On 31/08/17 15:30, Laurent Pinchart wrote:
>>> Hi Maciej,
>>>
>>> Thank you for the patch.
>>>
>>> On Thursday, 31 August 2017 15:27:13 EEST Maciej Purski wrote:
 SiI9234 transmitter converts eTMDS/HDMI signal to MHL 1.0.
 It is controlled via I2C bus. Its interaction with other
 devices in video pipeline is performed mainly on HW level.
 The only interaction it does on device driver level is
 filtering-out unsupported video modes, it exposes drm_bridge
 interface to perform this operation.

 This patch is based on the code refactored by Tomasz Stanislawski
 , which was initially developed by:
 Adam Hampson 
 Erik Gilling 
 Shankar Bandal 
 Dharam Kumar 

 Signed-off-by: Maciej Purski 
 ---
 Changes in v2:
 - use bulk_requlators instead of single one
 - substitute some of the magic values with macros
 - improve coding style
 - improved error handling in sii9234_probe()
 ---

   .../devicetree/bindings/display/bridge/sii9234.txt |  34 +
   drivers/gpu/drm/bridge/Kconfig |   8 +
   drivers/gpu/drm/bridge/Makefile|   1 +
   drivers/gpu/drm/bridge/sii9234.c   | 993
   ++
   4 files changed, 1036 insertions(+)
   create mode 100644

 Documentation/devicetree/bindings/display/bridge/sii9234.txt create mode
 100644 drivers/gpu/drm/bridge/sii9234.c

 diff --git a/Documentation/devicetree/bindings/display/bridge/sii9234.txt
 b/Documentation/devicetree/bindings/display/bridge/sii9234.txt new file
 mode 100644
 index 000..3ce7413
 --- /dev/null
 +++ b/Documentation/devicetree/bindings/display/bridge/sii9234.txt
 @@ -0,0 +1,34 @@
 +Silicon Image SiI9234 HDMI/MHL bridge bindings
 +
 +Required properties:
 +  - compatible : "sil,sii9234".
 +  - reg : I2C address for TPI interface, use 0x39
 +  - avcc33-supply : MHL/USB Switch Supply Voltage (3.3V)
 +  - iovcc18-supply : I/O Supply Voltage (1.8V)
 +  - avcc12-supply : TMDS Analog Supply Voltage (1.2V)
 +  - cvcc12-supply : Digital Core Supply Voltage (1.2V)
 +  - interrupts, interrupt-parent: interrupt specifier of INT pin
 +  - reset-gpios: gpio specifier of RESET pin (active low)
 +  - video interfaces: Device node can contain video interface port
 +  node for HDMI encoder according to [1].
 +
 +[1]: Documentation/devicetree/bindings/media/video-interfaces.txt
>>> Doesn't this chip have two ports, one input connected to the SoC and one
>>> output connected to an HDMI connector ? If so there should be two ports in
>>> DT too.
>>>
 +Example:
 +  sii9234@39 {
 +  compatible = "sil,sii9234";
 +  reg = <0x39>;
 +  avcc33-supply = <>;
 +  iovcc18-supply = <>;
 +  avcc12-supply = <>;
 +  cvcc12-supply = <>;
 +  reset-gpios = < 4 GPIO_ACTIVE_LOW>;
 +  interrupt-parent = <>;
 +  interrupts = <5 IRQ_TYPE_LEVEL_HIGH>;
 +
 +  port {
 +  mhl_to_hdmi: endpoint {
 +  remote-endpoint = <_to_mhl>;
>>> It would be useful to include the remote DT nodes in the example too.
>>>
 +  };
 +  };
 +  };
>

___
dri-devel mailing list

Re: [PATCH 2/2] drm/ttm: fix ttm_bo_cleanup_refs_or_queue once more

[zhoucm1]

Acked-by: Chunming Zhou 


On 2017年09月05日 03:02, Christian König wrote:

From: Christian König 

With shared reservation objects __ttm_bo_reserve() can easily fail even on
destroyed BOs. This prevents correct handling when we need to individualize
the reservation object.

Fix this by individualizing the object before even trying to reserve it.

Signed-off-by: Christian König 
---
  drivers/gpu/drm/ttm/ttm_bo.c | 32 +---
  1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/drivers/gpu/drm/ttm/ttm_bo.c
index 180ce62..bee77d3 100644
--- a/drivers/gpu/drm/ttm/ttm_bo.c
+++ b/drivers/gpu/drm/ttm/ttm_bo.c
@@ -440,28 +440,29 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
struct ttm_bo_global *glob = bo->glob;
int ret;
  
+	ret = ttm_bo_individualize_resv(bo);

+   if (ret) {
+   /* Last resort, if we fail to allocate memory for the
+* fences block for the BO to become idle
+*/
+   reservation_object_wait_timeout_rcu(bo->resv, true, false,
+   30 * HZ);
+   spin_lock(>lru_lock);
+   goto error;
+   }
+
spin_lock(>lru_lock);
ret = __ttm_bo_reserve(bo, false, true, NULL);
-
if (!ret) {
-   if (!ttm_bo_wait(bo, false, true)) {
+   if (reservation_object_test_signaled_rcu(>ttm_resv, true)) {
ttm_bo_del_from_lru(bo);
spin_unlock(>lru_lock);
+   if (bo->resv != >ttm_resv)
+   reservation_object_unlock(>ttm_resv);
ttm_bo_cleanup_memtype_use(bo);
-
return;
}
  
-		ret = ttm_bo_individualize_resv(bo);

-   if (ret) {
-   /* Last resort, if we fail to allocate memory for the
-* fences block for the BO to become idle and free it.
-*/
-   spin_unlock(>lru_lock);
-   ttm_bo_wait(bo, true, true);
-   ttm_bo_cleanup_memtype_use(bo);
-   return;
-   }
ttm_bo_flush_all_fences(bo);
  
  		/*

@@ -474,11 +475,12 @@ static void ttm_bo_cleanup_refs_or_queue(struct 
ttm_buffer_object *bo)
ttm_bo_add_to_lru(bo);
}
  
-		if (bo->resv != >ttm_resv)

-   reservation_object_unlock(>ttm_resv);
__ttm_bo_unreserve(bo);
}
+   if (bo->resv != >ttm_resv)
+   reservation_object_unlock(>ttm_resv);
  
+error:

kref_get(>list_kref);
list_add_tail(>ddestroy, >ddestroy);
spin_unlock(>lru_lock);


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

[Bug 102242] [CI] assert(level < 128) failed for igt@pm_rpm@sysfs-read

[bugzilla-daemon]

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

Martin Peres  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #8 from Martin Peres  ---
Verified fixed! Thanks Chris!

-- 
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/2] dma-buf: make reservation_object_copy_fences rcu save

[Christian König]

Ping? David can you take a look?

Alex is on vacation and that is a rather important bug fix.

Thanks,
Christian.

Am 04.09.2017 um 21:02 schrieb Christian König:

From: Christian König 

Stop requiring that the src reservation object is locked for this operation.

Signed-off-by: Christian König 
---
  drivers/dma-buf/reservation.c | 56 ---
  1 file changed, 42 insertions(+), 14 deletions(-)

diff --git a/drivers/dma-buf/reservation.c b/drivers/dma-buf/reservation.c
index dec3a81..b44d9d7 100644
--- a/drivers/dma-buf/reservation.c
+++ b/drivers/dma-buf/reservation.c
@@ -266,8 +266,7 @@ EXPORT_SYMBOL(reservation_object_add_excl_fence);
  * @dst: the destination reservation object
  * @src: the source reservation object
  *
-* Copy all fences from src to dst. Both src->lock as well as dst-lock must be
-* held.
+* Copy all fences from src to dst. dst-lock must be held.
  */
  int reservation_object_copy_fences(struct reservation_object *dst,
   struct reservation_object *src)
@@ -277,33 +276,62 @@ int reservation_object_copy_fences(struct 
reservation_object *dst,
size_t size;
unsigned i;
  
-	src_list = reservation_object_get_list(src);

+   rcu_read_lock();
+   src_list = rcu_dereference(src->fence);
  
+retry:

if (src_list) {
-   size = offsetof(typeof(*src_list),
-   shared[src_list->shared_count]);
+   unsigned shared_count = src_list->shared_count;
+
+   size = offsetof(typeof(*src_list), shared[shared_count]);
+   rcu_read_unlock();
+
dst_list = kmalloc(size, GFP_KERNEL);
if (!dst_list)
return -ENOMEM;
  
-		dst_list->shared_count = src_list->shared_count;

-   dst_list->shared_max = src_list->shared_count;
-   for (i = 0; i < src_list->shared_count; ++i)
-   dst_list->shared[i] =
-   dma_fence_get(src_list->shared[i]);
+   rcu_read_lock();
+   src_list = rcu_dereference(src->fence);
+   if (!src_list || src_list->shared_count > shared_count) {
+   kfree(dst_list);
+   goto retry;
+   }
+
+   dst_list->shared_count = 0;
+   dst_list->shared_max = shared_count;
+   for (i = 0; i < src_list->shared_count; ++i) {
+   struct dma_fence *fence;
+
+   fence = rcu_dereference(src_list->shared[i]);
+   if (test_bit(DMA_FENCE_FLAG_SIGNALED_BIT,
+>flags))
+   continue;
+
+   if (!dma_fence_get_rcu(fence)) {
+   kfree(dst_list);
+   src_list = rcu_dereference(src->fence);
+   goto retry;
+   }
+
+   if (dma_fence_is_signaled(fence)) {
+   dma_fence_put(fence);
+   continue;
+   }
+
+   dst_list->shared[dst_list->shared_count++] = fence;
+   }
} else {
dst_list = NULL;
}
  
+	new = dma_fence_get_rcu_safe(>fence_excl);

+   rcu_read_unlock();
+
kfree(dst->staged);
dst->staged = NULL;
  
  	src_list = reservation_object_get_list(dst);

-
old = reservation_object_get_excl(dst);
-   new = reservation_object_get_excl(src);
-
-   dma_fence_get(new);
  
  	preempt_disable();

write_seqcount_begin(>seq);



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

[Bug 102574] glDrawBuffer crashes in case of surfaceless context

[bugzilla-daemon]

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

Bug ID: 102574
   Summary: glDrawBuffer crashes in case of surfaceless context
   Product: Mesa
   Version: 17.1
  Hardware: x86-64 (AMD64)
OS: Linux (All)
Status: NEW
  Severity: normal
  Priority: medium
 Component: Drivers/DRI/i915
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: v.vogelhu...@digitalendoscopy.de
QA Contact: dri-devel@lists.freedesktop.org

I've created a surfaceless OpenGL context using the EGL_KHR_surfaceless_context
extension together with eglGetPlatformDisplay/EGL_PLATFORM_GBM_MESA.
In this scenario there seem to be no valid default framebuffer which is Ok, as
I'm normally only render to FBOs with textures bound. Due to an error on my
side I called glDrawBuffer with GL_FRONT_LEFT while no FBO was bound.

This result in a crash in intel_buffers.c because in intelDrawBuffer()
dri2InvalidateDrawable is called with a null pointer which is
not checked in dri2InvalidateDrawable() or anywhere before.

While the root cause for triggering the error is on my side,
I think it may be better to raise an error instead of crashing.
So I propose to add a check to brw->driContext->driDrawablePriv
within intelDrawBuffer. Probably if the driDrawablePriv is nullptr
one should not call intel_prepare_render either. 

Mesa 17.1 with Kernel 4.9.6 on Intel Apollo Lake GPU

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