Re: [Intel-gfx] [08/11] drm/i915/guc: Wait for doorbell to be inactive before deallocating

On 13/03/17 01:56, Oscar Mateo wrote: On 03/13/2017 04:46 AM, Chris Wilson wrote: On Fri, Mar 10, 2017 at 08:28:55AM -0800, Oscar Mateo wrote: Doorbell release flow requires that we wait for GEN8_DRB_VALID bit to go to zero after updating db_status before we call the GuC to release the

Re: [Intel-gfx] [PATCH 20/24] drm/exynos: Merge pre/postclose hooks

2017년 03월 14일 22:28에 Daniel Vetter 이(가) 쓴 글: > On Mon, Mar 13, 2017 at 03:18:05PM -0400, Sean Paul wrote: >> On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote: >>> Again no apparent explanation for the split except hysterical raisins. >>> Merging them also makes it a bit more obviuos

[Intel-gfx] [PATCH v3 2/2] drm/i915: Implement cdclk restrictions based on Azalia BCLK

According to BSpec, "The CD clock frequency must be at least twice the frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by default. This check is needed because BXT and GLK support cdclk frequencies less than 192 MHz. v2: Include other Gen9 platforms too for completeness.(Paulo)

[Intel-gfx] [PATCH v10] drm/i915: Implement Link Rate fallback on Link training failure

If link training at a link rate optimal for a particular mode fails during modeset's atomic commit phase, then we let the modeset complete and then retry. We save the link rate value at which link training failed, update the link status property to "BAD" and use a lower link rate to prune the

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Move engine->submit_request selection to a vfunc

On Tue, Mar 14, 2017 at 04:31:58PM +, Tvrtko Ursulin wrote: > > On 14/03/2017 09:34, Chris Wilson wrote: > >It turns out that we may want to restore the original > >engine->submit_request (and engine->schedule) callbacks from more than > >just the guc <-> execlists transition. Move this to a

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Implement cdclk restrictions based on Azalia BCLK

On Tue, 2017-03-14 at 17:47 -0300, Paulo Zanoni wrote: > Em Ter, 2017-03-07 às 16:12 -0800, Dhinakaran Pandiyan escreveu: > > According to BSpec, "The CD clock frequency must be at least twice > > the > > frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by > > default. This check is

[Intel-gfx] [PATCH] drm/i915/guc: Use formalized struct definition for ads object

From: Michal Wajdeczko Manual pointer manipulation is error prone. Let compiler calculate right offsets for us in case we need to change ads layout. v2: don't call it object (Chris) v3: restyle offset assignments (Chris) v4: stylistic reductions Signed-off-by:

Re: [Intel-gfx] [PATCH v2 2/2] drm/i915: Implement cdclk restrictions based on Azalia BCLK

Em Ter, 2017-03-07 às 16:12 -0800, Dhinakaran Pandiyan escreveu: > According to BSpec, "The CD clock frequency must be at least twice > the > frequency of the Azalia BCLK." and BCLK is configured to 96 MHz by > default. This check is needed because BXT and GLK support cdclk > frequencies less than

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915/glk: Apply cdclk workaround for DP audio

Em Ter, 2017-03-07 às 16:12 -0800, Dhinakaran Pandiyan escreveu: > Implement the DP-Audio cdclk restriction for GLK, similar to what is > implemented for BDW and other GEN9 platforms. The max. pixel clock > adjustment for GLK, however factors in the 2 pixels per clock output > that > GLK

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/2] drm/i915: Extract intel_wm_plane_visible()

== Series Details == Series: series starting with [1/2] drm/i915: Extract intel_wm_plane_visible() URL : https://patchwork.freedesktop.org/series/21226/ State : success == Summary == Series 21226v1 Series without cover letter

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

From: "Navare, Manasi D" Display stream compression is supported on DP 1.4 DP devices. This patch adds the corersponding DPCD register definitions for DSC. v3: * Add some SHIFTS and MASKS for uniformity (Jani Nikula) v2: * Rebased on drm-tip Signed-off-by: Manasi

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

== Series Details == Series: GuC Scrub vol. 1 (rev13) URL : https://patchwork.freedesktop.org/series/16856/ State : success == Summary == Series 16856v13 GuC Scrub vol. 1 https://patchwork.freedesktop.org/api/1.0/series/16856/revisions/13/mbox/ Test gem_exec_suspend: Subgroup

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Use formalized struct definition for ads object (rev3)

== Series Details == Series: drm/i915/guc: Use formalized struct definition for ads object (rev3) URL : https://patchwork.freedesktop.org/series/20826/ State : success == Summary == Series 20826v3 drm/i915/guc: Use formalized struct definition for ads object

