Re: [Intel-gfx] HDMI audio to support extcon

>-Original Message- >From: Daniel Vetter [mailto:daniel.vet...@ffwll.ch] On Behalf Of Daniel Vetter >Sent: Monday, May 15, 2017 9:49 PM >To: Yang, Libin >Cc: Vetter, Daniel ; Bossart, Pierre-louis louis.boss...@intel.com>;

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: introduce vgt_caps to pvinfo

On 2017.05.12 17:37:56 +0800, Tina Zhang wrote: > vgt_caps is used for guest i915 driver to get the vgpu capabilities from > the device model. VGT_CPAS_FULL_PPGTT is one of the capabilities type to > let guest i915 dirver know that the guest i915 full ppgtt is supported by > device model. > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm: i915: Preserve old FBC status if update with no new planes

== Series Details == Series: drm: i915: Preserve old FBC status if update with no new planes URL : https://patchwork.freedesktop.org/series/24471/ State : success == Summary == Series 24471v1 drm: i915: Preserve old FBC status if update with no new planes

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

On Mon, May 15, 2017 at 4:07 PM, Pandiyan, Dhinakaran < dhinakaran.pandi...@intel.com> wrote: > On Fri, 2017-05-12 at 17:31 -0700, Puthikorn Voravootivat wrote: > > > > > > > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran > > wrote: > > On Thu,

[Intel-gfx] [PATCH] drm: i915: Preserve old FBC status if update with no new planes

If the atomic commit doesn't include any new plane, there is no need to choose a new CRTC for FBC, and the intel_fbc_choose_crtc() will bail out early. Although, if the FBC setup failed beforehand for whatever reason, we don't bail early, but we change the no_fbc_reason to "no suitable CRTC for

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

On 15/05/17 10:41, Michal Wajdeczko wrote: On Mon, May 15, 2017 at 09:35:30AM -0700, Daniele Ceraolo Spurio wrote: We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them

[Intel-gfx] [PATCH] drm/i915: Disable decoupled mmio for GEN9LP

From: Kai Chen The decoupled mmio feature doesn't work as intended by HW team. Enabling it with forcewake will only make debugging efforts more difficult, so let's just simply remove it. Signed-off-by: Kai Chen --- drivers/gpu/drm/i915/i915_pci.c | 1 -

Re: [Intel-gfx] [PATCH v7 9/9] drm/i915: Set PWM divider to match desired frequency in vbt

On Fri, 2017-05-12 at 17:31 -0700, Puthikorn Voravootivat wrote: > > > > On Fri, May 12, 2017 at 5:12 PM, Pandiyan, Dhinakaran > wrote: > On Thu, 2017-05-11 at 16:02 -0700, Puthikorn Voravootivat > wrote: > > Read desired PWM frequency

Re: [Intel-gfx] [PATCH 12/12] drm/i915/skl+: consider max supported plane pixel rate while scaling

On Mon, May 15, 2017 at 02:04:37PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > A display resolution is only supported if it meets all the restrictions > below for Maximum Pipe Pixel Rate. > > The display resolution must fit within the maximum pixel rate

