[Intel-gfx] ✗ Ro.CI.BAT: failure for x86, build: Set -fno-pic for 32/64-bit kernels (rev2)

== Series Details == Series: x86, build: Set -fno-pic for 32/64-bit kernels (rev2) URL : https://patchwork.freedesktop.org/series/11348/ State : failure == Summary == Series 11348v2 x86, build: Set -fno-pic for 32/64-bit kernels

Re: [Intel-gfx] drm/i915: Check GuC load status for Host to GuC action and SLPC status

On 20/08/16 10:39 AM, Sagar Arun Kamble wrote: Host to GuC actions should not be invoked when GuC isn't loaded hence add early return in i915_guc_action if GuC load status is not SUCCESS. Also, SLPC status has to be linked with GuC load status to make sure SLPC actions get invoked when GuC is

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+

== Series Details == Series: drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+ URL : https://patchwork.freedesktop.org/series/11343/ State : failure == Summary == Series 11343v1 drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: Add DRM_DEBUG_DISPLAY macro for display configuration debug messages

== Series Details == Series: drm: Add DRM_DEBUG_DISPLAY macro for display configuration debug messages URL : https://patchwork.freedesktop.org/series/11345/ State : failure == Summary == Applying: drm: Add DRM_DEBUG_DISPLAY macro for display configuration debug messages Using index info to

[Intel-gfx] 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) v5: Rebase. (Sagar) Signed-off-by: Tom O'Rourke Signed-off-by: Sagar Arun Kamble

[Intel-gfx] drm/i915/slpc: Only Enable GTPERF, Disable DCC, Balancer, IBC, FPS Stall

v2: Updated tasks and frequency post reset. v3: Added DFPS param update for MAX_FPS and FPS Stall. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_debugfs.c | 2 +- drivers/gpu/drm/i915/intel_slpc.c | 29 +

[Intel-gfx] drm/i915/slpc: Keep RP SW Mode enabled while disabling rps

With SLPC, only RP SW Mode control should be left enabled by i915. Else, SLPC requests through through RPNSWREQ will not be granted. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_pm.c | 9 - 1 file changed, 8 insertions(+), 1 deletion(-) diff

[Intel-gfx] 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] 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] drm/i915/slpc: Allocate/Release/Initialize SLPC shared data

From: Tom O'Rourke SLPC shared data is used to pass information to/from SLPC in GuC 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

[Intel-gfx] 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) v5: Removed WARN_ON for checking msb of gtt address of shared gem obj. (ChrisW)

[Intel-gfx] drm/i915: Mark GuC load status as PENDING in i915_drm_resume_early

This will help avoid Host to GuC actions being called till GuC gets loaded during i915_drm_resume. Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_drv.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/gpu/drm/i915/i915_drv.c

[Intel-gfx] drm/i915/slpc: Sanitize SLPC version

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. v5: Updated with modified

[Intel-gfx] drm/i915: Add support for SKL/BXT 9.18 GuC Firmware for SLPC

Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/i915_debugfs.c | 63 ++-- drivers/gpu/drm/i915/intel_guc_loader.c | 12 +++--- drivers/gpu/drm/i915/intel_slpc.c | 28 - drivers/gpu/drm/i915/intel_slpc.h | 73

[Intel-gfx] drm/i915/slpc: Update freq min/max softlimits

Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_slpc.c | 30 ++ 1 file changed, 30 insertions(+) diff --git a/drivers/gpu/drm/i915/intel_slpc.c b/drivers/gpu/drm/i915/intel_slpc.c index 26cea21..2bfb30f 100644 ---

[Intel-gfx] drm/i915: Check GuC load status for Host to GuC action and SLPC status

Host to GuC actions should not be invoked when GuC isn't loaded hence add early return in i915_guc_action if GuC load status is not SUCCESS. Also, SLPC status has to be linked with GuC load status to make sure SLPC actions get invoked when GuC is loaded. Signed-off-by: Sagar Arun Kamble

[Intel-gfx] 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. v2: fix whitespace (Sagar) Signed-off-by: Tom O'Rourke

[Intel-gfx] Add support for GuC-based SLPC

SLPC (Single Loop Power Controller) is a replacement for some host-based power management features. The SLPC implementation runs in firmware on GuC. This series has been tested with SKL GuC firmware version 9.18 which is yet to be released. Performance and power testing with these patches and

