[Intel-gfx] [PATCH v4 14/17] drm/i915/gen9: Propagate watermark calculation failures up the call chain

Once we move watermark calculation to the atomic check phase, we'll want to start rejecting display configurations that exceed out watermark limits. At the moment we just assume that there's always a valid set of watermarks, even though this may not actually be true. Let's prepare by passing

[Intel-gfx] [PATCH v4 17/17] drm/i915: Remove wm_config from dev_priv/intel_atomic_state

We calculate the watermark config into intel_atomic_state and then save it into dev_priv, but never actually use it from there. This is left-over from some early ILK-style watermark programming designs that got changed over time. Signed-off-by: Matt Roper Reviewed-by:

[Intel-gfx] [PATCH v4 16/17] drm/i915/gen9: Reject display updates that exceed wm limitations (v2)

If we can't find any valid level 0 watermark values for the requested atomic transaction, reject the configuration before we try to start programming the hardware. v2: - Add extra debugging output when we reject level 0 watermarks so that we can more easily debug how/why they were rejected.

[Intel-gfx] [PATCH v4 15/17] drm/i915/gen9: Calculate watermarks during atomic 'check'

Moving watermark calculation into the check phase will allow us to to reject display configurations for which there are no valid watermark values before we start trying to program the hardware (although those tests will come in a subsequent patch). Another advantage of moving this calculation to

[Intel-gfx] [PATCH v4 12/17] drm/i915/gen9: Allow watermark calculation on in-flight atomic state (v3)

In an upcoming patch we'll move this calculation to the atomic 'check' phase so that the display update can be rejected early if no valid watermark programming is possible. v2: - Drop intel_pstate_for_cstate_plane() helper and add note about how the code needs to evolve in the future if we

[Intel-gfx] [PATCH v4 11/17] drm/i915/gen9: Calculate plane WM's from state

In a future patch we'll want to calculate plane watermarks for in-flight atomic state rather than the already-committed state. Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c | 16

[Intel-gfx] [PATCH v4 09/17] drm/i915/gen9: Compute DDB allocation at atomic check time (v4)

Calculate the DDB blocks needed to satisfy the current atomic transaction at atomic check time. This is a prerequisite to calculating SKL watermarks during the 'check' phase and rejecting any configurations that we can't find valid watermarks for. Due to the nature of DDB allocation, it's

[Intel-gfx] [PATCH v4 13/17] drm/i915/gen9: Use a bitmask to track dirty pipe watermarks

Slightly easier to work with than an array of bools. Signed-off-by: Matt Roper Reviewed-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 2 +- drivers/gpu/drm/i915/intel_pm.c | 10 +- 2 files changed, 6

[Intel-gfx] [PATCH v4 08/17] drm/i915: Add distrust_bios_wm flag to dev_priv

SKL-style platforms can't fully trust the watermark/DDB settings programmed by the BIOS and need to do extra sanitization on their first atomic update. Add a flag to dev_priv that is set during hardware readout and cleared at the end of the first commit. Note that for the somewhat common case

[Intel-gfx] [PATCH v4 10/17] drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)

Now that we're properly pre-allocating the DDB during the atomic check phase and we trust that the allocation is appropriate, let's actually use the allocation computed and not duplicate that work during the commit phase. v2: - Significant rebasing now that we can use cached data rates and

[Intel-gfx] [PATCH v4 07/17] drm/i915/gen9: Allow skl_allocate_pipe_ddb() to operate on in-flight state (v3)

We eventually want to calculate watermark values at atomic 'check' time instead of atomic 'commit' time so that any requested configurations that result in impossible watermark requirements are properly rejected. The first step along this path is to allocate the DDB at atomic 'check' time. As we

[Intel-gfx] [PATCH v4 04/17] drm/i915/gen9: Allow calculation of data rate for in-flight state (v2)

Our skl_get_total_relative_data_rate() function gets passed a crtc state object to calculate the data rate for, but it currently always looks up the committed plane states that correspond to that CRTC. Let's check whether the CRTC state is an in-flight state (meaning cstate->state is non-NULL)

[Intel-gfx] [PATCH v4 02/17] drm/i915: Rename s/skl_compute_pipe_wm/skl_build_pipe_wm/

When we added atomic watermarks, we added a new display vfunc 'compute_pipe_wm' that is used to compute any pipe-specific watermark information that we can at atomic check time. This was a somewhat poor naming choice since we already had a 'skl_compute_pipe_wm' function that doesn't quite fit

