Re: [Intel-gfx] [RFC v3 02/12] drm/file: Don't set master on in-kernel clients

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:43PM +0100, Noralf Trønnes wrote: > It only makes sense for userspace clients. > > Signed-off-by: Noralf Trønnes I think we might be able to reuse some of the master stuff to better handle hand-over between in-kernel clients and userspace masters for kms. But this d

Re: [Intel-gfx] [RFC v3 04/12] drm: Make ioctls available for in-kernel clients part 2

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:45PM +0100, Noralf Trønnes wrote: > This is part 2 of making ioctls useable for in-kernel clients. > Make an ioctl wrapper function that calls a function that can be used by > in-kernel clients. > > It adjusts the signature of the following functions: > - drm_mode_get

Re: [Intel-gfx] [RFC v3 08/12] drm/framebuffer: Add drm_mode_can_dirtyfb()

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:49PM +0100, Noralf Trønnes wrote: > Add a function so the generic fbdev client can check if the framebuffer > does flushing. This is needed to set up deferred I/O. > > Signed-off-by: Noralf Trønnes Again I guess not needed if we use drm_framebuffer * internally for

Re: [Intel-gfx] [RFC v3 07/12] drm/modes: Add drm_umode_equal()

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:48PM +0100, Noralf Trønnes wrote: > Add a way to check if userspace modes are equal. Useful for in-kernel > clients. Also export drm_mode_convert_umode(). > > Signed-off-by: Noralf Trønnes Assuming we don't use the KMS ioctls for in-kernel clients I guess we don't n

Re: [Intel-gfx] [RFC v3 09/12] drm: Add API for in-kernel clients

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:50PM +0100, Noralf Trønnes wrote: > This adds an API for writing in-kernel clients. > > TODO: > - Flesh out and complete documentation. > - Cloned displays is not tested. > - Complete tiled display support and test it. > - Test plug/unplug different monitors. > - A ru

Re: [Intel-gfx] [RFC v3 10/12] drm/client: Add fbdev emulation client

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:51PM +0100, Noralf Trønnes wrote: > This adds generic fbdev emulation for drivers that support the > dumb buffer API. No fbdev code is necessary in the driver. > > Differences from drm_fb_helper: > - The backing buffer is created when the first fd is opened. > - Suppo

Re: [Intel-gfx] [RFC v3 11/12] drm/client: Add bootsplash client

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 09:06:52PM +0100, Noralf Trønnes wrote: > Just a hack to test the client API. > > Signed-off-by: Noralf Trønnes Adding the suse folks who submitted the bootsplash a while ago, would be great if they could pick this up and run with it. > --- > drivers/gpu/drm/client/Kcon

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

2018-03-06 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2018-03-05 22:21:21) > some of the static functions used from capture() have the "i915_" > prefix while other don't; most of them take i915 as a parameter, but one > of them derives it internally from error->i915. Let's be consistent by > avoiding prefix for static f

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/error: capture uc_state after gen_state

