[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915/fbc: disable FBC on FIFO underruns (rev2)

== Series Details == Series: drm/i915/fbc: disable FBC on FIFO underruns (rev2) URL : https://patchwork.freedesktop.org/series/8575/ State : failure == Summary == Series 8575v2 drm/i915/fbc: disable FBC on FIFO underruns http://patchwork.freedesktop.org/api/1.0/series/8575/revisions/2/mbox

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

On 8/15/2016 10:26 PM, Chris Wilson wrote: On Mon, Aug 15, 2016 at 10:16:56PM +0530, Goel, Akash wrote: On 8/15/2016 9:36 PM, Chris Wilson wrote: On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: +static void guc_read_update_log_buffer(struct intel_guc *guc) +{ +

[Intel-gfx] ✗ Ro.CI.BAT: warning for drm/i915: Silence GCC warning for cmn_a_well

== Series Details == Series: drm/i915: Silence GCC warning for cmn_a_well URL : https://patchwork.freedesktop.org/series/11121/ State : warning == Summary == Series 11121v1 drm/i915: Silence GCC warning for cmn_a_well http://patchwork.freedesktop.org/api/1.0/series/11121/revisions/1/mbox

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

On 8/15/2016 9:18 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, 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

[Intel-gfx] [PATCH 1/2] drm/i915: make i915 the source of acpi device ids for _DOD

From: Jani Nikula The graphics driver is supposed to define the DIDL, which are used for _DOD, not the BIOS. Restore that behaviour. This is basically a revert of commit 3143751ff51a163b77f7efd389043e038f3e008e Author: Zhang Rui Date: Mon Mar 29

[Intel-gfx] [PATCH 2/2] drm/i915/opregion: update cadl based on actually active outputs

From: Jani Nikula Previously we've just shoved the first eight devices in DIDL to CADL (list of active outputs). Some of the active outputs may have been left outside of CADL. The problem is, some BIOS implementations prevent laptop brightness hotkey propagation if the

[Intel-gfx] [PATCH 0/2] Adapt patches from Jani to solve brightness hot key problem

Hi guys, these are the same patches that Jani sent some time ago[1], but adapted to current 4.8-rc1. These fixed the problem I had with my Asus laptop[2], and now the brightness hotkeys are working in my machine. The only adaptation needed was change dev_priv->dev to dev_priv->drm on

[Intel-gfx] [PATCH v2 2/3] drm/i915: Move audio_connector to intel_encoder

With DP MST, a digital_port can carry more than one audio stream. Hence, more than one audio_connector needs to be attached to intel_digital_port in such cases. However, each stream is associated with an unique encoder. So, instead of creating an array of audio_connectors per port, move

[Intel-gfx] [PATCH v2 3/3] drm/i915: start adding dp mst audio

From: Libin Yang (This patch is developed by Dave Airlie originally) This patch adds support for DP MST audio in i915. Enable audio codec when DP MST is enabled if has_audio flag is set. Disable audio codec when DP MST is disabled if has_audio

[Intel-gfx] [PATCH v2 0/3] Prep. for DP audio MST support

This series lays the groundwork for more DP MST audio work that will follow. (c) got possibly reverted because enc_to_dig_port() was incorrectly used on MST encoders. Let's bring it back with the fix introduced in (a). v2: (a) -different solution replacing the enc_to_dig_port() fix (Ville,

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

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 a generic implementation of intel_ddi_get_encoder_port() handling both DDI and Non-DDI encoders. The handling of the analog encoder is

Re: [Intel-gfx] [PATCH 11/25] drm/i915/fbc: fix the FBC state checking code

Em Seg, 2016-08-15 às 21:55 +0100, Chris Wilson escreveu: > On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote: > > > > We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate > > during atomic commits. This will continue to guarantee that we > > deactivate FBC and it will

[Intel-gfx] [PATCH] drm/i915/fbc: disable FBC on FIFO underruns

Ever since I started working on FBC I was already aware that FBC can really amplify the FIFO underrun symptoms. On systems where FIFO underruns were harmless error messages, enabling FBC would cause the underruns to give black screens. We recently tried to enable FBC on Haswell and got reports of

Re: [Intel-gfx] [PATCH v3 21/21] drm/i915: Move HAS_GUC definition to platform definition

On Tue, Aug 09, 2016 at 11:45:27AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platform > - possible to see supported features when dumping struct > definitions >

Re: [Intel-gfx] [PATCH v3 20/21] drm/i915: Make HWS_NEEDS_PHYSICAL the exception

On Tue, Aug 09, 2016 at 11:45:26AM -0700, Carlos Santa wrote: > Make the .hws_needs_physical the exception by switching the flag > on earlier platforms since they are fewer to support. Remove the flag on > later GPUs hardware since they all use GTT hws by default. > > Switch the logic as well in

Re: [Intel-gfx] [PATCH 11/25] drm/i915/fbc: fix the FBC state checking code

On Tue, Jan 19, 2016 at 11:35:44AM -0200, Paulo Zanoni wrote: > We'll now call intel_fbc_pre_update instead of intel_fbc_deactivate > during atomic commits. This will continue to guarantee that we > deactivate FBC and it will also update the state checking structures > at the correct time. Then,

Re: [Intel-gfx] [PATCH v3 19/21] drm/i915: Move HAS_GMCH_DISPLAY definition to platform

On Tue, Aug 09, 2016 at 11:45:25AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 18/21] drm/i915: Move HAS_L3_DPF definition to platform definition

On Tue, Aug 09, 2016 at 11:45:24AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions >

Re: [Intel-gfx] [PATCH v3 17/21] drm/i915: Move HAS_LOGICAL_RING_CONTEXTS definition to platform

On Tue, Aug 09, 2016 at 11:45:23AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions >

Re: [Intel-gfx] drm/i915/fbc: disable FBC on FIFO underruns

Em Sáb, 2016-08-13 às 10:05 +0100, Chris Wilson escreveu: > On Fri, Aug 12, 2016 at 11:24:59PM +, Pandiyan, Dhinakaran wrote: > Do we know why we get black screens in this scenario? I don't know exactly, but I can speculate that it's probably because the display engine fails to decompress the

Re: [Intel-gfx] [PATCH v3 16/21] drm/i915: Move HAS_HW_CONTEXTS definition to platform

On Tue, Aug 09, 2016 at 11:45:22AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 15/21] drm/i915: Introduce GEN2_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:21AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. > same as others > Use it for 830, 845g, i85x, i865g. > > Signed-off-by: Carlos Santa > --- > drivers/gpu/drm/i915/i915_pci.c | 37