[Intel-gfx] [PATCH v4 05/17] drm/i915/gen9: Store plane minimum blocks in CRTC wm state (v2)

This will eventually allow us to re-use old values without re-calculating them for unchanged planes (which also helps us avoid re-grabbing extra plane states). v2: - Drop unnecessary memset's; they were meant for a later patch (which got reworked anyway to not need them, but were

[Intel-gfx] [PATCH v4 06/17] drm/i915: Track whether an atomic transaction changes the active CRTC's

For the purposes of DDB re-allocation we need to know whether a transaction changes the list of CRTC's that are active. While state->modeset could be used for this purpose, that would be slightly too aggressive since it would lead us to re-allocate the DDB when a CRTC's mode changes, but not its

[Intel-gfx] [PATCH v4 01/17] drm/i915: Reorganize WM structs/unions in CRTC state

Reorganize the nested structures and unions we have for pipe watermark data in intel_crtc_state so that platform-specific data can be added in a more sensible manner (and save a bit of memory at the same time). The change basically changes the organization from: union {

[Intel-gfx] [PATCH v4 03/17] drm/i915/gen9: Cache plane data rates in CRTC state

This will be important when we start calculating CRTC data rates for in-flight CRTC states since it will allow us to calculate the total data rate without needing to grab the plane state for any planes that aren't updated by the transaction. Signed-off-by: Matt Roper

[Intel-gfx] [PATCH v4 00/17] Pre-calculate SKL-style atomicwatermarks

For a detailed explanation of this series, please see the original cover letter: https://lists.freedesktop.org/archives/intel-gfx/2016-April/091293.html This version is pretty much the same as v3 except that it should also fix the problems that appear if the BIOS programs bogus/unexpected DDB

Re: [Intel-gfx] [PATCH v3 09/16] drm/i915/gen9: Drop re-allocation of DDB at atomic commit (v2)

On Fri, May 06, 2016 at 02:42:46PM -0400, Lyude Paul wrote: > On Fri, 2016-05-06 at 14:12 -0400, Lyude Paul wrote: > > On Thu, 2016-04-21 at 16:17 -0700, Matt Roper wrote: > > > > > > Now that we're properly pre-allocating the DDB during the atomic check > > > phase and we trust that the

[Intel-gfx] Request for documentation of 2011 Intel HD 2000 Graphics

Hi, I'm looking for missing documentation of the offsets to the PCH registers on Intel 2011 processors. https://01.org/sites/default/files/documentation/snb_ihd_os_vol3_part3.pdf says to consult a spreadsheet, which I can't find on that site: -- 1.1.4 Register Instances and Address Offsets

Re: [Intel-gfx] [Mesa-dev] [PATCH v2 mesa] vk/intel: use negative VK_NO_PROTOTYPES scheme

On Mon, May 9, 2016 at 3:13 PM, Chad Versace wrote: > On Mon 09 May 2016, Eric Engestrom wrote: > > On Sun, May 01, 2016 at 09:39:58PM -0700, Jason Ekstrand wrote: > > > On May 1, 2016 6:04 PM, "Kenneth Graunke" > wrote: > > > > On Sunday, May 1,

Re: [Intel-gfx] [Mesa-dev] [PATCH v2 mesa] vk/intel: use negative VK_NO_PROTOTYPES scheme

On Mon 09 May 2016, Eric Engestrom wrote: > On Sun, May 01, 2016 at 09:39:58PM -0700, Jason Ekstrand wrote: > > On May 1, 2016 6:04 PM, "Kenneth Graunke" wrote: > > > On Sunday, May 1, 2016 9:51:00 AM PDT Emil Velikov wrote: > > > > Adding the anv authors. > > > > > > > >

Re: [Intel-gfx] [PATCH i-g-t v4 4/5] kms_vblank: Switch from using crtc0 statically to explicitly setting mode.

On 2016-05-09 11:38 AM, Marius Vlad wrote: > On Tue, Apr 26, 2016 at 11:54:21AM -0400, robert.f...@collabora.com wrote: >> From: Robert Foss >> >> Previously crtc0 was statically used for VBLANK tests, but >> that assumption is not valid for the VC4 platform. >>

Re: [Intel-gfx] [PATCH] drm: use seqlocks for vblank time/count

On Mon, May 09, 2016 at 08:16:07PM +0300, Ville Syrjälä wrote: > On Mon, May 09, 2016 at 05:08:43PM +0100, Matthew Auld wrote: > > This patch aims to replace the roll-your-own seqlock implementation with > > full-blown seqlock'. We also remove the timestamp ring-buffer in favour > > of single

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm: Remove unused drm_device from drm_gem_object_lookup()

== Series Details == Series: drm: Remove unused drm_device from drm_gem_object_lookup() URL : https://patchwork.freedesktop.org/series/6897/ State : warning == Summary == Series 6897v1 drm: Remove unused drm_device from drm_gem_object_lookup()

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] Introduce & use new SG page iterators