[Intel-gfx] [PATCH dim 1/2] dim: Add extract-tags command

From: Ville Syrjälä Add a command for extracting various tags (eg. Reviwed-by:) from emails. You can give the comamnd a rangeish to add the tags from the same email to multiple already applied patches. The regexp used to pick up tags is purposefully quite broad.

[Intel-gfx] [PATCH dim 2/2] dim: Add add-link command

From: Ville Syrjälä Add the "add-link" command so that you can add the Link: tag to patches that failed to apply directly. Signed-off-by: Ville Syrjälä --- dim | 39 +++ 1 file changed, 39

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/7] drm/i915: Move residency calculation into intel_pm.c

== Series Details == Series: series starting with [1/7] drm/i915: Move residency calculation into intel_pm.c URL : https://patchwork.freedesktop.org/series/21217/ State : warning == Summary == Series 21217v1 Series without cover letter

Re: [Intel-gfx] [PATCH 1/3] drm/i915: Convert intel_tv connector properties to atomic, v2.

On Mon, Mar 13, 2017 at 05:10:28PM +0100, Maarten Lankhorst wrote: > As a proof of concept, first try to convert intel_tv, which is a rarely > used connector. It has 5 properties, tv format and 4 margins. > > I'm less certain about the state behavior itself, should we pass a size > parameter to

[Intel-gfx] [PATCH] drm/i915: Keep vblanks enabled during the entire pipe update

From: Ville Syrjälä We currently hold a vblank referenced while trying to evade the vblank, but we drop it as soon as we've done that. After all the planes have been committed we are quite likely to grab a new vblank reference for delivering the flip event. This

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Replace irq_seqno_barrier on hws write with a clflush (rev2)

== Series Details == Series: drm/i915: Replace irq_seqno_barrier on hws write with a clflush (rev2) URL : https://patchwork.freedesktop.org/series/21210/ State : failure == Summary == Series 21210v2 drm/i915: Replace irq_seqno_barrier on hws write with a clflush

[Intel-gfx] [PATCH i-g-t] tests/kms_cursor_legacy: make_busy() before get_vblank()

From: Ville Syrjälä VLV is a sloth and so doing anything extra between the first and last get_vblank() is likely to increase the chance of failing the test. Let's move the make_busy() stuff to happen before the first get_vblank() to reduce the amount of work done

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/3] drm/i915/guc: Release GuC interrupts in i915_guc_submission_disable

On 3/13/2017 3:17 PM, Chris Wilson wrote: On Mon, Mar 13, 2017 at 10:28:34AM +0530, Kamble, Sagar A wrote: On 3/12/2017 6:29 PM, Chris Wilson wrote: On Sat, Mar 11, 2017 at 04:17:34AM -, Patchwork wrote: == Series Details == Series: series starting with [1/3] drm/i915/guc: Release GuC