Re: [Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

On Mon, May 15, 2017 at 02:04:36PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > This patch implements new DDB allocation algorithm as per HW team > recommendation. This algo takecare of scenario where we allocate less DDB > for the planes with lower relative

Re: [Intel-gfx] [PATCH 10/12] drm/i915/skl+: use linetime latency if ddb size is not available

On Mon, May 15, 2017 at 02:04:35PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > This patch make changes to use linetime latency if allocated > DDB size during plane watermark calculation is not available, > This is required to implement new DDB allocation

Re: [Intel-gfx] [PATCH 09/12] drm/i915/skl+: Perform wm level calculations in separate function

On Mon, May 15, 2017 at 02:04:34PM +0530, Mahesh Kumar wrote: > Instead of iterating over planes & wm levels in a single function use > skl_compute_wm_level function to interate over WM levels. > Change name of function to skl_compute_wm_levels (Matt). > > These changes are to clean-up WM code &

Re: [Intel-gfx] [PATCH 07/12] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

On Mon, May 15, 2017 at 02:04:32PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > DDB minimum requirement of crtc configuration (cumulative of all the > enabled planes in crtc) may exceed the allocated DDB for crtc/pipe. > This patch make changes to fail the

Re: [Intel-gfx] [PATCH 08/12] drm/i915/skl+: Watermark calculation cleanup

On Mon, May 15, 2017 at 02:04:33PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > This patch cleanup/reorganises the watermark calculation functions. > This patch make use of already available macro > "drm_atomic_crtc_state_for_each_plane_state" to walk through >

Re: [Intel-gfx] [PATCH 05/12] drm/i915/skl: Fail the flip if no FB for WM calculation

On Mon, May 15, 2017 at 02:04:30PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > Fail the flip if no FB is present but plane_state is set as visible. > Above is not a valid combination so instead of continue fail the flip. > > Signed-off-by: Mahesh Kumar

Re: [Intel-gfx] [PATCH 02/12] drm/i915: Add more wrapper for fixed_point_16_16 operations

On Mon, May 15, 2017 at 02:04:27PM +0530, Mahesh Kumar wrote: > From: "Kumar, Mahesh" > > This patch adds few wrapper to perform fixed_point_16_16 operations > mul_round_up_u32_fixed16 : Multiplies u32 and fixed_16_16_t variables > & returns u32

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

On 5/15/2017 2:47 PM, Chris Wilson wrote: On Mon, May 15, 2017 at 10:31:58PM +0100, Chris Wilson wrote: On Mon, May 15, 2017 at 02:20:01PM -0700, Michel Thierry wrote: @@ -2827,21 +2830,34 @@ int i915_gem_reset_prepare_engine(struct intel_engine_cs *engine) if

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev7)

== Series Details == Series: Gen8+ engine-reset (rev7) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v7 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/7/mbox/ fi-bdw-5557u total:278 pass:267 dwarn:0

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

On Mon, May 15, 2017 at 10:31:58PM +0100, Chris Wilson wrote: > On Mon, May 15, 2017 at 02:20:01PM -0700, Michel Thierry wrote: > > @@ -2827,21 +2830,34 @@ int i915_gem_reset_prepare_engine(struct > > intel_engine_cs *engine) > > > > if (engine_stalled(engine)) { > > request =

[Intel-gfx] ✓ Fi.CI.BAT: success for Gen8+ engine-reset (rev5)

== Series Details == Series: Gen8+ engine-reset (rev5) URL : https://patchwork.freedesktop.org/series/21868/ State : success == Summary == Series 21868v5 Gen8+ engine-reset https://patchwork.freedesktop.org/api/1.0/series/21868/revisions/5/mbox/ Test gem_exec_flush: Subgroup

Re: [Intel-gfx] [PATCH 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

On Mon, May 15, 2017 at 02:20:01PM -0700, Michel Thierry wrote: > @@ -2827,21 +2830,34 @@ int i915_gem_reset_prepare_engine(struct > intel_engine_cs *engine) > > if (engine_stalled(engine)) { > request = i915_gem_find_active_request(engine); > - if (request &&

[Intel-gfx] [PATCH 05/20] drm/i915: Cancel reset-engine if we couldn't find an active request

Before reseting an engine, check if there is an active request, and if the _hung_ request has completed. In these two cases, the seqno has moved after hang declaration and we can skip the reset. Also store the active request so that we only search for it once. v2: Check for request completion

[Intel-gfx] [PATCH 03/20] drm/i915: Add support for per engine reset recovery

This change implements support for per-engine reset as an initial, less intrusive hang recovery option to be attempted before falling back to the legacy full GPU reset recovery mode if necessary. This is only supported from Gen8 onwards. Hangchecker determines which engines are hung and invokes

[Intel-gfx] [PATCH 02/20] drm/i915: Modify error handler for per engine hang recovery

This is a preparatory patch which modifies error handler to do per engine hang recovery. The actual patch which implements this sequence follows later in the series. The aim is to prepare existing recovery function to adapt to this new function where applicable (which fails at this point because

Re: [Intel-gfx] [PATCH 1/2] drm/dp: start a DPCD based DP sink/branch device quirk database

On Thu, 2017-05-11 at 12:57 +0300, Jani Nikula wrote: > Face the fact, there are Display Port sink and branch devices out there > in the wild that don't follow the Display Port specifications, or they > have bugs, or just otherwise require special treatment. Start a common > quirk database the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Detect USB-C specific dongles before reducing M and N

On Thu, 2017-05-11 at 09:12 -0700, Clint Taylor wrote: > > On 05/11/2017 02:57 AM, Jani Nikula wrote: > > From: Clint Taylor > > > > The Analogix 7737 DP to HDMI converter requires reduced M and N values > > when to operate correctly at HBR2. Detect this IC by its OUI

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move engine HWS setup into dedicated function

On Mon, May 15, 2017 at 07:08:00PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Move engine HWS setup into dedicated function > URL : https://patchwork.freedesktop.org/series/24462/ > State : success > > == Summary == > > Series 24462v1 drm/i915: Move engine HWS setup

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Move engine HWS setup into dedicated function

== Series Details == Series: drm/i915: Move engine HWS setup into dedicated function URL : https://patchwork.freedesktop.org/series/24462/ State : success == Summary == Series 24462v1 drm/i915: Move engine HWS setup into dedicated function

[Intel-gfx] [PATCH] drm/i915: Move engine HWS setup into dedicated function

This will make future patches simpler. Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Oscar Mateo --- drivers/gpu/drm/i915/intel_lrc.c | 21 + 1 file changed, 13 insertions(+), 8

[Intel-gfx] New "RPM wakelock ref not held during HW access" in 4.12-rc1 ?

Hi, I'm seeing this on suspend/resume on a GPD-win, cherrytrail z8700 device: [ 75.514651] RPM wakelock ref not held during HW access [ 75.514827] [ cut here ] [ 75.515025] WARNING: CPU: 2 PID: 1832 at drivers/gpu/drm/i915/intel_drv.h:1780

Re: [Intel-gfx] [RFC PATCH 6/6] drm/i915/gvt: support QEMU getting the dmabuf

On Mon, 15 May 2017 03:36:50 + "Chen, Xiaoguang" wrote: > Hi Alex and Gerd, > > >-Original Message- > >From: Alex Williamson [mailto:alex.william...@redhat.com] > >Sent: Saturday, May 13, 2017 12:38 AM > >To: Gerd Hoffmann > >Cc: Chen,

Re: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

> -Original Message- > From: Nikula, Jani > Sent: Monday, May 15, 2017 9:19 PM > To: Ville Syrjälä ; Chauhan, Madhav > > Cc: intel-gfx@lists.freedesktop.org; Conselvan De Oliveira, Ander > ;

Re: [Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

On Mon, May 15, 2017 at 09:35:30AM -0700, Daniele Ceraolo Spurio wrote: > We're currently deleting the GuC logs if the FW fails to load, but those > are still useful to understand why the loading failed. Keeping the > object around allows us to access them after driver load is completed. > > v2:

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Remove action status and statistics from debugfs (rev2)

== Series Details == Series: drm/i915/guc: Remove action status and statistics from debugfs (rev2) URL : https://patchwork.freedesktop.org/series/24453/ State : success == Summary == Series 24453v2 drm/i915/guc: Remove action status and statistics from debugfs

[Intel-gfx] [PATCH v2] drm/i915/guc: Remove action status and statistics from debugfs

Usefulness of these stats was over-advertised. v2: remove duplicated engine stats (Chris) Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: capture GuC logs if FW fails to load (rev4)

== Series Details == Series: drm/i915/guc: capture GuC logs if FW fails to load (rev4) URL : https://patchwork.freedesktop.org/series/23982/ State : success == Summary == Series 23982v4 drm/i915/guc: capture GuC logs if FW fails to load

[Intel-gfx] [PATCH v4] drm/i915/guc: capture GuC logs if FW fails to load

We're currently deleting the GuC logs if the FW fails to load, but those are still useful to understand why the loading failed. Keeping the object around allows us to access them after driver load is completed. v2: keep the object around instead of using kernel memory (chris) don't store the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915/guc: Remove action status and statistics from debugfs

== Series Details == Series: drm/i915/guc: Remove action status and statistics from debugfs URL : https://patchwork.freedesktop.org/series/24453/ State : success == Summary == Series 24453v1 drm/i915/guc: Remove action status and statistics from debugfs

Re: [Intel-gfx] [PATCH] drm/i915/guc: Remove action status and statistics from debugfs

On Mon, May 15, 2017 at 03:52:07PM +, Michal Wajdeczko wrote: > Usefulness of these stats were over-advertised. > > Suggested-by: Chris Wilson > Signed-off-by: Michal Wajdeczko > Cc: Chris Wilson > Cc: Daniele

[Intel-gfx] [PATCH] drm/i915/guc: Remove action status and statistics from debugfs

Usefulness of these stats were over-advertised. Suggested-by: Chris Wilson Signed-off-by: Michal Wajdeczko Cc: Chris Wilson Cc: Daniele Ceraolo Spurio ---

Re: [Intel-gfx] [PATCH 2/2] drm/i915/glk: Enable cold boot for GLK DSI

On Tue, 09 May 2017, Ville Syrjälä wrote: > On Tue, May 09, 2017 at 06:59:25PM +0530, Madhav Chauhan wrote: >> As per BSEPC, if device ready bit is '0' in enable IO sequence >> then its a cold boot/reset scenario eg: S3/S4 resume. In these >> conditions we need to

Re: [Intel-gfx] [PATCH 1/2] drm/i915/glk: Calculate high/low switch count for GLK

On Tue, 09 May 2017, Madhav Chauhan wrote: > As per BSPEC, high/low switch count to be programmed in > terms of byteclock using exit_zero_count and prep_count. > For Geminilake exit/prep counts are already calculated > in terms of byteclock. This patch calculates

Re: [Intel-gfx] [PATCH 2/2] drm/dp: Wait up all outstanding tx waiters

On Mon, 15 May 2017, Daniel Vetter wrote: > On Mon, May 15, 2017 at 03:33:12PM +0300, Ville Syrjälä wrote: >> On Mon, May 15, 2017 at 02:04:43PM +0200, Daniel Vetter wrote: >> > On Sat, May 13, 2017 at 11:52:01AM +0100, Chris Wilson wrote: >> > > As we can have multiple tx in the

Re: [Intel-gfx] [PATCH v3] drm/i915: Split execlist priority queue into rbtree + linked list

On Mon, May 15, 2017 at 02:29:50PM +0100, Chris Wilson wrote: > All the requests at the same priority are executed in FIFO order. They > do not need to be stored in the rbtree themselves, as they are a simple > list within a level. If we move the requests at one priority into a list, > we can then

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

On Mon, May 15, 2017 at 04:00:55PM +0200, Daniel Vetter wrote: > On Fri, May 12, 2017 at 02:17:29PM +0100, Chris Wilson wrote: > > The ABI for testing whether the device is wedged before use is > > gem_throttle(). This is encapsulated into igt_require_gem() and any test > > that depends upon

Re: [Intel-gfx] [PATCH igt] intel-ci: Add gem_exec_reloc/basic-range to BAT

On Thu, May 11, 2017 at 12:13:44AM +0100, Chris Wilson wrote: > We have no coverage of sign-extended relocations in BAT, so provide > some. > > Signed-off-by: Chris Wilson > Cc: Petri Latvala There's a metric ton of simple abi checks we should

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/i915: Remove kref from i915_sw_fence (rev4)

== Series Details == Series: series starting with [01/12] drm/i915: Remove kref from i915_sw_fence (rev4) URL : https://patchwork.freedesktop.org/series/24314/ State : success == Summary == Series 24314v4 Series without cover letter

Re: [Intel-gfx] [PATCH i-g-t] tests/initial_state: Add a test to capture the state of the GPU

On Fri, May 12, 2017 at 02:17:29PM +0100, Chris Wilson wrote: > The ABI for testing whether the device is wedged before use is > gem_throttle(). This is encapsulated into igt_require_gem() and any test > that depends upon execution on the GPU should be checking for GEM first. > > This test should

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix hw state verifier access to crtc->state.

On Thu, May 11, 2017 at 11:41:22AM +0200, Maarten Lankhorst wrote: > Op 11-05-17 om 11:23 schreef Daniel Vetter: > > On Thu, May 11, 2017 at 10:28:43AM +0200, Maarten Lankhorst wrote: > >> We shouldn't inspect crtc->state, instead grab the crtc state. > >> At this point the hw state verifier

Re: [Intel-gfx] HDMI audio to support extcon

Adding dri-devel. On Mon, May 15, 2017 at 08:16:44AM +, Yang, Libin wrote: > Hi Daniel, > > >-Original Message- > >From: Vetter, Daniel > >Sent: Friday, May 12, 2017 2:06 AM > >To: Bossart, Pierre-louis ; Yang, Libin > >;

[Intel-gfx] Unable to compile xf86-video-intel-2.99.917

Requesting advice: Unable to use the 'intel graphics update tool' due to running ubuntu 17.04, NUC715BNH (intel HD640) Able to compile all options in the stack, except xf86-video-intel-2.99.917, whereby make fails with: i810_video.c: In function 'I810BlockHandler': i810_video.c:1149:6: error:

Re: [Intel-gfx] [PATCH] drm/i915: Fixup 64bit divides in timelines selftest

On Mon, May 15, 2017 at 10:54:10AM +0100, Tvrtko Ursulin wrote: > > On 13/05/2017 10:41, Chris Wilson wrote: > >Some 64b divides snuck in when doing the prng timing compensation. > > > >Fixes: 4797948071f6 ("drm/i915: Squash repeated awaits on the same fence") > >Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 2/2] drm/dp: Wait up all outstanding tx waiters

On Mon, May 15, 2017 at 03:33:12PM +0300, Ville Syrjälä wrote: > On Mon, May 15, 2017 at 02:04:43PM +0200, Daniel Vetter wrote: > > On Sat, May 13, 2017 at 11:52:01AM +0100, Chris Wilson wrote: > > > As we can have multiple tx in the queue, with individual waiters, make > > > sure that all are

[Intel-gfx] [PATCH v3] drm/i915: Split execlist priority queue into rbtree + linked list

All the requests at the same priority are executed in FIFO order. They do not need to be stored in the rbtree themselves, as they are a simple list within a level. If we move the requests at one priority into a list, we can then reduce the rbtree to the set of priorities. This should keep the

Re: [Intel-gfx] [PATCH v2] drm/i915: Split execlist priority queue into rbtree + linked list

On Mon, May 15, 2017 at 01:56:16PM +0100, Chris Wilson wrote: > -static bool insert_request(struct i915_priotree *pt, struct rb_root *root) > +static bool > +insert_request(struct intel_engine_cs *engine, > +struct i915_priotree *pt, > +int prio) > { > - struct rb_node

[Intel-gfx] [PATCH v2] drm/i915: Split execlist priority queue into rbtree + linked list

All the requests at the same priority are executed in FIFO order. They do not need to be stored in the rbtree themselves, as they are a simple list within a level. If we move the requests at one priority into a list, we can then reduce the rbtree to the set of priorities. This should keep the

[Intel-gfx] Fixes that failed to backport to v4.12-rc1

Continuing [1] for v4.12-rc1 The following commits have been marked as Cc: stable or fixing something in v4.12-rc1 or earlier, but failed to cherry-pick to drm-intel-fixes. Please see if they are worth backporting, and please do so if they are. BR, Jani. e6ba9992de6c ("drm/i915: Differentiate

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

On Mon, May 15, 2017 at 01:06:47PM +0100, Tvrtko Ursulin wrote: > > On 15/05/2017 11:41, Chris Wilson wrote: > >On Mon, May 15, 2017 at 11:14:32AM +0100, Tvrtko Ursulin wrote: > >> > >>On 12/05/2017 23:16, Chris Wilson wrote: > >>>Currently the timer is armed for 1ms after the first use and is

Re: [Intel-gfx] [PATCH 2/2] drm/dp: Wait up all outstanding tx waiters

On Mon, May 15, 2017 at 02:04:43PM +0200, Daniel Vetter wrote: > On Sat, May 13, 2017 at 11:52:01AM +0100, Chris Wilson wrote: > > As we can have multiple tx in the queue, with individual waiters, make > > sure that all are woken when any state changes (so that we are sure the > > right owner of

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Split execlist priority queue into rbtree + linked list

On Mon, May 15, 2017 at 12:45:16PM +0100, Tvrtko Ursulin wrote: > > On 11/05/2017 20:59, Chris Wilson wrote: > >+if (prio == I915_PRIORITY_NORMAL) { > >+p = >default_priolist; > >+} else { > >+p = kmalloc(sizeof(*p), GFP_ATOMIC); > > I am back to being nervous

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

On 15/05/2017 11:41, Chris Wilson wrote: On Mon, May 15, 2017 at 11:14:32AM +0100, Tvrtko Ursulin wrote: On 12/05/2017 23:16, Chris Wilson wrote: Currently the timer is armed for 1ms after the first use and is killed immediately, dropping the forcewake as early as possible. However, for

Re: [Intel-gfx] [PATCH 2/2] drm/dp: Wait up all outstanding tx waiters

On Sat, May 13, 2017 at 11:52:01AM +0100, Chris Wilson wrote: > As we can have multiple tx in the queue, with individual waiters, make > sure that all are woken when any state changes (so that we are sure the > right owner of the txmsg is woken). > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 1/2] drm/dp: Read the tx msg state once after checking for an event

On Sat, May 13, 2017 at 11:52:00AM +0100, Chris Wilson wrote: > Both as an exercise to document that we are reading the state outside of > the appropriate mutex and to ensure that we only read the value once > before the multiple comparisons, use READ_ONCE. I think gcc could also opt to

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

On Mon, May 15, 2017 at 02:20:24PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > @@ -520,8 +527,10 @@ static void __intel_uncore_forcewake_put(struct > > drm_i915_private *dev_priv, > > if (WARN_ON(domain->wake_count == 0)) > >

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

Hey On Mon, May 15, 2017 at 1:42 PM, Chris Wilson wrote: > On Mon, May 15, 2017 at 12:50:04PM +0200, David Herrmann wrote: >> Hey >> >> On Mon, May 15, 2017 at 12:10 PM, Chris Wilson >> wrote: >> > Constructing the name takes the majority of

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [01/12] drm/i915: Remove kref from i915_sw_fence (rev2)

== Series Details == Series: series starting with [01/12] drm/i915: Remove kref from i915_sw_fence (rev2) URL : https://patchwork.freedesktop.org/series/24314/ State : success == Summary == Series 24314v2 Series without cover letter

Re: [Intel-gfx] [PATCH 10/12] drm/i915/execlists: Reduce lock contention between schedule/submit_request

On 15/05/2017 11:55, Chris Wilson wrote: On Mon, May 15, 2017 at 11:51:52AM +0100, Tvrtko Ursulin wrote: On 11/05/2017 20:59, Chris Wilson wrote: If we do not require to perform priority bumping, and we haven't yet submitted the request, we can update its priority in situ and skip acquiring

Re: [Intel-gfx] [PATCH 08/12] drm/i915: Split execlist priority queue into rbtree + linked list

On 11/05/2017 20:59, Chris Wilson wrote: All the requests at the same priority are executed in FIFO order. They do not need to be stored in the rbtree themselves, as they are a simple list within a level. If we move the requests at one priority into a list, we can then reduce the rbtree to the

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

On Mon, May 15, 2017 at 12:50:04PM +0200, David Herrmann wrote: > Hey > > On Mon, May 15, 2017 at 12:10 PM, Chris Wilson > wrote: > > Constructing the name takes the majority of the time for allocating a > > sync_file to wrap a fence, and the name is very rarely used

Re: [Intel-gfx] [GIT PULL] GVT-g fixes for 4.12-rc

On Thu, 11 May 2017, Zhenyu Wang wrote: > Hi, > > Here's current gvt fixes for 4.12-rc kernel. Include vGPU scheduler > regression fix from Ping, vGPU hang fix to bypass in-context mmio > restore from Chuanxiao, and one typo fix. Pulled to drm-intel-fixes, thanks. BR,

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-buf/sync-file: Defer creation of sync_file->name (rev3)

== Series Details == Series: dma-buf/sync-file: Defer creation of sync_file->name (rev3) URL : https://patchwork.freedesktop.org/series/24353/ State : success == Summary == Series 24353v3 dma-buf/sync-file: Defer creation of sync_file->name

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

Chris Wilson writes: > Currently the timer is armed for 1ms after the first use and is killed > immediately, dropping the forcewake as early as possible. However, for > very frequent operations the forcewake dance has a large impact on > latency and keeping the timer

[Intel-gfx] ✓ Fi.CI.BAT: success for Implement DDB algorithm and WM cleanup (rev7)

== Series Details == Series: Implement DDB algorithm and WM cleanup (rev7) URL : https://patchwork.freedesktop.org/series/20376/ State : success == Summary == Series 20376v7 Implement DDB algorithm and WM cleanup https://patchwork.freedesktop.org/api/1.0/series/20376/revisions/7/mbox/ Test

Re: [Intel-gfx] [PATCH v2 0/4] Enable guest linux i915 full ppgtt functionality

Remember to add Cc's for people who have previously commented on the patches, and initially try to capture people who've been involved with virtualization code reviews, to shorten the time it takes to notice the series. I went through the i915 portion and suggested reordering the series a bit,

Re: [Intel-gfx] [PATCH v2 4/4] drm/i915: enable guest full ppgtt when device model supports

On pe, 2017-05-12 at 17:37 +0800, Tina Zhang wrote: > Add full ppgtt capability check in guest i915 driver and enable the full > ppgtt in guest only when device mode supports. > > Changes since v1: > - Use u32 instead of uint32_t. (Joonas) > - Rewrite the vgpu full ppgtt capability checking

Re: [Intel-gfx] [PATCH 10/12] drm/i915/execlists: Reduce lock contention between schedule/submit_request

On Mon, May 15, 2017 at 11:51:52AM +0100, Tvrtko Ursulin wrote: > > On 11/05/2017 20:59, Chris Wilson wrote: > >If we do not require to perform priority bumping, and we haven't yet > >submitted the request, we can update its priority in situ and skip > >acquiring the engine locks -- thus avoiding

[Intel-gfx] [PATCH v2] drm/i915: Import the kfence selftests for i915_sw_fence

A long time ago, I wrote some selftests for the struct kfence idea. Now that we have infrastructure in i915/igt for running kselftests, include some for i915_sw_fence. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/Kconfig.debug | 12 +

Re: [Intel-gfx] [PATCH 10/12] drm/i915/execlists: Reduce lock contention between schedule/submit_request

On 11/05/2017 20:59, Chris Wilson wrote: If we do not require to perform priority bumping, and we haven't yet submitted the request, we can update its priority in situ and skip acquiring the engine locks -- thus avoiding any contention between us and submit/execute. v2: Remove the stack

Re: [Intel-gfx] [PATCH v2 1/4] drm/i915/gvt: reorder the shadow ppgtt update process by adding entry first

On pe, 2017-05-12 at 17:37 +0800, Tina Zhang wrote: > Guest i915 driver may update the ppgtt table just before this workload > is going to be submitted to the hardware by device model. This case > wasn't handled well by device model before, due to the small time > window between removing old ppgtt

Re: [Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

Hey On Mon, May 15, 2017 at 12:10 PM, Chris Wilson wrote: > Constructing the name takes the majority of the time for allocating a > sync_file to wrap a fence, and the name is very rarely used (only via > the sync_file status user interface). To reduce the impact on the

Re: [Intel-gfx] [PATCH v2 3/4] drm/i915/gvt: provide full ppgtt capability for guest

On pe, 2017-05-12 at 17:37 +0800, Tina Zhang wrote: > This patch is to provide full ppgtt capability for guest i915 driver. > > Changes since v1: > - Move VGT_CAPS_FULL_PPGTT introduction to patch 2/4. (Joonas) > > Signed-off-by: Tina Zhang I think this should get

Re: [Intel-gfx] [PATCH v2 2/4] drm/i915: introduce vgt_caps to pvinfo

On pe, 2017-05-12 at 17:37 +0800, Tina Zhang wrote: > vgt_caps is used for guest i915 driver to get the vgpu capabilities from > the device model. VGT_CPAS_FULL_PPGTT is one of the capabilities type to > let guest i915 dirver know that the guest i915 full ppgtt is supported by > device model. > >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Compute the fw_domain id from the mask

On Mon, May 15, 2017 at 11:18:11AM +0100, Tvrtko Ursulin wrote: > > On 12/05/2017 14:53, Chris Wilson wrote: > >Storing both the mask and the id is redundant as we can trivially > >compute one from the other. As the mask is more frequently used, remove > >the id. > > > >Signed-off-by: Chris

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

On Mon, May 15, 2017 at 11:14:32AM +0100, Tvrtko Ursulin wrote: > > On 12/05/2017 23:16, Chris Wilson wrote: > >Currently the timer is armed for 1ms after the first use and is killed > >immediately, dropping the forcewake as early as possible. However, for > > Correct for implicit grabs, but for

Re: [Intel-gfx] [PATCH 12/12] drm/i915: Don't force serialisation on marking up execlists irq posted

On 11/05/2017 20:59, Chris Wilson wrote: Since we coordinate with the execlists tasklet using a locked schedule operation that ensures that after we set the engine->irq_posted we always have an invocation of the tasklet, we do not need to use a locked operation to set the engine->irq_posted

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Remove defunct trace points

On 12/05/2017 21:21, Chris Wilson wrote: trace_i915_gem_evict_everything and trace_i915_gem_ring_flush stopped being used when their parent functions were removed. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_trace.h | 72

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix some tracepoints to capture full 64b

On 12/05/2017 21:21, Chris Wilson wrote: The tracepoints need some tlc, in particular we've neglected to update them for the 64b era. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/i915_trace.h | 42 +++ 1 file changed, 21

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Compute the fw_domain id from the mask

On 12/05/2017 14:53, Chris Wilson wrote: Storing both the mask and the id is redundant as we can trivially compute one from the other. As the mask is more frequently used, remove the id. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc:

Re: [Intel-gfx] [PATCH v2] drm/i915: Keep the forcewake timer alive for 1ms past the most recent use

On 12/05/2017 23:16, Chris Wilson wrote: Currently the timer is armed for 1ms after the first use and is killed immediately, dropping the forcewake as early as possible. However, for Correct for implicit grabs, but for explicit it is 1-2ms after the last use. very frequent operations the

[Intel-gfx] [PATCH v4] dma-buf/sync-file: Defer creation of sync_file->name

Constructing the name takes the majority of the time for allocating a sync_file to wrap a fence, and the name is very rarely used (only via the sync_file status user interface). To reduce the impact on the common path (that of creating sync_file to pass around), defer the construction of the name

Re: [Intel-gfx] [PATCH] drm/i915: Fixup 64bit divides in timelines selftest

On 13/05/2017 10:41, Chris Wilson wrote: Some 64b divides snuck in when doing the prng timing compensation. Fixes: 4797948071f6 ("drm/i915: Squash repeated awaits on the same fence") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: Joonas

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations

On Mon, 15 May 2017, Benjamin Tissoires wrote: > On Mon, May 15, 2017 at 10:42 AM, Jani Nikula > wrote: >> On Mon, 15 May 2017, Benjamin Tissoires wrote: >>> I'll answer everything in the other thread,

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations

On Mon, May 15, 2017 at 10:42 AM, Jani Nikula wrote: > On Mon, 15 May 2017, Benjamin Tissoires wrote: >> I'll answer everything in the other thread, where there are slightly >> more other points raised: https://lkml.org/lkml/2017/5/15/10

Re: [Intel-gfx] [PATCH v3] dma-buf/sync-file: Defer creation of sync_file->name

On Mon, May 15, 2017 at 09:01:29AM +0200, Daniel Vetter wrote: > On Fri, May 12, 2017 at 07:55:42PM +0100, Chris Wilson wrote: > > Constructing the name takes the majority of the time for allocating a > > sync_file to wrap a fence, and the name is very rarely used (only via > > the sync_file

Re: [Intel-gfx] [PATCH v2 5/5] ACPI: button: Obselete acpi_lid_open() invocations

On Mon, 15 May 2017, Benjamin Tissoires wrote: > I'll answer everything in the other thread, where there are slightly > more other points raised: https://lkml.org/lkml/2017/5/15/10 If you are discussing changes impacting i915, please keep intel-gfx list in the loop.

[Intel-gfx] [PATCH 10/12] drm/i915/skl+: use linetime latency if ddb size is not available

From: "Kumar, Mahesh" This patch make changes to use linetime latency if allocated DDB size during plane watermark calculation is not available, This is required to implement new DDB allocation algorithm. In New Algorithm DDB is allocated based on WM values, because of

[Intel-gfx] [PATCH 09/12] drm/i915/skl+: Perform wm level calculations in separate function

Instead of iterating over planes & wm levels in a single function use skl_compute_wm_level function to interate over WM levels. Change name of function to skl_compute_wm_levels (Matt). These changes are to clean-up WM code & will help in making only new ddb algorithm related changes in later

[Intel-gfx] [PATCH 11/12] drm/i915/skl: New ddb allocation algorithm

From: "Kumar, Mahesh" This patch implements new DDB allocation algorithm as per HW team recommendation. This algo takecare of scenario where we allocate less DDB for the planes with lower relative pixel rate, but they require more DDB to work. It also takes care of

[Intel-gfx] [PATCH 08/12] drm/i915/skl+: Watermark calculation cleanup

From: "Kumar, Mahesh" This patch cleanup/reorganises the watermark calculation functions. This patch make use of already available macro "drm_atomic_crtc_state_for_each_plane_state" to walk through plane_state list instead of calculating plane_state in function itself.

[Intel-gfx] [PATCH 07/12] drm/i915/skl+: Fail the flip if ddb min requirement exceeds pipe allocation

From: "Kumar, Mahesh" DDB minimum requirement of crtc configuration (cumulative of all the enabled planes in crtc) may exceed the allocated DDB for crtc/pipe. This patch make changes to fail the flip/ioctl if minimum requirement for pipe exceeds the total ddb allocated

  1   2   >