[Intel-gfx] [PATCH] drm/i915/gvt: set ring buffer size to default for guc submission

When not using GuC submission, the ring buffer size for GVT context is 512KB which is the max size. When switching to GuC submission, the ring buffer size is required to be less than 16KB. So use the GVT context default ring buffer size if GuC submission is enabled. Signed-off-by: Chuanxiao Dong

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Support HDMI EDID injection (rev3)

== Series Details == Series: drm/i915: Support HDMI EDID injection (rev3) URL : https://patchwork.freedesktop.org/series/3007/ State : failure == Summary == Series 3007v3 drm/i915: Support HDMI EDID injection https://patchwork.freedesktop.org/api/1.0/series/3007/revisions/3/mbox/ Test

[Intel-gfx] [PATCH] drm/i915: Support HDMI EDID injection

From: marius vlad Make a copy of drm_property_blob data for user-supplied EDID blobs. Signed-off-by: Abdiel Janulgue Signed-off-by: Marius Vlad --- drivers/gpu/drm/i915/intel_hdmi.c | 10 ++ 1 file

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

On Wed, Feb 15, 2017 at 06:28:59PM -0800, Daniele Ceraolo Spurio wrote: > On 14/02/17 05:53, Joonas Lahtinen wrote: > >-static void guc_disable_doorbell(struct intel_guc *guc, > >- struct i915_guc_client *client) > >+static int __destroy_doorbell(struct i915_guc_client

[Intel-gfx] [PATCH] drm/i915/glk: CDCLK calculation changes for glk

As per BSPEC, valid cdclk values for glk are 79.2, 158.4, 316.8 Mhz. Practically we can achive only 99% of these cdclk values(HW team checking on this). So cdclk should be calculated for the given pixclk as per that otherwise it may lead to screen corruption for some scenarios. v2: Rebased to new

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/glk: CDCLK calculation changes for glk (rev2)

== Series Details == Series: drm/i915/glk: CDCLK calculation changes for glk (rev2) URL : https://patchwork.freedesktop.org/series/19226/ State : failure == Summary == Series 19226v2 drm/i915/glk: CDCLK calculation changes for glk

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Consolidate gen8_emit_pipe_control

On 15/02/2017 16:33, Chris Wilson wrote: On Wed, Feb 15, 2017 at 04:06:34PM +, Tvrtko Ursulin wrote: +static inline u32 *gen8_emit_pipe_control(u32 *batch, u32 flags, u32 offset) +{ + static const u32 pc6[6] = { GFX_OP_PIPE_CONTROL(6), 0, 0, 0, 0, 0 }; + + memcpy(batch, pc6,

Re: [Intel-gfx] [PATCH] drm/i915/gvt: set ring buffer size to default for guc submission

On Thu, Feb 16, 2017 at 02:36:40PM +0800, Chuanxiao Dong wrote: > When not using GuC submission, the ring buffer size for GVT context is > 512KB which is the max size. When switching to GuC submission, the ring > buffer size is required to be less than 16KB. So use the GVT context > default ring

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Tidy workaround batch buffer emission

On 15/02/2017 21:18, Chris Wilson wrote: On Wed, Feb 15, 2017 at 04:06:33PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Use the "*batch++ = " style as in the ring emission for better readability and also simplify the logic a bit by consolidating the offset and

Re: [Intel-gfx] [PATCH v2] drm/i915: Sanitize GuC client initialization

On 14/02/17 05:53, Joonas Lahtinen wrote: Started adding proper teardown to guc_client_alloc, ended up removing quite a few dead ends where errors communicating with the GuC were silently ignored. There also seemed to be quite a few erronous teardown actions performed in case of an error

Re: [Intel-gfx] [PATCH RESEND] drm/dp/mst: fix kernel oops when turning off secondary monitor

On Wed, 15 Feb 2017, Jani Nikula wrote: > On Tue, 14 Feb 2017, Daniel Vetter wrote: >> On Tue, Feb 14, 2017 at 02:49:21PM +0200, Jani Nikula wrote: >>> From: Pierre-Louis Bossart >>> >>> 100% reproducible issue found

Re: [Intel-gfx] [GIT PULL] more GVT-g fixes for 4.11

On Wed, 15 Feb 2017, Zhenyu Wang wrote: > Hi, > > This contains recent gvt fixes that target for 4.11. Team is busy on > know issues fixing and improve usability. This includes IOMMU workaround > fix with proper dma mapping from Chuanxiao, some log message cleanup, one >

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,01/23] drm/i915: Micro-optimise i915_get_ggtt_vma_pages()

On Wed, Feb 15, 2017 at 09:52:14AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [CI,01/23] drm/i915: Micro-optimise > i915_get_ggtt_vma_pages() > URL : https://patchwork.freedesktop.org/series/19686/ > State : success > > == Summary == > > Series 19686v1

Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware

On Tue, 14 Feb 2017, Seth Forshee wrote: > Hi, > > I've noted that kbl_guc_ver9_14.bin and bxt_guc_ver8_7.bin are not in > linux-firmware despite being available here: > > https://01.org/linuxgraphics/downloads/firmware > > Is there some reason they haven't been

Re: [Intel-gfx] [PATCH] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

On Wed, Feb 15, 2017 at 01:34:46AM -0800, Kenneth Graunke wrote: > This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 > (indicating the optional feature is not supported), and makes execbuf > always return -EINVAL if the flags are used. > > Apparently, no userspace ever shipped

[Intel-gfx] [PATCH] drm/i915: Hold forcewake for whole of punit communication

Take the forcewake for punit access and hold it across our waits to ensure that the powerwell is not dropped by a spurious sleep. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/intel_sideband.c | 55

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [CI,01/23] drm/i915: Micro-optimise i915_get_ggtt_vma_pages()

== Series Details == Series: series starting with [CI,01/23] drm/i915: Micro-optimise i915_get_ggtt_vma_pages() URL : https://patchwork.freedesktop.org/series/19686/ State : success == Summary == Series 19686v1 Series without cover letter

[Intel-gfx] [PATCH 3/3] drm/i915: Drop struct_mutex around frontbuffer flushes

Since the frontbuffer has self-contained locking, it does not require us to hold the BKL struct_mutex as we send invalidate and flush messages. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_fbdev.c | 43 +++--- 1 file

[Intel-gfx] [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers

We do not need to hold struct_mutex for destroying drm_i915_gem_objects any longer, and with a little care taken over tracking obj->framebuffer_references, we can relinquish BKL locking around the destroy of intel_framebuffer. Signed-off-by: Chris Wilson ---

[Intel-gfx] [PATCH 2/4] drm/i915: Call the sync_hw hook for power wells without a domain

So far the sync_hw hook wasn't called for power wells not belonging to any power domain, that is the GEN9 PW1 and MISC_IO power wells. This wasn't a problem so far since the goal of the sync_hw hook - to clear the corresponding BIOS request bit - was guaranteed by clearing the whole BIOS request

[Intel-gfx] [PATCH 3/4] drm/i915/gen9: Fix clearing of the BIOS power well request register

Atm, in the power well sync_hw hook we are clearing all BIOS request bits, not just the one corresponding to the given power well. This could turn off an unrelated power well inadvertently if it didn't have a request bit set in the driver request register. This didn't cause a problem so far,

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

On Wed, Feb 15, 2017 at 11:36:08AM +, Chris Wilson wrote: > I tried lightening the barrier in commit 9b9ed3093613 ("drm/i915: Remove > forcewake dance from seqno/irq barrier on legacy gen6+") but that > appears slightly on the optimistic side as we detect a very rare missed > interrupt on a

[Intel-gfx] [PATCH 1/4] drm/i915: Remove redundant toggling from the power well sync_hw hooks

Doing an explicit enable/disable in the power well sync_hw hook based on the power well's reference count is redundant, since by the time these hooks are called all the power wells are enabled and have a reference. So remove the redundant toggling. This is needed by a follow-up patchset that adds

[Intel-gfx] [PATCH 4/4] drm/i915: Preserve the state of power wells not explicitly enabled

Atm, power wells that BIOS has enabled, but which we don't explicitly enable during power domain initialization would get disabled as we clear the BIOS request bit in the given power well sync_hw hook. To prevent this copy over any set request bits in the BIOS request register to the driver

[Intel-gfx] [PATCH 0/4] drm/i915: Fix clearing of BIOS power well requests

While reading Ander's GLK DDI power well patches [1] I noticed a few issues in the existing code related to clearing/taking over the power well request bits from BIOS. These didn't cause a problem so far, but would be exposed by his patchset, so after discussing with him I decided to fix them.

Re: [Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

On Wed, Feb 15, 2017 at 12:04:18PM +, Chris Wilson wrote: > On Wed, Feb 15, 2017 at 01:23:35PM +0200, Ville Syrjälä wrote: > > On Wed, Feb 15, 2017 at 09:06:53AM +, Chris Wilson wrote: > > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > > > b/drivers/gpu/drm/i915/intel_hotplug.c > >

Re: [Intel-gfx] [PATCH i-g-t] gitignore: Add files starting with .

On pe, 2017-02-10 at 12:37 -0800, Michel Thierry wrote: > I cant be the only one that have added .tags by mistake. > > Cc: Marius Vlad > Cc: Petri Latvala > Signed-off-by: Michel Thierry > +++ b/.gitignore > @@

Re: [Intel-gfx] [PATCH] drm/i915/guc: Keep the ctx_pool_vaddr mapped, for easy access

On to, 2017-02-09 at 02:23 -0800, Oscar Mateo wrote: > From: Michal Wajdeczko > > The GuC descriptor is big in size. If we use a local definition of > guc_desc we have a chance to overflow stack, so avoid it. > > Also, Chris abhors scatterlists :) > > Signed-off-by:

Re: [Intel-gfx] [PATCH 1/5] drm/i915/uc: Rename intel_?uc_{setup, load}() to _init_hw()

On ti, 2017-02-14 at 17:15 +0100, Arkadiusz Hiler wrote: > GuC historically has two "startup" functions called _init() and _setup() > > Then HuC came with it's _init() and _load(). > > To make naming more consistent this commit renames intel_guc_setup() and > intel_huc_load() to *uc_init_hw() as

[Intel-gfx] [PATCH 2/3] drm/i915: struct_mutex is not required for allocating the framebuffer

We do not need the BKL struct_mutex in order to allocate a GEM object, nor to create the framebuffer, so resist the temptation to take the BKL willy nilly. As this changes the locking contract around internal API calls, the patch is a little larger than a plain removal of a pair of

Re: [Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

On Wed, Feb 15, 2017 at 09:06:53AM +, Chris Wilson wrote: > In order to prevent accessing the hpd registers outside of the display > power wells, we should refrain from writing to the registers before the > display interrupts are enabled. > > [4.740136] WARNING: CPU: 1 PID: 221 at >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

On Wed, Feb 15, 2017 at 01:59:59PM +0200, Ville Syrjälä wrote: > On Wed, Feb 15, 2017 at 11:36:08AM +, Chris Wilson wrote: > > I tried lightening the barrier in commit 9b9ed3093613 ("drm/i915: Remove > > forcewake dance from seqno/irq barrier on legacy gen6+") but that > > appears slightly on

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. (rev3)

== Series Details == Series: drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters. (rev3) URL : https://patchwork.freedesktop.org/series/19676/ State : success == Summary == Series 19676v3 drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

On Wed, Feb 15, 2017 at 12:15:43PM +, Chris Wilson wrote: > On Wed, Feb 15, 2017 at 01:59:59PM +0200, Ville Syrjälä wrote: > > On Wed, Feb 15, 2017 at 11:36:08AM +, Chris Wilson wrote: > > > I tried lightening the barrier in commit 9b9ed3093613 ("drm/i915: Remove > > > forcewake dance from

[Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2

Certain Baytrails, namely the 4 cpu core variants, have been plaqued by spurious system hangs, mostly occurring with light loads. Multiple bisects by various people point to a commit which changes the reclocking strategy for Baytrail to follow its bigger brethen: commit 8fb55197e64d ("drm/i915:

Re: [Intel-gfx] [PATCH 2/2] drm/i915/scheduler: emulate a scheduler for guc

On 14/02/2017 11:44, Chris Wilson wrote: This emulates execlists on top of the GuC in order to defer submission of requests to the hardware. This deferral allows time for high priority requests to gazump their way to the head of the queue, however it nerfs the GuC by converting it back into a

Re: [Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

On Wed, Feb 15, 2017 at 01:23:35PM +0200, Ville Syrjälä wrote: > On Wed, Feb 15, 2017 at 09:06:53AM +, Chris Wilson wrote: > > diff --git a/drivers/gpu/drm/i915/intel_hotplug.c > > b/drivers/gpu/drm/i915/intel_hotplug.c > > index 6a9c16508ab5..bad4f14858e3 100644 > > ---

Re: [Intel-gfx] [PATCH v3 4/8] drm: Add driver-private objects to atomic state

Hi, On 02/09/2017 12:08 PM, Dhinakaran Pandiyan wrote: It is necessary to track states for objects other than connector, crtc and plane for atomic modesets. But adding objects like DP MST link bandwidth to drm_atomic_state would mean that a non-core object will be modified by the core helper

Re: [Intel-gfx] [PATCH] drm/i915: Hold forcewake for whole of punit communication

On Wed, Feb 15, 2017 at 10:41:29AM +, Chris Wilson wrote: > Take the forcewake for punit access and hold it across our waits to > ensure that the powerwell is not dropped by a spurious sleep. > > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

[Intel-gfx] [PATCH 1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

I tried lightening the barrier in commit 9b9ed3093613 ("drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+") but that appears slightly on the optimistic side as we detect a very rare missed interrupt on a few machines. This patch goes super heavy with a force-waked sync-flush

[Intel-gfx] [PATCH 2/2] drm/i915: Share the heavyweight sync-flush irq barrier with gen5

Currently we use an empirically derived sleep for waiting fr the seqno to be coherent following an interrupt on Ironlake. However, that is occasionally too short and we get a missed-interrupt warning from CI. We can use the sync-flush dance now employed for gen6 for a more realistic delay, and

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

== Series Details == Series: drm/i915: Only enable hotplug interrupts if the display interrupts are enabled URL : https://patchwork.freedesktop.org/series/19687/ State : success == Summary == Series 19687v1 drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

Re: [Intel-gfx] [PATCH] drm/i915: Hold forcewake for whole of punit communication

On Wed, Feb 15, 2017 at 01:33:01PM +0200, Ville Syrjälä wrote: > On Wed, Feb 15, 2017 at 10:41:29AM +, Chris Wilson wrote: > > Take the forcewake for punit access and hold it across our waits to > > ensure that the powerwell is not dropped by a spurious sleep. > > > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 2/2] drm/i915/scheduler: emulate a scheduler for guc

On Wed, Feb 15, 2017 at 11:56:28AM +, Tvrtko Ursulin wrote: > > On 14/02/2017 11:44, Chris Wilson wrote: > >diff --git a/drivers/gpu/drm/i915/i915_irq.c > >b/drivers/gpu/drm/i915/i915_irq.c > >index cdc7da60d37a..aa886b5fb2cd 100644 > >--- a/drivers/gpu/drm/i915/i915_irq.c > >+++

Re: [Intel-gfx] [PATCH 2/2] drm/i915/scheduler: emulate a scheduler for guc

On 15/02/2017 12:20, Chris Wilson wrote: On Wed, Feb 15, 2017 at 11:56:28AM +, Tvrtko Ursulin wrote: On 14/02/2017 11:44, Chris Wilson wrote: diff --git a/drivers/gpu/drm/i915/i915_irq.c b/drivers/gpu/drm/i915/i915_irq.c index cdc7da60d37a..aa886b5fb2cd 100644 ---

Re: [Intel-gfx] [PATCH 3/5] drm/i915/guc: Extract param logic form guc_init

On ti, 2017-02-14 at 20:37 +0100, Michal Wajdeczko wrote: > On Tue, Feb 14, 2017 at 05:15:39PM +0100, Arkadiusz Hiler wrote: > > > > Let intel_guc_init() focus on determining and fetching the correct > > firmware. > > > > This patch introduces intel_sanitize_uc_params() that is called from > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Hold forcewake for whole of punit communication

== Series Details == Series: drm/i915: Hold forcewake for whole of punit communication URL : https://patchwork.freedesktop.org/series/19691/ State : success == Summary == Series 19691v1 drm/i915: Hold forcewake for whole of punit communication

Re: [Intel-gfx] [PATCH RESEND] drm/dp/mst: fix kernel oops when turning off secondary monitor

On Tue, 14 Feb 2017, Daniel Vetter wrote: > On Tue, Feb 14, 2017 at 02:49:21PM +0200, Jani Nikula wrote: >> From: Pierre-Louis Bossart >> >> 100% reproducible issue found on SKL SkullCanyon NUC with two external >> DP daisy-chained monitors

Re: [Intel-gfx] [PATCH v2] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

On Tue, Feb 14, 2017 at 08:17:51PM -0800, Kenneth Graunke wrote: > This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 > (indicating the optional feature is not supported), and makes execbuf > always return -EINVAL if the flags are used. > > Apparently, no userspace ever shipped

[Intel-gfx] [CI 10/23] drm/i915: Remove redundant clear of appgtt

Upon creation of the va range, it is initialised to point at scratch. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4 1 file changed, 4 deletions(-) diff --git

[Intel-gfx] [CI 04/23] drm/i915: Don't special case teardown of aliasing_ppgtt

The aliasing_ppgtt is a regular ppgtt, and we can use the regular i915_ppgtt_put() to properly tear it down. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 50

[Intel-gfx] [CI 15/23] drm/i915: Remove bitmap tracking for used-pml4

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

Hi, On 14-02-17 17:12, Jani Nikula wrote: From: Hans de Goede If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may use the ASLE_EXT parts of the opregion. Adjust the vbt_size calculation for a vbt in mailbox #4 for this. This fixes the driver not finding

Re: [Intel-gfx] [PATCH v2] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

On Wednesday, February 15, 2017 12:12:50 AM PST Chris Wilson wrote: > On Tue, Feb 14, 2017 at 08:17:51PM -0800, Kenneth Graunke wrote: > > This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 > > (indicating the optional feature is not supported), and makes execbuf > > always

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Remove duplicate intel_logical_ring_workarounds_emit

On 14/02/2017 19:55, Saarinen, Jani wrote: HI, -Original Message- From: Intel-gfx [mailto:intel-gfx-boun...@lists.freedesktop.org] On Behalf Of Patchwork Sent: Tuesday, February 14, 2017 8:52 PM To: Tvrtko Ursulin Cc: intel-gfx@lists.freedesktop.org Subject:

[Intel-gfx] [PATCH] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

In order to prevent accessing the hpd registers outside of the display power wells, we should refrain from writing to the registers before the display interrupts are enabled. [4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]

Re: [Intel-gfx] [PATCH] drm: Add DPCD definitions for DP 1.4 DSC feature

On Wed, 15 Feb 2017, Manasi Navare wrote: > Display stream compression is supported on DP 1.4 DP > devices. This patch adds the corersponding DPCD > register definitions for DSC. Please resend Cc: dri-de...@lists.freedesktop.org. Try 'git show --pretty=email |

Re: [Intel-gfx] [PATCH v3] drm/i915: Fix not finding the VBT when it overlaps with OPREGION_ASLE_EXT

On Wed, 15 Feb 2017, Hans de Goede wrote: > Hi, > > On 14-02-17 17:12, Jani Nikula wrote: >> From: Hans de Goede >> >> If there is no OPREGION_ASLE_EXT then a VBT stored in mailbox #4 may >> use the ASLE_EXT parts of the opregion. Adjust the vbt_size

[Intel-gfx] [PATCH] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 (indicating the optional feature is not supported), and makes execbuf always return -EINVAL if the flags are used. Apparently, no userspace ever shipped which used this optional feature: I checked the git history of Mesa,

Re: [Intel-gfx] [PATCH v3 03/23] drm/i915: Micro-optimise gen8_ppgtt_insert_entries()

On Tue, Feb 14, 2017 at 06:00:55PM +0200, Mika Kuoppala wrote: > Chris Wilson writes: > > - while (__sg_page_iter_next(sg_iter)) { > > - if (pt_vaddr == NULL) { > > - struct i915_page_directory *pd = > > pdp->page_directory[pdpe]; > > -

[Intel-gfx] [CI 02/23] drm/i915: Micro-optimise gen6_ppgtt_insert_entries()

Inline the address computation to avoid the vfunc call for every page. We still have to pay the high overhead of sg_page_iter_next(), but now at least GCC can optimise the inner most loop, giving a significant boost to some thrashing Unreal Engine workloads. Signed-off-by: Chris Wilson

[Intel-gfx] [CI 07/23] drm/i915: Remove kmap/kunmap wrappers

As these are now both plain and simple kmap_atomic/kunmap_atomic pairs, we can remove the wrappers for a small gain of clarity (in particular, not hiding the atomic critical sections!). Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

[Intel-gfx] [CI 11/23] drm/i915: Tidy gen6_write_pde()

Stop passing around unused parameters makes the code more compact. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 39 + 1 file changed, 14 insertions(+), 25

[Intel-gfx] [CI 05/23] drm/i915: Split ggtt/alasing_gtt unbind_vma

Similar to how we already split the bind_vma for ggtt/aliasing_gtt, also split up the unbind for symmetry. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 29 + 1 file

[Intel-gfx] [CI 09/23] drm/i915: Always preallocate gen6/7 ppgtt

The hardware does not cope very well with us changing the PD within an active context (the context must be idle for it to re-read the PD). As we only check whether the page is idle before changing the entry (and on through the PD tree), we cannot reliably replace PD entries on gen6/gen7. To fully

[Intel-gfx] [CI 06/23] drm/i915: Convert clflushed pagetables over to WC maps

We flush the entire page every time we update a few bytes, making the update of a page table many, many times slower than is required. If we create a WC map of the page for our updates, we can avoid the clflush but incur additional cost for creating the pagetable. We amoritize that cost by reusing

[Intel-gfx] [CI 01/23] drm/i915: Micro-optimise i915_get_ggtt_vma_pages()

The predominant VMA class is normal GTT, so allow gcc to emphasize that path and avoid unnecessary stack movement. Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 61

[Intel-gfx] [CI 12/23] drm/i915: Remove bitmap tracking for used-ptes

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=99295

[Intel-gfx] [CI 03/23] drm/i915: Micro-optimise gen8_ppgtt_insert_entries()

Improve the sg iteration and in hte process eliminate a bug in miscomputing the pml4 length as orig_nents< Reviewed-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 172 +++- 1 file changed, 93 insertions(+), 79 deletions(-)

[Intel-gfx] [CI 23/23] drm/i915: Use preferred kernel types in i915_gem_gtt.c

Make checkpatch happy and make the use of u32/u64 consistent throughout i915_gem_gtt.[ch] Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala Reviewed-by: Joonas Lahtinen ---

[Intel-gfx] [CI 20/23] drm/i915: Remove i915_address_space.start

Once upon a time, back in the UMS days, we supported userspace initialising the GTT and sharing portions of the GTT with other users. Now, we own the GTT (both global and per-process) and the tables always start at 0 - so we can remove i915_address_space.start and forget about this old

[Intel-gfx] [CI 13/23] drm/i915: Remove bitmap tracking for used-pdes

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 21/23] drm/i915: Only preallocate the aliasing GTT to the extents of the global GTT

As the aliasing GTT is only accessed via the global GTT, we will never use more of it than we expose via the Global GTT and so we only need to preallocate sufficient space within the ppgtt for the full GTT. Equally, if the aliasing GTT is smaller than the global GTT, we have a serious issue and

[Intel-gfx] [CI 16/23] drm/i915: Remove superfluous posting reads after clear GGTT

The barrier here is not required - we apply the barrier before the range is ever reused by the GPU instead. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 3 --- 1 file changed, 3 deletions(-)

[Intel-gfx] [CI 14/23] drm/i915: Remove bitmap tracking for used-pdpes

We only operate on known extents (both for alloc/clear) and so we can use both the knowledge of the bind/unbind range along with the knowledge of the existing pagetable to avoid having to allocate temporary and auxiliary bitmaps. Signed-off-by: Chris Wilson Reviewed-by:

[Intel-gfx] [CI 18/23] drm/i915: Remove defunct GTT tracepoints

The tracepoints are now entirely synonymous with binding and unbinding the VMA (and the tracepoints there). Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4 -- drivers/gpu/drm/i915/i915_trace.h

[Intel-gfx] [CI 19/23] drm/i915: Remove unused ppgtt->enable()

We never assign or use the ppgtt->enable() callback, so remove it. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_gtt.h | 1 - 1 file changed, 1 deletion(-) diff --git

[Intel-gfx] [CI 22/23] drm/i915: Differentiate the aliasing_ppgtt with an invalid filp

Use an invalid filp so that the aliasing_ppgtt can be clearly identified. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git

[Intel-gfx] [CI 17/23] drm/i915: Always mark the PDP as dirty when altered

We want to reload the PDP (and flush the TLB) when the addresses are changed. Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld --- drivers/gpu/drm/i915/i915_gem_gtt.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git

[Intel-gfx] [CI 08/23] drm/i915: Move allocate_va_range to GTT

In the future, we need to call allocate_va_range on the aliasing-ppgtt which means moving the call down from the vma into the vm (which is more appropriate for calling the vm function). Signed-off-by: Chris Wilson Reviewed-by: Matthew Auld ---

Re: [Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v2

On Wed, Feb 15, 2017 at 02:37:50PM +0200, Mika Kuoppala wrote: > Certain Baytrails, namely the 4 cpu core variants, have been > plaqued by spurious system hangs, mostly occurring with light loads. > > Multiple bisects by various people point to a commit which changes the > reclocking strategy for

Re: [Intel-gfx] kbl_guc and bxt_guc firmware missing from linux-firmware

On Wed, Feb 15, 2017 at 12:28:42PM +0200, Jani Nikula wrote: > On Tue, 14 Feb 2017, Seth Forshee wrote: > > Hi, > > > > I've noted that kbl_guc_ver9_14.bin and bxt_guc_ver8_7.bin are not in > > linux-firmware despite being available here: > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

On Wed, Feb 15, 2017 at 02:54:40PM +0200, Joonas Lahtinen wrote: > On ke, 2017-02-08 at 16:54 +, Chris Wilson wrote: > > We first wait for a request to be submitted to hw and assigned a seqno, > > before we can wait for the hw to signal completion (otherwise we don't > > know the hw id we need

[Intel-gfx] [PATCH] drm/i915: Avoid tweaking evaluation thresholds on Baytrail v3

Certain Baytrails, namely the 4 cpu core variants, have been plaqued by spurious system hangs, mostly occurring with light loads. Multiple bisects by various people point to a commit which changes the reclocking strategy for Baytrail to follow its bigger brethen: commit 8fb55197e64d ("drm/i915:

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers

On ke, 2017-02-15 at 10:59 +, Chris Wilson wrote: > We do not need to hold struct_mutex for destroying drm_i915_gem_objects > any longer, and with a little care taken over tracking > obj->framebuffer_references, we can relinquish BKL locking around the > destroy of intel_framebuffer. > >

[Intel-gfx] [PATCH 1/3] drm/i915: Make int __intel_ring_space static

From: Tvrtko Ursulin It is only used within intel_ringbuffer.c Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_ringbuffer.c | 2 +- drivers/gpu/drm/i915/intel_ringbuffer.h | 1 - 2 files changed, 1 insertion(+), 2 deletions(-)

[Intel-gfx] [PATCH 0/3] Moving the common engine/ring code to intel_engine_cs.c

From: Tvrtko Ursulin Chris suggested that we should do this but it is a lot of churn so I don't know. There is more re-org we could do to make things more logical, like maybe move struct intel_ring code to intel_ring.c, but said, I am not sure it is worth the

[Intel-gfx] [PATCH 2/3] drm/i915: Move common engine and ring code into intel_engine_cs

From: Tvrtko Ursulin This leaves the ringbuff submission code in intel_ringbuffer.c Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 834 drivers/gpu/drm/i915/intel_ringbuffer.c |

[Intel-gfx] [PATCH 3/3] drm/i915: Simplify cleanup path in intel_engines_init

From: Tvrtko Ursulin We can call the engine cleanup vfunc instead of duplicating the decision making here. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_engine_cs.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-)

Re: [Intel-gfx] ppgtt allocation fixes and speedups

On Tue, Feb 14, 2017 at 11:04:34AM +, Chris Wilson wrote: > And finally it should even compile! (Having merged the selftests.) And pushed (after applying the couple of improvements Mika and Matthew suggested). Thanks all for the help! -Chris -- Chris Wilson, Intel Open Source Technology

Re: [Intel-gfx] [PATCH i-g-t v2 7/7] tests: Use BIT macro instead of (1<<x)

On to, 2017-02-09 at 10:23 -0800, Michel Thierry wrote: > Mostly done with coccinelle, > @@ > expression x; > @@ > ( > - (1< + BIT(x) > > > > > - (1 << x) > + BIT(x) > > > > > - 1 << x > + BIT(x) > > > > > - (1UL< + BIT(x) > > > > > - (1UL << x) > + BIT(x) > > > > > - 1UL << x

Re: [Intel-gfx] [PATCH] drm/i915: Drop support for I915_EXEC_CONSTANTS_* execbuf parameters.

On ke, 2017-02-15 at 10:40 +, Chris Wilson wrote: > On Wed, Feb 15, 2017 at 01:34:46AM -0800, Kenneth Graunke wrote: > > > > This patch makes the I915_PARAM_HAS_EXEC_CONSTANTS getparam return 0 > > (indicating the optional feature is not supported), and makes execbuf > > always return -EINVAL

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers

== Series Details == Series: series starting with [1/3] drm/i915: Remove struct_mutex for destroying framebuffers URL : https://patchwork.freedesktop.org/series/19692/ State : success == Summary == Series 19692v1 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+

== Series Details == Series: series starting with [1/2] drm/i915: Use a heavyweight irq-seqno barrier for gen6+ URL : https://patchwork.freedesktop.org/series/19697/ State : failure == Summary == Series 19697v1 Series without cover letter

Re: [Intel-gfx] [PATCH v3 4/4] drm: Resurrect atomic rmfb code, v3

On Wed, 25 Jan 2017, Maarten Lankhorst wrote: > This was somehow lost between v3 and the merged version in Maarten's > patch merged as: > > commit f2d580b9a8149735cbc4b59c4a8df60173658140 > Author: Maarten Lankhorst > Date:

[Intel-gfx] [PULL] drm-misc-next-fixes

Hi Dave, a couple of drm core fixes for the v4.11 merge window. BR, Jani. The following changes since commit 13f62f54d174d3417c3caaafedf5e22a0a03e442: Merge branch 'drm-next-4.11' of git://people.freedesktop.org/~agd5f/linux into drm-next (2017-02-10 10:13:30 +1000) are available in the

[Intel-gfx] [PULL] drm-intel-next-fixes

Hi Dave, I'm flushing out the GVT fixes for the v4.11 merge window. I'll probably have more pure i915 fixes still. Heads up, for some reason your merge of drm-rockchip-next-2017-02-07 shows up in the stats below. I'm not quite sure what's going on here. Let me know if you want me to do something

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Remove struct_mutex for destroying framebuffers

On Wed, Feb 15, 2017 at 03:59:23PM +0200, Joonas Lahtinen wrote: > On ke, 2017-02-15 at 10:59 +, Chris Wilson wrote: > > We do not need to hold struct_mutex for destroying drm_i915_gem_objects > > any longer, and with a little care taken over tracking > > obj->framebuffer_references, we can

Re: [Intel-gfx] [PATCH] drm/i915: Check for timeout completion when waiting for the rq to submitted

On ke, 2017-02-08 at 16:54 +, Chris Wilson wrote: > We first wait for a request to be submitted to hw and assigned a seqno, > before we can wait for the hw to signal completion (otherwise we don't > know the hw id we need to wait upon). Whilst waiting for the request to > be submitted, we may

[Intel-gfx] [PATCH v2] drm/i915: Only enable hotplug interrupts if the display interrupts are enabled

In order to prevent accessing the hpd registers outside of the display power wells, we should refrain from writing to the registers before the display interrupts are enabled. [4.740136] WARNING: CPU: 1 PID: 221 at drivers/gpu/drm/i915/intel_uncore.c:795 __unclaimed_reg_debug+0x44/0x50 [i915]

  1   2   >