[Intel-gfx] 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

[Intel-gfx] 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] 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] drm/i915/slpc: Add slpc_status enum values

From: Tom O'Rourke v2: fix whitespace (Sagar) Signed-off-by: Tom O'Rourke Signed-off-by: Sagar Arun Kamble --- drivers/gpu/drm/i915/intel_slpc.h | 27 +++ 1 file changed, 27 insertions(+) diff

[Intel-gfx] 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. v5: Updated function names as they need to be made extern. (ChrisW) Signed-off-by: Tom

[Intel-gfx] drm/i915/slpc: Enable SLPC, where supported

From: Tom O'Rourke This patch makes SLPC enabled by default on platforms with hardware/firmware support. v5: Removing warning "enable_slpc < 0" as it is set to -1 with this patch now. This was caught by CI BAT. Signed-off-by: Tom O'Rourke

[Intel-gfx] 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. v2-v4: Rebase. v5: Adjusted slpc version check for major version 8. Added message if version mismatch happens for easier

[Intel-gfx] drm/i915/slpc: Add SKL SLPC Support

From: Tom O'Rourke This patch adds has_slpc to skylake info. 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

[Intel-gfx] 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] 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] drm/i915: Remove RPM suspend dependency on rps.enabled and related changes

For Gen9, RPM suspend is failing if rps.enabled=false. This is needed for other platforms as RC6 and RPS enabling is indicated by rps.enabled. RPM Suspend depends only on RC6, so we need to remove the check of rps.enabled. For Gen9 RC6 and RPS enabling is separated hence do rps.enabled check only

[Intel-gfx] 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) v5: Removed WARN_ON for checking msb of gtt address of shared gem

[Intel-gfx] 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 v2] x86, build: Set -fno-pic for 32/64-bit kernels

Now that 64-bit build configurations are common in both kernel and user space, let's make the -fno-pic compiler flag common for both 32 and 64 bit kernels. Avoid build breakages on build systems enabling -fpic by default (i.e., Android). Signed-off-by: Carlos Santa ---

Re: [Intel-gfx] [PATCH] x86, build: Set -fno-pic for 32/64-bit kernels

On Fri, 2016-08-19 at 16:23 -0700, Carlos Santa wrote: > Make the -fno-pic compiler flag common for both 32 and 64 bit kernels. > The GCC toolchain in Android still enables -fpic by default > causing the build to break. > > Signed-off-by: Carlos Santa Wrong version,

[Intel-gfx] [PATCH] x86, build: Set -fno-pic for 32/64-bit kernels

Make the -fno-pic compiler flag common for both 32 and 64 bit kernels. The GCC toolchain in Android still enables -fpic by default causing the build to break. Signed-off-by: Carlos Santa --- arch/x86/Makefile | 8 1 file changed, 4 insertions(+), 4 deletions(-)

[Intel-gfx] [PATCH v9 5/9] drm/i915/dp: Enable Upfront link training for typeC DP support on BXT

From: Durgadoss R 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

[Intel-gfx] [PATCH v2 3/9] drm/i915: Split intel_ddi_pre_enable() into DP and HDMI versions

From: Ander Conselvan de Oliveira Split intel_ddi_pre_enable() into encoder type specific versions that don't depend on crtc_state. The necessary parameters are passed as function arguments. This split will be necessary for implementing DP upfront link

[Intel-gfx] [PATCH v2 4/9] drm/i915: Split bxt_ddi_pll_select()

From: Durgadoss R Split out of bxt_ddi_pll_select() the logic that calculates the pll dividers and dpll_hw_state into a new function that doesn't depend on crtc state. This will be used for enabling the port pll when doing upfront link training. v2: * Refactored code so

[Intel-gfx] [PATCH 6/9] drm/i915: Split skl_get_dpll()

From: Jim Bride Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code does not directly depend on crtc state, so that the code can be used for upfront link training. Signed-off-by: Jim Bride ---

[Intel-gfx] [PATCH 7/9] drm/i915/dp: Enable upfront link training on SKL

From: Jim Bride Split the PLL selection code out of the BXT upfront link training implementation and into a stand-alone function in order to allow for the implementation of a platform neutral upfront link training function, and then enable upfront link training for

[Intel-gfx] [PATCH 9/9] drm/i915: Enable upfront link training support for HSW/BDW