== Series Details == Series: series starting with [1/3] Introduce & use new SG page iterators URL : https://patchwork.freedesktop.org/series/6894/ State : success == Summary == Series 6894v1 Series without cover letter http://patchwork.freedesktop.org/api/1.0/series/6894/revisions/1/mbox/

Re: [Intel-gfx] [PATCH] drm: use seqlocks for vblank time/count

On Mon, May 09, 2016 at 05:08:43PM +0100, Matthew Auld wrote: > This patch aims to replace the roll-your-own seqlock implementation with > full-blown seqlock'. We also remove the timestamp ring-buffer in favour > of single timestamp/count pair protected by a seqlock. In turn this > means we can

[Intel-gfx] [PATCH v2] x86: Silence 32bit compiler warning in intel_graphics_stolen()

arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’: arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects argument of type ‘long long unsigned int’, but argument 2 has type ‘phys_addr_t’ [-Wformat=] "0x%llx-0x%llx\n", base, base + size - 1); ^

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Add a FIXME about crtc !active vs. watermarks

On Wed, May 04, 2016 at 02:30:28PM +0200, Maarten Lankhorst wrote: > Op 29-04-16 om 16:31 schreef ville.syrj...@linux.intel.com: > > From: Ville Syrjälä > > > > When the crtc is enabled but !active, we should still compute the > > watermarks as if the planes were

[Intel-gfx] [PATCH] drm: use seqlocks for vblank time/count

This patch aims to replace the roll-your-own seqlock implementation with full-blown seqlock'. We also remove the timestamp ring-buffer in favour of single timestamp/count pair protected by a seqlock. In turn this means we can now increment the vblank freely without the need for clamping. Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Use drm_i915_private as the native pointer for intel_uncore.c

On Mon, May 09, 2016 at 06:59:58PM +0300, Joonas Lahtinen wrote: > On ma, 2016-05-09 at 14:58 +0100, Chris Wilson wrote: > > Pass drm_i915_private to the uncore init/fini routines and their > > subservients as it is their native type. > > > >    textdata bss dec hex filename > >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/3] drm: Restore double clflush on the last partial cacheline

== Series Details == Series: series starting with [CI,1/3] drm: Restore double clflush on the last partial cacheline URL : https://patchwork.freedesktop.org/series/6892/ State : failure == Summary == CC drivers/usb/host/uhci-hcd.o CC drivers/usb/storage/option_ms.o CC

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

> > >-Original Message- >From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On >Behalf Of Marius Vlad >Sent: Monday, May 9, 2016 4:55 PM >To: Lespiau, Damien >Cc: daniel.vet...@ffwll.ch; intel-gfx@lists.freedesktop.org >Subject: Re: [Intel-gfx]

Re: [Intel-gfx] [PATCH] drm/i915: Use drm_i915_private as the native pointer for intel_uncore.c

On ma, 2016-05-09 at 14:58 +0100, Chris Wilson wrote: > Pass drm_i915_private to the uncore init/fini routines and their > subservients as it is their native type. > >    textdata bss dec hex filename > 6309978 3578778  696320 10585076 a183f4 vmlinux > 6309530 3578778  

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

On Mon, May 09, 2016 at 06:55:12PM +0300, Marius Vlad wrote: > > Adding a test (with patchwork integration!) that ensures each commit > > posted on this mailing-list compiles without new warning with a chosen > > toolchain (and even passes distcheck!) would be nice. > We have this for check and

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

On Mon, May 09, 2016 at 04:25:40PM +0100, Damien Lespiau wrote: > On Mon, May 09, 2016 at 04:23:44PM +0300, Marius Vlad wrote: > > Easier to catch compilation errors. > > > Having -Werror by default is a no go as you cannot control/predict the > set of warnings (and the quality of those) of all

Re: [Intel-gfx] [Mesa-dev] [PATCH v2 mesa] vk/intel: use negative VK_NO_PROTOTYPES scheme