2018-03-06 Thread Chris Wilson
Quoting Daniele Ceraolo Spurio (2018-03-05 22:21:22) > error->device_info.has_guc, which we check in capture_uc_state, is set > in capture_gen_state, so the latter needs to be performed first. > > v2: rebased > > Reported-by: Vinay Belgaumkar > Fixes: 7d41ef3479a6 (drm/i915: Add Guc/HuC firmware

Re: [Intel-gfx] [PATCH 10/15] drm/i915/guc: Get rid of GuC log runtime

2018-03-06 Thread Sagar Arun Kamble
I think keeping the distinction between base/mandatory members and runtime/optional members is okay as they are handled differently. What do others think? another related query, should we alloc/dealloc guc_log work queue in relay_open/release? On 2/27/2018 6:22 PM, Michał Winiarski wrote: Ke

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > edid and display_info are protected by mode_config.mutex. Add lockdep > asserts to make sure we're not accessing things w/o the lock. > > FIXME: pretty sure this will blow up with amdgpu as they seem > to be

Re: [Intel-gfx] [RFC][PATCH 05/11] drm/edid: Clear display info fully

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:54PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Now that we have split the display info into static and dynamic parts, > we can just zero out the entire dynamic part with memset(). Previously > we were just clearing parts of it, leaving stale data in other

[Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915/cnp: Document WaSouthDisplayDisablePWMCGEGating URL : https://patchwork.freedesktop.org/series/39410/ State : failure == Summary == Possible new issues: Test gem_eio: Subgroup in-flight-contexts: pass -> INCOMPLETE (shar

Re: [Intel-gfx] [PATCH v2 3/3] drm/i915/error: capture uc_state after gen_state

2018-03-06 Thread Chris Wilson
Quoting Chris Wilson (2018-03-06 09:23:21) > Quoting Daniele Ceraolo Spurio (2018-03-05 22:21:22) > > error->device_info.has_guc, which we check in capture_uc_state, is set > > in capture_gen_state, so the latter needs to be performed first. > > > > v2: rebased > > > > Reported-by: Vinay Belgaumk

Re: [Intel-gfx] [PATCH igt v3] igt/gen7_forcewake_mt: Make the mmio register as volatile

2018-03-06 Thread Tvrtko Ursulin
On 05/03/2018 17:30, Chris Wilson wrote: Prevent the compiler from caching reads/writes to the hw register as we do want to perform mmio. Whilst fixing up the mmio access, also ensure that we do not leave the test with any other bits still set in the forcewake register to prevent affecting othe

Re: [Intel-gfx] [RFC][PATCH 04/11] drm: Split the display info into static and dynamic parts

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:53PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Currently we have a mix of static and dynamic information stored in > the display info structure. That makes it rather difficult to repopulate > the dynamic parts when a new EDID appears. Let's make life easi

Re: [Intel-gfx] [RFC][PATCH 05/11] drm/edid: Clear display info fully

2018-03-06 Thread Daniel Vetter
On Tue, Mar 06, 2018 at 10:33:31AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:56:54PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Now that we have split the display info into static and dynamic parts, > > we can just zero out the entire dynamic part with memset(). Pr

Re: [Intel-gfx] [PATCH igt v3] igt/gen7_forcewake_mt: Make the mmio register as volatile

2018-03-06 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-03-06 09:37:50) > > On 05/03/2018 17:30, Chris Wilson wrote: > > -static void *igfx_get_mmio(void) > > +static volatile uint32_t *igfx_mmio_forcewake_mt(void) > > I think its overkill to bother with volatile all throughout the chain, > it's not like it's const. But n

Re: [Intel-gfx] [RFC][PATCH 06/11] drm/edid: Don't call drm_add_display_info() with an invalid EDID

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:55PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > drm_mode_connector_update_edid_property() will call > drm_add_display_info() if an invalid edid is passed in. > This differs from the behaviour of drm_add_edid_modes() which > doesn't try to populate the disp

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

2018-03-06 Thread Michal Wajdeczko
On Mon, 05 Mar 2018 23:21:21 +0100, Daniele Ceraolo Spurio wrote: some of the static functions used from capture() have the "i915_" prefix while other don't; most of them take i915 as a parameter, but one of them derives it internally from error->i915. Let's be consistent by avoiding prefix f

Re: [Intel-gfx] [RFC][PATCH 07/11] drm/probe-helper: Avoid iterating the list twice on ww backoff

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:56PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > If we have to backoff there's no point in going over the mode list again > to mark all the modes as stale. We can defer that until we're ready to > refresh the mode list. Avoids multiple list walks if we have

Re: [Intel-gfx] [RFC][PATCH 05/11] drm/edid: Clear display info fully

2018-03-06 Thread Daniel Vetter
On Tue, Mar 06, 2018 at 10:33:31AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:56:54PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Now that we have split the display info into static and dynamic parts, > > we can just zero out the entire dynamic part with memset(). Pr

Re: [Intel-gfx] [RFC][PATCH 09/11] drm: Fix getconnector locking

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:58PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The edid is protected by mode_config.mutex so extend the locking to > protect the property readout part as well. > > Cc: Keith Packard > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä Ehrm no, properti

Re: [Intel-gfx] [RFC][PATCH 10/11] drm: Fix debugfs edid_override locking

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:59PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > The edid is protected by mode_config.mutex. Grab the lock when frobbing > the debugfs edid_override thing. > > Cc: Keith Packard > Cc: Daniel Vetter > Signed-off-by: Ville Syrjälä Yup, this looks correct

Re: [Intel-gfx] [RFC][PATCH 08/11] drm: Add drm_connector_fill_modes()

2018-03-06 Thread Daniel Vetter
On Tue, Feb 27, 2018 at 02:56:57PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Wrap the ->fill_modes() call in a small helper that first clears out the > stale data from connector->display_info. This should guarantee that we > get consistent display_info whether or not the drivers use t

Re: [Intel-gfx] [PATCH v2 2/3] drm/i915/error: standardize function style in error capture

2018-03-06 Thread Chris Wilson
Quoting Michal Wajdeczko (2018-03-06 09:48:14) > On Mon, 05 Mar 2018 23:21:21 +0100, Daniele Ceraolo Spurio > > static __always_inline void dup_param(const char *type, void *x) > > @@ -1749,13 +1744,12 @@ static int capture(void *data) > > capture_params(error); > > capture_uc_state(e

[Intel-gfx] ✓ Fi.CI.IGT: success for drm/i915: add schedule out notification of preempted but completed request (rev2)

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915: add schedule out notification of preempted but completed request (rev2) URL : https://patchwork.freedesktop.org/series/38903/ State : success == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-c-256x256-bottom-edge:

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

2018-03-06 Thread Ville Syrjälä
On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote: > On 2018-03-05 04:33 PM, Alex Deucher wrote: > > On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä > > wrote: > >> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: > >>> Ville Syrjala writes: > >>> > From: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/3] drm: Don't create properties without names

2018-03-06 Thread Daniel Vetter
On Fri, Mar 02, 2018 at 03:25:42PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Creating a property that doesn't have a name makes no sense to me. Don't > allow it. > > Signed-off-by: Ville Syrjälä Reviewed-by: Daniel Vetter > --- > drivers/gpu/drm/drm_property.c | 6 ++ > 1 fi

Re: [Intel-gfx] [PATCH] drm/i915: Handle changing enable_fbc parameter at runtime better.

2018-03-06 Thread Maarten Lankhorst
Op 05-03-18 om 19:50 schreef Rodrigo Vivi: > On Mon, Mar 05, 2018 at 01:36:08PM +0100, Maarten Lankhorst wrote: >> If i915.enable_fbc is cleared at runtime, but FBC was previously enabled >> then we don't disable FBC until the next time the crtc is disabled. >> >> Make sure that if the module param

Re: [Intel-gfx] [PATCH v2 2/3 drm: Check property/enum name length

2018-03-06 Thread Daniel Vetter
On Fri, Mar 02, 2018 at 04:03:00PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Reject requests to add properties/enums with an overly long name. > Previously we would have just silently truncated the string and exposed > it userspace. > > v2: drm_property_create() returns a pointer >

Re: [Intel-gfx] [RFC][PATCH 08/11] drm: Add drm_connector_fill_modes()

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 11:00:30AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:56:57PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Wrap the ->fill_modes() call in a small helper that first clears out the > > stale data from connector->display_info. This should guarant

Re: [Intel-gfx] [PATCH 3/3] drm: Fix some coding style issues

2018-03-06 Thread Daniel Vetter
On Mon, Mar 05, 2018 at 04:49:19PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > Put an empty line between the variable declarations and the code, and > use tabs for alignment. > > Signed-off-by: Ville Syrjälä Acked-by: Daniel Vetter > --- > drivers/gpu/drm/drm_framebuffer.c | 5 +++-

Re: [Intel-gfx] [PATCH 1/3] drm: Make sure at least one plane supports the fb format

2018-03-06 Thread Daniel Vetter
On Mon, Mar 05, 2018 at 05:44:16PM -0500, Harry Wentland wrote: > On 2018-03-05 04:33 PM, Alex Deucher wrote: > > On Mon, Mar 5, 2018 at 4:15 PM, Ville Syrjälä > > wrote: > >> On Mon, Mar 05, 2018 at 12:59:00PM -0800, Eric Anholt wrote: > >>> Ville Syrjala writes: > >>> > From: Ville Syrjälä

[Intel-gfx] [PATCH] drm/i915/icl: do not save DDI A/E sharing bit for ICL

2018-03-06 Thread Jani Nikula
We don't want to preserve the DDI A 4 lane bit on ICL. Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing limitation.") Cc: Mahesh Kumar Cc: Paulo Zanoni Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_ddi.c | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-)

[Intel-gfx] [PATCH igt] igt/gen7_forcewake_mt: Make the mmio register as volatile

2018-03-06 Thread Chris Wilson
Prevent the compiler from caching reads/writes to the hw register as we do want to perform mmio. Whilst fixing up the mmio access, also ensure that we do not leave the test with any other bits still set in the forcewake register to prevent affecting other tests, as spotted by Tvrtko. v2: Use inte

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel-gpu-overlay: Update for renamed tracepoints

2018-03-06 Thread Chris Wilson
Quoting Tvrtko Ursulin (2018-03-05 12:41:58) > From: Tvrtko Ursulin > > Request tracepoints have been renames so update the tool to be able to > find them. > > Also support falling back to the old name for compatibility. > > Signed-off-by: Tvrtko Ursulin > --- > Compile tested only so also loo

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/icl: do not save DDI A/E sharing bit for ICL

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915/icl: do not save DDI A/E sharing bit for ICL URL : https://patchwork.freedesktop.org/series/39439/ State : success == Summary == Series 39439v1 drm/i915/icl: do not save DDI A/E sharing bit for ICL https://patchwork.freedesktop.org/api/1.0/series/39439/rev

Re: [Intel-gfx] [PATCH igt] igt/gen7_forcewake_mt: Make the mmio register as volatile

2018-03-06 Thread Chris Wilson
Quoting Chris Wilson (2018-03-06 10:41:41) > static void *thread(void *arg) > { > + static const char acquire_error[] = "acquire"; > + static const char release_error[] = "release"; > + > struct thread *t = arg; > - uint32_t *forcewake_mt = (uint32_t *)((char *)t->mmio +

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] intel-gpu-overlay: Update for renamed tracepoints

2018-03-06 Thread Tvrtko Ursulin
On 06/03/2018 10:58, Chris Wilson wrote: Quoting Tvrtko Ursulin (2018-03-05 12:41:58) From: Tvrtko Ursulin Request tracepoints have been renames so update the tool to be able to find them. Also support falling back to the old name for compatibility. Signed-off-by: Tvrtko Ursulin --- Compil

Re: [Intel-gfx] [PATCH 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

2018-03-06 Thread Sagar Arun Kamble
On 2/27/2018 6:22 PM, Michał Winiarski wrote: If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter reason for this? I think this was needed for verifying log flushes. and tidy the debugfs for

[Intel-gfx] [PATCH igt 2/2] igt: Remoe gen7_forcewake_mt

2018-03-06 Thread Chris Wilson
Having demonstrated that FORCEWAKE_MT is suspect to the same old concurrent mmio access bug that stalks gen7, we have shown that it is not viable for userspace to poke around inside FORCEWAKE_MT directly. As it can not work correctly, remove the test. Signed-off-by: Chris Wilson Reviewed-by: Tvrt

[Intel-gfx] [PATCH igt 1/2] igt/gen7_forcewake_mt: Make the mmio register as volatile

2018-03-06 Thread Chris Wilson
Prevent the compiler from caching reads/writes to the hw register as we do want to perform mmio. Whilst fixing up the mmio access, also ensure that we do not leave the test with any other bits still set in the forcewake register to prevent affecting other tests, as spotted by Tvrtko. v2: Use inte

Re: [Intel-gfx] [RFC][PATCH 07/11] drm/probe-helper: Avoid iterating the list twice on ww backoff

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 10:49:43AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:56:56PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > If we have to backoff there's no point in going over the mode list again > > to mark all the modes as stale. We can defer that until we'r

Re: [Intel-gfx] [PATCH v2 2/3 drm: Check property/enum name length

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 11:22:54AM +0100, Daniel Vetter wrote: > On Fri, Mar 02, 2018 at 04:03:00PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Reject requests to add properties/enums with an overly long name. > > Previously we would have just silently truncated the string and exp

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] igt/gen7_forcewake_mt: Make the mmio register as volatile

2018-03-06 Thread Patchwork
== Series Details == Series: series starting with [1/2] igt/gen7_forcewake_mt: Make the mmio register as volatile URL : https://patchwork.freedesktop.org/series/39443/ State : failure == Summary == IGT patchset tested on top of latest successful build 68fb7595bc16a9672ea20e86431763f833cf47a7

Re: [Intel-gfx] [PATCH v2 1/3] drm: Make sure at least one plane supports the fb format

2018-03-06 Thread Ville Syrjälä
On Mon, Mar 05, 2018 at 11:41:02PM +0200, Ville Syrjala wrote: > From: Ville Syrjälä > > To make life easier for drivers, let's have the core check that the > requested pixel format is supported by at least one plane when creating > a new framebuffer. > > v2: Accept anyformat if the driver doesn

Re: [Intel-gfx] [PATCH 13/15] drm/i915/guc: Allow user to control default GuC logging

2018-03-06 Thread Sagar Arun Kamble
On 2/27/2018 6:22 PM, Michał Winiarski wrote: While both naming and actual log enable logic in GuC interface are confusing, we can simply expose the default log as yet another log level. GuC logic aside, from i915 point of view we now have the following GuC log levels: 0 Log disabled

Re: [Intel-gfx] [PATCH 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

2018-03-06 Thread Michał Winiarski
On Tue, Mar 06, 2018 at 04:51:27PM +0530, Sagar Arun Kamble wrote: > > > On 2/27/2018 6:22 PM, Michał Winiarski wrote: > > If nobody has enabled the relay, we're not comunicating with GuC, which > > means that the stats don't have any meaning. Let's also remove interrupt > > counter > reason for

[Intel-gfx] [PATCH v3] drm/i915/guc: Remove GUC_CTL_DEVICE_INFO parameter

2018-03-06 Thread Piotr Piórkowski
It looks that GuC does not actively use GUC_CTL_DEVICE_INFO parameter where we are passing GT type and Core family values. Let's stop/remove setup of this parameter and remove related definitions. v2: (this time without squashed HAX) - New title and description - Remove also GUC_CORE_FAMILY_*

Re: [Intel-gfx] [PATCH] drm/i915/icl: do not save DDI A/E sharing bit for ICL

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 12:41:55PM +0200, Jani Nikula wrote: > We don't want to preserve the DDI A 4 lane bit on ICL. > > Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing limitation.") > Cc: Mahesh Kumar > Cc: Paulo Zanoni > Signed-off-by: Jani Nikula Reviewed-by: Ville Syrjälä

Re: [Intel-gfx] [PATCH 1/2] drm/i915/breadcrumbs: Reduce signaler rbtree to a sorted list

2018-03-06 Thread Chris Wilson
Quoting Joonas Lahtinen (2018-03-05 14:25:07) > As a pre-existing condition it's bit surprising that intel_breadcrumbs_busy() > kicks the signaler as a side-effect. Since we explicitly cancel the signaling on retire now (to prevent the accumulation of references), we can actually say that we don't

Re: [Intel-gfx] [RFC][PATCH 11/11] drm: Sprinkle lockdep asserts for edid/display_info

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 10:31:27AM +0100, Daniel Vetter wrote: > On Tue, Feb 27, 2018 at 02:57:00PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > edid and display_info are protected by mode_config.mutex. Add lockdep > > asserts to make sure we're not accessing things w/o the lock. >

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/2] drm/i915/breadcrumbs: Reduce signaler rbtree to a sorted list

2018-03-06 Thread Chris Wilson
Quoting Patchwork (2018-02-22 13:51:19) > == Series Details == > > Series: series starting with [1/2] drm/i915/breadcrumbs: Reduce signaler > rbtree to a sorted list > URL : https://patchwork.freedesktop.org/series/38755/ > State : success > > == Summary == > > Test pm_rps: > Subgroup

[Intel-gfx] [PATCH v17 1/6] drm/i915: store all subslice masks

2018-03-06 Thread Lionel Landwerlin
Up to now, subslice mask was assumed to be uniform across slices. But starting with Cannonlake, slices can be asymmetric (for example slice0 has different number of subslices as slice1+). This change stores all subslices masks for all slices rather than having a single mask that applies to all slic

[Intel-gfx] [PATCH v17 2/6] drm/i915/debugfs: reuse max slice/subslices already stored in sseu

2018-03-06 Thread Lionel Landwerlin
Now that we have that information in topology fields, let's just reuse it. v2: Style tweaks (Tvrtko) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin Acked-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 27 +++ drivers/gpu/drm/i915/intel_de

[Intel-gfx] [PATCH v17 4/6] drm/i915: add rcs topology to error state

2018-03-06 Thread Lionel Landwerlin
This might be useful information for developers looking at an error state. v2: Place topology towards the end of the error state (Chris) v3: Reuse common printing code (Michal) v4: Make this a one-liner (Chris) Signed-off-by: Lionel Landwerlin Reviewed-by: Tvrtko Ursulin Acked-by: Chris Wilso

[Intel-gfx] [PATCH v17 3/6] drm/i915/debugfs: add rcs topology entry

2018-03-06 Thread Lionel Landwerlin
While the end goal is to make this information available to userspace through a new ioctl, there is no reason we can't display it in a human readable fashion through debugfs. slice0: 3 subslice(s) (0x7): subslice0: 8 EUs (0xff) subslice1: 8 EUs (0xff) subslice2: 8 EUs (0xff

[Intel-gfx] [PATCH v17 6/6] drm/i915: expose rcs topology through query uAPI

2018-03-06 Thread Lionel Landwerlin
With the introduction of asymmetric slices in CNL, we cannot rely on the previous SUBSLICE_MASK getparam to tell userspace what subslices are available. Here we introduce a more detailed way of querying the Gen's GPU topology that doesn't aggregate numbers. This is essential for monitoring parts o

[Intel-gfx] [PATCH v17 5/6] drm/i915: add query uAPI

2018-03-06 Thread Lionel Landwerlin
There are a number of information that are readable from hardware registers and that we would like to make accessible to userspace. One particular example is the topology of the execution units (how are execution units grouped in subslices and slices and also which ones have been fused off for die

[Intel-gfx] [PATCH v17 0/6] drm/i915: expose RCS topology to userspace

2018-03-06 Thread Lionel Landwerlin
Hi, This is the last iteration. Got Rbs form all relevant developers and the Mesa patches using this API have been Acked. Just sending the few nits from Joonas and waiting for CI results. Thank you all! Lionel Landwerlin (6): drm/i915: store all subslice masks drm/i915/debugfs: reuse max sli

[Intel-gfx] [PATCH i-g-t 09/11] trace.pl: Add support for colouring context execution

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Add the command line switch which uses different colours for different context execution boxes. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 41 +++-- 1 file changed, 39 insertions(+), 2 deletions(-) diff --gi

[Intel-gfx] [PATCH i-g-t 02/11] scripts/trace.pl: More hash key optimisations

2018-03-06 Thread Tvrtko Ursulin
From: John Harrison Cache the key count value rather than querying the hash every time. Also assert that the database does not magically change size after the fixups. v2: Rename variable according to style guide [Tvrtko] v3: Reverted accidental style change and added a blank line. [Tvrtko] Sig

[Intel-gfx] [PATCH i-g-t 11/11] trace.pl: Fix request split mode

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Request split mode had several bugs, both in the original version and also after the recent refactorings. One big one was that it wasn't considering different submit ports as a reason to split execution, and also that it was too time based instead of looking at relevant time

[Intel-gfx] [PATCH i-g-t 03/11] scripts/trace.pl: Sort order

2018-03-06 Thread Tvrtko Ursulin
From: John Harrison Add an extra level to the databse key sort so that the ordering is deterministic. If the time stamp matches, it now compares the key itself as well (context/seqno). This makes it much easier to determine if a change has actually broken anything. Previously back to back runs wi

[Intel-gfx] [PATCH i-g-t 06/11] trace.pl: Move sortQueue near its user

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Just to clear up some space for incoming code refactoring. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/scripts/trace.pl b/scripts/trace.pl index 509df6c0d

[Intel-gfx] [PATCH i-g-t 01/11] trace.pl: Catch-up with tracepoint renames

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin i915 renamed the request related tracepoints so catch up with that. Signed-off-by: Tvrtko Ursulin --- scripts/trace.pl | 36 ++-- 1 file changed, 18 insertions(+), 18 deletions(-) diff --git a/scripts/trace.pl b/scripts/trace.pl index cb939

[Intel-gfx] [PATCH i-g-t v2 00/11] trace.pl fixes

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Collection of fixes on top of John's recent work. Problems were mostly in the request split logic which had several issues both in my original version, and also after John's improvements. Handling of "incomplete" requests (the ones which received neither notify nor context

[Intel-gfx] [PATCH i-g-t 10/11] trace.pl: Fix incomplete request handling

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin Incomplete requests (no notify, no context complete) have to be corrected by looking at the engine timeline, and not the sorted-by-start-time view as was previously used. Per-engine timelines are generated on demand and cached for later use. v2: Find end of current context

[Intel-gfx] [PATCH i-g-t 04/11] scripts/trace.pl: Calculate stats only after all munging

2018-03-06 Thread Tvrtko Ursulin
From: John Harrison There are various statistics being calculated multiple times in multiple places while the log file is being read in. Some of these are then re-calculated when the database is munged to correct various issues with the logs. This patch consolidates the calculations into a separa

[Intel-gfx] [PATCH i-g-t 05/11] scripts/trace.pl: Simplify 'end' & 'notify' generation

2018-03-06 Thread Tvrtko Ursulin
From: John Harrison Delay the auto-generation of end/notify values until the point where everything is known. As opposed to potentially generating them multiple times with differing values (in the case of 'incomplete' entries). v2: More complete description. [Tvrtko] Signed-off-by: John Harriso

[Intel-gfx] [PATCH i-g-t 07/11] trace.pl: Move min/max timestamp lookup to last loop

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin It makes sense to fetch the min and max timestamp only after the last sort of the array. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/scripts/trace.pl b/scripts/trace.p

[Intel-gfx] [PATCH i-g-t 08/11] trace.pl: Fix engine busy accounting in split mode

2018-03-06 Thread Tvrtko Ursulin
From: Tvrtko Ursulin In split mode all requests have to be added up since they were previously re-arranged so there is no overlap. Signed-off-by: Tvrtko Ursulin Cc: John Harrison --- scripts/trace.pl | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/trace.pl b/scri

Re: [Intel-gfx] [PATCH v2 1/3] drm: Make sure at least one plane supports the fb format

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 01:57:26PM +0200, Ville Syrjälä wrote: > On Mon, Mar 05, 2018 at 11:41:02PM +0200, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > To make life easier for drivers, let's have the core check that the > > requested pixel format is supported by at least one plane when cr

[Intel-gfx] [PATCH 2/2] drm/i915: Flush waiters on seqno wraparound

2018-03-06 Thread Chris Wilson
Previously, we would spin waiting for all waiters to wake up and notice their request had completed before we would reset the seqno upon wraparound. However, we can mark their waits as complete and wake them up directly using the existing machinery for handling the flushing of missed wakeups when

[Intel-gfx] [PATCH 1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound

2018-03-06 Thread Chris Wilson
Since commit fd10e2ce9905 ("drm/i915/breadcrumbs: Ignore unsubmitted signalers"), we cancel the signaler when retiring the request and so upon wraparound, where we wait for all requests to be retired, we no longer need to spin waiting for the signaling thread to release its references to the in-fli

Re: [Intel-gfx] [PATCH 12/15] drm/i915/guc: Don't print out relay statistics when relay is disabled

2018-03-06 Thread Sagar Arun Kamble
I think we should also clear the stats.count and relay_full_count on relay_open. Thanks Sagar On 2/27/2018 6:22 PM, Michał Winiarski wrote: If nobody has enabled the relay, we're not comunicating with GuC, which means that the stats don't have any meaning. Let's also remove interrupt counter a

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Removed unused GuC parameters. (rev3)

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915/guc: Removed unused GuC parameters. (rev3) URL : https://patchwork.freedesktop.org/series/39154/ State : success == Summary == Series 39154v3 drm/i915/guc: Removed unused GuC parameters. https://patchwork.freedesktop.org/api/1.0/series/39154/revisions/3/mb

[Intel-gfx] ✗ Fi.CI.SPARSE: warning for drm/i915: expose RCS topology to userspace

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/39446/ State : warning == Summary == $ dim sparse origin/drm-tip Commit: drm/i915: store all subslice masks Okay! Commit: drm/i915/debugfs: reuse max slice/subslices already

Re: [Intel-gfx] [PATCH 1/3] drm: Don't create properties without names

2018-03-06 Thread Emil Velikov
Hi Ville, On 2 March 2018 at 13:25, Ville Syrjala wrote: > From: Ville Syrjälä > > Creating a property that doesn't have a name makes no sense to me. Don't > allow it. > > Signed-off-by: Ville Syrjälä > --- > drivers/gpu/drm/drm_property.c | 6 ++ > 1 file changed, 2 insertions(+), 4 delet

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: expose RCS topology to userspace

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915: expose RCS topology to userspace URL : https://patchwork.freedesktop.org/series/39446/ State : success == Summary == Series 39446v1 drm/i915: expose RCS topology to userspace https://patchwork.freedesktop.org/api/1.0/series/39446/revisions/1/mbox/ fi-bdw

Re: [Intel-gfx] [PATCH i-g-t v2 03/14] lib/igt_kms: Rework pipe properties to be more atomic, v7.

2018-03-06 Thread Daniel Vetter
On Mon, Mar 05, 2018 at 03:37:30PM +0100, Maxime Ripard wrote: > Hi, > > On Thu, Oct 12, 2017 at 01:54:24PM +0200, Maarten Lankhorst wrote: > > In the future I want to allow tests to commit more properties, > > but for this to work I have to fix all properties to work better > > with atomic commit

Re: [Intel-gfx] [PATCH 14/15] drm/i915/guc: Default to non-verbose GuC logging

2018-03-06 Thread Sagar Arun Kamble
On 2/27/2018 6:22 PM, Michał Winiarski wrote: Now that we've decoupled logging from relay, GuC log level is only controlling the GuC behavior - there shouldn't be any impact on i915 behaviour. We're only going to see a single extra interrupt when log will get half full. That, and the fact that

Re: [Intel-gfx] [PATCH i-g-t v2 03/14] lib/igt_kms: Rework pipe properties to be more atomic, v7.

2018-03-06 Thread Maarten Lankhorst
Op 06-03-18 om 14:41 schreef Daniel Vetter: > On Mon, Mar 05, 2018 at 03:37:30PM +0100, Maxime Ripard wrote: >> Hi, >> >> On Thu, Oct 12, 2017 at 01:54:24PM +0200, Maarten Lankhorst wrote: >>> In the future I want to allow tests to commit more properties, >>> but for this to work I have to fix all

Re: [Intel-gfx] [PATCH 05/15] drm/i915/guc: Log runtime should consist of both mapping and relay

2018-03-06 Thread Chris Wilson
Quoting Michał Winiarski (2018-02-27 12:52:20) > -static int guc_log_runtime_create(struct intel_guc *guc) > +static int guc_log_map(struct intel_guc *guc) > { > struct drm_i915_private *dev_priv = guc_to_i915(guc); > void *vaddr; > int ret; > > - lockdep_assert_hel

Re: [Intel-gfx] [PATCH i-g-t 2/3] meson: gtkdoc support

2018-03-06 Thread Daniel Vetter
On Thu, Feb 22, 2018 at 03:54:09PM -0800, Eric Anholt wrote: > Daniel Vetter writes: > > > Bunch of neat improvements: > > > > - xml generates correctly depend upon the test binaries > > - no need to re-run autogen.sh when new chapters/functions get added, > > all handed by meson > > I just re

Re: [Intel-gfx] [PATCH 1/3] drm: Don't create properties without names

2018-03-06 Thread Ville Syrjälä
On Tue, Mar 06, 2018 at 01:35:11PM +, Emil Velikov wrote: > Hi Ville, > > On 2 March 2018 at 13:25, Ville Syrjala wrote: > > From: Ville Syrjälä > > > > Creating a property that doesn't have a name makes no sense to me. Don't > > allow it. > > > > Signed-off-by: Ville Syrjälä > > --- > > d

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound

2018-03-06 Thread Patchwork
== Series Details == Series: series starting with [1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound URL : https://patchwork.freedesktop.org/series/39448/ State : success == Summary == Series 39448v1 series starting with [1/2] drm/i915: Stop kicking the signaling thread on

Re: [Intel-gfx] [PATCH 09/15] drm/i915/guc: Move check for fast memcpy_wc to relay creation

2018-03-06 Thread Chris Wilson
Quoting Michał Winiarski (2018-02-27 15:37:04) > On Tue, Feb 27, 2018 at 03:37:25PM +0100, Michal Wajdeczko wrote: > > On Tue, 27 Feb 2018 13:52:24 +0100, Michał Winiarski > > wrote: > > > > > We only need those fast memcpy_wc when we're using relay to read > > > continuous GuC log. Let's prevent

Re: [Intel-gfx] [PATCH 10/15] drm/i915/guc: Get rid of GuC log runtime

2018-03-06 Thread Chris Wilson
Quoting Michał Winiarski (2018-02-27 12:52:25) > Keeping a separate runtime struct is only making the code dealing with > relay less clear to read. Let's get rid of it, keeping everything in the > log instead. Or is just misnamed s/runtime/relay/, shorten a few member names for precision and take

[Intel-gfx] [PATCH] drm/i915: Disable pipe CRC before disabling the pipe.

2018-03-06 Thread Maarten Lankhorst
[ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Disable pipe CRC before disabling the pipe.

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915: Disable pipe CRC before disabling the pipe. URL : https://patchwork.freedesktop.org/series/39454/ State : failure == Summary == Applying: drm/i915: Disable pipe CRC before disabling the pipe. error: sha1 information is lacking or useless (drivers/gpu/drm

Re: [Intel-gfx] [PATCH] drm/i915/icl: do not save DDI A/E sharing bit for ICL

2018-03-06 Thread Paulo Zanoni
Em Ter, 2018-03-06 às 12:41 +0200, Jani Nikula escreveu: > We don't want to preserve the DDI A 4 lane bit on ICL. > Why not review https://patchwork.freedesktop.org/patch/206118/ instead? :) > Fixes: 3d2011cfa41f ("drm/i915/icl: remove port A/E lane sharing > limitation.") > Cc: Mahesh Kumar >

Re: [Intel-gfx] [igt-dev] [PATCH igt] igt/kms_frontbuffer_tracking: Disable FBC testing for -ENODEV

2018-03-06 Thread Daniel Vetter
On Tue, Feb 20, 2018 at 12:22:19PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2018-02-20 12:17:18) > > On Thu, Feb 15, 2018 at 09:21:47AM +, Chris Wilson wrote: > > > Quoting Chris Wilson (2018-02-11 18:54:33) > > > > Signed-off-by: Chris Wilson > > > > > > Poke, CI is still tripping

Re: [Intel-gfx] [PATCH igt] igt/kms_frontbuffer_tracking: Wait for PSR to be disabled

2018-03-06 Thread Daniel Vetter
On Tue, Feb 20, 2018 at 04:31:40PM +, Chris Wilson wrote: > Quoting Daniel Vetter (2018-02-20 15:44:38) > > On Tue, Feb 20, 2018 at 02:33:08PM +, Chris Wilson wrote: > > > PSR may not exit instantaneously, so while asserting that PSR is > > > disabled after an action, we may have to wait a

[Intel-gfx] ✗ Fi.CI.IGT: warning for drm/i915/icl: do not save DDI A/E sharing bit for ICL

2018-03-06 Thread Patchwork
== Series Details == Series: drm/i915/icl: do not save DDI A/E sharing bit for ICL URL : https://patchwork.freedesktop.org/series/39439/ State : warning == Summary == Possible new issues: Test kms_chv_cursor_fail: Subgroup pipe-c-64x64-top-edge: pass -> DMES

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Stop kicking the signaling thread on seqno wraparound

2018-03-06 Thread Joonas Lahtinen
On Tue, 2018-03-06 at 13:01 +, Chris Wilson wrote: > Since commit fd10e2ce9905 ("drm/i915/breadcrumbs: Ignore unsubmitted > signalers"), we cancel the signaler when retiring the request and so > upon wraparound, where we wait for all requests to be retired, we no > longer need to spin waiting f

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Flush waiters on seqno wraparound

2018-03-06 Thread Joonas Lahtinen
On Tue, 2018-03-06 at 13:01 +, Chris Wilson wrote: > Previously, we would spin waiting for all waiters to wake up and notice > their request had completed before we would reset the seqno upon > wraparound. However, we can mark their waits as complete and wake them > up directly using the exist

[Intel-gfx] [PATCH] drm/i915: Disable pipe CRC before disabling the pipe.

2018-03-06 Thread Maarten Lankhorst
[ 74.730271] WARNING: CPU: 4 PID: 0 at drivers/gpu/drm/drm_vblank.c:614 drm_calc_vbltimestamp_from_scanoutpos+0x13e/0x2f0 [ 74.730311] Modules linked in: vgem snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic i915 x86_pkg_temp_thermal intel_powerclamp coretemp snd_hda_intel crct

Re: [Intel-gfx] [RFC v3 11/12] drm/client: Add bootsplash client

2018-03-06 Thread Max Staudt
Thanks for CCing! I like the idea of this patchset. As far as I understand, this multiplexing is exactly what I would have had to write in order to port the bootsplash to DRM. And we finally get rid of the driver-specific FB emulation hacks, too. Good riddance. Thanks for the initiative, Noral

  1   2   >