Get the PLLs for HSW/BDW using the platform specific function and add hooks for enabling upfront link training on HSW and BDW. Signed-off-by: Manasi Navare --- drivers/gpu/drm/i915/intel_ddi.c | 2 ++ drivers/gpu/drm/i915/intel_dp.c | 4 +++- 2 files changed, 5

[Intel-gfx] [PATCH v2 2/9] drm/i915: Remove ddi_pll_sel from intel_crtc_state

From: Ander Conselvan de Oliveira The value of ddi_pll_sel is derived from the selection of shared dpll, so just calculate the final value when necessary. v2: Actually remove it from crtc state and delete remaining usages. (CI) Reviewed-by: Durgadoss R

[Intel-gfx] [PATCH 8/9] drm/i915: Split hsw_get_dpll()

Split out the DisplayPort and HDMI pll setup code into separate functions and refactor the DP code that calculates the pll so that it doesn't depend on crtc state. This will be used for acquiring port pll when doing upfront link training. Signed-off-by: Manasi Navare

[Intel-gfx] [PATCH 1/9] drm/i915: Don't pass crtc_state to intel_dp_set_link_params()

From: Ander Conselvan de Oliveira Decouple intel_dp_set_link_params() from struct intel_crtc_state. This will be useful for implementing DP upfront link training. Reviewed-by: Durgadoss R Signed-off-by: Ander Conselvan de Oliveira

[Intel-gfx] [RFC][PATCH] drm: Add DRM_DEBUG_DISPLAY macro for display configuration debug messages

KMS has a lot of code sequences where the driver has to select a certain HW configuration among the available ones. For e.g., link rate, clock, voltage swing, training pattern etc. Printing such low-level messages is valuable for debugging display problems. But, will bloat dmesg if printed with

[Intel-gfx] [PATCH] drm/i915: don't forget to set intel_crtc->dspaddr_offset on SKL+

We never remembered to set it (so it was zero), but this was not a problem in the past due to the way handled the hardware registers. Unfortunately we changed how we set the hardware and forgot to set intel_crtc->dspaddr_offset. This started to reflect on a few kms_frontbuffer_tracking subtests

