Re: [Intel-gfx] [PATCH v12 6/6] drm/i915: Introduce GEM proxy

> -Original Message- > From: Chris Wilson [mailto:ch...@chris-wilson.co.uk] > Sent: Wednesday, July 19, 2017 7:20 PM > To: Zhang, Tina ; intel-gfx@lists.freedesktop.org; > intel- > gvt-...@lists.freedesktop.org; dri-de...@lists.freedesktop.org; >

Re: [Intel-gfx] [PATCH 3/3] intel: Make driver aware of MOCS table version

On 17-07-07 09:28:08, Jason Ekstrand wrote: On Thu, Jul 6, 2017 at 4:27 PM, Ben Widawsky wrote: We don't yet have optimal MOCS settings, but we have enough to know how to at least determine when we might have non-optimal settings within our driver. Signed-off-by: Ben

Re: [Intel-gfx] [PATCH 2/4] drm: Create a format/modifier blob

On 17-07-14 22:10:15, Ville Syrjälä wrote: On Fri, Jul 14, 2017 at 11:41:49AM -0700, Ben Widawsky wrote: On 17-06-29 22:49:44, Ville Syrjälä wrote: [snip] > >... but here it's ALIGN(formats_offset+formats_size). I think we should >be aligning the same thing in both cases, or we add a

[Intel-gfx] linux-next: manual merge of the drm tree with the drm-intel-fixes tree

Hi all, Today's linux-next merge of the drm tree got a conflict in: drivers/gpu/drm/i915/intel_pm.c between commit: 9cc5bb18bd0a ("drm/i915: Fix bad comparison in skl_compute_plane_wm") from the drm-intel-fixes tree and commit: eac2cb81fb87 ("drm/i915: cleanup fixed-point wrappers

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

Hi all, The following conflict now exists between the drm and drm-intel trees. On Thu, 20 Jul 2017 11:23:33 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the drm-misc tree got a conflict in: > > drivers/gpu/drm/i915/i915_drv.c > > between commit: > >

Re: [Intel-gfx] linux-next: build failure after merge of the drm-misc tree

Hi Dave, The following is now applicable to the drm and staging.current trees ... On Wed, 19 Jul 2017 11:46:57 +1000 Stephen Rothwell wrote: > > After merging the drm-misc tree, today's linux-next build (x86_64 > allmodconfig) failed like this: > >

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

Hi Dave, The conflict below now exists between the drm-misc-fixes tree and the drm tree. On Tue, 18 Jul 2017 11:39:46 +1000 Stephen Rothwell wrote: > > Today's linux-next merge of the drm-misc tree got a conflict in: > > drivers/gpu/drm/vc4/vc4_crtc.c > > between

[Intel-gfx] [PULL] drm-misc-fixes

Hi Dave, Here's the first -misc-fixes pull for the current cycle. Note that I've based it off Linus' tree, so you might want to ff drm-fixes before applying. Pretty self-explanatory set of patches, I'm sure you have a good handle on the mst group. The vc4 fix comes from drm-misc-next-fixes after

Re: [Intel-gfx] [PATCH 7/7] drm/i915: Drop unpin stall in atomic_prepare_commit

On Thu, Jul 20, 2017 at 07:57:54PM +0200, Daniel Vetter wrote: > The core already does this in setup_commit(). With this we can also > remove the unpin_work_count since it's the last user, and also remove > the loop since that was only used for stalling against legacy flips. > > v2: Amend commit

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Avoid the gpu reset vs. modeset deadlock

== Series Details == Series: drm/i915: Avoid the gpu reset vs. modeset deadlock URL : https://patchwork.freedesktop.org/series/27670/ State : failure == Summary == Series 27670v1 drm/i915: Avoid the gpu reset vs. modeset deadlock

Re: [Intel-gfx] [PATCH v2] drm/i915: Don't touch fence->error when resetting an innocent request

On Thu, Jul 20, 2017 at 02:48:19PM +0100, Chris Wilson wrote: > If the request has been completed before the reset took effect, we don't > need to mark it up as being a victim. Touching fence->error after the > fence has been signaled is detected by dma_fence_set_error() and > triggers a BUG: > >

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't set fence errors on non-guilty requests (rev2)

== Series Details == Series: drm/i915: Don't set fence errors on non-guilty requests (rev2) URL : https://patchwork.freedesktop.org/series/27665/ State : success == Summary == Series 27665v2 drm/i915: Don't set fence errors on non-guilty requests

Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later

