Re: [PATCH] drm/amdgpu/display: fix wrong enum type for ddc_result

[kbuild test robot]

Hi Dominik,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/dbehr-chromium-org/drm-amdgpu-display-fix-wrong-enum-type-for-ddc_result/20180204-091310
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: x86_64-randconfig-s3-02041012 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
# save the attached .config to linux build tree
make ARCH=x86_64 

All warnings (new ones prefixed by >>):

   In file included from include/uapi/linux/swab.h:6:0,
from include/linux/swab.h:5,
from include/uapi/linux/byteorder/little_endian.h:13,
from include/linux/byteorder/little_endian.h:5,
from arch/x86/include/uapi/asm/byteorder.h:5,
from drivers/gpu/drm/amd/amdgpu/../display/dc/os_types.h:29,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services_types.h:29,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/dm_services.h:35,
from 
drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:2:
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function 
'dc_link_handle_hpd_rx_irq':
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:13: warning: 
comparison between 'enum ddc_result' and 'enum dc_status' [-Wenum-compare]
 if (result != DC_OK) {
^
   include/linux/compiler.h:58:30: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:2: note: in 
>> expansion of macro 'if'
 if (result != DC_OK) {
 ^~
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:13: warning: 
comparison between 'enum ddc_result' and 'enum dc_status' [-Wenum-compare]
 if (result != DC_OK) {
^
   include/linux/compiler.h:58:42: note: in definition of macro '__trace_if'
 if (__builtin_constant_p(!!(cond)) ? !!(cond) :   \
 ^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:2: note: in 
>> expansion of macro 'if'
 if (result != DC_OK) {
 ^~
   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:13: warning: 
comparison between 'enum ddc_result' and 'enum dc_status' [-Wenum-compare]
 if (result != DC_OK) {
^
   include/linux/compiler.h:69:16: note: in definition of macro '__trace_if'
  __r = !!(cond); \
   ^~~~
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:2: note: in 
>> expansion of macro 'if'
 if (result != DC_OK) {
 ^~

vim +/if +1949 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c

4562236b3b Harry Wentland 2017-09-12  1924  
d0778ebfd5 Harry Wentland 2017-07-22  1925  bool 
dc_link_handle_hpd_rx_irq(struct dc_link *link, union hpd_irq_data 
*out_hpd_irq_dpcd_data)
4562236b3b Harry Wentland 2017-09-12  1926  {
4562236b3b Harry Wentland 2017-09-12  1927  union hpd_irq_data 
hpd_irq_dpcd_data = 0;
c2e218dda0 Harry Wentland 2017-02-24  1928  union device_service_irq 
device_service_clear = { { 0 } };
698569c574 Dominik Behr   2018-02-01  1929  enum ddc_result result = 
DDC_RESULT_UNKNOWN;
4562236b3b Harry Wentland 2017-09-12  1930  bool status = false;
4562236b3b Harry Wentland 2017-09-12  1931  /* For use cases related to 
down stream connection status change,
4562236b3b Harry Wentland 2017-09-12  1932   * PSR and device auto test, 
refer to function handle_sst_hpd_irq
4562236b3b Harry Wentland 2017-09-12  1933   * in DAL2.1*/
4562236b3b Harry Wentland 2017-09-12  1934  
4562236b3b Harry Wentland 2017-09-12  1935  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 2017-09-12  1936  "%s: Got short pulse 
HPD on link %d\n",
d0778ebfd5 Harry Wentland 2017-07-22  1937  __func__, 
link->link_index);
4562236b3b Harry Wentland 2017-09-12  1938  
8ee65d7c93 Wenjing Liu2017-07-19  1939  
4562236b3b Harry Wentland 2017-09-12  1940   /* All the 
"handle_hpd_irq_xxx()" methods
4562236b3b Harry Wentland 2017-09-12  1941   * should be called 
only after
4562236b3b Harry Wentland 2017-09-12  1942   * 
dal_dpsst_ls_read_hpd_irq_data
4562236b3b Harry Wentland 2017-09-12  1943   * Order of calls is 
important too
4562236b3b Harry Wentland 2017-09-12  1944   */
4562236b3b Harry Wentland 2017-09-12  1945  result = 
read_hpd_rx_irq_data(link, _irq_dpcd_data);
8ee65d7c93 Wenjing Liu2017-07-19  1946  if (out_hpd_irq_dpcd_data)
8ee65d7c93 

Re: [PATCH] drm/amdgpu/display: fix wrong enum type for ddc_result

[kbuild test robot]

Hi Dominik,

Thank you for the patch! Perhaps something to improve:

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

url:
https://github.com/0day-ci/linux/commits/dbehr-chromium-org/drm-amdgpu-display-fix-wrong-enum-type-for-ddc_result/20180204-091310
base:   git://people.freedesktop.org/~airlied/linux.git drm-next
config: ia64-allmodconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64 

All warnings (new ones prefixed by >>):

   drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c: In function 
'dc_link_handle_hpd_rx_irq':
>> drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c:1949:13: warning: 
>> comparison between 'enum ddc_result' and 'enum dc_status' [-Wenum-compare]
 if (result != DC_OK) {
^~

vim +1949 drivers/gpu/drm/amd/amdgpu/../display/dc/core/dc_link_dp.c

4562236b3b Harry Wentland 2017-09-12  1924  
d0778ebfd5 Harry Wentland 2017-07-22  1925  bool 
dc_link_handle_hpd_rx_irq(struct dc_link *link, union hpd_irq_data 
*out_hpd_irq_dpcd_data)
4562236b3b Harry Wentland 2017-09-12  1926  {
4562236b3b Harry Wentland 2017-09-12  1927  union hpd_irq_data 
hpd_irq_dpcd_data = 0;
c2e218dda0 Harry Wentland 2017-02-24  1928  union device_service_irq 
device_service_clear = { { 0 } };
698569c574 Dominik Behr   2018-02-01  1929  enum ddc_result result = 
DDC_RESULT_UNKNOWN;
4562236b3b Harry Wentland 2017-09-12  1930  bool status = false;
4562236b3b Harry Wentland 2017-09-12  1931  /* For use cases related to 
down stream connection status change,
4562236b3b Harry Wentland 2017-09-12  1932   * PSR and device auto test, 
refer to function handle_sst_hpd_irq
4562236b3b Harry Wentland 2017-09-12  1933   * in DAL2.1*/
4562236b3b Harry Wentland 2017-09-12  1934  
4562236b3b Harry Wentland 2017-09-12  1935  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 2017-09-12  1936  "%s: Got short pulse 
HPD on link %d\n",
d0778ebfd5 Harry Wentland 2017-07-22  1937  __func__, 
link->link_index);
4562236b3b Harry Wentland 2017-09-12  1938  
8ee65d7c93 Wenjing Liu2017-07-19  1939  
4562236b3b Harry Wentland 2017-09-12  1940   /* All the 
"handle_hpd_irq_xxx()" methods
4562236b3b Harry Wentland 2017-09-12  1941   * should be called 
only after
4562236b3b Harry Wentland 2017-09-12  1942   * 
dal_dpsst_ls_read_hpd_irq_data
4562236b3b Harry Wentland 2017-09-12  1943   * Order of calls is 
important too
4562236b3b Harry Wentland 2017-09-12  1944   */
4562236b3b Harry Wentland 2017-09-12  1945  result = 
read_hpd_rx_irq_data(link, _irq_dpcd_data);
8ee65d7c93 Wenjing Liu2017-07-19  1946  if (out_hpd_irq_dpcd_data)
8ee65d7c93 Wenjing Liu2017-07-19  1947  *out_hpd_irq_dpcd_data 
= hpd_irq_dpcd_data;
4562236b3b Harry Wentland 2017-09-12  1948  
4562236b3b Harry Wentland 2017-09-12 @1949  if (result != DC_OK) {
4562236b3b Harry Wentland 2017-09-12  1950  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 2017-09-12  1951  "%s: DPCD read 
failed to obtain irq data\n",
4562236b3b Harry Wentland 2017-09-12  1952  __func__);
4562236b3b Harry Wentland 2017-09-12  1953  return false;
4562236b3b Harry Wentland 2017-09-12  1954  }
4562236b3b Harry Wentland 2017-09-12  1955  
4562236b3b Harry Wentland 2017-09-12  1956  if 
(hpd_irq_dpcd_data.bytes.device_service_irq.bits.AUTOMATED_TEST) {
4562236b3b Harry Wentland 2017-09-12  1957  
device_service_clear.bits.AUTOMATED_TEST = 1;
4562236b3b Harry Wentland 2017-09-12  1958  core_link_write_dpcd(
4562236b3b Harry Wentland 2017-09-12  1959  link,
3a340294f7 Dave Airlie2016-12-13  1960  
DP_DEVICE_SERVICE_IRQ_VECTOR,
4562236b3b Harry Wentland 2017-09-12  1961  
_service_clear.raw,
4562236b3b Harry Wentland 2017-09-12  1962  
sizeof(device_service_clear.raw));
4562236b3b Harry Wentland 2017-09-12  1963  
device_service_clear.raw = 0;
4562236b3b Harry Wentland 2017-09-12  1964  
handle_automated_test(link);
4562236b3b Harry Wentland 2017-09-12  1965  return false;
4562236b3b Harry Wentland 2017-09-12  1966  }
4562236b3b Harry Wentland 2017-09-12  1967  
4562236b3b Harry Wentland 2017-09-12  1968  if (!allow_hpd_rx_irq(link)) {
4562236b3b Harry Wentland 2017-09-12  1969  
dm_logger_write(link->ctx->logger, LOG_HW_HPD_IRQ,
4562236b3b Harry Wentland 

[Bug 104888] DPMS issue w/ GFX8/Polaris10/Ellesmere/Rx-480-8GiB & agd5f's drm-next-4.17-wip

[bugzilla-daemon]

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

Robin Kauffman  changed:

   What|Removed |Added

Version|XOrg git|unspecified

-- 
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 4/5 v2] drm/pl111: Support variants with broken VBLANK

[Eric Anholt]

Linus Walleij  writes:

> The early Integrator CLCD synthesized in the Integrator CP and
> IM-PD1 FPGAs are broken: their vertical and next base interrupts
> are not functional. Support these variants by simply disabling
> the use of the vblank interrupt on these variants.

I do wonder if we just have the vblank interrupt number wrong or
something for Integrator.  However, let's get to at least functional
parity with fbdev before we worry too much about the new features that
DRM can bring us.

The remainder of this series is also:

Reviewed-by: Eric Anholt 


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

[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

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

--- Comment #3 from Robin Kauffman  ---
Oops, discovered too late that INT3 is used to set a breakpoint.  Regardless,
it's still something SIGTRAP-ish (i.e. SIGDUMP-CORE-AND-TERMINATE).

-- 
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 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

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

--- Comment #2 from Robin Kauffman  ---
Created attachment 137160
  --> https://bugs.freedesktop.org/attachment.cgi?id=137160=edit
Xorg.0.log from firing up X directly with Awesome as a WM (Boring)

Finally, Xorg.0.log

-- 
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 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

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

--- Comment #1 from Robin Kauffman  ---
Created attachment 137159
  --> https://bugs.freedesktop.org/attachment.cgi?id=137159=edit
Kernel serial log while firing up gnome-shell as a Wayland compositor

Forgot that Bugzilla nominally allows only one attachment per comment.

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

[Bug 104932] Hang when running X11/Wayland on GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's DC-Patches-Jan-31-2018.mbox applied)

[bugzilla-daemon]

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

Bug ID: 104932
   Summary: Hang when running X11/Wayland on
GFX8/Polaris10/Ellesmere/Rx-480-8GiB (agd5f
a5592a6df4f45a018b48f252ad1c498e683e9b9d, hwentland's
DC-Patches-Jan-31-2018.mbox applied)
   Product: DRI
   Version: XOrg git
  Hardware: Other
OS: All
Status: NEW
  Severity: normal
  Priority: medium
 Component: DRM/AMDgpu
  Assignee: dri-devel@lists.freedesktop.org
  Reporter: rob...@creosotehill.org

Created attachment 137158
  --> https://bugs.freedesktop.org/attachment.cgi?id=137158=edit
Kernel serial log while firing up the Awesome WM

Hello-
I've been having (for a while now, and going back a bit in terms of AMDGPU
tree commit history) an issue whereby the framebuffer & graphics stack
(*usually* not the kernel writ large) will hang upon firing up XOrg's XServer
or a Wayland compositor (in my case, GNOME-Shell).
What compounded my frustration was that I'd rarely (if ever) see any output
from the Xorg server, the Wayland compositor, or the kernel indicating there
was any sort of problem, save for a trapped SIGQUIT (trap3) hitting
gnome-shell.
Finally, in firing up X11 directly w/ Awesome as the WM I obtained some
kernel output which will hopefully prove useful in diagnosing this issue.  It's
below (and attached):
amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_ADDR   0x0052
amdgpu :01:00.0:   VM_CONTEXT1_PROTECTION_FAULT_STATUS 0x0A088002
amdgpu :01:00.0: VM fault (0x02, vmid 5, pasid 32768) at page 5242882, read
from 'TC6' (0x54433600) (136)
[drm:amdgpu_job_timedout] *ERROR* ring gfx timeout, last signaled seq=45, last
emitted seq=48
[drm] IP block:gfx_v8_0 is hung!
[drm] GPU recovery disabled.

Doubt it's tremendously useful, but kernel output with gnome-shell (in this
case acting as a Wayland compositor) is below and attached as well:
traps: gnome-shell[1260] trap int3 ip:7f6e4b956e01 sp:7ffe72a8aa50 error:0 in
libglib-2.0.so.0.5200.3[7f6e4b908000+10f000]
traps: gnome-shell[1336] trap int3 ip:7f0f89b3ee01 sp:7ffefd8d3df0 error:0 in
libglib-2.0.so.0.5200.3[7f0f89af+10f000]
traps: gnome-shell[1351] trap int3 ip:7f0984cb6e01 sp:7ffd3caa7650 error:0 in
libglib-2.0.so.0.5200.3[7f0984c68000+10f000]

Lastly, my Xorg.0.log is attached, but you'll find it's quite boring (no
complaints, which is good, but seemingly no useful debugging information,
either).

-- 
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/nouveau: prefer XBGR2101010 for addfb ioctl

[Ilia Mirkin]

Nouveau only exposes support for XBGR2101010. Prior to the atomic
conversion, drm would pass in the wrong format in the framebuffer, but
it was always ignored -- both userspace (xf86-video-nouveau) and the
kernel driver agreed on the layout, so the fact that the format was
wrong didn't matter.

With the atomic conversion, nouveau all of a sudden started caring about
the exact format, and so the previously-working code in
xf86-video-nouveau no longer functioned since the (internally-assigned)
format from the addfb ioctl was wrong.

This change adds infrastructure to allow a drm driver to specify that it
prefers the XBGR format variant for the addfb ioctl, and makes nouveau's
nv50 display driver set it. (Prior gens had no support for 30bpp at all.)

Signed-off-by: Ilia Mirkin 
Cc: sta...@vger.kernel.org # v4.10+
---

Wasn't sure if the nouveau line needs to be split out into a separate
change or not.

 drivers/gpu/drm/drm_framebuffer.c  | 4 
 drivers/gpu/drm/nouveau/nv50_display.c | 1 +
 include/drm/drm_drv.h  | 1 +
 3 files changed, 6 insertions(+)

diff --git a/drivers/gpu/drm/drm_framebuffer.c 
b/drivers/gpu/drm/drm_framebuffer.c
index 5a13ff29f4f0..c0530a1af5e3 100644
--- a/drivers/gpu/drm/drm_framebuffer.c
+++ b/drivers/gpu/drm/drm_framebuffer.c
@@ -121,6 +121,10 @@ int drm_mode_addfb(struct drm_device *dev,
r.pixel_format = drm_mode_legacy_fb_format(or->bpp, or->depth);
r.handles[0] = or->handle;
 
+   if (r.pixel_format == DRM_FORMAT_XRGB2101010 &&
+   dev->driver->driver_features & DRIVER_PREFER_XBGR_30BPP)
+   r.pixel_format = DRM_FORMAT_XBGR2101010;
+
ret = drm_mode_addfb2(dev, , file_priv);
if (ret)
return ret;
diff --git a/drivers/gpu/drm/nouveau/nv50_display.c 
b/drivers/gpu/drm/nouveau/nv50_display.c
index dd8d4352ed99..caddce88d2d8 100644
--- a/drivers/gpu/drm/nouveau/nv50_display.c
+++ b/drivers/gpu/drm/nouveau/nv50_display.c
@@ -4477,6 +4477,7 @@ nv50_display_create(struct drm_device *dev)
nouveau_display(dev)->fini = nv50_display_fini;
disp->disp = _display(dev)->disp;
dev->mode_config.funcs = _disp_func;
+   dev->driver->driver_features |= DRIVER_PREFER_XBGR_30BPP;
if (nouveau_atomic)
dev->driver->driver_features |= DRIVER_ATOMIC;
 
diff --git a/include/drm/drm_drv.h b/include/drm/drm_drv.h
index d32b688eb346..d23dcdd1bd95 100644
--- a/include/drm/drm_drv.h
+++ b/include/drm/drm_drv.h
@@ -56,6 +56,7 @@ struct drm_printer;
 #define DRIVER_ATOMIC  0x1
 #define DRIVER_KMS_LEGACY_CONTEXT  0x2
 #define DRIVER_SYNCOBJ  0x4
+#define DRIVER_PREFER_XBGR_30BPP0x8
 
 /**
  * struct drm_driver - DRM driver structure
-- 
2.13.6

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

[Bug 104920] Broken hardware video encoding with vaapi/ffmpeg

[bugzilla-daemon]

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

Sven Arvidsson  changed:

   What|Removed |Added

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

--- Comment #2 from Sven Arvidsson  ---
Thank you, -profile:v 578 works fine.

Looks like I had everything needed for the new way with kmsgrab too, which is
even better!

Thank you so much for the tip and explanation, much appreciated!

Resolving as NOTABUG as this was a configuration problem/ignorance on my part.

-- 
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 104919] R9285 4.17-wip locks/vmfaults since drm/amdgpu: revert "drm/amdgpu: use AMDGPU_GEM_CREATE_VRAM_CLEARED for VM PD/PTs" v2

[bugzilla-daemon]

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

--- Comment #4 from Andy Furniss  ---
(In reply to Andy Furniss from comment #3)

> Seems good with that.
> Just a quick test as got to be AFK, will try more later.

Still good after a bit more time.

-- 
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: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Fri, Feb 2, 2018 at 7:18 PM, Andy Lutomirski  wrote:
> On Fri, Feb 2, 2018 at 1:24 AM, Andy Lutomirski  wrote:
>> On Thu, Feb 1, 2018 at 9:20 PM, Chris Wilson  
>> wrote:
>>> Quoting Andy Lutomirski (2018-02-01 21:04:30)
 I got this after a recent suspend/resume:

 Feb 01 09:44:34 laptop systemd-logind[2412]: Lid closed.
 Feb 01 09:44:34 laptop systemd-logind[2412]: device-enumerator: scan all 
 dirs
 Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
 scanning /sys/bus
 Feb 01 09:44:34 laptop systemd-logind[2412]:   device-enumerator:
 scanning /sys/class
 Feb 01 09:44:34 laptop systemd-logind[2412]: Failed to open
 configuration file '/etc/systemd/sleep.conf': No such file or
 directory
 Feb 01 09:44:34 laptop systemd-logind[2412]: Suspending...
 Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
 sender=n/a destination=n/a object=/org/freedesktop/login1
 interface=org.freedesktop.login1.Manager member=PrepareForSleep
 cookie=570 reply
 Feb 01 09:44:34 laptop systemd-logind[2412]: Got message
 type=method_call sender=:1.46 destination=:1.1
 object=/org/freedesktop/login1/session/_32
 interface=org.freedesktop.login1.Session member=ReleaseDevice
 Feb 01 09:44:34 laptop systemd-logind[2412]: Sent message type=signal
 sender=n/a destination=:1.46
 object=/org/freedesktop/login1/session/_32
 interface=org.freedesktop.login1.Session member=PauseDevice cookie
 Feb 01 09:44:34 laptop gnome-shell[2630]: Failed to apply DRM plane
 transform 0: Permission denied
 Feb 01 09:44:34 laptop gnome-shell[2630]: drmModeSetCursor2 failed
 with (Permission denied), drawing cursor with OpenGL from now on

 But I don't see the word "cursor" in my system logs before the first
 suspend.  What am I looking for?  This is Fedora 27 running a Gnome
 Wayland session, but it hasn't been reinstalled in some time, so it's
 possible that there are some weird settings sitting around.  But I did
 check and I have no weird i915 parameters.
>>>
>>> You are using gnome-shell as the display server. From that it appears to
>>> have started off with a HW cursor and switched to a SW cursor after
>>> suspend. Did you notice a change in behaviour? After rebooting or just
>>> restarting gnome-shell?
>>
>> I think it's less consistently bad after a reboot before suspending.
>>
>>>
 Also, are these things potentially related:

 [ 3067.702527] [drm:intel_pipe_update_start [i915]] *ERROR* Potential
 atomic update failure on pipe A
>>>
>>> They are just "missed the immediate vblank for the screen update"
>>> messages. Should not be related to PSR, but may cause jitter by delaying
>>> the odd screen update.
>>
>> I just got this one, and the timestamp is at least reasonably close to
>> a giant latency spike:
>>
>> [  288.799654] [drm:intel_pipe_update_end [i915]] *ERROR* Atomic
>> update failure on pipe A (start=31 end=32) time 15 us, min 1073, max
>> 1079, scanline start 1087, end 1088
>>
>>>
 As I'm typing this, I've seen a couple instances of what seems like a
 full *second* of cursor latency, but I've only gotten the potential
 atomic update failure once.

 And is there any straightforward tracing to do to distinguish between
 PSR exit latency and other potential sources of latency?
>>>
>>> It looks plausible that we could at least report how long it takes the
>>> registers to reflect the change in state (but we don't). The best source
>>> of information atm is /sys/kernel/debug/dri/0/i915_edp_psr_status.
>>
>> Hmm.
>>
>> I went and looked at the code, and I noticed what could be bugs or
>> could (more likely) be my confusion since I don't know this code at
>> all:
>>
>> intel_single_frame_update() does something inscrutable to me, but I
>> imagine it does something that causes the next page flip to get
>> noticed by the panel even with PSR on.  But how does the code that
>> calls it know that anything happened?  (Looking at the commit history,
>> maybe this is something special that's only needed on some platforms
>> but doesn't replace the normal PSR exit sequence.)
>>
>> Perhaps more interestingly, intel_psr_flush() does this:
>>
>> /* By definition flush = invalidate + flush */
>> if (frontbuffer_bits)
>> intel_psr_exit(dev_priv);
>>
>> if (!dev_priv->psr.active && !dev_priv->psr.busy_frontbuffer_bits)
>> if (!work_busy(_priv->psr.work.work))
>> schedule_delayed_work(_priv->psr.work,
>>   msecs_to_jiffies(100));
>>
>> I'm guessing that the idea is that we're turning off PSR because we
>> want the panel to update and we expect that, in 100ms, the update will
>> have hit the panel and we'll have been idle long enough for it to make
>> sense to re-enter PSR.  IOW, the code wants PSR to be off for at least
>> 100ms 

Re: [Intel-gfx] i915 PSR test results and cursor lag

[Andy Lutomirski]

On Sat, Feb 3, 2018 at 5:20 AM, Pandiyan, Dhinakaran
 wrote:
>
> On Fri, 2018-02-02 at 19:18 +, Andy Lutomirski wrote:
>> I updated to 4.15, and the situation is much worse.  With
>> enable_psr=1, the system survives for several seconds and then the
>> screen stops updating entirely.  If I boot with i915.enable_psr=1, I
>> get to the Fedora login screen and then the system dies.  If I set
>> enable_psr=1 using sysfs, it does a bit after the next resume.  It
>> seems like it also sometimes hangs even worse a bit after the screen
>> stops updating, but it's hard to tell.
>
> The login screen freeze sounds like what I have. Does this system have
> DMC firmware? If yes, can you try this series
> https://patchwork.freedesktop.org/series/37598/. You'll only need
> patches 1,8,9 and 10.

That fixes the hang.  Feel free to add:

Tested-by: Andy Lutomirski 

to the i915 parts.  Also, any chance of getting it into the 4.15 stable kernels?

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

Re: clang warning: implicit conversion in intel_ddi.c:1481

[Knut Omang]

On Fri, 2018-02-02 at 16:50 +0100, Greg KH wrote:
> On Fri, Feb 02, 2018 at 04:37:55PM +0200, Jani Nikula wrote:
> > On Fri, 02 Feb 2018, Greg KH  wrote:
> > > On Fri, Feb 02, 2018 at 12:44:38PM +0200, Jani Nikula wrote:
> > >> 
> > >> +Knut, Fengguang
> > >> 
> > >> On Fri, 02 Feb 2018, Greg KH  wrote:
> > >> >- If clang now builds the kernel "cleanly", yes, I want to take
> > >> >  warning fixes in the stable tree.  And even better yet, if you
> > >> >  keep working to ensure the tree is "clean", that would be
> > >> >  wonderful.
> > >> 
> > >> So we can run sparse using 'make C=1' and friends, or other static
> > >> analysis tools using 'make CHECK=foo C=1', as long as the passed command
> > >> line params work. There was work by Knut to extend this make checker
> > >> stuff [1]. Since mixing different HOSTCC's in a single workdir seems
> > >> like a bad idea, I wonder how hard it would be to make clang work like
> > >> this:
> > >> 
> > >> $ make CHECK=clang C=1
> > >> 
> > >> Or using Knut's wrapper. Feels like that could increase the use of clang
> > >> for static analysis of patches.
> > >
> > > Why not just build with clang itself:
> > >   make CC=clang
> > 
> > Same as HOSTCC, mixing different CC's in a single build dir seems like a
> > bad idea. Sure, everyone can setup a separate build dir for clang, but
> > IMHO having 'make CHECK=clang C=1' work has least resistance. YMMV.
> 
> "O=some_output_dir" is your friend.  If you aren't doing that already
> for your test builds, you don't know what you are missing :)

I use O= a lot myself - so good not to have all the output files "pollute" the 
source
tree, and to be able to switch branches and compile without having to recompile 
everything
by having multiple O= set up.

I think what my runchecks wrapper script brings in addition is the ability to 
to a number
of checks which may or may not pass, even return error codes, from the same 
'make' command
and configure what errors to fix now and what to postpone/ignore (and thus not 
fail from).

As an example, I just tried clang (on v4.15-rc6) with:

cd $HOME/src/kernel
make O=$HOME/build/kernel/clang
cd $HOME/build/kernel/clang
make

and it fails to compile for me in arch/x86/xen/mmu_pv.o. 

If I'd want to just make sure that some patches did not introduce new errors 
with clang, 
I would waste some time with unrelated errors, and there will be noise in the 
output, also
consuming personal "cycles".

I haven't really looked at the details of much of what clang outputs of errors 
yet, but I
can imagine that specific errors reported by clang might be useful to correct 
even in old
kernels, where some files inevitably will fail to compile like this.

This would be easy to handle with runchecks using a few exceptions for those
problems/files not yet fixed, allowing a run to easily detect (while compiling 
with gcc as
the main compiler) that no new clang errors were introduced of any other kind 
than those
suppressed.

Thanks,
Knut

> 
> thanks,
> 
> greg k-h
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: [PATCH 01/10] drm/vblank: Data type fixes for 64-bit vblank sequences.

[Keith Packard]

Dhinakaran Pandiyan  writes:

> From: "Pandiyan, Dhinakaran" 
>
> drm_vblank_count() has an u32 type returning what is a 64-bit vblank count.
> The effect of this is when drm_wait_vblank_ioctl() tries to widen the user
> space requested vblank sequence using this clipped 32-bit count(when the
> value is >= 2^32) as reference, the requested sequence remains a 32-bit
> value and gets queued like that. However, the code that checks if the
> requested sequence has passed compares this against the 64-bit vblank
> count.

For patches 1-7:

Reviewed-by: Keith Packard 

-- 
-keith


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