Re: [Intel-gfx] [PATCH v3 14/21] drm/i915: Introduce GEN3_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:20AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES from Ben W. > same as previous > Use it for i915g, i915gm, i945g, i945gm, g33 and pnv. > > Signed-off-by: Carlos Santa Reviewed-by: Rodrigo Vivi > ---

Re: [Intel-gfx] [PATCH v3 13/21] drm/i915: Introduce GEN4_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:19AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben W. same comments as for gen5 > > Use it for i965g, i965gm, g45 and gm45. > > Signed-off-by: Carlos Santa Reviewed-by: Rodrigo Vivi >

Re: [Intel-gfx] [PATCH v3 12/21] drm/i915: Move HAS_GMBUS_IRQ definition to platform definition

On Tue, Aug 09, 2016 at 11:45:18AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions >

Re: [Intel-gfx] [PATCH v3 11/21] drm/i915: Introduce GEN5_FEATURES for device info

On Tue, Aug 09, 2016 at 11:45:17AM -0700, Carlos Santa wrote: > Based on the GEN7_FEATURES changes from Ben w. Maybe this comment and also on the previous GEN6_FEATURE could be improved. And also good to Cc people you are mentioning on the commit message. Besides I still believe we should add

Re: [Intel-gfx] [PATCH v3 10/21] drm/i915: Move HAS_DP_MST definition to platform definition

