[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915/guc: Sanitory checks for platform that dont have GuC (rev3)

== Series Details == Series: drm/i915/guc: Sanitory checks for platform that dont have GuC (rev3) URL : https://patchwork.freedesktop.org/series/13358/ State : failure == Summary == Series 13358v3 drm/i915/guc: Sanitory checks for platform that dont have GuC

[Intel-gfx] [PATCH] drm/i915/guc: Sanitory checks for platform that dont have GuC

i915.enable_guc_loading/submission=2 forces the usage of GuC. For platforms that do not have a GuC, asking the kernel to use a GuC should not result in an error state. Do extra checks to see if the platform even has a GuC or not, regardless of the kernel parameter. v2: Based on Rodrigo's patch

Re: [Intel-gfx] [PATCH v2] drm/i915: Allow compaction upto SWIOTLB max segment size

On Wed, Oct 12, 2016 at 05:19:14PM -0400, Konrad Rzeszutek Wilk wrote: > On Mon, Oct 10, 2016 at 11:27:00PM +0100, Chris Wilson wrote: > > commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation > > work with SWIOTLB backend") took a heavy handed approach to undo the > >

Re: [Intel-gfx] [CI 3/3] drm/i915/gtt: Free unused lower-level page tables

On Wed, Oct 12, 2016 at 06:47:38PM +0200, Michał Winiarski wrote: > +static bool gen8_ppgtt_clear_pd(struct i915_address_space *vm, > struct i915_page_directory *pd, > uint64_t start, > uint64_t length) > {

Re: [Intel-gfx] [PATCH v2] drm/i915: Allow compaction upto SWIOTLB max segment size

On Mon, Oct 10, 2016 at 11:27:00PM +0100, Chris Wilson wrote: > commit 1625e7e549c5 ("drm/i915: make compact dma scatter lists creation > work with SWIOTLB backend") took a heavy handed approach to undo the > scatterlist compaction in the face of SWIOTLB. (The compaction hit a bug > whereby we

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode URL : https://patchwork.freedesktop.org/series/13663/ State : failure == Summary == Series 13663v1 Series without cover letter

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Add support for Legacy Hdmi audio

> == Series Details == > > Series: Add support for Legacy Hdmi audio > URL : https://patchwork.freedesktop.org/series/13661/ > State : warning > > == Summary == > > Series 13661v1 Add support for Legacy Hdmi audio > https://patchwork.freedesktop.org/api/1.0/series/13661/revisions/1/mbox/ > >

[Intel-gfx] ✗ Fi.CI.BAT: warning for Add support for Legacy Hdmi audio

== Series Details == Series: Add support for Legacy Hdmi audio URL : https://patchwork.freedesktop.org/series/13661/ State : warning == Summary == Series 13661v1 Add support for Legacy Hdmi audio https://patchwork.freedesktop.org/api/1.0/series/13661/revisions/1/mbox/ Test

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 2016-10-12 at 14:06 +0200, Paul Bolle wrote: > That might take some time. Because bisecting always takes a long time > and especially since hitting this WARNING sometimes takes over an hour. > Anyhow, please prod me if I stay silent for too long. For the record: I just had to power cycle

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for Support for sustained capturing of GuC firmware logs (rev11)

> == Series Details == > > Series: Support for sustained capturing of GuC firmware logs (rev11) > URL : https://patchwork.freedesktop.org/series/7910/ > State : warning > > == Summary == > > Series 7910v11 Support for sustained capturing of GuC firmware logs >

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/hsw: Fix GPU hang during resume from S3-devices state

> == Series Details == > > Series: drm/i915/hsw: Fix GPU hang during resume from S3-devices state > URL : https://patchwork.freedesktop.org/series/13654/ > State : warning > > == Summary == > > Series 13654v1 drm/i915/hsw: Fix GPU hang during resume from S3-devices > state >

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Treat a framebuffer reference as an active reference whilst shrinking

> == Series Details == > > Series: drm/i915: Treat a framebuffer reference as an active reference whilst > shrinking > URL : https://patchwork.freedesktop.org/series/13648/ > State : failure > > == Summary == > > Series 13648v1 drm/i915: Treat a framebuffer reference as an active > reference

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Record the current requests queue for execlists upon hang

== Series Details == Series: drm/i915: Record the current requests queue for execlists upon hang URL : https://patchwork.freedesktop.org/series/13660/ State : success == Summary == Series 13660v1 drm/i915: Record the current requests queue for execlists upon hang

[Intel-gfx] ✗ Fi.CI.BAT: warning for Support for sustained capturing of GuC firmware logs (rev11)

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

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915/hsw: Fix GPU hang during resume from S3-devices state

== Series Details == Series: drm/i915/hsw: Fix GPU hang during resume from S3-devices state URL : https://patchwork.freedesktop.org/series/13654/ State : warning == Summary == Series 13654v1 drm/i915/hsw: Fix GPU hang during resume from S3-devices state

Re: [Intel-gfx] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

Accidentally sent original view twice and found one more issue after looking at the rest of them, sorry about that! On Wed, 2016-10-12 at 13:04 -0400, Lyude wrote: > Loving this patch so far! Would it be possible to get this split into > two separate patches though? One for removing skl_results

Re: [Intel-gfx] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

Loving this patch so far! Would it be possible to get this split into two separate patches though? One for removing skl_results and one for programming watermarks as a separate step. On Wed, 2016-10-12 at 15:28 +0200, Maarten Lankhorst wrote: > Instead of running the watermark updates from the

Re: [Intel-gfx] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

Loving this patch so far! Would it be possible to get this split into two separate patches though? One for removing skl_results and one for programming watermarks as a separate step. On Wed, 2016-10-12 at 15:28 +0200, Maarten Lankhorst wrote: > Instead of running the watermark updates from the

Re: [Intel-gfx] [PATCH 2/4] drm/i915: Respect alternate_ddc_pin for all DDI ports

Retested the _2 branch, works fine as well. On Wed, Oct 12, 2016 at 12:57 PM, Ville Syrjälä < ville.syrj...@linux.intel.com> wrote: > On Tue, Oct 11, 2016 at 10:04:00PM +0200, Maarten Maathuis wrote: > > My name does not include the word "show" (Tested-by tag). > > Sorry about that. Some

[Intel-gfx] [CI 3/3] drm/i915/gtt: Free unused lower-level page tables

Since "Dynamic page table allocations" were introduced, our page tables can grow (being dynamically allocated) with address space range usage. Unfortunately, their lifetime is bound to vm. This is not a huge problem when we're not using softpin - drm_mm is creating an upper bound on used range by

[Intel-gfx] [CI 2/3] drm/i915/gtt: Split gen8_ppgtt_clear_pte_range

Let's use more top-down approach, where each gen8_ppgtt_clear_* function is responsible for clearing the struct passed as an argument and calling relevant clear_range functions on lower-level tables. Doing this rather than operating on PTE ranges makes the implementation of shrinking page tables

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [PATCH i-g-t] build: Fix assmebler/etc. tools build for 32bit x86

From: Ville Syrjälä Match the i?86 pattern when looking for an x86 to catch 32bit build systems as well. Cc: Daniel Stone Cc: Eric Anholt Fixes: bccc0ec6a3fd ("build: Disable x86-specific utilities on non-x86")

Re: [Intel-gfx] [PATCH i-g-t] intel-ci: Remove kms_psr_sink_crc@psr_basic from BAT

On Wed, 12 Oct 2016, Petri Latvala wrote: > The test is producing a lot of CI noise. > > Signed-off-by: Petri Latvala > --- > > Will be pushed shortly. Visible in CI results tomorrow-ish. > > > tests/intel-ci/fast-feedback.testlist | 1 - I know

[Intel-gfx] [RFC PATCH v2 4/8] drm/i915: Add support for enabling/disabling hdmi audio interrupts

API definitions for enabling/disabling hdmi audio interrupts in different hdmi pipes are implemented. Signed-off-by: Jerome Anand --- drivers/gpu/drm/i915/i915_irq.c | 69 drivers/gpu/drm/i915/intel_drv.h | 2 ++ 2 files

[Intel-gfx] [RFC PATCH v2 2/8] ALSA: add shell for Intel HDMI LPE audio driver

On Baytrail and Cherrytrail, HDaudio may be fused out or disabled by the BIOS. This driver enables an alternate path to the i915 display registers and DMA. Although there is no hardware path between i915 display and LPE/SST audio clusters, this HDMI capability is referred to in the documentation

[Intel-gfx] [RFC PATCH v2 8/8] hdmi_audio: continue audio playback even when display resolution changes

When the display resolution changes, the drm disables the display pipes due to which audio rendering stops. At this time, we need to ensure the existing audio pointers and buffers are cleared out so that the playback can restarted once the display pipe is enabled with a different N/CTS values

[Intel-gfx] [RFC PATCH v2 1/8] drm/i915: setup bridge for HDMI LPE audio driver

Enable support for HDMI LPE audio mode on Baytrail and Cherrytrail when HDaudio controller is not detected Setup minimum required resources during i915_driver_load: 1. Create a platform device to share MMIO/IRQ resources 2. Make the platform device child of i915 device for runtime PM. 3. Create

[Intel-gfx] [RFC PATCH v2 7/8] hdmi_audio: Fixup some monitor

I think this change was given to us, and they claimed it fixed an issue on some monitor brand. I'm not sure what this patch actually does. Signed-off-by: David Henningsson Signed-off-by: Pierre-Louis Bossart Signed-off-by:

[Intel-gfx] [RFC PATCH v2 3/8] ALSA: Add support for hdmi audio driver

Hdmi audio driver based on the child platform device created by gfx driver is implemented. This audio driver is derived from legacy intel hdmi audio driver. The interfaces for interaction between gfx and audio are updated and the driver implementation updated to derive interrupts in its own

[Intel-gfx] [RFC PATCH v2 5/8] drm/i915: Add support for audio driver notifications

Notifiations like mode change, hot plug and edid to the audio driver are added. This is inturn used by the audio driver for its functionality. A new interface file capturing the notifications needed by the audio driver is added Signed-off-by: Jerome Anand ---

[Intel-gfx] [RFC PATCH v2 6/8] hdmi_audio: Improve position reporting Using a hw register to calculate sub-period position reports.

This makes PulseAudio happier. Signed-off-by: David Henningsson Signed-off-by: Pierre-Louis Bossart Signed-off-by: Jerome Anand --- sound/x86/intel_hdmi_audio.c | 12 +++- 1 file changed, 11

[Intel-gfx] [RFC PATCH v2 0/8] Add support for Legacy Hdmi audio

Legacy Hdmi audio drivers are added. Added support for audio/ gfx interface using irq chip framework Jerome Anand (8): drm/i915: setup bridge for HDMI LPE audio driver ALSA: add shell for Intel HDMI LPE audio driver ALSA: Add support for hdmi audio driver drm/i915: Add support for

[Intel-gfx] [PATCH] drm/i915: Record the current requests queue for execlists upon hang

Mika wanted to know what requests were pending at the time of a hang as we now track which requests we have submitted to the hardware. Signed-off-by: Chris Wilson Cc: Mika Kuoppala --- drivers/gpu/drm/i915/i915_drv.h | 3 +-

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

From: Akash Goel 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 side, manually doing cache flush may not be effective always if cached CPU

[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 17/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

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

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 is suspended. This work item function uses rpm get/put calls around the

[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 04/18] drm/i915: Add low level set of routines for programming PM IER/IIR/IMR register set

From: Akash Goel So far PM IER/IIR/IMR registers were being used only for Turbo related interrupts. But interrupts coming from GuC also use the same set. As a precursor to supporting GuC interrupts, added new low level routines so as to allow sharing the programming of PM

[Intel-gfx] [PATCH 14/18] drm/i915: Support for forceful flush of GuC log buffer

From: Sagar Arun Kamble GuC firmware sends a flush interrupt to Host when the log buffer is half full and at that time only it updates the log buffer state. But in certain cases, as described below, it could be useful to have all that even when log buffer is only

[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 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 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

[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 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 07/18] 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 06/18] drm/i915: Handle log buffer flush interrupt event from GuC

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 contents by copying them to a file or buffer. Even

[Intel-gfx] [PATCH 03/18] drm/i915: New structure to contain GuC logging related fields

From: Akash Goel So far there were 2 fields related to GuC logs in 'intel_guc' structure. For the support of capturing GuC logs & storing them in a local buffer, multiple new fields would have to be added. This warrants a separate structure to contain the fields related to

[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 v10 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] ✗ Fi.CI.BAT: failure for drm/i915: Treat a framebuffer reference as an active reference whilst shrinking

== Series Details == Series: drm/i915: Treat a framebuffer reference as an active reference whilst shrinking URL : https://patchwork.freedesktop.org/series/13648/ State : failure == Summary == Series 13648v1 drm/i915: Treat a framebuffer reference as an active reference whilst shrinking

Re: [Intel-gfx] [PATCH] drm/i915/hsw: Fix GPU hang during resume from S3-devices state

On Wed, Oct 12, 2016 at 05:46:37PM +0300, Imre Deak wrote: > Currently resuming on HSW from S3 pm_test/devices state leads to an > unrecoverable GPU hang. Resetting the GPU during suspend fixes this. For > a full S3 cycle this change only means the reset happens earlier (before > reaching S3). For

[Intel-gfx] [PATCH igt] igt/gem_wait: Use explicit timers

Rather than guestimating a workload that should take a certain amount of time, use a sigitimer to terminate a batch (and so complete the wait) after an exact amount of time. And in the process expand testing to cover multiple rings and hangcheck. Signed-off-by: Chris Wilson

[Intel-gfx] [PATCH igt] igt: Add exerciser for execbuf fence-out <-> fence-in

When execbuf2 supports explicit fencing with sync_file in/out fences (via a fence-fd), we can control execution via the fence. Signed-off-by: Chris Wilson --- tests/Makefile.sources | 1 + tests/gem_exec_fence.c | 377 +

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 2016-10-12 at 17:34 +0300, Jani Nikula wrote: > In the mean time, please file a bug over at [1] so we don't lose > track. Done:  https://bugs.freedesktop.org/show_bug.cgi?id=98214 Paul Bolle ___ Intel-gfx mailing list

[Intel-gfx] [PATCH] drm/i915/hsw: Fix GPU hang during resume from S3-devices state

Currently resuming on HSW from S3 pm_test/devices state leads to an unrecoverable GPU hang. Resetting the GPU during suspend fixes this. For a full S3 cycle this change only means the reset happens earlier (before reaching S3). For S4 the reset will happen now both during the freeze and quiesce

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 12 Oct 2016, Paul Bolle wrote: > On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: >> Bisecting the offending commit between v4.8 and v4.8.1 would be a good >> start. > > That would be between v4.7 and v4.8. (I guess my report was ambiguous.) > > That might

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode

== Series Details == Series: series starting with [CI,1/3] drm/i915: Remove unused "valid" parameter from pte_encode URL : https://patchwork.freedesktop.org/series/13646/ State : failure == Summary == LD fs/btrfs/built-in.o LD arch/x86/kernel/cpu/built-in.o LD

[Intel-gfx] ✗ Fi.CI.BAT: failure for series starting with [CI,1/2] drm/i915: Use fence_write() from rpm resume

== Series Details == Series: series starting with [CI,1/2] drm/i915: Use fence_write() from rpm resume URL : https://patchwork.freedesktop.org/series/13642/ State : failure == Summary == Series 13642v1 Series without cover letter

Re: [Intel-gfx] [PATCH] drm/i915: Make sure the base lives at offset 0 of all kms objects

On Wed, Oct 12, 2016 at 02:33:11PM +0300, ville.syrj...@linux.intel.com wrote: > From: Ville Syrjälä > > We occasionally depend on eg. to_intel_crtc(NULL) being NULL as > well. Sprinkle in some BUILD_BUG_ON()s to make sure we don't > accidentally change things in a

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: GMBUS don't need no forcewake

== Series Details == Series: drm/i915: GMBUS don't need no forcewake URL : https://patchwork.freedesktop.org/series/13641/ State : warning == Summary == Series 13641v1 drm/i915: GMBUS don't need no forcewake https://patchwork.freedesktop.org/api/1.0/series/13641/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v4] tools/intel_guc_logger: Utility for capturing GuC firmware logs in a file

On 10/10/2016 15:31, Goel, Akash wrote: On 10/10/2016 7:22 PM, Tvrtko Ursulin wrote: On 10/10/2016 11:59, akash.g...@intel.com wrote: From: Akash Goel This patch provides a test utility which helps capture GuC firmware logs and then dump them to file. The logs are

[Intel-gfx] [PATCH 1/8] drm/i915/skl+: Prepare for removing data rate from skl watermark state

Caching is not required, drm_atomic_crtc_state_for_each_plane_state can be used to inspect all plane_states that are assigned to the current crtc_state, so we can just recalculate every time. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_pm.c

[Intel-gfx] [PATCH 2/8] drm/i915/skl+: Remove data_rate from watermark struct.

It's only used in one function, and can be calculated without caching it in the global struct by using drm_atomic_crtc_state_for_each_plane_state. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_drv.h | 4 drivers/gpu/drm/i915/intel_pm.c

[Intel-gfx] [PATCH 0/8] drm/i915/gen9+: Atomic wm fixes.

This patch series applies on top of Lyude's patches. They clean up the remainder of SKL style wm's, and finally makes SKL watermarks ready for nonblocking modeset by using the crtc_state for watermarks as much as possible. Maarten Lankhorst (8): drm/i915/skl+: Prepare for removing data rate

[Intel-gfx] [PATCH 5/8] drm/i915: Add a atomic evasion step to watermark programming.

Allow the driver to write watermarks during atomic evasion. This will make it possible to write the watermarks in a cleaner way on gen9+. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/i915_drv.h | 6 --

[Intel-gfx] [PATCH 6/8] drm/i915/gen9+: Use the watermarks from crtc_state for everything.

There's no need to keep a duplicate skl_pipe_wm around any more, everything can be discovered from crtc_state, which we pass around correctly now even in case of plane disable. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 2 +-

[Intel-gfx] [PATCH 4/8] drm/i915/skl+: Clean up minimum allocations.

Move calculating minimum allocations to a helper, which cleans up the code some more. The cursor is still allocated in advance because it doesn't count towards data rate and should always be reserved. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [PATCH 7/8] drm/i915/gen9+: Program watermarks as a separate step during evasion

Instead of running the watermark updates from the callbacks run them from a separate hook atomic_evade_watermarks. This also gets rid of the global skl_results, which was required for keeping track of the current atomic commit. Signed-off-by: Maarten Lankhorst

[Intel-gfx] [PATCH 3/8] drm/i915/skl+: Remove minimum block allocation from crtc state.

This is not required any more now that we get fresh state from drm_atomic_crtc_state_for_each_plane_state. Zero all state in advance. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_drv.h | 4 drivers/gpu/drm/i915/intel_pm.c | 15

[Intel-gfx] [PATCH 8/8] drm/i915/gen9+: Preserve old allocation from crtc_state.

This is the last bit required for making nonblocking modesets work correctly. The state in intel_crtc->hw_ddb is not updated until somewhere in atomic commit, while the previous crtc state should be accurate if the ddb hasn't changed. Signed-off-by: Maarten Lankhorst

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Make sure the base lives at offset 0 of all kms objects

== Series Details == Series: drm/i915: Make sure the base lives at offset 0 of all kms objects URL : https://patchwork.freedesktop.org/series/13640/ State : failure == Summary == Series 13640v1 drm/i915: Make sure the base lives at offset 0 of all kms objects

Re: [Intel-gfx] [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

On Wed, Oct 12, 2016 at 04:04:34PM +0300, Jani Nikula wrote: > On Wed, 12 Oct 2016, Joonas Lahtinen wrote: > > On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote: > >> If you really care, go ahead and send the patches to make these Bourne > >> shell compatible,

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix misplaced '\n' in printing the GPU error's RING_HEAD

> Test kms_flip: > Subgroup basic-flip-vs-modeset: > pass -> DMESG-WARN (fi-skl-6770hq) [ 468.807117] [drm:skl_set_cdclk [i915]] *ERROR* failed to inform PCU about cdclk change [ 468.816844] [drm:intel_cpu_fifo_underrun_irq_handler [i915]] *ERROR* CPU pipe C FIFO

Re: [Intel-gfx] [PATCH i-g-t 1/5] tests: Use bash for debugfs_wedged and drm_lib.sh

On Wed, 12 Oct 2016, Joonas Lahtinen wrote: > On ke, 2016-10-12 at 14:16 +0300, Jani Nikula wrote: >> If you really care, go ahead and send the patches to make these Bourne >> shell compatible, but then do also sign up for testing them on non-bash >> shells. The

[Intel-gfx] ✗ Fi.CI.BAT: warning for drm/i915: Fix misplaced '\n' in printing the GPU error's RING_HEAD

== Series Details == Series: drm/i915: Fix misplaced '\n' in printing the GPU error's RING_HEAD URL : https://patchwork.freedesktop.org/series/13639/ State : warning == Summary == Series 13639v1 drm/i915: Fix misplaced ' ' in printing the GPU error's RING_HEAD

Re: [Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

Op 07-10-16 om 13:45 schreef Mika Kahola: > This is a testcase with multiple planes. The idea here is the following > > - draw a uniform frame with blue color > - grab crc for reference > - put planes randomly on top with the same blue color > - punch holes with black color into the primary

Re: [Intel-gfx] [PATCH 20/42] drm/i915: Implement pread without struct-mutex

On pe, 2016-10-07 at 10:46 +0100, Chris Wilson wrote: > @@ -871,7 +845,7 @@ shmem_clflush_swizzled_range(char *addr, unsigned long > length, >  /* Only difference to the fast-path function is that this can handle bit17 >   * and uses non-atomic copy and kmap functions. */ >  static int >

Re: [Intel-gfx] [PATCH] drm/i915: GMBUS don't need no forcewake

On Wed, Oct 12, 2016 at 03:39:47PM +0300, Ville Syrjälä wrote: > On Wed, Oct 12, 2016 at 12:58:34PM +0100, Chris Wilson wrote: > > On Wed, Oct 12, 2016 at 02:44:47PM +0300, ville.syrj...@linux.intel.com > > wrote: > > > From: Ville Syrjälä > > > > > > GMBUS is

Re: [Intel-gfx] [PATCH 13/19] drm/i915: Make IS_BROXTON only take dev_priv

On Wed, Oct 12, 2016 at 01:06:51PM +0100, Tvrtko Ursulin wrote: > > On 12/10/2016 12:52, David Weinehall wrote: > > On Tue, Oct 11, 2016 at 02:21:46PM +0100, Tvrtko Ursulin wrote: > > > From: Tvrtko Ursulin > > > > > > Saves 1392 bytes of .rodata strings. > > > > > >

[Intel-gfx] [CI] drm/i915: Treat a framebuffer reference as an active reference whilst shrinking

Treat a framebuffer reference with the same priority as an active reference whilst shrinking. Framebuffers are likely to be reused and typically cost more to migrate to and from GPU memory (on LLC architectures we need to clflush), so defer the temptation to purge them during a kswapd run until we

[Intel-gfx] [PATCH i-g-t] tests/kms_plane_multiple: CRC based atomic correctness test

This is a testcase with multiple planes. The idea here is the following - draw a uniform frame with blue color - grab crc for reference - put planes randomly on top with the same blue color - punch holes with black color into the primary framebuffer - ideally the planes should cover these

Re: [Intel-gfx] [PATCH] drm/i915: GMBUS don't need no forcewake

On Wed, Oct 12, 2016 at 12:58:34PM +0100, Chris Wilson wrote: > On Wed, Oct 12, 2016 at 02:44:47PM +0300, ville.syrj...@linux.intel.com wrote: > > From: Ville Syrjälä > > > > GMBUS is part of the display engine, and thus has no need for > > forcewake. Let's not

[Intel-gfx] [CI 2/3] drm/i915/gtt: Split gen8_ppgtt_clear_pte_range

Let's use more top-down approach, where each gen8_ppgtt_clear_* function is responsible for clearing the struct passed as an argument and calling relevant clear_range functions on lower-level tables. Doing this rather than operating on PTE ranges makes the implementation of shrinking page tables

[Intel-gfx] [CI 1/3] drm/i915: Remove unused "valid" parameter from pte_encode

We never used any invalid ptes, those were put in place for a possibility of doing gpu faults. However our batchbuffers are not restricted in length, so everything needs to be pointing to something and thus out-of-bounds is pointing to scratch. Remove the valid flag as it is always true. v2:

[Intel-gfx] [CI 3/3] drm/i915/gtt: Free unused lower-level page tables

Since "Dynamic page table allocations" were introduced, our page tables can grow (being dynamically allocated) with address space range usage. Unfortunately, their lifetime is bound to vm. This is not a huge problem when we're not using softpin - drm_mm is creating an upper bound on used range by

[Intel-gfx] ✗ Fi.CI.BAT: warning for series starting with [1/5] drm/i915: Use fence_write() from rpm resume

== Series Details == Series: series starting with [1/5] drm/i915: Use fence_write() from rpm resume URL : https://patchwork.freedesktop.org/series/13636/ State : warning == Summary == Series 13636v1 Series without cover letter

[Intel-gfx] [PATCH i-g-t] intel-ci: Remove kms_psr_sink_crc@psr_basic from BAT

The test is producing a lot of CI noise. Signed-off-by: Petri Latvala --- Will be pushed shortly. Visible in CI results tomorrow-ish. tests/intel-ci/fast-feedback.testlist | 1 - 1 file changed, 1 deletion(-) diff --git a/tests/intel-ci/fast-feedback.testlist

Re: [Intel-gfx] [PATCH 16/19] drm/i915: Make IS_CHERRYVIEW only take dev_priv

On Tue, Oct 11, 2016 at 02:21:49PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Saves 864 bytes of .rodata strings and ~100 of .text. > > v2: Add parantheses around dev_priv. (Ville Syrjala) > > Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] [PATCH 09/19] drm/i915: Make IS_BROADWELL only take dev_priv

On Tue, Oct 11, 2016 at 02:21:42PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Saves 1808 bytes of .rodata strings. > > v2: Add parantheses around dev_priv. (Ville Syrjala) > > Signed-off-by: Tvrtko Ursulin Reviewed-by: David

Re: [Intel-gfx] [RFC i-g-t PATCH 2/3] igt/gem_wait: Use new igt_dummyload api

On Wed, Oct 12, 2016 at 02:59:53PM +0300, Abdiel Janulgue wrote: > Signed-off-by: Abdiel Janulgue > --- > tests/gem_wait.c | 77 > +--- > 1 file changed, 12 insertions(+), 65 deletions(-) We can do so much

Re: [Intel-gfx] [PATCH 13/19] drm/i915: Make IS_BROXTON only take dev_priv

On 12/10/2016 12:52, David Weinehall wrote: On Tue, Oct 11, 2016 at 02:21:46PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Saves 1392 bytes of .rodata strings. v2: Add parantheses around dev_priv. (Ville Syrjala) Signed-off-by: Tvrtko Ursulin

Re: [Intel-gfx] drm/i915: WARN_ON_ONCE(!crtc_clock || cdclk < crtc_clock)

On Wed, 2016-10-12 at 14:08 +0300, Joonas Lahtinen wrote: > Bisecting the offending commit between v4.8 and v4.8.1 would be a good > start. That would be between v4.7 and v4.8. (I guess my report was ambiguous.) That might take some time. Because bisecting always takes a long time and especially

Re: [Intel-gfx] [PATCH 06/19] drm/i915: Make IS_GEN-range macro only take dev_priv

On Tue, Oct 11, 2016 at 02:21:39PM +0100, Tvrtko Ursulin wrote: > From: Tvrtko Ursulin > > Saves 944 bytes of .rodata strings. > > v2: Add parantheses around dev_priv. (Ville Syrjala) > > Signed-off-by: Tvrtko Ursulin Reviewed-by: David

[Intel-gfx] [RFC i-g-t PATCH 1/3] lib: add igt_dummyload

Generalized from auto-tuned GPU dummy workload in gem_wait and kms_flip Signed-off-by: Abdiel Janulgue --- lib/Makefile.sources | 2 + lib/igt.h| 1 + lib/igt_dummyload.c | 419 +++

[Intel-gfx] [RFC i-g-t PATCH 3/3] igt/kms_flip: Use new igt_dummyload api

Signed-off-by: Abdiel Janulgue --- tests/kms_flip.c | 191 +++ 1 file changed, 10 insertions(+), 181 deletions(-) diff --git a/tests/kms_flip.c b/tests/kms_flip.c index 065ad66..93cf391 100644 ---

[Intel-gfx] [RFC i-g-t] Extract autotuned dummy load into lib

A lot of igt testcases need some dummy load to make sure a race window is big enough. Unfortunately having a fixed amount of workload leads to spurious test failures or overtly long runtimes on some fast/slow platforms. This library contains functionality to submit GPU workloads that is

  1   2   >