On Sun, May 01, 2016 at 09:39:58PM -0700, Jason Ekstrand wrote: > On May 1, 2016 6:04 PM, "Kenneth Graunke" wrote: > > On Sunday, May 1, 2016 9:51:00 AM PDT Emil Velikov wrote: > > > Adding the anv authors. > > > > > > Jason, Chad, is there a canonical place where changes

Re: [Intel-gfx] [PATCH i-g-t v4 4/5] kms_vblank: Switch from using crtc0 statically to explicitly setting mode.

On Tue, Apr 26, 2016 at 11:54:21AM -0400, robert.f...@collabora.com wrote: > From: Robert Foss > > Previously crtc0 was statically used for VBLANK tests, but > that assumption is not valid for the VC4 platform. > Instead we're now explicitly setting the mode. > > Also

Re: [Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change

no problem, I'll let you know when they're ready On Mon, 2016-05-09 at 16:53 +0200, Daniel Vetter wrote: > On Mon, May 09, 2016 at 10:07:08AM -0400, Lyude Paul wrote: > > > > Yep, Dave's patches fix the issue on their own so this is only going to be > > needed for 4.6. > Ok, so not the first one

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

On Mon, May 09, 2016 at 04:23:44PM +0300, Marius Vlad wrote: > Easier to catch compilation errors. Having -Werror by default is a no go as you cannot control/predict the set of warnings (and the quality of those) of all previous and future gcc/clang versions. Always using this flag will cause

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On Mon, May 09, 2016 at 05:40:39PM +0300, Jani Nikula wrote: > On Mon, 09 May 2016, Dave Gordon wrote: > > On 09/05/16 13:32, Jani Nikula wrote: > >> On Fri, 06 May 2016, Dave Gordon wrote: > >>> On 06/05/16 15:33, Chris Wilson wrote: > On

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Simplify control flow in intel_atomic_check a bit.

== Series Details == Series: drm/i915: Simplify control flow in intel_atomic_check a bit. URL : https://patchwork.freedesktop.org/series/6890/ State : warning == Summary == Series 6890v1 drm/i915: Simplify control flow in intel_atomic_check a bit.

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Discard previous atomic state on resume if connectors change (rev2)

== Series Details == Series: drm/i915: Discard previous atomic state on resume if connectors change (rev2) URL : https://patchwork.freedesktop.org/series/6673/ State : failure == Summary == Series 6673v2 drm/i915: Discard previous atomic state on resume if connectors change

Re: [Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change

On Mon, May 09, 2016 at 10:07:08AM -0400, Lyude Paul wrote: > Yep, Dave's patches fix the issue on their own so this is only going to be > needed for 4.6. Ok, so not the first one that only needs to be applied to stable kernels. For that to work you need to explain that this is the most minimal

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On Mon, 09 May 2016, Dave Gordon wrote: > On 09/05/16 13:32, Jani Nikula wrote: >> On Fri, 06 May 2016, Dave Gordon wrote: >>> On 06/05/16 15:33, Chris Wilson wrote: On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: >

[Intel-gfx] [PATCH] drm/i915: add missing condition for committing planes on crtc

We are currently missing the color management update condition to commit planes on crtc. v2: add comment about moving the commit of color management registers to an async worker v3: Commit color management register right after vblank v4: Move back color management commit condition together

Re: [Intel-gfx] [PATCH 1/3] drm: Drop crtc argument from __drm_atomic_helper_crtc_destroy_state

On Mon, May 09, 2016 at 02:47:58PM +0300, Laurent Pinchart wrote: > Hi Daniel, > > Thank you for the patch. > > On Friday 06 May 2016 10:32:28 Daniel Vetter wrote: > > It's unused, and really this helper should only look at the state > > structure and nothing else. > > > > v2: Rebase on top of

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v3,1/6] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED

== Series Details == Series: series starting with [v3,1/6] drm/i915/guc: distinguish HAS_GUC() from HAS_GUC_UCODE/HAS_GUC_SCHED URL : https://patchwork.freedesktop.org/series/6846/ State : warning == Summary == Series 6846v1 Series without cover letter

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On 09/05/16 13:32, Jani Nikula wrote: On Fri, 06 May 2016, Dave Gordon wrote: On 06/05/16 15:33, Chris Wilson wrote: On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin To be used for more efficient Gen

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

On 06/05/16 14:43, Tvrtko Ursulin wrote: From: Tvrtko Ursulin This way optimization from a previous patch works even better. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--

Re: [Intel-gfx] [PATCH v2] drm/i915: Discard previous atomic state on resume if connectors change

Yep, Dave's patches fix the issue on their own so this is only going to be needed for 4.6. On Mon, 2016-05-09 at 08:42 +0200, Daniel Vetter wrote: > On Fri, May 06, 2016 at 05:39:56PM -0400, Lyude wrote: > > > > If an MST device is disconnected while the machine is suspended, the > > number of

[Intel-gfx] [PATCH] drm/i915: Use drm_i915_private as the native pointer for intel_uncore.c

Pass drm_i915_private to the uncore init/fini routines and their subservients as it is their native type. textdata bss dec hex filename 6309978 3578778 696320 10585076 a183f4 vmlinux 6309530 3578778 696320 10584628 a18234 vmlinux a modest 400 bytes of saving,

Re: [Intel-gfx] [PATCH i-g-t] tests/{gem_ctx_switch, gem_exec_create}: Fix shadow declaration of child variable.

On Mon, May 09, 2016 at 04:23:11PM +0300, Marius Vlad wrote: > Signed-off-by: Marius Vlad Reviewed-by: Chris Wilson -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

== Series Details == Series: drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms URL : https://patchwork.freedesktop.org/series/6845/ State : success == Summary == Series 6845v1 drm/i915: Re-enable GGTT earlier during resume on pre-gen6 platforms

[Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

Easier to catch compilation errors. Signed-off-by: Marius Vlad --- benchmarks/Makefile.am | 2 +- demos/Makefile.am | 3 ++- overlay/Makefile.am| 3 ++- tests/Makefile.am | 2 +- tools/Makefile.am | 4 +++- 5 files changed, 9 insertions(+), 5

[Intel-gfx] [PATCH i-g-t] tests/{gem_ctx_switch, gem_exec_create}: Fix shadow declaration of child variable.

Signed-off-by: Marius Vlad --- tests/gem_ctx_switch.c | 1 - tests/gem_exec_create.c | 1 - 2 files changed, 2 deletions(-) diff --git a/tests/gem_ctx_switch.c b/tests/gem_ctx_switch.c index 691a4f1..004ba22 100644 --- a/tests/gem_ctx_switch.c +++

Re: [Intel-gfx] [PATCH] x86: Silence 32bit compiler warning in intel_graphics_stolen()

On Mon, May 09, 2016 at 04:04:31PM +0300, Joonas Lahtinen wrote: > On pe, 2016-05-06 at 13:57 +0300, Ville Syrjälä wrote: > > On Thu, May 05, 2016 at 05:15:17PM +0100, Chris Wilson wrote: > > > > > > arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’: > > >

Re: [Intel-gfx] [PATCH] x86: Silence 32bit compiler warning in intel_graphics_stolen()

On pe, 2016-05-06 at 13:57 +0300, Ville Syrjälä wrote: > On Thu, May 05, 2016 at 05:15:17PM +0100, Chris Wilson wrote: > > > > arch/x86/kernel/early-quirks.c: In function ‘intel_graphics_stolen’: > > arch/x86/kernel/early-quirks.c:539:9: warning: format ‘%llx’ expects > > argument of type ‘long

[Intel-gfx] [PATCH 5/5] drm/i915: Do not use a bitfield for INTEL_INFO->num_pipes

From: Tvrtko Ursulin It just makes more work for the compiler and generates more code. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_drv.h | 2 +- 1 file changed, 1

[Intel-gfx] [PATCH 2/5] drm/i915: Promote IS_BROADWELL to a simple macro

From: Tvrtko Ursulin If we allow it a dedicated flag in dev_priv we enable the compiler to nicely optimize conditions like IS_HASSWELL || IS_BROADWELL. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson ---

[Intel-gfx] [PATCH 4/5] drm/i915: Introduce INTEL_GEN_RANGE macro

From: Tvrtko Ursulin To be used for more efficient Gen range checking. v2: Remove spurious chunk. (Chris Wilson) v3: Rebase. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson ---

[Intel-gfx] [PATCH 3/5] drm/i915: Replace "INTEL_INFO->gen == x" checks with IS_GENx

From: Tvrtko Ursulin This way optimization from a previous patch works even better. v2: Rebase. Signed-off-by: Tvrtko Ursulin Reviewed-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c | 4 ++--

[Intel-gfx] [PATCH 1/5] drm/i915: Make IS_GENx macros work on a mask

From: Tvrtko Ursulin If instead of numerical comparison me make these test a bitmask, we enable the compiler to optimize all instances of IS_GENx || IS_GENy. v2: Make bit zero of gen mask mean gen 1. Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] What's using all my DRI memory?

On Mon, May 09, 2016 at 10:06:49PM +1000, Adam Nielsen wrote: > Hi all, > > I'm trying to track down an annoying bug which is making my system > crash every two weeks, and in between those two weeks I get various > programs, typically Firefox, killed every day or two due to out of > memory

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Fix modeset handling during gpu reset, v3.

On Mon, May 09, 2016 at 01:04:21PM +0200, Maarten Lankhorst wrote: > This function would call drm_modeset_lock_all, while the suspend/resume > functions already have their own locking. Fix this by factoring out > __intel_display_resume, and calling the atomic helpers for duplicating > atomic state

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [for-CI,1/3] drm: Restore double clflush on the last partial cacheline

On Mon, May 09, 2016 at 12:23:31PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [for-CI,1/3] drm: Restore double clflush on the > last partial cacheline > URL : https://patchwork.freedesktop.org/series/6839/ > State : warning > > == Summary == > > Series

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Small display interrupt handlers tidy (rev2)

On 09/05/16 11:53, Patchwork wrote: == Series Details == Series: drm/i915: Small display interrupt handlers tidy (rev2) URL : https://patchwork.freedesktop.org/series/6819/ State : failure == Summary == Series 6819v2 drm/i915: Small display interrupt handlers tidy

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Introduce INTEL_GEN_RANGE macro

On Fri, 06 May 2016, Dave Gordon wrote: > On 06/05/16 15:33, Chris Wilson wrote: >> On Fri, May 06, 2016 at 03:16:25PM +0100, Tvrtko Ursulin wrote: >>> From: Tvrtko Ursulin >>> >>> To be used for more efficient Gen range checking. >>> >>>

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [for-CI,1/3] drm: Restore double clflush on the last partial cacheline

== Series Details == Series: series starting with [for-CI,1/3] drm: Restore double clflush on the last partial cacheline URL : https://patchwork.freedesktop.org/series/6839/ State : warning == Summary == Series 6839v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 0/4] drm: DP++ adaptor support (v2)

On Mon, May 02, 2016 at 10:08:21PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Here's a respin of my DP++ adaptor support series [1]. Pardon for taking > forever with this. Presumably we want to get this into stable to fix the > regression

[Intel-gfx] What's using all my DRI memory?

Hi all, I'm trying to track down an annoying bug which is making my system crash every two weeks, and in between those two weeks I get various programs, typically Firefox, killed every day or two due to out of memory errors. Apparently all this memory is used by the Intel video driver, which

[Intel-gfx] [PATCH 2/2] Reapply "drm/atomic: Call ww_acquire_done after check phase is complete"

This reapplies commit 992cbf19b32900efa17850b9fa0031fd623edd4d. With atomic drm_framebuffer_remove and the fbdev emulation layer atomic this should be safe to apply again. Signed-off-by: Maarten Lankhorst Cc: Rob Clark Cc: Daniel Vetter

[Intel-gfx] [PATCH 2/2] Reapply "drm/atomic: Call ww_acquire_done after check phase is complete"

This reapplies commit 992cbf19b32900efa17850b9fa0031fd623edd4d. With atomic drm_framebuffer_remove and the fbdev emulation layer atomic this should be safe to apply again. Signed-off-by: Maarten Lankhorst Cc: Rob Clark Cc: Daniel Vetter

[Intel-gfx] [PATCH 1/2] drm/atomic: Add a way to call remove_fb atomically, v2.

Use this in drm_framebuffer_remove, this is to remove the fb in an atomic way. i915 doesn't export DRIVER_ATOMIC yet by default but is atomic, so add a function pointer to allow drivers to use the atomic framebuffer remove. Changes since v1: - Move the atomic framebuffer removal function from

[Intel-gfx] [PATCH 1/2] drm/atomic: Add a way to call remove_fb atomically, v2.

Use this in drm_framebuffer_remove, this is to remove the fb in an atomic way. i915 doesn't export DRIVER_ATOMIC yet by default but is atomic, so add a function pointer to allow drivers to use the atomic framebuffer remove. Changes since v1: - Move the atomic framebuffer removal function from

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Pin pages as we flush for CPU access

== Series Details == Series: series starting with [1/2] drm/i915: Pin pages as we flush for CPU access URL : https://patchwork.freedesktop.org/series/6838/ State : success == Summary == Series 6838v1 Series without cover letter

Re: [Intel-gfx] [PATCH 3/3] drm: Drop crtc argument from __drm_atomic_helper_connector_destroy_state

Hi Daniel, Thank you for the patch. s/crtc/connector/ in the subject (I've just realized that the same comment applies to patch 2/3, with s/connector/plane/ as well). Apart from that, Acked-by: Laurent Pinchart On Friday 06 May 2016 10:32:30 Daniel Vetter

Re: [Intel-gfx] [PATCH 2/3] drm: Drop crtc argument from __drm_atomic_helper_connector_destroy_state

Hi Daniel, Thank you for the patch. On Friday 06 May 2016 10:32:29 Daniel Vetter wrote: > It's unused, and really this helper should only look at the state > structure and nothing else. > > Cc: Maarten Lankhorst > Cc: Thierry Reding

Re: [Intel-gfx] [PATCH 1/3] drm: Drop crtc argument from __drm_atomic_helper_crtc_destroy_state

Hi Daniel, Thank you for the patch. On Friday 06 May 2016 10:32:28 Daniel Vetter wrote: > It's unused, and really this helper should only look at the state > structure and nothing else. > > v2: Rebase on top of rockchip changes > > Cc: Maarten Lankhorst >

Re: [Intel-gfx] [PATCH v4] prime_mmap_kms: show case dma-buf new API and processes restrictions

Pushed. Thanks! On Fri, May 06, 2016 at 04:51:29PM -0300, Tiago Vignatti wrote: > dma-buf new API consists of: > > - mmap(dma_buf_fd, ...): the ability to map a dma-buf file-descriptor of a > graphics buffer to the userspace, and more importantly, to actually write on > the mapped pointer (which

Re: [Intel-gfx] i915 with valleyview

On Mon, May 09, 2016 at 11:19:16AM +0300, Jani Nikula wrote: > On Fri, 06 May 2016, Sudip Mukherjee wrote: > > On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote: > >> Hi Daniel, > >> I am trying to use i915 in one of our board which has Intel ATOM E3840.

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Small display interrupt handlers tidy (rev2)

== Series Details == Series: drm/i915: Small display interrupt handlers tidy (rev2) URL : https://patchwork.freedesktop.org/series/6819/ State : failure == Summary == Series 6819v2 drm/i915: Small display interrupt handlers tidy

Re: [Intel-gfx] [PATCHv4 3/3] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

Hi Ander, Thanks for looking at it. Few queries below.. > -Original Message- > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > Sent: Friday, May 6, 2016 6:39 PM > To: R, Durgadoss ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx]

Re: [Intel-gfx] [PATCH v2] drm/i915/execlists: Refactor common engine setup

On Mon, May 09, 2016 at 09:58:20AM +0200, Daniel Vetter wrote: > On Mon, May 09, 2016 at 08:45:16AM +0100, Chris Wilson wrote: > > This is sanitize. We do enable it in engine->init_hw(), but the point > > raised by Ville earlier in his review of GT irq handling is that nobody > > currently

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix modeset handling during gpu reset, v2.

Op 06-05-16 om 15:06 schreef Ville Syrjälä: > On Mon, May 02, 2016 at 10:57:01AM +0200, Maarten Lankhorst wrote: >> This function would call drm_modeset_lock_all, while the suspend/resume >> functions already have their own locking. Fix this by factoring out >> __intel_display_resume, and calling

Re: [Intel-gfx] [PATCH 10/12] drm/i915: Compute display surface offset in the plane check hook for SKL+

Reviewed-by: Sivakumar Thulasimani On Tuesday 03 May 2016 09:09 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä SKL has nasty limitations with the display surface offsets: * source x offset + width must be less than

[Intel-gfx] [PATCH] drm: Remove unused drm_device from drm_gem_object_lookup()

drm_gem_object_lookup() has never required the drm_device for its file local translation of the user handle to the GEM object. Let's remove the unused parameter and save some space. Signed-off-by: Chris Wilson Cc: dri-de...@lists.freedesktop.org Cc: Dave Airlie

Re: [Intel-gfx] [PATCH 1/3] Introduce & use new SG page iterators

On Mon, May 09, 2016 at 10:33:31AM +0100, Dave Gordon wrote: > The existing for_each_sg_page() iterator is somewhat inconvenient; in > particular, the 'nents' parameters is not expressed in any useful way, > and so there is no way to get a precise (maximum) number of iterations > (and therefore

[Intel-gfx] ✗ Fi.CI.BAT: warning for GPU scheduler for i915 driver (rev4)

== Series Details == Series: GPU scheduler for i915 driver (rev4) URL : https://patchwork.freedesktop.org/series/3585/ State : warning == Summary == Series 3585v4 GPU scheduler for i915 driver http://patchwork.freedesktop.org/api/1.0/series/3585/revisions/4/mbox/ Test kms_pipe_crc_basic:

Re: [Intel-gfx] [PATCHv4 1/3] drm/i915: Make finding unused crtc as a generic function

> -Original Message- > From: Ander Conselvan De Oliveira [mailto:conselv...@gmail.com] > Sent: Friday, May 6, 2016 6:38 PM > To: R, Durgadoss ; intel-gfx@lists.freedesktop.org > Subject: Re: [Intel-gfx] [PATCHv4 1/3] drm/i915: Make finding unused crtc as > a

Re: [Intel-gfx] [PATCH] Revert "i965: Always use Y-tiled buffers on SKL+"

Hi, On 9 May 2016 at 08:05, Daniel Vetter wrote: > On Mon, May 02, 2016 at 11:38:15AM -0700, Kenneth Graunke wrote: >> On Monday, May 2, 2016 3:40:14 PM PDT Daniel Stone wrote: >> > This commit broke Weston/KMS, and presumably also xf86-video-modesetting. >> >> For me,

[Intel-gfx] [PATCH 2/3] drm/i915: refactor i915_gem_object_pin_map()

The recently-added i915_gem_object_pin_map() can be further optimised for "small" objects. To facilitate this, and simplify the error paths before adding the new code, this patch pulls out the "mapping" part of the operation (involving local allocations which must be undone before return) into its

[Intel-gfx] [PATCH 3/3] drm/i915: optimise i915_gem_object_map() for small objects

We're using this function for ringbuffers and other "small" objects, so it's worth avoiding an extra malloc()/free() cycle if the page array is small enough to put on the stack. Here we've chosen an arbitrary cutoff of 32 (4k) pages, which is big enough for a ringbuffer (4 pages) or a context

[Intel-gfx] [PATCH 1/3] Introduce & use new SG page iterators

The existing for_each_sg_page() iterator is somewhat inconvenient; in particular, the 'nents' parameters is not expressed in any useful way, and so there is no way to get a precise (maximum) number of iterations (and therefore pages) without knowing that the SGL has been constructed in a specific

Re: [Intel-gfx] [PATCH 09/12] drm/i915: Make intel_adjust_tile_offset() work for linear buffers

Reviewed-by: Sivakumar Thulasimani On Tuesday 03 May 2016 09:09 PM, ville.syrj...@linux.intel.com wrote: From: Ville Syrjälä To make life less surprising we can make intel_adjust_tile_offset() deal with linear buffers as well.

Re: [Intel-gfx] [PATCH] drm/i915: Small display interrupt handlers tidy

On Mon, May 09, 2016 at 10:05:06AM +0200, Daniel Vetter wrote: > Not sure about intel_display because that's an ever-growing dumping ground > and with atomic still in-flight I definitely don't want to upset this. > There's been various plans to split it up a bit (and document while at > it). Maybe

Re: [Intel-gfx] i915 with valleyview

On Fri, 06 May 2016, Sudip Mukherjee wrote: > On Fri, May 06, 2016 at 12:21:04PM +0100, Sudip Mukherjee wrote: >> Hi Daniel, >> I am trying to use i915 in one of our board which has Intel ATOM E3840. >> I know Intel has released emgd driver for this cpu to use i915 but

[Intel-gfx] [CI 1/3] drm: Restore double clflush on the last partial cacheline

This effectively reverts commit afcd950cafea6e27b739fe7772cbbeed37d05b8b Author: Chris Wilson Date: Wed Jun 10 15:58:01 2015 +0100 drm: Avoid the double clflush on the last cache line in drm_clflush_virt_range() as we have observed issues with serialisation of

[Intel-gfx] [CI 2/3] drm/i915/execlists: Refactor common engine setup

Move all of the constant assignments up front and into a common function. This is primarily to ensure the backpointers are set as early as possible for later use during initialisation. v2: Use a constant struct so that all the similar values are set together. v3: Sanitize the engine's IMR to

Re: [Intel-gfx] PATCH i-g-t small patch

On Fri, May 06, 2016 at 11:12:50AM +0100, David CARLIER wrote: >Hi all, > >this is a small patch to fix couple of mem leaks, possible double free >case. Please don't bother freeing before process exit. In tests, I would rather those be left around, and open file description, mmaps

  1   2   >