On Thu, 2017-07-20 at 10:06 +, Tc, Jenny wrote: > > >> With older panels, AUX pin for backlight doesn't work. > > > > What evidence do you have to back up that claim? > > Debugging further it's found that the panel I am having doesn't support AUX > Backlight. > > cat

Re: [Intel-gfx] [PATCH] drm/i915: Don't set fence errors on non-guilty requests

Oops, sent out the wrong patch, pls disregard. -Daniel On Thu, Jul 20, 2017 at 10:14 PM, Daniel Vetter wrote: > ... at least not in that place, because this can also fire for > requests which have completed. Which then hits the assert in > dma_fence_set_error. > > Since

[Intel-gfx] [PATCH] drm/i915: Avoid the gpu reset vs. modeset deadlock

... using the biggest hammer we have. This is essentially a weaponized version of the timeout-based wedging Chris added in commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 Author: Chris Wilson Date: Thu Jun 22 11:56:25 2017 +0100 drm/i915: Break modeset deadlocks

Re: [Intel-gfx] [PATCH 2/2] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"

On Thu, 2017-07-20 at 12:25 +0300, Jani Nikula wrote: > This reverts commit 560a758d39c616f83ac25ff6e0816a49ebe6401c. > > The DPCD backlight commits regress a Thinkpad X1 Carbon 4th Gen and a > BXT-P (in CI). Enabling dynamic backlight boots to a black screen, and > enabling DPCD backlight

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

On Thu, Jul 20, 2017 at 10:16 PM, Chris Wilson wrote: > Quoting Daniel Vetter (2017-07-20 21:04:50) >> On Thu, Jul 20, 2017 at 9:47 PM, Chris Wilson >> wrote: >> >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> >>

[Intel-gfx] [PATCH] drm/i915: Don't set fence errors on non-guilty requests

... at least not in that place, because this can also fire for requests which have completed. Which then hits the assert in dma_fence_set_error. Since I'm not really clear what should be done here I pinged Chris, and he suggested we simply remove this for now. Found while stress-testing gpu

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

Quoting Daniel Vetter (2017-07-20 21:04:50) > On Thu, Jul 20, 2017 at 9:47 PM, Chris Wilson > wrote: > >> diff --git a/drivers/gpu/drm/i915/intel_display.c > >> b/drivers/gpu/drm/i915/intel_display.c > >> index 02b1f4966049..995522e40ec1 100644 > >> ---

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

On Thu, Jul 20, 2017 at 9:47 PM, Chris Wilson wrote: >> diff --git a/drivers/gpu/drm/i915/intel_display.c >> b/drivers/gpu/drm/i915/intel_display.c >> index 02b1f4966049..995522e40ec1 100644 >> --- a/drivers/gpu/drm/i915/intel_display.c >> +++