Re: [Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock during i915_handle_error()

On 3/14/2017 10:18 AM, Chris Wilson wrote: We take the runtime pm wakelock during i915_handle_error() to ensure that all paths that reach the error capture keep the device awake during the hw reads. However, we need to extend that from the reset handler to include the earlier capture routines.

[Intel-gfx] [PATCH] drm/i915: Extend rpm wakelock during i915_handle_error()

We take the runtime pm wakelock during i915_handle_error() to ensure that all paths that reach the error capture keep the device awake during the hw reads. However, we need to extend that from the reset handler to include the earlier capture routines. Reported-by: Antonio Argenziano

Re: [Intel-gfx] [PATCH] drm/i915: get a runtime PM ref in i915_wedged_set

On Tue, Mar 14, 2017 at 10:05:08AM -0700, Michel Thierry wrote: > On 3/14/2017 2:09 AM, Chris Wilson wrote: > >On Mon, Mar 13, 2017 at 05:26:06PM -0700, Michel Thierry wrote: > >>At least in bxt (with decoupled mmio), it prevents a warning while > >>capturing the reg state: > >> > >> [ ] WARNING:

Re: [Intel-gfx] [PATCH] drm/i915: get a runtime PM ref in i915_wedged_set

On 3/14/2017 2:09 AM, Chris Wilson wrote: On Mon, Mar 13, 2017 at 05:26:06PM -0700, Michel Thierry wrote: At least in bxt (with decoupled mmio), it prevents a warning while capturing the reg state: [ ] WARNING: assert_rpm_wakelock_held.part.4+0x1e/0x20 [i915] [ ] RPM wakelock ref not held

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Implement Link Rate fallback on Link training failure"

Hi Daniel, I investigated the CI failures because of this patch. These were essentially the failures which were always there but hidden because they used be DEBUG_KMS messages for link failures so never got caught by CI. But now my patch actually throws DRM_ERROR if the link training fails at RBR

Re: [Intel-gfx] [PATCH] drm/i915: get a runtime PM ref in i915_wedged_set

On 13/03/17 17:26, Michel Thierry wrote: At least in bxt (with decoupled mmio), it prevents a warning while capturing the reg state: [ ] WARNING: assert_rpm_wakelock_held.part.4+0x1e/0x20 [i915] [ ] RPM wakelock ref not held during HW access [ ] Call Trace: [ ] dump_stack+0x63/0x87

Re: [Intel-gfx] [PATCH v3 1/2] drm/i915: Move engine->submit_request selection to a vfunc

On 14/03/2017 09:34, Chris Wilson wrote: It turns out that we may want to restore the original engine->submit_request (and engine->schedule) callbacks from more than just the guc <-> execlists transition. Move this to a vfunc so we can have a common interface. Signed-off-by: Chris Wilson

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [v3,1/2] drm/i915: Move engine->submit_request selection to a vfunc

== Series Details == Series: series starting with [v3,1/2] drm/i915: Move engine->submit_request selection to a vfunc URL : https://patchwork.freedesktop.org/series/21203/ State : success == Summary == Series 21203v1 Series without cover letter

[Intel-gfx] [PATCH] drm/i915: Disable kmem_caches when KASAN is enabled

kasan is very good at detecting use-after-free. However, our requests are allocated from a rcu-typesafe slab that is important for performance but makes kasan less effective. When enabling kasan we are intentionally looking for memory errors, disable the use of our caches to improve the likelihood

[Intel-gfx] [dim PATCH 2/2] dim: rewrite dim_cherry_pick_branch

This is what I currently use for cherry-picking fixes. Completely non-interactive and stateless. Signed-off-by: Jani Nikula --- dim | 93 + 1 file changed, 61 insertions(+), 32 deletions(-) diff --git

[Intel-gfx] [dim PATCH 1/2] dim: abstract function to look up references to commit

Signed-off-by: Jani Nikula --- dim | 37 ++--- 1 file changed, 30 insertions(+), 7 deletions(-) diff --git a/dim b/dim index 6d3b9734b348..621f60471697 100755 --- a/dim +++ b/dim @@ -660,22 +660,44 @@ function dim_apply_next_fixes

Re: [Intel-gfx] [PATCH 02/24] drm: Extract drm_prime.h

On Tue, Mar 14, 2017 at 10:12:59AM +0100, Daniel Vetter wrote: > On Mon, Mar 13, 2017 at 12:42:54PM -0400, Sean Paul wrote: > > On Wed, Mar 08, 2017 at 03:12:35PM +0100, Daniel Vetter wrote: > > > +/** > > > + * struct drm_prime_file_private - per-file tracking for PRIME > > > + * > > > + * This

[Intel-gfx] [PATCH] drm/i915/breadcrumbs: Assert that we do not shortcut the current bottom-half

We need to ensure that we always serialize updates to the bottom-half using the breadcrumbs.irq_lock so that we don't race with a concurrent interrupt handler. This is most important just prior to leaving the waiter (when the intel_wait will be overwritten), so make sure we are not the current

Re: [Intel-gfx] [PATCH 10/11] drm/i915/uc: Add params for specifying firmware

On Tue, Mar 14, 2017 at 03:28:14PM +0100, Arkadiusz Hiler wrote: > `guc_firmware_path` and `huc_firmware_path` module parameters are added. > > Using the parameter disables version checks and loads desired firmware > instead of the default one. > > v2: make params unsafe && notice about disabled

[Intel-gfx] [PATCH 1/2] drm/i915: Extract intel_wm_plane_visible()

From: Ville Syrjälä All platforms that lack double buffered watermarks will need to handle the legacy cursor updates in the same way. So let's extract the logic to determine the plane visibility into a small helper. For simplicity we'll make the function DTRT for

[Intel-gfx] [PATCH 2/2] drm/i915: Fix SKL cursor watermarks

From: Ville Syrjälä Use intel_wm_plane_visible() to determine cursor visibility for SKL+ also. Previously SKL+ would check the actual visibility which now conflicts with the assumptions in intel_legacy_cursor_update(). We also change SKL+ to compute the cursor

[Intel-gfx] [PATCH 06/11] drm/i915/guc: Extract param logic form guc_init_fw()

Let intel_guc_init_fw() focus on determining and fetching the correct firmware. This patch introduces intel_uc_sanitize_options() that is called from intel_sanitize_options(). Then, if we have GuC, we can call intel_guc_init_fw() conditionally and we do not have to do the internal checks. v2:

[Intel-gfx] [PATCH 10/11] drm/i915/uc: Add params for specifying firmware

`guc_firmware_path` and `huc_firmware_path` module parameters are added. Using the parameter disables version checks and loads desired firmware instead of the default one. v2: make params unsafe && notice about disabled fw check (J. Lahtinen) Cc: Chris Wilson Cc:

[Intel-gfx] [PATCH 07/11] drm/i915/guc: Simplify intel_guc_init_hw()

Current version of intel_guc_init_hw() does a lot: - cares about submission - loads huc - implement WA This change offloads some of the logic to intel_uc_init_hw(), which now cares about the above. v2: rename guc_hw_reset and fix typo in define name (M. Wajdeczko) v3: rename once again v4:

[Intel-gfx] [PATCH 09/11] drm/i915/uc: Separate firmware selection and preparation

intel_{h,g}uc_init_fw selects correct firmware and then triggers it's preparation (fetch + initial parsing). This change separates out select steps, so those can be called by the sanitize_options(). Then, during the init_fw(), we prepare the firmware if the firmware was selected. Cc: Michal

[Intel-gfx] [PATCH 08/11] drm/i915/uc: Simplify firmware path handling

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 firmware 3) else - device with the uC and we have firmware Second case is used only to WARN at a later stage. We can WARN right away and merge cases

[Intel-gfx] [PATCH 02/11] drm/i915/huc: Add huc_to_i915

Used to obtain "dev_priv" from huc struct pointer. We already have similar thing for guc. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Michal Wajdeczko --- drivers/gpu/drm/i915/i915_drv.h |

[Intel-gfx] [PATCH 04/11] drm/i915/uc: Move intel_uc_fw_fetch() to intel_uc.c

The file fits better. Additionally rename it to intel_uc_prepare_fw(), as the function does more than simple fetch. `obj` cleanup in the function is also fixed (i.e. removed). In the fail scenario it was always 'put' but there's no possible flow that initializes the obj properly and then goes to

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

GuC historically has two "startup" functions called _init() and _setup() Then HuC came with it's _init() and _load(). This commit renames intel_guc_setup() and intel_huc_load() to *uc_init_hw() as they called from the i915_gem_init_hw(). The aim is to be consistent in that entry points called

[Intel-gfx] [PATCH 05/11] drm/i915/uc: Introduce intel_uc_init_fw()

Instead of calling intel_guc_init() and intel_huc_init() one by one this patch introduces intel_uc_init_fw() function that calls them both. Called functions are renamed accordingly. Trying to have subject_verb_object ordering and more descriptive names, the intel_huc_init() and intel_guc_init()

[Intel-gfx] [PATCH 11/11] HAX enable GuC for CI

--- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/gpu/drm/i915/i915_params.c b/drivers/gpu/drm/i915/i915_params.c index b6a7e36..9dcc8a0 100644 --- a/drivers/gpu/drm/i915/i915_params.c +++ b/drivers/gpu/drm/i915/i915_params.c

[Intel-gfx] [PATCH 01/11] drm/i915/uc: Drop superfluous externs in intel_uc.h

Externs are implicit and we generally try to avoid them. Cc: Michal Wajdeczko Signed-off-by: Arkadiusz Hiler Reviewed-by: Joonas Lahtinen --- drivers/gpu/drm/i915/intel_uc.h | 12 ++-- 1 file

[Intel-gfx] [PATCH v9 00/11] GuC Scrub vol. 1

Reasoning = General GuC/HuC cleanup simplifying logic and moving chunks around as the area got pretty rusty. This is the first part of effort to clean it up. A lot of logic were extracted from intel_guc_load() to other functions - it did not only handle the actual loading but had WA

Re: [Intel-gfx] [PATCH i-g-t] kms_cursor_crc: Add a subtest with a 256x256 gradient cursor

On Fri, 2017-03-10 at 12:27 +0200, Ander Conselvan De Oliveira wrote: > On Fri, 2017-03-10 at 12:18 +0200, Ander Conselvan de Oliveira wrote: > > Some of the kms_cursor_crc subtests where failing on Geminilake. The > > root cause was an error on programming the pre-CSC gamma tables, which > > led

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/glk: Improve rounding caused by pre-CSC gamma tables

On Fri, 2017-03-10 at 13:18 +, Patchwork wrote: > == Series Details == > > Series: drm/i915/glk: Improve rounding caused by pre-CSC gamma tables > URL : https://patchwork.freedesktop.org/series/21049/ > State : success Pushed. Thanks for reviewing. Ander > > == Summary == > > Series

Re: [Intel-gfx] [Mesa-dev] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

Hi, On 14.03.2017 12:48, Eero Tamminen wrote: On 11.03.2017 03:14, Kenneth Graunke wrote: On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has had the surprising behavior of doing a synchronized GTT mapping. This is obviously not what the user of the API wanted. Eric left a

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Convert debugfs to use generic residency calculator

On Tue, Mar 14, 2017 at 03:17:26PM +0200, Mika Kuoppala wrote: > Use intel_rc6_residency to get benefit for increased resolution > in byt/chv. > > Signed-off-by: Mika Kuoppala I was thinking what's the point, but Reviewed-by: Chris Wilson

Re: [Intel-gfx] [PATCH 2/7] drm/i915: Return residency as microseconds

On Tue, Mar 14, 2017 at 03:17:24PM +0200, Mika Kuoppala wrote: > Change the granularity from milliseconds to microseconds > when returning rc6 residencies. This is in preparation > for increased resolution on some platforms. > > Signed-off-by: Mika Kuoppala > --- >

Re: [Intel-gfx] [PATCH 3/7] drm/i915: Extend vlv/chv residency resolution

On Tue, Mar 14, 2017 at 03:17:25PM +0200, Mika Kuoppala wrote: > The high counter value bit can be used to get 8 bits more > of range out of the same residency counter registers. Please do note that it is internally a 40bit register with a 32bit window (and a similar comment in code). > Lets

Re: [Intel-gfx] [PATCH 22/24] drm: Nerf the preclose callback for modern drivers

On Mon, Mar 13, 2017 at 03:29:20PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:55PM +0100, Daniel Vetter wrote: > > With all drivers converted there's only legacy dri1 drivers using it. > > Not going to touch those, instead just hide it like we've done with > > other dri1 driver hooks

Re: [Intel-gfx] [linux-mmotm] i915_gem_userptr_get_pages: possible circular locking dependency detected

On Tue, Mar 14, 2017 at 10:21:09PM +0900, Sergey Senozhatsky wrote: > Hello, > > [ 530.698622] == > [ 530.698623] WARNING: possible circular locking dependency detected > [ 530.698626] 4.11.0-rc2-mm1-dbg-00167-gdb8a9941614c-dirty #222 Not

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Use cpu clock to calculate rc0 residency

On Tue, Mar 14, 2017 at 01:30:40PM +, Chris Wilson wrote: > On Tue, Mar 14, 2017 at 03:17:27PM +0200, Mika Kuoppala wrote: > > Avoid more costly punit access and use the local cpu clock. > > The time diff between separate processor units is irrelevant in > > our rc0 residency granularity so we

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

On Mon, 2017-03-13 at 16:54 +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 monitor

Re: [Intel-gfx] [PATCH 12/24] drm/i915: Merge pre/postclose hooks

On Wed, Mar 08, 2017 at 04:45:13PM +0100, Daniel Vetter wrote: > On Wed, Mar 08, 2017 at 03:07:48PM +, Chris Wilson wrote: > > On Wed, Mar 08, 2017 at 03:12:45PM +0100, Daniel Vetter wrote: > > > There's really not a reason afaics that we can't just clean up > > > everything at the end, in the

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Upclock on the first residency calculation

Chris Wilson writes: > On Tue, Mar 14, 2017 at 03:17:29PM +0200, Mika Kuoppala wrote: >> After ei reset, upclock as default if we don't have a previous >> timestamp at hand. We might at sometimes waste one interval >> of more power but also be more agile if we need to

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Upclock on the first residency calculation

On Tue, Mar 14, 2017 at 03:17:29PM +0200, Mika Kuoppala wrote: > After ei reset, upclock as default if we don't have a previous > timestamp at hand. We might at sometimes waste one interval > of more power but also be more agile if we need to ramp up. Why? There is nothing special about the first

[Intel-gfx] [PATCH v3] drm/i915/guc: Use formalized struct definition for ads object

Manual pointer manipulation is error prone. Let compiler calculate right offsets for us in case we need to change ads layout. v2: don't call it object (Chris) v3: restyle offset assignments (Chris) Signed-off-by: Michal Wajdeczko Cc: Oscar Mateo

Re: [Intel-gfx] [PATCH 24/24] drm/gem: Add DEFINE_DRM_GEM_FOPS

On Mon, Mar 13, 2017 at 03:35:43PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:57PM +0100, Daniel Vetter wrote: > > Sadly there's only 1 driver which can use it, everyone else is special > > for some reason: > > > > - gma500 has a horrible runtime PM ioctl wrapper that probably

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Use cpu clock to calculate rc0 residency

On Tue, Mar 14, 2017 at 03:17:27PM +0200, Mika Kuoppala wrote: > Avoid more costly punit access and use the local cpu clock. > The time diff between separate processor units is irrelevant in > our rc0 residency granularity so we can ignore it. > > Cc: Chris Wilson > Cc:

Re: [Intel-gfx] [PATCH 20/24] drm/exynos: Merge pre/postclose hooks

On Mon, Mar 13, 2017 at 03:18:05PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:53PM +0100, Daniel Vetter wrote: > > Again no apparent explanation for the split except hysterical raisins. > > Merging them also makes it a bit more obviuos what's going on wrt the > > runtime pm

Re: [Intel-gfx] [PATCH 17/24] drm/vgem: switch to postclose

On Mon, Mar 13, 2017 at 03:11:05PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:50PM +0100, Daniel Vetter wrote: > > I didn't spot anything that would require ordering here (well not > > anywhere else either), and I'm trying to unify at least modern drivers > > on one close hook. > > >

Re: [Intel-gfx] [PATCH 11/24] drm/doc: Document drm_file.[hc]

On Mon, Mar 13, 2017 at 01:53:28PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:44PM +0100, Daniel Vetter wrote: > > Well, mostly drm_file.h, and clean up all related things: > > > > - I didnt' figure out the difference between preclose and postclose. > > The existing explanation in

Re: [Intel-gfx] [PATCH 11/24] drm/doc: Document drm_file.[hc]

On Mon, Mar 13, 2017 at 01:53:28PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:44PM +0100, Daniel Vetter wrote: > > Well, mostly drm_file.h, and clean up all related things: > > > > - I didnt' figure out the difference between preclose and postclose. > > The existing explanation in

[Intel-gfx] [PATCH 7/7] drm/i915: Upclock on the first residency calculation

After ei reset, upclock as default if we don't have a previous timestamp at hand. We might at sometimes waste one interval of more power but also be more agile if we need to ramp up. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_irq.c | 2 ++ 1 file

[Intel-gfx] [PATCH 2/7] drm/i915: Return residency as microseconds

Change the granularity from milliseconds to microseconds when returning rc6 residencies. This is in preparation for increased resolution on some platforms. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 4 ++-- drivers/gpu/drm/i915/i915_sysfs.c |

[Intel-gfx] [linux-mmotm] i915_gem_userptr_get_pages: possible circular locking dependency detected

Hello, [ 530.698622] == [ 530.698623] WARNING: possible circular locking dependency detected [ 530.698626] 4.11.0-rc2-mm1-dbg-00167-gdb8a9941614c-dirty #222 Not tainted [ 530.698627] -- [

Re: [Intel-gfx] [PATCH 10/24] drm: Remove drm_pending_event->pid

On Mon, Mar 13, 2017 at 01:05:27PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:43PM +0100, Daniel Vetter wrote: > > We might as well dump the drm_file pointer, that's about as useful > > a cookie as the pid. Noticed while typing docs for drm_file and friends. > > > > Since the only

[Intel-gfx] [PATCH 3/7] drm/i915: Extend vlv/chv residency resolution

The high counter value bit can be used to get 8 bits more of range out of the same residency counter registers. Lets toggle this bit on and off on vlv/chv while reading the counters to push the wrap from 13 seconds to 54 minutes. Reported-by: Len Brown Cc: Chris Wilson

[Intel-gfx] [PATCH 1/7] drm/i915: Move residency calculation into intel_pm.c

Plan is to make generic residency calculation utility function for usage outside of sysfs. As a first step move residency calculation into intel_pm.c Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 2 ++ drivers/gpu/drm/i915/i915_sysfs.c | 27

[Intel-gfx] [PATCH 6/7] drm/i915: Use coarse grained residency counter with byt

Set byt rc residency counters high level as chv does by default. We lose some accuracy on byt but we can do the calculation without extra hw read on both platforms, as now they behave identically in this respect. Cc: Chris Wilson Cc: Ville Syrjälä

[Intel-gfx] [PATCH 5/7] drm/i915: Use cpu clock to calculate rc0 residency

Avoid more costly punit access and use the local cpu clock. The time diff between separate processor units is irrelevant in our rc0 residency granularity so we can ignore it. Cc: Chris Wilson Cc: Ville Syrjälä Signed-off-by: Mika Kuoppala

[Intel-gfx] [PATCH 4/7] drm/i915: Convert debugfs to use generic residency calculator

Use intel_rc6_residency to get benefit for increased resolution in byt/chv. Signed-off-by: Mika Kuoppala --- drivers/gpu/drm/i915/i915_debugfs.c | 24 1 file changed, 12 insertions(+), 12 deletions(-) diff --git

Re: [Intel-gfx] [PATCH 10/11] drm/i915/uc: Add params for specifying firmware

On ma, 2017-03-13 at 14:15 +0100, Arkadiusz Hiler wrote: > `guc_firmware_path` and `huc_firmware_path` module parameters are added. > > Using the parameter disables version checks and loads desired firmware > instead of the default one. > > v2: make params unsafe && notice about disabled fw

[Intel-gfx] [PATCH] drm/i915: Avoid rcu_barrier() from reclaim paths (shrinker)

The rcu_barrier() takes the cpu_hotplug mutex which itself is not reclaim-safe, and so rcu_barrier() is illegal from inside the shrinker. [ 309.661373] = [ 309.661376] [ INFO: possible irq lock inversion dependency detected ] [

Re: [Intel-gfx] [PATCH] drm/i915: Replace irq_seqno_barrier on hws write with a clflush

On Tue, Mar 14, 2017 at 11:38:59AM +, Chris Wilson wrote: > When manually overwriting the HWS, rather than assume irq_seqno_barrier > does the right thing, we can explicitly flush the cacheline instead. > This avoids us calling the engine->irq_seqno_barrier() from an illegal > context: Drat,

[Intel-gfx] [PATCH] drm/i915: Replace irq_seqno_barrier on hws write with a clflush

When manually overwriting the HWS, rather than assume irq_seqno_barrier does the right thing, we can explicitly flush the cacheline instead. This avoids us calling the engine->irq_seqno_barrier() from an illegal context: [ 1472.651797] BUG: scheduling while atomic: migration/0/11/0x0002 [

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

On Tue 2017-03-14 10:08:23, Thorsten Leemhuis wrote: > On 06.03.2017 00:01, Pavel Machek wrote: > >>> mplayer stopped working after a while. Dmesg says: > >>> > >>> [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas

Re: [Intel-gfx] Potential BUG in drm/i915/execlists: Reset RING registers upon resume

On Tue, 14 Mar 2017, Damian Dominik Martinez Dreyer wrote: > I am writing regarding this kernel patch: https://git.kernel.org/pub/sc > m/linux/kernel/git/stable/stable-queue.git/tree/releases/4.9.9/drm- > i915-execlists-reset-ring-registers-upon-resume.patch . That would be

[Intel-gfx] [PATCH] drm/i915: Replace irq_seqno_barrier on hws write with a clflush

When manually overwriting the HWS, rather than assume irq_seqno_barrier does the right thing, we can explicitly flush the cacheline instead. This avoids us calling the engine->irq_seqno_barrier() from an illegal context: [ 1472.651797] BUG: scheduling while atomic: migration/0/11/0x0002 [

Re: [Intel-gfx] Fixes that failed to backport to v4.11-rc1

On Tue, 14 Mar 2017, Jani Nikula wrote: > Thank you for the backports. I'll likely send a pull request of the > stuff I have in -fixes now, apply these, and let them simmer until next > week's pull. I sent the fixes pull request for -rc3, and pushed Chris' backports after

Re: [Intel-gfx] [Mesa-dev] [libdrm PATCH] intel: Make unsynchronized GTT mappings work on systems with snooping.

Hi, On 11.03.2017 03:14, Kenneth Graunke wrote: On systems without LLC, drm_intel_gem_bo_map_unsynchronized() has had the surprising behavior of doing a synchronized GTT mapping. This is obviously not what the user of the API wanted. Eric left a comment indicating a valid concern: if the CPU

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Ignore panel type from OpRegion on SKL"

On Wed, Mar 08, 2017 at 04:53:58PM +0200, Jani Nikula wrote: > On Wed, 08 Mar 2017, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > This reverts commit bb10d4ec3be4b069bfb61c60ca4f708f58f440f1. > > > > Since commit c8ebfad7a063 ("drm/i915:

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

On Mon, Mar 13, 2017 at 04:09:53PM -0700, Manasi Navare wrote: > On Mon, Mar 13, 2017 at 10:53:23PM +0200, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > Apparently some DP sinks are a little nuts and cause HPD to drop > > intermittently

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

Hi Dave, I'm early this week, here are the drm/i915 fixes for -rc3. The majority of them are actually Cc: stable, not bugs introduced this cycle, and almost all of them also have Fixes: annotations. BR, Jani. The following changes since commit 70647f9163aa4fc7090b0d6795d026ebe3897928: Merge

Re: [Intel-gfx] [regression] Re: 4.11-rc0, thinkpad x220: GPU hang

On 06.03.2017 00:01, Pavel Machek wrote: >>> mplayer stopped working after a while. Dmesg says: >>> >>> [ 3000.266533] cdc_ether 2-1.2:1.0 usb0: register 'cdc_ether' at > Now I'm pretty sure it is a regression in v4.11-rc0. Any ideas what to > try? Bisect will be slow and nasty :-(. @Pavel,

[Intel-gfx] [PATCH v3 1/2] drm/i915: Move engine->submit_request selection to a vfunc

It turns out that we may want to restore the original engine->submit_request (and engine->schedule) callbacks from more than just the guc <-> execlists transition. Move this to a vfunc so we can have a common interface. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

[Intel-gfx] [PATCH v3 2/2] drm/i915: Restore engine->submit_request before unwedging

When we wedge the device, we override engine->submit_request with a nop to ensure that all in-flight requests are marked in error. However, igt would like to unwedge the device to test -EIO handling. This requires us to flush those in-flight requests and restore the original

Re: [Intel-gfx] [PATCH 02/24] drm: Extract drm_prime.h

On Mon, Mar 13, 2017 at 12:42:54PM -0400, Sean Paul wrote: > On Wed, Mar 08, 2017 at 03:12:35PM +0100, Daniel Vetter wrote: > > +/** > > + * struct drm_prime_file_private - per-file tracking for PRIME > > + * > > + * This just contains the internal dma_buf and handle caches for > > each > > + *

Re: [Intel-gfx] [PATCH] drm/i915: annote drop_caches debugfs interface with lockdep

On Mon, Mar 13, 2017 at 09:30:41AM +0100, Peter Zijlstra wrote: > On Mon, Mar 13, 2017 at 09:15:17AM +0100, Daniel Vetter wrote: > > On Mon, Mar 13, 2017 at 09:01:57AM +0100, Peter Zijlstra wrote: > > > On Sun, Mar 12, 2017 at 09:53:40PM +0100, Daniel Vetter wrote: > > > > > > > Peter/Ingo, > > >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/vbt: split out defaults that are set when there is no VBT

On Mon, 13 Mar 2017, Manasi Navare wrote: > On Mon, Mar 13, 2017 at 11:55:31AM +0200, Jani Nikula wrote: >> On Sat, 11 Mar 2017, Manasi Navare wrote: >> > On Fri, Mar 10, 2017 at 03:27:58PM +0200, Jani Nikula wrote: >> >> The main thing are

Re: [Intel-gfx] [PATCH] drm/i915: get a runtime PM ref in i915_wedged_set

On Mon, Mar 13, 2017 at 05:26:06PM -0700, Michel Thierry wrote: > At least in bxt (with decoupled mmio), it prevents a warning while > capturing the reg state: > > [ ] WARNING: assert_rpm_wakelock_held.part.4+0x1e/0x20 [i915] > [ ] RPM wakelock ref not held during HW access > [ ] Call

Re: [Intel-gfx] Potential BUG in drm/i915/execlists: Reset RING registers upon resume

That's funny. I have a MacBook Pro 12,1 from late 2015. Hibernate failed for me in 4.9.6 through 4.9.8 (possibly earlier as well, I do no recall) without the patch. The patch you reference fixed my problem and apparently many others based on the bug reports:

Re: [Intel-gfx] Fixes that failed to backport to v4.11-rc1

On Mon, 13 Mar 2017, Chris Wilson wrote: > On Mon, Mar 13, 2017 at 06:14:56PM +0200, Jani Nikula wrote: >> 1f7b847d72c3 ("drm/i915: Disable engine->irq_tasklet around resets") > Done. > >> 370a81fb89cb ("drm/i915: Remove unused function intel_ddi_get_link_dpll()") >

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use new atomic iterator macros in display code

On Mon, Mar 13, 2017 at 12:08:19PM +0100, Maarten Lankhorst wrote: > Op 13-03-17 om 11:15 schreef Daniel Vetter: > > On Thu, Mar 09, 2017 at 03:52:04PM +0100, Maarten Lankhorst wrote: > >> Add a big fat warning in __intel_display_resume that the old state is > >> invalid, and use the correct state

  1   2   >