Re: [Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

> > Can we proceed with merging it? I'm pretty sure I acked this on irc a week or so agao, Acked-by: Dave Airlie Dave. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 17/19] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer

On Fri, Aug 19, 2016 at 02:13:16PM +0530, akash.g...@intel.com wrote: > From: Akash Goel > > In order to have fast reads from the GuC log buffer, used SSE4.1 movntdqa > based memcpy function i915_memcpy_from_wc. > GuC log buffer has a WC type vmalloc mapping and copying

Re: [Intel-gfx] [PATCH 15/19] drm/i915: Debugfs support for GuC logging control

On Fri, Aug 19, 2016 at 02:13:14PM +0530, akash.g...@intel.com wrote: > +static int i915_guc_log_control_get(void *data, u64 *val) > +{ > + struct drm_device *dev = data; > + struct drm_i915_private *dev_priv = to_i915(dev); > + > + if (!dev_priv->guc.log.vma) > + return

Re: [Intel-gfx] [PATCH 14/19] drm/i915: Forcefully flush GuC log buffer on reset

On Fri, Aug 19, 2016 at 02:13:13PM +0530, akash.g...@intel.com wrote: > From: Sagar Arun Kamble > > Before capturing the GuC logs as a part of error state, there should be a > force log buffer flush action sent to GuC before proceeding with GPU reset > and

Re: [Intel-gfx] [PATCH 08/19] drm/i915: Add a relay backed debugfs interface for capturing GuC logs

On Fri, Aug 19, 2016 at 02:13:07PM +0530, akash.g...@intel.com wrote: > static void *guc_get_write_buffer(struct intel_guc *guc) > { > - return NULL; > + /* FIXME: Cover the check under a lock ? */ > + if (!guc->log.relay_chan) > + return NULL; > + > + /* Just get the

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Add function to return port from an encoder

On Fri, 2016-08-19 at 10:02 +0200, Daniel Vetter wrote: > On Mon, Aug 15, 2016 at 05:00:53PM -0700, Dhinakaran Pandiyan wrote: > > There are places in the driver where we just need the 'port' associated > > with an encoder and not 'struct intel_digital_port' that contains it. > > This basically is

Re: [Intel-gfx] linux-next: manual merge of the jc_docs tree with the drm-misc tree

On Fri, 19 Aug 2016 11:52:15 +1000 Stephen Rothwell wrote: > Today's linux-next merge of the jc_docs tree got a conflict in: > > Documentation/gpu/index.rst > > between commit: > > b754b35b089d ("vgaarbiter: rst-ifiy and polish kerneldoc") > > from the drm-misc

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [1/2] drm/i915: Take forcewake once for the entire GMBUS transaction

== Series Details == Series: series starting with [1/2] drm/i915: Take forcewake once for the entire GMBUS transaction URL : https://patchwork.freedesktop.org/series/11332/ State : failure == Summary == Series 11332v1 Series without cover letter

Re: [Intel-gfx] [PATCH v2 1/3] drm/i915: Add function to return port from an encoder

On Thu, 2016-08-18 at 21:39 -0700, Rodrigo Vivi wrote: > On Mon, Aug 15, 2016 at 05:00:53PM -0700, Dhinakaran Pandiyan wrote: > > There are places in the driver where we just need the 'port' associated > > with an encoder and not 'struct intel_digital_port' that contains it. > > This basically is

[Intel-gfx] [PATCH 1/2] drm/i915: Take forcewake once for the entire GMBUS transaction

As we do many register reads within a very short period of time, hold the GMBUS powerwell from start to finish. Signed-off-by: Chris Wilson Cc: David Weinehall --- drivers/gpu/drm/i915/intel_i2c.c | 131

[Intel-gfx] [PATCH 2/2] drm/i915: Try GPIO NAK discovery before GMBUS

Some GMBUS devices fail to report NAKs (even recent Skylakes), resulting in us hitting the 50ms timeout every time we try to read an EDID on a disconnected device. Try a quick GPIO discovery first by setting the clock line and seeing if the device responds. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Ro.CI.BAT: failure for series starting with [CI,1/6] drm/i915: Flush delayed fence releases after reset

== Series Details == Series: series starting with [CI,1/6] drm/i915: Flush delayed fence releases after reset URL : https://patchwork.freedesktop.org/series/11329/ State : failure == Summary == Series 11329v1 Series without cover letter

Re: [Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Reattach comment, complete type specification

On 19/08/16 15:49, Patchwork wrote: == Series Details == Series: drm/i915: Reattach comment, complete type specification URL : https://patchwork.freedesktop.org/series/11327/ State : failure == Summary == Series 11327v1 drm/i915: Reattach comment, complete type specification

[Intel-gfx] [CI 3/6] drm/i915/fbc: Allow on unfenced surfaces, for recent gen

Only fbc1 is tied to using a fence. Later iterations of fbc are more flexible and allow operation on unfenced frontbuffers. Signed-off-by: Chris Wilson Cc: Daniel Vetter Cc: "Zanoni, Paulo R" ---

[Intel-gfx] [CI 6/6] drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass

Very old numbers indicate this is a 66% improvement when remapping the entire object for fence contention - due to the elimination of track_pfn_insert and its strcmp. Signed-off-by: Chris Wilson Testcase: igt/gem_fence_upload/performance Testcase: igt/gem_mmap_gtt

[Intel-gfx] [CI 2/6] drm/i915/fbc: Don't set an illegal fence if unfenced

If the frontbuffer doesn't have an associated fence, it will have a fence reg of -1. If we attempt to OR in this register into the FBC control register we end up setting all control bits, oops! Signed-off-by: Chris Wilson Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

On 19/08/16 15:30, Chris Wilson wrote: On Fri, Aug 19, 2016 at 03:23:42PM +0100, Dave Gordon wrote: In the recent patch bc3d674 drm/i915: Allow userspace to request no-error-capture upon ... the final version moved the flags and the associated #defines around so they were adjacent;

[Intel-gfx] [CI 1/6] drm/i915: Flush delayed fence releases after reset

What I never hit in testing, but Mika immediately did, was a GPU hang with a pending fence release (where a tiled object has been changed by the user to be untiled, and the update has not yet been committed to the fence register). As the stride/tiling is 0, this causes a divide-by-zero error when

[Intel-gfx] [CI 5/6] drm/i915: Embed the io-mapping struct inside drm_i915_private

As io_mapping.h now always allocates the struct, we can avoid that allocation and extra pointer dance by embedding the struct inside drm_i915_private Signed-off-by: Chris Wilson Reviewed-by: Joonas Lahtinen ---

Re: [Intel-gfx] [isg-gms] [PATCH] drm/i915/bxt: Bring MIPI out of reset

On Fri, 19 Aug 2016 13:04:54 +0300 Jani Nikula wrote: > On Sat, 06 Aug 2016, Bob Paauwe wrote: > > On Fri, 5 Aug 2016 15:23:23 -0700 > > "Xiong, James" wrote: > > > >> Reviewed-by James Xiong

Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

On 19/08/16 14:39, Chris Wilson wrote: On Fri, Aug 19, 2016 at 02:31:15PM +0100, Dave Gordon wrote: @@ -654,6 +680,14 @@ int intel_logical_ring_alloc_request_extras(struct drm_i915_gem_request *request */ request->reserved_space += EXECLISTS_REQUEST_SIZE; + /* +

[Intel-gfx] [CI 4/6] io-mapping: Always create a struct to hold metadata about the io-mapping

Currently, we only allocate a structure to hold metadata if we need to allocate an ioremap for every access, such as on x86-32. However, it would be useful to store basic information about the io-mapping, such as its page protection, on all platforms. Signed-off-by: Chris Wilson

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Reattach comment, complete type specification

== Series Details == Series: drm/i915: Reattach comment, complete type specification URL : https://patchwork.freedesktop.org/series/11327/ State : failure == Summary == Series 11327v1 drm/i915: Reattach comment, complete type specification

Re: [Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

On Fri, Aug 19, 2016 at 03:23:42PM +0100, Dave Gordon wrote: > In the recent patch > bc3d674 drm/i915: Allow userspace to request no-error-capture upon ... > the final version moved the flags and the associated #defines around > so they were adjacent; unfortunately, they ended up between a comment

Re: [Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

On Fri, Aug 19, 2016 at 03:23:42PM +0100, Dave Gordon wrote: > In the recent patch > bc3d674 drm/i915: Allow userspace to request no-error-capture upon ... > the final version moved the flags and the associated #defines around > so they were adjacent; unfortunately, they ended up between a comment

[Intel-gfx] [PATCH] drm/i915: Reattach comment, complete type specification

In the recent patch bc3d674 drm/i915: Allow userspace to request no-error-capture upon ... the final version moved the flags and the associated #defines around so they were adjacent; unfortunately, they ended up between a comment and the thing (hw_id) to which the comment applies :( So this patch

[Intel-gfx] [PATCH v5 07/11] drm/i915: advertise available metrics via sysfs

Each metric set is given a sysfs entry like: /sys/class/drm/card0/metrics//id This allows userspace to enumerate the specific sets that are available for the current system. The 'id' file contains an unsigned integer that can be used to open the associated metric set via

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable i915 perf stream for Haswell OA unit (rev2)

== Series Details == Series: Enable i915 perf stream for Haswell OA unit (rev2) URL : https://patchwork.freedesktop.org/series/11295/ State : failure == Summary == Applying: drm/i915: Add i915 perf infrastructure Using index info to reconstruct a base tree... M

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/execlists: Move WA_TAIL_DWORDS to callee (rev3)

== Series Details == Series: drm/i915/execlists: Move WA_TAIL_DWORDS to callee (rev3) URL : https://patchwork.freedesktop.org/series/3133/ State : failure == Summary == Series 3133v3 drm/i915/execlists: Move WA_TAIL_DWORDS to callee

Re: [Intel-gfx] [PATCH] drm/i915: Flush delayed fence releases after reset

Chris Wilson writes: > What I never hit in testing, but Mika immediately did, was a GPU hang > with a pending fence release (where a tiled object has been changed by > the user to be untiled, and the update has not yet been committed to the > fence register). As the

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Flush delayed fence releases after reset

== Series Details == Series: drm/i915: Flush delayed fence releases after reset URL : https://patchwork.freedesktop.org/series/11323/ State : failure == Summary == Series 11323v1 drm/i915: Flush delayed fence releases after reset

Re: [Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

On Fri, Aug 19, 2016 at 02:31:15PM +0100, Dave Gordon wrote: > @@ -654,6 +680,14 @@ int intel_logical_ring_alloc_request_extras(struct > drm_i915_gem_request *request >*/ > request->reserved_space += EXECLISTS_REQUEST_SIZE; > > + /* > + * WA_TAIL_DWORDS is specific to the

[Intel-gfx] [PATCH v7] drm/i915/execlists: Move WA_TAIL_DWORDS to callee

Currently the execlist-specific emit-request functions start writing to the ring and reserve space for a workaround to be emitted later whilst submitting the request. It is easier to read if the caller only allocates sufficient space for its own accesses (then the reader can quickly verify that

[Intel-gfx] [PATCH] drm/i915: Flush delayed fence releases after reset

What I never hit in testing, but Mika immediately did, was a GPU hang with a pending fence release (where a tiled object has been changed by the user to be untiled, and the update has not yet been committed to the fence register). As the stride/tiling is 0, this causes a divide-by-zero error when

Re: [Intel-gfx] [PATCH v4 1/4] drm: extra printk() wrapper macros

Hi Dave, Daniel, We had this i915 series with a single DRM core patch (reviewed) ready for a while - just waiting for an ack to merge it via i915 trees. Can we proceed with merging it? Regards, Tvrtko On 18/08/16 18:17, Dave Gordon wrote: We had only DRM_INFO() and DRM_ERROR(), whereas

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass

On Fri, Aug 19, 2016 at 02:32:05PM +0300, Joonas Lahtinen wrote: > On ma, 2016-08-15 at 12:53 +0100, Chris Wilson wrote: > > +int remap_io_mapping(struct vm_area_struct *vma, > > +  unsigned long addr, unsigned long pfn, unsigned long size, > > +  struct io_mapping

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Restore debugfs/i915_gem_gtt back to its former glory

== Series Details == Series: drm/i915: Restore debugfs/i915_gem_gtt back to its former glory URL : https://patchwork.freedesktop.org/series/11321/ State : failure == Summary == Series 11321v1 drm/i915: Restore debugfs/i915_gem_gtt back to its former glory

[Intel-gfx] [PATCH] drm/i915: Restore debugfs/i915_gem_gtt back to its former glory

The passed in flag that distinguishes i915_gem_pin_display from i915_gem_gtt is from node->info_ent->data not the data function parameter. Fixes: 6da8482936c7 ("drm/i915: Focus debugfs/i915_gem_pinned to show...") Signed-off-by: Chris Wilson Cc: Joonas Lahtinen

Re: [Intel-gfx] [PATCH 2/2] drm/i915: Use remap_io_mapping() to prefault all PTE in a single pass

On ma, 2016-08-15 at 12:53 +0100, Chris Wilson wrote: > +int remap_io_mapping(struct vm_area_struct *vma, > +  unsigned long addr, unsigned long pfn, unsigned long size, > +  struct io_mapping *iomap) > +{ > + struct remap_pfn r; > + int err; > + > +#define

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Check live status before reading edid"

On Thu, Aug 18, 2016 at 10:29:43AM +0300, David Weinehall wrote: > On Wed, Aug 17, 2016 at 04:43:36PM +0300, Jani Nikula wrote: > > On Wed, 17 Aug 2016, Chris Wilson wrote: > > > On Wed, Aug 17, 2016 at 03:47:48PM +0300, David Weinehall wrote: > > >> This reverts commit

Re: [Intel-gfx] [PATCH 1/2] io-mapping: Always create a struct to hold metadata about the io-mapping

On ma, 2016-08-15 at 12:53 +0100, Chris Wilson wrote: > Currently, we only allocate a structure to hold metadata if we need to > allocate an ioremap for every access, such as on x86-32. However, it > would be useful to store basic information about the io-mapping, such as > its page protection, on

Re: [Intel-gfx] [PATCH 19/19] drm/i915: Mark the GuC log buffer flush interrupts handling WQ as freezable

On pe, 2016-08-19 at 14:13 +0530, akash.g...@intel.com wrote: > From: Akash Goel > > The GuC log buffer flush work item has to do a register access to send the > ack to GuC and this work item, if not synced before suspend, can potentially > get executed after the GFX device

Re: [Intel-gfx] [PATCH v4 07/11] drm/i915: advertise available metrics via sysfs

On Thu, Aug 18, 2016 at 11:42:37PM +0100, Robert Bragg wrote: > Each metric set is given a sysfs entry like: > > /sys/class/drm/card0/metrics//id > > This allows userspace to enumerate the specific sets that are available > for the current system. The 'id' file contains an unsigned integer that

Re: [Intel-gfx] [PATCH 06/19] drm/i915: Handle log buffer flush interrupt event from GuC

On 19/08/16 09:43, akash.g...@intel.com wrote: From: Sagar Arun Kamble GuC ukernel sends an interrupt to Host to flush the log buffer and expects Host to correspondingly update the read pointer information in the state structure, once it has consumed the log buffer

Re: [Intel-gfx] [isg-gms] [PATCH] drm/i915/bxt: Bring MIPI out of reset

On Sat, 06 Aug 2016, Bob Paauwe wrote: > On Fri, 5 Aug 2016 15:23:23 -0700 > "Xiong, James" wrote: > >> Reviewed-by James Xiong > > Merged to gold. Thanks for the review. What does this mean? Why do you Cc both internal and

[Intel-gfx] ✗ Ro.CI.BAT: failure for Support for sustained capturing of GuC firmware logs (rev9)

== Series Details == Series: Support for sustained capturing of GuC firmware logs (rev9) URL : https://patchwork.freedesktop.org/series/7910/ State : failure == Summary == Series 7910v9 Support for sustained capturing of GuC firmware logs

[Intel-gfx] E3800 CPU hung without any logs

Hi, I post a question in Intel Communities website(https://communities.intel.com/message/414994), an answer from Intel said that maybe I can get workaround from https://01.org/. Because I'm not familiar with this website, I just choose this maillist as the most related to ask the question.

[Intel-gfx] [PATCH 15/19] drm/i915: Debugfs support for GuC logging control

From: Sagar Arun Kamble This patch provides debugfs interface i915_guc_output_control for on the fly enabling/disabling of logging in GuC firmware and controlling the verbosity level of logs. The value written to the file, should have bit 0 set to enable logging and

[Intel-gfx] [PATCH 16/19] drm/i915: Use uncached(WC) mapping for acessing the GuC log buffer

From: Akash Goel Host needs to sample the GuC log buffer on every flush interrupt from GuC. To ensure that we always get the up-to-date data from log buffer, its better to access the buffer through an uncached CPU mapping. Also the way buffer is accessed from GuC & Host

[Intel-gfx] [PATCH 07/19] relay: Use per CPU constructs for the relay channel buffer pointers

From: Akash Goel relay essentially needs to maintain the per CPU array of channel buffer pointers but it manually creates that array. Instead its better to avail the per CPU constructs, provided by the kernel, to allocate & access the array of pointer to channel buffers.

[Intel-gfx] [PATCH 17/19] drm/i915: Use SSE4.1 movntdqa based memcpy for sampling GuC log buffer

From: Akash Goel In order to have fast reads from the GuC log buffer, used SSE4.1 movntdqa based memcpy function i915_memcpy_from_wc. GuC log buffer has a WC type vmalloc mapping and copying using movntqda from WC type memory is almost as fast as reading from WB memory.

[Intel-gfx] [PATCH 14/19] drm/i915: Forcefully flush GuC log buffer on reset

From: Sagar Arun Kamble Before capturing the GuC logs as a part of error state, there should be a force log buffer flush action sent to GuC before proceeding with GPU reset and re-initializing GUC. There could be some data in the log buffer which is yet to be captured

[Intel-gfx] [PATCH 11/19] drm/i915: Optimization to reduce the sampling time of GuC log buffer

From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full, so Driver doesn't really need to sample the complete buffer and can just copy only the newly written data by GuC into the local buffer, i.e. as per the read & write pointer

[Intel-gfx] [PATCH 18/19] drm/i915: Early creation of relay channel for capturing boot time logs

From: Akash Goel As per the current i915 Driver load sequence, debugfs registration is done at the end and so the relay channel debugfs file is also created after that but the GuC firmware is loaded much earlier in the sequence. As a result Driver could miss capturing the

[Intel-gfx] [PATCH 10/19] drm/i915: Add stats for GuC log buffer flush interrupts

From: Akash Goel GuC firmware sends an interrupt to flush the log buffer when it becomes half full. GuC firmware also tracks how many times the buffer overflowed. It would be useful to maintain a statistics of how many flush interrupts were received and for which type of

  1   2   >