Re: [Intel-gfx] [PATCH v2] drm/i915: reinstate call to trace_i915_vma_bind

On Fri, Jan 20, 2017 at 01:51:23PM -0800, Daniele Ceraolo Spurio wrote: > The call went away in: > > commit 3b16525cc4c1a43e9053cfdc414356eea24bdfad > Author: Chris Wilson > Date: Thu Aug 4 16:32:25 2016 +0100 > > drm/i915: Split insertion/binding of an object

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Provide a driver hook for drm_dev_release() (rev3)

== Series Details == Series: drm: Provide a driver hook for drm_dev_release() (rev3) URL : https://patchwork.freedesktop.org/series/16538/ State : success == Summary == Series 16538v3 drm: Provide a driver hook for drm_dev_release()

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Split intel_engine allocation and initialisation

== Series Details == Series: series starting with [1/2] drm/i915: Split intel_engine allocation and initialisation URL : https://patchwork.freedesktop.org/series/18347/ State : success == Summary == Series 18347v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Only disable execlist preemption for the duration of the request

On Sat, Jan 21, 2017 at 10:54:09AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [1/4] drm/i915: Only disable execlist preemption > for the duration of the request > URL : https://patchwork.freedesktop.org/series/18340/ > State : warning > > == Summary == >

[Intel-gfx] [PATCH v2] drm: Provide a driver hook for drm_dev_release()

Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected (i.e. the current pattern of the driver tearing

[Intel-gfx] [PATCH 1/4] drm/i915: Only disable execlist preemption for the duration of the request

We need to prevent resubmission of the context immediately following an initial resubmit (which does a lite-restore preemption). Currently we do this by disabling all submission whilst the context is still active, but we can improve this by limiting the restriction to only until we receive

[Intel-gfx] [PATCH 4/4] drm/i915: Emit dma-fence (and execlists submit) first from signaler

When introduced, I thought that reducing client latency from the signaler was the priority. Since its inception the signaler has become responsible for keeping the execlists full, via the dma-fence. As this is very important to minimise overall execution time, signal the dma-fence first and then

[Intel-gfx] [PATCH 2/4] drm/i915: Skip the execlists CSB scan and rewrite if the ring is untouched

If the CSB head/tail pointers are unchanged, we can skip the update of the CSB register afterwards. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git

[Intel-gfx] [PATCH 3/4] drm/i915: Dequeue execlists on a new request if any port is available

If the second ELSP port is available, schedule the execlists tasklet to see if the new request can occupy it. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_lrc.c | 2 +- 1 file changed, 1 insertion(+), 1

Re: [Intel-gfx] [PATCH v3] drm: Provide a driver hook for drm_dev_release()

Den 21.01.2017 11:58, skrev Chris Wilson: Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected

[Intel-gfx] [PATCH 1/3] drm/i915: Tidy max/display priority macro

Convert I915_PRIORITY_DISPLAY to an enum for easier ranking with new priorities in later patches. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 1 - drivers/gpu/drm/i915/i915_gem_request.h | 4 2 files changed, 4 insertions(+), 1

[Intel-gfx] [PATCH 2/3] drm/i915: Priority boost for locked waits

We always try to do an unlocked wait before resorting to having a blocking wait under the mutex - so we very rarely have to sleep under the struct_mutex. However, when we do we want that wait to be as short as possible as the struct_mutex is our BKL that will stall the driver and all clients.

[Intel-gfx] [PATCH 3/3] drm/i915: Priority boost switching to an idle ring

In order to maximise concurrency between engines, if we queue a request to a current idle ring, reorder its dependencies to execute that request as early as possible and ideally improve occupancy of multiple engines simultaneously. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Pass around gen to tile_height to special case gen2

On Fri, Jan 20, 2017 at 02:29:38PM +0200, Joonas Lahtinen wrote: > On to, 2017-01-19 at 19:26 +, Chris Wilson wrote: > > gen2 has a different tiling pattern, and a fixed tile_height. Pass > > along the gen so that we the computed tile_row is large enough to align > > with gen2 fences. > > > >

[Intel-gfx] [PATCH v3] drm: Provide a driver hook for drm_dev_release()

Some state is coupled into the device lifetime outside of the load/unload timeframe and requires teardown during final unreference from drm_dev_release(). For example, dmabufs hold both a device and module reference and may live longer than expected (i.e. the current pattern of the driver tearing

[Intel-gfx] [PATCH 1/2] drm/i915: Split intel_engine allocation and initialisation

In order to reset the GPU early on in the module load sequence, we need to allocate the basic engine structs (to populate the mmio offsets etc). Currently, the engine initialisation allocates both the base struct and also allocate auxiliary objects, which depend upon state setup quite late in the

[Intel-gfx] [PATCH 2/2] drm/i915: Reset the gpu on takeover

The GPU may be in an unknown state following resume and module load. The previous occupant may have left contexts loaded, or other dangerous state, which can cause an immediate GPU hang for us. The only save course of action is to reset the GPU prior to using it - similarly to how we reset the GPU

Re: [Intel-gfx] [PATCH 0/4] Add automation support for DP Compliance (Rev 6)

On Sat, 21 Jan 2017, Manasi Navare wrote: > This patch series addresses all the review comments from the previous series: > https://patchwork.freedesktop.org/series/18256/ It does not, and it frustrates me. BR, Jani. > > On top of that it also adds a fix for CRC

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Priority boost switching to an idle ring

On Sat, Jan 21, 2017 at 09:25:26AM +, Chris Wilson wrote: > In order to maximise concurrency between engines, if we queue a request > to a current idle ring, reorder its dependencies to execute that request > as early as possible and ideally improve occupancy of multiple engines >

[Intel-gfx] ✓ Fi.CI.BAT: success for agp/intel: Move intel_fake_agp_sizes into #ifdef block

== Series Details == Series: agp/intel: Move intel_fake_agp_sizes into #ifdef block URL : https://patchwork.freedesktop.org/series/18357/ State : success == Summary == Series 18357v1 agp/intel: Move intel_fake_agp_sizes into #ifdef block

Re: [Intel-gfx] [PATCH v3] drm: Provide a driver hook for drm_dev_release()

Hi Chris, Thank you for the patch. On Saturday 21 Jan 2017 10:58:25 Chris Wilson wrote: > Some state is coupled into the device lifetime outside of the > load/unload timeframe and requires teardown during final unreference > from drm_dev_release(). For example, dmabufs hold both a device and >

[Intel-gfx] [PATCH 2/2] drm/i915: Assert that the context-switch completion matches our context

When execlists signals the context completion, it also provides the context id for the status event. Assert that id matches the one we expect. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_lrc.c | 4 1 file changed, 4 insertions(+) diff --git

[Intel-gfx] [PATCH 1/2] drm/i915: Assert that the kernel_context is hw-id 0

For easy recognisability, we want the kernel context to have id 0 and all user contexts to have non-zero ids. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_context.c | 5 + 1 file changed, 5 insertions(+) diff --git

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Assert that the kernel_context is hw-id 0

== Series Details == Series: series starting with [1/2] drm/i915: Assert that the kernel_context is hw-id 0 URL : https://patchwork.freedesktop.org/series/18353/ State : success == Summary == Series 18353v1 Series without cover letter

[Intel-gfx] [PATCH] agp/intel: Move intel_fake_agp_sizes into #ifdef block

Move the intel_fake_agp_sizes array into the same #ifdef block as it is used to avoid instantiation when not used, and so triggering a compiler warning drivers/char/agp/intel-gtt.c:335:42: warning: ‘intel_fake_agp_sizes’ defined but not used [-Wunused-const-variable=] Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH 01/11] drm/i915/dp: use known correct array size in rate_to_index

I can't think of a real world bug this could cause now, but this will be required in follow-up work. While at it, change the parameter order to be slightly more sensible. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 11 ++- 1 file changed, 6

[Intel-gfx] [PATCH 00/11] drm/i915/dp: link rate and lane count refactoring

The link rate and lane count management has become quite convoluted. Clean it up. Calculate source/sink/common rates only once. Separate the max link rate and lane count from the source/sink max link rate and lane counts; the former are dynamic and depend on the link conditions, the latter are

[Intel-gfx] [PATCH 11/11] drm/i915/mst: use max link not sink lane count

The source might not support as many lanes as the sink, or the link training might have failed at higher lane counts. Take these into account. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 2 +- drivers/gpu/drm/i915/intel_dp_mst.c | 4 ++--

[Intel-gfx] [PATCH 09/11] drm/i915/dp: don't call the link parameters sink parameters

If we modify these on the fly depending on the link conditions, don't pretend they are sink properties. Some link vs. sink confusion still remains, but we'll take care of them in follow-up patches. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 23

[Intel-gfx] [PATCH 10/11] drm/i915/dp: add functions for max common link rate and lane count

These are the theoretical maximums common for source and sink. These are the maximums we should start with. They may be degraded in case of link training failures, and the dynamic link values are stored separately. Signed-off-by: Jani Nikula ---

[Intel-gfx] [PATCH 05/11] drm/i915/dp: generate and cache sink rate array for all DP, not just eDP 1.4

There is some conflation related to sink rates, making this change more complicated than it would otherwise have to be. There are three changes here that are rather difficult to split up: 1) Use the intel_dp->sink_rates array for all DP, not just eDP 1.4. We initialize it from DPCD on eDP 1.4

[Intel-gfx] [PATCH 04/11] drm/i915/dp: cache source rates at init

We need the source rates array so often that it makes sense to set it once at init. This reduces function calls when we need the rates, making the code easier to follow. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 35

[Intel-gfx] [PATCH 07/11] drm/i915/dp: cache common rates with sink rates

Now that source rates are static and sink rates are updated whenever DPCD is updated, we can do and cache the intersection of them whenever sink rates are updated. This reduces code complexity, as we don't have to keep calling the functions to intersect. We also get rid of several common rates

[Intel-gfx] [PATCH 03/11] drm/i915/dp: rename rate_to_index() to intel_dp_find_rate() and reuse

Rename the function, move it at the top, and reuse in intel_dp_link_rate_index(). If there was a reason in the past to use reverse search order here, there isn't now. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 33 ++--- 1

[Intel-gfx] [PATCH 06/11] drm/i915/dp: use the sink rates array for max sink rates

Looking at DPCD DP_MAX_LINK_RATE may be completely bogus for eDP 1.4 which is allowed to use link rate select method and have 0 in max link rate. With this change, it makes sense to store the max rate as the actual rate rather than as a bw code. Signed-off-by: Jani Nikula

[Intel-gfx] [PATCH 08/11] drm/i915/dp: fallback link rate seek doesn't need to use rate limit

We're trying to find a rate that we know is in a sorted array. We don't need to limit the array using the max rate. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 21 ++--- 1 file changed, 6 insertions(+), 15 deletions(-) diff --git

[Intel-gfx] [PATCH 02/11] drm/i915/dp: return errors from rate_to_index()

We shouldn't silently use the first element if we can't find the rate we're looking for. Make rate_to_index() more generally useful, and fallback to the first element in the caller, with a big warning. Signed-off-by: Jani Nikula --- drivers/gpu/drm/i915/intel_dp.c | 13

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/dp: link rate and lane count refactoring

== Series Details == Series: drm/i915/dp: link rate and lane count refactoring URL : https://patchwork.freedesktop.org/series/18359/ State : failure == Summary == Series 18359v1 drm/i915/dp: link rate and lane count refactoring

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/4] drm/i915: Only disable execlist preemption for the duration of the request

== Series Details == Series: series starting with [1/4] drm/i915: Only disable execlist preemption for the duration of the request URL : https://patchwork.freedesktop.org/series/18340/ State : warning == Summary == Series 18340v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3] drm: Provide a driver hook for drm_dev_release()

On Sat, Jan 21, 2017 at 12:02:03PM +0100, Noralf Trønnes wrote: > > Den 21.01.2017 11:58, skrev Chris Wilson: > >Some state is coupled into the device lifetime outside of the > >load/unload timeframe and requires teardown during final unreference > >from drm_dev_release(). For example, dmabufs