Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firmware path handling

On ke, 2017-02-22 at 16:52 +0100, Arkadiusz Hiler wrote: > On Wed, Feb 22, 2017 at 04:30:49PM +0100, Arkadiusz Hiler wrote: > > > > On Wed, Feb 22, 2017 at 12:53:47PM +, Chris Wilson wrote: > > > > > > Now plan for having fw_path overriden by a i915_param.guc_firmware. > > > > > > Perhaps

[Intel-gfx] ✓ Fi.CI.BAT: success for GLK plane/scaling fixes (rev2)

== Series Details == Series: GLK plane/scaling fixes (rev2) URL : https://patchwork.freedesktop.org/series/20051/ State : success == Summary == Series 20051v2 GLK plane/scaling fixes https://patchwork.freedesktop.org/api/1.0/series/20051/revisions/2/mbox/ fi-bdw-5557u total:253 pass:242

[Intel-gfx] [PATCH v4 15/16] drm/i915: Immediately process a reset before starting waiting

As we handoff the GPU reset to the waiter, we need to check we don't miss a wakeup if it has already been sent prior to us starting the wait. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 7 +-- 1 file changed, 5 insertions(+), 2

Re: [Intel-gfx] [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()

On ke, 2017-02-22 at 16:29 +0100, Arkadiusz Hiler wrote: > On Wed, Feb 22, 2017 at 03:59:01PM +0200, Joonas Lahtinen wrote: > > > > > + * @huc: intel_huc struct > > >   * > > >   * Called early during driver load, but after GEM is initialised. The > > > loading > > >   * will continue only when

[Intel-gfx] [PATCH v4 06/16] drm/i915: Inline __i915_gem_request_wait_for_execute()

It had only one callsite and existed to keep the code clearer. Now having shared the wait-on-error between phases and with plans to change the wait-for-execute in the next few patches, remove the out of line wait loop and move it into the main body of i915_wait_request. Signed-off-by: Chris

[Intel-gfx] [PATCH v4 01/16] drm/i915: Check against the signaled bit for fences/requests

When dma_fence_signal() is called, it sets a flag to indicate the fence is complete. Before the dma_fence is signaled, the seqno check will first be passed. During an unlocked check (such as inside a waiter), it is possible for the fence to be signaled even though the seqno has been reset (by

[Intel-gfx] [PATCH v4 12/16] drm/i915: Exercise request cancellation using a mock selftest

Add a mock selftest to preempt a request and check that we cancel it, requeue the request and then complete its execution. v2: Error leaks no more. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/selftests/i915_gem_request.c | 64 +++

[Intel-gfx] [PATCH v4 13/16] drm/i915: Replace reset_wait_queue with default_wake_function

If we change the wait_queue_t from using the autoremove_wake_function to the default_wake_function, we no longer have to restore the wait_queue_t entry on the wait_queue_head_t list after being woken up by it, as we are unusual in sleeping multiple times on the same wait_queue_t. Signed-off-by:

[Intel-gfx] Preemption preparation pass phaw

Tvrkto ordered a stay of execution for the intel_wait_helpers. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

[Intel-gfx] [PATCH v4 16/16] drm/i915: Remove one level of indention from wait-for-execute

Now that the code is getting simpler, we can reduce the indentation when waiting for the global_seqno. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_gem_request.c | 39 +++--

[Intel-gfx] [PATCH v4 08/16] drm/i915: Protect the request->global_seqno with the engine->timeline lock

A request is assigned a global seqno only when it is on the hardware execution queue. The global seqno can be used to maintain a list of requests on the same engine in retirement order, for example for constructing a priority queue for waiting. Prior to its execution, or if it is subsequently

[Intel-gfx] [PATCH v4 05/16] drm/i915: Add ourselves to the gpu error waitqueue for the entire wait

Add ourselves to the gpu error waitqueue earlier on, even before we determine we have to wait on the seqno. This is so that we can then share the waitqueue between stages in subsequent patches. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v4 14/16] drm/i915: Refactor direct GPU reset from request waiters

Combine the common code for the pair of waiters into a single function. v2: Rename reset_request to wait_request_check_and_reset Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_gem_request.c | 20 1 file changed, 12 insertions(+), 8

[Intel-gfx] [PATCH v4 11/16] drm/i915: Remove the preempted request from the execution queue

After the request is cancelled, we then need to remove it from the global execution timeline and return it to the context timeline, the inverse of submit_request(). v2: Move manipulation of struct intel_wait to helpers Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v4 03/16] drm/i915: Move reserve_seqno() next to unreserve_seqno()