On Tue, Aug 09, 2016 at 11:45:16AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 09/21] drm/i915: Move HAS_RC6p definition to platform definition

On Tue, Aug 09, 2016 at 11:45:15AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 08/21] drm/i915: Move HAS_RC6 definition to platform definition

On Tue, Aug 09, 2016 at 11:45:14AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 07/21] drm/i915: Move HAS_RESOURCE_STREAMER definition to platform definition

On Tue, Aug 09, 2016 at 11:45:13AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 06/21] drm/i915 Move HAS_CSR definition to platform definition

On Tue, Aug 09, 2016 at 11:45:12AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 04/21] drm/i915: Move HAS_RUNTIME_PM definition to platform

On Tue, Aug 09, 2016 at 11:45:10AM -0700, Carlos Santa wrote: > Moving all GPU features to the platform struct definition allows for > - standard place when adding new features from new platforms > - possible to see supported features when dumping struct > definitions > >

Re: [Intel-gfx] [PATCH v3 02/21] drm/i915: Remove .is_mobile field from platform struct

On Tue, Aug 09, 2016 at 11:45:08AM -0700, Carlos Santa wrote: > As recommended by Ville Syrjala removing .is_mobile field from the > platform struct definition for vlv and hsw+ GPUs as there's no need to > make the distinction in later hardware anymore. Keep it for older GPUs > as it is still

Re: [Intel-gfx] [PATCH v3 05/21] drm/i915: Get rid of HAS_CORE_RING_FREQ

On Tue, Aug 09, 2016 at 07:59:38PM +0100, Chris Wilson wrote: > On Tue, Aug 09, 2016 at 11:45:11AM -0700, Carlos Santa wrote: > > No need for HAS_CORE_RING_FREQ as that flag is actually the same as > > .has_llc. Feedback from V. Syrjala. > > > > Signed-off-by: Carlos Santa

[Intel-gfx] [PATCH] drm/i915: Silence GCC warning for cmn_a_well

Just make the logic simple enough for even GCC to understand (and foolproof against random changes): drivers/gpu/drm/i915/intel_runtime_pm.c: warning: 'cmn_a_well' may be used uninitialized in this function [-Wuninitialized]: => 871:23 Reported-by: Geert Uytterhoeven

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

