Re: [Intel-gfx] [PATCH igt] core/sighelper: Interrupt everyone in the process group

On Fri, Jan 08, 2016 at 08:44:29AM +, Chris Wilson wrote: > Some stress tests create both the signal helper and a lot of competing > processes. In these tests, the parent is just waiting upon the children, > and the intention is not to keep waking up the waiting parent, but to > keep

Re: [Intel-gfx] [PATCH 02/39] drm/i915: Updating assorted register and status page definitions

On Fri, Jan 08, 2016 at 02:26:40PM +0200, Joonas Lahtinen wrote: > Hi, > > Comments below. > > On ma, 2015-11-23 at 11:38 +, john.c.harri...@intel.com wrote: > > From: Dave Gordon > > > > Added various definitions that will be useful for the scheduler in > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/gen9: Calculate edram size

On Fri, Jan 08, 2016 at 06:58:45PM +0200, Mika Kuoppala wrote: > With gen9+ the edram capabilities are defined so > that we can calculate the edram (ellc) size accordingly. > > Note that there are undefined combinations for some subset of > edram capability bits. Return the closest size for

Re: [Intel-gfx] [PATCH 15/21] drm/omap: Nuke close hooks

On Mon, Jan 11, 2016 at 02:03:34AM +0200, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Friday 08 January 2016 21:36:47 Daniel Vetter wrote: > > Again since the core takes care of this we can remove them. While at > > it also remove the postclose hook, it's empty. > >

Re: [Intel-gfx] [PATCH] drm/i915: Reject invalid-pad for context-destroy ioctl

On Fri, Jan 08, 2016 at 09:40:52PM +, Chris Wilson wrote: > Unknown parameters, especially structure padding, are expected to invoke > rejection with -EINVAL. > > Testcase: igt/gem_ctx_bad_destroy/invalid-pad > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=89602 > Signed-off-by:

Re: [Intel-gfx] [PATCH] drm/i915: Support to enable TRTT on GEN9

On 1/10/2016 11:09 PM, Chris Wilson wrote: On Sat, Jan 09, 2016 at 05:00:21PM +0530, akash.g...@intel.com wrote: From: Akash Goel Gen9 has an additional address translation hardware support in form of Tiled Resource Translation Table (TR-TT) which provides an extra

Re: [Intel-gfx] [PATCH] drm/i915: Support to enable TRTT on GEN9

On Sat, Jan 09, 2016 at 05:00:21PM +0530, akash.g...@intel.com wrote: > From: Akash Goel > > Gen9 has an additional address translation hardware support in form of > Tiled Resource Translation Table (TR-TT) which provides an extra level > of abstraction over PPGTT. > This

Re: [Intel-gfx] i915 Skylake: "Invalid ROM contents"

On Sun, Jan 10, 2016 at 10:41 AM, Andy Lutomirski wrote: > On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone wrote: >> Hi, >> >> On 18 November 2015 at 15:59, Andy Lutomirski wrote: >>> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä

Re: [Intel-gfx] i915 Skylake: "Invalid ROM contents"

On Wed, Nov 18, 2015 at 8:12 AM, Daniel Stone wrote: > Hi, > > On 18 November 2015 at 15:59, Andy Lutomirski wrote: >> On Wed, Nov 18, 2015 at 2:59 AM, Ville Syrjälä >> wrote: >>> On Tue, Nov 17, 2015 at 11:43:25AM -0800,

Re: [Intel-gfx] [PATCH 21/21] drm/vmwgfx: Nuke preclose hook

On 01/09/2016 11:43 AM, Daniel Vetter wrote: > On Fri, Jan 8, 2016 at 9:53 PM, Thomas Hellstrom > wrote: >> On 01/08/2016 09:36 PM, Daniel Vetter wrote: >>> Again since the drm core takes care of event unlinking/disarming this >>> is now just needless code. >>> >>> Cc:

[Intel-gfx] [PATCH] drm/vmwgfx: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: I've completely missed eaction->fpriv_head and all the related code. We need to nuke that too to avoid accidentally deferencing the freed-up vmwgfx-private fpriv. Cc: Thomas Hellström

[Intel-gfx] [PATCH 5/5] drm/vmwgfx: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: I've completely missed eaction->fpriv_head and all the related code. We need to nuke that too to avoid accidentally deferencing the freed-up vmwgfx-private fpriv. v3: Also remove

[Intel-gfx] [PATCH 2/5] drm/tegra: Stop cancelling page flip events

The core takes care of that now. v2: Fixup misplaced hunk. Cc: Thierry Reding Cc: Terje Bergström Signed-off-by: Daniel Vetter --- drivers/gpu/drm/tegra/dc.c | 17 - drivers/gpu/drm/tegra/drm.c | 3

[Intel-gfx] [PATCH 1/5] drm/shmob: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: Fixup misplaced hunk. Cc: Laurent Pinchart Signed-off-by: Daniel Vetter --- drivers/gpu/drm/shmobile/shmob_drm_crtc.c | 20

