[Intel-gfx] [Regression report] Weekly regression report WW39

2016-09-25 Thread Jairo Miramontes 


This week's new regressions
+---+---+++
| BugId | Summary   | Created on | 
Bisect |

+---+---+++
| 97918 | [bdw regression 4.8] Severe graphics regressi | 2016-09-25 | 
No |
| 97878 | [SKL][REGRESSION][BISECTED] Dropped frames an | 2016-09-20 | 
Yes|
| 97888 | [regression] [i915] [SKL] Tearing / flickerin | 2016-09-21 | 
No |
| 97867 | [HSW][Regression] 4.6.7 and beyond causes scr | 2016-09-19 | 
No |

+---+---+++

Previous Regressions
+---+---+++
| BugId | Summary   | Created on | 
Bisect |

+---+---+++
| 90112 | [BSW bisected] OglGSCloth/Lightsmark/CS/ Port | 2015-04-20 | 
Yes|
| 94590 | [KBL] igt/kms_fbcon_fbt/psr-suspend regressio | 2016-03-17 | 
No |
| 93263 | 945GM regression since 4.3| 2015-12-05 | 
No |
| 92237 | [SNB]Horrible noise (audio) via DisplayPort [ | 2015-10-02 | 
No |
| 72782 | [945GM bisected] screen blank on S3 resume on | 2013-12-17 | 
Yes|
| 92414 | [Intel-gfx] As of kernel 4.3-rc1 system will  | 2015-10-10 | 
Yes|
| 92050 | [regression]/bug introduced by commit [0e572f | 2015-09-19 | 
No |
| 93393 | Regression for Skylake modesetting in kernel  | 2015-12-16 | 
No |
| 93802 | [IVB bisected] switching to tty1 causes fifo  | 2016-01-20 | 
Yes|
| 95197 | [i915] regression in 4.6-rc5: GPU HANG: ecode | 2016-04-28 | 
No |
| 96800 | [regression] The drm-intel-nightly branch no  | 2016-07-04 | 
No |
| 95736 | [IVB bisected] *ERROR* uncleared fifo underru | 2016-05-24 | 
Yes|
| 89728 | [HSW/BDW/BYT bisected] igt / pm_rps / reset f | 2015-03-23 | 
Yes|
| 89629 | [i965 regression]igt/kms_rotation_crc/sprite- | 2015-03-18 | 
No |
| 96938 | [HSW modeset regression] i915/drm locks up wh | 2016-07-15 | 
No |
| 87131 | [PNV regression] igt/gem_exec_lut_handle take | 2014-12-09 | 
No |
| 87726 | [BDW Bisected] OglDrvCtx performance reduced  | 2014-12-26 | 
Yes|
| 91974 | [bisected] unrecoverable black screen after k | 2015-09-11 | 
Yes|
| 96645 | [regression 4.7] [BISECT]Low package c-states | 2016-06-22 | 
Yes|
| 94430 | [HSW+nvidia] regression: display becomes "dis | 2016-03-07 | 
No |
| 97295 | Regression backlight control broken on Dell X | 2016-08-11 | 
No |
| 97573 | [IVB/SNB/BYT/HSW/BDW] GuC boot kernel command | 2016-09-02 | 
No |
| 97596 | [SKL] [regression] Flickering artefact window | 2016-09-05 | 
No |
| 93971 | video framerate performance regression with U | 2016-02-02 | 
No |
| 89872 | [ HSW Bisected ] VGA was white screen when re | 2015-04-02 | 
Yes|
| 96428 | [IVB bisected] [drm:intel_dp_aux_ch] *ERROR*  | 2016-06-07 | 
Yes|
| 91959 | [865g Linux regression] GPU hang and disabled | 2015-09-10 | 
No |
| 95097 | [hdmi regression ilk] no signal to TV | 2016-04-24 | 
No |
| 97450 | [SKL] [regression] Random display flickering  | 2016-08-23 | 
No |
| 92972 | Black screen on Intel NUC hardware (i915) pos | 2015-11-16 | 
No |
| 87725 | [BDW Bisected] OglBatch7 performance reduced  | 2014-12-26 | 
Yes|
| 94337 | Linux 4.5 regression: FIFO underruns on Skyla | 2016-02-29 | 
No |
| 97820 | [BDW BYT SKL HSW] [Regression] [GPU Hang] wit | 2016-09-15 | 
No |
| 97017 | [SKL GT3e guc bisected] ~10% performance drop | 2016-07-21 | 
Yes|
| 96916 | Regression: screen flashes with PSR enabled   | 2016-07-13 | 
No |
| 90368 | [SNB BSW SKL BXT KBL] [Regression] bisected i | 2015-05-08 | 
Yes|
| 94588 | [IVB/KBL/BSW/BXT/BDW] [Regression] igt/gem_re | 2016-03-17 | 
No |
| 96736 | kernel 4.6 regression: PSR causes screen to f | 2016-06-29 | 
No |
| 90134 | [BSW Bisected]GFXBench3_gl_driver/GFXBench3_g | 2015-04-22 | 
Yes|
| 96704 | kernel 4.6 regression: PSR on Haswell causes  | 2016-06-28 | 
No |
| 93782 | [i9xx TV][BISECT] vblank wait timeout on crtc | 2016-01-19 | 
Yes|
| 89632 | [i965 regression]igt/kms_universal_plane/univ | 2015-03-18 | 
No |

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

[Intel-gfx] [PATCH 1/2] drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE

2016-09-25 Thread Joe Perches 
Use a bit more consistent style with kernel loglevels without
using macro argument concatenation.

Miscellanea:

o Single statement macros don't need do {} while (0)

Signed-off-by: Joe Perches 
---
 drivers/gpu/drm/i915/intel_guc_loader.c | 22 --
 include/drm/drmP.h  | 26 +-
 2 files changed, 25 insertions(+), 23 deletions(-)

diff --git a/drivers/gpu/drm/i915/intel_guc_loader.c 
b/drivers/gpu/drm/i915/intel_guc_loader.c
index 6fd39efb7894..bc4f9895f356 100644
--- a/drivers/gpu/drm/i915/intel_guc_loader.c
+++ b/drivers/gpu/drm/i915/intel_guc_loader.c
@@ -566,7 +566,7 @@ int intel_guc_setup(struct drm_device *dev)
else if (err == 0)
DRM_INFO("GuC firmware load skipped\n");
else if (ret != -EIO)
-   DRM_NOTE("GuC firmware load failed: %d\n", err);
+   DRM_NOTICE("GuC firmware load failed: %d\n", err);
else
DRM_WARN("GuC firmware load failed: %d\n", err);
 
@@ -574,7 +574,7 @@ int intel_guc_setup(struct drm_device *dev)
if (fw_path == NULL)
DRM_INFO("GuC submission without firmware not 
supported\n");
if (ret == 0)
-   DRM_NOTE("Falling back from GuC submission to execlist 
mode\n");
+   DRM_NOTICE("Falling back from GuC submission to 
execlist mode\n");
else
DRM_ERROR("GuC init failed: %d\n", ret);
}
@@ -606,7 +606,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* Check the size of the blob before examining buffer contents */
if (fw->size < sizeof(struct guc_css_header)) {
-   DRM_NOTE("Firmware header is missing\n");
+   DRM_NOTICE("Firmware header is missing\n");
goto fail;
}
 
@@ -618,7 +618,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
css->key_size_dw - css->exponent_size_dw) * sizeof(u32);
 
if (guc_fw->header_size != sizeof(struct guc_css_header)) {
-   DRM_NOTE("CSS header definition mismatch\n");
+   DRM_NOTICE("CSS header definition mismatch\n");
goto fail;
}
 
@@ -628,7 +628,7 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
/* now RSA */
if (css->key_size_dw != UOS_RSA_SCRATCH_MAX_COUNT) {
-   DRM_NOTE("RSA key size is bad\n");
+   DRM_NOTICE("RSA key size is bad\n");
goto fail;
}
guc_fw->rsa_offset = guc_fw->ucode_offset + guc_fw->ucode_size;
@@ -637,14 +637,14 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
/* At least, it should have header, uCode and RSA. Size of all three. */
size = guc_fw->header_size + guc_fw->ucode_size + guc_fw->rsa_size;
if (fw->size < size) {
-   DRM_NOTE("Missing firmware components\n");
+   DRM_NOTICE("Missing firmware components\n");
goto fail;
}
 
/* Header and uCode will be loaded to WOPCM. Size of the two. */
size = guc_fw->header_size + guc_fw->ucode_size;
if (size > guc_wopcm_size(to_i915(dev))) {
-   DRM_NOTE("Firmware is too large to fit in WOPCM\n");
+   DRM_NOTICE("Firmware is too large to fit in WOPCM\n");
goto fail;
}
 
@@ -659,9 +659,11 @@ static void guc_fw_fetch(struct drm_device *dev, struct 
intel_guc_fw *guc_fw)
 
if (guc_fw->guc_fw_major_found != guc_fw->guc_fw_major_wanted ||
guc_fw->guc_fw_minor_found < guc_fw->guc_fw_minor_wanted) {
-   DRM_NOTE("GuC firmware version %d.%d, required %d.%d\n",
-   guc_fw->guc_fw_major_found, guc_fw->guc_fw_minor_found,
-   guc_fw->guc_fw_major_wanted, 
guc_fw->guc_fw_minor_wanted);
+   DRM_NOTICE("GuC firmware version %d.%d, required %d.%d\n",
+  guc_fw->guc_fw_major_found,
+  guc_fw->guc_fw_minor_found,
+  guc_fw->guc_fw_major_wanted,
+  guc_fw->guc_fw_minor_wanted);
err = -ENOEXEC;
goto fail;
}
diff --git a/include/drm/drmP.h b/include/drm/drmP.h
index c53dc90942e0..95cd04aa9bf7 100644
--- a/include/drm/drmP.h
+++ b/include/drm/drmP.h
@@ -168,25 +168,25 @@ void drm_printk(const char *level, unsigned int category,
 /** \name Macros to make printk easier */
 /*@{*/
 
-#define _DRM_PRINTK(once, level, fmt, ...) \
-   do {\
-   printk##once(KERN_##level "[" DRM_NAME "] " fmt,\
-##__VA_ARGS__);\
-   } while (0)
+#define _drm_printk(level,

[Intel-gfx] [PATCH 0/2] drm: Neaten and reduce object size

2016-09-25 Thread Joe Perches 
Joe Perches (2):
  drm: Simplify logging macros, convert DRM_NOTE to DRM_NOTICE
  drm: Simplify drm_printk to reduce object size quite a bit

 drivers/gpu/drm/drm_drv.c   |  5 +--
 drivers/gpu/drm/i915/intel_guc_loader.c | 22 +++--
 include/drm/drmP.h  | 56 -
 3 files changed, 42 insertions(+), 41 deletions(-)

-- 
2.10.0.rc2.1.g053435c

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

[Intel-gfx] [PULL] topic/drm-misc

2016-09-25 Thread Daniel Vetter 
Hi Dave,

- more core cleanup patches to prep drm_file to be used for
  kernel-internal contexts (David Herrmann)
- more split-up+docs for drm_crtc.c
- lots of small fixes and polish all over

This pull contains 4 patches from Markus to switch to
kcalloc/kmalloc_array in legacy bufs ioctl code. Because ioctls seems
justified, but given the poor s/n and that Markus doesn't seem interested
at all in coordinating his patch piles first I won't bother trying to dig
out the good ones any more.

Also reminder to pick up one of the udl fixes (don't forget the cc:
stable) for drm-fixes.

Cheers, Daniel


The following changes since commit 9f8cf165c62913244479832f04c44cd77ffc9293:

  Merge tag 'topic/drm-misc-2016-09-19' of 
git://anongit.freedesktop.org/drm-intel into drm-next (2016-09-19 17:16:02 
+1000)

are available in the git repository at:

  git://anongit.freedesktop.org/drm-intel tags/topic/drm-misc-2016-09-25

for you to fetch changes up to 089cfdd9b0ec1b21d3356d2e057f69b89d46ae66:

  drm: bridge: analogix/dp: mark symbols static where possible (2016-09-25 
22:59:02 +0200)


Baoyou Xie (2):
  drm/bochs: mark bochs_connector_get_modes() static
  drm: bridge: analogix/dp: mark symbols static where possible

Brian Starkey (1):
  drm/i2c: tda998x: don't register the connector

Daniel Vetter (11):
  drm: Move a few macros away from drm_crtc.h
  drm: Extract drm_bridge.h
  drm: Move all decl for drm_edid.c to drm_edid.h
  drm: Extract drm_plane.[hc]
  drm/doc: Polish for drm_plane.[hc]
  drm: Conslidate blending properties in drm_blend.[hc]
  drm/doc: Polish plane composition property docs
  drm: Extract drm_color_mgmt.[hc]
  drm/doc: Document color space handling
  drm: Remove dirty property from docs
  drm: Fix plane type uabi breakage

David Herrmann (4):
  drm: remove redundant drm_file->uid
  drm: use drm_file to tag vm-bos
  drm: drop obsolete drm_core.h
  drm: cleanup drm_core_{init,exit}()

Dhinakaran Pandiyan (1):
  drm: Fix typo in encoder docs

Emilio López (1):
  dma-buf/sync_file: fix documentation error

Gustavo Padovan (1):
  dma-buf/sync_file: free fences array in num_fences is 1

Jani Nikula (1):
  drm: fix implicit declaration build error on ia64

Markus Elfring (4):
  GPU-DRM: Use kmalloc_array() in drm_legacy_addbufs_pci()
  GPU-DRM: Replace two kzalloc() calls by kcalloc() in 
drm_legacy_addbufs_pci()
  GPU-DRM: Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_agp()
  GPU-DRM: Replace a kzalloc() call by kcalloc() in drm_legacy_addbufs_sg()

Rafael Antognolli (1):
  dma-buf/sync_file: Increment refcount of fence when all are signaled.

Sean Paul (4):
  drm/tilcdc: Add atomic and crtc headers to crtc.c
  Revert "drm/i2c: tda998x: don't register the connector"
  drm/bridge: analogix_dp: Don't read EDID if panel present
  drm/bridge: analogix_dp: Improve panel on time

Tom Gundersen (2):
  drm: Distinguish no name from ENOMEM in set_unique()
  drm: Don't swallow error codes in drm_dev_alloc()

Tomeu Vizoso (1):
  drm/bridge: analogix_dp: Remove duplicated code

Ville Syrjälä (3):
  drm/atomic-helper: Fix sparse warnings
  drm/blend: Fix sparse warnings
  drm/fb-helper: Fix sparse warnings

 Documentation/gpu/drm-kms-helpers.rst  |   10 +
 Documentation/gpu/drm-kms.rst  |   78 +-
 Documentation/gpu/kms-properties.csv   |   21 -
 drivers/dma-buf/sync_file.c|7 +-
 drivers/gpu/drm/Makefile   |3 +-
 drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c|3 +-
 drivers/gpu/drm/arc/arcpgu_drv.c   |4 +-
 drivers/gpu/drm/arm/hdlcd_drv.c|4 +-
 drivers/gpu/drm/arm/malidp_drv.c   |4 +-
 drivers/gpu/drm/ast/ast_ttm.c  |3 +-
 drivers/gpu/drm/atmel-hlcdc/atmel_hlcdc_dc.c   |4 +-
 drivers/gpu/drm/bochs/bochs_kms.c  |2 +-
 drivers/gpu/drm/bochs/bochs_mm.c   |3 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.c |  311 ++--
 drivers/gpu/drm/bridge/analogix/analogix_dp_core.h |   40 +-
 drivers/gpu/drm/bridge/analogix/analogix_dp_reg.c  |  451 ++
 drivers/gpu/drm/cirrus/cirrus_ttm.c|3 +-
 drivers/gpu/drm/drm_atomic_helper.c|2 +-
 drivers/gpu/drm/drm_blend.c|  199 ++-
 drivers/gpu/drm/drm_bridge.c   |5 +-
 drivers/gpu/drm/drm_bufs.c |   14 +-
 drivers/gpu/drm/drm_color_mgmt.c   |  296 
 drivers/gpu/drm/drm_crtc.c | 1683 +++-
 drivers/gpu/drm/drm_crtc_helper_internal.h |7 +
 drivers/gpu/drm/drm_crtc_internal.h|   45 +-
 drivers/gpu/drm/drm_dp_helper.c

Re: [Intel-gfx] [PATCH 11/11] dma-buf: Do a fast lockless check for poll with timeout=0

2016-09-25 Thread Daniel Vetter 
On Fri, Sep 23, 2016 at 07:59:44PM +0200, Christian König wrote:
> Am 23.09.2016 um 17:20 schrieb Chris Wilson:
> > On Fri, Sep 23, 2016 at 03:50:44PM +0200, Daniel Vetter wrote:
> > > On Mon, Aug 29, 2016 at 08:08:34AM +0100, Chris Wilson wrote:
> > > > Currently we install a callback for performing poll on a dma-buf,
> > > > irrespective of the timeout. This involves taking a spinlock, as well as
> > > > unnecessary work, and greatly reduces scaling of poll(.timeout=0) across
> > > > multiple threads.
> > > > 
> > > > We can query whether the poll will block prior to installing the
> > > > callback to make the busy-query fast.
> > > > 
> > > > Single thread: 60% faster
> > > > 8 threads on 4 (+4 HT) cores: 600% faster
> > > > 
> > > > Still not quite the perfect scaling we get with a native busy ioctl, but
> > > > poll(dmabuf) is faster due to the quicker lookup of the object and
> > > > avoiding drm_ioctl().
> > > > 
> > > > Signed-off-by: Chris Wilson 
> > > > Cc: Sumit Semwal 
> > > > Cc: linux-me...@vger.kernel.org
> > > > Cc: dri-de...@lists.freedesktop.org
> > > > Cc: linaro-mm-...@lists.linaro.org
> > > > Reviewed-by: Daniel Vetter 
> > > Need to strike the r-b here, since Christian König pointed out that
> > > objects won't magically switch signalling on.
> > Oh, it also means that
> > 
> > commit fb8b7d2b9d80e1e71f379e57355936bd2b024be9
> > Author: Jammy Zhou 
> > Date:   Wed Jan 21 18:35:47 2015 +0800
> > 
> >  reservation: wait only with non-zero timeout specified (v3)
> >  When the timeout value passed to reservation_object_wait_timeout_rcu
> >  is zero, no wait should be done if the fences are not signaled.
> >  Return '1' for idle and '0' for busy if the specified timeout is '0'
> >  to keep consistent with the case of non-zero timeout.
> >  v2: call fence_put if not signaled in the case of timeout==0
> >  v3: switch to reservation_object_test_signaled_rcu
> >  Signed-off-by: Jammy Zhou 
> >  Reviewed-by: Christian König 
> >  Reviewed-by: Alex Deucher 
> >  Reviewed-By: Maarten Lankhorst 
> >  Signed-off-by: Sumit Semwal 
> > 
> > is wrong. And reservation_object_test_signaled_rcu() is unreliable.
> 
> Ups indeed, that patch is wrong as well.
> 
> I suggest that we just enable the signaling in this case as well.

Will you/Zhou take care of this corner case? Just so I can't forget about
it ;-)

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

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH 10/11] dma-buf: Use seqlock to close RCU race in test_signaled_single

2016-09-25 Thread Daniel Vetter 
On Fri, Sep 23, 2016 at 03:02:32PM +0100, Chris Wilson wrote:
> On Fri, Sep 23, 2016 at 03:49:26PM +0200, Daniel Vetter wrote:
> > On Mon, Aug 29, 2016 at 08:08:33AM +0100, Chris Wilson wrote:
> > > With the seqlock now extended to cover the lookup of the fence and its
> > > testing, we can perform that testing solely under the seqlock guard and
> > > avoid the effective locking and serialisation of acquiring a reference to
> > > the request.  As the fence is RCU protected we know it cannot disappear
> > > as we test it, the same guarantee that made it safe to acquire the
> > > reference previously.  The seqlock tests whether the fence was replaced
> > > as we are testing it telling us whether or not we can trust the result
> > > (if not, we just repeat the test until stable).
> > > 
> > > Signed-off-by: Chris Wilson 
> > > Cc: Sumit Semwal 
> > > Cc: linux-me...@vger.kernel.org
> > > Cc: dri-de...@lists.freedesktop.org
> > > Cc: linaro-mm-...@lists.linaro.org
> > 
> > Not entirely sure this is safe for non-i915 drivers. We might now call
> > ->signalled on a zombie fence (i.e. refcount == 0, but not yet kfreed).
> > i915 can do that, but other drivers might go boom.
> 
> All fences must be under RCU guard, or is that the sticking point? Given
> that, the problem is fence reallocation within the RCU grace period. If
> we can mandate that fence reallocation must be safe for concurrent
> fence->ops->*(), we can use this technique to avoid the serialisation
> barrier otherwise required. In the simple stress test, the difference is
> an order of magnitude, and test_signaled_rcu is often on a path where
> every memory barrier quickly adds up (at least for us).
> 
> So is it just that you worry that others using SLAB_DESTROY_BY_RCU won't
> ensure their fence is safe during the reallocation?

Before your patch the rcu-protected part was just the
kref_get_unless_zero. This was done before calling down into and
fenc->ops->* functions. Which means the code of these functions was
guaranteed to run on a real fence object, and not a zombie fence in the
process of getting destructed.

Afaiui with your patch we might call into fence->ops->* on these zombie
fences. That would be a behaviour change with rather big implications
(since we'd need to audit all existing implementations, and also make sure
all future ones will be ok too). Or I missed something again.

I think we could still to this trick, at least partially, by making sure
we only inspect generic fence state and never call into fence->ops before
we're guaranteed to have a real fence.

But atm (at least per Christian König) a fence won't eventually get
signalled without calling into ->ops functions, so there's a catch 22.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx