Re: [Intel-gfx] [PATCH] drm/i915: Only grab correct forcewake for the engine with execlists

On Wed, Apr 06, 2016 at 03:49:55PM +0100, Tvrtko Ursulin wrote: > +static const i915_reg_t gen9_shadowed_regs[] = { > + RING_TAIL(RENDER_RING_BASE), > + RING_TAIL(GEN6_BSD_RING_BASE), > + RING_TAIL(VEBOX_RING_BASE), > + RING_TAIL(BLT_RING_BASE), It occurs to me that we will never

[Intel-gfx] [PATCH] drm/i915/dp/mst: Fix MST logic in intel_dp_long_pulse()

In commit 7d23e3c3 ("drm/i915: Cleaning up intel_dp_hpd_pulse") some much needed clean-up was done, but unfortunately part of the change broke DP MST. The real issue was setting the connector state to disconnected in the MST case, which is good, but the code then (after a goto) checks if the

[Intel-gfx] [PATCH] DO NOT MERGE: drm/i915: Enable GuC submission, where supported

From: Dave Gordon DO NOT MERGE: This patch is being sent for CI testing only v5: Rebased Signed-off-by: Dave Gordon Acked-by: Tom O'Rourke --- drivers/gpu/drm/i915/i915_params.c | 4 ++-- 1 file changed, 2

[Intel-gfx] [4.6-rcX regression] closing and opening LID on thinkpad x200s freezes X

Hi, after updating to 4.6-rcX (where X is 1 or 2, doesn't really matter) on thinkpad x200s notebook with 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) closing and opening the lid freezes the computer completely

Re: [Intel-gfx] [PATCH 18/25] drm/i915/slpc: Add slpc support for max/min freq

On 06/04/16 22:24, tom.orou...@intel.com wrote: From: Tom O'Rourke Update sysfs and debugfs functions to set SLPC parameters when setting max/min frequency. v2: Update for SLPC 2015.2.4 (params for both slice and unslice) Replace HAS_SLPC with intel_slpc_active()

[Intel-gfx] [PATCH 05/25] drm/i915/slpc: Use intel_slpc_* functions if supported

From: Tom O'Rourke On platforms with SLPC support: call intel_slpc_*() functions from corresponding intel_*_gt_powersave() functions; and do not use rps functions. v2: return void instead of ignored error code (Paulo) enable/disable RC6 in SLPC flows (Sagar)

[Intel-gfx] [PATCH 16/25] drm/i915/slpc: Add slpc_status enum values

From: Tom O'Rourke Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_slpc.h | 27 +++ 1 file changed, 27 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_slpc.h b/drivers/gpu/drm/i915/intel_slpc.h index

[Intel-gfx] [PATCH 12/25] drm/i915/slpc: Send shutdown event

From: Tom O'Rourke Send SLPC shutdown event during disable, suspend, and reset operations. Sending shutdown event while already shutdown is OK. v2: return void instead of ignored error code (Paulo) Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 08/25] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

From: Tom O'Rourke SLPC shared data is used to pass information to/from SLPC firmware. For Skylake, platform sku type and slice count are identified from device id and fuse values. Support for other platforms needs to be added. v2: Update for SLPC interface version

[Intel-gfx] [PATCH 23/25] DO NOT MERGE: drm/i915: resize the GuC WOPCM for rc6

From: Peter Antoine This patch resizes the GuC WOPCM to so that the GuC and the RC6 memory spaces do not overlap. DO NOT MERGE: This patch is expected as part of another series and is included for convenience in testing this series. Issue:

[Intel-gfx] [PATCH 22/25] DO NOT MERGE: drm/i915/bxt: Add Broxton to guc loader

From: Tom O'Rourke This patch is expected as part of another series and is included for convenience in testing this series. Do not merge unless Broxton guc v5 firmware is available. Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 02/25] drm/i915/slpc: Add has_slpc capability flag

From: Tom O'Rourke Add has_slpc capablity flag to indicate GuC firmware supports single loop power control (SLPC). SLPC is a replacement for some host-based power management features. Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 01/25] drm/i915/slpc: Expose guc functions for use with SLPC

From: Tom O'Rourke Expose host2guc_action for use by SLPC in intel_slpc.c. Expose functions to allocate and release objects used by GuC to be used for SLPC shared memory object. Signed-off-by: Tom O'Rourke ---

[Intel-gfx] [PATCH 19/25] drm/i915/slpc: Add enable/disable debugfs for slpc

From: Tom O'Rourke Adds debugfs hooks for each slpc task. The enable/disable debugfs files are i915_slpc_gtperf, i915_slpc_balancer, and i915_slpc_dcc. Each of these can take the values: "default", "enabled", or "disabled" v2: update for SLPC v2015.2.4 dfps and

[Intel-gfx] [PATCH 09/25] drm/i915/slpc: Setup rps frequency values during SLPC init

From: Tom O'Rourke v2: Add mutex lock/unlock Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_drv.h | 1 + drivers/gpu/drm/i915/intel_pm.c | 2 +- drivers/gpu/drm/i915/intel_slpc.c | 5 + 3 files changed, 7 insertions(+), 1

[Intel-gfx] [PATCH 24/25] DO NOT MERGE: drm/i915: Enable GuC submission, where supported

From: Dave Gordon DO NOT MERGE: This patch is added for convenience in reviewing SLPC patch series. This patch should be merged as part of a separate series to enable guc submission by default. v5: Rebased Signed-off-by: Dave Gordon

[Intel-gfx] [PATCH 21/25] drm/i915/slpc: Add i915_slpc_info to debugfs

From: Tom O'Rourke i915_slpc_info shows the contents of SLPC shared data parsed into text format. v2: reformat slpc info (Radek) squashed query task state info in slpc info, kunmap before seq_print (Paulo) return void instead of ignored return value (Paulo)

[Intel-gfx] [PATCH 11/25] drm/i915/slpc: Send reset event

From: Tom O'Rourke Add host2guc SLPC reset event and send reset event during enable. v2: extract host2guc_slpc to handle slpc status code coding style changes (Paulo) Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_slpc.c | 33

[Intel-gfx] [PATCH 15/25] drm/i915/slpc: Notification of Refresh Rate change

From: Sagar Arun Kamble This patch will inform GuC SLPC about changes in the refresh rate due to Seamless DRRS. Refresh rate changes due to Static DRRS will be notified via commit path. v2: Rebased on previous changed patch and printed error message if H2G action

[Intel-gfx] [PATCH 03/25] drm/i915/slpc: Add slpc_version_check

From: Tom O'Rourke The SLPC interface has changed and could continue to change. Only GuC versions known to be compatible are supported here. On Skylake, GuC firmware v6 is supported. Other platforms and versions can be added here later. This patch also adds has_slpc

[Intel-gfx] [PATCH 25/25] DO NOT MERGE: drm/i915: Enable SLPC, where supported

From: Tom O'Rourke This patch makes SLPC enabled by default on platforms with hardware/firmware support. DO NOT MERGE: This patch is added for convenience in reviewing SLPC patch series. This patch should be merged after validation results show benefits of using SLPC.

[Intel-gfx] [PATCH v3 00/25] Add support for GuC-based SLPC

From: Tom O'Rourke SLPC (Single Loop Power Controller) is a replacement for some host-based power management features. The SLPC implemenation runs in firmware on GuC. This series has been tested with SKL guc firmware version 6.1 and BXT guc version 5.1. The graphics

[Intel-gfx] [PATCH 07/25] drm/i915/slpc: If using SLPC, do not set frequency

From: Tom O'Rourke When frequency requests are made by SLPC, host driver should not attempt to make frequency requests due to potential conflicts. Host-based turbo operations are already avoided when SLPC is used. This change covers other frequency requests such as from

[Intel-gfx] [PATCH 13/25] drm/i915/slpc: Add Display mode event related data structures

From: Sagar Arun Kamble v2: Cleaning up defines for number of pipes and other cosmetic changes. Signed-off-by: Sagar Arun Kamble Acked-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_slpc.h | 29

[Intel-gfx] [PATCH 04/25] drm/i915/slpc: Add enable_slpc module parameter

From: Tom O'Rourke i915.enable_slpc is used to override the default for slpc usage. The expected values are -1=auto, 0=disabled [default], 1=enabled. slpc_enable_sanitize() converts i915.enable_slpc to either 0 or 1. Interpretation of default value is based on

[Intel-gfx] [PATCH 17/25] drm/i915/slpc: Add parameter unset/set/get functions

From: Tom O'Rourke Add slpc_param_id enum values. Add events for setting/unsetting parameters. v2: use host2guc_slpc update slcp_param_id enum values for SLPC 2015.2.4 return void instead of ignored error code (Paulo) Signed-off-by: Tom O'Rourke

[Intel-gfx] [PATCH 14/25] drm/i915/slpc: Notification of Display mode change

From: Sagar Arun Kamble GuC SLPC need to be sent data related to Active pipes, refresh rates, widi pipes, fullscreen pipes related via host to GuC display mode change event. Based on this, SLPC will track FPS on active pipes. This patch defines the event and implements

[Intel-gfx] [PATCH 06/25] drm/i915/slpc: Enable SLPC in guc if supported

From: Tom O'Rourke If slpc enabled, then add enable SLPC flag to guc control parameter during guc load. v2: Use intel_slpc_enabled() (Paulo) Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/intel_guc_loader.c | 3 +++ 1 file changed, 3

[Intel-gfx] [PATCH 18/25] drm/i915/slpc: Add slpc support for max/min freq

From: Tom O'Rourke Update sysfs and debugfs functions to set SLPC parameters when setting max/min frequency. v2: Update for SLPC 2015.2.4 (params for both slice and unslice) Replace HAS_SLPC with intel_slpc_active() (Paulo) Signed-off-by: Tom O'Rourke

[Intel-gfx] [PATCH 20/25] drm/i915/slpc: Add broxton support

From: Tom O'Rourke Adds has_slpc to broxton info and adds broxton to version check. The SLPC interface version 2015.2.4 is found in Broxton Guc v5. Signed-off-by: Tom O'Rourke --- drivers/gpu/drm/i915/i915_drv.c | 1 +

[Intel-gfx] [PATCH 10/25] drm/i915/slpc: Update current requested frequency

From: Tom O'Rourke When SLPC is controlling requested frequency, the rps.cur_freq value is not used to make the frequency request. Before using rps.cur_freq in sysfs or debugfs, read requested frequency from register to get the value most recently requested by SLPC

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly

On Wed, Apr 06, 2016 at 08:22:56PM +0300, Imre Deak wrote: > On ti, 2016-04-05 at 14:55 -0700, Matt Roper wrote: > > On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote: > > > intel_update_max_cdclk() doesn't have a switch case for Broxton, so > > > dev_priv->max_cdclk_freq gets set to

Re: [Intel-gfx] [PATCH 04/16] drm/i915/skl+: Use plane size for relative data rate calculation

On Wed, Apr 06, 2016 at 06:09:00PM +0300, Imre Deak wrote: > On to, 2016-03-31 at 18:46 -0700, Matt Roper wrote: > > From: "Kumar, Mahesh" > > > > Use plane size for relative data rate calculation. don't always use > > pipe source width & height. > > adjust height &

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl+: Use plane size for relative data rate calculation

On Wed, Apr 06, 2016 at 04:06:36PM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/skl+: Use plane size for relative data rate calculation > URL : https://patchwork.freedesktop.org/series/5376/ > State : failure > > == Summary == > > Series 5376v1 drm/i915/skl+: Use plane

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/bxt: Set max cdclk frequency properly

On Wed, Apr 06, 2016 at 08:30:00AM +, Patchwork wrote: > == Series Details == > > Series: drm/i915/bxt: Set max cdclk frequency properly > URL : https://patchwork.freedesktop.org/series/5348/ > State : failure > > == Summary == > > Series 5348v1 drm/i915/bxt: Set max cdclk frequency

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly

On ti, 2016-04-05 at 14:55 -0700, Matt Roper wrote: > On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote: > > intel_update_max_cdclk() doesn't have a switch case for Broxton, so > > dev_priv->max_cdclk_freq gets set to whatever clock frequency we're > > currently running at (e.g., 144 MHz)

Re: [Intel-gfx] [PATCH 1/3] drm/edid: Add drm_edid_get_monitor_name()

On Wed, Apr 06, 2016 at 11:35:44AM +0300, Jani Nikula wrote: > On Tue, 05 Apr 2016, Jim Bride wrote: > > In order to include monitor name information in debugfs > > output we needed to add a function that would extract the > > monitor name from the EDID, and that

Re: [Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3

On 4/6/2016 7:24 PM, Zanoni, Paulo R wrote: Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu: dont want to hijack thread but wanted to point out a possible regression in the previous patches of this series. intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug)

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/skl+: Use plane size for relative data rate calculation

== Series Details == Series: drm/i915/skl+: Use plane size for relative data rate calculation URL : https://patchwork.freedesktop.org/series/5376/ State : failure == Summary == Series 5376v1 drm/i915/skl+: Use plane size for relative data rate calculation

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only grab correct forcewake for the engine with execlists

On Wed, Apr 06, 2016 at 03:29:37PM -, Patchwork wrote: > == Series Details == > > Series: drm/i915: Only grab correct forcewake for the engine with execlists > URL : https://patchwork.freedesktop.org/series/5375/ > State : success > > == Summary == > > Series 5375v1 drm/i915: Only grab

[Intel-gfx] [PATCH RESEND FOR CI] drm/i915/skl+: Use plane size for relative data rate calculation

From: "Kumar, Mahesh" Use plane size for relative data rate calculation. don't always use pipe source width & height. adjust height & width according to rotation. use plane size for watermark calculations also. v2: Address Matt's comments. Use

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Only grab correct forcewake for the engine with execlists

== Series Details == Series: drm/i915: Only grab correct forcewake for the engine with execlists URL : https://patchwork.freedesktop.org/series/5375/ State : success == Summary == Series 5375v1 drm/i915: Only grab correct forcewake for the engine with execlists

Re: [Intel-gfx] [PATCH] drm/i915: Only grab correct forcewake for the engine with execlists

On Wed, Apr 06, 2016 at 03:49:55PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Rather than blindly waking up all forcewake domains on command > submission, we can teach each engine what is (or are) the correct > one to take. > > On platforms with multiple

Re: [Intel-gfx] [PATCH 04/16] drm/i915/skl+: Use plane size for relative data rate calculation

On to, 2016-03-31 at 18:46 -0700, Matt Roper wrote: > From: "Kumar, Mahesh" > > Use plane size for relative data rate calculation. don't always use > pipe source width & height. > adjust height & width according to rotation. > use plane size for watermark calculations

[Intel-gfx] [PATCH] drm/i915: Only grab correct forcewake for the engine with execlists

From: Tvrtko Ursulin Rather than blindly waking up all forcewake domains on command submission, we can teach each engine what is (or are) the correct one to take. On platforms with multiple forcewake domains like VLV, CHV, SKL and BXT, this has the potential of

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/5] drm/i915: Splitting intel_dp_detect

On 04/04/16 12:41, Tvrtko Ursulin wrote: On 04/04/16 12:08, Jani Nikula wrote: On Mon, 04 Apr 2016, Tvrtko Ursulin wrote: On 01/04/16 08:41, Ander Conselvan De Oliveira wrote: On Thu, 2016-03-31 at 12:38 +, Patchwork wrote: == Series Details == Series:

Re: [Intel-gfx] [PATCH 0/4] Enable FBC on SKL, v3

Em Qua, 2016-04-06 às 10:36 +0530, Thulasimani, Sivakumar escreveu: > dont want to hijack thread but wanted to point out a possible > regression  > in the > previous patches of this series. > > intel_fbc_can_choose: returns true for gen 4/5/6/7. (possible bug) How? It will check for

Re: [Intel-gfx] [PATCH v2 9/9] drm/i915: Simplify check for idleness in hangcheck

Chris Wilson writes: > [ text/plain ] > Having fixed the tracking of the engine's last_submitted_seqno, we can > now rely on it for detecting when the engine is idle (and not have to > touch the requests pointer). > > Testcase: igt/gem_exec_whisper > Signed-off-by:

Re: [Intel-gfx] [PATCH v2 8/9] drm/i915: Apply a mb between emitting the request and hangcheck

Chris Wilson writes: > [ text/plain ] > Seal the request and mark it as pending execution before we submit it to > hardware. We assume that the actual submission cannot fail (that > guarantee is provided by preallocating space in the request for the > submission). As we

Re: [Intel-gfx] [PATCH 2/4] drm/i915/fbc: sanitize i915.enable_fbc during FBC init

On Mon, Apr 04, 2016 at 06:17:16PM -0300, Paulo Zanoni wrote: > The DDX driver changes its behavior depending on the value it reads > from i915.enable_fbc, so sanitize the value in order to allow it to > know what's going on. It uses this in order to choose the defaults for > the TearFree option.

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly

On Wed, Apr 06, 2016 at 01:28:25PM +0300, Ville Syrjälä wrote: > On Tue, Apr 05, 2016 at 02:55:51PM -0700, Matt Roper wrote: > > On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote: > > > intel_update_max_cdclk() doesn't have a switch case for Broxton, so > > > dev_priv->max_cdclk_freq gets

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

On 06/04/16 11:05, Chris Wilson wrote: On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote: diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 985f067c1f0e..dc8e1b76c896 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++

Re: [Intel-gfx] [PATCH 12/12] DO_NOT_MERGE: drm/i915: Hack to enable lspcon initialization

Regards Shashank Expecting this patch to enable lspcon bits in VBT: https://lists.freedesktop.org/archives/intel-gfx/2016-March/089541.html FYI, an updated version of that patch has been pushed now. BR, Jani. Thanks Jani, will have a look. Signed-off-by: Shashank Sharma

[Intel-gfx] [PATCH v2 1/9] drm/i915: Include engine->last_submitted_seqno in GPU error state

It's useful to look at the last seqno submitted on a particular engine and compare it against the HWS value to check for irregularities. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v2 9/9] drm/i915: Simplify check for idleness in hangcheck

Having fixed the tracking of the engine's last_submitted_seqno, we can now rely on it for detecting when the engine is idle (and not have to touch the requests pointer). Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH v2 6/9] drm/i915: Reset semaphore page for gen8

An oversight is that when we wrap the seqno, we need to reset the hw semaphore counters to 0. We did this for gen6 and gen7 and forgot to do so for the new implementation required for gen8 (legacy). Signed-off-by: Chris Wilson Cc: Mika Kuoppala

[Intel-gfx] [PATCH v2 4/9] drm/i915: Move the hw semaphore initialisation from GEM to the engine

Since we are setting engine local values that are tied to the hardware, move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() backend, next to where the other hw semaphore registers are written. v2: Make the explanatory comment about always resetting the semaphores to 0

[Intel-gfx] [PATCH v2 3/9] drm/i915: Remove unneeded drm_device pointer from intel_ring_init_seqno()

We only use drm_i915_private within the function, so delete the unneeded drm_device local. Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Joonas Lahtinen Reviewed-by: Joonas Lahtinen

[Intel-gfx] [PATCH v2 7/9] drm/i915: Reset engine->last_submitted_seqno

When we change the current seqno, we also need to remember to reset the last_submitted_seqno for the engine. Testcase: igt/gem_exec_whisper Signed-off-by: Chris Wilson Cc: Mika Kuoppala Cc: Joonas Lahtinen

[Intel-gfx] [PATCH v2 2/9] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno

After the GPU reset and we discard all of the incomplete requests, mark the GPU as having advanced to the last_submitted_seqno (as having completed the requests and ready for fresh work). The impact of this is negligible, as all the requests will be considered completed by this point, it just

[Intel-gfx] [PATCH v2 8/9] drm/i915: Apply a mb between emitting the request and hangcheck

Seal the request and mark it as pending execution before we submit it to hardware. We assume that the actual submission cannot fail (that guarantee is provided by preallocating space in the request for the submission). As we may inspect this state without holding any locks during hangcheck we

[Intel-gfx] [PATCH v2 5/9] drm/i915: Refactor gen8 semaphore offset calculation

We reuse the same calculation into two macros, and I want to add a third user. Time to refactor. Signed-off-by: Chris Wilson --- drivers/gpu/drm/i915/intel_ringbuffer.h | 11 +-- 1 file changed, 5 insertions(+), 6 deletions(-) diff --git

[Intel-gfx] ✗ Fi.CI.BAT: failure for Add USB typeC based DP support for BXT platform (rev4)

== Series Details == Series: Add USB typeC based DP support for BXT platform (rev4) URL : https://patchwork.freedesktop.org/series/1731/ State : failure == Summary == Series 1731v4 Add USB typeC based DP support for BXT platform

Re: [Intel-gfx] [PATCH 12/12] DO_NOT_MERGE: drm/i915: Hack to enable lspcon initialization

On Mon, 04 Apr 2016, Shashank Sharma wrote: > This patch adds a hack to enable lspcon on GEN9 devices. > This should not be merged, and the hack must be replaced > by proper VBT parsing logic. > > Expecting this patch to enable lspcon bits in VBT: >

Re: [Intel-gfx] [PATCH 2/2] drm/i915/BXT: Get pipe conf from the port registers

On Wed, 30 Mar 2016, Ramalingam C wrote: > At BXT DSI, PIPE registers are inactive. So we can't get the > PIPE's mode parameters from them. The possible option is > retriving them from the PORT registers. > > The required changes are added for BXT in intel_dsi_get_config >

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Sharing the pixel_format_from_vbt to whole i915

On Wed, 30 Mar 2016, Ramalingam C wrote: > Shared the function pixel_format_from_vbt for whole display module. > Function declaration is added to intel_dsi.h. > > Signed-off-by: Ramalingam C > --- > drivers/gpu/drm/i915/intel_dsi.h |

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

On 06/04/16 11:05, Chris Wilson wrote: On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote: diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index 985f067c1f0e..dc8e1b76c896 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++

Re: [Intel-gfx] Solving vlv hpd issues by holding power wells?

On Tue, Apr 05, 2016 at 06:01:54PM -0400, Lyude wrote: > Hi. Currently I'm working on a bug in the i915 driver where hotplugging seems > to > break if we power on the machine without any connectors attached: > > https://bugzilla.redhat.com/show_bug.cgi?id=1277863 > > So the main cause of the

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Set invert bit for hpd based on VBT

On Thu, 31 Mar 2016, Shubhangi Shrivastava wrote: > This patch sets the invert bit for hpd detection for each port > based on VBT configuration. Since each AOB can be designed to > depend on invert bit or not, it is expected if an AOB requires > invert bit, the

[Intel-gfx] [PATCHv3 1/4] drm/i915: Make finding unused crtc as a generic function

Looping over the crtc list and finding an unused crtc has other users like upfront link training. Hence move it to a common function to re-use the logic. v3: * Added kernel Doc and removed an invalid comment (Ander) * Rebased on top of latest code which includes locking for state->enable usage.

[Intel-gfx] [PATCHv3 3/4] drm/i915: Update dpll_hw_state if mask is same

Currently, the dpll_hw_state of a particular pll config is not updated if the crtc_mask is non-zero, indicating possibly shared dpll. But for things like upfront link training, dpll_hw_state of a pll config needs to be updated multiple times (for every new link_clock calculation). This patch does

[Intel-gfx] [PATCHv3 2/4] drm/i915: Store the dpll config in crtc_state->shared_dpll

Currently, the required shared dpll is saved in the crtc_state. Similarly, this patch saves the dpll config values also, so that these values (through crtc_state->shared_dpll->config.hw_state) can be used for upfront link training. Signed-off-by: Durgadoss R ---

[Intel-gfx] [PATCHv3 4/4] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable. Sometimes, the type-C cable may limit the bandwidth even if Panel can support more lanes. To address these

[Intel-gfx] [PATCHv3 0/4] Add USB typeC based DP support for BXT platform

This patch series adds upfront link training support to enable USB type C based DP on BXT platform. To support USB type C alternate DP mode, the display driver needs to know the number of lanes required by the DP panel as well as number of lanes that can be supported by the type-C cable.

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

On Wed, Apr 06, 2016 at 10:28:29AM -, Patchwork wrote: > == Series Details == > > Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent > forcewake auto-release timeout across kernel configs > URL : https://patchwork.freedesktop.org/series/5368/ > State : failure > >

Re: [Intel-gfx] [PATCH v2 04/16] drm/i915/gen9: Reset secondary power well requests left on by DMC/KVMR

On Tue, Apr 05, 2016 at 01:26:05PM +0300, Imre Deak wrote: > DMC forces on power well 1 and the misc IO power well by setting the > corresponding request bits both in the BIOS and the DEBUG power well > request registers. This is somewhat unexpected since the firmware should > really just save and

Re: [Intel-gfx] Reviving the LPSS PWM patches

On Tue, Apr 05, 2016 at 09:06:25PM +0200, Lluís Batlle i Rossell wrote: > On Tue, Apr 05, 2016 at 12:39:30PM +0200, Lluís Batlle i Rossell wrote: > > On Tue, Apr 05, 2016 at 12:03:44PM +0530, Kumar, Shobhit wrote: > > > On Thursday 31 March 2016 03:57 PM, Lluís Batlle i Rossell wrote: > > >

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Reset semaphore page for gen8

On ke, 2016-04-06 at 11:10 +0100, Chris Wilson wrote: > On Wed, Apr 06, 2016 at 12:58:43PM +0300, Joonas Lahtinen wrote: > > > > On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > > > > > > An oversight is that when we wrap the seqno, we need to reset the hw > > > semaphore counters to 0.

Re: [Intel-gfx] [PATCH 2/7] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno

On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > After the GPU reset and we discard all of the incomplete requests, mark > the GPU as having advanced to the last_submitted_seqno (as having > completed the requests and ready for fresh work). The impact of this is > negligible, as all the

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Reset engine->last_submitted_seqno

On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > When we change the current seqno, we also need to remember to reset the > last_submitted_seqno for the engine. > > Testcase: igt/gem_exec_whisper > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

== Series Details == Series: series starting with [resend-for-CI,1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs URL : https://patchwork.freedesktop.org/series/5368/ State : failure == Summary == Series 5368v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915/bxt: Set max cdclk frequency properly

On Tue, Apr 05, 2016 at 02:55:51PM -0700, Matt Roper wrote: > On Tue, Apr 05, 2016 at 02:37:19PM -0700, Matt Roper wrote: > > intel_update_max_cdclk() doesn't have a switch case for Broxton, so > > dev_priv->max_cdclk_freq gets set to whatever clock frequency we're > > currently running at (e.g.,

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

== Series Details == Series: drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport URL : https://patchwork.freedesktop.org/series/5367/ State : failure == Summary == Series 5367v1 drm/i915/gen9: implement WaEnableSamplerGPGPUPreemptionSupport

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move the hw semaphore initialisation from GEM to the engine

On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > Since we are setting engine local values that are tied to the hardware, > move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() > backend, next to where the other hw semaphore registers are written. > > Signed-off-by: Chris

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Reset semaphore page for gen8

On Wed, Apr 06, 2016 at 12:58:43PM +0300, Joonas Lahtinen wrote: > On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > > An oversight is that when we wrap the seqno, we need to reset the hw > > semaphore counters to 0. We did this for gen6 and gen7 and forgot to do > > so for the new

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

On Wed, Apr 06, 2016 at 10:49:36AM +0100, Tvrtko Ursulin wrote: > >diff --git a/drivers/gpu/drm/i915/i915_gem.c > >b/drivers/gpu/drm/i915/i915_gem.c > >index 985f067c1f0e..dc8e1b76c896 100644 > >--- a/drivers/gpu/drm/i915/i915_gem.c > >+++ b/drivers/gpu/drm/i915/i915_gem.c > >@@ -2233,7 +2233,10

Re: [Intel-gfx] [PATCH 5/7] drm/i915: Reset semaphore page for gen8

On ke, 2016-04-06 at 00:57 +0100, Chris Wilson wrote: > An oversight is that when we wrap the seqno, we need to reset the hw > semaphore counters to 0. We did this for gen6 and gen7 and forgot to do > so for the new implementation required for gen8 (legacy). > > Signed-off-by: Chris Wilson

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Refactor duplicate object vmap functions

On Wed, Apr 06, 2016 at 10:30:15AM +0100, Tvrtko Ursulin wrote: > > On 05/04/16 13:57, Chris Wilson wrote: > >We now have two implementations for vmapping a whole object, one for > >dma-buf and one for the ringbuffer. If we couple the vmapping into the > >obj->pages lifetime, then we can reuse an

Re: [Intel-gfx] [PATCH 6/6] drm/i915: Avoid allocating a vmap arena for a single page

On 05/04/16 13:57, Chris Wilson wrote: If we want a contiguous mapping of a single page sized object, we can forgo using vmap() and just use a regular kmap(). Note that this is only suitable if the desired pgprot_t is comptabitible. You noticed the spelling already. :) Signed-off-by:

Re: [Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()

On Wed, Apr 06, 2016 at 10:40:19AM +0100, Tvrtko Ursulin wrote: > > On 05/04/16 14:05, Chris Wilson wrote: > >On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote: > >>I have instances where I want to use drm_malloc_ab() but with a custom > >>gfp mask. And with those, where I want a

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Simplify check for idleness in hangcheck

On Wed, Apr 06, 2016 at 12:32:29PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > [ text/plain ] > > Having fixed the tracking of the engine's last_submitted_seqno, we can > > now rely on it for detecting when the engine is idle (and not have to > > touch the

Re: [Intel-gfx] [PATCH 5/6] drm,i915: Introduce drm_malloc_gfp()

On 05/04/16 14:05, Chris Wilson wrote: On Tue, Apr 05, 2016 at 01:57:36PM +0100, Chris Wilson wrote: I have instances where I want to use drm_malloc_ab() but with a custom gfp mask. And with those, where I want a temporary allocation, I want to try a high-order kmalloc() before using a

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Simplify check for idleness in hangcheck

Chris Wilson writes: > [ text/plain ] > Having fixed the tracking of the engine's last_submitted_seqno, we can > now rely on it for detecting when the engine is idle (and not have to > touch the requests pointer). > > Testcase: igt/gem_exec_whisper > Signed-off-by:

[Intel-gfx] [PATCH resend-for-CI 3/3] drm/i915: Do not serialize forcewake acquire across domains

From: Tvrtko Ursulin On platforms with multiple forcewake domains it seems more efficient to request all desired ones and then to wait for acks to avoid needlessly serializing on each domain. v2: Rebase. Signed-off-by: Tvrtko Ursulin

[Intel-gfx] [PATCH resend-for-CI 1/3] drm/i915: Use consistent forcewake auto-release timeout across kernel configs

From: Tvrtko Ursulin Because it is based on jiffies, current implementation releases the forcewake at any time between straight away and between 1ms and 10ms, depending on the kernel configuration (CONFIG_HZ). This is probably not what has been desired, since the

[Intel-gfx] [PATCH resend-for-CI 2/3] drm/i915: Simplify for_each_fw_domain iterators

From: Tvrtko Ursulin As the vast majority of users do not use the domain id variable, we can eliminate it from the iterator and also change the latter using the same principle as was recently done for for_each_engine. For a couple of callers which do need the domain

Re: [Intel-gfx] [PATCH 6/7] drm/i915: Reset engine->last_submitted_seqno

Chris Wilson writes: > [ text/plain ] > When we change the current seqno, we also need to remember to reset the > last_submitted_seqno for the engine. > > Testcase: igt/gem_exec_whisper > Signed-off-by: Chris Wilson > Cc: Mika Kuoppala

Re: [Intel-gfx] [PATCH 3/6] drm/i915: Refactor duplicate object vmap functions

On 05/04/16 13:57, Chris Wilson wrote: We now have two implementations for vmapping a whole object, one for dma-buf and one for the ringbuffer. If we couple the vmapping into the obj->pages lifetime, then we can reuse an obj->vmapping for both and at the same time couple it into the shrinker.

Re: [Intel-gfx] [PATCH 4/7] drm/i915: Move the hw semaphore initialisation from GEM to the engine

Chris Wilson writes: > [ text/plain ] > Since we are setting engine local values that are tied to the hardware, > move it out of i915_gem_init_seqno() into the intel_ring_init_seqno() > backend, next to where the other hw semaphore registers are written. > >

Re: [Intel-gfx] [PATCH 2/7] drm/i915: On GPU reset, set the HWS breadcrumb to the last seqno

Chris Wilson writes: > [ text/plain ] > After the GPU reset and we discard all of the incomplete requests, mark > the GPU as having advanced to the last_submitted_seqno (as having > completed the requests and ready for fresh work). The impact of this is > negligible, as

  1   2   >