[Intel-gfx] [PATCH 3/5] drm/tilcdc: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: Fixup misplaced hunks. Cc: Rob Clark Signed-off-by: Daniel Vetter --- drivers/gpu/drm/tilcdc/tilcdc_crtc.c | 20

[Intel-gfx] [PATCH 4/5] drm/vc4: Nuke preclose hook

Again since the drm core takes care of event unlinking/disarming this is now just needless code. v2: Fixup misplaced hunk. Cc: Eric Anholt Signed-off-by: Daniel Vetter --- drivers/gpu/drm/vc4/vc4_crtc.c | 20

Re: [Intel-gfx] Intel graphics on Thinkpad T540p is most unsuable now :( (Intel(R) HD Graphics 4600)

I noticed hard lockups using chrome from a *long* way back. Various people have reported issues with Chrome running under Enlightenment, and the consensus ( IIRC ) was that Chrome was using its own libX11 parts or something, and playing havoc with Enlightenment ( messing with focus policy,

Re: [Intel-gfx] [PATCH] Add NULL checking for drawable in sna_dri2_flip_event

Hi, CC-ing Chris Wilson to help do code review DDX driver side and possible others corner case that we didn't spotted. This is corner case that happen hitting assert checking until SNA DDX driver exit. I'm trying to cc-ing Chirs Wilson in "ch...@chris-wilson.co.uk" email address. But received

Re: [Intel-gfx] [PATCH 16/21] drm/rcar: Nuke preclose hook

Hi Daniel, Thank you for the patch. On Friday 08 January 2016 21:36:48 Daniel Vetter wrote: > Again since the drm core takes care of event unlinking/disarming this > is now just needless code. This looks good to me assuming that the mechanism works in the core, which looks like magic to me at

Re: [Intel-gfx] [PATCH 1/5] drm/shmob: Nuke preclose hook

Hi Daniel, Thank you for the patch. On Sunday 10 January 2016 23:26:06 Daniel Vetter wrote: > Again since the drm core takes care of event unlinking/disarming this > is now just needless code. > > v2: Fixup misplaced hunk. > > Cc: Laurent Pinchart >

[Intel-gfx] Updated drm-intel-testing

Hi all, New -testing cycle with cool stuff: - GuC ADS support (Alex Dai) - support for v3 of the vbt mipi/dsi panel sequence (Jani Nikula) - more prep work for atomic watermarks (Matt Roper) - clean up cursor handling and align more with other planes (Maarten) - improvements to the unclaimed mmio

Re: [Intel-gfx] [PATCH] drm: Clean up pending events in the core

Hi Daniel, Thank you for the patch. On Saturday 09 January 2016 14:28:46 Daniel Vetter wrote: > There's really no reason to not do so, instead of replicating this > for every use-case and every driver. Now we can't just nuke the events, > since that would still mean that all drm_event users

Re: [Intel-gfx] [PATCH 21/21] drm/vmwgfx: Nuke preclose hook

On Sun, Jan 10, 2016 at 9:52 PM, Thomas Hellstrom wrote: > On 01/09/2016 11:43 AM, Daniel Vetter wrote: >> On Fri, Jan 8, 2016 at 9:53 PM, Thomas Hellstrom >> wrote: >>> On 01/08/2016 09:36 PM, Daniel Vetter wrote: Again since the drm core takes

Re: [Intel-gfx] Intel graphics on Thinkpad T540p is most unsuable now :( (Intel(R) HD Graphics 4600)

On Mon, Jan 11, 2016 at 09:41:47AM +1100, Daniel Kasak wrote: > I noticed hard lockups using chrome from a *long* way back. Various > people have reported issues with Chrome running under Enlightenment, > and the consensus ( IIRC ) was that Chrome was using its own libX11 > parts or something, and

Re: [Intel-gfx] [PATCH] drm/vmwgfx: Nuke preclose hook

In general, looks good. Two things though. 1) vc4_drv.h looks like it ended up in the wrong patch. 2) Should be able to nuke also struct vmw_fpriv::fence_events and struct vmw_event_fence_action::fpriv_head? /Thomas On 01/10/2016 11:02 PM, Daniel Vetter wrote: > Again since the drm core takes

Re: [Intel-gfx] [PATCH] drm/vmwgfx: Nuke preclose hook

On Sun, Jan 10, 2016 at 11:17 PM, Thomas Hellstrom wrote: > In general, looks good. Two things though. > > 1) vc4_drv.h looks like it ended up in the wrong patch. Oops, will fix. > 2) Should be able to nuke also struct vmw_fpriv::fence_events and struct >

Re: [Intel-gfx] [PATCH 15/21] drm/omap: Nuke close hooks

Hi Daniel, Thank you for the patch. On Friday 08 January 2016 21:36:47 Daniel Vetter wrote: > Again since the core takes care of this we can remove them. While at > it also remove the postclose hook, it's empty. > > Cc: Laurent Pinchart > Cc: Tomi Valkeinen