Move the companion functions next to each other. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_request.c | 161 +++- 1 file changed, 77 insertions(+), 84

[Intel-gfx] [PATCH v4 02/16] drm/i915: Keep a global seqno per-engine

Replace the global device seqno with one for each engine, and account for in-flight seqno on each separately. This is consistent with dma-fence as each timeline has separate fence-contexts for each engine and a seqno is only ordered within a fence-context (i.e. seqno do not need to be ordered wrt

[Intel-gfx] [PATCH v4 10/16] drm/i915: Allow a request to be cancelled

If we preempt a request and remove it from the execution queue, we need to undo its global seqno and restart any waiters. Signed-off-by: Chris Wilson Reviewed-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/intel_breadcrumbs.c | 71

[Intel-gfx] [PATCH v4 07/16] drm/i915: Deconstruct execute fence

On reflection, we are only using the execute fence as a waitqueue on the global_seqno and not using it for dependency tracking between fences (unlike the submit and dma fences). By only treating it as a waitqueue, we can then treat it similar to the other waitqueues during submit, making the code

[Intel-gfx] [PATCH v4 04/16] drm/i915: Use a local to shorten req->i915->gpu_error.wait_queue

Use a local variable to avoid having to type out the full name of the gpu_error wait_queue. Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen Reviewed-by: Tvrtko Ursulin ---

[Intel-gfx] [PATCH v4 09/16] drm/i915: Take a reference whilst processing the signaler request

The plan in the near-future is to allow requests to be removed from the signaler. We can no longer then rely on holding a reference to the request for the duration it is in the signaling tree, and instead must obtain a reference to the request for the current operation using RCU. Signed-off-by:

Re: [Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

On Wed, Feb 22, 2017 at 10:18:33PM -0500, Lyude wrote: > Now that we can just disable HPD storm detection, there's no need to > sleep between each hotplug cycle. > > Signed-off-by: Lyude > --- > tests/chamelium.c | 5 ++--- > 1 file changed, 2 insertions(+), 3 deletions(-) >

[Intel-gfx] [PATCH v2 1/4] drm/i915/glk: Fix watermark computations for third sprite plane

Geminilake has a third sprite plane (or fourth universal plane) that is independent from the cursor. Make sure that for_each_plane_id_on_crtc() is aware of that extra plane so that the watermark code takes it into account. Fixes: e9c9882556fc ("drm/i915/glk: Configure number of sprite planes

[Intel-gfx] [PATCH v2 0/4] GLK plane/scaling fixes

Ander Conselvan de Oliveira (4): drm/i915/glk: Fix watermark computations for third sprite plane drm/i915/glk: Fix maximum scaling factor for Geminilake scalers drm/i915/glk: Pass dev_priv to intel_atomic_setup_scalers() drm/i915/glk: Fix Geminilake scalers mode programming

[Intel-gfx] [PATCH v2 3/4] drm/i915/glk: Pass dev_priv to intel_atomic_setup_scalers()

Pass dev_priv to intel_atomic_setup_scalers(). The next patch will need a dev_priv pointer. Cc: Ville Syrjälä Signed-off-by: Ander Conselvan de Oliveira --- drivers/gpu/drm/i915/intel_atomic.c | 10 +-

[Intel-gfx] [PATCH v2 4/4] drm/i915/glk: Fix Geminilake scalers mode programming

Geminilake scalers can do 7x7 filtering for all supported input sizes, so it doesn't need the "high quality" mode programming, which was actually removed from that platform. v2: Split dev_priv parameter change out. (Ville) Cc: Ville Syrjälä , Signed-off-by: Ander

[Intel-gfx] [PATCH v2 2/4] drm/i915/glk: Fix maximum scaling factor for Geminilake scalers

Geminilake can output two pixels per clock, and that affects the maximum scaling factor for its scalers. Take that into account and avoid the following warning: WARNING: CPU: 1 PID: 593 at drivers/gpu/drm/i915/intel_display.c:13223 skl_max_scale.part.129+0x78/0x80 [i915] WARN_ON_ONCE(!crtc_clock

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915: enable scrambling

Regards Shashank On 2/22/2017 10:59 PM, Ville Syrjälä wrote: On Wed, Feb 22, 2017 at 06:48:30PM +0530, Shashank Sharma wrote: Geminilake platform sports a native HDMI 2.0 controller, and is capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec mendates scrambling for these higher

Re: [Intel-gfx] [PATCH] drm/i915: Perform link quality check unconditionally during long pulse

On Thu, Feb 16, 2017 at 9:46 AM, Ville Syrjälä wrote: > On Thu, Feb 16, 2017 at 09:24:09AM -0800, Manasi Navare wrote: >> On Thu, Feb 16, 2017 at 07:18:57PM +0200, Ville Syrjälä wrote: >> > On Thu, Feb 16, 2017 at 09:07:53AM -0800, Manasi Navare wrote: >> > > On

Re: [Intel-gfx] [PATCH v4 4/6] drm: scrambling support in drm layer

Regards Shashank On 2/22/2017 10:54 PM, Ville Syrjälä wrote: On Wed, Feb 22, 2017 at 06:48:29PM +0530, Shashank Sharma wrote: HDMI 2.0 spec mandates scrambling for modes with pixel clock higher than 340 MHz. This patch adds few new functions in drm layer for core drivers to enable/disable

Re: [Intel-gfx] [PATCH v4 1/6] drm: Add SCDC helpers

Thanks for the review Ville, my comments inline. Regards Shashank On 2/22/2017 10:39 PM, Ville Syrjälä wrote: On Wed, Feb 22, 2017 at 06:48:26PM +0530, Shashank Sharma wrote: From: Thierry Reding SCDC is a mechanism defined in the HDMI 2.0 specification that allows the

[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_debugfs: Add functions/tests for controlling/testing HPD storm logic

Recently we added i915_hpd_storm_ctl into i915's debugfs directory, which allows us to control the thresholds i915 uses for detecting hotplug interrupt storms from userspace, along with the ability to entirely disable them. This adds some helper functions into IGT to enable making use of this

[Intel-gfx] [PATCH i-g-t 2/2] tests/chamelium: Don't sleep so much in basic hpd tests

Now that we can just disable HPD storm detection, there's no need to sleep between each hotplug cycle. Signed-off-by: Lyude --- tests/chamelium.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git a/tests/chamelium.c b/tests/chamelium.c index

Re: [Intel-gfx] [PATCH i-g-t v2] igt/drv_hangman: Fix clear_error_state

On 22/02/17 18:31, Michel Thierry wrote: v2: Use new igt_sysfs_write, add len > 0 assert in igt_sysfs_set to catch future errors, clean-up strcasecmp logic (Chris). Nevermind, didn't see you were faster than me... ___ Intel-gfx mailing list

[Intel-gfx] [PATCH i-g-t v2] igt/drv_hangman: Fix clear_error_state

clear_error_state was not doing anything (igt_sysfs_set was not writing to the error file because strlen was 0). Also fix assert_entry to catch this issue; strcasecmp returns 0 when there's a match, or an integer in a mismatch. v2: Use new igt_sysfs_write, add len > 0 assert in igt_sysfs_set to

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

On 22/02/17 18:04, Chris Wilson wrote: On Thu, Feb 23, 2017 at 01:52:04AM +, Chris Wilson wrote: On Wed, Feb 22, 2017 at 05:26:29PM -0800, Michel Thierry wrote: static void clear_error_state(void) { - igt_sysfs_set(sysfs, "error", ""); + igt_sysfs_set(sysfs, "error", " ");

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

On Thu, Feb 23, 2017 at 01:52:04AM +, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 05:26:29PM -0800, Michel Thierry wrote: > > static void clear_error_state(void) > > { > > - igt_sysfs_set(sysfs, "error", ""); > > + igt_sysfs_set(sysfs, "error", " "); > > My bad, I was expecting it

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder (rev2)

== Series Details == Series: drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder (rev2) URL : https://patchwork.freedesktop.org/series/17287/ State : success == Summary == Series 17287v2 drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

Re: [Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

On Wed, Feb 22, 2017 at 05:26:29PM -0800, Michel Thierry wrote: > clear_error_state was not doing anything (igt_sysfs_set was not writing to > the error file). > > Also fix assert_entry to catch this issue; strcasecmp returns 0 when > there's a match, or an integer in a mismatch. > > Finally,

[Intel-gfx] [PATCH i-g-t] igt/drv_hangman: Fix clear_error_state

clear_error_state was not doing anything (igt_sysfs_set was not writing to the error file). Also fix assert_entry to catch this issue; strcasecmp returns 0 when there's a match, or an integer in a mismatch. Finally, only print part of the error string when the assert fails. Cc: Chris Wilson

[Intel-gfx] [PATCH v2] drm/i915/guc: fix mmio whitelist mmio_start offset and add reminder

The mmio_start offset for the whitelist is the first FORCE_TO_NONPRIV register the GuC can use to restore the provided whitelist when an engine reset via GuC (which we still don't support) is triggered. We're currently adding the mmio_base of the engine to the absolute address of the RCS version

Re: [Intel-gfx] [PATCH] drm/i915: check status and reply value both in skl_pcode_try_request()

Thanks Imre. I see, it's a little hard to read, need to check the final state across 2 level function return value. Thanks. Best Regards. Weinan, LI > -Original Message- > From: Deak, Imre > Sent: Wednesday, February 22, 2017 4:56 PM > To: Li, Weinan Z > Cc:

Re: [Intel-gfx] [PATCH] drm/i915: Remove Braswell GGTT update w/a

On Wed, Feb 22, 2017 at 06:02:46PM +, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 11:39:30AM +, Chris Wilson wrote: > > On Wed, Feb 22, 2017 at 01:27:41PM +0200, Joonas Lahtinen wrote: > > > On ma, 2017-02-20 at 12:47 +, Chris Wilson wrote: > > > > Testing with concurrent GGTT

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/: DMC 1.04 for Geminilake

== Series Details == Series: drm/i915/: DMC 1.04 for Geminilake URL : https://patchwork.freedesktop.org/series/20091/ State : warning == Summary == Series 20091v1 drm/i915/: DMC 1.04 for Geminilake https://patchwork.freedesktop.org/api/1.0/series/20091/revisions/1/mbox/ Test prime_vgem:

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

On Wed, 2017-02-22 at 09:59 +0530, Archit Taneja wrote: > > On 02/22/2017 05:31 AM, Pandiyan, Dhinakaran wrote: > > On Fri, 2017-02-17 at 15:37 +0530, Archit Taneja wrote: > >> > >> On 02/16/2017 05:43 AM, Pandiyan, Dhinakaran wrote: > >>> On Wed, 2017-02-15 at 16:53 +0530, Archit Taneja wrote: >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine (rev2)

On Wed, Feb 22, 2017 at 08:52:45PM -, Patchwork wrote: > == Series Details == > > Series: series starting with [v2,01/15] drm/i915: Keep a global seqno > per-engine (rev2) > URL : https://patchwork.freedesktop.org/series/20056/ > State : warning > > == Summary == > > Series 20056v2

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine (rev2)

== Series Details == Series: series starting with [v2,01/15] drm/i915: Keep a global seqno per-engine (rev2) URL : https://patchwork.freedesktop.org/series/20056/ State : warning == Summary == Series 20056v2 Series without cover letter

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Check against the signaled bit for fences/requests (rev2)

== Series Details == Series: drm/i915: Check against the signaled bit for fences/requests (rev2) URL : https://patchwork.freedesktop.org/series/20085/ State : warning == Summary == Series 20085v2 drm/i915: Check against the signaled bit for fences/requests

[Intel-gfx] [PATCH] drm/i915/: DMC 1.04 for Geminilake

There is a nre version of DMC available for GLK. The release notes mentions: This FW has the fix to remove the hang conditions due to some debug related issues. Cc: Rodrigo Vivi Signed-off-by: Anusha Srivatsa ---

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

== Series Details == Series: series starting with [1/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro URL : https://patchwork.freedesktop.org/series/20086/ State : success == Summary == Series 20086v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for Enable OA unit for Gen 8 and 9 in i915 perf

== Series Details == Series: Enable OA unit for Gen 8 and 9 in i915 perf URL : https://patchwork.freedesktop.org/series/20084/ State : success == Summary == Series 20084v1 Enable OA unit for Gen 8 and 9 in i915 perf https://patchwork.freedesktop.org/api/1.0/series/20084/revisions/1/mbox/

[Intel-gfx] [PATCH v3] drm/i915: Remove the preempted request from the execution queue

After the request is cancelled, we then need to remove it from the global execution timeline and return it to the context timeline, the inverse of submit_request(). v2: Move manipulation of struct intel_wait to helpers Signed-off-by: Chris Wilson ---

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915/selftests: don't leak the gem object

== Series Details == Series: series starting with [1/2] drm/i915/selftests: don't leak the gem object URL : https://patchwork.freedesktop.org/series/20077/ State : success == Summary == Series 20077v1 Series without cover letter

[Intel-gfx] ✓ Fi.CI.BAT: success for Some minor i915-perf prep changes

== Series Details == Series: Some minor i915-perf prep changes URL : https://patchwork.freedesktop.org/series/20073/ State : success == Summary == Series 20073v1 Some minor i915-perf prep changes https://patchwork.freedesktop.org/api/1.0/series/20073/revisions/1/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH 1/2] drm/i915: signal first fence from irq handler if complete

On Wed, Feb 22, 2017 at 04:53:35PM +, Tvrtko Ursulin wrote: > > On 17/02/2017 15:51, Chris Wilson wrote: > > if (engine->irq_seqno_barrier && > >-rcu_access_pointer(engine->breadcrumbs.irq_seqno_bh) == current && > > test_and_clear_bit(ENGINE_IRQ_BREADCRUMB, >irq_posted))

Re: [Intel-gfx] [PATCH] drm/i915: Remove Braswell GGTT update w/a

On Wed, Feb 22, 2017 at 11:39:30AM +, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 01:27:41PM +0200, Joonas Lahtinen wrote: > > On ma, 2017-02-20 at 12:47 +, Chris Wilson wrote: > > > Testing with concurrent GGTT accesses no longer show the coherency > > > problems from yonder, commit

[Intel-gfx] [PATCH v2] drm/i915: Check against the signaled bit for fences/requests

When dma_fence_signal() is called, it sets a flag to indicate the fence is complete. Before the dma_fence is signaled, the seqno check will first be passed. During an unlocked check (such as inside a waiter), it is possible for the fence to be signaled even though the seqno has been reset (by

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/lspcon: Switch back to PCON mode after output replug (rev2)

== Series Details == Series: drm/i915/lspcon: Switch back to PCON mode after output replug (rev2) URL : https://patchwork.freedesktop.org/series/20072/ State : success == Summary == Series 20072v2 drm/i915/lspcon: Switch back to PCON mode after output replug

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

On Wed, Feb 22, 2017 at 05:26:34PM +, Tvrtko Ursulin wrote: > > On 17/02/2017 15:51, Chris Wilson wrote: > >A significant cost in setting up a wait is the overhead of enabling the > >interrupt. As we disable the interrupt whenever the queue of waiters is > >empty, if we are frequently waiting

Re: [Intel-gfx] [PATCH] drm/i915: Check against the signaled bit for fences/requests

On Wed, Feb 22, 2017 at 05:30:59PM +, Tvrtko Ursulin wrote: > > On 22/02/2017 16:42, Chris Wilson wrote: > >When dma_fence_signal() is called, it sets a flag to indicate the fenece > >is complete. Before the dma_fence is signaled, the seqno check will > >first be passed. However, if the

Re: [Intel-gfx] [PATCH] drm/i915: Check against the signaled bit for fences/requests

On 22/02/2017 16:42, Chris Wilson wrote: When dma_fence_signal() is called, it sets a flag to indicate the fenece is complete. Before the dma_fence is signaled, the seqno check will first be passed. However, if the request is being held by an observer across a global seqno reset, it is possible

Re: [Intel-gfx] [PATCH v4 5/6] drm/i915: enable scrambling

On Wed, Feb 22, 2017 at 06:48:30PM +0530, Shashank Sharma wrote: > Geminilake platform sports a native HDMI 2.0 controller, and is > capable of driving pixel-clocks upto 594Mhz. HDMI 2.0 spec > mendates scrambling for these higher clocks, for reduced RF footprint. > > This patch checks if the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Delay disabling the user interrupt for breadcrumbs

On 17/02/2017 15:51, Chris Wilson wrote: A significant cost in setting up a wait is the overhead of enabling the interrupt. As we disable the interrupt whenever the queue of waiters is empty, if we are frequently waiting on alternating batches, we end up re-enabling the interrupt on a frequent

Re: [Intel-gfx] [PATCH 4/5] drm/i915/gtt: No need to do tlb flush with 48bit vm

On Wed, Feb 22, 2017 at 06:54:24PM +0200, Mika Kuoppala wrote: > The pdp rewrite to force tlb flush is only a 32bit ppgtt > trick. That should not be needed with 48bit ppgtt. > > Cc: Chris Wilson > Signed-off-by: Mika Kuoppala > --- >

Re: [Intel-gfx] [PATCH v4 4/6] drm: scrambling support in drm layer

On Wed, Feb 22, 2017 at 06:48:29PM +0530, Shashank Sharma wrote: > HDMI 2.0 spec mandates scrambling for modes with pixel clock higher > than 340 MHz. This patch adds few new functions in drm layer for > core drivers to enable/disable scrambling. > > This patch adds: > - A function to detect

[Intel-gfx] ✓ Fi.CI.BAT: success for HDMI 2.0: Scrambling in DRM layer (rev4)

== Series Details == Series: HDMI 2.0: Scrambling in DRM layer (rev4) URL : https://patchwork.freedesktop.org/series/19161/ State : success == Summary == Series 19161v4 HDMI 2.0: Scrambling in DRM layer https://patchwork.freedesktop.org/api/1.0/series/19161/revisions/4/mbox/ fi-bdw-5557u

Re: [Intel-gfx] [PATCH 5/5] drm/i915/gtt: Setup vm callbacks late

On Wed, Feb 22, 2017 at 06:54:25PM +0200, Mika Kuoppala wrote: > If we manage to tangle errorpaths and get call to callbacks, > it is better to defensively keep them as null until object init is > finished so that we get clean null deref on callsite, > instead of more cryptic wreckage with partly

Re: [Intel-gfx] [PATCH 3/5] drm/i915/gtt: Use 32bit instead of legacy

On Wed, Feb 22, 2017 at 06:54:23PM +0200, Mika Kuoppala wrote: > Instead of using the subjective term legacy, use more descriptive and > less loaded name '32bit' where appropriate. Hmm. We have a mix of 32/48bit and 3/4 level. I think here we are better using e.g. gen8_mm_switch_3lvl

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Don't mark pdps clear if pdps are not submitted

On Wed, Feb 22, 2017 at 06:54:22PM +0200, Mika Kuoppala wrote: > Don't mark pdps clear if never do the necessary actions > with the hardware to make them clear. > > Signed-off-by: Mika Kuoppala > --- > drivers/gpu/drm/i915/intel_lrc.c | 17 - > 1 file

Re: [Intel-gfx] [PATCH v4 1/6] drm: Add SCDC helpers

On Wed, Feb 22, 2017 at 06:48:26PM +0530, Shashank Sharma wrote: > From: Thierry Reding > > SCDC is a mechanism defined in the HDMI 2.0 specification that allows > the source and sink devices to communicate. > > This commit introduces helpers to access the SCDC and provides

Re: [Intel-gfx] [PATCH 1/2] drm/i915: signal first fence from irq handler if complete

On Wed, Feb 22, 2017 at 04:53:35PM +, Tvrtko Ursulin wrote: > > On 17/02/2017 15:51, Chris Wilson wrote: > >@@ -4034,9 +4038,8 @@ __i915_request_irq_complete(const struct > >drm_i915_gem_request *req) > > * is woken. > > */ > > if (engine->irq_seqno_barrier && > >-

Re: [Intel-gfx] [PATCH 1/2] drm/i915: signal first fence from irq handler if complete

On 17/02/2017 15:51, Chris Wilson wrote: As execlists and other non-semaphore multi-engine devices coordinate between engines using interrupts, we can shave off a few 10s of microsecond of scheduling latency by doing the fence signaling from the interrupt as opposed to a RT kthread.

[Intel-gfx] [PATCH 2/5] drm/i915: Don't mark pdps clear if pdps are not submitted

Don't mark pdps clear if never do the necessary actions with the hardware to make them clear. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/intel_lrc.c | 17 - 1 file changed, 8 insertions(+), 9 deletions(-) diff --git

[Intel-gfx] [PATCH 3/5] drm/i915/gtt: Use 32bit instead of legacy

Instead of using the subjective term legacy, use more descriptive and less loaded name '32bit' where appropriate. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 20 ++-- drivers/gpu/drm/i915/i915_gem_gtt.h | 8

[Intel-gfx] [PATCH 1/5] drm/i915/gtt: Prefer i915_vm_is_48bit() over macro

If we setup the vm size early, we can use the newly introduced i915_vm_is_48bit() in majority of callsites wanting to know the vm size. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 58 + 1 file changed, 33

[Intel-gfx] [PATCH 5/5] drm/i915/gtt: Setup vm callbacks late

If we manage to tangle errorpaths and get call to callbacks, it is better to defensively keep them as null until object init is finished so that we get clean null deref on callsite, instead of more cryptic wreckage with partly initialized vm objects. Signed-off-by: Mika Kuoppala

[Intel-gfx] [PATCH 4/5] drm/i915/gtt: No need to do tlb flush with 48bit vm

The pdp rewrite to force tlb flush is only a 32bit ppgtt trick. That should not be needed with 48bit ppgtt. Cc: Chris Wilson Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_gem_gtt.c | 3 ++- 1 file changed, 2 insertions(+), 1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: Add name for DRM_DP_DUAL_MODE_LSPCON

== Series Details == Series: drm: Add name for DRM_DP_DUAL_MODE_LSPCON URL : https://patchwork.freedesktop.org/series/20062/ State : success == Summary == Series 20062v1 drm: Add name for DRM_DP_DUAL_MODE_LSPCON https://patchwork.freedesktop.org/api/1.0/series/20062/revisions/1/mbox/

[Intel-gfx] [PATCH] drm/i915: Check against the signaled bit for fences/requests

When dma_fence_signal() is called, it sets a flag to indicate the fenece is complete. Before the dma_fence is signaled, the seqno check will first be passed. However, if the request is being held by an observer across a global seqno reset, it is possible for the observer to not notice the seqno

[Intel-gfx] [PATCH 2/6] drm/i915: expose _SUBSLICE_MASK GETPARM

Assuming a uniform mask across all slices, this enables userspace to determine the specific sub slices enabled. This information is required, for example, to be able to analyse some OA counter reports where the counter configuration depends on the HW sub slice configuration. Signed-off-by: Robert

[Intel-gfx] [PATCH 0/6] Enable OA unit for Gen 8 and 9 in i915 perf

This extends i915 perf to support periodic sampling of OA metrics for BDW, CHV, SKL and BXT. I've recently been working through a number of issues that were uncovered once I started adapting the gen7 IGT tests. Some further issues were also noticed by others using INTEL_performance_query in Mesa.

[Intel-gfx] [PATCH 1/6] drm/i915: expose _SLICE_MASK GETPARM

Enables userspace to determine the number of slices enabled and also know what specific slices are enabled. This information is required, for example, to be able to analyse some OA counter reports where the counter configuration depends on the HW slice configuration. Signed-off-by: Robert Bragg

[Intel-gfx] [PATCH 3/6] drm/i915: Add uncore mmio api for per-context registers

Since the exponent for periodic OA counter sampling is maintained in a per-context register while we want to treat it as if it were global state we need to be able to safely issue an mmio write to a per-context register and affect any currently running context. We have to take some extra care in

[Intel-gfx] [PATCH 4/6] drm/i915: Add 'render basic' Gen8+ OA unit configs

Adds a static OA unit, MUX, B Counter + Flex EU configurations for basic render metrics on Broadwell, Cherryview, Skylake and Broxton. These are auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml >

[Intel-gfx] [PATCH 5/6] drm/i915: Add OA unit support for Gen 8+

Enables access to OA unit metrics for BDW, CHV, SKL and BXT which all share (more-or-less) the same OA unit design. Of particular note in comparison to Haswell: some OA unit HW config state has become per-context state and as a consequence it is somewhat more complicated to manage synchronous

Re: [Intel-gfx] [PATCH 2/2] drm/i915: prefer use of i915_gem_object_put

On 22 February 2017 at 16:12, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 04:01:06PM +, Matthew Auld wrote: >> Always use i915_gem_object_put over i915_gem_object_free if we can. >> >> Signed-off-by: Matthew Auld >> Cc: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for GuC Scrub vol. 1 (rev4)

== Series Details == Series: GuC Scrub vol. 1 (rev4) URL : https://patchwork.freedesktop.org/series/16856/ State : success == Summary == Series 16856v4 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/4/mbox/ fi-bdw-5557u total:253 pass:242 dwarn:0

Re: [Intel-gfx] [PATCH 1/2] drm/i915/selftests: don't leak the gem object

On Wed, Feb 22, 2017 at 04:01:05PM +, Matthew Auld wrote: > For our fake dma objects we can leak the underlying gem object if we > fail to pin our "backing storage". > > [ 39.952618] > = > [ 39.952625] BUG

Re: [Intel-gfx] [PATCH 2/2] drm/i915: prefer use of i915_gem_object_put

On Wed, Feb 22, 2017 at 04:01:06PM +, Matthew Auld wrote: > Always use i915_gem_object_put over i915_gem_object_free if we can. > > Signed-off-by: Matthew Auld > Cc: Chris Wilson > Cc: Joonas Lahtinen > ---

[Intel-gfx] [PATCH 1/2] drm/i915/selftests: don't leak the gem object

For our fake dma objects we can leak the underlying gem object if we fail to pin our "backing storage". [ 39.952618] = [ 39.952625] BUG mock_object (Tainted: G U ): Objects remaining in mock_object on

[Intel-gfx] [PATCH 2/2] drm/i915: prefer use of i915_gem_object_put

Always use i915_gem_object_put over i915_gem_object_free if we can. Signed-off-by: Matthew Auld Cc: Chris Wilson Cc: Joonas Lahtinen --- drivers/gpu/drm/i915/i915_gem_stolen.c | 2 +- 1 file changed, 1

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2)

== Series Details == Series: drm/i915: Stop using RP_DOWN_EI on Baytrail (rev2) URL : https://patchwork.freedesktop.org/series/20019/ State : success == Summary == Series 20019v2 drm/i915: Stop using RP_DOWN_EI on Baytrail

Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firmware path handling

On Wed, Feb 22, 2017 at 04:30:49PM +0100, Arkadiusz Hiler wrote: > On Wed, Feb 22, 2017 at 12:53:47PM +, Chris Wilson wrote: > > On Wed, Feb 22, 2017 at 01:41:25PM +0100, Arkadiusz Hiler wrote: > > > Currently fw->path values can represent one of three possible states: > > > > > > 1) NULL -

[Intel-gfx] [PATCH 2/3] drm/i915/perf: better pipeline aged/aging tail updates

This updates the tail pointer race workaround handling to updating the 'aged' pointer before looking to start aging a new one. There's the possibility that there is already new data available and so we can immediately start aging a new pointer without having to first wait for a later hrtimer

Re: [Intel-gfx] [PATCH 8/8] drm/i915/uc: Simplify firmware path handling

On Wed, Feb 22, 2017 at 12:53:47PM +, Chris Wilson wrote: > On Wed, Feb 22, 2017 at 01:41:25PM +0100, Arkadiusz Hiler wrote: > > Currently fw->path values can represent one of three possible states: > > > > 1) NULL - device without the uC > > 2) '\0' - device with the uC but have no

Re: [Intel-gfx] [PATCH 4/8] drm/i915/uc: Rename intel_?uc_init() to intel_?uc_fetch_fw()

On Wed, Feb 22, 2017 at 03:59:01PM +0200, Joonas Lahtinen wrote: > On ke, 2017-02-22 at 13:41 +0100, Arkadiusz Hiler wrote: > > Trying to have subject_verb_object ordering and more descriptive names, > > the intel_huc_init() and intel_guc_init() functions are renamed: > > > >  * `intel_guc` is

[Intel-gfx] [PATCH 1/3] drm/i915/perf: improve invalid OA format debug message

A minor improvement to debugging output Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_perf.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_perf.c b/drivers/gpu/drm/i915/i915_perf.c index

[Intel-gfx] [PATCH 3/3] drm/i915/perf: rate limit spurious oa report notice

This change is pre-emptively aiming to avoid a potential cause of kernel logging noise in case some condition were to result in us seeing invalid OA reports. The workaround for the OA unit's tail pointer race condition is what avoids the primary know cause of invalid reports being seen and with

[Intel-gfx] [PATCH 0/3] Some minor i915-perf prep changes

A small set of i915 perf changes that could ideally land before the gen8+ patches I hope to send out soon. These are based on top of the gen7 tail pointer race workaround changes that were sent out recently. Robert Bragg (3): drm/i915/perf: improve invalid OA format debug message

[Intel-gfx] [PATCH v2] drm/i915/lspcon: Switch back to PCON mode after output replug

At least a ParadTech PS175 LSPCON chip/firmware uses long instead of short pulses to signal output unplug/plug events. This is contrary to how branch devices normally work which use short HPD signaling. This chip will also switch to LS mode after an unplug event, which could be the consequence of

Re: [Intel-gfx] [PATCH v2 13/15] drm/i915: Refactor direct GPU reset from request waiters

On 22/02/2017 14:26, Chris Wilson wrote: On Wed, Feb 22, 2017 at 02:16:49PM +, Tvrtko Ursulin wrote: On 22/02/2017 11:46, Chris Wilson wrote: Combine the common code for the pair of waiters into a single function. Signed-off-by: Chris Wilson ---

  1   2   3   >