Re: [Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

Quoting Daniel Vetter (2017-07-20 18:57:48) > ... using the biggest hammer we have. This is essentially a weaponized > version of the timeout-based wedging Chris added in > > commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 > Author: Chris Wilson > Date: Thu Jun 22

Re: [Intel-gfx] ✓ Fi.CI.BAT: success for gpu reset and page_flip removal, take 2

Quoting Patchwork (2017-07-20 19:14:57) > == Series Details == > > Series: gpu reset and page_flip removal, take 2 > URL : https://patchwork.freedesktop.org/series/27664/ > State : success > > == Summary == > > Series 27664v1 gpu reset and page_flip removal, take 2 >

[Intel-gfx] [PATCH] drm-intel.rst: Fix formatting

Somehow a few formatting issues crept in that rst complained about in commit 7b414ba9e7aa75fc4dff6597036ff758031b9bdf (HEAD -> maintainer-tools) Author: Daniel Vetter Date: Thu Jul 20 21:28:12 2017 +0200 drm-intel.rst: Fix formatting Cc: Rodrigo Vivi

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't set fence errors on non-guilty requests

== Series Details == Series: drm/i915: Don't set fence errors on non-guilty requests URL : https://patchwork.freedesktop.org/series/27665/ State : success == Summary == Series 27665v1 drm/i915: Don't set fence errors on non-guilty requests

Re: [Intel-gfx] [PATCH] drm/i915: Don't set fence errors on non-guilty requests

Quoting Daniel Vetter (2017-07-20 18:59:01) > ... at least not in that place, because this can also fire for > requests which have completed. Which then hits the assert in > dma_fence_set_error. > > Since I'm not really clear what should be done here I pinged Chris, > and he suggested we simply

Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later

On Thu, 2017-07-20 at 18:35 +0300, David Weinehall wrote: > On 2017-07-20 12:33, Jani Nikula wrote: > > On Wed, 19 Jul 2017, "Pandiyan, Dhinakaran" > > wrote: > >> On Wed, 2017-07-19 at 15:59 +0530, Jenny TC wrote: > >>> With older panels, AUX pin for backlight

[Intel-gfx] ✓ Fi.CI.BAT: success for gpu reset and page_flip removal, take 2

== Series Details == Series: gpu reset and page_flip removal, take 2 URL : https://patchwork.freedesktop.org/series/27664/ State : success == Summary == Series 27664v1 gpu reset and page_flip removal, take 2 https://patchwork.freedesktop.org/api/1.0/series/27664/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH 5/5] drm/hisilicon: Remove custom FB helper deferred setup

On Fri, Jul 07, 2017 at 09:28:11AM -0400, Sean Paul wrote: > On Thu, Jul 6, 2017 at 9:00 AM, Daniel Vetter wrote: > > From: Thierry Reding > > > > The FB helper core now supports deferred setup, so the driver's custom > > implementation can be removed.

[Intel-gfx] [PATCH] drm/i915: Don't set fence errors on non-guilty requests

... at least not in that place, because this can also fire for requests which have completed. Which then hits the assert in dma_fence_set_error. Since I'm not really clear what should be done here I pinged Chris, and he suggested we simply remove this for now. Found while stress-testing gpu

[Intel-gfx] [PATCH 6/7] drm/i915: Remove intel_flip_work infrastructure

This gets rid of all the interactions between the legacy flip code and the modeset code. Yay! This highlights an ommission in the atomic paths, where we fail to apply a boost to the pending rendering when we miss the target vblank. But the existing code is still dead and can be removed. v2: Note

[Intel-gfx] [PATCH 5/7] drm/i915: adjust has_pending_fb_unpin to atomic

A bit an oversight - the current code did nothing, since only legacy flips used the unpin_work_count and assorted logic. Cc: Maarten Lankhorst Cc: Ville Syrjälä Reviewed-by: Maarten Lankhorst

[Intel-gfx] [PATCH 7/7] drm/i915: Drop unpin stall in atomic_prepare_commit

The core already does this in setup_commit(). With this we can also remove the unpin_work_count since it's the last user, and also remove the loop since that was only used for stalling against legacy flips. v2: Amend commit message a bit (Chris). Cc: Maarten Lankhorst

[Intel-gfx] [PATCH 3/7] drm/i915: More surgically unbreak the modeset vs reset deadlock

There's no reason to entirely wedge the gpu, for the minimal deadlock bugfix we only need to unbreak/decouple the atomic commit from the gpu reset. The simplest way to fix that is by replacing the unconditional fence wait a the top of commit_tail by a wait which completes either when the fences

[Intel-gfx] [PATCH 4/7] drm/i915: Rip out legacy page_flip completion/irq handling

All these races and things are now solved through the vblank evasion trick, plus event handling is done using normal vblank even processing and drm_crtc_arm_vblank_event. We can get rid of all this complexity. Cc: Maarten Lankhorst Cc: Ville Syrjälä

[Intel-gfx] [PATCH 1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

... using the biggest hammer we have. This is essentially a weaponized version of the timeout-based wedging Chris added in commit 36703e79a982c8ce5a8e43833291f2719e92d0d1 Author: Chris Wilson Date: Thu Jun 22 11:56:25 2017 +0100 drm/i915: Break modeset deadlocks

[Intel-gfx] [PATCH 2/7] drm/i915: Push i915_sw_fence_wait into the nonblocking atomic commit

Blocking in a worker is ok, that's what the unbound_wq is for. And it unifies the paths between the blocking and nonblocking commit, giving me just one path where I have to implement the deadlock avoidance trickery in the next patch. I first tried to implement the following patch without this

[Intel-gfx] [PATCH 0/7] gpu reset and page_flip removal, take 2

Hi all, I landed the locking change, which fixes the gpu reset deadlocks at least for anything modern (and non-igt). Would be great if we can get the first patch landed fast, just to address the regression in CI and get rid of the dmesg-warn. Currently we're blind to dmesg noise in a lot of gpu

Re: [Intel-gfx] [PATCH i-g-t 1/2] lib/igt_core: Move all config-related parsing to common_init_config

For the whole series: Reviewed-by: Lyude And pushed On Thu, 2017-07-20 at 17:11 +0300, Paul Kocialkowski wrote: > This moves all the pieces related to config parsing to the dedicated > function for this purpose, renamed common_init_config for > consistency. > > It allows

Re: [Intel-gfx] [PATCH i-g-t v4 0/2] Analogue/VGA frame comparison support

For the whole series: Reviewed-by: Lyude I've also just pushed them, cheers! On Thu, 2017-07-20 at 18:13 +0300, Paul Kocialkowski wrote: > Changes since v3: > * Squashed configure.ac changes in this series > > Changes since v2: > * Changed analogue in favor of analog > *

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Assert that machine is wedged for nop_submit_request

On 7/20/2017 5:51 AM, Chris Wilson wrote: Quoting Michel Thierry (2017-07-18 01:15:00) On 17/07/17 02:11, Chris Wilson wrote: We should only ever do nop_submit_request when the machine is wedged, so assert it is so. Signed-off-by: Chris Wilson ---

Re: [Intel-gfx] [PATCH] drm/i915: Pass enum pipe to intel_set_pch_fifo_underrun_reporting()

On Thu, Jul 20, 2017 at 1:27 AM, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 10:39:28AM -0700, Matthias Kaehlcke wrote: >> Commit a21960339c8c ("drm/i915: Consistently use enum pipe for PCH >> transcoders") misses some pieces, due to a problem with the patch >> format, this

Re: [Intel-gfx] [PATCH 4/5] drm/i915: Use new atomic iterator macros in display code

Op 16-03-17 om 09:47 schreef Daniel Vetter: > On Wed, Mar 15, 2017 at 09:23:30AM +0100, Maarten Lankhorst wrote: >> Op 14-03-17 om 07:50 schreef Daniel Vetter: >>> On Mon, Mar 13, 2017 at 12:08:19PM +0100, Maarten Lankhorst wrote: Op 13-03-17 om 11:15 schreef Daniel Vetter: > On Thu, Mar

Re: [Intel-gfx] [PATCH v4 4/6] drm/i915: prepare csc unit for YCBCR420 output

On Mon, Jul 17, 2017 at 08:06:25PM +0530, Shashank Sharma wrote: > To support ycbcr output, we need a pipe CSC block to do > RGB->YCBCR conversion. > > Current Intel platforms have only one pipe CSC unit, so > we can either do color correction using it, or we can perform > RGB->YCBCR conversion.

Re: [Intel-gfx] [PATCH v4 3/6] drm/i915: prepare pipe for YCBCR420 output

On Mon, Jul 17, 2017 at 08:06:24PM +0530, Shashank Sharma wrote: > To get HDMI YCBCR420 output, the PIPEMISC register should be > programmed to: > - Generate YCBCR output (bit 11) > - In case of YCBCR420 outputs, it should be programmed in full > blend mode to use the scaler in 5x3 ratio (bits

Re: [Intel-gfx] [RFC PATCH 8/8] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

Op 20-07-17 om 15:15 schreef Maarten Lankhorst: > The watermarks it should calculate against are the old optimal watermarks. > The currently active crtc watermarks are pure fiction, and are invalid in > case of a nonblocking modeset, page flip enabling/disabling planes or any > other reason. > >

[Intel-gfx] Making IGT runnable by CI and developers

Hi everyone, As some of you may already know, we have made great strides in making our CI system usable, especially in the last 6 months when everything started clicking together. The CI team is no longer overwhelmed with fires and bug reports, so we started working on increasing the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Don't touch fence->error when resetting an innocent request (rev2)

== Series Details == Series: drm/i915: Don't touch fence->error when resetting an innocent request (rev2) URL : https://patchwork.freedesktop.org/series/27641/ State : success == Summary == Series 27641v2 drm/i915: Don't touch fence->error when resetting an innocent request

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Stop using get_existing_state.

== Series Details == Series: drm/i915: Stop using get_existing_state. URL : https://patchwork.freedesktop.org/series/27640/ State : success == Summary == Series 27640v1 drm/i915: Stop using get_existing_state. https://patchwork.freedesktop.org/api/1.0/series/27640/revisions/1/mbox/ Test

Re: [Intel-gfx] [PATCH v4 2/6] drm/i915: prepare scaler for YCBCR420 modeset

On Mon, Jul 17, 2017 at 08:06:23PM +0530, Shashank Sharma wrote: > To get a YCBCR420 output from intel platforms, we need one > scaler to scale down YCBCR444 samples to YCBCR420 samples. > > This patch: > - Does scaler allocation for HDMI ycbcr420 outputs. > - Programs PIPE_MISC register for

Re: [Intel-gfx] [PATCH] drm/i915: Use AUX for backlight only if eDP 1.4 or later

On 2017-07-20 12:33, Jani Nikula wrote: On Wed, 19 Jul 2017, "Pandiyan, Dhinakaran" wrote: On Wed, 2017-07-19 at 15:59 +0530, Jenny TC wrote: With older panels, AUX pin for backlight doesn't work. What evidence do you have to back up that claim? Chapter 10.1

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

== Series Details == Series: drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3. URL : https://patchwork.freedesktop.org/series/27639/ State : failure == Summary == CHK include/config/kernel.release CHK include/generated/uapi/linux/version.h CHK

Re: [Intel-gfx] [PATCH i-g-t v3 0/2] Analogue/VGA frame comparison support

On Wed, 2017-07-19 at 13:50 -0400, Lyude Paul wrote: > For both patches once you squash the configure.ac changes into the > first one: > > Reviewed-by: Lyude > > Once you post the new versions I'll just go ahead and push them I think it makes more sense to split the

[Intel-gfx] [PATCH i-g-t v4 1/2] lib/igt_frame: Add support for analog frame comparison testing

This adds support for analog frame comparison check, as used in VGA. Since VGA uses a DAC-ADC chain, its data cannot be expected to be pixel perfect. Thus, it is impossible to uses a CRC check and full frames have to be analyzed instead. Such an analysis is implemented, based on both an absolute

[Intel-gfx] [PATCH i-g-t v4 2/2] chamelium: Add support for VGA frame comparison testing

This adds support for VGA frame comparison testing with the reference generated from cairo. The retrieved frame from the chamelium is first cropped, as it contains the blanking intervals, through a dedicated helper. Another helper function asserts that the analog frame matches or dump it to png if

[Intel-gfx] [PATCH i-g-t v4 0/2] Analogue/VGA frame comparison support

Changes since v3: * Squashed configure.ac changes in this series Changes since v2: * Changed analogue in favor of analog * Integrated analog frame match fixup in the original commit * Rebased on top of the new revisions of the series this depends on Changes since v1: * Split analogue frame

Re: [Intel-gfx] [PATCH] Revert "drm/i915: Add heuristic to determine better way to adjust brightness"

On Tue, Jul 18, 2017 at 11:56:23AM -0700, Puthikorn Voravootivat wrote: > May be the older panel might not work well with this feature. > David/Jani, what do you think about adding check that the panel is eDP > 1.4 or later in the heuristic? While this patch might seem correct on the surface

Re: [Intel-gfx] [PATCH 1/2] drm/i915: Fix scaler init during CRTC HW state readout

Acked-by: Shashank Sharma Regards Shashank On 7/20/2017 4:20 AM, Imre Deak wrote: The scaler allocation code depends on a non-zero default value for the crtc scaler_id, so make sure we initialize the scaler state accordingly even if the crtc is off. This fixes at

Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq

On Wed, 2017-07-19 at 23:11 -0700, Manasi Navare wrote: > On Tue, Jul 18, 2017 at 03:11:42PM +0300, Paul Kocialkowski wrote: > > On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote: > > > After detecting an IRQ storm, hotplug detection will switch from > > > irq-based detection to

Re: [Intel-gfx] [PATCH] drm/i915: Synchronize connectors states when switching from poll to irq

On Thu, 2017-07-20 at 01:04 +, Pandiyan, Dhinakaran wrote: > On Mon, 2017-06-26 at 15:32 +0300, Paul Kocialkowski wrote: > > After detecting an IRQ storm, hotplug detection will switch from > > irq-based detection to poll-based detection. After a short delay or > > when resetting storm

Re: [Intel-gfx] Artifacts on virtual console basing on inteldrmfb framebuffer

Moving to intel-gfx list, intel-gfx-bugs is mainly just for the automated emails from bugzilla. And please let's keep the debugging in the bug. BR, Jani. On Thu, 20 Jul 2017, sdrb wrote: > Hello, > > I have got some problems with intel drm frame buffer on Linux virtual >

Re: [Intel-gfx] Fixes that failed to backport to v4.13-rc1

On Wed, 19 Jul 2017, Maarten Lankhorst wrote: > Op 19-07-17 om 15:17 schreef Jani Nikula: >> Another kernel, another list of failed backports. >> >> The following commits have been marked as Cc: stable or fixing something >> in v4.13-rc1 or earlier, but failed

[Intel-gfx] [PATCH i-g-t 1/2] tests/debugfs_test: Fix testcases to pass

emon_crash should skip if the debugfs file could not be opened the first time, and debugfs_test.read_all_entries should skip files that could not be opened, instead of returning an error. This is because in a typical IGT run there may be more debugfs files registered than can be opened. This is

[Intel-gfx] [PATCH i-g-t 2/2] igt: Add debugfs_test.read_all_entries to the fast-feedback list

Every time we add something to debugfs, we test on the new platform but forget to test that old platforms still work. The test adds at most 200 ms extra time, which is worth it considering how often we break debugfs. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [maintainer-tools PATCH] Add flowchart to help determine appropriate branch

This patch adds a flowchart to the drm-misc documentation to help committers decide which branch is most appropriate for a given patch. Signed-off-by: Sean Paul --- .gitignore | 1 + Makefile | 2 +- drm-misc-commit-flow.dot | 22

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging

Chris Wilson writes: > Quoting Mika Kuoppala (2017-07-20 14:31:31) >> Chris Wilson writes: >> >> > When we wedge the device, we clear out the in-flight requests and >> > advance the breadcrumb to indicate they are complete. However, the >> >

Re: [Intel-gfx] [PATCH i-g-t v5 4/7] Introduce common frame dumping configuration and helpers

On Thu, 2017-07-20 at 09:24 +0200, Daniel Vetter wrote: > On Wed, Jul 19, 2017 at 04:46:07PM +0300, Paul Kocialkowski wrote: > > This introduces a common FrameDumpPath configuration field, as well > > as > > helper functions in dedicated igt_frame for writing cairo surfaces > > to png files. > >

[Intel-gfx] [PATCH i-g-t 1/2] lib/igt_core: Move all config-related parsing to common_init_config

This moves all the pieces related to config parsing to the dedicated function for this purpose, renamed common_init_config for consistency. It allows making the common_init function less big and more readable. Signed-off-by: Paul Kocialkowski ---

[Intel-gfx] [PATCH i-g-t 2/2] lib/igt_core: Split out env-related handling to common_init_env

This moves the parts of the code doing env-related handling from common_init to a new dedicated common_init_env function, making common_init a bit more readable. Signed-off-by: Paul Kocialkowski --- lib/igt_core.c | 46

[Intel-gfx] [PATCH i-g-t] docs: Update documentation generation with missing entries

This adds missing entries for documentation generation, both for tests and the API reference. The list of tests is made complete and ordered alphabetically, with modified descriptions for consistency. More files are added to the API reference, with a minimalistic description block added to them

Re: [Intel-gfx] [Linaro-mm-sig] [PATCH] dma-fence: Don't BUG_ON when not absolutely needed

Am Donnerstag, den 20.07.2017, 14:51 +0200 schrieb Daniel Vetter: > It makes debugging a massive pain. It is also considered very bad style to BUG the kernel on anything other than filesystem eating catastrophic failures. Reviewed-by: Lucas Stach > Signed-off-by: Daniel

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging

Quoting Mika Kuoppala (2017-07-20 14:31:31) > Chris Wilson writes: > > > When we wedge the device, we clear out the in-flight requests and > > advance the breadcrumb to indicate they are complete. However, the > > breadcrumb advance includes an assert that the engine is

[Intel-gfx] [PATCH v2] drm/i915: Don't touch fence->error when resetting an innocent request

If the request has been completed before the reset took effect, we don't need to mark it up as being a victim. Touching fence->error after the fence has been signaled is detected by dma_fence_set_error() and triggers a BUG: [ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434! [

Re: [Intel-gfx] [PATCH 09/15] drm/i915: Wake up waiters after setting the WEDGED bit

Chris Wilson writes: > After setting the WEDGED bit, make sure that we do wake up waiters as > they may not be waiting for a request completion yet, just for its > execution. > > Signed-off-by: Chris Wilson Reviewed-by: Mika Kuoppala

[Intel-gfx] ✓ Fi.CI.BAT: success for dma-fence: Don't BUG_ON when not absolutely needed

== Series Details == Series: dma-fence: Don't BUG_ON when not absolutely needed URL : https://patchwork.freedesktop.org/series/27636/ State : success == Summary == Series 27636v1 dma-fence: Don't BUG_ON when not absolutely needed

Re: [Intel-gfx] [PATCH v3 5/5] drm/i915/execlists: Read the context-status HEAD from the HWSP

Chris Wilson writes: > The engine also provides a mirror of the CSB write pointer in the HWSP, > but not of our read pointer. To take advantage of this we need to > remember where we read up to on the last interrupt and continue off from > there. This poses a problem

Re: [Intel-gfx] [PATCH] drm/i915: Don't touch fence->error when resetting an innocent request

Quoting Chris Wilson (2017-07-20 14:24:29) > If the request has been completed before the reset took effect, we don't > need to mark it up as being a victim. Touching fence->error after the > fence has been signaled is detected by dma_fence_set_error() and > triggers a BUG: > > [ 231.743133]

Re: [Intel-gfx] [PATCH 08/15] drm/i915: Clear execlist port[] before updating seqno on wedging

Chris Wilson writes: > When we wedge the device, we clear out the in-flight requests and > advance the breadcrumb to indicate they are complete. However, the > breadcrumb advance includes an assert that the engine is idle, so that > advancement needs to be the last step

[Intel-gfx] [PATCH] drm/i915: Don't touch fence->error when resetting an innocent request

If the request has been completed before the reset took effect, we don't need to mark it up as being a victim. Touching fence->error after the fence has been signaled is detected by dma_fence_set_error() and triggers a BUG: [ 231.743133] kernel BUG at ./include/linux/dma-fence.h:434! [

[Intel-gfx] ✗ Fi.CI.BAT: failure for drm/i915: Only mark the execobject as pinned on success

== Series Details == Series: drm/i915: Only mark the execobject as pinned on success URL : https://patchwork.freedesktop.org/series/27634/ State : failure == Summary == Series 27634v1 drm/i915: Only mark the execobject as pinned on success

Re: [Intel-gfx] [PATCH 07/15] drm/i915: Move idle checks before intel_engine_init_global_seqno()

Chris Wilson writes: > intel_engine_init_globa_seqno() may be called from an uncontrolled > set-wedged path where we have given up waiting for broken hw and declare > it defunct. Along that path, any sanity checks that the hw is idle > before we adjust its state will

[Intel-gfx] [PATCH 5/8] drm/i915: Remove last references to drm_atomic_get_existing* macros

All the references to get_existing_state can be converted to get_new_state or get_old_state, which means that i915 is now get_existing_state free. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_display.c | 57

[Intel-gfx] [PATCH 2/8] drm/i915: Change get_existing_crtc_state to old state

get_existing_crtc_state is currently unused, but the next commit needs to access the old intel state. Rename this and use this as convenience wrapper. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_drv.h | 6 +++--- 1 file changed, 3

[Intel-gfx] [PATCH 3/8] drm/i915: Use new atomic helpers in intel_plane_atomic_check

Remove the use of plane->state and drm_atomic_get_existing_state, instead use the new helpers, and also add intel_atomic_get_new_crtc_state as it's needed. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_atomic_plane.c | 22

[Intel-gfx] [PATCH 4/8] drm/i915: Use intel_atomic_get_new_crtc_state in intel_fbc.c

The previous commit added intel_atomic_get_new_crtc_state, convert intel_fbc.c to the new helper. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_fbc.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) diff --git

[Intel-gfx] [RFC PATCH 7/8] drm/i915: Calculate ironlake intermediate watermarks correctly, v2.

The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the

[Intel-gfx] [PATCH 6/8] drm/i915: Do not update legacy state any more

FBC has been converted to atomic, so updating some legacy variables is no longer needed. drm_atomic_helper_update_legacy_modeset_state does update crtc->x/y anyway, but we shouldn't need it. Signed-off-by: Maarten Lankhorst ---

[Intel-gfx] [RFC PATCH 8/8] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the

[Intel-gfx] [PATCH 1/8] drm/i915: Change use get_new_plane_state instead of existing plane state

The get_existing macros are deprecated and should be replaced by get_old/new_state for clarity. Signed-off-by: Maarten Lankhorst --- drivers/gpu/drm/i915/intel_atomic.c | 4 ++-- drivers/gpu/drm/i915/intel_drv.h| 4 ++-- drivers/gpu/drm/i915/intel_pm.c

[Intel-gfx] [PATCH 0/8] drm/i915: Stop using get_existing_state.

drm_atomic_get_existing_state should be removed, so stop using it in i915. Fortunately all places can be converted to use the new state or old state, even removing some dereferncing of obj->state in the process. i915 no longer depends on plane->fb, so patch 6 removes the assignment. The first 6

Re: [Intel-gfx] [PATCH 04/15] drm/i915: Flush the execlist ports if idle

Chris Wilson writes: > When doing a GPU reset, the CSB register will be trashed and we will > lose any context-switch notifications that happened since the tasklet > was disabled. If we find that all requests on this engine were > completed, we want to make sure that

Re: [Intel-gfx] [PATCH 07/18] drm/i915/bxt, glk: Give a proper name to the power well struct phy field

On Thu, Jul 06, 2017 at 05:40:29PM +0300, Imre Deak wrote: > Follow-up patches will add new fields to the i915_power_well struct that > are specific to the hsw_power_well_ops helpers. Prepare for this by > changing the generic 'data' field to a union of platform specific > structs. > >

Re: [Intel-gfx] [PATCH v3 06/18] drm/i915: Check for duplicated power well IDs

On Tue, Jul 11, 2017 at 11:42:33PM +0300, Imre Deak wrote: > Check that all the power well IDs are unique on the given platform. > > v2: > - Fix using BIT_ULL() instead of BIT() for 64 bit mask. > v3: > - Move the check to a separate function. (Ville) > > Signed-off-by: Imre Deak

[Intel-gfx] [TRYBOT PATCH] drm/i915: Calculate vlv/chv intermediate watermarks correctly, v3.

The watermarks it should calculate against are the old optimal watermarks. The currently active crtc watermarks are pure fiction, and are invalid in case of a nonblocking modeset, page flip enabling/disabling planes or any other reason. When the crtc is disabled or during a modeset the

[Intel-gfx] ✓ Fi.CI.BAT: success for drm/i915: Remove assertion from raw __i915_vma_unpin()

== Series Details == Series: drm/i915: Remove assertion from raw __i915_vma_unpin() URL : https://patchwork.freedesktop.org/series/27632/ State : success == Summary == Series 27632v1 drm/i915: Remove assertion from raw __i915_vma_unpin()

Re: [Intel-gfx] [PATCH 13/15] drm/i915: Emit a user level message when resetting the GPU (or engine)

Quoting Michel Thierry (2017-07-18 01:22:28) > On 17/07/17 02:11, Chris Wilson wrote: > > Although a banned context will be told to -EIO off if they try to submit > > more requests, we have a discrepancy between whole device resets and > > per-engine resets where we report the GPU reset but not

[Intel-gfx] [PATCH] dma-fence: Don't BUG_ON when not absolutely needed

It makes debugging a massive pain. Signed-off-by: Daniel Vetter Cc: Sumit Semwal Cc: Gustavo Padovan Cc: linux-me...@vger.kernel.org Cc: linaro-mm-...@lists.linaro.org --- drivers/dma-buf/dma-fence.c | 4 ++--

[Intel-gfx] ✓ Fi.CI.BAT: success for series starting with [1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock

== Series Details == Series: series starting with [1/7] drm/i915: Avoid the gpu reset vs. modeset deadlock URL : https://patchwork.freedesktop.org/series/27631/ State : success == Summary == Series 27631v1 Series without cover letter

Re: [Intel-gfx] [PATCH 10/15] drm/i915: Assert that machine is wedged for nop_submit_request

Quoting Michel Thierry (2017-07-18 01:15:00) > On 17/07/17 02:11, Chris Wilson wrote: > > We should only ever do nop_submit_request when the machine is wedged, so > > assert it is so. > > > > Signed-off-by: Chris Wilson > > --- > > drivers/gpu/drm/i915/i915_gem.c | 1

Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements

On Thu, 2017-07-20 at 14:41 +0200, Daniel Vetter wrote: > On Thu, Jul 20, 2017 at 1:27 PM, Paul Kocialkowski > wrote: > > On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote: > > > For future reference, please post new versions of the entire > > > series as > >

Re: [Intel-gfx] [PATCH i-g-t v5 0/7] CRC testing with Chamelium improvements

On Thu, Jul 20, 2017 at 1:27 PM, Paul Kocialkowski wrote: > On Thu, 2017-07-20 at 12:39 +0300, Jani Nikula wrote: >> For future reference, please post new versions of the entire series as >> new threads. When posting new versions of just some individual >>

  1   2   >