On Mon, Aug 15, 2016 at 10:16:56PM +0530, Goel, Akash wrote: > > > On 8/15/2016 9:36 PM, Chris Wilson wrote: > >On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: > >>+static void guc_read_update_log_buffer(struct intel_guc *guc) > >>+{ > >>+ struct guc_log_buffer_state

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

On 8/15/2016 9:36 PM, Chris Wilson wrote: On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: +static void guc_read_update_log_buffer(struct intel_guc *guc) +{ + struct guc_log_buffer_state *log_buffer_state, *log_buffer_snapshot_state; + struct

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

On Mon, Aug 15, 2016 at 10:08:15PM +0530, Goel, Akash wrote: > > > On 8/15/2016 9:42 PM, Chris Wilson wrote: > >On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote: > >>On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: > >>>+void i915_guc_register(struct

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

On 8/15/2016 9:42 PM, Chris Wilson wrote: On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote: On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: +void i915_guc_register(struct drm_i915_private *dev_priv) +{ + if (!i915.enable_guc_submission) +

Re: [Intel-gfx] [PATCH RFC 1/4] drm/i915: add create_context2 ioctl

On Mon, Aug 15, 2016 at 09:25:15AM -0700, Jesse Barnes wrote: > On Mon, 2016-08-15 at 13:56 +0100, Chris Wilson wrote: > > On Mon, Aug 15, 2016 at 03:25:43PM +0300, Mika Kuoppala wrote: > > > > > > Chris Wilson writes: > > > > > > > > > > > On Mon, Aug 15, 2016 at

[Intel-gfx] ✗ Ro.CI.BAT: failure for dma-buf: Wait on the reservation object when sync'ing before CPU access

== Series Details == Series: dma-buf: Wait on the reservation object when sync'ing before CPU access URL : https://patchwork.freedesktop.org/series/6/ State : failure == Summary == Series 6v1 dma-buf: Wait on the reservation object when sync'ing before CPU access

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

On Mon, Aug 15, 2016 at 05:09:45PM +0100, Chris Wilson wrote: > On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: > > +void i915_guc_register(struct drm_i915_private *dev_priv) > > +{ > > + if (!i915.enable_guc_submission) > > + return; > > The final state of

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

On 8/15/2016 9:06 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, akash.g...@intel.com wrote: 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

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

On Mon, Aug 15, 2016 at 08:19:49PM +0530, akash.g...@intel.com wrote: > +void i915_guc_register(struct drm_i915_private *dev_priv) > +{ > + if (!i915.enable_guc_submission) > + return; The final state of i915.enable_guc_submission is not known at this time. Does it matter if you

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

On Mon, Aug 15, 2016 at 08:19:47PM +0530, akash.g...@intel.com wrote: > +static void guc_read_update_log_buffer(struct intel_guc *guc) > +{ > + struct guc_log_buffer_state *log_buffer_state, > *log_buffer_snapshot_state; > + struct guc_log_buffer_state log_buffer_state_local; > + void

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

On 15/08/16 15:49, akash.g...@intel.com wrote: 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

Re: [Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

On Mon, Aug 15, 2016 at 04:42:18PM +0100, Chris Wilson wrote: > Rendering operations to the dma-buf are tracked implicitly via the > reservation_object (dmabuf->resv). This is used to allow poll() to > wait upon outstanding rendering (or just query the current status of > rendering). The dma-buf

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

On 8/15/2016 8:59 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface,

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm: make drm_get_format_name thread-safe (rev2)

== Series Details == Series: drm: make drm_get_format_name thread-safe (rev2) URL : https://patchwork.freedesktop.org/series/11069/ State : failure == Summary == Applying: drm: remove `const` attribute to hint at caller that they now own the memory fatal: sha1 information is lacking or

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

On 15/08/16 15:49, akash.g...@intel.com wrote: 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

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

On 8/15/2016 8:50 PM, Tvrtko Ursulin wrote: On 15/08/16 15:49, 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

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

On 15/08/16 15:49, 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-initializing GUC. There could be some

Re: [Intel-gfx] [PATCH v3 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

On Mon, Aug 15, 2016 at 03:41:23PM +0100, Robert Bragg wrote: > int __must_check i915_gem_evict_something(struct drm_device *dev, > diff --git a/drivers/gpu/drm/i915/i915_gem_context.c > b/drivers/gpu/drm/i915/i915_gem_context.c > index bd13d08..b4de357 100644 > ---

[Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

Rendering operations to the dma-buf are tracked implicitly via the reservation_object (dmabuf->resv). This is used to allow poll() to wait upon outstanding rendering (or just query the current status of rendering). The dma-buf sync ioctl allows userspace to prepare the dma-buf for CPU access,

Re: [Intel-gfx] [PATCH v2] drm/i915: Use common RPS scheme for Cherryview

Apolgies, I changed trees between resending after the first git-send-email bounced off the wrong address. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org

Re: [Intel-gfx] [PATCH 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel Added the dump of GuC log buffer to i915 error state, as the contents of GuC log buffer would also be useful to determine that why the GPU reset was triggered. v2: - For uniformity use existing helper

[Intel-gfx] [PATCH v2] drm/i915: Use common RPS scheme for Cherryview

Cherryview uses a custom static definition of its RPS parameters (for automatically driving GPU frequency selection) - yet still couples into the waitboosting scheme of the common RPS setup. The rationale given in commit 8fb55197e64d ("drm/i915: Agressive downclocking on Baytrail") was that

[Intel-gfx] [PATCH v2] dma-buf: Wait on the reservation object when sync'ing before CPU access

Rendering operations to the dma-buf are tracked implicitly via the reservation_object (dmabuf->resv). This is used to allow poll() to wait upon outstanding rendering (or just query the current status of rendering). The dma-buf sync ioctl allows userspace to prepare the dma-buf for CPU access,

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

On 15/08/16 15:49, akash.g...@intel.com wrote: 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

[Intel-gfx] [FIXUP] drm: remove `const` attribute to hint at caller that they now own the memory

Signed-off-by: Eric Engestrom --- drivers/gpu/drm/amd/amdgpu/dce_v10_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v11_0.c | 2 +- drivers/gpu/drm/amd/amdgpu/dce_v8_0.c | 2 +- drivers/gpu/drm/drm_atomic.c| 2 +-

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

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to just use a relay API to

Re: [Intel-gfx] [PATCH 02/10] drm/i915/userptr: Make gup errors stickier

On Mon, Aug 15, 2016 at 06:08:21PM +0300, Mika Kuoppala wrote: > Chris Wilson writes: > > > + if (obj->userptr.work) { > > /* active flag should still be held for the pending work */ > > - return -EAGAIN; > > + if

Re: [Intel-gfx] linux-firmware-i915 pull request (restore skl dmc 1.23)

On Thu, Aug 11, 2016 at 06:22:56PM +, Vivi, Rodrigo wrote: > The following changes since commit > c170c8d95794d6aedbaeea44674daaa96baf04f7: > >   linux-firmware: intel: Update Skylake audio firmware (2016-08-04 > 16:09:21 +0530) > > are available in the git repository at: > >  

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

On 15/08/16 15:49, 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

[Intel-gfx] ✗ Ro.CI.BAT: failure for Enable Gen 7 Observation Architecture (rev5)

== Series Details == Series: Enable Gen 7 Observation Architecture (rev5) URL : https://patchwork.freedesktop.org/series/3024/ State : failure == Summary == Applying: drm/i915: Add i915 perf infrastructure Using index info to reconstruct a base tree... M drivers/gpu/drm/i915/Makefile M

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

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

Re: [Intel-gfx] [PATCH 02/10] drm/i915/userptr: Make gup errors stickier

Chris Wilson writes: > Keep any error reported by the gup_worker until we are notified that the > arena has changed (via the mmu-notifier). This has the importance of > making two consecutive calls to i915_gem_object_get_pages() reporting > the same error, and

Re: [Intel-gfx] [PATCH] drm: make drm_get_format_name thread-safe

On Mon, Aug 15, 2016 at 03:52:07PM +0200, Daniel Vetter wrote: > On Mon, Aug 15, 2016 at 04:13:54PM +0300, Jani Nikula wrote: > > On Mon, 15 Aug 2016, Eric Engestrom wrote: > > > On Mon, Aug 15, 2016 at 12:54:01PM +0300, Jani Nikula wrote: > > >> On Mon, 15 Aug 2016,

Re: [Intel-gfx] [PATCH v3 03/11] drm/i915: return EACCES for check_cmd() failures

On Mon, Aug 15, 2016 at 03:41:20PM +0100, Robert Bragg wrote: > check_cmd() is checking whether a command adheres to certain > restrictions that ensure it's safe to execute within a privileged batch > buffer. Returning false implies a privilege problem, not that the > command is invalid. > > The

Re: [Intel-gfx] [PATCH v3 01/11] drm/i915: Add i915 perf infrastructure

On Mon, Aug 15, 2016 at 03:41:18PM +0100, Robert Bragg wrote: > Adds base i915 perf infrastructure for Gen performance metrics. > > This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 > properties to configure a stream of metrics and returns a new fd usable > with standard

Re: [Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

On 15/08/16 15:49, akash.g...@intel.com wrote: From: Sagar Arun Kamble There are certain types of interrupts which Host can receive from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel.

[Intel-gfx] Current drm-intel-next status on broadwell platform

Hello, I tested drm-intel-next published Aug 9th 2016. I'm facing two major bugs: 1) hard lockups with fbc enabled (neverending story it seems to be) 2) screen tearing in browsers and video players (I do not use any kind of compositor) Should I fire a bug report? both of these two were OK in

[Intel-gfx] [PATCH v3 05/11] drm/i915: Add 'render basic' Haswell OA unit config

Adds a static OA unit, MUX + B Counter configuration for basic render metrics on Haswell. This is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml > scripts/i915-perf-kernelgen.py $ make -C

[Intel-gfx] [PATCH v3 08/11] drm/i915: Add dev.i915.perf_event_paranoid sysctl option

Consistent with the kernel.perf_event_paranoid sysctl option that can allow non-root users to access system wide cpu metrics, this can optionally allow non-root users to access system wide OA counter metrics from Gen graphics hardware. Signed-off-by: Robert Bragg ---

[Intel-gfx] ✗ Ro.CI.BAT: failure for drm/i915: Use common RPS scheme for Cherryview

== Series Details == Series: drm/i915: Use common RPS scheme for Cherryview URL : https://patchwork.freedesktop.org/series/0/ State : failure == Summary == Series 0v1 drm/i915: Use common RPS scheme for Cherryview http://patchwork.freedesktop.org/api/1.0/series/0/revisions/1/mbox

[Intel-gfx] [PATCH v3 06/11] drm/i915: Enable i915 perf stream for Haswell OA unit

Gen graphics hardware can be set up to periodically write snapshots of performance counters into a circular buffer via its Observation Architecture and this patch exposes that capability to userspace via the i915 perf interface. Cc: Chris Wilson Signed-off-by: Robert

[Intel-gfx] [PATCH v3 11/11] drm/i915: Add a kerneldoc summary for i915_perf.c

In particular this tries to capture for posterity some of the early challenges we had with using the core perf infrastructure in case we ever want to revisit adapting perf for device metrics. Cc: Chris Wilson Signed-off-by: Robert Bragg ---

[Intel-gfx] [PATCH v3 10/11] drm/i915: Add more Haswell OA metric sets

This adds 'compute', 'compute extended', 'memory reads', 'memory writes' and 'sampler balance' metric sets for Haswell. The code is auto generated from an XML description of metric sets, currently maintained in gputop, ref: https://github.com/rib/gputop > gputop-data/oa-*.xml >

[Intel-gfx] [PATCH v3 04/11] drm/i915: don't whitelist oacontrol in cmd parser

Being able to program OACONTROL from a non-privileged batch buffer is not sufficient to be able to configure the OA unit. This was originally allowed to help enable Mesa to expose OA counters via the INTEL_performance_query extension, but the current implementation based on programming OACONTROL

[Intel-gfx] [PATCH v3 00/11] Enable Gen 7 Observation Architecture

Mostly just a rebase on a more recent nightly, except for an update to how POLLIN events are reported to reduce the CPU overhead that was otherwise seen while running gputop. The problem seen with poll was largely a fault with gputop having multiple redundant 200ms, but out-of-phase, timers

[Intel-gfx] [PATCH v3 01/11] drm/i915: Add i915 perf infrastructure

Adds base i915 perf infrastructure for Gen performance metrics. This adds a DRM_IOCTL_I915_PERF_OPEN ioctl that takes an array of uint64 properties to configure a stream of metrics and returns a new fd usable with standard VFS system calls including read() to read typed and sized records; ioctl()

[Intel-gfx] [PATCH v3 03/11] drm/i915: return EACCES for check_cmd() failures

check_cmd() is checking whether a command adheres to certain restrictions that ensure it's safe to execute within a privileged batch buffer. Returning false implies a privilege problem, not that the command is invalid. The distinction makes the difference between allowing the buffer to be

[Intel-gfx] [PATCH v3 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] [PATCH v3 02/11] drm/i915: rename OACONTROL GEN7_OACONTROL

OACONTROL changes quite a bit for gen8, with some bits split out into a per-context OACTXCONTROL register. Rename now before adding more gen7 OA registers Signed-off-by: Robert Bragg --- drivers/gpu/drm/i915/i915_cmd_parser.c | 4 ++-- drivers/gpu/drm/i915/i915_reg.h

[Intel-gfx] [PATCH v3 09/11] drm/i915: add oa_event_min_timer_exponent sysctl

The minimal sampling period is now configurable via a dev.i915.oa_min_timer_exponent sysctl parameter. Following the precedent set by perf, the default is the minimum that won't (on its own) exceed the default kernel.perf_event_max_sample_rate default of 10 samples/s. Signed-off-by: Robert

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

Re: [Intel-gfx] [PATCH 6/9] drm/i915/cmdparser: Compare against the previous command descriptor

On Mon, Aug 15, 2016 at 12:00:32PM +0100, Matthew Auld wrote: > On 12 August 2016 at 16:07, Chris Wilson wrote: > > On the blitter (and in test code), we see long sequences of repeated > > commands, e.g. XY_PIXEL_BLT, XY_SCANLINE_BLT, or XY_SRC_COPY. For these, > > we

[Intel-gfx] [PATCH 15/18] 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 11/18] 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 02/18] drm/i915: Add GuC ukernel logging related fields to fw interface file

From: Sagar Arun Kamble The first page of the GuC log buffer contains state info or meta data which is required to parse the logs contained in the subsequent pages. The structure representing the state info is added to interface file as Driver would need to handle log

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

From: Akash Goel Added a new debugfs interface '/sys/kernel/debug/dri/guc_log' for the User to capture GuC firmware logs. Availed relay framework to implement the interface, where Driver will have to just use a relay API to store snapshots of the GuC log buffer in the

[Intel-gfx] [PATCH 05/18] drm/i915: Support for GuC interrupts

From: Sagar Arun Kamble There are certain types of interrupts which Host can receive from GuC. GuC ukernel sends an interrupt to Host for certain events, like for example retrieve/consume the logs generated by ukernel. This patch adds support to receive interrupts from

[Intel-gfx] [PATCH 16/18] 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 10/18] 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

[Intel-gfx] [PATCH v6 00/18] Support for sustained capturing of GuC firmware logs

From: Akash Goel GuC firmware log its debug messages into a Host-GuC shared memory buffer and when the buffer is half full it sends a Flush interrupt to Host. GuC firmware follows the half-full draining protocol where it expects that while it is writing to 2nd half of the

[Intel-gfx] [PATCH 01/18] drm/i915: Decouple GuC log setup from verbosity parameter

From: Sagar Arun Kamble GuC Log buffer allocation was tied up with verbosity level module param i915.guc_log_level. User would be given a provision to enable firmware logging at runtime, through a host2guc action, and not necessarily during Driver load time. But the

[Intel-gfx] [PATCH 12/18] drm/i915: Increase GuC log buffer size to reduce flush interrupts

From: Akash Goel In cases where GuC generate logs at a very high rate, correspondingly the rate of flush interrupts is also very high. So far total 8 pages were allocated for storing both ISR & DPC logs. As per the half-full draining protocol followed by GuC, by doubling

[Intel-gfx] [PATCH 09/18] drm/i915: New lock to serialize the Host2GuC actions

From: Akash Goel With the addition of new Host2GuC actions related to GuC logging, there is a need of a lock to serialize them, as they can execute concurrently with each other and also with other existing actions. v2: Use mutex in place of spinlock to serialize, as sleep

[Intel-gfx] [PATCH 14/18] 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 13/18] drm/i915: Augment i915 error state to include the dump of GuC log buffer

From: Akash Goel Added the dump of GuC log buffer to i915 error state, as the contents of GuC log buffer would also be useful to determine that why the GPU reset was triggered. v2: - For uniformity use existing helper function print_error_obj() to dump out contents of

  1   2   3   >