Re: [Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation

On 14/01/16 22:09, Chris Wilson wrote: On Thu, Jan 14, 2016 at 03:02:59PM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin At the moment execbuf ring selection is fully coupled to internal ring ids which is not a good thing on its own. This dependency is also

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

On Fri, Jan 15, 2016 at 09:53:46AM +, Tvrtko Ursulin wrote: > > On 14/01/16 13:34, Chris Wilson wrote: > >On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote: > >>>diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h > >>>b/drivers/gpu/drm/i915/i915_gem_gtt.h > >>>index

Re: [Intel-gfx] [PATCH 079/190] drm/i915: Reduce the pointer dance of i915_is_ggtt()

On 11/01/16 09:17, Chris Wilson wrote: The multiple levels of indirect do nothing but hinder the compiler and the pointer chasing turns to be quite painful but painless to fix. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_debugfs.c| 13

Re: [Intel-gfx] [PATCH i-g-t] tools/intel_bios_reader: Fix typo on dump info

On Fri, 15 Jan 2016, Mika Kahola wrote: > Fix typo on intel_bios_reader.c > > Signed-off-by: Mika Kahola Pushed, thanks for the patch. BR, Jani. > --- > tools/intel_bios_reader.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On 15/01/16 12:27, Chris Wilson wrote: On Fri, Jan 15, 2016 at 11:58:32AM +, Tvrtko Ursulin wrote: On 15/01/16 11:06, Chris Wilson wrote: Tvrtko was looking through the execbuffer-ioctl and noticed that the uABI was tightly coupled to our internal engine identifiers. Close inspection

[Intel-gfx] [PATCH] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

Throughout the code base, we use u32 for offsets into the global GTT. If we ever see any hardware with a larger GGTT, then we run the real risk of silent corruption. So test for our assumption up front so that we have a nice reminder should the time come when it fails. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

Tvrtko was looking through the execbuffer-ioctl and noticed that the uABI was tightly coupled to our internal engine identifiers. Close inspection also revealed that we leak those internal engine identifiers through the busy-ioctl, and those internal identifiers already do not match the user

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (skl-i7k-2)

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Remove obsolete starting offset from struct i915_address_space

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE dmesg-warn -> PASS

Re: [Intel-gfx] [PATCH] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

On Fri, Jan 15, 2016 at 11:28:16AM +, Chris Wilson wrote: > On Fri, Jan 15, 2016 at 10:20:11AM +, Chris Wilson wrote: > > Throughout the code base, we use u32 for offsets into the global GTT. If > > we ever see any hardware with a larger GGTT, then we run the real risk > > of silent

Re: [Intel-gfx] [PATCH] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

On 15/01/16 10:20, Chris Wilson wrote: Throughout the code base, we use u32 for offsets into the global GTT. If we ever see any hardware with a larger GGTT, then we run the real risk of silent corruption. So test for our assumption up front so that we have a nice reminder should the time come

Re: [Intel-gfx] [PATCH] drm/i915: Decouple execbuf uAPI from internal implementation

On Fri, Jan 15, 2016 at 10:29:05AM +, Tvrtko Ursulin wrote: > >One question, how does this look if we move this section to its own > >function: > > > >ring = eb_select_ring(dev_priv, file, args); > >if (IS_ERR(ring)) > > return PTR_ERR(ring); > > > >Do you keep your code size reduction? >

Re: [Intel-gfx] [PATCH] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

On Fri, Jan 15, 2016 at 11:25:38AM +, Dave Gordon wrote: > On 15/01/16 10:20, Chris Wilson wrote: > >Throughout the code base, we use u32 for offsets into the global GTT. If > >we ever see any hardware with a larger GGTT, then we run the real risk > >of silent corruption. So test for our

Re: [Intel-gfx] [PATCH 079/190] drm/i915: Reduce the pointer dance of i915_is_ggtt()

On Fri, Jan 15, 2016 at 12:12:15PM +, Dave Gordon wrote: > On 11/01/16 09:17, Chris Wilson wrote: > >The multiple levels of indirect do nothing but hinder the compiler and > >the pointer chasing turns to be quite painful but painless to fix. > > > >Signed-off-by: Chris Wilson

Re: [Intel-gfx] [i-g-t PATCH 0/6] intel_bios_reader: support MIPI sequence block v3

On Thu, 14 Jan 2016, Jani Nikula wrote: > Support MIPI sequence block v3 in the intel_bios_reader tool. This is > mostly copied from the kernel. It makes some of the parts a bit > artifical for an userspace tool, but hey, this pattern has been followed > all around in IGT

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Splitting intel_dp_detect

On Thu, 2016-01-14 at 19:20 +0530, Shubhangi Shrivastava wrote: > > On Wednesday 13 January 2016 07:03 PM, Ander Conselvan De Oliveira wrote: > > On Wed, 2016-01-13 at 13:20 +0200, Ander Conselvan De Oliveira wrote: > > > On Tue, 2016-01-05 at 18:20 +0530, Shubhangi Shrivastava wrote: > > > >

Re: [Intel-gfx] [PATCH] drm/i915: Codify our assumption that the Global GTT is <= 4GiB

On Fri, Jan 15, 2016 at 10:20:11AM +, Chris Wilson wrote: > Throughout the code base, we use u32 for offsets into the global GTT. If > we ever see any hardware with a larger GGTT, then we run the real risk > of silent corruption. So test for our assumption up front so that we > have a nice

Re: [Intel-gfx] [PATCH v10] drm/i915: Extend LRC pinning to cover GPU context writeback

On 14/01/2016 12:37, Nick Hoath wrote: On 14/01/2016 12:31, Chris Wilson wrote: On Thu, Jan 14, 2016 at 11:56:07AM +, Nick Hoath wrote: On 14/01/2016 11:36, Chris Wilson wrote: On Wed, Jan 13, 2016 at 04:19:45PM +, Nick Hoath wrote: + if (ctx->engine[ring->id].dirty) { +

Re: [Intel-gfx] ✗ failure: Fi.CI.BAT

On Thu, Jan 14, 2016 at 05:00:02PM +0200, Ville Syrjälä wrote: > On Thu, Jan 14, 2016 at 02:49:45PM -, Patchwork wrote: > > == Summary == > > > > Built on 8fb2feecca499d11e104264071ac55e273e23af5 drm-intel-nightly: > > 2016y-01m-14d-13h-06m-44s UTC integration manifest > > > > Test

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On Fri, Jan 15, 2016 at 11:58:32AM +, Tvrtko Ursulin wrote: > > On 15/01/16 11:06, Chris Wilson wrote: > >Tvrtko was looking through the execbuffer-ioctl and noticed that the > >uABI was tightly coupled to our internal engine identifiers. Close > >inspection also revealed that we leak those

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Codify our assumption that the Global GTT is <= 4GiB

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) pass -> DMESG-WARN (bdw-ultra)

[Intel-gfx] [PATCH] drm/i915: Remove obsolete starting offset from struct i915_address_space

Since the removal of UMS, we have always had sole ownership of the GTTs. We no longer have to track the subsection we are allowed to use (denoted by start + total). vGPU does restrict the range of the global GTT we can use (as it has to share it amongst all the clients on the host), but that is

Re: [Intel-gfx] [PATCH i-g-t 2/2] lib/igt_kms: Short description between Intel/DRM terminology.

On Fri, Jan 15, 2016 at 11:06:42AM +0200, Marius Vlad wrote: > lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes, encoders and > connectors. > > Signed-off-by: Marius Vlad > --- > lib/igt_kms.c | 82 >

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On 15/01/16 11:06, Chris Wilson wrote: Tvrtko was looking through the execbuffer-ioctl and noticed that the uABI was tightly coupled to our internal engine identifiers. Close inspection also revealed that we leak those internal engine identifiers through the busy-ioctl, and those internal

[Intel-gfx] [PATCH 3/6] drm/i915: Broadwell execlists needs exactly the same seqno w/a as legacy

In legacy mode, we use the gen6 seqno barrier to insert a delay after the interrupt before reading the seqno (as the seqno write is not flushed before the interrupt is sent, the interrupt arrives before the seqno is visible). Execlists ignored the evidence of igt. Note that is harder, but not

[Intel-gfx] [PATCH 1/3] drm/i915: Do not call API requiring struct_mutex where it is not available

From: Tvrtko Ursulin LRC code was calling GEM API like i915_gem_obj_ggtt_offset from places where the struct_mutex cannot be grabbed (irq handlers). To avoid that this patch caches some interesting bits and values in the engine and context structures. Some usages are

[Intel-gfx] [PATCH 2/3] drm/i915: Cache ringbuffer GTT VMA

From: Tvrtko Ursulin Purpose is to avoid calling i915_gem_obj_ggtt_offset from the interrupt context without the big lock held. v2: Renamed gtt_start to gtt_offset. (Daniel Vetter) v3: Cache the VMA instead of address. (Chris Wilson) Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [PATCH] drm/i915: Only grab timestamps when needed

From: Tvrtko Ursulin No need to call ktime_get_raw_ns twice per unlimited wait and can also elimate a local variable. v2: Added comment about silencing the compiler warning. (Daniel Vetter) Signed-off-by: Tvrtko Ursulin Reviewed-by: Dave

Re: [Intel-gfx] [PATCH igt] tests: Add gem_busy

On Fri, Jan 15, 2016 at 02:45:49PM +, Tvrtko Ursulin wrote: > > On 15/01/16 13:53, Chris Wilson wrote: > >Exercise the busy-ioctl and verify it reports the right active engines > >using the execbuffer notation. > > > >Signed-off-by: Chris Wilson > >--- > >

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote: > Looks like your DDX is the only user not using it in the boolean mode? As far as I am aware, that is the only user that worries about which engine the object is currently active on. > And libdrm is a bit confused in its return

Re: [Intel-gfx] [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

On pe, 2016-01-15 at 16:44 +0200, Imre Deak wrote: > Adding Chris. We would need stolen_base and size early, could you > check > if moving i915_gem_init_stolen() earlier based on the diff at the end > is ok? Oops, I meant stolen reserved_base and reserved_size. > On to, 2016-01-14 at 21:26

Re: [Intel-gfx] [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

On Fri, Jan 15, 2016 at 04:44:46PM +0200, Imre Deak wrote: > Adding Chris. We would need stolen_base and size early, could you check > if moving i915_gem_init_stolen() earlier based on the diff at the end > is ok? Had a quick discussion with Imre on irc, and yes this is fine. Though we could move

Re: [Intel-gfx] [PATCH igt] tests: Add gem_busy

On 15/01/16 13:53, Chris Wilson wrote: Exercise the busy-ioctl and verify it reports the right active engines using the execbuffer notation. Signed-off-by: Chris Wilson --- tests/Makefile.sources | 1 + tests/gem_busy.c | 233

[Intel-gfx] [PATCH] MAINTAINERS: Add "B:" preferred bug reporting method

Different subsystems and drivers have different preferred ways of receiving bug reports; mailing list or bugzillas at various locations. Add "B:" entry for specifying the preference to guide bug reporters at the right location. While at it, document the freedesktop.org bugzilla as the preferred

Re: [Intel-gfx] [PATCH 10/11] acpi: Export acpi_bus_type

On Thursday, January 14, 2016 11:46:46 AM ankitprasad.r.sha...@intel.com wrote: > From: Ankitprasad Sharma > > Some modules, like i915.ko, needs to detect when certain ACPI features > are active inorder to prevent corruption on contended resources. > In

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

On 15/01/16 11:44, Chris Wilson wrote: On Fri, Jan 15, 2016 at 09:53:46AM +, Tvrtko Ursulin wrote: On 14/01/16 13:34, Chris Wilson wrote: On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote: diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/6] drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS (bdw-nuci7) UNSTABLE Test kms_flip: Subgroup

[Intel-gfx] [PATCH igt] tests: Add gem_busy

Exercise the busy-ioctl and verify it reports the right active engines using the execbuffer notation. Signed-off-by: Chris Wilson --- tests/Makefile.sources | 1 + tests/gem_busy.c | 233 + 2 files changed, 234

Re: [Intel-gfx] [PATCH v5 1/1] drm/i915/bxt: Check BIOS RC6 setup before enabling RC6

Adding Chris. We would need stolen_base and size early, could you check if moving i915_gem_init_stolen() earlier based on the diff at the end is ok? On to, 2016-01-14 at 21:26 +0530, Sagar Arun Kamble wrote: > RC6 setup is shared between BIOS and Driver. BIOS sets up subset of RC6 > setup

[Intel-gfx] [PATCH 3/3] drm/i915: Cache LRC state page in the context

From: Tvrtko Ursulin LRC lifetime is well defined so we can cache the page pointing to the object backing store in the context in order to avoid walking over the object SG page list from the interrupt context without the big lock held. v2: Also cache the mapping.

[Intel-gfx] [PATCH v2] drm/i915: Decouple execbuf uAPI from internal implementation

From: Tvrtko Ursulin At the moment execbuf ring selection is fully coupled to internal ring ids which is not a good thing on its own. This dependency is also spread between two source files and not spelled out at either side which makes it hidden and fragile. This

[Intel-gfx] PROBLEM: displayport MST external monitors don't return from sleep mode

Kind Regards, Derek Yerger Computer Engineering 10171358 / djy24 [1.] displayport MST external monitors don't return from sleep mode [2.] When displays go to sleep, upon return from sleep the two monitors attached to a belkin mini displayport to 2x HDMI, do not return from sleep. This results

[Intel-gfx] [PATCH 2/6] drm/i915: Separate out the seqno-barrier from engine->get_seqno

In order to simplify future patches, extract the lazy_coherency optimisation our of the engine->get_seqno() vfunc into its own callback. v2: Rename the barrier to engine->irq_seqno_barrier to try and better reflect that the barrier is only required after the user interrupt before reading the

[Intel-gfx] [PATCH 5/6] drm/i915: Use simplest form for flushing the single cacheline in the HWS

Rather than call a function to compute the matching cachelines and clflush them, just call the clflush *instruction* directly. We also know that we can use the unpatched plain clflush rather than the clflushopt alternative. Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH 6/6] drm/i915: Replace manual barrier() with READ_ONCE() in HWS accessor

When reading from the HWS page, we use barrier() to prevent the compiler optimising away the read from the volatile (may be updated by the GPU) memory address. This is more suited to READ_ONCE(); make it so. Signed-off-by: Chris Wilson Cc: Daniel Vetter

[Intel-gfx] [PATCH 4/6] drm/i915: Harden detection of missed interrupts

Only declare a missed interrupt if we find that the GPU is idle with waiters and a hangcheck interval has passed in which no new user interrupts have been raised. Signed-off-by: Chris Wilson Cc: Mika Kuoppala ---

[Intel-gfx] "missed-interrupt" syndrome on Broadwell+

Mika wanted to bump these patches as they should help reduce both real and false declarations of missed interrupts plaguing Broadwell/Skylake CI. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

[Intel-gfx] [PATCH 1/6] drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+

In order to ensure seqno/irq coherency, we current read a ring register. We are not sure quite how it works, only that is does. Experiments show that e.g. doing a clflush(seqno) instead is not sufficient, but we can remove the forcewake dance from the mmio access. v2: Baytrail wants a clflush

[Intel-gfx] [PATCH i-g-t] tests/kms_fbc_crc.c: No longer dependant on Cairo A setup function that used to use Cairo to draw 2 rectangles covering the whole screen has been changed to use igt_draw

From: Devon Davies tests/kms_frontbuffer_tracking.c: Now builds with DRM_PRIMARY_DISABLE Each call to the function drmModeSetPlane now has an addtional NULL in the arguments if DRM_PRIMARY_DISABLE is set. tests/Android.mk: Allow the above tests to be built

Re: [Intel-gfx] [PATCH v2] drm/i915: Decouple execbuf uAPI from internal implementation

On Fri, Jan 15, 2016 at 03:12:50PM +, Tvrtko Ursulin wrote: > +static int > +eb_select_ring(struct drm_i915_private *dev_priv, > +struct drm_file *file, > +struct drm_i915_gem_execbuffer2 *args, > +struct intel_engine_cs **ring) > +{ > + unsigned int

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Decouple execbuf uAPI from internal implementation (rev2)

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE pass -> DMESG-WARN

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids (rev2)

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i5k-2) UNSTABLE dmesg-warn -> PASS

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Only grab timestamps when needed

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (bdw-ultra) UNSTABLE Test kms_flip: Subgroup

Re: [Intel-gfx] [PATCH v5] drm/i915: Cache LRC state page in the context

On Fri, Jan 15, 2016 at 04:39:29PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > LRC lifetime is well defined so we can cache the page pointing > to the object backing store in the context in order to avoid > walking over the object SG page list from the

Re: [Intel-gfx] [PATCH v2] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On Fri, Jan 15, 2016 at 04:51:46PM +, Chris Wilson wrote: > Tvrtko was looking through the execbuffer-ioctl and noticed that the > uABI was tightly coupled to our internal engine identifiers. Close > inspection also revealed that we leak those internal engine identifiers > through the

[Intel-gfx] [PATCH v6] drm/i915: Cache LRC state page in the context

From: Tvrtko Ursulin LRC lifetime is well defined so we can cache the page pointing to the object backing store in the context in order to avoid walking over the object SG page list from the interrupt context without the big lock held. v2: Also cache the mapping.

Re: [Intel-gfx] [PATCH 1/6] drm/i915: Remove forcewake dance from seqno/irq barrier on legacy gen6+

Chris Wilson writes: > In order to ensure seqno/irq coherency, we current read a ring register. > We are not sure quite how it works, only that is does. Experiments show > that e.g. doing a clflush(seqno) instead is not sufficient, but we can > remove the forcewake

[Intel-gfx] [PATCH v2] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

Tvrtko was looking through the execbuffer-ioctl and noticed that the uABI was tightly coupled to our internal engine identifiers. Close inspection also revealed that we leak those internal engine identifiers through the busy-ioctl, and those internal identifiers already do not match the user

Re: [Intel-gfx] [PATCH i-g-t] tools/Android.mk: Add zlib support

On Fri, Jan 15, 2016 at 03:49:00PM +, Morton, Derek J wrote: > Can this be merged so IGT on Android builds? No one has raise any > objections since Monday about this patch. Merged, thanks for the patch. -- Damien ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Cache LRC state page in the context

On Fri, Jan 15, 2016 at 04:05:24PM +, Tvrtko Ursulin wrote: > > On 15/01/16 16:01, Chris Wilson wrote: > >On Fri, Jan 15, 2016 at 03:10:29PM +, Tvrtko Ursulin wrote: > >>@@ -1118,15 +1126,22 @@ void intel_lr_context_unpin(struct > >>drm_i915_gem_request *rq) > >>+ if

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On Fri, Jan 15, 2016 at 04:02:52PM +, Tvrtko Ursulin wrote: > > On 15/01/16 13:57, Chris Wilson wrote: > >On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote: > >>Looks like your DDX is the only user not using it in the boolean mode? > > > >As far as I am aware, that is the only

[Intel-gfx] ✗ Fi.CI.BAT: failure for MAINTAINERS: Add "B:" preferred bug reporting method

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: pass ->

Re: [Intel-gfx] [PATCH i-g-t] tools/Android.mk: Add zlib support

Can this be merged so IGT on Android builds? No one has raise any objections since Monday about this patch. //Derek -Original Message- From: Morton, Derek J Sent: Monday, January 11, 2016 1:32 PM To: intel-gfx@lists.freedesktop.org Cc: Wood, Thomas; Gore, Tim; ch...@chris-wilson.co.uk;

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Cache LRC state page in the context

On 15/01/16 16:01, Chris Wilson wrote: On Fri, Jan 15, 2016 at 03:10:29PM +, Tvrtko Ursulin wrote: @@ -1118,15 +1126,22 @@ void intel_lr_context_unpin(struct drm_i915_gem_request *rq) + if (--rq->ctx->engine[ring->id].pin_count == 0) { + lrc_state_page =

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Cache LRC state page in the context

On Fri, Jan 15, 2016 at 03:10:29PM +, Tvrtko Ursulin wrote: > @@ -1118,15 +1126,22 @@ void intel_lr_context_unpin(struct > drm_i915_gem_request *rq) > + if (--rq->ctx->engine[ring->id].pin_count == 0) { > + lrc_state_page = i915_gem_object_get_dirty_page(ctx_obj, > +

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On 15/01/16 13:57, Chris Wilson wrote: On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote: Looks like your DDX is the only user not using it in the boolean mode? As far as I am aware, that is the only user that worries about which engine the object is currently active on. And

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Do not call API requiring struct_mutex where it is not available

== Summary == Built on 615fbad7f4cea73b1a8eccdcc942c8ca1a708dab drm-intel-nightly: 2016y-01m-15d-09h-46m-32s UTC integration manifest Test gem_storedw_loop: Subgroup basic-render: pass -> DMESG-WARN (skl-i7k-2) UNSTABLE Test kms_flip: Subgroup

Re: [Intel-gfx] [PATCH] drm/i915: Seal busy-ioctl uABI and prevent leaking of internal ids

On 15/01/16 16:19, Chris Wilson wrote: On Fri, Jan 15, 2016 at 04:02:52PM +, Tvrtko Ursulin wrote: On 15/01/16 13:57, Chris Wilson wrote: On Fri, Jan 15, 2016 at 01:22:39PM +, Tvrtko Ursulin wrote: Looks like your DDX is the only user not using it in the boolean mode? As far as I

[Intel-gfx] [PATCH v5] drm/i915: Cache LRC state page in the context

From: Tvrtko Ursulin LRC lifetime is well defined so we can cache the page pointing to the object backing store in the context in order to avoid walking over the object SG page list from the interrupt context without the big lock held. v2: Also cache the mapping.

[Intel-gfx] [PATCH] drm/i915: Don't reject primayr plane windowing with color keying enabled on SKL+

From: Ville Syrjälä On SKL+ plane scaling is mutually exclusive with color keying. The code check for this, but during some refactoring the code got changed to also reject primary plane windowing when color keying is used. There is no such restriction in the

Re: [Intel-gfx] [PATCH] drm/i915: skl_update_scaler() wants a rotation bitmask instead of bit number

On Thu, Oct 15, 2015 at 05:01:58PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler(). > The former is a mask, the latter just the bit number. > > Fortunately the only thing

Re: [Intel-gfx] [PATCH 0/8] drm/i915: Some more fb offsets[] prep stuff

On Thu, Jan 14, 2016 at 03:22:08PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > Yanked a few more prep patches from my earlier fb offsets[] work [1]. First > few have r-bs, the rest don't. > > The last two patches are new. Things just

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use the active wm config for merging on ILK-BDW

On Thu, Jan 14, 2016 at 06:37:32PM -0800, Matt Roper wrote: > On Thu, Jan 14, 2016 at 02:53:35PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > ilk_program_watermarks() is supposed to merge the active watermarks from > > all pipes. Thus

Re: [Intel-gfx] [PATCH v6] drm/i915: Cache LRC state page in the context

On Fri, Jan 15, 2016 at 05:12:45PM +, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > LRC lifetime is well defined so we can cache the page pointing > to the object backing store in the context in order to avoid > walking over the object SG page list from the

Re: [Intel-gfx] [PATCH] drm/i915: Don't do pre plane update on disabled crtcs

On Thu, Jan 14, 2016 at 06:32:10PM +0200, Mika Kuoppala wrote: > CI/Bat got following (shortened) trace on byt and also > on bsw: > > [ cut here ]--- > Unclaimed register detected before reading register 0x186500 > Call Trace: > __unclaimed_reg_debug+0x68/0x80 [i915] >

Re: [Intel-gfx] [PATCH] drm/i915: skl_update_scaler() wants a rotation bitmask instead of bit number

On Fri, Jan 15, 2016 at 08:48:26PM +0200, Ville Syrjälä wrote: > On Thu, Oct 15, 2015 at 05:01:58PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Pass BIT(DRM_ROTATE_0) instead of DRM_ROTATE_0 to skl_update_scaler(). > > The former is

Re: [Intel-gfx] [PATCH] drm/i915: Don't reject primayr plane windowing with color keying enabled on SKL+

On Fri, Jan 15, 2016 at 08:46:53PM +0200, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > On SKL+ plane scaling is mutually exclusive with color keying. The code > check for this, but during some refactoring the code got changed to > also reject

Re: [Intel-gfx] [PATCH] MAINTAINERS: Add "B:" preferred bug reporting method

On Fri, 2016-01-15 at 16:45 +0200, Jani Nikula wrote: > Different subsystems and drivers have different preferred ways of > receiving bug reports; mailing list or bugzillas at various > locations. Add "B:" entry for specifying the preference to guide bug > reporters at the right location. [] >

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [1/3] drm/i915: Do not call API requiring struct_mutex where it is not available (rev3)

== Summary == Built on 0ea9000bcb6f394edde5111494a92b0607214cfa drm-intel-nightly: 2016y-01m-15d-19h-09m-45s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS

[Intel-gfx] [PATCH i-g-t 1/2 v2] lib/igt_kms: Various fixes and add remaining documentation

lib/igt_kms: Fix minor spelling/gtk-doc links. Style changes -- trimmed several calls to asprintf(). Placed SECTION header at the beginning of the file. Add documentation for remaining functions and macros. v2: Initially, I wanted to aggregate the documentation in header file(s). This version

[Intel-gfx] [PATCH i-g-t 2/2] lib/igt_kms: Short description between Intel/DRM terminology.

lib/igt_kms: Briefly describe Intel-to-DRM mapping between pipes, encoders and connectors. Signed-off-by: Marius Vlad --- lib/igt_kms.c | 82 +++ 1 file changed, 82 insertions(+) diff --git a/lib/igt_kms.c

[Intel-gfx] [PATCH i-g-t] lib/igt_kms: Add COMIT_ATOMIC to igt_display_commit2()

So far, we had only COMMIT_UNIVERSAL and COMMIT_LEGACY, using drmModeSetPlane()/drmSetCrtc(). This patch adds COMMIT_ATOMIC to igt_display_commit2() that makes use of drmModeAtomicCommit(). Signed-off-by: Marius Vlad --- lib/igt_kms.c | 190

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Expose exec parameter to force non IA-Coherent for Gen9+ (rev2)

== Summary == Built on 4efb7ea717f8478860c4cb829fc0956f195c0b50 drm-intel-nightly: 2016y-01m-15d-02h-35m-27s UTC integration manifest Test gem_ctx_basic: pass -> FAIL (bdw-ultra) Test gem_storedw_loop: Subgroup basic-render: dmesg-warn -> PASS

[Intel-gfx] [PATCH] [v2] drm/i915: Exec flag to force non IA-Coherent cache for Gen9+

Starting from Gen9 we can use IA-Coherent caches. Generally, coherency can be programmed using RENDER_SURFACE_STATE or BTI 255, depending if surface state model or stateless model is used. It is important to control whether IA or GPU cache coherency should be used, especially for non-LLC devices.

[Intel-gfx] [PATCH i-g-t] tools/intel_bios_reader: Fix typo on dump info

Fix typo on intel_bios_reader.c Signed-off-by: Mika Kahola --- tools/intel_bios_reader.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/tools/intel_bios_reader.c b/tools/intel_bios_reader.c index b31f648..5ca50ff 100644 --- a/tools/intel_bios_reader.c

Re: [Intel-gfx] [PATCH igt] igt/gem_softpin: Remove false dependencies on esoteric features

Hi, On 14/01/16 11:02, Chris Wilson wrote: For softpinning, we do not require either userptr or extended ppgtt, so remove those requirements and make the tests work universally. (Certain ABI tests require large GTT, or per-process GTT.) In the process, make the tests more extensive - validate

Re: [Intel-gfx] [PATCH] drm/i915/dp: fall back to 18 bpp when sink capability is unknown

On Wed, 13 Jan 2016, Ville Syrjälä wrote: > On Wed, Jan 13, 2016 at 04:35:20PM +0200, Jani Nikula wrote: >> Per DP spec, the source device should fall back to 18 bpp, VESA range >> RGB when the sink capability is unknown. Fix the color depth >> clamping. 18 bpp

Re: [Intel-gfx] [PATCH] drm/i915: Make sure DC writes are coherent on flush.

On Thu, 14 Jan 2016, Francisco Jerez wrote: > Jani Nikula writes: > >> On Thu, 14 Jan 2016, Francisco Jerez wrote: >>> We need to set the DC FLUSH PIPE_CONTROL bit on Gen7+ to guarantee >>> that writes performed via the

Re: [Intel-gfx] [PATCH] drm/i915/bios: Fix the sequence size calculations for MIPI seq v3

On Thu, 14 Jan 2016, Ville Syrjälä wrote: > On Thu, Jan 14, 2016 at 05:12:07PM +0200, Jani Nikula wrote: >> Two errors in a single line. The size was read from the wrong offset, >> and the end index didn't take the five bytes for sequence byte and size >> of

Re: [Intel-gfx] [PATCH 01/11] drm/i915: Add support for mapping an object page by page

On 14/01/16 13:34, Chris Wilson wrote: On Thu, Jan 14, 2016 at 10:32:11AM +, Tvrtko Ursulin wrote: diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.h b/drivers/gpu/drm/i915/i915_gem_gtt.h index b448ad8..5f86596 100644 --- a/drivers/gpu/drm/i915/i915_gem_gtt.h +++

Re: [Intel-gfx] [PATCH 7/8] drm/i915: Make display gtt offsets u32

On Thu, Jan 14, 2016 at 10:36:53PM +, Chris Wilson wrote: > On Thu, Jan 14, 2016 at 03:22:15PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Using 'unsigned long' for ggtt offsets doesn't make much sense. Use > > 'u32' instead